[Mip6] LISP or Ivip for IPv4/6 mobility support

[Robin Whittle <[e-mail]>]

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 Correspondent Nodes
(CNs) 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

Not shown is that multiple CNs all over the Net have their packets
tunneled, by generally different ITRs near to each CN, to the same
TTR for a given MN.

The paths taken by the packets are generally highly optimal, since
they flow from the CN 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 CNs.  The MH needs
special software, of course.

This should work for both IPv4 and IPv6.

 - Robin



_______________________________________________
Mip6 mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mip6