idnits 2.17.1 draft-meuric-ccamp-tsvmode-signaling-00.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 : ---------------------------------------------------------------------------- == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 6, 2020) is 1505 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) == Missing Reference: 'G.694.1' is mentioned on line 87, but not defined == Missing Reference: 'This I-D' is mentioned on line 378, but not defined == Outdated reference: A later version (-16) exists of draft-ggalimbe-ccamp-flexigrid-carrier-label-08 ** Downref: Normative reference to an Experimental draft: draft-ggalimbe-ccamp-flexigrid-carrier-label (ref. 'I-D.ggalimbe-ccamp-flexigrid-carrier-label') == Outdated reference: A later version (-09) exists of draft-ietf-ccamp-dwdm-if-lmp-01 ** Downref: Normative reference to an Informational RFC: RFC 5920 == Outdated reference: A later version (-10) exists of draft-ietf-ccamp-dwdm-if-param-yang-02 Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Meuric, Ed. 3 Internet-Draft E. Le Rouzic 4 Updates: RFC7689 (if approved) Orange 5 Intended status: Standards Track L. Alahdab 6 Expires: September 7, 2020 Individual 7 G. Galimberti 8 Cisco 9 March 6, 2020 11 Conveying Transceiver-Related Information within RSVP-TE Signaling 12 draft-meuric-ccamp-tsvmode-signaling-00 14 Abstract 16 The ReSource Reservation Protocol with Traffic Engineering extensions 17 (RSVP-TE) allows to carry optical information so as to set up 18 channels over Wavelength Division Multiplexing (WDM) networks between 19 a pair of transceivers. Nowadays, there are many transceivers that 20 not only support tunable lasers, but also multiple modulation 21 formats. This memo leverages the Generalized Multiprotocol Label 22 Switching protocol extensions to support the signaling of the 23 associated information as a "mode" parameter within a "transceiver 24 type" context. 26 Requirements Language 28 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 29 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 30 document are to be interpreted as described in RFC 2119 [RFC2119]. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on September 7, 2020. 49 Copyright Notice 51 Copyright (c) 2020 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Main Use Cases . . . . . . . . . . . . . . . . . . . . . . . 3 68 2.1. Single Control Domain . . . . . . . . . . . . . . . . . . 3 69 2.2. Open Line Systems . . . . . . . . . . . . . . . . . . . . 4 70 3. Signaling Messages . . . . . . . . . . . . . . . . . . . . . 4 71 3.1. Encodings . . . . . . . . . . . . . . . . . . . . . . . . 4 72 3.1.1. WDM-Transceiver-ModeID Sub-TLV . . . . . . . . . . . 4 73 3.1.2. WDM-Tranceiver-Param Sub-TLV . . . . . . . . . . . . 6 74 3.2. Processing . . . . . . . . . . . . . . . . . . . . . . . 7 75 3.2.1. Downstream Direction . . . . . . . . . . . . . . . . 7 76 3.2.2. Upstream Direction . . . . . . . . . . . . . . . . . 7 77 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 78 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 79 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 80 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 81 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 82 7.2. Informative References . . . . . . . . . . . . . . . . . 12 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 85 1. Introduction 87 The ITU-T's recommendation [G.694.1] defines the flexi-grid 88 technology as the latest evolution of the WDM data plane. [RFC7689] 89 defines the extensions to the RSVP-TE signaling ([RFC3473]) to 90 provision lightpaths in WDM networks, from transceiver to 91 transceiver, including transit Reconfigurable Optical Add-Drop 92 Multiplexers (ROADMs). [RFC7792] specifies the encoding of the flex- 93 grid label to be carried within RSVP-TE signaling messages, 94 leveraging the reconfiguration capability of optical switches and the 95 wavelength tunability of the transceivers at both ends of the optical 96 signal. 98 To address the various requirements of optical networks, some 99 transceivers are supporting multiple modulation formats, baudrates, 100 FECs, etc. This capability enables to select at setup time the right 101 trade-off between bitrate, baudrate, reach, spectral width, etc. 102 This memo defines the required fields to explicitly addresses this 103 case of "elastic" transceivers. Two options are proposed to address 104 this issue. The first extension relies on a two-stage identifier: a 105 Transceiver Type, allowing to summarize the set of capabilities and 106 consistently correlate both ends of a given optical channel, and a 107 Transceiver ModeID, i.e. a hardware-related identifier to be 108 interpreted within the Type context. The second extension replaces 109 the aforementioned ModeID by a set of optical parameters. In the 110 latter, the exact list of fields will follow 111 [I-D.ietf-ccamp-dwdm-if-param-yang] 113 2. Main Use Cases 115 In the following section, it is assumed that, to be able to meet 116 optical performance requirements, the Routing and Wavelength 117 Assignment (RWA) tasks are performed before the signaling messages 118 leave the ingress ROADM. This could happen in various ways, provided 119 the network topology is available, including optical parameters 120 (e.g., advertised using [I-D.ietf-ccamp-wson-iv-encode]). This 121 includes ROADM-local computation process, passive PCE responding to 122 the ingress ROADM's request [I-D.ietf-pce-wson-rwa-ext]), as well 123 centralized controllers relying on PCEP to trigger the RSVP-TE 124 signaling in the ingress node ([RFC8281]). 126 2.1. Single Control Domain 128 We consider that transceivers are in the same control domain as the 129 optical switches. In many deployments, transceivers are embedded in 130 the edge ROADM shelves, where both the transceiver and the optical 131 switching are configured by the same set of local control processes. 132 In this case, carrying the Mode parameter in RSVP-TE signaling is 133 required to configure the egress side of the signaling session. Even 134 though some receiver implementations may be able to detect the 135 modulation format without configuration, most operational deployments 136 rely on bidirectional signals, thus making the modulation information 137 a mandatory parameter to fully configure the egress transceiver in 138 most cases. 140 The specification below allows to address this use case. 142 2.2. Open Line Systems 144 We now consider that transceivers are installed in shelves 145 independant from the ROADMs. The set of ROADMs is referred to as the 146 "optical line", the shelves carrying the transceivers are named 147 "client devices". This use case is aligned with the problem 148 statement specified in [I-D.ietf-ccamp-dwdm-if-mng-ctrl-fwk] and is 149 consistent with [RFC7698]. 151 The network topology and the associated optical parameters are only 152 advertised among the ROADMs, part of the line system, i.e. the 153 topology information does not leak up to the transceiver shelves 154 (otherwise, that is a specific case of [[CREF1: Section 2.1]]). 155 Therefore, beyond the usual signaling features, the resulting 156 signaling messages serve 3 additional purposes: 158 o advertise the ingress Transceiver Type to the optical line, in 159 charge of the decision related to the optical path across the 160 network, 162 o convey the Transceiver Type up to the egress Transceiver, allowing 163 to check correct match between both ends (as in [[CREF2: 164 Section 2.1]]), 166 o inform transceivers at both ends about the Transceiver Mode 167 allocated by the optical line. 169 The specification below allows to address this use case. 171 3. Signaling Messages 173 The following sections specify the fields used in the RSVP-TE Path 174 and Resv messages to address the requirements above. 176 3.1. Encodings 178 This documents specifies two sub-TLVs. Both serve the same purpose, 179 with a different level of details: the transceiver mode is described 180 either using an identifier or a detailed set of parameters. As a 181 result, an RSVP-TE message SHOULD only carry one of the sub-TLV for a 182 given hop. In case several of the sub-TLVs below are included, the 183 first one takes precedence and the following ones are ignored. 185 3.1.1. WDM-Transceiver-ModeID Sub-TLV 187 This document introduces the WDM-Transceiver-ModeID sub-TLV so as to 188 carry the Transceiver Type and ModeID. It has the following format: 190 0 1 2 3 191 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 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | Type = TBD1 | Length = 16 | Reserved |AppID Type=TBD6| 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | OUI | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | OUI (cont'd) | ModeID | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | Tsv-Type | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 Application ID Type (8 bits): As per section 5 of 203 [I-D.ietf-ccamp-dwdm-if-lmp], this field allows to distinguish 204 between the possible encodings of the trailing "Application ID" 205 field. This specification defines a new Application ID Type (value 206 TBD6) that extends the "Proprietary" type and specifies specific 207 fields within the "value" bytes: 209 o the first 6 bytes of the Application Identifier must contain the 210 hexadecimal representation of an Organizationally Unique 211 Identifier (OUI); 213 o the following 2 bytes encode a ModeID; 215 o the last 4 bytes carry a Tsv-Type. 217 Tsv-Type (32 bits): A transponder-specific value allowing to identify 218 a compatible Tsv-Type at the remote end, and supporting a set of 219 optical ModeIDs. This value MUST be included by the ingress 220 transceiver, i.e. from the signaling first hop. 0 is a Reserved value 221 that MUST trigger a PathErr message in response, with Error Code 24 222 (Routing Problem) and Error Sub-code TBD3 ("Unsupported Tsv-Type"). 224 ModeID (16 bits): Within a given Tsv-Type, this ID allows to specify 225 how the transceiver should be configured among the set of options 226 supported by Tsv-Type; e.g. optical modulation format or baudrate. 227 The value 0 means that the sending device has not chosen a particular 228 ModeID and expects this information to be determined by a downstream 229 node (e.g., the edge ROADM of the optical line). If the Tsv-Type 230 resolves into a single ModeID, the ModeID field SHOULD use a non-zero 231 value and MAY be ignored. A transceiver receiving a ModeID with the 232 value 0 MAY select a mode based on local policies combined to other 233 signaling information, e.g. channel spectral width. 235 3.1.2. WDM-Tranceiver-Param Sub-TLV 237 This document introduces the WDM-Transceiver-Param sub-TLV so as to 238 carry the Transceiver Type identifier and the "detailed mode" 239 description, which is a subset of the ones specified in 240 [I-D.ietf-ccamp-dwdm-if-param-yang]. It is aligned on figure 3 in 241 [I-D.ggalimbe-ccamp-flexigrid-carrier-label] and has the following 242 format: 244 0 1 2 3 245 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 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | Type = TBD | Length = 20 | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | Modulation Format | Bits per Symbol | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | FEC-ID | Min OSNR Threshold | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | Baud-rate | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | Channel output power | Tsv-Type | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 Modulation Format: A codepoint identifying the modulation format of 259 the transceiver signal. Knowing this parameter is not mandatory to 260 perform an optical path computation, thus the value 0 is acceptable 261 within a successful signaling session. 263 Bits per Symbol (16 bits): A nonnegative integer specifying the 264 number of bits encoded per symbol value in case of hybrid modulation 265 format. It is an off-set with values from 0 to 127 to be applied to 266 the specified Modulation Format and indicates the mix between the 267 selected Modulation Format and its upper adjacent (e.g. QPSK + 63 268 bits per symbol indicates that there is a 50% MIX between QPSK and 269 8-QAM = 2.5 bits per symbol). If value = 0 the standard Modulation 270 Format is applied. 272 FEC-ID (16 bits): A codepoint identifying the Forward Error 273 Correction of the transceiver. 275 Min OSNR Threshold (16 bits): An integer specifying the minimum 276 accepted threshold for the Optical Signal-Noise Ratio in 0.1 nm. 278 Baud-rate (32 bits): A nonnegative integer specifying the number of 279 symbols per second. 281 Channel Ouput Power (16 bits): An integer specifying the signal power 282 coming out of the transceiver (in dB or W?). 284 Tsv-Type (16 bits): A transponder-specific value allowing to identify 285 a compatible Tsv-Type at the remote end. This field MAY be set to 0, 286 which is a reserved value to disable Tsv-Type checking between end 287 transceivers (e.g. because it is useless). 289 3.2. Processing 291 3.2.1. Downstream Direction 293 The parameters to be used by the egress transceivers are carried in 294 Path messages. In RSVP-TE signaling, hop-specific information is 295 encoded within the ERO as hop attributes and WDM parameters are to be 296 carried as sub-TLVs within the Type 4 TLV of the Hop Attribute 297 subobject [RFC7689]. 299 When sending a Path message, if a signaling head end node includes 300 one of the WDM-Transceiver sub-TLVs specified in this document, the 301 entity in charge of the path computation (e.g. the ingress ROADM) 302 MUST include (unless an error is raised), as part of the ERO 303 population step, the same sub-TLV to specify the Hop Attibutes of the 304 tail end transceiver, allowing this information to be propagated 305 along the RSVP-TE Path messages. 307 A signaling head end node sending a Path message including one of the 308 WDM-Transceiver sub-TLVs specified in the previous section with 309 unallocated values, i.e. Mode-defining fields set to 0 (e.g. "ModeID 310 = 0" in the WDM-Transceiver-ModeID sub-TLV), MUST include an empty 311 RRO to request its population by some downstream nodes [RFC3209]. In 312 case the Mode specification is fully defined before the first 313 signaling hop (e.g. operator-specified), the use of the RRO remains 314 OPTIONAL. 316 3.2.2. Upstream Direction 318 When the mode selection happens after the signaling has left the 319 signaling head node, which carries the ingress transceiver, the 320 selected value needs to be sent back to the head node. As specified 321 in [RFC7570], it can be included in the Record Route Object (RRO) 322 within RSVP-TE Resv messages. Starting from the fact that both end 323 transceivers share a common mode to properly set up a channel, this 324 leads to the following processing: 326 o After a transceiver shelf (signaling tail end or regenerator) has 327 received a Path message: 329 * If both an RRO and a WDM-Transceiver sub-TLV (defined above) 330 are included, the node MUST populate, in the responding Resv 331 message, the RRO with its own hop attributes, using the 332 corresponding sub-TLV. At this stage, the values of the Mode- 333 defining fields MUST be allocated, wherever the selection has 334 happened (e.g., ingress ROADM, local decision). 336 * If the Mode description is not supported, the node MUST respond 337 using a PathErr with Error Code 24 (Routing Problem) and Error 338 Sub-code TBD4 ("Unsupported Transceiver Mode"). 340 * If the values within the WDM-Transceiver sub-TLV are not 341 allocated and the node is unable to make a local allocation, it 342 MUST respond using a PathErr with Error Code 24 (Routing 343 Problem) and Error Sub-code TBD5 ("Unable to Select Transceiver 344 Mode") 346 o When a signaling head end node pending a mode information receives 347 a Resv message, it MUST look into the RRO and configure itself 348 consistently with the hop attribute information associated to the 349 remote transceiver. A signaling head node receiving an 350 inconsistent Mode (unupported or not matching the corresponding 351 Path state) MUST respond using a ResvErr with Error Code 24 352 (Routing Problem) and Error Sub-code TBD4 ("Unsupported 353 Transceiver Mode"). 355 4. IANA Considerations 357 The IANA is requested to allocate, from the "Sub-TLV Types for WSON 358 Processing Hop Attribute TLV" section within the "RSVP-TE Parameters" 359 registry: 361 +-------+------------------------+------------+ 362 | Value | Meaning | Reference | 363 +-------+------------------------+------------+ 364 | TDB1 | WDM-Transceiver-ModeID | [This I-D] | 365 | TDB2 | WDM-Transceiver-Param | [This I-D] | 366 +-------+------------------------+------------+ 368 The IANA is requested to allocate, from the "Error Codes and 369 Globally-Defined Error Value Sub-Codes" section within the "RSVP 370 Parameters" registry: 372 +-----------+----------+-------------------------------+------------+ 373 | Error | Sub-code | Meaning | Reference | 374 | Code | | | | 375 +-----------+----------+-------------------------------+------------+ 376 | 24 | TBD3 | Unsupported Tsv-Type | [This I-D] | 377 | | TBD4 | Unsupported Transceiver Mode | [This I-D] | 378 | | TBD5 | Unable to Select Transceiver | [This I-D] | 379 | | | Mode | | 380 +-----------+----------+-------------------------------+------------+ 382 The IANA is requested to create, within the "GMPLS Signaling 383 Parameters" registry, two new sub-registries named "WDM Modulation 384 Formats" and "WDM FEC Types". 386 For both of them: 388 o the value 0 means "Pending selection", 390 o the range 1-65503 follows the Expert Review policy for 391 registration, 393 o the range 65504-65535 is for experimental use. 395 The "WDM Modulation Format" sub-registry is initialized as follows: 397 +-------------+---------------------+ 398 | Value | Modulation Format | 399 +-------------+---------------------+ 400 | 0 | Pending selection | 401 | 1 | QPSK | 402 | 2 | 8-QAM | 403 | 3 | 16-QAM | 404 | 4 | 32-QAM | 405 | 5 | 64-QAM | 406 | 6-63999 | Unallocated | 407 | 64000-65535 | Vendor-specific use | 408 +-------------+---------------------+ 410 The "WDM FEC Types" sub-registry is initialized as follows: 412 +-------------+---------------------+ 413 | Value | FEC Types | 414 +-------------+---------------------+ 415 | 0 | Pending selection | 416 | 1 | Reed Solomon FEC | 417 | 2 | Staircase FEC | 418 | 3 | O-FEC | 419 | 4-63999 | Unallocated | 420 | 64000-65535 | Vendor-specific use | 421 +-------------+---------------------+ 423 The IANA is requested to allocate, from the "Application ID Type" 424 section within the "LMP" registry: 426 +------+-------------------------+------------------------------+ 427 | Type | Meaning | Reference | 428 +------+-------------------------+------------------------------+ 429 | TBA | G.698.2 | [I-D.ietf-ccamp-dwdm-if-lmp] | 430 | TBA | OUI + proprietary value | [I-D.ietf-ccamp-dwdm-if-lmp] | 431 | TBD6 | OUI + Tsv-Type + ModeID | [This document] | 432 +------+-------------------------+------------------------------+ 434 5. Security Considerations 436 This specification only adds TLVs to RSVP-TE signaling messages. As 437 a result, it relies on security guidelines documented in [RFC5920]. 439 6. Acknowledgements 441 The authors would like to thank Ramon Casellas for his valuable 442 feedback on the work related to this document. 444 7. References 446 7.1. Normative References 448 [I-D.ggalimbe-ccamp-flexigrid-carrier-label] 449 Galimberti, G., Fauci, D., Zanardi, A., and L. Galvagni, 450 "Signaling extensions for Media Channel sub-carriers 451 configuration in Spectrum Switched Optical Networks (SSON) 452 in Lambda Switch Capable (LSC) Optical Line Systems.", 453 draft-ggalimbe-ccamp-flexigrid-carrier-label-08 (work in 454 progress), November 2019. 456 [I-D.ietf-ccamp-dwdm-if-lmp] 457 Hiremagalur, D., Grammel, G., Galimberti, G., Kunze, R., 458 and D. Beller, "Extension to the Link Management Protocol 459 (LMP/DWDM -rfc4209) for Dense Wavelength Division 460 Multiplexing (DWDM) Optical Line Systems to manage the 461 application code of optical interface parameters in DWDM 462 application", draft-ietf-ccamp-dwdm-if-lmp-01 (work in 463 progress), November 2019. 465 [I-D.ietf-pce-wson-rwa-ext] 466 Lee, Y. and R. Casellas, "PCEP Extension for WSON Routing 467 and Wavelength Assignment", draft-ietf-pce-wson-rwa-ext-17 468 (work in progress), March 2019. 470 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 471 Requirement Levels", BCP 14, RFC 2119, 472 DOI 10.17487/RFC2119, March 1997, 473 . 475 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 476 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 477 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 478 . 480 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 481 Switching (GMPLS) Signaling Resource ReserVation Protocol- 482 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 483 DOI 10.17487/RFC3473, January 2003, 484 . 486 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 487 Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, 488 . 490 [RFC7570] Margaria, C., Ed., Martinelli, G., Balls, S., and B. 491 Wright, "Label Switched Path (LSP) Attribute in the 492 Explicit Route Object (ERO)", RFC 7570, 493 DOI 10.17487/RFC7570, July 2015, 494 . 496 [RFC7689] Bernstein, G., Ed., Xu, S., Lee, Y., Ed., Martinelli, G., 497 and H. Harai, "Signaling Extensions for Wavelength 498 Switched Optical Networks", RFC 7689, 499 DOI 10.17487/RFC7689, November 2015, 500 . 502 [RFC7792] Zhang, F., Zhang, X., Farrel, A., Gonzalez de Dios, O., 503 and D. Ceccarelli, "RSVP-TE Signaling Extensions in 504 Support of Flexi-Grid Dense Wavelength Division 505 Multiplexing (DWDM) Networks", RFC 7792, 506 DOI 10.17487/RFC7792, March 2016, 507 . 509 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 510 Computation Element Communication Protocol (PCEP) 511 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 512 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 513 . 515 7.2. Informative References 517 [I-D.ietf-ccamp-dwdm-if-mng-ctrl-fwk] 518 Kunze, R., Grammel, G., Beller, D., Galimberti, G., and J. 519 Meuric, "A framework for Management and Control of DWDM 520 optical interface parameters", draft-ietf-ccamp-dwdm-if- 521 mng-ctrl-fwk-13 (work in progress), July 2019. 523 [I-D.ietf-ccamp-dwdm-if-param-yang] 524 Galimberti, G., Kunze, R., Hiremagalur, D., and G. 525 Grammel, "A YANG model to manage the optical interface 526 parameters for an external transponder in a WDM network", 527 draft-ietf-ccamp-dwdm-if-param-yang-02 (work in progress), 528 November 2019. 530 [I-D.ietf-ccamp-wson-iv-encode] 531 Martinelli, G., Lee, Y., Galimberti, G., and F. Zhang, 532 "Information Encoding for WSON with Impairments 533 Validation", draft-ietf-ccamp-wson-iv-encode-02 (work in 534 progress), January 2019. 536 [RFC7698] Gonzalez de Dios, O., Ed., Casellas, R., Ed., Zhang, F., 537 Fu, X., Ceccarelli, D., and I. Hussain, "Framework and 538 Requirements for GMPLS-Based Control of Flexi-Grid Dense 539 Wavelength Division Multiplexing (DWDM) Networks", 540 RFC 7698, DOI 10.17487/RFC7698, November 2015, 541 . 543 Authors' Addresses 544 Julien Meuric (editor) 545 Orange 546 2 avenue Pierre Marzin 547 Lannion 22300 548 France 550 Email: julien.meuric@orange.com 552 Esther Le Rouzic 553 Orange 554 2 avenue Pierre Marzin 555 Lannion 22300 556 France 558 Email: esther.lerouzic@orange.com 560 Luay Alahdab 561 Individual 562 Lannion 22300 563 France 565 Email: luayahdab@gmail.com 567 Gabriele Galimberti 568 Cisco 569 Via S. Maria Molgora, 48 c 570 Vimercate 20871 571 Italy 573 Email: ggalimbe@cisco.com