idnits 2.17.1 draft-ietf-pce-wson-rwa-ext-16.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 (March 1, 2019) is 1876 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: September 1, 2019 CTTC 7 March 1, 2019 9 PCEP Extension for WSON Routing and Wavelength Assignment 11 draft-ietf-pce-wson-rwa-ext-16 13 Abstract 15 This document provides the Path Computation Element communication 16 Protocol (PCEP) extensions for the support of Routing and Wavelength 17 Assignment (RWA) in Wavelength Switched Optical Networks (WSON). 18 Path provisioning in WSONs requires a routing and wavelength 19 assignment (RWA) process. From a path computation perspective, 20 wavelength assignment is the process of determining which wavelength 21 can be used on each hop of a path and forms an additional routing 22 constraint to optical path computation. 24 Status of this Memo 26 This Internet-Draft is submitted to IETF in full conformance with 27 the provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six 35 months and may be updated, replaced, or obsoleted by other documents 36 at any time. It is inappropriate to use Internet-Drafts as 37 reference material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This Internet-Draft will expire on September 1, 2019. 46 Copyright Notice 48 Copyright (c) 2019 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with 56 respect to this document. Code Components extracted from this 57 document must include Simplified BSD License text as described in 58 Section 4.e of the Trust Legal Provisions and are provided without 59 warranty as described in the Simplified BSD License. 61 Table of Contents 63 1. Terminology....................................................3 64 2. Requirements Language..........................................3 65 3. Introduction...................................................3 66 4. Encoding of a RWA Path Request.................................6 67 4.1. Wavelength Assignment (WA) Object.........................7 68 4.2. Wavelength Selection TLV..................................9 69 4.3. Wavelength Restriction Constraint TLV.....................9 70 4.3.1. Link Identifier Field...............................12 71 4.3.2. Wavelength Restriction Field........................14 72 4.4. Signal Processing Capability Restrictions................15 73 4.4.1. Signal Processing Exclusion.........................17 74 4.4.2. Signal Processing Inclusion.........................18 75 5. Encoding of a RWA Path Reply..................................19 76 5.1. Wavelength Allocation TLV................................19 77 5.2. Error Indicator..........................................21 78 5.3. NO-PATH Indicator........................................21 79 6. Manageability Considerations..................................22 80 6.1. Control of Function and Policy...........................22 81 6.2. Liveness Detection and Monitoring........................22 82 6.3. Verifying Correct Operation..............................22 83 6.4. Requirements on Other Protocols and Functional Components23 84 6.5. Impact on Network Operation..............................23 86 7. Security Considerations.......................................23 87 8. IANA Considerations...........................................23 88 8.1. New PCEP Object: Wavelength Assignment Object............23 89 8.2. WA Object Flag Field.....................................24 90 8.3. New PCEP TLV: Wavelength Selection TLV...................24 91 8.4. New PCEP TLV: Wavelength Restriction Constraint TLV......24 92 8.5. Wavelength Restriction Constraint TLV Action Values......25 93 8.6. New PCEP TLV: Wavelength Allocation TLV..................25 94 8.7. Wavelength Allocation TLV Flag Field.....................26 95 8.8. New PCEP TLV: Optical Interface Class List TLV...........26 96 8.9. New PCEP TLV: Client Signal TLV..........................27 97 8.10. New No-Path Reasons.....................................27 98 8.11. New Error-Types and Error-Values........................27 99 8.12. New Subobjects for the Exclude Route Object.............28 100 8.13. New Subobjects for the Include Route Object.............28 101 8.14. Request for Updated Note for LMP TE Link Object Class Type 102 ..............................................................29 103 9. Acknowledgments...............................................29 104 10. References...................................................29 105 10.1. Normative References....................................29 106 10.2. Informative References..................................30 107 11. Contributors.................................................32 108 Authors' Addresses...............................................33 110 1. Terminology 112 This document uses the terminology defined in [RFC4655], and 113 [RFC5440]. 115 2. Requirements Language 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 119 "OPTIONAL" in this document are to be interpreted as described in 120 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 121 capitals, as shown here. 123 3. Introduction 125 [RFC5440] specifies the Path Computation Element (PCE) Communication 126 Protocol (PCEP) for communications between a Path Computation Client 127 (PCC) and a PCE, or between two PCEs. Such interactions include 128 path computation requests and path computation replies as well as 129 notifications of specific states related to the use of a PCE in the 130 context of Multiprotocol Label Switching (MPLS) and Generalized MPLS 131 (GMPLS) Traffic Engineering. 133 A PCC is said to be any network component that makes such a request 134 and may be, for instance, an Optical Switching Element within a 135 Wavelength Division Multiplexing (WDM) network. The PCE, itself, 136 can be located anywhere within the network, and may be within an 137 optical switching element, a Network Management System (NMS) or 138 Operational Support System (OSS), or may be an independent network 139 server. 141 This document provides the PCEP extensions for the support of 142 Routing and Wavelength Assignment (RWA) in Wavelength Switched 143 Optical Networks (WSON) based on the requirements specified in 144 [RFC6163] and [RFC7449]. 146 WSON refers to WDM based optical networks in which switching is 147 performed selectively based on the wavelength of an optical signal. 148 The devices used in WSONs that are able to switch signals based on 149 signal wavelength are known as Lambda Switch Capable (LSC). WSONs 150 can be transparent or translucent. A transparent optical network is 151 made up of optical devices that can switch but not convert from one 152 wavelength to another, all within the optical domain. On the other 153 hand, translucent networks include 3R regenerators (Re- 154 amplification, Re-shaping, Re-timing) that are sparsely placed. The 155 main function of the 3R regenerators is to convert one optical 156 wavelength to another. 158 A Lambda Switch Capable (LSC) Label Switched Path (LSP) may span one 159 or several transparent segments, which are delimited by 3R 160 regenerators typically with electronic regenerator and optional 161 wavelength conversion. Each transparent segment or path in WSON is 162 referred to as an optical path. An optical path may span multiple 163 fiber links and the path should be assigned the same wavelength for 164 each link. In such case, the optical path is said to satisfy the 165 wavelength-continuity constraint. Figure 1 illustrates the 166 relationship between a LSC LSP and transparent segments (optical 167 paths). 169 +---+ +-----+ +-----+ +-----+ +-----+ 170 | |I1 | | | | | | I2| | 171 | |o------| |-------[(3R) ]------| |--------o| | 172 | | | | | | | | | | 173 +---+ +-----+ +-----+ +-----+ +-----+ 174 (X LSC) (LSC LSC) (LSC LSC) (LSC X) 175 <-------> <-------> <-----> <-------> 176 <-----------------------><----------------------> 177 Transparent Segment Transparent Segment 178 <-------------------------------------------------> 179 LSC LSP 181 Figure 1 Illustration of a LSC LSP and transparent segments 183 Note that two transparent segments within a WSON LSP do not need to 184 operate on the same wavelength (due to the wavelength conversion 185 capabilities). Two optical channels that share a common fiber link 186 cannot be assigned the same wavelength; Otherwise, the two signals 187 would interfere with each other. Note that advanced additional 188 multiplexing techniques such as polarization based multiplexing are 189 not addressed in this document since the physical layer aspects are 190 not currently standardized. Therefore, assigning the proper 191 wavelength on a path is an essential requirement in the optical path 192 computation process. 194 When a switching node has the ability to perform wavelength 195 conversion, the wavelength-continuity constraint can be relaxed, and 196 a LSC Label Switched Path (LSP) may use different wavelengths on 197 different links along its route from origin to destination. It is, 198 however, to be noted that wavelength converters may be limited due 199 to their relatively high cost, while the number of WDM channels that 200 can be supported in a fiber is also limited. As a WSON can be 201 composed of network nodes that cannot perform wavelength conversion, 202 nodes with limited wavelength conversion, and nodes with full 203 wavelength conversion abilities, wavelength assignment is an 204 additional routing constraint to be considered in all optical path 205 computation. 207 For example (see Figure 1), within a translucent WSON, a LSC LSP may 208 be established between interfaces I1 and I2, spanning 2 transparent 209 segments (optical paths) where the wavelength continuity constraint 210 applies (i.e. the same unique wavelength must be assigned to the LSP 211 at each TE link of the segment). If the LSC LSP induced a Forwarding 212 Adjacency / TE link, the switching capabilities of the TE link would 213 be (X X) where X refers to the switching capability of I1 and I2. 214 For example, X can be Packet Switch Capable (PSC), Time Division 215 Multiplexing (TDM), etc. 217 This document aligns with GMPLS extensions for PCEP [PCEP-GMPLS] for 218 generic properties such as label, label-set and label assignment 219 noting that wavelength is a type of label. Wavelength restrictions 220 and constraints are also formulated in terms of labels per 221 [RFC7579]. 223 The optical modulation properties, which are also referred to as 224 signal compatibility, are already considered in signaling in 225 [RFC7581] and [RFC7688]. In order to improve the signal quality and 226 limit some optical effects several advanced modulation processing 227 capabilities are used by the mechanisms specified in this document. 228 These modulation capabilities contribute not only to optical signal 229 quality checks but also constrain the selection of sender and 230 receiver, as they should have matching signal processing 231 capabilities. This document includes signal compatibility 232 constraints as part of RWA path computation. That is, the signal 233 processing capabilities (e.g., modulation and Forward Error 234 Correction (FEC)) indicated by means of optical interface class 235 (OIC) must be compatible between the sender and the receiver of the 236 optical path across all optical elements. 238 This document, however, does not address optical impairments as part 239 of RWA path computation. See [RFC6566] for the framework for optical 240 impairments. 242 4. Encoding of a RWA Path Request 244 Figure 2 shows one typical PCE based implementation, which is 245 referred to as the Combined Process (R&WA). With this architecture, 246 the two processes of routing and wavelength assignment are accessed 247 via a single PCE. This architecture is the base architecture 248 specified in [RFC6163] and the PCEP extensions that are specified in 249 this document are based on this architecture. 251 +----------------------------+ 252 +-----+ | +-------+ +--+ | 253 | | | |Routing| |WA| | 254 | PCC |<----->| +-------+ +--+ | 255 | | | | 256 +-----+ | PCE | 257 +----------------------------+ 259 Figure 2 Combined Process (R&WA) architecture 261 4.1. Wavelength Assignment (WA) Object 263 Wavelength allocation can be performed by the PCE by different 264 means: 266 (a) By means of Explicit Label Control [RFC3471] where the PCE 267 allocates which label to use for each interface/node along the path. 268 The allocated labels MAY appear after an interface route subobject. 270 (b) By means of a Label Set where the PCE provides a range of 271 potential labels to allocate by each node along the path. 273 Option (b) allows distributed label allocation (performed during 274 signaling) to complete wavelength assignment. 276 Additionally, given a range of potential labels to allocate, a PC 277 Request SHOULD convey the heuristic / mechanism used for the 278 allocation. 280 The format of a PCReq message per [RFC5440] after incorporating the 281 Wavelength Assignment (WA) object is as follows: 283 ::= 285 [] 287 289 Where: 291 ::=[] 293 ::= 294 296 298 [other optional objects...] 300 If the WA object is present in the request, it MUST be encoded after 301 the END-POINTS object as defined in [PCEP-GMPLS]. The WA Object is 302 mandatory in this document. Orderings for the other optional objects 303 are irrelevant. 305 WA Object-Class is (TBD1) (To be assigned by IANA). 307 WA Object-Type is 1. 309 The format of the WA object body is as follows: 311 0 1 2 3 312 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 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | Reserved | Flags |M| 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | | 317 // TLVs // 318 | | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 Figure 3 WA Object 323 o Reserved (16 bits): Reserved for future use and SHOULD be zeroed 324 and ignored on receipt. 326 o Flags (16 bits) 328 One flag bit is allocated as follows: 330 - M (Mode - 1 bit): M bit is used to indicate the mode of 331 wavelength assignment. When M bit is set to 1, this indicates 332 that the label assigned by the PCE must be explicit. That is, 333 the selected way to convey the allocated wavelength is by means 334 of Explicit Label Control for each hop of a computed LSP. 335 Otherwise (M bit is set to 0), the label assigned by the PCE 336 need not be explicit (i.e., it can be suggested in the form of 337 label set objects in the corresponding response, to allow 338 distributed WA. If M is 0, the PCE MUST return a Label Set 339 Field as described in Section 2.6 of [RFC7579] in the response. 340 See Section 5 of this document for the encoding discussion of a 341 Label Set Field in a PCRep message. 343 All unused flags SHOULD be zeroed. IANA is to create a new 344 registry to manage the Flag field of the WA object. 346 o TLVs (variable). In the TLVs field, the following two TLVs are 347 defined. At least one TLV MUST be present. 349 - Wavelength Selection TLV: A TLV of type (TBD2) with fixed 350 length of 32 bits indicating the wavelength selection. See 351 Section 4.2 for details. 353 - Wavelength Restriction Constraint TLV: A TLV of type (TBD3) 354 with variable length indicating wavelength restrictions. See 355 Section 4.3 for details. 357 4.2. Wavelength Selection TLV 359 The Wavelength Selection TLV is used to indicate the wavelength 360 selection constraint in regard to the order of wavelength assignment 361 to be returned by the PCE. This TLV is only applied when M bit is 362 set in the WA Object specified in Section 4.1. This TLV MUST NOT be 363 used when the M bit is cleared. 365 The encoding of this TLV is specified as the Wavelength Selection 366 Sub-TLV in Section 4.2.2 of [RFC7689]. IANA is to allocate a new TLV 367 type, Wavelength Selection TLV type (TBD2). 369 4.3. Wavelength Restriction Constraint TLV 371 For any request that contains a wavelength assignment, the requester 372 (PCC) MUST specify a restriction on the wavelengths to be used. This 373 restriction is to be interpreted by the PCE as a constraint on the 374 tuning ability of the origination laser transmitter or on any other 375 maintenance related constraints. Note that if the LSP LSC spans 376 different segments, the PCE must have mechanisms to know the 377 tunability restrictions of the involved wavelength converters / 378 regenerators, e.g. by means of the Traffic Engineering Database 379 (TED) either via IGP or Network Management System (NMS). Even if the 380 PCE knows the tunability of the transmitter, the PCC must be able to 381 apply additional constraints to the request. 383 The format of the Wavelength Restriction Constraint TLV is as 384 follows: 386 ::= 388 ( 390 )... 392 Where 394 ::= [] 396 See Section 4.3.1. for the encoding of the Link Identifiers Field. 398 These fields (i.e., , and , etc.) MAY appear together more than once to be able to 400 specify multiple actions and their restrictions. 402 IANA is to allocate a new TLV type, Wavelength Restriction 403 Constraint TLV type (TBD3). 405 The TLV data is defined as follows: 407 0 1 2 3 408 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 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | Action | Count | Reserved | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | Link Identifiers Field | 413 // . . . // 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | Wavelength Restriction Field | 416 // . . . . // 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 ~ . . . . ~ 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | Action | Count | Reserved | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | Link Identifiers Field | 423 // . . . // 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | Wavelength Restriction Field | 426 // . . . . // 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 Figure 4 Wavelength Restriction Constraint TLV Encoding 431 o Action (8 bits): 433 o 0 - Inclusive List indicates that one or more link 434 identifiers are included in the Link Set. Each identifies a 435 separate link that is part of the set. 437 o 1 - Inclusive Range indicates that the Link Set defines a 438 range of links. It contains two link identifiers. The first 439 identifier indicates the start of the range (inclusive). The 440 second identifier indicates the end of the range 441 (inclusive). All links with numeric values between the 442 bounds are considered to be part of the set. A value of zero 443 in either position indicates that there is no bound on the 444 corresponding portion of the range. 446 o 2-255 - For future use 448 IANA is to create a new registry to manage the Action values of the 449 Wavelength Restriction Constraint TLV. 451 If PCE receives an unrecognized Action value, the PCE MUST send a 452 PCErr message with a PCEP-ERROR Object (Error-Type=TBD8) and an 453 Error-value (Error-value=3). See Section 5.2 for details. 455 Note that "links" are assumed to be bidirectional. 457 o Count (8 bits): The number of the link identifiers 459 Note that a PCC MAY add a Wavelength restriction that applies to all 460 links by setting the Count field to zero and specifying just a set 461 of wavelengths. 463 Note that all link identifiers in the same list MUST be of the same 464 type. 466 o Reserved (16 bits): Reserved for future use and SHOULD be 467 zeroed and ignored on receipt. 469 o Link Identifiers: Identifies each link ID for which 470 restriction is applied. The length is dependent on the link 471 format and the Count field. See Section 4.3.1. for Link 472 Identifier encoding. 474 o Wavelength Restriction: See Section 4.3.2. for the Wavelength 475 Restriction Field encoding. 477 Various encoding errors are possible with this TLV (e.g., not 478 exactly two link identifiers with the range case, unknown identifier 479 types, no matching link for a given identifier, etc.). To indicate 480 errors associated with this encoding, a PCEP speaker MUST send a 481 PCErr message with Error-Type=TBD8 and Error-value=3. See Section 482 5.1 for the details. 484 4.3.1. Link Identifier Field 486 The link identifier field can be an IPv4 [RFC3630], IPv6 [RFC5329] 487 or unnumbered interface ID [RFC4203]. 489 ::= 491 | | 493 The encoding of each case is as follows: 495 IPv4 Address Field 497 0 1 2 3 498 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 | Type = 1 | Reserved (24 bits) | 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 | IPv4 address (4 bytes) | 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 IPv6 Address Field 507 0 1 2 3 508 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 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 | Type = 2 | Reserved (24 bits) | 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 | IPv6 address (16 bytes) | 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 | IPv6 address (continued) | 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 | IPv6 address (continued) | 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 | IPv6 address (continued) | 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 Unnumbered Interface ID Address Field 523 0 1 2 3 524 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 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 | Type = 3 | Reserved (24 bits) | 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 | TE Node ID (32 bits) | 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 | Interface ID (32 bits) | 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 o Type (8 bits): It indicates the type of the link identifier. 535 o Reserved (24 bits): Reserved for future use and SHOULD be 536 zeroed and ignored on receipt. 538 o Link Identifier: When Type field is 1, 4-bytes IPv4 address 539 is encoded; when Type field is 2, 16-bytes IPv6 address is 540 encoded; when Type field is 3, a tuple of 4-bytes TE node 541 ID and 4-bytes interface ID is encoded. 543 The Type field is extensible and matches to the IANA registry 544 created for Link Management Protocol (LMP) [RFC4204] for "TE Link 545 Object Class Type name space": https://www.iana.org/assignments/lmp- 546 parameters/lmp-parameters.xhtml#lmp-parameters-15. See Section 8.14 547 for the request to update the introductory text of the 548 aforementioned registry to note that the values have additional 549 usage for the Link Identifier Type field. 551 4.3.2. Wavelength Restriction Field 553 The Wavelength Restriction Field of the Wavelength Restriction 554 Constraint TLV is encoded as a Label Set field as specified in 555 Section 2.6 in [RFC7579] with base label encoded as a 32 bit LSC 556 label, defined in [RFC6205]. The Label Set format is repeated here 557 for convenience, with the base label internal structure included. 558 See [RFC6205] for a description of Grid, C.S, Identifier and n, as 559 well as [RFC7579] for the details of each action. 561 0 1 2 3 563 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 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 | Action| Num Labels | Length | 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 |Grid | C.S | Identifier | n | 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 | Additional fields as necessary per action | 571 | | 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 Action (4 bits): 576 0 - Inclusive List 577 1 - Exclusive List 579 2 - Inclusive Range 581 3 - Exclusive Range 583 4 - Bitmap Set 585 Num Labels (12 bits): It is generally the number of labels. It has a 586 specific meaning depending on the action value. 588 Length (16 bits): It is the length in bytes of the entire Wavelength 589 Restriction field. 591 The Identifier has a specific PCEP context. To clarify the 592 interpretation of the Identifier, the following additional 593 explanation is added. 595 Identifier (9 bits): The value to be included in the "Identifier" 596 field of the WDM label in RSVP-TE signaling, as defined in section 597 3.2 of [RFC6205]. The PCC MAY use the assigned value for the 598 Identifier field in the corresponding LSP-related messages in RSVP- 599 TE signaling. The Identifier is always set to 0. If PCC receives the 600 value of the identifier other than 0, it will ignore. 602 See Sections 2.6.1 - 2.6.3 of [RFC7579] for details on additional 603 field discussion for each action. 605 4.4. Signal Processing Capability Restrictions 607 Path computation for WSON includes checking of signal processing 608 capabilities at each interface against requested capability; the PCE 609 MUST have mechanisms to know the signal processing capabilities at 610 each interface, e.g. by means of the Traffic Engineering Database 611 (TED) either via IGP or Network Management System (NMS). Moreover, 612 a PCC should be able to indicate additional restrictions to signal 613 processing compatibility, either on the endpoint or any given link. 615 The supported signal processing capabilities considered in the RWA 616 Information Model [RFC7446] are: 618 o Optical Interface Class List 620 o Bit Rate 622 o Client Signal 624 The Bit Rate restriction is already expressed in [PCEP-GMPLS] in the 625 BANDWIDTH object. 627 In order to support the Optical Interface Class information and the 628 Client Signal information new TLVs are introduced as endpoint- 629 restriction in the END-POINTS type Generalized endpoint: 631 o Client Signal TLV 633 o Optical Interface Class List TLV 635 The END-POINTS type generalized endpoint is extended as follows: 637 ::= 638 640 ::= 641 [] 643 ::= (| 644 [] 645 []) 646 Where 648 ::= 649 [] [] 651 The Wavelength Restriction Constraint TLV is defined in Section 4.3. 653 A new TLV for the Optical Interface Class List TLV (TBD5) is 654 defined, and the encoding of the value part of the Optical Interface 655 Class List TLV is described in Section 4.1 of [RFC7581]. 657 A new TLV for the Client Signal Information TLV (TBD6) is defined, 658 and the encoding of the value part of the Client Signal Information 659 TLV is described in Section 4.2 of [RFC7581]. 661 4.4.1. Signal Processing Exclusion 663 The PCC/PCE should be able to exclude particular types of signal 664 processing along the path in order to handle client restriction or 665 multi-domain path computation. [RFC5440] defines how Exclude Route 666 Object (XRO) subobject is used. In this draft, we add two new XRO 667 Signal Processing Exclusion Subobjects. 669 The first XRO subobject type (TBD9) is the Optical Interface Class 670 List Field defined as follows: 672 0 1 2 3 674 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 675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 676 |X| Type=TBD9 | Length | Reserved | Attribute | 677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 678 // Optical Interface Class List // 679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 Figure 5 Optical Interface Class List XRO Subobject 683 Refer to [RFC5521] for the definition of X, Length and Attribute. 685 Type (7 bits): The Type of the Signaling Processing Exclusion Field. 686 The TLV Type value (TBD9) is to be assigned by the IANA for the 687 Optical Interface Class List XRO Subobject Type. 689 Reserved bits (8 bits) are for future use and SHOULD be zeroed and 690 ignored on receipt. 692 The Attribute field (8 bits): [RFC5521] defines several Attribute 693 values; the only permitted Attribute values for this field are 0 694 (Interface) or 1 (Node). 696 The Optical Interface Class List is encoded as described in Section 697 4.1 of [RFC7581]. 699 The second XRO subobject type (TBD10) is the Client Signal 700 Information defined as follows: 702 0 1 2 3 703 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 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 |X| Type=TBD10 | Length | Reserved | Attribute | 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 // Client Signal Information // 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 710 Figure 6 Client Signal Information XRO Subobject 712 Refer to [RFC5521] for the definition of X, Length and Attribute. 714 Type (7 bits): The Type of the Signaling Processing Exclusion Field. 715 The TLV Type value (TBD10) is to be assigned by the IANA for the 716 Client Signal Information XRO Subobject Type. 718 Reserved bits (8 bits) are for future use and SHOULD be zeroed and 719 ignored on receipt. 721 The Attribute field (8 bits): [RFC5521] defines several Attribute 722 values; the only permitted Attribute values for this field are 0 723 (Interface) or 1 (Node). 725 The Client Signal Information is encoded as described in Section 4.2 726 of [RFC7581]. 728 The XRO needs to support the new Signaling Processing Exclusion XRO 729 Subobject types: 731 Type XRO Subobject Type 733 TBD9 Optical Interface Class List 735 TBD10 Client Signal Information 737 4.4.2. Signal Processing Inclusion 739 Similar to the XRO subobject, the PCC/PCE should be able to include 740 particular types of signal processing along the path in order to 741 handle client restriction or multi-domain path computation. 743 [RFC5440] defines how Include Route Object (IRO) subobject is used. 744 In this draft, we add two new Signal Processing Inclusion 745 Subobjects. 747 The IRO needs to support the new IRO Subobject types (TBD11 and 748 TBD12) for the PCEP IRO object [RFC5440]: 750 Type IRO Subobject Type 752 TBD11 Optical Interface Class List 754 TBD12 Client Signal Information 756 The encoding of the Signal Processing Inclusion subobjects is 757 similar to Section 4.4.1 where the 'X' field is replaced with 'L' 758 field, all the other fields remains the same. The 'L' field is 759 described in [RFC3209]. 761 5. Encoding of a RWA Path Reply 763 This section provides the encoding of a RWA Path Reply for 764 wavelength allocation request as discussed in Section 4. 766 5.1. Wavelength Allocation TLV 768 Recall that wavelength allocation can be performed by the PCE by 769 different means: 771 (a) By means of Explicit Label Control (ELC) where the PCE 772 allocates which label to use for each interface/node along the 773 path. 774 (b) By means of a Label Set where the PCE provides a range of 775 potential labels to allocate by each node along the path. 777 Option (b) allows distributed label allocation (performed during 778 signaling) to complete wavelength allocation. 780 The Wavelength Allocation TLV type is TBD4 (See Section 8.4). Note 781 that this TLV is used for both (a) and (b). The TLV data is defined 782 as follows: 784 0 1 2 3 785 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 786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 787 | Reserved | Flag |M| 788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 789 | Link Identifier Field | 790 // . . . // 791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 792 | Allocated Wavelength(s) | 793 // . . . . // 794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 796 Figure 7 Wavelength Allocation TLV Encoding 798 o Reserved (16 bits): Reserved for future use. 800 o Flags (16 bits) 802 One flag bit is allocated as follows: 804 . M (Mode): 1 bit 806 - 0 indicates the allocation is under Explicit Label Control. 807 - 1 indicates the allocation is expressed in Label Sets. 809 IANA is to create a new registry to manage the Flag field (TBD14) of 810 the Wavelength Allocation TLV. 812 Note that all link identifiers in the same list must be of the same 813 type. 815 o Link Identifier: Identifies the interface to which 816 assignment wavelength(s) is applied. See Section 4.3.1. for 817 Link Identifier encoding. 819 o Allocated Wavelength(s): Indicates the allocated 820 wavelength(s) to be associated with the Link Identifier. See 821 Section 4.3.2 for encoding details. 823 This TLV is carried in a PCRep message as an attribute TLV [RFC5420] 824 in the Hop Attribute Subobjects [RFC7570] in the ERO [RFC5440]. 826 5.2. Error Indicator 828 To indicate errors associated with the RWA request, a new Error Type 829 (TBD8) and subsequent error-values are defined as follows for 830 inclusion in the PCEP-ERROR Object: 832 A new Error-Type (TBD8) and subsequent error-values are defined as 833 follows: 835 o Error-Type=TBD8; Error-value=1: if a PCE receives a RWA request 836 and the PCE is not capable of processing the request due to 837 insufficient memory, the PCE MUST send a PCErr message with a 838 PCEP-ERROR Object (Error-Type=TBD8) and an Error-value (Error- 839 value=1). The PCE stops processing the request. The 840 corresponding RWA request MUST be cancelled at the PCC. 842 o Error-Type=TBD8; Error-value=2: if a PCE receives a RWA request 843 and the PCE is not capable of RWA computation, the PCE MUST 844 send a PCErr message with a PCEP-ERROR Object (Error-Type=TBD8) 845 and an Error-value (Error-value=2). The PCE stops processing 846 the request. The corresponding RWA computation MUST be 847 cancelled at the PCC. 849 o Error-Type=TBD8; Error-value=3: if a PCE receives a RWA request 850 and there are syntactical encoding errors (e.g., not exactly 851 two link identifiers with the range case, unknown identifier 852 types, no matching link for a given identifier, unknown Action 853 value, etc.), the PCE MUST send a PCErr message with a PCEP- 854 ERROR Object (Error-Type=TBD8) and an Error-value (Error- 855 value=3). 857 5.3. NO-PATH Indicator 859 To communicate the reason(s) for not being able to find RWA for the 860 path request, the NO-PATH object can be used in the corresponding 861 response. The format of the NO-PATH object body is defined in 862 [RFC5440]. The object may contain a NO-PATH-VECTOR TLV to provide 863 additional information about why a path computation has failed. 865 One new bit flag is defined to be carried in the Flags field in the 866 NO-PATH-VECTOR TLV carried in the NO-PATH Object. 868 o Bit TBD7: When set, the PCE indicates no feasible route was 869 found that meets all the constraints (e.g., wavelength 870 restriction, signal compatibility, etc.) associated with RWA. 872 6. Manageability Considerations 874 Manageability of WSON Routing and Wavelength Assignment (RWA) with 875 PCE must address the following considerations: 877 6.1. Control of Function and Policy 879 In addition to the parameters already listed in Section 8.1 of 880 [RFC5440], a PCEP implementation SHOULD allow configuration of the 881 following PCEP session parameters on a PCC: 883 o The ability to send a WSON RWA request. 885 In addition to the parameters already listed in Section 8.1 of 886 [RFC5440], a PCEP implementation SHOULD allow configuration of the 887 following PCEP session parameters on a PCE: 889 o The support for WSON RWA. 891 o A set of WSON RWA specific policies (authorized sender, 892 request rate limiter, etc). 894 These parameters may be configured as default parameters for any 895 PCEP session the PCEP speaker participates in, or may apply to a 896 specific session with a given PCEP peer or a specific group of 897 sessions with a specific group of PCEP peers. 899 6.2. Liveness Detection and Monitoring 901 Mechanisms defined in this document do not imply any new liveness 902 detection and monitoring requirements in addition to those already 903 listed in section 8.3 of [RFC5440]. 905 6.3. Verifying Correct Operation 907 Mechanisms defined in this document do not imply any new 908 verification requirements in addition to those already listed in 909 section 8.4 of [RFC5440] 911 6.4. Requirements on Other Protocols and Functional Components 913 The PCEP Link-State mechanism [PCEP-LS] may be used to advertise 914 WSON RWA path computation capabilities to PCCs. 916 6.5. Impact on Network Operation 918 Mechanisms defined in this document do not imply any new network 919 operation requirements in addition to those already listed in 920 section 8.6 of [RFC5440]. 922 7. Security Considerations 924 The security considerations discussed in [RFC5440] are relevant for 925 this document, this document does not introduce any new security 926 issues. If an operator wishes to keep private the information 927 distributed by WSON, PCEPS [RFC8253] SHOULD be used. 929 8. IANA Considerations 931 IANA maintains a registry of PCEP parameters. IANA has made 932 allocations from the sub-registries as described in the following 933 sections. 935 8.1. New PCEP Object: Wavelength Assignment Object 937 As described in Section 4.1, a new PCEP Object is defined to carry 938 wavelength assignment related constraints. IANA is to allocate the 939 following from "PCEP Objects" sub-registry 940 (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-objects): 942 Object Class Name Object Reference 943 Value Type 944 --------------------------------------------------------- 946 TBD1 WA 1: Wavelength Assignment [This.I-D] 948 8.2. WA Object Flag Field 950 As described in Section 4.1, IANA is to create a registry to manage 951 the Flag field of the WA object. New values are to be assigned by 952 Standards Action [RFC8126]. Each bit should be tracked with the 953 following qualities: 955 o Bit number (counting from bit 0 as the most significant bit) 957 o Capability description 959 o Defining RFC 961 The following values are defined in this document: 963 One bit is defined for the WA Object flag in this document: 965 Codespace of the Flag field (WA Object) 967 Bit Description Reference 968 ------------------------------------------------- 969 0-14 Unassigned [This.I-D] 971 15 Explicit Label Control [This.I-D] 973 8.3. New PCEP TLV: Wavelength Selection TLV 975 As described in Sections 4.2, a new PCEP TLV is defined to indicate 976 wavelength selection constraints. IANA is to allocate this new TLV 977 from the "PCEP TLV Type Indicators" subregistry 978 (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type- 979 indicators). 981 Value Description Reference 982 --------------------------------------------------------- 983 TBD2 Wavelength Selection [This.I-D] 985 8.4. New PCEP TLV: Wavelength Restriction Constraint TLV 987 As described in Sections 4.3, a new PCEP TLV is defined to indicate 988 wavelength restriction constraints. IANA is to allocate this new TLV 989 from the "PCEP TLV Type Indicators" subregistry 990 (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type- 991 indicators). 993 Value Description Reference 994 --------------------------------------------------------- 995 TBD3 Wavelength Restriction [This.I-D] 996 Constraint 998 8.5. Wavelength Restriction Constraint TLV Action Values 1000 As described in Section 4.3, IANA is to allocate a new registry to 1001 manage the Action values of the Action field in the Wavelength 1002 Restriction Constraint TLV. New values are assigned by Standards 1003 Action [RFC8126]. Each value should be tracked with the following 1004 qualities: value, meaning, and defining RFC. The following values 1005 are defined in this document: 1007 Value Meaning Reference 1009 --------------------------------------------------------- 1011 0 Inclusive List [This.I-D] 1013 1 Inclusive Range [This.I-D] 1015 2-255 Reserved [This.I-D] 1017 8.6. New PCEP TLV: Wavelength Allocation TLV 1019 As described in Section 5.1, a new PCEP TLV is defined to indicate 1020 the allocation of wavelength(s) by the PCE in response to a request 1021 by the PCC. IANA is to allocate this new TLV from the "PCEP TLV Type 1022 Indicators" subregistry 1023 (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type- 1024 indicators). 1026 Value Description Reference 1027 --------------------------------------------------------- 1028 TBD4 Wavelength Allocation [This.I-D] 1030 8.7. Wavelength Allocation TLV Flag Field 1032 As described in Section 5.1, IANA is to allocate a registry to 1033 manage the Flag field of the Wavelength Allocation TLV. New values 1034 are to be assigned by Standards Action [RFC8126]. Each bit should 1035 be tracked with the following qualities: 1037 o Bit number (counting from bit 0 as the most significant bit) 1039 o Capability description 1041 o Defining RFC 1043 One bit is defined for the Wavelength Allocation flag in this - 1044 document: 1046 Codespace of the Flag field (Wavelength Allocation TLV) 1048 Bit Description Reference 1049 ------------------------------------------------- 1050 0-14 Unassigned [This.I-D] 1052 15 Wavelength Allocation Mode [This.I-D] 1054 8.8. New PCEP TLV: Optical Interface Class List TLV 1056 As described in Section 4.4, a new PCEP TLV is defined to indicate 1057 the optical interface class list. IANA is to allocate this new TLV 1058 from the "PCEP TLV Type Indicators" subregistry 1059 (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type- 1060 indicators). 1062 Value Description Reference 1063 --------------------------------------------------------- 1064 TBD5 Optical Interface [This.I-D] 1065 Class List 1067 8.9. New PCEP TLV: Client Signal TLV 1069 As described in Section 4.4, a new PCEP TLV is defined to indicate 1070 the client signal information. IANA is to allocate this new TLV from 1071 the "PCEP TLV Type Indicators" subregistry 1072 (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type- 1073 indicators). 1075 Value Description Reference 1076 --------------------------------------------------------- 1077 TBD6 Client Signal Information [This.I-D] 1079 8.10. New No-Path Reasons 1081 As described in Section 5.3, a new bit flag are defined to be 1082 carried in the Flags field in the NO-PATH-VECTOR TLV carried in the 1083 NO-PATH Object. This flag, when set, indicates that no feasible 1084 route was found that meets all the RWA constraints (e.g., wavelength 1085 restriction, signal compatibility, etc.) associated with a RWA path 1086 computation request. 1088 IANA is to allocate this new bit flag from the "PCEP NO-PATH-VECTOR 1089 TLV Flag Field" subregistry 1090 (http://www.iana.org/assignments/pcep/pcep.xhtml#no-path-vector- 1091 tlv). 1093 Bit Description Reference 1094 ----------------------------------------------------- 1095 TBD7 No RWA constraints met [This.I-D] 1097 8.11. New Error-Types and Error-Values 1099 As described in Section 5.2, new PCEP error codes are defined for 1100 WSON RWA errors. IANA is to allocate from the ""PCEP-ERROR Object 1101 Error Types and Values" sub-registry 1102 (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-error-object). 1104 Error- Meaning Error-Value Reference 1105 Type 1106 --------------------------------------------------------------- 1108 TBD8 WSON RWA Error 0: Unassigned [This.I-D] 1110 1: Insufficient [This.I-D] 1111 Memory 1113 2: RWA computation [This.I-D] 1114 Not supported 1116 3: Syntactical [This.I-D] 1117 Encoding error 1119 4-255: Unassigned [This.I-D] 1121 8.12. New Subobjects for the Exclude Route Object 1123 As described in Section 4.4.1, the "PCEP Parameters" registry 1124 contains a subregistry "PCEP Objects" with an entry for the Exclude 1125 Route Object (XRO). IANA is requested to add further subobjects that 1126 can be carried in the XRO as follows: 1128 Subobject Type Reference 1130 ---------------------------------------------------------- 1132 TBD9 Optical Interface Class List [This.I-D] 1134 TBD10 Client Signal Information [This.I-D] 1136 8.13. New Subobjects for the Include Route Object 1138 As described in Section 4.4.2, the "PCEP Parameters" registry 1139 contains a subregistry "PCEP Objects" with an entry for the Include 1140 Route Object (IRO). IANA is requested to add further subobjects that 1141 can be carried in the IRO as follows: 1143 Subobject Type Reference 1145 ---------------------------------------------------------- 1146 TBD11 Optical Interface Class List [This.I-D] 1148 TBD12 Client Signal Information [This.I-D] 1150 8.14. Request for Updated Note for LMP TE Link Object Class Type 1152 As discussed in Section 4.3.1, the registry created for Link 1153 Management Protocol (LMP) [RFC4204] for "TE Link Object Class Type 1154 name space": https://www.iana.org/assignments/lmp-parameters/lmp- 1155 parameters.xhtml#lmp-parameters-15 is requested for the updated 1156 introductory note that the values have additional usage for the Link 1157 Identifier Type field. 1159 9. Acknowledgments 1161 The authors would like to thank Adrian Farrel, Julien Meuric, Dhruv 1162 Dhody and Benjamin Kaduk for many helpful comments that greatly 1163 improved the contents of this draft. 1165 10. References 1167 10.1. Normative References 1169 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1170 Requirement Levels", BCP 14, RFC 2119, March 1997. 1172 [RFC3209] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, G. 1173 Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", 1174 RFC 3209, December 2001. 1176 [RFC3630] D. Katz, K. Kompella, D. Yeung, "Traffic Engineering (TE) 1177 Extensions to OSPF Version 2", RFC 3630, September 2003. 1179 [RFC5329] A. Lindem, Ed., "Traffic Engineering Extensions to OSPF 1180 Version 3", RFC 5329, September 2008. 1182 [RFC5440] JP. Vasseur, Ed., JL. Le Roux, Ed., "Path Computation 1183 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 1184 March 2009. 1186 [RFC6205] Tomohiro, O. and D. Li, "Generalized Labels for Lambda- 1187 Switching Capable Label Switching Routers", RFC 6205, 1188 January, 2011. 1190 [RFC7570] C. Margaria, et al., "Label Switched Path (LSP) Attribute 1191 in the Explicit Route Object (ERO)", RFC 7570, July 2015. 1193 [RFC7579] G. Bernstein and Y. Lee, "General Network Element 1194 Constraint Encoding for GMPLS Controlled Networks", RFC 1195 7579, June 2015. 1197 [RFC7581] G. Bernstein and Y. Lee, "Routing and Wavelength 1198 Assignment Information Encoding for Wavelength Switched 1199 Optical Networks", RFC7581, June 2015. 1201 [RFC7689] Bernstein et al., "Signaling Extensions for Wavelength 1202 Switched Optical Networks", RFC 7689, November 2015. 1204 [RFC7688] Y. Lee, and G. Bernstein, "OSPF Enhancement for Signal and 1205 Network Element Compatibility for Wavelength Switched 1206 Optical Networks", RFC 7688, November 2015. 1208 [RFC8174] B. Leiba, "Ambiguity of Uppercase vs Lowercase in RFC 2119 1209 Key Words", RFC 8174, May 2017. 1211 [RFC8253] D. Lopez, O. Gonzalez de Dios, Q. Wu, D. Dhody, "PCEPS: 1212 Usage of TLS to Provide a Secure Transport for the Path 1213 Computation Element Communication Protocol (PCEP)", RFC 1214 8253, October 2017. 1216 [PCEP-GMPLS] C. Margaria, et al., "PCEP extensions for GMPLS", 1217 draft-ietf-pce-gmpls-pcep-extensions, work in progress. 1219 10.2. Informative References 1221 [RFC3471] Berger, L. (Editor), "Generalized Multi-Protocol Label 1222 Switching (GMPLS) Signaling Functional Description", RFC 1223 3471. January 2003. 1225 [RFC4203] K. Kompella, Ed., Y. Rekhter, Ed., "OSPF Extensions in 1226 Support of Generalized Multi-Protocol Label Switching 1227 (GMPLS)", RFC 4203, October 2005. 1229 [RFC4204] J. Lang, Ed., "Link Management Protocol (LMP)", RFC 4204, 1230 October 2005. 1232 [RFC4655] A. Farrel, JP. Vasseur, G. Ash, "A Path Computation 1233 Element (PCE)-Based Architecture", RFC 4655, August 2006. 1235 [RFC5420] Farrel, A. "Encoding of Attributes for MPLS LSP 1236 Establishment Using Resource Reservation Protocol Traffic 1237 Engineering (RSVP-TE)", RFC5420, February 2009. 1239 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1240 Element (PCE) communication Protocol", RFC 5440, March 1241 2009.[RFC5521] Oki, E, T. Takeda, and A. Farrel, 1242 "Extensions to the Path Computation Element Communication 1243 Protocol (PCEP) for Route Exclusions", RFC 5521, April 1244 2009. 1246 [RFC6163] Lee, Y. and Bernstein, G. (Editors), and W. Imajuku, 1247 "Framework for GMPLS and PCE Control of Wavelength 1248 Switched Optical Networks", RFC 6163, March 2011. 1250 [RFC6566] Lee, Y. and Berstein, G. (Editors), "A Framework for the 1251 Control of Wavelength Switched Optical Networks (WSONs) 1252 with Impairments", RFC 6566, March 2012. 1254 [RFC7446] Y. Lee, G. Bernstein, (Editors), "Routing and Wavelength 1255 Assignment Information Model for Wavelength Switched 1256 Optical Networks", RFC 7446, February 2015. 1258 [RFC7449] Y. Lee, G. Bernstein, (Editors), "Path Computation Element 1259 Communication Protocol (PCEP) Requirements for Wavelength 1260 Switched Optical Network (WSON) Routing and Wavelength 1261 Assignment", RFC 7449, February 2015. 1263 [PCEP-LS] Y. Lee, et al., "PCEP Extension for Distribution of Link- 1264 State and TE information for Optical Networks", draft-lee- 1265 pce-pcep-ls-optical, work in progress. 1267 [RFC8126] M. Cotton, B. Leiba, T,.Narten, "Guidelines for Writing an 1268 IANA Considerations Section in RFCs", RFC 8126, June 2017. 1270 11. Contributors 1272 Fatai Zhang 1273 Huawei Technologies 1274 Email: zhangfatai@huawei.com 1276 Cyril Margaria 1277 Nokia Siemens Networks 1278 St Martin Strasse 76 1279 Munich, 81541 1280 Germany 1281 Phone: +49 89 5159 16934 1282 Email: cyril.margaria@nsn.com 1284 Oscar Gonzalez de Dios 1285 Telefonica Investigacion y Desarrollo 1286 C/ Emilio Vargas 6 1287 Madrid, 28043 1288 Spain 1289 Phone: +34 91 3374013 1290 Email: ogondio@tid.es 1292 Greg Bernstein 1293 Grotto Networking 1294 Fremont, CA, USA 1295 Phone: (510) 573-2237 1296 Email: gregb@grotto-networking.com 1298 Authors' Addresses 1300 Young Lee, Editor 1301 Huawei Technologies 1302 5700 Tennyson Parkway Suite 600 1303 Plano, TX 75024, USA 1304 Email: leeyoung@huawei.com 1306 Ramon Casellas, Editor 1307 CTTC PMT Ed B4 Av. Carl Friedrich Gauss 7 1308 08860 Castelldefels (Barcelona) 1309 Spain 1310 Phone: (34) 936452916 1311 Email: ramon.casellas@cttc.es