idnits 2.17.1 draft-ietf-pce-wson-rwa-ext-10.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 (December 13, 2018) is 1933 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: 'RFC4655' is mentioned on line 104, but not defined == Missing Reference: 'RFC7449' is mentioned on line 136, but not defined Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Y. Lee, Ed. 2 Internet Draft Huawei Technologies 4 Intended status: Standard Track R. Casellas, Ed. 5 Expires: June 13, 2019 CTTC 7 December 13, 2018 9 PCEP Extension for WSON Routing and Wavelength Assignment 11 draft-ietf-pce-wson-rwa-ext-10 13 Abstract 15 This document provides the Path Computation Element communication 16 Protocol (PCEP) extensions for the support of Routing and Wavelength 17 Assignment (RWA) in Wavelength Switched Optical Networks (WSON). 18 Path provisioning in WSONs requires a routing and wavelength 19 assignment (RWA) process. From a path computation perspective, 20 wavelength assignment is the process of determining which wavelength 21 can be used on each hop of a path and forms an additional routing 22 constraint to optical path computation. 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 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This Internet-Draft will expire on June 13, 2019. 46 Copyright Notice 48 Copyright (c) 2018 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with 56 respect to this document. Code Components extracted from this 57 document must include Simplified BSD License text as described in 58 Section 4.e of the Trust Legal Provisions and are provided without 59 warranty as described in the Simplified BSD License. 61 Table of Contents 63 1. Terminology....................................................3 64 2. Requirements Language..........................................3 65 3. Introduction...................................................3 66 4. Encoding of a RWA Path Request.................................6 67 4.1. Wavelength Assignment (WA) Object.........................6 68 4.2. Wavelength Selection TLV..................................8 69 4.3. Wavelength Restriction Constraint TLV.....................8 70 4.3.1. Link Identifier Field...............................10 71 4.3.2. Wavelength Restriction Field........................12 72 4.4. Signal processing capability restrictions................13 73 4.4.1. Signal Processing Exclusion XRO Sub-Object..........14 74 4.4.2. IRO sub-object: signal processing inclusion.........14 75 5. Encoding of a RWA Path Reply..................................15 76 5.1. Error Indicator..........................................16 77 5.2. NO-PATH Indicator........................................17 78 6. Manageability Considerations..................................17 79 6.1. Control of Function and Policy...........................17 80 6.2. Information and Data Models..............................18 81 6.3. Liveness Detection and Monitoring........................18 82 6.4. Verifying Correct Operation..............................18 83 6.5. Requirements on Other Protocols and Functional Components18 84 6.6. Impact on Network Operation..............................18 85 7. Security Considerations.......................................18 86 8. IANA Considerations...........................................18 87 8.1. New PCEP Object..........................................19 88 8.2. New PCEP TLV: Wavelength Selection TLV...................19 89 8.3. New PCEP TLV: Wavelength Restriction Constraint TLV......19 90 8.4. New PCEP TLV: Wavelength Allocation TLV..................20 91 8.5. New PCEP TLV: Optical Interface Class List TLV...........20 92 8.6. New PCEP TLV: Client Signal TLV..........................20 93 8.7. New No-Path Reasons......................................21 94 8.8. New Error-Types and Error-Values.........................21 95 9. Acknowledgments...............................................22 96 10. References...................................................22 97 10.1. Normative References....................................22 98 10.2. Informative References..................................22 99 11. Contributors.................................................24 100 Authors' Addresses...............................................25 102 1. Terminology 104 This document uses the terminology defined in [RFC4655], and 105 [RFC5440]. 107 2. Requirements Language 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 111 "OPTIONAL" in this document are to be interpreted as described in 112 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 113 capitals, as shown here. 115 3. Introduction 117 [RFC5440] specifies the Path Computation Element (PCE) Communication 118 Protocol (PCEP) for communications between a Path Computation Client 119 (PCC) and a PCE, or between two PCEs. Such interactions include 120 path computation requests and path computation replies as well as 121 notifications of specific states related to the use of a PCE in the 122 context of Multiprotocol Label Switching (MPLS) and Generalized MPLS 123 (GMPLS) Traffic Engineering. 125 A PCC is said to be any network component that makes such a request 126 and may be, for instance, an Optical Switching Element within a 127 Wavelength Division Multiplexing (WDM) network. The PCE, itself, 128 can be located anywhere within the network, and may be within an 129 optical switching element, a Network Management System (NMS) or 130 Operational Support System (OSS), or may be an independent network 131 server. 133 This document provides the PCEP extensions for the support of 134 Routing and Wavelength Assignment (RWA) in Wavelength Switched 135 Optical Networks (WSON) based on the requirements specified in 136 [RFC6163] and [RFC7449]. 138 WSON refers to WDM based optical networks in which switching is 139 performed selectively based on the wavelength of an optical signal. 140 WSONs can be transparent or translucent. A transparent optical 141 network is made up of optical devices that can switch but not 142 convert from one wavelength to another, all within the optical 143 domain. On the other hand, translucent networks include 3R 144 regenerators that are sparsely placed. The main function of the 3R 145 regenerators is to convert one optical wavelength to another. In 146 this document, only wavelength converters that require electrical 147 signal regeneration are considered. 149 A Lambda Switch Capable (LSC) Label Switched Path (LSP) may span one 150 or several transparent segments, which are delimited by 3R 151 regenerators (typically with electronic regenerator and optional 152 wavelength conversion). Each transparent segment or path in WSON is 153 referred to as an optical path. An optical path may span multiple 154 fiber links and the path should be assigned the same wavelength for 155 each link. In such case, the optical path is said to satisfy the 156 wavelength-continuity constraint. Figure 1 illustrates the 157 relationship between a LSC LSP and transparent segments (optical 158 paths). 160 +---+ +-----+ +-----+ +-----+ +-----+ 161 | |I1 | | | | | | I2| | 162 | |o------| |-------[(3R) ]------| |--------o| | 163 | | | | | | | | | | 164 +---+ +-----+ +-----+ +-----+ +-----+ 165 (X LSC) (LSC LSC) (LSC LSC) (LSC X) 166 <-------> <-------> <-----> <-------> 167 <-----------------------><----------------------> 168 Transparent Segment Transparent Segment 169 <-------------------------------------------------> 170 LSC LSP 172 Figure 1 Illustration of a LSC LSP and transparent segments 173 Note that two optical paths within a WSON LSP do not need to operate 174 on the same wavelength (due to the wavelength conversion 175 capabilities). Two optical paths that share a common fiber link 176 cannot be assigned the same wavelength; Otherwise, both signals 177 would interfere with each other. Note that advanced additional 178 multiplexing techniques such as polarization based multiplexing are 179 not addressed in this document since the physical layer aspects are 180 not currently standardized. Therefore, assigning the proper 181 wavelength on a path is an essential requirement in the optical path 182 computation process. 184 When a switching node has the ability to perform wavelength 185 conversion, the wavelength-continuity constraint can be relaxed, and 186 a LSC Label Switched Path (LSP) may use different wavelengths on 187 different links along its route from origin to destination. It is, 188 however, to be noted that wavelength converters may be limited due 189 to their relatively high cost, while the number of WDM channels that 190 can be supported in a fiber is also limited. As a WSON can be 191 composed of network nodes that cannot perform wavelength conversion, 192 nodes with limited wavelength conversion, and nodes with full 193 wavelength conversion abilities, wavelength assignment is an 194 additional routing constraint to be considered in all optical path 195 computation. 197 For example (see Figure 1), within a translucent WSON, a LSC LSP may 198 be established between interfaces I1 and I2, spanning 2 transparent 199 segments (optical paths) where the wavelength continuity constraint 200 applies (i.e. the same unique wavelength must be assigned to the LSP 201 at each TE link of the segment). If the LSC LSP induced a Forwarding 202 Adjacency / TE link, the switching capabilities of the TE link would 203 be (X X) where X refers to the switching capability of I1 and I2. 204 For example, X can be PSC, TDM, etc. 206 This document aligns with GMPLS extensions for PCEP [PCEP-GMPLS] for 207 generic property such as label, label-set and label assignment 208 noting that wavelength is a type of label. Wavelength restrictions 209 and constraints are also formulated in terms of labels per 210 [RFC7579]. 212 The optical modulation properties, which are also referred to as 213 signal compatibility, are already considered in signaling in 214 [RFC7581] and [RFC7688]. In order to improve the signal quality and 215 limit some optical effects several advanced modulation processing 216 are used. Those modulation properties contribute not only to optical 217 signal quality checks but also constrain the selection of sender and 218 receiver, as they should have matching signal processing 219 capabilities. This document includes signal compatibility 220 constraints as part of RWA path computation. That is, the signal 221 processing capabilities (e.g., modulation and FEC) by the means of 222 optical interface class (OIC) must be compatible between the sender 223 and the receiver of the optical path across all optical elements. 225 This document, however, does not address optical impairments as part 226 of RWA path computation. 228 4. Encoding of a RWA Path Request 230 Figure 2 shows one typical PCE based implementation, which is 231 referred to as the Combined Process (R&WA). With this architecture, 232 the two processes of routing and wavelength assignment are accessed 233 via a single PCE. This architecture is the base architecture 234 specified in [RFC6163] and the PCEP extensions that are going to be 235 specified in this document are based on this architecture. 237 +----------------------------+ 238 +-----+ | +-------+ +--+ | 239 | | | |Routing| |WA| | 240 | PCC |<----->| +-------+ +--+ | 241 | | | | 242 +-----+ | PCE | 243 +----------------------------+ 245 Figure 2 Combined Process (R&WA) architecture 247 4.1. Wavelength Assignment (WA) Object 249 Wavelength allocation can be performed by the PCE by different 250 means: 252 (a) By means of Explicit Label Control [RFC3471] where the PCE 253 allocates which label to use for each interface/node along the path. 254 The allocated labels MAY appear after an interface route subobject. 256 (b) By means of a Label Set where the PCE provides a range of 257 potential labels to allocate by each node along the path. 259 Option (b) allows distributed label allocation (performed during 260 signaling) to complete wavelength assignment. 262 Additionally, given a range of potential labels to allocate, the 263 request SHOULD convey the heuristic / mechanism to the allocation. 265 The format of a PCReq message after incorporating the WA object is 266 as follows: 268 ::= 270 [] 272 274 Where: 276 ::=[] 278 ::= 280 282 284 [other optional objects...] 286 If the WA object is present in the request, it MUST be encoded after 287 the ENDPOINTS object as defined in [PCEP-GMPLS]. Orderings with 288 respect to the other following objects are irrelevant. 290 The format of the Wavelength Assignment (WA) object body is as 291 follows: 293 0 1 2 3 294 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 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | Reserved | Flags |M| 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | Wavelength Selection TLV | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | Wavelength Restriction Constraint TLV | 301 . . 302 . . 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 // Optional TLVs // 305 | | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 Figure 3 WA Object 310 o Reserved (16 bits) 312 o Flags (16 bits) 314 The following new flags SHOULD be set 316 . M (Mode - 1 bit): M bit is used to indicate the mode of 317 wavelength assignment. When M bit is set to 1, this indicates 318 that the label assigned by the PCE must be explicit. That is, 319 the selected way to convey the allocated wavelength is by means 320 of Explicit Label Control for each hop of a computed LSP. 321 Otherwise, the label assigned by the PCE needs not be explicit 322 (i.e., it can be suggested in the form of label set objects in 323 the corresponding response, to allow distributed WA. In such 324 case, the PCE MUST return a Label Set Field as described in 325 Section 2.6 of [RFC7579] in the response. See Section 5 of this 326 document for the encoding discussion of a Label Set Field in a 327 PCRep message. 329 4.2. Wavelength Selection TLV 331 The Wavelength Selection TLV is used to indicate the wavelength 332 selection constraint in regard to the order of wavelength assignment 333 to be returned by the PCE. This TLV is only applied when M bit is 334 set in the WA Object specified in Section 4.1. This TLV MUST NOT be 335 used when the M bit is cleared. 337 The encoding of this TLV is specified as the Wavelength Selection 338 Sub-TLV in Section 4.2.2 of [RFC7689]. 340 4.3. Wavelength Restriction Constraint TLV 342 For any request that contains a wavelength assignment, the requester 343 (PCC) MUST be able to specify a restriction on the wavelengths to be 344 used. This restriction is to be interpreted by the PCE as a 345 constraint on the tuning ability of the origination laser 346 transmitter or on any other maintenance related constraints. Note 347 that if the LSP LSC spans different segments, the PCE MUST have 348 mechanisms to know the tunability restrictions of the involved 349 wavelength converters / regenerators, e.g. by means of the TED 350 either via IGP or NMS. Even if the PCE knows the tunability of the 351 transmitter, the PCC MUST be able to apply additional constraints to 352 the request. 354 The format of the Wavelength Restriction Constraint TLV is as 355 follows: 357 ::= 359 361 ( )... 363 Where 365 ::= [] 367 See Section 4.3.1. for the encoding of the Link Identifiers Field. 369 The Wavelength Restriction Constraint TLV type is TBD, recommended 370 value is TBD. This TLV MAY appear more than once to be able to 371 specify multiple restrictions. 373 The TLV data is defined as follows: 375 0 1 2 3 376 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 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | Action | Count | Reserved | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | Link Identifiers | 381 | . . . | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | Wavelength Restriction Field | 384 // . . . . // 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 Figure 4 Wavelength Restriction Constraint TLV Encoding 389 o Action: 8 bits 390 . 0 - Inclusive List indicates that one or more link identifiers 391 are included in the Link Set. Each identifies a separate link 392 that is part of the set. 394 . 1 - Inclusive Range indicates that the Link Set defines a 395 range of links. It contains two link identifiers. The first 396 identifier indicates the start of the range (inclusive). The 397 second identifier indicates the end of the range (inclusive). 398 All links with numeric values between the bounds are 399 considered to be part of the set. A value of zero in either 400 position indicates that there is no bound on the corresponding 401 portion of the range. 403 Note that "interfaces" are assumed to be bidirectional. 405 o Count: The number of the link identifiers (8 bits) 407 Note that a PCC MAY add a Wavelength restriction that applies to all 408 links by setting the Count field to zero and specifying just a set 409 of wavelengths. 411 Note that all link identifiers in the same list must be of the same 412 type. 414 o Reserved: Reserved for future use (16 bits) 416 o Link Identifiers: Identifies each link ID for which restriction 417 is applied. The length is dependent on the link format and the Count 418 field. See Section 4.3.1. for Link Identifier encoding and Section 419 4.3.2. for the Wavelength Restriction Field encoding, respectively. 421 4.3.1. Link Identifier Field 423 The link identifier field can be an IPv4 [RFC3630], IPv6 [RFC5329] 424 or unnumbered interface ID [RFC4203]. 426 ::= 428 | | 430 The encoding of each case is as follows: 432 IPv4 prefix sub-TLV 434 0 1 2 3 435 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 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | Type = 1 | Reserved | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | IPv4 address (4 bytes) | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 IPv6 prefix Sub-TLV 444 0 1 2 3 445 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 | Type = 2 | Reserved | 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 | IPv6 address (16 bytes) | 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 | IPv6 address (continued) | 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | IPv6 address (continued) | 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | IPv6 address (continued) | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 Unnumbered Interface ID Sub-TLV 460 0 1 2 3 461 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 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | Type = 3 | Reserved | 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 | TE Node ID | 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 | Interface ID | 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 4.3.2. Wavelength Restriction Field 471 The Wavelength Restriction Field of the wavelength restriction TLV 472 is encoded as a Label Set field as specified in Section 2.6 in 473 [RFC7579] with base label encoded as a 32 bit LSC label, defined in 474 [RFC6205]. See [RFC6205] for a description of Grid, C.S, Identifier 475 and n, as well as [RFC7579] for the details of each action. 477 0 1 2 3 479 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 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 | Action| Num Labels | Length | 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 |Grid | C.S | Identifier | n | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | Additional fields as necessary per action | 487 | | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 Action: 492 0 - Inclusive List 494 1 - Exclusive List 496 2 - Inclusive Range 498 3 - Exclusive Range 500 4 - Bitmap Set 502 Num Labels is generally the number of labels. It has a specific 503 meaning depending on the action value. Num Labels is a 12 bit 504 integer. 506 Length is the length in bytes of the entire label set field. 508 See Sections 2.6.1 - 2.6.3 of [RFC7579] for details on additional 509 field discussion for each action. 511 4.4. Signal processing capability restrictions 513 Path computation for WSON includes the check of signal processing 514 capabilities, those capability MAY be provided by the IGP. Moreover, 515 a PCC should be able to indicate additional restrictions for those 516 signal compatibility, either on the endpoint or any given link. 518 The supported signal processing capabilities are the one described 519 in [RFC7446]: 521 . Optical Interface Class List 523 . Bit Rate 525 . Client Signal 527 The Bit Rate restriction is already expressed in [PCEP-GMPLS] in the 528 BANDWIDTH object. 530 In order to support the Optical Interface Class information and the 531 Client Signal information new TLVs are introduced as endpoint- 532 restriction in the END-POINTS type Generalized endpoint: 534 . Client Signal TLV 536 . Optical Interface Class List TLV 538 The END-POINTS type generalized endpoint is extended as follows: 540 ::= 542 544 [...] 546 Where 548 signal-compatibility-restriction ::= 550 552 The encoding for the Optical Interface Class List is described in 553 Section 4.1 of [RFC7581]. 555 The encoding for the Client Signal Information is described in 556 Section 4.2 of [RFC7581]. 558 4.4.1. Signal Processing Exclusion XRO Sub-Object 560 The PCC/PCE should be able to exclude particular types of signal 561 processing along the path in order to handle client restriction or 562 multi-domain path computation. 564 In order to support the exclusion a new XRO sub-object is defined: 565 the signal processing exclusion: 567 0 1 2 3 569 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 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 |X| Type = X | Length | Reserved | Attribute | 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 | sub-sub objects | 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 Figure 5 Signaling Processing XRO Sub-Object 578 Refer to [RFC5521] for the definition of X, Type, Length and 579 Attribute. 581 The Attribute field indicates how the exclusion sub-object is to be 582 interpreted. The Attribute can only be 0 (Interface) or 1 (Node). 584 The sub-sub objects are encoded as in RSVP signaling definition 585 [RFC7689]. 587 4.4.2. IRO sub-object: signal processing inclusion 589 Similar to the XRO sub-object the PCC/PCE should be able to include 590 particular types of signal processing along the path in order to 591 handle client restriction or multi-domain path computation. 593 This is supported by adding the sub-object "processing" defined for 594 ERO in [RFC7689] to the PCEP IRO object. 596 5. Encoding of a RWA Path Reply 598 This section provides the encoding of a RWA Path Reply for 599 wavelength allocation request as discussed in Section 4. Recall that 600 wavelength allocation can be performed by the PCE by different 601 means: 603 (a) By means of Explicit Label Control (ELC) where the PCE 604 allocates which label to use for each interface/node along the 605 path. 606 (b) By means of a Label Set where the PCE provides a range of 607 potential labels to allocate by each node along the path. 609 Option (b) allows distributed label allocation (performed during 610 signaling) to complete wavelength allocation. 612 The Wavelength Allocation TLV type is TBD, recommended value is TBD. 613 The TLV data is defined as follows: 615 0 1 2 3 616 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 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 | Type | Length |M| 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 | Link Identifier | 621 | . . . | 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 | Allocated Wavelength(s) | 624 // . . . . // 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 Figure 6 Wavelength Allocation TLV Encoding 629 o Type (16 bits): The type of the TLV. 631 o Length (15 bits): The length of the TLV including the Type and 632 Length fields. 634 o M (Mode): 1 bit 636 - 0 indicates the allocation is under Explicit Label Control. 638 - 1 indicates the allocation is expressed in Label Sets. 640 Note that all link identifiers in the same list must be of the same 641 type. 643 o Link Identifier (variable): Identifies the interface to which 644 assignment wavelength(s) is applied. See Section 4.3.1. for Link 645 Identifier encoding. 647 o Allocated Wavelength(s) (variable): Indicates the allocated 648 wavelength(s) to the link identifier. See Section 4.3.2 for encoding 649 details. 651 This TLV is encoded as an attributes TLV, per [RFC5420], which is 652 carried in the ERO LSP Attribute Subobjects per [RFC7570]. The type 653 value of the Wavelength Restriction Constraint TLV is TBD by IANA. 655 5.1. Error Indicator 657 To indicate errors associated with the RWA request, a new Error Type 658 (TDB) and subsequent error-values are defined as follows for 659 inclusion in the PCEP-ERROR Object: 661 A new Error-Type (TDB) and subsequent error-values are defined as 662 follows: 664 . Error-Type=TBD; Error-value=1: if a PCE receives a RWA request 665 and the PCE is not capable of processing the request due to 666 insufficient memory, the PCE MUST send a PCErr message with a 667 PCEP-ERROR Object (Error-Type=TDB) and an Error-value(Error- 668 value=1). The PCE stops processing the request. The 669 corresponding RWA request MUST be cancelled at the PCC. 671 . Error-Type=TBD; Error-value=2: if a PCE receives a RWA request 672 and the PCE is not capable of RWA computation, the PCE MUST 673 send a PCErr message with a PCEP-ERROR Object (Error-Type=TDB) 674 and an Error-value (Error-value=2). The PCE stops processing 675 the request. The corresponding RWA computation MUST be 676 cancelled at the PCC. 678 5.2. NO-PATH Indicator 680 To communicate the reason(s) for not being able to find RWA for the 681 path request, the NO-PATH object can be used in the corresponding 682 response. The format of the NO-PATH object body is defined in 683 [RFC5440]. The object may contain a NO-PATH-VECTOR TLV to provide 684 additional information about why a path computation has failed. 686 One new bit flag is defined to be carried in the Flags field in the 687 NO-PATH-VECTOR TLV carried in the NO-PATH Object. 689 . Bit TDB: When set, the PCE indicates no feasible route was 690 found that meets all the constraints (e.g., wavelength 691 restriction, signal compatibility, etc.) associated with RWA. 693 6. Manageability Considerations 695 Manageability of WSON Routing and Wavelength Assignment (RWA) with 696 PCE must address the following considerations: 698 6.1. Control of Function and Policy 700 In addition to the parameters already listed in Section 8.1 of 701 [RFC5440], a PCEP implementation SHOULD allow configuring the 702 following PCEP session parameters on a PCC: 704 . The ability to send a WSON RWA request. 706 In addition to the parameters already listed in Section 8.1 of 707 [RFC5440], a PCEP implementation SHOULD allow configuring the 708 following PCEP session parameters on a PCE: 710 . The support for WSON RWA. 712 . A set of WSON RWA specific policies (authorized sender, 713 request rate limiter, etc). 715 These parameters may be configured as default parameters for any 716 PCEP session the PCEP speaker participates in, or may apply to a 717 specific session with a given PCEP peer or a specific group of 718 sessions with a specific group of PCEP peers. 720 6.2. Information and Data Models 722 Extensions to a MIB or a YANG model should be defined, so as to 723 cover the WSON RWA information introduced in this document. 725 6.3. Liveness Detection and Monitoring 727 Mechanisms defined in this document do not imply any new liveness 728 detection and monitoring requirements in addition to those already 729 listed in section 8.3 of [RFC5440]. 731 6.4. Verifying Correct Operation 733 Mechanisms defined in this document do not imply any new 734 verification requirements in addition to those already listed in 735 section 8.4 of [RFC5440] 737 6.5. Requirements on Other Protocols and Functional Components 739 The PCEP Link-State mechanism [PCEP-LS] may be used to advertise 740 WSON RWA path computation capabilities to PCCs. 742 6.6. Impact on Network Operation 744 Mechanisms defined in this document do not imply any new network 745 operation requirements in addition to those already listed in 746 section 8.6 of [RFC5440]. 748 7. Security Considerations 750 The security considerations discussed in [RFC5440] are relevant for 751 this document, this document does not introduce any new security 752 issues. If an operator wishes to keep private the information 753 distributed by WSON, PCEPS [RFC8253] SHOULD be used. 755 8. IANA Considerations 757 IANA maintains a registry of PCEP parameters. IANA has made 758 allocations from the sub-registries as described in the following 759 sections. 761 8.1. New PCEP Object 763 As described in Section 4.1, a new PCEP Object is defined to carry 764 wavelength assignment related constraints. IANA is to allocate the 765 following from "PCEP Objects" sub-registry 766 (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-objects): 768 Object Class Name Object Reference 769 Value Type 770 --------------------------------------------------------- 772 TDB WA 1: Wavelength-Assignment [This.I-D] 774 8.2. New PCEP TLV: Wavelength Selection TLV 776 As described in Sections 4.2, a new PCEP TLV is defined to indicate 777 wavelength selection constraints. IANA is to allocate this new TLV 778 from the "PCEP TLV Type Indicators" subregistry 779 (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type- 780 indicators). 782 Value Description Reference 783 --------------------------------------------------------- 784 TBD Wavelength Selection [This.I-D] 786 8.3. New PCEP TLV: Wavelength Restriction Constraint TLV 788 As described in Sections 4.3, a new PCEP TLV is defined to indicate 789 wavelength restriction constraints. IANA is to allocate this new TLV 790 from the "PCEP TLV Type Indicators" subregistry 791 (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type- 792 indicators). 794 Value Description Reference 795 --------------------------------------------------------- 796 TBD Wavelength Restriction [This.I-D] 797 Constraint 799 8.4. New PCEP TLV: Wavelength Allocation TLV 801 As described in Section 5, a new PCEP TLV is defined to indicate the 802 allocation of wavelength(s) by the PCE in response to a request by 803 the PCC. IANA is to allocate this new TLV from the "PCEP TLV Type 804 Indicators" subregistry 805 (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type- 806 indicators). 808 Value Description Reference 809 --------------------------------------------------------- 810 TBD Wavelength Allocation [This.I-D] 812 8.5. New PCEP TLV: Optical Interface Class List TLV 814 As described in Section 4.3, a new PCEP TLV is defined to indicate 815 the optical interface class list. IANA is to allocate this new TLV 816 from the "PCEP TLV Type Indicators" subregistry 817 (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type- 818 indicators). 820 Value Description Reference 821 --------------------------------------------------------- 822 TBD Optical Interface [This.I-D] 823 Class List 825 8.6. New PCEP TLV: Client Signal TLV 827 As described in Section 4.3, a new PCEP TLV is defined to indicate 828 the client signal information. IANA is to allocate this new TLV from 829 the "PCEP TLV Type Indicators" subregistry 830 (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type- 831 indicators). 833 Value Description Reference 834 --------------------------------------------------------- 835 TBD Client Signal Information [This.I-D] 837 8.7. New No-Path Reasons 839 As described in Section 5.2., a new bit flag are defined to be 840 carried in the Flags field in the NO-PATH-VECTOR TLV carried in the 841 NO-PATH Object. This flag, when set, indicates that no feasible 842 route was found that meets all the RWA constraints (e.g., wavelength 843 restriction, signal compatibility, etc.) associated with a RWA path 844 computation request. 846 IANA is to allocate this new bit flag from the "PCEP NO-PATH-VECTOR 847 TLV Flag Field" subregistry 848 (http://www.iana.org/assignments/pcep/pcep.xhtml#no-path-vector- 849 tlv). 851 Bit Description Reference 852 ----------------------------------------------------- 853 TBD No RWA constraints met [This.I-D] 855 8.8. New Error-Types and Error-Values 857 As described in Section 5.1, new PCEP error codes are defined for 858 WSON RWA errors. IANA is to allocate from the ""PCEP-ERROR Object 859 Error Types and Values" sub-registry 860 (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-error-object). 862 Error- Meaning Error-Value Reference 863 Type 864 --------------------------------------------------------------- 866 TDB WSON RWA Error 1: Insufficient [This.I-D] 867 Memory 869 2: RWA computation {This.I-D] 870 Not supported 872 9. Acknowledgments 874 The authors would like to thank Adrian Farrel for many helpful 875 comments that greatly improved the contents of this draft. 877 This document was prepared using 2-Word-v2.0.template.dot. 879 10. References 881 10.1. Normative References 883 [PCEP-GMPLS] C. Margaria, et al., "PCEP extensions for GMPLS", 884 draft-ietf-pce-gmpls-pcep-extensions, work in progress. 886 [RFC5440] JP. Vasseur, Ed., JL. Le Roux, Ed., "Path Computation 887 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 888 March 2009. 890 [RFC7570] C. Margaria, et al., "Label Switched Path (LSP) Attribute 891 in the Explicit Route Object (ERO)", RFC 7570, July 2015. 893 [RFC7689] Bernstein et al., "Signaling Extensions for Wavelength 894 Switched Optical Networks", RFC 7689, November 2015. 896 [RFC7688] Y. Lee, and G. Bernstein, "OSPF Enhancement for Signal and 897 Network Element Compatibility for Wavelength Switched 898 Optical Networks", RFC 7688, November 2015. 900 10.2. Informative References 902 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 903 Requirement Levels", BCP 14, RFC 2119, March 1997. 905 [RFC3471] Berger, L. (Editor), "Generalized Multi-Protocol Label 906 Switching (GMPLS) Signaling Functional Description", RFC 907 3471. January 2003. 909 [RFC3630] D. Katz, K. Kompella, D. Yeung, "Traffic Engineering (TE) 910 Extensions to OSPF Version 2", RFC 3630, September 2003. 912 [RFC4203] K. Kompella, Ed., Y. Rekhter, Ed., " OSPF Extensions in 913 Support of Generalized Multi-Protocol Label Switching 914 (GMPLS)", RFC 4203, October 2005. 916 [RFC5329] A. Lindem, Ed., "Traffic Engineering Extensions to OSPF 917 Version 3", RFC 5329, September 2008. 919 [RFC5420] Farrel, A. "Encoding of Attributes for MPLS LSP 920 Establishment Using Resource Reservation Protocol Traffic 921 Engineering (RSVP-TE)", RFC5420, February 2009. 923 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 924 Element (PCE) communication Protocol", RFC 5440, March 925 2009.[RFC5521] Oki, E, T. Takeda, and A. Farrel, 926 "Extensions to the Path Computation Element Communication 927 Protocol (PCEP) for Route Exclusions", RFC 5521, April 928 2009. 930 [RFC6163] Lee, Y. and Bernstein, G. (Editors), and W. Imajuku, 931 "Framework for GMPLS and PCE Control of Wavelength 932 Switched Optical Networks", RFC 6163, March 2011. 934 [RFC6205] Tomohiro, O. and D. Li, "Generalized Labels for Lambda- 935 Switching Capable Label Switching Routers", RFC 6205, 936 January, 2011. 938 [RFC7446] Y. Lee, G. Bernstein. (Editors),"Routing and Wavelength 939 Assignment Information Model for Wavelength Switched 940 Optical Networks", RFC 7446, February 2015. 942 [RFC7581] G. Bernstein and Y. Lee, "Routing and Wavelength 943 Assignment Information Encoding for Wavelength Switched 944 Optical Networks", RFC7581, June 2015. 946 [RFC7579] G. Bernstein and Y. Lee, "General Network Element 947 Constraint Encoding for GMPLS Controlled Networks", RFC 948 7579, June 2015. 950 [RFC8174] B. Leiba, "Ambiguity of Uppercase vs Lowercase in RFC 2119 951 Key Words", RFC 8174, May 2017. 953 [RFC8253] D. Lopez, O. Gonzalez de Dios, Q. Wu, D. Dhody, "PCEPS: 954 Usage of TLS to Provide a Secure Transport for the Path 955 Computation Element Communication Protocol (PCEP)", RFC 956 8253, October 2017. 958 [PCEP-LS] Y. Lee, et al., "PCEP Extension for Distribution of Link- 959 State and TE information for Optical Networks", draft-lee- 960 pce-pcep-ls-optical, work in progress. 962 11. Contributors 963 Authors' Addresses 965 Young Lee, Editor 966 Huawei Technologies 967 1700 Alma Drive, Suite 100 968 Plano, TX 75075, USA 969 Phone: (972) 509-5599 (x2240) 970 Email: leeyoung@huawei.com 972 Ramon Casellas, Editor 973 CTTC PMT Ed B4 Av. Carl Friedrich Gauss 7 974 08860 Castelldefels (Barcelona) 975 Spain 976 Phone: (34) 936452916 977 Email: ramon.casellas@cttc.es 979 Fatai Zhang 980 Huawei Technologies 981 Email: zhangfatai@huawei.com 983 Cyril Margaria 984 Nokia Siemens Networks 985 St Martin Strasse 76 986 Munich, 81541 987 Germany 988 Phone: +49 89 5159 16934 989 Email: cyril.margaria@nsn.com 991 Oscar Gonzalez de Dios 992 Telefonica Investigacion y Desarrollo 993 C/ Emilio Vargas 6 994 Madrid, 28043 995 Spain 996 Phone: +34 91 3374013 997 Email: ogondio@tid.es 999 Greg Bernstein 1000 Grotto Networking 1001 Fremont, CA, USA 1002 Phone: (510) 573-2237 1003 Email: gregb@grotto-networking.com