idnits 2.17.1 draft-ietf-pce-inter-layer-ext-07.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 8 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 (July 13, 2012) is 4298 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC5520' is mentioned on line 647, but not defined ** Downref: Normative reference to an Informational RFC: RFC 6457 ** Downref: Normative reference to an Informational RFC: RFC 5623 ** Downref: Normative reference to an Informational RFC: RFC 5339 Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 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: January 13, 2013 July 13, 2012 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-07.txt 18 Status of this Memo 20 This Internet-Draft is submitted to IETF in full conformance with 21 the provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on January 13, 2013. 41 Abstract 42 The Path Computation Element (PCE) provides path computation 43 functions in support of traffic engineering in Multiprotocol Label 44 Switching (MPLS) and Generalized MPLS (GMPLS) networks. 46 MPLS and GMPLS networks may be constructed from layered service 47 networks. It is advantageous for overall network efficiency to 48 provide end-to-end traffic engineering across multiple network layers 49 through a process called inter-layer traffic engineering. PCE is a 50 candidate solution for such requirements. 52 The PCE communication Protocol (PCEP) is designed as a communication 53 protocol between Path Computation Clients (PCCs) and PCEs. This 54 document presents PCEP extensions for inter-layer traffic engineering. 56 Conventions used in this document 58 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 59 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 60 document are to be interpreted as described in RFC-2119 [RFC2119]. 62 Table of Contents 64 1. Introduction ................................................. 3 65 2. Overview of PCE-Based Inter-Layer Path Computation ........... 3 66 3. Protocol Extensions .......................................... 4 67 3.1. INTER-LAYER Object....................................... 4 68 3.2. SWITCH-LAYER Object ..................................... 7 69 3.3. REQ-ADAP-CAP Object ..................................... 8 70 3.4. New Metric Types......................................... 9 71 3.5. ERO sub-object ......................................... 10 72 4. Procedures .................................................. 10 73 4.1. Path Computation Request ............................... 10 74 4.2. Path Computation Reply ................................. 11 75 5. Updated Format of PCEP Messages ............................. 12 76 6. Manageability Considerations ................................ 13 77 7. IANA Considerations ......................................... 13 78 7.1. New PCEP Objects........................................ 13 79 7.2. New Registry for INTER-LAYER Object Flags .............. 14 80 7.3. METRIC Type ............................................ 15 81 8. Security Considerations ..................................... 15 82 9. Acknowledgments ............................................. 15 83 10. References ................................................. 15 84 10.1. Normative References .................................. 15 85 10.2. Informative References ................................ 16 86 11. Authors' Addresses ......................................... 16 88 1. Introduction 90 The Path Computation Element (PCE) defined in [RFC4655] is an entity 91 that is capable of computing a network path or route based on a 92 network graph, and applying computational constraints. A Path 93 Computation Client (PCC) may make requests to a PCE for paths to be 94 computed. 96 A network may comprise multiple layers. These layers may represent 97 separations of technologies (e.g., packet switch capable (PSC), time 98 division multiplex (TDM), lambda switch capable (LSC)) [RFC3945], 99 separation of data plane switching granularity levels (e.g., PSC-1 100 and PSC-2, or VC4 and VC12) [RFC5212], or a distinction between 101 client and server networking roles (e.g., commercial or 102 administrative separation of client and server networks). In this 103 multi-layer network, Label Switched Paths (LSPs) in lower layers are 104 used to carry higher-layer LSPs. The network topology formed by 105 lower-layer LSPs and advertised as traffic engineering links (TE 106 links) in the higher layer is called a Virtual Network Topology (VNT) 107 [RFC5212]. 109 It is important to optimize network resource utilization globally, 110 i.e., taking into account all layers, rather than optimizing resource 111 utilization at each layer independently. This allows better network 112 efficiency to be achieved. This is what we call inter-layer traffic 113 engineering. This includes mechanisms allowing the computation of 114 end-to-end paths across layers (known as inter-layer path 115 computation), and mechanisms for control and management of the VNT by 116 setting up and releasing LSPs in the lower layers [RFC5212]. 118 PCE can provide a suitable mechanism for resolving inter-layer path 119 computation issues. The framework for applying the PCE-based path 120 computation architecture to inter-layer traffic engineering is 121 described in [RFC5623]. 123 The PCE communication protocol (PCEP) is designed as a communication 124 protocol between PCCs and PCEs and is defined in [RFC5440]. A set of 125 requirements for PCEP extensions to support inter-layer traffic 126 engineering is described in [RFC6457]. 128 This document presents PCEP extensions for inter-layer traffic 129 engineering that satisfy the requirements described in [RFC6457]. 131 2. Overview of PCE-Based Inter-Layer Path Computation 133 [RFC4206] defines a way to signal a higher-layer LSP which has an 134 explicit route that includes hops traversed by LSPs in lower layers. 136 The computation of end-to-end paths across layers is called Inter- 137 Layer Path Computation. 139 A Label Switching Router (LSR) in the higher-layer might not have 140 information on the lower-layer topology, particularly in an overlay 141 or augmented model [RFC3945], and hence may not be able to compute an 142 end-to-end path across layers. 144 PCE-based inter-layer path computation consists of using one or more 145 PCEs to compute an end-to-end path across layers. This could be 146 achieved by relying on a single PCE that has topology information 147 about multiple layers and can directly compute an end-to-end path 148 across layers considering the topology of all of the layers. 149 Alternatively, the inter-layer path computation could be performed 150 using multiple cooperating PCEs where each PCE has information about 151 the topology of one or more layers (but not all layers) and where the 152 PCEs collaborate to compute an end-to-end path. 154 As described in [RFC5339], a hybrid nodes may advertise a single TE 155 link with multiple switching capabilities. Those TE links exist at 156 the layer/region boarder normally. In this case, PCE needs to be 157 capable of specifying the server layer path information when the 158 server layer path information is required to be returned to the PCC. 160 [RFC5623] describes models for inter-layer path computation in more 161 detail. 163 3. Protocol Extensions 165 This section describes PCEP extensions for inter-layer path 166 computation. Three new objects are defined: the INTER-LAYER object, 167 the SWITCH-LAYER object, the REQ-ADAP-CAP object and SERVER- 168 INDICATION. Also, two new metric types are defined. 170 3.1. INTER-LAYER Object 172 The INTER-LAYER object is optional and can be used in PCReq and PCRep 173 messages. 175 In a PCReq message, the INTER-LAYER object indicates whether inter- 176 layer path computation is allowed, the type of path to be computed, 177 and whether triggered signaling (hierarchical LSPs per [RFC4206] or 178 stitched LSPs per [RFC5150] depending on physical network 179 technologies) is allowed. When the INTER-LAYER object is absent from 180 a PCReq message, the receiving PCE MUST process as though inter-layer 181 path computation had been explicitly disallowed (I-bit set to zero - 182 see below). 184 In a PCRep message, the INTER-LAYER object indicates whether inter- 185 layer path computation has been performed, the type of path that has 186 been computed, and whether triggered signaling is used. 188 When a PCReq message includes more than one request, an INTER-LAYER 189 object is used per request. When a PCRep message includes more than 190 one path per request that is responded to, an INTER-LAYER object is 191 used per path. 193 INTER-LAYER Object-Class is to be assigned by IANA (recommended 194 value=18) 196 INTER-LAYER Object-Type is to be assigned by IANA (recommended 197 value=1) 199 The format of the INTER-LAYER object body is as follows: 201 0 1 2 3 202 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 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | Reserved |T|M|I| 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 I flag (1 bit): The I flag is used by a PCC in a PCReq message to 208 indicate to a PCE whether an inter-layer path is allowed. When the I 209 flag is set (one), the PCE MAY perform inter-layer path computation 210 and return an inter-layer path. When the flag is clear (zero), the 211 path that is returned MUST NOT be an inter-layer path. 213 The I flag is used by a PCE in a PCRep message to indicate to a PCC 214 whether the path returned is an inter-layer path. When the I flag is 215 set (one), the path is an inter-layer path. When it is clear (zero), 216 the path is contained within a single layer either because inter- 217 layer path computation was not performed or because a mono-layer path 218 (without any virtual TE link and without any loose hop that spans the 219 lower-layer network) was found notwithstanding the use of inter-layer 220 path computation. 222 M flag (1 bit): The M flag is used by a PCC in a PCReq message to 223 indicate to a PCE whether mono-layer path or multi-layer path is 224 requested. When the M flag is set (one), multi-layer path is 225 requested. When it is clear (zero), mono-layer path is requested. 227 The M flag is used by a PCE in a PCRep message to indicate to a PCC 228 whether mono-layer path or multi-layer path is returned. When M flag 229 is set (one), multi-layer path is returned. When M flag is set (zero), 230 mono-layer path is returned. 232 If the I flag is clear (zero), the M flag has no meaning and MUST be 233 ignored. 235 [RFC6457] describes two sub-options for mono-layer path. 237 - A mono-layer path that is specified by strict hops. The path may 238 include virtual TE links. 240 - A mono-layer path that includes loose hops that span the lower- 241 layer network. 243 The choice of this sub-option can be specified by the use of O flag 244 in the RP object specified in [RFC5440]. 246 T flag (1 bit): The T flag is used by a PCC in a PCReq message to 247 indicate to a PCE whether triggered signaling is allowed. When the T 248 flag is set (one), triggered signaling is allowed. When it is clear 249 (zero), triggered signaling is not allowed. 251 The T flag is used by a PCE in a PCRep message to indicate to a PCC 252 whether triggered signaling is required to support the returned path. 253 When the T flag is set (one), triggered signaling is required. When 254 it is clear (zero), triggered signaling is not required. 256 Note that triggered signaling is used to support hierarchical 257 [RFC4206] or stitched [RFC5150] LSPs according to the physical 258 attributes of the network layers. 260 If the I flag is clear (zero), the T flag has no meaning and MUST be 261 ignored. 263 Note that the I flag and M flag differ in the following ways. - When 264 the I flag is clear (zero), virtual TE links must not be used in path 265 computation. In addition, loose hops that span the lower-layer 266 network must not be specified. Only regular TE links from the same 267 layer may be used. 269 - When the I flag is set (one), the M flag is clear (zero), and the T 270 flag is set (one), virtual TE links are allowed in path computation. 271 In addition, when the O flag of the RP object is set, loose hops that 272 span the lower-layer network may be specified. This will initiate 273 lower-layer LSP setup, thus inter-layer path is setup even though the 274 path computation result from a PCE to a PCC include hops from the 275 same layer only. 277 - However, when the I flag is set (one), the M flag is clear (zero), 278 and the T flag is clear (zero), since triggered signaling is not 279 allowed, virtual TE links must not be used in path computation. In 280 addition, loose hops that span the lower-layer network must not be 281 specified. Therefore, this is equivalent to the I flag being clear 282 (zero). 284 Reserved bits of the INTER-LAYER object SHOULD be transmitted as zero 285 and SHOULD be ignored on receipt. A PCE that forwards a path 286 computation request to other PCEs SHOULD preserve the settings of 287 reserved bits in the PCReq messages it sends and in the PCRep 288 messages it forwards to PCCs. 290 3.2. SWITCH-LAYER Object 292 The SWITCH-LAYER object is optional on a PCReq message and specifies 293 switching layers in which a path MUST, or MUST NOT, be established. A 294 switching layer is expressed as a switching type and encoding type. 296 When a SWITCH-LAYER object is used on a PCReq it is interpreted in 297 the context of the INTER-LAYER object on the same message. If no 298 INTER-LAYER object is present, the PCE MUST process the SWITCH-LAYER 299 object as though inter-layer path computation had been explicitly 300 disallowed. In such a case, the SWITCH-LAYER object MUST NOT have 301 more than one LSP Encoding Type and Switching Type with the I flag 302 set. 304 The SWITCH-LAYER object is optional on a PCRep message, where it is 305 used with the NO-PATH object in the case of unsuccessful path 306 computation to indicate the set of constraints that could not be 307 satisfied. 309 SWITCH-LAYER Object-Class is to be assigned by IANA (recommended 310 value=19) 312 SWITCH-LAYER Object-Type is to be assigned by IANA (recommended 313 value=1) 315 The format of the SWITCH-LAYER object body is as follows: 317 0 1 2 3 318 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 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | LSP Enc. Type |Switching Type | Reserved |I| 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | . | 323 // . // 324 | . | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | LSP Enc. Type |Switching Type | Reserved |I| 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 Each row indicates a switching type and encoding type that must or 330 must not be used for specified layer(s) in the computed path. 332 The format is based on [RFC3471], and has equivalent semantics. 334 LSP Encoding Type (8 bits): see [RFC3471] for a description of 335 parameters. 337 Switching Type (8 bits): see [RFC3471] for a description of 338 parameters. 340 I flag (1 bit): the I flag indicates whether a layer with the 341 specified switching type and encoding type must or must not be used 342 by the computed path. When the I flag is set (one), the computed path 343 MUST traverse a layer with the specified switching type and encoding 344 type. When the I flag is clear (zero), the computed path MUST NOT 345 enter or traverse any layer with the specified switching type and 346 encoding type. 348 When a combination of switching type and encoding type is not 349 included in SWITCH-LAYER object, the computed path MAY traverse a 350 layer with that combination of switching type and encoding type. 352 A PCC may want to specify only a Switching Type and not an LSP 353 Encoding Type. In this case, the LSP Encoding Type is set to zero. 355 3.3. REQ-ADAP-CAP Object 357 The REQ-ADAP-CAP object is optional and is used to specify a 358 requested adaptation capability for both ends of the lower layer LSP. 359 The REQ-ADAP-CAP object is used in a PCReq message for inter-PCE 360 communication, where the PCE that is responsible for computing higher 361 layer paths acts as a PCC to request a path computation from a PCE 362 that is responsible for computing lower layer paths. 364 The REQ-ADAP-CAP object is used in a PCRep message in case of 365 unsuccessful path computation (in this case, the PCRep message also 366 contains a NO-PATH object, and the REQ-ADAP-CAP object is used to 367 indicate the set of constraints that could not be satisfied). 369 The REQ-ADAP-CAP object MAY be used in a PCReq message in a mono- 370 layer network to specify a requested adaptation capability for both 371 ends of the LSP. In this case, it MAY be carried without INTER-LAYER 372 Object. 374 REQ-ADAP-CAP Object-Class is to be assigned by IANA (recommended 375 value=20) 377 REQ-ADAP-CAP Object-Type is to be assigned by IANA (recommended 378 value=1) 380 The format of the REQ-ADAP-CAP object body is as follows: 382 0 1 2 3 383 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 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | Switching Cap | Encoding | Reserved | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 The format is based on [RFC6001] and has equivalent semantics as the 389 IACD Upper SC and Lower SC. 391 Switching Capability (8 bits): see [RFC4203] for a description of 392 parameters. 394 Encoding (8 bits): see [RFC3471] for a description of parameters. 396 A PCC may want to specify a Switching Capability, but not an Encoding. 397 In this case, the Encoding MUST be set zero. 399 3.4. New Metric Types 401 Two new metric types are defined for the METRIC object in PCEP. 403 Type 11 (suggested value, to be assigned by IANA): Number of 404 adaptations on a path. 406 Type 12 (suggested value, to be assigned by IANA): Number of layers 407 to be involved on a path. 409 3.5. SERVER-INDICATION object 411 The SERVER-INDICATION is optional and is used to indicate that path 412 information included in the ERO is server layer information and 413 specify the characteristics of the server layer, e.g. the switching 414 capability and encoding of the server layer path. 416 0 1 2 3 417 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 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | Switching Cap | Encoding | Reserved | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 ~ Optional TLVs ~ 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 The type of SERVER-INDICATION object is to be assigned by IANA. 426 Switching Capability (8 bits): see [RFC4203] for a description of 427 parameters. 429 Encoding (8 bits): see [RFC3471] for a description of parameters. 431 Optional TLVs: Optional TLVs may be included within the object to 432 specify more specific server layer path information (e.g., traffic 433 parameters). 435 4. Procedures 437 4.1. Path Computation Request 439 A PCC requests or allows inter-layer path computation in a PCReq 440 message by including the INTER-LAYER object with the I flag set. The 441 INTER-LAYER object indicates whether inter-layer path computation is 442 allowed, which path type is requested, and whether triggered 443 signaling is allowed. 445 The SWITCH-LAYER object, which MUST NOT be present unless the INTER- 446 LAYER object is also present, is optionally used to specify the 447 switching types and encoding types that define layers that must, or 448 must not, be used in the computed path. When the SWITCH-LAYER object 449 is used with the INTER-LAYER object I flag clear (zero), inter-layer 450 path computation is not allowed, but constraints specified in the 451 SWITCH-LAYER object apply. Example usage includes path computation in 452 a single layer GMPLS network. 454 The REQ-ADAP-CAP object is optionally used to specify the interface 455 switching capability of both ends of the lower layer LSP. The REQ- 456 ADAP-CAP object is used in inter-PCE communication, where the PCE 457 that is responsible for computing higher layer paths makes a request 458 as a PCC to a PCE that is responsible for computing lower layer paths. 459 Alternatively, the REQ-ADAP-CAP object may be used in the NMS-VNTM 460 model, where the VNTM makes a request as a PCC to a PCE that is 461 responsible for computing lower-layer paths. 463 The METRIC object is optionally used to specify metric types to be 464 optimized or bounded. When metric type 11 (TBC by IANA) is used, it 465 indicates that path computation MUST minimize or bound the number of 466 adaptations on a path. When metric type 12 (TBC by IANA) is used, it 467 indicates that path computation MUST minimize or bound the number of 468 layers to be involved on a path. 470 Furthermore, in order to allow different objective functions to be 471 applied within different network layers, multiple OF objects MAY be 472 present. In such a case, the first OF object specifies an objective 473 function for the higher-layer network, and subsequent OF objects 474 specify objection functions of the subsequent lower-layer networks. 476 4.2. Path Computation Reply 478 In the case of successful path computation, the requested PCE replies 479 to the requesting PCC for the inter-layer path computation result in 480 a PCRep message that MAY include the INTER-LAYER object. When the 481 INTER-LAYER object is included in a PCRep message, the I flag, M flag, 482 and T flag indicate semantics of the path as described in Section 3.1. 483 Furthermore, when the C flag of the METRIC object in a PCReq is set, 484 the METRIC object MUST be included in the PCRep to provide the 485 computed metric value, as specified in [RFC5440]. 487 PCE MAY specify the server layer path information in the ERO. In this 488 case, the requested PCE replies a PCRep message that includes at 489 least two sets of ERO information in the path-list, one is for the 490 client layer path information, and another one is the server layer 491 path information. When SERVER-INDICATION is included in a PCRep 492 message, it indicates that the path in the ERO is the server layer 493 path information. The server layer path specified in the ERO could be 494 loose or strict. On receiving the replied path, the PCC (e.g. NMS, 495 ingress node) can trigger the signaling to setup the LSPs according 496 to the computed paths. 498 In the case of unsuccessful path computation, the PCRep message also 499 contains a NO-PATH object, and the SWITCH-TYPE object and/or the REQ- 500 ADAP-CAP MAY be used to indicate the set of constraints that could 501 not be satisfied. 503 5. Updated Format of PCEP Messages 505 Message formats in this section, as those in [RFC5440] are presented 506 using Backus-Naur Format as specified in [RFC5511]. 508 The format of the PCReq message is updated as follows: 510 ::= 511 [] 512 514 where: 515 ::= 516 [] 518 ::=[] 520 ::= 521 522 [] 523 [] 524 [] 525 [] 526 [[]] 527 [] 528 [] 529 [ []] 530 [] 531 where: 533 ::=[] 534 ::=[] 536 The format of the PCRep message is updated as follows: 537 ::= 538 540 where: 541 ::=[] 543 ::= 544 [] 545 [] 546 [] 548 ::=[] 550 ::= 552 where: 553 ::=[] 554 [] 555 [] 556 [] 557 [] 558 [] 559 [] 560 [] 561 [] 563 ::=[] 564 ::=[] 566 6. Manageability Considerations 568 Manageability of inter-layer traffic engineering with PCE must 569 address the following consideration for section 5.1. 571 - need for a MIB module for control and monitoring 572 - need for built-in diagnostic tools 573 - configuration implication for the protocol 575 7. IANA Considerations 577 7.1. New PCEP Objects 579 Four new objects: INTER-LAYER object, SWITCH-LAYER object, REQ-ADAP- 580 CAP and SERVER-INDICATION object. 582 INTER-LAYER Object-Class is to be assigned by IANA (recommended 583 value=18) 585 INTER-LAYER Object-Type is to be assigned by IANA (recommended 586 value=1) 588 SWITCH-LAYER Object-Class is to be assigned by IANA (recommended 589 value=19) 591 SWITCH-LAYER Object-Type is to be assigned by IANA (recommended 592 value=1) 594 REQ-ADAP-CAP Object-Class is to be assigned by IANA (recommended 595 value=20) 597 REQ-ADAP-CAP Object-Type is to be assigned by IANA (recommended 598 value=1) 600 SERVER-INDICATION Object-Class is to be assigned by IANA (recommended 601 value=21) 603 SERVER-INDICATION Object-Type is to be assigned by IANA (recommended 604 value=1) 606 7.2. New Registry for INTER-LAYER Object Flags 608 IANA is requested to create a registry to manage the Flag field of 609 the INTER-Layer object. 611 New bit numbers may be allocated only by an IETF Consensus action. 612 Each bit should be tracked with the following qualities: 614 o Bit number (counting from bit 0 as the most significant bit) 616 o Capability Description 618 o Defining RFC 620 Several bits are defined for the INTER-LAYER object flag fields in 621 this document. The following values have been assigned: 623 Bit Number Description Reference 625 29 T flag this document 626 30 M flag this document 627 31 I flag this document 629 7.3. METRIC Type 631 Two new metric types are defined in this document for the METRIC 632 object (specified in [RFC5440]). The IANA is requested to make the 633 following allocation (suggested value): 635 - Type 11 : Number of adaptations on a path 637 - Type 12 : Number of layers on a path 639 8. Security Considerations 641 Inter-layer traffic engineering with PCE may raise new security 642 issues when PCE-PCE communication is done between different layer 643 networks for inter-layer path computation. Security issues may also 644 exist when a single PCE is granted full visibility of TE information 645 that applies to multiple layers. 647 Path-Key-based mechanism defined in [RFC5520] MAY be applied to 648 address the topology confidentiality between different layers. 650 9. Acknowledgments 652 The authors would like to thank Cyril Margaria for his valuable 653 comments. 655 10. References 657 10.1. Normative References 659 [RFC2119] S. Bradner, "Key words for use in RFCs to indicate 660 requirements levels", RFC 2119, March 1997. 662 [RFC3471] L. Burger, "Generalized Multi-Protocol Label Switching 663 (GMPLS)", RFC 3471, January 2003. 665 [RFC3945] E. Mannie, "Generalized Multi-Protocol Label Switching 666 Architecture", RFC 3945, October 2004. 668 [RFC4203] K. Kompella and Y. Rekhter, "OSPF Extensions in Support of 669 Generalized Multi-Protocol Label Switching (GMPLS)", RFC 670 4203, October 2005. 672 [RFC4206] K. Kompella, and Y. Rekhter, "Label Switched Paths (LSP) 673 Hierarchy with Generalized Multi-Protocol Label Switching 674 (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. 676 [RFC5440] JP. Vasseur et al, "Path Computation Element (PCE) 677 Communication Protocol (PCEP)" RFC 5440, March 2009. 679 [RFC6457] E. Oki et al., "PCC-PCE Communication Requirements for 680 Inter-Layer Traffic Engineering", RFC6457, December 2011. 682 [RFC5623] E. Oki et al., "Framework for PCE-Based Inter-Layer MPLS 683 and GMPLS Traffic Engineering", September 2009. 685 [RFC5339] JL. Le Roux et al, "Evaluation of Existing GMPLS Protocols 686 against Multi-Layer and Multi-Region Networks (MLN/MRN)", 687 RFC5339, September 2008. 689 10.2. Informative References 691 [RFC4655] A. Farrel, JP. Vasseur and J. Ash, "A Path Computation 692 Element (PCE)-Based Architecture", RFC 4655, September 2006. 694 [RFC5212] K. Shiomoto et al., "Requirements for GMPLS-based multi- 695 region and multi-layer networks (MRN/MLN)", RFC 5212, July 696 2008. 698 [RFC6001] D. Papadimitriou et al., "Generalized Multi-Protocol Label 699 Switching (GMPLS) Protocol Extensions for Multi-Layer and 700 Multi-Region Networks (MLN/MRN)", RFC6001, October 2010. 702 [RFC5150] A. Ayyangar et al., "Label Switched Path Stitching with 703 Generalized Multiprotocol Label Switching Traffic 704 Engineering (GMPLS TE)", RFC 5150, February 2008. 706 [RFC5511] Farrel, A., "Reduced Backus-Naur Form (RBNF) A Syntax Used 707 in Various Protocol Specifications", April 2009. 709 11. Authors' Addresses 711 Eiji Oki 712 University of Electro-Communications 713 Tokyo 714 Japan 715 Email: oki@ice.uec.ac.jp 716 Tomonori Takeda 717 NTT 718 3-9-11 Midori-cho, 719 Musashino-shi, Tokyo 180-8585, Japan 720 Email: takeda.tomonori@lab.ntt.co.jp 722 Jean-Louis Le Roux 723 France Telecom R&D, 724 Av Pierre Marzin, 725 22300 Lannion, France 726 Email: julien.meuric@orange.com 728 Adrian Farrel 729 Juniper Networks 730 Email: adrian@olddog.co.uk 732 Fatai Zhang 733 Huawei Technologies Co., Ltd. 734 F3-5-B R&D Center, Huawei Base, 735 Bantian, Longgang District 736 Shenzhen 518129 P.R.China 737 Phone: +86-755-28972912 738 Email: zhangfatai@huawei.com 740 Intellectual Property 742 The IETF Trust takes no position regarding the validity or scope of 743 any Intellectual Property Rights or other rights that might be 744 claimed to pertain to the implementation or use of the technology 745 described in any IETF Document or the extent to which any license 746 under such rights might or might not be available; nor does it 747 represent that it has made any independent effort to identify any 748 such rights. 750 Copies of Intellectual Property disclosures made to the IETF 751 Secretariat and any assurances of licenses to be made available, or 752 the result of an attempt made to obtain a general license or 753 permission for the use of such proprietary rights by implementers or 754 users of this specification can be obtained from the IETF on-line IPR 755 repository at http://www.ietf.org/ipr 757 The IETF invites any interested party to bring to its attention any 758 copyrights, patents or patent applications, or other proprietary 759 rights that may cover technology that may be required to implement 760 any standard or specification contained in an IETF Document. Please 761 address the information to the IETF at ietf-ipr@ietf.org. 763 The definitive version of an IETF Document is that published by, or 764 under the auspices of, the IETF. Versions of IETF Documents that are 765 published by third parties, including those that are translated into 766 other languages, should not be considered to be definitive versions 767 of IETF Documents. The definitive version of these Legal Provisions 768 is that published by, or under the auspices of, the IETF. Versions of 769 these Legal Provisions that are published by third parties, including 770 those that are translated into other languages, should not be 771 considered to be definitive versions of these Legal Provisions. 773 For the avoidance of doubt, each Contributor to the IETF Standards 774 Process licenses each Contribution that he or she makes as part of 775 the IETF Standards Process to the IETF Trust pursuant to the 776 provisions of RFC 5378. No language to the contrary, or terms, 777 conditions or rights that differ from or are inconsistent with the 778 rights and licenses granted under RFC 5378, shall have any effect and 779 shall be null and void, whether published or posted by such 780 Contributor, or included with or in such Contribution. 782 Disclaimer of Validity 784 All IETF Documents and the information contained therein are provided 785 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 786 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 787 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 788 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 789 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 790 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 791 FOR A PARTICULAR PURPOSE. 793 Full Copyright Statement 795 Copyright (c) 2010 IETF Trust and the persons identified as the 796 document authors. All rights reserved. 798 This document is subject to BCP 78 and the IETF Trust's Legal 799 Provisions Relating to IETF Documents 800 (http://trustee.ietf.org/license-info) in effect on the date of 801 publication of this document. Please review these documents carefully, 802 as they describe your rights and restrictions with respect to this 803 document. Code Components extracted from this document must include 804 Simplified BSD License text as described in Section 4.e of the Trust 805 Legal Provisions and are provided without warranty as described in 806 the Simplified BSD License.