rfc1241.txt

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

   The Flow ID that results from the mapping of a Clear Header is a 32
   bit quantity and identifies the Flow as it is seen by the
   Encapsulator.  If a Clear Datagram must be encapsulated and
   decapsulated several times in order reach the destination, the Flow
   ID may be different at each Encapsulator, but need not be.  The Flow
   ID acts as an index into a table of Encapsulation Header information
   that is used to build the Encapsulation Header.  Note that the
   decision to make the Flow ID local to the Encapsulator is due to the
   difficulty in choosing and maintaining globally unique identifiers.

   The intermediate step of using a Flow ID entirely optional.  The
   important requirement is that all Encapsulators along a Flow map the
   same Clear Header to the same Flow (which could be identified by
   different identifiers along the way).  However, by allowing for a



Woodburn & Mills                                                [Page 6]

RFC 1241                 Internet Encapsulation                July 1991


   Flow ID in the protocol, a more efficient implementation of the
   mapping function becomes possible.  This is discussed in more detail
   when we consider the Decapsulator.

   The following information is required to construct the Encapsulation
   Header:

   Flow ID -
     This is the key for this table of information and
     represents the Flow ID relative to the current
     Encapsulator.

   Decapsulator Address -
     The IP address of the Decapsulator in the Encapsulation
     Space must be known to build the IP portion of the
     Encapsulation Header.

   Decapsulator's Flow ID -
     The Flow ID, if any, for the Flow as seen by the
     Decapsulator must be known.

   Previous Encapsulator's Address -
     If this is not the first Encapsulator along the Flow, the
     previous Encapsulator's address must be known for error
     reporting.

   Previous Encapsulator's Flow ID -
     In addition to the previous Encapsulator's address, the
     Flow ID of the Flow relative to the previous Encapsulator
     must be known.

   The Encapsulation Header consists of an IP Header as well as an
   Encapsulation Protocol Header.  The two pieces of information
   required for the Encapsulation Protocol Header which must be
   determined at the time of encapsulation are the protocol which is
   being encapsulated and the Flow ID to send to the Decapsulator.  The
   generation of the IP header is more complicated.

   There are  two possible ways each field in the Clear Header could
   related to the new IP header.

   Copy -
     Copy the existing field from the Clear Header to the IP
     header in the Encapsulation Header.

   Ignore -
     The field may or may not have existed in the Clear Header,
     but does not apply to the new IP header.



Woodburn & Mills                                                [Page 7]

RFC 1241                 Internet Encapsulation                July 1991


   The IP header has a fixed portion and a variable portion, the options
   list.  A summary of all possible IP fields and the relation to the
   Clear Header follows in Table 1. [2]

   Note that most of the fields in the Clear Header are simply ignored.
   Fields such as the Header Length in the Clear Header have no effect
   on the Header Length of the new IP header.  The fields which are more
   interesting and require some thought are now discussed.

   The Quality of Service bits should be copied from the Clear Header to
   the new IP header.  This is in keeping with the transparency
   principle that if the User Space was providing a given service, then
   the Encapsulation Space must provide the same service.

   The More Fragments bit and Fragment Offset should not be copied,
   since the datagram being built is a complete datagram, regardless of
   the status of the encapsulated datagram.  If the completed datagram
   is too large for the interface, it will be fragmented for
   transmission to the decapsulator by the normal IP fragmentation
   mechanism.

   The Don't Fragment bit should not be copied into the Encapsulation
   Header.  The transparency principle would again be violated.  It
   should be up to the Encapsulator to decide whether fragmentation
   should be allowed across the Encapsulation Space.  If it is decided
   that the DF bit should be used, then ICMP message would be returned
   if the Encapsulated Datagram required fragmentation across the
   Encapsulation Space The mechanism for returning an ICMP message to
   the source in the User space will have to be modified, however, and
   this is discussed in the Appendix B.

   Regarding the Time To Live (TTL) field, the easiest thing to do is to
   ignore the TTL from the Clear Header.  If this field were copied from
   the Clear Header to the new IP header, the packet life might be
   prematurely exceeded during transit in the Encapsulation Space.  This
   breaks the transparency rule of encapsulation as seen from the User
   Space.  The TTL of the Clear Header is decremented before
   encapsulation by the IP forwarding function, so there is no chance of
   a packet looping forever if the links of a Flow form a loop.












Woodburn & Mills                                                [Page 8]

RFC 1241                 Internet Encapsulation                July 1991


                          +---------------------+---------+
                          |        Field        | Mapping |
                          +---------------------+---------+
                          | Version             | Ignore  |
                          | Header Length       | Ignore  |
                          | Precedence          | Copy    |
                          | QoS bits            | Copy    |
                          | Total Length        | Ignore  |
                          | Identification      | Ignore  |
                          | Don't Fragment Bit  | Ignore  |
                          | More Fragments Bit  | Ignore  |
                          | Fragment Offset     | Ignore  |
                          | Time to Live        | Ignore  |
                          | Protocol            | Ignore  |
                          | Header Checksum     | Ignore  |
                          | Source Address      | Ignore  |
                          | Destination Address | Ignore  |
                          | End of Option List  | Ignore  |
                          | NOP Option          | Ignore  |
                          | Security Option     | Copy    |
                          | LSR Option          | Ignore  |
                          | SSR Option          | Ignore  |
                          | RR Option           | Ignore  |
                          | Stream ID Option    | Ignore  |
                          | Timestamp Option    | Ignore  |
                          +---------------------+---------+

                       Table 1.  Summary of IP Header Mappings

   The protocol field for the new IP header should be filled with the
   protocol number of the encapsulation protocol.

   The source address in the new IP header becomes the IP address of the
   Encapsulator in the Encapsulation Domain.  The destination address
   becomes the IP address of the Decapsulator as found in the
   encapsulation table.

   IP Options are generally not copied because most don't make sense in
   the context of the Encapsulation Space, as the transparency principle
   would indicate.  The security option is probably the one option that
   should get copied for the same reason QOS and precedence fields are
   copied, the Encapsulation Space must provide the expected service.
   Timestamp, Loose Source Route, Strict Source Route, and Record Route
   are not copied during encapsulation.

