Ivip - a scalable routing and addressing architecture for the Internet

Robin Whittle rw@firstpr.com.au 2010-07-08

To the main IP page


Multihoming service restoration with Ivip


Introduction - Ivip and the IRTF Routing Research Group

Ivip - Internet Vastly improved Plumbing - is intended to help solve the Internet's routing scaling problem, for both IPv4 and IPv6.  It will also help improve IPv4 address utilization and be a good basis for the TTR Mobility architecture.

For people who are new to the IRTF Routing Research Group's discussion of the Internet's routing scaling problem, please see this RRG List message msg00623.html and the Ivip-glossary ID mentioned below for a description of some of the terminology and for an explanation of the above diagram, which depicts multi-homing service restoration.   Please see RRG-2009/ for links to the RRG and to other resources regarding scalable routing and addressing.  My attempt (2010-02-23) to describe the routing scaling problem is in the RRG mailing list archives: Scalable routing problem & architectural enhancements : msg06099.html .

Latest RRG developments

According to my understanding of recent (2008-03-08) messages msg06192.html from co-chair Tony Li, the co-chairs will be writing RRG's Recommendation.  They summarized their intended recommendation at the recent RRG meeting (2010-03-26 in Anaheim), and are not planning to test for consensus support for it.  So this will be a recommendation of the co-chairs, not from the group.

My assessment of their proposed Recommendation: msg06353.html .  Consensus is not required in IRTF Research Groups (msg06204).  The slides of Lixia's and Tony's presentation are here:  http://www.ietf.org/proceedings/10mar/slides/RRG-0.pptx and in PDF format: RRG-2010/RRG-2010-03-26.pdf .  The slide 19 material on Ivip is almost entirely inaccurate.  See msg06373 .

An audio archive of the meeting will be at: http://www.ietf.org/audio/ietf77/ , but on 2010-04-01 this was not ready.  Here is a 64kbps MP3 of the 1 hour 13 minute meeting  RRG-2010/RRG-2010-03-26.mp3 , which consisted of the co-chairs' presentation and some questions and comments from the floor.


The latest version of the developing RRG Report is:


I have written critiques of all the proposals except ILNP and my own proposal - Ivip.  Please see the RRG archives .  In June and July, critical discussion of ILNP continues.

On 2010-03-09 I wrote some text of a Recommendation msg06219.html I would like everyone to agree to.  This won't happen, of course, but no-one has yet written why they disagree - and no-one has yet (2010-07-08) written another Recommendation they would like everyone to agree to.  This msg06219 contains a general critique of all Core-Edge Elimination architectures (Locator / Identifier Separation), which includes ILNP.  It also contains a list of goals, including scalable Mobility.



Latest Internet Drafts and other important documents

Ivip-Architecture  

tools.ietf.org/html/draft-whittle-ivip-arch 

The 04 version of 2010-03-08 covers the new DRTM mapping system.


Also, a quick description of Ivip's network elements:

ITR        QSC          QSR        QSA      ETR
DITR      (QSCs are
ITFH       Optional)

network-elements/ .



DRTM - Distributed Real Time Mapping for Ivip and (potentially) LISP

2010-03-26: please see the new description of the major parts of DRTM, with three detailed illustrations:


One of the illustrations is below.  This is the best way to understand the overview of DRTM - best to read it before reading the Internet Draft:

tools.ietf.org/html/draft-whittle-ivip-drtm-01


This is a new mapping system which I devised in Feb-March 2010, which is still real-time, but avoids the need for any server having the entire mapping database, and the need for ISPs and other networks with ITRs to run servers which gets real-time mapping feeds.  All the ITRs and query servers needed by ISPs etc. are fully caching devices. 

Significant adoption of scalable-routing-friendly SPI address space can be achieved with little or no ISP investment or involvement.  The initiative is taken by, and the investments are made by, organizations which need not be ISPs.  This requires only DITRs, QSAs and ETRs.  Compared to the original Ivip mapping distribution system, DRTM will be simpler for ISPs etc. to implement - and will be more robust. 


Glossary of Ivip and scalable routing terms 

tools.ietf.org/html/draft-whittle-ivip-glossary-01

2010-03-06 - intended to help people come up to speed in this field.


Instead of encapsulation, Modified Header Forwarding for IPv4 

