tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 3209

 
 
 

RSVP-TE: Extensions to RSVP for LSP Tunnels

Part 2 of 3, p. 17 to 43
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 17 
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:

   LABEL class = 16, C_Type = 1

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           (top label)                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The contents of a LABEL is a single label, encoded in 4 octets.  Each
   generic MPLS label is an unsigned integer in the range 0 through
   1048575.  Generic MPLS labels and FR labels are encoded right aligned
   in 4 octets.  ATM labels are encoded with the VPI right justified in
   bits 0-15 and the VCI right justified in bits 16-31.

4.1.1. Handling Label Objects in Resv messages

   In MPLS a node may support multiple label spaces, perhaps associating
   a unique space with each incoming interface.  For the purposes of the
   following discussion, the term "same label" means the identical label
   value drawn from the identical label space.  Further, the following
   applies only to unicast sessions.

   Labels received in Resv messages on different interfaces are always
   considered to be different even if the label value is the same.

4.1.1.1. Downstream

   The downstream node selects a label to represent the flow.  If a
   label range has been specified in the label request, the label MUST
   be drawn from that range.  If no label is available the node sends a
   PathErr message with an error code of "routing problem" and an error
   value of "label allocation failure".

   If a node receives a Resv message that has assigned the same label
   value to multiple senders, then that node MAY also assign a single
   value to those same senders or to any subset of those senders.  Note

Top      Up      ToC       Page 18 
   that if a node intends to police individual senders to a session, it
   MUST assign unique labels to those senders.

   In the case of ATM, one further condition applies.  Some ATM nodes
   are not capable of merging streams.  These nodes MAY indicate this by
   setting a bit in the label request to zero.  The M-bit in the
   LABEL_REQUEST object of C-Type 2, label request with ATM label range,
   serves this purpose.  The M-bit SHOULD be set by nodes which are
   merge capable.  If for any senders the M-bit is not set, the
   downstream node MUST assign unique labels to those senders.

   Once a label is allocated, the node formats a new LABEL object.  The
   node then sends the new LABEL object as part of the Resv message to
   the previous hop.  The node SHOULD be prepared to forward packets
   carrying the assigned label prior to sending the Resv message.  The
   LABEL object SHOULD be kept in the Reservation State Block.  It is
   then used in the next Resv refresh event for formatting the Resv
   message.

   A node is expected to send a Resv message before its refresh timers
   expire if the contents of the LABEL object change.

4.1.1.2. Upstream

   A node uses the label carried in the LABEL object as the outgoing
   label associated with the sender.  The router allocates a new label
   and binds it to the incoming interface of this session/sender.  This
   is the same interface that the router uses to forward Resv messages
   to the previous hops.

   Several circumstance can lead to an unacceptable label.

      1. the node is a merge incapable ATM switch but the downstream
         node has assigned the same label to two senders

      2. The implicit null label was assigned, but the node is not
         capable of doing a penultimate pop for the associated L3PID

      3. The assigned label is outside the requested label range

   In any of these events the node send a ResvErr message with an error
   code of "routing problem" and an error value of "unacceptable label
   value".

Top      Up      ToC       Page 19 
4.1.2. Non-support of the Label Object

   Under normal circumstances, a node should never receive a LABEL
   object in a Resv message unless it had included a LABEL_REQUEST
   object in the corresponding Path message.  However, an RSVP router
   that does not recognize the LABEL object sends a ResvErr with the
   error code "Unknown object class" toward the receiver.  This causes
   the reservation to fail.

4.2. Label Request Object

   The Label Request Class is 19.  Currently there are three possible
   C_Types.  Type 1 is a Label Request without label range.  Type 2 is a
   label request with an ATM label range.  Type 3 is a label request
   with a Frame Relay label range.  The LABEL_REQUEST object formats are
   shown below.

4.2.1. Label Request without Label Range

   Class = 19, C_Type = 1

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Reserved            |             L3PID             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Reserved

         This field is reserved.  It MUST be set to zero on transmission
         and MUST be ignored on receipt.

      L3PID

         an identifier of the layer 3 protocol using this path.
         Standard Ethertype values are used.

Top      Up      ToC       Page 20 
4.2.2. Label Request with ATM Label Range

   Class = 19, C_Type = 2

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Reserved            |             L3PID             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M| Res |    Minimum VPI        |      Minimum VCI              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Res  |    Maximum VPI        |      Maximum VCI              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Reserved (Res)

         This field is reserved.  It MUST be set to zero on transmission
         and MUST be ignored on receipt.

      L3PID

         an identifier of the layer 3 protocol using this path.
         Standard Ethertype values are used.

      M

         Setting this bit to one indicates that the node is capable of
         merging in the data plane

      Minimum VPI (12 bits)

         This 12 bit field specifies the lower bound of a block of
         Virtual Path Identifiers that is supported on the originating
         switch.  If the VPI is less than 12-bits it MUST be right
         justified in this field and preceding bits MUST be set to zero.

      Minimum VCI (16 bits)

         This 16 bit field specifies the lower bound of a block of
         Virtual Connection Identifiers that is supported on the
         originating switch.  If the VCI is less than 16-bits it MUST be
         right justified in this field and preceding bits MUST be set to
         zero.

