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.
4.7. Session Attribute Object
The Session Attribute Class is 207. Two C_Types are defined,
LSP_TUNNEL, C-Type = 7 and LSP_TUNNEL_RA, C-Type = 1. The
LSP_TUNNEL_RA C-Type includes all the same fields as the LSP_TUNNEL
C-Type. Additionally it carries resource affinity information. The
formats are as follows:
4.7.1. Format without resource affinities
SESSION_ATTRIBUTE class = 207, LSP_TUNNEL 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Setup Prio | Holding Prio | Flags | Name Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Session Name (NULL padded display string) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Setup Priority
The priority of the session with respect to taking resources,
in the range of 0 to 7. The value 0 is the highest priority.
The Setup Priority is used in deciding whether this session can
preempt another session.
Holding Priority
The priority of the session with respect to holding resources,
in the range of 0 to 7. The value 0 is the highest priority.
Holding Priority is used in deciding whether this session can
be preempted by another session.
Flags
0x01 Local protection desired
This flag permits transit routers to use a local repair
mechanism which may result in violation of the explicit
route object. When a fault is detected on an adjacent
downstream link or node, a transit router can reroute
traffic for fast service restoration.
0x02 Label recording desired
This flag indicates that label information should be
included when doing a route record.
0x04 SE Style desired
This flag indicates that the tunnel ingress node may
choose to reroute this tunnel without tearing it down.
A tunnel egress node SHOULD use the SE Style when
responding with a Resv message.
Name Length
The length of the display string before padding, in bytes.
Session Name
A null padded string of characters.
4.7.2. Format with resource affinities
SESSION_ATTRIBUTE class = 207, LSP_TUNNEL_RA 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Exclude-any |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Include-any |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Include-all |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Setup Prio | Holding Prio | Flags | Name Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Session Name (NULL padded display string) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Exclude-any
A 32-bit vector representing a set of attribute filters
associated with a tunnel any of which renders a link
unacceptable.
Include-any
A 32-bit vector representing a set of attribute filters
associated with a tunnel any of which renders a link acceptable
(with respect to this test). A null set (all bits set to zero)
automatically passes.
Include-all
A 32-bit vector representing a set of attribute filters
associated with a tunnel all of which must be present for a
link to be acceptable (with respect to this test). A null set
(all bits set to zero) automatically passes.
Setup Priority
The priority of the session with respect to taking resources,
in the range of 0 to 7. The value 0 is the highest priority.
The Setup Priority is used in deciding whether this session can
preempt another session.
Holding Priority
The priority of the session with respect to holding resources,
in the range of 0 to 7. The value 0 is the highest priority.
Holding Priority is used in deciding whether this session can
be preempted by another session.
Flags
0x01 Local protection desired
This flag permits transit routers to use a local repair
mechanism which may result in violation of the explicit
route object. When a fault is detected on an adjacent
downstream link or node, a transit router can reroute
traffic for fast service restoration.
0x02 Label recording desired
This flag indicates that label information should be
included when doing a route record.
0x04 SE Style desired
This flag indicates that the tunnel ingress node may
choose to reroute this tunnel without tearing it down.
A tunnel egress node SHOULD use the SE Style when
responding with a Resv message.
Name Length
The length of the display string before padding, in bytes.
Session Name
A null padded string of characters.
4.7.3. Procedures applying to both C-Types
The support of setup and holding priorities is OPTIONAL. A node can
recognize this information but be unable to perform the requested
operation. The node SHOULD pass the information downstream
unchanged.
As noted above, preemption is implemented by two priorities. The
Setup Priority is the priority for taking resources. The Holding
Priority is the priority for holding a resource. Specifically, the
Holding Priority is the priority at which resources assigned to this
session will be reserved. The Setup Priority SHOULD never be higher
than the Holding Priority for a given session.
The setup and holding priorities are directly analogous to the
preemption and defending priorities as defined in [9]. While the
interaction of these two objects is ultimately a matter of policy,
the following default interaction is RECOMMENDED.
When both objects are present, the preemption priority policy element
is used. A mapping between the priority spaces is defined as
follows. A session attribute priority S is mapped to a preemption
priority P by the formula P = 2^(14-2S). The reverse mapping is
shown in the following table.
Preemption Priority Session Attribute Priority
0 - 3 7
4 - 15 6
16 - 63 5
64 - 255 4
256 - 1023 3
1024 - 4095 2
4096 - 16383 1
16384 - 65535 0
When a new Path message is considered for admission, the bandwidth
requested is compared with the bandwidth available at the priority
specified in the Setup Priority.
If the requested bandwidth is not available a PathErr message is
returned with an Error Code of 01, Admission Control Failure, and an
Error Value of 0x0002. The first 0 in the Error Value indicates a
globally defined subcode and is not informational. The 002 indicates
"requested bandwidth unavailable".
If the requested bandwidth is less than the unused bandwidth then
processing is complete. If the requested bandwidth is available, but
is in use by lower priority sessions, then lower priority sessions
(beginning with the lowest priority) MAY be preempted to free the
necessary bandwidth.
When preemption is supported, each preempted reservation triggers a
TC_Preempt() upcall to local clients, passing a subcode that
indicates the reason. A ResvErr and/or PathErr with the code "Policy
Control failure" SHOULD be sent toward the downstream receivers and
upstream senders.
The support of local-protection is OPTIONAL. A node may recognize
the local-protection Flag but may be unable to perform the requested
operation. In this case, the node SHOULD pass the information
downstream unchanged.
The recording of the Label subobject in the ROUTE_RECORD object is
controlled by the label-recording-desired flag in the
SESSION_ATTRIBUTE object. Since the Label subobject is not needed
for all applications, it is not automatically recorded. The flag
allows applications to request this only when needed.
The contents of the Session Name field are a string, typically of
display-able characters. The Length MUST always be a multiple of 4
and MUST be at least 8. For an object length that is not a multiple
of 4, the object is padded with trailing NULL characters. The Name
Length field contains the actual string length.
4.7.4. Resource Affinity Procedures
Resource classes and resource class affinities are described in [3].
In this document we use the briefer term resource affinities for the
latter term. Resource classes can be associated with links and
advertised in routing protocols. Resource class affinities are used
by RSVP in two ways. In order to be validated a link MUST pass the
three tests below. If the test fails a PathErr with the code "policy
control failure" SHOULD be sent.
When a new reservation is considered for admission over a strict node
in an ERO, a node MAY validate the resource affinities with the
resource classes of that link. When a node is choosing links in
order to extend a loose node of an ERO, the node MUST validate the
resource classes of those links against the resource affinities. If
no acceptable links can be found to extend the ERO, the node SHOULD
send a PathErr message with an error code of "Routing Problem" and an
error value of "no route available toward destination".
In order to be validated a link MUST pass the following three tests.
To precisely describe the tests use the definitions in the object
description above. We also define
Link-attr A 32-bit vector representing attributes associated
with a link.
The three tests are
1. Exclude-any
This test excludes a link from consideration if the link
carries any of the attributes in the set.
(link-attr & exclude-any) == 0
2. Include-any
This test accepts a link if the link carries any of the
attributes in the set.
(include-any == 0) | ((link-attr & include-any) != 0)
3. Include-all
This test accepts a link only if the link carries all of the
attributes in the set.
(include-all == 0) | (((link-attr & include-all) ^ include-
all) == 0)
For a link to be acceptable, all three tests MUST pass. If the test
fails, the node SHOULD send a PathErr message with an error code of
"Routing Problem" and an error value of "no route available toward
destination".
If a Path message contains multiple SESSION_ATTRIBUTE objects, only
the first SESSION_ATTRIBUTE object is meaningful. Subsequent
SESSION_ATTRIBUTE objects can be ignored and need not be forwarded.
All RSVP routers, whether they support the SESSION_ATTRIBUTE object
or not, SHALL forward the object unmodified. The presence of non-
RSVP routers anywhere between senders and receivers has no impact on
this object.
5. Hello Extension
The RSVP Hello extension enables RSVP nodes to detect when a
neighboring node is not reachable. The mechanism provides node to
node failure detection. When such a failure is detected it is
handled much the same as a link layer communication failure. This
mechanism is intended to be used when notification of link layer
failures is not available and unnumbered links are not used, or when
the failure detection mechanisms provided by the link layer are not
sufficient for timely node failure detection.
It should be noted that node failure detection is not the same as a
link failure detection mechanism, particularly in the case of
multiple parallel unnumbered links.
The Hello extension is specifically designed so that one side can use
the mechanism while the other side does not. Neighbor failure
detection may be initiated at any time. This includes when neighbors
first learn about each other, or just when neighbors are sharing Resv
or Path state.
The Hello extension is composed of a Hello message, a HELLO REQUEST
object and a HELLO ACK object. Hello processing between two
neighbors supports independent selection of, typically configured,
failure detection intervals. Each neighbor can autonomously issue
HELLO REQUEST objects. Each request is answered by an
acknowledgment. Hello Messages also contain enough information so
that one neighbor can suppress issuing hello requests and still
perform neighbor failure detection. A Hello message may be included
as a sub-message within a bundle message.
Neighbor failure detection is accomplished by collecting and storing
a neighbor's "instance" value. If a change in value is seen or if
the neighbor is not properly reporting the locally advertised value,
then the neighbor is presumed to have reset. When a neighbor's value
is seen to change or when communication is lost with a neighbor, then
the instance value advertised to that neighbor is also changed. The
HELLO objects provide a mechanism for polling for and providing an
instance value. A poll request also includes the sender's instance
value. This allows the receiver of a poll to optionally treat the
poll as an implicit poll response. This optional handling is an
optimization that can reduce the total number of polls and responses
processed by a pair of neighbors. In all cases, when both sides
support the optimization the result will be only one set of polls and
responses per failure detection interval. Depending on selected
intervals, the same benefit can occur even when only one neighbor
supports the optimization.
5.1. Hello Message Format
Hello Messages are always sent between two RSVP neighbors. The IP
source address is the IP address of the sending node. The IP
destination address is the IP address of the neighbor node.
The HELLO mechanism is intended for use between immediate neighbors.
When HELLO messages are being the exchanged between immediate
neighbors, the IP TTL field of all outgoing HELLO messages SHOULD be
set to 1.
The Hello message has a Msg Type of 20. The Hello message format is
as follows:
<Hello Message> ::= <Common Header> [ <INTEGRITY> ]
<HELLO>
5.2. HELLO Object formats
The HELLO Class is 22. There are two C_Types defined.
5.2.1. HELLO REQUEST object
Class = HELLO Class, 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src_Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Dst_Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.2.2. HELLO ACK object
Class = HELLO Class, 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src_Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Dst_Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Src_Instance: 32 bits
a 32 bit value that represents the sender's instance. The
advertiser maintains a per neighbor representation/value. This
value MUST change when the sender is reset, when the node reboots,
or when communication is lost to the neighboring node and
otherwise remains the same. This field MUST NOT be set to zero
(0).
Dst_Instance: 32 bits
The most recently received Src_Instance value received from the
neighbor. This field MUST be set to zero (0) when no value has
ever been seen from the neighbor.
5.3. Hello Message Usage
The Hello Message is completely OPTIONAL. All messages may be
ignored by nodes which do not wish to participate in Hello message
processing. The balance of this section is written assuming that the
receiver as well as the sender is participating. In particular, the
use of MUST and SHOULD with respect to the receiver applies only to a
node that supports Hello message processing.
A node periodically generates a Hello message containing a HELLO
REQUEST object for each neighbor who's status is being tracked. The
periodicity is governed by the hello_interval. This value MAY be
configured on a per neighbor basis. The default value is 5 ms.
When generating a message containing a HELLO REQUEST object, the