rfc2746.txt

RFC 的详细文档！

4.2.1.  Handling End-to-End PATH Messages at Rentry

   When forwarding an end-to-end PATH message, a router acting as the
   tunnel entry point, Rentry, takes the following actions depending on
   the end-to-end session mentioned in the PATH message. There are two
   possible cases:

      1. The end-to-end PATH message is a refresh of a previously known
         end-to-end session.
      2. The end-to-end PATH message is from a new end-to-end session.

   If the PATH message is a refresh of a previously known end-to-end
   session, then Rentry refreshes the Path state of the end-to-end
   session and checks to see if this session is mapped to a tunnel
   session. If this is the case, then when Rentry refreshes the end-to-
   end session, it includes in the end-to-end PATH message a
   SESSION_ASSOC object linking this session to its corresponding tunnel
   session It then encapsulates the end-to-end PATH message and sends it
   over the tunnel to Rexit. If the tunnel session was dynamically
   created, the end-to-end PATH message serves as a refresh for the
   local tunnel state at Rentry as well as for the end-to-end session.






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


   Otherwise, if the PATH message is from a new end-to-end session that
   has not yet been mapped to a tunnel session, Rentry creates Path
   state for this new session setting the outgoing interface to be the
   tunnel interface. After that, Rentry encapsulates the PATH message
   and sends it to Rexit without adding a SESSION_ASSOC message.

   When an end-to-end PATH TEAR is received by Rentry, this node
   encapsulates and forwards the message to Rexit. If this end-to-end
   session has a one-to-one mapping to a tunnel session or if this is
   the last one of the many end-to-end sessions mapping to a tunnel
   session, Rentry tears down the tunnel session by sending a PATH TEAR
   for that session to Rexit. If, on the other hand, there are remaining
   end-to-end sessions mapping to the tunnel session, then Rentry sends
   a tunnel PATH message adjusting the Tspec of the tunnel session.

4.2.2.  Handling End-to-End PATH Messages at Rexit

   Encapsulated end-to-end PATH messages are decapsulated and processed
   at Rexit. Depending on whether the end-to-end PATH message contains a
   SESSION_ASSOC object or not, Rexit takes the following steps:

      1. If the end-to-end PATH message does not contain a SESSION_ASSOC
         object, then Rentry sets the Non_RSVP flag at the Path state
         stored for this end-to-end sender, sets the global break bit in
         the ADSPEC and forwards the packets downstream. Alternatively,
         if tunnel sessions exist and none of them has the Non_RSVP flag
         set, Rexit can pick the worst-case Path ADSPEC params from the
         existing tunnel sessions and update the end-to-end ADSPEC using
         these values. This is a conservative estimation of the composed
         ADSPEC but it has the benefit of avoiding to set the break bit
         in the end-to-end ADSPEC before mapping information is
         available. In this case the Non_RSVP flag at the end-to-end
         Path state is not set.

      2. If the PATH message contains a SESSION_ASSOC object and no
         association for this end-to-end session already exists, then
         Rexit records the association between the end-to-end session
         and the tunnel session described by the object. If the end-to-
         end PATH arrives early before the tunnel PATH message arrives
         then it creates PATH state at Rexit for the tunnel session.
         When the actual PATH message for the tunnel session arrives it
         is treated as an update of the existing PATH state and it
         updates any information missing. We believe that this situation
         is another transient along with the others existing in RSVP and
         that it does not have any long-term effects on the correct
         operation of the mechanism described here.





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


         Before further forwarding the message to the next hop along the
         path to the destination, Rexit finds the corresponding tunnel
         session's recorded state and turns on Non_RSVP flag in the
         end-to-end Path state if the Non_RSVP bit was turned on for the
         tunnel session.  If the end-to-end PATH message carries an
         ADSPEC object, Rexit performs composition of the
         characterization parameters contained in the ADSPEC. It does
         this by considering the tunnel session's overall (composed)
         characterization parameters as the local parameters for the
         logical link implemented by the tunnel, and composing these
         parameters with those in the end-to-end ADSPEC by executing
         each parameter's defined composition function. In the logical
         link's characterization parameters, the minimum path latency
         may take into account the encapsulation/decapsulation delay and
         the bandwidth estimate can represent the decrease in available
         bandwidth caused by the addition of the extra UDP header.
         ADSPECs and composition functions are discussed in great detail
         in [RFC2210].

         If the end-to-end session has reservation state, while no
         reservation state for the matching tunnel session exists, Rexit
         send a tunnel RESV message to Rentry matching the reservation
         in the end-to-end session.

   If Rentry does not support RSVP tunneling, then Rexit will have no
   PATH state for the tunnel. In this case Rexit simply turns on the
   global break bit in the decapsulated end-to-end PATH message and
   forwards it.