Top      Up      ToC       Page 21 
      Maximum VPI (12 bits)

         This 12 bit field specifies the upper bound of a block of
         Virtual Path Identifiers that is supported on the originating
         switch.  If the VPI is less than 12-bits it MUST be right
         justified in this field and preceding bits MUST be set to zero.

      Maximum VCI (16 bits)

         This 16 bit field specifies the upper bound of a block of
         Virtual Connection Identifiers that is supported on the
         originating switch.  If the VCI is less than 16-bits it MUST be
         right justified in this field and preceding bits MUST be set to
         zero.

4.2.3. Label Request with Frame Relay Label Range

   Class = 19, C_Type = 3

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Reserved            |             L3PID             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Reserved    |DLI|                     Minimum DLCI            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Reserved        |                     Maximum DLCI            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Reserved

         This field is reserved.  It MUST be set to zero on transmission
         and ignored on receipt.

      L3PID

         an identifier of the layer 3 protocol using this path.
         Standard Ethertype values are used.

      DLI

         DLCI Length Indicator.  The number of bits in the DLCI.  The
         following values are supported:

                   Len    DLCI bits

                    0        10
                    2        23

Top      Up      ToC       Page 22 
      Minimum DLCI

         This 23-bit field specifies the lower bound of a block of Data
         Link Connection Identifiers (DLCIs) that is supported on the
         originating switch.  The DLCI MUST be right justified in this
         field and unused bits MUST be set to 0.

      Maximum DLCI

         This 23-bit field specifies the upper bound of a block of Data
         Link Connection Identifiers (DLCIs) that is supported on the
         originating switch.  The DLCI MUST be right justified in this
         field and unused bits MUST be set to 0.

4.2.4. Handling of LABEL_REQUEST

   To establish an LSP tunnel the sender creates a Path message with a
   LABEL_REQUEST object.  The LABEL_REQUEST object indicates that a
   label binding for this path is requested and provides an indication
   of the network layer protocol that is to be carried over this path.
   This permits non-IP network layer protocols to be sent down an LSP.
   This information can also be useful in actual label allocation,
   because some reserved labels are protocol specific, see [5].

   The LABEL_REQUEST SHOULD be stored in the Path State Block, so that
   Path refresh messages will also contain the LABEL_REQUEST object.
   When the Path message reaches the receiver, the presence of the
   LABEL_REQUEST object triggers the receiver to allocate a label and to
   place the label in the LABEL object for the corresponding Resv
   message.  If a label range was specified, the label MUST be allocated
   from that range.  A receiver that accepts a LABEL_REQUEST object MUST
   include a LABEL object in Resv messages pertaining to that Path
   message.  If a LABEL_REQUEST object was not present in the Path
   message, a node MUST NOT include a LABEL object in a Resv message for
   that Path message's session and PHOP.

   A node that sends a LABEL_REQUEST object MUST be ready to accept and
   correctly process a LABEL object in the corresponding Resv messages.

   A node that recognizes a LABEL_REQUEST object, but that is unable to
   support it (possibly because of a failure to allocate labels) SHOULD
   send a PathErr with the error code "Routing problem" and the error
   value "MPLS label allocation failure."  This includes the case where
   a label range has been specified and a label cannot be allocated from
   that range.

Top      Up      ToC       Page 23 
   A node which receives and forwards a Path message each with a
   LABEL_REQUEST object, MUST copy the L3PID from the received
   LABEL_REQUEST object to the forwarded LABEL_REQUEST object.

   If the receiver cannot support the protocol L3PID, it SHOULD send a
   PathErr with the error code "Routing problem" and the error value
   "Unsupported L3PID."  This causes the RSVP session to fail.

4.2.5. Non-support of the Label Request Object

   An RSVP router that does not recognize the LABEL_REQUEST object sends
   a PathErr with the error code "Unknown object class" toward the
   sender.  An RSVP router that recognizes the LABEL_REQUEST object but
   does not recognize the C_Type sends a PathErr with the error code
   "Unknown object C_Type" toward the sender.  This causes the path
   setup to fail.  The sender should notify management that a LSP cannot
   be established and possibly take action to continue the reservation
   without the LABEL_REQUEST.

   RSVP is designed to cope gracefully with non-RSVP routers anywhere
   between senders and receivers.  However, obviously, non-RSVP routers
   cannot convey labels via RSVP.  This means that if a router has a
   neighbor that is known to not be RSVP capable, the router MUST NOT
   advertise the LABEL_REQUEST object when sending messages that pass
   through the non-RSVP routers.  The router SHOULD send a PathErr back
   to the sender, with the error code "Routing problem" and the error
   value "MPLS being negotiated, but a non-RSVP capable router stands in
   the path."  This same message SHOULD be sent, if a router receives a
   LABEL_REQUEST object in a message from a non-RSVP capable router.
   See [1] for a description of how a downstream router can determine
   the presence of non-RSVP routers.

