Ivip - a new routing and
addressing architecture for the Internet
Robin Whittle rw@firstpr.com.au 2008-06-11
To the main IP
page
Introduction
I
am developing a new proposal to help solve the crisis in routing and
addressing, to provide a new form of mobility for both IPv4 and IPv6,
and to help improve IPv4 address utilization - and thereby combat
the IPv4 address depletion problem.
Ivip
-
Internet Vastly improved Plumbing
(or your choice of several other meanings, such as "Internet Versatile
redIrection of Packets" etc.) - is based on some elements of LISP
(Locator/ID Separation Protocol), for which there are links at the
RRG's wiki page
wiki
page .
For people who are new to the RRG 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 and (ITR1) Ivip's "anycast ITRs in the core/DFZ", which are
now known as OITRDs (Open ITRs in the DFZ). Please search the RRG
list 2008 archives for "Newbies" for other messages which may help to
familiarize you with this discussion.
Please see the ../sram-ip-forwarding/
page for more information on this routing and addressing crisis and for
links to mailing lists
(previously the RAM and IDR lists, now mainly the RRG list) and
to other
resources.
Recent developments
2008-06-11
In the last few days there has been a big debate on the
RRG list about
how rapidly IPv6 will be adopted, which is a vital question when the
RRG is deciding whether to recommend a solution for IPv4 and IPv6, or
just for IPv6.
There is a similar debate in the
ARIN
PPML list under the threads: "IPv6 in the Economist". This
includes some interesting critiques of the IPv6 DNS arrangements by Leo
Bicknell and Dean Anderson. Also, the thread: "Portable address
space vs. IPv6 auto-numbering". That thread starts
here
and someone who liked my initial message suggested I "blog or wiki it".
There was an article about IPv6, dated June 5th 2008 in
The Economist Technology Quarterly by an unidentified author (Monitor):
Your
number's up . Mine is the fourth comment from the bottom
here:
Summary
and Analysis
8 Page Conceptual
Summary and Analysis of Ivip 2008-04-23 This is the most concise introduction to Ivip.
It is
written primarily for people who are already up to speed with RRG list
discussions.
As
of 2008-03-21, "OITRD" is the new name for the ITRs previously known as
"anycast ITRs in the core/DFZ":
psg.com/lists/rrg/2008/msg00937.html
.
A discussion in early March 2008 of the initial version of
Ivip-summary.pdf, and of
various other aspects of Ivip, is in these messages:
msg00648.html
,
msg00657.html
and
msg00682.html
.
Changelog:
2008-04-23:
I updated from this original version: Ivip-summary-2008-02-19.pdf (in
this directory) to fine tune it and account for recent developments:
The new term OITRD.
The new approach to
PMTUD.
Comparison with other proposals
Comparing LISP-NERD/ALT, APT, Ivip and TRRP
(All new 2008-04-21)
Internet
Drafts
ivip-arch
In the future I will update the long
ivip-arch
ID to become a shorter,
purely architectural
description to be accompanied by a bunch of new, more specific IDs.
The
Ivip Architecture Internet
Draft
(I-D) version 00 of 2007-07-15 is:
ivip-fast-push
This was completed on 2008-02-19 and
concerns the fast
push database distribution system.
Overall
plan for Internet Drafts
The
complete series of IDs will be
something like:
| ivip-arch-02 | August 2008? | For now, please
refer to Ivip-summary.pdf (above) for an architectural overview, to
ivip-arch-00 and to the documents listed below. |
| ivip-db-fast-push-00 | Done,
see above. | Fast push of mapping data to hundreds of thousands
or
millions of ITRDs and QSCs all over the Net. Not yet updated to
OITRD terminology. In the next update I intend to go into more
detail of the data formats from the RUAS to the Launch system, and then
for the packets fanned out by the Replicator system, |
| ivip-itr-qs | Later,
but much
of this is in arch-00. | ITRs and Query Servers, their internal
functions and how to use them. |
| ivip-etr-filter | Later, but
much of this is in arch-00. | ETR internal functions and how to
use them. Also how outer header source address enables the ETR to
respect filtering. |
| ivip-mobility | There should
be a paper describing this, by August at the latest. | TTR internal functions and
how to use them for the new kind of mobility provided by Ivip.
Please see messages and diagrams in the Mobility section below. |
| ivip-pmtud-frag | Later - but
will be based on the material here: pmtud-frag/ | Ivip
is the only map-encap scheme to integrate mechanisms for handling the
problems of encapsulated packets exceeding path MTU limits - apart from
some recent additions to LISP, which I think are problematic.
(See critique at: lisp-links/.) |
| ivip-deployment | Later. | Why
ISPs and end-users will want what Ivip provides, and how to get the
ball rolling. See the section below on RRG list discussions
for a message regarding the business case for the mapping system and
OITRDs. |
Ivip's approach
to mobility
Ivip's TTR
(Translating Tunnel Router) approach to mobility discussed in
these messages, (some in reverse order, but this may be the best order
to read them in) and in the diagrams below:
(2008-03-14)
Easy explanation, starting from ordinary mobile IP concepts:
Long
discussion, reverse order:
(2008-02-27)
Mobility, billions
of micronets in the future, and maximum imaginable mapping update
rates:
(2008-03-18) Mobility, update rates & charging per
update
(2008-03-20)
This map-encap ITR -> TTR approach to mobility will render existing
approaches obsolete and be a major aspect of any future map-encap
scheme - so we really need to keep exploring mobility as part of the
RRG discussions:
Some
illustrations:


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
IRTF Routing Research Group
Some
older material
Ivip documentation
is pretty detailed - this is about a big topic: the
first major change to the routing and addressing architecture of the
Net since the early 1980s. If you only have a few minutes, there
is
always the script for the
Ivip TV
advertisement:
tv-ad/
.
Here is a
Quick
Introduction
(mid 2007) to the Internet's routing and addressing problems, and to
the most
significant currently proposed solutions: LISP, eFIT-APT and Ivip.
Slides:
LISP-NERD/CONS, eFIT-APT and Ivip - and some
challenges common to them all (Color diagram above added
2007-07-26, pointer to Errata added 2007-07-28.)
Two tables from these slides:
General
features|
| SHIM6 | Mobile IPv6 | LISP- NERD | LISP- CONS or ALT | APT | Ivip |
| Address
portability | | | Y | Y | Y | Y |
| Multihoming | Y | | Y | Y | Y | Y |
| Mobility | | Y | | | | Y |
| IPv4 too | | | Y | Y | Y | Y |
Multihoming and Traffic Engineering
functionality|
| LISP- NERD | LISP- CONS or ALT | APT | Ivip |
| Address ITRs do complex
communications, accept and forward ICMP etc.? | Yes | Yes | Yes + Default
Mappers | No |
| ETRs communicate with ITRs? | Yes | Yes | Yes + Default
Mappers | No |
| Real time decisions for
multihoming service restoration and traffic engineering. | Functionality
fixed in protocols, controlled by mapping data and implemented in
real-time by ITRs etc. | No
built-in MH or load sharing functions. Open ended - relies on
external systems
chosen by end-user, and fast replication of mapping changes to all ITRs. |
Complex
communications, responding to ICMP etc.
= security problems
and heavy load for router's CPU.
Since
BGP's limitations are driving the need for a new architecture, please
also
see also the discussion of BGP's path hunting, the MRAI timer etc. in
the
RRG and
IDR mailing lists, beginning
around 2007-06-20. I have a little guide to this discussion at:
../sram-ip-forwarding/##BGP_hunting_MRAI_disc
.
A list of messages on
the RAM list regarding LISP, between 15 June and 15 July 2007 is
available here:
ram-messages/ .
(These
pages are created with KompoZer www.kompozer.net
, apart from the Internet Drafts, which were created with
xml2rfc xml.resource.org .
The slides were made with Microsoft PowerPoint, the diagrams with Adobe
Illustrator 8 and the summary and analysis PDF with MS Word and an old
version of Adobe Acrobat Distiller.)