[Mip4] LISP or Ivip for IPv4/6 mobility support
Robin Whittle <rw@firstpr.com.au> Sun, 15 July 2007 15:16 UTC
Return-path: <mip4-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IA5pa-0002Np-Ll; Sun, 15 Jul 2007 11:16:18 -0400
Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1IA5pZ-0002Ni-DU for mip4-confirm+ok@megatron.ietf.org; Sun, 15 Jul 2007 11:16:17 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IA5pZ-0002NZ-2F for mip4@ietf.org; Sun, 15 Jul 2007 11:16:17 -0400
Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IA5pT-0005LO-LP for mip4@ietf.org; Sun, 15 Jul 2007 11:16:16 -0400
Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id 1D12159DA1; Mon, 16 Jul 2007 01:16:10 +1000 (EST)
Message-ID: <469A3A2C.5050406@firstpr.com.au>
Date: Mon, 16 Jul 2007 01:15:56 +1000
From: Robin Whittle <rw@firstpr.com.au>
Organization: First Principles
User-Agent: Thunderbird 2.0.0.4 (Windows/20070604)
MIME-Version: 1.0
To: mip4@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433
Subject: [Mip4] LISP or Ivip for IPv4/6 mobility support
X-BeenThere: mip4@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mobility for IPv4 <mip4.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mip4>, <mailto:mip4-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:mip4@ietf.org>
List-Help: <mailto:mip4-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mip4>, <mailto:mip4-request@ietf.org?subject=subscribe>
Errors-To: mip4-bounces@ietf.org
I am not directly involved with Mobile IP, but am working on a new routing and addressing architecture for the Internet, as are other people on the RAM list: http://www1.ietf.org/mailman/listinfo/ram in response to the IAB RAWS report: http://www.iab.org/about/workshops/routingandaddressing/ http://tools.ietf.org/html/draft-iab-raws-report A proposal called LISP (Locator/ID Separation Protocol): http://tools.ietf.org/html/draft-farinacci-lisp http://tools.ietf.org/html/draft-lear-lisp-nerd http://tools.ietf.org/html/draft-meyer-lisp-cons involves a global system of Ingress Tunnel Routers (ITRs) which intercept packets addressed to certain prefixes and tunnel them to one of many Egress Tunnel Routers (ETRs). The mapping between the original address (EID) and the tunnel endpoint (RLOC) is controlled, in one way or another, by a centralised or distributed database - in principle down to single IP address granularity for IPv4, and maybe /64 for IPv6. I have my own proposal - Ivip (Internet Vastly Improved Plumbing) which is based on some of LISP's principles. http://www.firstpr.com.au/ip/ivip/ An I-D draft-whittle-ivip-arch-00 is available there and should appear in the IETF system soon. I think Ivip is more incrementally deployable than LISP, because Ivip ITRs can be outside provider and AS-end-user networks, using anycast to attract packets which are addressed to Ivip-mapped addresses, without there needing to be an ITR in every such network (as with LISP) in order for hosts in those networks to be able to send packets to hosts with LISP/Ivip-mapped addresses. The current state of discussions on the RAM list indicates that the most likely solution to the problems with routing and addressing will be something like LISP or Ivip. Once such a system of ITRs exists, if it could be controlled rapidly (which it needs to be to fulfil its primary mission of supporting multihomed end-user networks without involving traditional PI address space or BGP), then this is a mighty powerful tool for directing packets sent by Correpsondent Hosts (CHs) towards what I call "Translating Tunnel Routers" (TTRs). Consider thousands of TTRs all around the Net, inside and outside provider and AS-end-user networks. Mobile Nodes (MNs - which have their own care-of-address in each network they connect to) find a topologically nearby TTR and create a two-way tunnel to it. If the MN has two network connections (eg. UMTS and WiFi), it can find two different TTRs, probably in each network, but also perhaps nearby but not associated with these networks. Then it can build two tunnels to these two TTRs. Now consider each TTR to be somewhat like a home-agent with a 2-way tunnel from the MN. However, the MN can (probably with help from a centralised monitoring system) change the LISP/Ivip mapping database to make all the ITRs tunnel packets to one TTR or another. The TTR decapsulates the packets from the tunnel it entered at any one of these ITRs around the Net. It then tunnels the packet to the MN. Packets from the MN are sent out one link or the other, where the TTR at the end of that 2-way tunnel forwards them to the rest of the Net. The MN has its own LISP/Ivip-mapped IP address - completely unrelated to the addresses of these ITRs or TTRs. This means it can make multiple connections via various networks as it moves around the world, directing the LISP/Ivip system to beam packets to whichever TTR is best at the time. The MN can maintain sessions on its Ivip-mapped IP address. ................ ............ . N1 . . N2 . . . . . . CN1----ITR1~~~~~BR~~~TR~~~BR~~~~~TTR1===PE==\ . . \ . . = ................ | ............ = | = | = | MN1 ......... | ........... = . N4 . / . N3 . = . ./ . . = . TTR2==BR======BR==========PE==/ . . . . ......... ........... ~~~~ 1-way Ivip tunnel ==== 2-way tunnel established by Mobile Node to TTR Figure 10: Mobile IP with two TTRs. >From TTRs and Mobility: http://www.firstpr.com.au/ip/ivip/draft-whittle-ivip-arch-00.html#anchor81 The paths taken by the packets are generally highly optimal, since they flow from the CH to a nearby ITR (which is probably in the shortest path anyway) and then to the TTR which is close to the MN. Packets in the reverse direction come out of the MN and go via ordinary BGP routing to the CH - unless the CH has a LISP/Ivip-mapped address, in which case they go via an ITR near the TTR (or integrated into the TTR) and then an ETR near the CH. All this should work fine for unmodified CHs. The MH needs special software, of course. This should work for both IPv4 and IPv6. - Robin -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/
- [Mip4] LISP or Ivip for IPv4/6 mobility support Robin Whittle