SIPP: SIP and Pip Merger
hinden@eng.sun.com, francis@thumper.bellcore.com, deering@parc.xerox.com Fri, 10 September 1993 01:49 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12194; 9 Sep 93 21:49 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12190; 9 Sep 93 21:49 EDT
Received: from Sun.COM by CNRI.Reston.VA.US id aa22468; 9 Sep 93 21:49 EDT
Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA16565; Thu, 9 Sep 93 18:48:47 PDT
Received: from sunroof2.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA05039; Thu, 9 Sep 93 18:51:29 PDT
Received: from bigriver.Eng.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02842; Thu, 9 Sep 93 18:48:41 PDT
Received: by bigriver.Eng.Sun.COM (5.0/SMI-SVR4) id AA09558; Thu, 9 Sep 1993 18:48:33 +0800
Date: Thu, 09 Sep 1993 18:48:33 +0800
Message-Id: <9309100148.AA09558@bigriver.Eng.Sun.COM>
To: pip@thumper.bellcore.com, sip@sunroof.eng.sun.com
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: hinden@eng.sun.com, francis@thumper.bellcore.com, deering@parc.xerox.com
X-Orig-Sender: Bob.Hinden@eng.sun.com
Cc: Bob.Hinden@eng.sun.com, francis@thumper.bellcore.com, deering@parc.xerox.com
Subject: SIPP: SIP and Pip Merger
Content-Length: 8468
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.
- SIPP: SIP and Pip Merger hinden
- Re: SIPP: SIP and Pip Merger bound
- Re: SIPP: SIP and Pip Merger Jon Crowcroft
- Re: SIPP: SIP and Pip Merger Jon Crowcroft
- Re: SIPP: SIP and Pip Merger William Manning
- Re: SIPP: SIP and Pip Merger Paul Francis--formerly Tsuchiya
- Re: SIPP: SIP and Pip Merger bound