Tech-invite3GPPspaceIETFspace
96959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 3209

RSVP-TE: Extensions to RSVP for LSP Tunnels

Pages: 61
Proposed Standard
Errata
Updated by:  393644204874515154205711678067907274
Part 2 of 3 – Pages 17 to 43
First   Prev   Next

Top   ToC   RFC3209 - Page 17   prevText

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   ToC   RFC3209 - 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   ToC   RFC3209 - 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   ToC   RFC3209 - 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   ToC   RFC3209 - 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   ToC   RFC3209 - 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   ToC   RFC3209 - 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   ToC   RFC3209 - 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   ToC   RFC3209 - 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   ToC   RFC3209 - 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   ToC   RFC3209 - 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   ToC   RFC3209 - 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   ToC   RFC3209 - 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   ToC   RFC3209 - 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   ToC   RFC3209 - 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   ToC   RFC3209 - 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   ToC   RFC3209 - 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   ToC   RFC3209 - 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   ToC   RFC3209 - 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   ToC   RFC3209 - 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   ToC   RFC3209 - 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   ToC   RFC3209 - 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   ToC   RFC3209 - 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   ToC   RFC3209 - 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   ToC   RFC3209 - 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   ToC   RFC3209 - 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   ToC   RFC3209 - 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 Section