RFC 3209
RSVP-TE: Extensions to RSVP for LSP Tunnels
Pages: 61
Proposed Standard
→ Errata
Updated by: 3936 4420 4874 5151 5420 5711 6780 6790 7274
Proposed Standard
→ Errata
Updated by: 3936 4420 4874 5151 5420 5711 6780 6790 7274
Part 2 of 3 – Pages 17 to 43
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
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".
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.
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.
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
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.
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:
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.
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
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
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.
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
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.
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.
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.
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.
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.
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.
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
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.
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.
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:
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.
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
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.
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.)
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)