idnits 2.17.1 draft-ietf-pce-wson-rwa-ext-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 6, 2019) is 1898 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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: August 5, 2019 CTTC 7 February 6, 2019 9 PCEP Extension for WSON Routing and Wavelength Assignment 11 draft-ietf-pce-wson-rwa-ext-12 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 August 5, 2019. 46 Copyright Notice 48 Copyright (c) 2019 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.....................9 70 4.3.1. Link Identifier Field...............................11 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..........15 74 4.4.2. IRO sub-object: signal processing inclusion.........16 75 5. Encoding of a RWA Path Reply..................................16 76 5.1. Error Indicator..........................................18 77 5.2. NO-PATH Indicator........................................18 78 6. Manageability Considerations..................................19 79 6.1. Control of Function and Policy...........................19 80 6.2. Liveness Detection and Monitoring........................19 81 6.3. Verifying Correct Operation..............................19 82 6.4. Requirements on Other Protocols and Functional Components20 83 6.5. Impact on Network Operation..............................20 84 7. Security Considerations.......................................20 85 8. IANA Considerations...........................................20 86 8.1. New PCEP Object..........................................20 87 8.2. New PCEP TLV: Wavelength Selection TLV...................21 88 8.3. New PCEP TLV: Wavelength Restriction Constraint TLV......21 89 8.4. New PCEP TLV: Wavelength Allocation TLV..................21 90 8.5. New PCEP TLV: Optical Interface Class List TLV...........22 91 8.6. New PCEP TLV: Client Signal TLV..........................22 92 8.7. New No-Path Reasons......................................22 93 8.8. New Error-Types and Error-Values.........................23 94 8.9. New Sub-object for the Exclude Route Object..............23 95 8.10. New Sub-object for the Include Route Object.............24 96 9. Acknowledgments...............................................24 97 10. References...................................................24 98 10.1. Normative References....................................24 99 10.2. Informative References..................................25 100 11. Contributors.................................................27 101 Authors' Addresses...............................................28 103 1. Terminology 105 This document uses the terminology defined in [RFC4655], and 106 [RFC5440]. 108 2. Requirements Language 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 112 "OPTIONAL" in this document are to be interpreted as described in 113 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 114 capitals, as shown here. 116 3. Introduction 118 [RFC5440] specifies the Path Computation Element (PCE) Communication 119 Protocol (PCEP) for communications between a Path Computation Client 120 (PCC) and a PCE, or between two PCEs. Such interactions include 121 path computation requests and path computation replies as well as 122 notifications of specific states related to the use of a PCE in the 123 context of Multiprotocol Label Switching (MPLS) and Generalized MPLS 124 (GMPLS) Traffic Engineering. 126 A PCC is said to be any network component that makes such a request 127 and may be, for instance, an Optical Switching Element within a 128 Wavelength Division Multiplexing (WDM) network. The PCE, itself, 129 can be located anywhere within the network, and may be within an 130 optical switching element, a Network Management System (NMS) or 131 Operational Support System (OSS), or may be an independent network 132 server. 134 This document provides the PCEP extensions for the support of 135 Routing and Wavelength Assignment (RWA) in Wavelength Switched 136 Optical Networks (WSON) based on the requirements specified in 137 [RFC6163] and [RFC7449]. 139 WSON refers to WDM based optical networks in which switching is 140 performed selectively based on the wavelength of an optical signal. 141 The devices used in WSONs that are able to switch signals based on 142 signal wavelength are known as Lambda Switch Capable (LSC). WSONs 143 can be transparent or translucent. A transparent optical network is 144 made up of optical devices that can switch but not convert from one 145 wavelength to another, all within the optical domain. On the other 146 hand, translucent networks include 3R regenerators (Re- 147 amplification, Re-shaping, Re-timing) that are sparsely placed. The 148 main function of the 3R regenerators is to convert one optical 149 wavelength to another. 151 A Lambda Switch Capable (LSC) Label Switched Path (LSP) may span one 152 or several transparent segments, which are delimited by 3R 153 regenerators typically with electronic regenerator and optional 154 wavelength conversion. Each transparent segment or path in WSON is 155 referred to as an optical path. An optical path may span multiple 156 fiber links and the path should be assigned the same wavelength for 157 each link. In such case, the optical path is said to satisfy the 158 wavelength-continuity constraint. Figure 1 illustrates the 159 relationship between a LSC LSP and transparent segments (optical 160 paths). 162 +---+ +-----+ +-----+ +-----+ +-----+ 163 | |I1 | | | | | | I2| | 164 | |o------| |-------[(3R) ]------| |--------o| | 165 | | | | | | | | | | 166 +---+ +-----+ +-----+ +-----+ +-----+ 167 (X LSC) (LSC LSC) (LSC LSC) (LSC X) 168 <-------> <-------> <-----> <-------> 169 <-----------------------><----------------------> 170 Transparent Segment Transparent Segment 171 <-------------------------------------------------> 172 LSC LSP 174 Figure 1 Illustration of a LSC LSP and transparent segments 175 Note that two optical paths within a WSON LSP do not need to operate 176 on the same wavelength (due to the wavelength conversion 177 capabilities). Two optical paths that share a common fiber link 178 cannot be assigned the same wavelength; Otherwise, the two signals 179 would interfere with each other. Note that advanced additional 180 multiplexing techniques such as polarization based multiplexing are 181 not addressed in this document since the physical layer aspects are 182 not currently standardized. Therefore, assigning the proper 183 wavelength on a path is an essential requirement in the optical path 184 computation process. 186 When a switching node has the ability to perform wavelength 187 conversion, the wavelength-continuity constraint can be relaxed, and 188 a LSC Label Switched Path (LSP) may use different wavelengths on 189 different links along its route from origin to destination. It is, 190 however, to be noted that wavelength converters may be limited due 191 to their relatively high cost, while the number of WDM channels that 192 can be supported in a fiber is also limited. As a WSON can be 193 composed of network nodes that cannot perform wavelength conversion, 194 nodes with limited wavelength conversion, and nodes with full 195 wavelength conversion abilities, wavelength assignment is an 196 additional routing constraint to be considered in all optical path 197 computation. 199 For example (see Figure 1), within a translucent WSON, a LSC LSP may 200 be established between interfaces I1 and I2, spanning 2 transparent 201 segments (optical paths) where the wavelength continuity constraint 202 applies (i.e. the same unique wavelength must be assigned to the LSP 203 at each TE link of the segment). If the LSC LSP induced a Forwarding 204 Adjacency / TE link, the switching capabilities of the TE link would 205 be (X X) where X refers to the switching capability of I1 and I2. 206 For example, X can be Packet Switch Capable (PSC), Time Division 207 Multiplexing (TDM), etc. 209 This document aligns with GMPLS extensions for PCEP [PCEP-GMPLS] for 210 generic properties such as label, label-set and label assignment 211 noting that wavelength is a type of label. Wavelength restrictions 212 and constraints are also formulated in terms of labels per 213 [RFC7579]. 215 The optical modulation properties, which are also referred to as 216 signal compatibility, are already considered in signaling in 217 [RFC7581] and [RFC7688]. In order to improve the signal quality and 218 limit some optical effects several advanced modulation processing 219 capabilities are used. These modulation capabilities contribute not 220 only to optical signal quality checks but also constrain the 221 selection of sender and receiver, as they should have matching 222 signal processing capabilities. This document includes signal 223 compatibility constraints as part of RWA path computation. That is, 224 the signal processing capabilities (e.g., modulation and Forward 225 Error Correction (FEC)) indicated by means of optical interface 226 class (OIC) must be compatible between the sender and the receiver 227 of the optical path across all optical elements. 229 This document, however, does not address optical impairments as part 230 of RWA path computation. See [RFC6566] for the framework for optical 231 impairments. 233 4. Encoding of a RWA Path Request 235 Figure 2 shows one typical PCE based implementation, which is 236 referred to as the Combined Process (R&WA). With this architecture, 237 the two processes of routing and wavelength assignment are accessed 238 via a single PCE. This architecture is the base architecture 239 specified in [RFC6163] and the PCEP extensions that are specified in 240 this document are based on this architecture. 242 +----------------------------+ 243 +-----+ | +-------+ +--+ | 244 | | | |Routing| |WA| | 245 | PCC |<----->| +-------+ +--+ | 246 | | | | 247 +-----+ | PCE | 248 +----------------------------+ 250 Figure 2 Combined Process (R&WA) architecture 252 4.1. Wavelength Assignment (WA) Object 254 Wavelength allocation can be performed by the PCE by different 255 means: 257 (a) By means of Explicit Label Control [RFC3471] where the PCE 258 allocates which label to use for each interface/node along the path. 259 The allocated labels MAY appear after an interface route subobject. 261 (b) By means of a Label Set where the PCE provides a range of 262 potential labels to allocate by each node along the path. 264 Option (b) allows distributed label allocation (performed during 265 signaling) to complete wavelength assignment. 267 Additionally, given a range of potential labels to allocate, the 268 request SHOULD convey the heuristic / mechanism used for the 269 allocation. 271 The format of a PCReq message per [RFC5440] after incorporating the 272 Wavelength Assignment (WA) object is as follows: 274 ::= 276 [] 278 280 Where: 282 ::=[] 284 ::= 286 288 290 [other optional objects...] 292 If the WA object is present in the request, it MUST be encoded after 293 the END-POINTS object as defined in [PCEP-GMPLS]. The WA Object is 294 mandatory in this document. Orderings for the other optional objects 295 are irrelevant. 297 The format of the WA object body is as follows: 299 0 1 2 3 300 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 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | Reserved | Flags |M| 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | | 305 | Wavelength Selection TLV | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | Wavelength Restriction Constraint TLV | 308 . . 310 . . 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 Figure 3 WA Object 315 o Reserved (16 bits): Reserved for future use and SHOULD be zeroed 316 and ignored on receipt. 318 o Flags (16 bits) 320 One flag bit is allocated as follows: 322 . M (Mode - 1 bit): M bit is used to indicate the mode of 323 wavelength assignment. When M bit is set to 1, this indicates 324 that the label assigned by the PCE must be explicit. That is, 325 the selected way to convey the allocated wavelength is by means 326 of Explicit Label Control for each hop of a computed LSP. 327 Otherwise (M bit is set to 0), the label assigned by the PCE 328 need not be explicit (i.e., it can be suggested in the form of 329 label set objects in the corresponding response, to allow 330 distributed WA. If M is 0, the PCE MUST return a Label Set 331 Field as described in Section 2.6 of [RFC7579] in the response. 332 See Section 5 of this document for the encoding discussion of a 333 Label Set Field in a PCRep message. 335 All unused flags SHOULD be zeroed. 337 . Wavelength Selection TLV (32 bits): See Section 4.2 for 338 details. 340 . Wavelength Restriction Constraint TLV (Variable): See Section 341 4.3 for details. 343 4.2. Wavelength Selection TLV 345 The Wavelength Selection TLV is used to indicate the wavelength 346 selection constraint in regard to the order of wavelength assignment 347 to be returned by the PCE. This TLV is only applied when M bit is 348 set in the WA Object specified in Section 4.1. This TLV MUST NOT be 349 used when the M bit is cleared. 351 The encoding of this TLV is specified as the Wavelength Selection 352 Sub-TLV in Section 4.2.2 of [RFC7689]. 354 4.3. Wavelength Restriction Constraint TLV 356 For any request that contains a wavelength assignment, the requester 357 (PCC) MUST be able to specify a restriction on the wavelengths to be 358 used. This restriction is to be interpreted by the PCE as a 359 constraint on the tuning ability of the origination laser 360 transmitter or on any other maintenance related constraints. Note 361 that if the LSP LSC spans different segments, the PCE MUST have 362 mechanisms to know the tunability restrictions of the involved 363 wavelength converters / regenerators, e.g. by means of the Traffic 364 Engineering Database (TED) either via IGP or Network Management 365 System (NMS). Even if the PCE knows the tunability of the 366 transmitter, the PCC MUST be able to apply additional constraints to 367 the request. 369 The format of the Wavelength Restriction Constraint TLV is as 370 follows: 372 ::= 374 376 ( )... 378 Where 380 ::= [] 382 See Section 4.3.1. for the encoding of the Link Identifiers Field. 384 and fields together MAY 385 appear more than once to be able to specify multiple restrictions. 387 The Wavelength Restriction Constraint TLV type is TBD3 (See Section 388 8.3). 390 The TLV data is defined as follows: 392 0 1 2 3 393 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 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | Action | Count | Reserved | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | Link Identifiers | 398 | . . . | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | Wavelength Restriction Field | 401 // . . . . // 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 Figure 4 Wavelength Restriction Constraint TLV Encoding 406 o Action (8 bits): 408 . 0 - Inclusive List indicates that one or more link identifiers 409 are included in the Link Set. Each identifies a separate link 410 that is part of the set. 412 . 1 - Inclusive Range indicates that the Link Set defines a 413 range of links. It contains two link identifiers. The first 414 identifier indicates the start of the range (inclusive). The 415 second identifier indicates the end of the range (inclusive). 416 All links with numeric values between the bounds are 417 considered to be part of the set. A value of zero in either 418 position indicates that there is no bound on the corresponding 419 portion of the range. 421 . 2-255 - For future use 423 Note that "links" are assumed to be bidirectional. 425 o Count (8 bits): The number of the link identifiers 427 Note that a PCC MAY add a Wavelength restriction that applies to all 428 links by setting the Count field to zero and specifying just a set 429 of wavelengths. 431 Note that all link identifiers in the same list must be of the same 432 type. 434 o Reserved (16 bits): Reserved for future use and SHOULD be zeroed 435 and ignored on receipt. 437 o Link Identifiers: Identifies each link ID for which restriction 438 is applied. The length is dependent on the link format and the Count 439 field. See Section 4.3.1. for Link Identifier encoding and Section 440 4.3.2. for the Wavelength Restriction Field encoding, respectively. 442 Various encoding errors are possible with this TLV (e.g., not 443 exactly two link identifiers with the range case, unknown identifier 444 types, no matching link for a given identifier, etc.). To indicate 445 errors associated with this type, a new Error-Type (TBD8) and an 446 Error-value (Error-value=3) are assigned so that the PCE MUST send a 447 PCErr message with a PCEP-ERROR Object. See Section 5.1 for the 448 details. 450 4.3.1. Link Identifier Field 452 The link identifier field can be an IPv4 [RFC3630], IPv6 [RFC5329] 453 or unnumbered interface ID [RFC4203]. 455 ::= 457 | | 459 The encoding of each case is as follows: 461 IPv4 prefix sub-TLV 463 0 1 2 3 464 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 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | Type = 1 | Reserved (16 bits) | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 | IPv4 address (4 bytes) | 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 IPv6 prefix Sub-TLV 473 0 1 2 3 474 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 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 | Type = 2 | Reserved (16 bits) | 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 | IPv6 address (16 bytes) | 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | IPv6 address (continued) | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 | IPv6 address (continued) | 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | IPv6 address (continued) | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 Unnumbered Interface ID Sub-TLV 489 0 1 2 3 490 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 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 | Type = 3 | Reserved (16 bits) | 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 | TE Node ID (32 bits) | 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 | Interface ID (32 bits) | 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 Type (8 bits): It indicates the type of the link identifier. 501 Reserved (16 bits): Reserved for future use and SHOULD be zeroed 502 and ignored on receipt. 504 4.3.2. Wavelength Restriction Field 506 The Wavelength Restriction Field of the wavelength restriction TLV 507 is encoded as a Label Set field as specified in Section 2.6 in 508 [RFC7579] with base label encoded as a 32 bit LSC label, defined in 509 [RFC6205]. The Label Set format is repeated here for convenience, 510 with the base label internal structure included. See [RFC6205] for a 511 description of Grid, C.S, Identifier and n, as well as [RFC7579] for 512 the details of each action. 514 0 1 2 3 516 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 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 | Action| Num Labels | Length | 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 |Grid | C.S | Identifier | n | 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 | Additional fields as necessary per action | 523 | | 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 Action (4 bits): 528 0 - Inclusive List 530 1 - Exclusive List 532 2 - Inclusive Range 534 3 - Exclusive Range 536 4 - Bitmap Set 538 Num Labels (12 bits): It is generally the number of labels. It has a 539 specific meaning depending on the action value. 541 Length (16 bits): It is the length in bytes of the entire Wavelength 542 Restriction field. 544 See Sections 2.6.1 - 2.6.3 of [RFC7579] for details on additional 545 field discussion for each action. 547 4.4. Signal processing capability restrictions 549 Path computation for WSON includes checking of signal processing 550 capabilities at each interface against requested capability; the PCE 551 MUST have mechanisms to know the signal processing capabilities at 552 each interface, e.g. by means of the Traffic Engineering Database 553 (TED) either via IGP or Network Management System (NMS). Moreover, 554 a PCC should be able to indicate additional restrictions to signal 555 processing compatibility, either on the endpoint or any given link. 557 The supported signal processing capabilities considered in the RWA 558 Information Model [RFC7446] are: 560 . Optical Interface Class List 562 . Bit Rate 564 . Client Signal 566 The Bit Rate restriction is already expressed in [PCEP-GMPLS] in the 567 BANDWIDTH object. 569 In order to support the Optical Interface Class information and the 570 Client Signal information new TLVs are introduced as endpoint- 571 restriction in the END-POINTS type Generalized endpoint: 573 . Client Signal TLV 575 . Optical Interface Class List TLV 577 The END-POINTS type generalized endpoint is extended as follows: 579 ::= 581 583 [...] 585 Where 587 signal-compatibility-restriction ::= 589 591 The encoding for the Optical Interface Class List (TBD5) is 592 described in Section 4.1 of [RFC7581]. 594 The encoding for the Client Signal Information (TBD6) is described 595 in Section 4.2 of [RFC7581]. 597 4.4.1. Signal Processing Exclusion XRO Sub-Object 599 The PCC/PCE should be able to exclude particular types of signal 600 processing along the path in order to handle client restriction or 601 multi-domain path computation. [RFC5440] defines how Exclude Route 602 Object (XRO) sub-object is used. In this draft, we add a new XRO 603 sub-object, signal processing sub-object. 605 In order to support the exclusion a new XRO sub-object is defined: 606 the signal processing exclusion: 608 0 1 2 3 610 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 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 |X| Type =TBD | Length | Reserved | Attribute | 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 | sub-sub objects | 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 Figure 5 Signaling Processing XRO Sub-Object 619 Refer to [RFC5521] for the definition of X, Length and Attribute. 621 Type (7 bits): The Type of the XRO sub-sub objects. See below for 622 the two TBD values (TBD9 and TBD10) to be assigned by the IANA. 624 Reserved bits (8 bits) are for future use and SHOULD be zeroed and 625 ignored on receipt. 627 The Attribute field (8 bits): [RFC5521] defines several Attribute 628 values; the only permitted Attribute values for this sub-object are 629 0 (Interface) or 1 (Node). 631 The permitted sub-sub objects are the Optical Interface Class List 632 and the Client Signal information whose encodings are described in 633 Section 4.1 and Section 4.2 of [RFC7581], respectively. 635 The XRO needs to support the new sub-object types: 637 Type Sub-sub object 639 TBD9 Optical Interface Class List 641 TBD10 Client Signal Information 643 4.4.2. IRO sub-object: signal processing inclusion 645 Similar to the XRO sub-object, the PCC/PCE should be able to include 646 particular types of signal processing along the path in order to 647 handle client restriction or multi-domain path computation. 648 [RFC5440] defines how Include Route Object (IRO) sub-object is used. 649 In this draft, we add a new IRO sub-object, signal processing sub- 650 object. 652 The IRO needs to support the new sub-object types as defined in 653 Section 4.2 [RFC7689] "WSON Processing Hop Attribute TLV" (TBD9) 654 defined for ERO in Section 4.2 [RFC7689] to the PCEP IRO object 655 [RFC5440]: 657 Type Sub-sub-object 659 TBD11 Optical Interface Class List 661 TBD12 Client Signal Information 663 5. Encoding of a RWA Path Reply 665 This section provides the encoding of a RWA Path Reply for 666 wavelength allocation request as discussed in Section 4. Recall that 667 wavelength allocation can be performed by the PCE by different 668 means: 670 (a) By means of Explicit Label Control (ELC) where the PCE 671 allocates which label to use for each interface/node along the 672 path. 673 (b) By means of a Label Set where the PCE provides a range of 674 potential labels to allocate by each node along the path. 676 Option (b) allows distributed label allocation (performed during 677 signaling) to complete wavelength allocation. 679 The Wavelength Allocation TLV type is TBD4 (See Section 8.4). Note 680 that this TLV is used for both (a) and (b). The TLV data is defined 681 as follows: 683 0 1 2 3 684 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 685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 686 | Reserved |M| 687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 688 | Link Identifier | 689 | . . . | 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 691 | Allocated Wavelength(s) | 692 // . . . . // 693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 695 Figure 6 Wavelength Allocation TLV Encoding 697 o Reserved (15 bits): Reserved for future use. 699 o M (Mode): 1 bit 701 - 0 indicates the allocation is under Explicit Label Control. 703 - 1 indicates the allocation is expressed in Label Sets. 705 Note that all link identifiers in the same list must be of the same 706 type. 708 o Link Identifier: Identifies the interface to which assignment 709 wavelength(s) is applied. See Section 4.3.1. for Link Identifier 710 encoding. 712 o Allocated Wavelength(s): Indicates the allocated wavelength(s) to 713 be associated with the Link Identifier. See Section 4.3.2 for 714 encoding details. 716 This TLV is encoded as an attributes TLV, per [RFC5420], which is 717 carried in the Hop Attribute Subobjects per [RFC7570]. 719 5.1. Error Indicator 721 To indicate errors associated with the RWA request, a new Error Type 722 (TBD8) and subsequent error-values are defined as follows for 723 inclusion in the PCEP-ERROR Object: 725 A new Error-Type (TBD8) and subsequent error-values are defined as 726 follows: 728 . Error-Type=TBD8; Error-value=1: if a PCE receives a RWA 729 request and the PCE is not capable of processing the request 730 due to insufficient memory, the PCE MUST send a PCErr message 731 with a PCEP-ERROR Object (Error-Type=TBD8) and an Error- 732 value(Error-value=1). The PCE stops processing the request. 733 The corresponding RWA request MUST be cancelled at the PCC. 735 . Error-Type=TBD8; Error-value=2: if a PCE receives a RWA 736 request and the PCE is not capable of RWA computation, the PCE 737 MUST send a PCErr message with a PCEP-ERROR Object (Error- 738 Type=TBD8) and an Error-value (Error-value=2). The PCE stops 739 processing the request. The corresponding RWA computation 740 MUST be cancelled at the PCC. 742 . Error-Type=TBD8; Error-value=3: if a PCE receives a RWA 743 request and there are syntactical encoding errors (e.g., not 744 exactly two link identifiers with the range case, unknown 745 identifier types, no matching link for a given identifier, 746 etc.), the PCE MUST send a PCErr message with a PCEP-ERROR 747 Object (Error-Type=TBD8) and an Error-value (Error-value=3). 749 5.2. NO-PATH Indicator 751 To communicate the reason(s) for not being able to find RWA for the 752 path request, the NO-PATH object can be used in the corresponding 753 response. The format of the NO-PATH object body is defined in 754 [RFC5440]. The object may contain a NO-PATH-VECTOR TLV to provide 755 additional information about why a path computation has failed. 757 One new bit flag is defined to be carried in the Flags field in the 758 NO-PATH-VECTOR TLV carried in the NO-PATH Object. 760 . Bit TBD7: When set, the PCE indicates no feasible route was 761 found that meets all the constraints (e.g., wavelength 762 restriction, signal compatibility, etc.) associated with RWA. 764 6. Manageability Considerations 766 Manageability of WSON Routing and Wavelength Assignment (RWA) with 767 PCE must address the following considerations: 769 6.1. Control of Function and Policy 771 In addition to the parameters already listed in Section 8.1 of 772 [RFC5440], a PCEP implementation SHOULD allow configuration of the 773 following PCEP session parameters on a PCC: 775 . The ability to send a WSON RWA request. 777 In addition to the parameters already listed in Section 8.1 of 778 [RFC5440], a PCEP implementation SHOULD allow configuration of the 779 following PCEP session parameters on a PCE: 781 . The support for WSON RWA. 783 . A set of WSON RWA specific policies (authorized sender, 784 request rate limiter, etc). 786 These parameters may be configured as default parameters for any 787 PCEP session the PCEP speaker participates in, or may apply to a 788 specific session with a given PCEP peer or a specific group of 789 sessions with a specific group of PCEP peers. 791 6.2. Liveness Detection and Monitoring 793 Mechanisms defined in this document do not imply any new liveness 794 detection and monitoring requirements in addition to those already 795 listed in section 8.3 of [RFC5440]. 797 6.3. Verifying Correct Operation 799 Mechanisms defined in this document do not imply any new 800 verification requirements in addition to those already listed in 801 section 8.4 of [RFC5440] 803 6.4. Requirements on Other Protocols and Functional Components 805 The PCEP Link-State mechanism [PCEP-LS] may be used to advertise 806 WSON RWA path computation capabilities to PCCs. 808 6.5. Impact on Network Operation 810 Mechanisms defined in this document do not imply any new network 811 operation requirements in addition to those already listed in 812 section 8.6 of [RFC5440]. 814 7. Security Considerations 816 The security considerations discussed in [RFC5440] are relevant for 817 this document, this document does not introduce any new security 818 issues. If an operator wishes to keep private the information 819 distributed by WSON, PCEPS [RFC8253] SHOULD be used. 821 8. IANA Considerations 823 IANA maintains a registry of PCEP parameters. IANA has made 824 allocations from the sub-registries as described in the following 825 sections. 827 8.1. New PCEP Object 829 As described in Section 4.1, a new PCEP Object is defined to carry 830 wavelength assignment related constraints. IANA is to allocate the 831 following from "PCEP Objects" sub-registry 832 (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-objects): 834 Object Class Name Object Reference 835 Value Type 836 --------------------------------------------------------- 838 TBD1 WA 1: Wavelength-Assignment [This.I-D] 840 8.2. New PCEP TLV: Wavelength Selection TLV 842 As described in Sections 4.2, a new PCEP TLV is defined to indicate 843 wavelength selection constraints. IANA is to allocate this new TLV 844 from the "PCEP TLV Type Indicators" subregistry 845 (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type- 846 indicators). 848 Value Description Reference 849 --------------------------------------------------------- 850 TBD2 Wavelength Selection [This.I-D] 852 8.3. New PCEP TLV: Wavelength Restriction Constraint TLV 854 As described in Sections 4.3, a new PCEP TLV is defined to indicate 855 wavelength restriction constraints. IANA is to allocate this new TLV 856 from the "PCEP TLV Type Indicators" subregistry 857 (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type- 858 indicators). 860 Value Description Reference 861 --------------------------------------------------------- 862 TBD3 Wavelength Restriction [This.I-D] 863 Constraint 865 8.4. New PCEP TLV: Wavelength Allocation TLV 867 As described in Section 5, a new PCEP TLV is defined to indicate the 868 allocation of wavelength(s) by the PCE in response to a request by 869 the PCC. IANA is to allocate this new TLV from the "PCEP TLV Type 870 Indicators" subregistry 871 (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type- 872 indicators). 874 Value Description Reference 875 --------------------------------------------------------- 876 TBD4 Wavelength Allocation [This.I-D] 878 8.5. New PCEP TLV: Optical Interface Class List TLV 880 As described in Section 4.4, a new PCEP TLV is defined to indicate 881 the optical interface class list. IANA is to allocate this new TLV 882 from the "PCEP TLV Type Indicators" subregistry 883 (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type- 884 indicators). 886 Value Description Reference 887 --------------------------------------------------------- 888 TBD5 Optical Interface [This.I-D] 889 Class List 891 8.6. New PCEP TLV: Client Signal TLV 893 As described in Section 4.4, a new PCEP TLV is defined to indicate 894 the client signal information. IANA is to allocate this new TLV from 895 the "PCEP TLV Type Indicators" subregistry 896 (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type- 897 indicators). 899 Value Description Reference 900 --------------------------------------------------------- 901 TBD6 Client Signal Information [This.I-D] 903 8.7. New No-Path Reasons 905 As described in Section 5.2., a new bit flag are defined to be 906 carried in the Flags field in the NO-PATH-VECTOR TLV carried in the 907 NO-PATH Object. This flag, when set, indicates that no feasible 908 route was found that meets all the RWA constraints (e.g., wavelength 909 restriction, signal compatibility, etc.) associated with a RWA path 910 computation request. 912 IANA is to allocate this new bit flag from the "PCEP NO-PATH-VECTOR 913 TLV Flag Field" subregistry 914 (http://www.iana.org/assignments/pcep/pcep.xhtml#no-path-vector- 915 tlv). 917 Bit Description Reference 918 ----------------------------------------------------- 919 TBD7 No RWA constraints met [This.I-D] 921 8.8. New Error-Types and Error-Values 923 As described in Section 5.1, new PCEP error codes are defined for 924 WSON RWA errors. IANA is to allocate from the ""PCEP-ERROR Object 925 Error Types and Values" sub-registry 926 (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-error-object). 928 Error- Meaning Error-Value Reference 929 Type 930 --------------------------------------------------------------- 932 TBD8 WSON RWA Error 1: Insufficient [This.I-D] 933 Memory 935 2: RWA computation [This.I-D] 936 Not supported 938 3: Syntactical [This.I-D] 939 Encoding error 941 8.9. New Sub-object for the Exclude Route Object 943 The "PCEP Parameters" registry contains a subregistry "PCEP Objects" 944 with an entry for the Exclude Route Object (XRO). IANA is requested 945 to add a further subobject that can be carried in the XRO as 946 follows: 948 Sub-object Type Reference 950 ---------------------------------------------------------- 952 TBD9 Optical Interface Class List [This.I-D] 954 TBD10 Client Signal Information [This.I-D] 956 8.10. New Sub-object for the Include Route Object 958 The "PCEP Parameters" registry contains a subregistry "PCEP Objects" 959 with an entry for the Include Route Object (IRO). IANA is requested 960 to add a further subobject that can be carried in the IRO as 961 follows: 963 Sub-object Type Reference 965 ---------------------------------------------------------- 967 TBD11 Optical Interface Class List [This.I-D] 969 TBD12 Client Signal Information [This.I-D] 971 9. Acknowledgments 973 The authors would like to thank Adrian Farrel for many helpful 974 comments that greatly improved the contents of this draft. 976 This document was prepared using 2-Word-v2.0.template.dot. 978 10. References 980 10.1. Normative References 982 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 983 Requirement Levels", BCP 14, RFC 2119, March 1997. 985 [RFC3630] D. Katz, K. Kompella, D. Yeung, "Traffic Engineering (TE) 986 Extensions to OSPF Version 2", RFC 3630, September 2003. 988 [RFC5329] A. Lindem, Ed., "Traffic Engineering Extensions to OSPF 989 Version 3", RFC 5329, September 2008. 991 [RFC5440] JP. Vasseur, Ed., JL. Le Roux, Ed., "Path Computation 992 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 993 March 2009. 995 [RFC6205] Tomohiro, O. and D. Li, "Generalized Labels for Lambda- 996 Switching Capable Label Switching Routers", RFC 6205, 997 January, 2011. 999 [RFC7570] C. Margaria, et al., "Label Switched Path (LSP) Attribute 1000 in the Explicit Route Object (ERO)", RFC 7570, July 2015. 1002 [RFC7579] G. Bernstein and Y. Lee, "General Network Element 1003 Constraint Encoding for GMPLS Controlled Networks", RFC 1004 7579, June 2015. 1006 [RFC7581] G. Bernstein and Y. Lee, "Routing and Wavelength 1007 Assignment Information Encoding for Wavelength Switched 1008 Optical Networks", RFC7581, June 2015. 1010 [RFC7689] Bernstein et al., "Signaling Extensions for Wavelength 1011 Switched Optical Networks", RFC 7689, November 2015. 1013 [RFC7688] Y. Lee, and G. Bernstein, "OSPF Enhancement for Signal and 1014 Network Element Compatibility for Wavelength Switched 1015 Optical Networks", RFC 7688, November 2015. 1017 [RFC8174] B. Leiba, "Ambiguity of Uppercase vs Lowercase in RFC 2119 1018 Key Words", RFC 8174, May 2017. 1020 [PCEP-GMPLS] C. Margaria, et al., "PCEP extensions for GMPLS", 1021 draft-ietf-pce-gmpls-pcep-extensions, work in progress. 1023 10.2. Informative References 1025 [RFC3471] Berger, L. (Editor), "Generalized Multi-Protocol Label 1026 Switching (GMPLS) Signaling Functional Description", RFC 1027 3471. January 2003. 1029 [RFC4203] K. Kompella, Ed., Y. Rekhter, Ed., "OSPF Extensions in 1030 Support of Generalized Multi-Protocol Label Switching 1031 (GMPLS)", RFC 4203, October 2005. 1033 [RFC4655] A. Farrel, JP. Vasseur, G. Ash, "A Path Computation 1034 Element (PCE)-Based Architecture", RFC 4655, August 2006. 1036 [RFC5420] Farrel, A. "Encoding of Attributes for MPLS LSP 1037 Establishment Using Resource Reservation Protocol Traffic 1038 Engineering (RSVP-TE)", RFC5420, February 2009. 1040 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1041 Element (PCE) communication Protocol", RFC 5440, March 1042 2009.[RFC5521] Oki, E, T. Takeda, and A. Farrel, 1043 "Extensions to the Path Computation Element Communication 1044 Protocol (PCEP) for Route Exclusions", RFC 5521, April 1045 2009. 1047 [RFC6163] Lee, Y. and Bernstein, G. (Editors), and W. Imajuku, 1048 "Framework for GMPLS and PCE Control of Wavelength 1049 Switched Optical Networks", RFC 6163, March 2011. 1051 [RFC6566] Lee, Y. and Berstein, G. (Editors), "A Framework for the 1052 Control of Wavelength Switched Optical Networks (WSONs) 1053 with Impairments", RFC 6566, March 2012. 1055 [RFC7446] Y. Lee, G. Bernstein, (Editors), "Routing and Wavelength 1056 Assignment Information Model for Wavelength Switched 1057 Optical Networks", RFC 7446, February 2015. 1059 [RFC7449] Y. Lee, G. Bernstein, (Editors), "Path Computation Element 1060 Communication Protocol (PCEP) Requirements for Wavelength 1061 Switched Optical Network (WSON) Routing and Wavelength 1062 Assignment", RFC 7449, February 2015. 1064 [RFC8253] D. Lopez, O. Gonzalez de Dios, Q. Wu, D. Dhody, "PCEPS: 1065 Usage of TLS to Provide a Secure Transport for the Path 1066 Computation Element Communication Protocol (PCEP)", RFC 1067 8253, October 2017. 1069 [PCEP-LS] Y. Lee, et al., "PCEP Extension for Distribution of Link- 1070 State and TE information for Optical Networks", draft-lee- 1071 pce-pcep-ls-optical, work in progress. 1073 11. Contributors 1075 Fatai Zhang 1076 Huawei Technologies 1077 Email: zhangfatai@huawei.com 1079 Cyril Margaria 1080 Nokia Siemens Networks 1081 St Martin Strasse 76 1082 Munich, 81541 1083 Germany 1084 Phone: +49 89 5159 16934 1085 Email: cyril.margaria@nsn.com 1087 Oscar Gonzalez de Dios 1088 Telefonica Investigacion y Desarrollo 1089 C/ Emilio Vargas 6 1090 Madrid, 28043 1091 Spain 1092 Phone: +34 91 3374013 1093 Email: ogondio@tid.es 1095 Greg Bernstein 1096 Grotto Networking 1097 Fremont, CA, USA 1098 Phone: (510) 573-2237 1099 Email: gregb@grotto-networking.com 1101 Authors' Addresses 1103 Young Lee, Editor 1104 Huawei Technologies 1105 1700 Alma Drive, Suite 100 1106 Plano, TX 75075, USA 1107 Phone: (972) 509-5599 (x2240) 1108 Email: leeyoung@huawei.com 1110 Ramon Casellas, Editor 1111 CTTC PMT Ed B4 Av. Carl Friedrich Gauss 7 1112 08860 Castelldefels (Barcelona) 1113 Spain 1114 Phone: (34) 936452916 1115 Email: ramon.casellas@cttc.es