Foundry NetIron M2404C and M2404F Metro Access Switches
Configuring MPLS and H-VPLS (Rev. 03)
Resource Reservation Protocol Traffic Engineering (RSVP-TE)© 2008 Foundry Networks, Inc
Page 75 of 113
In the above example, R2 has built a bypass tunnel that protects against the failure of link [R2-
>R3] and node [R3]. The doubled lines represent this tunnel. This technique provides a scalability
improvement, in that the same bypass tunnel can also be used to protect LSPs from any of R1, R2,
or R8 to any of R4, R5, or R9. Example 2 describes three different protected LSPs that are using
the same bypass tunnel for protection.
There could be as many as (N-1) bypass tunnels to fully protect an LSP that traverses N nodes.
However, each of those bypass tunnels could protect a set of LSPs.
When a failure occurs along a protected LSP, the PLR redirects traffic into the appropriate bypass
tunnel. For instance, if link [R2->R3] fails in Example 2, R2 will switch traffic received from R1
on the protected LSP onto link [R2->R6]. The label will be switched for one which will be
understood by R4 to indicate the protected LSP, and the bypass tunnel label will then be pushed
onto the label- stack of the redirected packets. If penultimate-hop-popping is used, the merge point
in Example 2, R4, will receive the redirected packet with a label indicating the protected LSP that
the packet is to follow. If penultimate-hop-popping is not used, R4 will pop the bypass tunnel
label and examine the label underneath to determine the protected LSP that the packet is to follow.
When R2 is using the bypass tunnel for protected LSP 1, the traffic takes the path [R1->R2->R6-
>R7->R4->R5]; the bypass tunnel is the connection between R2 and R4.
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 either sets the "local
protection desired" flag in the SESSION_ATTRIBUTE object or includes a FAST_REROUTE
object in the PATH message, or both. The “local protection desired” flag in the
SESSION_ATTRIBUTE object
is
always set. If a head-end LSR signals a FAST_REROUTE
object, it
is
stored for Path refreshes.
The head-end LSR of a protected LSP sets 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 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.
Point of Local Repair (PLR) Behavior
Every LSR along a protected LSP (except the egress) follows the PLR behavior.
A PLR supports 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