PCE Working Group C. Barth Internet-Draft Juniper Networks Intended status: Standards Track R. Gandhi Expires: November 22, 2017 Cisco Systems, Inc. B. Wen Comcast May 21, 2017 PCEP Extensions for Associated Bidirectional Label Switched Paths (LSPs) draft-barth-pce-association-bidir-02 Abstract The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients (PCCs) requests. The Stateful PCE extensions allow stateful control of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Label Switched Paths (LSPs) using PCEP. This document defines PCEP extensions for binding two reverse unidirectional MPLS TE LSPs into an Associated Bidirectional Label Switched Path (LSP) when using a Stateful PCE for both PCE-Initiated and PCC-Initiated LSPs as well as when using a Stateless PCE. 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." Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. Barth, et al. Expires November 22, 2017 [Page 1] Internet-Draft PCEP For Associated Bidirectional LSPs May 21, 2017 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 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. Conventions Used in This Document . . . . . . . . . . . . . . 4 2.1. Key Word Definitions . . . . . . . . . . . . . . . . . . . 4 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Single-sided Initiation . . . . . . . . . . . . . . . . . 5 3.2. Double-sided Initiation . . . . . . . . . . . . . . . . . 5 3.3. Co-routed Associated Bidirectional LSP . . . . . . . . . . 6 4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 6 4.1. Association Object . . . . . . . . . . . . . . . . . . . . 6 4.2. Bidirectional LSP Association Group TLV . . . . . . . . . 6 5. PCEP Procedure . . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. PCE Initiated LSPs . . . . . . . . . . . . . . . . . . . . 8 5.2. PCC Initiated LSPs . . . . . . . . . . . . . . . . . . . . 8 5.3. Stateless PCE . . . . . . . . . . . . . . . . . . . . . . 8 5.4. State Synchronization . . . . . . . . . . . . . . . . . . 8 5.5. Error Handling . . . . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. Manageability Considerations . . . . . . . . . . . . . . . . . 9 7.1. Control of Function and Policy . . . . . . . . . . . . . . 9 7.2. Information and Data Models . . . . . . . . . . . . . . . 9 7.3. Liveness Detection and Monitoring . . . . . . . . . . . . 9 7.4. Verify Correct Operations . . . . . . . . . . . . . . . . 9 7.5. Requirements On Other Protocols . . . . . . . . . . . . . 9 7.6. Impact On Network Operations . . . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8.1. Association Types . . . . . . . . . . . . . . . . . . . . 10 8.2. Bidirectional LSP Association Group TLV . . . . . . . . . 10 8.2.1. Flag Fields in Bidirectional LSP Association Group TLV . . . . . . . . . . . . . . . . . . . . . . . . . 10 8.3. PCEP Errors . . . . . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 9.2. Informative References . . . . . . . . . . . . . . . . . . 12 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 14 Barth, et al. Expires November 22, 2017 [Page 2] Internet-Draft PCEP For Associated Bidirectional LSPs May 21, 2017 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 1. Introduction [RFC5440] describes the Path Computation Element Protocol (PCEP) as a communication mechanism between a Path Computation Client (PCC) and a Path Control Element (PCE), or between PCE and PCC, that enables computation of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Label Switched Paths (LSPs). [I-D.ietf-pce-stateful-pce] specifies extensions to PCEP to enable stateful control of MPLS TE LSPs. It describes two modes of operation - Passive Stateful PCE and Active Stateful PCE. In [I- D.ietf-pce-stateful-pce], the focus is on Active Stateful PCE where LSPs are provisioned on the PCC and control over them is delegated to a PCE. Further, [I-D.ietf-pce-pce-initiated-lsp] describes the setup, maintenance and teardown of PCE-Initiated LSPs for the Stateful PCE model. [I-D.ietf-pce-association] introduces a generic mechanism to create a grouping of LSPs which can then be used to define associations between a set of LSPs and/or a set of attributes, for example primary and secondary LSP associations, and is equally applicable to the active and passive modes of a Stateful PCE [I-D.ietf-pce-stateful- pce] or a stateless PCE [RFC5440]. The MPLS Transport Profile (MPLS-TP) requirements document [RFC5654] specifies that MPLS-TP MUST support associated bidirectional point- to-point LSPs. [RFC7551] specifies RSVP signaling extensions for binding two reverse unidirectional LSPs into an associated bidirectional LSP. The fast reroute (FRR) procedures for associated bidirectional LSPs are described in [I-D.ietf-teas-assoc-corouted- bidir-frr]. This document specifies PCEP extensions for binding two reverse unidirectional MPLS-TE LSPs into an Associated Bidirectional LSP for both single-sided and double-sided initiation cases when using a Stateful or Stateless PCE. The PCEP extensions cover the following cases: o A PCE initiates the forward and/ or reverse LSP of a single-sided or double-sided bidirectional LSP on a PCC and retains the control of the LSP. The PCE computes the path of the LSP and updates the PCC with the information about the path. o A PCC initiates the forward and/ or reverse LSP of a single-sided bidirectional LSP and retains the control of the LSP. The PCC Barth, et al. Expires November 22, 2017 [Page 3] Internet-Draft PCEP For Associated Bidirectional LSPs May 21, 2017 computes the path of the LSP and updates the PCE with the information about the path (as long as it controls the LSP). o A PCC initiates the forward and/ or reverse LSP of a single-sided bidirectional LSP and delegates the control of the LSP to a Stateful PCE. The PCE may compute the path of the LSP and update the PCC with the information about the path (as long as it controls the LSP). o A PCC requests co-routed or non co-routed paths for forward and reverse LSPs of a bidirectional LSP from a Stateless PCE. 2. Conventions Used in This Document 2.1. Key Word Definitions 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.2. Terminology The reader is assumed to be familiar with the terminology defined in [RFC5440] and [RFC7551]. 3. Overview As shown in Figure 1, two reverse unidirectional LSPs can be associated to form an associated bidirectional LSP. There are two methods of initiating the bidirectional LSP association, single-sided and double-sided as described in the following sections. LSP1 --> LSP1 --> LSP1 --> +-----+ +-----+ +-----+ +-----+ | A +-----------+ B +-----------+ C +-----------+ D | +-----+ +--+--+ +--+--+ +-----+ <-- LSP2 | | <-- LSP2 | | | | +--+--+ +--+--+ | E +-----------+ F | +-----+ +-----+ <-- LSP2 Figure 1: Example of Associated Bidirectional LSP Barth, et al. Expires November 22, 2017 [Page 4] Internet-Draft PCEP For Associated Bidirectional LSPs May 21, 2017 3.1. Single-sided Initiation As specified in [RFC7551], in the single-sided initiation case, the bidirectional tunnel is signaled only by one endpoint node (PCC) of the tunnel. Both forward and reverse LSPs of this tunnel are initiated with the Association Type set to "Single-sided Bidirectional LSP Association" on the originating endpoint node. The forward and reverse LSPs are identified in the Bidirectional LSP Association Group TLV of their PCEP Association Objects. The originating endpoint node signals the properties for the revere LSP in the RSVP REVERSE_LSP Object [RFC7551] of the forward LSP Path message. The remote endpoint then creates the corresponding reverse tunnel and signals the reverse LSP in response to the received RSVP Path message. The two unidirectional reverse LSPs on the originating endpoint node are bound together using the PCEP Association Object and on the remote endpoint node by the RSVP signaled Association Object. As shown in Figure 1, both the forward LSP LSP1 and the reverse LSP LSP2 are initiated on the originating endpoint node A, either by the PCE or the PCC. The creation of reverse LSP2 on the remote endpoint node D is triggered by the RSVP signaled LSP1. As specified in [I-D.ietf-teas-assoc-corouted-bidir-frr], for fast- reroute bypass tunnel assignment, the LSP starting from the originating node is identified as the forward LSP of the single-sided initiated bidirectional LSP. 3.2. Double-sided Initiation As specified in [RFC7551], in the double-sided initiation case, the bidirectional LSP is signaled by the both endpoint nodes (PCCs) of the tunnel. The forward and reverse LSPs of this tunnel are initiated with the Association Type set to "Double-sided Bidirectional LSP Association" on both endpoint nodes. The forward and reverse LSPs are identified in the Bidirectional LSP Association Group TLV of their Association Objects. The two reverse unidirectional LSPs on both the endpoint nodes are bound together by using the PCEP Association Object. As shown in Figure 1, LSP1 is initiated on the endpoint node A and LSP2 is initiated on the endpoint node D, both by the PCE. As specified in [I-D.ietf-teas-assoc-corouted-bidir-frr], for fast- reroute bypass tunnel assignment, the LSP with the higher source Barth, et al. Expires November 22, 2017 [Page 5] Internet-Draft PCEP For Associated Bidirectional LSPs May 21, 2017 address is identified as the forward LSP of the double-sided initiated bidirectional LSP. 3.3. Co-routed Associated Bidirectional LSP In both single-sided and double-sided initiation cases, forward and reverse LSPs may be co-routed as shown in Figure 2, where both forward and reverse LSPs follow the same congruent path. LSP3 --> LSP3 --> LSP3 --> +-----+ +-----+ +-----+ +-----+ | A +-----------+ B +-----------+ C +-----------+ D | +-----+ +-----+ +-----+ +-----+ <-- LSP4 <-- LSP4 <-- LSP4 Figure 2: Example of Co-routed Associated Bidirectional LSP 4. Protocol Extensions 4.1. Association Object As per [I-D.ietf-pce-association], LSPs are associated by adding them to a common association group. This document defines two new Bidirectional LSP Association Groups to be used by the associated bidirectional LSPs. A member of the Bidirectional LSP Association Group can take the role of a forward or reverse LSP. The reverse LSP source address MUST be the destination address of the forward LSP and the reverse LSP destination address MUST be the source address of the forward LSP within a bidirectional LSP association group. An LSP can not be part of more than one Bidirectional LSP Association Group. This document defines two new Association Types for the Association Object as follows: o Association Type (TBD1) = Single-sided Bidirectional LSP Association Group o Association Type (TBD2) = Double-sided Bidirectional LSP Association Group The Association ID, Association Source, optional Global Association Source and optional Extended Association ID in the Bidirectional LSP Association Group Object are populated using the procedures defined in [RFC7551]. 4.2. Bidirectional LSP Association Group TLV Barth, et al. Expires November 22, 2017 [Page 6] Internet-Draft PCEP For Associated Bidirectional LSPs May 21, 2017 The Bidirectional LSP Association Group TLV is an optional TLV for use with the Single-sided and Double-sided Bidirectional LSP Association Group Object Types. o The Bidirectional LSP Association Group TLV follows the PCEP TLV format from [RFC5440]. o The Type (16 bits) of the TLV is TBD3, to be assigned by IANA. o The Length is 4 Bytes. o The value comprises of a single field, the Bidirectional LSP Association Flags (32 bits), where each bit represents a flag option. o If the Bidirectional LSP Association Group TLV is missing, it means the LSP is the forward LSP. o The Bidirectional LSP Association Group TLV MUST NOT be present more than once. If it appears more than once, only the first occurrence is processed and any others MUST be ignored. The format of the Bidirectional LSP Association Group TLV is shown in Figure 3: 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 = TBD3 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved |C|R|F| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Bidirectional LSP Association Group TLV format Bidirectional LSP Association Flags are defined as following. F (Forward LSP, 1 bit) - Indicates whether the LSP associated is the forward LSP of the bidirectional LSP. If this flag is set, the LSP is a forward LSP. R (Reverse LSP, 1 bit) - Indicates whether the LSP associated is the reverse LSP of the bidirectional LSP. If this flag is set, the LSP is a reverse LSP. C (Co-routed LSP, 1 bit) - Indicates whether the bidirectional LSP is co-routed. If this flag is set, the associated bidirectional LSP Barth, et al. Expires November 22, 2017 [Page 7] Internet-Draft PCEP For Associated Bidirectional LSPs May 21, 2017 is co-routed. This flag MUST be set for both the forward and reverse LSPs of a co-routed bidirectional LSP. The Reserved flags MUST be set to 0 when sent and MUST be ignore when received. When an associated bidirectional LSP is delegated to a Stateful PCE, the C flag is used by the PCE to compute paths of the forward and reverse LSPs. 5. PCEP Procedure 5.1. PCE Initiated LSPs As specified in [I-D.ietf-pce-association], Association Groups can be created by both Stateful PCE and PCC. A Stateful PCE can create and update the forward and reverse LSPs independently for both Single-sided and Double-sided bidirectional LSP association groups. 5.2. PCC Initiated LSPs A PCC can associate or remove an LSP under its control from the bidirectional LSP association group. The PCC must report the change in association to Stateful PCE via PCRpt message. 5.3. Stateless PCE A PCC can request co-routed or non co-routed forward and reverse direction paths from a stateless PCE for the bidirectional LSP association group. 5.4. State Synchronization During state synchronization, a PCC MUST report all the existing bidirectional LSP association groups to the Stateful PCE. After the state synchronization, the PCE MUST remove all stale associations. 5.5. Error Handling The reverse LSP in the bidirectional LSP association group MUST have the source address matching the destination address of the forward LSP and destination address matching the source address of the forward LSP. If a PCE attempts to add an LSP to a bidirectional LSP association group not complying to this rule, the PCC for the single- sided initiation case MUST send PCErr with Error-Type= TBD4 Barth, et al. Expires November 22, 2017 [Page 8] Internet-Draft PCEP For Associated Bidirectional LSPs May 21, 2017 (Bidirectional LSP Association Error) and Error-Value = 1 (Endpoints mismatch). Similarly, if a PCC attempts to add an LSP to a bidirectional LSP association group at PCE not complying to this rule, the PCE for both single-sided and double-sided initiated bidirectional LSPs MUST send this PCErr. 6. Security Considerations This document introduces two new Association Types for the Association Object, Double-sided Bidirectional LSP Association Group and Single-sided Associated Bidirectional LSP Group. These types, by themselves, introduce no additional security concerns beyond those discussed in [RFC5440], [I-D.ietf-pce-stateful-pce], and [I-D.ietf- pce-association]. 7. Manageability Considerations 7.1. Control of Function and Policy An operator MUST be allowed to provision the bidirectional LSP association parameters at PCEP peers. 7.2. Information and Data Models A Management Information Base (MIB) module for modeling PCEP is described in [RFC7420]. However, one may prefer the mechanism for configuration using YANG data model [I-D.ietf-pce-pcep-yang]. These SHOULD be enhanced to provide controls and indicators for support of the associated bidirectional LSP feature. Support for various configuration parameters as well as counters of messages sent/received containing the TLVs defined in this document SHOULD be added. 7.3. Liveness Detection and Monitoring The mechanisms defined in this document do not imply any new liveness detection and monitoring requirements in addition to those already listed in [RFC5440]. 7.4. Verify Correct Operations The mechanisms defined in this document do not imply any new operation verification requirements in addition to those already listed in [RFC5440]. 7.5. Requirements On Other Protocols Barth, et al. Expires November 22, 2017 [Page 9] Internet-Draft PCEP For Associated Bidirectional LSPs May 21, 2017 The mechanisms defined in this document do not add any new requirements on other protocols. 7.6. Impact On Network Operations The mechanisms defined in this document do not have any new impact on network operations. 8. IANA Considerations 8.1. Association Types This document defines the following Association Types for the Association Object defined [I-D.ietf-pce-association]. Value Name Reference --------------------------------------------------------------------- TBD1 Single-sided Bidirectional LSP Association Group [This document] TBD2 Double-sided Bidirectional LSP Association Group [This document] 8.2. Bidirectional LSP Association Group TLV This document defines a new TLV for carrying additional LSP information for the Bidirectional LSP Association Group TLV as following: TLV-Type Name Reference ------------------------------------------------------------------- TBD3 Bidirectional LSP Association Group TLV [This document] 8.2.1. Flag Fields in Bidirectional LSP Association Group TLV This document requests that a new sub-registry, named "Bidirectional LSP Association Group TLV Flag Field", is created within the "Path Computation Element Protocol (PCEP) Numbers" registry to manage the Flag field in the Bidirectional LSP Association Group TLV. New values are to be assigned by Standards Action [RFC5226]. Each bit should be tracked with the following qualities: o Bit number (counting from bit 0 as the most significant bit) o Capability description o Defining RFC Barth, et al. Expires November 22, 2017 [Page 10] Internet-Draft PCEP For Associated Bidirectional LSPs May 21, 2017 The following values are defined in this document for the Flag field. Bit No. Description Reference --------------------------------------------------------- 31 F - Forward LSP [This document] 30 R - Reverse LSP [This document] 29 C - Co-routed LSP [This document] 8.3. PCEP Errors IANA is requested to allocate new Error-Type and Error-Value within the " PCEP-ERROR Object Error Types and Values" sub-registry of the PCEP Numbers registry, as follows: Error-Type Description Reference ----------------------------------------------------------------- TBD4 Bidirectional LSP Association Error [This document] Error-value=1: Endpoints mismatch [This document] Barth, et al. Expires November 22, 2017 [Page 11] Internet-Draft PCEP For Associated Bidirectional LSPs May 21, 2017 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009. [RFC7551] Zhang, F., Ed., Jing, R., and Gandhi, R., Ed., "RSVP-TE Extensions for Associated Bidirectional LSPs", RFC 7551, May 2015. [I-D.ietf-pce-association] Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., Zhang, X., and Y. Tanaka, "PCEP Extensions for Establishing Relationships Between Sets of LSPs", draft-ietf-pce-association-group (work in progress). [I-D.ietf-pce-stateful-pce] Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP Extensions for Stateful PCE", draft-ietf- pce-stateful-pce (work in progress). [I-D.ietf-pce-pce-initiated-lsp] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP Extensions for PCE-initiated LSP Setup in a Stateful PCE Model", draft-ietf-pce-pce- initiated-lsp (work in progress). [I-D.ietf-teas-assoc-corouted-bidir-frr] Gandhi, R., Ed., Shah, H., and J. Whittaker, "Fast Reroute Procedures for Associated Bidirectional Label Switched Paths", draft-ietf-teas- assoc-corouted-bidir-frr (work-in-progress). 9.2. Informative References [RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., Sprecher, N., and S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, September 2009. [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. Hardwick, "Path Computation Element Communication Protocol (PCEP) Management Information Base (MIB) Module", RFC Barth, et al. Expires November 22, 2017 [Page 12] Internet-Draft PCEP For Associated Bidirectional LSPs May 21, 2017 7420, December 2014. [I-D.ietf-pce-pcep-yang] Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A YANG Data Model for Path Computation Element Communications Protocol (PCEP)", draft-ietf-pce-pcep-yang (work in progress). Barth, et al. Expires November 22, 2017 [Page 13] Internet-Draft PCEP For Associated Bidirectional LSPs May 21, 2017 Acknowledgments TBA. Authors' Addresses Colby Barth Juniper Networks Email: cbarth@juniper.net Rakesh Gandhi Cisco Systems, Inc. Email: rgandhi@cisco.com Bin Wen Comcast Email: Bin_Wen@cable.comcast.com Barth, et al. Expires November 22, 2017 [Page 14]