4.2.3.  Handling End-to-End RESV Messages at Rexit

   When forwarding a RESV message upstream, a router serving as the exit
   router, Rexit, may discover that one of the upstream interfaces is a
   tunnel.  In this case the router performs a number of tests.

   Step 1: Rexit must determine if there is a tunnel session bound to
   the end-to-end session given in the RESV message.  If not, the tunnel
   is treated as a non-RSVP link, Rexit appends a NODE_CHAR object with
   the T bit set, to the RESV message and forwards it over the tunnel
   interface (where it is encapsulated as a normal IP datagram and
   forwarded towards Rentry).

   Step 2: If a bound tunnel session is found, Rexit checks to see if a
   reservation is already in place for the tunnel session bound to the
   end-to-end session given in the RESV message. If the arriving end-
   to-end RESV message is a refresh of existing RESV state, then Rexit
   sends the original RESV through tunnel interface (after adding the
   NODE_CHAR object). For dynamic tunnel sessions, the end-to-end RESV



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


   message acts as a refresh for the tunnel session reservation state,
   while for configured tunnel sessions, reservation state never
   expires.

   If the arriving end-to-end RESV message causes a change in the end-
   to-end RESV flowspec parameters, it may also trigger an attempt to
   change the tunnel session's flowspec parameters.  In this case Rexit
   sends a tunnel session RESV, including a RESV_CONFIRM object.

   In the case of a "hard pipe" tunnel, a new end-to-end reservation or
   change in the level of resources requested by an existing reservation
   may cause the total resource level needed by the end-to-end
   reservations to exceed the level of resources reserved by the tunnel
   reservation. This event should be treated as an admission control
   failure, identically to the case where RSVP requests exceed the level
   of resources available over a hardware link. A RESV_ERR message with
   Error Code set to 01 (Admission Control failure), should be sent back
   to the originator of the end-to-end RESV message.

   If a RESV CONFIRM response arrives, the original RESV is encapsulated
   and sent through the tunnel. If the updated tunnel reservation fails,
   Rexit must send a RESV ERR to the originator of the end-to-end RESV
   message, using the error code and value fields from the ERROR_SPEC
   object of the received tunnel session RESV ERR message. Note that the
   pre-existing reservations through the tunnel stay in place. Rexit
   continues refreshing the tunnel RESV using the old flowspec.

   Tunnel session state for a "soft pipe" may also be adjusted when an
   end-to-end reservation is deleted.  The tunnel session gets reduced
   whenever one of the end-to-end sessions using the tunnel goes away
   (or gets reduced itself). However even when the last end-to-end
   session bound to that tunnel goes away, the configured tunnel session
   remains active, perhaps with a configured minimal flowspec.

   Note that it will often be appropriate to use some hysteresis in the
   adjustment of the tunnel reservation parameters, rather than
   adjusting the tunnel reservation up and down with each arriving or
   departing end-to-end reservation.  Doing this will require the tunnel
   exit router to keep track of the resources allocated to the tunnel
   (the tunnel flowspec) and the resources actually in use by end-to-end
   reservations (the sum or statistical sum of the end-to-end
   reservation flowspecs) separately.

   When an end-to-end RESV TEAR is received by Rexit, it encapsulates
   and forwards the message to Rentry. If the end-to-end session had
   created a dynamic tunnel session, then a RESV TEAR for the
   corresponding tunnel session is send by Rexit.




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


