Hi Noel, In "Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for LISP" you wrote:
> Not necessarily. It all depends on what functionality you're > trying to get out of that layer of binding, i.e. how often the > average binding changes. E.g. if you try and do some > mobility through that binding layer (I'm not saying we should, > just as an illustration) that will radically increase the > rate/amount of updates. The most obvious thought about using a core-edge separation scheme such as LISP, APT, Ivip, etc. (Six/One Router too?) for mobility is that the mapping needs to change every time the Mobile Node (MN) gets a new Care of Address (CoA). This is not the case, since the best way to cater for MNs is to have them establish two-way tunnels to a "nearby" Translating Tunnel Router (TTR). The TTR acts as an ETR for packets going to the MN, and probably as an ITR for packets coming from the MN. The MN may have multiple CoAs and would establish a tunnel from each to the "nearby" TTR. It is up to the MN and the TTR (not a concern of the core-edge separation scheme) how traffic is directed over these multiple tunnels. If one or more of the new CoAs are not "near" the current TTR, the MN can keep the current TTR and establish tunnel(s) from the CoA(s) to another TTR which is "nearby". There only needs to be a mapping change from the first TTR's address to the second TTR's address when the excessive distance, (or perhaps some other impediment, such as congestion) to the first TTR makes the second preferable. With Ivip, the end-user network (in this case, the owner of the MN) pays a small fee per mapping change. So the frequency of mapping changes and their impact on the fast-push mapping distribution system will tend to be a commercially agreeable arrangement. The consortium of Root Update Authority System organisations which build and run the network (or all but the last stages, near the ISPs) will be charging their end-user customers directly or indirectly. They will try to reduce fees and costs, while making the system have the greatest capacity and performance. The end-users pay for most of the fast-push infrastructure and if they are not paying enough to run it well, the operators put up the prices. So the "tragedy of the commons" arrangement where people can impose their changes on a global system without in some way paying for the cost of these changes is largely or entirely avoided. I think we should encourage mobility for Ivip, since mobility is so valuable and the revenues from this potentially huge number of end-users will help pay for the fast-push mapping system. The TTR approach to mobility for core-edge separation schemes is described here: TTR Mobility Extensions for Core-Edge Separation Solutions to the Internet's Routing Scaling Problem Robin Whittle (First Principles) and Steven Russert (Boeing) 2008-08-25 http://www.firstpr.com.au/ip/ivip/TTR-Mobility.pdf This is not a peer-reviewed paper. RRG folks are peers - so please review it on the RRG list! Not using something like the TTR approach turns out to be difficult or impossible. When a MN gets a CoA, it might be behind NAT. Also, the CoA address is probably not a place where the MN could successfully send packets to the rest of the Net with the source address being its EID/micronet address. An ETR could presumably connect to some MN, if the ETR was wise to the local network in which the MN had its CoA. However, this is impossible if the CoA is behind NAT - so in this situation and perhaps in others, the MN needs to connect to the ETR by establishing a two-way tunnel to the ETR *from* its CoA. To get outgoing packets to the Net, the MN needs to have some device which it can tunnel to which is able to forward these packets. When you look at doing all this starting with the ordinary, non-mobile, ETR as a starting point, pretty soon you realise the MN needs to create a two-way tunnel to the ETR anyway. Then, you might as well make this ETR handle outgoing packets too - in which case it probably makes sense for it to be an ITR too. Then, you realise that this combined device - the same thing as a TTR - does not have to be in the same access network as the MN. For efficiency (short physical paths, low hop count, short delays, less packet loss), it needs to be "near" to wherever the MN connects to an access network - but it will still work, with more delays and greater risk of packet loss, if the TTR and the MN are on opposite sides of the world. "Near" probably means something like 1000km or so. So a mapping change is typically "needed" - more likely is desirable, but not absolutely needed - when the MN moves more than 1000 km. Some MNs will move this far once or more a day - but only when on commercial airliners or by car or train on long, linear, journeys. Most MNs will stay in the same area for months or years and so can keep using the one TTR - so there is no need for a mapping change - despite connecting and disconnecting potentially thousands of times to different access networks and so having at various times potentially thousands of different CoAs. While I agree that mobility would drive a much greater number of mapping changes, this is not due to MNs getting new CoAs. It would be caused primarily by there being a vastly greater number of mobile "end-user networks", each a handset or PC etc. than there are conventional, non-mobile, end-user networks with any need for multihoming, TE and portability. A new CoA could happen very frequently, such as switching to WiFi in a subway tunnel and then back to 3G when out of the tunnel. Just walking around a large city on a 3G network could put the MN in an area for a different IP gateway, so it gets a different CoA. Moving something like 1000km - or whatever change in CoA is required to make the now more distant current TTR a problem - is a far less frequent event. You are not saying that mobility should be handled by a core-edge separation scheme but I am saying emphatically that it should be. The LISP folks must be assuming the use of their system for mobility. How else would there be 10^10 EIDs? This is the target set by Dino in recent posts for LISP-ALT and any other core-edge separation scheme. Mobility is at least as big a deal for TCP/IP as it is for telephony. The TTR approach enables the MN to retain its one or more IP addresses - an EID prefix, micronet or whatever - indefinitely. As long as there is a mapping change to the new TTR when the MN moves so far as to make it worth tunneling to a new, closer, TTR, then the overall path of packets to and from the MN and all its correspondent nodes is either optimal or generally close to optimal. Other than some tunneling and TTR communications software in the MN, there are no stack, API or application changes in the MN. Correspondent nodes require no changes whatsoever. This will work fine with IPv4 or IPv6. However, global mobility for anything more than a billion or so devices is going to require IPv6. A billion single IPv4 address micronets would probably be fine with Ivip. The system can use address space close to 100% efficiently, for instance breaking a /12 Mapped Address Block (MAB) into 2^20 single IP address micronets, one for each cellphone-PC-media-player-whatever. Massive global mobile IP access networks will generally need to be built with IPv6. A MN can always tunnel to a TTR via IPv6 and conduct IPv4 communications to the rest of the world through that tunnel - but in the long-term, if billions of people are to have these things, even with 100% efficient utilization of IPv4 space with one IPv4 address micronet per each device, there is not going to be enough IPv4 space to go around. - Robin _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
