idnits 2.17.1 draft-ietf-pce-inter-layer-ext-09.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 : ---------------------------------------------------------------------------- ** There are 7 instances of too long lines in the document, the longest one being 1 character in excess of 72. 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 (April 25, 2016) is 2923 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group E. Oki 2 Internet-Draft UEC Tokyo 3 Intended status: Standards Track Tomonori Takeda 4 NTT 5 J-L Le Roux 6 France Telecom 7 A. Farrel 8 Juniper Networks 9 Fatai Zhang 10 Huawei 11 Expires: October 25, 2016 April 25, 2016 13 Extensions to the Path Computation Element communication Protocol 14 (PCEP) for Inter-Layer MPLS and GMPLS Traffic Engineering 16 draft-ietf-pce-inter-layer-ext-09.txt 18 Abstract 20 The Path Computation Element (PCE) provides path computation 21 functions in support of traffic engineering in Multiprotocol Label 22 Switching (MPLS) and Generalized MPLS (GMPLS) networks. 24 MPLS and GMPLS networks may be constructed from layered service 25 networks. It is advantageous for overall network efficiency to 26 provide end-to-end traffic engineering across multiple network layers 27 through a process called inter-layer traffic engineering. PCE is a 28 candidate solution for such requirements. 30 The PCE communication Protocol (PCEP) is designed as a communication 31 protocol between Path Computation Clients (PCCs) and PCEs. This 32 document presents PCEP extensions for inter-layer traffic engineering. 34 Status of this Memo 36 This Internet-Draft is submitted to IETF in full conformance with 37 the provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF), its areas, and its working groups. Note that 41 other groups may also distribute working documents as Internet- 42 Drafts. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 49 The list of current Internet-Drafts can be accessed at 50 http://www.ietf.org/ietf/1id-abstracts.txt. 52 The list of Internet-Draft Shadow Directories can be accessed at 53 http://www.ietf.org/shadow.html. 55 This Internet-Draft will expire on October 25, 2016. 57 Copyright Notice 59 Copyright (c) 2016 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (http://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with respect 67 to this document. Code Components extracted from this document must 68 include Simplified BSD License text as described in Section 4.e of 69 the Trust Legal Provisions and are provided without warranty as 70 described in the Simplified BSD License. 72 Conventions used in this document 74 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 75 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 76 document are to be interpreted as described in RFC-2119 [RFC2119]. 78 Table of Contents 80 1. Introduction .................................................. 3 81 2. Overview of PCE-Based Inter-Layer Path Computation ............ 4 82 3. Protocol Extensions ........................................... 5 83 3.1. INTER-LAYER Object ...................................... 5 84 3.2. SWITCH-LAYER Object ...................................... 7 85 3.3. REQ-ADAP-CAP Object ..................................... 9 86 3.4. New Metric Types ....................................... 10 87 3.5. SERVER-INDICATION object.. ............................... 10 89 4. Procedures .................................................... 11 90 4.1. Path Computation Request ............................... 11 91 4.2. Path Computation Reply ................................... 11 92 5. Updated Format of PCEP Messages . ............................. 12 93 6. Manageability Considerations................................... 14 94 7. IANA Considerations ........................................... 14 95 7.1. New PCEP Objects ......................................... 14 96 7.2. New Registry for INTER-LAYER Object Flags ................ 14 97 7.3. METRIC Type .............................................. 15 98 8. Security Considerations ....................................... 15 99 9. Acknowledgments ............................................... 15 100 10. References ................................................... 16 101 10.1. Normative References .................................... 16 102 10.2. Informative References .................................. 16 103 11. Authors' Addresses ........................................... 17 105 1. Introduction 107 The Path Computation Element (PCE) defined in [RFC4655] is an entity 108 that is capable of computing a network path or route based on a 109 network graph, and applying computational constraints. A Path 110 Computation Client (PCC) may make requests to a PCE for paths to be 111 computed. 113 A network may comprise multiple layers. These layers may represent 114 separations of technologies (e.g., packet switch capable (PSC), time 115 division multiplex (TDM), lambda switch capable (LSC)) [RFC3945], 116 separation of data plane switching granularity levels (e.g., PSC-1 117 and PSC-2, or VC4 and VC12) [RFC5212], or a distinction between 118 client and server networking roles (e.g., commercial or 119 administrative separation of client and server networks). In this 120 multi-layer network, Label Switched Paths (LSPs) in lower layers are 121 used to carry higher-layer LSPs. The network topology formed by 122 lower-layer LSPs and advertised as traffic engineering links (TE 123 links) in the higher layer is called a Virtual Network Topology (VNT) 124 [RFC5212]. 126 It is important to optimize network resource utilization globally, 127 i.e., taking into account all layers, rather than optimizing resource 128 utilization at each layer independently. This allows better network 129 efficiency to be achieved. This is what we call inter-layer traffic 130 engineering. This includes mechanisms allowing the computation of 131 end-to-end paths across layers (known as inter-layer path 132 computation), and mechanisms for control and management of the VNT by 133 setting up and releasing LSPs in the lower layers [RFC5212]. 135 PCE can provide a suitable mechanism for resolving inter-layer path 136 computation issues. The framework for applying the PCE-based path 137 computation architecture to inter-layer traffic engineering is 138 described in [RFC5623]. 140 The PCE communication protocol (PCEP) is designed as a communication 141 protocol between PCCs and PCEs and is defined in [RFC5440]. A set of 142 requirements for PCEP extensions to support inter-layer traffic 143 engineering is described in [RFC6457]. 145 This document presents PCEP extensions for inter-layer traffic 146 engineering that satisfy the requirements described in [RFC6457]. 148 2. Overview of PCE-Based Inter-Layer Path Computation 150 [RFC4206] defines a way to signal a higher-layer LSP which has an 151 explicit route that includes hops traversed by LSPs in lower layers. 152 The computation of end-to-end paths across layers is called Inter- 153 Layer Path Computation. 155 A Label Switching Router (LSR) in the higher-layer might not have 156 information on the lower-layer topology, particularly in an overlay 157 or augmented model [RFC3945], and hence may not be able to compute an 158 end-to-end path across layers. 160 PCE-based inter-layer path computation consists of using one or more 161 PCEs to compute an end-to-end path across layers. This could be 162 achieved by relying on a single PCE that has topology information 163 about multiple layers and can directly compute an end-to-end path 164 across layers considering the topology of all of the layers. 165 Alternatively, the inter-layer path computation could be performed 166 using multiple cooperating PCEs where each PCE has information about 167 the topology of one or more layers (but not all layers) and where the 168 PCEs collaborate to compute an end-to-end path. 170 As described in [RFC5339], a hybrid nodes may advertise a single TE 171 link with multiple switching capabilities. Those TE links exist at 172 the layer/region boarder normally. In this case, PCE needs to be 173 capable of specifying the server layer path information when the 174 server layer path information is required to be returned to the PCC. 176 [RFC5623] describes models for inter-layer path computation in more 177 detail. 179 3. Protocol Extensions 181 This section describes PCEP extensions for inter-layer path 182 computation. Three new objects are defined: the INTER-LAYER object, 183 the SWITCH-LAYER object, the REQ-ADAP-CAP object and SERVER- 184 INDICATION. Also, two new metric types are defined. 186 3.1. INTER-LAYER Object 188 The INTER-LAYER object is optional and can be used in PCReq and PCRep 189 messages. 191 In a PCReq message, the INTER-LAYER object indicates whether inter- 192 layer path computation is allowed, the type of path to be computed, 193 and whether triggered signaling (hierarchical LSPs per [RFC4206] or 194 stitched LSPs per [RFC5150] depending on physical network 195 technologies) is allowed. When the INTER-LAYER object is absent from 196 a PCReq message, the receiving PCE MUST process as though inter-layer 197 path computation had been explicitly disallowed (I-bit set to zero - 198 see below). 200 In a PCRep message, the INTER-LAYER object indicates whether inter- 201 layer path computation has been performed, the type of path that has 202 been computed, and whether triggered signaling is used. 204 When a PCReq message includes more than one request, an INTER-LAYER 205 object is used per request. When a PCRep message includes more than 206 one path per request that is responded to, an INTER-LAYER object is 207 used per path. 209 INTER-LAYER Object-Class is to be assigned by IANA (recommended 210 value=18) 212 INTER-LAYER Object-Type is to be assigned by IANA (recommended 213 value=1) 215 The format of the INTER-LAYER object body is as follows: 217 0 1 2 3 218 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 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | Reserved |T|M|I| 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 I flag (1 bit): The I flag is used by a PCC in a PCReq message to 224 indicate to a PCE whether an inter-layer path is allowed. When the I 225 flag is set (one), the PCE MAY perform inter-layer path computation 226 and return an inter-layer path. When the flag is clear (zero), the 227 path that is returned MUST NOT be an inter-layer path. 229 The I flag is used by a PCE in a PCRep message to indicate to a PCC 230 whether the path returned is an inter-layer path. When the I flag is 231 set (one), the path is an inter-layer path. When it is clear (zero), 232 the path is contained within a single layer either because inter- 233 layer path computation was not performed or because a mono-layer path 234 (without any virtual TE link and without any loose hop that spans the 235 lower-layer network) was found notwithstanding the use of inter-layer 236 path computation. 238 M flag (1 bit): The M flag is used by a PCC in a PCReq message to 239 indicate to a PCE whether mono-layer path or multi-layer path is 240 requested. When the M flag is set (one), multi-layer path is 241 requested. When it is clear (zero), mono-layer path is requested. 243 The M flag is used by a PCE in a PCRep message to indicate to a PCC 244 whether mono-layer path or multi-layer path is returned. When M flag 245 is set (one), multi-layer path is returned. When M flag is set (zero), 246 mono-layer path is returned. 248 If the I flag is clear (zero), the M flag has no meaning and MUST be 249 ignored. 251 [RFC6457] describes two sub-options for mono-layer path. 253 - A mono-layer path that is specified by strict hops. The path may 254 include virtual TE links. 256 - A mono-layer path that includes loose hops that span the lower- 257 layer network. 259 The choice of this sub-option can be specified by the use of O flag 260 in the RP object specified in [RFC5440]. 262 T flag (1 bit): The T flag is used by a PCC in a PCReq message to 263 indicate to a PCE whether triggered signaling is allowed. When the T 264 flag is set (one), triggered signaling is allowed. When it is clear 265 (zero), triggered signaling is not allowed. 267 The T flag is used by a PCE in a PCRep message to indicate to a PCC 268 whether triggered signaling is required to support the returned path. 269 When the T flag is set (one), triggered signaling is required. When 270 it is clear (zero), triggered signaling is not required. 272 Note that triggered signaling is used to support hierarchical 273 [RFC4206] or stitched [RFC5150] LSPs according to the physical 274 attributes of the network layers. 276 If the I flag is clear (zero), the T flag has no meaning and MUST be 277 ignored. 279 Note that the I flag and M flag differ in the following ways. - When 280 the I flag is clear (zero), virtual TE links must not be used in path 281 computation. In addition, loose hops that span the lower-layer 282 network must not be specified. Only regular TE links from the same 283 layer may be used. 285 - When the I flag is set (one), the M flag is clear (zero), and the T 286 flag is set (one), virtual TE links are allowed in path computation. 287 In addition, when the O flag of the RP object is set, loose hops that 288 span the lower-layer network may be specified. This will initiate 289 lower-layer LSP setup, thus inter-layer path is setup even though the 290 path computation result from a PCE to a PCC include hops from the 291 same layer only. 293 - However, when the I flag is set (one), the M flag is clear (zero), 294 and the T flag is clear (zero), since triggered signaling is not 295 allowed, virtual TE links must not be used in path computation. In 296 addition, loose hops that span the lower-layer network must not be 297 specified. Therefore, this is equivalent to the I flag being clear 298 (zero). 300 Reserved bits of the INTER-LAYER object SHOULD be transmitted as zero 301 and SHOULD be ignored on receipt. A PCE that forwards a path 302 computation request to other PCEs SHOULD preserve the settings of 303 reserved bits in the PCReq messages it sends and in the PCRep 304 messages it forwards to PCCs. 306 3.2. SWITCH-LAYER Object 308 The SWITCH-LAYER object is optional on a PCReq message and specifies 309 switching layers in which a path MUST, or MUST NOT, be established. A 310 switching layer is expressed as a switching type and encoding type. 312 When a SWITCH-LAYER object is used on a PCReq it is interpreted in 313 the context of the INTER-LAYER object on the same message. If no 314 INTER-LAYER object is present, the PCE MUST process the SWITCH-LAYER 315 object as though inter-layer path computation had been explicitly 316 disallowed. In such a case, the SWITCH-LAYER object MUST NOT have 317 more than one LSP Encoding Type and Switching Type with the I flag 318 set. 320 The SWITCH-LAYER object is optional on a PCRep message, where it is 321 used with the NO-PATH object in the case of unsuccessful path 322 computation to indicate the set of constraints that could not be 323 satisfied. 325 SWITCH-LAYER Object-Class is to be assigned by IANA (recommended 326 value=19) 328 SWITCH-LAYER Object-Type is to be assigned by IANA (recommended 329 value=1) 331 The format of the SWITCH-LAYER object body is as follows: 333 0 1 2 3 334 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 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | LSP Enc. Type |Switching Type | Reserved |I| 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | . | 339 // . // 340 | . | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | LSP Enc. Type |Switching Type | Reserved |I| 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 Each row indicates a switching type and encoding type that must or 346 must not be used for specified layer(s) in the computed path. 348 The format is based on [RFC3471], and has equivalent semantics. 350 LSP Encoding Type (8 bits): see [RFC3471] for a description of 351 parameters. 353 Switching Type (8 bits): see [RFC3471] for a description of 354 parameters. 356 I flag (1 bit): the I flag indicates whether a layer with the 357 specified switching type and encoding type must or must not be used 358 by the computed path. When the I flag is set (one), the computed path 359 MUST traverse a layer with the specified switching type and encoding 360 type. When the I flag is clear (zero), the computed path MUST NOT 361 enter or traverse any layer with the specified switching type and 362 encoding type. 364 When a combination of switching type and encoding type is not 365 included in SWITCH-LAYER object, the computed path MAY traverse a 366 layer with that combination of switching type and encoding type. 368 A PCC may want to specify only a Switching Type and not an LSP 369 Encoding Type. In this case, the LSP Encoding Type is set to zero. 371 3.3. REQ-ADAP-CAP Object 373 The REQ-ADAP-CAP object is optional and is used to specify a 374 requested adaptation capability for both ends of the lower layer LSP. 375 The REQ-ADAP-CAP object is used in a PCReq message for inter-PCE 376 communication, where the PCE that is responsible for computing higher 377 layer paths acts as a PCC to request a path computation from a PCE 378 that is responsible for computing lower layer paths. 380 The REQ-ADAP-CAP object is used in a PCRep message in case of 381 unsuccessful path computation (in this case, the PCRep message also 382 contains a NO-PATH object, and the REQ-ADAP-CAP object is used to 383 indicate the set of constraints that could not be satisfied). 385 The REQ-ADAP-CAP object MAY be used in a PCReq message in a mono- 386 layer network to specify a requested adaptation capability for both 387 ends of the LSP. In this case, it MAY be carried without INTER-LAYER 388 Object. 390 REQ-ADAP-CAP Object-Class is to be assigned by IANA (recommended 391 value=20) 393 REQ-ADAP-CAP Object-Type is to be assigned by IANA (recommended 394 value=1) 396 The format of the REQ-ADAP-CAP object body is as follows: 398 0 1 2 3 399 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 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | Switching Cap | Encoding | Reserved | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 The format is based on [RFC6001] and has equivalent semantics as the 405 IACD Upper SC and Lower SC. 407 Switching Capability (8 bits): see [RFC4203] for a description of 408 parameters. 410 Encoding (8 bits): see [RFC3471] for a description of parameters. 412 A PCC may want to specify a Switching Capability, but not an Encoding. 413 In this case, the Encoding MUST be set zero. 415 3.4. New Metric Types 417 Two new metric types are defined for the METRIC object in PCEP. 419 Type 11 (suggested value, to be assigned by IANA): Number of 420 adaptations on a path. 422 Type 12 (suggested value, to be assigned by IANA): Number of layers 423 to be involved on a path. 425 3.5. SERVER-INDICATION object 427 The SERVER-INDICATION is optional and is used to indicate that path 428 information included in the ERO is server layer information and 429 specify the characteristics of the server layer, e.g. the switching 430 capability and encoding of the server layer path. 432 0 1 2 3 433 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 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 | Switching Cap | Encoding | Reserved | 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 ~ Optional TLVs ~ 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 The type of SERVER-INDICATION object is to be assigned by IANA. 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 Optional TLVs: Optional TLVs may be included within the object to 448 specify more specific server layer path information (e.g., traffic 449 parameters). 451 4. Procedures 453 4.1. Path Computation Request 455 A PCC requests or allows inter-layer path computation in a PCReq 456 message by including the INTER-LAYER object with the I flag set. The 457 INTER-LAYER object indicates whether inter-layer path computation is 458 allowed, which path type is requested, and whether triggered 459 signaling is allowed. 461 The SWITCH-LAYER object, which MUST NOT be present unless the INTER- 462 LAYER object is also present, is optionally used to specify the 463 switching types and encoding types that define layers that must, or 464 must not, be used in the computed path. When the SWITCH-LAYER object 465 is used with the INTER-LAYER object I flag clear (zero), inter-layer 466 path computation is not allowed, but constraints specified in the 467 SWITCH-LAYER object apply. Example usage includes path computation in 468 a single layer GMPLS network. 470 The REQ-ADAP-CAP object is optionally used to specify the interface 471 switching capability of both ends of the lower layer LSP. The REQ- 472 ADAP-CAP object is used in inter-PCE communication, where the PCE 473 that is responsible for computing higher layer paths makes a request 474 as a PCC to a PCE that is responsible for computing lower layer paths. 475 Alternatively, the REQ-ADAP-CAP object may be used in the NMS-VNTM 476 model, where the VNTM makes a request as a PCC to a PCE that is 477 responsible for computing lower-layer paths. 479 The METRIC object is optionally used to specify metric types to be 480 optimized or bounded. When metric type 11 (TBC by IANA) is used, it 481 indicates that path computation MUST minimize or bound the number of 482 adaptations on a path. When metric type 12 (TBC by IANA) is used, it 483 indicates that path computation MUST minimize or bound the number of 484 layers to be involved on a path. 486 Furthermore, in order to allow different objective functions to be 487 applied within different network layers, multiple OF objects MAY be 488 present. In such a case, the first OF object specifies an objective 489 function for the higher-layer network, and subsequent OF objects 490 specify objection functions of the subsequent lower-layer networks. 492 4.2. Path Computation Reply 494 In the case of successful path computation, the requested PCE replies 495 to the requesting PCC for the inter-layer path computation result in 496 a PCRep message that MAY include the INTER-LAYER object. When the 497 INTER-LAYER object is included in a PCRep message, the I flag, M flag, 498 and T flag indicate semantics of the path as described in Section 3.1. 499 Furthermore, when the C flag of the METRIC object in a PCReq is set, 500 the METRIC object MUST be included in the PCRep to provide the 501 computed metric value, as specified in [RFC5440]. 503 PCE MAY specify the server layer path information in the ERO. In this 504 case, the requested PCE replies a PCRep message that includes at 505 least two sets of ERO information in the path-list, one is for the 506 client layer path information, and another one is the server layer 507 path information. When SERVER-INDICATION is included in a PCRep 508 message, it indicates that the path in the ERO is the server layer 509 path information. The server layer path specified in the ERO could be 510 loose or strict. On receiving the replied path, the PCC (e.g. NMS, 511 ingress node) can trigger the signaling to setup the LSPs according 512 to the computed paths. 514 In the case of unsuccessful path computation, the PCRep message also 515 contains a NO-PATH object, and the SWITCH-TYPE object and/or the REQ- 516 ADAP-CAP MAY be used to indicate the set of constraints that could 517 not be satisfied. 519 5. Updated Format of PCEP Messages 521 Message formats in this section, as those in [RFC5440] are presented 522 using Backus-Naur Format as specified in [RFC5511]. 524 The format of the PCReq message is updated as follows: 526 ::= 527 [] 528 530 where: 531 ::= 532 [] 534 ::=[] 536 ::= 537 538 [] 539 [] 540 [] 541 [] 543 [[]] 544 [] 545 [] 546 [ []] 547 [] 548 where: 550 ::=[] 551 ::=[] 553 The format of the PCRep message is updated as follows: 554 ::= 555 557 where: 558 ::=[] 560 ::= 561 [] 562 [] 563 [] 565 ::=[] 567 ::= 569 where: 570 ::=[] 571 [] 572 [] 573 [] 574 [] 575 [] 576 [] 577 [] 578 [] 580 ::=[] 581 ::=[] 583 6. Manageability Considerations 585 Manageability of inter-layer traffic engineering with PCE must 586 address the following consideration for section 5.1. 588 - need for a MIB module for control and monitoring 589 - need for built-in diagnostic tools 590 - configuration implication for the protocol 592 7. IANA Considerations 594 7.1. New PCEP Objects 596 Four new objects: INTER-LAYER object, SWITCH-LAYER object, REQ-ADAP- 597 CAP and SERVER-INDICATION object. 599 INTER-LAYER Object-Class is to be assigned by IANA (recommended 600 value=18) 602 INTER-LAYER Object-Type is to be assigned by IANA (recommended 603 value=1) 605 SWITCH-LAYER Object-Class is to be assigned by IANA (recommended 606 value=19) 608 SWITCH-LAYER Object-Type is to be assigned by IANA (recommended 609 value=1) 611 REQ-ADAP-CAP Object-Class is to be assigned by IANA (recommended 612 value=20) 614 REQ-ADAP-CAP Object-Type is to be assigned by IANA (recommended 615 value=1) 617 SERVER-INDICATION Object-Class is to be assigned by IANA (recommended 618 value=21) 620 SERVER-INDICATION Object-Type is to be assigned by IANA (recommended 621 value=1) 623 7.2. New Registry for INTER-LAYER Object Flags 625 IANA is requested to create a registry to manage the Flag field of 626 the INTER-Layer object. 628 New bit numbers may be allocated only by an IETF Consensus action. 629 Each bit should be tracked with the following qualities: 631 o Bit number (counting from bit 0 as the most significant bit) 633 o Capability Description 635 o Defining RFC 637 Several bits are defined for the INTER-LAYER object flag fields in 638 this document. The following values have been assigned: 640 Bit Number Description Reference 642 29 T flag this document 643 30 M flag this document 644 31 I flag this document 646 7.3. METRIC Type 648 Two new metric types are defined in this document for the METRIC 649 object (specified in [RFC5440]). The IANA is requested to make the 650 following allocation (suggested value): 652 - Type 11 : Number of adaptations on a path 654 - Type 12 : Number of layers on a path 656 8. Security Considerations 658 Inter-layer traffic engineering with PCE may raise new security 659 issues when PCE-PCE communication is done between different layer 660 networks for inter-layer path computation. Security issues may also 661 exist when a single PCE is granted full visibility of TE information 662 that applies to multiple layers. 664 Path-Key-based mechanism defined in [RFC5520] MAY be applied to 665 address the topology confidentiality between different layers. 667 9. Acknowledgments 669 The authors would like to thank Cyril Margaria for his valuable 670 comments. 672 10. References 674 10.1. Normative References 676 [RFC2119] S. Bradner, "Key words for use in RFCs to indicate 677 requirements levels", RFC 2119, March 1997. 679 [RFC3471] L. Burger, "Generalized Multi-Protocol Label Switching 680 (GMPLS)", RFC 3471, January 2003. 682 [RFC3945] E. Mannie, "Generalized Multi-Protocol Label Switching 683 Architecture", RFC 3945, October 2004. 685 [RFC4203] K. Kompella and Y. Rekhter, "OSPF Extensions in Support of 686 Generalized Multi-Protocol Label Switching (GMPLS)", RFC 687 4203, October 2005. 689 [RFC4206] K. Kompella, and Y. Rekhter, "Label Switched Paths (LSP) 690 Hierarchy with Generalized Multi-Protocol Label Switching 691 (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. 693 [RFC5520] Rich Bradford, JP. Vasseur, Adrian Farrel, "Preserving 694 Topology Confidentiality in Inter-Domain Path Computation 695 Using a Path-Key-Based Mechanism" RFC 5520, April 2009. 697 [RFC5440] JP. Vasseur et al., "Path Computation Element (PCE) 698 Communication Protocol (PCEP)" RFC 5440, March 2009. 700 10.2. Informative References 702 [RFC4655] A. Farrel, JP. Vasseur and J. Ash, "A Path Computation 703 Element (PCE)-Based Architecture", RFC 4655, September 2006. 705 [RFC5212] K. Shiomoto et al., "Requirements for GMPLS-based multi- 706 region and multi-layer networks (MRN/MLN)", RFC 5212, July 707 2008. 709 [RFC6001] D. Papadimitriou et al., "Generalized Multi-Protocol Label 710 Switching (GMPLS) Protocol Extensions for Multi-Layer and 711 Multi-Region Networks (MLN/MRN)", RFC6001, October 2010. 713 [RFC5150] A. Ayyangar et al., "Label Switched Path Stitching with 714 Generalized Multiprotocol Label Switching Traffic 715 Engineering (GMPLS TE)", RFC 5150, February 2008. 717 [RFC5339] JL. Le Roux et al., "Evaluation of Existing GMPLS Protocols 718 against Multi-Layer and Multi-Region Networks (MLN/MRN)", 719 RFC5339, September 2008. 721 [RFC5511] Farrel, A., "Reduced Backus-Naur Form (RBNF) A Syntax Used 722 in Various Protocol Specifications", April 2009. 724 [RFC5623] E. Oki et al., "Framework for PCE-Based Inter-Layer MPLS 725 and GMPLS Traffic Engineering", September 2009. 727 [RFC6457] E. Oki et al., "PCC-PCE Communication Requirements for 728 Inter-Layer Traffic Engineering", RFC6457, December 2011. 730 11. Authors' Addresses 732 Eiji Oki 733 University of Electro-Communications 734 Tokyo 735 Japan 736 Email: oki@ice.uec.ac.jp 738 Tomonori Takeda 739 NTT 740 3-9-11 Midori-cho, 741 Musashino-shi, Tokyo 180-8585, Japan 742 Email: takeda.tomonori@lab.ntt.co.jp 744 Jean-Louis Le Roux 745 France Telecom R&D, 746 Av Pierre Marzin, 747 22300 Lannion, France 748 Email: julien.meuric@orange.com 750 Adrian Farrel 751 Juniper Networks 752 Email: adrian@olddog.co.uk 754 Fatai Zhang 755 Huawei Technologies Co., Ltd. 756 F3-5-B R&D Center, Huawei Base, 757 Bantian, Longgang District 758 Shenzhen 518129 P.R.China 759 Phone: +86-755-28972912 760 Email: zhangfatai@huawei.com