idnits 2.17.1 draft-ietf-pce-wson-rwa-ext-17.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 1882 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-17 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.........................16 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..........................................20 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 Components22 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.....................................23 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.....................25 95 8.8. New PCEP TLV: Optical Interface Class List TLV...........26 96 8.9. New PCEP TLV: Client Signal TLV..........................26 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 ..............................................................28 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 Identifier (9 bits): The Identifier is always set to 0. If PCC 592 receives the value of the identifier other than 0, it will ignore. 594 See Sections 2.6.1 - 2.6.3 of [RFC7579] for details on additional 595 field discussion for each action. 597 4.4. Signal Processing Capability Restrictions 599 Path computation for WSON includes checking of signal processing 600 capabilities at each interface against requested capability; the PCE 601 MUST have mechanisms to know the signal processing capabilities at 602 each interface, e.g. by means of the Traffic Engineering Database 603 (TED) either via IGP or Network Management System (NMS). Moreover, 604 a PCC should be able to indicate additional restrictions to signal 605 processing compatibility, either on the endpoint or any given link. 607 The supported signal processing capabilities considered in the RWA 608 Information Model [RFC7446] are: 610 o Optical Interface Class List 612 o Bit Rate 614 o Client Signal 616 The Bit Rate restriction is already expressed in [PCEP-GMPLS] in the 617 BANDWIDTH object. 619 In order to support the Optical Interface Class information and the 620 Client Signal information new TLVs are introduced as endpoint- 621 restriction in the END-POINTS type Generalized endpoint: 623 o Client Signal TLV 625 o Optical Interface Class List TLV 627 The END-POINTS type generalized endpoint is extended as follows: 629 ::= 630 632 ::= 633 [] 635 ::= (| 636 [] 637 []) 638 Where 640 ::= 641 [] [] 643 The Wavelength Restriction Constraint TLV is defined in Section 4.3. 645 A new TLV for the Optical Interface Class List TLV (TBD5) is 646 defined, and the encoding of the value part of the Optical Interface 647 Class List TLV is described in Section 4.1 of [RFC7581]. 649 A new TLV for the Client Signal Information TLV (TBD6) is defined, 650 and the encoding of the value part of the Client Signal Information 651 TLV is described in Section 4.2 of [RFC7581]. 653 4.4.1. Signal Processing Exclusion 655 The PCC/PCE should be able to exclude particular types of signal 656 processing along the path in order to handle client restriction or 657 multi-domain path computation. [RFC5440] defines how Exclude Route 658 Object (XRO) subobject is used. In this draft, we add two new XRO 659 Signal Processing Exclusion Subobjects. 661 The first XRO subobject type (TBD9) is the Optical Interface Class 662 List Field defined as follows: 664 0 1 2 3 666 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 667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 |X| Type=TBD9 | Length | Reserved | Attribute | 669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 670 // Optical Interface Class List // 671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 673 Figure 5 Optical Interface Class List XRO Subobject 675 Refer to [RFC5521] for the definition of X, Length and Attribute. 677 Type (7 bits): The Type of the Signaling Processing Exclusion Field. 678 The TLV Type value (TBD9) is to be assigned by the IANA for the 679 Optical Interface Class List XRO Subobject Type. 681 Reserved bits (8 bits) are for future use and SHOULD be zeroed and 682 ignored on receipt. 684 The Attribute field (8 bits): [RFC5521] defines several Attribute 685 values; the only permitted Attribute values for this field are 0 686 (Interface) or 1 (Node). 688 The Optical Interface Class List is encoded as described in Section 689 4.1 of [RFC7581]. 691 The second XRO subobject type (TBD10) is the Client Signal 692 Information defined as follows: 694 0 1 2 3 696 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 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 |X| Type=TBD10 | Length | Reserved | Attribute | 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 700 // Client Signal Information // 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 702 Figure 6 Client Signal Information XRO Subobject 704 Refer to [RFC5521] for the definition of X, Length and Attribute. 706 Type (7 bits): The Type of the Signaling Processing Exclusion Field. 707 The TLV Type value (TBD10) is to be assigned by the IANA for the 708 Client Signal Information XRO Subobject Type. 710 Reserved bits (8 bits) are for future use and SHOULD be zeroed and 711 ignored on receipt. 713 The Attribute field (8 bits): [RFC5521] defines several Attribute 714 values; the only permitted Attribute values for this field are 0 715 (Interface) or 1 (Node). 717 The Client Signal Information is encoded as described in Section 4.2 718 of [RFC7581]. 720 The XRO needs to support the new Signaling Processing Exclusion XRO 721 Subobject types: 723 Type XRO Subobject Type 725 TBD9 Optical Interface Class List 727 TBD10 Client Signal Information 729 4.4.2. Signal Processing Inclusion 731 Similar to the XRO subobject, the PCC/PCE should be able to include 732 particular types of signal processing along the path in order to 733 handle client restriction or multi-domain path computation. 734 [RFC5440] defines how Include Route Object (IRO) subobject is used. 735 In this draft, we add two new Signal Processing Inclusion 736 Subobjects. 738 The IRO needs to support the new IRO Subobject types (TBD11 and 739 TBD12) for the PCEP IRO object [RFC5440]: 741 Type IRO Subobject Type 742 TBD11 Optical Interface Class List 744 TBD12 Client Signal Information 746 The encoding of the Signal Processing Inclusion subobjects is 747 similar to Section 4.4.1 where the 'X' field is replaced with 'L' 748 field, all the other fields remains the same. The 'L' field is 749 described in [RFC3209]. 751 5. Encoding of a RWA Path Reply 753 This section provides the encoding of a RWA Path Reply for 754 wavelength allocation request as discussed in Section 4. 756 5.1. Wavelength Allocation TLV 758 Recall that wavelength allocation can be performed by the PCE by 759 different means: 761 (a) By means of Explicit Label Control (ELC) where the PCE 762 allocates which label to use for each interface/node along the 763 path. 764 (b) By means of a Label Set where the PCE provides a range of 765 potential labels to allocate by each node along the path. 767 Option (b) allows distributed label allocation (performed during 768 signaling) to complete wavelength allocation. 770 The Wavelength Allocation TLV type is TBD4 (See Section 8.4). Note 771 that this TLV is used for both (a) and (b). The TLV data is defined 772 as follows: 774 0 1 2 3 775 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 776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 777 | Reserved | Flag |M| 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 779 | Link Identifier Field | 780 // . . . // 781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 782 | Allocated Wavelength(s) | 783 // . . . . // 784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 785 Figure 7 Wavelength Allocation TLV Encoding 787 o Reserved (16 bits): Reserved for future use. 789 o Flags (16 bits) 791 One flag bit is allocated as follows: 793 . M (Mode): 1 bit 795 - 0 indicates the allocation is under Explicit Label Control. 796 - 1 indicates the allocation is expressed in Label Sets. 798 IANA is to create a new registry to manage the Flag field (TBD14) of 799 the Wavelength Allocation TLV. 801 Note that all link identifiers in the same list must be of the same 802 type. 804 o Link Identifier: Identifies the interface to which 805 assignment wavelength(s) is applied. See Section 4.3.1. for 806 Link Identifier encoding. 808 o Allocated Wavelength(s): Indicates the allocated 809 wavelength(s) to be associated with the Link Identifier. See 810 Section 4.3.2 for encoding details. 812 This TLV is carried in a PCRep message as an attribute TLV [RFC5420] 813 in the Hop Attribute Subobjects [RFC7570] in the ERO [RFC5440]. 815 5.2. Error Indicator 817 To indicate errors associated with the RWA request, a new Error Type 818 (TBD8) and subsequent error-values are defined as follows for 819 inclusion in the PCEP-ERROR Object: 821 A new Error-Type (TBD8) and subsequent error-values are defined as 822 follows: 824 o Error-Type=TBD8; Error-value=1: if a PCE receives a RWA request 825 and the PCE is not capable of processing the request due to 826 insufficient memory, the PCE MUST send a PCErr message with a 827 PCEP-ERROR Object (Error-Type=TBD8) and an Error-value (Error- 828 value=1). The PCE stops processing the request. The 829 corresponding RWA request MUST be cancelled at the PCC. 831 o Error-Type=TBD8; Error-value=2: if a PCE receives a RWA request 832 and the PCE is not capable of RWA computation, the PCE MUST 833 send a PCErr message with a PCEP-ERROR Object (Error-Type=TBD8) 834 and an Error-value (Error-value=2). The PCE stops processing 835 the request. The corresponding RWA computation MUST be 836 cancelled at the PCC. 838 o Error-Type=TBD8; Error-value=3: if a PCE receives a RWA request 839 and there are syntactical encoding errors (e.g., not exactly 840 two link identifiers with the range case, unknown identifier 841 types, no matching link for a given identifier, unknown Action 842 value, etc.), the PCE MUST send a PCErr message with a PCEP- 843 ERROR Object (Error-Type=TBD8) and an Error-value (Error- 844 value=3). 846 5.3. NO-PATH Indicator 848 To communicate the reason(s) for not being able to find RWA for the 849 path request, the NO-PATH object can be used in the corresponding 850 response. The format of the NO-PATH object body is defined in 851 [RFC5440]. The object may contain a NO-PATH-VECTOR TLV to provide 852 additional information about why a path computation has failed. 854 One new bit flag is defined to be carried in the Flags field in the 855 NO-PATH-VECTOR TLV carried in the NO-PATH Object. 857 o Bit TBD7: When set, the PCE indicates no feasible route was 858 found that meets all the constraints (e.g., wavelength 859 restriction, signal compatibility, etc.) associated with RWA. 861 6. Manageability Considerations 863 Manageability of WSON Routing and Wavelength Assignment (RWA) with 864 PCE must address the following considerations: 866 6.1. Control of Function and Policy 868 In addition to the parameters already listed in Section 8.1 of 869 [RFC5440], a PCEP implementation SHOULD allow configuration of the 870 following PCEP session parameters on a PCC: 872 o The ability to send a WSON RWA request. 874 In addition to the parameters already listed in Section 8.1 of 875 [RFC5440], a PCEP implementation SHOULD allow configuration of the 876 following PCEP session parameters on a PCE: 878 o The support for WSON RWA. 880 o A set of WSON RWA specific policies (authorized sender, 881 request rate limiter, etc). 883 These parameters may be configured as default parameters for any 884 PCEP session the PCEP speaker participates in, or may apply to a 885 specific session with a given PCEP peer or a specific group of 886 sessions with a specific group of PCEP peers. 888 6.2. Liveness Detection and Monitoring 890 Mechanisms defined in this document do not imply any new liveness 891 detection and monitoring requirements in addition to those already 892 listed in section 8.3 of [RFC5440]. 894 6.3. Verifying Correct Operation 896 Mechanisms defined in this document do not imply any new 897 verification requirements in addition to those already listed in 898 section 8.4 of [RFC5440] 900 6.4. Requirements on Other Protocols and Functional Components 902 The PCEP Link-State mechanism [PCEP-LS] may be used to advertise 903 WSON RWA path computation capabilities to PCCs. 905 6.5. Impact on Network Operation 907 Mechanisms defined in this document do not imply any new network 908 operation requirements in addition to those already listed in 909 section 8.6 of [RFC5440]. 911 7. Security Considerations 913 The security considerations discussed in [RFC5440] are relevant for 914 this document, this document does not introduce any new security 915 issues. If an operator wishes to keep private the information 916 distributed by WSON, PCEPS [RFC8253] SHOULD be used. 918 8. IANA Considerations 920 IANA maintains a registry of PCEP parameters. IANA has made 921 allocations from the sub-registries as described in the following 922 sections. 924 8.1. New PCEP Object: Wavelength Assignment Object 926 As described in Section 4.1, a new PCEP Object is defined to carry 927 wavelength assignment related constraints. IANA is to allocate the 928 following from "PCEP Objects" sub-registry 929 (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-objects): 931 Object Class Name Object Reference 932 Value Type 933 --------------------------------------------------------- 935 TBD1 WA 1: Wavelength Assignment [This.I-D] 937 8.2. WA Object Flag Field 939 As described in Section 4.1, IANA is to create a registry to manage 940 the Flag field of the WA object. New values are to be assigned by 941 Standards Action [RFC8126]. Each bit should be tracked with the 942 following qualities: 944 o Bit number (counting from bit 0 as the most significant bit) 946 o Capability description 948 o Defining RFC 950 The following values are defined in this document: 952 One bit is defined for the WA Object flag in this document: 954 Codespace of the Flag field (WA Object) 956 Bit Description Reference 957 ------------------------------------------------- 958 0-14 Unassigned [This.I-D] 960 15 Explicit Label Control [This.I-D] 962 8.3. New PCEP TLV: Wavelength Selection TLV 964 As described in Sections 4.2, a new PCEP TLV is defined to indicate 965 wavelength selection constraints. IANA is to allocate this new TLV 966 from the "PCEP TLV Type Indicators" subregistry 967 (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type- 968 indicators). 970 Value Description Reference 971 --------------------------------------------------------- 972 TBD2 Wavelength Selection [This.I-D] 974 8.4. New PCEP TLV: Wavelength Restriction Constraint TLV 976 As described in Sections 4.3, a new PCEP TLV is defined to indicate 977 wavelength restriction constraints. IANA is to allocate this new TLV 978 from the "PCEP TLV Type Indicators" subregistry 979 (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type- 980 indicators). 982 Value Description Reference 983 --------------------------------------------------------- 984 TBD3 Wavelength Restriction [This.I-D] 985 Constraint 987 8.5. Wavelength Restriction Constraint TLV Action Values 989 As described in Section 4.3, IANA is to allocate a new registry to 990 manage the Action values of the Action field in the Wavelength 991 Restriction Constraint TLV. New values are assigned by Standards 992 Action [RFC8126]. Each value should be tracked with the following 993 qualities: value, meaning, and defining RFC. The following values 994 are defined in this document: 996 Value Meaning Reference 998 --------------------------------------------------------- 1000 0 Inclusive List [This.I-D] 1002 1 Inclusive Range [This.I-D] 1004 2-255 Reserved [This.I-D] 1006 8.6. New PCEP TLV: Wavelength Allocation TLV 1008 As described in Section 5.1, a new PCEP TLV is defined to indicate 1009 the allocation of wavelength(s) by the PCE in response to a request 1010 by the PCC. IANA is to allocate this new TLV from the "PCEP TLV Type 1011 Indicators" subregistry 1012 (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type- 1013 indicators). 1015 Value Description Reference 1016 --------------------------------------------------------- 1017 TBD4 Wavelength Allocation [This.I-D] 1019 8.7. Wavelength Allocation TLV Flag Field 1021 As described in Section 5.1, IANA is to allocate a registry to 1022 manage the Flag field of the Wavelength Allocation TLV. New values 1023 are to be assigned by Standards Action [RFC8126]. Each bit should 1024 be tracked with the following qualities: 1026 o Bit number (counting from bit 0 as the most significant bit) 1027 o Capability description 1029 o Defining RFC 1031 One bit is defined for the Wavelength Allocation flag in this - 1032 document: 1034 Codespace of the Flag field (Wavelength Allocation TLV) 1036 Bit Description Reference 1037 ------------------------------------------------- 1038 0-14 Unassigned [This.I-D] 1040 15 Wavelength Allocation Mode [This.I-D] 1042 8.8. New PCEP TLV: Optical Interface Class List TLV 1044 As described in Section 4.4, a new PCEP TLV is defined to indicate 1045 the optical interface class list. IANA is to allocate this new TLV 1046 from the "PCEP TLV Type Indicators" subregistry 1047 (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type- 1048 indicators). 1050 Value Description Reference 1051 --------------------------------------------------------- 1052 TBD5 Optical Interface [This.I-D] 1053 Class List 1055 8.9. New PCEP TLV: Client Signal TLV 1057 As described in Section 4.4, a new PCEP TLV is defined to indicate 1058 the client signal information. IANA is to allocate this new TLV from 1059 the "PCEP TLV Type Indicators" subregistry 1060 (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type- 1061 indicators). 1063 Value Description Reference 1064 --------------------------------------------------------- 1065 TBD6 Client Signal Information [This.I-D] 1067 8.10. New No-Path Reasons 1069 As described in Section 5.3, a new bit flag are defined to be 1070 carried in the Flags field in the NO-PATH-VECTOR TLV carried in the 1071 NO-PATH Object. This flag, when set, indicates that no feasible 1072 route was found that meets all the RWA constraints (e.g., wavelength 1073 restriction, signal compatibility, etc.) associated with a RWA path 1074 computation request. 1076 IANA is to allocate this new bit flag from the "PCEP NO-PATH-VECTOR 1077 TLV Flag Field" subregistry 1078 (http://www.iana.org/assignments/pcep/pcep.xhtml#no-path-vector- 1079 tlv). 1081 Bit Description Reference 1082 ----------------------------------------------------- 1083 TBD7 No RWA constraints met [This.I-D] 1085 8.11. New Error-Types and Error-Values 1087 As described in Section 5.2, new PCEP error codes are defined for 1088 WSON RWA errors. IANA is to allocate from the ""PCEP-ERROR Object 1089 Error Types and Values" sub-registry 1090 (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-error-object). 1092 Error- Meaning Error-Value Reference 1093 Type 1094 --------------------------------------------------------------- 1096 TBD8 WSON RWA Error 0: Unassigned [This.I-D] 1098 1: Insufficient [This.I-D] 1099 Memory 1101 2: RWA computation [This.I-D] 1102 Not supported 1104 3: Syntactical [This.I-D] 1105 Encoding error 1107 4-255: Unassigned [This.I-D] 1109 8.12. New Subobjects for the Exclude Route Object 1111 As described in Section 4.4.1, the "PCEP Parameters" registry 1112 contains a subregistry "PCEP Objects" with an entry for the Exclude 1113 Route Object (XRO). IANA is requested to add further subobjects that 1114 can be carried in the XRO as follows: 1116 Subobject Type Reference 1118 ---------------------------------------------------------- 1120 TBD9 Optical Interface Class List [This.I-D] 1122 TBD10 Client Signal Information [This.I-D] 1124 8.13. New Subobjects for the Include Route Object 1126 As described in Section 4.4.2, the "PCEP Parameters" registry 1127 contains a subregistry "PCEP Objects" with an entry for the Include 1128 Route Object (IRO). IANA is requested to add further subobjects that 1129 can be carried in the IRO as follows: 1131 Subobject Type Reference 1133 ---------------------------------------------------------- 1135 TBD11 Optical Interface Class List [This.I-D] 1137 TBD12 Client Signal Information [This.I-D] 1139 8.14. Request for Updated Note for LMP TE Link Object Class Type 1141 As discussed in Section 4.3.1, the registry created for Link 1142 Management Protocol (LMP) [RFC4204] for "TE Link Object Class Type 1143 name space": https://www.iana.org/assignments/lmp-parameters/lmp- 1144 parameters.xhtml#lmp-parameters-15 is requested for the updated 1145 introductory note that the values have additional usage for the Link 1146 Identifier Type field. 1148 9. Acknowledgments 1150 The authors would like to thank Adrian Farrel, Julien Meuric, Dhruv 1151 Dhody and Benjamin Kaduk for many helpful comments that greatly 1152 improved the contents of this draft. 1154 10. References 1156 10.1. Normative References 1158 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1159 Requirement Levels", BCP 14, RFC 2119, March 1997. 1161 [RFC3209] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, G. 1162 Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", 1163 RFC 3209, December 2001. 1165 [RFC3630] D. Katz, K. Kompella, D. Yeung, "Traffic Engineering (TE) 1166 Extensions to OSPF Version 2", RFC 3630, September 2003. 1168 [RFC5329] A. Lindem, Ed., "Traffic Engineering Extensions to OSPF 1169 Version 3", RFC 5329, September 2008. 1171 [RFC5440] JP. Vasseur, Ed., JL. Le Roux, Ed., "Path Computation 1172 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 1173 March 2009. 1175 [RFC6205] Tomohiro, O. and D. Li, "Generalized Labels for Lambda- 1176 Switching Capable Label Switching Routers", RFC 6205, 1177 January, 2011. 1179 [RFC7570] C. Margaria, et al., "Label Switched Path (LSP) Attribute 1180 in the Explicit Route Object (ERO)", RFC 7570, July 2015. 1182 [RFC7579] G. Bernstein and Y. Lee, "General Network Element 1183 Constraint Encoding for GMPLS Controlled Networks", RFC 1184 7579, June 2015. 1186 [RFC7581] G. Bernstein and Y. Lee, "Routing and Wavelength 1187 Assignment Information Encoding for Wavelength Switched 1188 Optical Networks", RFC7581, June 2015. 1190 [RFC7689] Bernstein et al., "Signaling Extensions for Wavelength 1191 Switched Optical Networks", RFC 7689, November 2015. 1193 [RFC7688] Y. Lee, and G. Bernstein, "OSPF Enhancement for Signal and 1194 Network Element Compatibility for Wavelength Switched 1195 Optical Networks", RFC 7688, November 2015. 1197 [RFC8174] B. Leiba, "Ambiguity of Uppercase vs Lowercase in RFC 2119 1198 Key Words", RFC 8174, May 2017. 1200 [RFC8253] D. Lopez, O. Gonzalez de Dios, Q. Wu, D. Dhody, "PCEPS: 1201 Usage of TLS to Provide a Secure Transport for the Path 1202 Computation Element Communication Protocol (PCEP)", RFC 1203 8253, October 2017. 1205 [PCEP-GMPLS] C. Margaria, et al., "PCEP extensions for GMPLS", 1206 draft-ietf-pce-gmpls-pcep-extensions, work in progress. 1208 10.2. Informative References 1210 [RFC3471] Berger, L. (Editor), "Generalized Multi-Protocol Label 1211 Switching (GMPLS) Signaling Functional Description", RFC 1212 3471. January 2003. 1214 [RFC4203] K. Kompella, Ed., Y. Rekhter, Ed., "OSPF Extensions in 1215 Support of Generalized Multi-Protocol Label Switching 1216 (GMPLS)", RFC 4203, October 2005. 1218 [RFC4204] J. Lang, Ed., "Link Management Protocol (LMP)", RFC 4204, 1219 October 2005. 1221 [RFC4655] A. Farrel, JP. Vasseur, G. Ash, "A Path Computation 1222 Element (PCE)-Based Architecture", RFC 4655, August 2006. 1224 [RFC5420] Farrel, A. "Encoding of Attributes for MPLS LSP 1225 Establishment Using Resource Reservation Protocol Traffic 1226 Engineering (RSVP-TE)", RFC5420, February 2009. 1228 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1229 Element (PCE) communication Protocol", RFC 5440, March 1230 2009.[RFC5521] Oki, E, T. Takeda, and A. Farrel, 1231 "Extensions to the Path Computation Element Communication 1232 Protocol (PCEP) for Route Exclusions", RFC 5521, April 1233 2009. 1235 [RFC6163] Lee, Y. and Bernstein, G. (Editors), and W. Imajuku, 1236 "Framework for GMPLS and PCE Control of Wavelength 1237 Switched Optical Networks", RFC 6163, March 2011. 1239 [RFC6566] Lee, Y. and Berstein, G. (Editors), "A Framework for the 1240 Control of Wavelength Switched Optical Networks (WSONs) 1241 with Impairments", RFC 6566, March 2012. 1243 [RFC7446] Y. Lee, G. Bernstein, (Editors), "Routing and Wavelength 1244 Assignment Information Model for Wavelength Switched 1245 Optical Networks", RFC 7446, February 2015. 1247 [RFC7449] Y. Lee, G. Bernstein, (Editors), "Path Computation Element 1248 Communication Protocol (PCEP) Requirements for Wavelength 1249 Switched Optical Network (WSON) Routing and Wavelength 1250 Assignment", RFC 7449, February 2015. 1252 [PCEP-LS] Y. Lee, et al., "PCEP Extension for Distribution of Link- 1253 State and TE information for Optical Networks", draft-lee- 1254 pce-pcep-ls-optical, work in progress. 1256 [RFC8126] M. Cotton, B. Leiba, T,.Narten, "Guidelines for Writing an 1257 IANA Considerations Section in RFCs", RFC 8126, June 2017. 1259 11. Contributors 1261 Fatai Zhang 1262 Huawei Technologies 1263 Email: zhangfatai@huawei.com 1265 Cyril Margaria 1266 Nokia Siemens Networks 1267 St Martin Strasse 76 1268 Munich, 81541 1269 Germany 1270 Phone: +49 89 5159 16934 1271 Email: cyril.margaria@nsn.com 1273 Oscar Gonzalez de Dios 1274 Telefonica Investigacion y Desarrollo 1275 C/ Emilio Vargas 6 1276 Madrid, 28043 1277 Spain 1278 Phone: +34 91 3374013 1279 Email: ogondio@tid.es 1281 Greg Bernstein 1282 Grotto Networking 1283 Fremont, CA, USA 1284 Phone: (510) 573-2237 1285 Email: gregb@grotto-networking.com 1287 Authors' Addresses 1289 Young Lee, Editor 1290 Huawei Technologies 1291 5700 Tennyson Parkway Suite 600 1292 Plano, TX 75024, USA 1293 Email: leeyoung@huawei.com 1295 Ramon Casellas, Editor 1296 CTTC PMT Ed B4 Av. Carl Friedrich Gauss 7 1297 08860 Castelldefels (Barcelona) 1298 Spain 1299 Phone: (34) 936452916 1300 Email: ramon.casellas@cttc.es