PCE WG Quan. Xiong Internet-Draft Fangwei. Hu Intended status: Standards Track Ran. Chen Expires: September 11, 2017 ZTE Corporation March 10, 2017 pce multilayer lsp association draft-xiong-pce-multilayer-lsp-association-00.txt 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. [I-D.ietf-pce-association-group] proposed an association mechanism for a set of LSPs. This document proposes a set of extensions to PCEP to associate a grouping of multi-layer LSPs. The extensions define a mechanism to create associations between upper-layer LSP and related lower-layer LSPs. 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 September 11, 2017. Copyright Notice Copyright (c) 2017 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 Xiong, et al. Expires September 11, 2017 [Page 1] Internet-Draft multilayer lsp association March 2017 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. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 3.2. Operation Overview . . . . . . . . . . . . . . . . . . . 4 4. Extensions to the PCEP . . . . . . . . . . . . . . . . . . . 4 4.1. LAYER-ASSOCIATION TLV . . . . . . . . . . . . . . . . . . 5 4.2. Processing Rules . . . . . . . . . . . . . . . . . . . . 6 4.2.1. Multi-Layer LSPs Associations Creation . . . . . . . 6 4.2.2. Bandwidth Adjustment . . . . . . . . . . . . . . . . 6 4.2.3. TE Links Optimization . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6.1. Association Object Type . . . . . . . . . . . . . . . . . 7 6.2. LAYER-ASSOCIATION TLV . . . . . . . . . . . . . . . . . . 7 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1. Informative References . . . . . . . . . . . . . . . . . 7 8.2. Normative References . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction [RFC5440] describes the Path Computation Element Protocol (PCEP) which is used between a Path Computation Element (PCE) and a Path Computation Client (PCC) (or other PCE) to enable computation of Multi-protocol Label Switching (MPLS) for Traffic Engineering Label Switched Path (TE LSP). [I-D.ietf-pce-association-group] proposed an association mechanism to create a grouping of LSPs in the context of a PCE. This document proposes a set of extensions to PCEP to associate a grouping of multi-layer LSPs. The extensions define a mechanism to create associations between upper-layer LSP and related lower-layer LSPs. Xiong, et al. Expires September 11, 2017 [Page 2] Internet-Draft multilayer lsp association March 2017 2. 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.1. Terminology The terminology is defined as [RFC5440] and [I-D.ietf-pce-stateful-pce-app]. 3. Overview 3.1. Motivation In GMPLS/MPLS networks, service provider network is divided into several service layers according to the requirements and customer network is the upper layer with the lower layers as the Forwarding Adjacency LSP (FA-LSP). The service connection is established with the set up of multi-layer LSPs. As discussed in [I-D.ietf-pce-stateful-pce-app] , it consists of a set of one or more TE LSPs in the lower layer which provides TE links to the upper layer in Multi-Layer Networks (MLN). The requirement is to control of the multi-layer LSPs and related TE links. The establishment or teardown of a lower layer LSP needs to take into consideration the state of existing LSPs or new LSP request in the upper layer. As discussed in [I-D.ietf-pce-stateful-pce] , the stateful PCE MAY determine to optimize the link and path based on the lower layer of the LSP and its upper TE Link, and in the case of the failure of the lower level LSP, it MAY update the upper network LSP path according to the existing resources and the status of the LSP. The stateful PCE provides the ability to update the LSP, in the process of bandwidth adjustment, it MAY be necessary to adjust the bandwidth of related lower layer LSPs, which provide the TE link for the upper layer LSP. The association of multi-layer LSPs can reduce the repeated operations and optimize the information interaction between PCC and PCE. In these cases, it is necessary to add multi-layer LSPs to an association group. Xiong, et al. Expires September 11, 2017 [Page 3] Internet-Draft multilayer lsp association March 2017 3.2. Operation Overview [I-D.ietf-pce-association-group] 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. In order to solve the problem of multi-layer LSP control in PCE network, this document proposes the association if the multi-layer LSPs. The upper LSP is associated with its related lower LSPs by adding them to a multi-layer association group. One new optional Association Object type is defined carried in the Association object defined in [I-D.ietf-pce-association-group]. This document proposes a new association type called "Layer Association Type" and related TLV called "LAYER-ASSOCIATION TLV". The handling and policy of multi-layer LSPs Association is similar to the generic association and some processing rules as shown in session 4.2. 4. Extensions to the PCEP [I-D.ietf-pce-association-group] introduces the ASSOCIATION object and this document proposes a new Association type for multi-layer LSPs association. The format of the IPv4 Association object is shown in 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Flags |R| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Association type=TBD | Association ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Association Source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Optional TLVs // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 The IPv4 ASSOCIATION Object format The format of the IPv6 Association object is shown in Figure 2: Xiong, et al. Expires September 11, 2017 [Page 4] Internet-Draft multilayer lsp association March 2017 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=TBD | Association ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | IPv6 Association Source | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Optional TLVs // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: The IPv6 ASSOCIATION Object format Association type: [TBD], 16 bits-Layer Association Type, the association type for multi-layer LSPs. The definition of other fields is the same with [I-D.ietf-pce-association-group]. 4.1. LAYER-ASSOCIATION TLV This document proposes LAYER-ASSOCIATION TLV for the association of multi-layer LSPs. The TLV is optional. The format of the new Association 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 = TBD | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Layer Association Flags |H|L| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: The LAYER-ASSOCIATION TLV format The type of the TLV is [TBD] which indicates the LAYER ASSOCIATION TLV. The fields in the format are: Length:16bits,the length of the TLV. Layer Association Flags-H:1bit, indicates LSP of the upper layer when it is set. Layer Association Flags-L:1bit, indicates LSP of the lower layer when it is set. Xiong, et al. Expires September 11, 2017 [Page 5] Internet-Draft multilayer lsp association March 2017 4.2. Processing Rules Once a group of multilayer LSPs is created, the upper layer LSP is associated with its related lower layer LSPs. Association objects can be carried in PCReq, PCRpt, PCUpd, or PCInit messages. 4.2.1. Multi-Layer LSPs Associations Creation As defined in [I-D.ietf-pce-association-group], association groups can be created by both PCC and PCE. In stateless PCE, the association object with "Layer Association type" is carried in PCReq message from PCC to PCE, indicating that the LSP joins one existing multi-layer LSPs association group or create a new one. If the LSP is belong to upper layer then set the "H" bit in "LAYER-ASSOCIATION TLV", otherwise set the "L" bit when it is lower layer LSP. If the association group changes, PCC needs to report the relevant group changes to PCE through the PCRpt message. In stateful PCE, PCE MAY create a new association group or associate a LSP to an existing association group carried in PCInit message after the LSP delegation from PCC to the PCE as discussed in [I-D.ietf-pce-pce-initiated-lsp]. In state synchronization process between PCC and PCE, PCC also need to report the existing multi-layer LSPs association groups to PCE. 4.2.2. Bandwidth Adjustment The stateful PCE provides the ability to update the LSP, in the process of bandwidth adjustment, for example, enlarge the bandwidth of the upper layer LSP, it MUST be necessary to adjust the bandwidth of related lower layer LSPs, which provide the TE link for it. Once the multi-layer LSPs associated in a group, the PCE MAY send the PCUpd message to the PCE with the association object to adjust the upper layer LSP. Once receiving the request, PCC will search the relevant lower layer LSPs and adjust their bandwidth before the adjustment of the upper layer LSP. 4.2.3. TE Links Optimization The stateful PCE MAY determine to optimize the link and path based on the lower layer of the LSP and its upper TE Link, and in the case of the failure of the lower level LSP, it MAY update the upper network LSP path and re-optimize resource usage across multi-layers. When removing the upper layer LSP, PCC or PCE MAY release each of lower layer LSPs which associated in a group and re-use the resources Xiong, et al. Expires September 11, 2017 [Page 6] Internet-Draft multilayer lsp association March 2017 for other upper layer LSP according to the existing resources and the status of the LSP. 5. Security Considerations TBD 6. IANA Considerations 6.1. Association Object Type This document defines a new association type in Association object which originally defined in [I-D.ietf-pce-association-group]. IANA is requested to make allocations from the registry, as follows: +--------+-------------------------+------------------+ | Value | Name | Reference | +--------+-------------------------+------------------+ | TBD | Layer Association Type | [this document] | +--------+-------------------------+------------------+ Table 1 6.2. LAYER-ASSOCIATION TLV This document defines the following TLV in Association object which originally defined in [I-D.ietf-pce-association-group]. IANA is requested to make allocations from the registry, as follows: +--------+-----------------------+------------------+ | Value | Name | Reference | +--------+-----------------------+------------------+ | TBD | LAYER-ASSOCIATION TLV | [this document] | +--------+-----------------------+------------------+ Table 2 7. Acknowledgements TBD. 8. References 8.1. Informative References Xiong, et al. Expires September 11, 2017 [Page 7] Internet-Draft multilayer lsp association March 2017 [I-D.ietf-pce-stateful-pce-app] Zhang, X. and I. Minei, "Applicability of a Stateful Path Computation Element (PCE)", draft-ietf-pce-stateful-pce- app-08 (work in progress), October 2016. 8.2. Normative References [I-D.ietf-pce-association-group] 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-02 (work in progress), January 2017. [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-09 (work in progress), March 2017. [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-18 (work in progress), December 2016. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, . Authors' Addresses Quan Xiong ZTE Corporation No.6 Huashi Park Rd Wuhan, Hubei 430223 China Phone: +86 27 83531060 Email: xiong.quan@zte.com.cn Xiong, et al. Expires September 11, 2017 [Page 8] Internet-Draft multilayer lsp association March 2017 Fangwei Hu ZTE Corporation No.889 Bibo Rd Shanghai 201203 China Phone: +86 21 68896273 Email: hu.fangwei@zte.com.cn Ran Chen ZTE Corporation No.50 Software Avenue,Yuhuatai District Nanjing, Jiangsu Province 210012 China Phone: +86 025 88014636 Email: chen.ran@zte.com.cn Xiong, et al. Expires September 11, 2017 [Page 9]