rfc3209.txt

RFC 的详细文档！

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC2119 [6].

   The reader is assumed to be familiar with the terminology in [1], [2]
   and [3].

   Abstract Node

      A group of nodes whose internal topology is opaque to the ingress
      node of the LSP.  An abstract node is said to be simple if it
      contains only one physical node.

   Explicitly Routed LSP

      An LSP whose path is established by a means other than normal IP
      routing.

   Label Switched Path

      The path created by the concatenation of one or more label
      switched hops, allowing a packet to be forwarded by swapping
      labels from an MPLS node to another MPLS node.  For a more precise
      definition see [2].

   LSP

      A Label Switched Path




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


   LSP Tunnel

      An LSP which is used to tunnel below normal IP routing and/or
      filtering mechanisms.

   Traffic Engineered Tunnel (TE Tunnel)

      A set of one or more LSP Tunnels which carries a traffic trunk.

   Traffic Trunk

      A set of flows aggregated by their service class and then placed
      on an LSP or set of LSPs called a traffic engineered tunnel.  For
      further discussion see [3].

2. Overview

2.1. LSP Tunnels and Traffic Engineered Tunnels

   According to [1], "RSVP defines a 'session' to be a data flow with a
   particular destination and transport-layer protocol." However, when
   RSVP and MPLS are combined, a flow or session can be defined with
   greater flexibility and generality.  The ingress node of an LSP can
   use a variety of means to determine which packets are assigned a
   particular label.  Once a label is assigned to a set of packets, the
   label effectively defines the "flow" through the LSP.  We refer to
   such an LSP as an "LSP tunnel" because the traffic through it is
   opaque to intermediate nodes along the label switched path.

   New RSVP SESSION, SENDER_TEMPLATE, and FILTER_SPEC objects, called
   LSP_TUNNEL_IPv4 and LSP_TUNNEL_IPv6 have been defined to support the
   LSP tunnel feature.  The semantics of these objects, from the
   perspective of a node along the label switched path, is that traffic
   belonging to the LSP tunnel is identified solely on the basis of
   packets arriving from the PHOP or "previous hop" (see [1]) with the
   particular label value(s) assigned by this node to upstream senders
   to the session.  In fact, the IPv4(v6) that appears in the object
   name only denotes that the destination address is an IPv4(v6)
   address.  When we refer to these objects generically, we use the
   qualifier LSP_TUNNEL.

   In some applications it is useful to associate sets of LSP tunnels.
   This can be useful during reroute operations or to spread a traffic
   trunk over multiple paths.  In the traffic engineering application
   such sets are called traffic engineered tunnels (TE tunnels).  To
   enable the identification and association of such LSP tunnels, two
   identifiers are carried.  A tunnel ID is part of the SESSION object.
   The SESSION object uniquely defines a traffic engineered tunnel.  The



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


   SENDER_TEMPLATE and FILTER_SPEC objects carry an LSP ID.  The
   SENDER_TEMPLATE (or FILTER_SPEC) object together with the SESSION
   object uniquely identifies an LSP tunnel

2.2. Operation of LSP Tunnels

   This section summarizes some of the features supported by RSVP as
   extended by this document related to the operation of LSP tunnels.
   These include: (1) the capability to establish LSP tunnels with or
   without QoS requirements, (2) the capability to dynamically reroute
   an established LSP tunnel, (3) the capability to observe the actual
   route traversed by an established LSP tunnel, (4) the capability to
   identify and diagnose LSP tunnels, (5) the capability to preempt an
   established LSP tunnel under administrative policy control, and (6)
   the capability to perform downstream-on-demand label allocation,
   distribution, and binding.  In the following paragraphs, these
   features are briefly described.  More detailed descriptions can be
   found in subsequent sections of this document.

   To create an LSP tunnel, the first MPLS node on the path -- that is,
   the sender node with respect to the path -- creates an RSVP Path
   message with a session type of LSP_TUNNEL_IPv4 or LSP_TUNNEL_IPv6 and
   inserts a LABEL_REQUEST object into the Path message.  The
   LABEL_REQUEST object indicates that a label binding for this path is
   requested and also provides an indication of the network layer
   protocol that is to be carried over this path.  The reason for this
   is that the network layer protocol sent down an LSP cannot be assumed
   to be IP and cannot be deduced from the L2 header, which simply
   identifies the higher layer protocol as MPLS.

   If the sender node has knowledge of a route that has high likelihood
   of meeting the tunnel's QoS requirements, or that makes efficient use
   of network resources, or that satisfies some policy criteria, the
   node can decide to use the route for some or all of its sessions.  To
   do this, the sender node adds an EXPLICIT_ROUTE object to the RSVP
   Path message.  The EXPLICIT_ROUTE object specifies the route as a
   sequence of abstract nodes.

   If, after a session has been successfully established, the sender
   node discovers a better route, the sender can dynamically reroute the
   session by simply changing the EXPLICIT_ROUTE object.  If problems
   are encountered with an EXPLICIT_ROUTE object, either because it
   causes a routing loop or because some intermediate routers do not
   support it, the sender node is notified.

   By adding a RECORD_ROUTE object to the Path message, the sender node
   can receive information about the actual route that the LSP tunnel
   traverses.  The sender node can also use this object to request



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


   notification from the network concerning changes to the routing path.
   The RECORD_ROUTE object is analogous to a path vector, and hence can
   be used for loop detection.

   Finally, a SESSION_ATTRIBUTE object can be added to Path messages to
   aid in session identification and diagnostics.  Additional control
   information, such as setup and hold priorities, resource affinities
   (see [3]), and local-protection, are also included in this object.

   Routers along the path may use the setup and hold priorities along
   with SENDER_TSPEC and any POLICY_DATA objects contained in Path
   messages as input to policy control.  For instance, in the traffic
   engineering application, it is very useful to use the Path message as
   a means of verifying that bandwidth exists at a particular priority
   along an entire path before preempting any lower priority
   reservations.  If a Path message is allowed to progress when there
   are insufficient resources, then there is a danger that lower
   priority reservations downstream of this point will unnecessarily be
   preempted in a futile attempt to service this request.

   When the EXPLICIT_ROUTE object (ERO) is present, the Path message is
   forwarded towards its destination along a path specified by the ERO.
   Each node along the path records the ERO in its path state block.
   Nodes may also modify the ERO before forwarding the Path message.  In
   this case the modified ERO SHOULD be stored in the path state block
   in addition to the received ERO.

   The LABEL_REQUEST object requests intermediate routers and receiver
   nodes to provide a label binding for the session.  If a node is
   incapable of providing a label binding, it sends a PathErr message
   with an "unknown object class" error.  If the LABEL_REQUEST object is
   not supported end to end, the sender node will be notified by the
   first node which does not provide this support.

   The destination node of a label-switched path responds to a
   LABEL_REQUEST by including a LABEL object in its response RSVP Resv
   message.  The LABEL object is inserted in the filter spec list
   immediately following the filter spec to which it pertains.

   The Resv message is sent back upstream towards the sender, following
   the path state created by the Path message, in reverse order.  Note
   that if the path state was created by use of an ERO, then the Resv
   message will follow the reverse path of the ERO.

   Each node that receives a Resv message containing a LABEL object uses
   that label for outgoing traffic associated with this LSP tunnel.  If
   the node is not the sender, it allocates a new label and places that
   label in the corresponding LABEL object of the Resv message which it



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


   sends upstream to the PHOP.  The label sent upstream in the LABEL
   object is the label which this node will use to identify incoming
   traffic associated with this LSP tunnel.  This label also serves as
   shorthand for the Filter Spec.  The node can now update its "Incoming
   Label Map" (ILM), which is used to map incoming labeled packets to a
   "Next Hop Label Forwarding Entry" (NHLFE), see [2].

   When the Resv message propagates upstream to the sender node, a
   label-switched path is effectively established.

