idnits 2.17.1 draft-ietf-pce-flexible-grid-01.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 -- The document date (March 11, 2019) is 1844 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) == Unused Reference: 'RFC3209' is defined on line 713, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 4655 ** Downref: Normative reference to an Informational RFC: RFC 4657 ** Downref: Normative reference to an Informational RFC: RFC 6163 ** Downref: Normative reference to an Informational RFC: RFC 7449 ** Downref: Normative reference to an Informational RFC: RFC 7698 Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PCE Working Group Y. Lee (Editor) 2 Internet Draft H. Zheng 3 Intended status: Standard Track Huawei 4 Expires: September 12, 2019 5 R. Casellas 6 R. Vilalta 7 CTTC 9 D. Ceccarelli 10 F. Lazzeri 11 Ericsson 13 March 11, 2019 15 PCEP Extension for Flexible Grid Networks 17 draft-ietf-pce-flexible-grid-01 19 Abstract 21 This document provides the Path Computation Element Communication 22 Protocol (PCEP) extensions for the support of Routing and Spectrum 23 Assignment (RSA) in Flexible Grid networks. 25 Status of this Memo 27 This Internet-Draft is submitted to IETF in full conformance with 28 the provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet- 33 Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six 36 months and may be updated, replaced, or obsoleted by other documents 37 at any time. It is inappropriate to use Internet-Drafts as 38 reference material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/ietf/1id-abstracts.txt 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html. 46 This Internet-Draft will expire on September 12, 2019. 48 Copyright Notice 50 Copyright (c) 2019 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with 58 respect to this document. Code Components extracted from this 59 document must include Simplified BSD License text as described in 60 Section 4.e of the Trust Legal Provisions and are provided without 61 warranty as described in the Simplified BSD License. 63 Table of Contents 65 1. Terminology....................................................3 66 2. Requirements Language..........................................3 67 3. Introduction...................................................3 68 4. Spectrum Assignment (SA) Object................................4 69 4.1. Frequency-Slot Selection TLV..............................6 70 4.2. Frequency-slot Restriction Constraint TLV.................8 71 4.2.1. Frequency-Slot Restriction Field....................10 72 5. Encoding of a RSA Path Reply..................................10 73 5.1. Error Indicator..........................................12 74 5.2. NO-PATH Indicator........................................12 75 6. Manageability Considerations..................................13 76 6.1. Control of Function and Policy...........................13 77 6.2. Information and Data Models..............................13 78 6.3. Verifying Correct Operation..............................13 79 6.4. Requirements on Other Protocols and Functional Components14 80 6.5. Impact on Network Operation..............................14 81 7. Security Considerations.......................................14 82 8. IANA Considerations...........................................14 83 8.1. New PCEP Object..........................................14 84 8.2. New PCEP TLV: Frequency Slot Selection TLV...............15 85 8.3. New PCEP TLV: Frequency Slot Restriction Constraint TLV..15 86 8.4. New PCEP TLV: Spectrum Allocation TLV....................15 87 8.5. New No-Path Reasons......................................16 88 8.6. New Error-Types and Error-Values.........................16 89 9. References....................................................17 90 9.1. Normative References.....................................17 91 9.2. Informative References...................................18 92 10. Contributors.................................................19 93 Authors' Addresses...............................................20 95 1. Terminology 97 This document uses the terminology defined in [RFC4655], [RFC5440] 98 and [RFC7698]. 100 2. Requirements Language 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 104 "OPTIONAL" in this document are to be interpreted as described in 105 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 106 capitals, as shown here. 108 3. Introduction 110 [RFC4655] defines a Path Computation Element (PCE) based path 111 computation architecture and explains how a Path Computation Element 112 (PCE) may compute Label Switched Paths (LSP) in Multiprotocol Label 113 Switching Traffic Engineering (MPLS-TE) and Generalized MPLS (GMPLS) 114 networks at the request of Path Computation Clients (PCCs). A PCC 115 is said to be any network component that makes such a request and 116 may be, for instance, an Optical Switching Element within a 117 Wavelength Division Multiplexing (WDM) network. The PCE, itself, 118 can be located anywhere within the network, and may be within an 119 optical switching element, a Network Management System (NMS) or 120 Operational Support System (OSS), or may be an independent network 121 server. 123 The PCE communications Protocol (PCEP) is the communication protocol 124 used between a PCC and a PCE, and may also be used between 125 cooperating PCEs. [RFC4657] sets out the common protocol 126 requirements for PCEP. Additional application-specific requirements 127 for PCEP are deferred to separate documents. 129 [PCEP-WSON] provides the PCEP extensions for the support of Routing 130 and Wavelength Assignment (RWA) in Wavelength Switched Optical 131 Networks (WSON) based on the requirements specified in [RFC6163] and 132 [RFC7449]. 134 To allow efficient allocation of optical spectral bandwidth for 135 systems that have high bit-rates, the International 136 Telecommunication Union Telecommunication Standardization Sector 137 (ITU-T) has extended its Recommendations [G.694.1] and [G.872] to 138 include a new Dense Wavelength Division Multiplexing (DWDM) grid by 139 defining a set of nominal central frequencies, channel spacings, and 140 the concept of the "frequency slot". In such an environment, a data- 141 plane connection is switched based on allocated, variable-sized 142 frequency ranges within the optical spectrum, creating what is known 143 as a flexible grid (flexi-grid). [RFC7698] provides Framework and 144 Requirements for GMPLS-Based Control of Flexi-Grid Dense Wavelength 145 Division Multiplexing (DWDM) Networks. 147 The terms "Routing and Spectrum Assignment" (RSA) is introduced in 148 [RFC7698] to refer to the process determines a route and frequency 149 slot for an LSP. Hence, when a route is computed, the spectrum 150 assignment process determines the central frequency and slot width. 151 The term "Spectrum Switched Optical Networks" is also introduced in 152 [RFC7698] to refer to a flexi-grid enabled DWDM network that is 153 controlled by a GMPLS or PCE control plane. 155 This document provides PCEP extensions to support RSA in SSONs. 157 Figure 2 shows one typical PCE based implementation, which is 158 referred to as the Combined Routing and Spectrum Assignment (R&SA) 159 [RFC7698]. With this architecture, the two processes of routing and 160 spectrum assignment are accessed via a single PCE. This architecture 161 is the base architecture from which the PCEP extensions are 162 specified in this document. 164 +----------------------------+ 165 +-----+ | +-------+ +--+ | 166 | | | |Routing| |SA| | 167 | PCC |<----->| +-------+ +--+ | 168 | | | | 169 +-----+ | PCE | 170 +----------------------------+ 172 Figure 1 Combined Process (R&SA) architecture 174 4. Spectrum Assignment (SA) Object 176 This document aligns with GMPLS extensions for PCEP [PCEP-GMPLS] for 177 generic property such as label, label-set and label assignment 178 noting that frequency is a type of label. Frequency restrictions and 179 constraints are also formulated in terms of labels per [RFC7579]. 181 Spectrum allocation can be performed by the PCE by different means: 183 (a) By means of Explicit Label Control (ELC) where the PCE 184 allocates which label to use for each interface/node along the 185 path. 187 (b) By means of a Label Set where the PCE provides a range of 188 potential frequency slots to allocate by each node along the path. 190 Option (b) allows distributed spectrum allocation (performed during 191 signaling) to complete spectrum assignment. 193 Additionally, given a range of potential spectrums to allocate, a PC 194 Request SHOULD convey the heuristic / mechanism to the allocation. 196 The format Routing Backus-Naur Form (RBNF) [RFC5511] of a PCReq 197 message per [RFC5440] after incorporating the Spectrum Assignment 198 (SA) object is as follows: 200 ::= 202 [] 204 206 Where: 208 ::=[] 210 ::= 212 214 [ ] 216 [other optional objects...] 218 If the SA object is present in the request, it MUST be encoded after 219 the GENERALIZED ENDPOINTS object. 221 SA Object-Class is (TBD1) (To be assigned by IANA). 223 SA Object-Type is 1. 225 The format of the Spectrum Assignment (SA) object body is as 226 follows: 228 0 1 2 3 229 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 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Reserved | Flags |M| 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | Frequency-Slot Selection TLV | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | Frequency-Slot Restriction Constraint TLV | 236 . . 237 . . 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 // Optional TLVs // 240 | | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 Figure 2 SA Object 245 o Reserved (16 bits) 247 o Flags (16 bits) 249 One Flag bit is allocated as follows: 251 . M (Mode - 1 bit): M bit is used to indicate the mode of 252 spectrum assignment. When M bit is set to 1, this indicates 253 that the spectrum assigned by the PCE must be explicit. That 254 is, the selected way to convey the allocated spectrum is by 255 means of Explicit Label Control (ELC) [RFC4003] for each hop of 256 a computed LSP. Otherwise, the spectrum assigned by the PCE 257 needs not be explicit (i.e., it can be suggested in the form of 258 label set objects in the corresponding response, to allow 259 distributed SA. In such case, the PCE MUST return a Label Set 260 Field as described in Section 2.6 of [RFC7579] in the response. 261 See Section 5 of this document for the encoding discussion of a 262 Label Set Field in a PCRep message. 264 4.1. Frequency-Slot Selection TLV 266 The Frequency-Slot Selection TLV is used to indicate the frequency- 267 slot selection constraint in regard to the order of frequency-slot 268 assignment to be returned by the PCE. This TLV is only applied when 269 M bit is set in the SA Object specified in Section 4. This TLV 270 SHOULD NOT be present and MUST be ignored when the M bit is cleared. 272 The Frequency-Slot Selection sub-TLV value field is defined as: 274 0 1 2 3 275 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 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 |S| FSA Method | Reserved | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 Where: 281 Frequency-Slot Assignment (FSA) Method (7 bits): 283 0: unspecified (any); This does not constrain the SA method 284 used by a PCC This value is implied when the 285 Frequency-Slot Selection sub-TLV is absent. 287 1: First-Fit. All the feasible frequency slots are numbered 288 (based on "n" parameter), and this SA method chooses the 289 available frequency-slot with the lowest index, where "n" is 290 the parameter in f = 193.1 THz + n x 0.00625 THz where 193.1 291 THz is the ITU-T "anchor frequency" and "n" is a positive 292 integer including 0 [RFC7698]. 294 2: Random. This SA method chooses a feasible frequency-slot 295 value of "n" randomly. 297 3-127: Unassigned. 299 S (Symmetry, 1 bit): This flag is only meaningful when the request 300 is for a bidirectional LSP (see [RFC5440]). 302 0 denotes requiring the same frequency-slot in both directions; 303 1 denotes that different spectrums on both directions are 304 allowed. 306 IANA is to allocate a new PCEP TLV type, Frequency-Slot Selection 307 TLV (TBD2) in the "PCEP TLV Type Indicators" subregistry 308 (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type- 309 indicators). 311 The processing rules for this TLV are as follows: 313 If a PCE does not support the attribute(s), its 314 behavior is specified below: 316 - S bit clear not supported: a PathErr MUST be generated with 317 The Error Code "Routing Problem" (24) with error sub-code 318 "Unsupported Frequency slot Selection Symmetry value" (TBD3). 320 - FSA method not supported: a PathErr MUST be generated with the 321 Error Code "Routing Problem" (24) with error sub-code 322 "Unsupported Frequency Slot Assignment value" (TBD4). 324 4.2. Frequency-slot Restriction Constraint TLV 326 For any request that contains a Frequency-slot assignment, the 327 requester (PCC) must be able to specify a restriction on the 328 frequency-slots to be used. This restriction is to be interpreted by 329 the PCE as a constraint on the tuning ability of the origination 330 laser transmitter or on any other maintenance related constraints. 332 The format of the Frequency-Slot Restriction Constraint TLV is as 333 follows: 335 ::= 337 ( 339 )... 341 Where 343 ::= [] 345 See Section 4.3.1 in [PCEP-WSON] for the encoding of the Link 346 Identifiers Field. 348 IANA is to allocate a new PCEP TLV, the Frequency slot Restriction 349 Constraint TLV type (TBD5). This TLV MAY appear more than once to be 350 able to specify multiple restrictions. 352 The TLV data is defined as follows: 354 0 1 2 3 355 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 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | Action | Count | Reserved | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | Link Identifiers | 360 | . . . | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | Frequency Slot Restriction Field | 363 // . . . . // 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 Figure 3 spectrum Restriction Constraint TLV Encoding 368 o Action: 8 bits 370 . 0 - Inclusive List indicates that one or more link identifiers 371 are included in the Link Set. Each identifies a separate link 372 that is part of the set. 374 . 1 - Inclusive Range indicates that the Link Set defines a 375 range of links. It contains two link identifiers. The first 376 identifier indicates the start of the range (inclusive). The 377 second identifier indicates the end of the range (inclusive). 378 All links with numeric values between the bounds are 379 considered to be part of the set. A value of zero in either 380 position indicates that there is no bound on the corresponding 381 portion of the range. Note that the Action field can be set to 382 0 when unnumbered link identifier is used. 384 o Count: The number of the link identifiers (8 bits) 386 Note that a PCC MAY add a frequency slot restriction that applies to 387 all links by setting the Count field to zero and specifying just a 388 set of frequency slots. 390 Note that all link identifiers in the same list must be of the same 391 type. 393 o Reserved: Reserved for future use (16 bits) 395 o Link Identifiers: Identifies each link ID for which restriction 396 is applied. The length is dependent on the link format and the Count 397 field. See Section 4.3.1 in [PCEP-WSON] for Link Identifier 398 encoding. 400 4.2.1. Frequency-Slot Restriction Field 402 The Frequency-Slot Restriction Field of the Frequency slot 403 restriction TLV is encoded as defined in 404 https://tools.ietf.org/html/draft-ietf-ccamp-flexible-grid-ospf-ext- 405 09#section-4.2. 407 5. Encoding of a RSA Path Reply 409 This section provides the encoding of a RSA Path Reply for frequency 410 slot allocation as discussed in Section 4. Spectrum Allocation TLV 412 IANA is to allocate a new PCEP TLV type, the Spectrum Allocation TLV 413 type (TBD6). The TLV data is defined as follows: 415 0 1 2 3 416 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 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | Type | Length |M| 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | Link Identifier | 421 | . . . | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | Allocated Spectrum(s) | 424 // . . . . // 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 Figure 4 Spectrum Allocation TLV Encoding 429 o Type (16 bits): The type of the TLV. 431 o Length (15 bits): The length of the TLV including the Type and 432 Length fields. 434 o M (Mode): 1 bit 436 - 0 indicates the allocation is under Explicit Label Control. 438 - 1 indicates the allocation is expressed in Label Sets. 440 Note that all link identifiers in the same list must be of the same 441 type. 443 o Link Identifier (variable): Identifies the interface to which 444 assignment spectrum(s) is applied. See Section 3.3 for Link 445 Identifier encoding. 447 o Allocated Spectrum(s) (variable): Indicates the allocated 448 spectrum(s) to the link identifier. See Section 3.3.1 for encoding 449 details. 451 This TLV is encoded as an attributes TLV, per [RFC5420], which is 452 carried in the ERO LSP Attribute Subobjects per [RFC7570]. 454 5.1. Error Indicator 456 To indicate errors associated with the RSA request, a new Error Type 457 (TDB) and subsequent error-values are defined as follows for 458 inclusion in the PCEP-ERROR Object: 460 A new Error-Type (TBD7) and subsequent error-values are defined as 461 follows: 463 . Error-Type=TBD7; Error-value=1: if a PCE receives a RSA 464 request and the PCE is not capable of processing the request 465 due to insufficient memory, the PCE MUST send a PCErr message 466 with a PCEP-ERROR Object (Error-Type=TDB) and an Error- 467 value(Error-value=1). The PCE stops processing the request. 468 The corresponding RSA request MUST be cancelled at the PCC. 470 . Error-Type=TBD7; Error-value=2: if a PCE receives a RSA 471 request and the PCE is not capable of RSA computation, the PCE 472 MUST send a PCErr message with a PCEP-ERROR Object (Error- 473 Type=TDB) and an Error-value (Error-value=2). The PCE stops 474 processing the request. The corresponding RSA computation 475 MUST be cancelled at the PCC. 477 5.2. NO-PATH Indicator 479 To communicate the reason(s) for not being able to find RSA for the 480 path request, the NO-PATH object can be used in the corresponding 481 response. The format of the NO-PATH object body is defined in 482 [RFC5440]. The object may contain a NO-PATH-VECTOR TLV to provide 483 additional information about why a path computation has failed. 485 One new bit flag is defined to be carried in the Flags field in the 486 NO-PATH-VECTOR TLV carried in the NO-PATH Object. 488 . Bit TBD8: When set, the PCE indicates no feasible route was 489 found that meets all the constraints (e.g., spectrum 490 restriction, etc.) associated with RSA. 492 6. Manageability Considerations 494 Manageability of SSON Routing and Spectrum Assignment (RSA) with PCE 495 must address the following considerations: 497 6.1. Control of Function and Policy 499 In addition to the parameters already listed in Section 8.1 of 500 [RFC5440], a PCEP implementation SHOULD allow configuring the 501 following PCEP session parameters on a PCC: 503 . The ability to send a Flexi-Grid RSA request. 505 In addition to the parameters already listed in Section 8.1 of 506 [RFC5440], a PCEP implementation SHOULD allow configuring the 507 following PCEP session parameters on a PCE: 509 . The support for Flexi-Grid RSA . 511 . A set of Flexi-Grid RSA specific policies (authorized sender, 512 request rate limiter, etc). 514 These parameters may be configured as default parameters for any 515 PCEP session the PCEP speaker participates in, or may apply to a 516 specific session with a given PCEP peer or a specific group of 517 sessions with a specific group of PCEP peers. 519 6.2. Information and Data Models 521 Extensions to the PCEP YANG module may include to cover the Flexi- 522 Grid RSA information introduced in this document. Liveness Detection 523 and Monitoring 525 Mechanisms defined in this document do not imply any new liveness 526 detection and monitoring requirements in addition to those already 527 listed in section 8.3 of [RFC5440]. 529 6.3. Verifying Correct Operation 531 Mechanisms defined in this document do not imply any new 532 verification requirements in addition to those already listed in 533 section 8.4 of [RFC5440] 535 6.4. Requirements on Other Protocols and Functional Components 537 The PCE Discovery mechanisms ([RFC5089] and [RFC5088]) may be used 538 to advertise Flexi-Grid RSA path computation capabilities to PCCs. 539 This draft has requirements on other protocols (ERO objects, etc. 540 which are under TEAS or CCAMP.) 542 6.5. Impact on Network Operation 544 Mechanisms defined in this document do not imply any new network 545 operation requirements in addition to those already listed in 546 section 8.6 of [RFC5440]. 548 7. Security Considerations 550 This document has no requirement for a change to the security models 551 within PCEP. However, the additional information distributed in 552 order to address the RSA problem represents a disclosure of network 553 capabilities that an operator may wish to keep private. 554 Consideration should be given to securing this information. 556 8. IANA Considerations 558 IANA is requested to make allocations from the sub-registries as 559 described in the following sections. 561 8.1. New PCEP Object 563 As described in Section 4.1, a new PCEP Object is defined to carry 564 frequency-slot assignment related constraints. IANA is to allocate 565 the following from "PCEP Objects" sub-registry 566 (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-objects): 568 Object Class Name Object Reference 569 Value Type 570 --------------------------------------------------------- 571 TBD1 SA 1: Spectrum Assignment [This.I-D] 573 8.2. New PCEP TLV: Frequency Slot Selection TLV 575 As described in Sections 4.2, a new PCEP TLV is defined to indicate 576 spectrum selection constraints. IANA is to allocate this new TLV 577 from the "PCEP TLV Type Indicators" subregistry 578 (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type- 579 indicators). 581 Value Description Reference 582 --------------------------------------------------------- 583 TBD2 Spectrum Selection [This.I-D] 585 8.3. New PCEP TLV: Frequency Slot Restriction Constraint TLV 587 As described in Section 4.3, a new PCEP TLV is defined to indicate 588 wavelength restriction constraints. IANA is to allocate this new TLV 589 from the "PCEP TLV Type Indicators" subregistry 590 (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type- 591 indicators). 593 Value Description Reference 594 --------------------------------------------------------- 595 TBD5 Frequency Slot Restriction [This.I-D] 596 Constraint 598 8.4. New PCEP TLV: Spectrum Allocation TLV 600 As described in Section 5, a new PCEP TLV is defined to indicate the 601 allocation of freq-slots(s) by the PCE in response to a request by 602 the PCC. IANA is to allocate this new TLV from the "PCEP TLV Type 603 Indicators" subregistry 604 (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type- 605 indicators). 607 Value Description Reference 608 --------------------------------------------------------- 609 TBD6 Spectrum Allocation [This.I-D] 611 8.5. New No-Path Reasons 613 As described in Section 4.3, a new bit flag are defined to be 614 carried in the Flags field in the NO-PATH-VECTOR TLV carried in the 615 NO-PATH Object. This flag, when set, indicates that no feasible 616 route was found that meets all the RSA constraints (e.g., spectrum 617 restriction, signal compatibility, etc.) associated with a RSA path 618 computation request. 620 IANA is to allocate this new bit flag from the "PCEP NO-PATH-VECTOR 621 TLV Flag Field" subregistry 622 (http://www.iana.org/assignments/pcep/pcep.xhtml#no-path-vector- 623 tlv). 625 Bit Description Reference 626 ----------------------------------------------------- 627 TBD8 No RSA constraints met [This.I-D] 629 8.6. New Error-Types and Error-Values 631 As described in Section 5.1, new PCEP error codes are defined for 632 WSON RWA errors. IANA is to allocate from the ""PCEP-ERROR Object 633 Error Types and Values" sub-registry 634 (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-error-object). 636 Error- Meaning Error-Value Reference 637 Type 638 --------------------------------------------------------------- 640 TBD7 Flexi-Grid RSA Error 1: Insufficient [This.I-D] 641 Memory 643 2: RSA computation [This.I-D] 644 Not supported 646 8.7. New Error-Values for Existing Error Type (24) 648 As discussed in Section 4.1, two new PathErr values for the Existing 649 Error Type (24) are to be allocated: 651 Meaning Error-Value Reference 653 --------------------------------------------------------------- 654 Unsupported Frequency slot 655 Selection Symmetry value TBD3 [This.I-D] 657 Unsupported Frequency Slot 658 Assignment value TBD4 [This.I-D] 660 9. References 662 9.1. Normative References 664 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 665 Requirement Levels", BCP 14, RFC 2119, March 1997. 667 [RFC4003] Berger, L., "GMPLS Signaling Procedure for Egress 668 Control", RFC 4003, February 2005. 670 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 671 Element (PCE)-Based Architecture", RFC 4655, August 2006. 673 [RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE) 674 Communication Protocol Generic Requirements", RFC 4657, 675 September 2006. 677 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 678 Element (PCE) communication Protocol", RFC 5440, March 679 2009. 681 [RFC5511] A. Farrel, "Routing Backus-Naur Form (RBNF): A Syntax Used 682 to Form Encoding Rules in Various Routing Protocol 683 Specifications", RFC 5511, April 2009. 685 [RFC5088] Le Roux, JL, JP. Vasseur, Y. Ikejiri, and R. Zhang, "OSPF 686 Protocol Extensions for Path Computation Element (PCE) 687 Discovery," RFC 5088, January 2008. 689 [RFC5089] Le Roux, JL, JP. Vasseur, Y. Ikejiri, and R. Zhang, "IS-IS 690 Protocol Extensions for Path Computation Element (PCE) 691 Discovery," RFC 5089, January 2008. 693 [RFC6163] Lee, Y. and Bernstein, G. (Editors), and W. Imajuku, 694 "Framework for GMPLS and PCE Control of Wavelength 695 Switched Optical Networks", RFC 6163, March 2011. 697 [RFC7449] Lee, Y., et. al., "PCEP Requirements for WSON Routing and 698 Wavelength Assignment", RFC 7449, February 2015. 700 [RFC7698] O. Gonzalez de Dios, R. Casellas, editors, "Framework and 701 Requirements for GMPLS-Based Control of Flexi-Grid Dense 702 Wavelength Division Multiplexing (DWDM) Networks", RFC 703 7698, November 2015. 705 [RFC8174] B. Leiba, "Ambiguity of Uppercase vs Lowercase in RFC 2119 706 Key Words", RFC 8174, May 2017. 708 9.2. Informative References 710 [PCEP-GMPLS] Margaria, et al., "PCEP extensions for GMPLS", draft- 711 ietf-pce-gmpls-pcep-extensions, work in progress. 713 [RFC3209] D. Awduche, et. al., "RSVP-TE: Extensions to RSVP for LSP 714 Tunnels", RFC 3209, December 2001. 716 [RFC5420] Farrel, A. "Encoding of Attributes for MPLS LSP 717 Establishment Using Resource Reservation Protocol Traffic 718 Engineering (RSVP-TE)", RFC 5420, February 2009. 720 [RFC7570] Margaria, et al., "Label Switched Path (LSP) Attribute in 721 the Explicit Route Object (ERO)", RFC 7570, July 2015. 723 [RFC7579] Bernstein and Lee, "General Network Element Constraint 724 Encoding for GMPLS Controlled Networks", RFC 7579, June 725 2015. 727 [PCEP-WSON] Y. Lee (Ed.), and R. Casellas (Ed.), "PCEP Extension for 728 WSON Routing and Wavelength Assignment", draft-ietf-pce- 729 wson-rwa-ext, work in progress. 731 [G.694.1] "Spectral grids for WDM applications: DWDM frequency 732 grid", ITU-T G.694.1, February 2012. 734 [G.872] "Architecture of optical transport networks", ITU-T G.872, 735 January 2017. 737 10. Contributors 738 Authors' Addresses 740 Young Lee, Editor 741 Huawei Technologies 743 Email: leeyoung@huawei.com 745 Haomian Zheng 746 Huawei Technologies 748 Email: zhenghaomian@huawei.com 750 Ramon Casellas 751 CTTC 752 Av. Carl Friedrich Gauss n7 753 Castelldefels, Barcelona 08860 754 Spain 756 Email: ramon.casellas@cttc.es 758 Ricard Vilalta 759 CTTC 760 Email: ricard.vilalta@cttc.es 762 Daniele Ceccarelli 763 Ericsson AB 764 Gronlandsgatan 21 765 Kista - Stockholm 766 Email: daniele.ceccarelli@ericsson.com 768 Francesco Lazzeri 769 Ericsson 770 Via Melen 77 771 Genova - Italy 772 Email: francesco.lazzeri@ericsson.com