4.3. Explicit Route Object

   Explicit routes are specified via the EXPLICIT_ROUTE object (ERO).
   The Explicit Route Class is 20.  Currently one C_Type is defined,
   Type 1 Explicit Route.  The EXPLICIT_ROUTE object has the following
   format:

Top      Up      ToC       Page 24 
   Class = 20, C_Type = 1

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                        (Subobjects)                          //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Subobjects

   The contents of an EXPLICIT_ROUTE object are a series of variable-
   length data items called subobjects.  The subobjects are defined in
   section 4.3.3 below.

   If a Path message contains multiple EXPLICIT_ROUTE objects, only the
   first object is meaningful.  Subsequent EXPLICIT_ROUTE objects MAY be
   ignored and SHOULD NOT be propagated.

4.3.1. Applicability

   The EXPLICIT_ROUTE object is intended to be used only for unicast
   situations.  Applications of explicit routing to multicast are a
   topic for further research.

   The EXPLICIT_ROUTE object is to be used only when all routers along
   the explicit route support RSVP and the EXPLICIT_ROUTE object.  The
   EXPLICIT_ROUTE object is assigned a class value of the form 0bbbbbbb.
   RSVP routers that do not support the object will therefore respond
   with an "Unknown Object Class" error.

4.3.2. Semantics of the Explicit Route Object

   An explicit route is a particular path in the network topology.
   Typically, the explicit route is determined by a node, with the
   intent of directing traffic along that path.

   An explicit route is described as a list of groups of nodes along the
   explicit route.  In addition to the ability to identify specific
   nodes along the path, an explicit route can identify a group of nodes
   that must be traversed along the path.  This capability allows the
   routing system a significant amount of local flexibility in
   fulfilling a request for an explicit route.  This capability allows
   the generator of the explicit route to have imperfect information
   about the details of the path.

Top      Up      ToC       Page 25 
   The explicit route is encoded as a series of subobjects contained in
   an EXPLICIT_ROUTE object.  Each subobject identifies a group of nodes
   in the explicit route.  An explicit route is thus a specification of
   groups of nodes to be traversed.

   To formalize the discussion, we call each group of nodes an abstract
   node.  Thus, we say that an explicit route is a specification of a
   set of abstract nodes to be traversed.  If an abstract node consists
   of only one node, we refer to it as a simple abstract node.

   As an example of the concept of abstract nodes, consider an explicit
   route that consists solely of Autonomous System number subobjects.
   Each subobject corresponds to an Autonomous System in the global
   topology.  In this case, each Autonomous System is an abstract node,
   and the explicit route is a path that includes each of the specified
   Autonomous Systems.  There may be multiple hops within each
   Autonomous System, but these are opaque to the source node for the
   explicit route.

4.3.3. Subobjects

   The contents of an EXPLICIT_ROUTE object are a series of variable-
   length data items called subobjects.  Each subobject has the form:

    0                   1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------//----------------+
   |L|    Type     |     Length    | (Subobject contents)          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------//----------------+

      L

         The L bit is an attribute of the subobject.  The L bit is set
         if the subobject represents a loose hop in the explicit route.
         If the bit is not set, the subobject represents a strict hop in
         the explicit route.

      Type

         The Type indicates the type of contents of the subobject.
         Currently defined values are:

                   1   IPv4 prefix
                   2   IPv6 prefix
                  32   Autonomous system number

Top      Up      ToC       Page 26 
      Length

         The Length contains the total length of the subobject in bytes,
         including the L, Type and Length fields.  The Length MUST be at
         least 4, and MUST be a multiple of 4.

4.3.3.1. Strict and Loose Subobjects

   The L bit in the subobject is a one-bit attribute.  If the L bit is
   set, then the value of the attribute is 'loose.'  Otherwise, the
   value of the attribute is 'strict.'  For brevity, we say that if the
   value of the subobject attribute is 'loose' then it is a 'loose
   subobject.'  Otherwise, it's a 'strict subobject.'  Further, we say
   that the abstract node of a strict or loose subobject is a strict or
   a loose node, respectively.  Loose and strict nodes are always
   interpreted relative to their prior abstract nodes.

   The path between a strict node and its preceding node MUST include
   only network nodes from the strict node and its preceding abstract
   node.

   The path between a loose node and its preceding node MAY include
   other network nodes that are not part of the strict node or its
   preceding abstract node.

