idnits 2.17.1 draft-xiong-pce-multilayer-lsp-association-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.ietf-pce-association-group]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 22, 2018) is 1984 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'TBD' is mentioned on line 238, but not defined == Outdated reference: A later version (-10) exists of draft-ietf-pce-association-group-06 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE WG Quan. Xiong 3 Internet-Draft Fangwei. Hu 4 Intended status: Standards Track Ran. Chen 5 Expires: April 25, 2019 ZTE Corporation 6 October 22, 2018 8 PCE Multi-layer LSP Association 9 draft-xiong-pce-multilayer-lsp-association-02 11 Abstract 13 The Path Computation Element Communication Protocol (PCEP) provides 14 mechanisms for Path Computation Elements (PCEs) to perform path 15 computations in response to Path Computation Clients (PCCs) requests. 16 [I-D.ietf-pce-association-group] proposed an association mechanism 17 for a set of LSPs. 19 This document proposes a set of extensions to PCEP to associate a 20 grouping of multi-layer LSPs. The extensions define a mechanism to 21 create associations between upper-layer LSP and related lower-layer 22 LSPs. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on April 25, 2019. 41 Copyright Notice 43 Copyright (c) 2018 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 60 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 63 3.2. Operation Overview . . . . . . . . . . . . . . . . . . . 4 64 4. Extensions to the PCEP . . . . . . . . . . . . . . . . . . . 5 65 4.1. Association Type and Group . . . . . . . . . . . . . . . 5 66 4.2. MULTI-LAYER-ASSOCIATION TLV . . . . . . . . . . . . . . . 5 67 5. PCEP Procedure . . . . . . . . . . . . . . . . . . . . . . . 6 68 5.1. Multi-Layer LSPs Associations Creation . . . . . . . . . 6 69 5.2. Bandwidth Adjustment . . . . . . . . . . . . . . . . . . 6 70 5.3. TE Links Optimization . . . . . . . . . . . . . . . . . . 7 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 72 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 73 7.1. Association Object Type . . . . . . . . . . . . . . . . . 7 74 7.2. LAYER-ASSOCIATION TLV . . . . . . . . . . . . . . . . . . 7 75 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 76 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 77 9.1. Informative References . . . . . . . . . . . . . . . . . 8 78 9.2. Normative References . . . . . . . . . . . . . . . . . . 8 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 81 1. Introduction 83 [RFC5440] describes the Path Computation Element Protocol (PCEP) 84 which is used between a Path Computation Element (PCE) and a Path 85 Computation Client (PCC) (or other PCE) to enable computation of 86 Multi-protocol Label Switching (MPLS) for Traffic Engineering Label 87 Switched Path (TE LSP). [I-D.ietf-pce-association-group] proposed an 88 association mechanism to create a grouping of LSPs in the context of 89 a PCE. 91 This document proposes a set of extensions to PCEP to associate a 92 grouping of multi-layer LSPs. The extensions define a mechanism to 93 create associations between upper-layer LSP and related lower-layer 94 LSPs. 96 2. Requirements Language 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in [RFC2119]. 102 2.1. Terminology 104 The terminology is defined as [RFC5440] 105 ,[I-D.ietf-pce-stateful-pce-app] and 106 [I-D.ietf-pce-association-group]. 108 3. Overview 110 3.1. Motivation 112 In GMPLS/MPLS networks, service provider network is divided into 113 several service layers according to the requirements and customer 114 network is the upper layer with the lower layers as the Forwarding 115 Adjacency LSP (FA-LSP) as shown in Figure 1. The service connection 116 is established with the set up of multi-layer LSPs. 118 Initiate & Update LSP and related lower LSPs 119 | 120 | 121 V 122 +---+--+ 123 +--------------+ PCE +---------------+ 124 | +---+--+ | 125 | | | 126 | | | 127 | | | 128 +---+--+ +---+--+ +---+--+ 129 | PCC1 +-----------+ PCC2 +-----------+ PCC3 + 130 +------+ LSP1-> +------+ LSP2-> +------+ 131 | | 132 |<------ LSP3 ----->| 134 Figure 1 Usecase for multi-layer LSPs 136 As discussed in [I-D.ietf-pce-stateful-pce-app] , it consists of a 137 set of one or more TE LSPs in the lower layer which provides TE links 138 to the upper layer in Multi-Layer Networks (MLN). The requirement is 139 to control of the multi-layer LSPs and related TE links. The 140 establishment or teardown of a lower layer LSP needs to take into 141 consideration the state of existing LSPs or new LSP request in the 142 upper layer. 144 As discussed in [I-D.ietf-pce-stateful-pce] , the stateful PCE MAY 145 determine to optimize the link and path based on the lower layer of 146 the LSP and its upper TE Link, and in the case of the failure of the 147 lower level LSP, it MAY update the upper network LSP path according 148 to the existing resources and the status of the LSP. 150 The stateful PCE provides the ability to update the LSP, in the 151 process of bandwidth adjustment, it MAY be necessary to adjust the 152 bandwidth of related lower layer LSPs, which provide the TE link for 153 the upper layer LSP. The association of multi-layer LSPs can reduce 154 the repeated operations and optimize the information interaction 155 between PCC and PCE. 157 In overlayer multi-domain scenario, the lower-layer LSPs in each 158 domain may be initiated by respective domain's PCE and stitched 159 together to an association group with an end-to-end LSP as its upper- 160 layer LSP. 162 In these cases, it is necessary to add multi-layer LSPs to an 163 association group. 165 3.2. Operation Overview 167 [I-D.ietf-pce-association-group] introduces a generic mechanism to 168 create a grouping of LSPs. This grouping can then be used to define 169 associations between sets of LSPs or between a set of LSPs and a set 170 of attributes. 172 In order to solve the problem of multi-layer LSP control in PCE 173 network, this document proposes the association if the multi-layer 174 LSPs. The upper LSP is associated with its related lower LSPs by 175 adding them to a multi-layer association group. 177 One new optional Association Object type is defined carried in the 178 Association object defined in [I-D.ietf-pce-association-group]. This 179 document proposes a new association type called "Layer Association 180 Type" and related TLV called "LAYER-ASSOCIATION TLV". 182 As defined in [I-D.ietf-pce-association-group], multi-layer LSPs 183 associations could be created dynamically or configured by the 184 operator when operator-configured association is needed. 186 The handling and policy of multi-layer LSPs Association is similar to 187 the generic association and some processing rules as shown in session 188 4.2. 190 4. Extensions to the PCEP 192 4.1. Association Type and Group 194 [I-D.ietf-pce-association-group] introduces the ASSOCIATION object 195 and this document proposes a new Association type for multi-layer 196 LSPs association to associate multi-layer LSPs into one group for 197 further operation. An association ID will be used to identify the 198 group and a new Association Type is defined in this document, based 199 on the generic Association object : 201 Association type = TBD1 ("Multi-Layer Association Type") for Multi- 202 Layer Association Group (MLAG) 204 MLAG may carry optional TLVs including but not limited to : 206 MULTI-LAYER-ASSOCIATION-TLV: Used to identify the upper-layer LSP and 207 lower-layer LSP in multi-layer information, described in Section 4.2. 209 As [I-D.ietf-pce-association-group] specified, the capability 210 advertisement of the association types supported by a PCEP speaker is 211 performed by defining a ASSOC-Type-List TLV to be carried within an 212 OPEN object. The association type which defined in this document 213 should be added in the list and be advertised between the PCEP 214 speakers before the multi-layer association. 216 This Association-Type is operator-configured and created by the 217 operator manually on the PCEP peers. The LSP belonging to this 218 associations is conveyed via PCEP messages to the PCEP peer. 219 Operator-configured Association Range SHOULD NOT be set for this 220 association-type, and MUST be ignored, so that the full range of 221 association identifier can be utilized. 223 4.2. MULTI-LAYER-ASSOCIATION TLV 225 This document proposes LAYER-ASSOCIATION TLV for the association of 226 multi-layer LSPs. The TLV is optional. The format of the new 227 Association TLV is shown in Figure 4: 229 0 1 2 3 230 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 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | Type = TBD | Length | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | Layer Association Flags |H|L| 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 Figure 4: The LAYER-ASSOCIATION TLV format 238 The type of the TLV is [TBD] which indicates the LAYER ASSOCIATION 239 TLV. The fields in the format are: 241 Length:16bits,the length of the TLV. 243 Layer Association Flags-H:1bit, indicates LSP of the upper layer when 244 it is set. 246 Layer Association Flags-L:1bit, indicates LSP of the lower layer when 247 it is set. 249 5. PCEP Procedure 251 Once a group of multilayer LSPs is created, the upper layer LSP is 252 associated with its related lower layer LSPs. Association objects 253 can be carried in PCReq, PCRpt, PCUpd, or PCInit messages. 255 5.1. Multi-Layer LSPs Associations Creation 257 As defined in [I-D.ietf-pce-association-group], association groups 258 can be created by both PCC and PCE. 260 In stateless PCE, the association object with "Layer Association 261 type" is carried in PCReq message from PCC to PCE, indicating that 262 the LSP joins one existing multi-layer LSPs association group or 263 create a new one. If the LSP is belong to upper layer then set the 264 "H" bit in "LAYER-ASSOCIATION TLV", otherwise set the "L" bit when it 265 is lower layer LSP. 267 In stateful PCE, PCE MAY create a new association group or associate 268 a LSP to an existing association group carried in PCInit message 269 after the LSP delegation from PCC to the PCE as discussed in 270 [I-D.ietf-pce-pce-initiated-lsp]. In state synchronization process 271 between PCC and PCE, PCC also need to report the existing multi-layer 272 LSPs association groups to PCE. If the association group changes, 273 PCC needs to report the relevant group changes to PCE through the 274 PCRpt message. 276 5.2. Bandwidth Adjustment 278 The stateful PCE provides the ability to update the LSP, in the 279 process of bandwidth adjustment, for example, enlarge the bandwidth 280 of the upper layer LSP, it MUST be necessary to adjust the bandwidth 281 of related lower layer LSPs, which provide the TE link for it. 283 Once the multi-layer LSPs associated in a group, the PCE MAY send the 284 PCUpd message to the PCC with the association object to adjust the 285 upper layer LSP. Once receiving the request, PCC will search the 286 relevant lower layer LSPs and adjust their bandwidth before the 287 adjustment of the upper layer LSP. 289 5.3. TE Links Optimization 291 The stateful PCE MAY determine to optimize the link and path based on 292 the lower layer of the LSP and its upper TE Link, and in the case of 293 the failure of the lower level LSP, it MAY update the upper network 294 LSP path and re-optimize resource usage across multi-layers. 296 When removing the upper layer LSP, PCC or PCE MAY release each of 297 lower layer LSPs which associated in a group and re-use the resources 298 for other upper layer LSP according to the existing resources and the 299 status of the LSP. 301 6. Security Considerations 303 TBD 305 7. IANA Considerations 307 7.1. Association Object Type 309 This document defines a new association type in Association object 310 which originally defined in [I-D.ietf-pce-association-group]. IANA 311 is requested to make allocations from the registry, as follows: 313 +--------+-------------------------+------------------+ 314 | Value | Name | Reference | 315 +--------+-------------------------+------------------+ 316 | TBD | Layer Association Type | [this document] | 317 +--------+-------------------------+------------------+ 319 Table 1 321 7.2. LAYER-ASSOCIATION TLV 323 This document defines the following TLV in Association object which 324 originally defined in [I-D.ietf-pce-association-group]. IANA is 325 requested to make allocations from the registry, as follows: 327 +--------+-----------------------+------------------+ 328 | Value | Name | Reference | 329 +--------+-----------------------+------------------+ 330 | TBD | LAYER-ASSOCIATION TLV | [this document] | 331 +--------+-----------------------+------------------+ 333 Table 2 335 8. Acknowledgements 337 TBD. 339 9. References 341 9.1. Informative References 343 [I-D.ietf-pce-stateful-pce-app] 344 Zhang, X. and I. Minei, "Applicability of a Stateful Path 345 Computation Element (PCE)", draft-ietf-pce-stateful-pce- 346 app-08 (work in progress), October 2016. 348 9.2. Normative References 350 [I-D.ietf-pce-association-group] 351 Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., 352 Dhody, D., and Y. Tanaka, "PCEP Extensions for 353 Establishing Relationships Between Sets of LSPs", draft- 354 ietf-pce-association-group-06 (work in progress), June 355 2018. 357 [I-D.ietf-pce-pce-initiated-lsp] 358 Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 359 Extensions for PCE-initiated LSP Setup in a Stateful PCE 360 Model", draft-ietf-pce-pce-initiated-lsp-11 (work in 361 progress), October 2017. 363 [I-D.ietf-pce-stateful-pce] 364 Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP 365 Extensions for Stateful PCE", draft-ietf-pce-stateful- 366 pce-21 (work in progress), June 2017. 368 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 369 Requirement Levels", BCP 14, RFC 2119, 370 DOI 10.17487/RFC2119, March 1997, 371 . 373 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 374 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 375 DOI 10.17487/RFC5440, March 2009, 376 . 378 Authors' Addresses 379 Quan Xiong 380 ZTE Corporation 381 No.6 Huashi Park Rd 382 Wuhan, Hubei 430223 383 China 385 Phone: +86 27 83531060 386 Email: xiong.quan@zte.com.cn 388 Fangwei Hu 389 ZTE Corporation 390 No.889 Bibo Rd 391 Shanghai 201203 392 China 394 Phone: +86 21 68896273 395 Email: hu.fangwei@zte.com.cn 397 Ran Chen 398 ZTE Corporation 399 No.50 Software Avenue,Yuhuatai District 400 Nanjing, Jiangsu Province 210012 401 China 403 Phone: +86 025 88014636 404 Email: chen.ran@zte.com.cn