As you understand by now, much of RSVP-based MPLS TE revolves around RSVP signalling. Fast restoration is not an exception. FRR concepts and implementation depend heavily on making further extensions to what is already defined in RFC 3209. These extensions are specified in draft-ietf-mpls-rsvp-lsp-fastreroute. This section talks about RSVP signalling that happens after FRR protection has kicked in. This can be broken into the following:
• Upstream signalling
• IGP notification
• Downstream signalling
Recall from Chapter 4, "Path Calculation and Setup," that when a link goes down along an LSP, the node that is upstream of the failed link signals a path error to the headends of the LSPs traversing the failed link. In Figure 7-12, after the link between 12008a and 12008c fails, it is the responsibility of 12008a to send a PathErr message to 7200a, which is the headend of the primary tunnel.
Was this article helpful?