idnits 2.17.1 draft-xiong-pce-multilayer-lsp-association-00.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 (March 10, 2017) is 2575 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 221, but not defined == Outdated reference: A later version (-10) exists of draft-ietf-pce-association-group-02 == Outdated reference: A later version (-11) exists of draft-ietf-pce-pce-initiated-lsp-09 == Outdated reference: A later version (-21) exists of draft-ietf-pce-stateful-pce-18 Summary: 1 error (**), 0 flaws (~~), 5 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: September 11, 2017 ZTE Corporation 6 March 10, 2017 8 pce multilayer lsp association 9 draft-xiong-pce-multilayer-lsp-association-00.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 http://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 September 11, 2017. 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 (http://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 . . . . . . . . . . . . . . . . 6 69 4.2.3. TE Links Optimization . . . . . . . . . . . . . . . . 6 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 72 6.1. Association Object Type . . . . . . . . . . . . . . . . . 7 73 6.2. LAYER-ASSOCIATION TLV . . . . . . . . . . . . . . . . . . 7 74 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 76 8.1. Informative References . . . . . . . . . . . . . . . . . 7 77 8.2. Normative References . . . . . . . . . . . . . . . . . . 8 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 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] and 104 [I-D.ietf-pce-stateful-pce-app]. 106 3. Overview 108 3.1. Motivation 110 In GMPLS/MPLS networks, service provider network is divided into 111 several service layers according to the requirements and customer 112 network is the upper layer with the lower layers as the Forwarding 113 Adjacency LSP (FA-LSP). The service connection is established with 114 the set up of multi-layer LSPs. 116 As discussed in [I-D.ietf-pce-stateful-pce-app] , it consists of a 117 set of one or more TE LSPs in the lower layer which provides TE links 118 to the upper layer in Multi-Layer Networks (MLN). The requirement is 119 to control of the multi-layer LSPs and related TE links. The 120 establishment or teardown of a lower layer LSP needs to take into 121 consideration the state of existing LSPs or new LSP request in the 122 upper layer. 124 As discussed in [I-D.ietf-pce-stateful-pce] , the stateful PCE MAY 125 determine to optimize the link and path based on the lower layer of 126 the LSP and its upper TE Link, and in the case of the failure of the 127 lower level LSP, it MAY update the upper network LSP path according 128 to the existing resources and the status of the LSP. 130 The stateful PCE provides the ability to update the LSP, in the 131 process of bandwidth adjustment, it MAY be necessary to adjust the 132 bandwidth of related lower layer LSPs, which provide the TE link for 133 the upper layer LSP. The association of multi-layer LSPs can reduce 134 the repeated operations and optimize the information interaction 135 between PCC and PCE. 137 In these cases, it is necessary to add multi-layer LSPs to an 138 association group. 140 3.2. Operation Overview 142 [I-D.ietf-pce-association-group] introduces a generic mechanism to 143 create a grouping of LSPs. This grouping can then be used to define 144 associations between sets of LSPs or between a set of LSPs and a set 145 of attributes. 147 In order to solve the problem of multi-layer LSP control in PCE 148 network, this document proposes the association if the multi-layer 149 LSPs. The upper LSP is associated with its related lower LSPs by 150 adding them to a multi-layer association group. 152 One new optional Association Object type is defined carried in the 153 Association object defined in [I-D.ietf-pce-association-group]. This 154 document proposes a new association type called "Layer Association 155 Type" and related TLV called "LAYER-ASSOCIATION TLV". 157 The handling and policy of multi-layer LSPs Association is similar to 158 the generic association and some processing rules as shown in session 159 4.2. 161 4. Extensions to the PCEP 163 [I-D.ietf-pce-association-group] introduces the ASSOCIATION object 164 and this document proposes a new Association type for multi-layer 165 LSPs association. 167 The format of the IPv4 Association object is shown in Figure 1: 169 0 1 2 3 170 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 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | Reserved | Flags |R| 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 | Association type=TBD | Association ID | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | IPv4 Association Source | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 // Optional TLVs // 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 Figure 1 The IPv4 ASSOCIATION Object format 182 The format of the IPv6 Association object is shown in Figure 2: 184 0 1 2 3 185 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 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | Reserved | Flags |R| 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | Association type=TBD | Association ID | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | | 192 | IPv6 Association Source | 193 | | 194 | | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 // Optional TLVs // 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 Figure 2: The IPv6 ASSOCIATION Object format 200 Association type: [TBD], 16 bits-Layer Association Type, the 201 association type for multi-layer LSPs. 203 The definition of other fields is the same with 204 [I-D.ietf-pce-association-group]. 206 4.1. LAYER-ASSOCIATION TLV 208 This document proposes LAYER-ASSOCIATION TLV for the association of 209 multi-layer LSPs. The TLV is optional. The format of the new 210 Association TLV is shown in Figure 3: 212 0 1 2 3 213 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 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | Type = TBD | Length | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | Layer Association Flags |H|L| 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 Figure 3: The LAYER-ASSOCIATION TLV format 221 The type of the TLV is [TBD] which indicates the LAYER ASSOCIATION 222 TLV. The fields in the format are: 224 Length:16bits,the length of the TLV. 226 Layer Association Flags-H:1bit, indicates LSP of the upper layer when 227 it is set. 229 Layer Association Flags-L:1bit, indicates LSP of the lower layer when 230 it is set. 232 4.2. Processing Rules 234 Once a group of multilayer LSPs is created, the upper layer LSP is 235 associated with its related lower layer LSPs. Association objects 236 can be carried in PCReq, PCRpt, PCUpd, or PCInit messages. 238 4.2.1. Multi-Layer LSPs Associations Creation 240 As defined in [I-D.ietf-pce-association-group], association groups 241 can be created by both PCC and PCE. 243 In stateless PCE, the association object with "Layer Association 244 type" is carried in PCReq message from PCC to PCE, indicating that 245 the LSP joins one existing multi-layer LSPs association group or 246 create a new one. If the LSP is belong to upper layer then set the 247 "H" bit in "LAYER-ASSOCIATION TLV", otherwise set the "L" bit when it 248 is lower layer LSP. If the association group changes, PCC needs to 249 report the relevant group changes to PCE through the PCRpt message. 251 In stateful PCE, PCE MAY create a new association group or associate 252 a LSP to an existing association group carried in PCInit message 253 after the LSP delegation from PCC to the PCE as discussed in 254 [I-D.ietf-pce-pce-initiated-lsp]. In state synchronization process 255 between PCC and PCE, PCC also need to report the existing multi-layer 256 LSPs association groups to PCE. 258 4.2.2. Bandwidth Adjustment 260 The stateful PCE provides the ability to update the LSP, in the 261 process of bandwidth adjustment, for example, enlarge the bandwidth 262 of the upper layer LSP, it MUST be necessary to adjust the bandwidth 263 of related lower layer LSPs, which provide the TE link for it. 265 Once the multi-layer LSPs associated in a group, the PCE MAY send the 266 PCUpd message to the PCE with the association object to adjust the 267 upper layer LSP. Once receiving the request, PCC will search the 268 relevant lower layer LSPs and adjust their bandwidth before the 269 adjustment of the upper layer LSP. 271 4.2.3. TE Links Optimization 273 The stateful PCE MAY determine to optimize the link and path based on 274 the lower layer of the LSP and its upper TE Link, and in the case of 275 the failure of the lower level LSP, it MAY update the upper network 276 LSP path and re-optimize resource usage across multi-layers. 278 When removing the upper layer LSP, PCC or PCE MAY release each of 279 lower layer LSPs which associated in a group and re-use the resources 280 for other upper layer LSP according to the existing resources and the 281 status of the LSP. 283 5. Security Considerations 285 TBD 287 6. IANA Considerations 289 6.1. Association Object Type 291 This document defines a new association type in Association object 292 which originally defined in [I-D.ietf-pce-association-group]. IANA 293 is requested to make allocations from the registry, as follows: 295 +--------+-------------------------+------------------+ 296 | Value | Name | Reference | 297 +--------+-------------------------+------------------+ 298 | TBD | Layer Association Type | [this document] | 299 +--------+-------------------------+------------------+ 301 Table 1 303 6.2. LAYER-ASSOCIATION TLV 305 This document defines the following TLV in Association object which 306 originally defined in [I-D.ietf-pce-association-group]. IANA is 307 requested to make allocations from the registry, as follows: 309 +--------+-----------------------+------------------+ 310 | Value | Name | Reference | 311 +--------+-----------------------+------------------+ 312 | TBD | LAYER-ASSOCIATION TLV | [this document] | 313 +--------+-----------------------+------------------+ 315 Table 2 317 7. Acknowledgements 319 TBD. 321 8. References 323 8.1. Informative References 325 [I-D.ietf-pce-stateful-pce-app] 326 Zhang, X. and I. Minei, "Applicability of a Stateful Path 327 Computation Element (PCE)", draft-ietf-pce-stateful-pce- 328 app-08 (work in progress), October 2016. 330 8.2. Normative References 332 [I-D.ietf-pce-association-group] 333 Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., 334 Zhang, X., and Y. Tanaka, "PCEP Extensions for 335 Establishing Relationships Between Sets of LSPs", draft- 336 ietf-pce-association-group-02 (work in progress), January 337 2017. 339 [I-D.ietf-pce-pce-initiated-lsp] 340 Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 341 Extensions for PCE-initiated LSP Setup in a Stateful PCE 342 Model", draft-ietf-pce-pce-initiated-lsp-09 (work in 343 progress), March 2017. 345 [I-D.ietf-pce-stateful-pce] 346 Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP 347 Extensions for Stateful PCE", draft-ietf-pce-stateful- 348 pce-18 (work in progress), December 2016. 350 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 351 Requirement Levels", BCP 14, RFC 2119, 352 DOI 10.17487/RFC2119, March 1997, 353 . 355 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 356 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 357 DOI 10.17487/RFC5440, March 2009, 358 . 360 Authors' Addresses 362 Quan Xiong 363 ZTE Corporation 364 No.6 Huashi Park Rd 365 Wuhan, Hubei 430223 366 China 368 Phone: +86 27 83531060 369 Email: xiong.quan@zte.com.cn 370 Fangwei Hu 371 ZTE Corporation 372 No.889 Bibo Rd 373 Shanghai 201203 374 China 376 Phone: +86 21 68896273 377 Email: hu.fangwei@zte.com.cn 379 Ran Chen 380 ZTE Corporation 381 No.50 Software Avenue,Yuhuatai District 382 Nanjing, Jiangsu Province 210012 383 China 385 Phone: +86 025 88014636 386 Email: chen.ran@zte.com.cn