6. Decapsulation

   In the ideal situation, a Decapsulator receives an Encapsulated



Woodburn & Mills                                                [Page 9]

RFC 1241                 Internet Encapsulation                July 1991


   Datagram, strips off the Encapsulation Header and sends the Clear
   Datagram back into IP so that it is forwarded from that point.
   However, if the Clear Datagram has not reached the destination User
   Space, it must again be encapsulated to move it close to the
   destination User Space.  In this latter case the Decapsulator would
   become an Encapsulator and would perform the same calculation to
   generate the Encapsulation Header as did the previous Encapsulator.
   In order to make this process more efficient, the use of Flow IDs
   have been incorporated into the protocol.

   When Flow IDs are used, the Flow ID received in the Encapsulation
   Header corresponds to a stored Flow ID in the Decapsulator.  At this
   point the Decapsulator has the option of bypassing the mask and match
   operation on the Clear Header.  The received Flow ID can be used to
   point directly into the local Encapsulator tables for the
   construction of the next Encapsulation Header.  If the Flow ID is
   unknown, an error message is sent back to the previous Encapsulator
   to that effect and a signal is sent to upper layer entity managing
   the encapsulation tables.

   Because the normal IP forwarding mechanism is being bypassed when
   Flow IDs are used, certain mechanisms normally handled by IP must be
   taken care of by the Decapsulator before encapsulation.  The
   Decapsulator must decrement the TTL before the next encapsulation
   occurs.  If a Time Exceeded error occurs, then an ICMP message is
   sent to the source indicated in the Clear Header.

7. Error Messages

   There are two kinds of error message built into the encapsulation
   protocol.  The first is used to report unknown flow identifiers seen
   by a Decapsulator and the second is for the forwarding of ICMP
   messages.

   When a Decapsulator is using the received Flow ID in an Encapsulation
   Header to forward a datagram to the next Decapsulator in a Flow, it
   is possible that the Flow ID may not be known.  For this case the
   Decapsulator will notify the previous Encapsulator that the Flow was
   not known so that the problem may be reported to the layer
   responsible for the programming of the Flow tables.  This is
   accomplished through an encapsulation error message.

   If an Encapsulator receives an ICMP messages regarding a given flow,
   this message should be forwarded backwards along the flow to the
   source Encapsulator.  This is accomplished by the second kind of
   error message.  The ICMP message will contain the Flow ID of the
   message which caused the error.  This Flow ID must be translated to
   the Flow ID relative to the Encapsulator to which the error message



Woodburn & Mills                                               [Page 10]

RFC 1241                 Internet Encapsulation                July 1991


   is sent.

   If an error occurs while sending any error message, no further error
   message are generated.

8. References

   [1]  J. Postel,  Internet  Control  Message  Protocol,  RFC  792,
        September 1981.

   [2]  J. Postel, Internet Protocol, RFC 791, September 1981.

   [3]  J. Postel, Transmission Control Protocol, RFC 793, September
        1981.

   [4]  ORWG, Inter-Domain Policy Routing Protocol Specification and
        Usage, Draft, August 1990

A. Packet Formats

   This section describes the packet formats for the encapsulation
   protocol.

        0               8              16              24            31
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Vers  |  HL   |  MT   |  RC   |            Checksum           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                            Flow ID                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Fig. A.1.  Encapsulation Protocol Header Example

       Vers      4 bits    The  version   number  of  the  encapsulation
                           protocol.     The  version  of  the  protocol
                           described by this document is 1.

       HL        4 bits    The  header   length  of   the  Encapsulation
                           Protocol Header in octets.

       MT        4 bits    The  message   type  of   the   Encapsulation
                           Protocol message.    A  data  message  has  a
                           message type  of 1.   An  error message has a
                           message type of 2.

       RC        4 bits    The reason code.  This field is unused in the
                           Data Message  and must have a value of 0.  In
                           the Error Message it contains the reason code
                           for the  Error Message.   Defined reason code



Woodburn & Mills                                               [Page 11]

RFC 1241                 Internet Encapsulation                July 1991


                           values are:

                                1 Unknown Flow ID
                                2 ICMP returned

       Checksum  16 bits   A   one's   complement   checksum   for   the
                           Encapsulation Protocol Header.  This field is
                           set to 0 upon calculation of the checksum and
                           is  filled   with  the  checksum  calculation
                           result before the data message is sent.

       Flow ID   32 bits   The Flow  ID as  seen by  the Decapsulator or
                           Encapsulator to  which this  message is being
                           sent.   In the  case of  an Unknown  Flow  ID
                           error, the Flow ID causing the error is used.