rfc1622.txt

RFC 的详细文档！

Network Working Group                                         P. Francis
Request for Comments: 1622                                           NTT
Category: Informational                                         May 1994


                         Pip Header Processing

Status of this Memo

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

Preamble

   During 1992 and 1993, the Pip internet protocol, developed at
   Bellcore, was one of the candidate replacments for IP.  In mid 1993,
   Pip was merged with another candidate, the Simple Internet Protocol
   (SIP), creating SIPP (SIP Plus).  While the major aspects of Pip--
   particularly its distinction of identifier from address, and its use
   of the source route mechanism to achieve rich routing capabilities--
   were preserved, many of the ideas in Pip were not.  The purpose of
   this RFC and the companion RFC "Pip Near-term Architecture" are to
   record the ideas (good and bad) of Pip.

   The remainder of this document is taken verbatem from the Pip draft
   memo of the same title that existed when the Pip project ended.  As
   such, any text that indicates that Pip is an intended replacement for
   IP should be ignored.

Abstract

   Pip is an internet protocol intended as the replacement for IP
   version 4.  Pip is a general purpose internet protocol, designed to
   handle all forseeable internet protocol requirements.  This
   specification defines the Pip header processing for Routers and
   Hosts.

Acknowledgements

   I want to individually acknowledge Rob Coltun, Steve Deering, Ramesh
   Govindan, Joel Halpern, John Ioannidis, Chris Petrilli, Bob Smart,
   and Zheng Wang.  I want also to acknowledge the many people from the
   Pip working group who have participated in developing Pip.  Finally,
   I want to acknowledge the SIP protocol (or, more accurately, the
   people behind the SIP protocol) for providing certain good ideas.





Francis                                                         [Page 1]

RFC 1622                 Pip Header Processing                  May 1994


Conventions

   All functions in this specification are mandatory.

1.  Introduction

   Pip is an internet protocol intended as the replacement for IP
   version 4.  Pip is a general purpose internet protocol, designed to
   handle all forseeable internet protocol requirements.  This
   specification defines the Pip header processing for Routers and
   Hosts.

   The design of Pip is fundamentally different from that of previous
   internetwork protocols.  Pip is designed to be as general as
   possible, but without significantly compromising performance.
   Because of Pip's generality, it can handle forseeable routing and
   addressing requirements.  It is hoped that it will be able to handle
   most if not all future routing and addressing requirements.

   There are many detailed aspects of Pip that provide this generality
   that are not discussed here.  It is useful, however, to mention one
   general aspect.  That is, Pip strives to remove as much "functional
   semantics" from the base specification as possible.  Pip defines a
   packet header and forwarding rules that can include many different
   functional semantics (that is, routing, addressing, and flow
   paradigms).  Therefore, the reader may often find him or herself
   asking "But how do you do foo with Pip?" The answer to this sort of
   question belongs in companion documents to the basic Pip spec.

   Pip can be thought of as a mechanism for triggering actions in hosts
   and routers, just as a machine language can be thought of as a
   mechanism for triggering actions in CPUs.  The machine language has
   no functional semantics outside of the specific actions it triggers
   (move this register, write that memory location, etc.).  But, the
   machine language is a very powerful tool upon which functional
   semantics are built.  Likewise, Pip is a powerful tool upon which
   routing, addressing, and flow functions can be built.














Francis                                                         [Page 2]

RFC 1622                 Pip Header Processing                  May 1994


2.  Pip Specification

   The Pip header is partitioned into three parts, the Initial Part, the
   Transit Part, and the Options Part.


           +===========================+
           |       Initial Part        |
           +===========================+
           |       Transit Part        |
           +===========================+
           |       Options Part        |
           +===========================+
           |                           |
           |         Payload           |
           |                           |


   Each part falls on a 32-bit boundary (as indicated by the double
   lines shown), and the Transit Part falls on a 64 bit boundary.

   The concept of tunneling in an integral part of Pip.  Pip achieves
   tunneling by encapsulating the Transit Part of the Pip header in
   another Transit Part.  Therefore, when tunneling, there is one
   Transit Part for each (nested) tunnel:


           +===========================+
           |       Initial Part        |
           +===========================+
           |       Transit Part        |
           +===========================+
           |       Transit Part        |
           +===========================+
                       .
                       .
                       .
           +===========================+
           |       Transit Part        |
           +===========================+
           |       Options Part        |
           +===========================+


   Because each Transit Part has only what is necessary for router
   forwarding and handling, this method of tunneling is reasonably
   efficient in terms of packet size.




