Here's an easy way to convert an understanding of conventional mobile IP into an understanding of the Ivip approach.
This Ivip vision of mobility is very different from Bill Herrin's (message 766). His vision involves the ITRs tunnelling packets directly to Care of Addresses in each access network. The Ivip approach involves the ITRs tunnelling to relatively stable TTRs, which involves far less mapping changes than with Bill's model. Also, Bill's model involves each mobile node somehow forwarding packets with its own IP address as the source, from various access networks. In the Ivip model, these outgoing packets are forwarded from the TTRs, which are operated by a company with which the mobile end-user has a lasting business relationship. Start with the MN (Mobile Node) and a Home Agent (HA) router. The HA is in one fixed location and the MN can be anywhere. The MN gains one or more Care of Addresses, CoA-A, CoA-B etc. It builds a 2-way encrypted tunnel from each CoA to the HA. Ordinary Correspondent Hosts (CHs) send packets to the MN on its permanent IP address, which is always handled by the HA. The HA tunnels the packets to the MN. In the opposite direction, the packets from the MH addressed to the CH are tunnelled to the HA and forwarded conventionally to the CH. The MN needs some new software, which is fine. In the above scenario, the CH doesn't need new software. The trouble is that the HA isn't necessarily anywhere near the CH or the MN, so there is often really excessive path lengths. If the MN is in Los Angeles and the CH in San Francisco, it is clearly bad if the HA is in Prague. This is called "triangle routing". The only way of fixing this with conventional Mobile IP is to put fancy software in the OS of the CH, so it can send the packets directly to the MN, thereby achieving optimal path lengths. There is a lot of complexity in this, in order to do it robustly and securely. This is called "route optimisation". So conventional mobile IP can only achieve optimal path lengths by the use of elaborate new software in both the MH and the CH - and I think there needs to be a HA somewhere too to get things going and to support CHs which lack the fancy software. Now return to the plain use of the HA, with the CH having no special software. This is OK, except for the problem of "triangle routing". With Ivip, the MH can set up 2-way tunnels with one or more Translating Tunnel Routers. These can be thought of like "Home Agents" - except there are thousands of them around the Net, operated by some company which the end-user has a business relationship with. The MN chooses a TTRs which is close to the current access networks - and sets up tunnels to that TTR. Now it can use it somewhat like a HA. This is where the map-encap scheme comes in. Without the map-encap scheme, there is no way CHs could get packets to these TTRs - unless the CHs had elaborate software and were in some way coordinated, such as by a HA. The map-encap scheme solves this problem neatly. The end-user has a micronet of address space (EID prefix, in LISP or ALT terminology). That micronet may be as small as a single IP address, but it could be of any size. The end-user arranges things so the TTR company can control the mapping of their micronet. The TTR company sets the mapping to point to the TTR which the MN has one or more 2-way tunnels to. This one TTR could have two 2-way tunnels to the MH, each via a different CoA at a different access network. Suitable software in the TTR and MH sends incoming and outgoing packets over both links for redundancy. As long as the MH is in the same approximate geographic area, it gains new CoA addresses in various access networks and makes 2-way tunnels to the same currently active TTR. Path lengths are optimal, since the TTR is near the MH and there are ITRs near all the CHs. The key point is that there is no need at all for the CHs to have special mobility software. So it works fine for all IPv4 and IPv6 CHs. When the MH moves significantly - typically 1000s of km - it can still make 2-way tunnels from its new access network CoAs to the current TTR. However, it figures out (with the help of the TTR company's network and its special software provided by that company) that it is now far from the current TTR. So it finds a nearby second TTR and builds 2-way tunnels to it. Once this is done, the mapping is changed to point to the new TTR. There is no break in connectivity, since the MH has tunnels to both TTRs. Once the mapping change is complete, the old TTR isn't needed any more. All packets are again following optimal or close to optimal paths, since the new TTR is close to the MN, and all the CHs are close to ITRs. As long as there is some kind of connectivity to some access network, there is no loss of connectivity to the MN. There is no need for mobility features in CHs, or in the access networks. The end-user needs a micronet and to be a customer of a TTR company. Neither the end-user or the TTR company need to have any business relationship or technical coordination with the access network - beyond whatever the end-user needs for their MN to be admitted to the access network and to gain a CoA. It is fine if the CoA is behind one or more layers of NAT, since the MN makes the 2-way encrypted tunnel to the TTR. Please see my previous message 765 for how there are 3 separate mobility systems at work here, and how the mapping only needs to when the MN moves large geographic distances. Note that the MN <==> TTR relationship does all the mobility work which is required while the MN stays in the one geographic area. The same TTR can be used after a big move, but it is best to get another one after moving a large distance. It is only then that the mapping needs to change. When the mapping does needs to change, most end-users will want or need it to change in a few seconds. However, even the most rapidly moving end-user won't be changing their mapping more than every hour or two. Unlike BGP and APT, which involve flooding of changes, with no gateway, with difficulties authenticating the changes and with no reasonable way of charging for each change, Ivip's changes are propagated by a highly efficient past-push system, which will involve charges in one form or another per update. http://www.firstpr.com.au/ip/ivip/draft-whittle-ivip-db-fast-push-00.pdf This pays for the fast push system and avoids the problem which is inherent in BGP and APT of some end-users propagating what others consider to be an unreasonably number of changes, burdening the whole system, without contributing any payment towards it. The role of the map-encap scheme in this form of mobility is to: 1 - Allow the use of TTRs - which are like inventing a HA nice and close to the current access network(s), while: 2 - Ensuring packets get to the the TTR with optimal or nearly optimal path lengths, while: 3 - Requiring no mobility software in the correspondent hosts. This is not at all like multihoming to multiple CoAs and access networks rather than to multiple ETRs. It is a little like multihoming to one TTR or another according to large (> 1000km) geographic movements. However, there is typically not a way of predicting where the new TTR will be. So to make the system work well, there needs to be fast (seconds, not minutes or hours) control of the mapping for all ITRs, so the end-user can use the nearest TTR without undue delay. Only Ivip is intended to provide this. However, the end users don't need to change their mapping every few seconds, or in most cases every few hours. Since most people spend most of their time in the one 1000km geographic area, the mapping update rate is slow and not at all related to the changes in access network, which could be very frequent indeed. - Robin -- to unsubscribe send a message to [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
