Hi Brian, In "Re: [RRG] Mobility frequency" you wrote:
> I think we should also remember Layer 7 mobility. There are many > application suites that recover in one way or another from a low > frequency of Layer 3 disconnects and re-addressing events, using > Layer 7 identities to restore a connection and to maintain > application state. This is so much established practice that it > really gives us license to offer best-effort mobility at Layer 3. > > That doesn't mean we shouldn't strive for fast handover etc., > but ultimately it's the applications' job to survive connectivity > problems. I agree. Any application which actually copes with a radio mobile situation has to cope with the radio link being physically flaky or inoperative, with no notice or predictability. In an offlist discussion, Bill Herrin suggested that an ideal mobile arrangement wouldn't close down application communication sessions when it lost connectivity. Currently, I think if the physical link goes down, the operating system's concept of the IP address which was bound to that link is instantly deleted, causing any applications which use it to terminate their session with the correspondent host. This makes some sense when connectivity is via Ethernet cables and IP addresses are assigned dynamically, or when a fixed IP address is used and applications are regarded as best closed down if the cable is unplugged. However, in a world where a map-encap scheme such as Ivip enables a device to have its own IP addresses, or subnet of address space, semi-permanently, then operating systems could be tweaked to regard loss of all physical links to ETRs as a temporary inconvenience. The IP address would still exist - its just that no packets would arrive from the outside world for it, and probably any packets sent out from it would be dropped. (In this discussion TTR means Translating Tunnel Router - which behaves as an ETR and has a two-way encrypted link from the mobile node, also accepting outgoing packets from the mobile node and forwarding them to the rest of the Internet.) Then, from the application's point of view, there's no visible difference between: 100% packet loss in both directions, followed later by normal connectivity. Loss of all radio links (or the one used for the currently mapped ETR) for a few seconds or for hours or days. The currently used ETR/TTR becomes unusable - due to it being unreachable from the Net, or the radio link the mobile node used to make the 2-way tunnel to it goes down. Either the ETR becomes usable again, the mobility monitoring system switches the mapping to another ETR/TTR which the mobile node has an operating tunnel to, or at some later time the mobile node fires up another radio link, finds another ETR/TTR and the mapping is changed to that one instead. In all cases the mobile node's operating system is gaining and relinquishing care-of addresses in the various networks it connects to, and creating 2-way tunnels from these to ETRs/TTRs which are ideally closest to each point where the mobile node connects to each ISP network. Meanwhile, the mobile node's tunnel software is connecting these tunnels to the local IP address (or prefix) which the operating system knows it has indefinitely. Maybe, one day, an Ivip-like system could achieve a latency as low as a second or two between the user command and all the ITRs in the world changing their tunnelling. 5 seconds seems a more realistic initial goal. (Using LISP's approach of the ITRs testing reachability and tunnelling to an alternative ETR wouldn't be any faster, unless there was an oppressive number of probes, or acknowledgement packets by which the ITR could detect loss of connectivity moment-to-moment.) [Plan A - not as good as Plan B] An application which really wants to achieve continued real-time connectivity in a setting such as this, with Ivip, would need two or more micronets each mapped to a separate ETR/TTR, with the mobile node having a tunnel to each of these via a different radio link, and therefore a different network and care-of address. Then, the application software at the correspondent host could do a brute force communication style of sending packets to the two or more IP addresses of the mobile node in the two or more micronets, such that full communication would continue as long as just one of them was working at any one time. Thinking about this . . . it doesn't have to be the application at the other end which does this. [Plan B] There could be a single TTR which the end-user's single micronet is mapped to. The micronet could be as small as a single IPv4 address. The TTR would typically be outside each radio network, and hopefully geographically close to all the radio networks the mobile node has connections with. The mobile node has multiple care-of addresses and 2-way tunnels from each of these to the one TTR. The TTR decapsulates packets and sends the same packet out on every one of these tunnels to the mobile node, so the tunnelling software (which can have its own private protocols etc. not necessarily part of Ivip, as it chooses the TTRs to tunnel to, probably with outside help) can recognise the arrival of duplicates and feed only one to the stable, IP address where it goes to the application. Similarly, every time an application in the mobile node emits a packet, the tunnelling software sends it out on the two or more tunnels, and the TTR is smart enough to use the first copy which arrives and ignore the rest - forwarding that packet to its destination in the Internet. This form of multi-radio-link parallel redundancy would be extremely robust to drop-outs and lost radio sessions - and would be completely transparent to the TCP/IP stack and applications in both the mobile node and the correspondent node. So the only host changes are some pretty fancy add-in software in the mobile node to make these care-of addresses and do the tunnelling - and perhaps the OS being configured not to terminate the node's IP address even if all the tunnels go down. [Plan C] Another option would be the mobile node establishing two or more tunnels to separate TTRs, and the mapping of the micronet being set to tunnel packets to one of these TTRs. To ensure robust communications, this "master TTR" sets up 2-way encrypted tunnels with the other one or more TTRs, sending every packet received from an ITR directly to the mobile node, and indirectly via the one or more other TTRs. Likewise, the mobile node sends each outgoing packet on every 2-way tunnel it has to a TTR, and the slaves send these packets to the master. Brute force parallel redundancy could then be achieved with TTRs which are all close to, or within, the various ISP networks of the various physical links - WiFi, 3G, Ethernet cable etc. - 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
