PCE Working Group I. Minei Internet-Draft E. Crabbe Intended status: Standards Track Google, Inc. Expires: December 29, 2014 S. Sivabalan Cisco Systems, Inc. H. Ananthakrishnan Juniper Networks, Inc. X. Zhang Huawei Technologies Y. Tanaka NTT Communications Corporation June 27, 2014 PCEP Extensions for establishing relationships between sets of LSPs draft-minei-pce-association-group-00 Abstract This document introduces a generic mechanism to create a grouping of LSPs in the context of stateful PCE. This grouping can then be used to define associations between sets of LSPs or between a set of LSPs and a set of attributes (such as configuration parameters or behaviors), and is equally applicable to the active and passive modes of stateful PCE. 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]. 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 December 29, 2014. Minei, et al. Expires December 29, 2014 [Page 1] Internet-Draft PCE association group June 2014 Copyright Notice Copyright (c) 2014 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 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Architectural Overview . . . . . . . . . . . . . . . . . . . 3 3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 3.2. Operation overview . . . . . . . . . . . . . . . . . . . 3 4. LSP association groups . . . . . . . . . . . . . . . . . . . 4 5. Using the LSP association group . . . . . . . . . . . . . . . 4 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 5 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 9.1. Normative References . . . . . . . . . . . . . . . . . . 6 9.2. Informative References . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction [RFC5440] describes the Path Computation Element Protocol PCEP. PCEP enables the communication between a Path Computation Client (PCC) and a Path Control Element (PCE), or between PCE and PCE, for the purpose of computation of Multiprotocol Label Switching (MPLS) for Traffic Engineering Label Switched Path (TE LSP) characteristics. Stateful pce [I-D.ietf-pce-stateful-pce] specifies a set of extensions to PCEP to enable stateful control of TE LSPs between and across PCEP sessions in compliance with [RFC4657] and focuses on a model where LSPs are configured on the PCC and control over them is delegated to the PCE. The model of operation where LSPs are initiated from the PCE is described in [I-D.ietf-pce-pce-initiated-lsp]. Minei, et al. Expires December 29, 2014 [Page 2] Internet-Draft PCE association group June 2014 This document introduces a generic mechanism to create a grouping of LSPs. This grouping can then be used to define associations between sets of LSPs or between a set of LSPs and a set of attributes (such as configuration parameters or behaviors), and is equally applicable to the active and passive modes of stateful PCE. 2. Terminology This document uses the following terms defined in [RFC5440]: PCC, PCE, PCEP Peer. 3. Architectural Overview 3.1. Motivation Stateful PCE provides the ability to update existing LSPs and to instantiate new ones. To enable support for PCE-controlled make- before-break and for protection, there is a need to define associations between LSPs. For example, the association between the original and the reoptimized path in the make-before break scenario, or between the working and protection path in end-to-end protection. Another use for LSP grouping is for applying a common set of configuration parameters or behaviors to a set of LSPs. Rather than creating separate mechanisms for each use case, this draft defines a generic one. 3.2. Operation overview LSPs are associated with other LSPs with which they interact by adding them to a common association group. Association groups as defined in this document are locally meaningful at the LSP head-end, and can only be applied to LSPs originating at that head end. Thus, the association identifiers are unique at each head end, but not necessarily across the network, and are owned and managed by the head end. Multiple types of groups can exist, each with their own identifiers space. The definition of the different association types and their behaviors is outside the scope of this document. The establishment and removal of the association relationship can be done on a per LSP basis. There is support for removal of all LSPs from an association as well. An LSP may join multiple association groups, of different or of the same type. Minei, et al. Expires December 29, 2014 [Page 3] Internet-Draft PCE association group June 2014 4. LSP association groups Association groups are owned by the PCC, but the PCE may request creation of an association group (for example before instantiating LSPs that belong to that group). Membership in an association group can be initiated by either the PCE or the PCC. Association groups and their memberships are defined using the Association object. The Association Object is an optional object in the PCupd, PCRpt and PCinit messages. The format of the Association object is shown Figure 1: 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 | Generic flags |R| Type-specific flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Association group id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Optional TLVs // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: The Association Object format Type - the association type (for example protection or make-before- break). The association type will be defined in separate documents. Generic flags - flags for the association object. A single one is defined, the R flag indicating removal from the association group. Type-specific flags - specific to the association type, will be defined at the time of the association type. Association group id - identifier of the association group. The values 0 and 0xffffffff are reserved. Value 0 is used when the PCE requests allocation of an association group. Value 0xffffffff indicates all association groups. 5. Using the LSP association group Membership in an association group is reported in PCRpt messages by including the association object along with the LSP object. Removal of the LSP from the association group on the PCC (for example through configuration) is reported by including the association object with the R flag set. When an LSP belongs to multiple association groups, Minei, et al. Expires December 29, 2014 [Page 4] Internet-Draft PCE association group June 2014 multiple association objects are included in the PCRpt, one for each association the LSP belongs to. A PCE can associate an LSP that was delegated to it (the candidate LSP) with an existing association group, by sending a PCUpd for the candidate LSP, including the Association Object for the association group. Error handling for this operation will be defined in a future version of this draft. An association group can be created locally at the PCC (for example through configuration) or it can be requested by the PCE. A PCE may request the creation of an association group by sending a PCUpd message with the reserved value 0. In response to this request, the PCC will allocate an association group id and report it in the PCRpt message. Error handling will be defined in a future version of this draft. Note that this operation includes creation of the group and association of one LSP with this group. Requesting the creation of an association group before the LSP exists will be handled in a future version of this draft. 6. IANA considerations This document defines the following new PCEP Object-classes and Object-values: Object-Class Value Name Reference TBD Association This document Object-Type 1 This document requests that a registry is created to manage the Flags field of the Association object. New values are to be assigned by Standards Action [RFC5226]. 7. Security Considerations The security considerations described in [I-D.ietf-pce-stateful-pce] apply to the extensions described in this document. Additional considerations related to a malicious PCE are introduced, as the PCE may now create additional state on the PCC through the creation of association groups. 8. Acknowledgements We would like to thank Yuji Kamite and Joshua George for their contributions to this document. Minei, et al. Expires December 29, 2014 [Page 5] Internet-Draft PCE association group June 2014 9. References 9.1. Normative References [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-01 (work in progress), June 2014. [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-09 (work in progress), June 2014. [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. and JL. Le Roux, "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009. 9.2. Informative References [I-D.tanaka-pce-stateful-pce-mbb] Tanaka, Y., Kamite, Y., and D. Dhody, "Make-Before-Break MPLS-TE LSP restoration and reoptimization procedure using Stateful PCE", draft-tanaka-pce-stateful-pce-mbb-03 (work in progress), February 2014. [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006. [RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC 4657, September 2006. Authors' Addresses Minei, et al. Expires December 29, 2014 [Page 6] Internet-Draft PCE association group June 2014 Ina Minei Google, Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 US Email: inaminei@google.com Edward Crabbe Google, Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 US Email: edc@google.com Siva Sivabalan Cisco Systems, Inc. 170 West Tasman Dr. San Jose, CA 95134 US Email: msiva@cisco.com Hariharan Ananthakrishnan Juniper Networks, Inc. 1194 N. Mathilda Ave. Sunnyvale, CA 94089 US Email: hanantha@juniper.net Xian Zhang Huawei Technologies F3-5-B R&D Center, Huawei Base Bantian, Longgang District Shenzhen, Guangdong 518129 P.R.China Email: zhang.xian@huawei.com Minei, et al. Expires December 29, 2014 [Page 7] Internet-Draft PCE association group June 2014 Yosuke Tanaka NTT Communications Corporation Granpark Tower 3-4-1 Shibaura, Minato-ku Tokyo 108-8118 Japan Email: yosuke.tanaka@ntt.com Minei, et al. Expires December 29, 2014 [Page 8]