PCE Working Group V. Kondreddy Internet-Draft D. Dhody Intended status: Informational Huawei Technologies India Pvt Expires: January 10, 2013 Ltd July 9, 2012 Applicability of Path Computation Element (PCE) for Fast Reroute (FRR) Boundary Node protection. draft-kondreddy-pce-frr-boundary-node-app-00 Abstract Path computation element (PCE) can be used to compute a label switched path that spans across multiple domains. This document explain the mechanism of Fast Re-Route (FRR) where a point of local repair (PLR) needs to find the appropriate merge point (MP) to do bypass path computation using PCE. In case of boundary node protection when PCE confidentiality (path key) is enabled, new mechanisms are suggested in this document. Status of This Memo This Internet-Draft is submitted 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 January 10, 2013. Copyright Notice Copyright (c) 2012 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 Kondreddy & Dhody Expires January 10, 2013 [Page 1] Internet-Draft PCE-FRR-BN-APP July 2012 to this document. Code Components extracted from this document must 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 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Methods to find MP and calculate the optimal backup path . . . 5 3.1. Intra-domain node protection . . . . . . . . . . . . . . . 5 3.2. Boundary node protection . . . . . . . . . . . . . . . . . 6 3.2.1. Area Boundary Router (ABR) node protection . . . . . . 6 3.2.2. Autonomous System Border Router (ASBR) node protection . . . . . . . . . . . . . . . . . . . . . . 7 3.2.3. Boundary node protection with Path-Key Confidentiality . . . . . . . . . . . . . . . . . . . 8 3.2.3.1. Area Boundary Router (ABR) node protection . . . . 8 3.2.3.2. Autonomous System Border Router (ASBR) node protection . . . . . . . . . . . . . . . . . . . . 11 4. Manageability Considerations . . . . . . . . . . . . . . . . . 11 4.1. Control of Function and Policy . . . . . . . . . . . . . . 11 4.2. Information and Data Models . . . . . . . . . . . . . . . 11 4.3. Liveness Detection and Monitoring . . . . . . . . . . . . 11 4.4. Verify Correct Operations . . . . . . . . . . . . . . . . 11 4.5. Requirements On Other Protocols . . . . . . . . . . . . . 11 4.6. Impact On Network Operations . . . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 Kondreddy & Dhody Expires January 10, 2013 [Page 2] Internet-Draft PCE-FRR-BN-APP July 2012 1. Introduction The Path Computation Element (PCE) [RFC4655] can be used to perform complex path computation in large single domain, multi-domain and multi-layered networks. The PCE can also be used to compute a variety of restoration and protection paths and services. As stated in [RFC4090], there are two independent methods (one-to-one backup and facility backup) of doing fast reroute (FRR). PCE can be used to compute backup path for both the methods. Cooperating PCEs may be used to compute inter-domain backup path. In case of one to one backup method, the destination MUST be the tail-end of the protected LSP. Whereas for facility backup, destination MUST be the address of the merge point (MP) from the corresponding point of local repair (PLR). The problem of finding the MP using the interface addresses or node-ids present in Record Route Object (RRO) of protected path can be easily solved in the case of a single Interior Gateway Protocol (IGP) area because the PLR has the complete Traffic Engineering Database (TED). Thus, the PLR can unambiguously determine - o Is a backup tunnel intersecting a protected TE LSP on a downstream node exists? o The MP address regardless of RRO IPv4 or IPv6 sub-objects (interface address or LSR ID). It is complex for a PLR to find the MP in case of boundary node protection for computing a bypass path because the PLR doesn't have the full TED visibility. When confidentiality (via path key) [RFC5520] is enabled, finding MP is very complex. This document describes the mechanism to find MP and to setup bypass tunnel to protect a boundary node. 1.1. Requirements Language 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 RFC2119. 2. Terminology The following terminology is used in this document. Kondreddy & Dhody Expires January 10, 2013 [Page 3] Internet-Draft PCE-FRR-BN-APP July 2012 ABR: Area Border Router. Router used to connect two IGP areas (Areas in OSPF or levels in IS-IS). ASBR: Autonomous System Border Router. Router used to connect together ASes of the same or different service providers via one or more inter-AS links. BN: Boundary Node (BN) a boundary node is either an ABR in the context of inter-area Traffic Engineering or an ASBR in the context of inter-AS Traffic Engineering. CPS: Confidential Path Segment. A segment of a path that contains nodes and links that the AS policy requires not to be disclosed outside the AS. CSPF: Constrained Shorted Path First Algorithm. ERO: Explicit Route Object FRR: Fast Re-Route IGP: Interior Gateway Protocol. Either of the two routing protocols, Open Shortest Path First (OSPF) or Intermediate System to Intermediate System (IS-IS). IS-IS: Intermediate System to Intermediate System. LSP: Label Switched Path LSR: Label Switching Router MP: Merge Point. The LSR where one or more backup tunnels rejoin the path of the protected LSP downstream of the potential failure. OSPF: Open Shortest Path First. PCC: Path Computation Client: any client application requesting a path computation to be performed by a Path Computation Element. PCE: Path Computation Element. An entity (component, application, or network node) that is capable of computing a network path or route based on a network graph and applying computational constraints. PKS: Path Key Subobject. A subobject of an Explicit Route Object or Record Route Object that encodes a CPS so as to preserve confidentiality. Kondreddy & Dhody Expires January 10, 2013 [Page 4] Internet-Draft PCE-FRR-BN-APP July 2012 PLR: Point of Local Repair. The head-end LSR of a backup tunnel or a detour LSP. RRO: Record Route Object RSVP: Resource Reservation Protocol TE: Traffic Engineering. TED: Traffic Engineering Database. 3. Methods to find MP and calculate the optimal backup path The Merge Point (MP) address is required at the PLR in order to select a bypass tunnel intersecting a protected Traffic Engineering Label Switched Path (TE LSP) on a downstream LSR. Some implementations may choose to pre-configure a bypass tunnel on PLR with destination address as MP. MP's Domain to be traversed by bypass path can be administratively configured or learned via some other means (ex Hierarchical PCE (HPCE) [PCE-HIERARCHY-FWK]). Path Computation Client (PCC) on PLR can request its local PCE to compute bypass path from PLR to MP, excluding links and node between PLR and MP. At PLR once primary tunnel is up, a pre-configured bypass tunnel is bound to the primary tunnel, note that multiple bypass tunnel can also exist. Most implementations may choose to create a bypass tunnel on PLR after primary tunnel is signaled with Record Route Object (RRO) being present in primary path's Resource Reservation Protocol (RSVP) Path Reserve message. MP address has to be determined (described below) to create a bypass tunnel. PCC on PLR can request its local PCE to compute bypass path from PLR to MP, excluding links and node between PLR and MP. 3.1. Intra-domain node protection [R1]----[R2]----[R3]----[R4]---[R5] \ / [R6]--[R7]--[R8] Protected LSP Path: [R1->R2->R3->R4->R5] Bypass LSP Path: [R2->R6->R7->R8->R4] Figure 1: Node Protection for R3 In Figure 1, R2 has to build a bypass tunnel that protects against Kondreddy & Dhody Expires January 10, 2013 [Page 5] Internet-Draft PCE-FRR-BN-APP July 2012 the failure of link [R2->R3] and node [R3]. R2 is PLR and R4 is MP in this case. Since, both PLR and MP belong to the same area. The problem of finding the MP using the interface addresses or node-ids can be easily solved. Thus, the PLR can unambiguously determine whether a backup tunnel intersecting a protected TE LSP on a downstream node exists and can also find the MP address regardless of RRO IPv4 or IPv6 sub-objects (interface address or LSR ID). TED on PLR will have the information of both R2 and R4, which can be used to find MP's TE router IP address and compute optimal backup path from R2 to R4, excluding link [R2->R3] and node [R3]. Thus, RSVP-TE can signal bypass tunnel along the computed path. 3.2. Boundary node protection 3.2.1. Area Boundary Router (ABR) node protection | PCE-1 | PCE-2 | IGP area 0 | IGP area 1 | | [R1]----[R2]----[R3]----[R4]---[R5] \ | / [R6]--[R7]--[R8] | | | Protected LSP Path: [R1->R2->R3->R4->R5] Bypass LSP Path: [R2->R6->R7->R8->R4] Figure 2: Node Protection for R3 (ABR) In Figure 2, cooperating PCE(s) (PCE-1 and PCE-2) have computed the primary LSP Path [R1->R2->R3->R4->R5] and provided to R1 (PCC). R2 has to build a bypass tunnel that protects against the failure of link [R2->R3] and node [R3]. R2 is PLR and R4 is MP. Both PLR and MP are in different area. TED on PLR doesn't have the information of R4. The problem of finding the MP address in a network with inter-domain TE LSP is solved by inserting a node-id sub-object [RFC4561] in the RRO object carried in the RSVP Path Reserve message. PLR can find Kondreddy & Dhody Expires January 10, 2013 [Page 6] Internet-Draft PCE-FRR-BN-APP July 2012 out the MP from the RRO it has received in Path Reserve message from its downstream LSR. But the computation of optimal backup path from R2 to R4, excluding link [R2->R3] and node [R3] is not possible with running of Constrained Shortest Path First (CSPF) algorithm locally at R2. PCE can be used to compute backup path in this case. R2 acting as PCC on PLR can request PCE-1 to compute bypass path from PLR(R2) to MP(R4), excluding link [R2->R3] and node [R3]. PCE MAY use inter-domain path computation mechanism (like HPCE ([PCE-HIERARCHY-FWK]) etc) when the domain information of MP is unknown at PLR. Further, RSVP-TE can signal bypass tunnel along the computed path. 3.2.2. Autonomous System Border Router (ASBR) node protection | | PCE-1 | | PCE-2 | | AS 100 | | AS 200 | | | | [R1]----[R2]-------[R3]---------[R4]---[R5] |\ | / | +-----[R6]--[R7]--[R8] | | | | Protected LSP Path: [R1->R2->R3->R4->R5] Bypass LSP Path: [R2->R6->R7->R8->R4] Figure 3: Node Protection for R3 (ASBR) In Figure 3, Links [R2->R3] and [R2->R6] are inter-AS links. IGP extensions ([RFC5316] and [RFC5392]) describe the flooding of inter-AS TE information for inter-AS path computation. Cooperating PCE(s) (PCE-1 and PCE-2) have computed the primary LSP Path [R1->R2->R3->R4->R5] and provided to R1 (PCC). R2 is PLR and R4 is MP. Both PLR and MP are in different AS. TED on PLR doesn't have the information of R4. The address of MP can be found using node-id sub-object [RFC4561] in the RRO object carried in the RSVP Path Reserve message. And Cooperating PCEs could be used to compute the inter-AS bypass path. Thus ASBR boundary node protection is similar to ABR protection. Kondreddy & Dhody Expires January 10, 2013 [Page 7] Internet-Draft PCE-FRR-BN-APP July 2012 3.2.3. Boundary node protection with Path-Key Confidentiality [RFC5520] defines a mechanism to hide the contents of a segment of a path, called the Confidential Path Segment (CPS). The CPS may be replaced by a path-key that can be conveyed in the PCE Communication Protocol (PCEP) and signaled within in a Resource Reservation Protocol TE (RSVP-TE) explicit route object. [RFC5553] states that, when the signaling message crosses a domain boundary, the path segment that needs to be hidden (that is, a CPS) MAY be replaced in the RRO with a PKS. Note that RRO in Path Reserve message carries the same PKS as originally signaled in the ERO of the Path message. 3.2.3.1. Area Boundary Router (ABR) node protection | PCE-1 | PCE-2 | IGP area 0 | IGP area 1 | | [R1]----[R2]----[R3]----[R4]---[R5]---[R9] \ | / [R6]--[R7]--[R8] | | | Figure 4: Node Protection for R3 (ABR) and Path-Key In Figure 4, when path-key is enabled, cooperating PCE(s) (PCE-1 and PCE-2) have computed the primary LSP Path [R1->R2->R3->PKS->R9] and provided to R1 (PCC). Note that there isn't a way to identify the MP when path-key is enabled i.e. using node-id subobject will not work. 3.2.3.1.1. Option 1: New MP Subobject In Figure 4, on receiving ERO at R3 with PKS, it SHOULD request the PCE identified by PCE-ID in path key subobject to expand the path segment and on receiving RRO it should replace the CPS with the same PKS and append its own RRO subobjects. The boundary node can also append the identity of the MP. Note that the RRO in Path Reserve Messages can be carried as it is as ERO in Path Message. So if we use the same node-id object as described in [RFC4561] along with PKS it will lead to a looping issue Kondreddy & Dhody Expires January 10, 2013 [Page 8] Internet-Draft PCE-FRR-BN-APP July 2012 as explained below - In Figure 4, at R1 the RRO received will be [R1->R2->R3->R4->PKS->R9] with R4 as the node-id subobject added by R3. if this path is signaled using the ERO, after expansion of PKS at node R3, will lead to presence of R4 twice leading to loop. Note that the issue exists irrespective of the ordering of PKS and Node-id subobject. Hence there is a need for a new sub-object to identify the MP incase of path-key. This sub-object should be added by the boundary node (R3) during the RRO Path key processing. The PLR can use the MP sub- object to identify the MP. To avoid the looping issue, the immediate upstream LSR (usually PLR) should remove this sub-object from the RRO at the time of RRO processing. [RFC3209] defines the IPv4 and IPv6 RRO subobjects. In this document, we define the following new flag: MP-id: 0x40 (TBA) When set, this indicates that the address specified in the RRO's IPv4 or IPv6 sub-object is a MP-id address, which refers to the "Router Address" of the MP as defined in [RFC3630], or "Traffic Engineering Router ID" as defined in [RFC5305]. An IPv4 or IPv6 RRO sub-object with the MP-id flag set is also called a MP-id sub-object. The problem of finding an MP address when pathkey is enabled in a network with inter-domain TE LSP is solved by inserting a MP-id sub-object (an RRO "IPv4" and "IPv6" sub-object with the 0x40 flag (TBA) set) in the RRO object carried in the RSVP Path Reserve message. 3.2.3.1.2. Option 2: PCE Path-key Handling In Figure 4, when path-key is enabled, PCE-2 will replace the segment [R3->R4->R5->R9] with [R3->PKS->R9]. To enable FRR protection with path-key, following change should be done - o Scope of confidential path segment is relaxed to immediate downstream node i.e. [R3->R4->PKS->R9] note that R3->R4 MAYBE the address of the interface instead of LSR-ID. o Pathkey expansion during signaling would be done at the immediate downstream node of the boundary node. Note that this node must have PCC functionality. Kondreddy & Dhody Expires January 10, 2013 [Page 9] Internet-Draft PCE-FRR-BN-APP July 2012 o This facilitates the insertion of node-id sub-object [RFC4561] in the RRO object from immediate next downstream node of BN in the RSVP Path Reserve message and aids the PLR in previous domain to determine MP In Figure 4, during RSVP signaling, on receiving ERO at R4 with PKS, it SHOULD request the PCE identified by PCE-ID in path key subobject to expand the path segment and on receiving RRO it should replace the CPS with the same PKS and append its RRO subobjects including Node-id subobject. On successful signaling of primary tunnel, R2 has to build a bypass tunnel that protects against the failure of link [R2->R3] and node [R3]. Note that by above mechanism PLR (R2) knows the identity of MP (R4) via the RRO Node-id subobject. Also consider the case of R4 node protection within a single IGP area. R3 is PLR and R5 should become MP. | PCE-1 | PCE-2 | IGP area 0 | IGP area 1 | | [R10]---[R11] |/ \ [R1]----[R2]----[R3]----[R4]---[R5]---[R9] \ | / [R6]--[R7]--[R8] | | Figure 5: Node Protection for R4 In Figure 5, RRO received in RSVP Path Reserve message at R3 contains [R3->R4->PKS->R9]. Since there is no node-id sub-object in RRO beyond R4, R3 may not be able to find R5 as MP without expansion of PKS. R3 SHOULD request the PCE identified by PCE-ID in PKS to expand the path segment. Note that, the PCE should retain the pathkey for some time as multiple expansion requests will be issued. R3 can now find the identity of MP (R5). Kondreddy & Dhody Expires January 10, 2013 [Page 10] Internet-Draft PCE-FRR-BN-APP July 2012 3.2.3.2. Autonomous System Border Router (ASBR) node protection | | PCE-1 | | PCE-2 | | AS 100 | | AS 200 | | | | [R1]----[R2]-------[R3]---------[R4]---[R5] |\ | / | +-----[R6]--[R7]--[R8] | | | | Figure 6: Node Protection for R3 (ASBR) The address of MP can be found using the same mechanism as explained above. Thus ASBR boundary node protection is similar to ABR protection. 4. Manageability Considerations 4.1. Control of Function and Policy TBD 4.2. Information and Data Models TBD 4.3. Liveness Detection and Monitoring TBD 4.4. Verify Correct Operations TBD 4.5. Requirements On Other Protocols TBD 4.6. Impact On Network Operations TBD Kondreddy & Dhody Expires January 10, 2013 [Page 11] Internet-Draft PCE-FRR-BN-APP July 2012 5. Security Considerations PCE(s) when computes the inter-domain path will generate PKS relaxing the path from BN to next immediate downstream router. (Refer Section 3.2.3.1.2) This relaxation is required to find MP in case of BN node protection. This may be an added security risk. Note that the facility backup method requires that a PLR and its selected MP trust RSVP messages received from each other. Further analysis must be done. 6. IANA Considerations TBD 7. Acknowledgments We would like to thank Sandeep Boina & Reeja Paul for their useful comments and suggestions. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006. 8.2. Informative References [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. [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003. [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005. [RFC4561] Vasseur, J., Ali, Z., and S. Sivabalan, Kondreddy & Dhody Expires January 10, 2013 [Page 12] Internet-Draft PCE-FRR-BN-APP July 2012 "Definition of a Record Route Object (RRO) Node-Id Sub-Object", RFC 4561, June 2006. [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, October 2008. [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering", RFC 5316, December 2008. [RFC5392] Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering", RFC 5392, January 2009. [RFC5520] Bradford, R., Vasseur, JP., and A. Farrel, "Preserving Topology Confidentiality in Inter- Domain Path Computation Using a Path-Key-Based Mechanism", RFC 5520, April 2009. [RFC5553] Farrel, A., Bradford, R., and JP. Vasseur, "Resource Reservation Protocol (RSVP) Extensions for Path Key Support", RFC 5553, May 2009. [PCE-HIERARCHY-FWK] King, D. and A. Farrel, "The Application of the Path Computation Element Architecture to the Determination of a Sequence of Domains in MPLS and GMPLS. (draft-ietf-pce-hierarchy-fwk-04)", June 2012. Authors' Addresses Venugopal Reddy Kondreddy Huawei Technologies India Pvt Ltd Leela Palace Bangalore, Karnataka 560008 INDIA EMail: venugopalreddyk@huawei.com Kondreddy & Dhody Expires January 10, 2013 [Page 13] Internet-Draft PCE-FRR-BN-APP July 2012 Dhruv Dhody Huawei Technologies India Pvt Ltd Leela Palace Bangalore, Karnataka 560008 INDIA EMail: dhruv.dhody@huawei.com Kondreddy & Dhody Expires January 10, 2013 [Page 14]