Francis                                                         [Page 3]

RFC 1622                 Pip Header Processing                  May 1994


2.1  Initial Part

   The Initial Part is formatted as shown in Figure 1.

                                         length, in bits
           +===========================+
           |    Version Number = 8     |     4
           +---------------------------+
           |       Sub-Version         |     4
           +---------------------------+
           |      Options Offset       |     8
           +---------------------------+
           |     Options Contents      |     8
           +---------------------------+
           |     Options Present       |     8
           +===========================+
           |       Packet SubID        |     16
           +---------------------------+
           |         Protocol          |     16
           +===========================+
           |         Dest ID           |     64
           +===========================+
           |        Source ID          |     64
           +===========================+
           |      Payload Length       |     32
           +===========================+
           |       Host Version        |     8
           +---------------------------+
           |      Payload Offset       |     8
           +---------------------------+
           |        Hop Count          |     16
           +===========================+

                          Figure 1:  Initial Part

   An explanation of each field follows.

   2.1.1  Version Numbers

   The first octet is divided into two 4-bit fields, the Version and the
   Sub-Version.  The Version field is set to be 8, and is meant to be
   version 8 of IP.  (As of this writing, this is an experimental number
   assigned for development of Pip.) Thus, all encapsulation schemes
   defined for IP can work for Pip as well.

   As long as the Version field is 8, the Initial Part and Options Part
   of the Pip Header is as specified in this standard.  (In other words,
   the Sub-Version field refers only to the Transit Part.)



Francis                                                         [Page 4]

RFC 1622                 Pip Header Processing                  May 1994


   By doing this, we allow the Transit Part of the Pip Header to change
   completely without necessarily requiring a host to understand the new
   Transit Part.  If a host receives a Pip header with a Version number
   of 8 and an unknown Sub-version number, the host does not try to
   parse the Transit Part at all, rather it processes only the Initial
   Part and the Options Part.  (By using the Pip Header Protocol to
   format Pip Headers, a host can be made to formulate the right Transit
   Part, even though the host doesn't understand the semantics of the
   Transit Part.  This allows radical migration of the Transit Part
   while potentially not requiring changes to hosts.)

   If a host or a router receives a packet with an unknown Version
   number, the packet is silently discarded.

   The Sub-Version field is set to the value 0 for the version of Pip
   defined in this specification.  As long as the Sub-Version number is
   0, the Transit Part is as specified in this standard.  Any packet
   received by a router with a Version number of 8 and an unknown Sub-
   Version number is silently discarded.

   2.1.2  Options Offset

   The Options Offset indicates the position of the Options Part.  The
   unit of measure of the Options Offset is 32-bit words, counting the
   first word of the Pip Header as word 0.

   2.1.3  Options Contents

   This field indicates how the Options Present field should be
   interpreted.  Each bit of the Options field indicates if each of up
   to eight options is present in the Options Part.  The Options
   Contents field indirectly indicates which option each bit of the
   Options Present field refers to.  We say indirectly because the
   mapping referred to by the Options Contents field is stored locally.
   In other words, without additional information (the mapping), it is
   not possible to examine the Options Contents field and know what
   option each bit of the Options Present field refers to.

   Any of 256 possible Options Contents values can be active at a given
   time.  (Note that the means by which the meaning of the Options
   Contents values are assigned and conveyed to routers and hosts is
   outside the scope of this specification.)









Francis                                                         [Page 5]

RFC 1622                 Pip Header Processing                  May 1994


   2.1.4  Options Present

   This field indicates which of the Options indicated by the Options
   Contents field are actually present in the Options Part.  Each bit of
   this field refers to a single option type.  The mapping of each bit
   to its' option type is determined by the Options Contents field.

   For instance, assume that the Options Contents field indicates that
   bit 0 of the Options Present field refers to the PDN Address option,
   that bit 1 of the Options Present field refers to the foo option, and
   that bit 2 of the Options Present field refers to the Fragmentation
   option.  (As of this writing, there is only one option.  Until there
   are more than eight options, there is no need to define more than one
   Options Contents values.)