idnits 2.17.1 draft-ietf-pce-inter-layer-ext-11.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 16, 2016) is 2718 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) == Outdated reference: A later version (-11) exists of draft-ietf-pce-pce-initiated-lsp-07 == Outdated reference: A later version (-21) exists of draft-ietf-pce-stateful-pce-16 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-23) exists of draft-ietf-pce-pcep-yang-01 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group E. Oki 3 Internet-Draft University of Electro-Communications 4 Intended status: Standards Track T. Takeda 5 Expires: May 20, 2017 NTT 6 A. Farrel 7 Juniper Networks 8 F. Zhang 9 Huawei Technologies Co., Ltd. 10 November 16, 2016 12 Extensions to the Path Computation Element communication Protocol (PCEP) 13 for Inter-Layer MPLS and GMPLS Traffic Engineering 14 draft-ietf-pce-inter-layer-ext-11 16 Abstract 18 The Path Computation Element (PCE) provides path computation 19 functions in support of traffic engineering in Multiprotocol Label 20 Switching (MPLS) and Generalized MPLS (GMPLS) networks. 22 MPLS and GMPLS networks may be constructed from layered service 23 networks. It is advantageous for overall network efficiency to 24 provide end-to-end traffic engineering across multiple network layers 25 through a process called inter-layer traffic engineering. PCE is a 26 candidate solution for such requirements. 28 The PCE communication Protocol (PCEP) is designed as a communication 29 protocol between Path Computation Clients (PCCs) and PCEs. This 30 document presents PCEP extensions for inter-layer traffic 31 engineering. 33 Requirements Language 35 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 36 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 37 document are to be interpreted as described in [RFC2119]. 39 Status of This Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at http://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on May 20, 2017. 56 Copyright Notice 58 Copyright (c) 2016 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (http://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the Simplified BSD License. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 74 2. Overview of PCE-Based Inter-Layer Path Computation . . . . . 4 75 3. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 4 76 3.1. INTER-LAYER Object . . . . . . . . . . . . . . . . . . . 4 77 3.2. SWITCH-LAYER Object . . . . . . . . . . . . . . . . . . . 7 78 3.3. REQ-ADAP-CAP Object . . . . . . . . . . . . . . . . . . . 9 79 3.4. New Metric Types . . . . . . . . . . . . . . . . . . . . 10 80 3.5. SERVER-INDICATION Object . . . . . . . . . . . . . . . . 10 81 4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 11 82 4.1. Path Computation Request . . . . . . . . . . . . . . . . 11 83 4.2. Path Computation Reply . . . . . . . . . . . . . . . . . 12 84 4.3. Stateful PCE and PCE Initiated LSPs . . . . . . . . . . . 13 85 5. Updated Format of PCEP Messages . . . . . . . . . . . . . . . 13 86 6. Manageability Considerations . . . . . . . . . . . . . . . . 15 87 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 88 7.1. New PCEP Objects . . . . . . . . . . . . . . . . . . . . 16 89 7.2. New Registry for INTER-LAYER Object Flags . . . . . . . . 16 90 7.3. New Metric Types . . . . . . . . . . . . . . . . . . . . 17 91 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 92 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 93 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18 94 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 95 11.1. Normative References . . . . . . . . . . . . . . . . . . 18 96 11.2. Informative References . . . . . . . . . . . . . . . . . 19 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 100 1. Introduction 102 The Path Computation Element (PCE) defined in [RFC4655] is an entity 103 that is capable of computing a network path or route based on a 104 network graph, and applying computational constraints. A Path 105 Computation Client (PCC) may make requests to a PCE for paths to be 106 computed, and a PCE may initiate or modify services in a network by 107 supplying new paths ([I-D.ietf-pce-stateful-pce], 108 [I-D.ietf-pce-pce-initiated-lsp]). 110 A network may comprise multiple layers. These layers may represent 111 separations of technologies (e.g., packet switch capable (PSC), time 112 division multiplex (TDM), lambda switch capable (LSC)) [RFC3945], 113 separation of data plane switching granularity levels (e.g., VC4 and 114 VC12) [RFC5212], or a distinction between client and server 115 networking roles (e.g., commercial or administrative separation of 116 client and server networks). In this multi-layer network, Label 117 Switched Paths (LSPs) in lower layers are used to carry higher-layer 118 LSPs. The network topology formed by lower-layer LSPs and advertised 119 as traffic engineering links (TE links) in the higher layer is called 120 a Virtual Network Topology (VNT) [RFC5212]. Discussion of other ways 121 that network layering can be support such that connectivity in a 122 higher layer network can be provided by LSPs in a lower layer network 123 is provided in [RFC7926]. 125 It is important to optimize network resource utilization globally, 126 i.e., taking into account all layers, rather than optimizing resource 127 utilization at each layer independently. This allows better network 128 efficiency to be achieved. This is what we call inter-layer traffic 129 engineering. This includes mechanisms allowing the computation of 130 end-to-end paths across layers (known as inter-layer path 131 computation), and mechanisms for control and management of the VNT by 132 setting up and releasing LSPs in the lower layers [RFC5212]. 134 PCE can provide a suitable mechanism for resolving inter-layer path 135 computation issues. The framework for applying the PCE-based path 136 computation architecture to inter-layer traffic engineering is 137 described in [RFC5623]. 139 The PCE communication protocol (PCEP) is designed as a communication 140 protocol between PCCs and PCEs and is defined in [RFC5440]. A set of 141 requirements for PCEP extensions to support inter-layer traffic 142 engineering is described in [RFC6457]. 144 This document presents PCEP extensions for inter-layer traffic 145 engineering that satisfy the requirements described in [RFC6457]. 147 2. Overview of PCE-Based Inter-Layer Path Computation 149 [RFC4206] defines a way to signal a higher-layer LSP which has an 150 explicit route that includes hops traversed by LSPs in lower layers. 151 The computation of end-to-end paths across layers is called Inter- 152 Layer Path Computation. 154 A Label Switching Router (LSR) in the higher-layer might not have 155 information on the lower-layer topology, particularly in an overlay 156 or augmented model [RFC3945], and hence may not be able to compute an 157 end-to-end path across layers. 159 PCE-based inter-layer path computation consists of using one or more 160 PCEs to compute an end-to-end path across layers. This could be 161 achieved by relying on a single PCE that has topology information 162 about multiple layers and can directly compute an end-to-end path 163 across layers considering the topology of all of the layers. 164 Alternatively, the inter-layer path computation could be performed 165 using multiple cooperating PCEs where each PCE has information about 166 the topology of one or more layers (but not all layers) and where the 167 PCEs collaborate to compute an end-to-end path. 169 As described in [RFC5339], a hybrid nodes may advertise a single TE 170 link with multiple switching capabilities. Those TE links exist at 171 the layer/region boarder normally. In this case, PCE needs to be 172 capable of specifying the server layer path information when the 173 server layer path information is required to be returned to the PCC. 175 [RFC5623] describes models for inter-layer path computation in more 176 detail. 178 3. Protocol Extensions 180 This section describes PCEP extensions for inter-layer path 181 computation. Four new objects are defined: the INTER-LAYER object, 182 the SWITCH-LAYER object, the REQ-ADAP-CAP object, and the SERVER- 183 INDICATION object. Also, two new metric types are defined. 185 3.1. INTER-LAYER Object 187 The INTER-LAYER object is optional and can be used in PCReq and PCRep 188 messages, and also in PCRpt, PCUpd, and PCInitiate message. 190 In a PCReq message, the INTER-LAYER object indicates whether inter- 191 layer path computation is allowed, the type of path to be computed, 192 and whether triggered signaling (hierarchical LSPs per [RFC4206] or 193 stitched LSPs per [RFC5150] depending on physical network 194 technologies) is allowed. When the INTER-LAYER object is absent from 195 a PCReq message, the receiving PCE MUST process as though inter-layer 196 path computation had been explicitly disallowed (I-bit set to zero - 197 see below). 199 In a PCRep message, the INTER-LAYER object indicates whether inter- 200 layer path computation has been performed, the type of path that has 201 been computed, and whether triggered signaling is used. 203 When a PCReq message includes more than one request, an INTER-LAYER 204 object is used per request. When a PCRep message includes more than 205 one path per request that is responded to, an INTER-LAYER object is 206 used per path. 208 The applicability of this object to PCRpt and PCUpd messages follows 209 as the usage of other objects on those messages as described in 210 [I-D.ietf-pce-stateful-pce]. The applicability of this object to the 211 PCInitiate message follows as the usage of other objects on those 212 messages as described in [I-D.ietf-pce-pce-initiated-lsp]. These 213 messages use the as defined in [RFC5440] and 214 extended by further PCEP extensions, and so the as 215 extended in Section 5 can be used to include the INTER-LAYER object 216 on these messages. 218 INTER-LAYER Object-Class TBD1 to be assigned by IANA. 220 INTER-LAYER Object-Type 1 to be assigned by IANA. 222 The format of the INTER-LAYER object body is shown in Figure 1. 224 0 1 2 3 225 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 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | Reserved |T|M|I| 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 Figure 1: The INTER-LAYER Object 232 I flag (1 bit): The I flag is used by a PCC in a PCReq message to 233 indicate to a PCE whether an inter-layer path is allowed. When the I 234 flag is set (one), the PCE MAY perform inter-layer path computation 235 and return an inter-layer path. When the flag is clear (zero), the 236 path that is returned MUST NOT be an inter-layer path. 238 The I flag is used by a PCE in a PCRep message to indicate to a PCC 239 whether the path returned is an inter-layer path. When the I flag is 240 set (one), the path is an inter-layer path. When it is clear (zero), 241 the path is contained within a single layer either because inter- 242 layer path computation was not performed or because a mono-layer path 243 (without any virtual TE link and without any loose hop that spans the 244 lower-layer network) was found notwithstanding the use of inter-layer 245 path computation. 247 M flag (1 bit): The M flag is used by a PCC in a PCReq message to 248 indicate to a PCE whether mono-layer path or multi-layer path is 249 requested. When the M flag is set (one), multi-layer path is 250 requested. When it is clear (zero), mono-layer path is requested. 252 The M flag is used by a PCE in a PCRep message to indicate to a PCC 253 whether mono-layer path or multi-layer path is returned. When M flag 254 is set (one), multi-layer path is returned. When M flag is set 255 (zero), mono-layer path is returned. 257 If the I flag is clear (zero), the M flag has no meaning and MUST be 258 ignored. 260 [RFC6457] describes two sub-options for mono-layer path. 262 o A mono-layer path that is specified by strict hops. The path may 263 include virtual TE links. 265 o A mono-layer path that includes loose hops that span the lower- 266 layer network. 268 The choice of this sub-option can be specified by the use of O flag 269 in the RP object specified in [RFC5440]. 271 T flag (1 bit): The T flag is used by a PCC in a PCReq message to 272 indicate to a PCE whether triggered signaling is allowed. When the T 273 flag is set (one), triggered signaling is allowed. When it is clear 274 (zero), triggered signaling is not allowed. 276 The T flag is used by a PCE in a PCRep message to indicate to a PCC 277 whether triggered signaling is required to support the returned path. 278 When the T flag is set (one), triggered signaling is required. When 279 it is clear (zero), triggered signaling is not required. 281 Note that triggered signaling is used to support hierarchical 282 [RFC4206] or stitched (xref target="RFC5150" /> LSPs according to the 283 physical attributes of the network layers. 285 If the I flag is clear (zero), the T flag has no meaning and MUST be 286 ignored. 288 Note that the I flag and M flag differ in the following ways. When 289 the I flag is clear (zero), virtual TE links must not be used in path 290 computation. In addition, loose hops that span the lower-layer 291 network must not be specified. Only regular TE links from the same 292 layer may be used. 294 o When the I flag is set (one), the M flag is clear (zero), and the 295 T flag is set (one), virtual TE links are allowed in path 296 computation. In addition, when the O flag of the RP object is 297 set, loose hops that span the lower-layer network may be 298 specified. This will initiate lower-layer LSP setup, thus inter- 299 layer path is setup even though the path computation result from a 300 PCE to a PCC include hops from the same layer only. 302 o However, when the I flag is set (one), the M flag is clear (zero), 303 and the T flag is clear (zero), since triggered signaling is not 304 allowed, virtual TE links must not be used in path computation. 305 In addition, loose hops that span the lower-layer network must not 306 be specified. Therefore, this is equivalent to the I flag being 307 clear (zero). 309 Reserved bits of the INTER-LAYER object SHOULD be transmitted as zero 310 and SHOULD be ignored on receipt. A PCE that forwards a path 311 computation request to other PCEs SHOULD preserve the settings of 312 reserved bits in the PCReq messages it sends and in the PCRep 313 messages it forwards to PCCs. 315 Note that the flags in the PCRpt message indicate the state of an 316 LSP, whereas the flags in the PCUpd and the PCInitiate messages 317 indicate the intended/desired state as determined by the PCE. 319 3.2. SWITCH-LAYER Object 321 The SWITCH-LAYER object is optional on a PCReq message and specifies 322 switching layers in which a path MUST, or MUST NOT, be established. 323 A switching layer is expressed as a switching type and encoding type. 325 When a SWITCH-LAYER object is used on a PCReq it is interpreted in 326 the context of the INTER-LAYER object on the same message. If no 327 INTER-LAYER object is present, the PCE MUST process the SWITCH-LAYER 328 object as though inter-layer path computation had been explicitly 329 disallowed. In such a case, the SWITCH-LAYER object MUST NOT have 330 more than one LSP Encoding Type and Switching Type with the I flag 331 set. 333 The SWITCH-LAYER object is optional on a PCRep message, where it is 334 used with the NO-PATH object in the case of unsuccessful path 335 computation to indicate the set of constraints that could not be 336 satisfied. 338 The SWTCH-LAYER object may be used on a PCRpt message consistent with 339 how properties of existing LSPs are reported on that message 340 [I-D.ietf-pce-stateful-pce]. The PCRpt message uses the as defined in [RFC5440] and extended by further PCEP 342 extensions. This message can use the as extended in 343 Section 5 to carry the SWITCH-LAYER object. The SWTCH-LAYER object 344 is not used on a PCUpd or PCInitiate message. 346 SWITCH-LAYER Object-Class TBD2 is to be assigned by IANA. 348 SWITCH-LAYER Object-Type 1 is to be assigned by IANA. 350 The format of the SWITCH-LAYER object body is shown in Figure 2. 352 0 1 2 3 353 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 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | LSP Enc. Type |Switching Type | Reserved |I| 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | . | 358 // . // 359 | . | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | LSP Enc. Type |Switching Type | Reserved |I| 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 Figure 2: The SWITCH-LAYER Object 366 Each row indicates a switching type and encoding type that must or 367 must not be used for specified layer(s) in the computed path. 369 The format is based on [RFC3471], and has equivalent semantics. 371 LSP Encoding Type (8 bits): see [RFC3471] for a description of 372 parameters. 374 Switching Type (8 bits): see [RFC3471] for a description of 375 parameters. 377 I flag (1 bit): the I flag indicates whether a layer with the 378 specified switching type and encoding type must or must not be used 379 by the computed path. When the I flag is set (one), the computed 380 path MUST traverse a layer with the specified switching type and 381 encoding type. When the I flag is clear (zero), the computed path 382 MUST NOT enter or traverse any layer with the specified switching 383 type and encoding type. 385 When a combination of switching type and encoding type is not 386 included in SWITCH-LAYER object, the computed path MAY traverse a 387 layer with that combination of switching type and encoding type. 389 A PCC may want to specify only a Switching Type and not an LSP 390 Encoding Type. In this case, the LSP Encoding Type is set to zero. 392 3.3. REQ-ADAP-CAP Object 394 The REQ-ADAP-CAP object is optional and is used to specify a 395 requested adaptation capability for both ends of the lower layer LSP. 396 The REQ-ADAP-CAP object is used in a PCReq message for inter-PCE 397 communication, where the PCE that is responsible for computing higher 398 layer paths acts as a PCC to request a path computation from a PCE 399 that is responsible for computing lower layer paths. 401 The REQ-ADAP-CAP object is used in a PCRep message in case of 402 unsuccessful path computation (in this case, the PCRep message also 403 contains a NO-PATH object, and the REQ-ADAP-CAP object is used to 404 indicate the set of constraints that could not be satisfied). 406 The REQ-ADAP-CAP object MAY be used in a PCReq message in a mono- 407 layer network to specify a requested adaptation capability for both 408 ends of the LSP. In this case, it MAY be carried without INTER-LAYER 409 Object. 411 The applicability of this object to PCRpt and PCUpd messages follows 412 as the usage of other objects on those messages as described in 413 [I-D.ietf-pce-stateful-pce]. The applicability of this object to the 414 PCInitiate message follows as the usage of other objects on those 415 messages as described in [I-D.ietf-pce-pce-initiated-lsp]. These 416 messages use the as defined in [RFC5440] and 417 extended by further PCEP extensions. These messages can use the 418 as extended in Section 5 to carry the REQ-ADAP-CAP 419 object. 421 REQ-ADAP-CAP Object-Class TBD3 is to be assigned by IANA. 423 REQ-ADAP-CAP Object-Type 1 is to be assigned by IANA. 425 The format of the REQ-ADAP-CAP object body is shown in Figure 3. 427 0 1 2 3 428 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 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | Switching Cap | Encoding | Reserved | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 Figure 3: The REQ-ADAP-CAP Object 435 The format is based on [RFC6001] and has equivalent semantics as the 436 IACD Upper SC and Lower SC. 438 Switching Capability (8 bits): see [RFC4203] for a description of 439 parameters. 441 Encoding (8 bits): see [RFC3471] for a description of parameters. 443 A PCC may want to specify a Switching Capability, but not an 444 Encoding. In this case, the Encoding MUST be set zero. 446 3.4. New Metric Types 448 This document defines two new metric types for use in the PCEP METRIC 449 object. 451 IANA has assigned the value TBD5 to indicate the metric "Number of 452 adaptations on a path." 454 IANA has assigned the value TBD6 to indicate the metric "Number of 455 layers to be involved on a path." 457 See Section 4.1, Section 4.2, and Section 4.3 for a description of 458 how these metrics are applied. 460 3.5. SERVER-INDICATION Object 462 The SERVER-INDICATION is optional and is used to indicate that path 463 information included in the ERO is server layer information and 464 specify the characteristics of the server layer, e.g., the switching 465 capability and encoding of the server layer path. 467 The format of the SERVER-INDICATION object body is shown in Figure 4. 469 0 1 2 3 470 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 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 | Switching Cap | Encoding | Reserved | 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 ~ Optional TLVs ~ 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 Figure 4: The SERVER-INDICATION Object 479 SERVER-INDICATION Object-Class TBD4 to be assigned by IANA. 481 SERVER-INDICATION Object-Type 1 to be assigned by IANA. 483 Switching Capability (8 bits): see [RFC4203] for a description of 484 parameters. 486 Encoding (8 bits): see [RFC3471] for a description of parameters. 488 Optional TLVs: Optional TLVs may be included within the object to 489 specify more specific server layer path information (e.g., traffic 490 parameters). 492 4. Procedures 494 4.1. Path Computation Request 496 A PCC requests or allows inter-layer path computation in a PCReq 497 message by including the INTER-LAYER object with the I flag set. The 498 INTER-LAYER object indicates whether inter-layer path computation is 499 allowed, which path type is requested, and whether triggered 500 signaling is allowed. 502 The SWITCH-LAYER object, which MUST NOT be present unless the INTER- 503 LAYER object is also present, is optionally used to specify the 504 switching types and encoding types that define layers that must, or 505 must not, be used in the computed path. When the SWITCH-LAYER object 506 is used with the INTER-LAYER object I flag clear (zero), inter-layer 507 path computation is not allowed, but constraints specified in the 508 SWITCH-LAYER object apply. Example usage includes path computation 509 in a single layer GMPLS network. 511 The REQ-ADAP-CAP object is optionally used to specify the interface 512 switching capability of both ends of the lower layer LSP. The REQ- 513 ADAP-CAP object is used in inter-PCE communication, where the PCE 514 that is responsible for computing higher layer paths makes a request 515 as a PCC to a PCE that is responsible for computing lower layer 516 paths. Alternatively, the REQ-ADAP-CAP object may be used in the 517 NMS-VNTM model, where the VNTM makes a request as a PCC to a PCE that 518 is responsible for computing lower-layer paths. 520 The METRIC object is optionally used to specify metric types to be 521 optimized or bounded. When metric type TBD5 is used, it indicates 522 that path computation MUST minimize or bound the number of 523 adaptations on a path. When metric type TBD6 is used, it indicates 524 that path computation MUST minimize or bound the number of layers to 525 be involved on a path. 527 Furthermore, in order to allow different objective functions to be 528 applied within different network layers, multiple OF objects MAY be 529 present. In such a case, the first OF object specifies an objective 530 function for the higher-layer network, and subsequent OF objects 531 specify objection functions of the subsequent lower-layer networks. 533 4.2. Path Computation Reply 535 In the case of successful path computation, the requested PCE replies 536 to the requesting PCC for the inter-layer path computation result in 537 a PCRep message that MAY include the INTER-LAYER object. When the 538 INTER-LAYER object is included in a PCRep message, the I flag, M 539 flag, and T flag indicate semantics of the path as described in 540 Section 3.1. Furthermore, when the C flag of the METRIC object in a 541 PCReq is set, the METRIC object MUST be included in the PCRep to 542 provide the computed metric value, as specified in [RFC5440]. 544 PCE MAY specify the server layer path information in the ERO. In 545 this case, the requested PCE replies a PCRep message that includes at 546 least two sets of ERO information in the path-list, one is for the 547 client layer path information, and another one is the server layer 548 path information. When SERVER-INDICATION is included in a PCRep 549 message, it indicates that the path in the ERO is the server layer 550 path information. The server layer path specified in the ERO could 551 be loose or strict. On receiving the replied path, the PCC (e.g., 552 NMS, ingress node) can trigger the signaling to setup the LSPs 553 according to the computed paths. 555 In the case of unsuccessful path computation, the PCRep message also 556 contains a NO-PATH object, and the SWITCH-TYPE object and/or the REQ- 557 ADAP-CAP MAY be used to indicate the set of constraints that could 558 not be satisfied. 560 4.3. Stateful PCE and PCE Initiated LSPs 562 Processing for stateful PCEs is described in 563 [I-D.ietf-pce-stateful-pce]. That document defines the PCRpt message 564 to allow a PCC to report to a PCE an LSP that already exists in the 565 network and to delegate control of that LSP to the PCE. 567 When the LSP is a multi-layer LSP (or a mono-layer LSP for which 568 specific adaptations exist), the message objects define in this 569 document are used on the PCRpt to describe an LSP that is delegated 570 to the PCE so that the PCE may process the LSP. 572 Furthermore, [I-D.ietf-pce-stateful-pce] defines the PCUpd message to 573 allow a PCE to modify an LSP that has been delegated to it. When the 574 LSP is a multi-layer LSP (or a mono-layer LSP for which specific 575 adaptations exist), the message objects defined in this document are 576 used on the PCUpd to describe the new attributes of the modified LSP. 578 Processing for PCE initiated LSPs is described in 579 [I-D.ietf-pce-pce-initiated-lsp]. That document defines the 580 PCInitiate message that is used by a PCE to request a PCC to set up a 581 new LSP. When the LSP is a multi-layer LSP (or a mono-layer LSP for 582 which specific adaptations exist), the message objects defined in 583 this document are used on the PCInitiate to describe the attributes 584 of the new LSP. 586 The new metric types defined in this document can also be used with 587 the stateful PCE extensions. The format of PCEP messages described 588 in [I-D.ietf-pce-stateful-pce] and [I-D.ietf-pce-pce-initiated-lsp] 589 uses (which is extended in Section 5 for the purpose 590 of including the new metrics. 592 The stateful PCE implementation MAY use the extension of PCReq and 593 PCRep messages as defined in Section 5 to enable the use of inter- 594 layer parameters during passive stateful operations too, using the 595 LSP object. 597 5. Updated Format of PCEP Messages 599 Message formats in this section, as those in [RFC5440] are presented 600 using Backus-Naur Format as specified in [RFC5511]. 602 The format of the PCReq message is updated as shown in Figure 5 603 ::= 604 [] 605 607 where: 608 ::= 609 [] 611 ::=[] 613 ::= 614 615 [] 616 [] 617 [] 618 [] 619 [] 620 [[]] 621 [] 622 [] 623 [ []] 624 [] 625 where: 627 ::=[] 628 ::=[] 630 Figure 5: The Updated PCReq Message 632 The format of the PCRep message is updated as shown in Figure 6 633 ::= 634 636 where: 637 ::=[] 639 ::= 640 [] 641 [] 642 [] 643 [] 645 ::=[] 647 ::= 649 where: 650 ::=[] 651 [] 652 [] 653 [] 654 [] 655 [] 656 [] 657 [] 658 [] 660 ::=[] 661 ::=[] 663 Figure 6: The Updated PCRep Message 665 6. Manageability Considerations 667 Implementations of this specification should provide a mechanism to 668 configure any optional features (such as whether a PCE supports 669 inter-layer computation, and which metrics are supported). 671 A Management Information Base (MIB) module for modeling PCEP is 672 described in [RFC7420]. Systems that already use a MIB module to 673 manage their PCEP implementations might want to augment that module 674 to provide controls and indicators for support of inter-layer 675 features defined in this document, and to add counters of messages 676 sent and received containing the objects defined here. 678 However, the preferred mechanism for configuration is through a YANG 679 model. Work has started on a YANG model for PCEP 681 [I-D.ietf-pce-pcep-yang], and this could be enhanced as described for 682 the MIB module, above. 684 Additional policy configuration might be provided to allow a PCE to 685 discriminate between the computation services offered to different 686 PCCs. 688 A set of monitoring tools for the PCE-based architecture are provided 689 in [RFC5886]. Systems implementing this specification and PCE 690 monitoring should consider defining extensions to the mechanisms 691 defined in [RFC5886] to help monitor inter-layer path computation 692 requests. 694 7. IANA Considerations 696 IANA maintains a registry called the "Path Computation Element 697 Protocol (PCEP) Numbers". This document requests IANA to carry out 698 actions on subregistries of that registry. 700 7.1. New PCEP Objects 702 IANA is requested to make the following assignments from the "PCEP 703 Objects" subregistry. 705 Object-Class Value |Name |Object-Type |Reference 706 -------------------+-------+-----------------------+----------- 707 INTER-LAYER | TBD1 | 1: Inter-layer | [This.I-D] 708 | | 2-15: Unassigned | 709 SWITCH-LAYER | TBD2 | 1: Switch-layer | [This.I-D] 710 | | 2-15: Unassigned | 711 REQ-ADAP-CAP | TBD3 | 1: Req-Adap-Cap | [This.I-D] 712 | | 2-15: Unassigned | 713 SERVER-INDICATION | TBD4 | 1: Server-indication | [This.I-D] 715 Figure 7 717 7.2. New Registry for INTER-LAYER Object Flags 719 IANA is requested to create a new subregistry to manage the Flag 720 field of the INTER-Layer object called the "Inter-Layer Object Path 721 Property Bits" registry. 723 New bit numbers may be allocated only by an "IETF Review" action 724 [RFC5226]. Each bit should be tracked with the following qualities: 726 o Bit number (counting from bit 0 as the most significant bit up to 727 a maximum of bit 31) 729 o Capability Description 731 o Defining RFC 733 IANA is requested to pre-populate the registry as follows: 735 Bit | Flag | Multi-Layer Path Property | Reference 736 ----+------+-------------------------------+------------ 737 0-28| Unassigned | 738 29 | T | Triggered Signalling Required | [This.I-D] 739 30 | M | Multi-Layer Requested | [This.I-D] 740 31 | I | Inter-Layer Allowed | [This.I-D] 742 Figure 8 744 7.3. New Metric Types 746 Two new metric types are defined in this document for the METRIC 747 object (specified in [RFC5440]). The IANA is requested to make the 748 following allocations from the "Metric Object T Field" registry. 750 Value | Description | Reference 751 ------+---------------------------------+------------ 752 TBD5 | Number of adaptations on a path | [This.I-D] 753 TBD6 | Number of layers on a path | [This.I-D] 755 Figure 9 757 IANA is further requested to update the registry to show an 758 assignment action of "IETF Consensus" as already documented in 759 [RFC5440]. 761 8. Security Considerations 763 Inter-layer traffic engineering with PCE may raise new security 764 issues when PCE-PCE communication is done between different layer 765 networks for inter-layer path computation. Security issues may also 766 exist when a single PCE is granted full visibility of TE information 767 that applies to multiple layers. 769 Path-Key-based mechanism defined in [RFC5520] MAY be applied to 770 address the topology confidentiality between different layers. 772 9. Acknowledgments 774 The authors would like to thank Cyril Margaria for his valuable 775 comments. Helpful comments and suggeted text were offered by Dhruv 776 Dhody who also fixed the RBNF. 778 10. Contributors 780 Jean-Louis Le Roux 781 France Telecom R&D 782 Av Pierre Marzin 783 Lannion 784 France 785 22300 787 Email: jeanlouis.leroux@orange.com 789 11. References 791 11.1. Normative References 793 [I-D.ietf-pce-pce-initiated-lsp] 794 Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 795 Extensions for PCE-initiated LSP Setup in a Stateful PCE 796 Model", draft-ietf-pce-pce-initiated-lsp-07 (work in 797 progress), July 2016. 799 [I-D.ietf-pce-stateful-pce] 800 Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP 801 Extensions for Stateful PCE", draft-ietf-pce-stateful- 802 pce-16 (work in progress), September 2016. 804 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 805 Requirement Levels", BCP 14, RFC 2119, 806 DOI 10.17487/RFC2119, March 1997, 807 . 809 [RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label 810 Switching (GMPLS) Signaling Functional Description", 811 RFC 3471, DOI 10.17487/RFC3471, January 2003, 812 . 814 [RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label 815 Switching (GMPLS) Architecture", RFC 3945, 816 DOI 10.17487/RFC3945, October 2004, 817 . 819 [RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in 820 Support of Generalized Multi-Protocol Label Switching 821 (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005, 822 . 824 [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) 825 Hierarchy with Generalized Multi-Protocol Label Switching 826 (GMPLS) Traffic Engineering (TE)", RFC 4206, 827 DOI 10.17487/RFC4206, October 2005, 828 . 830 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 831 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 832 DOI 10.17487/RFC5226, May 2008, 833 . 835 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 836 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 837 DOI 10.17487/RFC5440, March 2009, 838 . 840 [RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel, 841 "Preserving Topology Confidentiality in Inter-Domain Path 842 Computation Using a Path-Key-Based Mechanism", RFC 5520, 843 DOI 10.17487/RFC5520, April 2009, 844 . 846 11.2. Informative References 848 [I-D.ietf-pce-pcep-yang] 849 Dhody, D., Hardwick, J., Beeram, V., and j. 850 jefftant@gmail.com, "A YANG Data Model for Path 851 Computation Element Communications Protocol (PCEP)", 852 draft-ietf-pce-pcep-yang-01 (work in progress), October 853 2016. 855 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 856 Element (PCE)-Based Architecture", RFC 4655, 857 DOI 10.17487/RFC4655, August 2006, 858 . 860 [RFC5150] Ayyangar, A., Kompella, K., Vasseur, JP., and A. Farrel, 861 "Label Switched Path Stitching with Generalized 862 Multiprotocol Label Switching Traffic Engineering (GMPLS 863 TE)", RFC 5150, DOI 10.17487/RFC5150, February 2008, 864 . 866 [RFC5212] Shiomoto, K., Papadimitriou, D., Le Roux, JL., Vigoureux, 867 M., and D. Brungard, "Requirements for GMPLS-Based Multi- 868 Region and Multi-Layer Networks (MRN/MLN)", RFC 5212, 869 DOI 10.17487/RFC5212, July 2008, 870 . 872 [RFC5339] Le Roux, JL., Ed. and D. Papadimitriou, Ed., "Evaluation 873 of Existing GMPLS Protocols against Multi-Layer and Multi- 874 Region Networks (MLN/MRN)", RFC 5339, 875 DOI 10.17487/RFC5339, September 2008, 876 . 878 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax 879 Used to Form Encoding Rules in Various Routing Protocol 880 Specifications", RFC 5511, DOI 10.17487/RFC5511, April 881 2009, . 883 [RFC5623] Oki, E., Takeda, T., Le Roux, JL., and A. Farrel, 884 "Framework for PCE-Based Inter-Layer MPLS and GMPLS 885 Traffic Engineering", RFC 5623, DOI 10.17487/RFC5623, 886 September 2009, . 888 [RFC5886] Vasseur, JP., Ed., Le Roux, JL., and Y. Ikejiri, "A Set of 889 Monitoring Tools for Path Computation Element (PCE)-Based 890 Architecture", RFC 5886, DOI 10.17487/RFC5886, June 2010, 891 . 893 [RFC6001] Papadimitriou, D., Vigoureux, M., Shiomoto, K., Brungard, 894 D., and JL. Le Roux, "Generalized MPLS (GMPLS) Protocol 895 Extensions for Multi-Layer and Multi-Region Networks (MLN/ 896 MRN)", RFC 6001, DOI 10.17487/RFC6001, October 2010, 897 . 899 [RFC6457] Takeda, T., Ed. and A. Farrel, "PCC-PCE Communication and 900 PCE Discovery Requirements for Inter-Layer Traffic 901 Engineering", RFC 6457, DOI 10.17487/RFC6457, December 902 2011, . 904 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 905 Hardwick, "Path Computation Element Communication Protocol 906 (PCEP) Management Information Base (MIB) Module", 907 RFC 7420, DOI 10.17487/RFC7420, December 2014, 908 . 910 [RFC7926] Farrel, A., Ed., Drake, J., Bitar, N., Swallow, G., 911 Ceccarelli, D., and X. Zhang, "Problem Statement and 912 Architecture for Information Exchange between 913 Interconnected Traffic-Engineered Networks", BCP 206, 914 RFC 7926, DOI 10.17487/RFC7926, July 2016, 915 . 917 Authors' Addresses 919 Eiji Oki 920 University of Electro-Communications 921 Tokyo 922 Japan 924 Email: oki@ice.uec.ac.jp 926 Tomonori Takeda 927 NTT 928 3-9-11 Midori-cho 929 Musashino-shi, Tokyo 930 Japan 932 Email: takeda.tomonori@lab.ntt.co.jp 934 Adrian Farrel 935 Juniper Networks 937 Email: afarrel@juniper.net 939 Fatai Zhang 940 Huawei Technologies Co., Ltd. 941 F3-5-B R&D Center, Huawei Base 942 Bantian, Longgang District, Shenzhen 518129 943 P. R. China 945 Phone: +86-755-28972912 946 Email: zhangfatai@huawei.com