rfc3209.txt

RFC 的详细文档！

   of these cases a common label may be assigned.








Awduche, et al.             Standards Track                    [Page 11]

RFC 3209           Extensions to RSVP for LSP Tunnels      December 2001


   Path messages from different senders can each carry their own ERO,
   and the paths taken by the senders can converge and diverge at any
   point in the network topology.  When Path messages have differing
   EXPLICIT_ROUTE objects, separate LSPs for each EXPLICIT_ROUTE object
   must be established.

2.5. Rerouting Traffic Engineered Tunnels

   One of the requirements for Traffic Engineering is the capability to
   reroute an established TE tunnel under a number of conditions, based
   on administrative policy.  For example, in some contexts, an
   administrative policy may dictate that a given TE tunnel is to be
   rerouted when a more "optimal" route becomes available.  Another
   important context when TE tunnel reroute is usually required is upon
   failure of a resource along the TE tunnel's established path.  Under
   some policies, it may also be necessary to return the TE tunnel to
   its original path when the failed resource becomes re-activated.

   In general, it is highly desirable not to disrupt traffic, or
   adversely impact network operations while TE tunnel rerouting is in
   progress.  This adaptive and smooth rerouting requirement
   necessitates establishing a new LSP tunnel and transferring traffic
   from the old LSP tunnel onto it before tearing down the old LSP
   tunnel.  This concept is called "make-before-break." A problem can
   arise because the old and new LSP tunnels might compete with each
   other for resources on network segments which they have in common.
   Depending on availability of resources, this competition can cause
   Admission Control to prevent the new LSP tunnel from being
   established.  An advantage of using RSVP to establish LSP tunnels is
   that it solves this problem very elegantly.

   To support make-before-break in a smooth fashion, it is necessary
   that on links that are common to the old and new LSPs, resources used
   by the old LSP tunnel should not be released before traffic is
   transitioned to the new LSP tunnel, and reservations should not be
   counted twice because this might cause Admission Control to reject
   the new LSP tunnel.

   A similar situation can arise when one wants to increase the
   bandwidth of a TE tunnel.  The new reservation will be for the full
   amount needed, but the actual allocation needed is only the delta
   between the new and old bandwidth.  If policy is being applied to
   PATH messages by intermediate nodes, then a PATH message requesting
   too much bandwidth will be rejected.  In this situation simply
   increasing the bandwidth request without changing the
   SENDER_TEMPLATE, could result in a tunnel being torn down, depending
   upon local policy.




Awduche, et al.             Standards Track                    [Page 12]

RFC 3209           Extensions to RSVP for LSP Tunnels      December 2001


   The combination of the LSP_TUNNEL SESSION object and the SE
   reservation style naturally accommodates smooth transitions in
   bandwidth and routing.  The idea is that the old and new LSP tunnels
   share resources along links which they have in common.  The
   LSP_TUNNEL SESSION object is used to narrow the scope of the RSVP
   session to the particular TE tunnel in question.  To uniquely
   identify a TE tunnel, we use the combination of the destination IP
   address (an address of the node which is the egress of the tunnel), a
   Tunnel ID, and the tunnel ingress node's IP address, which is placed
   in the Extended Tunnel ID field.

   During the reroute or bandwidth-increase operation, the tunnel
   ingress needs to appear as two different senders to the RSVP session.
   This is achieved by the inclusion of the "LSP ID", which is carried
   in the SENDER_TEMPLATE and FILTER_SPEC objects.  Since the semantics
   of these objects are changed, a new C-Types are assigned.

   To effect a reroute, the ingress node picks a new LSP ID and forms a
   new SENDER_TEMPLATE.  The ingress node then creates a new ERO to
   define the new path.  Thereafter the node sends a new Path Message
   using the original SESSION object and the new SENDER_TEMPLATE and
   ERO.  It continues to use the old LSP and refresh the old Path
   message.  On links that are not held in common, the new Path message
   is treated as a conventional new LSP tunnel setup.  On links held in
   common, the shared SESSION object and SE style allow the LSP to be
   established sharing resources with the old LSP.  Once the ingress
   node receives a Resv message for the new LSP, it can transition
   traffic to it and tear down the old LSP.

   To effect a bandwidth-increase, a new Path Message with a new LSP_ID
   can be used to attempt a larger bandwidth reservation while the
   current LSP_ID continues to be refreshed to ensure that the
   reservation is not lost if the larger reservation fails.

2.6. Path MTU

   Standard RSVP [1] and Int-Serv [11] provide the RSVP sender with the
   minimum MTU available between the sender and the receiver.  This path
   MTU identification capability is also provided for LSPs established
   via RSVP.

   Path MTU information is carried, depending on which is present, in
   the Integrated Services or Null Service objects.  When using
   Integrated Services objects, path MTU is provided based on the
   procedures defined in [11].  Path MTU identification when using Null
   Service objects is defined in [16].





Awduche, et al.             Standards Track                    [Page 13]