4.3.3.2. Subobject 1:  IPv4 prefix

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |L|    Type     |     Length    | IPv4 address (4 bytes)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | IPv4 address (continued)      | Prefix Length |      Resvd    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      L

         The L bit is an attribute of the subobject.  The L bit is set
         if the subobject represents a loose hop in the explicit route.
         If the bit is not set, the subobject represents a strict hop in
         the explicit route.

      Type

         0x01  IPv4 address

Top      Up      ToC       Page 27 
      Length

         The Length contains the total length of the subobject in bytes,
         including the Type and Length fields.  The Length is always 8.

      IPv4 address

         An IPv4 address.  This address is treated as a prefix based on
         the prefix length value below.  Bits beyond the prefix are
         ignored on receipt and SHOULD be set to zero on transmission.

      Prefix length

         Length in bits of the IPv4 prefix

      Padding

         Zero on transmission.  Ignored on receipt.

   The contents of an IPv4 prefix subobject are a 4-octet IPv4 address,
   a 1-octet prefix length, and a 1-octet pad.  The abstract node
   represented by this subobject is the set of nodes that have an IP
   address which lies within this prefix.  Note that a prefix length of
   32 indicates a single IPv4 node.

4.3.3.3. Subobject 2:  IPv6 Prefix

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |L|    Type     |     Length    | IPv6 address (16 bytes)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | IPv6 address (continued)                                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | IPv6 address (continued)                                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | IPv6 address (continued)                                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | IPv6 address (continued)      | Prefix Length |      Resvd    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      L

         The L bit is an attribute of the subobject.  The L bit is set
         if the subobject represents a loose hop in the explicit route.
         If the bit is not set, the subobject represents a strict hop in
         the explicit route.

Top      Up      ToC       Page 28 
      Type

         0x02  IPv6 address

      Length

         The Length contains the total length of the subobject in bytes,
         including the Type and Length fields.  The Length is always 20.

      IPv6 address

         An IPv6 address.  This address is treated as a prefix based on
         the prefix length value below.  Bits beyond the prefix are
         ignored on receipt and SHOULD be set to zero on transmission.

      Prefix Length

         Length in bits of the IPv6 prefix.

      Padding

         Zero on transmission.  Ignored on receipt.

   The contents of an IPv6 prefix subobject are a 16-octet IPv6 address,
   a 1-octet prefix length, and a 1-octet pad.  The abstract node
   represented by this subobject is the set of nodes that have an IP
   address which lies within this prefix.  Note that a prefix length of
   128 indicates a single IPv6 node.

4.3.3.4. Subobject 32:  Autonomous System Number

   The contents of an Autonomous System (AS) number subobject are a 2-
   octet AS number.  The abstract node represented by this subobject is
   the set of nodes belonging to the autonomous system.

   The length of the AS number subobject is 4 octets.

4.3.4. Processing of the Explicit Route Object

4.3.4.1. Selection of the Next Hop

   A node receiving a Path message containing an EXPLICIT_ROUTE object
   must determine the next hop for this path.  This is necessary because
   the next abstract node along the explicit route might be an IP subnet
   or an Autonomous System.  Therefore, selection of this next hop may
   involve a decision from a set of feasible alternatives.  The criteria
   used to make a selection from feasible alternatives is implementation
   dependent and can also be impacted by local policy, and is beyond the

Top      Up      ToC       Page 29 
   scope of this specification.  However, it is assumed that each node
   will make a best effort attempt to determine a loop-free path.  Note
   that paths so determined can be overridden by local policy.

   To determine the next hop for the path, a node performs the following
   steps:

   1) The node receiving the RSVP message MUST first evaluate the first
      subobject.  If the node is not part of the abstract node described
      by the first subobject, it has received the message in error and
      SHOULD return a "Bad initial subobject" error.  If there is no
      first subobject, the message is also in error and the system
      SHOULD return a "Bad EXPLICIT_ROUTE object" error.

   2) If there is no second subobject, this indicates the end of the
      explicit route.  The EXPLICIT_ROUTE object SHOULD be removed from
      the Path message.  This node may or may not be the end of the
      path.  Processing continues with section 4.3.4.2, where a new
      EXPLICIT_ROUTE object MAY be added to the Path message.

   3) Next, the node evaluates the second subobject.  If the node is
      also a part of the abstract node described by the second
      subobject, then the node deletes the first subobject and continues
      processing with step 2, above.  Note that this makes the second
      subobject into the first subobject of the next iteration and
      allows the node to identify the next abstract node on the path of
      the message after possible repeated application(s) of steps 2 and
      3.

   4) Abstract Node Border Case: The node determines whether it is
      topologically adjacent to the abstract node described by the
      second subobject.  If so, the node selects a particular next hop
      which is a member of the abstract node.  The node then deletes the
      first subobject and continues processing with section 4.3.4.2.

   5) Interior of the Abstract Node Case: Otherwise, the node selects a
      next hop within the abstract node of the first subobject (which
      the node belongs to) that is along the path to the abstract node
      of the second subobject (which is the next abstract node).  If no
      such path exists then there are two cases:

   5a) If the second subobject is a strict subobject, there is an error
       and the node SHOULD return a "Bad strict node" error.

   5b) Otherwise, if the second subobject is a loose subobject, the node
       selects any next hop that is along the path to the next abstract
       node.  If no path exists, there is an error, and the node SHOULD
       return a "Bad loose node" error.

