idnits 2.17.1 draft-ietf-pce-wson-rwa-ext-13.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 7, 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 6, 2019 CTTC 7 February 7, 2019 9 PCEP Extension for WSON Routing and Wavelength Assignment 11 draft-ietf-pce-wson-rwa-ext-13 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 6, 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................14 73 4.4.1. Signal Processing Exclusion XRO Subobject...........15 74 4.4.2. IRO subobject: 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..............................20 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 Subobject for the Exclude Route Object...............23 95 8.10. New Subobject 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 specify a restriction on the wavelengths to be used. This 358 restriction is to be interpreted by the PCE as a constraint on the 359 tuning ability of the origination laser transmitter or on any other 360 maintenance related constraints. Note that if the LSP LSC spans 361 different segments, the PCE must have mechanisms to know the 362 tunability restrictions of the involved wavelength converters / 363 regenerators, e.g. by means of the Traffic Engineering Database 364 (TED) either via IGP or Network Management System (NMS). Even if the 365 PCE knows the tunability of the transmitter, the PCC must be able to 366 apply additional constraints to the request. 368 The format of the Wavelength Restriction Constraint TLV is as 369 follows: 371 ::= 373 375 ( )... 377 Where 379 ::= [] 381 See Section 4.3.1. for the encoding of the Link Identifiers Field. 383 and fields together MAY 384 appear more than once to be able to specify multiple restrictions. 386 The Wavelength Restriction Constraint TLV type is TBD3 (See Section 387 8.3). 389 The TLV data is defined as follows: 391 0 1 2 3 392 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 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | Action | Count | Reserved | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | Link Identifiers | 397 | . . . | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | Wavelength Restriction Field | 400 // . . . . // 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 Figure 4 Wavelength Restriction Constraint TLV Encoding 405 o Action (8 bits): 407 . 0 - Inclusive List indicates that one or more link identifiers 408 are included in the Link Set. Each identifies a separate link 409 that is part of the set. 411 . 1 - Inclusive Range indicates that the Link Set defines a 412 range of links. It contains two link identifiers. The first 413 identifier indicates the start of the range (inclusive). The 414 second identifier indicates the end of the range (inclusive). 415 All links with numeric values between the bounds are 416 considered to be part of the set. A value of zero in either 417 position indicates that there is no bound on the corresponding 418 portion of the range. 420 . 2-255 - For future use 422 Note that "links" are assumed to be bidirectional. 424 o Count (8 bits): The number of the link identifiers 426 Note that a PCC MAY add a Wavelength restriction that applies to all 427 links by setting the Count field to zero and specifying just a set 428 of wavelengths. 430 Note that all link identifiers in the same list must be of the same 431 type. 433 o Reserved (16 bits): Reserved for future use and SHOULD be zeroed 434 and ignored on receipt. 436 o Link Identifiers: Identifies each link ID for which restriction 437 is applied. The length is dependent on the link format and the Count 438 field. See Section 4.3.1. for Link Identifier encoding and Section 439 4.3.2. for the Wavelength Restriction Field encoding, respectively. 441 Various encoding errors are possible with this TLV (e.g., not 442 exactly two link identifiers with the range case, unknown identifier 443 types, no matching link for a given identifier, etc.). To indicate 444 errors associated with this type, a new Error-Type (TBD8) and an 445 Error-value (Error-value=3) are assigned so that the PCE MUST send a 446 PCErr message with a PCEP-ERROR Object. See Section 5.1 for the 447 details. 449 4.3.1. Link Identifier Field 451 The link identifier field can be an IPv4 [RFC3630], IPv6 [RFC5329] 452 or unnumbered interface ID [RFC4203]. 454 ::= 456 | | 458 The encoding of each case is as follows: 460 IPv4 prefix sub-TLV 462 0 1 2 3 463 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 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 | Type = 1 | Reserved (16 bits) | 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 | IPv4 address (4 bytes) | 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 IPv6 prefix Sub-TLV 472 0 1 2 3 473 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 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 | Type = 2 | Reserved (16 bits) | 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 | IPv6 address (16 bytes) | 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 | IPv6 address (continued) | 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | IPv6 address (continued) | 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | IPv6 address (continued) | 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 Unnumbered Interface ID Sub-TLV 488 0 1 2 3 489 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 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | Type = 3 | Reserved (16 bits) | 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 | TE Node ID (32 bits) | 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 | Interface ID (32 bits) | 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 Type (8 bits): It indicates the type of the link identifier. 500 Reserved (16 bits): Reserved for future use and SHOULD be zeroed 501 and ignored on receipt. 503 The Type field is extensible. Please refer to the IANA registry 504 allocated for Link Management Protocol (LMP) [RFC4204]: 505 https://www.iana.org/assignments/lmp-parameters/lmp- 506 parameters.xhtml#lmp-parameters-15. 508 4.3.2. Wavelength Restriction Field 510 The Wavelength Restriction Field of the Wavelength Restriction 511 Constraint TLV is encoded as a Label Set field as specified in 512 Section 2.6 in [RFC7579] with base label encoded as a 32 bit LSC 513 label, defined in [RFC6205]. The Label Set format is repeated here 514 for convenience, with the base label internal structure included. 515 See [RFC6205] for a description of Grid, C.S, Identifier and n, as 516 well as [RFC7579] for the details of each action. 518 0 1 2 3 519 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 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 | Action| Num Labels | Length | 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 |Grid | C.S | Identifier | n | 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 | Additional fields as necessary per action | 527 | | 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 Action (4 bits): 532 0 - Inclusive List 534 1 - Exclusive List 536 2 - Inclusive Range 538 3 - Exclusive Range 540 4 - Bitmap Set 542 Num Labels (12 bits): It is generally the number of labels. It has a 543 specific meaning depending on the action value. 545 Length (16 bits): It is the length in bytes of the entire Wavelength 546 Restriction field. 548 The Identifier has a specific PCEP context. To clarify the 549 interpretation of the Identifier, the following additional 550 explanation is added. 552 Identifier (9 bits): The value to be included in the "Identifier" 553 field of the WDM label in RSVP-TE signaling, as defined in section 554 3.2 of [RFC6205]. The PCC MAY use the assigned value for the 555 Identifier field in the corresponding LSP-related messages in RSVP- 556 TE signaling. 558 See Sections 2.6.1 - 2.6.3 of [RFC7579] for details on additional 559 field discussion for each action. 561 4.4. Signal processing capability restrictions 563 Path computation for WSON includes checking of signal processing 564 capabilities at each interface against requested capability; the PCE 565 MUST have mechanisms to know the signal processing capabilities at 566 each interface, e.g. by means of the Traffic Engineering Database 567 (TED) either via IGP or Network Management System (NMS). Moreover, 568 a PCC should be able to indicate additional restrictions to signal 569 processing compatibility, either on the endpoint or any given link. 571 The supported signal processing capabilities considered in the RWA 572 Information Model [RFC7446] are: 574 . Optical Interface Class List 576 . Bit Rate 578 . Client Signal 580 The Bit Rate restriction is already expressed in [PCEP-GMPLS] in the 581 BANDWIDTH object. 583 In order to support the Optical Interface Class information and the 584 Client Signal information new TLVs are introduced as endpoint- 585 restriction in the END-POINTS type Generalized endpoint: 587 . Client Signal TLV 589 . Optical Interface Class List TLV 591 The END-POINTS type generalized endpoint is extended as follows: 593 ::= 595 597 [...] 599 Where 601 signal-compatibility-restriction ::= 602 604 The encoding for the Optical Interface Class List (TBD5) is 605 described in Section 4.1 of [RFC7581]. 607 The encoding for the Client Signal Information (TBD6) is described 608 in Section 4.2 of [RFC7581]. 610 4.4.1. Signal Processing Exclusion XRO Subobject 612 The PCC/PCE should be able to exclude particular types of signal 613 processing along the path in order to handle client restriction or 614 multi-domain path computation. [RFC5440] defines how Exclude Route 615 Object (XRO) subobject is used. In this draft, we add a new XRO 616 subobject, signal processing subobject. 618 In order to support the exclusion a new XRO subobject is defined: 619 the signal processing exclusion: 621 0 1 2 3 623 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 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 |X| Type =TBD | Length | Reserved | Attribute | 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 | sub-sub objects | 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 Figure 5 Signaling Processing XRO Subobject 632 Refer to [RFC5521] for the definition of X, Length and Attribute. 634 Type (7 bits): The Type of the XRO sub-sub objects. See below for 635 the two TBD values (TBD9 and TBD10) to be assigned by the IANA. 637 Reserved bits (8 bits) are for future use and SHOULD be zeroed and 638 ignored on receipt. 640 The Attribute field (8 bits): [RFC5521] defines several Attribute 641 values; the only permitted Attribute values for this subobject are 642 0 (Interface) or 1 (Node). 644 The permitted sub-sub objects are the Optical Interface Class List 645 and the Client Signal information whose encodings are described in 646 Section 4.1 and Section 4.2 of [RFC7581], respectively. 648 The XRO needs to support the new subobject types: 650 Type Sub-subobject 652 TBD9 Optical Interface Class List 654 TBD10 Client Signal Information 656 4.4.2. IRO subobject: signal processing inclusion 658 Similar to the XRO subobject, the PCC/PCE should be able to include 659 particular types of signal processing along the path in order to 660 handle client restriction or multi-domain path computation. 661 [RFC5440] defines how Include Route Object (IRO) subobject is used. 662 In this draft, we add a new IRO subobject, signal processing 663 subobject. 665 The IRO needs to support the new subobject types as defined in 666 Section 4.2 [RFC7689] "WSON Processing Hop Attribute TLV" (TBD9) 667 defined for ERO in Section 4.2 [RFC7689] to the PCEP IRO object 668 [RFC5440]: 670 Type Sub-subobject 672 TBD11 Optical Interface Class List 674 TBD12 Client Signal Information 676 5. Encoding of a RWA Path Reply 678 This section provides the encoding of a RWA Path Reply for 679 wavelength allocation request as discussed in Section 4. Recall that 680 wavelength allocation can be performed by the PCE by different 681 means: 683 (a) By means of Explicit Label Control (ELC) where the PCE 684 allocates which label to use for each interface/node along the 685 path. 687 (b) By means of a Label Set where the PCE provides a range of 688 potential labels to allocate by each node along the path. 690 Option (b) allows distributed label allocation (performed during 691 signaling) to complete wavelength allocation. 693 The Wavelength Allocation TLV type is TBD4 (See Section 8.4). Note 694 that this TLV is used for both (a) and (b). The TLV data is defined 695 as follows: 697 0 1 2 3 698 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 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 700 | Reserved |M| 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 702 | Link Identifier | 703 | . . . | 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 | Allocated Wavelength(s) | 706 // . . . . // 707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 709 Figure 6 Wavelength Allocation TLV Encoding 711 o Reserved (15 bits): Reserved for future use. 713 o M (Mode): 1 bit 715 - 0 indicates the allocation is under Explicit Label Control. 717 - 1 indicates the allocation is expressed in Label Sets. 719 Note that all link identifiers in the same list must be of the same 720 type. 722 o Link Identifier: Identifies the interface to which assignment 723 wavelength(s) is applied. See Section 4.3.1. for Link Identifier 724 encoding. 726 o Allocated Wavelength(s): Indicates the allocated wavelength(s) to 727 be associated with the Link Identifier. See Section 4.3.2 for 728 encoding details. 730 This TLV is encoded as an attributes TLV, per [RFC5420], which is 731 carried in the Hop Attribute Subobjects per [RFC7570]. 733 5.1. Error Indicator 735 To indicate errors associated with the RWA request, a new Error Type 736 (TBD8) and subsequent error-values are defined as follows for 737 inclusion in the PCEP-ERROR Object: 739 A new Error-Type (TBD8) and subsequent error-values are defined as 740 follows: 742 . Error-Type=TBD8; Error-value=1: if a PCE receives a RWA 743 request and the PCE is not capable of processing the request 744 due to insufficient memory, the PCE MUST send a PCErr message 745 with a PCEP-ERROR Object (Error-Type=TBD8) and an Error- 746 value(Error-value=1). The PCE stops processing the request. 747 The corresponding RWA request MUST be cancelled at the PCC. 749 . Error-Type=TBD8; Error-value=2: if a PCE receives a RWA 750 request and the PCE is not capable of RWA computation, the PCE 751 MUST send a PCErr message with a PCEP-ERROR Object (Error- 752 Type=TBD8) and an Error-value (Error-value=2). The PCE stops 753 processing the request. The corresponding RWA computation 754 MUST be cancelled at the PCC. 756 . Error-Type=TBD8; Error-value=3: if a PCE receives a RWA 757 request and there are syntactical encoding errors (e.g., not 758 exactly two link identifiers with the range case, unknown 759 identifier types, no matching link for a given identifier, 760 etc.), the PCE MUST send a PCErr message with a PCEP-ERROR 761 Object (Error-Type=TBD8) and an Error-value (Error-value=3). 763 5.2. NO-PATH Indicator 765 To communicate the reason(s) for not being able to find RWA for the 766 path request, the NO-PATH object can be used in the corresponding 767 response. The format of the NO-PATH object body is defined in 768 [RFC5440]. The object may contain a NO-PATH-VECTOR TLV to provide 769 additional information about why a path computation has failed. 771 One new bit flag is defined to be carried in the Flags field in the 772 NO-PATH-VECTOR TLV carried in the NO-PATH Object. 774 . Bit TBD7: When set, the PCE indicates no feasible route was 775 found that meets all the constraints (e.g., wavelength 776 restriction, signal compatibility, etc.) associated with RWA. 778 6. Manageability Considerations 780 Manageability of WSON Routing and Wavelength Assignment (RWA) with 781 PCE must address the following considerations: 783 6.1. Control of Function and Policy 785 In addition to the parameters already listed in Section 8.1 of 786 [RFC5440], a PCEP implementation SHOULD allow configuration of the 787 following PCEP session parameters on a PCC: 789 . The ability to send a WSON RWA request. 791 In addition to the parameters already listed in Section 8.1 of 792 [RFC5440], a PCEP implementation SHOULD allow configuration of the 793 following PCEP session parameters on a PCE: 795 . The support for WSON RWA. 797 . A set of WSON RWA specific policies (authorized sender, 798 request rate limiter, etc). 800 These parameters may be configured as default parameters for any 801 PCEP session the PCEP speaker participates in, or may apply to a 802 specific session with a given PCEP peer or a specific group of 803 sessions with a specific group of PCEP peers. 805 6.2. Liveness Detection and Monitoring 807 Mechanisms defined in this document do not imply any new liveness 808 detection and monitoring requirements in addition to those already 809 listed in section 8.3 of [RFC5440]. 811 6.3. Verifying Correct Operation 813 Mechanisms defined in this document do not imply any new 814 verification requirements in addition to those already listed in 815 section 8.4 of [RFC5440] 817 6.4. Requirements on Other Protocols and Functional Components 819 The PCEP Link-State mechanism [PCEP-LS] may be used to advertise 820 WSON RWA path computation capabilities to PCCs. 822 6.5. Impact on Network Operation 824 Mechanisms defined in this document do not imply any new network 825 operation requirements in addition to those already listed in 826 section 8.6 of [RFC5440]. 828 7. Security Considerations 830 The security considerations discussed in [RFC5440] are relevant for 831 this document, this document does not introduce any new security 832 issues. If an operator wishes to keep private the information 833 distributed by WSON, PCEPS [RFC8253] SHOULD be used. 835 8. IANA Considerations 837 IANA maintains a registry of PCEP parameters. IANA has made 838 allocations from the sub-registries as described in the following 839 sections. 841 8.1. New PCEP Object 843 As described in Section 4.1, a new PCEP Object is defined to carry 844 wavelength assignment related constraints. IANA is to allocate the 845 following from "PCEP Objects" sub-registry 846 (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-objects): 848 Object Class Name Object Reference 849 Value Type 850 --------------------------------------------------------- 851 TBD1 WA 1: Wavelength-Assignment [This.I-D] 853 8.2. New PCEP TLV: Wavelength Selection TLV 855 As described in Sections 4.2, a new PCEP TLV is defined to indicate 856 wavelength selection constraints. IANA is to allocate this new TLV 857 from the "PCEP TLV Type Indicators" subregistry 858 (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type- 859 indicators). 861 Value Description Reference 862 --------------------------------------------------------- 863 TBD2 Wavelength Selection [This.I-D] 865 8.3. New PCEP TLV: Wavelength Restriction Constraint TLV 867 As described in Sections 4.3, a new PCEP TLV is defined to indicate 868 wavelength restriction constraints. IANA is to allocate this new TLV 869 from the "PCEP TLV Type Indicators" subregistry 870 (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type- 871 indicators). 873 Value Description Reference 874 --------------------------------------------------------- 875 TBD3 Wavelength Restriction [This.I-D] 876 Constraint 878 8.4. New PCEP TLV: Wavelength Allocation TLV 880 As described in Section 5, a new PCEP TLV is defined to indicate the 881 allocation of wavelength(s) by the PCE in response to a request by 882 the PCC. IANA is to allocate this new TLV from the "PCEP TLV Type 883 Indicators" subregistry 884 (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type- 885 indicators). 887 Value Description Reference 888 --------------------------------------------------------- 889 TBD4 Wavelength Allocation [This.I-D] 891 8.5. New PCEP TLV: Optical Interface Class List TLV 893 As described in Section 4.4, a new PCEP TLV is defined to indicate 894 the optical interface class list. IANA is to allocate this new TLV 895 from 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 TBD5 Optical Interface [This.I-D] 902 Class List 904 8.6. New PCEP TLV: Client Signal TLV 906 As described in Section 4.4, a new PCEP TLV is defined to indicate 907 the client signal information. IANA is to allocate this new TLV from 908 the "PCEP TLV Type Indicators" subregistry 909 (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type- 910 indicators). 912 Value Description Reference 913 --------------------------------------------------------- 914 TBD6 Client Signal Information [This.I-D] 916 8.7. New No-Path Reasons 918 As described in Section 5.2., a new bit flag are defined to be 919 carried in the Flags field in the NO-PATH-VECTOR TLV carried in the 920 NO-PATH Object. This flag, when set, indicates that no feasible 921 route was found that meets all the RWA constraints (e.g., wavelength 922 restriction, signal compatibility, etc.) associated with a RWA path 923 computation request. 925 IANA is to allocate this new bit flag from the "PCEP NO-PATH-VECTOR 926 TLV Flag Field" subregistry 927 (http://www.iana.org/assignments/pcep/pcep.xhtml#no-path-vector- 928 tlv). 930 Bit Description Reference 931 ----------------------------------------------------- 932 TBD7 No RWA constraints met [This.I-D] 934 8.8. New Error-Types and Error-Values 936 As described in Section 5.1, new PCEP error codes are defined for 937 WSON RWA errors. IANA is to allocate from the ""PCEP-ERROR Object 938 Error Types and Values" sub-registry 939 (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-error-object). 941 Error- Meaning Error-Value Reference 942 Type 943 --------------------------------------------------------------- 945 TBD8 WSON RWA Error 1: Insufficient [This.I-D] 946 Memory 948 2: RWA computation [This.I-D] 949 Not supported 951 3: Syntactical [This.I-D] 952 Encoding error 954 8.9. New Subobject for the Exclude Route Object 956 The "PCEP Parameters" registry contains a subregistry "PCEP Objects" 957 with an entry for the Exclude Route Object (XRO). IANA is requested 958 to add a further subobject that can be carried in the XRO as 959 follows: 961 Subobject Type Reference 963 ---------------------------------------------------------- 964 TBD9 Optical Interface Class List [This.I-D] 966 TBD10 Client Signal Information [This.I-D] 968 8.10. New Subobject for the Include Route Object 970 The "PCEP Parameters" registry contains a subregistry "PCEP Objects" 971 with an entry for the Include Route Object (IRO). IANA is requested 972 to add a further subobject that can be carried in the IRO as 973 follows: 975 Subobject Type Reference 977 ---------------------------------------------------------- 979 TBD11 Optical Interface Class List [This.I-D] 981 TBD12 Client Signal Information [This.I-D] 983 9. Acknowledgments 985 The authors would like to thank Adrian Farrel and Julien Meuric for 986 many helpful comments that greatly improved the contents of this 987 draft. 989 10. References 991 10.1. Normative References 993 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 994 Requirement Levels", BCP 14, RFC 2119, March 1997. 996 [RFC3630] D. Katz, K. Kompella, D. Yeung, "Traffic Engineering (TE) 997 Extensions to OSPF Version 2", RFC 3630, September 2003. 999 [RFC5329] A. Lindem, Ed., "Traffic Engineering Extensions to OSPF 1000 Version 3", RFC 5329, September 2008. 1002 [RFC5440] JP. Vasseur, Ed., JL. Le Roux, Ed., "Path Computation 1003 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 1004 March 2009. 1006 [RFC6205] Tomohiro, O. and D. Li, "Generalized Labels for Lambda- 1007 Switching Capable Label Switching Routers", RFC 6205, 1008 January, 2011. 1010 [RFC7570] C. Margaria, et al., "Label Switched Path (LSP) Attribute 1011 in the Explicit Route Object (ERO)", RFC 7570, July 2015. 1013 [RFC7579] G. Bernstein and Y. Lee, "General Network Element 1014 Constraint Encoding for GMPLS Controlled Networks", RFC 1015 7579, June 2015. 1017 [RFC7581] G. Bernstein and Y. Lee, "Routing and Wavelength 1018 Assignment Information Encoding for Wavelength Switched 1019 Optical Networks", RFC7581, June 2015. 1021 [RFC7689] Bernstein et al., "Signaling Extensions for Wavelength 1022 Switched Optical Networks", RFC 7689, November 2015. 1024 [RFC7688] Y. Lee, and G. Bernstein, "OSPF Enhancement for Signal and 1025 Network Element Compatibility for Wavelength Switched 1026 Optical Networks", RFC 7688, November 2015. 1028 [RFC8174] B. Leiba, "Ambiguity of Uppercase vs Lowercase in RFC 2119 1029 Key Words", RFC 8174, May 2017. 1031 [RFC8253] D. Lopez, O. Gonzalez de Dios, Q. Wu, D. Dhody, "PCEPS: 1032 Usage of TLS to Provide a Secure Transport for the Path 1033 Computation Element Communication Protocol (PCEP)", RFC 1034 8253, October 2017. 1036 [PCEP-GMPLS] C. Margaria, et al., "PCEP extensions for GMPLS", 1037 draft-ietf-pce-gmpls-pcep-extensions, work in progress. 1039 10.2. Informative References 1041 [RFC3471] Berger, L. (Editor), "Generalized Multi-Protocol Label 1042 Switching (GMPLS) Signaling Functional Description", RFC 1043 3471. January 2003. 1045 [RFC4203] K. Kompella, Ed., Y. Rekhter, Ed., "OSPF Extensions in 1046 Support of Generalized Multi-Protocol Label Switching 1047 (GMPLS)", RFC 4203, October 2005. 1049 [RFC4204] J. Lang, Ed., "Link Management Protocol (LMP)", RFC 4204, 1050 October 2005. 1052 [RFC4655] A. Farrel, JP. Vasseur, G. Ash, "A Path Computation 1053 Element (PCE)-Based Architecture", RFC 4655, August 2006. 1055 [RFC5420] Farrel, A. "Encoding of Attributes for MPLS LSP 1056 Establishment Using Resource Reservation Protocol Traffic 1057 Engineering (RSVP-TE)", RFC5420, February 2009. 1059 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1060 Element (PCE) communication Protocol", RFC 5440, March 1061 2009.[RFC5521] Oki, E, T. Takeda, and A. Farrel, 1062 "Extensions to the Path Computation Element Communication 1063 Protocol (PCEP) for Route Exclusions", RFC 5521, April 1064 2009. 1066 [RFC6163] Lee, Y. and Bernstein, G. (Editors), and W. Imajuku, 1067 "Framework for GMPLS and PCE Control of Wavelength 1068 Switched Optical Networks", RFC 6163, March 2011. 1070 [RFC6566] Lee, Y. and Berstein, G. (Editors), "A Framework for the 1071 Control of Wavelength Switched Optical Networks (WSONs) 1072 with Impairments", RFC 6566, March 2012. 1074 [RFC7446] Y. Lee, G. Bernstein, (Editors), "Routing and Wavelength 1075 Assignment Information Model for Wavelength Switched 1076 Optical Networks", RFC 7446, February 2015. 1078 [RFC7449] Y. Lee, G. Bernstein, (Editors), "Path Computation Element 1079 Communication Protocol (PCEP) Requirements for Wavelength 1080 Switched Optical Network (WSON) Routing and Wavelength 1081 Assignment", RFC 7449, February 2015. 1083 [PCEP-LS] Y. Lee, et al., "PCEP Extension for Distribution of Link- 1084 State and TE information for Optical Networks", draft-lee- 1085 pce-pcep-ls-optical, work in progress. 1087 11. Contributors 1089 Fatai Zhang 1090 Huawei Technologies 1091 Email: zhangfatai@huawei.com 1093 Cyril Margaria 1094 Nokia Siemens Networks 1095 St Martin Strasse 76 1096 Munich, 81541 1097 Germany 1098 Phone: +49 89 5159 16934 1099 Email: cyril.margaria@nsn.com 1101 Oscar Gonzalez de Dios 1102 Telefonica Investigacion y Desarrollo 1103 C/ Emilio Vargas 6 1104 Madrid, 28043 1105 Spain 1106 Phone: +34 91 3374013 1107 Email: ogondio@tid.es 1109 Greg Bernstein 1110 Grotto Networking 1111 Fremont, CA, USA 1112 Phone: (510) 573-2237 1113 Email: gregb@grotto-networking.com 1115 Authors' Addresses 1117 Young Lee, Editor 1118 Huawei Technologies 1119 1700 Alma Drive, Suite 100 1120 Plano, TX 75075, USA 1121 Phone: (972) 509-5599 (x2240) 1122 Email: leeyoung@huawei.com 1124 Ramon Casellas, Editor 1125 CTTC PMT Ed B4 Av. Carl Friedrich Gauss 7 1126 08860 Castelldefels (Barcelona) 1127 Spain 1128 Phone: (34) 936452916 1129 Email: ramon.casellas@cttc.es