4.2.4.  Handling of End-to-End RESV Messages at Rentry.

   If the RESV message received is a refresh of an existing reservation
   then Rentry updates the reservation state and forwards the message
   upstream. On the other hand, if this is the first RESV message for
   this end-to-end session and a NODE_CHAR object with the T bit set is
   present, Rentry should initiate the mapping between this end-to-end
   session and some (possibly new) tunnel session. This mapping is based
   on some or all of the contents of the end-to-end PATH message, the
   contents of the end-to-end RESV message, and local policies. For
   example, there could be different tunnel sessions based on the
   bandwidth or delay requirements of end-to-end sessions)

   If Rentry decides that this end-to-end session should be mapped to an
   existing configured tunnel session, it binds this end-to-end session
   to that tunnel session.

   If this end-to-end RSVP session is allowed to set up a new tunnel
   session, Rentry sets up tunnel session PATH state as if it were a
   source of data by starting to send tunnel-session PATH messages to
   Rexit, which is treated as the unicast destination of the data. The
   Tspec in this new PATH message is computed from the original PATH
   message by adjusting the Tspec parameters to include the tunnel
   overhead of the encapsulation of data packets. In this case Rentry
   should also send a PATH message from the end-to-end session this time
   containing the SESSION_ASSOC object linking the two sessions. The
   receipt of this PATH message by Rexit will trigger an update of the
   end-to-end Path state which in turn will have the effect of Rexit
   sending a tunnel RESV message, allocating resources inside the
   tunnel.

   The last case is when the end-to-end session is not allowed to use
   the tunnel resources. In this case no association is created between
   this end-to-end session and a tunnel session and no new tunnel
   session is created.

   One limitation of our scheme is that the first RESV message of an
   end-to-end session determines the mapping between that end-to-end
   session and its corresponding session over the tunnel. Moreover as
   long as the reservation is active this mapping cannot change.











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


5.  Forwarding Data

   When data packets arrive at the tunnel entry point Rentry, Rentry
   must decide whether to forward the packets using the normal IP-in-IP
   tunnel encapsulation or the IP+UDP encapsulation expected by the
   tunnel session.  This decision is made by determining whether there
   is a resource reservation (not just PATH state) actually in place for
   the tunnel session bound to the arriving packet, that is, whether the
   packet matches any active filterspec.

   If a reservation is in place, it means that both Rentry and Rexit are
   RSVP-tunneling aware routers, and the data will be correctly
   decapsulated at Rexit.

   If no tunnel session reservation is in place, the data should be
   encapsulated in the tunnel's normal format, regardless of whether
   end-to-end PATH state covering the data is present.

6.  Details

6.1.  Selecting UDP port numbers

   There may be multiple end-to-end RSVP sessions between the two end
   points Rentry and Rexit. These sessions are distinguished by the
   source UDP port. Other components of the session ID, the source and
   destination IP addresses and the destination UDP port, are identical
   for all such sessions.

   The source UDP port is chosen by the tunnel entry point Rentry when
   it establishes the initial PATH state for a new tunnel session. The
   source UDP port associated with the new session is then conveyed to
   Rexit by the SESSION_ASSOC object.

   The destination UDP port used in tunnel sessions should the one
   assigned by IANA (363).

6.2.  Error Reporting

   When a tunnel session PATH message encounters an error, it is
   reported back to Rentry. Rentry must relay the error report back to
   the original source of the end-to-end session.

   When a tunnel session RESV request fails, an error message is
   returned to Rexit. Rexit must treat this as an error in crossing the
   logical link (the tunnel) and forward the error message back to the
   end host.





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


6.3.  MTU Discovery

   Since the UDP encapsulated packets should not be fragmented, tunnel
   entry routers must support tunnel MTU discovery as discussed in
   section 5.1 of [IP4INIP4]. Alternatively, the Path MTU Discovery
   mechanism discussed in RFC 2210 [RFC2210] can be used.

6.4.  Tspec and Flowspec Calculations

   As multiple End-to-End sessions can be mapped to a single tunnel
   session, there is the need to compute the aggregate Tspec of all the
   senders of those End-to-End sessions. This aggregate Tspec will the
   Tspec of the representative tunnel session. The same operation needs
   to be performed for flowspecs of End-to-End reservations arriving at
   Rexit.

   The semantics of these operations are not addressed here.  The
   simplest way to do them is to compute a sum of the end-to-end Tspecs,
   as is defined in the specifications of the Controlled-Load and
   Guaranteed services (found at [RFC2211] and [RFC2212] respectively).
   However, it may also be appropriate to compute the aggregate
   reservation level for the tunnel using a more sophisticated
   statistical or measurement-based computation.

7.  IPSEC Tunnels

   In the case where the IP-in-IP tunnel supports IPSEC (especially ESP
   in Tunnel-Mode with or without AH) then the Tunnel Session uses the
   GPI SESSION and GPI SENDER_TEMPLATE/FILTER_SPEC as defined in
   [RSVPESP] for the PATH and RESV messages.

   Data packets are not encapsulated with a UDP header since the SPI can
   be used by the intermediate nodes for classification purposes.
   Notice that user oriented keying must be used between Rentry and
   Rexit, so that different SPIs are assigned to data packets that have
   reservation and "best effort" packets, as well as packets that belong
   to different Tunnel Sessions if those are supported.

8.  RSVP Support for Multicast and Multipoint Tunnels