Top      Up      ToC       Page 30 
   6) Finally, the node replaces the first subobject with any subobject
      that denotes an abstract node containing the next hop.  This is
      necessary so that when the explicit route is received by the next
      hop, it will be accepted.

4.3.4.2. Adding subobjects to the Explicit Route Object

   After selecting a next hop, the node MAY alter the explicit route in
   the following ways.

   If, as part of executing the algorithm in section 4.3.4.1, the

   EXPLICIT_ROUTE object is removed, the node MAY add a new
   EXPLICIT_ROUTE object.

   Otherwise, if the node is a member of the abstract node for the first
   subobject, a series of subobjects MAY be inserted before the first
   subobject or MAY replace the first subobject.  Each subobject in this
   series MUST denote an abstract node that is a subset of the current
   abstract node.

   Alternately, if the first subobject is a loose subobject, an
   arbitrary series of subobjects MAY be inserted prior to the first
   subobject.

4.3.5. Loops

   While the EXPLICIT_ROUTE object is of finite length, the existence of
   loose nodes implies that it is possible to construct forwarding loops
   during transients in the underlying routing protocol.  This can be
   detected by the originator of the explicit route through the use of
   another opaque route object called the RECORD_ROUTE object.  The
   RECORD_ROUTE object is used to collect detailed path information and
   is useful for loop detection and for diagnostics.

4.3.6. Forward Compatibility

   It is anticipated that new subobjects may be defined over time.  A
   node which encounters an unrecognized subobject during its normal ERO
   processing sends a PathErr with the error code "Routing Error" and
   error value of "Bad Explicit Route Object" toward the sender.  The
   EXPLICIT_ROUTE object is included, truncated (on the left) to the
   offending subobject.  The presence of an unrecognized subobject which
   is not encountered in a node's ERO processing SHOULD be ignored.  It
   is passed forward along with the rest of the remaining ERO stack.

Top      Up      ToC       Page 31 
4.3.7. Non-support of the Explicit Route Object

   An RSVP router that does not recognize the EXPLICIT_ROUTE object
   sends a PathErr with the error code "Unknown object class" toward the
   sender.  This causes the path setup to fail.  The sender should
   notify management that a LSP cannot be established and possibly take
   action to continue the reservation without the EXPLICIT_ROUTE or via
   a different explicit route.

4.4. Record Route Object

   Routes can be recorded via the RECORD_ROUTE object (RRO).
   Optionally, labels may also be recorded.  The Record Route Class is
   21.  Currently one C_Type is defined, Type 1 Record Route.  The
   RECORD_ROUTE object has the following format:

   Class = 21, C_Type = 1

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                        (Subobjects)                          //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Subobjects

         The contents of a RECORD_ROUTE object are a series of
         variable-length data items called subobjects.  The subobjects
         are defined in section 4.4.1 below.

   The RRO can be present in both RSVP Path and Resv messages.  If a
   Path message contains multiple RROs, only the first RRO is
   meaningful.  Subsequent RROs SHOULD be ignored and SHOULD NOT be
   propagated.  Similarly, if in a Resv message multiple RROs are
   encountered following a FILTER_SPEC before another FILTER_SPEC is
   encountered, only the first RRO is meaningful.  Subsequent RROs
   SHOULD be ignored and SHOULD NOT be propagated.

4.4.1. Subobjects

   The contents of a RECORD_ROUTE object are a series of variable-length
   data items called subobjects.  Each subobject has its own Length
   field.  The length contains the total length of the subobject in
   bytes, including the Type and Length fields.  The length MUST always
   be a multiple of 4, and at least 4.

Top      Up      ToC       Page 32 
   Subobjects are organized as a last-in-first-out stack.  The first
   subobject relative to the beginning of RRO is considered the top.
   The last subobject is considered the bottom.  When a new subobject is
   added, it is always added to the top.

   An empty RRO with no subobjects is considered illegal.

   Three kinds of subobjects are currently defined.

