idnits 2.17.1 draft-ietf-pce-flexible-grid-05.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 is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 22, 2021) is 1149 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PCE Working Group Y. Lee 2 Internet Draft Samsung 3 Intended status: Standard Track H. Zheng (Editor) 4 Expires: August 22, 2021 Huawei Technologies 5 R. Casellas 6 R. Vilalta 7 CTTC 8 D. Ceccarelli 9 F. Lazzeri 10 Ericsson 12 February 22, 2021 14 PCEP Extension for Flexible Grid Networks 16 draft-ietf-pce-flexible-grid-05 18 Abstract 20 This document provides the Path Computation Element Communication 21 Protocol (PCEP) extensions for the support of Routing and Spectrum 22 Assignment (RSA) in Flexible Grid networks. 24 Status of this Memo 26 This Internet-Draft is submitted to IETF in full conformance with 27 the provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six 35 months and may be updated, replaced, or obsoleted by other documents 36 at any time. It is inappropriate to use Internet-Drafts as 37 reference material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 45 This Internet-Draft will expire on August 22, 2021. 47 Copyright Notice 49 Copyright (c) 2021 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with 57 respect to this document. Code Components extracted from this 58 document must include Simplified BSD License text as described in 59 Section 4.e of the Trust Legal Provisions and are provided without 60 warranty as described in the Simplified BSD License. 62 Table of Contents 64 1. Terminology ................................................. 3 65 2. Requirements Language ....................................... 3 66 3. Introduction ................................................ 3 67 4. Spectrum Assignment (SA) Object ............................. 5 68 4.1. Frequency-Slot Selection TLV ........................... 7 69 4.2. Frequency-slot Restriction Constraint TLV .............. 8 70 4.2.1. Frequency-Slot Restriction Field ................. 10 71 5. Encoding of a RSA Path Reply ............................... 10 72 5.1. Error Indicator........................................ 11 73 5.2. NO-PATH Indicator ..................................... 11 74 6. Manageability Considerations ............................... 12 75 6.1. Control of Function and Policy ........................ 12 76 6.2. Information and Data Models ........................... 12 77 6.3. Verifying Correct Operation ........................... 13 78 6.4. Requirements on Other Protocols and Functional Components13 79 6.5. Impact on Network Operation ........................... 13 80 7. Implementation Status ...................................... 13 81 8. Security Considerations .................................... 14 82 9. IANA Considerations ........................................ 14 83 9.1. New PCEP Object........................................ 14 84 9.2. New PCEP TLV: Frequency Slot Selection TLV ............ 14 85 9.3. New PCEP TLV: Frequency Slot Restriction Constraint TLV. 15 86 9.4. New PCEP TLV: Spectrum Allocation TLV ................. 15 87 9.5. New No-Path Reasons ................................... 15 88 9.6. New Error-Types and Error-Values ...................... 16 89 9.7. New Error-Values for Existing Error Type (24) ......... 16 90 10. References ................................................ 16 91 10.1. Normative References ................................. 16 92 10.2. Informative References ............................... 17 93 11. Contributors .............................................. 18 94 Authors' Addresses ............................................ 19 96 1. Terminology 98 This document uses the terminology defined in [RFC4655], [RFC5440] 99 and [RFC7698]. 101 2. Requirements Language 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 105 "OPTIONAL" in this document are to be interpreted as described in 106 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 107 capitals, as shown here. 109 3. Introduction 111 [RFC4655] defines a Path Computation Element (PCE) based path 112 computation architecture and explains how a Path Computation Element 113 (PCE) may compute Label Switched Paths (LSP) in Multiprotocol Label 114 Switching Traffic Engineering (MPLS-TE) and Generalized MPLS (GMPLS) 115 networks at the request of Path Computation Clients (PCCs). A PCC 116 is said to be any network component that makes such a request and 117 may be, for instance, an Optical Switching Element within a 118 Wavelength Division Multiplexing (WDM) network. The PCE, itself, 119 can be located anywhere within the network, and may be within an 120 optical switching element, a Network Management System (NMS) or 121 Operational Support System (OSS), or may be an independent network 122 server. 124 The PCE communications Protocol (PCEP) is the communication protocol 125 used between a PCC and a PCE, and can also be used between 126 cooperating PCEs. [RFC4657] sets out the common protocol 127 requirements for PCEP. Additional application-specific requirements 128 for PCEP are deferred to separate documents. 130 [RFC8780] provides the PCEP extensions for the support of Routing 131 and Wavelength Assignment (RWA) in Wavelength Switched Optical 132 Networks (WSON) based on the requirements specified in [RFC6163] and 133 [RFC7449]. 135 To allow efficient allocation of optical spectral bandwidth for 136 systems that have high bit-rates, the International 137 Telecommunication Union Telecommunication Standardization Sector 138 (ITU-T) has extended its Recommendations [G.694.1] and [G.872] to 139 include a new Dense Wavelength Division Multiplexing (DWDM) grid by 140 defining a set of nominal central frequencies, channel spacings, and 141 the concept of the "frequency slot". In such an environment, a data- 142 plane connection is switched based on allocated, variable-sized 143 frequency ranges within the optical spectrum, creating what is known 144 as a flexible grid (flexi-grid). [RFC7698] provides Framework and 145 Requirements for GMPLS-Based Control of Flexi-Grid Dense Wavelength 146 Division Multiplexing (DWDM) Networks. 148 The terms "Routing and Spectrum Assignment" (RSA) is introduced in 149 [RFC7698] to refer to the process determines a route and frequency 150 slot for an LSP. Hence, when a route is computed, the spectrum 151 assignment process determines the central frequency and slot width. 152 The term "Spectrum Switched Optical Networks" is also introduced in 153 [RFC7698] to refer to a flexi-grid enabled DWDM network, which can 154 be controlled by a GMPLS or PCE control plane. 156 This document provides PCEP extensions to support RSA in Flexi-grid 157 networks. 159 Figure 2 shows one typical PCE based implementation, which is 160 referred to as the Combined Routing and Spectrum Assignment (R&SA) 161 [RFC7698]. With this architecture, the two processes of routing and 162 spectrum assignment are accessed via a single PCE. This architecture 163 is the base architecture from which the PCEP extensions are 164 specified in this document. 166 +----------------------------+ 167 +-----+ | +-------+ +--+ | 168 | | | |Routing| |SA| | 169 | PCC |<----->| +-------+ +--+ | 170 | | | | 171 +-----+ | PCE | 172 +----------------------------+ 174 Figure 1 Combined Process (R&SA) architecture 176 4. Spectrum Assignment (SA) Object 178 This document aligns with GMPLS extensions for PCEP [RFC8779] for 179 generic property such as label, label-set and label assignment 180 noting that frequency is a type of label. Frequency restrictions and 181 constraints are also formulated in terms of labels per [RFC7579]. 183 Spectrum allocation can be performed by the PCE by different means: 185 (a) By means of Explicit Label Control (ELC) where the PCE 186 allocates which label to use for each interface/node along the 187 path. 189 (b) By means of a Label Set where the PCE provides a range of 190 potential frequency slots to allocate by each node along the path. 192 Option (b) allows distributed spectrum allocation (performed during 193 signaling) to complete spectrum assignment. 195 Additionally, given a range of potential spectrums to allocate, a PC 196 Request SHOULD convey the heuristic / mechanism to the allocation. 198 The format Routing Backus-Naur Form (RBNF) [RFC5511] of a PCReq 199 message per [RFC5440] after incorporating the Spectrum Assignment 200 (SA) object is as follows: 202 ::= 204 [] 206 208 Where: 210 ::=[] 212 ::= 214 216 [ ] 218 [other optional objects...] 220 If the SA object is present in the request, it MUST be encoded after 221 the GENERALIZED ENDPOINTS object. 223 SA Object-Class is (TBD1) (To be assigned by IANA). 225 SA Object-Type is 1. 227 The format of the Spectrum Assignment (SA) object body is as 228 follows: 230 0 1 2 3 231 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 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | Reserved | Flags |M| 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | Frequency-Slot Selection TLV | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | Frequency-Slot Restriction Constraint TLV | 238 . . 239 . . 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 // Optional TLVs // 242 | | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 Figure 2 SA Object 247 o Reserved (16 bits) 249 o Flags (16 bits) 251 One Flag bit is allocated as follows: 253 M (Mode - 1 bit): M bit is used to indicate the mode of spectrum 254 assignment. When M bit is set to 1, this indicates that the 255 spectrum assigned by the PCE must be explicit. That is, the 256 selected way to convey the allocated spectrum is by means of 257 Explicit Label Control (ELC) [RFC4003] for each hop of a 258 computed LSP. Otherwise, the spectrum assigned by the PCE 259 needs not be explicit (i.e., it can be suggested in the form 260 of label set objects in the corresponding response, to allow 261 distributed SA. In such case, the PCE MUST return a Label Set 262 Field as described in Section 2.6 of [RFC7579] in the 263 response. See Section 5 of this document for the encoding 264 discussion of a Label Set Field in a PCRep message. 266 4.1. Frequency-Slot Selection TLV 268 The Frequency-Slot Selection TLV is used to indicate the frequency- 269 slot selection constraint in regard to the order of frequency-slot 270 assignment to be returned by the PCE. This TLV is only applied when 271 M bit is set in the SA Object specified in Section 4. This TLV 272 SHOULD NOT be present and MUST be ignored when the M bit is cleared. 274 The Frequency-Slot Selection sub-TLV value field is defined as: 276 0 1 2 3 277 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 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 |S| FSA Method | Reserved | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 Where: 283 Frequency-Slot Assignment (FSA) Method (7 bits): 285 0: unspecified (any); This does not constrain the SA method 286 used by a PCC This value is implied when the 287 Frequency-Slot Selection sub-TLV is absent. 289 1: First-Fit. All the feasible frequency slots are numbered3 290 (based on "n" parameter), and this SA method chooses the 291 available frequency-slot with the lowest index, where "n" is 292 the parameter in f = 193.1 THz + n x 0.00625 THz where 193.1 293 THz is the ITU-T "anchor frequency" and "n" is a positive 294 integer including 0 [RFC7698]. 296 2: Random. This SA method chooses a feasible frequency-slot 297 value of "n" randomly. 299 3-127: Unassigned. 301 S (Symmetry, 1 bit): This flag is only meaningful when the request 302 is for a bidirectional LSP (see [RFC5440]). 304 0 denotes requiring the same frequency-slot in both directions; 305 1 denotes that different spectrums on both directions are 306 allowed. 308 IANA is to allocate a new PCEP TLV type, Frequency-Slot Selection 309 TLV (TBD2) in the "PCEP TLV Type Indicators" subregistry 310 (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type- 311 indicators). 313 The processing rules for this TLV are as follows: 315 If a PCE does not support the attribute(s), its behavior is 316 specified below: 318 - S bit clear not supported: a PathErr MUST be generated with 319 The Error Code "Routing Problem" (24) with error sub-code 320 "Unsupported Frequency slot Selection Symmetry value" (TBD3). 322 - FSA method not supported: a PathErr MUST be generated with the 323 Error Code "Routing Problem" (24) with error sub-code 324 "Unsupported Frequency Slot Assignment value" (TBD4). 326 4.2. Frequency-slot Restriction Constraint TLV 328 For any request that contains a Frequency-slot assignment, the 329 requester (PCC) must be able to specify a restriction on the 330 frequency-slots to be used. This restriction is to be interpreted by 331 the PCE as a constraint on the tuning ability of the origination 332 laser transmitter or on any other maintenance related constraints. 334 The format of the Frequency-Slot Restriction Constraint TLV is as 335 follows: 337 ::= 339 ( 341 )... 343 Where 345 ::= [] 347 See Section 4.3.1 in [RFC8780] for the encoding of the Link 348 Identifiers Field. 350 IANA is to allocate a new PCEP TLV, the Frequency slot Restriction 351 Constraint TLV type (TBD5). This TLV MAY appear more than once to be 352 able to specify multiple restrictions. 354 The TLV data is defined as follows: 356 0 1 2 3 357 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 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | Action | Count | Reserved | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | Link Identifiers | 362 | . . . | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | Frequency Slot Restriction Field | 365 // . . . . // 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 Figure 3 spectrum Restriction Constraint TLV Encoding 370 o Action: 8 bits 372 0 - Inclusive List indicates that one or more link identifiers 373 are included in the Link Set. Each identifies a separate link 374 that is part of the set. 376 1 - Inclusive Range indicates that the Link Set defines a 377 range of links. It contains two link identifiers. The first 378 identifier indicates the start of the range (inclusive). The 379 second identifier indicates the end of the range (inclusive). 380 All links with numeric values between the bounds are 381 considered to be part of the set. A value of zero in either 382 position indicates that there is no bound on the corresponding 383 portion of the range. Note that the Action field can be set to 384 0 when unnumbered link identifier is used. 386 o Count: The number of the link identifiers (8 bits) 388 Note that a PCC MAY add a frequency slot restriction that applies to 389 all links by setting the Count field to zero and specifying just a 390 set of frequency slots. 392 Note that all link identifiers in the same list must be of the same 393 type. 395 o Reserved: Reserved for future use (16 bits) 397 o Link Identifiers: Identifies each link ID for which restriction 398 is applied. The length is dependent on the link format and the Count 399 field. See Section 4.3.1 in [RFC8780] for Link Identifier encoding. 401 4.2.1. Frequency-Slot Restriction Field 403 The Frequency-Slot Restriction Field of the Frequency slot 404 restriction TLV is encoded as defined in section 4.2 of [RFC8363]. 406 5. Encoding of a RSA Path Reply 408 This section provides the encoding of a RSA Path Reply, in the 409 PCRep/PCUpd message, for frequency slot allocation as discussed in 410 Section 4. Spectrum Allocation TLV IANA is to allocate a new PCEP 411 TLV type, the Spectrum Allocation TLV type (TBD6). The TLV data is 412 defined as follows: 414 0 1 2 3 415 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 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | Type | Length |M| 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | Link Identifier | 420 | . . . | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | Allocated Spectrum(s) | 423 // . . . . // 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 Figure 4 Spectrum Allocation TLV Encoding 428 o Type (16 bits): The type of the TLV. 430 o Length (15 bits): The length of the TLV including the Type and 431 Length fields. 433 o M (Mode): 1 bit 434 - 0 indicates the allocation is under Explicit Label Control. 436 - 1 indicates the allocation is expressed in Label Sets. 438 Note that all link identifiers in the same list must be of the same 439 type. 440 o Link Identifier (variable): Identifies the interface to which 441 assignment spectrum(s) is applied. See Section 3.3 for Link 442 Identifier encoding. 444 o Allocated Spectrum(s) (variable): Indicates the allocated 445 spectrum(s) to the link identifier. See Section 3.3.1 for encoding 446 details. 448 This TLV is encoded as an attributes TLV, per [RFC5420], which is 449 carried in the ERO LSP Attribute Subobjects per [RFC7570]. 451 5.1. Error Indicator 453 To indicate errors associated with the RSA request, a new Error Type 454 (TDB) and subsequent error-values are defined as follows for 455 inclusion in the PCEP-ERROR Object: 457 A new Error-Type (TBD7) and subsequent error-values are defined as 458 follows: 460 Error-Type=TBD7; Error-value=1: if a PCE receives a RSA 461 request and the PCE is not capable of processing the request 462 due to insufficient memory, the PCE MUST send a PCErr message 463 with a PCEP-ERROR Object (Error-Type=TDB) and an Error- 464 value(Error-value=1). The PCE stops processing the request. 465 The corresponding RSA request MUST be cancelled at the PCC. 467 Error-Type=TBD7; Error-value=2: if a PCE receives a RSA 468 request and the PCE is not capable of RSA computation, the PCE 469 MUST send a PCErr message with a PCEP-ERROR Object (Error- 470 Type=TDB) and an Error-value (Error-value=2). The PCE stops 471 processing the request. The corresponding RSA computation 472 MUST be cancelled at the PCC. 474 5.2. NO-PATH Indicator 476 To communicate the reason(s) for not being able to find RSA for the 477 path request, the NO-PATH object can be used in the corresponding 478 response. The format of the NO-PATH object body is defined in 480 [RFC5440]. The object may contain a NO-PATH-VECTOR TLV to provide 481 additional information about why a path computation has failed. 483 One new bit flag is defined to be carried in the Flags field in the 484 NO-PATH-VECTOR TLV carried in the NO-PATH Object. 486 Bit TBD8: When set, the PCE indicates no feasible route was 487 found that meets all the constraints (e.g., spectrum 488 restriction, etc.) associated with RSA. 490 6. Manageability Considerations 492 Manageability of flexi-grid Routing and Spectrum Assignment (RSA) 493 with PCE must address the following considerations: 495 6.1. Control of Function and Policy 497 In addition to the parameters already listed in Section 8.1 of 498 [RFC5440], a PCEP implementation SHOULD allow configuring the 499 following PCEP session parameters on a PCC: 501 The ability to send a Flexi-Grid RSA request. 503 In addition to the parameters already listed in Section 8.1 of 504 [RFC5440], a PCEP implementation SHOULD allow configuring the 505 following PCEP session parameters on a PCE: 507 The support for Flexi-Grid RSA. 509 A set of Flexi-Grid RSA specific policies (authorized sender, 510 request rate limiter, etc). 512 These parameters may be configured as default parameters for any 513 PCEP session the PCEP speaker participates in, or may apply to a 514 specific session with a given PCEP peer or a specific group of 515 sessions with a specific group of PCEP peers. 517 6.2. Information and Data Models 519 Extensions to the PCEP YANG module may include to cover the Flexi- 520 Grid RSA information introduced in this document. Liveness Detection 521 and Monitoring Mechanisms defined in this document do not imply any 522 new liveness detection and monitoring requirements in addition to 523 those already listed in section 8.3 of [RFC5440]. 525 6.3. Verifying Correct Operation 527 Mechanisms defined in this document do not imply any new 528 verification requirements in addition to those already listed in 529 section 8.4 of [RFC5440]. 531 6.4. Requirements on Other Protocols and Functional Components 533 The PCE Discovery mechanisms ([RFC5089] and [RFC5088]) may be used 534 to advertise Flexi-Grid RSA path computation capabilities to PCCs. 535 This draft has requirements on other protocols (ERO objects, etc. 536 which are under TEAS or CCAMP.) 538 6.5. Impact on Network Operation 540 Mechanisms defined in this document do not imply any new network 541 operation requirements in addition to those already listed in 542 section 8.6 of [RFC5440]. 544 7. Implementation Status 546 [NOTE TO RFC EDITOR: This whole section and the reference to 547 [RFC7942] is to be removed before publication as an RFC] 549 This section records the status of known implementations of the 550 protocol defined by this specification at the time of posting of 551 this Internet-Draft, and is based on a proposal described in 552 [RFC7942]. 554 The description of implementations in this section is intended to 555 assist the IETF in its decision processes in progressing drafts to 556 RFCs. Please note that the listing of any individual implementation 557 here does not imply endorsement by the IETF. Furthermore, no effort 558 has been spent to verify the information presented here that was 559 supplied by IETF contributors. This is not intended as, and must 560 not be construed to be, a catalog of available implementations or 561 their features. Readers are advised to note that other 562 implementations may exist. 564 According to [RFC7942], "this will allow reviewers and working 565 groups to assign due consideration to documents that have the 566 benefit of running code, which may serve as evidence of valuable 567 experimentation and feedback that have made the implemented 568 protocols more mature. It is up to the individual working groups to 569 use this information as they see fit". 571 At the time of posting the -05 version of this document, there are 572 no known implementations of this mechanism. It is believed that two 573 vendors are considering prototype implementations, but these plans 574 are too vague to make any further assertions. 576 8. Security Considerations 578 This document has no requirement for a change to the security models 579 within PCEP. However, the additional information distributed in 580 order to address the RSA problem represents a disclosure of network 581 capabilities that an operator may wish to keep private. 582 Consideration should be given to securing this information. 584 9. IANA Considerations 586 IANA is requested to make allocations from the sub-registries as 587 described in the following sections. 589 9.1. New PCEP Object 591 As described in Section 4.1, a new PCEP Object is defined to carry 592 frequency-slot assignment related constraints. IANA is to allocate 593 the following from "PCEP Objects" sub-registry 594 (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-objects): 596 Object Class Name Object Reference 597 Value Type 598 --------------------------------------------------------- 600 TBD1 SA 1: Spectrum Assignment [This.I-D] 602 9.2. New PCEP TLV: Frequency Slot Selection TLV 604 As described in Sections 4.2, a new PCEP TLV is defined to indicate 605 spectrum selection constraints. IANA is to allocate this new TLV 606 from the "PCEP TLV Type Indicators" subregistry 607 (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type- 608 indicators). 610 Value Description Reference 611 --------------------------------------------------------- 612 TBD2 Spectrum Selection [This.I-D] 614 9.3. New PCEP TLV: Frequency Slot Restriction Constraint TLV 616 As described in Section 4.3, a new PCEP TLV is defined to indicate 617 wavelength restriction constraints. IANA is to allocate this new TLV 618 from the "PCEP TLV Type Indicators" subregistry 619 (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type- 620 indicators). 622 Value Description Reference 623 --------------------------------------------------------- 624 TBD5 Frequency Slot Restriction [This.I-D] 625 Constraint 627 9.4. New PCEP TLV: Spectrum Allocation TLV 629 As described in Section 5, a new PCEP TLV is defined to indicate the 630 allocation of freq-slots(s) by the PCE in response to a request by 631 the PCC. IANA is to allocate this new TLV from the "PCEP TLV Type 632 Indicators" subregistry 633 (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type- 634 indicators). 636 Value Description Reference 637 --------------------------------------------------------- 638 TBD6 Spectrum Allocation [This.I-D] 640 9.5. New No-Path Reasons 642 As described in Section 4.3, a new bit flag are defined to be 643 carried in the Flags field in the NO-PATH-VECTOR TLV carried in the 644 NO-PATH Object. This flag, when set, indicates that no feasible 645 route was found that meets all the RSA constraints (e.g., spectrum 646 restriction, signal compatibility, etc.) associated with a RSA path 647 computation request. 649 IANA is to allocate this new bit flag from the "PCEP NO-PATH-VECTOR 650 TLV Flag Field" subregistry 651 (http://www.iana.org/assignments/pcep/pcep.xhtml#no-path-vector- 652 tlv). 654 Bit Description Reference 655 ----------------------------------------------------- 656 TBD8 No RSA constraints met [This.I-D] 658 9.6. New Error-Types and Error-Values 660 As described in Section 5.1, new PCEP error codes are defined for 661 WSON RWA errors. IANA is to allocate from the ""PCEP-ERROR Object 662 Error Types and Values" sub-registry 663 (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-error-object). 665 Error- Meaning Error-Value Reference 666 Type 667 --------------------------------------------------------------- 668 TBD7 Flexi-Grid RSA Error 1: Insufficient [This.I-D] 669 Memory 671 2: RSA computation [This.I-D] 672 Not supported 674 9.7. New Error-Values for Existing Error Type (24) 676 As discussed in Section 4.1, two new PathErr values for the Existing 677 Error Type (24) are to be allocated: 679 Meaning Error-Value Reference 681 --------------------------------------------------------------- 682 Unsupported Frequency slot 683 Selection Symmetry value TBD3 [This.I-D] 685 Unsupported Frequency Slot 686 Assignment value TBD4 [This.I-D] 688 10. References 690 10.1. Normative References 692 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 693 Requirement Levels", BCP 14, RFC 2119, March 1997. 695 [RFC4003] Berger, L., "GMPLS Signaling Procedure for Egress 696 Control", RFC 4003, February 2005. 698 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 699 Element (PCE) communication Protocol", RFC 5440, March 700 2009. 702 [RFC5511] A. Farrel, "Routing Backus-Naur Form (RBNF): A Syntax Used 703 to Form Encoding Rules in Various Routing Protocol 704 Specifications", RFC 5511, April 2009. 706 [RFC5088] Le Roux, JL, JP. Vasseur, Y. Ikejiri, and R. Zhang, "OSPF 707 Protocol Extensions for Path Computation Element (PCE) 708 Discovery," RFC 5088, January 2008. 710 [RFC5089] Le Roux, JL, JP. Vasseur, Y. Ikejiri, and R. Zhang, "IS-IS 711 Protocol Extensions for Path Computation Element (PCE) 712 Discovery," RFC 5089, January 2008. 714 [RFC8174] B. Leiba, "Ambiguity of Uppercase vs Lowercase in RFC 2119 715 Key Words", RFC 8174, May 2017. 717 10.2. Informative References 719 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 720 Element (PCE)-Based Architecture", RFC 4655, August 2006. 722 [RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE) 723 Communication Protocol Generic Requirements", RFC 4657, 724 September 2006. 726 [RFC5420] Farrel, A. "Encoding of Attributes for MPLS LSP 727 Establishment Using Resource Reservation Protocol Traffic 728 Engineering (RSVP-TE)", RFC 5420, February 2009. 730 [RFC6163] Lee, Y. and Bernstein, G. (Editors), and W. Imajuku, 731 "Framework for GMPLS and PCE Control of Wavelength 732 Switched Optical Networks", RFC 6163, March 2011. 734 [RFC7449] Lee, Y., et. al., "PCEP Requirements for WSON Routing and 735 Wavelength Assignment", RFC 7449, February 2015. 737 [RFC7570] Margaria, et al., "Label Switched Path (LSP) Attribute in 738 the Explicit Route Object (ERO)", RFC 7570, July 2015. 740 [RFC7579] Bernstein and Lee, "General Network Element Constraint 741 Encoding for GMPLS Controlled Networks", RFC 7579, June 742 2015. 744 [RFC7698] O. Gonzalez de Dios, R. Casellas, editors, "Framework and 745 Requirements for GMPLS-Based Control of Flexi-Grid Dense 746 Wavelength Division Multiplexing (DWDM) Networks", RFC 747 7698, November 2015. 749 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of 750 Running Code: The Implementation Status Section", BCP 205, 751 RFC 7942, July 2016, 753 [RFC8363] X. Zhang, H. Zheng, R. Casellas, O. Gonzalez de Dios, D. 754 Ceccarelli, "GMPLS OSPF-TE Extensions in Support of Flexi- 755 Grid Dense Wavelength Division Multiplexing (DWDM) 756 Networks", RFC8363, May 2018. 758 [RFC8779] Margaria, et al., "PCEP extensions for GMPLS", RFC 8779, 759 July 2020. 761 [RFC8780] Y. Lee (Ed.), and R. Casellas (Ed.), "PCEP Extension for 762 WSON Routing and Wavelength Assignment", RFC8780, July 2020. 764 [G.694.1] "Spectral grids for WDM applications: DWDM frequency 765 grid", ITU-T G.694.1, February 2012. 767 [G.872] "Architecture of optical transport networks", ITU-T G.872, 768 January 2017. 770 11. Contributors 771 Authors' Addresses 773 Young Lee 774 Samsung 775 Email: younglee.tx@gmail.com 777 Haomian Zheng 778 Huawei Technologies 779 Email: zhenghaomian@huawei.com 781 Ramon Casellas 782 CTTC 783 Av. Carl Friedrich Gauss n7 784 Castelldefels, Barcelona 08860 785 Spain 787 Email: ramon.casellas@cttc.es 789 Ricard Vilalta 790 CTTC 791 Email: ricard.vilalta@cttc.es 793 Daniele Ceccarelli 794 Ericsson AB 795 Gronlandsgatan 21 796 Kista - Stockholm 797 Email: daniele.ceccarelli@ericsson.com 799 Francesco Lazzeri 800 Ericsson 801 Via Melen 77 802 Genova - Italy 803 Email: francesco.lazzeri@ericsson.com