MPLS Working Group S. Kini Internet-Draft A. Liu Intended Status: Standards Track Ericsson Expires: July 2011 January 13, 2011 Efficient Fast Re-route (FRR) using Facility backup in ring topology draft-kini-mpls-ring-frr-facility-backup-02.txt Status of this Memo Distribution of this memo is unlimited. This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 17, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Kini & Liu Expires July 2011 [Page 1] Internet Draft Efficient Facility Backup FRR January 13, 2010 Abstract Fast Re-route (FRR) using facility backup is a widely deployed MPLS protection mechanism that can protect against link and node failure. It provides a fast protection switch mechanism to minimize traffic loss (typically sub 50msec) if the node that detects the failure locally, does the repair by re-routing the protected traffic to go over the backup tunnel. A direct application of this mechanism to a ring topology results in an inefficient use of link bandwidth that could also result in degraded service. This document describes a mechanism to do it without such problems. Kini & Liu Expires July 2011 [Page 2] Internet Draft Efficient Facility Backup FRR January 13, 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions used in this document . . . . . . . . . . . . . . . 4 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 4 4. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. RSVP-TE signaling extensions . . . . . . . . . . . . . . . 7 4.2. Triggering protection switch at PLR-u . . . . . . . . . 10 4.3. Procedures at PLR . . . . . . . . . . . . . . . . . . . 10 4.4. Procedures at PLR-u . . . . . . . . . . . . . . . . . . 11 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6. Applicability to generic topologies . . . . . . . . . . . . . 12 7. Future work . . . . . . . . . . . . . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 10.1. Normative References . . . . . . . . . . . . . . . . . 14 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Kini & Liu Expires July 2011 [Page 3] Internet Draft Efficient Facility Backup FRR January 13, 2010 1. Introduction Fast Re-route for TE tunnels [MPLS-FRR] is widely used to realize sub 50msec protection of traffic in case of link or node failure. Specifically, the facility backup method described in [MPLS-FRR] provides a scalable mechanism to protect a large number of LSPs in sub 50msec. When applied to a ring topology this results in an in- efficient use of bandwidth and also leads to degraded service. This is described in detail with a sample topology/scenario in section 3. A solution that extends the facility backup method of [MPLS-FRR] is described in section 4. An explanation of the solution by applying it to the topology/scenario in the problem statement is provided in section 5. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALLNOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2.1. Terminology PLR-u - Point of Local Repair (PLR) Upstream. A PLR that is upstream along the protected LSP from the point of failure. This must be used in the context of a technique that conveys failure quickly from the failure point to the PLR-u so that the overall traffic loss is comparable to local repair adjacent to the failure. Path Backup Tunnel - A backup tunnel that can be used to protect many LSPs where each LSP traverses a path through the head-end and the tail-end of the path backup tunnel going through one or more intermediate facilities and LSRs. A path bypass tunnel is also a backup tunnel that bypasses a subset of the path of the protected LSP. It is also a backup path. Efficient-path backup tunnel - A path backup tunnel that improves the efficiency of backup tunnels that bypass a portion of the path that it bypasses. This is also referred to as e-backup tunnel. 3. Problem Statement Kini & Liu Expires July 2011 [Page 4] Internet Draft Efficient Facility Backup FRR January 13, 2010 +-------L1--------L2---------L3--------L4-------+ | .........>.........B1.........>............ | | . .......<.........B2.........<.......... . | | . . . . | | . . . . | L10 ^ V ^ V L5 | . . . . | | . . . . | | . ............> >............... . | | ..............< <................. | +-------L9--------L8---------L7--------L6-------+ >**************P1**************> <**************P2**************< ...... Bypass LSP ****** Protected LSP Figure 1 Facility bypass in a Ring topology The issue with backup tunnel in a ring topology is illustrated through the example in Figure 1. L1-10 are LSRs in a ring topology and say each link in the ring has 1G bandwidth. To protect the facility L8-L7, a uni-directional backup tunnel B1 is routed along L8-L9-L10-L1-L2-L3-L4-L5-L6-L7 with L8 as PLR and L7 as MP. Similarly, a uni-directional backup tunnel B2 is routed along L7-L6- L5-L4-L3-L2-L1-L10-L9-L8 with L7 as PLR and L8 as MP. A protected LSP P1 is routed along L9-L8-L7-L6 and has a bandwidth constraint of 0.6G. Another uni-directional protected LSP P2 is routed along L6-L7- L8-L9 and has bandwidth constraint of 0.6G. When facility L8-L7 fails, P1 is protection switched over B1 at PLR L8 and P2 over B2 at PLR L7, thereby bypassing the failed resource/facility. Since the aggregate bandwidth requirement on L8- >L9 becomes 1.2G (0.6G for P1 + 0.6G for B2), both P1 and P2 start experiencing degraded service. If there are other uni-directional protected LSPs e.g. P3 along the path L10-L9-L8-L7-L6, P4 along the path L8-L9, etc, they would also start experiencing degraded service. Even when P1 needs bandwidth less than 0.5G, the wraparound consumes bandwidth that would be better used by other LSPs such as P4. Note that similar issues would arise if (P1, P2) was a single bi- directional protected LSP and/or (B1, B2) was a single bi-directional bypass tunnel. 4. Solution To solve the problem described above it is required to switch the traffic from the protected LSP to a backup tunnel that does not U- Kini & Liu Expires July 2011 [Page 5] Internet Draft Efficient Facility Backup FRR January 13, 2010 turn overlap the protected LSP. This traffic switchover MUST be realized with timing characteristics similar to methods that execute local repair adjacent to the point of failure. To achieve this, an additional e-backup tunnel is proposed to be setup for any backup tunnel whose route is U-turn overlapping an LSP that it is protecting. Note that the e-backup tunnel would have its head-end and tail-end on the protected LSP. To switchover the traffic from the protected LSP to the e-backup tunnel with timing characteristics similar to a local repair method performed at a node adjacent to the failure, the head-end of the e-backup tunnel MUST receive the trigger within a very short duration after of failure. A simple and fast method to propagate the failed condition via the backup tunnel is proposed in section 4.2. It requires the head-end of the e-backup tunnel to be on the backup tunnel. The following criteria must be used to route the e-backup tunnel so that efficiency is realized: 1. The head-end of the e-backup tunnel SHOULD be at an LSR that is upstream (on the protected LSP) of the PLR where the protected LSP and the backup tunnel stop U-turn overlapping. In some scenarios it is possible that such an LSR may lack the functionality described in this draft. In such a case an LSR that has this functionality and is furthest upstream from the PLR but not beyond the LSR where the protected and the backup tunnel stop overlapping should be chosen to achieve the maximal efficiency. Since the head-end of the e-backup tunnel performs a repair by routing traffic from the protected LSP to the e- backup tunnel it is referred to as Point of Local Repair Upstream (PLR-u). The details of receiving a trigger and performing the protection switch are described in section 4.4. 2. The e-backup tunnel should be routed along the backup tunnel so that it can share reservation with the backup tunnel. It could also be routed along another path as long as resources are available and it satisfies the protection constraints of the protected LSP. 3. The tail-end of the e-backup tunnel SHOULD be at an LSR that is downstream (on the protected LSP) of the MP where the protected LSP and the backup LSP stop overlapping. The merge action at the tail-end is the same as described in [MPLS-FRR] for any backup tunnel. This document does not describe any additional procedures for the tail-end of the e-backup tunnel. Similar to a backup tunnel, an e-backup tunnel may be setup in advance or at the time a protected LSP is setup. An e-backup tunnel can make efficient the FRR of more than one backup tunnel. In a Kini & Liu Expires July 2011 [Page 6] Internet Draft Efficient Facility Backup FRR January 13, 2010 typical case an e-backup tunnel will make efficient the FRR for many NHOP Bypass Tunnels along the path that an e-backup tunnel would bypass. The following associations MUST be known in advance to setup the protection switch actions: 1. The e-backup tunnel and the protected LSP. 2. The e-backup tunnel and the backup tunnel whose FRR it is making efficient. If the protected LSP is setup via RSVP-TE then these associations can be signaled by the extensions defined in section 4.1. 4.1. RSVP-TE signaling extensions To enable e-backup path computation, the information about the backup tunnel is needed at LSRs that are upstream of the PLR. The RRO is used to record this information. This additional information is requested using the "Session Attribute" object as described in section 4.1.1. The information in the RRO is described in 4.1.2. 4.1.1. Session Attribute Object Flag: Local_protection_recording A new flag "Local protection recording desired" is defined for the "Flags" field in the Session Attribute object. This flag indicates that information about the local protection used should be included when doing a route record. 4.1.2. RRO subobjects A new RRO subobject called "Backup Session" subobject is defined. It follows an IPv4/IPv6 address sub-object (that would have "Local Protection Available" set). This subobject describes the backup LSP that protects against a failure detected at the interface corresponding to the preceding IPv4/IPv6 address sub-object. This subobject is carried in the RRO of a protected LSP. The encoding of this subobject is described in section 4.1.2.1. A new RRO subobject called "Backup Sender Template" subobject is defined. It follows the "Backup Session" subobject and is included only if the "Backup Session" subobject does not uniquely identify the backup LSP. The encoding of this subobject is described in section section 4.1.2.2. 4.1.2.1. Backup Session Subobject Kini & Liu Expires July 2011 [Page 7] Internet Draft Efficient Facility Backup FRR January 13, 2010 4.1.2.1.1. Backup_LSP_TUNNEL_IPv4 Session Suboobject 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Backup_LSP_TUNNEL_IPv4 Session Subobject (12 bytes) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved This field is reserved. It MUST be set to zero on transmission and MUST be ignored on receipt. Backup_LSP_TUNNEL_IPv4 Session subobject This must be the same as the object defined in section 4.6.1.1 of [RSVP-TE]. 4.1.2.1.2. Backup_LSP_TUNNEL_IPv6 Session Subobject 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Backup_LSP_TUNNEL_IPv6 Session Subobject (36 bytes) . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved This field is reserved. It MUST be set to zero on transmission and MUST be ignored on receipt. Backup_LSP_TUNNEL_IPv6 Session subobject This must be the same as the object defined in section 4.6.1.2 of [RSVP-TE]. Kini & Liu Expires July 2011 [Page 8] Internet Draft Efficient Facility Backup FRR January 13, 2010 4.1.2.2. Backup Sender Template Subobject 4.1.2.2.1. Backup_LSP_TUNNEL_IPv4 Sender Template Suboobject 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Backup_LSP_TUNNEL_IPv4 Sender Template Subobject (8 bytes) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved This field is reserved. It MUST be set to zero on transmission and MUST be ignored on receipt. Backup_LSP_TUNNEL_IPv4 Sender Template subobject This must be the same as the object defined in section 4.6.2.1 of [RSVP-TE]. 4.1.2.2.2. Backup_LSP_TUNNEL_IPv6 Sender Template Subobject 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Backup_LSP_TUNNEL_IPv6 Sender Template Subobject (20 bytes) . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved This field is reserved. It MUST be set to zero on transmission and MUST be ignored on receipt. Backup_LSP_TUNNEL_IPv6 Sender Template subobject This must be the same as the object defined in section 4.6.2.2 of [RSVP-TE]. Kini & Liu Expires July 2011 [Page 9] Internet Draft Efficient Facility Backup FRR January 13, 2010 4.2. Triggering protection switch at PLR-u Any LSR along the backup tunnel may be the head-end of an associated e-backup tunnel. Hence all the LSRs along a backup tunnel must be alerted immediately when a failure is detected at PLR. It is required to convey this failure information from the PLR instantaneously (except being gated by propagation delays) for the timing characteristics to be similar to methods that execute local repair adjacent to the point of failure. This document proposes using the alert mechanism in [ID.fast-lsp-alert] to convey the trigger message. A message format that can be implemented in hardware/firmware is required since the trigger should be generated and processed as quickly as possible to reduce traffic loss. Typically, implementations of [ID.BFD] fit these requirements. Hence the mechanism in [ID.BFD-MPLS] operating in the G-ACh ([RFC5586]) of the backup tunnel is proposed with an extension to signal that protection switch has occurred at PLR. A new BFD control packet diagnostic (Diag) code "Backup LSP not carrying protected traffic" is defined. It is applicable even if the "State" of the BFD session is "Up". A transit LSR along the backup tunnel may choose to ignore validating the "Authentication" section of the BFD control packet received via this alert mechanism for that backup since the end point would do the authentication and that would be sufficient to authenticate the BFD session. Similar reasoning holds true for any validation of ACH TLVs (some of them are listed in [ID.ACH-TLVs]). Also, a transit LSP along the backup tunnel that is not an upstream LSR for any of the protected LSPs, simply ignores this BFD message for local processing. 4.3. Procedures at PLR A PLR runs a BFD session on the backup tunnel's G-ACh. When the BFD session is Up, it signals the association of the protected LSPs with that backup tunnel by updating the RRO of the protected LSP as described in section 4.1. While the protection switch has not occurred at PLR and the BFD session in Up, the "Diagnostic" field in the BFD control packet is set to "Backup LSP not carrying protected traffic". When the PLR switches the protected LSP the backup tunnel, the value "Backup LSP not carrying protected traffic" is not used anymore in the "Diagnostic" field. The PLR sends the BFD Control packets on the backup tunnel in a way that all LSRs along the backup tunnel are alerted with the BFD message. To do this it uses the mechanism described [ID.fast-lsp- Kini & Liu Expires July 2011 [Page 10] Internet Draft Efficient Facility Backup FRR January 13, 2010 alert] i.e., the BFD packet is sent with TTL=1 in the LSP label, GAL TTL=255 and the FLA-bit set. The PLR may choose to not use this alert mechanism for every BFD control packet. In that case, the alert mechanism must be set for a period of at least the BFD "Detection Time" when any of the following events occur: 1. The association of a protected LSP with this backup tunnel is setup or deleted. 2. A protection switch or revert action occurs for a protected LSP to the backup (at PLR). 3. The backup tunnel is re-routed (typically with Make-before break or MBB). The BFD transmit timer must be treated as if it expired as soon as any of the above events occur. Additionally, to recover from packet loss, the BFD control packet (with the LSP alert mechanism) should be sent a couple more times within a very short duration (typically 10 milliseconds). Under stable conditions the PLR should send BFD packet with the alert mechanism enabled at a much lower frequency. It is recommended that this frequency be once every 100 * "Detection Time". 4.4. Procedures at PLR-u An upstream LSR on the protected LSP that is a transit for the backup tunnel routed in a direction opposite to the protected LSP, deduces the association between the protected LSP and the backup tunnel when processing the protected LSP's RRO. Such a LSR is a PLR-u and it creates an e-backup LSP (if one does not already exist) to a destination LSR as has been described earlier. The PLR-u associates a protection switch action of re-routing the protected LSP to the e-backup tunnel with a trigger. The trigger is an alert message received on the backup tunnel indicating that the PLR has done a protection switch action (as a result of locally detecting a failure) and re-routed the protected LSP to the backup tunnel. The PLR-u's protection switch action depends on the current status of the protection switch at PLR-u and the status of the protection switch at the PLR (known through the alert message on the backup tunnel). When the protection switch status at PLR-u is in-active i.e., the protected LSP is not re-routed to the e-backup tunnel, and the received alert message indicates that protection switch has occurred at PLR i.e., the BFD packet received as an alert message on the backup tunnel has Status as Up and the Diagnostic code is not "Backup LSP not carrying protected traffic", then the PLR-u re-routes Kini & Liu Expires July 2011 [Page 11] Internet Draft Efficient Facility Backup FRR January 13, 2010 traffic on the protected LSP over the e-backup tunnel. In all other conditions the protected LSP is not re-routed over the e-backup LSP. 5. Example Consider the scenario described in section 3. PLR (L8) creates a BFD session on B1. When the BFD session is Up, L8 appends to the RRO of P1, P3, P4, P5 the backup LSP Tunnel Session (of B1) subobject following the interface address of the link L8->L7. L9 on interpreting this subobject for P1 and also that the corresponding LSP (B1) is going in the opposite direction as P1, functions as PLR-u for P1. Using the RROs of B1, P1 and the TED, it deduces that a backup path L9-L10-L1-L2-L3-L4-L5-L6 can be used to protect P1. Say this LSP is called B3. L9 initiates a setup of B3 if it does not already exist and associates the trigger of an alert message on B1 to perform the protection switch from P1 to B3. Normally PLR-u (L9) receives a BFD control packet with FLA-bit set on the backup tunnel with "State" as "Up" and the "Diagnostic" code as "Backup LSP not carrying protected traffic". Say L8 does not set FLA-bit on all BFD control packets on the bypass. When L8 detects failure on link L8-L7 (due to loss of signal, BFD, etc), it does a protection switch of P1 to the bypass B1. It also modifies the BFD control packet for the session on B1, by clearing the "Diagnostic" code. The FLA-bit for the session is set for a short time. When PLR-u (L9) receives the G-Ach message due to FLA-bit being set, it processes the embedded BFD control packet. Since "State" is "Up" and the "Diagnostic" code is clear, L9 does a protection switch of P1 to B3. Conversely when the fault on L8-L7 clears, L8 switches traffic on P1 out of the bypass and sends it directly to L7. It also modifies the BFD control packet for the session on B1, by setting the "Diagnostic" code to "Backup LSP not carrying protected traffic". The FLA-bit for the session is set for a short time. Again PLR-u (L9) receives the G-Ach message and processes the embedded BFD control packet. Since "State" is "Up" and the "Diagnostic" code is "Backup LSP not carrying protected traffic", L9 reverts P1 by sending traffic directly to L8 instead of the backup path. 6. Applicability to generic topologies This document uses a ring topology in isolation, purely for illustrative clarity purposes. Any backup tunnel along with the segment that it is protecting, forms a logical ring. This sub-graph can be placed in any generic topology. This problem and solution would still be equally applicable. Kini & Liu Expires July 2011 [Page 12] Internet Draft Efficient Facility Backup FRR January 13, 2010 7. Future work The solution in its current form is applicable to point-to-point protected LSPs. However the problem applies to point-to-multipoint LSPs as well and a solution could follow a similar approach. Solutions to P2MP LSPs would be incorporated in future versions of this draft. Authentication parameters required by [ID.BFD] or the ACH TLVs, need to be communicated to all LSRs along the backup if it required to do authentication at each transit LSR. This can be simplified by extensions to [RSVP-TE]. 8. Security Considerations This document does not introduce new security considerations other than those already described in [MPLS-FRR], [ID.BFD] and [ID.fast- lsp-alert]. The optimization (optional) of not validating the authenticity of the BFD control packet (via authentication field or ACH TLVs) in a transit LSR of the backup tunnel should not introduce any new security threats. Note that this message is processed only when the "State" in the BFD control packet indicates Up. Any non- authentic packets would be detected by the LSRs at the LSP's end- points. Alarms would be raised by the end point and should be sufficient to diagnose potential problems. 9. IANA Considerations Values need to be allocated for: 1. "Flags" field position in SESSION_ATTRIBUTE object for newly defined flag "Local protection recording desired". Recommend using next unused field position 0x20. 2. "Type" field in RECORD_ROUTE object with C-Type 1 for newly defined subobjects Backup_LSP_TUNNEL_IPv4_Session, Backup_LSP_TUNNEL_IPv6_Session, Backup_LSP_Tunnel_IPv4_Sender_Template and Backup_LSP_TUNNEL_IPv6_Sender_Template. Recommend using values the next available values 4, 5, 6 and 7 respectively. 3. "Diagnostic" field in BFD control packet for newly defined code "Backup LSP not carrying protected traffic". Recommend using the first reserved value 9 for this purpose. 10. References Kini & Liu Expires July 2011 [Page 13] Internet Draft Efficient Facility Backup FRR January 13, 2010 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RSVP-TE] Awduche, D., et al, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC3209, December 2001. [MPLS-FRR] Pan, P., et al, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC4090, May 2005. [RFC4561] Vasseur, J. P., et al, "Definition of a Record Route Object (RRO) Node-Id Sub-Object", RFC4561, June 2006. [RFC5586] Bocci, M., et al, "MPLS Generic Associated Channel", RFC 5586, June 2009. [ID.BFD] Katz, D., et al, "Bidirectional Forwarding Detection", draft-ietf-bfd-base-11, (Work in progress), Jan 2010. [ID.BFD-MPLS] Aggarwal, R., et al, "BFD For MPLS LSPs", draft-ietf- bfd-mpls-07 (Work in progress), June 2008. [ID.ACH-TLVs] Boutros, S., et al, "Definition of ACH TLV Structure", draft-ietf-mpls-tp-ach-tlv-02 (Work in progress), March 2010. [ID.fast-lsp-alert] Kini, S., Liu, A., "A fast LSP-alert mechanism", draft-kini-mpls-tp-fast-lsp-alert-01 (Work in progress), July 2010. 11. Acknowledgements The authors would like to thank Marc Rapoport and Joel Halpern for their comments. Kini & Liu Expires July 2011 [Page 14] Internet Draft Efficient Facility Backup FRR January 13, 2010 Authors' Addresses Sriganesh Kini Ericsson 300 Holger Way, San Jose, CA 95134 EMail: sriganesh.kini@ericsson.com Autumn Liu Ericsson 300 Holger Way, San Jose, CA 95134 EMail: autumn.liu@ericsson.com Kini & Liu Expires July 2011 [Page 15]