4.4.1.1. Subobject 1: IPv4 address

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Type     |     Length    | IPv4 address (4 bytes)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | IPv4 address (continued)      | Prefix Length |      Flags    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type

         0x01  IPv4 address

      Length

         The Length contains the total length of the subobject in bytes,
         including the Type and Length fields.  The Length is always 8.

      IPv4 address

         A 32-bit unicast, host address.  Any network-reachable
         interface address is allowed here.  Illegal addresses, such as
         certain loopback addresses, SHOULD NOT be used.

      Prefix length

         32

      Flags

         0x01  Local protection available

               Indicates that the link downstream of this node is
               protected via a local repair mechanism.  This flag can
               only be set if the Local protection flag was set in the
               SESSION_ATTRIBUTE object of the corresponding Path
               message.

Top      Up      ToC       Page 33 
         0x02  Local protection in use

               Indicates that a local repair mechanism is in use to
               maintain this tunnel (usually in the face of an outage
               of the link it was previously routed over).

4.4.1.2. Subobject 2: IPv6 address

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Type     |     Length    | IPv6 address (16 bytes)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | IPv6 address (continued)                                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | IPv6 address (continued)                                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | IPv6 address (continued)                                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | IPv6 address (continued)      | Prefix Length |      Flags    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type

         0x02  IPv6 address

      Length

         The Length contains the total length of the subobject in bytes,
         including the Type and Length fields.  The Length is always 20.

      IPv6 address

         A 128-bit unicast host address.

      Prefix length

         128

      Flags

         0x01  Local protection available

               Indicates that the link downstream of this node is
               protected via a local repair mechanism.  This flag can
               only be set if the Local protection flag was set in the
               SESSION_ATTRIBUTE object of the corresponding Path
               message.

Top      Up      ToC       Page 34 
         0x02  Local protection in use

               Indicates that a local repair mechanism is in use to
               maintain this tunnel (usually in the face of an outage
               of the link it was previously routed over).

4.4.1.3. Subobject 3, Label

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |     Length    |    Flags      |   C-Type      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Contents of Label Object                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type

         0x03  Label

      Length

         The Length contains the total length of the subobject in bytes,
         including the Type and Length fields.

      Flags

         0x01 = Global label
           This flag indicates that the label will be understood
           if received on any interface.

      C-Type

         The C-Type of the included Label Object.  Copied from the Label
         Object.

      Contents of Label Object

         The contents of the Label Object.  Copied from the Label Object

4.4.2. Applicability

   Only the procedures for use in unicast sessions are defined here.

   There are three possible uses of RRO in RSVP.  First, an RRO can
   function as a loop detection mechanism to discover L3 routing loops,
   or loops inherent in the explicit route.  The exact procedure for
   doing so is described later in this document.

Top      Up      ToC       Page 35 
   Second, an RRO collects up-to-date detailed path information hop-by-
   hop about RSVP sessions, providing valuable information to the sender
   or receiver.  Any path change (due to network topology changes) will
   be reported.

   Third, RRO syntax is designed so that, with minor changes, the whole
   object can be used as input to the EXPLICIT_ROUTE object.  This is
   useful if the sender receives RRO from the receiver in a Resv
   message, applies it to EXPLICIT_ROUTE object in the next Path message
   in order to "pin down session path".

4.4.3. Processing RRO

   Typically, a node initiates an RSVP session by adding the RRO to the
   Path message.  The initial RRO contains only one subobject - the
   sender's IP addresses.  If the node also desires label recording, it
   sets the Label_Recording flag in the SESSION_ATTRIBUTE object.

   When a Path message containing an RRO is received by an intermediate
   router, the router stores a copy of it in the Path State Block.  The
   RRO is then used in the next Path refresh event for formatting Path
   messages.  When a new Path message is to be sent, the router adds a
   new subobject to the RRO and appends the resulting RRO to the Path
   message before transmission.

   The newly added subobject MUST be this router's IP address.  The
   address to be added SHOULD be the interface address of the outgoing
   Path messages.  If there are multiple addresses to choose from, the
   decision is a local matter.  However, it is RECOMMENDED that the same
   address be chosen consistently.

   When the Label_Recording flag is set in the SESSION_ATTRIBUTE object,
   nodes doing route recording SHOULD include a Label Record subobject.
   If the node is using a global label space, then it SHOULD set the
   Global Label flag.

   The Label Record subobject is pushed onto the RECORD_ROUTE object
   prior to pushing on the node's IP address.  A node MUST NOT push on a
   Label Record subobject without also pushing on an IPv4 or IPv6
   subobject.

   Note that on receipt of the initial Path message, a node is unlikely
   to have a label to include.  Once a label is obtained, the node
   SHOULD include the label in the RRO in the next Path refresh event.

   If the newly added subobject causes the RRO to be too big to fit in a
   Path (or Resv) message, the RRO object SHALL be dropped from the
   message and message processing continues as normal.  A PathErr (or

Top      Up      ToC       Page 36 
   ResvErr) message SHOULD be sent back to the sender (or receiver).  An
   error code of "Notify" and an error value of "RRO too large for MTU"
   is used.  If the receiver receives such a ResvErr, it SHOULD send a
   PathErr message with error code of "Notify" and an error value of
   "RRO notification".

   A sender receiving either of these error values SHOULD remove the RRO
   from the Path message.

   Nodes SHOULD resend the above PathErr or ResvErr message each n
   seconds where n is the greater of 15 and the refresh interval for the
   associated Path or RESV message.  The node MAY apply limits and/or
   back-off timers to limit the number of messages sent.

   An RSVP router can decide to send Path messages before its refresh
   time if the RRO in the next Path message is different from the
   previous one.  This can happen if the contents of the RRO received
   from the previous hop router changes or if this RRO is newly added to
   (or deleted from) the Path message.

   When the destination node of an RSVP session receives a Path message
   with an RRO, this indicates that the sender node needs route
   recording.  The destination node initiates the RRO process by adding
   an RRO to Resv messages.  The processing mirrors that of the Path
   messages.  The only difference is that the RRO in a Resv message
   records the path information in the reverse direction.

   Note that each node along the path will now have the complete route
   from source to destination.  The Path RRO will have the route from
   the source to this node; the Resv RRO will have the route from this
   node to the destination.  This is useful for network management.

   A received Path message without an RRO indicates that the sender node
   no longer needs route recording.  Subsequent Resv messages SHALL NOT
   contain an RRO.

