idnits 2.17.1 draft-xiong-pce-multilayer-lsp-association-01.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 27, 2017) is 2372 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 244, but not defined == Outdated reference: A later version (-10) exists of draft-ietf-pce-association-group-04 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 30, 2018 ZTE Corporation 6 October 27, 2017 8 pce multilayer lsp association 9 draft-xiong-pce-multilayer-lsp-association-01.txt 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 30, 2018. 41 Copyright Notice 43 Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . . 4 65 4.1. LAYER-ASSOCIATION TLV . . . . . . . . . . . . . . . . . . 5 66 4.2. Processing Rules . . . . . . . . . . . . . . . . . . . . 6 67 4.2.1. Multi-Layer LSPs Associations Creation . . . . . . . 6 68 4.2.2. Bandwidth Adjustment . . . . . . . . . . . . . . . . 7 69 4.2.3. TE Links Optimization . . . . . . . . . . . . . . . . 7 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 72 6.1. Association Object Type . . . . . . . . . . . . . . . . . 7 73 6.2. LAYER-ASSOCIATION TLV . . . . . . . . . . . . . . . . . . 8 74 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 76 8.1. Informative References . . . . . . . . . . . . . . . . . 8 77 8.2. Normative References . . . . . . . . . . . . . . . . . . 8 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 80 1. Introduction 82 [RFC5440] describes the Path Computation Element Protocol (PCEP) 83 which is used between a Path Computation Element (PCE) and a Path 84 Computation Client (PCC) (or other PCE) to enable computation of 85 Multi-protocol Label Switching (MPLS) for Traffic Engineering Label 86 Switched Path (TE LSP). [I-D.ietf-pce-association-group] proposed an 87 association mechanism to create a grouping of LSPs in the context of 88 a PCE. 90 This document proposes a set of extensions to PCEP to associate a 91 grouping of multi-layer LSPs. The extensions define a mechanism to 92 create associations between upper-layer LSP and related lower-layer 93 LSPs. 95 2. Requirements Language 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in [RFC2119]. 101 2.1. Terminology 103 The terminology is defined as [RFC5440] 104 ,[I-D.ietf-pce-stateful-pce-app] and 105 [I-D.ietf-pce-association-group]. 107 3. Overview 109 3.1. Motivation 111 In GMPLS/MPLS networks, service provider network is divided into 112 several service layers according to the requirements and customer 113 network is the upper layer with the lower layers as the Forwarding 114 Adjacency LSP (FA-LSP) as shown in Figure 1. The service connection 115 is established with the set up of multi-layer LSPs. 117 Initiate & Update LSP and related lower LSPs 118 | 119 | 120 V 121 +---+--+ 122 +--------------+ PCE +---------------+ 123 | +---+--+ | 124 | | | 125 | | | 126 | | | 127 +---+--+ +---+--+ +---+--+ 128 | PCC1 +-----------+ PCC2 +-----------+ PCC3 + 129 +------+ LSP1-> +------+ LSP2-> +------+ 130 | | 131 |<------ LSP3 ----->| 133 Figure 1 Usecase for multi-layer LSPs 135 As discussed in [I-D.ietf-pce-stateful-pce-app] , it consists of a 136 set of one or more TE LSPs in the lower layer which provides TE links 137 to the upper layer in Multi-Layer Networks (MLN). The requirement is 138 to control of the multi-layer LSPs and related TE links. The 139 establishment or teardown of a lower layer LSP needs to take into 140 consideration the state of existing LSPs or new LSP request in the 141 upper layer. 143 As discussed in [I-D.ietf-pce-stateful-pce] , the stateful PCE MAY 144 determine to optimize the link and path based on the lower layer of 145 the LSP and its upper TE Link, and in the case of the failure of the 146 lower level LSP, it MAY update the upper network LSP path according 147 to the existing resources and the status of the LSP. 149 The stateful PCE provides the ability to update the LSP, in the 150 process of bandwidth adjustment, it MAY be necessary to adjust the 151 bandwidth of related lower layer LSPs, which provide the TE link for 152 the upper layer LSP. The association of multi-layer LSPs can reduce 153 the repeated operations and optimize the information interaction 154 between PCC and PCE. 156 In these cases, it is necessary to add multi-layer LSPs to an 157 association group. 159 3.2. Operation Overview 161 [I-D.ietf-pce-association-group] introduces a generic mechanism to 162 create a grouping of LSPs. This grouping can then be used to define 163 associations between sets of LSPs or between a set of LSPs and a set 164 of attributes. 166 In order to solve the problem of multi-layer LSP control in PCE 167 network, this document proposes the association if the multi-layer 168 LSPs. The upper LSP is associated with its related lower LSPs by 169 adding them to a multi-layer association group. 171 One new optional Association Object type is defined carried in the 172 Association object defined in [I-D.ietf-pce-association-group]. This 173 document proposes a new association type called "Layer Association 174 Type" and related TLV called "LAYER-ASSOCIATION TLV". 176 As defined in [I-D.ietf-pce-association-group], multi-layer LSPs 177 associations could be created dynamically or configured by the 178 operator when operator-configured association is needed. 180 The handling and policy of multi-layer LSPs Association is similar to 181 the generic association and some processing rules as shown in session 182 4.2. 184 4. Extensions to the PCEP 186 [I-D.ietf-pce-association-group] introduces the ASSOCIATION object 187 and this document proposes a new Association type for multi-layer 188 LSPs association. 190 The format of the IPv4 Association object is shown in Figure 2: 192 0 1 2 3 193 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 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | Reserved | Flags |R| 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | Association type=TBD | Association ID | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | IPv4 Association Source | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 // Optional TLVs // 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 Figure 2 The IPv4 ASSOCIATION Object format 205 The format of the IPv6 Association object is shown in Figure 3: 207 0 1 2 3 208 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 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | Reserved | Flags |R| 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | Association type=TBD | Association ID | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | | 215 | IPv6 Association Source | 216 | | 217 | | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 // Optional TLVs // 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 Figure 3: The IPv6 ASSOCIATION Object format 223 Association type: [TBD], 16 bits-Layer Association Type, the 224 association type for multi-layer LSPs. 226 The definition of other fields is the same with 227 [I-D.ietf-pce-association-group]. 229 4.1. LAYER-ASSOCIATION TLV 231 This document proposes LAYER-ASSOCIATION TLV for the association of 232 multi-layer LSPs. The TLV is optional. The format of the new 233 Association TLV is shown in Figure 4: 235 0 1 2 3 236 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 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | Type = TBD | Length | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | Layer Association Flags |H|L| 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 Figure 4: The LAYER-ASSOCIATION TLV format 244 The type of the TLV is [TBD] which indicates the LAYER ASSOCIATION 245 TLV. The fields in the format are: 247 Length:16bits,the length of the TLV. 249 Layer Association Flags-H:1bit, indicates LSP of the upper layer when 250 it is set. 252 Layer Association Flags-L:1bit, indicates LSP of the lower layer when 253 it is set. 255 4.2. Processing Rules 257 Once a group of multilayer LSPs is created, the upper layer LSP is 258 associated with its related lower layer LSPs. Association objects 259 can be carried in PCReq, PCRpt, PCUpd, or PCInit messages. 261 4.2.1. Multi-Layer LSPs Associations Creation 263 As defined in [I-D.ietf-pce-association-group], association groups 264 can be created by both PCC and PCE. 266 In stateless PCE, the association object with "Layer Association 267 type" is carried in PCReq message from PCC to PCE, indicating that 268 the LSP joins one existing multi-layer LSPs association group or 269 create a new one. If the LSP is belong to upper layer then set the 270 "H" bit in "LAYER-ASSOCIATION TLV", otherwise set the "L" bit when it 271 is lower layer LSP. 273 In stateful PCE, PCE MAY create a new association group or associate 274 a LSP to an existing association group carried in PCInit message 275 after the LSP delegation from PCC to the PCE as discussed in 276 [I-D.ietf-pce-pce-initiated-lsp]. In state synchronization process 277 between PCC and PCE, PCC also need to report the existing multi-layer 278 LSPs association groups to PCE. If the association group changes, 279 PCC needs to report the relevant group changes to PCE through the 280 PCRpt message. 282 4.2.2. Bandwidth Adjustment 284 The stateful PCE provides the ability to update the LSP, in the 285 process of bandwidth adjustment, for example, enlarge the bandwidth 286 of the upper layer LSP, it MUST be necessary to adjust the bandwidth 287 of related lower layer LSPs, which provide the TE link for it. 289 Once the multi-layer LSPs associated in a group, the PCE MAY send the 290 PCUpd message to the PCC with the association object to adjust the 291 upper layer LSP. Once receiving the request, PCC will search the 292 relevant lower layer LSPs and adjust their bandwidth before the 293 adjustment of the upper layer LSP. 295 4.2.3. TE Links Optimization 297 The stateful PCE MAY determine to optimize the link and path based on 298 the lower layer of the LSP and its upper TE Link, and in the case of 299 the failure of the lower level LSP, it MAY update the upper network 300 LSP path and re-optimize resource usage across multi-layers. 302 When removing the upper layer LSP, PCC or PCE MAY release each of 303 lower layer LSPs which associated in a group and re-use the resources 304 for other upper layer LSP according to the existing resources and the 305 status of the LSP. 307 5. Security Considerations 309 TBD 311 6. IANA Considerations 313 6.1. Association Object Type 315 This document defines a new association type in Association object 316 which originally defined in [I-D.ietf-pce-association-group]. IANA 317 is requested to make allocations from the registry, as follows: 319 +--------+-------------------------+------------------+ 320 | Value | Name | Reference | 321 +--------+-------------------------+------------------+ 322 | TBD | Layer Association Type | [this document] | 323 +--------+-------------------------+------------------+ 325 Table 1 327 6.2. LAYER-ASSOCIATION TLV 329 This document defines the following TLV in Association object which 330 originally defined in [I-D.ietf-pce-association-group]. IANA is 331 requested to make allocations from the registry, as follows: 333 +--------+-----------------------+------------------+ 334 | Value | Name | Reference | 335 +--------+-----------------------+------------------+ 336 | TBD | LAYER-ASSOCIATION TLV | [this document] | 337 +--------+-----------------------+------------------+ 339 Table 2 341 7. Acknowledgements 343 TBD. 345 8. References 347 8.1. Informative References 349 [I-D.ietf-pce-stateful-pce-app] 350 Zhang, X. and I. Minei, "Applicability of a Stateful Path 351 Computation Element (PCE)", draft-ietf-pce-stateful-pce- 352 app-08 (work in progress), October 2016. 354 8.2. Normative References 356 [I-D.ietf-pce-association-group] 357 Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., 358 Dhody, D., and Y. Tanaka, "PCEP Extensions for 359 Establishing Relationships Between Sets of LSPs", draft- 360 ietf-pce-association-group-04 (work in progress), August 361 2017. 363 [I-D.ietf-pce-pce-initiated-lsp] 364 Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 365 Extensions for PCE-initiated LSP Setup in a Stateful PCE 366 Model", draft-ietf-pce-pce-initiated-lsp-11 (work in 367 progress), October 2017. 369 [I-D.ietf-pce-stateful-pce] 370 Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP 371 Extensions for Stateful PCE", draft-ietf-pce-stateful- 372 pce-21 (work in progress), June 2017. 374 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 375 Requirement Levels", BCP 14, RFC 2119, 376 DOI 10.17487/RFC2119, March 1997, 377 . 379 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 380 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 381 DOI 10.17487/RFC5440, March 2009, 382 . 384 Authors' Addresses 386 Quan Xiong 387 ZTE Corporation 388 No.6 Huashi Park Rd 389 Wuhan, Hubei 430223 390 China 392 Phone: +86 27 83531060 393 Email: xiong.quan@zte.com.cn 395 Fangwei Hu 396 ZTE Corporation 397 No.889 Bibo Rd 398 Shanghai 201203 399 China 401 Phone: +86 21 68896273 402 Email: hu.fangwei@zte.com.cn 404 Ran Chen 405 ZTE Corporation 406 No.50 Software Avenue,Yuhuatai District 407 Nanjing, Jiangsu Province 210012 408 China 410 Phone: +86 025 88014636 411 Email: chen.ran@zte.com.cn