Internet Engineering Task Force H. Chen Internet-Draft Huawei Technologies Intended status: Standards Track N. So Expires: May 2, 2012 Verizon Inc. A. Liu Ericsson October 30, 2011 Extensions to RSVP-TE for P2MP LSP Ingress Local Protection draft-chen-mpls-p2mp-ingress-protection-04.txt Abstract This document describes extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for locally protecting the ingress node of a Traffic Engineered (TE) Point-to-MultiPoint (P2MP) Label Switched Path (LSP) in a Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) network. Status of this Memo 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). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on May 2, 2012. Copyright Notice Copyright (c) 2011 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. Code Components extracted from this document must Chen, et al. Expires May 2, 2012 [Page 1] Internet-Draft P2MP LSP Ingress Protection October 2011 include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Conventions Used in This Document . . . . . . . . . . . . . . 4 4. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. An Example of Ingress Local Protection . . . . . . . . . . 4 4.2. Set up of Backup P2MP sub Tree . . . . . . . . . . . . . . 5 4.3. Forwarding State for Backup P2MP sub Tree . . . . . . . . 5 4.4. Detection of Failure around Ingress . . . . . . . . . . . 6 5. Ingress Local Protection with FRR . . . . . . . . . . . . . . 6 6. LSP Information Message . . . . . . . . . . . . . . . . . . . 7 6.1. Format of LSP Information Message . . . . . . . . . . . . 7 6.2. Processing of LSP Information Message . . . . . . . . . . 8 7. PATH Messages for Backup P2MP sub Tree . . . . . . . . . . . . 8 7.1. Construction of PATH Messages . . . . . . . . . . . . . . 8 7.2. Processing of PATH Messages . . . . . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 10.1. Normative References . . . . . . . . . . . . . . . . . . . 10 10.2. Informative References . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Chen, et al. Expires May 2, 2012 [Page 2] Internet-Draft P2MP LSP Ingress Protection October 2011 1. Introduction RFC4090 "Fast Reroute Extensions to RSVP-TE for LSP Tunnels" describes two methods to protect P2P LSP tunnels or paths at local repair points. For a P2P LSP, the local repair points may comprise a number of intermediate nodes between the ingress node and the egress node of the P2P LSP. The first method is a one-to-one backup method, where a detour backup P2P LSP for each protected P2P LSP is created at each potential point of local repair. The second method is a facility bypass backup protection method, where a bypass backup P2P LSP tunnel is created using MPLS label stacking to protect a potential failure point for a set of P2P LSP tunnels. The bypass backup tunnel can protect a set of P2P LSPs that have similar backup constraints. RFC4875 "Extensions to RSVP-TE for P2MP TE LSPs" describes how to use the one-to-one backup method and facility bypass backup method to protect a link or intermediate node failure on the path of a P2MP LSP. However, there is no mention of locally protecting an ingress node failure in a protected P2MP LSP. There exist two methods for protecting an ingress node of a P2MP LSP. The first method deploys a backup P2MP LSP from a backup ingress node to the destination nodes to protect the ingress node. The main disadvantage of this method is that the backup P2MP LSP consumes additional network bandwidth along the entire LSP paths. The impact on network efficiency can be significant in case of large P2MP deployments. In addition, the backup LSP often has to be manually constructed so that the backup P2MP LSP does not route through the unprotected ingress node, and it has to be linked to the primary LSP logically at the head-end to allow the fast switching in case of ingress failure. The second method extends the existing ways of protecting an intermediate node of a P2P LSP to protect an ingress node of a P2MP LSP. The disadvantages of this method include extra work for refreshing PATH messages and processing RESV messages for the P2MP LSP in the backup ingress node. This document defines extensions to RSVP-TE for locally protecting an ingress node of a Traffic Engineered (TE) point-to-multipoint (P2MP) Label Switched Path (LSP) through using a backup P2MP sub tree. The new method overcomes the disadvantages described above. It can also be applied for protecting an ingress node of a TE point-to-point (P2P) LSP since a TE P2P LSP can be considered as a special case of a TE P2MP LSP. Chen, et al. Expires May 2, 2012 [Page 3] Internet-Draft P2MP LSP Ingress Protection October 2011 2. Terminology This document uses terminologies defined in RFC2205, RFC3031, RFC3209, RFC3473, RFC4090, RFC4461, and RFC4875. 3. Conventions Used in This Document The key words "MUST", "MUST NOT","REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. 4. Mechanism This section briefly describes a solution that locally protects an ingress node of a P2MP LSP through using a backup P2MP sub tree. We start with a simple example, and then present different parts of the solution, which includes the creation of the backup P2MP sub tree, the forwarding state for the backup P2MP sub tree, and the detection of a failure in the ingress node. 4.1. An Example of Ingress Local Protection Figure 1 below illustrates an example of using a backup P2MP sub tree to locally protect the ingress of a P2MP LSP. The P2MP LSP to be protected is from ingress node R1 to three egress/leaf nodes: L1, L2 and L3. The backup P2MP sub tree used to protect the ingress node R1 is from backup ingress node Ra to the next hop nodes R2 and R4 of the ingress node R1 along the P2MP LSP. The traffic from source S may be delivered to both R1 and Ra. R1 introduces the traffic into the P2MP LSP, which is sent to the egress/leaf nodes L1, L2 and L3 along the P2MP LSP. Ra normally does not put the traffic into the backup P2MP sub tree, which is from Ra to R2 and R4. There may be a BFD session between ingress node R1 and backup ingress node Ra. Ra uses this BFD session to detect the failure of ingress R1. When Ra detects the failure of R1, it imports the traffic from the source S into the backup P2MP sub tree. The traffic from the sub tree is merged into the P2MP LSP at R2 and R4, and then sent to the egress/leaf nodes L1, L2 and L3 along the P2MP LSP. Chen, et al. Expires May 2, 2012 [Page 4] Internet-Draft P2MP LSP Ingress Protection October 2011 [R2]======[R3]=====[L1] // | // | // | // | // / // / // / +---[R1]======[R4]====[R5]=====[L2] | ! / / \\ | ! / / \\ [S]--| ! / / \\ | ! / / \\ | !/ / \\ +---[Ra]---[Rb] \\ \\ \\ [L3] Figure 1: P2MP sub Tree for Locally Protecting Ingress After the failure of the ingress node R1, the refresh of the PATH messages for the ingress node is not needed. Each of the next-hop nodes of the ingress node will receive the PATH messages and the refresh of the PATH messages for the backup P2MP sub tree from the backup ingress node Ra, which make the P2MP LSP alive. 4.2. Set up of Backup P2MP sub Tree For the ingress node of the P2MP LSP, a backup ingress node is designated to protect it. The ingress node sends the P2MP LSP information to the backup ingress node. The backup ingress node initiates the creation of the backup P2MP sub tree from itself to the next-hop nodes of the ingress node. The backup ingress node sets up the backup P2MP sub tree in a way similar to setting up a P2MP tree or LSP from the signaling's point of view. It constructs and sends RSVP-TE PATH messages along the path for the backup P2MP sub tree with the final destinations (i.e, egress/leaf nodes) matching the P2MP LSP. It receives and processes RSVP-TE RESV messages that response to the PATH messages. 4.3. Forwarding State for Backup P2MP sub Tree The forwarding state for the backup P2MP sub tree is different from that for a P2MP LSP. After receiving the RSVP-TE RESV messages for the backup P2MP sub tree, the backup ingress node creates a Chen, et al. Expires May 2, 2012 [Page 5] Internet-Draft P2MP LSP Ingress Protection October 2011 forwarding entry with an inactive state or flag. This forwarding entry with an inactive state or flag is called an inactive forwarding entry. In a normal operation, this inactive forwarding entry is not used to forward any data traffic to be transported by the P2MP LSP, even though the data traffic may be delivered to the backup ingress node from an external node such as source node S in the above example or network. The forwarding entry for the P2MP LSP is with an active state or flag. Thus when the data traffic from the external node or network reaches the ingress node of the P2MP LSP, it is imported into the P2MP LSP tunnel through the active forwarding entry on the ingress node. When the ingress node fails, the inactive forwarding entry on the backup ingress node is changed to active. Thus when the data traffic from the external node reaches the backup ingress node, it is imported into the backup P2MP sub tree. When the traffic arrives at the next-hop nodes through the backup P2MP sub tree, it is merged into the P2MP LSP to be transported to the destinations. 4.4. Detection of Failure around Ingress There can be two different failure scenarios involving the ingress node of a P2MP LSP that need to be detected. o The failure of the ingress node (e.g. R1 of figure 1). o The failure of the link between the source node and the ingress node (e.g. the link between node S and node R1 in figure 1). A failure of the ingress node can be detected through a BFD session between the ingress node and the backup ingress node. A failure of the link between the source node and the ingress node can be detected by a BFD session running over the link and to the backup ingress via the ingress. After the backup ingress node detects any failure involving the ingress node, it imports the traffic from the source node into the backup P2MP sub tree. The traffic from the backup ingress node via the sub tree is merged into the P2MP LSP on the next-hop nodes of the ingress of the P2MP LSP, and then transported to the egress/leaf nodes of the P2MP LSP. 5. Ingress Local Protection with FRR RFC4875 "Extensions to RSVP-TE for P2MP TE LSPs" describes how to use the existing FRR to locally protect failures in a link or intermediate node of a P2MP LSP. Thus, the ingress node , all the Chen, et al. Expires May 2, 2012 [Page 6] Internet-Draft P2MP LSP Ingress Protection October 2011 links and the intermediate nodes of a P2MP LSP can be locally protected through using the ingress local protection mechanism described above and the FRR. The ingress node of the P2MP LSP can be locally protected through using the ingress local protection. All the links and all the intermediate nodes of the P2MP LSP can be locally protected through using the FRR. All the intermediate nodes of the P2MP LSP may be locally protected by some other methods such as the method proposed in "P2MP MPLS-TE Fast Reroute with P2MP Bypass Tunnels". Note that the methods for locally protecting all the links and the intermediate nodes of a P2MP LSP are out of scope of this document. 6. LSP Information Message LSP information messages are used to transfer the information about a P2MP LSP to a backup ingress node from an ingress node. This section describes the format of an LSP information message and processing of the message. 6.1. Format of LSP Information Message The format of a P2MP LSP information message is illustrated below. ::= [ ] [ [ | ] ...] [ ] [ ] [ ] [ ... ] [ ] [ ] [ ] [ ... ] [] Chen, et al. Expires May 2, 2012 [Page 7] Internet-Draft P2MP LSP Ingress Protection October 2011 The formats and values of the objects in a P2MP LSP information message are similar to or the same as those of the corresponding objects defined in RFC4875. The value of the Msg Type field in the common header in the P2MP LSP information message will be a new number such as 68 for the LSP information message, or may be another number assigned by Internet Assigned Numbers Authority (IANA). 6.2. Processing of LSP Information Message Similar to sending an existing RSVP-TE message such as a PATH message, the primary ingress MUST send a updated RSVP-TE LSP information message to the backup ingress whenever there is a change in the RSVP-TE LSP information message. It MAY send the same RSVP-TE LSP information message to the backup ingress every refresh interval if there is no change. When the backup ingress receives the RSVP-TE LSP information message from the primary ingress, it stores the LSP information, constructs PATH messages, and sends the PATH messages downstream accordingly. If it has not received any RSVP-TE LSP information message for an extended period of time (e.g. a cleanup timeout interval) and the BFD session between the primary ingress and backup ingress is up, it SHALL remove the information about the P2MP LSP, constructs PathTear messages, and send the PathTear messages downstream accordingly. When the BFD session between the primary ingress and backup ingress is down, the backup ingress MUST keep the information about the P2MP LSP and the state of the backup P2MP sub tree even though it has not received any RSVP-TE LSP information message for an extended period of time. It refreshes the PATH messages downstream for the backup P2MP sub tree. 7. PATH Messages for Backup P2MP sub Tree PATH messages for a backup P2MP sub tree has the same format as PATH messages for a P2MP LSP defined in RFC 4875. This section describes the construction of the PATH messages for the backup P2MP sub tree, which is followed by processing of the PATH messages. 7.1. Construction of PATH Messages When the backup ingress node receives a P2MP LSP information message, it checks to see if anything has been changed. If the message is a new message or the information in the message has been changed, then the PATH messages for the backup P2MP sub tree are to be constructed Chen, et al. Expires May 2, 2012 [Page 8] Internet-Draft P2MP LSP Ingress Protection October 2011 as follows. First, a path to the next-hop nodes of the ingress node HAS to be computed. The path MUST satisfy the constraints for the P2MP LSP and not go through the ingress node. If a path is computed successfully, then the PATH messages for the backup P2MP sub tree are constructed based on the computed path and the information message received, and sent downstream accordingly. After sending the PATH messages, the backup ingress node receives RESV messages from downstream nodes responding to the PATH messages. It then processes the RESV messages and creates forwarding state based on the information in the RESV messages. If a path can not be found, the backup ingress node SHALL tear down the backup P2MP sub tree created based the previous information message. The construction of a PATH message on a backup ingress node for a backup P2MP sub tree is similar to the construction of a normal PATH message on an ingress node for a P2MP LSP. It is based on LSP information messages and a computed path for the backup P2MP sub tree. The EXPLICIT_ROUTE object and the objects in the S2L sub-LSP descriptor list for the PATH message may be constructed through combining the path computed to the next-hop nodes of the ingress node and the path from the next-hop nodes to the destination nodes of the P2MP LSP obtained from the RECORD_ROUTE object and the objects for the S2L sub-LSP flow descriptor list in the LSP information messages. 7.2. Processing of PATH Messages The processing of PATH messages on the intermediate nodes and the destination nodes along the backup P2MP sub tree is the same as the processing of PATH messages for a P2MP LSP. 8. IANA Considerations TBD 9. Acknowledgement The authors would like to thank Richard Li, Rahul Aggarwal, Neil Harrison, Lei Liu, Kannan Sampath, Yimin Shen and Quintin Zhao for their valuable comments and suggestions on this draft. Chen, et al. Expires May 2, 2012 [Page 9] Internet-Draft P2MP LSP Ingress Protection October 2011 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, January 2004. [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997. [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005. [RFC4461] Yasukawa, S., "Signaling Requirements for Point-to- Multipoint Traffic-Engineered MPLS Label Switched Paths (LSPs)", RFC 4461, April 2006. [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May 2007. [P2MP FRR] Le Roux, J., Aggarwal, R., Vasseur, J., and M. Vigoureux, "P2MP MPLS-TE Fast Reroute with P2MP Bypass Tunnels", draft-leroux-mpls-p2mp-te-bypass , March 1997. 10.2. Informative References [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999. Chen, et al. Expires May 2, 2012 [Page 10] Internet-Draft P2MP LSP Ingress Protection October 2011 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001. Authors' Addresses Huaimo Chen Huawei Technologies Boston, MA USA Email: Huaimochen@huawei.com Ning So Verizon Inc. 2400 North Glenville Drive Richardson, TX 75082 USA Email: Ning.So@verizonbusiness.com Autumn Liu Ericsson CA USA Email: autumn.liu@ericsson.com Chen, et al. Expires May 2, 2012 [Page 11]