rfc1241.txt

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

Network Working Group                                       R. Woodburn
Request for Comments: 1241                                         SAIC
                                                               D. Mills
                                                 University of Delaware
                                                              July 1991


            A Scheme for an Internet Encapsulation Protocol:
                               Version 1

1. Status of this Memo

   This memo defines an Experimental Protocol for the Internet
   community.  Discussion and suggestions for improvement are requested.
   Please refer to the current edition of the "IAB Official Protocol
   Standards" for the standardization state and status of this protocol.
   Distribution of this memo is unlimited.

2. Glossary

   Clear Datagram -
     The unmodified IP datagram in the User Space before
     Encapsulation.

   Clear Header -
     The header portion of the Clear Datagram before
     Encapsulation.  This header includes the IP header and
     possibly part or all of the next layer protocol header,
     i.e., the TCP header.

   Decapsulation -
     The stripping of the Encapsulation Header and forwarding
     of the Clear Datagram by the Decapsulator.

   Decapsulator -
     The entity responsible for receiving an Encapsulated
     Datagram, decapsulating it, and delivering it to the
     destination User Space.  Delivery may be direct, or via
     Encapsulation.  A Decapsulator may be a host or a gateway.

   Encapsulated Datagram -
     The datagram consisting of a Clear Datagram prepended with
     an Encapsulation Header.

   Encapsulation -
     The process of mapping a Clear Datagram to the
     Encapsulation Space, prepending an Encapsulation Header to
     the Clear Datagram and routing the Encapsulated Datagram



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


     to a Decapsulator.

   Encapsulation Header -
     The header for the Encapsulation Protocol prepended to the
     Clear Datagram during Encapsulation.  This header consists
     of an IP header followed by an Encapsulation Protocol
     Header.

   Encapsulation Protocol Header -
     The Encapsulation Protocol specific portion of the
     Encapsulation Header.

   Encapsulation Space -
     The address and routing space within which the
     Encapsulators and Decapsulators reside.  Routing within
     this space is accomplished via Flows.  Encapsulation
     Spaces do not overlap, that is, the address of any
     Encapsulator or Decapsulator is unique for all
     Encapsulation Spaces.

   Encapsulator -
     The entity responsible for mapping a given User Space
     datagram to the Encapsulation Space, encapsulating the
     datagram, and forwarding the Encapsulated Datagram to a
     Decapsulator.  An Encapsulator may be a host or a gateway.

   Flow -
     Also called a "tunnel."  A flow is the end-to-end path in
     the Encapsulation Space over which Encapsulated Datagrams
     travel.  There may be several Encapsulator/Decapsulator
     pairs along a given flow.  Note that a Flow does not
     denote what User Space gateways are traversed along the
     path.

   Flow ID -
     A 32-bit identifier which uniquely distinguishes a flow in
     a given Encapsulator or Decapsulator.  Flow IDs are
     specific to a single Encapsulator/Decapsulator Entity and
     are not global quantities.

   Mapping Function -
     This is the function of mapping a Clear Header to a
     particular Flow.  All encapsulators along a given Flow are
     required to map a given Clear Header to the same Flow.

   User Address -
     The address or identifier uniquely identifying an entity
     within a User Space.



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


   Source Route -
     A complete end-to-end route which is computed at the
     source and enumerates transit gateways.

   User Space -
     The address and routing space within which the users
     reside.  Routing within this space provides reachability
     between all address pairs within the space.  User Spaces
     do not overlap, that is, a given User Address is unique in
     all User Spaces.

3. Background

   For several years researchers in the Internet community have needed a
   means of "tunneling" between networks.  A tunnel is essentially a
   Source Route that circumvents conventional routing mechanisms.
   Tunnels provide the means to bypass routing failures, avoid broken
   gateways and routing domains, or establish deterministic paths for
   experimentation.

   There are several means of accomplishing tunneling.  In the past,
   tunneling has been accomplished through source routing options in the
   IP header which allow gateways along a given path to be enumerated.
   The disadvantage of source routing in the IP header is that it
   requires the source to know something about the networks traversed to
   reach the destination.  The source must then modify outgoing packets
   to reflect the source route.  Current routing implementations
   generally don't support source routes in their routing tables as a
   means of reaching an IP address, nor do current routing protocols.

   Another means of tunneling would be to develop a new IP option.  This
   option field would be part of a separate IP header that could be
   prepended to an IP datagram.  The IP option would indicate
   information about the original datagram.  This tunneling option has
   the disadvantage of significantly modifying existing IP
   implementations to handle a new IP option.  It also would be less
   flexible in permitting the tunneling of other protocols, such as ISO
   protocols, through an IP environment.  An even less palatable
   alternative would be to replace IP with a new networking protocol or
   a new version of IP with tunneling built in as part of its
   functionality.

   A final alternative is to create a new IP encapsulation protocol
   which uses the current IP header format.  By using encapsulation, a
   destination can be reached transparently without the source having to
   know topology specifics.  Virtual networks can be created by tying
   otherwise unconnected machines together with flows through an
   encapsulation space.



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


                                               ++++++  Clear Datagram
                                               ******  Encapsulated
       Datagram
                                                    #
       Encapsulator/Decapsulator
                                                    &  User Space Host


           User Space A                        User Space C

          --------------                    -----------
         /              \                  /           \
        /                \                /             \
       |                  |              |               |
       |     &            |              |               |
       |     +   +++++    |              |      *****    |
       |     +++++   +    |              |      *   *    |
       |             +    |              |  *****   *    |
        \            +   /  -----------  \ *       *    /  ----------
         \           ++> # *         **> # *        ***> # ++++      \
          --------------  / *        *  \  ------------  /   +        \
                         |  *        *   |              |    +         |
                         |  *        *   |              |    +         |
                         |  *****    *   |              |    +++++++   |
                         |      *****    |              |          V   |
                         |               |              |          &   |
                          \             /                \             /
                           \           /                  \           /
                            -----------                    ----------
                           Encapsulation                      User
                              Space B                        Space D


                  Fig. 1.  Encapsulation Architectural Model

   Up until now, there has been no standard for an encapsulation
   protocol.  This RFC provides a means of performing encapsulation in
   the Internet environment.