2.3. Service Classes

   This document does not restrict the type of Integrated Service
   requests for reservations.  However, an implementation SHOULD support
   the Controlled-Load service [4] and the Null Service [16].

2.4. Reservation Styles

   The receiver node can select from among a set of possible reservation
   styles for each session, and each RSVP session must have a particular
   style.  Senders have no influence on the choice of reservation style.
   The receiver can choose different reservation styles for different
   LSPs.

   An RSVP session can result in one or more LSPs, depending on the
   reservation style chosen.

   Some reservation styles, such as FF, dedicate a particular
   reservation to an individual sender node.  Other reservation styles,
   such as WF and SE, can share a reservation among several sender
   nodes.  The following sections discuss the different reservation
   styles and their advantages and disadvantages.  A more detailed
   discussion of reservation styles can be found in [1].

2.4.1. Fixed Filter (FF) Style

   The Fixed Filter (FF) reservation style creates a distinct
   reservation for traffic from each sender that is not shared by other
   senders.  This style is common for applications in which traffic from
   each sender is likely to be concurrent and independent.  The total
   amount of reserved bandwidth on a link for sessions using FF is the
   sum of the reservations for the individual senders.

   Because each sender has its own reservation, a unique label is
   assigned to each sender.  This can result in a point-to-point LSP
   between every sender/receiver pair.





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


2.4.2. Wildcard Filter (WF) Style

   With the Wildcard Filter (WF) reservation style, a single shared
   reservation is used for all senders to a session.  The total
   reservation on a link remains the same regardless of the number of
   senders.

   A single multipoint-to-point label-switched-path is created for all
   senders to the session.  On links that senders to the session share,
   a single label value is allocated to the session.  If there is only
   one sender, the LSP looks like a normal point-to-point connection.
   When multiple senders are present, a multipoint-to-point LSP (a
   reversed tree) is created.

   This style is useful for applications in which not all senders send
   traffic at the same time.  A phone conference, for example, is an
   application where not all speakers talk at the same time.  If,
   however, all senders send simultaneously, then there is no means of
   getting the proper reservations made.  Either the reserved bandwidth
   on links close to the destination will be less than what is required
   or then the reserved bandwidth on links close to some senders will be
   greater than what is required.  This restricts the applicability of
   WF for traffic engineering purposes.

   Furthermore, because of the merging rules of WF, EXPLICIT_ROUTE
   objects cannot be used with WF reservations.  As a result of this
   issue and the lack of applicability to traffic engineering, use of WF
   is not considered in this document.

2.4.3. Shared Explicit (SE) Style

   The Shared Explicit (SE) style allows a receiver to explicitly
   specify the senders to be included in a reservation.  There is a
   single reservation on a link for all the senders listed.  Because
   each sender is explicitly listed in the Resv message, different
   labels may be assigned to different senders, thereby creating
   separate LSPs.

   SE style reservations can be provided using multipoint-to-point
   label-switched-path or LSP per sender.  Multipoint-to-point LSPs may
   be used when path messages do not carry the EXPLICIT_ROUTE object, or
   when Path messages have identical EXPLICIT_ROUTE objects.  In either