idnits 2.17.1 draft-ietf-pce-gmpls-pcep-extensions-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 6 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 13, 2014) is 3724 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-12) exists of draft-ietf-pce-inter-layer-ext-08 == Outdated reference: A later version (-15) exists of draft-ietf-pce-wson-routing-wavelength-10 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 4 Intended status: Standards Track O. Gonzalez de Dios, Ed. 5 Expires: August 17, 2014 Telefonica Investigacion y Desarrollo 6 F. Zhang, Ed. 7 Huawei Technologies 8 February 13, 2014 10 PCEP extensions for GMPLS 11 draft-ietf-pce-gmpls-pcep-extensions-09 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 August 17, 2014. 35 Copyright Notice 37 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . 6 64 2.3. Traffic parameters encoding, BANDWIDTH object extensions 7 65 2.4. Traffic parameters encoding, LOAD-BALANCING . . . . . . . 9 66 2.5. END-POINTS Object extensions . . . . . . . . . . . . . . 12 67 2.5.1. Generalized Endpoint Object Type . . . . . . . . . . 12 68 2.5.2. END-POINTS TLVs extensions . . . . . . . . . . . . . 15 69 2.6. IRO extension . . . . . . . . . . . . . . . . . . . . . . 19 70 2.7. XRO extension . . . . . . . . . . . . . . . . . . . . . . 19 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 . . 24 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 . . . . . . . . . . . . . . . . . . . . . . 27 86 5.4. RP Object Flag Field . . . . . . . . . . . . . . . . . . 28 87 5.5. New PCEP Error Codes . . . . . . . . . . . . . . . . . . 28 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 . . . . . . . . . . . . . . . . . . . 30 92 7. Contributing Authors . . . . . . . . . . . . . . . . . . . . 30 93 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 94 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 95 9.1. Normative References . . . . . . . . . . . . . . . . . . 32 96 9.2. Informative References . . . . . . . . . . . . . . . . . 34 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 99 1. Introduction 101 Although [RFC4655] defines the PCE architecture and framework for 102 both MPLS and GMPLS networks, current PCEP RFCs [RFC5440], [RFC5521], 103 [RFC5541], [RFC5520] are focused on MPLS networks, and do not cover 104 the wide range of GMPLS networks. This document complements these 105 RFCs by addressing the extensions required for GMPLS applications and 106 routing requests, for example for OTN and WSON networks. 108 The functional requirements to be considered by the PCEP extensions 109 to support those application are described in [RFC7025] and 110 [I-D.ietf-pce-wson-routing-wavelength]. 112 1.1. Contributing Authors 114 Elie Sfeir, Franz Rambach (Nokia Siemens Networks) Francisco Javier 115 Jimenez Chico (Telefonica Investigacion y Desarrollo) Suresh BR, 116 Young Lee, SenthilKumar S, Jun Sun (Huawei Technologies), Ramon 117 Casellas (CTTC) 119 1.2. PCEP requirements for GMPLS 121 The document [RFC7025] describes the set of PCEP requirements to 122 support GMPLS TE-LSPs. When a PCC requests a PCE to perform a path 123 computation (by means of a PCReq message), the PCC should be able to 124 indicate the following additional information: 126 o Which data flow is switched by the LSP: a combination of Switching 127 Type (for instance L2SC or TDM), Switching Encoding (e.g., 128 Ethernet, SONET/SDH) and sometimes the Signal Type (e.g. in case 129 of TDM/LSC switching capability) 131 o Data flow specific traffic parameters, which are technology 132 specific. For instance, in SDH/SONET and G.709 OTN networks the 133 Concatenation Type and the Concatenation Number have an influence 134 on the switched data and on which link it can be supported 136 o Support for asymmetric bandwidth requests. 138 o Support for unnumbered interface identifiers, as defined in 139 [RFC3477] 141 o Label information and technology specific label(s) such as 142 wavelength labels as defined in [RFC6205]. A PCC should also be 143 able to specify a Label restriction similar to the one supported 144 by RSVP. 146 o Ability to indicate the requested granularity for the path ERO: 147 node, link or label. This is to allow the use of the explicit 148 label control feature of RSVP-TE. 150 We describe in this document a set of PCEP protocol extensions, 151 including new objects, TLVs, encodings, error codes and procedures, 152 in order to fulfill the aforementioned requirements. 154 1.3. Current GMPLS support and limitation of existing PCEP objects 156 PCEP as of [RFC5440], [RFC5521] and [I-D.ietf-pce-inter-layer-ext], 157 supports the following objects, included in requests and responses 158 related to the described requirements. 160 From [RFC5440]: 162 o ENDPOINTS: only numbered endpoints are considered. The context 163 specifies whether they are node identifiers or numbered 164 interfaces. 166 o BANDWIDTH: the data rate is encoded in the bandwidth object (as 167 IEEE 32 bit float). [RFC5440] does not include the ability to 168 convey an encoding proper to any GMPLS networks. 170 o ERO : Unnumbered endpoints are supported. 172 o LSPA: LSP attributes (setup and holding priorities) 174 From [RFC5521] : 176 o XRO object : 178 * This object allows excluding (strict or not) resources, and 179 includes the requested diversity (node, link or SRLG). 181 * When the F bit is set, the request indicates that the existing 182 route has failed and the resources present in the RRO can be 183 reused. 185 From [I-D.ietf-pce-inter-layer-ext]: 187 o INTER-LAYER : indicates whether inter-layer computation is allowed 189 o SWITCH-LAYER : indicates which layer(s) should be considered, can 190 be used to represent the RSVP-TE generalized label request 192 o REQ-ADAP-CAP : indicates the adaptation capabilities requested, 193 can also be used for the endpoints in case of mono-layer 194 computation 196 The shortcomings of the existing PCEP object are: 198 The BANDWIDTH and LOAD-BALANCING objects do not describe the 199 details of the traffic request (for example NVC, multiplier) in 200 the context of GMPLS networks, for instance TDM or OTN networks. 202 The END-POINTS object does not allow specifying an unnumbered 203 interface, nor potential label restrictions on the interface. 204 Those parameters are of interest in case of switching constraints. 206 The IRO/XRO objects do not allow the inclusion/exclusion of labels 208 Current attributes do not allow expressing the requested link 209 protection level and/or the end-to-end protection attributes. 211 The covered PCEP extensions are: 213 A new object type are introduced for the BANDWIDTH object 214 (Generalized-Bandwidth, Generalized Bandwidth of existing TE-LSP) 216 A new object type is introduced for the LOAD-BALANCING object 217 (Generalized bandwidth), 219 A new object type is introduced for the END-POINTS object 220 (GENERALIZED-ENDPOINT), 222 A new TLV is added to the LSPA object. 224 A new TLV type for label is allowed in IRO and XRO objects. 226 In order to indicate the used routing granularity in the response, 227 a new flag in the RP object is added. 229 1.4. Requirements Language 231 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 232 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 233 document are to be interpreted as described in RFC 2119 [RFC2119]. 235 2. PCEP objects and extensions 237 This section describes the required PCEP objects and extensions. The 238 PCReq and PCRep messages are defined in [RFC5440]. This document 239 does not change the existing grammars 241 2.1. GMPLS capability advertisement 243 2.1.1. GMPLS Computation TLV in the Existing PCE Discovery Protocol 245 IGP-based PCE Discovery (PCED) is defined in [RFC5088] and [RFC5089] 246 for the OSPF and IS-IS protocols. Those documents define bit 0 of 247 the PCED TLV for Path computation with GMPLS link constraints. This 248 capability can be used to detect GMPLS-capable PCEs. 250 2.1.2. OPEN Object extension GMPLS-CAPABILITY TLV 252 In addition to the IGP advertisement, a PCEP speaker should be able 253 to discover the other peer GMPLS capabilities during the Open message 254 exchange. This capability is also useful to avoid misconfigurations. 255 This document defines a new optional GMPLS-CAPABILITY TLV for use in 256 the OPEN object to negotiate the GMPLS capability. The inclusion of 257 this TLV in the OPEN message indicates that the PCC/PCE support the 258 PCEP extensions defined in the document. A PCE that is able to 259 support the GMPLS extensions defined in this document SHOULD include 260 the GMPLS-CAPABILITY TLV on the OPEN message. If the PCE does not 261 include the GMPLS-CAPABILITY TLV in the OPEN message and PCC does 262 include the TLV, it is RECOMMENDED that the PCC indicates a mismatch 263 of capabilities. Moreover , in case that the PCC does not receive 264 the GMPLS-CAPABILITY TLV it is RECOMMENDED that the PCC does not make 265 use of the objects and TLVs defined in this document. 267 IANA has allocated value 14 from the "PCEP TLV Type Indicators" sub- 268 registry, as documented in Section Section 5.3 ("New PCEP TLVs"). 269 The description is "GMPLS capable". Its format is shown in the 270 following figure. 272 0 1 2 3 273 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 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | Type=14 | Length | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | Flags | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 No Flags are defined in this document, they are reserved for future 281 use. 283 2.2. RP object extension 285 Explicit label control (ELC) is a procedure supported by RSVP-TE, 286 where the outgoing label(s) is(are) encoded in the ERO. In 287 consequence, the PCE may be able to provide such label(s) directly in 288 the path ERO. The PCC, depending on policies or switching layer, may 289 be required to use explicit label control or expect explicit link, 290 thus it need to indicate in the PCReq which granularity it is 291 expecting in the ERO. This correspond to requirement 12 of [RFC7025] 292 The possible granularities can be node, link or label. The 293 granularities are inter-dependent, in the sense that link granularity 294 implies the presence of node information in the ERO; similarly, a 295 label granularity implies that the ERO contains node, link and label 296 information. 298 A new 2-bit routing granularity (RG) flag is defined in the RP 299 object. The values are defined as follows 301 0 : reserved 302 1 : node 303 2 : link 304 3 : label 306 The flag in the RP object indicates the requested route granularity. 307 The PCE MAY try to follow this granularity and MAY return a NO-PATH 308 if the requested granularity cannot be provided. The PCE MAY return 309 any granularity it likes on the route based on its policy. The PCC 310 can decide if the ERO is acceptable based on its content. 312 If a PCE honored the requested routing granularity for a request, it 313 MUST indicate the selected routing granularity in the RP object 314 included in the response. The PCE MAY use the reserved RG to leave 315 the check of the ERO to the PCC. The RG flag is backward-compatible 316 with [RFC5440]: the value sent by an implementation (PCC or PCE) not 317 supporting it will indicate a reserved value. 319 2.3. Traffic parameters encoding, BANDWIDTH object extensions 321 From [RFC5440] the object carrying the request size for the TE-LSP is 322 the BANDWIDTH object. The object types 1 and 2 defined in [RFC5440] 323 do not describe enough information to describe the TE-LSP bandwidth 324 in GMPLS networks. The BANDWIDTH object encoding should be extended 325 to allow to express the bandwidth as described in[RFC7025]. RSVP-TE 326 extensions for GMPLS provide a set of encoding allowing such 327 representation in an unambiguous way, this is encoded in the RSVP-TE 328 TSpec and FlowSpec objects. This document extends the BANDWIDTH 329 object with new object types reusing the RSVP-TE encoding. 331 The following possibilities should be supported by the new encoding : 333 o Asymmetric bandwidth (different bandwidth in forward and reverse 334 direction), as described in [RFC6387] 336 o GMPLS (SDH/SONET, G.709, ATM, MEF etc) parameters. 338 This correspond to requirement 3,4,5 and 11 of [RFC7025]. 340 This document defines two OT for the BANDWIDTH object: 342 3 Requested generalized bandwidth 344 4 Generalized bandwidth of an existing TE LSP for which a re- 345 optimization is requested 347 The definitions below apply for Object Type 3 and 4. The payload is 348 as follows: 350 0 1 2 3 351 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 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | Bandwidth Spec Length | Rev. Bandwidth Spec Length | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | Bw Spec Type | Reserved | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | | 358 ~ generalized bandwidth ~ 359 | | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | | 362 ~ Optional : reverse generalized bandwidth ~ 363 | | 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 | | 366 ~ Optional TLVs ~ 367 | | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 The BANDWIDTH object type 3 and 4 have a variable length. The 16 bit 371 bandwidth spec length field indicates the length of the bandwidth 372 spec field. The bandwidth spec length MUST be strictly greater than 373 0. The 16 bit reverse bandwidth spec length field indicates the 374 length of the reverse bandwidth spec field. The reverse bandwidth 375 spec length MAY be equal to 0. 377 The Bw Type field determines which type of bandwidth is represented 378 by the object. 380 The Bw Type types correspond to the RSVPT-TE SENDER_TSPEC (Object 381 Class 12) C-Types 383 The encoding of the field generalized bandwidth and reverse 384 generalized bandwidth is the same as in RSVP-TE, it can be found in 385 the following references. 387 Object Type Name Reference 389 2 Intserv [RFC2210] 390 4 SONET/SDH [RFC4606] 391 5 G.709 [RFC4328] 392 6 Ethernet [RFC6003] 394 Traffic Spec field encoding 396 , When a PCC requests a bi-directional path with symmetric bandwidth, 397 is MUST specify the generalized bandwidth field, MUST NOT specify the 398 reverse generalized bandwidth and MUST set the Reverse Bandwidth Spec 399 Length to 0. When a PCC needs to request a bi-directional path with 400 asymmetric bandwidth, it SHOULD specify the different bandwidth in 401 the forward and reverse directions with a generalized bandwidth and 402 reverse generalized bandwidth fields. 404 The procedures described in [RFC5440] for the PCRep is unchanged, a 405 PCE MAY include the BANDWIDTH objects in the response to indicate the 406 BANDWIDTH of the path 408 As specified i [RFC5440] in the case of the re-optimization of a TE 409 LSP, the bandwidth of the existing TE LSP MUST also be included in 410 addition to the requested bandwidth if and only if the two values 411 differ. The Object Type 4 MAY be used instead of object type 2 to 412 indicate the existing TE-LSP bandwidth. A PCC that requested a path 413 with a BANDWIDTH object of with object type 1 SHOULD use object type 414 2 to represent the existing TE-LSP BANDWIDTH. 416 Optional TLVs may be included within the object body to specify more 417 specific bandwidth requirements. No TLVs for the Object Type 3 and 4 418 are defined by this document. 420 2.4. Traffic parameters encoding, LOAD-BALANCING 422 The LOAD-BALANCING object [RFC5440] is used to request a set of 423 maximum Max-LSP TE-LSP having in total the bandwidth specified in 424 BANDWIDTH, each TE-LSP having a minimum of bandwidth. The LOAD- 425 BALANCING follows the bandwidth encoding of the BANDWIDTH object, and 426 thus the existing definition from [RFC5440] does not describe enough 427 details for the bandwidth specification expected by GMPLS. A PCC 428 should be allowed to request a set of TE-LSP also in case of GMPLS 429 bandwidth specification. 431 The LOAD-BALANCING has the same limitation as the BANDWIDTH for GMPLS 432 networks. Similarly to the BANDWIDTH object a new object type is 433 defined to allow a PCC to represent the bandwidth types supported by 434 GMPLS networks. 436 This document defines the generalized load balancing object type 2 437 for the LOAD-BALANCING object, 439 The generalized load balancing object type has a variable length. 441 The format of the generalized load balancing object type is as 442 follows: 444 0 1 2 3 445 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 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 | Bandwidth spec length | Reverse Bandwidth spec length | 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 | BW Spec Type | Max-LSP | Reserved | 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 | Min Bandwidth Spec | 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | Min reverse Bandwidth Spec (optional) | 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | | 456 ~ Optional TLVs ~ 457 | | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 Bandwidth spec length (16 bits): the total length of the min 461 bandwidth specification. It should be noted that the RSVP traffic 462 specification may also include TLV different than the PCEP TLVs. The 463 length MUST be strictly greater than 0. 465 Reverse bandwidth spec length (16 bits): the total length of the 466 reverse min bandwidth specification. It MAY be equal to 0. 468 BW Spec Type (8 bits) : the bandwidth specification type, it 469 correspond to the RSVPT-TE SENDER_TSPEC (Object Class 12) C-Types 471 Max-LSP (8 bits): maximum number of TE LSPs in the set. 473 Min Bandwidth spec (variable): Specifies the minimum bandwidth spec 474 of each element of the set of TE LSPs. 476 Min Reverse Bandwidth spec (variable): Specifies the minimum reverse 477 bandwidth spec of each element of the set of TE LSPs. 479 The encoding of the field Min Bandwidth Spec and Min Reverse 480 Bandwidth spec is the same as in RSVP-TE SENDER_TSPEC object, it can 481 be found in the following references. 483 Object Type Name Reference 485 2 Intserv [RFC2210] 486 4 SONET/SDH [RFC4606] 487 5 G.709 [RFC4328] 488 6 Ethernet [RFC6003] 490 Traffic Spec field encoding 492 . When a PCC requests a bi-directional path with symmetric bandwidth 493 while specifying load balancing constraints is MUST specify the min 494 Bandwidth spec field, MUST NOT specify the min reverse bandwidth and 495 MUST set the Reverse Bandwidth spec length to 0. When a PCC needs to 496 request a bi-directional path with asymmetric bandwidth while 497 specifying load balancing constraints, it SHOULD specify the 498 different bandwidth in forward and reverse directions through a min 499 Bandwidth spec and min reverse bandwidth fields. 501 Optional TLVs may be included within the object body to specify more 502 specific bandwidth requirements. No TLVs for the generalized load 503 balancing object type are defined by this document. 505 The semantic of the LOAD-BALANCING object is not changed. If a PCC 506 requests the computation of a set of TE LSPs so that the total of 507 their generalized bandwidth is X, the maximum number of TE LSPs is N, 508 and each TE LSP must at least have a bandwidth of B, it inserts a 509 BANDWIDTH object specifying X as the required bandwidth and a LOAD- 510 BALANCING object with the Max-LSP and Min-traffic spec fields set to 511 N and B, respectively. 513 For example a request for one co-signaled n x VC-4 TE-LSP will not 514 use the LOAD-BALANCING. In case the V4 components can use different 515 paths, the BANDWIDTH with object type 3 will contain a traffic 516 specification indicating the complete n x VC4 traffic specification 517 and the LOAD-BALANCING the minimum co-signaled VC4. For a SDH 518 network, a request to have a TE-LSP group with 10 VC4 container, each 519 path using at minimum 2VC4 container, can be represented with a 520 BANDWIDTH object with OT=3, Bandwidth spec type set to 4, the content 521 of the bandwidth specification is ST=6,RCC=0,NCC=0,NVC=10,MT=1. The 522 LOAD-BALANCING, OT=2 with Bandwidth spec set to 4,Max-LSP=5, min 523 Traffic spec is (ST=6,RCC=0,NCC=0,NVC=2,MT=1). The PCE can respond 524 with a response with maximum 5 path, each of them having a BANDWIDTH 525 OT=3 and traffic spec matching the minimum traffic spec from the 526 LOAD-BALANCING object of the corresponding request. 528 2.5. END-POINTS Object extensions 530 The END-POINTS object is used in a PCEP request message to specify 531 the source and the destination of the path for which a path 532 computation is requested. From [RFC5440] the source IP address and 533 the destination IP address are used to identify those. A new Object 534 Type is defined to address the following possibilities: 536 o Different source and destination endpoint types. 538 o Label restrictions on the endpoint. 540 o Specification of unnumbered endpoints type as seen in GMPLS 541 networks. 543 The Object encoding is described in the following sections. 545 In path computation within a GMPLS context the endpoints can: 547 o Be unnumbered as described in [RFC3477]. 549 o Have label(s) associated to them, specifying a set of constraints 550 in the allocation of labels. 552 o May have different switching capabilities 554 The IPv4 and IPv6 endpoints are used to represent the source and 555 destination IP addresses. The scope of the IP address (Node or 556 numbered Link) is not explicitly stated. It is also possible to 557 request a Path between a numbered link and an unnumbered link, or a 558 P2MP path between different type of endpoints. 560 This new C-Type also supports the specification of constraints on the 561 endpoint label to be use. The PCE might know the interface 562 restrictions but this is not a requirement. This corresponds to 563 requirements 6 and 10 of [RFC7025]. 565 2.5.1. Generalized Endpoint Object Type 567 The Generalized Endpoint object type format consists of a body and a 568 list of TLVs scoped to this object type object. The TLVs give the 569 details of the endpoints and are described in Section 2.5.2. For 570 each endpoint type, a different grammar is defined. The TLVs defined 571 to describe an endpoint are: 573 1. IPv4 address endpoint. 575 2. IPv6 address endpoint. 577 3. Unnumbered endpoint. 579 4. Label set restriction. 581 5. Suggested label set restriction. 583 The Label Set and Suggested label set TLVs are used to restrict the 584 label allocation in the PCE. Those TLVs express the set of 585 restrictions provided by signaling. Label restriction support can be 586 an explicit value (Label set describing one label), mandatory range 587 restrictions (Label set), optional range restriction (suggested label 588 set) and single suggested value is using the suggested label set. 589 Endpoints label restriction may not be part of the RRO or IRO, they 590 may be included when following [RFC4003] in signaling for egress 591 endpoint, but ingress endpoint properties may be local to the PCC and 592 not signaled. To support this case the label set allows to indicate 593 which label are used in case of re-optimization. The label range 594 restrictions are valid in GMPLS networks, either by PCC policy or 595 depending on the switching technology used, for instance on given 596 Ethernet or ODU equipment having limited hardware capabilities 597 restricting the label range. Label set restriction also applies to 598 WSON networks where the optical sender and receivers are limited in 599 their frequency tunability ranges, restricting then in GMPLS the 600 possible label ranges on the interface. The END-POINTS Object with 601 Generalized Endpoint object type is encoded as follow: 603 0 1 2 3 604 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 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 | Reserved | endpoint type | 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 | | 609 ~ TLVs ~ 610 | | 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 Reserved bits should be set to 0 when a message is sent and ignored 614 when the message is received 616 the endpoint type is defined as follow: 618 Value Type Meaning 620 0 Point-to-Point 621 1 Point-to-Multipoint New leaves to add 622 2 Old leaves to remove 623 3 Old leaves whose path can be 624 modified/reoptimized 625 4 Old leaves whose path must be 626 left unchanged 627 5-244 Reserved 628 245-255 Experimental range 630 The endpoint type is used to cover both point-to-point and different 631 point-to-multipoint endpoints. Endpoint type 0 MAY be accepted by 632 the PCE, other endpoint type MAY be supported if the PCE 633 implementation supports P2MP path calculation. A PCE not supporting 634 a given endpoint type MUST respond with a PCErr with error code "Path 635 computation failure", error type "Unsupported endpoint type in END- 636 POINTS Generalized Endpoint object type". The TLVs present in the 637 request object body MUST follow the following grammar: 639 ::= 640 | 642 ::= 643 644 646 ::= 647 648 [] 650 ::= 651 652 [] 654 ::= 655 [] 656 [ []]... 658 For endpoint type Point-to-Multipoint several endpoint objects may be 659 present in the message and represent a leave, exact meaning depend on 660 the endpoint type defined of the object. 662 An endpoint is defined as follows: 664 ::=|| 665 ::= 666 [] 668 ::= 669 671 ::= 672 [] 673 ::= | 674 676 The different TLVs are described in the following sections. A PCE 677 MAY support IPV4-ADDRESS,IPV6-ADDRESS or UNNUMBERED-ENDPOINT TLV. A 678 PCE not supporting one of those TLV in a PCReq MUST respond with a 679 PCRep with NO-PATH with the bit "Unknown destination" or "Unknown 680 source" in the NO-PATH-VECTOR TLV, the response SHOULD include the 681 ENDPOINT object in the response with only the TLV it did not 682 understood. 684 A PCE MAY support LABEL-REQUEST, LABEL-SET or SUGGESTED-LABEL-SET 685 TLV. If a PCE finds a non-supported TLV in the END-POINTS the PCE 686 MUST respond with a PCErr message with error type="Path computation 687 failure" error value="Unsupported TLV present in END-POINTS 688 Generalized Endpoint object type" and the message SHOULD include the 689 ENDPOINT object in the response with only the endpoint and endpoint 690 restriction TLV it did not understand. A PCE supporting those TLVs 691 but not being able to fulfill the label restriction MUST send a 692 response with a NO-PATH object which has the bit "No endpoint label 693 resource" or "No endpoint label resource in range" set in the NO- 694 PATH- VECTOR TLV. The response SHOULD include an ENDPOINT object 695 containing only the TLV where the PCE could not meet the constraint. 697 2.5.2. END-POINTS TLVs extensions 699 All endpoint TLVs have the standard PCEP TLV header as defined in 700 [RFC5440] section 7.1. In this object type the order of the TLVs 701 MUST be followed according to the object type definition. 703 2.5.2.1. IPV4-ADDRESS 705 This TLV represent a numbered endpoint using IPv4 numbering, the 706 format of the IPv4-ADDRESS TLV value (TLV-Type=TBA) is as follows: 708 0 1 2 3 709 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 710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 711 | IPv4 address | 712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 714 This TLV MAY be ignored, in which case a PCRep with NO-PATH should be 715 responded, as described in Section 2.5.1. 717 2.5.2.2. IPV6-ADDRESS TLV 719 This TLV represent a numbered endpoint using IPV6 numbering, the 720 format of the IPv6-ADDRESS TLV value (TLV-Type=TBA) is as follows: 722 0 1 2 3 723 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 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 725 | IPv6 address (16 bytes) | 726 | | 727 | | 728 | | 729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 731 This TLV MAY be ignored, in which case a PCRep with NO-PATH should be 732 responded, as described in Section 2.5.1. 734 2.5.2.3. UNNUMBERED-ENDPOINT TLV 736 This TLV represent an unnumbered interface. This TLV has the same 737 semantic as in [RFC3477] The TLV value is encoded as follow (TLV- 738 Type=TBA) 740 0 1 2 3 741 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 742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 743 | LSR's Router ID | 744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 745 | Interface ID (32 bits) | 746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 748 This TLV MAY be ignored, in which case a PCRep with NO-PATH should be 749 responded, as described in Section 2.5.1. 751 2.5.2.4. LABEL-REQUEST TLV 753 The LABEL-REQUEST TLV indicates the switching capability and encoding 754 type of the following label restriction list for the endpoint. Its 755 format is the same as described in [RFC3471] Section 3.1 Generalized 756 label request. The LABEL-REQUEST TLV use TLV-Type=TBA. The fields 757 are encoded as in the RSVP-TE. The Encoding Type indicates the 758 encoding type, e.g., SONET/SDH/GigE etc., that will be used with the 759 data associated. The Switching type indicates the type of switching 760 that is being requested on the endpoint. G-PID identifies the 761 payload. This TLV and the following one are introduced to satisfy 762 requirement 13 for the endpoint. It is not directly related to the 763 TE-LSP label request, which is expressed by the SWITCH-LAYER object. 765 On the path calculation request only the Tspec and switch layer need 766 to be coherent, the endpoint labels could be different (supporting a 767 different Tspec). Hence the label restrictions include a Generalized 768 label request in order to interpret the labels. This TLV MAY be 769 ignored, in which case a PCRep with NO-PATH should be responded, as 770 described in Section 2.5.1. 772 2.5.2.5. Labels TLV 774 Label or label range restrictions may be specified for the TE-LSP 775 endpoints. Those are encoded using the LABEL-SET TLV. The label 776 value need to be interpreted with a description on the Encoding and 777 switching type. The REQ-ADAP-CAP object from 778 [I-D.ietf-pce-inter-layer-ext] can be used in case of mono-layer 779 request, however in case of multi-layer it is possible to have in the 780 future more than one object, so it is better to have a dedicated TLV 781 for the label and label request (the scope is then more clear). 782 Those TLV MAY be ignored, in which case a response with NO-PATH 783 should be responded, as described in Section 2.5.1. TLVs are encoded 784 as follow (following [RFC5440]) : 786 o LABEL-SET TLV, Type=TBA. The TLV Length is variable, Encoding 787 follows [RFC3471] Section 3.5 "Label set" with the addition of a U 788 bit and O Bit. The U bit is set for upstream direction in case of 789 bidirectional LSP and the O bit is used to represent an old label. 791 0 1 2 3 792 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 793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 794 | Action | Reserved |O|U| Label Type | 795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 796 | Subchannel 1 | 797 | ... | 798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 799 : : : 800 : : : 801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 802 | Subchannel N | 803 | ... | 804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 806 o SUGGESTED-LABEL-SET TLV Set, Type=TBA. The TLV length is variable 807 and its encoding is as LABEL-SET TLV. The 0 bit SHOULD be set to 808 0. 810 A LABEL-SET TLV represents a set of possible labels that can be used 811 on an interface. The label allocated on the first link SHOULD be 812 within the label set range. The action parameter in the Label set 813 indicates the type of list provided. Those parameters are described 814 by [RFC3471] section 3.5.1 A SUGGESTED-LABEL-SET TLV has the same 815 encoding as the LABEL-SET TLV, it indicates to the PCE a set of 816 preferred (ordered) set of labels to be used. The PCE MAY use those 817 labels for label allocation. 819 The U and 0 bits have the following meaning: 821 U: Upstream direction: set when the label or label set is in the 822 reverse direction 823 O: Old Label: set when the TLV represent the old label in case of re- 824 optimization. This Bit SHOULD be set to 0 in a SUGGESTED-LABEL-SET 825 TLV Set and ignored on receipt. This Label MAY be reused. The R 826 bit of the RP object MUST be set. When this bit is set the Action 827 field MUST be set to 0 (Inclusive List) and the Label Set MUST 828 contain one subchannel. 830 Several LABEL_SET TLVs MAY be present with the 0 bit cleared. At 831 most 2 LABEL_SET TLV SHOULD be present with the 0 bit set, at most 832 one with the U bit set and at most one with the U bit cleared. For a 833 given U bit value if more than one LABEL_SET TLV with the O bit set 834 is present, the first TLV SHOULD be processed and the following TLV 835 with the same U and O bit SHOULD be ignored. 837 A SUGGESTED-LABEL-SET TLV with the O bit set MUST trigger a PCErr 838 message with error type="Reception of an invalid object" error 839 value="Wrong LABEL-SET or SUGGESTED-LABEL-SET TLV present with 0 bit 840 set". 842 A LABEL-SET TLV with the O bit set and an Action Field not set to 0 843 (Inclusive list) or containing more than one subchannel MUST trigger 844 a PCErr message with error type="Reception of an invalid object" 845 error value="Wrong LABEL-SET or SUGGESTED-LABEL-SET TLV present with 846 0 bit set". 848 If a LABEL-SET TLV is present with O bit set, the R bit of the RP 849 object MUST be set or a PCErr message with error type="Reception of 850 an invalid object" error value="LABEL-SET TLV present with 0 bit set 851 but without R bit set in RP". 853 2.6. IRO extension 855 The IRO as defined in [RFC5440] is used to include specific objects 856 in the path. RSVP allows to include label definition, in order to 857 fulfill requirement 13 the IRO should support the new subobject type 858 as defined in [RFC3473]: 860 Type Sub-object 861 3 LABEL 863 The L bit of such sub-object has no meaning within an IRO. 865 The Label subobject MUST follow a subobject identifying a link, 866 currently an IP address subobject (Type 1 or 2) or an interface id 867 (type 4) subobject. IP address subobject MUST be a link subobject. 868 More than one label suboject MAY follow each link subobject. The 869 procedure associated with this subobject is as follow 871 If the PCE allocates labels (e.g via explicit label control) the PCE 872 MUST allocate one label of from within the set of label values for 873 the given link. If the PCE does not assign labels a response with a 874 NO-PATH and a NO-PATH-VECTOR-TLV with the bit .'No label resource in 875 range' set. 877 2.7. XRO extension 879 The XRO as defined in [RFC5521] is used to exclude specific objects 880 in the path. RSVP allows to exclude labels ([RFC6001], in order to 881 fulfill requirement 13 of [RFC7025] section 4.1, the XRO should 882 support a new subobject to support label exclusion. 884 The encoding of the XRO Label subobject follows the encoding of the 885 Label ERO subobject defined in [RFC3473] and XRO subobject defined in 886 [RFC5521]. The XRO Label subobject represent one Label and is 887 defined as follows: 889 XRO Subobject Type 3: Label Subobject. 891 0 1 2 3 892 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 893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 894 |X| Type=3 | Length |U| Reserved | C-Type | 895 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 896 | Label | 897 | ... | 898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 900 X (1 bit) 902 As per [RFC5521]. The X-bit indicates whether the exclusion is 903 mandatory or desired. 0 indicates that the resource specified 904 MUST be excluded from the path computed by the PCE. 1 905 indicates that the resource specified SHOULD be excluded from 906 the path computed by the PCE, but MAY be included subject to 907 PCE policy and the absence of a viable path that meets the 908 other constraints and excludes the resource. 910 Type (7 bits) 912 The Type of the XRO Label subobject is 3. 914 Length (8 bits) 916 See [RFC5521],The total length of the subobject in bytes 917 (including the Type and Length fields). The Length is always 918 divisible by 4. 920 U (1 bit) 922 See [RFC3471]. 924 C-Type (8 bits) 926 The C-Type of the included Label Object as defined in 927 [RFC3471]. 929 Label 931 See [RFC3471]. 933 XRO Label subobjects MUST follow the numbered or unnumbered interface 934 subobjects to which they refer. Each subobject represent one label, 935 several XRO Labels subobject MAY be present for each link. 937 Type Sub-object 938 3 LABEL 940 The L bit of such sub-object has no meaning within an XRO. 942 2.8. LSPA extensions 944 The LSPA carries the LSP attributes. In the end-to-end protection 945 context this also includes the protection state information. This 946 object is introduced to fulfill requirement 7 of [RFC7025] section 947 4.1 and requirement 3 of [RFC7025] section 4.2. This object contains 948 the the value of the PROTECTION object defined by [RFC4872] and may 949 be used as a policy input. The LSPA object MAY carry a PROTECTION- 950 ATTRIBUTE TLV defined as : Type TBA: PROTECTION-ATTRIBUTE 952 0 1 2 3 953 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 954 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 955 | Type | Length | 956 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 957 |S|P|N|O| Reserved | LSP Flags | Reserved | Link Flags| 958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 959 |I|R| Reserved | Seg.Flags | Reserved | 960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 962 The content is as defined in [RFC4872], [RFC4873]. 964 LSP (protection) Flags or Link flags field can be used by 965 implementation for routing policy input. The other attributes are 966 only meaningful for a stateful PCE. 968 This TLV is optional and MAY be ignored by the PCE, in which case it 969 MUST NOT include the TLV in the LSPA, if present, of the response. 970 When the TLV is used by the PCE, a LSPA object and the PROTECTION- 971 ATTRIBUTE TLV MUST be included in the response. Fields that were not 972 considered MUST be set to 0. 974 2.9. NO-PATH Object Extension 976 The NO-PATH object is used in PCRep messages in response to an 977 unsuccessful path computation request (the PCE could not find a path 978 satisfying the set of constraints). In this scenario, PCE MUST 979 include a NO-PATH object in the PCRep message. The NO-PATH object 980 may carries the NO-PATH-VECTOR TLV that specifies more information on 981 the reasons that led to a negative reply. In case of GMPLS networks 982 there could be some more additional constraints that led to the 983 failure like protection mismatch, lack of resources, and so on. Few 984 new flags have been introduced in the 32-bit flag field of the NO- 985 PATH-VECTOR TLV and no modifications have been made in the NO-PATH 986 object. 988 2.9.1. Extensions to NO-PATH-VECTOR TLV 990 The modified NO-PATH-VECTOR TLV carrying the additional information 991 is as follows: 993 Bit number TBA - Protection Mismatch (1-bit). Specifies the 994 mismatch of the protection type in the PROTECTION-ATTRIBUTE TLV in 995 the request. 997 Bit number TBA - No Resource (1-bit). Specifies that the 998 resources are not currently sufficient to provide the path. 1000 Bit number TBA - Granularity not supported (1-bit). Specifies 1001 that the PCE is not able to provide a route with the requested 1002 granularity. 1004 Bit number TBA - No endpoint label resource (1-bit). Specifies 1005 that the PCE is not able to provide a route because of the 1006 endpoint label restriction. 1008 Bit number TBA - No endpoint label resource in range (1-bit). 1009 Specifies that the PCE is not able to provide a route because of 1010 the endpoint label set restriction. 1012 Bit number TBA - No label resource in range (1-bit). Specifies 1013 that the PCE is not able to provide a route because of the label 1014 set restriction. 1016 3. Additional Error Type and Error Values Defined 1018 A PCEP-ERROR object is used to report a PCEP error and is 1019 characterized by an Error-Type that specifies the type of error while 1020 Error-value that provides additional information about the error. An 1021 additional error type and few error values are defined to represent 1022 some of the errors related to the newly identified objects related to 1023 GMPLS networks. For each PCEP error, an Error-Type and an Error- 1024 value are defined. Error-Type 1 to 10 are already defined in 1025 [RFC5440]. Additional Error- values are defined for Error-Type 10 1026 and A new Error-Type is introduced (value TBA). 1028 Error-Type Error-value 1030 10 Reception of an 1031 invalid object 1032 value=TBA: Bad Bandwidth Object type 3 or 4 value. 1033 value=TBA: Bad Bandwidth Object type 3 or 4 not 1034 supported. 1035 value=TBA: Unsupported LSP Protection Type in 1036 PROTECTION-ATTRIBUTE TLV. 1037 value=TBA: Unsupported LSP Protection Flags in 1038 PROTECTION-ATTRIBUTE TLV. 1039 value=TBA: Unsupported Secondary LSP Protection 1040 Flags in PROTECTION-ATTRIBUTE TLV. 1041 value=TBA: Unsupported Link Protection Type in 1042 PROTECTION-ATTRIBUTE TLV. 1043 value=TBA: Unsupported Link Protection Type in 1044 PROTECTION-ATTRIBUTE TLV. 1045 value=TBA: LABEL-SET TLV present with 0 bit set but 1046 without R bit set in RP. 1047 value=TBA: Wrong LABEL-SET or 1048 SUGGESTED-LABEL-SET TLV present with 1049 0 bit set. 1050 TBA Path computation 1051 failure 1052 value=TBA: Unacceptable request message. 1053 value=TBA: Generalized bandwidth value not 1054 supported. 1055 value=TBA: Label Set constraint could not be 1056 met. 1057 value=TBA: Label constraint could not be 1058 met. 1059 value=TBA: Unsupported endpoint type in 1060 END-POINTS Generalized Endpoint 1061 object type. 1062 value=TBA: Unsupported TLV present in END-POINTS 1063 Generalized Endpoint object type. 1064 value=TBA: Unsupported granularity in the RP object 1065 flags. 1067 4. Manageability Considerations 1069 This section follows the guidance of [RFC6123]. 1071 4.1. Control of Function through Configuration and Policy 1073 This document makes no change to the basic operation of PCEP and so 1074 the requirements described in [RFC5440] Section 8.1. also apply to 1075 this document. In addition to those requirements a PCEP 1076 implementation MAY allow the configuration of the following 1077 parameters: 1079 Accepted RG in the RP object. 1081 Default RG to use (overriding the one present in the PCReq) 1083 Accepted BANDWIDTH object type 3 and 4 parameters in request, 1084 default mapping to use when not specified in the request 1086 Accepted LOAD-BALANCING object type 3 and 4 parameters in request. 1088 Accepted endpoint type in END-POINTS object type Generalized 1089 Endpoint and allowed TLVs 1091 Accepted range for label restrictions in label restriction in END- 1092 POINTS, or IRO or XRO objects 1094 PROTECTION-ATTRIBUTE TLV acceptance and suppression. 1096 Those parameters configuration are applicable to the different 1097 sessions as described in [RFC5440] Section 8.1 (by default, per PCEP 1098 peer, ..etc). 1100 4.2. Information and Data Models 1102 This document makes no change to the basic operation of PCEP and so 1103 the requirements described in [RFC5440] Section 8.2. also apply to 1104 this document. This document does not introduces new ERO sub object, 1105 ERO information model is already covered in [RFC4802]. 1107 4.3. Liveness Detection and Monitoring 1109 This document makes no change to the basic operation of PCEP and so 1110 there are no changes to the requirements for liveness detection and 1111 monitoring set out in [RFC4657] and [RFC5440] Section 8.3. 1113 4.4. Verifying Correct Operation 1115 This document makes no change to the basic operations of PCEP and 1116 considerations described in [RFC5440] Section 8.4. New errors 1117 introduced by this document should be covered by the requirement to 1118 log error events. 1120 4.5. Requirements on Other Protocols and Functional Components 1122 No new Requirements on Other Protocols and Functional Components are 1123 made by this document. This document does not require ERO object 1124 extensions. Any new ERO subobject defined in CCAMP working group can 1125 be adopted without modifying the operations defined in this document. 1127 4.6. Impact on Network Operation 1129 This document makes no change to the basic operations of PCEP and 1130 considerations described in [RFC5440] Section 8.6. In addition to 1131 the limit on the rate of messages sent by a PCEP speaker, a limit MAY 1132 be placed on the size of the PCEP messages. 1134 5. IANA Considerations 1136 IANA assigns values to the PCEP protocol objects and TLVs. IANA is 1137 requested to make some allocations for the newly defined objects and 1138 TLVs introduced in this document. Also, IANA is requested to manage 1139 the space of flags that are newly added in the TLVs. 1141 5.1. PCEP Objects 1143 As described in Section 2.3, Section 2.4 and Section 2.5.1 new 1144 Objects types are defined IANA is requested to make the following 1145 Object-Type allocations from the "PCEP Objects" sub-registry. 1147 Object 5 1148 Class 1149 Name BANDWIDTH 1150 Object-Type 3: Generalized bandwidth 1151 4: Generalized bandwidth of an existing TE LSP for which 1152 a reoptimization is requested 1153 6-15: Unassigned 1154 Reference This document (section Section 2.3) 1156 Object Class 14 1157 Name LOAD-BALANCING 1158 Object-Type 2: Generalized load balancing 1159 3-15: Unassigned 1160 Reference This document (section Section 2.4) 1162 Object Class 4 1163 Name END-POINTS 1164 Object-Type 5: Generalized Endpoint 1165 6-15: unassigned 1166 Reference This document (section Section 2.3) 1168 5.2. END-POINTS object, Object Type Generalized Endpoint 1170 IANA is requested to create a registry to manage the endpoint type 1171 field of the END-POINTS object, Object Type Generalized Endpoint and 1172 manage the code space. 1174 New endpoint type in the Reserved range may be allocated by an IETF 1175 consensus action. Each endpoint type should be tracked with the 1176 following qualities: 1178 o endpoint type 1180 o Description 1182 o Defining RFC 1184 New endpoint type in the Experimental range are for experimental use; 1185 these will not be registered with IANA and MUST NOT be mentioned by 1186 RFCs. 1188 The following values have been defined by this document. 1189 (Section 2.5.1, Table 4): 1191 Value Type Meaning 1193 0 Point-to-Point 1194 1 Point-to-Multipoint New leaves to add 1195 2 Old leaves to remove 1196 3 Old leaves whose path can be 1197 modified/reoptimized 1198 4 Old leaves whose path must be 1199 left unchanged 1200 5-244 Reserved 1201 245-255 Experimental range 1203 5.3. New PCEP TLVs 1205 IANA manages the PCEP TLV code point registry (see [RFC5440]). This 1206 is maintained as the "PCEP TLV Type Indicators" sub-registry of the 1207 "Path Computation Element Protocol (PCEP) Numbers" registry. This 1208 document defines new PCEP TLVs, to be carried in the END-POINTS 1209 object with Generalized Endpoint object Type. IANA is requested to 1210 do the following allocation. The values here are suggested for use 1211 by IANA. 1213 Value Meaning Reference 1215 7 IPv4 endpoint This document (section Section 1216 2.5.2.1) 1217 8 IPv6 endpoint This document (section Section 1218 2.5.2.2) 1219 9 Unnumbered endpoint This document (section Section 1220 2.5.2.3) 1221 10 Label request This document (section Section 1222 2.5.2.4) 1223 11 Requested GMPLS Label Set This document (section Section 1224 2.5.2.5) 1225 12 Suggested GMPLS Label Set This document (section Section 1226 2.5.2.5) 1227 13 LSP Protection This document (section Section 2.8) 1228 Information 1229 14 GMPLS-CAPABILITY This document (section Section 2.1.2) 1231 5.4. RP Object Flag Field 1233 As described in Section 2.2 new flag are defined in the RP Object 1234 Flag IANA is requested to make the following Object-Type allocations 1235 from the "RP Object Flag Field" sub-registry. The values here are 1236 suggested for use by IANA. 1238 Bit Description Reference 1240 bit 17-16 routing granularity (RG) This document, Section 2.2 1242 5.5. New PCEP Error Codes 1244 As described in Section Section 3, new PCEP Error-Type and Error 1245 Values are defined. IANA is requested to make the following 1246 allocation in the "PCEP-ERROR Object Error Types and Values" 1247 registry. The values here are suggested for use by IANA. 1249 Error name Reference 1251 Type=10 Reception of an invalid object [RFC5440] 1252 Value=2: Bad Bandwidth Object type 3 or 4. This Document 1253 Value=3: Bandwidth Object type 3 or 4 not supported. This Document 1254 Value=4: Unsupported LSP Protection Type in This Document 1255 PROTECTION-ATTRIBUTE TLV. 1256 Value=5: Unsupported LSP Protection Flags in This Document 1257 PROTECTION-ATTRIBUTE TLV. 1258 Value=6: Unsupported Secondary LSP Protection Flags in This Document 1259 PROTECTION-ATTRIBUTE TLV. 1260 Value=7: Unsupported Link Protection Type in This Document 1261 PROTECTION-ATTRIBUTE TLV. 1262 Value=8: Unsupported Link Protection Type in This Document 1263 PROTECTION-ATTRIBUTE TLV. 1264 Value=9: LABEL-SET TLV present with 0 bit set but This Document 1265 without R bit set in RP. 1266 Value=q0: Wrong LABEL-SET or SUGGESTED-LABEL-SET TLV This Document 1267 present with 0 bit set. 1268 Type=14 Path computation failure This Document 1269 Value=1: Unacceptable request message. This Document 1270 Value=2: Generalized bandwidth value not supported. This Document 1271 Value=3: Label Set constraint could not be met. This Document 1272 Value=4: Label constraint could not be met. This Document 1273 Value=5: Unsupported endpoint type in END-POINTS This Document 1274 Generalized Endpoint object type 1275 Value=6: Unsupported TLV present in END-POINTS This Document 1276 Generalized Endpoint object type 1277 Value=7: Unsupported granularity in the RP object This Document 1278 flags 1280 5.6. New NO-PATH-VECTOR TLV Fields 1282 As described in Section Section 2.9.1, new NO-PATH-VECTOR TLV Flag 1283 Fields have been defined. IANA is requested to do the following 1284 allocations in the "NO-PATH-VECTOR TLV Flag Field" sub-registry. The 1285 values here are suggested for use by IANA. 1287 Bit number 23 - Protection Mismatch (1-bit). Specifies the 1288 mismatch of the protection type of the PROTECTION-ATTRIBUTE TLV in 1289 the request. 1291 Bit number 22 - No Resource (1-bit). Specifies that the resources 1292 are not currently sufficient to provide the path. 1294 Bit number 21 - Granularity not supported (1-bit). Specifies that 1295 the PCE is not able to provide a route with the requested 1296 granularity. 1298 Bit number 20 - No endpoint label resource (1-bit). Specifies 1299 that the PCE is not able to provide a route because of the 1300 endpoint label restriction. 1302 Bit number 19 - No endpoint label resource in range (1-bit). 1303 Specifies that the PCE is not able to provide a route because of 1304 the endpoint label set restriction. 1306 Bit number 18 - No label resource in range (1-bit). Specifies 1307 that the PCE is not able to provide a route because of the label 1308 set restriction. 1310 5.7. New Subobject for the Include Route Object 1312 The "PCEP Parameters" registry contains a subregistry "PCEP Objects" 1313 with an entry for the Include Route Object (IRO). 1315 IANA is requested to add a further subobject that can be carried in 1316 the IRO as follows: 1318 Subobject type Reference 1320 3 Label suboject [RFC3473] 1322 5.8. New Subobject for the Exclude Route Object 1324 The "PCEP Parameters" registry contains a subregistry "PCEP Objects" 1325 with an entry for the XRO object (Exclude Route Object). 1327 IANA is requested to add a further subobject that can be carried in 1328 the XRO as follows: 1330 Subobject type Reference 1332 3 Label suboject [RFC3473] 1334 6. Security Considerations 1336 None. 1338 7. Contributing Authors 1340 Nokia Siemens Networks: 1342 Elie Sfeir 1343 St Martin Strasse 76 1344 Munich, 81541 1345 Germany 1346 Phone: +49 89 5159 16159 1347 Email: elie.sfeir@nsn.com 1349 Franz Rambach 1350 St Martin Strasse 76 1351 Munich, 81541 1352 Germany 1354 Phone: +49 89 5159 31188 1355 Email: franz.rambach@nsn.com 1357 Francisco Javier Jimenez Chico 1358 Telefonica Investigacion y Desarrollo 1359 C/ Emilio Vargas 6 1360 Madrid, 28043 1361 Spain 1363 Phone: +34 91 3379037 1364 Email: fjjc@tid.es 1366 Huawei Technologies 1368 Suresh BR 1369 Shenzhen 1370 China 1371 Email: sureshbr@huawei.com 1373 Young Lee 1374 1700 Alma Drive, Suite 100 1375 Plano, TX 75075 1376 USA 1378 Phone: (972) 509-5599 (x2240) 1379 Email: ylee@huawei.com 1381 SenthilKumar S 1382 Shenzhen 1383 China 1384 Email: senthilkumars@huawei.com 1386 Jun Sun 1387 Shenzhen 1388 China 1389 Email: johnsun@huawei.com 1391 CTTC - Centre Tecnologic de Telecomunicacions de Catalunya 1393 Ramon Casellas 1394 PMT Ed B4 Av. Carl Friedrich Gauss 7 1395 08860 Castelldefels (Barcelona) 1396 Spain 1397 Phone: (34) 936452916 1398 Email: ramon.casellas@cttc.es 1400 8. Acknowledgments 1402 The research of Ramon Casellas, Francisco Javier Jimenez Chico, Oscar 1403 Gonzalez de Dios, Cyril Margaria, and Franz Rambach leading to these 1404 results has received funding from the European Community's Seventh 1405 Framework Program FP7/2007-2013 under grant agreement no 247674. 1407 The authors would like to thank Lyndon Ong, Giada Lander and Jonathan 1408 Hardwick for their useful comments to the document. 1410 9. References 1412 9.1. Normative References 1414 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1415 Requirement Levels", BCP 14, RFC 2119, March 1997. 1417 [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated 1418 Services", RFC 2210, September 1997. 1420 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 1421 (GMPLS) Signaling Functional Description", RFC 3471, 1422 January 2003. 1424 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 1425 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 1426 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 1428 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 1429 in Resource ReSerVation Protocol - Traffic Engineering 1430 (RSVP-TE)", RFC 3477, January 2003. 1432 [RFC4003] Berger, L., "GMPLS Signaling Procedure for Egress 1433 Control", RFC 4003, February 2005. 1435 [RFC4328] Papadimitriou, D., "Generalized Multi-Protocol Label 1436 Switching (GMPLS) Signaling Extensions for G.709 Optical 1437 Transport Networks Control", RFC 4328, January 2006. 1439 [RFC4606] Mannie, E. and D. Papadimitriou, "Generalized Multi- 1440 Protocol Label Switching (GMPLS) Extensions for 1441 Synchronous Optical Network (SONET) and Synchronous 1442 Digital Hierarchy (SDH) Control", RFC 4606, August 2006. 1444 [RFC4802] Nadeau, T. and A. Farrel, "Generalized Multiprotocol Label 1445 Switching (GMPLS) Traffic Engineering Management 1446 Information Base", RFC 4802, February 2007. 1448 [RFC4872] Lang, J., Rekhter, Y., and D. Papadimitriou, "RSVP-TE 1449 Extensions in Support of End-to-End Generalized Multi- 1450 Protocol Label Switching (GMPLS) Recovery", RFC 4872, May 1451 2007. 1453 [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, 1454 "GMPLS Segment Recovery", RFC 4873, May 2007. 1456 [RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 1457 "OSPF Protocol Extensions for Path Computation Element 1458 (PCE) Discovery", RFC 5088, January 2008. 1460 [RFC5089] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 1461 "IS-IS Protocol Extensions for Path Computation Element 1462 (PCE) Discovery", RFC 5089, January 2008. 1464 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 1465 (PCE) Communication Protocol (PCEP)", RFC 5440, March 1466 2009. 1468 [RFC5520] Bradford, R., Vasseur, JP., and A. Farrel, "Preserving 1469 Topology Confidentiality in Inter-Domain Path Computation 1470 Using a Path-Key-Based Mechanism", RFC 5520, April 2009. 1472 [RFC5521] Oki, E., Takeda, T., and A. Farrel, "Extensions to the 1473 Path Computation Element Communication Protocol (PCEP) for 1474 Route Exclusions", RFC 5521, April 2009. 1476 [RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of 1477 Objective Functions in the Path Computation Element 1478 Communication Protocol (PCEP)", RFC 5541, June 2009. 1480 [RFC6001] Papadimitriou, D., Vigoureux, M., Shiomoto, K., Brungard, 1481 D., and JL. Le Roux, "Generalized MPLS (GMPLS) Protocol 1482 Extensions for Multi-Layer and Multi-Region Networks (MLN/ 1483 MRN)", RFC 6001, October 2010. 1485 [RFC6003] Papadimitriou, D., "Ethernet Traffic Parameters", RFC 1486 6003, October 2010. 1488 [RFC6205] Otani, T. and D. Li, "Generalized Labels for Lambda- 1489 Switch-Capable (LSC) Label Switching Routers", RFC 6205, 1490 March 2011. 1492 [RFC6387] Takacs, A., Berger, L., Caviglia, D., Fedyk, D., and J. 1493 Meuric, "GMPLS Asymmetric Bandwidth Bidirectional Label 1494 Switched Paths (LSPs)", RFC 6387, September 2011. 1496 9.2. Informative References 1498 [I-D.ietf-pce-inter-layer-ext] 1499 Oki, E., Takeda, T., Farrel, A., and F. Zhang, "Extensions 1500 to the Path Computation Element communication Protocol 1501 (PCEP) for Inter-Layer MPLS and GMPLS Traffic 1502 Engineering", draft-ietf-pce-inter-layer-ext-08 (work in 1503 progress), January 2014. 1505 [I-D.ietf-pce-wson-routing-wavelength] 1506 Lee, Y., Bernstein, G., Martensson, J., Takeda, T., 1507 Tsuritani, T., and O. Dios, "PCEP Requirements for WSON 1508 Routing and Wavelength Assignment", draft-ietf-pce-wson- 1509 routing-wavelength-10 (work in progress), December 2013. 1511 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 1512 Element (PCE)-Based Architecture", RFC 4655, August 2006. 1514 [RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE) 1515 Communication Protocol Generic Requirements", RFC 4657, 1516 September 2006. 1518 [RFC6123] Farrel, A., "Inclusion of Manageability Sections in Path 1519 Computation Element (PCE) Working Group Drafts", RFC 6123, 1520 February 2011. 1522 [RFC7025] Otani, T., Ogaki, K., Caviglia, D., Zhang, F., and C. 1523 Margaria, "Requirements for GMPLS Applications of PCE", 1524 RFC 7025, September 2013. 1526 Authors' Addresses 1528 Cyril Margaria (editor) 1529 SabenerStr. 44 1530 Munich 81547 1531 Germany 1533 Email: cyril.margaria@gmail.com 1535 Oscar Gonzalez de Dios (editor) 1536 Telefonica Investigacion y Desarrollo 1537 C/ Emilio Vargas 6 1538 Madrid 28043 1539 Spain 1541 Phone: +34 91 3374013 1542 Email: ogondio@tid.es 1544 Fatai Zhang (editor) 1545 Huawei Technologies 1546 F3-5-B R&D Center, Huawei Base 1547 Bantian, Longgang District 1548 Shenzhen 518129 1549 P.R.China 1551 Email: zhangfatai@huawei.com