idnits 2.17.1 draft-ietf-pce-wson-rwa-ext-11.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 (January 14, 2019) is 1927 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 103, but not defined == Missing Reference: 'RFC7449' is mentioned on line 135, 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: July 14, 2019 CTTC 7 January 14, 2019 9 PCEP Extension for WSON Routing and Wavelength Assignment 11 draft-ietf-pce-wson-rwa-ext-11 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 July 14, 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.....................8 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..........14 74 4.4.2. IRO sub-object: signal processing inclusion.........15 75 5. Encoding of a RWA Path Reply..................................15 76 5.1. Error Indicator..........................................17 77 5.2. NO-PATH Indicator........................................17 78 6. Manageability Considerations..................................18 79 6.1. Control of Function and Policy...........................18 80 6.2. Liveness Detection and Monitoring........................18 81 6.3. Verifying Correct Operation..............................18 82 6.4. Requirements on Other Protocols and Functional Components19 83 6.5. Impact on Network Operation..............................19 84 7. Security Considerations.......................................19 85 8. IANA Considerations...........................................19 86 8.1. New PCEP Object..........................................19 87 8.2. New PCEP TLV: Wavelength Selection TLV...................20 88 8.3. New PCEP TLV: Wavelength Restriction Constraint TLV......20 89 8.4. New PCEP TLV: Wavelength Allocation TLV..................20 90 8.5. New PCEP TLV: Optical Interface Class List TLV...........21 91 8.6. New PCEP TLV: Client Signal TLV..........................21 92 8.7. New No-Path Reasons......................................21 93 8.8. New Error-Types and Error-Values.........................22 94 9. Acknowledgments...............................................22 95 10. References...................................................22 96 10.1. Normative References....................................22 97 10.2. Informative References..................................23 98 11. Contributors.................................................24 99 Authors' Addresses...............................................25 101 1. Terminology 103 This document uses the terminology defined in [RFC4655], and 104 [RFC5440]. 106 2. Requirements Language 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 110 "OPTIONAL" in this document are to be interpreted as described in 111 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 112 capitals, as shown here. 114 3. Introduction 116 [RFC5440] specifies the Path Computation Element (PCE) Communication 117 Protocol (PCEP) for communications between a Path Computation Client 118 (PCC) and a PCE, or between two PCEs. Such interactions include 119 path computation requests and path computation replies as well as 120 notifications of specific states related to the use of a PCE in the 121 context of Multiprotocol Label Switching (MPLS) and Generalized MPLS 122 (GMPLS) Traffic Engineering. 124 A PCC is said to be any network component that makes such a request 125 and may be, for instance, an Optical Switching Element within a 126 Wavelength Division Multiplexing (WDM) network. The PCE, itself, 127 can be located anywhere within the network, and may be within an 128 optical switching element, a Network Management System (NMS) or 129 Operational Support System (OSS), or may be an independent network 130 server. 132 This document provides the PCEP extensions for the support of 133 Routing and Wavelength Assignment (RWA) in Wavelength Switched 134 Optical Networks (WSON) based on the requirements specified in 135 [RFC6163] and [RFC7449]. 137 WSON refers to WDM based optical networks in which switching is 138 performed selectively based on the wavelength of an optical signal. 139 The devices used in WSONs that are able to switch signals based on 140 signal wavelength are known as Lambda Switch Capable (LSC). WSONs 141 can be transparent or translucent. A transparent optical network is 142 made up of optical devices that can switch but not convert from one 143 wavelength to another, all within the optical domain. On the other 144 hand, translucent networks include 3R regenerators that are sparsely 145 placed. The main function of the 3R regenerators is to convert one 146 optical wavelength to another. 148 A Lambda Switch Capable (LSC) Label Switched Path (LSP) may span one 149 or several transparent segments, which are delimited by 3R 150 regenerators (Re-amplification, Re-shaping, Re-timing) typically 151 with electronic regenerator and optional wavelength conversion. Each 152 transparent segment or path in WSON is referred to as an optical 153 path. An optical path may span multiple fiber links and the path 154 should be assigned the same wavelength for each link. In such case, 155 the optical path is said to satisfy the wavelength-continuity 156 constraint. Figure 1 illustrates the relationship between a LSC LSP 157 and transparent segments (optical paths). 159 +---+ +-----+ +-----+ +-----+ +-----+ 160 | |I1 | | | | | | I2| | 161 | |o------| |-------[(3R) ]------| |--------o| | 162 | | | | | | | | | | 163 +---+ +-----+ +-----+ +-----+ +-----+ 164 (X LSC) (LSC LSC) (LSC LSC) (LSC X) 165 <-------> <-------> <-----> <-------> 166 <-----------------------><----------------------> 167 Transparent Segment Transparent Segment 168 <-------------------------------------------------> 169 LSC LSP 171 Figure 1 Illustration of a LSC LSP and transparent segments 172 Note that two optical paths within a WSON LSP do not need to operate 173 on the same wavelength (due to the wavelength conversion 174 capabilities). Two optical paths that share a common fiber link 175 cannot be assigned the same wavelength; Otherwise, the two signals 176 would interfere with each other. Note that advanced additional 177 multiplexing techniques such as polarization based multiplexing are 178 not addressed in this document since the physical layer aspects are 179 not currently standardized. Therefore, assigning the proper 180 wavelength on a path is an essential requirement in the optical path 181 computation process. 183 When a switching node has the ability to perform wavelength 184 conversion, the wavelength-continuity constraint can be relaxed, and 185 a LSC Label Switched Path (LSP) may use different wavelengths on 186 different links along its route from origin to destination. It is, 187 however, to be noted that wavelength converters may be limited due 188 to their relatively high cost, while the number of WDM channels that 189 can be supported in a fiber is also limited. As a WSON can be 190 composed of network nodes that cannot perform wavelength conversion, 191 nodes with limited wavelength conversion, and nodes with full 192 wavelength conversion abilities, wavelength assignment is an 193 additional routing constraint to be considered in all optical path 194 computation. 196 For example (see Figure 1), within a translucent WSON, a LSC LSP may 197 be established between interfaces I1 and I2, spanning 2 transparent 198 segments (optical paths) where the wavelength continuity constraint 199 applies (i.e. the same unique wavelength must be assigned to the LSP 200 at each TE link of the segment). If the LSC LSP induced a Forwarding 201 Adjacency / TE link, the switching capabilities of the TE link would 202 be (X X) where X refers to the switching capability of I1 and I2. 203 For example, X can be PSC, TDM, etc. 205 This document aligns with GMPLS extensions for PCEP [PCEP-GMPLS] for 206 generic properties such as label, label-set and label assignment 207 noting that wavelength is a type of label. Wavelength restrictions 208 and constraints are also formulated in terms of labels per 209 [RFC7579]. 211 The optical modulation properties, which are also referred to as 212 signal compatibility, are already considered in signaling in 213 [RFC7581] and [RFC7688]. In order to improve the signal quality and 214 limit some optical effects several advanced modulation processing 215 capabilities are used. These modulation capabilities contribute not 216 only to optical signal quality checks but also constrain the 217 selection of sender and receiver, as they should have matching 218 signal processing capabilities. This document includes signal 219 compatibility constraints as part of RWA path computation. That is, 220 the signal processing capabilities (e.g., modulation and FEC) 221 indicated by means of optical interface class (OIC) must be 222 compatible between the sender and the receiver of the optical path 223 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 specified in 235 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 Wavelength 266 Assignment (WA) object is 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 WA object body is as follows: 292 0 1 2 3 293 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 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Reserved | Flags |M| 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | Wavelength Selection TLV | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | Wavelength Restriction Constraint TLV | 300 . . 301 . . 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 Figure 3 WA Object 306 o Reserved (16 bits): Reserved for future use and SHOULD be zeroed. 308 o Flags (16 bits) 310 One flag bit is allocated as follows: 312 . M (Mode - 1 bit): M bit is used to indicate the mode of 313 wavelength assignment. When M bit is set to 1, this indicates 314 that the label assigned by the PCE must be explicit. That is, 315 the selected way to convey the allocated wavelength is by means 316 of Explicit Label Control for each hop of a computed LSP. 317 Otherwise (M bit is set to 0), the label assigned by the PCE 318 need not be explicit (i.e., it can be suggested in the form of 319 label set objects in the corresponding response, to allow 320 distributed WA. If M is 0, the PCE MUST return a Label Set 321 Field as described in Section 2.6 of [RFC7579] in the response. 322 See Section 5 of this document for the encoding discussion of a 323 Label Set Field in a PCRep message. 325 All unused flags SHOULD be zeroed. 327 . Wavelength Selection TLV (32 bits): See Section 4.2 for 328 details. 330 . Wavelength Restriction Constraint TLV (Variable): See Section 331 4.3 for details. 333 4.2. Wavelength Selection TLV 335 The Wavelength Selection TLV is used to indicate the wavelength 336 selection constraint in regard to the order of wavelength assignment 337 to be returned by the PCE. This TLV is only applied when M bit is 338 set in the WA Object specified in Section 4.1. This TLV MUST NOT be 339 used when the M bit is cleared. 341 The encoding of this TLV is specified as the Wavelength Selection 342 Sub-TLV in Section 4.2.2 of [RFC7689]. 344 4.3. Wavelength Restriction Constraint TLV 346 For any request that contains a wavelength assignment, the requester 347 (PCC) MUST be able to specify a restriction on the wavelengths to be 348 used. This restriction is to be interpreted by the PCE as a 349 constraint on the tuning ability of the origination laser 350 transmitter or on any other maintenance related constraints. Note 351 that if the LSP LSC spans different segments, the PCE MUST have 352 mechanisms to know the tunability restrictions of the involved 353 wavelength converters / regenerators, e.g. by means of the TED 354 either via IGP or NMS. Even if the PCE knows the tunability of the 355 transmitter, the PCC MUST be able to apply additional constraints to 356 the request. 358 The format of the Wavelength Restriction Constraint TLV is as 359 follows: 361 ::= 363 365 ( )... 367 Where 369 ::= [] 371 See Section 4.3.1. for the encoding of the Link Identifiers Field. 373 The Wavelength Restriction Constraint TLV type is TBD3 (See Section 374 8.3). This TLV MAY appear more than once to be able to specify 375 multiple restrictions. 377 The TLV data is defined as follows: 379 0 1 2 3 380 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 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | Action | Count | Reserved | 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 | Link Identifiers | 385 | . . . | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | Wavelength Restriction Field | 388 // . . . . // 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 Figure 4 Wavelength Restriction Constraint TLV Encoding 393 o Action (8 bits): 395 . 0 - Inclusive List indicates that one or more link identifiers 396 are included in the Link Set. Each identifies a separate link 397 that is part of the set. 399 . 1 - Inclusive Range indicates that the Link Set defines a 400 range of links. It contains two link identifiers. The first 401 identifier indicates the start of the range (inclusive). The 402 second identifier indicates the end of the range (inclusive). 403 All links with numeric values between the bounds are 404 considered to be part of the set. A value of zero in either 405 position indicates that there is no bound on the corresponding 406 portion of the range. 408 Note that "interfaces" are assumed to be bidirectional. 410 o Count (8 bits): The number of the link identifiers 412 Note that a PCC MAY add a Wavelength restriction that applies to all 413 links by setting the Count field to zero and specifying just a set 414 of wavelengths. 416 Note that all link identifiers in the same list must be of the same 417 type. 419 o Reserved (16 bits): Reserved for future use and SHOULD be zeroed. 421 o Link Identifiers: Identifies each link ID for which restriction 422 is applied. The length is dependent on the link format and the Count 423 field. See Section 4.3.1. for Link Identifier encoding and Section 424 4.3.2. for the Wavelength Restriction Field encoding, respectively. 426 Various encoding errors are possible with this TLV (e.g., not 427 exactly two link identifiers with the range case, unknown identifier 428 types, no matching link for a given identifier, etc.). To indicate 429 errors associated with this type, a new Error-Type (TBD8) and an 430 Error-value (Error-value=3) MUST be defined so that the PCE MUST 431 send a PCErr message with a PCEP-ERROR Object. See Section 5.1 for 432 the details. 434 4.3.1. Link Identifier Field 436 The link identifier field can be an IPv4 [RFC3630], IPv6 [RFC5329] 437 or unnumbered interface ID [RFC4203]. 439 ::= 441 | | 443 The encoding of each case is as follows: 445 IPv4 prefix sub-TLV 447 0 1 2 3 448 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 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | Type = 1 | Reserved (16 bits) | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | IPv4 address (4 bytes) | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 IPv6 prefix Sub-TLV 457 0 1 2 3 458 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 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 | Type = 2 | Reserved (16 bits) | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | IPv6 address (16 bytes) | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | IPv6 address (continued) | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | IPv6 address (continued) | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 | IPv6 address (continued) | 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 Unnumbered Interface ID 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 = 3 | Reserved (16 bits) | 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 | TE Node ID (32 bits) | 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | Interface ID (32 bits) | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 Type (8 bits): It indicates the type of the link identifier. 485 Reserved (16 bits): Reserved for future use and SHOULD be zeroed. 487 4.3.2. Wavelength Restriction Field 489 The Wavelength Restriction Field of the wavelength restriction TLV 490 is encoded as a Label Set field as specified in Section 2.6 in 491 [RFC7579] with base label encoded as a 32 bit LSC label, defined in 492 [RFC6205]. See [RFC6205] for a description of Grid, C.S, Identifier 493 and n, as well as [RFC7579] for the details of each action. 495 0 1 2 3 497 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 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 | Action| Num Labels | Length | 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 |Grid | C.S | Identifier | n | 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 | Additional fields as necessary per action | 505 | | 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 Action (4 bits): 510 0 - Inclusive List 512 1 - Exclusive List 514 2 - Inclusive Range 516 3 - Exclusive Range 517 4 - Bitmap Set 519 Num Labels (12 bits): It is generally the number of labels. It has a 520 specific meaning depending on the action value. 522 Length (16 bits): It is the length in bytes of the entire label set 523 field. 525 See Sections 2.6.1 - 2.6.3 of [RFC7579] for details on additional 526 field discussion for each action. 528 4.4. Signal processing capability restrictions 530 Path computation for WSON includes checking of signal processing 531 capabilities at each interface against requested capability; this 532 requirement MAY be implemented by the IGP. Moreover, a PCC should 533 be able to indicate additional restrictions to signal processing 534 compatibility, either on the endpoint or any given link. 536 The supported signal processing capabilities are those described in 537 [RFC7446]: 539 . Optical Interface Class List 541 . Bit Rate 543 . Client Signal 545 The Bit Rate restriction is already expressed in [PCEP-GMPLS] in the 546 BANDWIDTH object. 548 In order to support the Optical Interface Class information and the 549 Client Signal information new TLVs are introduced as endpoint- 550 restriction in the END-POINTS type Generalized endpoint: 552 . Client Signal TLV 554 . Optical Interface Class List TLV 556 The END-POINTS type generalized endpoint is extended as follows: 558 ::= 559 561 [...] 563 Where 565 signal-compatibility-restriction ::= 567 569 The encoding for the Optical Interface Class List is described in 570 Section 4.1 of [RFC7581]. 572 The encoding for the Client Signal Information is described in 573 Section 4.2 of [RFC7581]. 575 4.4.1. Signal Processing Exclusion XRO Sub-Object 577 The PCC/PCE should be able to exclude particular types of signal 578 processing along the path in order to handle client restriction or 579 multi-domain path computation. [RFC5440] defines how Exclude Route 580 Object (XRO) sub-object is used. In this draft, we add a new XRO 581 sub-object, signal processing sub-object. 583 In order to support the exclusion a new XRO sub-object is defined: 584 the signal processing exclusion: 586 0 1 2 3 588 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 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 |X| Type = X | Length | Reserved | Attribute | 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 | sub-sub objects | 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 Figure 5 Signaling Processing XRO Sub-Object 597 Refer to [RFC5521] for the definition of X, Type, Length and 598 Attribute. 600 Reserved bits (8 bits) are for future use and SHOULD be zeroed. 602 The Attribute field (8 bits) indicates how the exclusion sub-object 603 is to be interpreted. The Attribute can only be 0 (Interface) or 1 604 (Node). 606 The permitted sub-sub objects are the Optical Interface Class List 607 and the Client Signal information whose encodings are described in 608 Section 4.1 and Section 4.2 of [RFC7581], respectively. 610 4.4.2. IRO sub-object: signal processing inclusion 612 Similar to the XRO sub-object, the PCC/PCE should be able to include 613 particular types of signal processing along the path in order to 614 handle client restriction or multi-domain path computation. 615 [RFC5440] defines how Include Route Object (IRO) sub-object is used. 616 In this draft, we add a new IRO sub-object, signal processing sub- 617 object. 619 This is supported by adding the sub-object "WSON Processing Hop 620 Attribute TLV" defined for ERO in Section 4.2 [RFC7689] to the PCEP 621 IRO object [RFC5440]. 623 5. Encoding of a RWA Path Reply 625 This section provides the encoding of a RWA Path Reply for 626 wavelength allocation request as discussed in Section 4. Recall that 627 wavelength allocation can be performed by the PCE by different 628 means: 630 (a) By means of Explicit Label Control (ELC) where the PCE 631 allocates which label to use for each interface/node along the 632 path. 633 (b) By means of a Label Set where the PCE provides a range of 634 potential labels to allocate by each node along the path. 636 Option (b) allows distributed label allocation (performed during 637 signaling) to complete wavelength allocation. 639 The Wavelength Allocation TLV type is TBD4 (See Section 8.4). The 640 TLV data is defined as follows: 642 0 1 2 3 643 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 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 | Type | Length |M| 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 | Link Identifier | 648 | . . . | 649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 650 | Allocated Wavelength(s) | 651 // . . . . // 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 654 Figure 6 Wavelength Allocation TLV Encoding 656 o Type (16 bits): The type of the TLV. 658 o Length (15 bits): The length of the TLV including the Type and 659 Length fields. 661 o M (Mode): 1 bit 663 - 0 indicates the allocation is under Explicit Label Control. 665 - 1 indicates the allocation is expressed in Label Sets. 667 Note that all link identifiers in the same list must be of the same 668 type. 670 o Link Identifier: Identifies the interface to which assignment 671 wavelength(s) is applied. See Section 4.3.1. for Link Identifier 672 encoding. 674 o Allocated Wavelength(s): Indicates the allocated wavelength(s) to 675 be associated with the Link Identifier. See Section 4.3.2 for 676 encoding details. 678 This TLV is encoded as an attributes TLV, per [RFC5420], which is 679 carried in the ERO LSP Attribute Subobjects per [RFC7570]. 681 5.1. Error Indicator 683 To indicate errors associated with the RWA request, a new Error Type 684 (TBD8) and subsequent error-values are defined as follows for 685 inclusion in the PCEP-ERROR Object: 687 A new Error-Type (TBD8) and subsequent error-values are defined as 688 follows: 690 . Error-Type=TBD8; Error-value=1: if a PCE receives a RWA 691 request and the PCE is not capable of processing the request 692 due to insufficient memory, the PCE MUST send a PCErr message 693 with a PCEP-ERROR Object (Error-Type=TBD8) and an Error- 694 value(Error-value=1). The PCE stops processing the request. 695 The corresponding RWA request MUST be cancelled at the PCC. 697 . Error-Type=TBD8; Error-value=2: if a PCE receives a RWA 698 request and the PCE is not capable of RWA computation, the PCE 699 MUST send a PCErr message with a PCEP-ERROR Object (Error- 700 Type=TBD8) and an Error-value (Error-value=2). The PCE stops 701 processing the request. The corresponding RWA computation 702 MUST be cancelled at the PCC. 704 . Error-Type=TBD8; Error-value=3: if a PCE receives a RWA 705 request and there are syntactical encoding errors (e.g., not 706 exactly two link identifiers with the range case, unknown 707 identifier types, no matching link for a given identifier, 708 etc.), the PCE MUST send a PCErr message with a PCEP-ERROR 709 Object (Error-Type=TBD8) and an Error-value (Error-value=3). 711 5.2. NO-PATH Indicator 713 To communicate the reason(s) for not being able to find RWA for the 714 path request, the NO-PATH object can be used in the corresponding 715 response. The format of the NO-PATH object body is defined in 716 [RFC5440]. The object may contain a NO-PATH-VECTOR TLV to provide 717 additional information about why a path computation has failed. 719 One new bit flag is defined to be carried in the Flags field in the 720 NO-PATH-VECTOR TLV carried in the NO-PATH Object. 722 . Bit TBD7: When set, the PCE indicates no feasible route was 723 found that meets all the constraints (e.g., wavelength 724 restriction, signal compatibility, etc.) associated with RWA. 726 6. Manageability Considerations 728 Manageability of WSON Routing and Wavelength Assignment (RWA) with 729 PCE must address the following considerations: 731 6.1. Control of Function and Policy 733 In addition to the parameters already listed in Section 8.1 of 734 [RFC5440], a PCEP implementation SHOULD allow configuration of the 735 following PCEP session parameters on a PCC: 737 . The ability to send a WSON RWA request. 739 In addition to the parameters already listed in Section 8.1 of 740 [RFC5440], a PCEP implementation SHOULD allow configuration of the 741 following PCEP session parameters on a PCE: 743 . The support for WSON RWA. 745 . A set of WSON RWA specific policies (authorized sender, 746 request rate limiter, etc). 748 These parameters may be configured as default parameters for any 749 PCEP session the PCEP speaker participates in, or may apply to a 750 specific session with a given PCEP peer or a specific group of 751 sessions with a specific group of PCEP peers. 753 6.2. Liveness Detection and Monitoring 755 Mechanisms defined in this document do not imply any new liveness 756 detection and monitoring requirements in addition to those already 757 listed in section 8.3 of [RFC5440]. 759 6.3. Verifying Correct Operation 761 Mechanisms defined in this document do not imply any new 762 verification requirements in addition to those already listed in 763 section 8.4 of [RFC5440] 765 6.4. Requirements on Other Protocols and Functional Components 767 The PCEP Link-State mechanism [PCEP-LS] may be used to advertise 768 WSON RWA path computation capabilities to PCCs. 770 6.5. Impact on Network Operation 772 Mechanisms defined in this document do not imply any new network 773 operation requirements in addition to those already listed in 774 section 8.6 of [RFC5440]. 776 7. Security Considerations 778 The security considerations discussed in [RFC5440] are relevant for 779 this document, this document does not introduce any new security 780 issues. If an operator wishes to keep private the information 781 distributed by WSON, PCEPS [RFC8253] SHOULD be used. 783 8. IANA Considerations 785 IANA maintains a registry of PCEP parameters. IANA has made 786 allocations from the sub-registries as described in the following 787 sections. 789 8.1. New PCEP Object 791 As described in Section 4.1, a new PCEP Object is defined to carry 792 wavelength assignment related constraints. IANA is to allocate the 793 following from "PCEP Objects" sub-registry 794 (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-objects): 796 Object Class Name Object Reference 797 Value Type 798 --------------------------------------------------------- 800 TBD1 WA 1: Wavelength-Assignment [This.I-D] 802 8.2. New PCEP TLV: Wavelength Selection TLV 804 As described in Sections 4.2, a new PCEP TLV is defined to indicate 805 wavelength selection constraints. IANA is to allocate this new TLV 806 from the "PCEP TLV Type Indicators" subregistry 807 (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type- 808 indicators). 810 Value Description Reference 811 --------------------------------------------------------- 812 TBD2 Wavelength Selection [This.I-D] 814 8.3. New PCEP TLV: Wavelength Restriction Constraint TLV 816 As described in Sections 4.3, a new PCEP TLV is defined to indicate 817 wavelength restriction constraints. IANA is to allocate this new TLV 818 from the "PCEP TLV Type Indicators" subregistry 819 (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type- 820 indicators). 822 Value Description Reference 823 --------------------------------------------------------- 824 TBD3 Wavelength Restriction [This.I-D] 825 Constraint 827 8.4. New PCEP TLV: Wavelength Allocation TLV 829 As described in Section 5, a new PCEP TLV is defined to indicate the 830 allocation of wavelength(s) by the PCE in response to a request by 831 the PCC. IANA is to allocate this new TLV from the "PCEP TLV Type 832 Indicators" subregistry 833 (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type- 834 indicators). 836 Value Description Reference 837 --------------------------------------------------------- 838 TBD4 Wavelength Allocation [This.I-D] 840 8.5. New PCEP TLV: Optical Interface Class List TLV 842 As described in Section 4.3, a new PCEP TLV is defined to indicate 843 the optical interface class list. 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 TBD5 Optical Interface [This.I-D] 851 Class List 853 8.6. New PCEP TLV: Client Signal TLV 855 As described in Section 4.3, a new PCEP TLV is defined to indicate 856 the client signal information. IANA is to allocate this new TLV from 857 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 TBD6 Client Signal Information [This.I-D] 865 8.7. New No-Path Reasons 867 As described in Section 5.2., a new bit flag are defined to be 868 carried in the Flags field in the NO-PATH-VECTOR TLV carried in the 869 NO-PATH Object. This flag, when set, indicates that no feasible 870 route was found that meets all the RWA constraints (e.g., wavelength 871 restriction, signal compatibility, etc.) associated with a RWA path 872 computation request. 874 IANA is to allocate this new bit flag from the "PCEP NO-PATH-VECTOR 875 TLV Flag Field" subregistry 876 (http://www.iana.org/assignments/pcep/pcep.xhtml#no-path-vector- 877 tlv). 879 Bit Description Reference 880 ----------------------------------------------------- 881 TBD7 No RWA constraints met [This.I-D] 883 8.8. New Error-Types and Error-Values 885 As described in Section 5.1, new PCEP error codes are defined for 886 WSON RWA errors. IANA is to allocate from the ""PCEP-ERROR Object 887 Error Types and Values" sub-registry 888 (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-error-object). 890 Error- Meaning Error-Value Reference 891 Type 892 --------------------------------------------------------------- 894 TBD8 WSON RWA Error 1: Insufficient [This.I-D] 895 Memory 897 2: RWA computation {This.I-D] 898 Not supported 900 9. Acknowledgments 902 The authors would like to thank Adrian Farrel for many helpful 903 comments that greatly improved the contents of this draft. 905 This document was prepared using 2-Word-v2.0.template.dot. 907 10. References 909 10.1. Normative References 911 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 912 Requirement Levels", BCP 14, RFC 2119, March 1997. 914 [RFC3630] D. Katz, K. Kompella, D. Yeung, "Traffic Engineering (TE) 915 Extensions to OSPF Version 2", RFC 3630, September 2003. 917 [RFC5329] A. Lindem, Ed., "Traffic Engineering Extensions to OSPF 918 Version 3", RFC 5329, September 2008. 920 [RFC5440] JP. Vasseur, Ed., JL. Le Roux, Ed., "Path Computation 921 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 922 March 2009. 924 [RFC6205] Tomohiro, O. and D. Li, "Generalized Labels for Lambda- 925 Switching Capable Label Switching Routers", RFC 6205, 926 January, 2011. 928 [RFC7570] C. Margaria, et al., "Label Switched Path (LSP) Attribute 929 in the Explicit Route Object (ERO)", RFC 7570, July 2015. 931 [RFC7579] G. Bernstein and Y. Lee, "General Network Element 932 Constraint Encoding for GMPLS Controlled Networks", RFC 933 7579, June 2015. 935 [RFC7581] G. Bernstein and Y. Lee, "Routing and Wavelength 936 Assignment Information Encoding for Wavelength Switched 937 Optical Networks", RFC7581, June 2015. 939 [RFC7689] Bernstein et al., "Signaling Extensions for Wavelength 940 Switched Optical Networks", RFC 7689, November 2015. 942 [RFC7688] Y. Lee, and G. Bernstein, "OSPF Enhancement for Signal and 943 Network Element Compatibility for Wavelength Switched 944 Optical Networks", RFC 7688, November 2015. 946 [RFC8174] B. Leiba, "Ambiguity of Uppercase vs Lowercase in RFC 2119 947 Key Words", RFC 8174, May 2017. 949 [PCEP-GMPLS] C. Margaria, et al., "PCEP extensions for GMPLS", 950 draft-ietf-pce-gmpls-pcep-extensions, work in progress. 952 10.2. Informative References 954 [RFC3471] Berger, L. (Editor), "Generalized Multi-Protocol Label 955 Switching (GMPLS) Signaling Functional Description", RFC 956 3471. January 2003. 958 [RFC4203] K. Kompella, Ed., Y. Rekhter, Ed., "OSPF Extensions in 959 Support of Generalized Multi-Protocol Label Switching 960 (GMPLS)", RFC 4203, October 2005. 962 [RFC5420] Farrel, A. "Encoding of Attributes for MPLS LSP 963 Establishment Using Resource Reservation Protocol Traffic 964 Engineering (RSVP-TE)", RFC5420, February 2009. 966 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 967 Element (PCE) communication Protocol", RFC 5440, March 968 2009.[RFC5521] Oki, E, T. Takeda, and A. Farrel, 969 "Extensions to the Path Computation Element Communication 970 Protocol (PCEP) for Route Exclusions", RFC 5521, April 971 2009. 973 [RFC6163] Lee, Y. and Bernstein, G. (Editors), and W. Imajuku, 974 "Framework for GMPLS and PCE Control of Wavelength 975 Switched Optical Networks", RFC 6163, March 2011. 977 [RFC7446] Y. Lee, G. Bernstein. (Editors),"Routing and Wavelength 978 Assignment Information Model for Wavelength Switched 979 Optical Networks", RFC 7446, February 2015. 981 [RFC8253] D. Lopez, O. Gonzalez de Dios, Q. Wu, D. Dhody, "PCEPS: 982 Usage of TLS to Provide a Secure Transport for the Path 983 Computation Element Communication Protocol (PCEP)", RFC 984 8253, October 2017. 986 [PCEP-LS] Y. Lee, et al., "PCEP Extension for Distribution of Link- 987 State and TE information for Optical Networks", draft-lee- 988 pce-pcep-ls-optical, work in progress. 990 11. Contributors 991 Authors' Addresses 993 Young Lee, Editor 994 Huawei Technologies 995 1700 Alma Drive, Suite 100 996 Plano, TX 75075, USA 997 Phone: (972) 509-5599 (x2240) 998 Email: leeyoung@huawei.com 1000 Ramon Casellas, Editor 1001 CTTC PMT Ed B4 Av. Carl Friedrich Gauss 7 1002 08860 Castelldefels (Barcelona) 1003 Spain 1004 Phone: (34) 936452916 1005 Email: ramon.casellas@cttc.es 1007 Fatai Zhang 1008 Huawei Technologies 1009 Email: zhangfatai@huawei.com 1011 Cyril Margaria 1012 Nokia Siemens Networks 1013 St Martin Strasse 76 1014 Munich, 81541 1015 Germany 1016 Phone: +49 89 5159 16934 1017 Email: cyril.margaria@nsn.com 1019 Oscar Gonzalez de Dios 1020 Telefonica Investigacion y Desarrollo 1021 C/ Emilio Vargas 6 1022 Madrid, 28043 1023 Spain 1024 Phone: +34 91 3374013 1025 Email: ogondio@tid.es 1027 Greg Bernstein 1028 Grotto Networking 1029 Fremont, CA, USA 1030 Phone: (510) 573-2237 1031 Email: gregb@grotto-networking.com