SIPP: SIP and Pip Merger

[[e-mail], [e-mail], [e-mail]]

Folks,
 
As you may have heard, since the last IETF meeting there have been
ongoing discussion about how the SIP and Pip groups could merge the
efforts of the two groups.  We believe we found a way to combine the
protocols which keeps the simplicity of SIP and the flexibility of Pip.
 
Attached is the announcement of the merger of the SIP and Pip working
groups.  We are very interested in your comments on the approach and
would like your support.
 
Bob, Paul, Steve

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

			SIPP: SIP and Pip Merger
			------------------------

		    Steve Deering, SIP w.g. Co-Chair
		      Paul Francis, Pip w.g. Chair
		      Bob Hinden, SIP w.g. Co-Chair

1) Introduction
---------------

Several of the principals in the SIP and Pip groups have been discussing
a possible merger of the two groups.  We believe we have found an
approach which combines the best features of each protocol.  Specifically
it keeps the simplicity of SIP while allowing the addition of the
advanced features of Pip.  This combination results in a protocol which
is better than its two ancestors.  The new protocol is named "SIP Plus"
and abbreviated as SIPP.


2) SIPP as the "IPng"
---------------------

The goals which led us to begin to discuss a merger of the two groups
are:

   1.  Keep the simplicity and transition features of SIP, providing the
       most natural enhancement to IPv4 to fix its immediate limitations.
 
   2.  Provide a platform that incorporates and utilizes the advanced
       features of Pip, while making them easier to use and understand.
 
   3.  Provide a platform for addition of further enhancements to the
       Internet's common protocol layer, as solutions are developed.
 
We believe these goals have been met.  This merger has the added benefit
of combining resources from the Pip and SIP efforts and should facilitate
the IETF IPng decision process.

The features of SIPP include (in alphabetical order):

      Address Renumbering
      Auto Configuration (aka "Plug and Play")
      Extensible Addresses
      Fast and Efficient Forwarding   
      Fixed Length Address Units (64-bits)
      Flexible Transition Scheme
      Flow Identification
      IPv4 Inter-operation
      Mobility
      Multicast Support
      Provider Selection
      Small Header (24 bytes)

The resulting protocol provides solutions to today's routing and
addressing problems, is backward compatible with IPv4, and provides new
capabilities.  It is our opinion that this combination, with its rich
feature set, meets all of the IETF's requirements for IPng.

We believe SIPP has the enhancements which will attract users and vendors
to adopt and deploy it.  This incentive will be a key factor to the
Internet successfully transitioning to an IPng.


3) SIP and Pip Merger Approach
------------------------------

Most of Pip's advanced features are derived from two mechanisms.  These
are its use of:

   End System Identifiers (EIDs), and 
   Loose-Source Routing Mechanism for Routing and Addressing

Much of the same functionality can be derived from SIP's addresses
combined with SIP's loose source route function.  In fact, SIP is able to
achieve Pip functionality (for instance, extended addressing and provider
selection) with no change to the SIP header syntax, and only a minor
change to the SIP forwarding rules.

The basic approach of the merger is to use SIP as-is when "advanced
features" are not needed.  Thus, SIP maintains its simplicity and
"IP-ness" most of the time.  When advanced features such as provider
selection or auto-configuration are required, or if the SIP address needs
to be extended beyond 64-bits, the SIP source-route feature is then used.

This approach of simple-when-possible is especially good for the initial
stages of transition.

The major new technical characteristics of SIPP are as follows:

  1.  End System identification is achieved using only the 64-bit
      source and destination "addresses" in the fixed part of the
      SIPP header.  These addresses are called "Identifying Addresses".
      Even when the SIPP "address" is extended beyond 64-bits using
      the source route mechanism, only the 64-bit Identifying Address
      is used for identification.  Thus, SIPP addresses have some of the
      characteristics of a topology-independent EID.  However, the SIPP
      Identifying Address can also carry traditional topology-related
      (i.e., routing) information, and is used in the traditional way
      when separate identification is not needed.

  2.  Hosts know how to reverse a received source route in order to
      return a packet to the originator.  The ability to reverse a
      source route is a mandatory feature of hosts.

  3.  DNS is able to store source route fragments and return them to
      hosts.  Thus, if it becomes necessary to extend the SIPP address
      beyond 64-bits in the future, it will not be necessary to change
      host software to support this capability.

It is important to note that our approach is to make SIPP host
implementations from the start support the handling and reversal of
source routes.  This is the key for allowing them to work with hosts
which implement the new features such as provider selection or extended
addresses.


4) SIPP Example
---------------

An example of the use of SIPP Identifying Address and source route is as
follows:

    Assume that two hosts H and J in domains D and E wish to exchange
    packets.  Both hosts are connected to two providers, P and Q, and
    that the addresses are provider-rooted.  Host H initiates the
    exchange and chooses to communicate to Host J in Domain E using
    provider P.

Thus Host H would create a packet of the form:

    Source Address       Dest Address        Source Route
    --------------       ------------        ------------
       P.D.H               P.E.J                NULL


Where P.D.H is the 64-bit address of Host H derived from provider P, and
P.E.J is the 64-bit address of Host J derived from provider P.  Return
packets from J to P would have the form:

    Source Address       Dest Address        Source Route
    --------------       ------------        ------------
       P.E.J                P.D.H               NULL


Assume that, after some packets of this sort have been exchanged, the
link between Host H and provider P goes down.  In order to direct packets
through provider Q, Host H would send a packet of the form:

    Source Address       Dest Address        Source Route
    --------------       ------------        ------------
       P.D.H               Q.E.0              Q.D.0, -> P.E.J

where the "->" symbol indicates which element of the source route to
process next.  The packet is routed to provider Q and domain E because of
the address Q.E.0 in the Dest Address field.  A router in domain E
advances the source route to:

    Source Address       Dest Address        Source Route
    --------------       ------------        ------------
       P.D.H               P.E.J             Q.D.0, Q.E.0 ->

Host J receives this packet, and sees from the source and destination
addresses that the packet is from Host H (P.D.H) and for itself (P.E.J).
Thus, once the provider choice has been changed over to Q, the original
addresses are used as identifiers only, and the source route is added to
route the packet appropriately.  When Host J "reverses" the source route,
it produces:

    Source Address       Dest Address        Source Route
    --------------       ------------        ------------
       P.E.J               Q.D.0             Q.E.0, -> P.D.H

and the packet is routed back to Host H.

This example is representative of the way SIPP uses source route to
achieve provider selection, mobility, and multicast.  In general, this
mechanism achieves most of Pip's flexibility as documented in the Pip
Internet Drafts.


5) Next Steps
-------------

The next steps in the merger are to revise the current SIP and Pip
documents to describe SIPP.  We are currently writing the following
documents:

    SIPP Protocol Specification
    SIPP Addressing and Routing Plan
    SIPP Transition Specification (formerly called IPAE)

We expect to publish Internet-Drafts of these documents by the end of
September.  Other relevant documents, based on the SIP and Pip
Internet-Drafts will follow.

We also expect to have a SIPP routing and addressing overview completed
next week.