RFC 3209           Extensions to RSVP for LSP Tunnels      December 2001


   With standard RSVP, the path MTU information is used by the sender to
   check which IP packets exceed the path MTU.  For packets that exceed
   the path MTU, the sender either fragments the packets or, when the IP
   datagram has the "Don't Fragment" bit set, issues an ICMP destination
   unreachable message.  This path MTU related handling is also required
   for LSPs established via RSVP.

   The following algorithm applies to all unlabeled IP datagrams and to
   any labeled packets which the node knows to be IP datagrams, to which
   labels need to be added before forwarding.  For labeled packets the
   bottom of stack is found, the IP header examined.

   Using the terminology defined in [5], an LSR MUST execute the
   following algorithm:

   1. Let N be the number of bytes in the label stack (i.e, 4 times the
      number of label stack entries) including labels to be added by
      this node.

   2. Let M be the smaller of the "Maximum Initially Labeled IP Datagram
      Size" or of (Path MTU - N).

   When the size of an IPv4 datagram (without labels) exceeds the value
      of M,

      If the DF bit is not set in the IPv4 header, then

         (a) the datagram MUST be broken into fragments, each of whose
             size is no greater than M, and

         (b) each fragment MUST be labeled and then forwarded.

      If the DF bit is set in the IPv4 header, then

         (a) the datagram MUST NOT be forwarded

         (b) Create an ICMP Destination Unreachable Message:

              i. set its Code field [12] to "Fragmentation Required and
                 DF Set",
             ii. set its Next-Hop MTU field [13] to M

         (c) If possible, transmit the ICMP Destination Unreachable
             Message to the source of the of the discarded datagram.

      When the size of an IPv6 datagram (without labels) exceeds the
             value of M,




Awduche, et al.             Standards Track                    [Page 14]

RFC 3209           Extensions to RSVP for LSP Tunnels      December 2001


         (a) the datagram MUST NOT be forwarded

         (b) Create an ICMP Packet too Big Message with the Next-Hop
             link MTU field [14] set to M

         (c) If possible, transmit the ICMP Packet too Big Message to
             the source of the of the discarded datagram.

3. LSP Tunnel related Message Formats

   Five new objects are defined in this section:

      Object name          Applicable RSVP messages
      ---------------      ------------------------
      LABEL_REQUEST          Path
      LABEL                  Resv
      EXPLICIT_ROUTE         Path
      RECORD_ROUTE           Path, Resv
      SESSION_ATTRIBUTE      Path

   New C-Types are also assigned for the SESSION, SENDER_TEMPLATE, and
   FILTER_SPEC, objects.

   Detailed descriptions of the new objects are given in later sections.
   All new objects are OPTIONAL with respect to RSVP.  An implementation
   can choose to support a subset of objects.  However, the
   LABEL_REQUEST and LABEL objects are mandatory with respect to this
   specification.

   The LABEL and RECORD_ROUTE objects, are sender specific.  In Resv
   messages they MUST appear after the associated FILTER_SPEC and prior
   to any subsequent FILTER_SPEC.

   The relative placement of EXPLICIT_ROUTE, LABEL_REQUEST, and
   SESSION_ATTRIBUTE objects is simply a recommendation.  The ordering
   of these objects is not important, so an implementation MUST be
   prepared to accept objects in any order.

3.1. Path Message

   The format of the Path message is as follows:

      <Path Message> ::=       <Common Header> [ <INTEGRITY> ]
                               <SESSION> <RSVP_HOP>
                               <TIME_VALUES>
                               [ <EXPLICIT_ROUTE> ]
                               <LABEL_REQUEST>
                               [ <SESSION_ATTRIBUTE> ]



Awduche, et al.             Standards Track                    [Page 15]

RFC 3209           Extensions to RSVP for LSP Tunnels      December 2001


                               [ <POLICY_DATA> ... ]
                               <sender descriptor>

      <sender descriptor> ::=  <SENDER_TEMPLATE> <SENDER_TSPEC>
                               [ <ADSPEC> ]
                               [ <RECORD_ROUTE> ]

3.2. Resv Message

   The format of the Resv message is as follows:

      <Resv Message> ::=       <Common Header> [ <INTEGRITY> ]
                               <SESSION>  <RSVP_HOP>
                               <TIME_VALUES>
                               [ <RESV_CONFIRM> ]  [ <SCOPE> ]
                               [ <POLICY_DATA> ... ]
                               <STYLE> <flow descriptor list>

      <flow descriptor list> ::= <FF flow descriptor list>
                               | <SE flow descriptor>


      <FF flow descriptor list> ::= <FLOWSPEC> <FILTER_SPEC>
                               <LABEL> [ <RECORD_ROUTE> ]
                               | <FF flow descriptor list>
                               <FF flow descriptor>

      <FF flow descriptor> ::= [ <FLOWSPEC> ] <FILTER_SPEC> <LABEL>
                               [ <RECORD_ROUTE> ]

      <SE flow descriptor> ::= <FLOWSPEC> <SE filter spec list>

      <SE filter spec list> ::= <SE filter spec>
                               | <SE filter spec list> <SE filter spec>

      <SE filter spec> ::=     <FILTER_SPEC> <LABEL> [ <RECORD_ROUTE> ]

      Note:  LABEL and RECORD_ROUTE (if present), are bound to the
             preceding FILTER_SPEC.  No more than one LABEL and/or
             RECORD_ROUTE may follow each FILTER_SPEC.











Awduche, et al.             Standards Track                    [Page 16]

RFC 3209           Extensions to RSVP for LSP Tunnels      December 2001


4. LSP Tunnel related Objects

4.1. Label Object

   Labels MAY be carried in Resv messages.  For the FF and SE styles, a
   label is associated with each sender.  The label for a sender MUST
   immediately follow the FILTER_SPEC for that sender in the Resv
   message.

   The LABEL object has the following format: