idnits 2.17.1 draft-ggalimbe-ccamp-flexigrid-carrier-label-03.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 abstract seems to contain references ([ITU.G872], [ITU.G694.1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (March 1, 2018) is 2247 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'ITU.G698.2' is defined on line 526, but no explicit reference was found in the text == Unused Reference: 'ITU.G709' is defined on line 532, but no explicit reference was found in the text == Unused Reference: 'ITU.G874.1' is defined on line 542, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 548, but no explicit reference was found in the text == Unused Reference: 'RFC3473' is defined on line 553, but no explicit reference was found in the text == Unused Reference: 'RFC3945' is defined on line 559, but no explicit reference was found in the text == Unused Reference: 'RFC5920' is defined on line 571, but no explicit reference was found in the text == Unused Reference: 'RFC6163' is defined on line 575, but no explicit reference was found in the text == Unused Reference: 'RFC7699' is defined on line 593, but no explicit reference was found in the text == Unused Reference: 'RFC2629' is defined on line 607, but no explicit reference was found in the text == Unused Reference: 'RFC3410' is defined on line 611, but no explicit reference was found in the text == Unused Reference: 'RFC4181' is defined on line 617, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 1 error (**), 0 flaws (~~), 14 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force G. Galimberti, Ed. 3 Internet-Draft D. La Fauci 4 Intended status: Experimental Cisco 5 Expires: September 2, 2018 A. Zanardi, Ed. 6 L. Galvagni 7 FBK-CreateNet 8 March 1, 2018 10 Signaling extensions for Media Channel sub-carriers configuration in 11 Spectrum Switched Optical Networks (SSON) in Lambda Switch Capable (LSC) 12 Optical Line Systems. 13 draft-ggalimbe-ccamp-flexigrid-carrier-label-03 15 Abstract 17 This memo defines the signaling extensions for managing Spectrum 18 Switched Optical Network (SSON) parameters shared between the Client 19 and the Network and inside the Network in accordance to the model 20 described in RFC 7698. The extensions are in accordance and 21 extending the parameters defined in ITU-T Recommendation 22 G.694.1.[ITU.G694.1] and its extensions and G.872.[ITU.G872]. 24 Copyright Notice 26 Copyright (c) 2011 IETF Trust and the persons identified as the 27 document authors. All rights reserved. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on September 2, 2018. 46 Copyright Notice 48 Copyright (c) 2018 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 (https://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 respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Client interface parameters . . . . . . . . . . . . . . . . . 3 65 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 4. Signalling Extensions . . . . . . . . . . . . . . . . . . . . 5 67 4.1. New LSP set-up parameters . . . . . . . . . . . . . . . . 5 68 4.2. Extension to LSP set-up reservation . . . . . . . . . . . 7 69 4.3. RSVP Protocol Extensions considerations . . . . . . . . . 12 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 72 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13 73 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 74 8.1. Normative References . . . . . . . . . . . . . . . . . . 13 75 8.2. Informative References . . . . . . . . . . . . . . . . . 15 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 78 1. Introduction 80 Generalised Multiprotocol Label Switched (GMPLS) is widely used in 81 Wavelength Switched Optical Network (WSON) to support the optical 82 circuits set-up through the signalling between Core Nodes and Edge 83 Nodes. This extension addresses the use cases described by [RFC7698] 84 Ch.3.3 and supports the information, needed in Spectrum Switched 85 Optical Network (SSON), to signal a Media Channel and the associated 86 carriers set request. The new set of parameters is related to the 87 Media Channel and the carrier(s) routed with it and keep the backward 88 compatibility with the WSON signalling. In particular this memo 89 wants do address the use cases where the SSON LSP (the Media Channel 90 in RFC7698) carries multiple carrier (OTSi) containing same Payload. 91 The set of the carriers can be seen as single Logical circuit. This 92 memo can be considered as the extension of [RFC7792]. The contents 93 and the parameters reflect the experimental activity on IP over SSON 94 recently done by some vendors and research consortia. 96 Figure 1 shows how the multiple carrier are mapped into a Media 97 Channel. A set of parameters must be shared on the UNI to allow the 98 GMPLS to do the proper routing and Spectrum Assignment and decide the 99 carrier position. 101 +------+ +------+ _________ +------+ +------+ 102 | E.N. | | C.N. | / /\ | C.N. | | E.N. | 103 | OTS1| ----- | || | || | ----- |OTS1 | 104 ==| OTS2| ----- | || Media | || | ----- |OTS2 |== 105 ==| OTS3| ----- | || Channel| || | ----- |OTS3 |== 106 | OTS4| ----- | || | || | ----- |OTS4 | 107 | | | ROADM| \________\/ | ROADM| | | 108 +------+ +------+ +------+ +------+ 109 ^ ^ ^ ^ 110 | | | | 111 +---UNI---+ +---UNI---+ 113 E.N. = Edge Node - UNI Client 114 C.N. = Core Node - UNI Network 115 ROADM = Lambda/Spectrum switch 116 Media Channel = the optical circuit 117 OTSi = Carriers belonging to the same Network Media Channel (or 118 Super Channel) 119 UNI = Signalig interface 121 Figure 1: Multi carrier LSP 123 2. Client interface parameters 125 The Edge Node interface can have one or multiple carriers (OTSi). 126 All the carrier have the same characteristics and are provisionable 127 in terms of: 129 Number of subcarriers: 130 This parameter indicates the number of subcarriers available for 131 the super-channel in case the Transceiver can support multiple 132 carrier circuits. 134 Central frequency (see G.694.1 Table 1): 135 This parameter indicates the Central frequency value that Ss and 136 Rs will be set to work (in THz). See the details in Section 6/ 137 G.694.1 or based on "n" value explanation and the following "k" 138 values definition in case of multicarrier transceivers. 140 Central frequency granularity: 141 This parameter indicates the Central frequency granularity 142 supported by the transceiver, this value is combined with k and n 143 value to calculate the central frequency of the carrier or sub- 144 carriers. 146 Minimum channel spacing: 147 This is the minimum nominal difference in frequency (in GHz) 148 between two adjacent channels (or carriers) depending on the 149 Transceiver characteristics. 151 Bit rate / Baud rate of optical tributary signals: 152 Optical Tributary Signal bit (for NRZ signals) rate or Symbol (for 153 Multiple bit per symbol) rate . 155 FEC Coding: 156 This parameter indicate what Forward Error Correction (FEC) code 157 is used at Ss and Rs (R/W) (not mentioned in G.698.2). . 159 Wavelength Range (see G.694.1): [ITU.G694.1] 160 This parameter indicate minimum and maximum wavelength spectrum in 161 a definite wavelength Band (L, C and S). 163 Modulation format: 164 This parameter indicates the list of supported Modulation Formats 165 and the provisioned Modulation Format.. 167 Inter carrier skew: 168 This parameter indicates, in case of multi-carrier transceivers 169 the maximum skew between the sub-carriers supported by the 170 transceiver. 172 Laser Output power: 173 This parameter provisions the Transceiver Output power, it can be 174 either a setting and measured value. 176 receiver input power: 177 This parameter provisions the Min and MAX input pover suppotred by 178 the Transceiver, i.e. Receiver Sensitivity. 180 The above parameters are related to the Edge Node Transceiver and are 181 used by the Core Network GMPLS in order to calculate the optical 182 feasibility and the spectrum allocation. The parameters can be 183 shared between the Client and the Network via LMP or provisioned to 184 the Network by an EMS or an operator OSS. 186 3. Use Cases 188 The use cases are described in draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk 189 and [RFC7698] 191 4. Signalling Extensions 193 Some of the above parameters can be applied to RFC7792 (SENDER_TSPEC/ 194 FLOWSPEC). The above parameters could be applied to [RFC4208] 195 scenarios but they are valid also in case of non UNI scenarios. The 196 [RFC6205] parameters remain valid. 198 4.1. New LSP set-up parameters 200 When the E.N. wants to request to the C.N. a new circuit set-up 201 request or the GMPLS wants to signal in the SSON network the Optical 202 Interface characteristics the following parameters will be provided 203 to the C.N.: 205 Number of available subcarriers (c): 206 This parameter is an integer and identifies the number of Client 207 ports connected to the Core ports available to suport the 208 requested circuit 210 Total bandwidth request: 211 e.g. 200Gb, 400Gb, 1Tb - it is the bandwidth (payload) to be 212 carried by the multiple carrier circuit 214 Policy (strict/loose): 215 Strict/loose referred to B/W and subcarrier number. This is to 216 give some flexibility to the GMPLS in order to commit client 217 request. 219 Subcarrier bandwidth tunability: 220 (optional) e.g. 34Ghz, 48GHz. 222 Figure 2: The format of the this sub-object is as follows: 224 The TLV define the resource constraints for the requested Media 225 Channel. 227 0 1 2 3 228 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 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 |S|B| Reserved | Carrier Number | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | Total Bandwidth | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 Figure 2: SSON LSP set-up request 237 Carrier Number: number of carrier to be allocated for the requested 238 channel (16-bit unsigned integer) 239 If Carrier Number == 0 no constraint set on the number of 240 carriers to be used 242 S strict number of subcarrier 243 - S = 0 the number of requested carriers is the maximum number 244 that can be allocated (a lower value can be allocated if 245 the requested bandwidth is satisfied) 246 - S = 1 the number of requested carriers is strict (must be > 0) 248 Total Bandwidth: the requested total bandwidth to be supported by 249 the Media Channel (32-bit IEEE float, bytes/s) 250 If Total Bandwidth == 0: no bandwidth constraint is defined 251 (B must be 0) 253 B Bandwidth constraints 254 - B = 0: the value is the maximum requested bandwidth (a lower 255 value can be allocated if resources are not available) 256 - B = 1: the requested bandwidth is the minimum value to be 257 allocated (a higher value can be allocated if requested 258 by the physical constraints of the ports) 260 Reserved: unused bit (for future use, should be 0) 262 Note: bandwidth unit is defined in accordance to RFC 3471 263 chap. 3.1.2 Bandwith Encoding specification. Bandwidth higher 264 than 40Gb/s values must be defined (e.g. 100Gb/s, 150Gb/s 265 400Gb/s, etc.) 267 TLV Usage: 268 Head UNI-C PATH: requested traffic constraints, the Head UNI-N node 269 must satisfy when reserving the optical resources and defining 270 the carriers configuration 271 The TLV can be omitted: no traffic constraints is defined (resources 272 allocated by UNI-N based on a local policy) 274 4.2. Extension to LSP set-up reservation 276 Once the GMPLS has calculated the Media Channel path, the Spectrum 277 Allocation, the Sub-carrier number and frequency, the modulation 278 format, the FEC and the Transmit power, sends back to the E.N. the 279 path set-up confirmation providing the values of the calculated 280 paramenters: 282 Media Channel: 283 (Grid, C.S., Identifier m and n). as indicated in RFC7699 284 Section 4.1 286 Modulation format: 287 This parameter indicates the Modulation Formats to be set in the 288 Transceivers. 290 FEC Coding: 291 This parameter indicate what Forward Error Correction (FEC) code 292 must be used by the Transceivers (not mentioned in G.698). . 294 Bit rate / Baud rate of optical tributary signals: 295 Optical tributary signal bit (for NRZ signals) rate or Symbol (for 296 Multiple bit per symbol) rate. 298 List of subcarriers: 299 This parameter indicates the subcarriers to be used for the super- 300 channel in case the Transceiver can support multiple carrier 301 Circuits. 303 Central frequency granularity (J): 304 This parameter indicates the Central frequency granularity 305 supported by the transceiver, this value is combined with K and n 306 value to calculate the central frequency on the carrier or sub- 307 carriers. 309 Central frequency (see G.694.1 Table 1): 310 Grid, Identifiers, central frequency and granularity. 312 Laser Output power: 313 This parameter provisions the Transceiver Output power, it can be 314 either a setting and measured value. 316 Circuit Path, RRO, etc: 317 All these info are defined in [RFC4208]. 319 Path Error: 320 e.g. no path exist, all the path error defined in [RFC4208]. 322 Figure 3: The format of this sub-object (Type = TBA, Length = TBA) is 323 as follows: 325 The TLV defines the carriers signal configuration. 326 All carriers in a Media Channel MUST have the same configuration. 328 0 1 2 3 329 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 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | Modulation Format | FEC | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | baud rate (Symbol Rate) | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 Figure 3: OCh_General 338 Traffic Type 339 - Modulation Format: is the modulation type: 340 BPSK, DC DP BSPSK, QPSK, DP QPSK, 8QAM, 16QAM, 64QAM, 341 Hybrid, etc. 342 - (ITU-T reference) 343 - value > 32768 (first bit is 1): custom defined values 344 Value 0 is reserved to be used if no value is defined 345 - FEC: the signal Forward Error Corrections type (16-bit 346 unsigned integer), the defined values are: 347 - (ITU-T reference) 348 - 32768 (first bit is 1): custom defined values 349 Value 0 is reserved to be used if no value is defined 350 - Baud Rate: the signal symbol rate (IEEE 32-bit float, 351 in bauds/s) 352 Value 0 is reserved to be used if no value is defined 354 Notes: 355 - The request from the Head UNI-C node can specify only a subset 356 of the parameters (e.g. the Modulation and the baud rate but 357 not the FEC) but setting to 0 the undefined parameters. 358 - Custom codes (values > 0x8000) interpretation is a local 359 installation matter. 361 TLV Usage: 362 - Head UNI-C PATH: used to force specific transponder 363 configurations 364 - Head UNI-N RESV: set selected configuration on head node 365 - Tail UNI-N PATH: set selected configuration on tail node 367 Figure 4: The format of this sub-object (Type = TBA, Length = TBA) is 368 as follows: 370 For Each carrier inside the Media Channel the TLV is used: 372 0 1 2 3 373 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 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | Carrier Identifier | j | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | k | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | sub-TLVs | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 Figure 4: Sub-Carrier parameters 384 Carrier set-up: 386 - Carrier identifier field: sub-carrier 387 identifier inside the mediachannel. Identifies the carrier 388 position inside the Media Channel (16-bit unsigned integer) 389 - J field: granularity of the channel spacing, can be a 390 multiple of 0.01GHz. - default value is 0.1GHz. 391 - K field: positive or negative integer (including 0) to multiply 392 by J and identify the Carrier Position inside the 393 Media Channel, offset from media Channel Central frequency 394 - sub-TLVs: additional information related to carriers if needed. 396 In summary Carrier Frequency = MC-C.F. (in THz) + K * J GHz 398 m=8 399 +-------------------------------X------------------------------+ 400 | | | 401 | sub-carrier sub-carrier | 402 | +----------X----------+ | +----------X----------+ | 403 | | OTSi | | OTSi | | 404 | | o | | | o | | 405 | | | | | | | | 406 -4 -3 -2 -1 0 1 2 3 4 5 6 7 8 9 10 11 12 407 --+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+- 408 | n=4 | 409 K1 -236 | +236 K2 411 <------------------------ Media Channel -----------------------> 413 Figure 5: The format of this sub-object (Type = TBA, Length = TBD) is 414 as follows: 416 The defined sub-TLVs are: 418 Port Identifier 420 0 1 2 3 421 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 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | Type (TBA) | Length (TBD) | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | Port Identifier | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 Figure 5: Port Identifier 430 Port Identifier: the local upstream optical logical identifier 431 (32-bits integer, ifindex) 433 Notes: 434 - The Carrier Identifier is the logical circuit sub-lane position, 435 a TLV for each value from 1 to the number of allocated carriers 436 must be present. 438 - The association of a carrier to a local link optical port is a 439 local link association (depending on the local ports physical 440 configuration), the sub-TLV value MUST be set by head/tail nodes 441 (with transit nodes not signaling its value). 442 The local port identifier is the identifier of the local link 443 port on the upstream node (with respect to the LSP nominal 444 direction): 445 - UNI-C port in head UNI link 446 - UNI-N port in tail UNI link 448 TLV Usage: 449 - Head UNI-C PATH: used to force specific carrier frequency/ports 450 [optional use, e.g. with external PCE scenario] 451 - Head UNI-N RESV: set selected configuration on head node 452 - Tail UNI-N PATH: set selected configuration on tail node 454 Figure 6: The format of this sub-object (Type = TBA, Length = TBD) is 455 as follows: 457 Carrier Power: 459 0 1 2 3 460 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 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | Type (TBA) | Length (TBD) | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | carrier power | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 Figure 6: Carrier Power 469 Carrier Power: the requested carrier transmit power (32-bits IEEE 470 Float, dBm), optionally used to notify the configured 471 power (in UNI client side) or force the power to the 472 to the UNI client). 474 TLV Usage: 475 - Head UNI-C PATH: used to force specific carrier frequency/ports 476 (optional use, e.g. with external PCE scenario) 477 - Head UNI-N RESV: set selected configuration on head node 478 - Tail UNI-N PATH: set selected configuration on tail node 480 4.3. RSVP Protocol Extensions considerations 482 The additional information described in the draft, is related to the 483 Media Channel supported traffic. It could be encoded in the 484 SENDER_TSPEC/FLOW_SPEC objects by extending the SSON_SENDER_TSPEC/ 485 SSON_FLOW_SPEC defined in RFC 7792 (or defining a new C-Type) with an 486 optional TLV list or it could be encoded in a newly defined entry 487 (new OBJECT or new LSP_ATTRIBUTES OBJECT TLV) 489 This solution is consistent with other technology specific extensions 490 (e.g. SDH), but requires the explicit handling of the extensions by 491 all nodes. 493 Beside this, some of the additional information defined is local to 494 the head/tail UNI link (e.g. the carrier/port association), while the 495 traffic spec info should be valid end-to-end. 497 5. Security Considerations 499 GMPLS message security uses IPsec, as described in xxxx. This 500 document only defines new UNI objects that are carried in existing 501 UNI messages, similar to the UNI objects in xxx. This document does 502 not introduce new security considerations. 504 6. IANA Considerations 506 T.B.D. 508 7. Contributors 510 Antonello Bonfanti 511 Cisco 512 Via Santa Maria Molgora, 48 c 513 20871 - Vimercate (MB) 514 Italy 515 abonfant@cisco.com 517 8. References 519 8.1. Normative References 521 [ITU.G694.1] 522 International Telecommunications Union, ""Spectral grids 523 for WDM applications: DWDM frequency grid"", 524 ITU-T Recommendation G.698.2, February 2012. 526 [ITU.G698.2] 527 International Telecommunications Union, "Amplified 528 multichannel dense wavelength division multiplexing 529 applications with single channel optical interfaces", 530 ITU-T Recommendation G.698.2, November 2009. 532 [ITU.G709] 533 International Telecommunications Union, "Interface for the 534 Optical Transport Network (OTN)", ITU-T Recommendation 535 G.709, February 2012. 537 [ITU.G872] 538 International Telecommunications Union, "Architecture of 539 optical transport networks", ITU-T Recommendation G.872, 540 October 2012. 542 [ITU.G874.1] 543 International Telecommunications Union, "Optical transport 544 network (OTN): Protocol-neutral management information 545 model for the network element view", ITU-T Recommendation 546 G.874.1, October 2012. 548 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 549 Requirement Levels", BCP 14, RFC 2119, 550 DOI 10.17487/RFC2119, March 1997, 551 . 553 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 554 Switching (GMPLS) Signaling Resource ReserVation Protocol- 555 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 556 DOI 10.17487/RFC3473, January 2003, 557 . 559 [RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label 560 Switching (GMPLS) Architecture", RFC 3945, 561 DOI 10.17487/RFC3945, October 2004, 562 . 564 [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, 565 "Generalized Multiprotocol Label Switching (GMPLS) User- 566 Network Interface (UNI): Resource ReserVation Protocol- 567 Traffic Engineering (RSVP-TE) Support for the Overlay 568 Model", RFC 4208, DOI 10.17487/RFC4208, October 2005, 569 . 571 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 572 Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, 573 . 575 [RFC6163] Lee, Y., Ed., Bernstein, G., Ed., and W. Imajuku, 576 "Framework for GMPLS and Path Computation Element (PCE) 577 Control of Wavelength Switched Optical Networks (WSONs)", 578 RFC 6163, DOI 10.17487/RFC6163, April 2011, 579 . 581 [RFC6205] Otani, T., Ed. and D. Li, Ed., "Generalized Labels for 582 Lambda-Switch-Capable (LSC) Label Switching Routers", 583 RFC 6205, DOI 10.17487/RFC6205, March 2011, 584 . 586 [RFC7698] Gonzalez de Dios, O., Ed., Casellas, R., Ed., Zhang, F., 587 Fu, X., Ceccarelli, D., and I. Hussain, "Framework and 588 Requirements for GMPLS-Based Control of Flexi-Grid Dense 589 Wavelength Division Multiplexing (DWDM) Networks", 590 RFC 7698, DOI 10.17487/RFC7698, November 2015, 591 . 593 [RFC7699] Farrel, A., King, D., Li, Y., and F. Zhang, "Generalized 594 Labels for the Flexi-Grid in Lambda Switch Capable (LSC) 595 Label Switching Routers", RFC 7699, DOI 10.17487/RFC7699, 596 November 2015, . 598 [RFC7792] Zhang, F., Zhang, X., Farrel, A., Gonzalez de Dios, O., 599 and D. Ceccarelli, "RSVP-TE Signaling Extensions in 600 Support of Flexi-Grid Dense Wavelength Division 601 Multiplexing (DWDM) Networks", RFC 7792, 602 DOI 10.17487/RFC7792, March 2016, 603 . 605 8.2. Informative References 607 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 608 DOI 10.17487/RFC2629, June 1999, 609 . 611 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 612 "Introduction and Applicability Statements for Internet- 613 Standard Management Framework", RFC 3410, 614 DOI 10.17487/RFC3410, December 2002, 615 . 617 [RFC4181] Heard, C., Ed., "Guidelines for Authors and Reviewers of 618 MIB Documents", BCP 111, RFC 4181, DOI 10.17487/RFC4181, 619 September 2005, . 621 Authors' Addresses 623 Gabriele Galimberti (editor) 624 Cisco 625 Via S. Maria Molgora, 48 c 626 20871 - Vimercate 627 Italy 629 Phone: +390392091462 630 Email: ggalimbe@cisco.com 631 Domenico La Fauci 632 Cisco 633 Via S. Maria Molgora, 48 c 634 20871 - Vimercate 635 Italy 637 Phone: +390392091946 638 Email: dlafauci@cisco.com 640 Andrea Zanardi (editor) 641 FBK-CreateNet 642 via alla Cascata 56/D 643 38123 Povo, Trento 644 Italy 646 Phone: +390461312450 647 Email: azanardi@fbk.eu 649 Lorenzo Galvagni 650 FBK-CreateNet 651 via alla Cascata 56/D 652 38123 Povo, Trento 653 Italy 655 Phone: +390461312427 656 Email: lgalvagni@fbk.eu