tools.ietf.org/html/draft-whittle-ivip-etr-addr-forw-01

Revised 2010-01-13 with a minor update in 2010-07-08.  With a modest upgrade to all DFZ router FIBs, and by taking liberties with the IPv4 header, we can avoid encapsulation, its overhead and its Path MTU Discovery problems.  This is for the long-term future - it is not an essential part of Ivip for initial introduction. 

(The update is that perhaps it would be better to do the same thing, with a new protocol, with the same header length, and so use the Evil bit too, which would enable it to carry 31 bits of ETR address.)

TTR Mobility

TTR-Mobility.pdf

By Steve Russert and myself, August 2008, with minor revisions in January 2010.
More on this below: #mobile  TTR Mobility does not require a mapping change whenever the MN gains a new address or uses a new access network. 


My suggestion for a Recommendation

msg06219.html (2010-03-09) Includes a list of goals, analysis of all the proposals and arguments against Core Edge Elimination (CEE, AKA Locator / Identity Separation) architectures.

This does not cover Fred Templin's IRON architecture, which he is extensively developing in June and July 2010.


"Overloading" of Loc & ID functions is good for hosts and should be maintained

msg07017.html (2010-06-22.)  A critique of all Core Edge Elimination (CEE, AKA Locator / Identity Separation) architectures.  (LISP is not such an architecture - it is a Core-Edge Separation architecture, as is Ivip and Fred Templin's IRON.)

On 2010-07-08, Dae Young Kim supported this viewpoint (msg07074.html), though I understand his ideal arrangement involves the IP address pointing to a node (host) rather than to one of its interfaces, as it does today.


The RRG's capacity to handle detail is not up to the task of designing architectural enhancements for v4/v6 Internets

msg07043.html (2010-06-26) 

Since I wrote this, which includes a lament on the lack of support for, or critiques of, Ivip, TTR Mobility and some other things I wrote, I have received some encouraging support.  I understand that Fred Templin's IRON architecture now uses some elements of TTR Mobility. 

Also, see Dae Young Kim's feedback mentioned above, and Tom Petch's support (msg06823 & msg07049)  for DRTM and my attempt to document the CEE/CES distinction - by stating he would like to see these written up as RFCs.  Unfortunately, I don't have time to do this in the foreseeable future, but perhaps someone will write up the CES/CEE material in an RFC.




Ivip's DRTM Distributed Real-Time Mapping system Fig. 3 of 4




Selected developments not mentioned above

2009-12-18
I also made a page to record the most recent version of my arguments against hosts being expected to take on any more Routing and Addressing responsibilities, other than those really needed for mobile hosts:  RRG-2009/host-responsibilities/ .  See also a later account of this subject: msg07017.html (2010-06-22.)

In early December 2009 I discussed on the LISP WG list the inability of LISP-ALT to scale well - to provide short paths, with large numbers of EIDs, whilst also being structured for robustness against link and router failure.  The initial message is ALT structure, robustness and the long-path problem: www.ietf.org/mail-archive/web/lisp/current/msg01801.html .  This is a continuation of a critique I first made in late 2007, soon after ALT was announced.  Still no-one has proposed how these problems can be solved.  The attraction of ALT is now said, by some people, to be its ease of implementation (or perhaps design), since it is constructed using existing router functionality.  That's fine, but why bother making an ALT test network if ALT can't scale to billions of EIDs or whatever?  If ALT can't do this, LISP's future must be with some other mapping system - which should be developed and prototyped ASAP.  LISP has no other mapping system under development.  NERD was retired on 2009-11-17 (rrg/current/msg05274.html) and there has been CONS development since ALT was launched in late 2007.

2009-07-30
The debate about whether LISP involves separate namespaces for EIDs and RLOCs has fired up again, on the LISP list:  namespace/  Also, I wrote a critique of the LISP Mobile I-D (draft-meyer-lisp-mn-00): http://www.ietf.org/mail-archive/web/lisp/current/msg00749.html.   See the #mobile section below for my suggestion that LISP use the TTR mobility approach rather than the "MN is its own ETR" approach of the recent Mobile LISP Internet draft.


2009-04-19
A new page RRG-2009/constraints/ has a draft list of constraints on any scalable routing solution which result from our reliance on widespread voluntary adoption.  Please comment on this in the RRG list.


2009-03-21
Added a page namespace/ as part of trying to determine the meaning of the noun "namespace".  This is part of a debate on the LISP list about whether or not statements about LISP involving separate namespaces for EIDs and RLOCs are accurate or not.  This is probably more than anyone ever wanted to know about the meaning of the term, but since the debate has involved the suggestion that "namespace" may have "a lot of other definitions floating around" I tried to find them - without success.

2009-03-01
This paper:

Towards a Future Internet Architecture: Arguments for Separating Edges from Transit Core
Dan Jen, Lixia Zhang, Lan Wang, Beichuan Zhang
http://conferences.sigcomm.org/hotnets/2008/papers/18.pdf

the authors argue that "core-edge separation" approaches  is a better way of achieving scalable routing and addressing than  "core-edge elimination" schemes.  Core-edge separation schemes are "Strategy A" in Bill Herrin's taxonomy (below) and in the 3.3 taxonomy of the draft RRG recommendations.  Core-edge separation proposals include LISP, APT, Ivip, TRRP and Six/One Router.


2009-01-03
Added a page rrgarch/ which attempts to match actual scalable routing proposals to the strategies in Bill Herrin's Summary of Routing Architectures: http://bill.herrin.us/network/rrgarchitectures.html



2008-08-12 

Forwarding with modified headers: I have devised two systems for getting packets from ITRs to ETRs without encapsulation or address translation.  Both systems require a modest upgrade to most or all core (DFZ) routers and for some or many internal routers - but would make for a much simpler, more efficient system, with no PMTUD problems and simpler ITRs and ETRs. 

ETR Address Forwarding (EAF) - for IPv4

tools.ietf.org/html/draft-whittle-ivip-etr-addr-forw.  It puts the 30 most significant bits of the ETR address in the header bits for:
More Fragments bit.
Fragment Offset.
Checksum.
and marks the packet as being in this EAF format by setting bit 48, the "Evil Bit" tools.ietf.org/html/rfc3514.

Prefix Label Forwarding (PLF) - for IPv6

I don't yet have an Internet draft for this, but the proposal is described in detail here:  PLF-for-IPv6/  .

The current plan is to use a 19 bit value in the proposed new Forwarding Label to get the packet from the ITR to one of 524,287 provider networks to which the new kind of end-user networks connect.  Each such recipient provider network can have effectively unlimited numbers of ETRs.

There is a another page exploring extending this system to be used by edge networks, with each such network, including the just-mentioned recipient provider networks, able to use 2^19 values of the proposed Forwarding Label to get the packet from its border router to any one of 524,287 ETRs, again without any encapsulation, PMTUD problems etc. PLF-for-IPv6/lfe/

Also, a little research page on which upper layer protocols look at bits in the IPv4 or IPv6 headers, in terms of their checksums - and which fields the IPsec Authentication Header looks at:  checksums/ .

2008-04-21
Comparing LISP-NERD/ALT, APT, Ivip and TRRP (Does not cover Ivip's  Modified Header Forwarding arrangements.)
See also the rrgarch/ page which attempts to match actual proposals to Bill Herrin's summary of strategies.



Ivip's approach to mobility

TTR Mobility Extensions for Core-Edge Separation Solutions to the Internet's Routing Scaling Problem
Robin Whittle, First Principles, Rosanna, Vic, Australia
Steven Russert (previously of) Boeing Phantom Works, Seattle, WA, USA
2008-08-25 http://www.firstpr.com.au/ip/ivip/#mobile  Minor revisions 2010-01-12



Some illustrations (using DITR - Default ITRs in the DFZ - previously known as OITRDs):


TTR mobility extensions for Ivip or other core-edge separation solutions to the Internet's routing scaling problem

 




TTR mobility extensions for Ivip or other core-edge separation solutions to the Internet's routing scaling problem



Path MTU Discovery and fragmentation problems


On 2008-04-21 I devised a new approach to the PMTUD (Path Maximum Transmission Unit Discovery) problems which all map-encap schemes need to deal with.  Please see:


and some 2010 research by Fred Templin and others: msg05910.html .

Notable RRG list discussions

To-do, but see LISP critiques at  lisp-links/ and the Ivip business models message: psg.com/lists/rrg/2008/msg01158.html .


.