4. Architecture and Approach

   The architecture for encapsulation is based on two entities -- an
   Encapsulator and a Decapsulator.  These entities and the associated
   spaces are shown in Fig. 1.

   Encapsulators and Decapsulators have addresses in the User Spaces to
   which they belong, as well as addresses in the Encapsulation Spaces
   to which they belong. An encapsulator will receive a Clear Datagram



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


   from its User Space, and after determining that encapsulation should
   be used, perform a mapping function which translates the User Space
   information in the Clear Header to an Encapsulation Header.  This
   Encapsulation Header is then prepended to the Clear Datagram to form
   the Encapsulated Datagram, as in Fig 2.  It is desirable that the
   encapsulation process be transparent to entities in the User Space.
   Only the Encapsulator need know that encapsulation is occurring.

         +---------------+-----------------+--------+----------------+
         | Encapsulating |  Encapsulation  | Clear  |  Remainder of  |
         |   IP Header   | Protocol Header | Header | Clear Datagram |
         +---------------+-----------------+--------+----------------+

         |                                 |                         |
         |        Encapsulation Header     |      Clear Datagram     |
         |                                 |                         |


                 Fig. 2.  Example of an Encapsulated Datagram

   The Encapsulator forwards the datagram to a Decapsulator whose
   identity is determined at the time of encapsulation.  The
   Decapsulator receives the Encapsulated Datagram and removes the
   Encapsulation Header and treats the Clear Datagram as if it were
   received locally.  The requirement for the address of the
   Decapsulator is that it be reachable from the Encapsulator's
   Encapsulation Space address.

5. Generation of the Encapsulation Header

   The contents of the Encapsulation Header are generated by performing
   a mapping function from the Clear Header to the contents of the
   Encapsulation Header.  This mapping function could take many forms,
   but the end result should be the same.  The following paragraphs
   describe one method of performing the mapping.  The process is
   illustrated in Fig. 3.

   In the first part of the mapping function, the Clear Header is
   matched with stored headers and masks to determine a Flow ID.  This
   is essentially a "mask-and-match" table look up, where the lookup
   table holds three entries, a Clear Header, a header mask, and a
   corresponding Flow ID.  The mask can be used for allowing a range of
   source and destination addresses to map to a given flow.  Other
   fields, such as the IP TOS bits or even the TCP source or destination
   port addresses could also be used to discriminate between Flows.
   This flexibility allows many possibilities for using the mapping
   function.  Not only can a given network be associated with a
   particular flow, but even a particular TCP protocol or connection



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


   could be distinguished from another.

   How the lookup table is built and maintained is not part of this
   protocol.  It is assumed that it is managed by some higher layer
   entity.  It would be sufficient to configure the tables from ascii
   text files if necessary.

                                                +--------+
                                                |        |
                                             +->| Encap. |--+
                                             |  | Info.  |  |
                   +-------+                 |  | Table  |  |
                   | Mask  |   +---------+   |  |        |  |
       Clear --+-->|  &    |-->| Flow ID |---+  |        |  |
       Header  |   | Match |   +---------+      +--------+  |
               |   +-------+                                |
               |                                            +-->  Encap
               +----------------------------------------------->  Header


                Fig. 3.  Generation of the Encapsulation Header

   The Flow IDs are managed at a higher layer as well.  An example of
   how Flow IDs can be managed is found in the Setup protocol of the
   Inter-Domain Policy Sensitive Routing Protocol (IDPR). [4] The upper
   layer protocol would be responsible for maintaining information not
   carried in the encapsulation protocol related to the flow.  This
   could include the information necessary to construct the
   Encapsulation Header (described below) as well as information such as
   the type of data being encapsulated (currently only IP is defined),
   and the type of authentication used if any.  Note that IDPR Setup
   requires the use of a longer Flow ID which is unique for the entire
   universe of Encapsulators and is the same at every Encapsulator.