4.4.4. Loop Detection

   As part of processing an incoming RRO, an intermediate router looks
   into all subobjects contained within the RRO.  If the router
   determines that it is already in the list, a forwarding loop exists.

   An RSVP session is loop-free if downstream nodes receive Path
   messages or upstream nodes receive Resv messages with no routing
   loops detected in the contained RRO.

Top      Up      ToC       Page 37 
   There are two broad classifications of forwarding loops.  The first
   class is the transient loop, which occurs as a normal part of
   operations as L3 routing tries to converge on a consistent forwarding
   path for all destinations.  The second class of forwarding loop is
   the permanent loop, which normally results from network mis-
   configuration.

   The action performed by a node on receipt of an RRO depends on the
   message type in which the RRO is received.

   For Path messages containing a forwarding loop, the router builds and
   sends a "Routing problem" PathErr message, with the error value "loop
   detected," and drops the Path message.  Until the loop is eliminated,
   this session is not suitable for forwarding data packets.  How the
   loop eliminated is beyond the scope of this document.

   For Resv messages containing a forwarding loop, the router simply
   drops the message.  Resv messages should not loop if Path messages do
   not loop.

4.4.5. Forward Compatibility

   New subobjects may be defined for the RRO.  When processing an RRO,
   unrecognized subobjects SHOULD be ignored and passed on.  When
   processing an RRO for loop detection, a node SHOULD parse over any
   unrecognized objects.  Loop detection works by detecting subobjects
   which were inserted by the node itself on an earlier pass of the
   object.  This ensures that the subobjects necessary for loop
   detection are always understood.

4.4.6. Non-support of RRO

   The RRO object is to be used only when all routers along the path
   support RSVP and the RRO object.  The RRO object is assigned a class
   value of the form 0bbbbbbb.  RSVP routers that do not support the
   object will therefore respond with an "Unknown Object Class" error.

4.5. Error Codes for ERO and RRO

   In the processing described above, certain errors must be reported as
   either a "Routing Problem" or "Notify".  The value of the "Routing
   Problem" error code is 24; the value of the "Notify" error code is
   25.

Top      Up      ToC       Page 38 
   The following defines error values for the Routing Problem Error
   Code:

      Value    Error:

         1     Bad EXPLICIT_ROUTE object

         2     Bad strict node

         3     Bad loose node

         4     Bad initial subobject

         5     No route available toward destination

         6     Unacceptable label value

         7     RRO indicated routing loops

         8     MPLS being negotiated, but a non-RSVP-capable router
               stands in the path

         9     MPLS label allocation failure

        10     Unsupported L3PID

   For the Notify Error Code, the 16 bits of the Error Value field are:

         ss00 cccc cccc cccc

   The high order bits are as defined under Error Code 1. (See [1]).

   When ss = 00, the following subcodes are defined:

         1    RRO too large for MTU

         2    RRO notification

         3    Tunnel locally repaired

4.6. Session, Sender Template, and Filter Spec Objects

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

   The LSP_TUNNEL objects have the following format:

Top      Up      ToC       Page 39 
4.6.1. Session Object

4.6.1.1. LSP_TUNNEL_IPv4 Session Object

   Class = SESSION, LSP_TUNNEL_IPv4 C-Type = 7

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   IPv4 tunnel end point address               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  MUST be zero                 |      Tunnel ID                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Extended Tunnel ID                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      IPv4 tunnel end point address

         IPv4 address of the egress node for the tunnel.

      Tunnel ID

         A 16-bit identifier used in the SESSION that remains constant
         over the life of the tunnel.

      Extended Tunnel ID

         A 32-bit identifier used in the SESSION that remains constant
         over the life of the tunnel.  Normally set to all zeros.
         Ingress nodes that wish to narrow the scope of a SESSION to the
         ingress-egress pair may place their IPv4 address here as a
         globally unique identifier.

