protected LSP in the same direction. This prevents the
possibility of early merging of the detour into the protected
LSP. When one-to-one protection is set up using the sender-
template-specific method, a detour should not traverse the
upstream links of the protected LSP in the same direction. This
prevents sharing the bandwidth between a protected LSP and its
backup upstream of the failure where the bandwidth would be used
twice in the event of a failure.
- The backup LSP cannot traverse the downstream node and/or link
whose failure is being protected against. Note that if the PLR
is the penultimate hop, node protection is not possible, and
only the downstream link can be avoided. The backup path may be
computed to be SRLG disjoint from the downstream node and/or
link being avoided.
- The backup path must satisfy the resource requirements of the
protected LSP. This includes the link attribute filters,
bandwidth, and hop limits determined from the FAST_REROUTE
object and the SESSION_ATTRIBUTE object.
If such computation succeeds, the PLR should attempt to establish a
backup path. The PLR may schedule a re-computation at a later time
to discover better paths that might have emerged. If for any reason,
the PLR is unable to bring up a backup path, it must schedule a retry
at a later time.
6.3. Signaling Backups for One-to-One Protection
Once a PLR has decided to protect an LSP locally with one-to-one
backup and has identified the desired path, it signals for the
detour.
The following describes the transformation to be performed upon the
protected LSP’s PATH message to create the detour LSP’s PATH message.
- If the sender template-specific method is to be used, then the
PLR MUST change the "IPv4 (or IPv6) tunnel sender address" of
the SENDER_TEMPLATE to an address belonging to the PLR that is
not the same as that used for the protected LSP. Additionally,
the DETOUR object MAY be added to the PATH message.
- If the path-specific method is to be used, then the PLR MUST add
a DETOUR object to the PATH message.
- The SESSION_ATTRIBUTE flags "Local protection desired",
"Bandwidth protection desired", and "Node protection desired"
MUST be cleared. The "Label recording desired" flag MAY be
modified. If the Path Message contained a FAST_REROUTE object
and the ERO is not completely strict, the Include-any, Exclude-
any, and Include-all fields of the FAST_REROUTE object SHOULD be
copied to the corresponding fields of the SESSION_ATTRIBUTE
object.
- If the protected LSP’s Path message contained a FAST_REROUTE
object, this object MUST be removed from the detour LSP’s PATH
message.
- The PLR MUST generate an EXPLICIT_ROUTE object toward the
egress. First, the PLR must remove all sub-objects preceding
the first address belonging to the Merge Point. Then the PLR
SHOULD add sub-objects corresponding to the desired backup path
between the PLR and the MP.
- The SENDER_TSPEC object SHOULD contain the bandwidth information
from the received FAST_REROUTE object, if included in the
protected LSP’s PATH message.
- The RSVP_HOP object containing one of the PLR’s IP address.
- The detour LSPs MUST use the same reservation style as the
protected LSP. This must be correctly reflected in the
SESSION_ATTRIBUTE object.
Detour LSPs operate like regular LSPs. Once a detour path is
successfully computed and the detour LSP is established, the PLR
need not compute detour routes again, unless (1) the contents of
FAST_REROUTE have changed or (2) the downstream interface and/or
the nexthop router for a protected LSP has changed. The PLR may
recompute detour routes at any time.
6.3.1. Make-before-Break with Detour LSPs
If the sender template-specific method is used, it is possible to do
make-before-break with detour LSPs. This is done using two different
IP addresses belonging to the PLR (which were not used in the
SENDER_TEMPLATE of the protected LSP). If the current detour LSP
uses the first IP address in its SENDER_TEMPLATE, then the new detour
LSP should be signaled by using the second IP address in its
SENDER_TEMPLATE. Once the new detour LSP has been created, the
current detour LSP can be torn down. By alternating the use of these
IP addresses, the current and new detour LSPs will have different
SENDER_TEMPLATES and, thus, different state in the downstream LSRs.
This make-before-break mechanism, which changes the PLR IP address in
the DETOUR object instead, is not feasible with the path-specific
method, as the PATH messages for new and current detour LSPs may be
merged if they share a common next-hop.
6.3.2. Message Handling
LSRs must process the detour LSPs independently of the protected LSPs
to avoid triggering the LSP loop detection procedure described in
[RSVP-TE].
The PLR MUST not mix the messages for the protected and the detour
LSPs. When a PLR receives Resv, ResvTear, and PathErr messages from
the downstream detour destination, the messages MUST not be forwarded
upstream. Similarly, when a PLR receives ResvErr and ResvConf
messages from a protected LSP, it MUST not propagate them onto the
associated detour LSP.
A session tear-down request is normally originated by the sender via
PathTear messages. When a PLR node receives a PathTear message from
upstream, it MUST delete both the protected and the detour LSPs. The
PathTear messages MUST propagate to both protected and detour LSPs.
During error conditions, the LSRs may send ResvTear messages to fix
problems on the failing path. When a PLR node receives the ResvTear
messages from downstream for a protected LSP, as long as a detour is
up, the ResvTear messages MUST not be sent further upstream.
PathErrs should be treated similarly.
6.3.3. Local Reroute of Traffic onto Detour LSP
When the PLR detects a failure on the protected LSP, the PLR MUST
rapidly switch packets to the protected LSP’s backup LSP instead of
to the protected LSP’s normal out-segment. The goal of this method
is to effect the redirection within 10s of milliseconds.
L32 L33 L34 L35
R1-------R2-------R3-------R4-------R5
| |
L46 | | L44
| L47 |
R6----------------R7
Protected LSP: [R1->R2->R3->R4->R5]
Detour LSP: [R2->R6->R7->R4]
Example 3. Redirect to Detour
In Example 3, if the link [R2->R3] fails, R2 would do the following.
Any traffic received on link [R1->R2] with label L32 would be sent on
link [R2->R6] with label L46 (along the detour LSP) instead of on
link [R3->R4] with label L34 (along the protected LSP). The merge
point R4 would recognize that packets received on link [R7->R4] with
label L44 should be sent on link [R4->R5] with label L35 and that
they should be merged with the protected LSP.
6.4. Signaling for Facility Protection
A PLR may use one or more bypass tunnels to protect against the
failure of a link and/or a node. These bypass tunnels may be set up
in advance or may be dynamically created as new protected LSPs are
signaled.
6.4.1. Discovering Downstream Labels
To support facility backup, the PLR must determine a label that will
indicate to the MP that packets received with that label should be
switched along the protected LSP. This can be done without
explicitly signaling the backup path if the MP uses a label space
global to that LSR.
As described in Section 6, the head-end LSR MUST set the "label
recording requested" flag in the SESSION_ATTRIBUTE object for LSPs
requesting local protection. This will cause (as specified in
[RSVP-TE]) all LSRs to record their INBOUND labels and to note via a
flag whether the label is global to the LSR. Thus, when a protected
LSP is first signaled through a PLR, the PLR can examine the RRO in
the Resv message and learn about the incoming labels that are used by
all downstream nodes for this LSP
When MPs use per-interface label spaces, the PLR must send Path
messages (for each protected LSP using a bypass tunnel) via that
bypass tunnel prior to the failure in order to discover the
appropriate MP label. The signaling procedures for this are in
Section 6.4.3 below.
6.4.2. Procedures for the PLR before Local Repair
A PLR that determines to use facility-backup to protect a given LSP
should select a bypass tunnel to use, taking into account whether
node protection is to be provided, what bandwidth was requested,
whether a bandwidth guarantee is desired, and what link attribute
filters were specified in the FAST_REROUTE object. The selection of
a bypass tunnel for a protected LSP is performed by the PLR when the
LSP is first set up.
6.4.3. Procedures for the PLR during Local Repair
When the PLR detects a link or/and node failure condition, it has to
reroute the data traffic onto the bypass tunnel and to start sending
the control traffic for the protected LSP onto the bypass tunnel.
The backup tunnel is identified by using the sender template-specific
method. The procedures to follow are similar to those described in
Section 6.3.
- The SESSION is unchanged.
- The SESSION_ATTRIBUTE is unchanged except as follows: The
"Local protection desired", "Bandwidth protection desired", and
"Node protection desired" flags SHOULD be cleared. The "Label
recording desired" MAY be modified.
- The IPv4 (or IPv6) tunnel sender address of the SENDER_TEMPLATE
is set to an address belonging to the PLR.
- The RSVP_HOP object MUST contain an IP source address belonging
to the PLR. Consequently, the MP will send messages back to the
PLR with that IP address as the destination.
- The PLR MUST generate an EXPLICIT_ROUTE object toward the
egress. Detailed ERO processing is described below.
- The RRO object may have to be updated as described in Section
6.5.
The PLR sends Path, PathTear, and ResvConf messages via the backup
tunnel. The MP sends Resv, ResvTear, and PathErr messages by sending
them directly to the address in the RSVP_HOP object, as specified in
[RSVP].
If it is necessary to signal the backup prior to failure to determine
the MP label to use, then the same Path message is sent. In this
case, the PLR SHOULD continue to send Path messages for the protected
LSP along the normal route. PathTear messages should be duplicated,
with one sent along the normal route and one sent through the bypass
tunnel. The MP should duplicate the Resv and ResvTear messages and
send them to both the PLR and the LSR indicated by the protected
LSP’s RSVP_HOP object.
6.4.4. Processing Backup Tunnel’s ERO
Procedures for ERO processing are described in [RSVP-TE]. This
section describes additional ERO update procedures for Path messages
that are sent over bypass tunnels. If normal ERO processing rules
were followed, the Merge Point would examine the first sub-object and
likely reject it (Bad initial sub-object). This is because the
unmodified ERO might contain the IP address of a bypassed node (in
the case of a NNHOP Bypass Tunnel) or of an interface that is
currently down (in the case of a NHOP Backup Tunnel). For this
reason, the PLR invokes the following ERO procedures before sending a
Path message via a bypass tunnel.
Sub-objects belonging to abstract nodes that precede the Merge
Point are removed, along with the first sub-object belonging to
the MP. A sub-object identifying the Backup Tunnel destination is
then added.
More specifically, the PLR MUST:
- remove all the sub-objects proceeding the first address
belonging to the MP, and
- replace this first MP address with an IP address of the MP.
(Note that this could be same address that was just removed.)
6.5. PLR Procedures during Local Repair
In addition to the method-specific signaling and packet treatment,
there is common signaling that should be followed.
During fast reroute, for each protected LSP containing an RRO object,
the PLR obtains the RRO from the protected LSP’s stored RESV. The
PLR MUST update the IPv4 or IPv6 sub-object it inserted into the RRO
by setting the "Local protection in use" and "Local Protection
Available" flags.
6.5.1. Notification of Local Repair
In many situations, the route used during local repair will be less
than optimal. The purpose of local repair is to keep high priority
and loss-sensitive traffic flowing while a more optimal re-routing of
the tunnel can be effected by the head-end of the tunnel. Thus, the
head-end has to know of the failure so that it may re-signal an
optimal LSP.
To provide this notification, the PLR SHOULD send a Path Error
message with error code of "Notify" (Error code = 25) and an error
value field of ss00 cccc cccc cccc, where ss=00 and the sub-code = 3
("Tunnel locally repaired") (see [RSVP-TE]).
Additionally, a head-end may detect that an LSP has to be moved to a
more optimal path by noticing failures reported via the IGP. Note
that in the case of inter-area TE LSP (TE LSP spanning areas), the
head-end LSR will have to rely exclusively on Path Error messages to
be informed of failures in another area.
6.5.2. Revertive Behavior
Upon a failure event, a protected TE LSP is locally repaired by the
PLR. There are two basic strategies for restoring the TE LSP to a
full working path.
- Global revertive mode: The head-end LSR of each tunnel is
responsible for reoptimizing the TE LSPs that used the failed
resource. There are several potential reoptimization triggers:
RSVP error messages, inspection of OSPF LSAs or ISIS LSPs, and
timers. Note that this re-optimization process may proceed as
soon as the failure is detected. It is not tied to the
restoration of the failed resource.
- Local revertive mode: Upon detecting that the resource is
restored, the PLR re-signals each of the TE LSPs that used to be
routed over the restored resource. Every TE LSP successfully
re-signaled along the restored resource is switched back.
There are several circumstances in which a local revertive mode might
not be desirable. In the case of resource flapping (not an uncommon
failure type), this could generate multiple traffic disruptions.
Therefore, in the local revertive mode, the PLR should implement a
means to dampen the re-signaling process in order to limit potential
disruptions due to flapping.
In the local revertive mode, any TE LSP will be switched back,
without any distinction, whereas in the global revertive mode, the
decision to reuse the restored resource is made by the head-end LSR
based on the TE LSP attributes. When the head-end learns of the
failure, it may reoptimize the protected LSP tunnel along a different
and more optimal path, as it has a more complete view of the
resources and TE LSP constraints. This means that the old LSP that
has been reverted to may no longer be optimal. Note that in the case
of inter-area LSP, where the TE LSP path computation might be done on
some Path Computation Element, the reoptimization process can
still be triggered on the Head-End LSP. The local revertive mode
is optional.
However, there are circumstances in which the head-end does not have
the ability to reroute the TE LSP (e.g., if the protected LSP is
pinned down, as may be desirable if the paths are determined by using
an off-line optimization tool), or if the head-end does not have the
complete TE topology information (depending on the path computation
scenario). In those cases, the local revertive mode might be an
interesting option.
The globally revertive mode SHOULD always be used. Note that a link
or node "failure" may be due to the facility being permanently taken
out of service. Local revertive mode is optional. When used in
combination, the global mode may rely solely on timers to do the
reoptimization. When local revertive mode is not used, head-end LSRs
SHOULD react to RSVP error messages and/or IGP indications in order
to make a timely response.
Interoperability: If a PLR is configured with the local revertive
mode but the MP is not, any attempt from the PLR to resignal the TE
LSP over the restored resource will fail, as the MP will not send any
Resv message. The PLR will still refresh the TE LSP over the backup
tunnel. The TE LSP will not revert to the restored resource;
instead, it will continue to use the backup until it is re-optimized.
7. Merge Node Behavior
An LSR is a Merge Point if it receives the Path message for a
protected LSP and one or more messages for a backup LSP that is
merged into that protected LSP. In the one-to-one backup method, the
LSR is aware that it is a merge node prior to failure. In the
facility backup method, the LSR may not know that it is a Merge Point
until a failure occurs and it receives a backup LSP’s Path message.
Therefore, an LSR that is on the path of a protected LSP SHOULD
always assume that it is a merge point.
When a MP receives a backup LSP’s Path message through a bypass
tunnel, the Send_TTL in the Common Header may not match the TTL of
the IP packet within which the Path message was transported. This is
expected behavior.
7.1. Handling Backup Path Messages before Failure
There are two circumstances in which a Merge Point will receive Path
messages for a backup path prior to failure. In the first case, if a
PLR is providing local protection via the one-to-one backup method,
the detour will be signaled and must be properly handled by the MP.
In this case, the backup LSP may be signaled via the sender
template-specific method or via the path-specific method.
In the second case, if the Merge Point does not provide labels global
to the MP and record them in a Label sub-object of the RRO, or if the
PLR does not use such recorded information, the PLR may signal the
backup path as described in Section 6.4.1. This will determine the
label to use if the PLR is providing protection according to the
facility backup method. In this case, the backup LSP is signaled via
the sender template-specific method.
The reception of a backup LSP’s path message does not indicate that a
failure has occurred or that the incoming protected LSP will no
longer be used.
7.1.1. Merging Backup Paths using the Sender Template-Specific Method
An LSR may receive multiple Path messages for one or more backup LSPs
and, possibly, for the protected LSP. Each of these Path messages
will have a different SENDER_TEMPLATE. The protected LSP can be
recognized because it will include the FAST_REROUTE object or have
the "local protection desired" flag set in the SESSION_ATTRIBUTE
object, or both.
If the outgoing interface and next-hop LSR are the same, then the
Path messages are eligible for merging. Similarly to the
specification in [RSVP-TE] for merging of RESV messages, only Path
messages whose ERO from that LSR to the egress is the same can be
merged. If merging occurs and one of the Path messages merged was
for the protected LSP, then the final Path message to be sent MUST be
that of the protected LSP. This merges the backup LSPs into the
protected LSP at that LSR. Once the final Path message has been
identified, the MP MUST start to refresh it downstream periodically.
If merging occurs and all the Path messages were for backup LSPs,
then the DETOUR object, if any, should be altered as specified in
Section 8.1
7.1.2. Merging Detours using the Path-Specific Method
An LSR (that is, an MP) may receive multiple Path messages from
different interfaces with identical SESSION and SENDER_TEMPLATE
objects. In this case, Path state merging is REQUIRED. The merging
rule is as follows:
If all Path messages have neither a FAST_REROUTE nor a DETOUR object,
or if the MP is the egress of the LSP, no merging is required. The
messages are processed according to [RSVP-TE].
Otherwise, the MP MUST record the Path state and the incoming
interface. If the Path messages do not share an outgoing interface
and a next-hop LSR, the MP MUST consider them to be independent LSPs
and MUST NOT merge them.
For all the Path messages that share the same outgoing interface and
next-hop LSR, the MP runs the following procedure to create a Path
message to forward downstream.
1. If one or more of the Path messages is for the protected LSP (a
protected LSP is one originated from this node, or with the
FAST_REROUTE object, or without the DETOUR object), one of these
must become the chosen Path message. There could be more than
one; in that case, which one to forward is a local decision.
Quit.
2. From the remaining set of Detour Path messages, eliminate from
consideration those that traverse nodes that others want to
avoid.
3. If several still remain, which one to forward is a local
decision. If none remain, then the MP MAY try to find a new
route that avoids all nodes that merging Detour Paths want to
avoid; it will forward a Path message with that ERO.
Once the final Path message has been identified, the MP MUST start to
refresh it downstream periodically. Other LSPs are considered merged
at this node. For bandwidth reservations on the outgoing link, any
merging should be considered to have occurred before bandwidth is
reserved. Thus, even though Fixed Filter style is specified,
multiple detours and/or their protected LSP (which are to be merged
due to sharing an outgoing interface and next-hop LSR) will reserve
only the bandwidth of the final Path message on that outgoing
interface.
If no merged Path message can be constructed, the MP SHOULD send a
PathErr in response to the most recently received detour Path
message. If a protected Path is chosen to be forwarded but it
traverses nodes that some detours want to avoid, PathErrs SHOULD be
sent in response to those detour Paths which cannot merge.
7.1.2.1. An Example of Path Message Merging
R7---R8---R9-\
| | | \
R1---R2---R3---R4---R5---R6
Protected LSP: [R1->R2->R3->R4->R5->R6]
R2’s Detour: [R2->R7->R8->R9->R4->R5->R6]
R3’s Detour: [R3->R8->R9->R5->R6]
Example 4. Path Message Merging
In Example 4, R8 will receive Path messages that have the same
SESSION and SENDER_TEMPLATE from detours for R2 and R3. During