idnits 2.17.1 draft-ietf-pce-inter-layer-ext-10.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 (October 19, 2016) is 2745 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) Summary: 1 error (**), 0 flaws (~~), 3 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: April 22, 2017 NTT 6 A. Farrel 7 Juniper Networks 8 F. Zhang 9 Huawei Technologies Co., Ltd. 10 October 19, 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-10 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 April 22, 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 . . . . . . . . . . . 12 85 5. Updated Format of PCEP Messages . . . . . . . . . . . . . . . 13 86 6. Manageability Considerations . . . . . . . . . . . . . . . . 14 87 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 88 7.1. New PCEP Objects . . . . . . . . . . . . . . . . . . . . 15 89 7.2. New Registry for INTER-LAYER Object Flags . . . . . . . . 15 90 7.3. New Metric Types . . . . . . . . . . . . . . . . . . . . 16 91 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 92 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 93 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17 94 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 95 11.1. Normative References . . . . . . . . . . . . . . . . . . 17 96 11.2. Informative References . . . . . . . . . . . . . . . . . 18 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 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]. 214 INTER-LAYER Object-Class TBD1 to be assigned by IANA. 216 INTER-LAYER Object-Type 1 to be assigned by IANA. 218 The format of the INTER-LAYER object body is shown in Figure 1. 220 0 1 2 3 221 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 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | Reserved |T|M|I| 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 Figure 1: The INTER-LAYER Object 228 I flag (1 bit): The I flag is used by a PCC in a PCReq message to 229 indicate to a PCE whether an inter-layer path is allowed. When the I 230 flag is set (one), the PCE MAY perform inter-layer path computation 231 and return an inter-layer path. When the flag is clear (zero), the 232 path that is returned MUST NOT be an inter-layer path. 234 The I flag is used by a PCE in a PCRep message to indicate to a PCC 235 whether the path returned is an inter-layer path. When the I flag is 236 set (one), the path is an inter-layer path. When it is clear (zero), 237 the path is contained within a single layer either because inter- 238 layer path computation was not performed or because a mono-layer path 239 (without any virtual TE link and without any loose hop that spans the 240 lower-layer network) was found notwithstanding the use of inter-layer 241 path computation. 243 M flag (1 bit): The M flag is used by a PCC in a PCReq message to 244 indicate to a PCE whether mono-layer path or multi-layer path is 245 requested. When the M flag is set (one), multi-layer path is 246 requested. When it is clear (zero), mono-layer path is requested. 248 The M flag is used by a PCE in a PCRep message to indicate to a PCC 249 whether mono-layer path or multi-layer path is returned. When M flag 250 is set (one), multi-layer path is returned. When M flag is set 251 (zero), mono-layer path is returned. 253 If the I flag is clear (zero), the M flag has no meaning and MUST be 254 ignored. 256 [RFC6457] describes two sub-options for mono-layer path. 258 o A mono-layer path that is specified by strict hops. The path may 259 include virtual TE links. 261 o A mono-layer path that includes loose hops that span the lower- 262 layer network. 264 The choice of this sub-option can be specified by the use of O flag 265 in the RP object specified in [RFC5440]. 267 T flag (1 bit): The T flag is used by a PCC in a PCReq message to 268 indicate to a PCE whether triggered signaling is allowed. When the T 269 flag is set (one), triggered signaling is allowed. When it is clear 270 (zero), triggered signaling is not allowed. 272 The T flag is used by a PCE in a PCRep message to indicate to a PCC 273 whether triggered signaling is required to support the returned path. 274 When the T flag is set (one), triggered signaling is required. When 275 it is clear (zero), triggered signaling is not required. 277 Note that triggered signaling is used to support hierarchical 278 [RFC4206] or stitched (xref target="RFC5150" /> LSPs according to the 279 physical attributes of the network layers. 281 If the I flag is clear (zero), the T flag has no meaning and MUST be 282 ignored. 284 Note that the I flag and M flag differ in the following ways. When 285 the I flag is clear (zero), virtual TE links must not be used in path 286 computation. In addition, loose hops that span the lower-layer 287 network must not be specified. Only regular TE links from the same 288 layer may be used. 290 o When the I flag is set (one), the M flag is clear (zero), and the 291 T flag is set (one), virtual TE links are allowed in path 292 computation. In addition, when the O flag of the RP object is 293 set, loose hops that span the lower-layer network may be 294 specified. This will initiate lower-layer LSP setup, thus inter- 295 layer path is setup even though the path computation result from a 296 PCE to a PCC include hops from the same layer only. 298 o However, when the I flag is set (one), the M flag is clear (zero), 299 and the T flag is clear (zero), since triggered signaling is not 300 allowed, virtual TE links must not be used in path computation. 301 In addition, loose hops that span the lower-layer network must not 302 be specified. Therefore, this is equivalent to the I flag being 303 clear (zero). 305 Reserved bits of the INTER-LAYER object SHOULD be transmitted as zero 306 and SHOULD be ignored on receipt. A PCE that forwards a path 307 computation request to other PCEs SHOULD preserve the settings of 308 reserved bits in the PCReq messages it sends and in the PCRep 309 messages it forwards to PCCs. 311 3.2. SWITCH-LAYER Object 313 The SWITCH-LAYER object is optional on a PCReq message and specifies 314 switching layers in which a path MUST, or MUST NOT, be established. 315 A switching layer is expressed as a switching type and encoding type. 317 When a SWITCH-LAYER object is used on a PCReq it is interpreted in 318 the context of the INTER-LAYER object on the same message. If no 319 INTER-LAYER object is present, the PCE MUST process the SWITCH-LAYER 320 object as though inter-layer path computation had been explicitly 321 disallowed. In such a case, the SWITCH-LAYER object MUST NOT have 322 more than one LSP Encoding Type and Switching Type with the I flag 323 set. 325 The SWITCH-LAYER object is optional on a PCRep message, where it is 326 used with the NO-PATH object in the case of unsuccessful path 327 computation to indicate the set of constraints that could not be 328 satisfied. 330 The SWTCH-LAYER object may be used on a PCRpt message consistent with 331 how properties of existing LSPs are reported on that message 332 [I-D.ietf-pce-stateful-pce]. The SWTCH-LAYER object is not used on a 333 PCUpd or PCInitiate message. 335 SWITCH-LAYER Object-Class TBD2 is to be assigned by IANA. 337 SWITCH-LAYER Object-Type 1 is to be assigned by IANA. 339 The format of the SWITCH-LAYER object body is shown in Figure 2. 341 0 1 2 3 342 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 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | LSP Enc. Type |Switching Type | Reserved |I| 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | . | 347 // . // 348 | . | 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | LSP Enc. Type |Switching Type | Reserved |I| 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 Figure 2: The SWITCH-LAYER Object 355 Each row indicates a switching type and encoding type that must or 356 must not be used for specified layer(s) in the computed path. 358 The format is based on [RFC3471], and has equivalent semantics. 360 LSP Encoding Type (8 bits): see [RFC3471] for a description of 361 parameters. 363 Switching Type (8 bits): see [RFC3471] for a description of 364 parameters. 366 I flag (1 bit): the I flag indicates whether a layer with the 367 specified switching type and encoding type must or must not be used 368 by the computed path. When the I flag is set (one), the computed 369 path MUST traverse a layer with the specified switching type and 370 encoding type. When the I flag is clear (zero), the computed path 371 MUST NOT enter or traverse any layer with the specified switching 372 type and encoding type. 374 When a combination of switching type and encoding type is not 375 included in SWITCH-LAYER object, the computed path MAY traverse a 376 layer with that combination of switching type and encoding type. 378 A PCC may want to specify only a Switching Type and not an LSP 379 Encoding Type. In this case, the LSP Encoding Type is set to zero. 381 3.3. REQ-ADAP-CAP Object 383 The REQ-ADAP-CAP object is optional and is used to specify a 384 requested adaptation capability for both ends of the lower layer LSP. 385 The REQ-ADAP-CAP object is used in a PCReq message for inter-PCE 386 communication, where the PCE that is responsible for computing higher 387 layer paths acts as a PCC to request a path computation from a PCE 388 that is responsible for computing lower layer paths. 390 The REQ-ADAP-CAP object is used in a PCRep message in case of 391 unsuccessful path computation (in this case, the PCRep message also 392 contains a NO-PATH object, and the REQ-ADAP-CAP object is used to 393 indicate the set of constraints that could not be satisfied). 395 The REQ-ADAP-CAP object MAY be used in a PCReq message in a mono- 396 layer network to specify a requested adaptation capability for both 397 ends of the LSP. In this case, it MAY be carried without INTER-LAYER 398 Object. 400 The applicability of this object to PCRpt and PCUpd messages follows 401 as the usage of other objects on those messages as described in 402 [I-D.ietf-pce-stateful-pce]. The applicability of this object to the 403 PCInitiate message follows as the usage of other objects on those 404 messages as described in [I-D.ietf-pce-pce-initiated-lsp]. 406 REQ-ADAP-CAP Object-Class TBD3 is to be assigned by IANA. 408 REQ-ADAP-CAP Object-Type 1 is to be assigned by IANA. 410 The format of the REQ-ADAP-CAP object body is shown in Figure 3. 412 0 1 2 3 413 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 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | Switching Cap | Encoding | Reserved | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 Figure 3: The REQ-ADAP-CAP Object 420 The format is based on [RFC6001] and has equivalent semantics as the 421 IACD Upper SC and Lower SC. 423 Switching Capability (8 bits): see [RFC4203] for a description of 424 parameters. 426 Encoding (8 bits): see [RFC3471] for a description of parameters. 428 A PCC may want to specify a Switching Capability, but not an 429 Encoding. In this case, the Encoding MUST be set zero. 431 3.4. New Metric Types 433 This document defines two new metric types for use in the PCEP METRIC 434 object. 436 IANA has assigned the value TBD5 to indicate the metric "Number of 437 adaptations on a path." 439 IANA has assigned the value TBD6 to indicate the metric "Number of 440 layers to be involved on a path." 442 See Section 4.1 and Section 4.2 for a description of how these 443 metrics are applied. 445 3.5. SERVER-INDICATION Object 447 The SERVER-INDICATION is optional and is used to indicate that path 448 information included in the ERO is server layer information and 449 specify the characteristics of the server layer, e.g., the switching 450 capability and encoding of the server layer path. 452 The format of the SERVER-INDICATION object body is shown in Figure 4. 454 0 1 2 3 455 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 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | Switching Cap | Encoding | Reserved | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 ~ Optional TLVs ~ 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 Figure 4: The SERVER-INDICATION Object 464 SERVER-INDICATION Object-Class TBD4 to be assigned by IANA. 466 SERVER-INDICATION Object-Type 1 to be assigned by IANA. 468 Switching Capability (8 bits): see [RFC4203] for a description of 469 parameters. 471 Encoding (8 bits): see [RFC3471] for a description of parameters. 473 Optional TLVs: Optional TLVs may be included within the object to 474 specify more specific server layer path information (e.g., traffic 475 parameters). 477 4. Procedures 479 4.1. Path Computation Request 481 A PCC requests or allows inter-layer path computation in a PCReq 482 message by including the INTER-LAYER object with the I flag set. The 483 INTER-LAYER object indicates whether inter-layer path computation is 484 allowed, which path type is requested, and whether triggered 485 signaling is allowed. 487 The SWITCH-LAYER object, which MUST NOT be present unless the INTER- 488 LAYER object is also present, is optionally used to specify the 489 switching types and encoding types that define layers that must, or 490 must not, be used in the computed path. When the SWITCH-LAYER object 491 is used with the INTER-LAYER object I flag clear (zero), inter-layer 492 path computation is not allowed, but constraints specified in the 493 SWITCH-LAYER object apply. Example usage includes path computation 494 in a single layer GMPLS network. 496 The REQ-ADAP-CAP object is optionally used to specify the interface 497 switching capability of both ends of the lower layer LSP. The REQ- 498 ADAP-CAP object is used in inter-PCE communication, where the PCE 499 that is responsible for computing higher layer paths makes a request 500 as a PCC to a PCE that is responsible for computing lower layer 501 paths. Alternatively, the REQ-ADAP-CAP object may be used in the 502 NMS-VNTM model, where the VNTM makes a request as a PCC to a PCE that 503 is responsible for computing lower-layer paths. 505 The METRIC object is optionally used to specify metric types to be 506 optimized or bounded. When metric type 11 (TBC by IANA) is used, it 507 indicates that path computation MUST minimize or bound the number of 508 adaptations on a path. When metric type 12 (TBC by IANA) is used, it 509 indicates that path computation MUST minimize or bound the number of 510 layers to be involved on a path. 512 Furthermore, in order to allow different objective functions to be 513 applied within different network layers, multiple OF objects MAY be 514 present. In such a case, the first OF object specifies an objective 515 function for the higher-layer network, and subsequent OF objects 516 specify objection functions of the subsequent lower-layer networks. 518 4.2. Path Computation Reply 520 In the case of successful path computation, the requested PCE replies 521 to the requesting PCC for the inter-layer path computation result in 522 a PCRep message that MAY include the INTER-LAYER object. When the 523 INTER-LAYER object is included in a PCRep message, the I flag, M 524 flag, and T flag indicate semantics of the path as described in 525 Section 3.1. Furthermore, when the C flag of the METRIC object in a 526 PCReq is set, the METRIC object MUST be included in the PCRep to 527 provide the computed metric value, as specified in [RFC5440]. 529 PCE MAY specify the server layer path information in the ERO. In 530 this case, the requested PCE replies a PCRep message that includes at 531 least two sets of ERO information in the path-list, one is for the 532 client layer path information, and another one is the server layer 533 path information. When SERVER-INDICATION is included in a PCRep 534 message, it indicates that the path in the ERO is the server layer 535 path information. The server layer path specified in the ERO could 536 be loose or strict. On receiving the replied path, the PCC (e.g., 537 NMS, ingress node) can trigger the signaling to setup the LSPs 538 according to the computed paths. 540 In the case of unsuccessful path computation, the PCRep message also 541 contains a NO-PATH object, and the SWITCH-TYPE object and/or the REQ- 542 ADAP-CAP MAY be used to indicate the set of constraints that could 543 not be satisfied. 545 4.3. Stateful PCE and PCE Initiated LSPs 547 Processing for stateful PCEs is described in 548 [I-D.ietf-pce-stateful-pce]. That document defines the PCRpt message 549 to allow a PCC to report to a PCE an LSP that already exists in the 550 network and to delegate control of that LSP to the PCE. 552 When the LSP is a multi-layer LSP (or a mono-layer LSP for which 553 specific adaptations exist), the message objects define in this 554 document are used on the PCRpt to describe an LSP that is delegated 555 to the PCE so that the PCE may process the LSP. 557 Furthermore, [I-D.ietf-pce-stateful-pce] defines the PCUpd message to 558 allow a PCE to modify an LSP that has been delegated to it. When the 559 LSP is a multi-layer LSP (or a mono-layer LSP for which specific 560 adaptations exist), the message objects defined in this document are 561 used on the PCUpd to describe the new attributes of the modified LSP. 563 Processing for PCE initiated LSPs is described in 564 [I-D.ietf-pce-pce-initiated-lsp]. That document defines the 565 PCInitiate message that is used by a PCE to request a PCC to set up a 566 new LSP. When the LSP is a multi-layer LSP (or a mono-layer LSP for 567 which specific adaptations exist), the message objects defined in 568 this document are used on the PCInitiate to describe the attributes 569 of the new LSP. 571 5. Updated Format of PCEP Messages 573 Message formats in this section, as those in [RFC5440] are presented 574 using Backus-Naur Format as specified in [RFC5511]. 576 The format of the PCReq message is updated as shown in Figure 5 578 ::= 579 [] 580 582 where: 583 ::= 584 [] 586 ::=[] 588 ::= 589 590 [] 591 [] 592 [] 593 [] 594 [[]] 595 [] 596 [] 597 [ []] 598 [] 599 where: 601 ::=[] 602 ::=[] 604 Figure 5: The Updated PCReq Message 606 The format of the PCRep message is updated as shown in Figure 6 607 ::= 608 610 where: 611 ::=[] 613 ::= 614 [] 615 [] 616 [] 618 ::=[] 620 ::= 622 where: 623 ::=[] 624 [] 625 [] 626 [] 627 [] 628 [] 629 [] 630 [] 631 [] 633 ::=[] 634 ::=[] 636 Figure 6: The Updated PCRep Message 638 6. Manageability Considerations 640 Implementations of this specification should provide a mechanism to 641 configure any optional features (such as whether a PCE supports 642 inter-layer computation, and which metrics are supported). 644 A Management Information Base (MIB) module for modeling PCEP is 645 described in [RFC7420]. Systems that already use a MIB module to 646 manage their PCEP implementations might want to augment that module 647 to provide controls and indicators for support of inter-layer 648 features defined in this document, and to add counters of messages 649 sent and received containing the objects defined here. 651 However, the preferred mechanism for configuration is through a YANG 652 model. Work has started on a YANG model for PCEP 654 [I-D.pkd-pce-pcep-yang], and this could be enhanced as described for 655 the MIB module, above. 657 Additional policy configuration might be provided to allow a PCE to 658 discriminate between the computation services offered to different 659 PCCs. 661 A set of monitoring tools for the PCE-based architecture are provided 662 in [RFC5886]. Systems implementing this specification and PCE 663 monitoring should consider defining extensions to the mechanisms 664 defined in [RFC5886] to help monitor inter-layer path computation 665 requests. 667 7. IANA Considerations 669 IANA maintains a registry called the "Path Computation Element 670 Protocol (PCEP) Numbers". This document requests IANA to carry out 671 actions on subregistries of that registry. 673 7.1. New PCEP Objects 675 IANA is requested to make the following assignments from the "PCEP 676 Objects" subregistry. 678 Object-Class Value |Name |Object-Type |Reference 679 -------------------+-------+-----------------------+----------- 680 INTER-LAYER | TBD1 | 1: Inter-layer | [This.I-D] 681 | | 2-15: Unassigned | 682 SWITCH-LAYER | TBD2 | 1: Switch-layer | [This.I-D] 683 | | 2-15: Unassigned | 684 REQ-ADAP-CAP | TBD3 | 1: Req-Adap-Cap | [This.I-D] 685 | | 2-15: Unassigned | 686 SERVER-INDICATION | TBD4 | 1: Server-indication | [This.I-D] 688 Figure 7 690 7.2. New Registry for INTER-LAYER Object Flags 692 IANA is requested to create a new subregistry to manage the Flag 693 field of the INTER-Layer object called the "Inter-Layer Object Path 694 Property Bits" registry. 696 New bit numbers may be allocated only by an "IETF Review" action 697 [RFC5226]. Each bit should be tracked with the following qualities: 699 o Bit number (counting from bit 0 as the most significant bit up to 700 a maximum of bit 31) 702 o Capability Description 704 o Defining RFC 706 IANA is requested to pre-populate the registry as follows: 708 Bit | Flag | Multi-Layer Path Property | Reference 709 ----+------+-------------------------------+------------ 710 0-28| Unassigned | 711 29 | T | Triggered Signalling Required | [This.I-D] 712 30 | M | Multi-Layer Requested | [This.I-D] 713 31 | I | Inter-Layer Allowed | [This.I-D] 715 Figure 8 717 7.3. New Metric Types 719 Two new metric types are defined in this document for the METRIC 720 object (specified in [RFC5440]). The IANA is requested to make the 721 following allocations from the "Metric Object T Field" registry. 723 Value | Description | Reference 724 ------+---------------------------------+------------ 725 TBD5 | Number of adaptations on a path | [This.I-D] 726 TBD6 | Number of layers on a path | [This.I-D] 728 Figure 9 730 IANA is further requested to update the registry to show an 731 assignment action of "IETF Consensus" as already documented in 732 [RFC5440]. 734 8. Security Considerations 736 Inter-layer traffic engineering with PCE may raise new security 737 issues when PCE-PCE communication is done between different layer 738 networks for inter-layer path computation. Security issues may also 739 exist when a single PCE is granted full visibility of TE information 740 that applies to multiple layers. 742 Path-Key-based mechanism defined in [RFC5520] MAY be applied to 743 address the topology confidentiality between different layers. 745 9. Acknowledgments 747 The authors would like to thank Cyril Margaria for his valuable 748 comments. 750 10. Contributors 752 Jean-Louis Le Roux 753 France Telecom R&D 754 Av Pierre Marzin 755 Lannion 756 France 757 22300 759 Email: jeanlouis.leroux@orange.com 761 11. References 763 11.1. Normative References 765 [I-D.ietf-pce-pce-initiated-lsp] 766 Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 767 Extensions for PCE-initiated LSP Setup in a Stateful PCE 768 Model", draft-ietf-pce-pce-initiated-lsp-07 (work in 769 progress), July 2016. 771 [I-D.ietf-pce-stateful-pce] 772 Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP 773 Extensions for Stateful PCE", draft-ietf-pce-stateful- 774 pce-16 (work in progress), September 2016. 776 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 777 Requirement Levels", BCP 14, RFC 2119, 778 DOI 10.17487/RFC2119, March 1997, 779 . 781 [RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label 782 Switching (GMPLS) Signaling Functional Description", 783 RFC 3471, DOI 10.17487/RFC3471, January 2003, 784 . 786 [RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label 787 Switching (GMPLS) Architecture", RFC 3945, 788 DOI 10.17487/RFC3945, October 2004, 789 . 791 [RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in 792 Support of Generalized Multi-Protocol Label Switching 793 (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005, 794 . 796 [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) 797 Hierarchy with Generalized Multi-Protocol Label Switching 798 (GMPLS) Traffic Engineering (TE)", RFC 4206, 799 DOI 10.17487/RFC4206, October 2005, 800 . 802 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 803 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 804 DOI 10.17487/RFC5226, May 2008, 805 . 807 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 808 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 809 DOI 10.17487/RFC5440, March 2009, 810 . 812 [RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel, 813 "Preserving Topology Confidentiality in Inter-Domain Path 814 Computation Using a Path-Key-Based Mechanism", RFC 5520, 815 DOI 10.17487/RFC5520, April 2009, 816 . 818 11.2. Informative References 820 [I-D.pkd-pce-pcep-yang] 821 Dhody, D., Hardwick, J., Beeram, V., and j. 822 jefftant@gmail.com, "A YANG Data Model for Path 823 Computation Element Communications Protocol (PCEP)", 824 draft-pkd-pce-pcep-yang-06 (work in progress), July 2016. 826 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 827 Element (PCE)-Based Architecture", RFC 4655, 828 DOI 10.17487/RFC4655, August 2006, 829 . 831 [RFC5150] Ayyangar, A., Kompella, K., Vasseur, JP., and A. Farrel, 832 "Label Switched Path Stitching with Generalized 833 Multiprotocol Label Switching Traffic Engineering (GMPLS 834 TE)", RFC 5150, DOI 10.17487/RFC5150, February 2008, 835 . 837 [RFC5212] Shiomoto, K., Papadimitriou, D., Le Roux, JL., Vigoureux, 838 M., and D. Brungard, "Requirements for GMPLS-Based Multi- 839 Region and Multi-Layer Networks (MRN/MLN)", RFC 5212, 840 DOI 10.17487/RFC5212, July 2008, 841 . 843 [RFC5339] Le Roux, JL., Ed. and D. Papadimitriou, Ed., "Evaluation 844 of Existing GMPLS Protocols against Multi-Layer and Multi- 845 Region Networks (MLN/MRN)", RFC 5339, 846 DOI 10.17487/RFC5339, September 2008, 847 . 849 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax 850 Used to Form Encoding Rules in Various Routing Protocol 851 Specifications", RFC 5511, DOI 10.17487/RFC5511, April 852 2009, . 854 [RFC5623] Oki, E., Takeda, T., Le Roux, JL., and A. Farrel, 855 "Framework for PCE-Based Inter-Layer MPLS and GMPLS 856 Traffic Engineering", RFC 5623, DOI 10.17487/RFC5623, 857 September 2009, . 859 [RFC5886] Vasseur, JP., Ed., Le Roux, JL., and Y. Ikejiri, "A Set of 860 Monitoring Tools for Path Computation Element (PCE)-Based 861 Architecture", RFC 5886, DOI 10.17487/RFC5886, June 2010, 862 . 864 [RFC6001] Papadimitriou, D., Vigoureux, M., Shiomoto, K., Brungard, 865 D., and JL. Le Roux, "Generalized MPLS (GMPLS) Protocol 866 Extensions for Multi-Layer and Multi-Region Networks (MLN/ 867 MRN)", RFC 6001, DOI 10.17487/RFC6001, October 2010, 868 . 870 [RFC6457] Takeda, T., Ed. and A. Farrel, "PCC-PCE Communication and 871 PCE Discovery Requirements for Inter-Layer Traffic 872 Engineering", RFC 6457, DOI 10.17487/RFC6457, December 873 2011, . 875 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 876 Hardwick, "Path Computation Element Communication Protocol 877 (PCEP) Management Information Base (MIB) Module", 878 RFC 7420, DOI 10.17487/RFC7420, December 2014, 879 . 881 [RFC7926] Farrel, A., Ed., Drake, J., Bitar, N., Swallow, G., 882 Ceccarelli, D., and X. Zhang, "Problem Statement and 883 Architecture for Information Exchange between 884 Interconnected Traffic-Engineered Networks", BCP 206, 885 RFC 7926, DOI 10.17487/RFC7926, July 2016, 886 . 888 Authors' Addresses 890 Eiji Oki 891 University of Electro-Communications 892 Tokyo 893 Japan 895 Email: oki@ice.uec.ac.jp 897 Tomonori Takeda 898 NTT 899 3-9-11 Midori-cho 900 Musashino-shi, Tokyo 901 Japan 903 Email: takeda.tomonori@lab.ntt.co.jp 905 Adrian Farrel 906 Juniper Networks 908 Email: adrian@olddog.co.uk 910 Fatai Zhang 911 Huawei Technologies Co., Ltd. 912 F3-5-B R&D Center, Huawei Base 913 Bantian, Longgang District, Shenzhen 518129 914 P. R. China 916 Phone: +86-755-28972912 917 Email: zhangfatai@huawei.com