Re: [rrg] Summary of Ivip for discussion and selection process

[Robin Whittle <[e-mail]>]

Hi Tony,

Here's a 995 word version.

  - Robin


Ivip Summary  Robin Whittle 2009-12-18

http://www.firstpr.com.au/ip/ivip/Ivip-RRG-1kw.html

The 2100 word http://www.firstpr.com.au/ip/ivip/Ivip-RRG.html has more
explanation and qualifications.

Key ideas

    Ivip (pr. eye-vip, est. 2007-06-15) is a core-edge separation scheme
    for IPv4 and IPv6.  It provides multihoming, portability of address
    space and inbound traffic engineering for end-user networks of all
    sizes and types, including those of corporations, SOHO and mobile
    devices.

    Ivip meets all the constraints imposed by the need for widespread
    voluntary adoption [1].

    Ivip's global fast-push mapping distribution network is structured
    like a cross-linked multicast tree.  This pushes all mapping changes
    to full database query servers (QSDs) within ISPs and end-user
    networks which have ITRs.  Each mapping change is sent to all QSDs
    within a few seconds.

    ITRs gain mapping information from these local QSDs within a few tens
    of milliseconds.  QSDs notify ITRs of changed mapping with similarly
    low latency.  ITRs tunnel all traffic packets to the correct ETR
    without significant delay.

    Ivip's mapping consists of a single ETR address for each range of
    mapped address space.  Ivip ITRs do not need to test reachability to
    ETRs because the mapping is changed in real-time to that of the
    desired ETR.

    End-user networks control the mapping, typically by contracting a
    specialized company to monitor the reachability of their ETRs and
    change the mapping to achieve multihoming and/or TE.  So the
    mechanisms which control ITR tunneling are controlled by the end-user
    networks in real-time and are completely separate from the core-edge
    separation scheme itself.

    ITRs can be implemented in dedicated servers or hardware-based
    routers.  The ITR function can also be integrated into sending hosts.
    ETRs are relatively simple and only communicate with ITRs rarely -
    for Path MTU management with longer packets.

    Ivip-mapped ranges of end-user address space need not be subnets.
    They can be of any length, in units of IPv4 addresses or IPv6 /64s.

    Compared to conventional unscalable BGP techniques, and to the use of
    core-edge separation architectures with non-real-time mapping
    systems, end-user networks will be able to achieve more flexible and
    responsive inbound TE.  If inbound traffic is split into several
    streams, each to addresses in different mapped ranges, then real-time
    mapping changes can be used to steer the streams between multiple
    ETRs at multiple ISPs.

    Open ITRs in the DFZ (OITRDs, similar to LISP's PTRs) tunnel packets
    sent by hosts in networks which lack ITRs.  So multihoming,
    portability and TE benefits apply to all traffic.

    ITRs request mapping either directly from a local QSD or via one or
    more layers of caching query servers (QSCs) which in turn request it
    from a local QSD.  QSCs are optional but generally desirable since
    they reduce the query load on QSDs.

    ETRs may be in ISP or end-user networks.  IP-in-IP encapsulation is
    used, so there is no UDP or any other header.  PMTUD (Path MTU
    Discovery) management with minimal complexity and overhead will
    handle the problems caused by encapsulation, and adapt smoothly to
    jumboframe paths becoming available in the DFZ.  The outer header's
    source address is that of the sending host - which enables existing
    ISP BR filtering of source addresses to be extended to encapsulated
    traffic packets by the simple mechanism of the ETR dropping packets
    whose inner and outer source address do not match.


  Extensions

    TTR Mobility

       The TTR approach to mobility [2] is applicable to all core-edge
       separation techniques and provides scalable IPv4 and IPv6 mobility
       in which the MN keeps its own mapped IP address(es) no matter how
       or where it is physically connected, including behind one or more
       layers of NAT.

       Path-lengths are typically optimal or close to optimal and the MN
       communicates normally with all other non-mobile hosts (no stack or
       app changes), and of course other MNs.  Mapping changes are only
       needed when the MN uses a new TTR, which would typically be if the
       MN moved more than 1000km.  Mapping changes are not required when
       the MN changes its physical address(es).

    Modified Header Forwarding

       Separate schemes for IPv4 and IPv6 enable tunneling from ITR to
       ETR without encapsulation.  This will remove the encapsulation
       overhead and PMTUD problems.  Both approaches involve modifying
       all routers between the ITR and ETR to accept a modified form of
       the IP header.  These schemes require new FIB/RIB functionality in
       DFZ and some other routers but do not alter the BGP functions of
       DFZ routers.

Gains

  Amenable to widespread voluntary adoption due to no need for host
  changes, complete support for packets sent from non-upgraded networks
  and no significant degradation in performance.

  Modular separation of the control of ITR tunneling behavior from the
  ITRs and the core-edge separation scheme itself: end-user networks
  control mapping in any way they like, in real-time.

  A small fee per mapping change deters frivolous changes and helps pay
  for pushing the mapping data to all QSDs.  End-user networks who make
  frequent mapping changes for inbound TE, should find these fees
  attractive considering how it improves their ability to utilize the
  bandwidth of multiple ISP links.

  End-user networks will typically pay the cost of OITRD forwarding to
  their networks.  This provides a business model for OITRD deployment
  and avoids unfair distribution of costs.

  Existing source address filtering arrangements at BRs of ISPs and
  end-user networks are prohibitively expensive to implement directly in
  ETRs, but with the outer header's source address being the same as the
  sending host's address, Ivip ETRs inexpensively enforce BR filtering on
  decapsulated packets.

Costs

  QSDs receive all mapping changes and store a complete copy of the
  mapping database.  However, a worst case scenario is 10 billion IPv6
  mappings, each of 32 bytes, which fits on a consumer hard drive today
  and should fit in server DRAM by the time such adoption is reached.

  The maximum number of non-mobile networks requiring multihoming etc. is
  likely to be ~10M, so most of the 10B mappings would be for mobile
  devices.  However, TTR mobility does not involve frequent mapping
  changes since most MNs only rarely move more than 1000km.

Documents

      http://www.firstpr.com.au/ip/ivip/Ivip-summary.pdf
      http://tools.ietf.org/html/draft-whittle-ivip-db-fast-push-01
      http://www.firstpr.com.au/ip/ivip/pmtud-frag/
      http://tools.ietf.org/html/draft-whittle-ivip4-etr-addr-forw-01
      http://www.firstpr.com.au/ip/ivip/ivip6/

 [1]  http://www.firstpr.com.au/ip/ivip/RRG-2009/constraints/

 [2]  http://www.firstpr.com.au/ip/ivip/TTR-Mobility.pdf