idnits 2.17.1 draft-ietf-pce-gmpls-pcep-extensions-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1206 has weird spacing: '...ted bit routi...' -- The document date (September 27, 2018) is 2037 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 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: March 31, 2019 Telefonica Investigacion y Desarrollo 6 F. Zhang, Ed. 7 Huawei Technologies 8 September 27, 2018 10 PCEP extensions for GMPLS 11 draft-ietf-pce-gmpls-pcep-extensions-12 13 Abstract 15 This memo provides extensions to 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 https://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 March 31, 2019. 35 Copyright Notice 37 Copyright (c) 2018 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 (https://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 Base PCEP Objects 4 56 1.4. Requirements Language . . . . . . . . . . . . . . . . . . 5 57 2. PCEP Objects and Extensions . . . . . . . . . . . . . . . . . 6 58 2.1. GMPLS Capability Advertisement . . . . . . . . . . . . . 6 59 2.1.1. GMPLS Computation TLV in the Existing PCE Discovery 60 Protocol . . . . . . . . . . . . . . . . . . . . . . 6 61 2.1.2. OPEN Object Extension GMPLS-CAPABILITY TLV . . . . . 6 62 2.2. RP Object Extension . . . . . . . . . . . . . . . . . . . 7 63 2.3. BANDWIDTH Object Extensions . . . . . . . . . . . . . . . 7 64 2.4. LOAD-BALANCING Object Extensions . . . . . . . . . . . . 10 65 2.5. END-POINTS Object Extensions . . . . . . . . . . . . . . 11 66 2.5.1. Generalized Endpoint Object Type . . . . . . . . . . 12 67 2.5.2. END-POINTS TLV Extensions . . . . . . . . . . . . . . 15 68 2.6. IRO Extension . . . . . . . . . . . . . . . . . . . . . . 18 69 2.7. XRO Extension . . . . . . . . . . . . . . . . . . . . . . 18 70 2.8. LSPA Extensions . . . . . . . . . . . . . . . . . . . . . 20 71 2.9. NO-PATH Object Extension . . . . . . . . . . . . . . . . 20 72 2.9.1. Extensions to NO-PATH-VECTOR TLV . . . . . . . . . . 21 73 3. Additional Error-Types and Error-Values Defined . . . . . . . 21 74 4. Manageability Considerations . . . . . . . . . . . . . . . . 23 75 4.1. Control of Function through Configuration and Policy . . 23 76 4.2. Information and Data Models . . . . . . . . . . . . . . . 23 77 4.3. Liveness Detection and Monitoring . . . . . . . . . . . . 23 78 4.4. Verifying Correct Operation . . . . . . . . . . . . . . . 24 79 4.5. Requirements on Other Protocols and Functional Components 24 80 4.6. Impact on Network Operation . . . . . . . . . . . . . . . 24 81 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 82 5.1. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . 24 83 5.2. END-POINTS Object, Object Type Generalized Endpoint . . . 25 84 5.3. New PCEP TLVs . . . . . . . . . . . . . . . . . . . . . . 26 85 5.4. RP Object Flag Field . . . . . . . . . . . . . . . . . . 26 86 5.5. New PCEP Error Codes . . . . . . . . . . . . . . . . . . 27 87 5.6. New NO-PATH-VECTOR TLV Fields . . . . . . . . . . . . . . 28 88 5.7. New Subobject for the Include Route Object . . . . . . . 28 89 5.8. New Subobject for the Exclude Route Object . . . . . . . 28 90 6. Security Considerations . . . . . . . . . . . . . . . . . . . 29 91 7. Contributing Authors . . . . . . . . . . . . . . . . . . . . 30 92 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31 93 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 94 9.1. Normative References . . . . . . . . . . . . . . . . . . 32 95 9.2. Informative References . . . . . . . . . . . . . . . . . 35 96 Appendix A. LOAD-BALANCING Usage for SDH Virtual Concatenation . 35 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 99 1. Introduction 101 Although [RFC4655] defines the PCE architecture and framework for 102 both MPLS and GMPLS networks, most preexisting PCEP RFCs [RFC5440], 103 [RFC5521], [RFC5541], [RFC5520] are focused on MPLS networks, and do 104 not cover the wide range of GMPLS networks. This document 105 complements these RFCs by addressing the extensions required for 106 GMPLS applications and routing requests, for example for OTN and WSON 107 networks. 109 The functional requirements to be considered by the PCEP extensions 110 to support those application are described in [RFC7025] and 111 [RFC7449]. 113 1.1. Contributing Authors 115 Elie Sfeir, Franz Rambach (Nokia Siemens Networks) Francisco Javier 116 Jimenez Chico (Telefonica Investigacion y Desarrollo) Suresh BR, 117 Young Lee, SenthilKumar S, Jun Sun (Huawei Technologies), Ramon 118 Casellas (CTTC) 120 1.2. PCEP Requirements for GMPLS 122 The document [RFC7025] describes the set of PCEP requirements to 123 support GMPLS TE-LSPs. When a PCC requests a PCE to perform a path 124 computation (by means of a PCReq message), the PCC should be able to 125 indicate the following additional information: 127 o Which data flow is switched by the LSP: a combination of Switching 128 type (for instance L2SC or TDM), LSP Encoding type (e.g., 129 Ethernet, SONET/SDH) and sometimes the Signal Type (e.g. in case 130 of TDM/LSC switching capability) 132 o Data flow specific traffic parameters, which are technology 133 specific. For instance, in SDH/SONET and G.709 OTN networks the 134 Concatenation Type and the Concatenation Number have an influence 135 on the switched data and on which link it can be supported 137 o Support for asymmetric bandwidth requests. 139 o Support for unnumbered interface identifiers, as defined in 140 [RFC3477] 142 o Label information and technology specific label(s) such as 143 wavelength labels as defined in [RFC6205]. A PCC should also be 144 able to specify a Label restriction similar to the one supported 145 by RSVP-TE (Resource Reservation Protocol - Traffic Engineering). 147 o Ability to indicate the requested granularity for the path ERO: 148 node, link or label. This is to allow the use of the explicit 149 label control feature of RSVP-TE. 151 We describe in this document a set of PCEP protocol extensions, 152 including new object types, TLVs, encodings, error codes and 153 procedures, in order to fulfill the aforementioned requirements. 155 1.3. Current GMPLS Support and Limitation of Base PCEP Objects 157 PCEP as of [RFC5440], [RFC5521] and [RFC8282], supports the following 158 objects, included in requests and responses related to the described 159 requirements. 161 From [RFC5440]: 163 o END-POINTS: only numbered endpoints are considered. The context 164 specifies whether they are node identifiers or numbered 165 interfaces. 167 o BANDWIDTH: the data rate is encoded in the bandwidth object (as 168 IEEE 32 bit float). [RFC5440] does not include the ability to 169 convey an encoding proper to all GMPLS-controlled networks. 171 o ERO: Unnumbered IDs are supported. 173 o LSPA: LSP attributes (setup and holding priorities) 175 From [RFC5521]: 177 o XRO object: 179 * This object allows excluding (strict or not) resources, and 180 includes the requested diversity (node, link or SRLG). 182 * When the F bit is set, the request indicates that the existing 183 path has failed and the resources present in the RRO can be 184 reused. 186 From [RFC8282]: 188 o INTER-LAYER: indicates whether inter-layer computation is allowed 190 o SWITCH-LAYER: indicates which layer(s) should be considered, can 191 be used to represent the RSVP-TE generalized label request 193 o REQ-ADAP-CAP: indicates the adaptation capabilities requested, can 194 also be used for the endpoints in case of mono-layer computation 196 The shortcomings of the base 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 Inclue/eXclude Route Objects (IRO/XRO) do not allow the 207 inclusion/exclusion of labels. 209 Base attributes do not allow expressing the requested link protection 210 level and/or the end-to-end protection attributes. 212 The covered PCEP extensions are: 214 Two new object types are introduced for the BANDWIDTH 215 object(Generalized bandwidth, Generalized bandwidth of existing 216 TE-LSP for which a reoptimization is requested for which a 217 reoptimization is requested). 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 the 270 GMPLS-CAPABILITY TLV it is RECOMMENDED that the PCC does not make use 271 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 corresponds to requirement 12 of 298 [RFC7025] 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 Table 1: RG flag 314 The flag in the RP object indicates the requested route granularity. 315 The PCE SHOULD follow this granularity and MAY return a NO-PATH if 316 the requested granularity cannot be provided. The PCE MAY return any 317 granularity on the route based on its policy. The PCC can decide if 318 the ERO is acceptable based on its content. 320 If a PCE honored the requested routing granularity for a request, it 321 MUST indicate the selected routing granularity in the RP object 322 included in the response. Otherwise, the PCE MUST use the reserved 323 RG to leave the check of the ERO to the PCC. The RG flag is 324 backward-compatible with [RFC5440]: the value sent by an 325 implementation (PCC or PCE) not supporting it will indicate a 326 reserved value. 328 2.3. BANDWIDTH Object Extensions 330 From [RFC5440] the object carrying the requested size for the TE-LSP 331 is the BANDWIDTH object. The object types 1 and 2 defined in 332 [RFC5440] do not describe enough information to describe the TE-LSP 333 bandwidth in GMPLS networks. The BANDWIDTH object encoding has to be 334 extended to allow to express the bandwidth as described in [RFC7025]. 335 RSVP-TE extensions for GMPLS provide a set of encoding allowing such 336 representation in an unambiguous way, this is encoded in the RSVP-TE 337 TSpec and FlowSpec objects. This document extends the BANDWIDTH 338 object with new object types reusing the RSVP-TE encoding. 340 The following possibilities are supported by the extended encoding: 342 o Asymmetric bandwidth (different bandwidth in forward and reverse 343 direction), as described in [RFC6387] 345 o GMPLS (SDH/SONET, G.709, ATM, MEF etc) parameters. 347 This correspond to requirement 3, 4, 5 and 11 of [RFC7025] section 348 3.1. 350 This document defines two Object Types for the BANDWIDTH object: 352 TBA-2 Generalized bandwidth 354 TBA-3 Generalized bandwidth of an existing TE-LSP for which a 355 reoptimization is requested 357 The definitions below apply for Object Type TBA-2 and TBA-3. The 358 body is as follows: 360 0 1 2 3 361 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 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | Bandwidth Spec Length | Rev. Bandwidth Spec Length | 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 | Bw Spec Type | Reserved | 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | | 368 ~ Generalized Bandwidth ~ 369 | | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | | 372 ~ Optional: Reverse Generalized Bandwidth ~ 373 | | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | | 376 ~ Optional TLVs ~ 377 | | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 The BANDWIDTH object type TBA-2 and TBA-3 have a variable length. 381 The 16-bit Bandwidth Spec Length field indicates the length of the 382 Generalized Bandwidth field. The Bandwidth Spec Length MUST be 383 strictly greater than 0. The 16-bit Reverse Bandwidth Spec Length 384 field indicates the length of the Reverse Generalized Bandwidth 385 field. The Reverse Bandwidth Spec Length MAY be equal to 0. 387 The Bw Spec Type field determines which type of bandwidth is 388 represented by the object. 390 The Bw Spec Type correspond to the RSVP-TE SENDER_TSPEC (Object Class 391 12) C-Types 393 The encoding of the fields Generalized Bandwidth and Reverse 394 Generalized Bandwidth is the same as the Traffic Parameters carried 395 in RSVP-TE, it can be found in the following references. 397 Object Type Name Reference 399 2 Intserv [RFC2210] 400 4 SONET/SDH [RFC4606] 401 5 G.709 [RFC4328] 402 6 Ethernet [RFC6003] 403 7 OTN-TDM [RFC7139] 404 8 SSON [RFC7792] 406 Table 2: Generalized Bandwidth and Reverse Generalized Bandwidth 407 field encoding 409 When a PCC requests a bi-directional path with symmetric bandwidth, 410 it SHOULD only specify the Generalized Bandwidth field, and set the 411 Reverse Bandwidth Spec Length to 0. When a PCC needs to request a 412 bi-directional path with asymmetric bandwidth, it SHOULD specify the 413 different bandwidth in the forward and reverse directions with a 414 Generalized Bandwidth and Reverse Generalized Bandwidth fields. 416 The procedure described in [RFC5440] for the PCRep is unchanged: a 417 PCE MAY include the BANDWIDTH objects in the response to indicate the 418 BANDWIDTH of the path. 420 As specified in [RFC5440] in the case of the reoptimization of a TE- 421 LSP, the bandwidth of the existing TE-LSP MUST also be included in 422 addition to the requested bandwidth if and only if the two values 423 differ. The Object Type TBA-3 MAY be used instead of object type 2 424 to indicate the existing TE-LSP bandwidth. A PCC that requested a 425 path with a BANDWIDTH object of object type 1 SHOULD use object type 426 2 to represent the existing TE-LSP BANDWIDTH. 428 OPTIONAL TLVs MAY be included within the object body to specify more 429 specific bandwidth requirements. No TLVs for the Object Type TBA-2 430 and TBA-3 are defined by this document. 432 2.4. LOAD-BALANCING Object Extensions 434 The LOAD-BALANCING object [RFC5440] is used to request a set of 435 maximum Max-LSP TE-LSP having in total the bandwidth specified in 436 BANDWIDTH, each TE-LSP having a minimum of bandwidth. The LOAD- 437 BALANCING follows the bandwidth encoding of the BANDWIDTH object, and 438 thus the existing definition from [RFC5440] does not describe enough 439 details for the bandwidth specification expected by GMPLS. 441 Similarly to the BANDWIDTH object, a new object type is defined to 442 allow a PCC to represent the bandwidth types supported by GMPLS 443 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 Spec field. It is to be noted that the RSVP-TE traffic 470 specification MAY also include TLV different from the PCEP TLVs. The 471 length MUST be strictly greater than 0. 473 Reverse Bandwidth Spec Length (16 bits): the total length of the Min 474 Reverse Bandwidth Spec field. It MAY be equal to 0. 476 Bw Spec Type (8 bits): the bandwidth specification type, it 477 corresponds to the RSVP-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 482 specification of each element of the TE-LSP set. 484 Min Reverse Bandwidth Spec (variable): specifies the minimum reverse 485 bandwidth specification of each element of the TE-LSP set. 487 The encoding of the fields 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 Table 2 from Section 2.3. 491 When a PCC requests a bi-directional path with symetric bandwidth 492 while specifying load balancing constraints it SHOULD specify the Min 493 Bandwidth Spec field, and set the Reverse Bandwidth Spec Length to 0. 494 When a PCC needs to request a bi-directional path with asymmetric 495 bandwidth while specifying load balancing constraints, it MUST 496 specify the different bandwidth in forward and reverse directions 497 through a Min Bandwidth Spec and Min Reverse Bandwidth Spec fields. 499 OPTIONAL TLVs MAY be included within the object body to specify more 500 specific bandwidth requirements. No TLVs for the Generalized Load 501 Balancing object type are defined by this document. 503 The semantic of the LOAD-BALANCING object is not changed. If a PCC 504 requests the computation of a set of TE-LSPs so that the total of 505 their generalized bandwidth is X, the maximum number of TE-LSPs is N, 506 and each TE-LSP must at least have a bandwidth of B, it inserts a 507 BANDWIDTH object specifying X as the required bandwidth and a LOAD- 508 BALANCING object with the Max-LSP and Min Bandwidth Spec fields set 509 to N and B, respectively. 511 2.5. END-POINTS Object Extensions 513 The END-POINTS object is used in a PCEP request message to specify 514 the source and the destination of the path for which a path 515 computation is requested. From [RFC5440], the source IP address and 516 the destination IP address are used to identify those. A new Object 517 Type is defined to address the following possibilities: 519 o Different source and destination endpoint types. 521 o Label restrictions on the endpoint. 523 o Specification of unnumbered endpoints type as seen in GMPLS 524 networks. 526 The Object encoding is described in the following sections. 528 In path computation within a GMPLS context the endpoints can: 530 o Be unnumbered as described in [RFC3477]. 532 o Have label(s) associated to them, specifying a set of constraints 533 in the allocation of labels. 535 o Have different switching capabilities 537 The IPv4 and IPv6 endpoints are used to represent the source and 538 destination IP addresses. The scope of the IP address (Node or 539 numbered Link) is not explicitly stated. It is also possible to 540 request a Path between a numbered link and an unnumbered link, or a 541 P2MP path between different type of endpoints. 543 This document defines the Generalized Endpoint object type TBA-5 for 544 the END-POINTS object. This new type also supports the specification 545 of constraints on the endpoint label to be used. The PCE might know 546 the interface restrictions but this is not a requirement. This 547 corresponds to requirements 6 and 10 of [RFC7025]. 549 2.5.1. Generalized Endpoint Object Type 551 The Generalized Endpoint object type format consists of a body and a 552 list of TLVs scoped to this object. The TLVs give the details of the 553 endpoints and are described in Section 2.5.2. For each Endpoint 554 Type, a different grammar is defined. The TLVs defined to describe 555 an endpoint are: 557 1. IPv4 address endpoint. 559 2. IPv6 address endpoint. 561 3. Unnumbered endpoint. 563 4. Label request. 565 5. Label set. 567 The Label set TLV is used to restrict or suggest the label allocation 568 in the PCE. This TLVs express the set of restrictions which may 569 apply to signaling. Label restriction support can be an explicit or 570 a suggested value (Label set describing one label, with the L bit 571 respectively cleared or set), mandatory range restrictions (Label set 572 with L bit cleared) and optional range restriction (Label set with L 573 bit set). Endpoints label restriction may not be part of the RRO or 574 IRO, they can be included when following [RFC4003] in signaling for 575 egress endpoint, but ingress endpoint properties can be local to the 576 PCC and not signaled. To support this case the label set allows to 577 indicate which label are used in case of reoptimization. The label 578 range restrictions are valid in GMPLS-controlled networks, either by 579 PCC policy or depending on the switching technology used, for 580 instance on given Ethernet or ODU equipment having limited hardware 581 capabilities restricting the label range. Label set restriction also 582 applies to WSON networks where the optical senders and receivers are 583 limited in their frequency tunability ranges, restricting then in 584 GMPLS the possible label ranges on the interface. The END-POINTS 585 Object with Generalized Endpoint object type is encoded as follow: 587 0 1 2 3 588 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 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 | Reserved | Endpoint Type | 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 | | 593 ~ TLVs ~ 594 | | 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 Reserved bits SHOULD be set to 0 when a message is sent and ignored 598 when the message is received. 600 The Endpoint Type is defined as follow: 602 Value Type Meaning 604 0 Point-to-Point 605 1 Point-to-Multipoint New leaves to add 606 2 Old leaves to remove 607 3 Old leaves whose path can be 608 modified/reoptimized 609 4 Old leaves whose path has to be 610 left unchanged 611 5-244 Reserved 612 245-255 Experimental range 614 Table 3: Generalized Endpoint endpoint types 616 The Endpoint Type is used to cover both point-to-point and different 617 point-to-multipoint endpoints. A PCE may accept only Endpoint Type 618 0: Endpoint Types 1-4 apply if the PCE implementation supports P2MP 619 path calculation. A PCE not supporting a given Endpoint Type SHOULD 620 respond with a PCErr with Error Type 4, Value TBD "Unsupported 621 endpoint type in END-POINTS Generalized Endpoint object type". As 622 per [RFC5440], a PCE unable to process Generalized Endpoints may 623 respond with Error Type 3 or 4, Value 2. The TLVs present in the 624 request object body MUST follow the following [RFC5511] grammar: 626 ::= 627 | 629 ::= 630 [] 631 [] 633 ::= 634 [] 635 [ []]... 637 For endpoint type Point-to-Multipoint, several endpoint objects MAY 638 be present in the message and each represents a leave, exact meaning 639 depend on the endpoint type defined of the object. 641 An endpoint is defined as follows: 643 ::=|| 644 ::= 645 [] 647 ::= 648 650 ::= 651 [] 652 ::= 654 The different TLVs are described in the following sections. A PCE 655 MAY support IPV4-ADDRESS, IPV6-ADDRESS or UNNUMBERED-ENDPOINT TLVs. 656 When receiving a PCReq, a PCE unable to resolve the identifier in one 657 of those TLVs MUST respond using a PCRep with NO-PATH and set the bit 658 "Unknown destination" or "Unknown source" in the NO-PATH-VECTOR TLV. 659 The response SHOULD include the END-POINTS object with only the 660 unsupported TLV(s). 662 A PCE MAY support LABEL-REQUEST or LABEL-SET TLVs. If a PCE finds a 663 non-supported TLV in the END-POINTS the PCE MUST respond with a PCErr 664 message with Error Type 4 error value="Unsupported TLV present in 665 END-POINTS Generalized Endpoint object type" and the message SHOULD 666 include the END-POINTS object in the response with only the endpoint 667 and endpoint restriction TLV it did not understand. A PCE supporting 668 those TLVs but not being able to fulfil the label restriction MUST 669 send a response with a NO-PATH object which has the bit "No endpoint 670 label resource" or "No endpoint label resource in range" set in the 671 NO-PATH-VECTOR TLV. The response SHOULD include an END-POINTS object 672 containing only the TLV(s) related to the constraints the PCE could 673 not meet. 675 2.5.2. END-POINTS TLV Extensions 677 All endpoint TLVs have the standard PCEP TLV header as defined in 678 [RFC5440] section 7.1. In this object type the order of the TLVs 679 MUST be followed according to the object type definition. 681 2.5.2.1. IPV4-ADDRESS TLV 683 This TLV represents a numbered endpoint using IPv4 numbering, the 684 format of the IPv4-ADDRESS TLV value (TLV-Type=TBA-6) is as follows: 686 0 1 2 3 687 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 688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 689 | IPv4 address | 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 692 This TLV MAY be ignored, in which case a PCRep with NO-PATH SHOULD be 693 responded, as described in Section 2.5.1. 695 2.5.2.2. IPV6-ADDRESS TLV 697 This TLV represents a numbered endpoint using IPV6 numbering, the 698 format of the IPv6-ADDRESS TLV value (TLV-Type=TBA-7) is as follows: 700 0 1 2 3 701 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 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 | IPv6 address (16 bytes) | 704 | | 705 | | 706 | | 707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 709 This TLV MAY be ignored, in which case a PCRep with NO-PATH SHOULD be 710 responded, as described in Section 2.5.1. 712 2.5.2.3. UNNUMBERED-ENDPOINT TLV 714 This TLV represents an unnumbered interface. This TLV has the same 715 semantic as in [RFC3477]. The TLV value is encoded as follow (TLV- 716 Type=TBA-8) 717 0 1 2 3 718 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 719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 720 | LSR's Router ID | 721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 722 | Interface ID (32 bits) | 723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 725 This TLV MAY be ignored, in which case a PCRep with NO-PATH SHOULD be 726 responded, as described in Section 2.5.1. 728 2.5.2.4. LABEL-REQUEST TLV 730 The LABEL-REQUEST TLV indicates the switching capability and encoding 731 type of the following label restriction list for the endpoint. Its 732 format and encoding is the same as described in [RFC3471] Section 3.1 733 Generalized label request. The LABEL-REQUEST TLV use TLV-Type=TBA-9. 734 The Encoding Type indicates the encoding type, e.g., SONET/SDH/GigE 735 etc., of the LSP with which the data is associated. The Switching 736 type indicates the type of switching that is being requested on the 737 endpoint. G-PID identifies the payload. This TLV and the following 738 one are introduced to satisfy requirement 13 of [RFC7025] for the 739 endpoint. It is not directly related to the TE-LSP label request, 740 which is expressed by the SWITCH-LAYER object. 742 On the path calculation request only the Tspec and switch layer need 743 to be coherent, the endpoint labels could be different (supporting a 744 different Tspec). Hence the label restrictions include a Generalized 745 label request in order to interpret the labels. This TLV MAY be 746 ignored, in which case a PCRep with NO-PATH SHOULD be responded, as 747 described in Section 2.5.1. 749 2.5.2.5. Labels TLV 751 Label or label range restrictions can be specified for the TE-LSP 752 endpoints. Those are encoded using the LABEL-SET TLV. The label 753 value need to be interpreted with a description on the Encoding and 754 switching type. The REQ-ADAP-CAP object from [RFC8282] can be used 755 in case of mono-layer request, however in case of multilayer it is 756 possible to have more than one object, so it is better to have a 757 dedicated TLV for the label and label request. Those TLV MAY be 758 ignored, in which case a response with NO-PATH SHOULD be responded, 759 as described in Section 2.5.1. TLVs are encoded as follow (following 760 [RFC5440]): 762 o LABEL-SET TLV, Type=TBA-10. The TLV Length is variable, Encoding 763 follows [RFC3471] Section 3.5 "Label set" with the addition of a U 764 bit, O bit and L bit. The L bit is used to represent a suggested 765 set of label, following the semantic of SUGGESTED_LABEL defined by 766 [RFC3471]. The U bit is set for upstream direction in case of 767 bidirectional LSP and the O bit is used to represent a previously 768 allocated label. 770 0 1 2 3 771 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 772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 773 | Action | Reserved |L|O|U| Label Type | 774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 775 | Subchannel 1 | 776 | ... | 777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 778 : : : 779 : : : 780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 781 | Subchannel N | 782 | ... | 783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 785 A LABEL-SET TLV represents a set of possible labels that can be used 786 on an interface. If the L bit is cleared, the label allocated on the 787 first endpoint MUST be within the label set range. The action 788 parameter in the Label set indicates the type of list provided. 789 Those parameters are described by [RFC3471] section 3.5.1. 791 The U, O and L bits have the following meaning: 793 U: Upstream direction: set when the label or label set is in the 794 reverse direction 795 O: Old Label: set when the TLV represent the old label in case of re- 796 optimization. The R bit of the RP object MUST be set to 1. If the 797 L bit is set, this bit SHOULD be set to 0 and ignored on receipt. 798 When this bit is set, the Action field MUST be set to 0 (Inclusive 799 List) and the Label Set MUST contain one subchannel. 800 L: Loose Label: set when the TLV indicates to the PCE a set of 801 preferred (ordered) labels to be used. The PCE MAY use those 802 labels for label allocation. 804 Labels TLV bits 806 Several LABEL_SET TLVs MAY be present with the O bit cleared, 807 LABEL_SET TLVs with L bit set can be combined with a LABEL_SET TLV 808 with L bit cleared. At most 2 LABEL_SET TLVs MUST be present with 809 the O bit set, at most one with the U bit set and at most one with 810 the U bit cleared. For a given U bit value, if more than one 811 LABEL_SET TLV with the O bit set is present, the first TLV MUST be 812 processed and the following TLVs with the same U and O bit MUST be 813 ignored. 815 A LABEL-SET TLV with the O and L bit set MUST trigger a PCErr message 816 with error type="Reception of an invalid object" error value="Wrong 817 LABEL-SET TLV present with O and L bit set". 819 A LABEL-SET TLV with the O bit set and an Action Field not set to 0 820 (Inclusive list) or containing more than one subchannel MUST trigger 821 a PCErr message with error type="Reception of an invalid object" 822 error value="Wrong LABEL-SET TLV present with O bit and wrong 823 format". 825 If a LABEL-SET TLV is present with O bit set, the R bit of the RP 826 object MUST be set, otherwise a PCErr message MUST be sent with error 827 type="Reception of an invalid object" error value="LABEL-SET TLV 828 present with O bit set but without R bit set in RP". 830 2.6. IRO Extension 832 The IRO as defined in [RFC5440] is used to include specific objects 833 in the path. RSVP-TE allows to include label definition, in order to 834 fulfill requirement 13 of [RFC7025] the IRO needs to support the new 835 subobject type as defined in [RFC3473]: 837 Type Sub-object 838 TBA-38 LABEL 840 The Label subobject MUST follow a subobject identifying a link, 841 currently an IP address subobject (Type 1 or 2) or an interface ID 842 (type 4) subobject. If an IP address subobject is used, then the 843 given IP address MUST be associated with a link. More than one label 844 subobject MAY follow each link subobject. The procedure associated 845 with this subobject is as follows. 847 If the PCE is able to allocate labels (e.g. via explicit label 848 control) the PCE MUST allocate one label from within the set of label 849 values for the given link. If the PCE does not assign labels, then 850 it sends a response with a NO-PATH object, containing a NO-PATH- 851 VECTOR TLV with the bit 'No label resource in range' set. 853 2.7. XRO Extension 855 The XRO as defined in [RFC5521] is used to exclude specific objects 856 in the path. RSVP-TE allows to exclude labels ([RFC6001]), in order 857 to fulfill requirement 13 of [RFC7025] section 3.1, the PCEP's XRO 858 needs to support a new subobject to enable label exclusion. 860 The encoding of the XRO Label subobject follows the encoding of the 861 Label ERO subobject defined in [RFC3473] and XRO subobject defined in 862 [RFC5521]. The XRO Label subobject represent one Label and is 863 defined as follows: 865 XRO Subobject Type TBA-39: Label Subobject. 867 0 1 2 3 868 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 869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 870 |X| Type=TBA-39 | Length |U| Reserved | C-Type | 871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 872 | Label | 873 | ... | 874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 876 X (1 bit): as per [RFC5521]. The X-bit indicates whether the 877 exclusion is mandatory or desired. 0 indicates that the resource 878 specified MUST be excluded from the path computed by the PCE. 1 879 indicates that the resource specified SHOULD be excluded from the 880 path computed by the PCE, but MAY be included subject to PCE 881 policy and the absence of a viable path that meets the other 882 constraints and excludes the resource. 884 Type (7 bits): The Type of the XRO Label subobject is TBA-39, 885 suggested value 3. 887 Length (8 bits): see [RFC5521], the total length of the subobject 888 in bytes (including the Type and Length fields). The Length is 889 always divisible by 4. 891 U (1 bit): see [RFC3471]. 893 C-Type (8 bits): the C-Type of the included Label Object as 894 defined in [RFC3471]. 896 Label: see [RFC3471]. 898 The Label subobject MUST follow a subobject identifying a link, 899 currently an IP address subobject (Type 1 or 2) or an interface ID 900 (type 4) subobject. If an IP address subobject is used, then the 901 given IP address MUST be associated with a link. More than one label 902 subobject MAY follow each link subobject. 904 Type Sub-object 905 3 LABEL 907 2.8. LSPA Extensions 909 The LSPA carries the LSP attributes. In the end-to-end recovery 910 context, this also includes the protection state information. This 911 object is introduced to fulfill requirement 7 of [RFC7025] section 912 3.1 and requirement 3 of [RFC7025] section 3.2. This object contains 913 the information of the PROTECTION object defined by [RFC4872] and can 914 be used as a policy input. The LSPA object MAY carry a PROTECTION- 915 ATTRIBUTE TLV defined as: Type TBA-12: PROTECTION-ATTRIBUTE 917 0 1 2 3 918 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 919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 920 | Type | Length | 921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 922 |S|P|N|O| Reserved | LSP Flags | Reserved | Link Flags| 923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 924 |I|R| Reserved | Seg.Flags | Reserved | 925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 927 The content is as defined in [RFC4872], [RFC4873]. 929 LSP (protection) Flags or Link flags field can be used by a PCE 930 implementation for routing policy input. The other attributes are 931 only meaningful for a stateful PCE. 933 This TLV is OPTIONAL and MAY be ignored by the PCE, in which case it 934 MUST NOT include the TLV in the LSPA, if present, of the response. 935 When the TLV is used by the PCE, a LSPA object and the PROTECTION- 936 ATTRIBUTE TLV MUST be included in the response. Fields that were not 937 considered MUST be set to 0. 939 2.9. NO-PATH Object Extension 941 The NO-PATH object is used in PCRep messages in response to an 942 unsuccessful path computation request (the PCE could not find a path 943 satisfying the set of constraints). In this scenario, PCE MUST 944 include a NO-PATH object in the PCRep message. The NO-PATH object 945 MAY carries the NO-PATH-VECTOR TLV that specifies more information on 946 the reasons that led to a negative reply. In case of GMPLS networks 947 there could be some additional constraints that led to the failure 948 like protection mismatch, lack of resources, and so on. Few new 949 flags have been introduced in the 32-bit flag field of the NO-PATH- 950 VECTOR TLV and no modifications have been made in the NO-PATH object. 952 2.9.1. Extensions to NO-PATH-VECTOR TLV 954 The modified NO-PATH-VECTOR TLV carrying the additional information 955 is as follows: 957 Bit number TBA-32 - Protection Mismatch (1-bit). Specifies the 958 mismatch of the protection type in the PROTECTION-ATTRIBUTE TLV in 959 the request. 961 Bit number TBA-33 - No Resource (1-bit). Specifies that the 962 resources are not currently sufficient to provide the path. 964 Bit number TBA-34 - Granularity not supported (1-bit). Specifies 965 that the PCE is not able to provide a path with the requested 966 granularity. 968 Bit number TBA-35 - No endpoint label resource (1-bit). Specifies 969 that the PCE is not able to provide a path because of the endpoint 970 label restriction. 972 Bit number TBA-36 - No endpoint label resource in range (1-bit). 973 Specifies that the PCE is not able to provide a path because of 974 the endpoint label set restriction. 976 Bit number TBA-37 - No label resource in range (1-bit). Specifies 977 that the PCE is not able to provide a path because of the label 978 set restriction. 980 3. Additional Error-Types and Error-Values Defined 982 A PCEP-ERROR object is used to report a PCEP error and is 983 characterized by an Error-Type that specifies the type of error while 984 Error-value that provides additional information about the error. An 985 additional error type and few error values are defined to represent 986 some of the errors related to the newly identified objects related to 987 GMPLS networks. For each PCEP error, an Error-Type and an Error- 988 value are defined. Error-Type 1 to 10 are already defined in 989 [RFC5440]. Additional Error- values are defined for Error-Types 4 990 and 10. A new Error-Type is introduced (value TBA-27). 992 Error-Type Error-value 994 4 Not supported 995 object 996 value=TBA-14: Bandwidth Object type TBA-2 or TBA-3 not 997 supported. 998 value=TBA-15: Unsupported endpoint type in 999 END-POINTS Generalized Endpoint 1000 object type. 1001 value=TBA-16: Unsupported TLV present in END-POINTS 1002 Generalized Endpoint object type. 1003 value=TBA-17: Unsupported granularity in the RP object 1004 flags. 1005 10 Reception of 1006 an invalid 1007 object 1008 value=TBA-18: Bad Bandwidth Object type TBA-2(Generalized 1009 bandwidth) or TBA-3( Generalized bandwidth 1010 of existing TE-LSP for which a 1011 reoptimization is requested). 1012 value=TBA-19: Unsupported LSP Protection Type in 1013 PROTECTION-ATTRIBUTE TLV. 1014 value=TBA-20: Unsupported LSP Protection Flags in 1015 PROTECTION-ATTRIBUTE TLV. 1016 value=TBA-21: Unsupported Secondary LSP Protection Flags 1017 in PROTECTION-ATTRIBUTE TLV. 1018 value=TBA-22: Unsupported Link Protection Type in 1019 PROTECTION-ATTRIBUTE TLV. 1020 value=TBA-23: Unsupported Link Protection Type in 1021 PROTECTION-ATTRIBUTE TLV. 1022 value=TBA-24: LABEL-SET TLV present with 0 bit set but 1023 without R bit set in RP. 1024 value=TBA-25: Wrong LABEL-SET 1025 TLV present with 1026 0 and L bit set. 1027 value=TBA-26: Wrong LABEL-SET with O bit set and wrong 1028 format. 1029 TBA-27 Path 1030 computation 1031 failure 1032 value=0: Unassigned. 1033 value=TBA-28: Unacceptable request message. 1034 value=TBA-29: Generalized bandwidth value not supported. 1035 value=TBA-30: Label Set constraint could not be 1036 met. 1037 value=TBA-31: Label constraint could not be 1038 met. 1040 4. Manageability Considerations 1042 This section follows the guidance of [RFC6123]. 1044 4.1. Control of Function through Configuration and Policy 1046 This document makes no change to the basic operation of PCEP and so 1047 the requirements described in [RFC5440] Section 8.1. also apply to 1048 this document. In addition to those requirements a PCEP 1049 implementation may allow the configuration of the following 1050 parameters: 1052 Accepted RG in the RP object. 1054 Default RG to use (overriding the one present in the PCReq) 1056 Accepted BANDWIDTH object type TBA-2 and TBA-3 parameters in 1057 request, default mapping to use when not specified in the request 1059 Accepted LOAD-BALANCING object type TBA-4 parameters in request. 1061 Accepted endpoint type and allowed TLVs in object END-POINTS with 1062 object type Generalized Endpoint. 1064 Accepted range for label restrictions in label restriction in END- 1065 POINTS, or IRO or XRO objects 1067 PROTECTION-ATTRIBUTE TLV acceptance and suppression. 1069 Those parameters configuration are applicable to the different 1070 sessions as described in [RFC5440] Section 8.1 (by default, per PCEP 1071 peer, etc.). 1073 4.2. Information and Data Models 1075 This document makes no change to the basic operation of PCEP and so 1076 the requirements described in [RFC5440] Section 8.2. also apply to 1077 this document. This document does not introduces new ERO sub object, 1078 ERO information model is already covered in [RFC4802]. 1080 4.3. Liveness Detection and Monitoring 1082 This document makes no change to the basic operation of PCEP and so 1083 there are no changes to the requirements for liveness detection and 1084 monitoring set out in [RFC4657] and [RFC5440] Section 8.3. 1086 4.4. Verifying Correct Operation 1088 This document makes no change to the basic operations of PCEP and 1089 considerations described in [RFC5440] Section 8.4. New errors 1090 introduced by this document should be covered by the requirement to 1091 log error events. 1093 4.5. Requirements on Other Protocols and Functional Components 1095 No new Requirements on Other Protocols and Functional Components are 1096 made by this document. This document does not require ERO object 1097 extensions. Any new ERO subobject defined in the TEAS or CCAMP 1098 working group can be adopted without modifying the operations defined 1099 in this document. 1101 4.6. Impact on Network Operation 1103 This document makes no change to the basic operations of PCEP and 1104 considerations described in [RFC5440] Section 8.6. In addition to 1105 the limit on the rate of messages sent by a PCEP speaker, a limit MAY 1106 be placed on the size of the PCEP messages. 1108 5. IANA Considerations 1110 IANA assigns values to the PCEP protocol objects and TLVs. IANA is 1111 requested to make some allocations for the newly defined objects and 1112 TLVs introduced in this document. Also, IANA is requested to manage 1113 the space of flags that are newly added in the TLVs. 1115 5.1. PCEP Objects 1117 As described in Section 2.3, Section 2.4 and Section 2.5.1 new 1118 Objects types are defined. IANA is requested to make the following 1119 Object-Type allocations from the "PCEP Objects" sub-registry. 1121 Object 5 1122 Class 1123 Name BANDWIDTH 1124 Object-Type TBA-2: Generalized bandwidth 1125 TBA-3: Generalized bandwidth of an existing TE-LSP for 1126 which a reoptimization is requested 1127 Reference This document (section Section 2.3) 1129 Object 14 1130 Class 1131 Name LOAD-BALANCING 1132 Object-Type TBA-4: Generalized Load Balancing 1134 Reference This document (section Section 2.4) 1135 Object 4 1136 Class 1137 Name END-POINTS 1138 Object-Type TBA-5: Generalized Endpoint 1139 Reference This document (section Section 2.5) 1141 5.2. END-POINTS Object, Object Type Generalized Endpoint 1143 IANA is requested to create a registry to manage the Endpoint Type 1144 field of the END-POINTS object, Object Type Generalized Endpoint and 1145 manage the code space. 1147 New endpoint type in the Reserved range MAY be allocated by an IETF 1148 consensus action. Each endpoint type should be tracked with the 1149 following qualities: 1151 o Endpoint type 1153 o Description 1155 o Defining RFC 1157 New endpoint type in the Experimental range are for experimental use; 1158 these will not be registered with IANA and MUST NOT be mentioned by 1159 RFCs. 1161 The following values have been defined by this document. 1162 (Section 2.5.1, Table 3): 1164 Value Type Meaning 1166 0 Point-to-Point 1167 1 Point-to-Multipoint New leaves to add 1168 2 Old leaves to remove 1169 3 Old leaves whose path can be 1170 modified/reoptimized 1171 4 Old leaves whose path has to be 1172 left unchanged 1173 5-244 Reserved 1174 245-255 Experimental range 1176 5.3. New PCEP TLVs 1178 IANA manages the PCEP TLV code point registry (see [RFC5440]). This 1179 is maintained as the "PCEP TLV Type Indicators" sub-registry of the 1180 "Path Computation Element Protocol (PCEP) Numbers" registry. This 1181 document defines new PCEP TLVs, to be carried in the END-POINTS 1182 object with Generalized Endpoint object Type. IANA is requested to 1183 do the following allocation. The values here are suggested for use 1184 by IANA. 1186 Value Meaning Reference 1188 TBA-6 IPV4-ADDRESS This document (section Section 2.5.2.1) 1189 TBA-7 IPV6-ADDRESS This document (section Section 2.5.2.2) 1190 TBA-8 UNNUMBERED-ENDPOINT This document (section Section 2.5.2.3) 1191 TBA-9 LABEL-REQUEST This document (section Section 2.5.2.4) 1192 TBA-10 LABEL-SET This document (section Section 2.5.2.5) 1193 TBA-11 SUGGESTED-LABEL-SET This document (section Section 2.5.2.5) 1194 TBA-12 PROTECTION-ATTRIBUTE This document (section Section 2.8) 1195 TBA-1 GMPLS-CAPABILITY This document (section Section 2.1.2) 1197 5.4. RP Object Flag Field 1199 As described in Section 2.2 new flag are defined in the RP Object 1200 Flag IANA is requested to make the following Object-Type allocations 1201 from the "RP Object Flag Field" sub-registry. The values here are 1202 suggested for use by IANA. 1204 Bit Description Reference 1206 TBA-13 (suggested bit routing granularity This document, Section 1207 17-16) (RG) 2.2 1209 5.5. New PCEP Error Codes 1211 As described in Section 3, new PCEP Error-Types and Error-values are 1212 defined. IANA is requested to make the following allocation in the 1213 "PCEP-ERROR Object Error Types and Values" registry. The values here 1214 are suggested for use by IANA. 1216 Error name Reference 1218 Type=4 Not supported object [RFC5440] 1219 Value=TBA-14: Bandwidth Object type TBA or TBA not This Document 1220 supported. 1221 Value=TBA-15: Unsupported endpoint type in END-POINTS This Document 1222 Generalized Endpoint object type 1223 Value=TBA-16: Unsupported TLV present in END-POINTS This Document 1224 Generalized Endpoint object type 1225 Value=TBA-17: Unsupported granularity in the RP object This Document 1226 flags 1227 Type=10 Reception of an invalid object [RFC5440] 1228 Value=TBA-18: Bad Bandwidth Object type This Document 1229 TBA-2(Generalized bandwidth) or 1230 TBA-3(Generalized bandwidth of existing 1231 TE-LSP for which a reoptimization is 1232 requested). 1233 Value=TBA-19: Unsupported LSP Protection Type in This Document 1234 PROTECTION-ATTRIBUTE TLV. 1235 Value=TBA-20: Unsupported LSP Protection Flags in This Document 1236 PROTECTION-ATTRIBUTE TLV. 1237 Value=TBA-21: Unsupported Secondary LSP Protection This Document 1238 Flags in PROTECTION-ATTRIBUTE TLV. 1239 Value=TBA-22: Unsupported Link Protection Type in This Document 1240 PROTECTION-ATTRIBUTE TLV. 1241 Value=TBA-23: Unsupported Link Protection Type in This Document 1242 PROTECTION-ATTRIBUTE TLV. 1243 Value=TBA-24: LABEL-SET TLV present with 0 bit set but This Document 1244 without R bit set in RP. 1245 Value=TBA-25: Wrong LABEL-SET TLV present with 0 and L This Document 1246 bit set. 1247 Value=TBA-26: Wrong LABEL-SET with O bit set and wrong This Document 1248 format. 1249 Type=TBA-27 Path computation failure This Document 1250 Value=0 Unassigned. This Document 1251 Value=TBA-28: Unacceptable request message. This Document 1252 Value=TBA-29: Generalized bandwidth value not This Document 1253 supported. 1254 Value=TBA-30: Label Set constraint could not be met. This Document 1255 Value=TBA-31: Label constraint could not be met. This Document 1257 5.6. New NO-PATH-VECTOR TLV Fields 1259 As described in Section 2.9.1, new NO-PATH-VECTOR TLV Flag Fields 1260 have been defined. IANA is requested to do the following allocations 1261 in the "NO-PATH-VECTOR TLV Flag Field" sub-registry. The values here 1262 are suggested for use by IANA. 1264 Bit number TBA-32 - Protection Mismatch (1-bit). Specifies the 1265 mismatch of the protection type of the PROTECTION-ATTRIBUTE TLV in 1266 the request. 1268 Bit number TBA-33 - No Resource (1-bit). Specifies that the 1269 resources are not currently sufficient to provide the path. 1271 Bit number TBA-34 - Granularity not supported (1-bit). Specifies 1272 that the PCE is not able to provide a path with the requested 1273 granularity. 1275 Bit number TBA-35 - No endpoint label resource (1-bit). Specifies 1276 that the PCE is not able to provide a path because of the endpoint 1277 label restriction. 1279 Bit number TBA-36 - No endpoint label resource in range (1-bit). 1280 Specifies that the PCE is not able to provide a path because of 1281 the endpoint label set restriction. 1283 Bit number TBA-37 - No label resource in range (1-bit). Specifies 1284 that the PCE is not able to provide a path because of the label 1285 set restriction. 1287 5.7. New Subobject for the Include Route Object 1289 The "PCEP Parameters" registry contains a subregistry "PCEP Objects" 1290 with an entry for the Include Route Object (IRO). 1292 IANA is requested to add a further subobject that can be carried in 1293 the IRO as follows: 1295 Subobject type Reference 1297 TBA-38, suggested value 3 Label subobject [RFC3473] 1299 5.8. New Subobject for the Exclude Route Object 1301 The "PCEP Parameters" registry contains a subregistry "PCEP Objects" 1302 with an entry for the XRO object (Exclude Route Object). 1304 IANA is requested to add a further subobject that can be carried in 1305 the XRO as follows: 1307 Subobject type Reference 1309 TBA-39, suggested value 3 Label subobject [RFC3473] 1311 6. Security Considerations 1313 GMPLS controls multiple technologies and types of network elements. 1314 The LSPs that are established using GMPLS, whose paths can be 1315 computed using the PCEP extensions to support GMPLS described in this 1316 document, can carry a high amount of traffic and can be a critical 1317 part of a network infrastructure. The PCE can then play a key role 1318 in the use of the resources and in determining the physical paths of 1319 the LSPs and thus it is important to ensure the identity of PCE and 1320 PCC, as well as the communication channel. In many deployments there 1321 will be a completely isolated network where an external attack is of 1322 very low probability. However, there are other deployment cases in 1323 which the PCC-PCE communication can be more exposed and there could 1324 be more security considerations. Three main situations in case of an 1325 attack in the GMPLS PCE context could happen: 1327 o PCE Identity theft: A legitimate PCC could requests a path for a 1328 GMPLS LSP to a malicious PCE, which poses as a legitimate PCE. 1329 The answer can make that the LSP traverses some geographical place 1330 known to the attacker where some sniffing devices could be 1331 installed. Also, the answer can omit constraints given in the 1332 requests (e.g. excluding certain fibers, avoiding some SRLGs) 1333 which could make that the LSP which will be later set-up can look 1334 perfectly fine, but will be in a risky situation. Also, the 1335 answer can lead to provide a LSP that does not provide the desired 1336 quality and gives less resources tan necessary. 1338 o PCC Identity theft: A malicious PCC, acting as a legitimate PCC, 1339 requesting LSP paths to a legitimate PCE can obtain a good 1340 knowledge of the physical topology of a critical infrastructure. 1341 It could get to know enough details to plan a later physical 1342 attack. 1344 o Message deciphering: As in the previous case, knowledge of an 1345 infrastructure can be obtained by sniffing PCEP messages. 1347 The security mechanisms can provide authentication and 1348 confidentiality for those scenarios where the PCC-PCE communication 1349 cannot be completely trusted. Authentication can provide origin 1350 verification, message integrity and replay protection, while 1351 confidentiality ensures that a third party cannot decipher the 1352 contents of a message. 1354 The document [RFC8253] describes the usage of Transport Layer 1355 Security (TLS) to enhance PCEP security. The document describes the 1356 initiation of the TLS procedures, the TLS handshake mechanisms, the 1357 TLS methods for peer authentication, the applicable TLS ciphersuites 1358 for data exchange, and the handling of errors in the security checks. 1360 Finally, as mentioned by [RFC7025] the PCEP extensions to support 1361 GMPLS should be considered under the same security as current PCE 1362 work and this extension will not change the underlying security 1363 issues. However, given the critical nature of the network 1364 infrastructures under control by GMPLS, the security issues described 1365 above should be seriously considered when deploying a GMPLS-PCE based 1366 control plane for such networks. For more information on the 1367 security considerations on a GMPLS control plane, not only related to 1368 PCE/PCEP, [RFC5920] provides an overview of security vulnerabilities 1369 of a GMPLS control plane. 1371 7. Contributing Authors 1373 Elie Sfeir 1374 Coriant 1375 St Martin Strasse 76 1376 Munich, 81541 1377 Germany 1379 Email: elie.sfeir@coriant.com 1381 Franz Rambach 1382 Nockherstrasse 2-4, 1383 Munich 81541 1384 Germany 1386 Phone: +49 178 8855738 1387 Email: franz.rambach@cgi.com 1389 Francisco Javier Jimenez Chico 1390 Telefonica Investigacion y Desarrollo 1391 C/ Emilio Vargas 6 1392 Madrid, 28043 1393 Spain 1395 Phone: +34 91 3379037 1396 Email: fjjc@tid.es 1398 Huawei Technologies 1399 Suresh BR 1400 Shenzhen 1401 China 1402 Email: sureshbr@huawei.com 1404 Young Lee 1405 1700 Alma Drive, Suite 100 1406 Plano, TX 75075 1407 USA 1409 Phone: (972) 509-5599 (x2240) 1410 Email: ylee@huawei.com 1412 SenthilKumar S 1413 Shenzhen 1414 China 1415 Email: senthilkumars@huawei.com 1417 Jun Sun 1418 Shenzhen 1419 China 1420 Email: johnsun@huawei.com 1422 CTTC - Centre Tecnologic de Telecomunicacions de Catalunya 1424 Ramon Casellas 1425 PMT Ed B4 Av. Carl Friedrich Gauss 7 1426 08860 Castelldefels (Barcelona) 1427 Spain 1428 Phone: (34) 936452916 1429 Email: ramon.casellas@cttc.es 1431 8. Acknowledgments 1433 The research of Ramon Casellas, Francisco Javier Jimenez Chico, Oscar 1434 Gonzalez de Dios, Cyril Margaria, and Franz Rambach leading to these 1435 results has received funding from the European Community's Seventh 1436 Framework Program FP7/2007-2013 under grant agreement no 247674 and 1437 no 317999. 1439 The authors would like to thank Julien Meuric, Lyndon Ong, Giada 1440 Lander, Jonathan Hardwick and Diego Lopez for their useful comments 1441 to the document. 1443 9. References 1445 9.1. Normative References 1447 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1448 Requirement Levels", BCP 14, RFC 2119, 1449 DOI 10.17487/RFC2119, March 1997, 1450 . 1452 [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated 1453 Services", RFC 2210, DOI 10.17487/RFC2210, September 1997, 1454 . 1456 [RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label 1457 Switching (GMPLS) Signaling Functional Description", 1458 RFC 3471, DOI 10.17487/RFC3471, January 2003, 1459 . 1461 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 1462 Switching (GMPLS) Signaling Resource ReserVation Protocol- 1463 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 1464 DOI 10.17487/RFC3473, January 2003, 1465 . 1467 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 1468 in Resource ReSerVation Protocol - Traffic Engineering 1469 (RSVP-TE)", RFC 3477, DOI 10.17487/RFC3477, January 2003, 1470 . 1472 [RFC4003] Berger, L., "GMPLS Signaling Procedure for Egress 1473 Control", RFC 4003, DOI 10.17487/RFC4003, February 2005, 1474 . 1476 [RFC4328] Papadimitriou, D., Ed., "Generalized Multi-Protocol Label 1477 Switching (GMPLS) Signaling Extensions for G.709 Optical 1478 Transport Networks Control", RFC 4328, 1479 DOI 10.17487/RFC4328, January 2006, 1480 . 1482 [RFC4606] Mannie, E. and D. Papadimitriou, "Generalized Multi- 1483 Protocol Label Switching (GMPLS) Extensions for 1484 Synchronous Optical Network (SONET) and Synchronous 1485 Digital Hierarchy (SDH) Control", RFC 4606, 1486 DOI 10.17487/RFC4606, August 2006, 1487 . 1489 [RFC4802] Nadeau, T., Ed., Farrel, A., and , "Generalized 1490 Multiprotocol Label Switching (GMPLS) Traffic Engineering 1491 Management Information Base", RFC 4802, 1492 DOI 10.17487/RFC4802, February 2007, 1493 . 1495 [RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, 1496 Ed., "RSVP-TE Extensions in Support of End-to-End 1497 Generalized Multi-Protocol Label Switching (GMPLS) 1498 Recovery", RFC 4872, DOI 10.17487/RFC4872, May 2007, 1499 . 1501 [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, 1502 "GMPLS Segment Recovery", RFC 4873, DOI 10.17487/RFC4873, 1503 May 2007, . 1505 [RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 1506 Zhang, "OSPF Protocol Extensions for Path Computation 1507 Element (PCE) Discovery", RFC 5088, DOI 10.17487/RFC5088, 1508 January 2008, . 1510 [RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 1511 Zhang, "IS-IS Protocol Extensions for Path Computation 1512 Element (PCE) Discovery", RFC 5089, DOI 10.17487/RFC5089, 1513 January 2008, . 1515 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1516 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 1517 DOI 10.17487/RFC5440, March 2009, 1518 . 1520 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax 1521 Used to Form Encoding Rules in Various Routing Protocol 1522 Specifications", RFC 5511, DOI 10.17487/RFC5511, April 1523 2009, . 1525 [RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel, 1526 "Preserving Topology Confidentiality in Inter-Domain Path 1527 Computation Using a Path-Key-Based Mechanism", RFC 5520, 1528 DOI 10.17487/RFC5520, April 2009, 1529 . 1531 [RFC5521] Oki, E., Takeda, T., and A. Farrel, "Extensions to the 1532 Path Computation Element Communication Protocol (PCEP) for 1533 Route Exclusions", RFC 5521, DOI 10.17487/RFC5521, April 1534 2009, . 1536 [RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of 1537 Objective Functions in the Path Computation Element 1538 Communication Protocol (PCEP)", RFC 5541, 1539 DOI 10.17487/RFC5541, June 2009, 1540 . 1542 [RFC6001] Papadimitriou, D., Vigoureux, M., Shiomoto, K., Brungard, 1543 D., and JL. Le Roux, "Generalized MPLS (GMPLS) Protocol 1544 Extensions for Multi-Layer and Multi-Region Networks (MLN/ 1545 MRN)", RFC 6001, DOI 10.17487/RFC6001, October 2010, 1546 . 1548 [RFC6003] Papadimitriou, D., "Ethernet Traffic Parameters", 1549 RFC 6003, DOI 10.17487/RFC6003, October 2010, 1550 . 1552 [RFC6205] Otani, T., Ed. and D. Li, Ed., "Generalized Labels for 1553 Lambda-Switch-Capable (LSC) Label Switching Routers", 1554 RFC 6205, DOI 10.17487/RFC6205, March 2011, 1555 . 1557 [RFC6387] Takacs, A., Berger, L., Caviglia, D., Fedyk, D., and J. 1558 Meuric, "GMPLS Asymmetric Bandwidth Bidirectional Label 1559 Switched Paths (LSPs)", RFC 6387, DOI 10.17487/RFC6387, 1560 September 2011, . 1562 [RFC7139] Zhang, F., Ed., Zhang, G., Belotti, S., Ceccarelli, D., 1563 and K. Pithewan, "GMPLS Signaling Extensions for Control 1564 of Evolving G.709 Optical Transport Networks", RFC 7139, 1565 DOI 10.17487/RFC7139, March 2014, 1566 . 1568 [RFC7792] Zhang, F., Zhang, X., Farrel, A., Gonzalez de Dios, O., 1569 and D. Ceccarelli, "RSVP-TE Signaling Extensions in 1570 Support of Flexi-Grid Dense Wavelength Division 1571 Multiplexing (DWDM) Networks", RFC 7792, 1572 DOI 10.17487/RFC7792, March 2016, 1573 . 1575 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 1576 "PCEPS: Usage of TLS to Provide a Secure Transport for the 1577 Path Computation Element Communication Protocol (PCEP)", 1578 RFC 8253, DOI 10.17487/RFC8253, October 2017, 1579 . 1581 [RFC8282] Oki, E., Takeda, T., Farrel, A., and F. Zhang, "Extensions 1582 to the Path Computation Element Communication Protocol 1583 (PCEP) for Inter-Layer MPLS and GMPLS Traffic 1584 Engineering", RFC 8282, DOI 10.17487/RFC8282, December 1585 2017, . 1587 9.2. Informative References 1589 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 1590 Element (PCE)-Based Architecture", RFC 4655, 1591 DOI 10.17487/RFC4655, August 2006, 1592 . 1594 [RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation 1595 Element (PCE) Communication Protocol Generic 1596 Requirements", RFC 4657, DOI 10.17487/RFC4657, September 1597 2006, . 1599 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 1600 Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, 1601 . 1603 [RFC6123] Farrel, A., "Inclusion of Manageability Sections in Path 1604 Computation Element (PCE) Working Group Drafts", RFC 6123, 1605 DOI 10.17487/RFC6123, February 2011, 1606 . 1608 [RFC7025] Otani, T., Ogaki, K., Caviglia, D., Zhang, F., and C. 1609 Margaria, "Requirements for GMPLS Applications of PCE", 1610 RFC 7025, DOI 10.17487/RFC7025, September 2013, 1611 . 1613 [RFC7449] Lee, Y., Ed., Bernstein, G., Ed., Martensson, J., Takeda, 1614 T., Tsuritani, T., and O. Gonzalez de Dios, "Path 1615 Computation Element Communication Protocol (PCEP) 1616 Requirements for Wavelength Switched Optical Network 1617 (WSON) Routing and Wavelength Assignment", RFC 7449, 1618 DOI 10.17487/RFC7449, February 2015, 1619 . 1621 Appendix A. LOAD-BALANCING Usage for SDH Virtual Concatenation 1623 For example a request for one co-signaled n x VC-4 TE-LSP will not 1624 use the LOAD-BALANCING. In case the VC-4 components can use 1625 different paths, the BANDWIDTH with object type TBA-2 will contain a 1626 traffic specification indicating the complete n x VC-4 traffic 1627 specification and the LOAD-BALANCING the minimum co-signaled VC-4. 1628 For an SDH network, a request to have a TE-LSP group with 10 VC-4 1629 containers, each path using at minimum 2 x VC-4 containers, can be 1630 represented with a BANDWIDTH object with OT=TBA-2, Bw Spec Type set 1631 to 4, the content of the Generalized Bandwidth is ST=6, RCC=0, NCC=0, 1632 NVC=10, MT=1. The LOAD-BALANCING, OT=TBA-4 with Bw Spec Type set to 1633 4, Max-LSP=5, Min Bandwidth Spec is (ST=6, RCC=0, NCC=0, NVC=2, 1634 MT=1). The PCE can respond with a response with maximum 5 paths, 1635 each of them having a BANDWIDTH OT=TBA-2 and Generalized Bandwidth 1636 matching the Min Bandwidth Spec from the LOAD-BALANCING object of the 1637 corresponding request. 1639 Authors' Addresses 1641 Cyril Margaria (editor) 1642 Juniper 1643 1133 Innovation Way, 1644 Sunnyvale, CA 94089 1645 USA 1647 Email: cmargaria@juniper.net 1649 Oscar Gonzalez de Dios (editor) 1650 Telefonica Investigacion y Desarrollo 1651 C/ Ronda de la Comunicacion 1652 Madrid 28050 1653 Spain 1655 Phone: +34 91 4833441 1656 Email: oscar.gonzalezdedios@telefonica.com 1658 Fatai Zhang (editor) 1659 Huawei Technologies 1660 F3-5-B R&D Center, Huawei Base 1661 Bantian, Longgang District 1662 Shenzhen 518129 1663 P.R.China 1665 Email: zhangfatai@huawei.com