idnits 2.17.1 draft-ietf-pce-wson-rwa-ext-04.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 11, 2016) is 2990 days in the past. Is this intentional? Checking references for intended status: Full Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'X X' is mentioned on line 201, but not defined == Missing Reference: 'RFC2863' is mentioned on line 398, but not defined == Missing Reference: 'RFC5420' is mentioned on line 642, but not defined == Missing Reference: 'RSVP-RO' is mentioned on line 643, but not defined == Missing Reference: 'PCEP' is mentioned on line 744, but not defined == Missing Reference: 'PCEP-MIB' is mentioned on line 713, but not defined == Missing Reference: 'RFC5089' is mentioned on line 732, but not defined == Missing Reference: 'RFC5088' is mentioned on line 732, but not defined == Unused Reference: 'RFC3471' is defined on line 880, but no explicit reference was found in the text == Unused Reference: 'RFC3473' is defined on line 884, but no explicit reference was found in the text == Unused Reference: 'RFC3477' is defined on line 889, but no explicit reference was found in the text == Unused Reference: 'RFC7570' is defined on line 912, but no explicit reference was found in the text == Unused Reference: 'PCEP-Layer' is defined on line 915, but no explicit reference was found in the text == Unused Reference: 'RFC6163' is defined on line 920, but no explicit reference was found in the text == Unused Reference: 'OSPF-Imp' is defined on line 959, but no explicit reference was found in the text ** Downref: Normative reference to an Proposed Standard draft: draft-ietf-pce-gmpls-pcep-extensions (ref. 'PCEP-GMPLS') ** Downref: Normative reference to an Proposed Standard RFC: RFC 7570 ** Downref: Normative reference to an Proposed Standard draft: draft-ietf-pce-inter-layer-ext (ref. 'PCEP-Layer') ** Downref: Normative reference to an Informational RFC: RFC 6163 ** Downref: Normative reference to an Informational RFC: RFC 7449 ** Downref: Normative reference to an Proposed Standard RFC: RFC 6205 ** Downref: Normative reference to an Proposed Standard RFC: RFC 7689 ** Downref: Normative reference to an Proposed Standard RFC: RFC 7688 ** Downref: Normative reference to an Informational RFC: RFC 7446 ** Downref: Normative reference to an Proposed Standard RFC: RFC 7581 ** Downref: Normative reference to an Proposed Standard RFC: RFC 7579 ** Downref: Normative reference to an Informational RFC: RFC 6566 -- Possible downref: Normative reference to a draft: ref. 'RSVP-Imp' ** Downref: Normative reference to an Experimental draft: draft-eb-ccamp-ospf-wson-impairments (ref. 'OSPF-Imp') Summary: 14 errors (**), 0 flaws (~~), 16 warnings (==), 2 comments (--). 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 R. Casellas, Ed. 5 Expires: January 2016 CTTC 7 February 11, 2016 9 PCEP Extension for WSON Routing and Wavelength Assignment 11 draft-ietf-pce-wson-rwa-ext-04.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 August 11, 2016. 46 Copyright Notice 48 Copyright (c) 2015 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..........................20 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 [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 In this document, it is assumed that wavelength converters require 142 electrical signal regeneration. Consequently, WSONs can be 143 transparent (A transparent optical network is made up of optical 144 devices that can switch but not convert from one wavelength to 145 another, all within the optical domain) or translucent (3R 146 regenerators are sparsely placed in the network). 148 A LSC Label Switched Path (LSP) may span one or several transparent 149 segments, which are delimited by 3R regenerators (typically with 150 electronic regenerator and optional wavelength conversion). Each 151 transparent segment or path in WSON is referred to as an optical 152 path. An optical path may span multiple fiber links and the path 153 should be assigned the same wavelength for each link. In such case, 154 the optical path is said to satisfy the wavelength-continuity 155 constraint. Figure 1 illustrates the relationship between a LSC LSP 156 and transparent segments (optical paths). 158 +---+ +-----+ +-----+ +-----+ +-----+ 159 | |I1 | | | | | | I2| | 160 | |o------| |-------[(3R) ]------| |--------o| | 161 | | | | | | | | | | 162 +---+ +-----+ +-----+ +-----+ +-----+ 163 [X LSC] [LSC LSC] [LSC LSC] [LSC X] SwCap 164 <-------> <-------> <-----> <-------> 165 <-----------------------><----------------------> 166 Transparent Segment Transparent Segment 167 <-------------------------------------------------> 168 LSC LSP 170 Figure 1 Illustration of a LSC LSP and transparent segments 171 Note that two optical paths within a WSON LSP need not operate on 172 the same wavelength (due to the wavelength conversion capabilities). 173 Two optical paths that share a common fiber link cannot be assigned 174 the same wavelength. To do otherwise would result in both signals 175 interfering with each other. Note that advanced additional 176 multiplexing techniques such as polarization based multiplexing are 177 not addressed in this document since the physical layer aspects are 178 not currently standardized. Therefore, assigning the proper 179 wavelength on a lightpath is an essential requirement in the optical 180 path computation process. 182 When a switching node has the ability to perform wavelength 183 conversion, the wavelength-continuity constraint can be relaxed, and 184 a LSC Label Switched Path (LSP) may use different wavelengths on 185 different links along its route from origin to destination. It is, 186 however, to be noted that wavelength converters may be limited due 187 to their relatively high cost, while the number of WDM channels that 188 can be supported in a fiber is also limited. As a WSON can be 189 composed of network nodes that cannot perform wavelength conversion, 190 nodes with limited wavelength conversion, and nodes with full 191 wavelength conversion abilities, wavelength assignment is an 192 additional routing constraint to be considered in all lightpath 193 computation. 195 For example (see Figure 1), within a translucent WSON, a LSC LSP may 196 be established between interfaces I1 and I2, spanning 2 transparent 197 segments (optical paths) where the wavelength continuity constraint 198 applies (i.e. the same unique wavelength MUST be assigned to the LSP 199 at each TE link of the segment). If the LSC LSP induced a Forwarding 200 Adjacency / TE link, the switching capabilities of the TE link would 201 be [X X] where X < LSC (PSC, TDM, ...). 203 This document aligns with GMPLS extensions for PCEP [PCEP-GMPLS] for 204 generic property such as label, label-set and label assignment 205 noting that wavelength is a type of label. Wavelength restrictions 206 and constraints are also formulated in terms of labels per 207 [RFC7579]. 209 The optical modulation properties, which are also referred to as 210 signal compatibility, are already considered in signaling in 211 [RFC7581] and [RFC7688]. In order to improve the signal quality and 212 limit some optical effects several advanced modulation processing 213 are used. Those modulation properties contribute not only to optical 214 signal quality checks but also constrain the selection of sender and 215 receiver, as they should have matching signal processing 216 capabilities. This document includes signal compatibility 217 constraints as part of RWA path computation. That is, the signal 218 processing capabilities (e.g., modulation and FEC) by the means of 219 optical interface class (OIC) must be compatible between the sender 220 and the receiver of the optical path across all optical elements. 222 This document, however, does not address optical impairments as part 223 of RWA path computation. See [RFC6566] and [RSVP-Imp] for more 224 information on optical impairments and GMPLS. 226 4. Encoding of a RWA Path Request 228 Figure 2 shows one typical PCE based implementation, which is 229 referred to as the Combined Process (R&WA). With this architecture, 230 the two processes of routing and wavelength assignment are accessed 231 via a single PCE. This architecture is the base architecture from 232 which the requirements have been specified in [RFC7449] and the PCEP 233 extensions that are going to be specified in this document based on 234 this architecture. 236 +----------------------------+ 237 +-----+ | +-------+ +--+ | 238 | | | |Routing| |WA| | 239 | PCC |<----->| +-------+ +--+ | 240 | | | | 241 +-----+ | PCE | 242 +----------------------------+ 244 Figure 2 Combined Process (R&WA) architecture 246 4.1. Wavelength Assignment (WA) Object 248 Wavelength allocation can be performed by the PCE by different 249 means: 251 (a) By means of Explicit Label Control (ELC) where the PCE allocates 252 which label to use for each interface/node along the path. 254 (b) By means of a Label Set where the PCE provides a range of 255 potential labels to allocate by each node along the path. 257 Option (b) allows distributed label allocation (performed during 258 signaling) to complete wavelength assignment. 260 Additionally, given a range of potential labels to allocate, the 261 request SHOULD convey the heuristic / mechanism to the allocation. 263 The format of a PCReq message after incorporating the WA object is 264 as follows: 266 ::= 268 [] 270 272 Where: 274 ::=[] 276 ::= 278 280 282 [other optional objects...] 284 If the WA object is present in the request, it MUST be encoded after 285 the ENDPOINTS object. 287 The format of the Wavelength Assignment (WA) object body is as 288 follows: 290 0 1 2 3 291 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 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | Flags |M| 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Wavelength Selection TLV | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | Wavelength Restriction Constraint TLV | 298 . . 299 . . 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 // Optional TLVs // 302 | | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 Figure 3 WA Object 307 o Flags (32 bits) 308 The following new flags SHOULD be set 310 . M (Mode - 1 bit): M bit is used to indicate the mode of 311 wavelength assignment. When M bit is set to 1, this indicates 312 that the label assigned by the PCE must be explicit. That is, 313 the selected way to convey the allocated wavelength is by means 314 of Explicit Label Control (ELC) [RFC4003] for each hop of a 315 computed LSP. Otherwise, the label assigned by the PCE needs 316 not be explicit (i.e., it can be suggested in the form of label 317 set objects in the corresponding response, to allow distributed 318 WA. In such case, the PCE MUST return a Label Set Field as 319 described in Section 2.6 of [RFC7579] in the response. See 320 Section 5 of this document for the encoding discussion of a 321 Label Set Field in a PCRep message. 323 4.2. Wavelength Selection TLV 325 The Wavelength Selection TLV is used to indicate the wavelength 326 selection constraint in regard to the order of wavelength assignment 327 to be returned by the PCE. This TLV is only applied when M bit is 328 set to ''explicit'' in the WA Object specified in Section 4.1. 330 The encoding of this TLV is specified as the Wavelength Selection 331 Sub-TLV in Section 4.2.2 of [RFC7689]. 333 4.3. Wavelength Restriction Constraint TLV 335 For any request that contains a wavelength assignment, the requester 336 (PCC) MUST be able to specify a restriction on the wavelengths to be 337 used. This restriction is to be interpreted by the PCE as a 338 constraint on the tuning ability of the origination laser 339 transmitter or on any other maintenance related constraints. Note 340 that if the LSP LSC spans different segments, the PCE MUST have 341 mechanisms to know the tunability restrictions of the involved 342 wavelength converters / regenerators, e.g. by means of the TED 343 either via IGP or NMS. Even if the PCE knows the tunability of the 344 transmitter, the PCC MUST be able to apply additional constraints to 345 the request. 347 The format of the Wavelength Restriction Constraint TLV is as 348 follows: 350 ::= 352 353 ( )... 355 Where 357 ::= [] 359 See Section 4.2.1. for the encoding of the Link Identifiers Field. 361 The Wavelength Restriction Constraint TLV type is TBD, recommended 362 value is TBD. This TLV MAY appear more than once to be able to 363 specify multiple restrictions. 365 The TLV data is defined as follows: 367 0 1 2 3 368 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 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | Action | Count | Reserved | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | Link Identifiers | 373 | . . . | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | Wavelength Restriction Field | 376 // . . . . // 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 Figure 4 Wavelength Restriction Constraint TLV Encoding 381 o Action: 8 bits 383 . 0 - Inclusive List indicates that one or more link identifiers 384 are included in the Link Set. Each identifies a separate link 385 that is part of the set. 387 . 1 - Inclusive Range indicates that the Link Set defines a 388 range of links. It contains two link identifiers. The first 389 identifier indicates the start of the range (inclusive). The 390 second identifier indicates the end of the range (inclusive). 391 All links with numeric values between the bounds are 392 considered to be part of the set. A value of zero in either 393 position indicates that there is no bound on the corresponding 394 portion of the range. Note that the Action field can be set to 395 0 when unnumbered link identifier is used. 397 Note that "interfaces" such as those discussed in the Interfaces MIB 398 [RFC2863] are assumed to be bidirectional. 400 o Count: The number of the link identifiers (8 bits) 402 Note that a PCC MAY add a Wavelength restriction that applies to all 403 links by setting the Count field to zero and specifying just a set 404 of wavelengths. 406 Note that all link identifiers in the same list must be of the same 407 type. 409 o Reserved: Reserved for future use (16 bits) 411 o Link Identifiers: Identifies each link ID for which restriction 412 is applied. The length is dependent on the link format and the Count 413 field. See Section 4.2.1. for Link Identifier encoding and Section 414 4.2.2. for the Wavelength Restriction Field encoding, respectively. 416 4.3.1. Link Identifier Field 418 The link identifier field can be an IPv4, IPv6 or unnumbered 419 interface ID. 421 ::= 423 | | 425 The encoding of each case is as follows: 427 IPv4 prefix Entry 429 0 1 2 3 430 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 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 | Type = 1 | IPv4 address (4 bytes) | 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 | IPv4 address (continued) | Prefix Length | 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 IPv6 prefix Sub-TLV 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 = 2 | IPv6 address (16 bytes) | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 | IPv6 address (continued) | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 | IPv6 address (continued) | 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | IPv6 address (continued) | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | IPv6 address (continued) | Prefix Length | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 Unnumbered Interface ID Sub-TLV 455 0 1 2 3 456 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 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | Type = 3 | Reserved | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 | TE Node ID | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | Interface ID | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 4.3.2. Wavelength Restriction Field 466 The Wavelength Restriction Field of the wavelength restriction TLV 467 is encoded as a Label Set field as specified in [RFC7579] section 468 2.6, as shown below, with base label encoded as a 32 bit LSC label, 469 defined in [RFC6205]. See [RFC6205] for a description of Grid, C.S, 470 Identifier and n, as well as [RFC7579] for the details of each 471 action. 473 0 1 2 3 475 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 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 | Action| Num Labels | Length | 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 |Grid | C.S | Identifier | n | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 | Additional fields as necessary per action | 483 | | 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 Action: 488 0 - Inclusive List 490 1 - Exclusive List 492 2 - Inclusive Range 494 3 - Exclusive Range 496 4 - Bitmap Set 498 Num Labels is generally the number of labels. It has a specific 499 meaning depending on the action value. Num Labels is a 12 bit 500 integer. 502 Length is the length in bytes of the entire label set field. 504 See Sections 2.6.1 - 2.6.3 of [RFC7579] for details on additional 505 field discussion for each action. 507 4.4. Signal processing capability restrictions 509 Path computation for WSON include the check of signal processing 510 capabilities, those capability MAY be provided by the IGP, however 511 this is not a MUST. Moreover, a PCC should be able to indicate 512 additional restrictions for those signal compatibility, either on 513 the endpoint or any given link. 515 The supported signal processing capabilities are the one described 516 in [RFC7446]: 518 . Optical Interface Class List 520 . Bit Rate 522 . Client Signal 524 The Bit Rate restriction is already expressed in [PCEP-GMPLS] in the 525 BANDWIDTH object. 527 In order to support the Optical Interface Class information and the 528 Client Signal information new TLVs are introduced as endpoint- 529 restriction in the END-POINTS type Generalized endpoint: 531 . Client Signal TLV 533 . Optical Interface Class List TLV 535 The END-POINTS type generalized endpoint is extended as follows: 537 ::= 539 541 [...] 543 Where 545 signal-compatibility-restriction ::= 547 549 The encoding for the Optical Interface Class List is described in 550 Section 4.1 of [RFC7581]. 552 The encoding for the Client Signal Information is described in 553 Section 4.2 of [RFC7581]. 555 4.4.1. Signal Processing Exclusion XRO Sub-Object 557 The PCC/PCE should be able to exclude particular types of signal 558 processing along the path in order to handle client restriction or 559 multi-domain path computation. 561 In order to support the exclusion a new XRO sub-object is defined: 562 the signal processing exclusion: 564 0 1 2 3 566 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 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 |X| Type = X | Length | Reserved | Attribute | 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 | sub-sub objects | 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 Figure 5 Signaling Processing XRO Sub-Object 575 The Attribute field indicates how the exclusion sub-object is to be 576 interpreted. The Attribute can only be 0 (Interface) or 1 (Node). 578 The sub-sub objects are encoded as in RSVP signaling definition 579 [RFC7689]. 581 4.4.2. IRO sub-object: signal processing inclusion 583 Similar to the XRO sub-object the PCC/PCE should be able to include 584 particular types of signal processing along the path in order to 585 handle client restriction or multi-domain path computation. 587 This is supported by adding the sub-object ''processing'' defined for 588 ERO in [RFC7689] to the PCEP IRO object. 590 5. Encoding of a RWA Path Reply 592 This section provides the encoding of a RWA Path Reply for 593 wavelength allocation as discussed in Section 4. Recall that 594 wavelength allocation can be performed by the PCE by different 595 means: 597 (a) By means of Explicit Label Control (ELC) where the PCE 598 allocates which label to use for each interface/node along the 599 path. 600 (b) By means of a Label Set where the PCE provides a range of 601 potential labels to allocate by each node along the path. 603 Option (b) allows distributed label allocation (performed during 604 signaling) to complete wavelength allocation. 606 The Wavelength Allocation TLV type is TBD, recommended value is TBD. 607 The TLV data is defined as follows: 609 0 1 2 3 610 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 | Reserved |M| 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 | Link Identifier | 615 | | 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 | Allocated Wavelength(s) | 618 // . . . . // 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 Figure 6 Wavelength Allocation TLV Encoding 623 o Reserved: Reserved for future use (31 bits) 625 o M (Mode): 1 bit 627 . 0 - indicates the allocation is under Explicit Label Control. 629 . 1 - indicates the allocation is expressed in Label Sets. 631 Note that all link identifiers in the same list must be of the same 632 type. 634 o Link Identifier (variable): Identifies the interface to which 635 assignment wavelength(s) is applied. See Section 4.2.1. for Link 636 Identifier encoding. 638 o Assigned Wavelength(s) (variable): Indicates the assigned 639 wavelength(s) to the link identifier. See Section 4.2.2 for encoding 640 details. 642 This TLV is encoded as an attributes TLV, per [RFC5420], which is 643 carried in the ERO LSP Attribute Subobjects per [RSVP-RO]. The type 644 value of the Wavelength Restriction Constraint TLV is TBD by IANA. 646 5.1. Error Indicator 648 To indicate errors associated with the RWA request, a new Error Type 649 (TDB) and subsequent error-values are defined as follows for 650 inclusion in the PCEP-ERROR Object: 652 A new Error-Type (TDB) and subsequent error-values are defined as 653 follows: 655 . Error-Type=TBD; Error-value=1: if a PCE receives a RWA request 656 and the PCE is not capable of processing the request due to 657 insufficient memory, the PCE MUST send a PCErr message with a 658 PCEP-ERROR Object (Error-Type=TDB) and an Error-value(Error- 659 value=1). The PCE stops processing the request. The 660 corresponding RWA request MUST be cancelled at the PCC. 662 . Error-Type=TBD; Error-value=2: if a PCE receives a RWA request 663 and the PCE is not capable of RWA computation, the PCE MUST 664 send a PCErr message with a PCEP-ERROR Object (Error-Type=TDB) 665 and an Error-value (Error-value=2). The PCE stops processing 666 the request. The corresponding RWA computation MUST be 667 cancelled at the PCC. 669 5.2. NO-PATH Indicator 671 To communicate the reason(s) for not being able to find RWA for the 672 path request, the NO-PATH object can be used in the corresponding 673 response. The format of the NO-PATH object body is defined in 674 [RFC5440]. The object may contain a NO-PATH-VECTOR TLV to provide 675 additional information about why a path computation has failed. 677 One new bit flag are defined to be carried in the Flags field in the 678 NO-PATH-VECTOR TLV carried in the NO-PATH Object. 680 . Bit TDB: When set, the PCE indicates no feasible route was 681 found that meets all the constraints (e.g., wavelength 682 restriction, signal compatibility, etc.) associated with RWA. 684 6. Manageability Considerations 686 Manageability of WSON Routing and Wavelength Assignment (RWA) with 687 PCE must address the following considerations: 689 6.1. Control of Function and Policy 691 In addition to the parameters already listed in Section 8.1 of 692 [PCEP], a PCEP implementation SHOULD allow configuring the following 693 PCEP session parameters on a PCC: 695 . The ability to send a WSON RWA request. 697 In addition to the parameters already listed in Section 8.1 of 698 [PCEP], a PCEP implementation SHOULD allow configuring the following 699 PCEP session parameters on a PCE: 701 . The support for WSON RWA. 703 . A set of WSON RWA specific policies (authorized sender, 704 request rate limiter, etc). 706 These parameters may be configured as default parameters for any 707 PCEP session the PCEP speaker participates in, or may apply to a 708 specific session with a given PCEP peer or a specific group of 709 sessions with a specific group of PCEP peers. 711 6.2. Information and Data Models, e.g. MIB module 713 Extensions to the PCEP MIB module defined in [PCEP-MIB] should be 714 defined, so as to cover the WSON RWA information introduced in this 715 document. A future revision of this document will list the 716 information that should be added to the MIB module. 718 6.3. Liveness Detection and Monitoring 720 Mechanisms defined in this document do not imply any new liveness 721 detection and monitoring requirements in addition to those already 722 listed in section 8.3 of [RFC5440]. 724 6.4. Verifying Correct Operation 726 Mechanisms defined in this document do not imply any new 727 verification requirements in addition to those already listed in 728 section 8.4 of [RFC5440] 730 6.5. Requirements on Other Protocols and Functional Components 732 The PCE Discovery mechanisms ([RFC5089] and [RFC5088]) may be used 733 to advertise WSON RWA path computation capabilities to PCCs. 735 6.6. Impact on Network Operation 737 Mechanisms defined in this document do not imply any new network 738 operation requirements in addition to those already listed in 739 section 8.6 of [RFC5440]. 741 7. Security Considerations 743 This document has no requirement for a change to the security models 744 within PCEP [PCEP]. However the additional information distributed 745 in order to address the RWA problem represents a disclosure of 746 network capabilities that an operator may wish to keep private. 747 Consideration should be given to securing this information. 749 8. IANA Considerations 751 IANA maintains a registry of PCEP parameters. IANA has made 752 allocations from the sub-registries as described in the following 753 sections. 755 8.1. New PCEP Object 757 As described in Section 4.1, a new PCEP Object is defined to carry 758 wavelength assignment related constraints. IANA is to allocate the 759 following from ''PCEP Objects'' sub-registry 760 (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-objects): 762 Object Class Name Object Reference 763 Value Type 764 --------------------------------------------------------- 766 TDB WA 1: Wavelength-Assignment [This.I-D] 768 8.2. New PCEP TLV: Wavelength Selection TLV 770 As described in Sections 4.2, a new PCEP TLV is defined to indicate 771 wavelength selection constraints. IANA is to allocate this new TLV 772 from the "PCEP TLV Type Indicators" subregistry 773 (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type- 774 indicators). 776 Value Description Reference 777 --------------------------------------------------------- 778 TBD Wavelength Selection [This.I-D] 780 8.3. New PCEP TLV: Wavelength Restriction Constraint TLV 782 As described in Sections 4.3, a new PCEP TLV is defined to indicate 783 wavelength restriction constraints. IANA is to allocate this new TLV 784 from the "PCEP TLV Type Indicators" subregistry 785 (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type- 786 indicators). 788 Value Description Reference 789 --------------------------------------------------------- 790 TBD Wavelength Restriction [This.I-D] 791 Constraint 793 8.4. New PCEP TLV: Wavelength Allocation TLV 795 As described in Section 5, a new PCEP TLV is defined to indicate the 796 allocation of wavelength(s) by the PCE in response to a request by 797 the PCC. IANA is to allocate this new TLV from the "PCEP TLV Type 798 Indicators" subregistry 799 (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type- 800 indicators). 802 Value Description Reference 803 --------------------------------------------------------- 804 TBD Wavelength Allocation [This.I-D] 806 8.5. New PCEP TLV: Optical Interface Class List TLV 808 As described in Section 4.3, a new PCEP TLV is defined to indicate 809 the optical interface class list. IANA is to allocate this new TLV 810 from the "PCEP TLV Type Indicators" subregistry 811 (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type- 812 indicators). 814 Value Description Reference 815 --------------------------------------------------------- 816 TBD Optical Interface [This.I-D] 817 Class List 819 8.6. New PCEP TLV: Client Signal TLV 821 As described in Section 4.3, a new PCEP TLV is defined to indicate 822 the client signal information. IANA is to allocate this new TLV from 823 the "PCEP TLV Type Indicators" subregistry 824 (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type- 825 indicators). 827 Value Description Reference 828 --------------------------------------------------------- 829 TBD Client Signal Information [This.I-D] 831 8.7. New No-Path Reasons 833 As described in Section 5.2., a new bit flag are defined to be 834 carried in the Flags field in the NO-PATH-VECTOR TLV carried in the 835 NO-PATH Object. This flag, when set, indicates that no feasible 836 route was found that meets all the RWA constraints (e.g., wavelength 837 restriction, signal compatibility, etc.) associated with a RWA path 838 computation request. 840 IANA is to allocate this new bit flag from the "PCEP NO-PATH-VECTOR 841 TLV Flag Field" subregistry 842 (http://www.iana.org/assignments/pcep/pcep.xhtml#no-path-vector- 843 tlv). 845 Bit Description Reference 846 ----------------------------------------------------- 847 TBD No RWA constraints met [This.I-D] 849 8.8. New Error-Types and Error-Values 851 As described in Section 5.1, new PCEP error codes are defined for 852 WSON RWA errors. IANA is to allocate from the ''"PCEP-ERROR Object Error 853 Types and Values" sub-registry 854 (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-error-object). 856 Error- Meaning Error-Value Reference 857 Type 858 --------------------------------------------------------------- 860 TDB WSON RWA Error 1: Insufficient [This.I-D] 861 Memory 863 2: RWA computation {This.I-D] 864 Not supported 866 9. Acknowledgments 868 The authors would like to thank Adrian Farrel for many helpful 869 comments that greatly improved the contents of this draft. 871 This document was prepared using 2-Word-v2.0.template.dot. 873 10. References 875 10.1. Informative References 877 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 878 Requirement Levels", BCP 14, RFC 2119, March 1997. 880 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 881 (GMPLS) Signaling Functional Description", RFC 3471, 882 January 2003. 884 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 885 Switching (GMPLS) Signaling Resource ReserVation Protocol- 886 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 887 January 2003. 889 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 890 in Resource ReSerVation Protocol - Traffic Engineering 891 (RSVP-TE)", RFC 3477, January 2003. 893 [RFC4003] Berger, L., "GMPLS Signaling Procedure for Egress Control", 894 RFC 4003, February 2005. 896 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 897 Element (PCE)-Based Architecture", RFC 4655, August 2006. 899 [RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE) 900 Communication Protocol Generic Requirements", RFC 4657, 901 September 2006. 903 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 904 Element (PCE) communication Protocol", RFC 5440, March 905 2009. 907 10.2. Normative References 909 [PCEP-GMPLS] Margaria, et al., ''PCEP extensions for GMPLS'', draft- 910 ietf-pce-gmpls-pcep-extensions, work in progress. 912 [RFC7570] Margaria, et al., ''Label Switched Path (LSP) Attribute in 913 the Explicit Route Object (ERO)'', RFC 7570, July 2015. 915 [PCEP-Layer] Oki, Takeda, Le Roux, and Farrel, ''Extensions to the 916 Path Computation Element communication Protocol (PCEP) for 917 Inter-Layer MPLS and GMPLS Traffic Engineering'', draft- 918 ietf-pce-inter-layer-ext, work in progress. 920 [RFC6163] Lee, Y. and Bernstein, G. (Editors), and W. Imajuku, 921 "Framework for GMPLS and PCE Control of Wavelength 922 Switched Optical Networks", RFC 6163, March 2011. 924 [RFC7449] Lee, Y., et. al., "PCEP Requirements for WSON Routing and 925 Wavelength Assignment", RFC 7449, February 2015. 927 [RFC6205] Tomohiro, O. and D. Li, "Generalized Labels for Lambda- 928 Switching Capable Label Switching Routers", RFC 6205, 929 January, 2011. 931 [RFC7689] Bernstein et al,''Signaling Extensions for Wavelength 932 Switched Optical Networks'', RFC 7689, November 2015. 934 [RFC7688] Y. Lee, and G. Bernstein,''OSPF Enhancement for Signal and 935 Network Element Compatibility for Wavelength Switched 936 Optical Networks'', RFC 7688, November, 2015. 938 [RFC7446] Y. Lee, G. Bernstein. (Editors), ''Routing and Wavelength 939 Assignment Information Model for Wavelength Switched 940 Optical Networks'', RFC 7446, February 2015. 942 [RFC7581] Bernstein and Lee, ''Routing and Wavelength Assignment 943 Information Encoding for Wavelength Switched Optical 944 Networks'', RFC7581, June 2015. 946 [RFC7579] Bernstein and Lee, ''General Network Element Constraint 947 Encoding for GMPLS Controlled Networks'', RFC 7579, June 948 2015. 950 [RFC6566] Y. Lee, G. Bernstein, D. Li, G. Martinelli, "A Framework 951 for the Control of Wavelength Switched Optical Networks 952 (WSON) with Impairments", RFC 6566, March 2012. 954 [RSVP-Imp] agraz, ''RSVP-TE Extensions in Support of Impairment Aware 955 Routing and Wavelength Assignment in Wavelength Switched 956 Optical Networks WSONs)'', draft-agraz-ccamp-wson- 957 impairment-rsvp, work in progress. 959 [OSPF-Imp] Bellagamba, et al., ''OSPF Extensions for Wavelength 960 Switched Optical Networks (WSON) with Impairments'',draft- 961 eb-ccamp-ospf-wson-impairments, work in progress. 963 11. Contributors 964 Authors' Addresses 966 Young Lee, Editor 967 Huawei Technologies 968 1700 Alma Drive, Suite 100 969 Plano, TX 75075, USA 970 Phone: (972) 509-5599 (x2240) 971 Email: leeyoung@huawei.com 973 Ramon Casellas, Editor 974 CTTC PMT Ed B4 Av. Carl Friedrich Gauss 7 975 08860 Castelldefels (Barcelona) 976 Spain 977 Phone: (34) 936452916 978 Email: ramon.casellas@cttc.es 980 Fatai Zhang 981 Huawei Technologies 982 Email: zhangfatai@huawei.com 984 Cyril Margaria 985 Nokia Siemens Networks 986 St Martin Strasse 76 987 Munich, 81541 988 Germany 989 Phone: +49 89 5159 16934 990 Email: cyril.margaria@nsn.com 992 Oscar Gonzalez de Dios 993 Telefonica Investigacion y Desarrollo 994 C/ Emilio Vargas 6 995 Madrid, 28043 996 Spain 997 Phone: +34 91 3374013 998 Email: ogondio@tid.es 1000 Greg Bernstein 1001 Grotto Networking 1002 Fremont, CA, USA 1003 Phone: (510) 573-2237 1004 Email: gregb@grotto-networking.com