rfc2746.txt

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

   (type 3 tunnel). In our scheme the association is created when a
   tunnel entry point first sees an end-to-end session's RESV message
   and either sets up a new tunnel session, or adds to an existing
   tunnel session.  This new association must be conveyed to Rexit, so
   that Rexit can reserve resources for the end-to-end sessions inside
   the tunnel. This information includes the identifier and certain
   parameters of the tunnel session, and the identifier of the end-to-
   end session to which the tunnel session is being bound. In our
   scheme, all RSVP sessions between the same two routers Rentry and
   Rexit will have identical values for source IP address, destination
   IP address, and destination UDP port number. An individual session is
   identified primarily by the source port value.

   We identified three possible choices for a binding mechanism:

      1. Define a new RSVP message that is exchanged only between two
         tunnel end points to convey the binding information.
      2. Define a new RSVP object to be attached to end-to-end PATH
         messages at Rentry, associating the end-to-end session with one
         of the tunnel sessions. This new object is interpreted by Rexit
         associating the end-to-end session with one of the tunnel
         sessions generated at Rentry.
      3. Apply the same UDP encapsulation to the end-to-end PATH
         messages as to data packets of the session.  When Rexit
         decapsulates the PATH message, it deduces the relation between
         the source UDP port used in the encapsulation and the RSVP
         session that is specified in the original PATH message.















Terzis, et al.              Standards Track                     [Page 7]

RFC 2746             RSVP Operation Over IP Tunnels         January 2000


   The last approach above does not require any new design.  However it
   requires additional resources to be reserved for PATH messages (since
   they are now subject to the tunnel reservation).  It also requires a
   priori knowledge of whether Rexit supports RSVP over tunnels by UDP
   encapsulation.  If Rentry encapsulates all the end-to-end PATH
   messages with the UDP encapsulation, but Rexit does not understand
   this encapsulation, then the encapsulated PATH messages will be lost
   at Rexit.

   On the other hand, options (1) and (2) can handle this case
   transparently.  They allow Rexit to pass on end-to-end PATHs received
   via the tunnel (because they are decapsulated normally), while
   throwing away the tunnel PATHs, all without any additional
   configuration.  We chose Option (2) because it is simpler.  We
   describe this object in the following section.

   Packet exchanges must follow the following constraints:

      1. Rentry encapsulates and sends end-to-end PATH messages over the
         tunnel to Rexit where they get decapsulated and forwarded
         downstream.
      2. When a corresponding end-to-end RESV message arrives at Rexit,
         Rexit encapsulates it and sends it to Rentry.
      3. Based on some or all of the information in the end-to-end PATH
         messages, the flowspec in the end-to-end RESV message and local
         policies, Rentry decides if and how to map the end-to-end
         session to a tunnel session.
      4. If the end-to-end session should be mapped to a tunnel session,
         Rentry either sends a PATH message for a new tunnel session or
         updates an existing one.
      5. Rentry sends a E2E Path containing a SESSION_ASSOC object
         associating the end-to-end session with the tunnel session
         above.  Rexit records the association and removes the object
         before forwarding the Path message further.
      6. Rexit responds to the tunnel PATH message by sending a tunnel
         RESV message, reserving resources inside the tunnel.
      7. Rentry UDP-encapsulates arriving packets only if a
         corresponding tunnel session reservation is actually in place
         for the packets.












Terzis, et al.              Standards Track                     [Page 8]

RFC 2746             RSVP Operation Over IP Tunnels         January 2000


2.3.1.  SESSION_ASSOC Object

   The new object, called SESSION_ASSOC, is defined with the following
   format:

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          length               |  class        |     c-type    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    |          SESSION object  (for the end-to-end session)         |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    |           Sender FILTER-SPEC (for the tunnel session)         |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                           SESSION_ASSOC Object

   Length

      This field contains the size of the SESSION_ASSOC object in bytes.

   Class

      Should be 192.

   Ctype

      Should be sent as zero and ignored on receipt.

   SESSION object

      The end-to-end SESSION contained in the object is to be mapped to
      the tunnel session described by the Sender FILTER-SPEC defined
      below.

   Sender FILTER-SPEC

      This is the tunnel session that the above mentioned end-to-end
      session maps to over the tunnel. As we mentioned above, a tunnel
      session is identified primarily by source port. This is why we use
      a Sender Filter-Spec for the tunnel session, in the place of a
      SESSION object.







Terzis, et al.              Standards Track                     [Page 9]

RFC 2746             RSVP Operation Over IP Tunnels         January 2000


