idnits 2.17.1 draft-ietf-pce-gmpls-pcep-extensions-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1255 has weird spacing: '...ted bit routi...' -- The document date (October 17, 2015) is 3112 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: 'I-D.ietf-pce-pceps' is mentioned on line 1648, but not defined == Outdated reference: A later version (-12) exists of draft-ietf-pce-inter-layer-ext-08 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Margaria, Ed. 3 Internet-Draft Juniper 4 Intended status: Standards Track O. Gonzalez de Dios, Ed. 5 Expires: April 19, 2016 Telefonica Investigacion y Desarrollo 6 F. Zhang, Ed. 7 Huawei Technologies 8 October 17, 2015 10 PCEP extensions for GMPLS 11 draft-ietf-pce-gmpls-pcep-extensions-11 13 Abstract 15 This memo provides extensions for the Path Computation Element 16 communication Protocol (PCEP) for the support of GMPLS control plane. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on April 19, 2016. 35 Copyright Notice 37 Copyright (c) 2015 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1. Contributing Authors . . . . . . . . . . . . . . . . . . 3 54 1.2. PCEP requirements for GMPLS . . . . . . . . . . . . . . . 3 55 1.3. Current GMPLS support and limitation of existing PCEP 56 objects . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 1.4. Requirements Language . . . . . . . . . . . . . . . . . . 5 58 2. PCEP objects and extensions . . . . . . . . . . . . . . . . . 6 59 2.1. GMPLS capability advertisement . . . . . . . . . . . . . 6 60 2.1.1. GMPLS Computation TLV in the Existing PCE Discovery 61 Protocol . . . . . . . . . . . . . . . . . . . . . . 6 62 2.1.2. OPEN Object extension GMPLS-CAPABILITY TLV . . . . . 6 63 2.2. RP object extension . . . . . . . . . . . . . . . . . . . 7 64 2.3. BANDWIDTH object extensions . . . . . . . . . . . . . . . 7 65 2.4. LOAD-BALANCING object extensions . . . . . . . . . . . . 10 66 2.5. END-POINTS Object extensions . . . . . . . . . . . . . . 12 67 2.5.1. Generalized Endpoint Object Type . . . . . . . . . . 13 68 2.5.2. END-POINTS TLVs extensions . . . . . . . . . . . . . 16 69 2.6. IRO extension . . . . . . . . . . . . . . . . . . . . . . 19 70 2.7. XRO extension . . . . . . . . . . . . . . . . . . . . . . 20 71 2.8. LSPA extensions . . . . . . . . . . . . . . . . . . . . . 21 72 2.9. NO-PATH Object Extension . . . . . . . . . . . . . . . . 22 73 2.9.1. Extensions to NO-PATH-VECTOR TLV . . . . . . . . . . 22 74 3. Additional Error Type and Error Values Defined . . . . . . . 23 75 4. Manageability Considerations . . . . . . . . . . . . . . . . 24 76 4.1. Control of Function through Configuration and Policy . . 25 77 4.2. Information and Data Models . . . . . . . . . . . . . . . 25 78 4.3. Liveness Detection and Monitoring . . . . . . . . . . . . 25 79 4.4. Verifying Correct Operation . . . . . . . . . . . . . . . 25 80 4.5. Requirements on Other Protocols and Functional Components 26 81 4.6. Impact on Network Operation . . . . . . . . . . . . . . . 26 82 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 83 5.1. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . 26 84 5.2. END-POINTS object, Object Type Generalized Endpoint . . . 27 85 5.3. New PCEP TLVs . . . . . . . . . . . . . . . . . . . . . . 28 86 5.4. RP Object Flag Field . . . . . . . . . . . . . . . . . . 28 87 5.5. New PCEP Error Codes . . . . . . . . . . . . . . . . . . 29 88 5.6. New NO-PATH-VECTOR TLV Fields . . . . . . . . . . . . . 29 89 5.7. New Subobject for the Include Route Object . . . . . . . 30 90 5.8. New Subobject for the Exclude Route Object . . . . . . . 30 91 6. Security Considerations . . . . . . . . . . . . . . . . . . . 31 92 7. Contributing Authors . . . . . . . . . . . . . . . . . . . . 32 93 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 94 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 95 9.1. Normative References . . . . . . . . . . . . . . . . . . 34 96 9.2. Informative References . . . . . . . . . . . . . . . . . 36 97 9.3. Experimental References . . . . . . . . . . . . . . . . . 37 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 101 1. Introduction 103 Although [RFC4655] defines the PCE architecture and framework for 104 both MPLS and GMPLS networks, current PCEP RFCs [RFC5440], [RFC5521], 105 [RFC5541], [RFC5520] are focused on MPLS networks, and do not cover 106 the wide range of GMPLS networks. This document complements these 107 RFCs by addressing the extensions required for GMPLS applications and 108 routing requests, for example for OTN and WSON networks. 110 The functional requirements to be considered by the PCEP extensions 111 to support those application are described in [RFC7025] and 112 [RFC7449]. 114 1.1. Contributing Authors 116 Elie Sfeir, Franz Rambach (Nokia Siemens Networks) Francisco Javier 117 Jimenez Chico (Telefonica Investigacion y Desarrollo) Suresh BR, 118 Young Lee, SenthilKumar S, Jun Sun (Huawei Technologies), Ramon 119 Casellas (CTTC) 121 1.2. PCEP requirements for GMPLS 123 The document [RFC7025] describes the set of PCEP requirements to 124 support GMPLS TE-LSPs. When a PCC requests a PCE to perform a path 125 computation (by means of a PCReq message), the PCC should be able to 126 indicate the following additional information: 128 o Which data flow is switched by the LSP: a combination of Switching 129 type (for instance L2SC or TDM), LSP Encoding type (e.g., 130 Ethernet, SONET/SDH) and sometimes the Signal Type (e.g. in case 131 of TDM/LSC switching capability) 133 o Data flow specific traffic parameters, which are technology 134 specific. For instance, in SDH/SONET and G.709 OTN networks the 135 Concatenation Type and the Concatenation Number have an influence 136 on the switched data and on which link it can be supported 138 o Support for asymmetric bandwidth requests. 140 o Support for unnumbered interface identifiers, as defined in 141 [RFC3477] 143 o Label information and technology specific label(s) such as 144 wavelength labels as defined in [RFC6205]. A PCC should also be 145 able to specify a Label restriction similar to the one supported 146 by RSVP-TE (Resource Reservation Protocol - Traffic Engineering). 148 o Ability to indicate the requested granularity for the path ERO: 149 node, link or label. This is to allow the use of the explicit 150 label control feature of RSVP-TE. 152 We describe in this document a set of PCEP protocol extensions, 153 including new object types, TLVs, encodings, error codes and 154 procedures, in order to fulfill the aforementioned requirements. 156 1.3. Current GMPLS support and limitation of existing PCEP objects 158 PCEP as of [RFC5440], [RFC5521] and [I-D.ietf-pce-inter-layer-ext], 159 supports the following objects, included in requests and responses 160 related to the described requirements. 162 From [RFC5440]: 164 o END-POINTS: only numbered endpoints are considered. The context 165 specifies whether they are node identifiers or numbered 166 interfaces. 168 o BANDWIDTH: the data rate is encoded in the bandwidth object (as 169 IEEE 32 bit float). [RFC5440] does not include the ability to 170 convey an encoding proper to any GMPLS networks. 172 o ERO : Unnumbered endpoints are supported. 174 o LSPA: LSP attributes (setup and holding priorities) 176 From [RFC5521] : 178 o XRO object : 180 * This object allows excluding (strict or not) resources, and 181 includes the requested diversity (node, link or SRLG). 183 * When the F bit is set, the request indicates that the existing 184 route has failed and the resources present in the RRO can be 185 reused. 187 From [I-D.ietf-pce-inter-layer-ext]: 189 o INTER-LAYER : indicates whether inter-layer computation is allowed 191 o SWITCH-LAYER : indicates which layer(s) should be considered, can 192 be used to represent the RSVP-TE generalized label request 194 o REQ-ADAP-CAP : indicates the adaptation capabilities requested, 195 can also be used for the endpoints in case of mono-layer 196 computation 198 The shortcomings of the existing PCEP object are: 200 The BANDWIDTH and LOAD-BALANCING objects do not describe the 201 details of the traffic request (for example NVC, multiplier) in 202 the context of GMPLS networks, for instance TDM or OTN networks. 204 The END-POINTS object does not allow specifying an unnumbered 205 interface, nor potential label restrictions on the interface. 206 Those parameters are of interest in case of switching constraints. 208 The IRO/XRO objects do not allow the inclusion/exclusion of labels 210 Current attributes do not allow expressing the requested link 211 protection level and/or the end-to-end protection attributes. 213 The covered PCEP extensions are: 215 Two new object types are introduced for the BANDWIDTH 216 object(Generalized-Bandwidth, Generalized Bandwidth of existing 217 TE-LSP). 219 A new object type is introduced for the LOAD-BALANCING object 220 (Generalized LOAD-BALANCING). 222 A new object type is introduced for the END-POINTS object 223 (GENERALIZED-ENDPOINT). 225 A new TLV is added to the OPEN message for capability negotiation. 227 A new TLV is added to the LSPA object. 229 A new TLV type for label is allowed in IRO and XRO objects. 231 In order to indicate the used routing granularity in the response, 232 a new flag in the RP object is added. 234 1.4. Requirements Language 236 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 237 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 238 document are to be interpreted as described in RFC 2119 [RFC2119]. 240 2. PCEP objects and extensions 242 This section describes the necessary PCEP objects and extensions. 243 The PCReq and PCRep messages are defined in [RFC5440]. This document 244 does not change the existing grammars 246 2.1. GMPLS capability advertisement 248 2.1.1. GMPLS Computation TLV in the Existing PCE Discovery Protocol 250 IGP-based PCE Discovery (PCED) is defined in [RFC5088] and [RFC5089] 251 for the OSPF and IS-IS protocols. Those documents have defined bit 0 252 in PCE-CAP-FLAGS Sub-TLV of the PCED TLV as "Path computation with 253 GMPLS link constraints". This capability can be used to detect 254 GMPLS-capable PCEs. 256 2.1.2. OPEN Object extension GMPLS-CAPABILITY TLV 258 In addition to the IGP advertisement, a PCEP speaker SHOULD be able 259 to discover the other peer GMPLS capabilities during the Open message 260 exchange. This capability is also useful to avoid misconfigurations. 261 This document defines a new OPTIONAL GMPLS-CAPABILITY TLV for use in 262 the OPEN object to negotiate the GMPLS capability. The inclusion of 263 this TLV in the OPEN message indicates that the PCC/PCE support the 264 PCEP extensions defined in the document. A PCE that is able to 265 support the GMPLS extensions defined in this document SHOULD include 266 the GMPLS-CAPABILITY TLV on the OPEN message. If the PCE does not 267 include the GMPLS-CAPABILITY TLV in the OPEN message and PCC does 268 include the TLV, it is RECOMMENDED that the PCC indicates a mismatch 269 of capabilities. Moreover , in case that the PCC does not receive 270 the GMPLS-CAPABILITY TLV it is RECOMMENDED that the PCC does not make 271 use of the objects and TLVs defined in this document. 273 IANA has allocated value TBA-1 from the "PCEP TLV Type Indicators" 274 sub-registry, as documented in Section 5.3 ("New PCEP TLVs"). The 275 description is "GMPLS-CAPABILITY". Its format is shown in the 276 following figure. 278 0 1 2 3 279 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 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | Type=14 | Length | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | Flags | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 No Flags are defined in this document, they are reserved for future 287 use. 289 2.2. RP object extension 291 Explicit label control (ELC) is a procedure supported by RSVP-TE, 292 where the outgoing label(s) is(are) encoded in the ERO. As a 293 consequence, the PCE can provide such label(s) directly in the path 294 ERO. Depending on policies or switching layer, it can be necessary 295 for the PCC to use explicit label control or expect explicit link, 296 thus it need to indicate in the PCReq which granularity it is 297 expecting in the ERO. This correspond to requirement 12 of [RFC7025] 298 The possible granularities can be node, link or label. The 299 granularities are inter-dependent, in the sense that link granularity 300 implies the presence of node information in the ERO; similarly, a 301 label granularity implies that the ERO contains node, link and label 302 information. 304 A new 2-bit routing granularity (RG) flag (Bits TBA-13) is defined in 305 the RP object. The values are defined as follows 307 0 : reserved 308 1 : node 309 2 : link 310 3 : label 312 The flag in the RP object indicates the requested route granularity. 313 The PCE MAY try to follow this granularity and MAY return a NO-PATH 314 if the requested granularity cannot be provided. The PCE MAY return 315 any granularity it likes on the route based on its policy. The PCC 316 can decide if the ERO is acceptable based on its content. 318 If a PCE honored the requested routing granularity for a request, it 319 MUST indicate the selected routing granularity in the RP object 320 included in the response. Otherwise, the PCE MAY use the reserved RG 321 to leave the check of the ERO to the PCC. The RG flag is backward- 322 compatible with [RFC5440]: the value sent by an implementation (PCC 323 or PCE) not supporting it will indicate a reserved value. 325 2.3. BANDWIDTH object extensions 327 From [RFC5440] the object carrying the request size for the TE-LSP is 328 the BANDWIDTH object. The object types 1 and 2 defined in [RFC5440] 329 do not describe enough information to describe the TE-LSP bandwidth 330 in GMPLS networks. The BANDWIDTH object encoding has to be extended 331 to allow to express the bandwidth as described in [RFC7025]. RSVP-TE 332 extensions for GMPLS provide a set of encoding allowing such 333 representation in an unambiguous way, this is encoded in the RSVP-TE 334 TSpec and FlowSpec objects. This document extends the BANDIDTH 335 object with new object types reusing the RSVP-TE encoding. 337 The following possibilities are to be supported by the new encoding: 339 o Asymmetric bandwidth (different bandwidth in forward and reverse 340 direction), as described in [RFC6387] 342 o GMPLS (SDH/SONET, G.709, ATM, MEF etc) parameters. 344 This correspond to requirement 3, 4, 5 and 11 of [RFC7025] section 345 3.1. 347 This document defines two Object Types for the BANDWIDTH object: 349 TBA-2 Requested generalized bandwidth 351 TBA-3 Generalized bandwidth of an existing TE LSP for which a 352 reoptimization is requested 354 The definitions below apply for Object Type TBA-2 and TBA-3. The 355 payload is as follows: 357 0 1 2 3 358 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 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | Bandwidth Spec Length | Rev. Bandwidth Spec Length | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | Bw Spec Type | Reserved | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | | 365 ~ generalized bandwidth ~ 366 | | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | | 369 ~ Optional : reverse generalized bandwidth ~ 370 | | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | | 373 ~ Optional TLVs ~ 374 | | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 The BANDWIDTH object type TBA-2 and TBA-3 have a variable length. 378 The 16 bit Bandwidth Spec Length field indicates the length of the 379 generalized bandwidth field. The Bandwidth Spec Length MUST be 380 strictly greater than 0. The 16 bit Reverse Bandwidth Spec Length 381 field indicates the length of the reverse generalized bandwidth 382 field. The Reverse Bandwidth Spec Length MAY be equal to 0. 384 The Bw Spec Type field determines which type of bandwidth is 385 represented by the object. 387 The Bw Spec Type correspond to the RSVPT-TE SENDER_TSPEC (Object 388 Class 12) C-Types 390 The encoding of the field generalized bandwidth and reverse 391 generalized bandwidth is the same as the Traffic Parameters carried 392 in RSVP-TE, it can be found in the following references. 394 Object Type Name Reference 396 2 Intserv [RFC2210] 397 4 SONET/SDH [RFC4606] 398 5 G.709 [RFC4328] 399 6 Ethernet [RFC6003] 400 7 OTN-TDM [RFC7139] 402 Generalized bandwidth and reverse generalized bandwidth field 403 encoding 405 When a PCC requests a bi-directional path with symetric bandwidth, it 406 MUST specify the generalized bandwidth field, MUST NOT specify the 407 reverse generalized bandwidth and MUST set the Reverse Bandwidth Spec 408 Length to 0. When a PCC needs to request a bi-directional path with 409 asymmetric bandwidth, it SHOULD specify the different bandwidth in 410 the forward and reverse directions with a generalized bandwidth and 411 reverse generalized bandwidth fields. 413 The procedures described in [RFC5440] for the PCRep is unchanged, a 414 PCE MAY include the BANDWIDTH objects in the response to indicate the 415 BANDWIDTH of the path 417 As specified in [RFC5440] in the case of the reoptimization of a TE 418 LSP, the bandwidth of the existing TE LSP MUST also be included in 419 addition to the requested bandwidth if and only if the two values 420 differ. The Object Type TBA-3 MAY be used instead of object type 2 421 to indicate the existing TE-LSP bandwidth. A PCC that requested a 422 path with a BANDWIDTH object of object type 1 SHOULD use object type 423 2 to represent the existing TE-LSP BANDWIDTH. 425 OPTIONAL TLVs MAY be included within the object body to specify more 426 specific bandwidth requirements. No TLVs for the Object Type TBA-2 427 and TBA-3 are defined by this document. 429 2.4. LOAD-BALANCING object extensions 431 The LOAD-BALANCING object [RFC5440] is used to request a set of 432 maximum Max-LSP TE-LSP having in total the bandwidth specified in 433 BANDWIDTH, each TE-LSP having a minimum of bandwidth. The LOAD- 434 BALANCING follows the bandwidth encoding of the BANDWIDTH object, and 435 thus the existing definition from [RFC5440] does not describe enough 436 details for the bandwidth specification expected by GMPLS. A PCC 437 SHOULD be allowed to request a set of TE-LSP also in case of GMPLS 438 bandwidth specification. 440 The LOAD-BALANCING has the same limitation as the BANDWIDTH for GMPLS 441 networks. Similarly to the BANDWIDTH object a new object type is 442 defined to allow a PCC to represent the bandwidth types supported by 443 GMPLS networks. 445 This document defines the Generalized Load Balancing object type 446 TBA-4 for the LOAD-BALANCING object. The generalized load balancing 447 object type has a variable length. 449 The format of the generalized load balancing object type is as 450 follows: 452 0 1 2 3 453 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 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | Bandwidth spec length | Reverse Bandwidth spec length | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | Bw Spec Type | Max-LSP | Reserved | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | Min Bandwidth Spec | 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 | Min reverse Bandwidth Spec (optional) | 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | | 464 ~ Optional TLVs ~ 465 | | 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 Bandwidth spec length (16 bits): the total length of the min 469 bandwidth specification. It is to be noted that the RSVP-TE traffic 470 specification MAY also include TLV different than the PCEP TLVs. The 471 length MUST be strictly greater than 0. 473 Reverse bandwidth spec length (16 bits): the total length of the 474 reverse min bandwidth specification. It MAY be equal to 0. 476 Bw Spec Type (8 bits) : the bandwidth specification type, it 477 correspond to the RSVPT-TE SENDER_TSPEC (Object Class 12) C-Types 479 Max-LSP (8 bits): maximum number of TE LSPs in the set. 481 Min Bandwidth spec (variable): Specifies the minimum bandwidth spec 482 of each element of the set of TE LSPs. 484 Min Reverse Bandwidth spec (variable): Specifies the minimum reverse 485 bandwidth spec of each element of the set of TE LSPs. 487 The encoding of the field Min Bandwidth Spec and Min Reverse 488 Bandwidth spec is the same as in RSVP-TE SENDER_TSPEC object, it can 489 be found in the following references. 491 Object Type Name Reference 493 2 Intserv [RFC2210] 494 4 SONET/SDH [RFC4606] 495 5 G.709 [RFC4328] 496 6 Ethernet [RFC6003] 497 7 OTN-TDM [RFC7139] 499 Min Bandwidth Spec and Min reverse Bandwidth Spec field encoding 501 When a PCC requests a bi-directional path with symetric bandwidth 502 while specifying load balancing constraints it MUST specify the min 503 Bandwidth spec field, MUST NOT specify the min reverse bandwidth and 504 MUST set the Reverse Bandwidth spec length to 0. When a PCC needs to 505 request a bi-directional path with asymmetric bandwidth while 506 specifying load balancing constraints, it SHOULD specify the 507 different bandwidth in forward and reverse directions through a min 508 Bandwidth spec and min reverse bandwidth fields. 510 OPTIONAL TLVs MAY be included within the object body to specify more 511 specific bandwidth requirements. No TLVs for the generalized load 512 balancing object type are defined by this document. 514 The semantic of the LOAD-BALANCING object is not changed. If a PCC 515 requests the computation of a set of TE LSPs so that the total of 516 their generalized bandwidth is X, the maximum number of TE LSPs is N, 517 and each TE LSP have to have at least have a bandwidth of B, it 518 inserts a BANDWIDTH object specifying X as the required bandwidth and 519 a LOAD-BALANCING object with the Max-LSP and Min-traffic spec fields 520 set to N and B, respectively. 522 For example a request for one co-signaled n x VC-4 TE-LSP will not 523 use the LOAD-BALANCING. In case the V4 components can use different 524 paths, the BANDWIDTH with object type 3 will contain a traffic 525 specification indicating the complete n x VC4 traffic specification 526 and the LOAD-BALANCING the minimum co-signaled VC4. For a SDH 527 network, a request to have a TE-LSP group with 10 VC4 container, each 528 path using at minimum 2 x VC4 container, can be represented with a 529 BANDWIDTH object with OT=3, Bandwidth spec type set to 4, the content 530 of the bandwidth specification is ST=6,RCC=0,NCC=0,NVC=10,MT=1. The 531 LOAD-BALANCING, OT=2 with Bandwidth spec set to 4,Max-LSP=5, min 532 Traffic spec is (ST=6,RCC=0,NCC=0,NVC=2,MT=1). The PCE can respond 533 with a response with maximum 5 path, each of them having a BANDWIDTH 534 OT=3 and traffic spec matching the minimum traffic spec from the 535 LOAD-BALANCING object of the corresponding request. 537 2.5. END-POINTS Object extensions 539 The END-POINTS object is used in a PCEP request message to specify 540 the source and the destination of the path for which a path 541 computation is requested. From [RFC5440]the source IP address and 542 the destination IP address are used to identify those. A new Object 543 Type is defined to address the following possibilities: 545 o Different source and destination endpoint types. 547 o Label restrictions on the endpoint. 549 o Specification of unnumbered endpoints type as seen in GMPLS 550 networks. 552 The Object encoding is described in the following sections. 554 In path computation within a GMPLS context the endpoints can: 556 o Be unnumbered as described in [RFC3477]. 558 o Have label(s) associated to them, specifying a set of constraints 559 in the allocation of labels. 561 o Have different switching capabilities 563 The IPv4 and IPv6 endpoints are used to represent the source and 564 destination IP addresses. The scope of the IP address (Node or 565 numbered Link) is not explicitly stated. It is also possible to 566 request a Path between a numbered link and an unnumbered link, or a 567 P2MP path between different type of endpoints. 569 This document defines the Generalized Endpoint object type TBA-5 for 570 the END-POINTS object. This new C-Type also supports the 571 specification of constraints on the endpoint label to be use. The 572 PCE might know the interface restrictions but this is not a 573 requirement. This corresponds to requirements 6 and 10 of [RFC7025]. 575 2.5.1. Generalized Endpoint Object Type 577 The Generalized Endpoint object type format consists of a body and a 578 list of TLVs scoped to this object type object. The TLVs give the 579 details of the endpoints and are described in Section 2.5.2. For 580 each endpoint type, a different grammar is defined. The TLVs defined 581 to describe an endpoint are: 583 1. IPv4 address endpoint. 585 2. IPv6 address endpoint. 587 3. Unnumbered endpoint. 589 4. Label request. 591 5. Label set. 593 6. Suggested label set. 595 The Label Set and Suggested label set TLVs are used to restrict the 596 label allocation in the PCE. Those TLVs express the set of 597 restrictions provided by signaling. Label restriction support can be 598 an explicit value (Label set describing one label), mandatory range 599 restrictions (Label set), OPTIONAL range restriction (suggested label 600 set) and single suggested value is using the suggested label set. 601 Endpoints label restriction are not always part of the RRO or IRO, 602 they can be included when following [RFC4003] in signaling for egress 603 endpoint, but ingress endpoint properties can be local to the PCC and 604 not signaled. To support this case the label set allows to indicate 605 which label are used in case of reoptimization. The label range 606 restrictions are valid in GMPLS networks, either by PCC policy or 607 depending on the switching technology used, for instance on given 608 Ethernet or ODU equipment having limited hardware capabilities 609 restricting the label range. Label set restriction also applies to 610 WSON networks where the optical sender and receivers are limited in 611 their frequency tunability ranges, restricting then in GMPLS the 612 possible label ranges on the interface. The END-POINTS Object with 613 Generalized Endpoint object type is encoded as follow: 615 0 1 2 3 616 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 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 | Reserved | endpoint type | 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 | | 621 ~ TLVs ~ 622 | | 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 Reserved bits SHOULD be set to 0 when a message is sent and ignored 626 when the message is received 628 the endpoint type is defined as follow: 630 Value Type Meaning 632 0 Point-to-Point 633 1 Point-to-Multipoint New leaves to add 634 2 Old leaves to remove 635 3 Old leaves whose path can be 636 modified/reoptimized 637 4 Old leaves whose path has to be 638 left unchanged 639 5-244 Reserved 640 245-255 Experimental range 642 The endpoint type is used to cover both point-to-point and different 643 point-to-multipoint endpoints. Endpoint type 0 MAY be accepted by 644 the PCE, other endpoint type MAY be supported if the PCE 645 implementation supports P2MP path calculation. A PCE not supporting 646 a given endpoint type MUST respond with a PCErr with error code "Path 647 computation failure", error type "Unsupported endpoint type in END- 648 POINTS Generalized Endpoint object type". The TLVs present in the 649 request object body MUST follow the following grammar: 651 ::= 652 | 654 ::= 655 656 658 ::= 659 660 [] 662 ::= 663 664 [] 666 ::= 667 [] 668 [ []]... 670 For endpoint type Point-to-Multipoint, several endpoint objects MAY 671 be present in the message and each represents a leave, exact meaning 672 depend on the endpoint type defined of the object. 674 An endpoint is defined as follows: 676 ::=|| 677 ::= 678 [] 680 ::= 681 683 ::= 684 [] 685 ::= | 686 688 The different TLVs are described in the following sections. A PCE 689 MAY support IPV4-ADDRESS,IPV6-ADDRESS or UNNUMBERED-ENDPOINT TLV. A 690 PCE not supporting one of those TLVs in a PCReq MUST respond with a 691 PCRep with NO-PATH with the bit "Unknown destination" or "Unknown 692 source" in the NO-PATH-VECTOR TLV, the response SHOULD include the 693 ENDPOINT object in the response with only the TLV it did not 694 understood. 696 A PCE MAY support LABEL-REQUEST, LABEL-SET or SUGGESTED-LABEL-SET 697 TLV. If a PCE finds a non-supported TLV in the END-POINTS the PCE 698 MUST respond with a PCErr message with error type="Path computation 699 failure" error value="Unsupported TLV present in END-POINTS 700 Generalized Endpoint object type" and the message SHOULD include the 701 ENDPOINT object in the response with only the endpoint and endpoint 702 restriction TLV it did not understand. A PCE supporting those TLVs 703 but not being able to fulfil the label restriction MUST send a 704 response with a NO-PATH object which has the bit "No endpoint label 705 resource" or "No endpoint label resource in range" set in the NO- 706 PATH- VECTOR TLV. The response SHOULD include an ENDPOINT object 707 containing only the TLV where the PCE could not meet the constraint. 709 2.5.2. END-POINTS TLVs extensions 711 All endpoint TLVs have the standard PCEP TLV header as defined in 712 [RFC5440] section 7.1. In this object type the order of the TLVs 713 MUST be followed according to the object type definition. 715 2.5.2.1. IPV4-ADDRESS 717 This TLV represent a numbered endpoint using IPv4 numbering, the 718 format of the IPv4-ADDRESS TLV value (TLV-Type=TBA-6) is as follows: 720 0 1 2 3 721 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 722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 723 | IPv4 address | 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 726 This TLV MAY be ignored, in which case a PCRep with NO-PATH SHOULD be 727 responded, as described in Section 2.5.1. 729 2.5.2.2. IPV6-ADDRESS TLV 731 This TLV represent a numbered endpoint using IPV6 numbering, the 732 format of the IPv6-ADDRESS TLV value (TLV-Type=TBA-7) is as follows: 734 0 1 2 3 735 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 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 | IPv6 address (16 bytes) | 738 | | 739 | | 740 | | 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 743 This TLV MAY be ignored, in which case a PCRep with NO-PATH SHOULD be 744 responded, as described in Section 2.5.1. 746 2.5.2.3. UNNUMBERED-ENDPOINT TLV 748 This TLV represent an unnumbered interface. This TLV has the same 749 semantic as in [RFC3477] The TLV value is encoded as follow (TLV- 750 Type=TBA-8) 752 0 1 2 3 753 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 754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 755 | LSR's Router ID | 756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 757 | Interface ID (32 bits) | 758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 760 This TLV MAY be ignored, in which case a PCRep with NO-PATH SHOULD be 761 responded, as described in Section 2.5.1. 763 2.5.2.4. LABEL-REQUEST TLV 765 The LABEL-REQUEST TLV indicates the switching capability and encoding 766 type of the following label restriction list for the endpoint. Its 767 format and encoding is the same as described in [RFC3471] Section 3.1 768 Generalized label request. The LABEL-REQUEST TLV use TLV-Type=TBA-9. 769 The Encoding Type indicates the encoding type, e.g., SONET/SDH/GigE 770 etc., of the LSP with which the data is associated. The Switching 771 type indicates the type of switching that is being requested on the 772 endpoint. G-PID identifies the payload. This TLV and the following 773 one are introduced to satisfy requirement 13 for the endpoint. It is 774 not directly related to the TE-LSP label request, which is expressed 775 by the SWITCH-LAYER object. 777 On the path calculation request only the Tspec and switch layer need 778 to be coherent, the endpoint labels could be different (supporting a 779 different Tspec). Hence the label restrictions include a Generalized 780 label request in order to interpret the labels. This TLV MAY be 781 ignored, in which case a PCRep with NO-PATH SHOULD be responded, as 782 described in Section 2.5.1. 784 2.5.2.5. Labels TLV 786 Label or label range restrictions can be specified for the TE-LSP 787 endpoints. Those are encoded using the LABEL-SET TLV. The label 788 value need to be interpreted with a description on the Encoding and 789 switching type. The REQ-ADAP-CAP object from 790 [I-D.ietf-pce-inter-layer-ext] can be used in case of mono-layer 791 request, however in case of multilayer it is possible to have in the 792 future more than one object, so it is better to have a dedicated TLV 793 for the label and label request (the scope is then more clear). 795 Those TLV MAY be ignored, in which case a response with NO-PATH 796 SHOULD be responded, as described in Section 2.5.1. TLVs are encoded 797 as follow (following [RFC5440]) : 799 o LABEL-SET TLV, Type=TBA-10. The TLV Length is variable, Encoding 800 follows [RFC3471] Section 3.5 "Label set" with the addition of a U 801 bit and O Bit. The U bit is set for upstream direction in case of 802 bidirectional LSP and the O bit is used to represent an old label. 804 0 1 2 3 805 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 806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 807 | Action | Reserved |O|U| Label Type | 808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 809 | Subchannel 1 | 810 | ... | 811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 812 : : : 813 : : : 814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 815 | Subchannel N | 816 | ... | 817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 819 o SUGGESTED-LABEL-SET TLV Set, Type=TBA-11. The TLV length is 820 variable and its encoding is as LABEL-SET TLV. The O bit SHOULD 821 be set to 0. 823 A LABEL-SET TLV represents a set of possible labels that can be used 824 on an interface. The label allocated on the first link SHOULD be 825 within the label set range. The action parameter in the Label set 826 indicates the type of list provided. Those parameters are described 827 by [RFC3471] section 3.5.1 A SUGGESTED-LABEL-SET TLV has the same 828 encoding as the LABEL-SET TLV, it indicates to the PCE a set of 829 preferred (ordered) set of labels to be used. The PCE MAY use those 830 labels for label allocation. 832 The U and 0 bits have the following meaning: 834 U: Upstream direction: set when the label or label set is in the 835 reverse direction 836 O: Old Label: set when the TLV represent the old label in case of re- 837 optimization. This Bit SHOULD be set to 0 in a SUGGESTED-LABEL-SET 838 TLV Set and ignored on receipt. This Label MAY be reused. The R 839 bit of the RP object MUST be set. When this bit is set the Action 840 field MUST be set to 0 (Inclusive List) and the Label Set MUST 841 contain one subchannel. 843 Several LABEL_SET TLVs MAY be present with the O bit cleared. At 844 most 2 LABEL_SET TLV SHOULD be present with the O bit set, at most 845 one with the U bit set and at most one with the U bit cleared. For a 846 given U bit value if more than one LABEL_SET TLV with the O bit set 847 is present, the first TLV SHOULD be processed and the following TLV 848 with the same U and O bit SHOULD be ignored. 850 A SUGGESTED-LABEL-SET TLV with the O bit set MUST trigger a PCErr 851 message with error type="Reception of an invalid object" error 852 value="Wrong LABEL-SET or SUGGESTED-LABEL-SET TLV present with O bit 853 set". 855 A LABEL-SET TLV with the O bit set and an Action Field not set to 0 856 (Inclusive list) or containing more than one subchannel MUST trigger 857 a PCErr message with error type="Reception of an invalid object" 858 error value="Wrong LABEL-SET or SUGGESTED-LABEL-SET TLV present with 859 O bit set". 861 If a LABEL-SET TLV is present with O bit set, the R bit of the RP 862 object MUST be set or a PCErr message with error type="Reception of 863 an invalid object" error value="LABEL-SET TLV present with O bit set 864 but without R bit set in RP". 866 2.6. IRO extension 868 The IRO as defined in [RFC5440] is used to include specific objects 869 in the path. RSVP-TE allows to include label definition, in order to 870 fulfill requirement 13 the IRO needs to support the new subobject 871 type as defined in [RFC3473]: 873 Type Sub-object 874 TBA-37 LABEL 876 The L bit of such sub-object has no meaning within an IRO. 878 The Label subobject MUST follow a subobject identifying a link, 879 currently an IP address subobject (Type 1 or 2) or an interface id 880 (type 4) subobject. If an IP address subobject is used, then the IP 881 address given MUST be associated with a link. More than one label 882 subobject MAY follow each link subobject. The procedure associated 883 with this subobject is as follows. 885 If the PCE allocates labels (e.g via explicit label control) the PCE 886 MUST allocate one label from within the set of label values for the 887 given link. If the PCE does not assign labels then it sends a 888 response with a NO-PATH object, containing a NO-PATH-VECTOR-TLV with 889 the bit 'No label resource in range' set. 891 2.7. XRO extension 893 The XRO as defined in [RFC5521] is used to exclude specific objects 894 in the path. RSVP-TE allows to exclude labels ([RFC6001], in order 895 to fulfill requirement 13 of [RFC7025] section 3.1, the XRO needs to 896 support a new subobject to support label exclusion. 898 The encoding of the XRO Label subobject follows the encoding of the 899 Label ERO subobject defined in [RFC3473] and XRO subobject defined in 900 [RFC5521]. The XRO Label subobject represent one Label and is 901 defined as follows: 903 XRO Subobject Type TBA-38: Label Subobject. 905 0 1 2 3 906 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 907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 908 |X| Type=3 | Length |U| Reserved | C-Type | 909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 910 | Label | 911 | ... | 912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 914 X (1 bit) 916 As per [RFC5521]. The X-bit indicates whether the exclusion is 917 mandatory or desired. 0 indicates that the resource specified 918 MUST be excluded from the path computed by the PCE. 1 919 indicates that the resource specified SHOULD be excluded from 920 the path computed by the PCE, but MAY be included subject to 921 PCE policy and the absence of a viable path that meets the 922 other constraints and excludes the resource. 924 Type (7 bits) 926 The Type of the XRO Label subobject is TBA, suggested value 3. 928 Length (8 bits) 930 See [RFC5521],The total length of the subobject in bytes 931 (including the Type and Length fields). The Length is always 932 divisible by 4. 934 U (1 bit) 936 See [RFC3471]. 938 C-Type (8 bits) 940 The C-Type of the included Label Object as defined in 941 [RFC3471]. 943 Label 945 See [RFC3471]. 947 The Label subobject MUST follow a subobject identifying a link, 948 currently an IP address subobject (Type 1 or 2) or an interface id 949 (type 4) subobject. If an IP address subobject is used, then the IP 950 address given MUST be associated with a link. More than one label 951 subobject MAY follow each link subobject. 953 Type Sub-object 954 3 LABEL 956 The L bit of such sub-object has no meaning within an XRO. 958 2.8. LSPA extensions 960 The LSPA carries the LSP attributes. In the end-to-end protection 961 context this also includes the protection state information. This 962 object is introduced to fulfill requirement 7 of [RFC7025] section 963 3.1 and requirement 3 of [RFC7025] section 3.2. This object contains 964 the information of the PROTECTION object defined by [RFC4872] and 965 can be used as a policy input. The LSPA object MAY carry a 966 PROTECTION-ATTRIBUTE TLV defined as : Type TBA-12: PROTECTION- 967 ATTRIBUTE 968 0 1 2 3 969 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 970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 971 | Type | Length | 972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 973 |S|P|N|O| Reserved | LSP Flags | Reserved | Link Flags| 974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 975 |I|R| Reserved | Seg.Flags | Reserved | 976 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 978 The content is as defined in [RFC4872], [RFC4873]. 980 LSP (protection) Flags or Link flags field can be used by 981 implementation for routing policy input. The other attributes are 982 only meaningful for a stateful PCE. 984 This TLV is OPTIONAL and MAY be ignored by the PCE, in which case it 985 MUST NOT include the TLV in the LSPA, if present, of the response. 986 When the TLV is used by the PCE, a LSPA object and the PROTECTION- 987 ATTRIBUTE TLV MUST be included in the response. Fields that were not 988 considered MUST be set to 0. 990 2.9. NO-PATH Object Extension 992 The NO-PATH object is used in PCRep messages in response to an 993 unsuccessful path computation request (the PCE could not find a path 994 satisfying the set of constraints). In this scenario, PCE MUST 995 include a NO-PATH object in the PCRep message. The NO-PATH object 996 MAY carries the NO-PATH-VECTOR TLV that specifies more information on 997 the reasons that led to a negative reply. In case of GMPLS networks 998 there could be some more additional constraints that led to the 999 failure like protection mismatch, lack of resources, and so on. Few 1000 new flags have been introduced in the 32-bit flag field of the NO- 1001 PATH-VECTOR TLV and no modifications have been made in the NO-PATH 1002 object. 1004 2.9.1. Extensions to NO-PATH-VECTOR TLV 1006 The modified NO-PATH-VECTOR TLV carrying the additional information 1007 is as follows: 1009 Bit number TBA-31 - Protection Mismatch (1-bit). Specifies the 1010 mismatch of the protection type in the PROTECTION-ATTRIBUTE TLV in 1011 the request. 1013 Bit number TBA-32 - No Resource (1-bit). Specifies that the 1014 resources are not currently sufficient to provide the path. 1016 Bit number TBA-33 - Granularity not supported (1-bit). Specifies 1017 that the PCE is not able to provide a route with the requested 1018 granularity. 1020 Bit number TBA-34 - No endpoint label resource (1-bit). Specifies 1021 that the PCE is not able to provide a route because of the 1022 endpoint label restriction. 1024 Bit number TBA-35 - No endpoint label resource in range (1-bit). 1025 Specifies that the PCE is not able to provide a route because of 1026 the endpoint label set restriction. 1028 Bit number TBA-36 - No label resource in range (1-bit). Specifies 1029 that the PCE is not able to provide a route because of the label 1030 set restriction. 1032 3. Additional Error Type and Error Values Defined 1034 A PCEP-ERROR object is used to report a PCEP error and is 1035 characterized by an Error-Type that specifies the type of error while 1036 Error-value that provides additional information about the error. An 1037 additional error type and few error values are defined to represent 1038 some of the errors related to the newly identified objects related to 1039 GMPLS networks. For each PCEP error, an Error-Type and an Error- 1040 value are defined. Error-Type 1 to 10 are already defined in 1041 [RFC5440]. Additional Error- values are defined for Error-Type 10 1042 and A new Error-Type is introduced (value TBA). 1044 Error-Type Error-value 1046 10 Reception of 1047 an invalid 1048 object 1049 value=TBA-14: Bad Bandwidth Object type TBA(Generalized 1050 bandwidth) or TBA(Generalized 1051 bandwidth,reoptimization). 1052 value=TBA-15: Bandwidth Object type TBA or TBA not 1053 supported. 1054 value=TBA-16: Unsupported LSP Protection Type in 1055 PROTECTION-ATTRIBUTE TLV. 1056 value=TBA-17: Unsupported LSP Protection Flags in 1057 PROTECTION-ATTRIBUTE TLV. 1058 value=TBA-18: Unsupported Secondary LSP Protection Flags 1059 in PROTECTION-ATTRIBUTE TLV. 1060 value=TBA-19: Unsupported Link Protection Type in 1061 PROTECTION-ATTRIBUTE TLV. 1062 value=TBA-20: Unsupported Link Protection Type in 1063 PROTECTION-ATTRIBUTE TLV. 1064 value=TBA-21: LABEL-SET TLV present with 0 bit set but 1065 without R bit set in RP. 1066 value=TBA-22: Wrong LABEL-SET or 1067 SUGGESTED-LABEL-SET TLV present with 1068 0 bit set. 1069 TBA-23 Path 1070 computation 1071 failure 1072 value=TBA-24: Unacceptable request message. 1073 value=TBA-25: Generalized bandwidth value not supported. 1074 value=TBA-26: Label Set constraint could not be 1075 met. 1076 value=TBA-27: Label constraint could not be 1077 met. 1078 value=TBA-28: Unsupported endpoint type in 1079 END-POINTS Generalized Endpoint 1080 object type. 1081 value=TBA-29: Unsupported TLV present in END-POINTS 1082 Generalized Endpoint object type. 1083 value=TBA-30: Unsupported granularity in the RP object 1084 flags. 1086 4. Manageability Considerations 1088 This section follows the guidance of [RFC6123]. 1090 4.1. Control of Function through Configuration and Policy 1092 This document makes no change to the basic operation of PCEP and so 1093 the requirements described in [RFC5440] Section 8.1. also apply to 1094 this document. In addition to those requirements a PCEP 1095 implementation MAY allow the configuration of the following 1096 parameters: 1098 Accepted RG in the RP object. 1100 Default RG to use (overriding the one present in the PCReq) 1102 Accepted BANDWIDTH object type TBA and TBA (Generalized 1103 Bandwidth)parameters in request, default mapping to use when not 1104 specified in the request 1106 Accepted LOAD-BALANCING object type TBA parameters in request. 1108 Accepted endpoint type and allowed TLVs in object END-POINTS with 1109 object type Generalized Endpoint. 1111 Accepted range for label restrictions in label restriction in END- 1112 POINTS, or IRO or XRO objects 1114 PROTECTION-ATTRIBUTE TLV acceptance and suppression. 1116 Those parameters configuration are applicable to the different 1117 sessions as described in [RFC5440] Section 8.1 (by default, per PCEP 1118 peer, ..etc). 1120 4.2. Information and Data Models 1122 This document makes no change to the basic operation of PCEP and so 1123 the requirements described in [RFC5440] Section 8.2. also apply to 1124 this document. This document does not introduces new ERO sub object, 1125 ERO information model is already covered in [RFC4802]. 1127 4.3. Liveness Detection and Monitoring 1129 This document makes no change to the basic operation of PCEP and so 1130 there are no changes to the requirements for liveness detection and 1131 monitoring set out in [RFC4657] and [RFC5440] Section 8.3. 1133 4.4. Verifying Correct Operation 1135 This document makes no change to the basic operations of PCEP and 1136 considerations described in [RFC5440] Section 8.4. New errors 1137 introduced by this document should be covered by the requirement to 1138 log error events. 1140 4.5. Requirements on Other Protocols and Functional Components 1142 No new Requirements on Other Protocols and Functional Components are 1143 made by this document. This document does not require ERO object 1144 extensions. Any new ERO subobject defined in CCAMP working group can 1145 be adopted without modifying the operations defined in this document. 1147 4.6. Impact on Network Operation 1149 This document makes no change to the basic operations of PCEP and 1150 considerations described in [RFC5440] Section 8.6. In addition to 1151 the limit on the rate of messages sent by a PCEP speaker, a limit MAY 1152 be placed on the size of the PCEP messages. 1154 5. IANA Considerations 1156 IANA assigns values to the PCEP protocol objects and TLVs. IANA is 1157 requested to make some allocations for the newly defined objects and 1158 TLVs introduced in this document. Also, IANA is requested to manage 1159 the space of flags that are newly added in the TLVs. 1161 5.1. PCEP Objects 1163 As described in Section 2.3, Section 2.4 and Section 2.5.1 new 1164 Objects types are defined. IANA is requested to make the following 1165 Object-Type allocations from the "PCEP Objects" sub-registry. 1167 Object 5 1168 Class 1169 Name BANDWIDTH 1170 Object-Type TBA-2 : Generalized bandwidth 1171 TBA-3: Generalized bandwidth of an existing TE LSP for 1172 which a reoptimization is requested 1173 5-15: Unassigned 1174 Reference This document (section Section 2.3) 1176 Object 14 1177 Class 1178 Name LOAD-BALANCING 1179 Object-Type TBA-4: Generalized load balancing 1180 3-15: Unassigned 1182 Reference This document (section Section 2.4) 1183 Object 4 1184 Class 1185 Name END-POINTS 1186 Object-Type TBA-5: Generalized Endpoint 1187 6-15: unassigned 1188 Reference This document (section Section 2.5) 1190 5.2. END-POINTS object, Object Type Generalized Endpoint 1192 IANA is requested to create a registry to manage the endpoint type 1193 field of the END-POINTS object, Object Type Generalized Endpoint and 1194 manage the code space. 1196 New endpoint type in the Reserved range MAY be allocated by an IETF 1197 consensus action. Each endpoint type should be tracked with the 1198 following qualities: 1200 o endpoint type 1202 o Description 1204 o Defining RFC 1206 New endpoint type in the Experimental range are for experimental use; 1207 these will not be registered with IANA and MUST NOT be mentioned by 1208 RFCs. 1210 The following values have been defined by this document. 1211 (Section 2.5.1, Table 4): 1213 Value Type Meaning 1215 0 Point-to-Point 1216 1 Point-to-Multipoint New leaves to add 1217 2 Old leaves to remove 1218 3 Old leaves whose path can be 1219 modified/reoptimized 1220 4 Old leaves whose path has to be 1221 left unchanged 1222 5-244 Reserved 1223 245-255 Experimental range 1225 5.3. New PCEP TLVs 1227 IANA manages the PCEP TLV code point registry (see [RFC5440]). This 1228 is maintained as the "PCEP TLV Type Indicators" sub-registry of the 1229 "Path Computation Element Protocol (PCEP) Numbers" registry. This 1230 document defines new PCEP TLVs, to be carried in the END-POINTS 1231 object with Generalized Endpoint object Type. IANA is requested to 1232 do the following allocation. The values here are suggested for use 1233 by IANA. 1235 Value Meaning Reference 1237 TBA-6 IPV4-ADDRESS This document (section Section 2.5.2.1) 1238 TBA-7 IPV6-ADDRESS This document (section Section 2.5.2.2) 1239 TBA-8 UNNUMBERED-ENDPOINT This document (section Section 2.5.2.3) 1240 TBA-9 LABEL-REQUEST This document (section Section 2.5.2.4) 1241 TBA-10 LABEL-SET This document (section Section 2.5.2.5) 1242 TBA-11 SUGGESTED-LABEL-SET This document (section Section 2.5.2.5) 1243 TBA-12 PROTECTION-ATTRIBUTE This document (section Section 2.8) 1244 TBA-1 GMPLS-CAPABILITY This document (section Section 2.1.2) 1246 5.4. RP Object Flag Field 1248 As described in Section 2.2 new flag are defined in the RP Object 1249 Flag IANA is requested to make the following Object-Type allocations 1250 from the "RP Object Flag Field" sub-registry. The values here are 1251 suggested for use by IANA. 1253 Bit Description Reference 1255 TBA-13 (suggested bit routing granularity This document, Section 1256 17-16) (RG) 2.2 1258 5.5. New PCEP Error Codes 1260 As described in Section 3, new PCEP Error-Type and Error Values are 1261 defined. IANA is requested to make the following allocation in the 1262 "PCEP-ERROR Object Error Types and Values" registry. The values here 1263 are suggested for use by IANA. 1265 Error name Reference 1267 Type=10 Reception of an invalid object [RFC5440] 1268 Value=TBA-14: Bad Bandwidth Object type TBA(Generalized This Document 1269 bandwidth) or TBA(Generalized 1270 bandwidth,reoptimization). 1271 Value=TBA-15: Bandwidth Object type TBA or TBA not This Document 1272 supported. 1273 Value=TBA-16: Unsupported LSP Protection Type in This Document 1274 PROTECTION-ATTRIBUTE TLV. 1275 Value=TBA-17: Unsupported LSP Protection Flags in This Document 1276 PROTECTION-ATTRIBUTE TLV. 1277 Value=TBA-18: Unsupported Secondary LSP Protection This Document 1278 Flags in PROTECTION-ATTRIBUTE TLV. 1279 Value=TBA-19: Unsupported Link Protection Type in This Document 1280 PROTECTION-ATTRIBUTE TLV. 1281 Value=TBA-20: Unsupported Link Protection Type in This Document 1282 PROTECTION-ATTRIBUTE TLV. 1283 Value=TBA-21: LABEL-SET TLV present with 0 bit set but This Document 1284 without R bit set in RP. 1285 Value=TBA-22: Wrong LABEL-SET or SUGGESTED-LABEL-SET This Document 1286 TLV present with 0 bit set. 1287 Type=TBA-23 Path computation failure This Document 1288 Value=TBA-24: Unacceptable request message. This Document 1289 Value=TBA-25: Generalized bandwidth value not This Document 1290 supported. 1291 Value=TBA-26: Label Set constraint could not be met. This Document 1292 Value=TBA-27: Label constraint could not be met. This Document 1293 Value=TBA-28: Unsupported endpoint type in END-POINTS This Document 1294 Generalized Endpoint object type 1295 Value=TBA-29: Unsupported TLV present in END-POINTS This Document 1296 Generalized Endpoint object type 1297 Value=TBA-30: Unsupported granularity in the RP object This Document 1298 flags 1300 5.6. New NO-PATH-VECTOR TLV Fields 1302 As described in Section 2.9.1, new NO-PATH-VECTOR TLV Flag Fields 1303 have been defined. IANA is requested to do the following allocations 1304 in the "NO-PATH-VECTOR TLV Flag Field" sub-registry. The values here 1305 are suggested for use by IANA. 1307 Bit number TBA-31 - Protection Mismatch (1-bit). Specifies the 1308 mismatch of the protection type of the PROTECTION-ATTRIBUTE TLV in 1309 the request. 1311 Bit number TBA-32 - No Resource (1-bit). Specifies that the 1312 resources are not currently sufficient to provide the path. 1314 Bit number TBA-33 - Granularity not supported (1-bit). Specifies 1315 that the PCE is not able to provide a route with the requested 1316 granularity. 1318 Bit number TBA-34 - No endpoint label resource (1-bit). Specifies 1319 that the PCE is not able to provide a route because of the 1320 endpoint label restriction. 1322 Bit number TBA-35 - No endpoint label resource in range (1-bit). 1323 Specifies that the PCE is not able to provide a route because of 1324 the endpoint label set restriction. 1326 Bit number TBA-36 - No label resource in range (1-bit). Specifies 1327 that the PCE is not able to provide a route because of the label 1328 set restriction. 1330 5.7. New Subobject for the Include Route Object 1332 The "PCEP Parameters" registry contains a subregistry "PCEP Objects" 1333 with an entry for the Include Route Object (IRO). 1335 IANA is requested to add a further subobject that can be carried in 1336 the IRO as follows: 1338 Subobject type Reference 1340 TBA-37, suggested value 3 Label subobject [RFC3473] 1342 5.8. New Subobject for the Exclude Route Object 1344 The "PCEP Parameters" registry contains a subregistry "PCEP Objects" 1345 with an entry for the XRO object (Exclude Route Object). 1347 IANA is requested to add a further subobject that can be carried in 1348 the XRO as follows: 1350 Subobject type Reference 1352 TBA-38, suggested value 3 Label subobject [RFC3473] 1354 6. Security Considerations 1356 GMPLS controls multiple technologies and types of network elements. 1357 The LSPs that are established using GMPLS, whose paths can be 1358 computed using the PCEP extensions to support GMPLS described in this 1359 document, can carry a high amount of traffic and can be a critical 1360 part of a network infrastructure. The PCE can then play a key role 1361 in the use of the resources and in determining the physical paths of 1362 the LSPs and thus it is important to ensure the identity of PCE and 1363 PCC, as well as the communication channel. In many deployments there 1364 will be a completely isolated network where an external attack is of 1365 very low probability. However, there are other deployment cases in 1366 which the PCC-PCE communication can be more exposed and there could 1367 be more security considerations. Three main situations in case of an 1368 attack in the GMPLS PCE context could happen: 1370 o PCE Identity theft: A legitimate PCC could requests a path for a 1371 GMPLS LSP to a malicious PCE, which poses as a legitimate PCE. 1372 The answer can make that the LSP traverses some geographical place 1373 known to the attacker where some sniffing devices could be 1374 installed. Also, the answer can omit constraints given in the 1375 requests (e.g. excluding certain fibers, avoiding some SRLGs) 1376 which could make that the LSP which will be later set-up can look 1377 perfectly fine, but will be in a risky situation. Also, the 1378 answer can lead to provide a LSP that does not provide the desired 1379 quality and gives less resources tan necessary. 1381 o PCC Identity theft: A malicious PCC, acting as a legitimate PCC, 1382 requesting LSP paths to a legitimate PCE can obtain a good 1383 knowledge of the physical topology of a critical infrastructure. 1384 It could get to know enough details to plan a later physical 1385 attack. 1387 o Message deciphering: As in the previous case, knowledge of an 1388 infrastructure can be obtained by sniffing PCEP messages. 1390 The security mechanisms can provide authentication and 1391 confidentiality for those scenarios where the PCC-PCE communication 1392 cannot be completely trusted. Authentication can provide origin 1393 verification, message integrity and replay protection, while 1394 confidentiality ensures that a third party cannot decipher the 1395 contents of a message. 1397 The document [I-D.ietf-pce-pceps] describes the usage of Transport 1398 Layer Security (TLS) to enhance PCEP security. The document 1399 describes the initiation of the TLS procedures, the TLS handshake 1400 mechanisms, the TLS methods for peer authentication, the applicable 1401 TLS ciphersuites for data exchange, and the handling of errors in the 1402 security checks. 1404 Finally, as mentioned by [RFC7025] the PCEP extensions to support 1405 GMPLS should be considered under the same security as current PCE 1406 work and this extension will not change the underlying security 1407 issues. However, given the critical nature of the network 1408 infrastructures under control by GMPLS, the security issues described 1409 above should be seriously considered when deploying a GMPLS-PCE based 1410 control plane for such networks. For more information on the 1411 security considerations on a GMPLS control plane, not only related to 1412 PCE/PCEP, [RFC5920] provides an overview of security vulnerabilities 1413 of a GMPLS control plane. 1415 7. Contributing Authors 1417 Elie Sfeir 1418 Coriant 1419 St Martin Strasse 76 1420 Munich, 81541 1421 Germany 1423 Email: elie.sfeir@coriant.com 1425 Franz Rambach 1426 Nockherstrasse 2-4, 1427 Munich 81541 1428 Germany 1430 Phone: +49 178 8855738 1431 Email: franz.rambach@cgi.com 1433 Francisco Javier Jimenez Chico 1434 Telefonica Investigacion y Desarrollo 1435 C/ Emilio Vargas 6 1436 Madrid, 28043 1437 Spain 1439 Phone: +34 91 3379037 1440 Email: fjjc@tid.es 1442 Huawei Technologies 1444 Suresh BR 1445 Shenzhen 1446 China 1447 Email: sureshbr@huawei.com 1448 Young Lee 1449 1700 Alma Drive, Suite 100 1450 Plano, TX 75075 1451 USA 1453 Phone: (972) 509-5599 (x2240) 1454 Email: ylee@huawei.com 1456 SenthilKumar S 1457 Shenzhen 1458 China 1459 Email: senthilkumars@huawei.com 1461 Jun Sun 1462 Shenzhen 1463 China 1464 Email: johnsun@huawei.com 1466 CTTC - Centre Tecnologic de Telecomunicacions de Catalunya 1468 Ramon Casellas 1469 PMT Ed B4 Av. Carl Friedrich Gauss 7 1470 08860 Castelldefels (Barcelona) 1471 Spain 1472 Phone: (34) 936452916 1473 Email: ramon.casellas@cttc.es 1475 8. Acknowledgments 1477 The research of Ramon Casellas, Francisco Javier Jimenez Chico, Oscar 1478 Gonzalez de Dios, Cyril Margaria, and Franz Rambach leading to these 1479 results has received funding from the European Community's Seventh 1480 Framework Program FP7/2007-2013 under grant agreement no 247674 and 1481 no 317999. 1483 The authors would like to thank Lyndon Ong, Giada Lander, Jonathan 1484 Hardwick and Diego Lopez for their useful comments to the document. 1486 9. References 1487 9.1. Normative References 1489 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1490 Requirement Levels", BCP 14, RFC 2119, 1491 DOI 10.17487/RFC2119, March 1997, 1492 . 1494 [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated 1495 Services", RFC 2210, DOI 10.17487/RFC2210, September 1997, 1496 . 1498 [RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label 1499 Switching (GMPLS) Signaling Functional Description", 1500 RFC 3471, DOI 10.17487/RFC3471, January 2003, 1501 . 1503 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 1504 Switching (GMPLS) Signaling Resource ReserVation Protocol- 1505 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 1506 DOI 10.17487/RFC3473, January 2003, 1507 . 1509 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 1510 in Resource ReSerVation Protocol - Traffic Engineering 1511 (RSVP-TE)", RFC 3477, DOI 10.17487/RFC3477, January 2003, 1512 . 1514 [RFC4003] Berger, L., "GMPLS Signaling Procedure for Egress 1515 Control", RFC 4003, DOI 10.17487/RFC4003, February 2005, 1516 . 1518 [RFC4328] Papadimitriou, D., Ed., "Generalized Multi-Protocol Label 1519 Switching (GMPLS) Signaling Extensions for G.709 Optical 1520 Transport Networks Control", RFC 4328, 1521 DOI 10.17487/RFC4328, January 2006, 1522 . 1524 [RFC4606] Mannie, E. and D. Papadimitriou, "Generalized Multi- 1525 Protocol Label Switching (GMPLS) Extensions for 1526 Synchronous Optical Network (SONET) and Synchronous 1527 Digital Hierarchy (SDH) Control", RFC 4606, 1528 DOI 10.17487/RFC4606, August 2006, 1529 . 1531 [RFC4802] Nadeau, T., Ed., Farrel, A., and , "Generalized 1532 Multiprotocol Label Switching (GMPLS) Traffic Engineering 1533 Management Information Base", RFC 4802, 1534 DOI 10.17487/RFC4802, February 2007, 1535 . 1537 [RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, 1538 Ed., "RSVP-TE Extensions in Support of End-to-End 1539 Generalized Multi-Protocol Label Switching (GMPLS) 1540 Recovery", RFC 4872, DOI 10.17487/RFC4872, May 2007, 1541 . 1543 [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, 1544 "GMPLS Segment Recovery", RFC 4873, DOI 10.17487/RFC4873, 1545 May 2007, . 1547 [RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 1548 Zhang, "OSPF Protocol Extensions for Path Computation 1549 Element (PCE) Discovery", RFC 5088, DOI 10.17487/RFC5088, 1550 January 2008, . 1552 [RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 1553 Zhang, "IS-IS Protocol Extensions for Path Computation 1554 Element (PCE) Discovery", RFC 5089, DOI 10.17487/RFC5089, 1555 January 2008, . 1557 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1558 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 1559 DOI 10.17487/RFC5440, March 2009, 1560 . 1562 [RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel, 1563 "Preserving Topology Confidentiality in Inter-Domain Path 1564 Computation Using a Path-Key-Based Mechanism", RFC 5520, 1565 DOI 10.17487/RFC5520, April 2009, 1566 . 1568 [RFC5521] Oki, E., Takeda, T., and A. Farrel, "Extensions to the 1569 Path Computation Element Communication Protocol (PCEP) for 1570 Route Exclusions", RFC 5521, DOI 10.17487/RFC5521, April 1571 2009, . 1573 [RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of 1574 Objective Functions in the Path Computation Element 1575 Communication Protocol (PCEP)", RFC 5541, 1576 DOI 10.17487/RFC5541, June 2009, 1577 . 1579 [RFC6001] Papadimitriou, D., Vigoureux, M., Shiomoto, K., Brungard, 1580 D., and JL. Le Roux, "Generalized MPLS (GMPLS) Protocol 1581 Extensions for Multi-Layer and Multi-Region Networks (MLN/ 1582 MRN)", RFC 6001, DOI 10.17487/RFC6001, October 2010, 1583 . 1585 [RFC6003] Papadimitriou, D., "Ethernet Traffic Parameters", 1586 RFC 6003, DOI 10.17487/RFC6003, October 2010, 1587 . 1589 [RFC6205] Otani, T., Ed. and D. Li, Ed., "Generalized Labels for 1590 Lambda-Switch-Capable (LSC) Label Switching Routers", 1591 RFC 6205, DOI 10.17487/RFC6205, March 2011, 1592 . 1594 [RFC6387] Takacs, A., Berger, L., Caviglia, D., Fedyk, D., and J. 1595 Meuric, "GMPLS Asymmetric Bandwidth Bidirectional Label 1596 Switched Paths (LSPs)", RFC 6387, DOI 10.17487/RFC6387, 1597 September 2011, . 1599 [RFC7139] Zhang, F., Ed., Zhang, G., Belotti, S., Ceccarelli, D., 1600 and K. Pithewan, "GMPLS Signaling Extensions for Control 1601 of Evolving G.709 Optical Transport Networks", RFC 7139, 1602 DOI 10.17487/RFC7139, March 2014, 1603 . 1605 9.2. Informative References 1607 [I-D.ietf-pce-inter-layer-ext] 1608 Oki, E., Takeda, T., Farrel, A., and F. Zhang, "Extensions 1609 to the Path Computation Element communication Protocol 1610 (PCEP) for Inter-Layer MPLS and GMPLS Traffic 1611 Engineering", draft-ietf-pce-inter-layer-ext-08 (work in 1612 progress), January 2014. 1614 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 1615 Element (PCE)-Based Architecture", RFC 4655, 1616 DOI 10.17487/RFC4655, August 2006, 1617 . 1619 [RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation 1620 Element (PCE) Communication Protocol Generic 1621 Requirements", RFC 4657, DOI 10.17487/RFC4657, September 1622 2006, . 1624 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 1625 Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, 1626 . 1628 [RFC6123] Farrel, A., "Inclusion of Manageability Sections in Path 1629 Computation Element (PCE) Working Group Drafts", RFC 6123, 1630 DOI 10.17487/RFC6123, February 2011, 1631 . 1633 [RFC7025] Otani, T., Ogaki, K., Caviglia, D., Zhang, F., and C. 1634 Margaria, "Requirements for GMPLS Applications of PCE", 1635 RFC 7025, DOI 10.17487/RFC7025, September 2013, 1636 . 1638 [RFC7449] Lee, Y., Ed., Bernstein, G., Ed., Martensson, J., Takeda, 1639 T., Tsuritani, T., and O. Gonzalez de Dios, "Path 1640 Computation Element Communication Protocol (PCEP) 1641 Requirements for Wavelength Switched Optical Network 1642 (WSON) Routing and Wavelength Assignment", RFC 7449, 1643 DOI 10.17487/RFC7449, February 2015, 1644 . 1646 9.3. Experimental References 1648 [I-D.ietf-pce-pceps] 1649 Lopez, D., Dios, O., Wu, W., and D. Dhody, "Secure 1650 Transport for PCEP", draft-ietf-pce-pceps-04 (work in 1651 progress), May 2015. 1653 Authors' Addresses 1655 Cyril Margaria (editor) 1656 Juniper 1657 200 Somerset Corporate Boulevard, , Suite 4001 1658 Bridgewater, NJ 08807 1659 USA 1661 Email: cmargaria@juniper.net 1663 Oscar Gonzalez de Dios (editor) 1664 Telefonica Investigacion y Desarrollo 1665 C/ Ronda de la Comunicacion 1666 Madrid 28050 1667 Spain 1669 Phone: +34 91 4833441 1670 Email: oscar.gonzalezdedios@telefonica.com 1671 Fatai Zhang (editor) 1672 Huawei Technologies 1673 F3-5-B R&D Center, Huawei Base 1674 Bantian, Longgang District 1675 Shenzhen 518129 1676 P.R.China 1678 Email: zhangfatai@huawei.com