rfc1622.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   In this case, a value of 101 in the Options Present field indicates
   that the PDN Address and Fragmentation options are present in the
   Options Part, and that the foo option is not present.

   Note that an Options Present value of 0 indicates that there are no
   options present, regardless of the value of the Options Contents
   field.  Note also that no more than 8 options, not including the
   default first option (the Options Descriptor), can be present in any
   Options Part.

   The Options Contents/Options Present method of processing options
   allows for efficient processing of options.  First, a router can
   ignore any options that may be present but that do not impact it (for
   instance, a router not attached to a PDN need not consider the PDN
   Address option).  Second, the desired option can be very quickly
   retrieved, because the first option, the Options Descriptor option,
   contains the offset of each of the up to eight options indicated by
   the Options Present field.

   2.1.5  Packet SubID

   This field is used by Pip hosts to correctly associate received PCMP
   messages with local control blocks.  This is necessary because the
   semantics of the Transit Part can change while a packet is in
   transit.  Therefore, a router sending a PCMP message cannot
   necessarily provide all of the information needed by the Pip host to
   correctly identify the context of the received message (that is,
   which "packet flow" it is identified with).

   A PCMP message uses the Protocol, Source ID, Dest ID, and Packet
   SubID to define the PCMP messages context.  It is not sufficient to
   use just Protocol, Source ID, and Dest ID, because two hosts running
   the same protocol between them may have multiple "flows", for



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


   instance, a data flow, a video flow, and an audio flow in the case of
   multi-media.  Each flow may have a different Transit Part, and take
   different paths.  Therefore, the Packet SubID field is needed to
   further differentiate.

   2.1.6  Protocol

   Indicates the protocol header found in the payload.  The values for
   this field are the same as those used for IPv4.

   2.1.7  Dest ID

   The Dest ID field indicates the Pip ID of the final recipient of the
   Pip packet.  This field is examined by both hosts and routers.

   When a Pip System processes the Routing Directive (RD), it may
   determine that it needs to examine the Dest ID for further
   processing.  This may happen both when a host or router receives a
   Pip packet destined for itself, or when a router receives a packet
   that should be forwarded based on Dest ID (as indicated by the RD).

   When a Pip system determines at forwarding time that a packet is
   destined for itself, it checks the Dest ID to verify if that packet
   is destined for it.  If the complete Dest ID matches one of its own
   Pip IDs, then the packet is for it, and is passed to the layer
   indicated by the Protocol field (in the Host Part).  (The Pip system
   may of course wish to check a security option before passing a packet
   to an upper layer.)

   If the complete Dest ID field does not match one of its own IDs, then
   an ID/RD Mismatch PCMP message is sent to the source of the packet,
   as indicated by the Source ID and potentially source information in
   the RD.  The purpose of this message is to flush the ID to RD binding
   in the source Pip host.

   2.1.8  Source ID

   This is the Pip ID of the source of the packet.  It is passed to
   upper layers for the purposes of identifying the context for the
   packet.

   2.1.9  Payload Length

   The Payload Length gives the length of the Pip packet payload in
   units of 8 bits.  The Payload Length does not include the length of
   the Pip header.





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


   2.1.10  Host Version

   The Host Version field indicates what "version" of Pip software the
   sending host has implemented.  This is to allow a host to inform a
   router which ancillary protocols/messages the host is able to accept.
   It is envisioned that over time, new host functions will be
   developed.  Different hosts will install these new functions at
   different times.  This field allows routers to know what functions
   the host can and cannot handle.

   2.1.11  Payload Offset

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

   If a Pip system encapsulates a Transit Part in another Transit Part,
   then the Payload Offset is increased by the length of the new Transit
   Part.

   2.1.12  Hop Count

   The Hop Count is decremented by every router that forwards the Pip
   packet.  If a system receives a Pip header with a Hop Count equal to
   0, and is not the recipient of the packet, then the packet is
   discarded and a PCMP Destination Unreachable is routed to the system
   indicated by the Routing Directive.  (In other words, a host can
   legally receive a Transit Part with a Hop Count of 0, and indeed a
   host doesn't look at the Hop Count field upon reception.)






















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


2.2  Transit Part

   The Transit Part is formatted as shown in Figure 2.


                                         length, in bits
                   +===========================+
                   |         Reserved          |     16
                   +---------------------------+
                   |    Transit Part Offset    |     8
                   +---------------------------+
                   |        HD Contents        |     8
                   +===========================+
                   |  Handling Directive (HD)  |     32
    ---------------+===========================+
        ^          |        FTIF Offset        |     8
        |          +---------------------------+
        |          |        RC Contents        |     8
        |          +---------------------------+
        |          |   Routing Context (RC)    |     16
     Routing       +===========================+
                   |         FTIF 1            |     16
     Directive     +---------------------------+
        |          |         FTIF 2            |     16
        |          +---------------------------+
        |                       .
        |                       .
        |                       .
        |          +---------------------------+
        |          |         FTIF N            |     16
        |          +---------------------------+
        v          |         Padding           |     Variable
    ---------------+===========================+

                          Figure 2: Transit Part

   An explanation of each field follows.

   2.2.1  Transit Part Offset

   This field gives the position of the first word of the next Transit
   Part.  The unit of measure of the Transit Part Offset is 32-bit
   words, counting the first word of the current Transit Part as word 0.
   If there is no next Transit Part, then this field is written as all
   0's.






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


   2.2.2  HD Contents

   The HD Contents field indicates how the Handling Directive (HD) field
   should be interpreted.  The HD field is divided into multiple fields,
   each representing a different handling function.  Each individual
   field in the HD is called an HD Unit (HDU).  The Options Contents
   field indirectly indicates which HDUs are in the HD field, and where
   they are.  We say indirectly because the mapping referred to by the
   HD Contents field is stored locally. In other words, without
   additional information (the mapping), it is not possible to examine
   the HD Contents field and know what the HDU locations are.

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

   2.2.3  Handling Directive (HD)

   The HD is a general purpose field used for the purpose of triggering
   special packet handling by a Pip system.  The HD field does not
   influence a Pip router's next hop choice for a Pip packet, nor does
   it influence a Pip host's determination as to whether the Pip packet
   is destined for it.  Examples of special packet handling would be
   "low priority queueing", or "high priority discard", etc.  (Note that
   the Transit Options also influence "handling", in the sense that
   handling is essentially defined here to mean "anything that is not
   routing.  The HD field, though, is intended for the most common types
   of handling--handling that is expected to be in a significant
   percentage of packets.)

   Both hosts and routers use the HD field.  (Hosts may make use of the
   HD field for packet handling for both incoming and outgoing packets.)

   There is a complete distinction between the syntax and the semantics
   of the HD field.  (This can be contrasted with, for instance, IP,
   which couples the semantics and syntax of the TOS bits.  That is, the
   IP specification itself determines, to a first degree, how the TOS
   bits are interpreted.) Each Pip system can modify the semantic
   meaning of the HD, for instance, by increasing or decreasing the
   queueing priority of a packet.  This is called packet tagging.

   From an abstract modeling perspective, the HD is handled as follows:

   1.  Extract the semantic meaning(s) (the handling instructions
       associated with the HDUs) from the HD field.  Transmitting Pip
       hosts determine the semantic meaning by some other means, such as
       the upper layer protocol.  If the receiving system decapsulates



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


       multiple Pip headers, then the HD semantics are extracted from the
       lowest Pip header for which it is not the target (see example on
       tunneling below).

   2.  Handle the Pip packet according to those instructions.  In some
       cases, it is possible that the Pip system does not understand the
       semantics of one or more HDUs of the HD field.  For each HDU whose
       semantics are not understood, however, the pip system at least
       knows whether to 1) pass the HDU on untouched, 2) set it to all
       0s, 3) set it to all 1s, 4) discard the packet silently, or 5)
       discard the packet with a PCMP HDU Not Understood packet.

   3.  Modify the semantic meaning if necessary.  Note also that if the
       Pip packet is replicated for multicast, each packet has its HD
       semantics modified individually.  .LP .in 3 2.2.4 Tunneling .LP
       Consider two Pip systems, X and Y, separated by one or
       intermediate Pip systems.  X wishes to tunnel a Transit Part to Y.
       Y is therefore the target system of the tunnel.  A Transit Part He
       arrives at X.  In order to forward the Transit Part to Y, X
       encapsulates He in another Transit Part, Hy.  Y is the target
       system for Transit Part Hy.  X sets the HD of He to what it would
       have been if Y was directly connected to X (that is, there were no
       intermediate Pip systems between X and Y).  Further, it is
       intended that Y will derive its HD semantics from the HD of
       Transit Part He, not Transit Part Hy.  .sp .KS

        ----0-----o-----o-----o-----o-----0----
            X     I     J     K     L     Y

   Now consider the operation of Pip system L (the previous hop system
   to Y).  When L forwards the packet to Y, it may either decapsulate
   the packet (in the knowledge that Y is the target for Hy), or not
   decapsulate the packet.  Either way, L derives its HD semantics from
   the HD of Transit Part Hy.