rfc1622.txt

RFC 的详细文档！

   If L does not decapsulate the Transit Part, then it is as though I,
   J, K, and L are a "subnetwork" (albeit a Pip subnetwork), and Y is
   stripping the "subnetwork" header (Hy) off before processing the true
   Transit Part (He).  If L does decapsulate the Transit Part, then,
   from Y's perspective, it is essentially as though Y were directly
   connected to X.










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


   2.2.5  Routing Directive (RD)

   The RD consists of the Routing Context (RC), the RC Contents, the
   FTIF Offset, and a series of zero or more FTIFs (Forwarding Table
   Index Fields).  This series of FTIFs is called the FTIF Chain.  The
   sole purpose of the RD is to determine how to forward the Pip
   packet--the RD does not influence handling in any way.


   Figure 3 illustrates the decision process for forwarding the Pip
   packet.

                 +---------+(next level RC)
    (decapsulate)|         |
                 |         v
                 |<--------RC----------------->FIB
                 |        /              |       |    IF Offset)
                 |       |     |
                 |       |     v
                 |<------|---FTIF------------->FIB
                 |       |  /  :
                 |       |<-   :(repeatedly...)
                 |       |     :
                 |       |     v
                 |<------|---FTIF------------->FIB
                         |  /  |
                         |<-   |
                         v     v
                          DestID-------------->FIB

                       Figure 3:  Forwarding Process


   Figure 3 is interpreted as follows.  The FIB is the Forwarding
   Information Block.  The FIB contains all the information needed to
   forward a packet, and may contain multiple next hop (for multicast).
   This information includes 1) the outgoing interface, 2) how to
   encapsulate the packet, including lower-layer address(es) (the
   lower-layer address(es) along with the outgoing interface determine
   the next hop Pip system), 3) whether and how to tunnel, 4) how to
   modify the semantics of the HD and RC, and how to modify the FTIF
   Offset.  The goal of the forwarding algorithm is to reach the
   appropriate FIB.

   The directed lines in Figure 3 start at the RC and, through various
   possible paths, reach a FIB.  These lines represent the various
   information that can influence the forwarding decision (that is, the
   FIB chosen).  For instance, there is no way to reach a FIB without



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


   first examining the information in the RC.  However, it is possible
   to identify a FIB by considering only the information in the RC (as
   indicated by the directed line leading directly right from the RC).
   Based on the information in the RC, it is also possible to determine
   that the Transit Part must be decapsulated, and 1) the RC of the next
   Transit Part be processed (the line leading directly left), 2) the
   FTIF indicated by the FTIF Offset is processed (the line leading down
   and right), or 3) the Dest ID is processed (the line leading down and
   lest).

   Likewise, when considering the value of an FTIF (in addition to all
   information already considered), the resulting action may be that 1)
   a FIB is identified, 2) the Transit Part is decapsulated, 3) the
   subsequent FTIF is processed, or 4) the Dest ID is processed.

   The RC is handled similarly to the HD.  The RC Contents field
   indicates how the RC should be interpreted.  While the RC is
   constructed similarly to the HD in the sense that it consists of
   multiple fields, the RC can be interpreted as a flat field in-so-far
   as forwarding a Pip packet is concerned, whereas the HD cannot.

   Thus, in a mechanical sense, the RC Contents can be viewed as an
   index into a table that returns a pointer to another table (an
   rcTable), which is indexed by the RC itself.  (Or, the combined RC
   Contents/RC can be viewed as a single large index into a single
   table, etc.)

   The FTIF Offset field indicates which FTIF is active.  The active
   FTIF is the one that is used to index the forwarding table indicated
   by the RC Contents/RC.  An FTIF Offset value of 0 means that the
   first FTIF is active, an FTIF Offset value of 1 means that the second
   FTIF is active, and so on.  If there are no FTIFs, then the FTIF
   Offset has no meaning, and can be any value.  In this case, the RC
   field itself will indicate how to forward the packet.

   The FTIF Chain is padded out to a 32-bit boundary.  Note that there
   can be more than 16 bits of padding (for instance, if it is desirable
   to pad out to a 64-bit boundary).  The padding is ignored upon
   receipt, and can be transmitted as any value (that is, it does not
   have to be any specific pattern of 0's or 1's).

   Note that a single "number" in the FTIF chain may in fact be more
   than 16 bits in length.  In this case, the number can be encoded as
   multiple FTIFs with no loss of generality.  It is only required that
   in all cases a multiple FTIF number be distinguishable from a single
   FTIF number.





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


   2.2.6  Router RD Forwarding Algorithm

   This section describes the forwarding algorithm for a Pip router.

   1.  Using the value of the RC field as an index, retrieve one of the
       following instructions (steps 2 - 5) from the rcTable determined
       by the RC Contents.

   2.  If the instruction is decapsulate, then decapsulate the Transit
       Part and re-execute step 1 using the next Transit Part.

   3.  If the instruction is forward, then retrieve the associated
       Forwarding Information Block (FIB), and go to step 12.

   4.  If the instruction is to examine the Dest ID, then retrieve the
       FIB associated with the Dest ID, and go to step 12.

   5.  If the instruction is to examine the FTIF Chain, then retrieve the
       forwardingTable indicated by the rcTable entry, and continue on to
       step 6.

   6.  Using the value of the currently active FTIF (this is the FTIF
       indicated by the FTIF Offset if this is the first FTIF examined)
       as an index, retrieve one or more of the following instructions
       (steps 7 - 10) from the forwardingTable identified in step 5 or
       step 10.

   7.  If the instruction is decapsulate, then decapsulate the Pip header
       and re-execute step 1 using the new header (this is the same as
       step 2).

   8.  If the instruction is forward, then (possibly additionally)
       retrieve the associated FIB, and go to step 12 (this is the same
       as step 3).

   9.  If the instruction is to examine the Dest ID, then retrieve the
       FIB associated with the Dest ID and go to step 12 (this is the
       same as step 4).

   10.  If the instruction is to examine the next FTIF, then, according
        to the information in the current forwardingTable entry, modify
        the current FTIF and choose a new forwardingTable.

   11.  Make the next FTIF the current FTIF and go to step 6.

   12.  The FIB contains a set of potential recipients for the Pip
        packet, including next hop Pip systems (both directly connected
        and at the end of Pip tunnels) and the upper layer of the local



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


        system.  Taking into consideration 1) the incoming interface, 2)
        the previous hop Pip system if known (as determined by the
        lower-layer source address and incoming interface), and 3)
        potentially other local information (such as congestion on
        outgoing queues), prune the set of potential recipients.  (This
        may result in no pruning having taken place or in every potential
        next hop having been pruned.)

   13.  For each remaining next hop, format a Pip header by modifying a)
        the RC, b) the current FTIF, c) the FTIF Offset (to point to 1)
        the FTIF pointed to in the received RD, 2) the current FTIF, 3)
        the Nth FTIF counting from the 0th FTIF, or 4) the Nth FTIF
        counting forwards or backwards from the current FTIF) and d) any
        Pip header encapsulations, according to the information in the
        FIB, and transmit the packet to the recipient (either a next hop
        or upper layer).

   2.3  Options Part

   The Option Part is formatted as shown in Figure 4.


           +===========================+
           |    Options Descriptor     |     64
           +===========================+
           |        Option 2           |     Variable
           +===========================+
           |        Option 3           |     Variable
           +===========================+
                       .
                       .
                       .
           +===========================+
           |        Option N           |     Variable
           +===========================+


                          Figure 4: Options Part

   Every Option is at least one 32-bit word in length, and ends on a
   32-bit word boundary.  Because the type of each option is known from
   the Options Contents field, there is no need to indicate the option
   type in the options field themselves.  Thus, there is no common
   format among the options--each option has its own format.  The
   individual options are defined in another specification.






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


   2.3.1  Options Descriptor

   The Options Descriptor option gives the offset of each option in the
   Options Part.  The Options Descriptor consists of eight eight-bit
   Option Position fields, each of which gives the position of up to
   eight options (there can be no more than 8 Options Part).  Each of
   the Option Position fields correspond to one of the bits in the
   Options Present field.  The unit of measure of each Option Position
   is 32-bit words, counting the first word of the Options Part as word
   0.  The high order Option Position field corresponds to the high
   order bit in the Options Present field.

Security Considerations

   Security issues are not discussed in this memo.

Author's Address

   Paul Francis
   NTT Software Lab
   3-9-11 Midori-cho Musashino-shi
   Tokyo 180 Japan

   Phone: [phone]
   Fax [phone]
   EMail: [e-mail]

























Francis                                                        [Page 16]