2.3.2.  NODE_CHAR Object

   There has to be a way (other than through configuration) for Rexit to
   communicate to Rentry the fact that it is a tunnel endpoint
   supporting the scheme described in this document. We have defined for
   this reason a new object, called NODE_CHAR, carrying this
   information. If a node receives this object but does not understand
   it, it should drop it without producing any error report. Objects
   with Class-Num = 10bbbbbb (`b' represents a bit), as defined in the
   RSVP specification [RFC2205], have the characteristics we need. While
   for now this object only carries one bit of information, it can be
   used in the future to describe other characteristics of an RSVP
   capable node that are not part of the original RSVP specification.

   The object NODE_CHAR has the following format:

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          length               |  class        |     c-type    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Reserved                            |T|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length

      This field contains the size of the NODE_CHAR object in bytes. It
      should be set to eight.

   Class

      An appropriate value should be assigned by the IANA. We propose
      this value to be 128.

   Ctype

      Should be sent as zero and ignored on receipt.

   T bit

      This bit shows that the node is a RSVP-tunnel capable node.

   When Rexit receives an end-to-end reservation, it appends a NODE_CHAR
   object with the T bit set, to the RESV object, it encapsulates it and
   sends it to Rentry. When Rentry receives this RESV message it deduces
   that Rexit implements the mechanism described here and so it creates
   or adjusts a tunnel session and associates the tunnel session to the
   end-to-end session via a SESSION_ASSOC object. Rentry should remove
   the NODE_CHAR object, before forwarding the RESV message upstream. If




Terzis, et al.              Standards Track                    [Page 10]

RFC 2746             RSVP Operation Over IP Tunnels         January 2000


   on the other hand, Rentry does not support the RSVP Tunnels mechanism
   it would simply ignore the NODE_CHAR object and not forward it
   further upstream.

3.  Implementation

   In this section we discuss several cases separately, starting from
   the simplest scenario and moving to the more complex ones.

3.1.  Single Configured RSVP Session over an IP-in-IP Tunnel

   Treating the two tunnel endpoints as a source and destination host,
   one easily sets up a FF-style reservation in between.  Now the
   question is what kind of filterspec to use for the tunnel
   reservation, which directly relates to how packets get encapsulated
   over the tunnel.  We discuss two cases below.

3.1.1.  In the Absence of End-to-End RSVP Session

   In the case where all the packets traversing a tunnel use the
   reserved resources, the current IP-in-IP encapsulation could be used.
   The RSVP session over the tunnel would simply specify a FF style
   reservation (with zero port number) with Rentry as the source address
   and Rexit as the destination address.

   However if only some of the packets traversing the tunnel should
   benefit from the reservation, we must encapsulate the qualified
   packets in IP and UDP. This allows intermediate routers to use
   standard RSVP filterspec handling, without having to know about the
   existence of tunnels.

   Rather than supporting both cases we choose to simplify
   implementations by requiring all data packets using reservations to
   be encapsulated with an outer IP and UDP header. This reduces special
   case checking and handling.

3.1.2.  In the Presence of End-to-End RSVP Session(s)

   According to the tunnel control policies, installed through some
   management interface, some or all end-to-end RSVP sessions may be
   allowed to map to the single RSVP session over the tunnel.  In this
   case there is no need to provide dynamic binding information between
   end-to-end sessions and the tunnel session, given that the tunnel
   session is unique and pre-configured, and therefore well-known.

   Binding multiple end-to-end sessions to one tunnel session, however,
   raises a new question of when and how the size of the tunnel
   reservation should be adjusted to accommodate the end-to-end sessions



Terzis, et al.              Standards Track                    [Page 11]

RFC 2746             RSVP Operation Over IP Tunnels         January 2000


   mapped onto it.  Again the tunnel manager makes such policy decision.
   Several scenarios are possible. In the first, the tunnel reservation
   is never adjusted. This makes the tunnel the rough equivalent of a
   fixed-capacity hardware link. In the second, the tunnel reservation
   is adjusted whenever a new end-to-end reservation arrives or an old
   one is torn down. In the third, the tunnel reservation is adjusted
   upwards or downwards occasionally, whenever the end-to-end
   reservation level has changed enough to warrant the adjustment. This
   trades off extra resource usage in the tunnel for reduced control
   traffic and overhead.

   We call a tunnel whose reservation cannot be adjusted a "hard pipe",
   as opposed to a "soft pipe" where the amount of resources allocated
   is adjustable. Section 5.2 explains how the adjustment can be carried
   out for soft pipes.

3.2.  Multiple Configured RSVP Sessions over an IP-in-IP Tunnel

   It is straightforward to build on the case of a single configured
   RSVP session over a tunnel by setting up multiple FF-style
   reservations between the two tunnel endpoints using a management
   interface.  In this case Rentry must carefully encapsulate data
   packets with the proper UDP port numbers, so that packets belonging
   to different tunnel sessions will be distinguished by the
   intermediate RSVP routers.  Note that this case and the one described
   before describe what we call type 2 tunnels.

3.2.1.  In the Absence of End-to-End RSVP Session

   Nothing more needs to be said in this case. Rentry classifies the
   packets and encapsulates them accordingly. Packets with no
   reservations are encapsulated with an outer IP header only, while
   packets qualified for reservations are encapsulated with a UDP header
   as well as an IP header. The UDP source port value should be properly
   set to map to the corresponding tunnel reservation the packet is
   supposed to use.

3.2.2.  In the Presence of End-to-End RSVP Session(s)

   Since in this case, there is more than one RSVP session operating
   over the tunnel, one must explicitly bind each end-to-end RSVP
   session to its corresponding tunnel session.  As discussed
   previously, this binding will be provided by the new SESSION_ASSOC
   object carried by the end-to-end PATH messages.







Terzis, et al.              Standards Track                    [Page 12]

RFC 2746             RSVP Operation Over IP Tunnels         January 2000


3.3.  Dynamically Created Tunnel RSVP Sessions

   This is the case of a type 3 tunnel. The only differences between
   this case and that of Section 4.2 are that:

      - The tunnel session is created when a new end-to-end session
        shows up.
      - There is a one-to-one mapping between the end-to-end and tunnel
        RSVP sessions, as opposed to possibly many-to-one mapping that
        is allowed in the case described in Section 4.2.

4.  RSVP Messages handling over an IP-in-IP Tunnel

4.1.  RSVP Messages for Configured Session(s) Over A Tunnel

   Here one or more RSVP sessions are set up over a tunnel through a
   management interface.  The session reservation parameters never
   change for a "hard pipe" tunnel. The reservation parameters may
   change for a "soft pipe" tunnel. Tunnel session PATH messages
   generated by Rentry are addressed to Rexit, where they are processed
   and deleted.

4.2.  Handling of RSVP Messages at Tunnel Endpoints