the FAST_REROUTE object are specified below. This is used by legacy
implementations. The meaning of the fields is the same as that
described for C-Type 1.
Class-Num = 205
C-Type = 7
0 1 2 3
+-------------+-------------+-------------+-------------+
| Length (bytes) | Class-Num | C-Type |
+-------------+-------------+-------------+-------------+
| Setup Prio | Hold Prio | Hop-limit | Reserved |
+-------------+-------------+-------------+-------------+
| Bandwidth |
+-------------+-------------+-------------+-------------+
| Include-any |
+-------------+-------------+-------------+-------------+
| Exclude-any |
+-------------+-------------+-------------+-------------+
Unknown C-Types should be treated as specified in [RSVP] Section
3.10.
4.2. DETOUR Object
The DETOUR object is used in the one-to-one backup method to identify
detour LSPs.
4.2.1. DETOUR Object for IPv4 Address
Class-Num = 63
C-Type = 7
0 1 2 3
+-------------+-------------+-------------+-------------+
| Length (bytes) | Class-Num | C-Type |
+-------------+-------------+-------------+-------------+
| PLR_ID 1 |
+-------------+-------------+-------------+-------------+
| Avoid_Node_ID 1 |
+-------------+-------------+-------------+-------------+
// .... //
+-------------+-------------+-------------+-------------+
| PLR_ID n |
+-------------+-------------+-------------+-------------+
| Avoid_Node_ID n |
+-------------+-------------+-------------+-------------+
PLR_ID (1 - n)
IPv4 address identifying the PLR that is the beginning point of
the detour. Any local address on the PLR can be used.
Avoid_Node_ID (1 - n)
IPv4 address identifying the immediate downstream node that the
PLR is trying to avoid. Any local address of the downstream
node can be used. This field is mandatory and is used by the
MP for the merging rules discussed below.
4.2.2. DETOUR Object for IPv6 Address
Class-Num = 63
C-Type = 8
0 1 2 3
+-------------+-------------+-------------+-------------+
| Length (bytes) | Class-Num | C-Type |
+-------------+-------------+-------------+-------------+
| PLR_ID 1 |
+-------------+-------------+-------------+-------------+
| PLR_ID 1 (continued) |
+-------------+-------------+-------------+-------------+
| PLR_ID 1 (continued) |
+-------------+-------------+-------------+-------------+
| PLR_ID 1 (continued) |
+-------------+-------------+-------------+-------------+
| Avoid_Node_ID 1 |
+-------------+-------------+-------------+-------------+
| Avoid_Node_ID 1 (continued) |
+-------------+-------------+-------------+-------------+
| Avoid_Node_ID 1 (continued) |
+-------------+-------------+-------------+-------------+
| Avoid_Node_ID 1 (continued) |
+-------------+-------------+-------------+-------------+
// .... //
+-------------+-------------+-------------+-------------+
PLR_ID (1 - n)
An IPv6 128-bit unicast host address identifying the PLR that
is the beginning point of the detour. Any local address on the
PLR can be used.
Avoid_Node_ID (1 - n)
An IPv6 128-bit unicast host address identifying the immediate
downstream node that the PLR is trying to avoid. Any local
address on the downstream node can be used. This field is
mandatory and is used by the MP for the merging rules discussed
below.
There can be more than one pair of (PLR_ID, Avoid_Node_ID) entries in
a DETOUR object. If detour merging is desired, after each merging
operation, the Detour Merge Point should combine all the merged
detours in subsequent Path messages.
The high-order bit of the Class-Num is zero; LSRs that do not support
the DETOUR objects MUST reject any Path message containing a DETOUR
object and send a PathErr to notify the PLR. This PathErr SHOULD be
generated as specified in [RSVP] for unknown objects with a Class-Num
of the form "0bbbbbbb".
Unknown C-Types should be treated as specified in [RSVP] Section
3.10.
4.3. SESSION_ATTRIBUTE Flags
To request bandwidth and node protection explicitly, two new flags
are defined in the SESSION_ATTRIBUTE object.
For both C-Type 1 and 7, the SESSION_ATTRIBUTE object currently has
the following flags defined [RSVP-TE]:
Local protection desired: 0x01
This flag permits transit routers to use a local repair
mechanism that may result in violation of the explicit route
object. When a fault is detected on an adjacent downstream
link or node, a transit node may reroute traffic for fast
service restoration.
Label recording desired: 0x02
This flag indicates that label information should be included
when doing a route record.
SE Style desired: 0x04
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. When requesting fast reroute, the head-end LSR SHOULD
set this flag; this is not necessary for the path-specific
method of the one-to-one backup method.
The following new flags are defined:
Bandwidth protection desired: 0x08
This flag indicates to the PLRs along the protected LSP path
that a backup path with a bandwidth guarantee is desired. The
bandwidth to be guaranteed is that of the protected LSP, if no
FAST_REROUTE object is included in the PATH message; if a
FAST_REROUTE object is in the PATH message, then the bandwidth
specified therein is to be guaranteed.
Node protection desired: 0x10
This flag indicates to the PLRs along a protected LSP path that
a backup path that bypasses at least the next node of the
protected LSP is desired.
4.4. RRO IPv4/IPv6 Sub-object Flags
To report whether bandwidth and/or node protection are provided as
requested, we define two new flags in the RRO IPv4 sub-object.
The RRO IPv4 and IPv6 address sub-objects currently have the
following flags defined [RSVP-TE]:
Local protection available: 0x01
Indicates that the link downstream of this node is protected
via a local repair mechanism, which can be either one-to-one or
facility backup.
Local protection in use: 0x02
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, or an outage of the neighboring
node).
Two new flags are defined:
Bandwidth protection: 0x04
The PLR will set this bit when the protected LSP has a backup
path that is guaranteed to provide the desired bandwidth that
is specified in the FAST_REROUTE object or the bandwidth of the
protected LSP, if no FAST_REROUTE object was included. The PLR
may set this whenever the desired bandwidth is guaranteed; the
PLR MUST set this flag when the desired bandwidth is guaranteed
and the "bandwidth protection desired" flag was set in the
SESSION_ATTRIBUTE object. If the requested bandwidth is not
guaranteed, the PLR MUST NOT set this flag.
Node protection: 0x08
The PLR will set this bit when the protected LSP has a backup
path that provides protection against a failure of the next LSR
along the protected LSP. The PLR may set this whenever node
protection is provided by the protected LSP’s backup path; the
PLR MUST set this flag when the node protection is provided and
the "node protection desired" flag was set in the
SESSION_ATTRIBUTE object. If node protection is not provided,
the PLR MUST NOT set this flag. Thus, if a PLR could only set
up a link-protection backup path, the "Local protection
available" bit will be set, but the "Node protection" bit will
be cleared.
5. Head-End Behavior
The head-end of an LSP determines whether local protection should be
requested for that LSP and which local protection method is desired
for the protected LSP. The head-end also determines what constraints
should be requested for the backup paths of a protected LSP.
To indicate that an LSP should be locally protected, the head-end LSR
MUST either set the "local protection desired" flag in the
SESSION_ATTRIBUTE object or include a FAST_REROUTE object in the PATH
message, or both. The "local protection desired" flag in the
SESSION_ATTRIBUTE object SHOULD always be set. If a head-end LSR
signals a FAST_REROUTE object, it MUST be stored for Path refreshes.
The head-end LSR of a protected LSP MUST set the "label recording
desired" flag in the SESSION_ATTRIBUTE object. This facilitates the
use of the facility backup method. If node protection is desired,
the head-end LSR should set the "node protection desired" flag in the
SESSION_ATTRIBUTE object; otherwise, this flag should be cleared.
Similarly, if a guarantee of bandwidth protection is desired, then
the "bandwidth protection desired" flag in the SESSION_ATTRIBUTE
object should be set; otherwise, this flag should be cleared. If the
head-end LSR determines that control of the backup paths for the
protected LSP is desired, then the LSR should include the
FAST_REROUTE object. The PLRs will use the attribute filters,
bandwidth, hop-limit, and priorities to determine the backup paths.
If the head-end LSR desires that the one-to-one backup method be used
for the protected LSP, then the head-end LSR should include a
FAST_REROUTE object and set the "one-to-one backup desired" flag. If
the head-end LSR desires that the protected LSP be protected via the
facility backup method, then the head-end LSR should include a
FAST_REROUTE object and set the "facility backup desired" flag. The
lack of a FAST_REROUTE object, or having both these flags clear,
should be treated by PLRs as a lack of preference. If both flags are
set, a PLR may use either method or both.
The head-end LSR of a protected LSP MUST support the additional flags
defined in Section 4.4 being set or clear in the RRO IPv4 and IPv6
sub-objects. The head-end LSR of a protected LSP MUST support the
RRO Label sub-object.
If the head-end LSR of an LSP determines that local protection is
newly desired, this SHOULD be signaled via make-before-break.
6. Point of Local Repair (PLR) Behavior
Every LSR along a protected LSP (except the egress) MUST follow the
PLR behavior described in this document.
A PLR SHOULD support the FAST_REROUTE object, the "local protection
desired", "label recording desired", "node protection desired", and
"bandwidth protection desired" flags in the SESSION_ATTRIBUTE object,
and the "local protection available", "local protection in use",
"bandwidth protection", and "node protection" flags in the RRO IPv4
and IPv6 sub-objects. A PLR MAY support the DETOUR object.
A PLR MUST consider an LSP to have asked for local protection if the
"local protection desired" flag is set in the SESSION_ATTRIBUTE
object and/or the FAST_REROUTE object is included. If the
FAST_REROUTE object is included, a PLR SHOULD consider providing
one-to-one protection if the "one-to-one desired" is set, and it
SHOULD consider providing facility backup if the "facility backup
desired" flag is set. If the "node protection desired" flag is set,
the PLR SHOULD try to provide node protection; if this is not
feasible, the PLR SHOULD then try to provide link protection. If the
"bandwidth protection guaranteed" flag is set, the PLR SHOULD try to
provide a bandwidth guarantee; if this is not feasible, the PLR
SHOULD then try to provide a backup without a guarantee of the full
bandwidth.
The following treatment for the RRO IPv4 or IPv6 sub-object’s flags
must be followed if an RRO is included in the protected LSP’s RESV
message. Based on this additional information, the head-end may take
appropriate actions.
- Until a PLR has a backup path available, the PLR MUST clear the
relevant four flags in the corresponding RRO IPv4 or IPv6 sub-
object.
- Whenever the PLR has a backup path available, the PLR MUST set the
"local protection available" flag. If no established one-to-one
backup LSP or bypass tunnel exists, or if the one-to-one LSP and
the bypass tunnel is in "DOWN" state, the PLR MUST clear the
"local protection available" flag in its IPv4 (or IPv6) address
sub-object of the RRO and SHOULD send the updated RESV.
- The PLR MUST clear the "local protection in use" flag unless it is
actively redirecting traffic into the backup path instead of along
the protected LSP.
- The PLR SHOULD also set the "node protection" flag if the backup
path protects against the failure of the immediate downstream
node, and, if the path does not, the PLR SHOULD clear the "node
protection" flag. This MUST be done if the "node protection
desired" flag was set in the SESSION_ATTRIBUTE object.
- The PLR SHOULD set the "bandwidth protection" flag if the backup
path offers a bandwidth guarantee, and, if the path does not, the
PLR SHOULD clear the "bandwidth protection" flag. This MUST be
done if the "bandwidth protection desired" flag was set in the
SESSION_ATTRIBUTE object.
6.1. Signaling a Backup Path
A number of objectives must be met to obtain a satisfactory signaling
solution. These are summarized as follows:
1. Unambiguously and uniquely identifying backup paths.
2. Unambiguously associating protected LSPs with their backup
paths.
3. Working with both global and non-global label spaces.
4. Allowing merging of backup paths.
5. Maintaining RSVP state during and after fail-over.
LSP tunnels are identified by a combination of the SESSION and
SENDER_TEMPLATE objects [RSVP-TE]. The relevant fields are as
follows.
IPv4 (or IPv6) tunnel end point address
IPv4 (or 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 32-bit (IPv4) or 128-bit (IPv6) identifier used in the
SESSION that remains constant over the life of the tunnel.
Normally it is set to all zero. Ingress nodes that wish to
narrow the scope of a SESSION to the ingress-egress pair may
place their IP address here as a globally unique identifier.
IPv4 (or IPv6) tunnel sender address
IPv4 (or IPv6) address for a sender node.
LSP ID
A 16-bit identifier used in the SENDER_TEMPLATE and the
FILTER_SPEC, which can be changed to allow a sender to share
resources with itself.
The first three of these are in the SESSION object and are the basic
identification for the tunnel. Setting the "Extended Tunnel ID" to
an IP address of the head-end LSR allows the scope of the SESSION to
be narrowed to only LSPs sent by that LSR. A backup LSP is
considered part of the same session as its protected LSP; therefore
these three cannot be varied.
The last two are in the SENDER_TEMPLATE. Multiple LSPs in the same
SESSION may be protected and may take different routes; this is
common when a tunnel is rerouted using make-before-break. A backup
path must be clearly identified with its protected LSP to allow
correct merging and state treatment. Therefore, a backup path must
inherit its LSP ID from the associated protected LSP. Thus, the only
field in the SESSION and SENDER_TEMPLATE objects that could be varied
between a backup path and a protected LSP is the "IPv4 (or IPv6)
tunnel sender address" in the SENDER_TEMPLATE.
There are two different methods to uniquely identify a backup path,
described below.
6.1.1. Backup Path Identification: Sender Template-Specific
In this approach, the SESSION object and the LSP_ID are copied from
the protected LSP. The "IPv4 tunnel sender address" is set to an
address of the PLR. If the head-end of a tunnel is also acting as
the PLR, it MUST choose an IP address different from the one used in
the SENDER_TEMPLATE of the original LSP tunnel.
When the sender template-specific approach is used, the protected
LSPs and the backup paths SHOULD use the Shared Explicit (SE) style.
This allows bandwidth sharing between multiple backup paths. The
backup paths and the protected LSP MAY be merged by the Detour Merge
Points, when the ERO from the MP to the egress is the same on each
LSP to be merged, as specified in [RSVP-TE].
6.1.2. Backup Path Identification: Path-Specific
In this approach, rather than vary the SESSION or SENDER_TEMPLATE
objects, an implementation uses a new object, the DETOUR object, to
distinguish between PATH messages for a backup path and the protected
LSP.
Thus, the backup paths use the same SESSION and SENDER_TEMPLATE
objects as the ones used in the protected LSP. The presence of a
DETOUR object in Path messages signifies a backup path; the presence
of a FAST_REROUTE object and/or the "local protection requested" flag
in the SESSION_ATTRIBUTE object indicates a protected LSP.
In the path message-specific approach, an LSR merges Path messages
that are received with the same SESSION and SENDER_TEMPLATE objects
and that also have the same next-hop object. Without this behavior,
it would be impossible to associate the multiple RESV messages with
the backup paths. However, this merging behavior reduces the total
number of RSVP states inside the network at the expense of merging
LSPs with different EROs.
6.2. Procedures for Backup Path Computation
Before a PLR can create a detour or a bypass tunnel, the desired
explicit route must be determined. This can be done using a CSPF
(Constraint-based Shortest Path First) computation. Before this CSPF
computation, the following information must be collected at a PLR:
- The list of downstream nodes that the protected LSP passes
through. This information is readily available from the
RECORD_ROUTE objects during LSP setup. This information is also
available from the ERO. However, if the ERO contains loose
sub-objects, the ERO may not provide adequate information.
- The downstream links/nodes that we want to protect against.
Once again, this information is learned from the RECORD_ROUTE
objects. Whether node protection is desired is determined by
the "node protection" flag in the SESSION_ATTRIBUTE object and
local policy.
- The upstream uni-directional links that the protected LSP passes
through. This information is learned from the RECORD_ROUTE
objects; it is only needed for setting up one-to-one protection.
In the path-specific method, it is necessary to avoid the detour
and the protected LSP sharing a common next-hop upstream of the
failure. In the sender template-specific mode, this same
restriction is necessary to avoid sharing bandwidth between the
detour and its protected LSP, where that bandwidth has been
reserved only once.
- The link attribute filters to be applied. These are derived
from the FAST_REROUTE object, if it is included in the PATH
message, or from the SESSION_ATTRIBUTE object otherwise.
- The bandwidth to be used is found in the FAST_REROUTE object, if
it is included in the PATH message, or in the SESSION_ATTRIBUTE
object otherwise. Local policy may modify the bandwidth to be
reserved.
- The hop-limit, if a FAST_REROUTE object was included in the PATH
message.
When a CSPF algorithm is used to compute the backup route, the
following constraints must be satisfied:
- For detour LSPs, the destination MUST be the tail-end of the
protected LSP. For bypass tunnels (Section 7), the destination
MUST be the address of the MP.
- When one-to-one protection is set up by using the path-specific
method, a detour MUST not traverse the upstream links of the