idnits 2.17.1 draft-lee-pce-flexible-grid-03.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 (October 22, 2018) is 1984 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC3209' is mentioned on line 318, but not defined == Unused Reference: 'RFC2863' is defined on line 654, but no explicit reference was found in the text == Unused Reference: 'RFC6566' is defined on line 683, but no explicit reference was found in the text == Unused Reference: 'RFC7420' is defined on line 687, but no explicit reference was found in the text == Unused Reference: 'RFC7446' is defined on line 692, but no explicit reference was found in the text == Unused Reference: 'RFC5521' is defined on line 708, but no explicit reference was found in the text == Unused Reference: 'RFC6205' is defined on line 712, but no explicit reference was found in the text == Unused Reference: 'RFC7689' is defined on line 719, but no explicit reference was found in the text == Unused Reference: 'RFC7688' is defined on line 722, but no explicit reference was found in the text == Unused Reference: 'RFC7581' is defined on line 731, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 7698 Summary: 1 error (**), 0 flaws (~~), 11 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: April 23, 2019 5 R. Casellas 6 R. Vilalta 7 CTTC 9 D. Ceccarelli 10 F. Lazzeri 11 Ericsson 13 October 22, 2018 15 PCEP Extension for Flexible Grid Networks 17 draft-lee-pce-flexible-grid-03 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 December 22, 2018. 48 Copyright Notice 50 Copyright (c) 2018 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..........................................11 74 5.2. NO-PATH Indicator........................................12 75 6. Manageability Considerations..................................12 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 Components13 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. Informative References...................................17 91 9.2. Normative 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", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in [RFC2119]. 106 3. Introduction 108 [RFC4655] defines a PCE based path computation architecture and 109 explains how a Path Computation Element (PCE) may compute Label 110 Switched Paths (LSP) in Multiprotocol Label Switching Traffic 111 Engineering (MPLS-TE) and Generalized MPLS (GMPLS) networks at the 112 request of Path Computation Clients (PCCs). A PCC is said to be any 113 network component that makes such a request and may be, for 114 instance, an Optical Switching Element within a Wavelength Division 115 Multiplexing (WDM) network. The PCE, itself, can be located 116 anywhere within the network, and may be within an optical switching 117 element, a Network Management System (NMS) or Operational Support 118 System (OSS), or may be an independent network server. 120 The PCE communications Protocol (PCEP) is the communication protocol 121 used between a PCC and a PCE, and may also be used between 122 cooperating PCEs. [RFC4657] sets out the common protocol 123 requirements for PCEP. Additional application-specific requirements 124 for PCEP are deferred to separate documents. 126 [PCEP-WSON] provides the PCEP extensions for the support of Routing 127 and Wavelength Assignment (RWA) in Wavelength Switched Optical 128 Networks (WSON) based on the requirements specified in [RFC6163] and 129 [RFC7449]. 131 [RFC7698] provides Framework and Requirements for GMPLS-Based 132 Control of Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) 133 Networks. To allow efficient allocation of optical spectral 134 bandwidth for systems that have high bit-rates, the International 135 Telecommunication Union Telecommunication Standardization Sector 136 (ITU-T) has extended its Recommendations G.694.1 and G.872 to 137 include a new Dense Wavelength Division Multiplexing (DWDM) grid by 138 defining a set of nominal central frequencies, channel spacings, and 139 the concept of the "frequency slot". In such an environment, a data- 140 plane connection is switched based on allocated, variable-sized 141 frequency ranges within the optical spectrum, creating what is known 142 as a flexible grid (flexi-grid). 144 This document provides PCEP extensions to support Routing and 145 Spectrum Assignment (RSA) in in Spectrum Switched Optical Networks 146 (SSON)[RFC7698]. 148 Figure 2 shows one typical PCE based implementation, which is 149 referred to as the Combined Routing and Spectrum Assignment (R&SA) 150 [RFC7698]. With this architecture, the two processes of routing and 151 spectrum assignment are accessed via a single PCE. This architecture 152 is the base architecture from which the PCEP extensions are going to 153 be specified in this document. 155 +----------------------------+ 156 +-----+ | +-------+ +--+ | 157 | | | |Routing| |SA| | 158 | PCC |<----->| +-------+ +--+ | 159 | | | | 160 +-----+ | PCE | 161 +----------------------------+ 163 Figure 1 Combined Process (R&SA) architecture 165 4. Spectrum Assignment (SA) Object 167 Spectrum allocation can be performed by the PCE by different means: 169 (a) By means of Explicit Label Control (ELC) where the PCE 170 allocates which label to use for each interface/node along the 171 path. 173 (b) By means of a Label Set where the PCE provides a range of 174 potential frequency slots to allocate by each node along the path. 175 This document aligns with GMPLS extensions for PCEP [PCEP-GMPLS] 176 for generic property such as label, label-set and label assignment 177 noting that frequency is a type of label. Frequency restrictions 178 and constraints are also formulated in terms of labels per 179 [RFC7579]. 181 Option (b) allows distributed spectrum allocation (performed during 182 signaling) to complete spectrum assignment. 184 Additionally, given a range of potential spectrums to allocate, the 185 request SHOULD convey the heuristic / mechanism to the allocation. 187 The format of a PCReq message after incorporating the Spectrum 188 Assignment (SA) object is as follows: 190 ::= 192 [] 194 196 Where: 198 ::=[] 200 ::= 202 204 [ ] 206 [other optional objects...] 208 If the SA object is present in the request, it MUST be encoded after 209 the ENDPOINTS object. 211 The format of the Spectrum Assignment (SA) object body is as 212 follows: 214 0 1 2 3 215 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 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | Reserved | Flags |M| 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | Frequency-Slot Selection TLV | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | Frequency-Slot Restriction Constraint TLV | 222 . . 223 . . 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 // Optional TLVs // 226 | | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 Figure 2 SA Object 231 o Reserved (16 bits) 233 o Flags (16 bits) 235 The following new flags SHOULD be set 237 . M (Mode - 1 bit): M bit is used to indicate the mode of 238 spectrum assignment. When M bit is set to 1, this indicates 239 that the spectrum assigned by the PCE must be explicit. That 240 is, the selected way to convey the allocated spectrum is by 241 means of Explicit Label Control (ELC) [RFC4003] for each hop of 242 a computed LSP. Otherwise, the spectrum assigned by the PCE 243 needs not be explicit (i.e., it can be suggested in the form of 244 label set objects in the corresponding response, to allow 245 distributed SA. In such case, the PCE MUST return a Label Set 246 Field as described in Section 2.6 of [RFC7579] in the response. 247 See Section 5 of this document for the encoding discussion of a 248 Label Set Field in a PCRep message. 250 4.1. Frequency-Slot Selection TLV 252 The Frequency-Slot Selection TLV is used to indicate the frequency- 253 slot selection constraint in regard to the order of frequency-slot 254 assignment to be returned by the PCE. This TLV is only applied when 255 M bit is set in the SA Object specified in Section 3.1. This TLV 256 MUST NOT be used when the M bit is cleared. 258 The Frequency-Slot Selection sub-TLV value field is defined as: 260 0 1 2 3 261 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 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 |S| FSA Method | Reserved | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 Where: 267 S (Symmetry, 1 bit): This flag is only meaningful when the 268 request is for a bidirectional LSP (see [RFC5440]). 270 0 denotes requiring the same frequency-slot in both directions; 271 1 denotes that different spectrums on both directions are 272 allowed. 274 Frequency-Slot Assignment (FSA) Method (7 bits): 276 0: unspecified (any); This does not constrain the SA method 277 used by a PCC This value is implied when the 278 Frequency-Slot Selection sub-TLV is absent. 280 1: First-Fit. All the feasible frequency slots are numbered 281 (based on "n" parameter), and this SA method chooses the 282 available frequency-slot with the lowest index (of "n" 283 parameter). 285 2: Random. This SA method chooses an feasible frequency-slot 286 ("n" paramerer) randomly. 288 3-127: Unassigned. 290 The processing rules for this TLV are as follows: 292 If a PCE does not support the attribute(s), its 293 behavior is specified below: 295 - S bit not supported: a PathErr MUST be generated with the 296 Error Code "Routing Problem" (24) with error sub-code 297 "Unsupported Frequency slot Selection Symmetry value" (TDB). 299 - FSA method not supported: a PathErr MUST be generated with the 300 Error Code "Routing Problem" (24) with error sub-code 301 "Unsupported Frequency Slot Assignment value" (TDB). 303 A Frequency Slot Selection TLV can be constructed by a node and 304 added to an ERO Hop Attributes subobject in order to be processed 305 by downstream nodes (transit and egress). As defined in 306 [RFC7570], the R bit reflects the LSP_REQUIRED_ATTRIBUTE and 307 LSP_ATTRIBUTE semantic defined in [RFC5420], and it SHOULD be set 308 accordingly. 310 Once a node properly parses the Spectrum Selection sub-TLV 311 received in an ERO Hop Attributes subobject, the node use the 312 indicated spectrum assignment method (at that hop) for the LSP. 313 In addition, the node SHOULD report compliance by adding an RRO 314 Hop Attributes subobject with the WSON Processing Hop Attribute 315 TLV (and its sub-TLVs) that indicate the utilized method. 316 Frequency-Slot Selection TLVs carried in an RRO Hop Attributes 317 subobject are subject to [RFC7570] and standard RRO processing; 318 see [RFC3209]. 320 4.2. Frequency-slot Restriction Constraint TLV 322 For any request that contains a Frequency-slot assignment, the 323 requester (PCC) MUST be able to specify a restriction on the 324 frequency-slots to be used. This restriction is to be interpreted by 325 the PCE as a constraint on the tuning ability of the origination 326 laser transmitter or on any other maintenance related constraints. 328 The format of the Frequency-Slot Restriction Constraint TLV is as 329 follows: 331 ::= 333 335 ( )... 337 Where 339 ::= [] 341 See Section 4.3.1 in [PCEP-WSON] for the encoding of the Link 342 Identifiers Field. 344 The Frequency slot Restriction Constraint TLV type is TBD. This TLV 345 MAY appear more than once to be able to specify multiple 346 restrictions. 348 The TLV data is defined as follows: 350 0 1 2 3 351 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | Action | Count | Reserved | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | Link Identifiers | 356 | . . . | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | Frequency Slot Restriction Field | 359 // . . . . // 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 Figure 3 spectrum Restriction Constraint TLV Encoding 364 o Action: 8 bits 366 . 0 - Inclusive List indicates that one or more link identifiers 367 are included in the Link Set. Each identifies a separate link 368 that is part of the set. 370 . 1 - Inclusive Range indicates that the Link Set defines a 371 range of links. It contains two link identifiers. The first 372 identifier indicates the start of the range (inclusive). The 373 second identifier indicates the end of the range (inclusive). 374 All links with numeric values between the bounds are 375 considered to be part of the set. A value of zero in either 376 position indicates that there is no bound on the corresponding 377 portion of the range. Note that the Action field can be set to 378 0 when unnumbered link identifier is used. 380 o Count: The number of the link identifiers (8 bits) 382 Note that a PCC MAY add a spectrum restriction that applies to all 383 links by setting the Count field to zero and specifying just a set 384 of spectrums. 386 Note that all link identifiers in the same list must be of the same 387 type. 389 o Reserved: Reserved for future use (16 bits) 391 o Link Identifiers: Identifies each link ID for which restriction 392 is applied. The length is dependent on the link format and the Count 393 field. See Section 4.3.1 in [PCEP-WSON] for Link Identifier encoding 394 and Section 3.3.1 for the Spectrum Restriction Field encoding, 395 respectively. 397 4.2.1. Frequency-Slot Restriction Field 399 The Frequency-Slot Restriction Field of the Frequency slot 400 restriction TLV is encoded as defined in 401 https://tools.ietf.org/html/draft-ietf-ccamp-flexible-grid-ospf-ext- 402 09#section-4.1.1. 404 5. Encoding of a RSA Path Reply 406 This section provides the encoding of a RSA Path Reply for frequency 407 slot allocation as discussed in Section 4. Spectrum Allocation TLV 409 The Spectrum Allocation TLV type is TBD, recommended value is TBD. 410 The TLV data is defined as follows: 412 0 1 2 3 413 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 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | Type | Length |M| 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | Link Identifier | 418 | . . . | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | Allocated Spectrum(s) | 421 // . . . . // 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 Figure 4 Spectrum Allocation TLV Encoding 426 o Type (16 bits): The type of the TLV. 428 o Length (15 bits): The length of the TLV including the Type and 429 Length fields. 431 o M (Mode): 1 bit 433 - 0 indicates the allocation is under Explicit Label Control. 435 - 1 indicates the allocation is expressed in Label Sets. 437 Note that all link identifiers in the same list must be of the same 438 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]. The type 450 value of the Spectrum Restriction Constraint TLV is TBD by IANA. 452 5.1. Error Indicator 454 To indicate errors associated with the RSA request, a new Error Type 455 (TDB) and subsequent error-values are defined as follows for 456 inclusion in the PCEP-ERROR Object: 458 A new Error-Type (TDB) and subsequent error-values are defined as 459 follows: 461 . Error-Type=TBD; Error-value=1: if a PCE receives a RSA request 462 and the PCE is not capable of processing the request due to 463 insufficient memory, the PCE MUST send a PCErr message with a 464 PCEP-ERROR Object (Error-Type=TDB) and an Error-value(Error- 465 value=1). The PCE stops processing the request. The 466 corresponding RSA request MUST be cancelled at the PCC. 468 . Error-Type=TBD; Error-value=2: if a PCE receives a RSA request 469 and the PCE is not capable of RSA computation, the PCE MUST 470 send a PCErr message with a PCEP-ERROR Object (Error-Type=TDB) 471 and an Error-value (Error-value=2). The PCE stops processing 472 the request. The corresponding RSA computation MUST be 473 cancelled at the PCC. 475 5.2. NO-PATH Indicator 477 To communicate the reason(s) for not being able to find RSA for the 478 path request, the NO-PATH object can be used in the corresponding 479 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 TDB: 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 SSON Routing and Spectrum Assignment (RSA) with PCE 493 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 523 Mechanisms defined in this document do not imply any new liveness 524 detection and monitoring requirements in addition to those already 525 listed in section 8.3 of [RFC5440]. 527 6.3. Verifying Correct Operation 529 Mechanisms defined in this document do not imply any new 530 verification requirements in addition to those already listed in 531 section 8.4 of [RFC5440] 533 6.4. Requirements on Other Protocols and Functional Components 535 The PCE Discovery mechanisms ([RFC5089] and [RFC5088]) may be used 536 to advertise Flexi-Grid RSA path computation capabilities to PCCs. 538 This draft has requirements on other protocols (ERO objects, etc. 539 which are under TEAS or CCAMP.) 541 6.5. Impact on Network Operation 543 Mechanisms defined in this document do not imply any new network 544 operation requirements in addition to those already listed in 545 section 8.6 of [RFC5440]. 547 7. Security Considerations 549 This document has no requirement for a change to the security models 550 within PCEP. However, the additional information distributed in 551 order to address the RSA problem represents a disclosure of network 552 capabilities that an operator may wish to keep private. 553 Consideration should be given to securing this information. 555 8. IANA Considerations 557 IANA maintains a registry of PCEP parameters. IANA has made 558 allocations from the sub-registries as described in the following 559 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 --------------------------------------------------------- 572 TDB SA 1: Spectrum Assignment [This.I-D] 574 8.2. New PCEP TLV: Frequency Slot Selection TLV 576 As described in Sections 4.2, a new PCEP TLV is defined to indicate 577 spectrum selection constraints. IANA is to allocate this new TLV 578 from the "PCEP TLV Type Indicators" subregistry 579 (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type- 580 indicators). 582 Value Description Reference 583 --------------------------------------------------------- 584 TBD Spectrum Selection [This.I-D] 586 8.3. New PCEP TLV: Frequency Slot Restriction Constraint TLV 588 As described in Section 4.3, a new PCEP TLV is defined to indicate 589 wavelength restriction constraints. IANA is to allocate this new TLV 590 from the "PCEP TLV Type Indicators" subregistry 591 (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type- 592 indicators). 594 Value Description Reference 595 --------------------------------------------------------- 596 TBD Frequency Slot Restriction [This.I-D] 597 Constraint 599 8.4. New PCEP TLV: Spectrum Allocation TLV 601 As described in Section 5, a new PCEP TLV is defined to indicate the 602 allocation of freq-slots(s) by the PCE in response to a request by 603 the PCC. IANA is to allocate this new TLV from the "PCEP TLV Type 604 Indicators" subregistry 605 (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type- 606 indicators). 608 Value Description Reference 609 --------------------------------------------------------- 610 TBD Spectrum Allocation [This.I-D] 612 8.5. New No-Path Reasons 614 As described in Section 4.3, a new bit flag are defined to be 615 carried in the Flags field in the NO-PATH-VECTOR TLV carried in the 616 NO-PATH Object. This flag, when set, indicates that no feasible 617 route was found that meets all the RSA constraints (e.g., spectrum 618 restriction, signal compatibility, etc.) associated with a RSA path 619 computation request. 621 IANA is to allocate this new bit flag from the "PCEP NO-PATH-VECTOR 622 TLV Flag Field" subregistry 623 (http://www.iana.org/assignments/pcep/pcep.xhtml#no-path-vector- 624 tlv). 626 Bit Description Reference 627 ----------------------------------------------------- 628 TBD No RSA constraints met [This.I-D] 630 8.6. New Error-Types and Error-Values 632 As described in Section 5.1, new PCEP error codes are defined for 633 WSON RWA errors. IANA is to allocate from the ""PCEP-ERROR Object 634 Error Types and Values" sub-registry 635 (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-error-object). 637 Error- Meaning Error-Value Reference 638 Type 639 --------------------------------------------------------------- 641 TDB Flexi-Grid RSA Error 1: Insufficient [This.I-D] 642 Memory 644 2: RSA computation [This.I-D] 645 Not supported 647 9. References 649 9.1. Informative References 651 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 652 Requirement Levels", BCP 14, RFC 2119, March 1997. 654 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 655 MIB", RFC 2863, June 2000. 657 [RFC4003] Berger, L., "GMPLS Signaling Procedure for Egress 658 Control", RFC 4003, February 2005. 660 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 661 Element (PCE)-Based Architecture", RFC 4655, August 2006. 663 [RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE) 664 Communication Protocol Generic Requirements", RFC 4657, 665 September 2006. 667 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 668 Element (PCE) communication Protocol", RFC 5440, March 669 2009. 671 [RFC5088] Le Roux, JL, JP. Vasseur, Y. Ikejiri, and R. Zhang, "OSPF 672 Protocol Extensions for Path Computation Element (PCE) 673 Discovery," RFC 5088, January 2008. 675 [RFC5089] Le Roux, JL, JP. Vasseur, Y. Ikejiri, and R. Zhang, "IS-IS 676 Protocol Extensions for Path Computation Element (PCE) 677 Discovery," RFC 5089, January 2008. 679 [RFC6163] Lee, Y. and Bernstein, G. (Editors), and W. Imajuku, 680 "Framework for GMPLS and PCE Control of Wavelength 681 Switched Optical Networks", RFC 6163, March 2011. 683 [RFC6566] Y. Lee, G. Bernstein, D. Li, G. Martinelli, "A Framework 684 for the Control of Wavelength Switched Optical Networks 685 (WSON) with Impairments", RFC 6566, March 2012. 687 [RFC7420] Koushik, A., E. Stephan, Q. Zhao, D. King, and J. 688 Hardwick, "Path Computation Element Communication Protocol 689 (PCEP) Management Information Base (MIB) Module", RFC 690 7420, December 2014. 692 [RFC7446] Y. Lee, G. Bernstein. (Editors), "Routing and Wavelength 693 Assignment Information Model for Wavelength Switched 694 Optical Networks", RFC 7446, February 2015. 696 [RFC7449] Lee, Y., et. al., "PCEP Requirements for WSON Routing and 697 Wavelength Assignment", RFC 7449, February 2015. 699 9.2. Normative References 701 [PCEP-GMPLS] Margaria, et al., "PCEP extensions for GMPLS", draft- 702 ietf-pce-gmpls-pcep-extensions, work in progress. 704 [RFC5420] Farrel, A. "Encoding of Attributes for MPLS LSP 705 Establishment Using Resource Reservation Protocol Traffic 706 Engineering (RSVP-TE)", RFC5420, February 2009. 708 [RFC5521] Oki, E, T. Takeda, and A. Farrel, "Extensions to the Path 709 Computation Element Communication Protocol (PCEP) for 710 Route Exclusions", RFC 5521, April 2009. 712 [RFC6205] Tomohiro, O. and D. Li, "Generalized Labels for Lambda- 713 Switching Capable Label Switching Routers", RFC 6205, 714 January, 2011. 716 [RFC7570] Margaria, et al., "Label Switched Path (LSP) Attribute in 717 the Explicit Route Object (ERO)", RFC 7570, July 2015. 719 [RFC7689] Bernstein et al, "Signaling Extensions for Wavelength 720 Switched Optical Networks", RFC 7689, November 2015. 722 [RFC7688] Y. Lee, and G. Bernstein, "OSPF Enhancement for Signal and 723 Network Element Compatibility for Wavelength Switched 724 Optical Networks", RFC 7688, November 2015. 726 [RFC7698] O. Gonzalez de Dios, R. Casellas, editors, "Framework and 727 Requirements for GMPLS-Based Control of Flexi-Grid Dense 728 Wavelength Division Multiplexing (DWDM) Networks", RFC 729 7698, November 2015. 731 [RFC7581] Bernstein and Lee, "Routing and Wavelength Assignment 732 Information Encoding for Wavelength Switched Optical 733 Networks", RFC7581, June 2015. 735 [RFC7579] Bernstein and Lee, "General Network Element Constraint 736 Encoding for GMPLS Controlled Networks", RFC 7579, June 737 2015. 739 [PCEP-WSON] Y. Lee (Ed.), and R. Casellas (Ed.), "PCEP Extension for 740 WSON Routing and Wavelength Assignment", draft-ietf-pce- 741 wson-rwa-ext, work in progress. 743 10. Contributors 744 Authors' Addresses 746 Young Lee, Editor 747 Huawei Technologies 749 Email: leeyoung@huawei.com 751 Haomian Zheng 752 Huawei Technologies 754 Email: zhenghaomian@huawei.com 756 Ramon Casellas 757 CTTC 758 Av. Carl Friedrich Gauss n7 759 Castelldefels, Barcelona 08860 760 Spain 762 Email: ramon.casellas@cttc.es 764 Ricard Vilalta 765 CTTC 766 Email: ricard.vilalta@cttc.es 768 Daniele Ceccarelli 769 Ericsson AB 770 Gronlandsgatan 21 771 Kista - Stockholm 772 Email: daniele.ceccarelli@ericsson.com 774 Francesco Lazzeri 775 Ericsson 776 Via Melen 77 777 Genova - Italy 778 Email: francesco.lazzeri@ericsson.com