idnits 2.17.1 draft-ietf-pce-inter-layer-ext-12.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 (January 3, 2017) is 2669 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-18 ** 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: July 7, 2017 NTT 6 A. Farrel 7 Juniper Networks 8 F. Zhang 9 Huawei Technologies Co., Ltd. 10 January 3, 2017 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-12 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 July 7, 2017. 56 Copyright Notice 58 Copyright (c) 2017 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 supported 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 node 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, a 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. It introduces the Virtual Network Topology Manager (VNTM), a 177 functional element that controls the VNT, and sets out three distinct 178 models (and a fourth hybrid model) for inter-layer control involving 179 a PCE, triggered signalling, and a Network Management System (NMS). 181 3. Protocol Extensions 183 This section describes PCEP extensions for inter-layer path 184 computation. Four new objects are defined: the INTER-LAYER object, 185 the SWITCH-LAYER object, the REQ-ADAP-CAP object, and the SERVER- 186 INDICATION object. Also, two new metric types are defined. 188 3.1. INTER-LAYER Object 190 The INTER-LAYER object is optional and can be used in PCReq and PCRep 191 messages, and also in PCRpt, PCUpd, and PCInitiate messages. 193 In a PCReq message, the INTER-LAYER object indicates whether inter- 194 layer path computation is allowed, the type of path to be computed, 195 and whether triggered signaling (hierarchical LSPs per [RFC4206] or 196 stitched LSPs per [RFC5150] depending on physical network 197 technologies) is allowed. When the INTER-LAYER object is absent from 198 a PCReq message, the receiving PCE MUST process as though inter-layer 199 path computation had been explicitly disallowed (I-bit set to zero - 200 see below). 202 In a PCRep message, the INTER-LAYER object indicates whether inter- 203 layer path computation has been performed, the type of path that has 204 been computed, and whether triggered signaling is used. 206 When a PCReq message includes more than one request, an INTER-LAYER 207 object is used per request. When a PCRep message includes more than 208 one path per request that is responded to, an INTER-LAYER object is 209 used per path. 211 The applicability of this object to PCRpt and PCUpd messages follows 212 as the usage of other objects on those messages as described in 213 [I-D.ietf-pce-stateful-pce]. The applicability of this object to the 214 PCInitiate message follows as the usage of other objects on those 215 messages as described in [I-D.ietf-pce-pce-initiated-lsp]. These 216 messages use the as defined in [RFC5440] and 217 extended by further PCEP extensions, and so the as 218 extended in Section 5 can be used to include the INTER-LAYER object 219 on these messages. 221 INTER-LAYER Object-Class TBD1 to be assigned by IANA. 223 INTER-LAYER Object-Type 1 to be assigned by IANA. 225 The format of the INTER-LAYER object body is shown in Figure 1. 227 0 1 2 3 228 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 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | Reserved |T|M|I| 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 Figure 1: The INTER-LAYER Object 235 I flag (1 bit): The I flag is used by a PCC in a PCReq message to 236 indicate to a PCE whether an inter-layer path is allowed. When the I 237 flag is set (one), the PCE MAY perform inter-layer path computation 238 and return an inter-layer path. When the flag is clear (zero), the 239 path that is returned MUST NOT be an inter-layer path. 241 The I flag is used by a PCE in a PCRep message to indicate to a PCC 242 whether the path returned is an inter-layer path. When the I flag is 243 set (one), the path is an inter-layer path. When it is clear (zero), 244 the path is contained within a single layer either because inter- 245 layer path computation was not performed or because a mono-layer path 246 (without any virtual TE link and without any loose hop that spans the 247 lower-layer network) was found notwithstanding the use of inter-layer 248 path computation. 250 M flag (1 bit): The M flag is used by a PCC in a PCReq message to 251 indicate to a PCE whether mono-layer path or multi-layer path is 252 requested. When the M flag is set (one), multi-layer path is 253 requested. When it is clear (zero), mono-layer path is requested. 255 The M flag is used by a PCE in a PCRep message to indicate to a PCC 256 whether mono-layer path or multi-layer path is returned. When M flag 257 is set (one), multi-layer path is returned. When M flag is clear 258 (zero), mono-layer path is returned. 260 If the I flag is clear (zero), the M flag has no meaning and MUST be 261 ignored. 263 [RFC6457] describes two sub-options for mono-layer path. 265 o A mono-layer path that is specified by strict hops. The path may 266 include virtual TE links. 268 o A mono-layer path that includes loose hops that span the lower- 269 layer network. 271 The choice of this sub-option can be specified by the use of O flag 272 in the RP object specified in [RFC5440]. 274 T flag (1 bit): The T flag is used by a PCC in a PCReq message to 275 indicate to a PCE whether triggered signaling is allowed. When the T 276 flag is set (one), triggered signaling is allowed. When it is clear 277 (zero), triggered signaling is not allowed. 279 The T flag is used by a PCE in a PCRep message to indicate to a PCC 280 whether triggered signaling is required to support the returned path. 281 When the T flag is set (one), triggered signaling is required. When 282 it is clear (zero), triggered signaling is not required. 284 Note that triggered signaling is used to support hierarchical 285 [RFC4206] or stitched [RFC5150] LSPs according to the physical 286 attributes of the network layers. 288 If the I flag is clear (zero), the T flag has no meaning and MUST be 289 ignored. 291 Note that the I flag and M flag differ in the following ways. When 292 the I flag is clear (zero), virtual TE links must not be used in path 293 computation. In addition, loose hops that span the lower-layer 294 network must not be specified. Only regular TE links from the same 295 layer may be used. 297 o When the I flag is set (one), the M flag is clear (zero), and the 298 T flag is set (one), virtual TE links are allowed in path 299 computation. In addition, when the O flag of the RP object is 300 set, loose hops that span the lower-layer network may be 301 specified. This will initiate lower-layer LSP setup, thus inter- 302 layer path is setup even though the path computation result from a 303 PCE to a PCC include hops from the same layer only. 305 o However, when the I flag is set (one), the M flag is clear (zero), 306 and the T flag is clear (zero), since triggered signaling is not 307 allowed, virtual TE links that have not been pre-signaled MUST NOT 308 be used in path computation. In addition, loose hops that span 309 the lower-layer network MUST NOT be specified. Therefore, this is 310 equivalent to the I flag being clear (zero). 312 Reserved bits of the INTER-LAYER object sent between a PCC and PCE in 313 the same domain MUST be transmitted as zero and SHOULD be ignored on 314 receipt. A PCE that forwards a path computation request to other 315 PCEs MUST preserve the settings of reserved bits in the PCReq 316 messages it sends and in the PCRep messages it forwards to PCCs. 318 Note that the flags in the PCRpt message indicate the state of an 319 LSP, whereas the flags in the PCUpd and the PCInitiate messages 320 indicate the intended/desired state as determined by the PCE. 322 3.2. SWITCH-LAYER Object 324 The SWITCH-LAYER object is optional on a PCReq message and specifies 325 switching layers in which a path MUST, or MUST NOT, be established. 326 A switching layer is expressed as a switching type and encoding type. 328 When a SWITCH-LAYER object is used on a PCReq it is interpreted in 329 the context of the INTER-LAYER object on the same message. If no 330 INTER-LAYER object is present, the PCE MUST process the SWITCH-LAYER 331 object as though inter-layer path computation had been explicitly 332 disallowed. In such a case, the SWITCH-LAYER object MUST NOT have 333 more than one LSP Encoding Type and Switching Type with the I flag 334 set. 336 The SWITCH-LAYER object is optional on a PCRep message, where it is 337 used with the NO-PATH object in the case of unsuccessful path 338 computation to indicate the set of constraints that could not be 339 satisfied. 341 The SWTCH-LAYER object may be used on a PCRpt message consistent with 342 how properties of existing LSPs are reported on that message 343 [I-D.ietf-pce-stateful-pce]. The PCRpt message uses the as defined in [RFC5440] and extended by further PCEP 345 extensions. This message can use the as extended in 346 Section 5 to carry the SWITCH-LAYER object. The SWTCH-LAYER object 347 is not used on a PCUpd or PCInitiate messages. 349 SWITCH-LAYER Object-Class TBD2 is to be assigned by IANA. 351 SWITCH-LAYER Object-Type 1 is to be assigned by IANA. 353 The format of the SWITCH-LAYER object body is shown in Figure 2. 355 0 1 2 3 356 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 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | LSP Enc. Type |Switching Type | Reserved |I| 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | . | 361 // . // 362 | . | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | LSP Enc. Type |Switching Type | Reserved |I| 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 Figure 2: The SWITCH-LAYER Object 369 Each row indicates a switching type and encoding type that must or 370 must not be used for specified layer(s) in the computed path. 372 The format is based on [RFC3471], and has equivalent semantics. 374 LSP Encoding Type (8 bits): see [RFC3471] for a description of 375 parameters. 377 Switching Type (8 bits): see [RFC3471] for a description of 378 parameters. 380 I flag (1 bit): the I flag indicates whether a layer with the 381 specified switching type and encoding type must or must not be used 382 by the computed path. When the I flag is set (one), the computed 383 path MUST traverse a layer with the specified switching type and 384 encoding type. When the I flag is clear (zero), the computed path 385 MUST NOT enter or traverse any layer with the specified switching 386 type and encoding type. 388 When a combination of switching type and encoding type is not 389 included in SWITCH-LAYER object, the computed path MAY traverse a 390 layer with that combination of switching type and encoding type. 392 A PCC may want to specify only a Switching Type and not an LSP 393 Encoding Type. In this case, the LSP Encoding Type is set to zero. 395 3.3. REQ-ADAP-CAP Object 397 The REQ-ADAP-CAP object is optional and is used to specify a 398 requested adaptation capability for both ends of the lower layer LSP. 399 The REQ-ADAP-CAP object is used in a PCReq message for inter-PCE 400 communication, where the PCE that is responsible for computing higher 401 layer paths acts as a PCC to request a path computation from a PCE 402 that is responsible for computing lower layer paths. 404 The REQ-ADAP-CAP object is used in a PCRep message in case of 405 unsuccessful path computation (in this case, the PCRep message also 406 contains a NO-PATH object, and the REQ-ADAP-CAP object is used to 407 indicate the set of constraints that could not be satisfied). 409 The REQ-ADAP-CAP object MAY be used in a PCReq message in a mono- 410 layer network to specify a requested adaptation capability for both 411 ends of the LSP. In this case, it MAY be carried without an INTER- 412 LAYER Object. 414 The applicability of this object to PCRpt and PCUpd messages follows 415 as the usage of other objects on those messages as described in 416 [I-D.ietf-pce-stateful-pce]. The applicability of this object to the 417 PCInitiate message follows as the usage of other objects on those 418 messages as described in [I-D.ietf-pce-pce-initiated-lsp]. These 419 messages use the as defined in [RFC5440] and 420 extended by further PCEP extensions. These messages can use the 421 as extended in Section 5 to carry the REQ-ADAP-CAP 422 object. 424 REQ-ADAP-CAP Object-Class TBD3 is to be assigned by IANA. 426 REQ-ADAP-CAP Object-Type 1 is to be assigned by IANA. 428 The format of the REQ-ADAP-CAP object body is shown in Figure 3. 430 0 1 2 3 431 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 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | Switching Cap | Encoding | Reserved | 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 Figure 3: The REQ-ADAP-CAP Object 438 The format is based on [RFC6001] and has equivalent semantics as the 439 Interface Adjustment Capability Descriptor (IACD) Upper Switching 440 Capability and Lower Switching Capability fields. 442 Switching Capability (8 bits): see [RFC4203] for a description of 443 parameters. 445 Encoding (8 bits): see [RFC3471] for a description of parameters. 447 A PCC may want to specify a Switching Capability, but not an 448 Encoding. In this case, the Encoding MUST be set zero. 450 3.4. New Metric Types 452 This document defines two new metric types for use in the PCEP METRIC 453 object. 455 IANA has assigned the value TBD5 to indicate the metric "Number of 456 adaptations on a path." 458 IANA has assigned the value TBD6 to indicate the metric "Number of 459 layers to be involved on a path." 461 See Section 4.1, Section 4.2, and Section 4.3 for a description of 462 how these metrics are applied. 464 3.5. SERVER-INDICATION Object 466 The SERVER-INDICATION is optional and is used to indicate that path 467 information included in the ERO is server layer information and 468 specify the characteristics of the server layer, e.g., the switching 469 capability and encoding of the server layer path. 471 The format of the SERVER-INDICATION object body is shown in Figure 4. 473 0 1 2 3 474 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 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 | Switching Cap | Encoding | Reserved | 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 ~ Optional TLVs ~ 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 Figure 4: The SERVER-INDICATION Object 483 SERVER-INDICATION Object-Class TBD4 to be assigned by IANA. 485 SERVER-INDICATION Object-Type 1 to be assigned by IANA. 487 Switching Capability (8 bits): see [RFC4203] for a description of 488 parameters. 490 Encoding (8 bits): see [RFC3471] for a description of parameters. 492 Optional TLVs: Optional TLVs MAY be included within the object to 493 specify more specific server layer path information (e.g., traffic 494 parameters). Such TLVs will be defined by other documents. 496 4. Procedures 498 4.1. Path Computation Request 500 A PCC requests or allows inter-layer path computation in a PCReq 501 message by including the INTER-LAYER object with the I flag set. The 502 INTER-LAYER object indicates whether inter-layer path computation is 503 allowed, which path type is requested, and whether triggered 504 signaling is allowed. 506 The SWITCH-LAYER object, which MUST NOT be present unless the INTER- 507 LAYER object is also present, is optionally used to specify the 508 switching types and encoding types that define layers that must, or 509 must not, be used in the computed path. When the SWITCH-LAYER object 510 is used with the INTER-LAYER object I flag clear (zero), inter-layer 511 path computation is not allowed, but constraints specified in the 512 SWITCH-LAYER object apply. Example usage includes path computation 513 in a single layer GMPLS network. 515 The REQ-ADAP-CAP object is optionally used to specify the interface 516 switching capability of both ends of the lower layer LSP. The REQ- 517 ADAP-CAP object is used in inter-PCE communication, where the PCE 518 that is responsible for computing higher layer paths makes a request 519 as a PCC to a PCE that is responsible for computing lower layer 520 paths. Alternatively, the REQ-ADAP-CAP object may be used in the 521 NMS-VNTM model, where the VNTM makes a request as a PCC to a PCE that 522 is responsible for computing lower-layer paths. 524 The METRIC object is optionally used to specify metric types to be 525 optimized or bounded. When metric type TBD5 is used, it indicates 526 that path computation MUST minimize or bound the number of 527 adaptations on a path. When metric type TBD6 is used, it indicates 528 that path computation MUST minimize or bound the number of layers to 529 be involved on a path. 531 Furthermore, in order to allow different objective functions to be 532 applied within different network layers, multiple OF objects 533 [RFC5541] MAY be present. In such a case, the first OF object 534 specifies an objective function for the higher-layer network, and 535 subsequent OF objects specify objection functions of the subsequent 536 lower-layer networks. 538 4.2. Path Computation Reply 540 In the case of successful path computation, the requested PCE replies 541 to the requesting PCC for the inter-layer path computation result in 542 a PCRep message that MAY include the INTER-LAYER object. When the 543 INTER-LAYER object is included in a PCRep message, the I flag, M 544 flag, and T flag indicate semantics of the path as described in 545 Section 3.1. Furthermore, when the C flag of the METRIC object in a 546 PCReq is set, the METRIC object MUST be included in the PCRep to 547 provide the computed metric value, as specified in [RFC5440]. 549 The PCE MAY specify the server layer path information in the ERO. In 550 this case, the requested PCE replies with a PCRep message that 551 includes at least two sets of ERO information in the path-list, one 552 is for the client layer path information, and another one is the 553 server layer path information. When SERVER-INDICATION is included in 554 a PCRep message, it indicates that the path in the ERO is the server 555 layer path information. The server layer path specified in the ERO 556 could be loose or strict. On receiving the replied path, the PCC 557 (e.g., NMS, ingress node) can trigger the signaling to setup the LSPs 558 according to the computed paths. 560 In the case of unsuccessful path computation, the PCRep message also 561 contains a NO-PATH object, and the SWITCH-TYPE object and/or the REQ- 562 ADAP-CAP MAY be used to indicate the set of constraints that could 563 not be satisfied. 565 4.3. Stateful PCE and PCE Initiated LSPs 567 Processing for stateful PCEs is described in 568 [I-D.ietf-pce-stateful-pce]. That document defines the PCRpt message 569 to allow a PCC to report to a PCE an LSP that already exists in the 570 network and to delegate control of that LSP to the PCE. 572 When the LSP is a multi-layer LSP (or a mono-layer LSP for which 573 specific adaptations exist), the message objects defined in this 574 document are used on the PCRpt to describe an LSP that is delegated 575 to the PCE so that the PCE may process the LSP. 577 Furthermore, [I-D.ietf-pce-stateful-pce] defines the PCUpd message to 578 allow a PCE to modify an LSP that has been delegated to it. When the 579 LSP is a multi-layer LSP (or a mono-layer LSP for which specific 580 adaptations exist), the message objects defined in this document are 581 used on the PCUpd to describe the new attributes of the modified LSP. 583 Processing for PCE initiated LSPs is described in 584 [I-D.ietf-pce-pce-initiated-lsp]. That document defines the 585 PCInitiate message that is used by a PCE to request a PCC to set up a 586 new LSP. When the LSP is a multi-layer LSP (or a mono-layer LSP for 587 which specific adaptations exist), the message objects defined in 588 this document are used on the PCInitiate to describe the attributes 589 of the new LSP. 591 The new metric types defined in this document can also be used with 592 the stateful PCE extensions. The format of PCEP messages described 593 in [I-D.ietf-pce-stateful-pce] and [I-D.ietf-pce-pce-initiated-lsp] 594 uses (which is extended in Section 5 for the purpose 595 of including the new metrics. 597 The stateful PCE implementation MAY use the extension of PCReq and 598 PCRep messages as defined in Section 5 to enable the use of inter- 599 layer parameters during passive stateful operations too, using the 600 LSP object. 602 5. Updated Format of PCEP Messages 604 Message formats in this section, as those in [RFC5440] are presented 605 using Routing Backus-Naur Format (RBNF) as specified in [RFC5511]. 607 The format of the PCReq message is updated as shown in Figure 5 608 ::= 609 [] 610 612 where: 613 ::= 614 [] 616 ::=[] 618 ::= 619 620 [] 621 [] 622 [] 623 [] 624 [] 625 [[]] 626 [] 627 [] 628 [ []] 629 [] 630 where: 632 ::=[] 633 ::=[] 635 Figure 5: The Updated PCReq Message 637 The format of the PCRep message is updated as shown in Figure 6 638 ::= 639 641 where: 642 ::=[] 644 ::= 645 [] 646 [] 647 [] 648 [] 650 ::=[] 652 ::= 654 where: 655 ::=[] 656 [] 657 [] 658 [] 659 [] 660 [] 661 [] 662 [] 663 [] 665 ::=[] 666 ::=[] 668 Figure 6: The Updated PCRep Message 670 6. Manageability Considerations 672 Implementations of this specification should provide a mechanism to 673 configure any optional features (such as whether a PCE supports 674 inter-layer computation, and which metrics are supported). 676 A Management Information Base (MIB) module for modeling PCEP is 677 described in [RFC7420]. Systems that already use a MIB module to 678 manage their PCEP implementations might want to augment that module 679 to provide controls and indicators for support of inter-layer 680 features defined in this document, and to add counters of messages 681 sent and received containing the objects defined here. 683 However, the preferred mechanism for configuration is through a YANG 684 model. Work has started on a YANG model for PCEP 686 [I-D.ietf-pce-pcep-yang], and this could be enhanced as described for 687 the MIB module, above. 689 Additional policy configuration might be provided to allow a PCE to 690 discriminate between the computation services offered to different 691 PCCs. 693 A set of monitoring tools for the PCE-based architecture are provided 694 in [RFC5886]. Systems implementing this specification and PCE 695 monitoring should consider defining extensions to the mechanisms 696 defined in [RFC5886] to help monitor inter-layer path computation 697 requests. 699 7. IANA Considerations 701 IANA maintains a registry called the "Path Computation Element 702 Protocol (PCEP) Numbers". This document requests IANA to carry out 703 actions on subregistries of that registry. 705 7.1. New PCEP Objects 707 IANA is requested to make the following assignments from the "PCEP 708 Objects" subregistry. 710 Object-Class Value |Name |Object-Type |Reference 711 -------------------+-------+-----------------------+----------- 712 INTER-LAYER | TBD1 | 1: Inter-layer | [This.I-D] 713 | | 2-15: Unassigned | 714 SWITCH-LAYER | TBD2 | 1: Switch-layer | [This.I-D] 715 | | 2-15: Unassigned | 716 REQ-ADAP-CAP | TBD3 | 1: Req-Adap-Cap | [This.I-D] 717 | | 2-15: Unassigned | 718 SERVER-INDICATION | TBD4 | 1: Server-indication | [This.I-D] 720 Figure 7 722 7.2. New Registry for INTER-LAYER Object Flags 724 IANA is requested to create a new subregistry to manage the Flag 725 field of the INTER-Layer object called the "Inter-Layer Object Path 726 Property Bits" registry. 728 New bit numbers may be allocated only by an "IETF Review" action 729 [RFC5226]. Each bit should be tracked with the following qualities: 731 o Bit number (counting from bit 0 as the most significant bit up to 732 a maximum of bit 31) 734 o Capability Description 736 o Defining RFC 738 IANA is requested to pre-populate the registry as follows: 740 Bit | Flag | Multi-Layer Path Property | Reference 741 ----+------+-------------------------------+------------ 742 0-28| Unassigned | 743 29 | T | Triggered Signalling Allowed | [This.I-D] 744 30 | M | Multi-Layer Requested | [This.I-D] 745 31 | I | Inter-Layer Allowed | [This.I-D] 747 Figure 8 749 7.3. New Metric Types 751 Two new metric types are defined in this document for the METRIC 752 object (specified in [RFC5440]). The IANA is requested to make the 753 following allocations from the "Metric Object T Field" registry. 755 Value | Description | Reference 756 ------+---------------------------------+------------ 757 TBD5 | Number of adaptations on a path | [This.I-D] 758 TBD6 | Number of layers on a path | [This.I-D] 760 Figure 9 762 IANA is further requested to update the registry to show an 763 assignment action of "IETF Consensus" as already documented in 764 [RFC5440]. 766 8. Security Considerations 768 Inter-layer traffic engineering with PCE may raise new security 769 issues when PCE-PCE communication is done between different layer 770 networks for inter-layer path computation. Security issues may also 771 exist when a single PCE is granted full visibility of TE information 772 that applies to multiple layers. 774 Path-Key-based mechanism defined in [RFC5520] MAY be applied to 775 address the topology confidentiality between different layers. 777 9. Acknowledgments 779 The authors would like to thank Cyril Margaria for his valuable 780 comments. Helpful comments and suggested text were offered by Dhruv 781 Dhody who also fixed the RBNF. Jonathan Hardwick provided a helpful 782 review as document shepherd. 784 10. Contributors 786 Jean-Louis Le Roux 787 France Telecom R&D 788 Av Pierre Marzin 789 Lannion 790 France 791 22300 793 Email: jeanlouis.leroux@orange.com 795 11. References 797 11.1. Normative References 799 [I-D.ietf-pce-pce-initiated-lsp] 800 Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 801 Extensions for PCE-initiated LSP Setup in a Stateful PCE 802 Model", draft-ietf-pce-pce-initiated-lsp-07 (work in 803 progress), July 2016. 805 [I-D.ietf-pce-stateful-pce] 806 Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP 807 Extensions for Stateful PCE", draft-ietf-pce-stateful- 808 pce-18 (work in progress), December 2016. 810 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 811 Requirement Levels", BCP 14, RFC 2119, 812 DOI 10.17487/RFC2119, March 1997, 813 . 815 [RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label 816 Switching (GMPLS) Signaling Functional Description", 817 RFC 3471, DOI 10.17487/RFC3471, January 2003, 818 . 820 [RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label 821 Switching (GMPLS) Architecture", RFC 3945, 822 DOI 10.17487/RFC3945, October 2004, 823 . 825 [RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in 826 Support of Generalized Multi-Protocol Label Switching 827 (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005, 828 . 830 [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) 831 Hierarchy with Generalized Multi-Protocol Label Switching 832 (GMPLS) Traffic Engineering (TE)", RFC 4206, 833 DOI 10.17487/RFC4206, October 2005, 834 . 836 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 837 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 838 DOI 10.17487/RFC5226, May 2008, 839 . 841 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 842 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 843 DOI 10.17487/RFC5440, March 2009, 844 . 846 [RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel, 847 "Preserving Topology Confidentiality in Inter-Domain Path 848 Computation Using a Path-Key-Based Mechanism", RFC 5520, 849 DOI 10.17487/RFC5520, April 2009, 850 . 852 11.2. Informative References 854 [I-D.ietf-pce-pcep-yang] 855 Dhody, D., Hardwick, J., Beeram, V., and j. 856 jefftant@gmail.com, "A YANG Data Model for Path 857 Computation Element Communications Protocol (PCEP)", 858 draft-ietf-pce-pcep-yang-01 (work in progress), October 859 2016. 861 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 862 Element (PCE)-Based Architecture", RFC 4655, 863 DOI 10.17487/RFC4655, August 2006, 864 . 866 [RFC5150] Ayyangar, A., Kompella, K., Vasseur, JP., and A. Farrel, 867 "Label Switched Path Stitching with Generalized 868 Multiprotocol Label Switching Traffic Engineering (GMPLS 869 TE)", RFC 5150, DOI 10.17487/RFC5150, February 2008, 870 . 872 [RFC5212] Shiomoto, K., Papadimitriou, D., Le Roux, JL., Vigoureux, 873 M., and D. Brungard, "Requirements for GMPLS-Based Multi- 874 Region and Multi-Layer Networks (MRN/MLN)", RFC 5212, 875 DOI 10.17487/RFC5212, July 2008, 876 . 878 [RFC5339] Le Roux, JL., Ed. and D. Papadimitriou, Ed., "Evaluation 879 of Existing GMPLS Protocols against Multi-Layer and Multi- 880 Region Networks (MLN/MRN)", RFC 5339, 881 DOI 10.17487/RFC5339, September 2008, 882 . 884 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax 885 Used to Form Encoding Rules in Various Routing Protocol 886 Specifications", RFC 5511, DOI 10.17487/RFC5511, April 887 2009, . 889 [RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of 890 Objective Functions in the Path Computation Element 891 Communication Protocol (PCEP)", RFC 5541, 892 DOI 10.17487/RFC5541, June 2009, 893 . 895 [RFC5623] Oki, E., Takeda, T., Le Roux, JL., and A. Farrel, 896 "Framework for PCE-Based Inter-Layer MPLS and GMPLS 897 Traffic Engineering", RFC 5623, DOI 10.17487/RFC5623, 898 September 2009, . 900 [RFC5886] Vasseur, JP., Ed., Le Roux, JL., and Y. Ikejiri, "A Set of 901 Monitoring Tools for Path Computation Element (PCE)-Based 902 Architecture", RFC 5886, DOI 10.17487/RFC5886, June 2010, 903 . 905 [RFC6001] Papadimitriou, D., Vigoureux, M., Shiomoto, K., Brungard, 906 D., and JL. Le Roux, "Generalized MPLS (GMPLS) Protocol 907 Extensions for Multi-Layer and Multi-Region Networks (MLN/ 908 MRN)", RFC 6001, DOI 10.17487/RFC6001, October 2010, 909 . 911 [RFC6457] Takeda, T., Ed. and A. Farrel, "PCC-PCE Communication and 912 PCE Discovery Requirements for Inter-Layer Traffic 913 Engineering", RFC 6457, DOI 10.17487/RFC6457, December 914 2011, . 916 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 917 Hardwick, "Path Computation Element Communication Protocol 918 (PCEP) Management Information Base (MIB) Module", 919 RFC 7420, DOI 10.17487/RFC7420, December 2014, 920 . 922 [RFC7926] Farrel, A., Ed., Drake, J., Bitar, N., Swallow, G., 923 Ceccarelli, D., and X. Zhang, "Problem Statement and 924 Architecture for Information Exchange between 925 Interconnected Traffic-Engineered Networks", BCP 206, 926 RFC 7926, DOI 10.17487/RFC7926, July 2016, 927 . 929 Authors' Addresses 931 Eiji Oki 932 University of Electro-Communications 933 Tokyo 934 Japan 936 Email: oki@ice.uec.ac.jp 938 Tomonori Takeda 939 NTT 940 3-9-11 Midori-cho 941 Musashino-shi, Tokyo 942 Japan 944 Email: tomonori.takeda@ntt.com 946 Adrian Farrel 947 Juniper Networks 949 Email: afarrel@juniper.net 950 Fatai Zhang 951 Huawei Technologies Co., Ltd. 952 F3-5-B R&D Center, Huawei Base 953 Bantian, Longgang District, Shenzhen 518129 954 P. R. China 956 Phone: +86-755-28972912 957 Email: zhangfatai@huawei.com