Top      Up      ToC       Page 40 
4.6.1.2. LSP_TUNNEL_IPv6 Session Object

   Class = SESSION, LSP_TUNNEL_IPv6 C_Type = 8

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                   IPv6 tunnel end point address               |
   +                                                               +
   |                            (16 bytes)                         |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  MUST be zero                 |      Tunnel ID                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                       Extended Tunnel ID                      |
   +                                                               +
   |                            (16 bytes)                         |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      IPv6 tunnel end point address

         IPv6 address of the egress node for the tunnel.

      Tunnel ID

         A 16-bit identifier used in the SESSION that remains constant
         over the life of the tunnel.

      Extended Tunnel ID

         A 16-byte identifier used in the SESSION that remains constant
         over the life of the tunnel.  Normally set to all zeros.
         Ingress nodes that wish to narrow the scope of a SESSION to the
         ingress-egress pair may place their IPv6 address here as a
         globally unique identifier.

4.6.2. Sender Template Object

4.6.2.1. LSP_TUNNEL_IPv4 Sender Template Object

   Class = SENDER_TEMPLATE, LSP_TUNNEL_IPv4 C-Type = 7

Top      Up      ToC       Page 41 
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   IPv4 tunnel sender address                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  MUST be zero                 |            LSP ID             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      IPv4 tunnel sender address

         IPv4 address for a sender node

      LSP ID

         A 16-bit identifier used in the SENDER_TEMPLATE and the
         FILTER_SPEC that can be changed to allow a sender to share
         resources with itself.

4.6.2.2. LSP_TUNNEL_IPv6 Sender Template Object

   Class = SENDER_TEMPLATE, LSP_TUNNEL_IPv6 C_Type = 8

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                   IPv6 tunnel sender address                  |
   +                                                               +
   |                            (16 bytes)                         |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  MUST be zero                 |            LSP ID             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      IPv6 tunnel sender address

         IPv6 address for a sender node

      LSP ID

         A 16-bit identifier used in the SENDER_TEMPLATE and the
         FILTER_SPEC that can be changed to allow a sender to share
         resources with itself.

Top      Up      ToC       Page 42 
4.6.3. Filter Specification Object

4.6.3.1. LSP_TUNNEL_IPv4 Filter Specification Object

      Class = FILTER SPECIFICATION, LSP_TUNNEL_IPv4 C-Type = 7

   The format of the LSP_TUNNEL_IPv4 FILTER_SPEC object is identical to
   the LSP_TUNNEL_IPv4 SENDER_TEMPLATE object.

4.6.3.2. LSP_TUNNEL_IPv6 Filter Specification Object

      Class = FILTER SPECIFICATION, LSP_TUNNEL_IPv6 C_Type = 8

   The format of the LSP_TUNNEL_IPv6 FILTER_SPEC object is identical to
   the LSP_TUNNEL_IPv6 SENDER_TEMPLATE object.

4.6.4. Reroute and Bandwidth Increase Procedure

   This section describes how to setup a tunnel that is capable of
   maintaining resource reservations (without double counting) while it
   is being rerouted or while it is attempting to increase its
   bandwidth.  In the initial Path message, the ingress node forms a
   SESSION object, assigns a Tunnel_ID, and places its IPv4 address in
   the Extended_Tunnel_ID.  It also forms a SENDER_TEMPLATE and assigns
   a LSP_ID.  Tunnel setup then proceeds according to the normal
   procedure.

   On receipt of the Path message, the egress node sends a Resv message
   with the STYLE Shared Explicit toward the ingress node.

   When an ingress node with an established path wants to change that
   path, it forms a new Path message as follows.  The existing SESSION
   object is used.  In particular the Tunnel_ID and Extended_Tunnel_ID
   are unchanged.  The ingress node picks a new LSP_ID to form a new
   SENDER_TEMPLATE.  It creates an EXPLICIT_ROUTE object for the new
   route.  The new Path message is sent.  The ingress node refreshes
   both the old and new path messages.

   The egress node responds with a Resv message with an SE flow
   descriptor formatted as:

      <FLOWSPEC><old_FILTER_SPEC><old_LABEL_OBJECT><new_FILTER_SPEC>
      <new_LABEL_OBJECT>

   (Note that if the PHOPs are different, then two messages are sent
   each with the appropriate FILTER_SPEC and LABEL_OBJECT.)

Top      Up      ToC       Page 43 
   When the ingress node receives the Resv Message(s), it may begin
   using the new route.  It SHOULD send a PathTear message for the old
   route.



(page 43 continued on part 3)

Next RFC Part