idnits 2.17.1 draft-ietf-pce-wson-rwa-ext-09.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 (November 4, 2018) is 1999 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) == Unused Reference: 'RFC4003' is defined on line 897, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 2 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: May 5, 2019 CTTC 7 November 4, 2018 9 PCEP Extension for WSON Routing and Wavelength Assignment 11 draft-ietf-pce-wson-rwa-ext-09.txt 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 Lightpath 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 light 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 May 5, 2019. 46 Copyright Notice 48 Copyright (c) 2018 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with 56 respect to this document. Code Components extracted from this 57 document must include Simplified BSD License text as described in 58 Section 4.e of the Trust Legal Provisions and are provided without 59 warranty as described in the Simplified BSD License. 61 Table of Contents 63 1. Terminology....................................................3 64 2. Requirements Language..........................................3 65 3. Introduction...................................................3 66 4. Encoding of a RWA Path Request.................................6 67 4.1. Wavelength Assignment (WA) Object.........................6 68 4.2. Wavelength Selection TLV..................................8 69 4.3. Wavelength Restriction Constraint TLV.....................8 70 4.3.1. Link Identifier Field...............................10 71 4.3.2. Wavelength Restriction Field........................12 72 4.4. Signal processing capability restrictions................13 73 4.4.1. Signal Processing Exclusion XRO Sub-Object..........14 74 4.4.2. IRO sub-object: signal processing inclusion.........14 75 5. Encoding of a RWA Path Reply..................................15 76 5.1. Error Indicator..........................................16 77 5.2. NO-PATH Indicator........................................17 78 6. Manageability Considerations..................................17 79 6.1. Control of Function and Policy...........................17 80 6.2. Information and Data Models, e.g. MIB module.............18 81 6.3. Liveness Detection and Monitoring........................18 82 6.4. Verifying Correct Operation..............................18 83 6.5. Requirements on Other Protocols and Functional Components18 84 6.6. Impact on Network Operation..............................18 86 7. Security Considerations.......................................18 87 8. IANA Considerations...........................................19 88 8.1. New PCEP Object..........................................19 89 8.2. New PCEP TLV: Wavelength Selection TLV...................19 90 8.3. New PCEP TLV: Wavelength Restriction Constraint TLV......19 91 8.4. New PCEP TLV: Wavelength Allocation TLV..................20 92 8.5. New PCEP TLV: Optical Interface Class List TLV...........20 93 8.6. New PCEP TLV: Client Signal TLV..........................21 94 8.7. New No-Path Reasons......................................21 95 8.8. New Error-Types and Error-Values.........................21 96 9. Acknowledgments...............................................22 97 10. References...................................................22 98 10.1. Informative References..................................22 99 10.2. Normative References....................................23 100 11. Contributors.................................................24 101 Authors' Addresses...............................................25 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", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in [RFC2119]. 114 3. Introduction 116 [RFC4655] defines a PCE based path computation architecture and 117 explains how a Path Computation Element (PCE) may compute Label 118 Switched Paths (LSP) in Multiprotocol Label Switching Traffic 119 Engineering (MPLS-TE) and Generalized MPLS (GMPLS) networks at the 120 request of Path Computation Clients (PCCs). A PCC is said to be any 121 network component that makes such a request and may be, for 122 instance, an Optical Switching Element within a Wavelength Division 123 Multiplexing (WDM) network. The PCE, itself, can be located 124 anywhere within the network, and may be within an optical switching 125 element, a Network Management System (NMS) or Operational Support 126 System (OSS), or may be an independent network server. 128 The PCE communications Protocol (PCEP) is the communication protocol 129 used between a PCC and a PCE, and may also be used between 130 cooperating PCEs. [RFC4657] sets out the common protocol 131 requirements for PCEP. Additional application-specific requirements 132 for PCEP are deferred to separate documents. 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 WSONs can be transparent or translucent. A transparent optical 142 network is made up of optical devices that can switch but not 143 convert from one wavelength to another, all within the optical 144 domain. On the other hand, translucent networks include 3R 145 regenerators that are sparsely placed. The main function of the 3R 146 regenerators is to convert one optical wavelength to another. In 147 this document, only wavelength converters that require electrical 148 signal regeneration are considered. 150 A Lambda Switch Capable (LSC) Label Switched Path (LSP) may span one 151 or several transparent segments, which are delimited by 3R 152 regenerators (typically with electronic regenerator and optional 153 wavelength conversion). Each transparent segment or path in WSON is 154 referred to as an optical path. An optical path may span multiple 155 fiber links and the path should be assigned the same wavelength for 156 each link. In such case, the optical path is said to satisfy the 157 wavelength-continuity constraint. Figure 1 illustrates the 158 relationship between a LSC LSP and transparent segments (optical 159 paths). 161 +---+ +-----+ +-----+ +-----+ +-----+ 162 | |I1 | | | | | | I2| | 163 | |o------| |-------[(3R) ]------| |--------o| | 164 | | | | | | | | | | 165 +---+ +-----+ +-----+ +-----+ +-----+ 166 (X LSC) (LSC LSC) (LSC LSC) (LSC X) 167 <-------> <-------> <-----> <-------> 168 <-----------------------><----------------------> 169 Transparent Segment Transparent Segment 170 <-------------------------------------------------> 171 LSC LSP 173 Figure 1 Illustration of a LSC LSP and transparent segments 174 Note that two optical paths within a WSON LSP do not need to operate 175 on the same wavelength (due to the wavelength conversion 176 capabilities). Two optical paths that share a common fiber link 177 cannot be assigned the same wavelength; Otherwise, both signals 178 would interfere with each other. Note that advanced additional 179 multiplexing techniques such as polarization based multiplexing are 180 not addressed in this document since the physical layer aspects are 181 not currently standardized. Therefore, assigning the proper 182 wavelength on a lightpath is an essential requirement in the optical 183 path computation process. 185 When a switching node has the ability to perform wavelength 186 conversion, the wavelength-continuity constraint can be relaxed, and 187 a LSC Label Switched Path (LSP) may use different wavelengths on 188 different links along its route from origin to destination. It is, 189 however, to be noted that wavelength converters may be limited due 190 to their relatively high cost, while the number of WDM channels that 191 can be supported in a fiber is also limited. As a WSON can be 192 composed of network nodes that cannot perform wavelength conversion, 193 nodes with limited wavelength conversion, and nodes with full 194 wavelength conversion abilities, wavelength assignment is an 195 additional routing constraint to be considered in all lightpath 196 computation. 198 For example (see Figure 1), within a translucent WSON, a LSC LSP may 199 be established between interfaces I1 and I2, spanning 2 transparent 200 segments (optical paths) where the wavelength continuity constraint 201 applies (i.e. the same unique wavelength must be assigned to the LSP 202 at each TE link of the segment). If the LSC LSP induced a Forwarding 203 Adjacency / TE link, the switching capabilities of the TE link would 204 be (X X) where X refers to the switching capability of I1 and I2. 205 For example, X can be PSC, TDM, etc. 207 This document aligns with GMPLS extensions for PCEP [PCEP-GMPLS] for 208 generic property such as label, label-set and label assignment 209 noting that wavelength is a type of label. Wavelength restrictions 210 and constraints are also formulated in terms of labels per 211 [RFC7579]. 213 The optical modulation properties, which are also referred to as 214 signal compatibility, are already considered in signaling in 215 [RFC7581] and [RFC7688]. In order to improve the signal quality and 216 limit some optical effects several advanced modulation processing 217 are used. Those modulation properties contribute not only to optical 218 signal quality checks but also constrain the selection of sender and 219 receiver, as they should have matching signal processing 220 capabilities. This document includes signal compatibility 221 constraints as part of RWA path computation. That is, the signal 222 processing capabilities (e.g., modulation and FEC) by the means of 223 optical interface class (OIC) must be compatible between the sender 224 and the receiver of the optical path across all optical elements. 226 This document, however, does not address optical impairments as part 227 of RWA path computation. See [RFC6566] for more information on 228 optical impairments and GMPLS. 230 4. Encoding of a RWA Path Request 232 Figure 2 shows one typical PCE based implementation, which is 233 referred to as the Combined Process (R&WA). With this architecture, 234 the two processes of routing and wavelength assignment are accessed 235 via a single PCE. This architecture is the base architecture from 236 which the requirements have been specified in [RFC7449] and the PCEP 237 extensions that are going to be specified in this document are based 238 on this architecture. 240 +----------------------------+ 241 +-----+ | +-------+ +--+ | 242 | | | |Routing| |WA| | 243 | PCC |<----->| +-------+ +--+ | 244 | | | | 245 +-----+ | PCE | 246 +----------------------------+ 248 Figure 2 Combined Process (R&WA) architecture 250 4.1. Wavelength Assignment (WA) Object 252 Wavelength allocation can be performed by the PCE by different 253 means: 255 (a) By means of Explicit Label Control (ELC) where the PCE allocates 256 which label to use for each interface/node along the path. in the 257 sense that the allocated labels MAY appear after an interface route 258 subobject. 259 (b) By means of a Label Set where the PCE provides a range of 260 potential labels to allocate by each node along the path. 262 Option (b) allows distributed label allocation (performed during 263 signaling) to complete wavelength assignment. 265 Additionally, given a range of potential labels to allocate, the 266 request SHOULD convey the heuristic / mechanism to the allocation. 268 The format of a PCReq message after incorporating the WA object is 269 as follows: 271 ::= 273 [] 275 277 Where: 279 ::=[] 281 ::= 283 285 287 [other optional objects...] 289 If the WA object is present in the request, it MUST be encoded after 290 the ENDPOINTS object. Orderings with respect to the other following 291 objects are irrelevant. 293 The format of the Wavelength Assignment (WA) object body is as 294 follows: 296 0 1 2 3 297 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 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | Reserved | Flags |M| 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | Wavelength Selection TLV | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | Wavelength Restriction Constraint TLV | 304 . . 305 . . 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 // Optional TLVs // 308 | | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 Figure 3 WA Object 313 o Reserved (16 bits) 315 o Flags (16 bits) 317 The following new flags SHOULD be set 319 . M (Mode - 1 bit): M bit is used to indicate the mode of 320 wavelength assignment. When M bit is set to 1, this indicates 321 that the label assigned by the PCE must be explicit. That is, 322 the selected way to convey the allocated wavelength is by means 323 of Explicit Label Control (ELC) [RFC3471] for each hop of a 324 computed LSP. Otherwise, the label assigned by the PCE needs 325 not be explicit (i.e., it can be suggested in the form of label 326 set objects in the corresponding response, to allow distributed 327 WA. In such case, the PCE MUST return a Label Set Field as 328 described in Section 2.6 of [RFC7579] in the response. See 329 Section 5 of this document for the encoding discussion of a 330 Label Set Field in a PCRep message. 332 4.2. Wavelength Selection TLV 334 The Wavelength Selection TLV is used to indicate the wavelength 335 selection constraint in regard to the order of wavelength assignment 336 to be returned by the PCE. This TLV is only applied when M bit is 337 set in the WA Object specified in Section 4.1. This TLV MUST NOT be 338 used when the M bit is cleared. 340 The encoding of this TLV is specified as the Wavelength Selection 341 Sub-TLV in Section 4.2.2 of [RFC7689]. 343 4.3. Wavelength Restriction Constraint TLV 345 For any request that contains a wavelength assignment, the requester 346 (PCC) MUST be able to specify a restriction on the wavelengths to be 347 used. This restriction is to be interpreted by the PCE as a 348 constraint on the tuning ability of the origination laser 349 transmitter or on any other maintenance related constraints. Note 350 that if the LSP LSC spans different segments, the PCE MUST have 351 mechanisms to know the tunability restrictions of the involved 352 wavelength converters / regenerators, e.g. by means of the TED 353 either via IGP or NMS. Even if the PCE knows the tunability of the 354 transmitter, the PCC MUST be able to apply additional constraints to 355 the request. 357 The format of the Wavelength Restriction Constraint TLV is as 358 follows: 360 ::= 362 364 ( )... 366 Where 368 ::= [] 370 See Section 4.3.1. for the encoding of the Link Identifiers Field. 372 The Wavelength Restriction Constraint TLV type is TBD, recommended 373 value is TBD. This TLV MAY appear more than once to be able to 374 specify multiple restrictions. 376 The TLV data is defined as follows: 378 0 1 2 3 379 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 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | Action | Count | Reserved | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | Link Identifiers | 384 | . . . | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | Wavelength Restriction Field | 387 // . . . . // 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 Figure 4 Wavelength Restriction Constraint TLV Encoding 392 o Action: 8 bits 394 . 0 - Inclusive List indicates that one or more link identifiers 395 are included in the Link Set. Each identifies a separate link 396 that is part of the set. 398 . 1 - Inclusive Range indicates that the Link Set defines a 399 range of links. It contains two link identifiers. The first 400 identifier indicates the start of the range (inclusive). The 401 second identifier indicates the end of the range (inclusive). 402 All links with numeric values between the bounds are 403 considered to be part of the set. A value of zero in either 404 position indicates that there is no bound on the corresponding 405 portion of the range. 407 Note that "interfaces" such as those discussed in the Interfaces MIB 408 [RFC2863] are assumed to be bidirectional. 410 o Count: The number of the link identifiers (8 bits) 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: Reserved for future use (16 bits) 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 4.3.1. Link Identifier Field 428 The link identifier field can be an IPv4, IPv6 or unnumbered 429 interface ID. 431 ::= 433 | | 435 The encoding of each case is as follows: 437 IPv4 prefix Entry 439 0 1 2 3 440 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 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 | Type = 1 | Reserved | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 | IPv4 address (4 bytes) | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 IPv6 prefix Sub-TLV 449 0 1 2 3 450 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 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | Type = 2 | Reserved | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | IPv6 address (16 bytes) | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | IPv6 address (continued) | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | IPv6 address (continued) | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 | IPv6 address (continued) | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 Unnumbered Interface ID Sub-TLV 465 0 1 2 3 466 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 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 | Type = 3 | Reserved | 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 | TE Node ID | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 | Interface ID | 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 4.3.2. Wavelength Restriction Field 477 The Wavelength Restriction Field of the wavelength restriction TLV 478 is encoded as a Label Set field as specified in Section 2.6 in 479 [RFC7579] with base label encoded as a 32 bit LSC label, defined in 480 [RFC6205]. See [RFC6205] for a description of Grid, C.S, Identifier 481 and n, as well as [RFC7579] for the details of each action. 483 0 1 2 3 485 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 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 | Action| Num Labels | Length | 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 |Grid | C.S | Identifier | n | 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 | Additional fields as necessary per action | 493 | | 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 Action: 498 0 - Inclusive List 500 1 - Exclusive List 502 2 - Inclusive Range 504 3 - Exclusive Range 506 4 - Bitmap Set 508 Num Labels is generally the number of labels. It has a specific 509 meaning depending on the action value. Num Labels is a 12 bit 510 integer. 512 Length is the length in bytes of the entire label set field. 514 See Sections 2.6.1 - 2.6.3 of [RFC7579] for details on additional 515 field discussion for each action. 517 4.4. Signal processing capability restrictions 519 Path computation for WSON includes the check of signal processing 520 capabilities, those capability MAY be provided by the IGP. Moreover, 521 a PCC should be able to indicate additional restrictions for those 522 signal compatibility, either on the endpoint or any given link. 524 The supported signal processing capabilities are the one described 525 in [RFC7446]: 527 . Optical Interface Class List 529 . Bit Rate 531 . Client Signal 533 The Bit Rate restriction is already expressed in [PCEP-GMPLS] in the 534 BANDWIDTH object. 536 In order to support the Optical Interface Class information and the 537 Client Signal information new TLVs are introduced as endpoint- 538 restriction in the END-POINTS type Generalized endpoint: 540 . Client Signal TLV 542 . Optical Interface Class List TLV 544 The END-POINTS type generalized endpoint is extended as follows: 546 ::= 548 550 [...] 552 Where 554 signal-compatibility-restriction ::= 556 558 The encoding for the Optical Interface Class List is described in 559 Section 4.1 of [RFC7581]. 561 The encoding for the Client Signal Information is described in 562 Section 4.2 of [RFC7581]. 564 4.4.1. Signal Processing Exclusion XRO Sub-Object 566 The PCC/PCE should be able to exclude particular types of signal 567 processing along the path in order to handle client restriction or 568 multi-domain path computation. 570 In order to support the exclusion a new XRO sub-object is defined: 571 the signal processing exclusion: 573 0 1 2 3 575 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 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 |X| Type = X | Length | Reserved | Attribute | 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 | sub-sub objects | 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 Figure 5 Signaling Processing XRO Sub-Object 584 Refer to [RFC5521] for the definition of X, Type, Length and 585 Attribute. 587 The Attribute field indicates how the exclusion sub-object is to be 588 interpreted. The Attribute can only be 0 (Interface) or 1 (Node). 590 The sub-sub objects are encoded as in RSVP signaling definition 591 [RFC7689]. 593 4.4.2. IRO sub-object: signal processing inclusion 595 Similar to the XRO sub-object the PCC/PCE should be able to include 596 particular types of signal processing along the path in order to 597 handle client restriction or multi-domain path computation. 599 This is supported by adding the sub-object "processing" defined for 600 ERO in [RFC7689] to the PCEP IRO object. 602 5. Encoding of a RWA Path Reply 604 This section provides the encoding of a RWA Path Reply for 605 wavelength allocation request as discussed in Section 4. Recall that 606 wavelength allocation can be performed by the PCE by different 607 means: 609 (a) By means of Explicit Label Control (ELC) where the PCE 610 allocates which label to use for each interface/node along the 611 path. 612 (b) By means of a Label Set where the PCE provides a range of 613 potential labels to allocate by each node along the path. 615 Option (b) allows distributed label allocation (performed during 616 signaling) to complete wavelength allocation. 618 The Wavelength Allocation TLV type is TBD, recommended value is TBD. 619 The TLV data is defined as follows: 621 0 1 2 3 622 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 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 | Type | Length |M| 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 | Link Identifier | 627 | . . . | 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 | Allocated Wavelength(s) | 630 // . . . . // 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 Figure 6 Wavelength Allocation TLV Encoding 635 o Type (16 bits): The type of the TLV. 637 o Length (15 bits): The length of the TLV including the Type and 638 Length fields. 640 o M (Mode): 1 bit 641 - 0 indicates the allocation is under Explicit Label Control. 643 - 1 indicates the allocation is expressed in Label Sets. 645 Note that all link identifiers in the same list must be of the same 646 type. 648 o Link Identifier (variable): Identifies the interface to which 649 assignment wavelength(s) is applied. See Section 4.3.1. for Link 650 Identifier encoding. 652 o Allocated Wavelength(s) (variable): Indicates the allocated 653 wavelength(s) to the link identifier. See Section 4.3.2 for encoding 654 details. 656 This TLV is encoded as an attributes TLV, per [RFC5420], which is 657 carried in the ERO LSP Attribute Subobjects per [RFC7570]. The type 658 value of the Wavelength Restriction Constraint TLV is TBD by IANA. 660 5.1. Error Indicator 662 To indicate errors associated with the RWA request, a new Error Type 663 (TDB) and subsequent error-values are defined as follows for 664 inclusion in the PCEP-ERROR Object: 666 A new Error-Type (TDB) and subsequent error-values are defined as 667 follows: 669 . Error-Type=TBD; Error-value=1: if a PCE receives a RWA request 670 and the PCE is not capable of processing the request due to 671 insufficient memory, the PCE MUST send a PCErr message with a 672 PCEP-ERROR Object (Error-Type=TDB) and an Error-value(Error- 673 value=1). The PCE stops processing the request. The 674 corresponding RWA request MUST be cancelled at the PCC. 676 . Error-Type=TBD; Error-value=2: if a PCE receives a RWA request 677 and the PCE is not capable of RWA computation, the PCE MUST 678 send a PCErr message with a PCEP-ERROR Object (Error-Type=TDB) 679 and an Error-value (Error-value=2). The PCE stops processing 680 the request. The corresponding RWA computation MUST be 681 cancelled at the PCC. 683 5.2. NO-PATH Indicator 685 To communicate the reason(s) for not being able to find RWA for the 686 path request, the NO-PATH object can be used in the corresponding 687 response. The format of the NO-PATH object body is defined in 688 [RFC5440]. The object may contain a NO-PATH-VECTOR TLV to provide 689 additional information about why a path computation has failed. 691 One new bit flag is defined to be carried in the Flags field in the 692 NO-PATH-VECTOR TLV carried in the NO-PATH Object. 694 . Bit TDB: When set, the PCE indicates no feasible route was 695 found that meets all the constraints (e.g., wavelength 696 restriction, signal compatibility, etc.) associated with RWA. 698 6. Manageability Considerations 700 Manageability of WSON Routing and Wavelength Assignment (RWA) with 701 PCE must address the following considerations: 703 6.1. Control of Function and Policy 705 In addition to the parameters already listed in Section 8.1 of 706 [RFC5440], a PCEP implementation SHOULD allow configuring the 707 following PCEP session parameters on a PCC: 709 . The ability to send a WSON RWA request. 711 In addition to the parameters already listed in Section 8.1 of 712 [RFC5440], a PCEP implementation SHOULD allow configuring the 713 following PCEP session parameters on a PCE: 715 . The support for WSON RWA. 717 . A set of WSON RWA specific policies (authorized sender, 718 request rate limiter, etc). 720 These parameters may be configured as default parameters for any 721 PCEP session the PCEP speaker participates in, or may apply to a 722 specific session with a given PCEP peer or a specific group of 723 sessions with a specific group of PCEP peers. 725 6.2. Information and Data Models, e.g. MIB module 727 Extensions to the PCEP MIB module defined in [RFC7420] should be 728 defined, so as to cover the WSON RWA information introduced in this 729 document. A future revision of this document will list the 730 information that should be added to the MIB module. 732 6.3. Liveness Detection and Monitoring 734 Mechanisms defined in this document do not imply any new liveness 735 detection and monitoring requirements in addition to those already 736 listed in section 8.3 of [RFC5440]. 738 6.4. Verifying Correct Operation 740 Mechanisms defined in this document do not imply any new 741 verification requirements in addition to those already listed in 742 section 8.4 of [RFC5440] 744 6.5. Requirements on Other Protocols and Functional Components 746 The PCE Discovery mechanisms ([RFC5089] and [RFC5088]) may be used 747 to advertise WSON RWA path computation capabilities to PCCs. 749 6.6. Impact on Network Operation 751 Mechanisms defined in this document do not imply any new network 752 operation requirements in addition to those already listed in 753 section 8.6 of [RFC5440]. 755 7. Security Considerations 757 This document has no requirement for a change to the security models 758 within PCEP . However the additional information distributed in 759 order to address the RWA problem represents a disclosure of network 760 capabilities that an operator may wish to keep private. 761 Consideration should be given to securing this information. 763 8. IANA Considerations 765 IANA maintains a registry of PCEP parameters. IANA has made 766 allocations from the sub-registries as described in the following 767 sections. 769 8.1. New PCEP Object 771 As described in Section 4.1, a new PCEP Object is defined to carry 772 wavelength assignment related constraints. IANA is to allocate the 773 following from "PCEP Objects" sub-registry 774 (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-objects): 776 Object Class Name Object Reference 777 Value Type 778 --------------------------------------------------------- 780 TDB WA 1: Wavelength-Assignment [This.I-D] 782 8.2. New PCEP TLV: Wavelength Selection TLV 784 As described in Sections 4.2, a new PCEP TLV is defined to indicate 785 wavelength selection constraints. IANA is to allocate this new TLV 786 from the "PCEP TLV Type Indicators" subregistry 787 (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type- 788 indicators). 790 Value Description Reference 791 --------------------------------------------------------- 792 TBD Wavelength Selection [This.I-D] 794 8.3. New PCEP TLV: Wavelength Restriction Constraint TLV 796 As described in Sections 4.3, a new PCEP TLV is defined to indicate 797 wavelength restriction constraints. IANA is to allocate this new TLV 798 from the "PCEP TLV Type Indicators" subregistry 799 (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type- 800 indicators). 802 Value Description Reference 803 --------------------------------------------------------- 804 TBD Wavelength Restriction [This.I-D] 805 Constraint 807 8.4. New PCEP TLV: Wavelength Allocation TLV 809 As described in Section 5, a new PCEP TLV is defined to indicate the 810 allocation of wavelength(s) by the PCE in response to a request by 811 the PCC. IANA is to allocate this new TLV from the "PCEP TLV Type 812 Indicators" subregistry 813 (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type- 814 indicators). 816 Value Description Reference 817 --------------------------------------------------------- 818 TBD Wavelength Allocation [This.I-D] 820 8.5. New PCEP TLV: Optical Interface Class List TLV 822 As described in Section 4.3, a new PCEP TLV is defined to indicate 823 the optical interface class list. IANA is to allocate this new TLV 824 from the "PCEP TLV Type Indicators" subregistry 825 (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type- 826 indicators). 828 Value Description Reference 829 --------------------------------------------------------- 830 TBD Optical Interface [This.I-D] 831 Class List 833 8.6. New PCEP TLV: Client Signal TLV 835 As described in Section 4.3, a new PCEP TLV is defined to indicate 836 the client signal information. IANA is to allocate this new TLV from 837 the "PCEP TLV Type Indicators" subregistry 838 (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type- 839 indicators). 841 Value Description Reference 842 --------------------------------------------------------- 843 TBD Client Signal Information [This.I-D] 845 8.7. New No-Path Reasons 847 As described in Section 5.2., a new bit flag are defined to be 848 carried in the Flags field in the NO-PATH-VECTOR TLV carried in the 849 NO-PATH Object. This flag, when set, indicates that no feasible 850 route was found that meets all the RWA constraints (e.g., wavelength 851 restriction, signal compatibility, etc.) associated with a RWA path 852 computation request. 854 IANA is to allocate this new bit flag from the "PCEP NO-PATH-VECTOR 855 TLV Flag Field" subregistry 856 (http://www.iana.org/assignments/pcep/pcep.xhtml#no-path-vector- 857 tlv). 859 Bit Description Reference 860 ----------------------------------------------------- 861 TBD No RWA constraints met [This.I-D] 863 8.8. New Error-Types and Error-Values 865 As described in Section 5.1, new PCEP error codes are defined for 866 WSON RWA errors. IANA is to allocate from the ""PCEP-ERROR Object 867 Error Types and Values" sub-registry 868 (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-error-object). 870 Error- Meaning Error-Value Reference 871 Type 872 --------------------------------------------------------------- 874 TDB WSON RWA Error 1: Insufficient [This.I-D] 875 Memory 877 2: RWA computation {This.I-D] 878 Not supported 880 9. Acknowledgments 882 The authors would like to thank Adrian Farrel for many helpful 883 comments that greatly improved the contents of this draft. 885 This document was prepared using 2-Word-v2.0.template.dot. 887 10. References 889 10.1. Informative References 891 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 892 Requirement Levels", BCP 14, RFC 2119, March 1997. 894 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 895 MIB", RFC 2863, June 2000. 897 [RFC4003] Berger, L., "GMPLS Signaling Procedure for Egress 898 Control", RFC 4003, February 2005. 900 [RFC3471] Berger, L. (Editor), "Generalized Multi-Protocol Label 901 Switching (GMPLS) Signaling Functional Description", RFC 902 3471. January 2003. 904 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 905 Element (PCE)-Based Architecture", RFC 4655, August 2006. 907 [RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE) 908 Communication Protocol Generic Requirements", RFC 4657, 909 September 2006. 911 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 912 Element (PCE) communication Protocol", RFC 5440, March 913 2009. 915 [RFC5088] Le Roux, JL, JP. Vasseur, Y. Ikejiri, and R. Zhang, "OSPF 916 Protocol Extensions for Path Computation Element (PCE) 917 Discovery," RFC 5088, January 2008. 919 [RFC5089] Le Roux, JL, JP. Vasseur, Y. Ikejiri, and R. Zhang, "IS-IS 920 Protocol Extensions for Path Computation Element (PCE) 921 Discovery," RFC 5089, January 2008. 923 [RFC6163] Lee, Y. and Bernstein, G. (Editors), and W. Imajuku, 924 "Framework for GMPLS and PCE Control of Wavelength 925 Switched Optical Networks", RFC 6163, March 2011. 927 [RFC6566] Y. Lee, G. Bernstein, D. Li, G. Martinelli, "A Framework 928 for the Control of Wavelength Switched Optical Networks 929 (WSON) with Impairments", RFC 6566, March 2012. 931 [RFC7420] Koushik, A., E. Stephan, Q. Zhao, D. King, and J. 932 Hardwick, "Path Computation Element Communication Protocol 933 (PCEP) Management Information Base (MIB) Module", RFC 934 7420, December 2014. 936 [RFC7446] Y. Lee, G. Bernstein. (Editors), "Routing and Wavelength 937 Assignment Information Model for Wavelength Switched 938 Optical Networks", RFC 7446, February 2015. 940 [RFC7449] Lee, Y., et. al., "PCEP Requirements for WSON Routing and 941 Wavelength Assignment", RFC 7449, February 2015. 943 10.2. Normative References 945 [PCEP-GMPLS] Margaria, et al., "PCEP extensions for GMPLS", draft- 946 ietf-pce-gmpls-pcep-extensions, work in progress. 948 [RFC5420] Farrel, A. "Encoding of Attributes for MPLS LSP 949 Establishment Using Resource Reservation Protocol Traffic 950 Engineering (RSVP-TE)", RFC5420, February 2009. 952 [RFC5521] Oki, E, T. Takeda, and A. Farrel, "Extensions to the Path 953 Computation Element Communication Protocol (PCEP) for 954 Route Exclusions", RFC 5521, May 2009. 956 [RFC6205] Tomohiro, O. and D. Li, "Generalized Labels for Lambda- 957 Switching Capable Label Switching Routers", RFC 6205, 958 January, 2011. 960 [RFC7570] Margaria, et al., "Label Switched Path (LSP) Attribute in 961 the Explicit Route Object (ERO)", RFC 7570, July 2015. 963 [RFC7689] Bernstein et al, "Signaling Extensions for Wavelength 964 Switched Optical Networks", RFC 7689, November 2015. 966 [RFC7688] Y. Lee, and G. Bernstein, "OSPF Enhancement for Signal and 967 Network Element Compatibility for Wavelength Switched 968 Optical Networks", RFC 7688, November 2015. 970 [RFC7581] Bernstein and Lee, "Routing and Wavelength Assignment 971 Information Encoding for Wavelength Switched Optical 972 Networks", RFC7581, June 2015. 974 [RFC7579] Bernstein and Lee, "General Network Element Constraint 975 Encoding for GMPLS Controlled Networks", RFC 7579, June 976 2015. 978 11. Contributors 979 Authors' Addresses 981 Young Lee, Editor 982 Huawei Technologies 983 1700 Alma Drive, Suite 100 984 Plano, TX 75075, USA 985 Phone: (972) 509-5599 (x2240) 986 Email: leeyoung@huawei.com 988 Ramon Casellas, Editor 989 CTTC PMT Ed B4 Av. Carl Friedrich Gauss 7 990 08860 Castelldefels (Barcelona) 991 Spain 992 Phone: (34) 936452916 993 Email: ramon.casellas@cttc.es 995 Fatai Zhang 996 Huawei Technologies 997 Email: zhangfatai@huawei.com 999 Cyril Margaria 1000 Nokia Siemens Networks 1001 St Martin Strasse 76 1002 Munich, 81541 1003 Germany 1004 Phone: +49 89 5159 16934 1005 Email: cyril.margaria@nsn.com 1007 Oscar Gonzalez de Dios 1008 Telefonica Investigacion y Desarrollo 1009 C/ Emilio Vargas 6 1010 Madrid, 28043 1011 Spain 1012 Phone: +34 91 3374013 1013 Email: ogondio@tid.es 1015 Greg Bernstein 1016 Grotto Networking 1017 Fremont, CA, USA 1018 Phone: (510) 573-2237 1019 Email: gregb@grotto-networking.com