idnits 2.17.1 draft-ietf-pce-wson-rwa-ext-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 16, 2016) is 2686 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: February 2017 CTTC 7 December 16, 2016 9 PCEP Extension for WSON Routing and Wavelength Assignment 11 draft-ietf-pce-wson-rwa-ext-06.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 February 16, 2017. 46 Copyright Notice 48 Copyright (c) 2016 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..........................................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..............................19 86 7. Security Considerations.......................................19 87 8. IANA Considerations...........................................19 88 8.1. New PCEP Object..........................................19 89 8.2. New PCEP TLV: Wavelength Selection TLV...................20 90 8.3. New PCEP TLV: Wavelength Restriction Constraint TLV......20 91 8.4. New PCEP TLV: Wavelength Allocation TLV..................20 92 8.5. New PCEP TLV: Optical Interface Class List TLV...........21 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.........................22 96 9. Acknowledgments...............................................22 97 10. References...................................................22 98 10.1. Informative References..................................22 99 10.2. Normative References....................................24 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. In this document, only 146 wavelength converters that require electrical signal regeneration 147 are considered. 149 A Lambda Switch Capable (LSC) Label Switched Path (LSP) may span one 150 or several transparent segments, which are delimited by 3R 151 regenerators (typically with electronic regenerator and optional 152 wavelength conversion). Each transparent segment or path in WSON is 153 referred to as an optical path. An optical path may span multiple 154 fiber links and the path should be assigned the same wavelength for 155 each link. In such case, the optical path is said to satisfy the 156 wavelength-continuity constraint. Figure 1 illustrates the 157 relationship between a LSC LSP and transparent segments (optical 158 paths). 160 +---+ +-----+ +-----+ +-----+ +-----+ 161 | |I1 | | | | | | I2| | 162 | |o------| |-------[(3R) ]------| |--------o| | 163 | | | | | | | | | | 164 +---+ +-----+ +-----+ +-----+ +-----+ 165 (X LSC) (LSC LSC) (LSC LSC) (LSC X) SwCap 166 <-------> <-------> <-----> <-------> 167 <-----------------------><----------------------> 168 Transparent Segment Transparent Segment 169 <-------------------------------------------------> 170 LSC LSP 172 Figure 1 Illustration of a LSC LSP and transparent segments 173 Note that two optical paths within a WSON LSP do not need to operate 174 on the same wavelength (due to the wavelength conversion 175 capabilities). Two optical paths that share a common fiber link 176 cannot be assigned the same wavelength; Otherwise, both signals 177 would interfere with each other. Note that advanced additional 178 multiplexing techniques such as polarization based multiplexing are 179 not addressed in this document since the physical layer aspects are 180 not currently standardized. Therefore, assigning the proper 181 wavelength on a lightpath is an essential requirement in the optical 182 path computation process. 184 When a switching node has the ability to perform wavelength 185 conversion, the wavelength-continuity constraint can be relaxed, and 186 a LSC Label Switched Path (LSP) may use different wavelengths on 187 different links along its route from origin to destination. It is, 188 however, to be noted that wavelength converters may be limited due 189 to their relatively high cost, while the number of WDM channels that 190 can be supported in a fiber is also limited. As a WSON can be 191 composed of network nodes that cannot perform wavelength conversion, 192 nodes with limited wavelength conversion, and nodes with full 193 wavelength conversion abilities, wavelength assignment is an 194 additional routing constraint to be considered in all lightpath 195 computation. 197 For example (see Figure 1), within a translucent WSON, a LSC LSP may 198 be established between interfaces I1 and I2, spanning 2 transparent 199 segments (optical paths) where the wavelength continuity constraint 200 applies (i.e. the same unique wavelength must be assigned to the LSP 201 at each TE link of the segment). If the LSC LSP induced a Forwarding 202 Adjacency / TE link, the switching capabilities of the TE link would 203 be (X X) where X refers to the switching capability of I1 and I2. 204 For example, X can be PSC, TDM, etc. 206 This document aligns with GMPLS extensions for PCEP [PCEP-GMPLS] for 207 generic property such as label, label-set and label assignment 208 noting that wavelength is a type of label. Wavelength restrictions 209 and constraints are also formulated in terms of labels per 210 [RFC7579]. 212 The optical modulation properties, which are also referred to as 213 signal compatibility, are already considered in signaling in 214 [RFC7581] and [RFC7688]. In order to improve the signal quality and 215 limit some optical effects several advanced modulation processing 216 are used. Those modulation properties contribute not only to optical 217 signal quality checks but also constrain the selection of sender and 218 receiver, as they should have matching signal processing 219 capabilities. This document includes signal compatibility 220 constraints as part of RWA path computation. That is, the signal 221 processing capabilities (e.g., modulation and FEC) by the means of 222 optical interface class (OIC) must be compatible between the sender 223 and the receiver of the optical path across all optical elements. 225 This document, however, does not address optical impairments as part 226 of RWA path computation. See [RFC6566] for more information on 227 optical impairments and GMPLS. 229 4. Encoding of a RWA Path Request 231 Figure 2 shows one typical PCE based implementation, which is 232 referred to as the Combined Process (R&WA). With this architecture, 233 the two processes of routing and wavelength assignment are accessed 234 via a single PCE. This architecture is the base architecture from 235 which the requirements have been specified in [RFC7449] and the PCEP 236 extensions that are going to be specified in this document based on 237 this architecture. 239 +----------------------------+ 240 +-----+ | +-------+ +--+ | 241 | | | |Routing| |WA| | 242 | PCC |<----->| +-------+ +--+ | 243 | | | | 244 +-----+ | PCE | 245 +----------------------------+ 247 Figure 2 Combined Process (R&WA) architecture 249 4.1. Wavelength Assignment (WA) Object 251 Wavelength allocation can be performed by the PCE by different 252 means: 254 (a) By means of Explicit Label Control (ELC) where the PCE allocates 255 which label to use for each interface/node along the path. in the 256 sense that the allocated labels MAY appear after an interface route 257 subobject. 258 (b) By means of a Label Set where the PCE provides a range of 259 potential labels to allocate by each node along the path. 261 Option (b) allows distributed label allocation (performed during 262 signaling) to complete wavelength assignment. 264 Additionally, given a range of potential labels to allocate, the 265 request SHOULD convey the heuristic / mechanism to the allocation. 267 The format of a PCReq message after incorporating the WA object is 268 as follows: 270 ::= 272 [] 274 276 Where: 278 ::=[] 280 ::= 282 284 286 [other optional objects...] 288 If the WA object is present in the request, it MUST be encoded after 289 the ENDPOINTS object. 291 The format of the Wavelength Assignment (WA) object body is as 292 follows: 294 0 1 2 3 295 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 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | Reserved | Flags |M| 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | Wavelength Selection TLV | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | Wavelength Restriction Constraint TLV | 302 . . 303 . . 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 // Optional TLVs // 306 | | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 Figure 3 WA Object 311 o Reserved (16 bits) 313 o Flags (16 bits) 315 The following new flags SHOULD be set 317 . M (Mode - 1 bit): M bit is used to indicate the mode of 318 wavelength assignment. When M bit is set to 1, this indicates 319 that the label assigned by the PCE must be explicit. That is, 320 the selected way to convey the allocated wavelength is by means 321 of Explicit Label Control (ELC) [RFC4003] for each hop of a 322 computed LSP. Otherwise, the label assigned by the PCE needs 323 not be explicit (i.e., it can be suggested in the form of label 324 set objects in the corresponding response, to allow distributed 325 WA. In such case, the PCE MUST return a Label Set Field as 326 described in Section 2.6 of [RFC7579] in the response. See 327 Section 5 of this document for the encoding discussion of a 328 Label Set Field in a PCRep message. 330 4.2. Wavelength Selection TLV 332 The Wavelength Selection TLV is used to indicate the wavelength 333 selection constraint in regard to the order of wavelength assignment 334 to be returned by the PCE. This TLV is only applied when M bit is 335 set in the WA Object specified in Section 4.1. This TLV MUST NOT be 336 used when the M bit is cleared. 338 The encoding of this TLV is specified as the Wavelength Selection 339 Sub-TLV in Section 4.2.2 of [RFC7689]. 341 4.3. Wavelength Restriction Constraint TLV 343 For any request that contains a wavelength assignment, the requester 344 (PCC) MUST be able to specify a restriction on the wavelengths to be 345 used. This restriction is to be interpreted by the PCE as a 346 constraint on the tuning ability of the origination laser 347 transmitter or on any other maintenance related constraints. Note 348 that if the LSP LSC spans different segments, the PCE MUST have 349 mechanisms to know the tunability restrictions of the involved 350 wavelength converters / regenerators, e.g. by means of the TED 351 either via IGP or NMS. Even if the PCE knows the tunability of the 352 transmitter, the PCC MUST be able to apply additional constraints to 353 the request. 355 The format of the Wavelength Restriction Constraint TLV is as 356 follows: 358 ::= 360 362 ( )... 364 Where 366 ::= [] 368 See Section 4.2.1. for the encoding of the Link Identifiers Field. 370 The Wavelength Restriction Constraint TLV type is TBD, recommended 371 value is TBD. This TLV MAY appear more than once to be able to 372 specify multiple restrictions. 374 The TLV data is defined as follows: 376 0 1 2 3 377 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 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | Action | Count | Reserved | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | Link Identifiers | 382 | . . . | 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 | Wavelength Restriction Field | 385 // . . . . // 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 Figure 4 Wavelength Restriction Constraint TLV Encoding 390 o Action: 8 bits 392 . 0 - Inclusive List indicates that one or more link identifiers 393 are included in the Link Set. Each identifies a separate link 394 that is part of the set. 396 . 1 - Inclusive Range indicates that the Link Set defines a 397 range of links. It contains two link identifiers. The first 398 identifier indicates the start of the range (inclusive). The 399 second identifier indicates the end of the range (inclusive). 400 All links with numeric values between the bounds are 401 considered to be part of the set. A value of zero in either 402 position indicates that there is no bound on the corresponding 403 portion of the range. Note that the Action field can be set to 404 0 when unnumbered link identifier is used. 406 Note that "interfaces" such as those discussed in the Interfaces MIB 407 [RFC2863] are assumed to be bidirectional. 409 o Count: The number of the link identifiers (8 bits) 411 Note that a PCC MAY add a Wavelength restriction that applies to all 412 links by setting the Count field to zero and specifying just a set 413 of wavelengths. 415 Note that all link identifiers in the same list must be of the same 416 type. 418 o Reserved: Reserved for future use (16 bits) 420 o Link Identifiers: Identifies each link ID for which restriction 421 is applied. The length is dependent on the link format and the Count 422 field. See Section 4.2.1. for Link Identifier encoding and Section 423 4.2.2. for the Wavelength Restriction Field encoding, respectively. 425 4.3.1. Link Identifier Field 427 The link identifier field can be an IPv4, IPv6 or unnumbered 428 interface ID. 430 ::= 432 | | 434 The encoding of each case is as follows: 436 IPv4 prefix Entry 438 0 1 2 3 439 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 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | Type = 1 | IPv4 address (4 bytes) | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | IPv4 address (continued) | Prefix Length | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 IPv6 prefix Sub-TLV 448 0 1 2 3 449 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 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 | Type = 2 | IPv6 address (16 bytes) | 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | IPv6 address (continued) | 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | IPv6 address (continued) | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | IPv6 address (continued) | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | IPv6 address (continued) | Prefix Length | 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 Unnumbered Interface ID Sub-TLV 464 0 1 2 3 465 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 [RFC7579] section 479 2.6, as shown below, with base label encoded as a 32 bit LSC label, 480 defined in [RFC6205]. See [RFC6205] for a description of Grid, C.S, 481 Identifier and n, as well as [RFC7579] for the details of each 482 action. 484 0 1 2 3 486 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 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | Action| Num Labels | Length | 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 |Grid | C.S | Identifier | n | 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 | Additional fields as necessary per action | 494 | | 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 Action: 499 0 - Inclusive List 501 1 - Exclusive List 503 2 - Inclusive Range 505 3 - Exclusive Range 507 4 - Bitmap Set 509 Num Labels is generally the number of labels. It has a specific 510 meaning depending on the action value. Num Labels is a 12 bit 511 integer. 513 Length is the length in bytes of the entire label set field. 515 See Sections 2.6.1 - 2.6.3 of [RFC7579] for details on additional 516 field discussion for each action. 518 4.4. Signal processing capability restrictions 520 Path computation for WSON includes the check of signal processing 521 capabilities, those capability MAY be provided by the IGP. Moreover, 522 a PCC should be able to indicate additional restrictions for those 523 signal compatibility, either on the endpoint or any given link. 525 The supported signal processing capabilities are the one described 526 in [RFC7446]: 528 . Optical Interface Class List 530 . Bit Rate 532 . Client Signal 534 The Bit Rate restriction is already expressed in [PCEP-GMPLS] in the 535 BANDWIDTH object. 537 In order to support the Optical Interface Class information and the 538 Client Signal information new TLVs are introduced as endpoint- 539 restriction in the END-POINTS type Generalized endpoint: 541 . Client Signal TLV 543 . Optical Interface Class List TLV 545 The END-POINTS type generalized endpoint is extended as follows: 547 ::= 549 551 [...] 553 Where 555 signal-compatibility-restriction ::= 557 559 The encoding for the Optical Interface Class List is described in 560 Section 4.1 of [RFC7581]. 562 The encoding for the Client Signal Information is described in 563 Section 4.2 of [RFC7581]. 565 4.4.1. Signal Processing Exclusion XRO Sub-Object 567 The PCC/PCE should be able to exclude particular types of signal 568 processing along the path in order to handle client restriction or 569 multi-domain path computation. 571 In order to support the exclusion a new XRO sub-object is defined: 572 the signal processing exclusion: 574 0 1 2 3 576 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 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 |X| Type = X | Length | Reserved | Attribute | 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 | sub-sub objects | 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 Figure 5 Signaling Processing XRO Sub-Object 585 Refer to [RFC5521] for the definition of X, Type, Length and 586 Attribute. 588 The Attribute field indicates how the exclusion sub-object is to be 589 interpreted. The Attribute can only be 0 (Interface) or 1 (Node). 591 The sub-sub objects are encoded as in RSVP signaling definition 592 [RFC7689]. 594 4.4.2. IRO sub-object: signal processing inclusion 596 Similar to the XRO sub-object the PCC/PCE should be able to include 597 particular types of signal processing along the path in order to 598 handle client restriction or multi-domain path computation. 600 This is supported by adding the sub-object "processing" defined for 601 ERO in [RFC7689] to the PCEP IRO object. 603 5. Encoding of a RWA Path Reply 605 This section provides the encoding of a RWA Path Reply for 606 wavelength allocation as discussed in Section 4. Recall that 607 wavelength allocation can be performed by the PCE by different 608 means: 610 (a) By means of Explicit Label Control (ELC) where the PCE 611 allocates which label to use for each interface/node along the 612 path. 613 (b) By means of a Label Set where the PCE provides a range of 614 potential labels to allocate by each node along the path. 616 Option (b) allows distributed label allocation (performed during 617 signaling) to complete wavelength allocation. 619 The Wavelength Allocation TLV type is TBD, recommended value is TBD. 620 The TLV data is defined as follows: 622 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 | Type | Length |M| 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 | Link Identifier | 628 | . . . | 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 | Allocated Wavelength(s) | 631 // . . . . // 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 634 Figure 6 Wavelength Allocation TLV Encoding 636 o Type (16 bits): The type of the TLV. 638 o Length (15 bits): The length of the TLV including the Type and 639 Length fields. 641 o M (Mode): 1 bit 643 - 0 indicates the allocation is under Explicit Label Control. 645 - 1 indicates the allocation is expressed in Label Sets. 647 Note that all link identifiers in the same list must be of the same 648 type. 650 o Link Identifier (variable): Identifies the interface to which 651 assignment wavelength(s) is applied. See Section 4.2.1. for Link 652 Identifier encoding. 654 o Allocated Wavelength(s) (variable): Indicates the allocated 655 wavelength(s) to the link identifier. See Section 4.2.2 for encoding 656 details. 658 This TLV is encoded as an attributes TLV, per [RFC5420], which is 659 carried in the ERO LSP Attribute Subobjects per [RFC7570]. The type 660 value of the Wavelength Restriction Constraint TLV is TBD by IANA. 662 5.1. Error Indicator 664 To indicate errors associated with the RWA request, a new Error Type 665 (TDB) and subsequent error-values are defined as follows for 666 inclusion in the PCEP-ERROR Object: 668 A new Error-Type (TDB) and subsequent error-values are defined as 669 follows: 671 . Error-Type=TBD; Error-value=1: if a PCE receives a RWA request 672 and the PCE is not capable of processing the request due to 673 insufficient memory, the PCE MUST send a PCErr message with a 674 PCEP-ERROR Object (Error-Type=TDB) and an Error-value(Error- 675 value=1). The PCE stops processing the request. The 676 corresponding RWA request MUST be cancelled at the PCC. 678 . Error-Type=TBD; Error-value=2: if a PCE receives a RWA request 679 and the PCE is not capable of RWA computation, the PCE MUST 680 send a PCErr message with a PCEP-ERROR Object (Error-Type=TDB) 681 and an Error-value (Error-value=2). The PCE stops processing 682 the request. The corresponding RWA computation MUST be 683 cancelled at the PCC. 685 5.2. NO-PATH Indicator 687 To communicate the reason(s) for not being able to find RWA for the 688 path request, the NO-PATH object can be used in the corresponding 689 response. The format of the NO-PATH object body is defined in 690 [RFC5440]. The object may contain a NO-PATH-VECTOR TLV to provide 691 additional information about why a path computation has failed. 693 One new bit flag is defined to be carried in the Flags field in the 694 NO-PATH-VECTOR TLV carried in the NO-PATH Object. 696 . Bit TDB: When set, the PCE indicates no feasible route was 697 found that meets all the constraints (e.g., wavelength 698 restriction, signal compatibility, etc.) associated with RWA. 700 6. Manageability Considerations 702 Manageability of WSON Routing and Wavelength Assignment (RWA) with 703 PCE must address the following considerations: 705 6.1. Control of Function and Policy 707 In addition to the parameters already listed in Section 8.1 of 708 [RFC5440], a PCEP implementation SHOULD allow configuring the 709 following PCEP session parameters on a PCC: 711 . The ability to send a WSON RWA request. 713 In addition to the parameters already listed in Section 8.1 of 714 [RFC5440], a PCEP implementation SHOULD allow configuring the 715 following PCEP session parameters on a PCE: 717 . The support for WSON RWA. 719 . A set of WSON RWA specific policies (authorized sender, 720 request rate limiter, etc). 722 These parameters may be configured as default parameters for any 723 PCEP session the PCEP speaker participates in, or may apply to a 724 specific session with a given PCEP peer or a specific group of 725 sessions with a specific group of PCEP peers. 727 6.2. Information and Data Models, e.g. MIB module 729 Extensions to the PCEP MIB module defined in [RFC7420] should be 730 defined, so as to cover the WSON RWA information introduced in this 731 document. A future revision of this document will list the 732 information that should be added to the MIB module. 734 6.3. Liveness Detection and Monitoring 736 Mechanisms defined in this document do not imply any new liveness 737 detection and monitoring requirements in addition to those already 738 listed in section 8.3 of [RFC5440]. 740 6.4. Verifying Correct Operation 742 Mechanisms defined in this document do not imply any new 743 verification requirements in addition to those already listed in 744 section 8.4 of [RFC5440] 746 6.5. Requirements on Other Protocols and Functional Components 748 The PCE Discovery mechanisms ([RFC5089] and [RFC5088]) may be used 749 to advertise WSON RWA path computation capabilities to PCCs. 751 6.6. Impact on Network Operation 753 Mechanisms defined in this document do not imply any new network 754 operation requirements in addition to those already listed in 755 section 8.6 of [RFC5440]. 757 7. Security Considerations 759 This document has no requirement for a change to the security models 760 within PCEP . However the additional information distributed in 761 order to address the RWA problem represents a disclosure of network 762 capabilities that an operator may wish to keep private. 763 Consideration should be given to securing this information. 765 8. IANA Considerations 767 IANA maintains a registry of PCEP parameters. IANA has made 768 allocations from the sub-registries as described in the following 769 sections. 771 8.1. New PCEP Object 773 As described in Section 4.1, a new PCEP Object is defined to carry 774 wavelength assignment related constraints. IANA is to allocate the 775 following from "PCEP Objects" sub-registry 776 (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-objects): 778 Object Class Name Object Reference 779 Value Type 780 --------------------------------------------------------- 782 TDB WA 1: Wavelength-Assignment [This.I-D] 784 8.2. New PCEP TLV: Wavelength Selection TLV 786 As described in Sections 4.2, a new PCEP TLV is defined to indicate 787 wavelength selection constraints. IANA is to allocate this new TLV 788 from the "PCEP TLV Type Indicators" subregistry 789 (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type- 790 indicators). 792 Value Description Reference 793 --------------------------------------------------------- 794 TBD Wavelength Selection [This.I-D] 796 8.3. New PCEP TLV: Wavelength Restriction Constraint TLV 798 As described in Sections 4.3, a new PCEP TLV is defined to indicate 799 wavelength restriction constraints. IANA is to allocate this new TLV 800 from the "PCEP TLV Type Indicators" subregistry 801 (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type- 802 indicators). 804 Value Description Reference 805 --------------------------------------------------------- 806 TBD Wavelength Restriction [This.I-D] 807 Constraint 809 8.4. New PCEP TLV: Wavelength Allocation TLV 811 As described in Section 5, a new PCEP TLV is defined to indicate the 812 allocation of wavelength(s) by the PCE in response to a request by 813 the PCC. IANA is to allocate this new TLV from the "PCEP TLV Type 814 Indicators" subregistry 815 (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type- 816 indicators). 818 Value Description Reference 819 --------------------------------------------------------- 820 TBD Wavelength Allocation [This.I-D] 822 8.5. New PCEP TLV: Optical Interface Class List TLV 824 As described in Section 4.3, a new PCEP TLV is defined to indicate 825 the optical interface class list. IANA is to allocate this new TLV 826 from the "PCEP TLV Type Indicators" subregistry 827 (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type- 828 indicators). 830 Value Description Reference 831 --------------------------------------------------------- 832 TBD Optical Interface [This.I-D] 833 Class List 835 8.6. New PCEP TLV: Client Signal TLV 837 As described in Section 4.3, a new PCEP TLV is defined to indicate 838 the client signal information. IANA is to allocate this new TLV from 839 the "PCEP TLV Type Indicators" subregistry 840 (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type- 841 indicators). 843 Value Description Reference 844 --------------------------------------------------------- 845 TBD Client Signal Information [This.I-D] 847 8.7. New No-Path Reasons 849 As described in Section 5.2., a new bit flag are defined to be 850 carried in the Flags field in the NO-PATH-VECTOR TLV carried in the 851 NO-PATH Object. This flag, when set, indicates that no feasible 852 route was found that meets all the RWA constraints (e.g., wavelength 853 restriction, signal compatibility, etc.) associated with a RWA path 854 computation request. 856 IANA is to allocate this new bit flag from the "PCEP NO-PATH-VECTOR 857 TLV Flag Field" subregistry 858 (http://www.iana.org/assignments/pcep/pcep.xhtml#no-path-vector- 859 tlv). 861 Bit Description Reference 862 ----------------------------------------------------- 863 TBD No RWA constraints met [This.I-D] 865 8.8. New Error-Types and Error-Values 867 As described in Section 5.1, new PCEP error codes are defined for 868 WSON RWA errors. IANA is to allocate from the ""PCEP-ERROR Object 869 Error Types and Values" sub-registry 870 (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-error-object). 872 Error- Meaning Error-Value Reference 873 Type 874 --------------------------------------------------------------- 876 TDB WSON RWA Error 1: Insufficient [This.I-D] 877 Memory 879 2: RWA computation {This.I-D] 880 Not supported 882 9. Acknowledgments 884 The authors would like to thank Adrian Farrel for many helpful 885 comments that greatly improved the contents of this draft. 887 This document was prepared using 2-Word-v2.0.template.dot. 889 10. References 891 10.1. Informative References 893 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 894 Requirement Levels", BCP 14, RFC 2119, March 1997. 896 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 897 MIB", RFC 2863, June 2000. 899 [RFC4003] Berger, L., "GMPLS Signaling Procedure for Egress Control", 900 RFC 4003, February 2005. 902 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 903 Element (PCE)-Based Architecture", RFC 4655, August 2006. 905 [RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE) 906 Communication Protocol Generic Requirements", RFC 4657, 907 September 2006. 909 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 910 Element (PCE) communication Protocol", RFC 5440, March 911 2009. 913 [RFC5088] Le Roux, JL, JP. Vasseur, Y. Ikejiri, and R. Zhang, "OSPF 914 Protocol Extensions for Path Computation Element (PCE) 915 Discovery," RFC 5088, January 2008. 917 [RFC5089] Le Roux, JL, JP. Vasseur, Y. Ikejiri, and R. Zhang, "IS-IS 918 Protocol Extensions for Path Computation Element (PCE) 919 Discovery," RFC 5089, January 2008. 921 [RFC6163] Lee, Y. and Bernstein, G. (Editors), and W. Imajuku, 922 "Framework for GMPLS and PCE Control of Wavelength 923 Switched Optical Networks", RFC 6163, March 2011. 925 [RFC6566] Y. Lee, G. Bernstein, D. Li, G. Martinelli, "A Framework 926 for the Control of Wavelength Switched Optical Networks 927 (WSON) with Impairments", RFC 6566, March 2012. 929 [RFC7420] Koushik, A., E. Stephan, Q. Zhao, D. King, and J. 930 Hardwick, "Path Computation Element Communication Protocol 931 (PCEP) Management Information Base (MIB) Module", RFC 932 7420, December 2014. 934 [RFC7446] Y. Lee, G. Bernstein. (Editors), "Routing and Wavelength 935 Assignment Information Model for Wavelength Switched 936 Optical Networks", RFC 7446, February 2015. 938 [RFC7449] Lee, Y., et. al., "PCEP Requirements for WSON Routing and 939 Wavelength Assignment", RFC 7449, February 2015. 941 10.2. Normative References 943 [PCEP-GMPLS] Margaria, et al., "PCEP extensions for GMPLS", draft- 944 ietf-pce-gmpls-pcep-extensions, work in progress. 946 [RFC5420] Farrel, A. "Encoding of Attributes for MPLS LSP 947 Establishment Using Resource Reservation Protocol Traffic 948 Engineering (RSVP-TE)", RFC5420, February 2009. 950 [RFC5521] Oki, E, T. Takeda, and A. Farrel, "Extensions to the Path 951 Computation Element Communication Protocol (PCEP) for 952 Route Exclusions", RFC 5521, April 2009. 954 [RFC6205] Tomohiro, O. and D. Li, "Generalized Labels for Lambda- 955 Switching Capable Label Switching Routers", RFC 6205, 956 January, 2011. 958 [RFC7570] Margaria, et al., "Label Switched Path (LSP) Attribute in 959 the Explicit Route Object (ERO)", RFC 7570, July 2015. 961 [RFC7689] Bernstein et al, "Signaling Extensions for Wavelength 962 Switched Optical Networks", RFC 7689, November 2015. 964 [RFC7688] Y. Lee, and G. Bernstein, "OSPF Enhancement for Signal and 965 Network Element Compatibility for Wavelength Switched 966 Optical Networks", RFC 7688, November 2015. 968 [RFC7581] Bernstein and Lee, "Routing and Wavelength Assignment 969 Information Encoding for Wavelength Switched Optical 970 Networks", RFC7581, June 2015. 972 [RFC7579] Bernstein and Lee, "General Network Element Constraint 973 Encoding for GMPLS Controlled Networks", RFC 7579, June 974 2015. 976 11. Contributors 977 Authors' Addresses 979 Young Lee, Editor 980 Huawei Technologies 981 1700 Alma Drive, Suite 100 982 Plano, TX 75075, USA 983 Phone: (972) 509-5599 (x2240) 984 Email: leeyoung@huawei.com 986 Ramon Casellas, Editor 987 CTTC PMT Ed B4 Av. Carl Friedrich Gauss 7 988 08860 Castelldefels (Barcelona) 989 Spain 990 Phone: (34) 936452916 991 Email: ramon.casellas@cttc.es 993 Fatai Zhang 994 Huawei Technologies 995 Email: zhangfatai@huawei.com 997 Cyril Margaria 998 Nokia Siemens Networks 999 St Martin Strasse 76 1000 Munich, 81541 1001 Germany 1002 Phone: +49 89 5159 16934 1003 Email: cyril.margaria@nsn.com 1005 Oscar Gonzalez de Dios 1006 Telefonica Investigacion y Desarrollo 1007 C/ Emilio Vargas 6 1008 Madrid, 28043 1009 Spain 1010 Phone: +34 91 3374013 1011 Email: ogondio@tid.es 1013 Greg Bernstein 1014 Grotto Networking 1015 Fremont, CA, USA 1016 Phone: (510) 573-2237 1017 Email: gregb@grotto-networking.com