PCE Working Group Y. Lee D. Dhody Internet-Draft Huawei Technologies Intended Status: Standards track D. Ceccarelli Ericsson Expires: August 2016 February 25, 2016 PCEP Extensions for Establishing Relationships Between Sets of LSPs and Virtual Networks draft-leedhody-pce-vn-association-00.txt Abstract This document describes how to extend PCE association mechanism introduced by [PCE-Association] to further associate sets of LSPs with a higher-level structure such as a virtual network requested by clients or applications. This extended association mechanism can be used to facilitate virtual network control using PCE architecture. 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), 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." Lee & Dhody, et al. Expires August 25, 2016 [Page 1] Internet-Draft PCEP VN Association February 2016 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 25, 2016. Copyright Notice Copyright (c) 2016 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 1.1. Requirements Language.....................................3 2. Terminology....................................................4 3. Operation Overview.............................................4 4. Extensions to PCEP.............................................4 5. Applicability to H-PCE architecture............................6 6. Security Considerations........................................7 7. IANA Considerations............................................7 7.1. Association Object Type Indicator.........................7 7.2. PCEP TLV Type Indicator...................................8 7.3. PCEP Error................................................8 8. References.....................................................8 8.1. Normative References......................................8 8.2. Informative References....................................9 Author's Addresses................................................9 1. Introduction The Path Computation Element communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path Lee & Dhody, et al. Expires August 25, 2016 [Page 2] Internet-Draft PCEP VN Association February 2016 computations in response to Path Computation Clients' (PCCs) requests. [I-D.ietf-pce-stateful-pce-app] describes general considerations for a stateful PCE deployment and examines its applicability and benefits, as well as its challenges and limitations through a number of use cases. [I-D.ietf-pce-stateful-pce] describes a set of extensions to PCEP to provide stateful control. A stateful PCE has access to not only the information carried by the network's Interior Gateway Protocol (IGP), but also the set of active paths and their reserved resources for its computations. The additional state allows the PCE to compute constrained paths while considering individual LSPs and their interactions. [I-D.ietf-pce-pce-initiated-lsp] describes the setup, maintenance and teardown of PCE-initiated LSPs under the stateful PCE model. Within the hierarchical PCE architecture, a PCE is used to initiate or delete LSPs to a PCC. [I-D.ietf-pce-association-group] introduces a generic mechanism to create a grouping of LSPs. This grouping can then be used to define association between sets of LSPs or between a set of LSPs and a set of attributes. [ACTN-REQ] describes various Virtual Network (VN) operations initiated by a customer/application. In this context, there is a need for associating a set of LSPs with a VN "construct" to facilitate VN operations in PCE architecture. This association allows the PCEs to identify which LSPs belong to a certain VN. This document specifies a PCEP extension to associate a set of LSPs based on Virtual Network or customer. 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]. Lee & Dhody, et al. Expires August 25, 2016 [Page 3] Internet-Draft PCEP VN Association February 2016 2. Terminology The terminology is as per [RFC4655], [RFC5440], [RFC6805], and [I- D.ietf-pce-stateful-pce]. 3. Operation Overview As per [I-D.ietf-pce-association-group], LSPs are associated with other LSPs with which they interact by adding them to a common association group. In this draft, this grouping is used to define associationsbetween a set of LSPs and a virtual network. One new optional Association Object-type is defined based on the generic Association object - o VN Association Group (VNAG) Thus this document define one new association type called "VN Association Type" of value TBD1. The scope and handling of VNAG identifier is similar to the generic association identifier defined in [I-D.ietf-pce-association-group]. 4. Extensions to PCEP [I-D.ietf-pce-association-group] introduces the ASSOCIATION object, the format of VNAG is as follows: Lee & Dhody, et al. Expires August 25, 2016 [Page 4] Internet-Draft PCEP VN Association February 2016 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Flags |R| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Association type=TBD1 | Association ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Association Source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Optional TLVs // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Flags |R| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Association type=TBD1 | Association ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | IPv6 Association Source | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Optional TLVs // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: The VNAG Object formats Please refer to [I-D.ietf-pce-association-group] for the definition of each field in Figure 1. This document defines one mandatory TLV. o VIRTUAL-NETWORK-TLV: Used to communicate the VN Identifier. The format of VIRTUAL-NETWORK-TLV is as follows. Lee & Dhody, et al. Expires August 25, 2016 [Page 5] Internet-Draft PCEP VN Association February 2016 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=[TBD2] | Length (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Virtual Network Name // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: The VIRTUAL-NETWORK-TLV formats Type: TBD2 (to be allocated by IANA) Length: Variable Length Virtual Network Name(variable): symbolic name for the VN. The VIRTUAL-NETWORK-TLV MUST be included in VNAG object.If a PCEP speaker receives the VNAG object without the VIRTUAL-NETWORK-TLV, it MUST send a PCErr message with Error-Type= 6 (mandatory object missing) and Error-Value=TBD3 (VIRTUAL-NETWORK-TLV missing) and close the session. 5. Applicability to H-PCE architecture The ability to compute shortest constrained TE LSPs in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across multiple domains has been identified as a key motivation for PCE development. [RFC6805] describes a Hierarchical PCE (H-PCE) architecture which can be used for computing end-to-end paths for inter-domain MPLS Traffic Engineering (TE) and GMPLS Label Switched Paths (LSPs). Within the hierarchical PCE architecture, the parent PCE is used to compute a multi-domain path based on the domain connectivity information. A child PCE may be responsible for a single domain or multiple domains, it is used to compute the intra- domain path based on its domain topology information. [I-D.ietf-dhodylee-stateful-HPCE] introduces general considerations for stateful PCE(s) in hierarchical PCE architecture. In Lee & Dhody, et al. Expires August 25, 2016 [Page 6] Internet-Draft PCEP VN Association February 2016 particular, the behavior changes and additions to the existing stateful PCE mechanisms in the context of a H-PCE architecture. In Stateful H-PCE architecture, the Parent PCE receives a virtual network creation request by its client over its Northbound API. This VN is uniquely identified by an Association ID in VNAG as well as the VIRTUAL-NETWORK name. This VN may comprise multiple LSPs in the network in a single domain or across multiple domains. As the Parent PCE computes the optimum E2E paths for each tunnel in VN, it MUST associate each LSP with the VN to which it belongs. Parent PCE sends a PCInitiate Message with this association information in the VNAG Object (See Section 4 for details). This in effect binds an LSP that is to be instantiated at the child PCE with the VN. Whenever changes occur with the instantiated LSP in a domain network, the domain child PCE reports the changes using a PCRpt Message in which the VNAG Object indicates the relationship between the LSP and the VN. Whenever an update occurs with VNs in the Parent PCE (via the client's request), the parent PCE sends an PCUpd Message to inform each affected child PCE of this change. 6. Security Considerations TDB 7. IANA Considerations 7.1. Association Object Type Indicator This document defines the following new association type originally defined in [I-D.ietf-pce-association-group]. Value Name Reference TBD1 VN Association Type [This I.D.] Lee & Dhody, et al. Expires August 25, 2016 [Page 7] Internet-Draft PCEP VN Association February 2016 7.2. PCEP TLV Type Indicator This document defines the following new PCEP TLV; IANA is requested to make the following allocations from this registry at http://www.iana.org/assignments/pcep/pcep.xhtml; see PCEP TLV Type Indicators. Value Name Reference TBD2 VIRTUAL-NETWORK-TLV [This I.D.] 7.3. PCEP Error IANA is requested to make the following allocations from this registry at http://www.iana.org/assignments/pcep/pcep.xhtml; see PCEP-ERROR Object Error Types and Values. This document defines new Error-Type and Error-Value for the following new error conditions: Error-Type Meaning 6 Mandatory Object missing Error-value=TBD3: VIRTUAL-NETWORK TLV missing 8. References 8.1. Normative References [I-D.ietf-pce-stateful-pce] E. Crabbe, I. Minei, J. Medved, and R. Varga, "PCEP Extensions for Stateful PCE", draft-ietf-pce- stateful-pce, work in progress. [I-D.ietf-pce-pce-initiated-lsp] E. Crabbe, et. al., "PCEP Extensions for PCE-initiated LSP Setup in a Stateful PCE Model", draft-ietf-pce-pce-initiated-lsp, work in progress. [I-D.ietf-pce-association-group] I, Minei, Ed., "PCEP Extensions for Establishing Relationships Between Sets of LSPs", draft- ietf-pce-association-group, work in progress. Lee & Dhody, et al. Expires August 25, 2016 [Page 8] Internet-Draft PCEP VN Association February 2016 [I-D.ietf-dhodylee-stateful-HPCE] Dhody, D. and Lee, Y., "Hierarchical Stateful Path Computation Element (PCE)", draft-dhodylee-pce-stateful-hpce, work in progress. 8.2. Informative References [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006. [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009. [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006. [RFC6805] A. Farrel and D. King, "The Application of the Path Computation Element Architecture to the Determination of a Sequence of Domains in MPLS and GMPLS", RFC 6805, November 2012. [I-D.ietf-pce-stateful-pce-app] Zhang, X., ED, and Minei, I., ED, "Applicability of a Stateful Path Computation Element (PCE)", draft-ietf-pce-stateful-pce-app, work-in-progress. [ACTN-REQ] Y. Lee, D. Dhody, S. Belotti, K. Pithewan, and D. Ceccarelli, "Requirements for Abstraction and Control of TE Networks", draft-ietf-teas-actn-requirements, work in progress. Author's Addresses Young Lee (Editor) Huawei Technologies 5340 Legacy Drive, Building 3 Plano, TX 75023, USA Email: leeyoung@huawei.com Lee & Dhody, et al. Expires August 25, 2016 [Page 9] Internet-Draft PCEP VN Association February 2016 Dhruv Dhody (Editor) Huawei Technologies Divyashree Technopark, Whitefield Bangalore, Karnataka 560037 India EMail: dhruv.ietf@gmail.com Daniele Ceccarelli Ericsson Torshamnsgatan,48 Stockholm, Sweden EMail: daniele.ceccarelli@ericsson.com Xian Zhang Huawei Technologies Email: zhang.xian@huawei.com Lee & Dhody, et al. Expires August 25, 2016 [Page 10]