Ivip - a scalable routing and addressing architecture for the Internet

Robin Whittle rw@firstpr.com.au 2010-02-06

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 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.

The RRG is finalizing its choice of a scalable routing solution to recommend to the IETF right now.  The final deadline is early March 2010, so please get involved in discussions if you are keen to contribute to this important debate.

The latest version of the developing RRG Report is:
My unofficial list the 14 (now 15 - see RANGER below) proposals is: msg05548.html   My attempt to group them is here msg05562.html - but this is based on first impressions and could well be wrong.  The current version of the RRG report is here: http://tools.ietf.org/html/draft-irtf-rrg-recommendation ,  V03 of this includes the summary of each proposal and links to all the references for each.  Later, this will include the second stage - the 500 word "critiques" (This second stage was initially known as the analysis: msg05664.html .)  Critiques of each proposal are written by one or ideally more people other than the proponents.  The third state will be a 500 word "rebuttal" of the critique, written by by the proponents.  The fourth stage will be a 500 word "reflection" - also by people other than the proponents.  After that, I guess we will debate the choice of which proposal to recommend. 

On 2010-01-15 (msg05665.html) Fred Templin's RANGER proposal was added - a fourth core-edge separation architecture.)

My understanding of this phase of the RRG work is msg05571.html and Tony Li's reply to this is  msg05573.html .  At the time of writing, the most recent word on deadlines for writing critiques of the proposals is from Lixia Zhang is (2010-01-14): msg05648.html .  "I'd like to second your vote for Monday 1/18 as I myself need that few extra days as well."   So I understand that Monday 18th January is the deadline - but please check the RRG list for latest developments. 

I have written critiques of LISP and TIDR.  I am working on critiques of Name Based Sockets and RANGER.  See here for a longer discussion of RANGER and SEAL.  I would really appreciate people reading Ivip-arch and contributing to the critique of Ivip. 
Lixia Zhang has written a critique: msg05697.html but it may not be to late to add to it.

Here is a link to my pep-talk on why now - these few days - is the time to publicly state any concerns you have about Ivip:  msg05646.html   At least two kinds of concern also apply to other proposals.  If you object to any kind of core-edge separation scheme, then your concerns apply to LISP, Ivip, TIDR, RANGER and APT (which is no longer being developed).  If you object to pushing all mapping to local full-database query servers, then your concerns apply to Ivip and APT.

Two pages which I think are important to the RRG debate are on constraints due to the need for widespread voluntary adoption, and objections to Core-Edge Elimination architectures which making hosts do more routing and addressing work than at present:


Latest Internet Drafts and other important documents

Please read this RRG message regarding a forthcoming redesign of the fast-push real-time mapping distribution system to be more decentralised than is depicted in the current IDs:


Ivip's new distributed mapping distribution system  2010-02-06
http://www.ietf.org/mail-archive/web/rrg/current/msg05975.html


Ivip-Architecture  

http://tools.ietf.org/html/draft-whittle-ivip-arch-03  (25k words)

Fresh rewrite, 2010-01-13.  This is the way to fully understand the whole Ivip proposal.

Note: I have designing a significant simplification of the Launch server system and how the RUASes will drive it.  See Ivip-FPR below.

Comments on Ivip-arch-03 by Mohamad Boucadair

On 2010-01-14, Mohamed Boucadair, of orange.com wrote some thoughtful comments:  fb/Ivip-arch-03-Med-Boucadair.pdf .  I really appreciate this and will respond to them on the RRG list ASAP.  After doing this, I will update ivip-arch accordingly to 04.



Ivip Fast Push Mapping Distribution 

The main part of the real-time mapping distribution system is described in a separate ID:

Ivip Fast Payload Replication
http://tools.ietf.org/html/draft-whittle-ivip-fpr-00

This replaces the previous "Launch" servers with ordinary Replicators, which will be simpler, faster and more robust.  I have also added a distributed system of "Missing Payload Servers" by which QSDs will be able to quickly obtain any payloads which did not arrive in the streams from the QSD's two or more upstream Replicators.  I also discuss hardening the system against DoS attacks by connecting level 0 and level 1 Replicators via private networks.

The overall fast-push mapping distribution system is described in:

http://tools.ietf.org/html/draft-whittle-ivip-db-fast-push-03



Instead of encapsulation, Modified Header Forwarding for IPv4 

http://tools.ietf.org/html/draft-whittle-ivip-etr-addr-forw-00

Revised 2010-01-13.  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.


Glossary of Ivip and scalable routing terms 

http://tools.ietf.org/html/draft-whittle-ivip-glossary-00

New 2010-01-13 - intended to help people come up to speed in this field.

Conceptual Summary and Analysis of Ivip, updated 2010-01-12

Ivip-summary.pdf  (10k words)

A concise introduction to Ivip.  It is written primarily for people who are already up to speed with RRG list discussions.  Quite a lot of overlap with Ivip-arch, but is a separate document with a different structure.  Best to read Ivip-arch if you have time, and then read Ivip-summary if you want another angle on it.


Shorter summaries

Ivip-RRG.html          (2.1k words)
Ivip-RRG-1kw.html  (1k words)

For the late 2009, early 2010 RRG proposal discussion and selection process:

TTR Mobility

TTR-Mobility.pdf

By Steve Russert and myself, August 2008, with minor revisions in January 2010.
More on this below: #mobile



Recent developments

2010-01-13
New Ivip-arch ID and Glossary, updated the other two IDs.  Revised this page.


2009-12-18
I wrote 2100 and 995 word summaries of Ivip for the RRG final proposal selection process:  Ivip-RRG.html and Ivip-RRG-1kw.html .

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/ . 

In recent weeks I discussed on the LISP 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 OITRD, the old name for DITRs - Default ITRs in the DFZ):


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:


the RRG list discussion of this, and Fred Templin's SEAL ID.

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 .


.