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 77 of 113
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.
The head-end LSR sets the “label recording requested” flag in the SESSION_ATTRIBUTE object
for LSPs requesting local protection. This will cause 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.
Procedures for the PLR before Local Repair
A PLR that uses facility-backup to protect a given LSP selects 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.
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 SESSION is unchanged.
•
The SESSION_ATTRIBUTE is unchanged exceptchanging flags in it.
•
The IPv4 tunnel sender address of the SENDER_TEMPLATE is set to an address belonging to
the PLR.
•
The RSVP_HOP object contains an IP source address belonging to the PLR. Consequently,
the MP sends messages back to the PLR with that IP address as the destination.
•
The PLR generates an EXPLICIT_ROUTE object toward the egress. Detailed ERO
processing is described below.
•
The RRO object may have to be updated.
•
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.
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 will 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 RSVP_HOP object.
Processing Backup Tunnel ERO
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.