idnits 2.17.1 draft-ggalimbe-ccamp-flexigrid-carrier-label-09.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 ([RFC7698], [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 6, 2020) is 1511 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'G.959.1' is mentioned on line 137, but not defined == Missing Reference: 'G.709' is mentioned on line 138, but not defined == Missing Reference: 'G.807' is mentioned on line 143, but not defined == Missing Reference: 'RFC7689' is mentioned on line 536, but not defined == Unused Reference: 'ITU.G698.2' is defined on line 663, but no explicit reference was found in the text == Unused Reference: 'ITU.G709' is defined on line 669, but no explicit reference was found in the text == Unused Reference: 'ITU.G874.1' is defined on line 679, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 685, but no explicit reference was found in the text == Unused Reference: 'RFC3473' is defined on line 690, but no explicit reference was found in the text == Unused Reference: 'RFC3945' is defined on line 696, but no explicit reference was found in the text == Unused Reference: 'RFC6163' is defined on line 712, but no explicit reference was found in the text == Unused Reference: 'RFC6205' is defined on line 718, but no explicit reference was found in the text == Unused Reference: 'RFC2629' is defined on line 744, but no explicit reference was found in the text == Unused Reference: 'RFC3410' is defined on line 748, but no explicit reference was found in the text == Unused Reference: 'RFC4181' is defined on line 754, 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 (~~), 17 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 7, 2020 A. Zanardi, Ed. 6 L. Galvagni 7 FBK 8 J. Meuric 9 Orange 10 March 6, 2020 12 Signaling extensions for Media Channel sub-carriers configuration in 13 Spectrum Switched Optical Networks (SSON) in Lambda Switch Capable (LSC) 14 Optical Line Systems. 15 draft-ggalimbe-ccamp-flexigrid-carrier-label-09 17 Abstract 19 This memo defines the signaling extensions for managing Spectrum 20 Switched Optical Network (SSON) parameters shared between the Client 21 and the Network and inside the Network in accordance to the model 22 described in [RFC7698]. The extensions are in accordance and 23 extending the parameters defined in ITU-T Recommendation 24 G.694.1.[ITU.G694.1] and its extensions and G.872.[ITU.G872]. 26 Copyright Notice 28 Copyright (c) 2011 IETF Trust and the persons identified as the 29 document authors. All rights reserved. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on September 7, 2020. 48 Copyright Notice 50 Copyright (c) 2020 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Client interface parameters . . . . . . . . . . . . . . . . . 3 67 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 4. Signalling Extensions . . . . . . . . . . . . . . . . . . . . 5 69 4.1. New LSP Request Parameters . . . . . . . . . . . . . . . 5 70 4.2. Extension to LSP set-up specification . . . . . . . . . . 7 71 4.2.1. Common Signal Description TLV . . . . . . . . . . . . 8 72 4.2.2. Sub-carrier List Content TLV . . . . . . . . . . . . 9 73 4.2.3. Sub-carrier sub-TLV . . . . . . . . . . . . . . . . . 11 74 4.3. RSVP Protocol Extensions Considerations . . . . . . . . . 13 75 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 76 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 77 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 79 8.1. Normative References . . . . . . . . . . . . . . . . . . 17 80 8.2. Informative References . . . . . . . . . . . . . . . . . 19 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 83 1. Introduction 85 Generalized Multiprotocol Label Switching (GMPLS) is widely used in 86 Wavelength Switched Optical Network (WSON) to support the optical 87 circuit set-up through the signalling between Core Nodes and Edge 88 Nodes (reusing terminology from [RFC4208. This extension addresses 89 the use cases described by [RFC7698] Ch.3.3 and supports the 90 information, needed in Spectrum Switched Optical Network (SSON), to 91 signal a Media Channel and the associated carriers set request. The 92 new set of parameters is related to the Media Channel and the 93 carrier(s) routed with it and keep the backward compatibility with 94 the WSON signalling. In particular this memo addresses the use cases 95 where the SSON LSP (the Media Channel in RFC7698) use multiple 96 carrier (OTSi) to carry the Payload. The set of the carriers can be 97 seen as single Logical circuit. This memo can be considered as the 98 extension of [RFC7792]. 100 Figure 1 shows how the multiple carrier are mapped into a Media 101 Channel. A set of parameters must be shared on the UNI to allow the 102 core control plane to do the proper routing and Spectrum Assignment 103 and decide the carrier position. 105 +------+ +------+ _________ +------+ +------+ 106 | E.N. | | C.N. | / /\ | C.N. | | E.N. | 107 | OTS1| ----- | || | || | ----- |OTS1 | 108 ==| OTS2| ----- | || Media | || | ----- |OTS2 |== 109 ==| OTS3| ----- | || Channel| || | ----- |OTS3 |== 110 | OTS4| ----- | || | || | ----- |OTS4 | 111 | | | ROADM| \________\/ | ROADM| | | 112 +------+ +------+ +------+ +------+ 113 ^ ^ ^ ^ 114 | | | | 115 +---UNI---+ +---UNI---+ 117 E.N. = Edge Node (a.k.a. UNI Client / transceiver shelf) 118 C.N. = Core Node (a.k.a. UNI Network / edge ROADM) 119 ROADM = Lambda/Spectrum switch 120 Media Channel = the optical circuit 121 OTSi = Carriers belonging to the same Network Media Channel (or 122 Super Channel) 123 UNI = Signallig interface between E.N. and C.N. 125 Figure 1: Multi carrier LSP 127 2. Client interface parameters 129 The Edge Node interface can have one or multiple carriers (OTSi). 130 All the carrier have the same characteristics and are provisionable 131 in terms of: 133 Number of subcarriers: 134 This parameter indicates the number of subcarriers (OTSi) 135 available for the super-channel (OTSiG) in case the Transceiver 136 can support multiple carrier circuits. The OTSi is defined in 137 ITU-T Recommendation G.959.1, section 3.2.4 [G.959.1]. The OTSiG 138 is currently being moved from ITU-T Recommendation G.709 [G.709] 139 to the new draft Recommendation G.807 (still work in progress) 140 [G.807]. The OTSiG is an electrical signal that is carried by one 141 or more OTSi's. The relationship between the OTSiG and the OTSi's 142 is described in ITU-T draft Recommendation G.807, section 10.2 143 [G.807]. This draft specifies the case where the each carrier 144 (OTSi) is terminated on a physical port so the rtansceiver can 145 have multiple ports. In future editions also the case where 146 multiple carriers are terminated on the same port will be 147 supported (also known as Sliceable Transponders). 149 Central frequency (see G.694.1 Table 1): 150 This parameter indicates the Central frequency value that Ss and 151 Rs will be set to work (in THz). See the details in Section 6/ 152 G.694.1 or based on "n" value explanation and the following "k" 153 values definition in case of multicarrier transceivers. 155 Central frequency granularity: 156 This parameter indicates the Central frequency granularity 157 supported by the transceiver, this value is combined with k and n 158 value to calculate the central frequency of the carrier or sub- 159 carriers. 161 Minimum channel spacing: 162 This is the minimum nominal difference in frequency (in GHz) 163 between two adjacent channels (or carriers) depending on the 164 Transceiver characteristics. 166 Bit rate / Baud rate of Optical Tributary Signals (OTSi): 167 Optical Tributary Signal bit (for NRZ signals) rate or Symbol (for 168 Multiple bit per symbol) rate . 170 FEC Coding: 171 This parameter indicate what Forward Error Correction (FEC) code 172 is used at Ss and Rs (R/W) (not mentioned in G.698.2). . 174 Wavelength Range (see G.694.1): [ITU.G694.1] 175 This parameter indicate minimum and maximum wavelength spectrum in 176 a definite wavelength Band (L, C and S). That is the transceiver 177 tunability range 179 Modulation format: 180 This parameter indicates the list of supported Modulation Formats 181 and the provisioned Modulation Format. 183 Inter carrier skew: 184 This parameter indicates, in case of multi-carrier LSP (OTSiG) the 185 maximum skew between the sub-carriers OTSi) supported by the 186 transceivers. 188 Laser Output power: 190 This parameter provisions the Transceiver Output power, it can be 191 either a setting and measured value. 193 Receiver input power: 194 This parameter provisions the Min and Max input power supported by 195 the Transceiver, i.e. Receiver Sensitivity. 197 The above parameters are related to the Edge Node Transceiver and are 198 used by the Core Network control plane in order to calculate the 199 optical feasibility and the spectrum allocation. The parameters can 200 be shared between the Client and the Network via LMP or provisioned 201 to the Network by an EMS or an operator OSS. 203 3. Use Cases 205 The use cases are described in [RFC7698] 207 4. Signalling Extensions 209 The following sections specify the fields used in the RSVP-TE Path 210 and Resv messages to address the requirements above. The above 211 parameters could be applied to [RFC4208] scenarios but they are valid 212 also in case of non UNI scenarios. The [RFC7699] parameters remain 213 valid. 215 4.1. New LSP Request Parameters 217 When the E.N. wants to request to the C.N. a new circuit set-up, i.e. 218 the control plane wants to signal in the SSON network the Optical 219 Interface characteristics, the following parameters will be provided 220 to the C.N.: 222 Number of available subcarriers (c): 223 This parameter is an integer and identifies the number of OTSi in 224 an OTSiG. In this version of the document, it maps to the number 225 of Client ports connected to the Core ports available to support 226 the requested circuit. 228 Total bandwidth request: 229 e.g. 200Gb, 400Gb, 1Tb - it is the bandwidth (payload) to be 230 carried by the multiple carrier circuit (OTSiG). In alternative 231 the OTUCn can be used 233 Policy (strict/loose): 234 Strict/loose referred to B/W and subcarrier number. This is to 235 give some flexibility to the GMPLS in order to commit client 236 request. 238 Subcarrier bandwidth tunability: 239 (optional) e.g. 34Ghz, 48GHz. 241 The TLV define the resource constraints for the requested Media 242 Channel. 244 The format of the sub-object is as follows: 246 0 1 2 3 247 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 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 |S|B| Reserved | Carrier Number | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | Total Bandwidth | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 Figure 2: SSON LSP set-up request 256 Carrier Number: number of carrier to be allocated for the requested 257 channel (16-bit unsigned integer) 258 If Carrier Number == 0 no constraint set on the number of 259 carriers to be used 261 Total Bandwidth: the requested total bandwidth to be supported by 262 the Media Channel (32-bit IEEE float, bytes/s) 263 If Total Bandwidth == 0: no bandwidth constraint is defined 264 (B must be 0) 266 S strict number of subcarrier 267 - S = 0 the number of requested carriers is the maximum number 268 that can be allocated (a lower value can be allocated if 269 the requested bandwidth is satisfied) 270 - S = 1 the number of requested carriers is strict (must be > 0) 272 B Bandwidth constraints 273 - B = 0: the value is the maximum requested bandwidth (a lower 274 value can be allocated if resources are not available) 275 - B = 1: the requested bandwidth is the minimum value to be 276 allocated (a higher value can be allocated if requested 277 by the physical constraints of the ports) 279 Reserved: unused bit (for future use, should be 0) 280 Note: bandwidth unit is defined in accordance to RFC 3471 281 chap. 3.1.2 Bandwith Encoding specification. Bandwidth higher 282 than 40Gb/s values must be defined (e.g. 100Gb/s, 150Gb/s 283 400Gb/s, etc.) or in alternative the OTUCn defined in 284 ITU-T G.709. 286 TLV Usage in RSVP-TE message: 287 Path from head E.N.: requested traffic constraints, the Head C.N. 288 must satisfy when reserving the optical resources and 289 defining the carriers configuration 290 The TLV can be omitted: no traffic constraints is defined 291 (resources allocated by C.N. based on a local policy) 293 4.2. Extension to LSP set-up specification 295 Once the WDM comtrol plane has calculated the Media Channel path, the 296 Spectrum Allocation, the Sub-carrier number and frequency, the 297 modulation format, the FEC and the Transmit power, it MUST send back 298 to the E.N. the path set-up confirmation providing the values of the 299 calculated parameters: 301 Media Channel: 302 (Grid, C.S., Identifier m and n). as indicated in RFC7699 303 Section 4.1 305 Modulation format: 306 This parameter indicates the Modulation Formats to be set in the 307 Transceivers. 309 FEC Coding: 310 This parameter indicate what Forward Error Correction (FEC) code 311 must be used by the Transceivers (not mentioned in G.698). . 313 Baud rate of optical tributary signals: 314 Symbol (for Multiple bit per symbol) rate. 316 List of subcarriers: 317 This parameter indicates the subcarriers to be used for the super- 318 channel (OTSiG) in case the Transceiver can support multiple 319 carrier Circuits. 321 Central frequency granularity (J): 322 This parameter indicates the Central frequency granularity 323 supported by the transceiver, this value is combined with K and n 324 value to calculate the central frequency on the carrier or sub- 325 carriers. 327 Central frequency (see G.694.1 Table 1): 329 Grid, Identifiers, central frequency and granularity. 331 Laser Output power: 332 This parameter provisions the Transceiver Output power, it can be 333 either a setting and measured value. 335 Circuit Path, RRO, etc: 336 All these info are defined in [RFC4208]. 338 Path Error: 339 e.g. no path exist, all the path error defined in [RFC4208]. 341 4.2.1. Common Signal Description TLV 343 The TLV defines the carriers signal configuration. 344 All carriers in a Media Channel MUST have the same configuration. 346 The format of this sub-object (Type = TBA, Length = TBA) is 347 as follows: 349 0 1 2 3 350 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 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | Modulation ID | Bit/Symbol | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | FEC | Min OSNR Threshold | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | baud rate (Symbol Rate) | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 Figure 3: OCh_General 361 Traffic Type 362 - Modulation ID (Format) : is the modulation type: 363 BPSK, DC DP BSPSK, QPSK, DP QPSK, 8QAM, 16QAM, 364 32QAM, 64QAM, etc. 365 - Bits/Symbol(BPS) this indicates the bit per symbol in case of 366 hybrid modulation format. It is an off-set with values from 0 367 to 127 to be applied to the specified Modulation Format and 368 indicates the mix between the selected Modulation Format and its 369 upper adjacent. 370 (e.g. QPSK + 63 BPS indicates that there is a 50% MIX between 371 QPSK and 8-QAM = 2.5 bits per symbol) If value = 0 the 372 standard Modulation Format is applied 373 - FEC: the signal Forward Error Corrections type (16-bit 374 unsigned integer), the defined values are: 375 - Value 0 is reserved to be used if no value is defined 376 - Min OSNR Threshold: An integer specifying the minimum accepted 377 threshold for the Optical Signal-Noise Ratio in 0.1 nm. 378 - Baud Rate: the signal symbol rate (IEEE 32-bit float, 379 in bauds/s) 380 - Value 0 is reserved to be used if no value is defined 382 Notes: 383 - The Path message from the E.C. can specify all or 384 only a subset of the parameters (e.g. the Modulation and the 385 baud rate as required but not the FEC) setting to 0 for the 386 undefined parameters. 387 When forwarding the Path message, the C.N. will set the 388 undefined parameters based on the optical impairment calculation 389 and the constraints given by the E.N. 390 - Custom codes (values > 0x8000) interpretation is a local 391 installation matter. 393 TLV Usage in RSVP-TE messages: 394 - Path from the head E.N.: used to force specific transponder 395 configurations 396 - Path from the tail C.N.: set selected configuration on head node 397 - Resv from the head C.N.: set selected configuration on tail node 399 4.2.2. Sub-carrier List Content TLV 400 For Each carrier inside the Media Channel the TLV is used. 402 The format of this sub-object (Type = TBA, Length = TBA) 403 is as follows: 405 0 1 2 3 406 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 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | Carrier Index | j | 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | k | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | sub-TLVs | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 Figure 4: Sub-Carrier parameters 417 Carrier setup: 419 - Carrier Index field: sub-carrier (OTSi) index 420 inside the OTSiG (corresponding to the media channel). 421 Identifies the carrier 422 position inside the Media Channel (16-bit unsigned integer) 423 The Carrier Index is the logical circuit sub-lane 424 position, a TLV for each value from 1 to the number of 425 allocated carriers must be present. 426 - J field: granularity of the channel spacing, can be a 427 multiple of 0.01GHz. - default value is 0.1GHz. 428 - K field: positive or negative integer (including 0) to multiply 429 by J and identify the Carrier Position inside the 430 Media Channel, offset from media Channel Central frequency 431 - sub-TLVs: additional information related to carriers if needed 432 and the ports associated to the carrier. 434 In summary Carrier Frequency = MC-C.F. (in THz) + K * J GHz. 436 m=8 437 +-------------------------------X------------------------------+ 438 | | | 439 | sub-carrier sub-carrier | 440 | +----------X----------+ | +----------X----------+ | 441 | | OTSi | | OTSi | | 442 | | o | | | o | | 443 | | | | | | | | 444 -4 -3 -2 -1 0 1 2 3 4 5 6 7 8 9 10 11 12 445 -+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+- 446 | n=4 | 447 K1 -236 | +236 K2 449 <------------------------ Media Channel -----------------------> 451 4.2.3. Sub-carrier sub-TLV 453 The defined sub-TLVs are Port Identifiers and Carrier Power 454 Source Port Identifier 456 The format of this sub-object (Type = TBA, Length = 8) is 457 as follows: 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) | reserved | Length = 8 | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | Source Port Identifier | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 Figure 5: Source Port Identifier 469 Source Port Identifier: the HEAD E.N. optical logical source end 470 point identifier (32-bits integer, ifindex) 472 TLV Usage in RSVP-TE message: 473 - path from the head E.N.: used to force specific carrier ports 474 [optional use, e.g. with external PCE scenario] 475 - Path from the tail C.N.: report selected carrier head ports 476 to tail C.N. 477 - Resv: report selected configuration to head E.N. 479 Destination Port Identifier 481 The format of this sub-object (Type = TBA, Length = 8) is 482 as follows: 484 0 1 2 3 485 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 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | Type (TBA) | reserved | Length = 8 | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | Destination Port Identifier | 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 Figure 6: Destination Port Identifiers 494 Destination Port Identifier: the local upstream optical logical 495 destination end point identifier (32-bits integer, ifindex) 497 TLV Usage in RSVP-TE messages: 498 - Path from head E.N.: used to force specific carrier ports 499 [optional use, e.g. with external PCE scenario] 500 - Path from tail C.N.: set selected configuration on tail node 501 - Resv: report selected configuration to the head E.N. 503 Carrier Power 505 The format of this sub-object (Type = TBA, Length = 8) 506 is as follows: 508 0 1 2 3 509 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 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 | Type (TBA) | reserved | Length = 8 | 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 | carrier power | 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 Figure 7: Carrier Power 518 Carrier Power: the requested carrier transmit power (32-bits IEEE 519 Float, dBm), optionally used to notify the configured 520 power (from E.N. to C.N.) or force the power to from 521 the C.N. to the E.N. 523 TLV Usage in RSVP-TE messages: 524 - Path from head the E.N.: used to force specific carrier 525 frequency/ports (optional use, e.g. with external PCE scenario) 526 - Path from tail C.N.: set selected configuration on tail node 527 - Resv from the head C.N.: set selected configuration on head node 529 4.3. RSVP Protocol Extensions Considerations 531 The additional information described in the draft, is related to the 532 Media Channel supported traffic. The parameters to be used by the 533 egress transceivers are carried in Path messages. In RSVP-TE 534 signaling, hop-specific information is encoded within the ERO as hop 535 attributes and WDM parameters are to be carried as sub-TLVs within 536 the Type 4 TLV [RFC7689], in the Hop Attributes SubObject 538 Beside, some of the additional information defined is local to the 539 head/tail UNI link (e.g. the carrier/port association), while the 540 traffic spec info should be valid end-to-end. 542 There can be different methods to model and signal the carriers as 543 described in draft-ietf-ccamp-optical-impairment-topology-yang. The 544 Media Channel, Network Media Channel and lables are well modelled by 545 the RFC7698, RFC7699 and RFC7792 reflecting the ITU-T Recommendations 546 G.694.1 and G.698.2. 548 Some work is in progress in ITU-T SG15/Q12 to define Network Media 549 Channel (group) that is capable of accommodating the optical 550 tributary signals (OTSi) belonging to optical tributary signal group 551 (OTSiG) (see new ITU-T Draft Recommendation G.807). 553 Other the encoding proposal reported in this draft, there are several 554 at least two other methods to describe the parameters. An option is 555 to describe the OTSi carrier frequency relative to the anchor 556 frequency 193.1THz based on a well-defined granularity (e.g. OTSi 557 carrier frequency = 193100 (GHz) + K * granularity (GHz) where K is a 558 signed integer value). A second option is to explicitly describe the 559 OTSi carrier frequency and the OTSi signal width in GHz with a 560 certain accuracy. 562 The second option which is independent of the n, m values already 563 defined in ITU-T Recommendation G.694.1. The OTSi carrier frequency 564 is described in GHz with 3 fractional digits (decimal 64 fraction 565 digits 3). The OTSi signal width is described in GHz with 3 566 fractional digits (decimal 64 fraction digits 3) and includes the 567 signal roll off as well as some guard band. 569 The accuracy of 0.001 GHz does not impose a requirement on the 570 optical transceiver components (optical transmitter) in terms of 571 carrier frequency tunability precision. Today's components typically 572 provide a tunability precision in the range of 1..1.5GHz (carrier 573 frequency offset compared to the configured nominal carrier 574 frequency). 575 Future components may provide a better precision as technology 576 evolves. If needed, a controller may retrieve the transceiver 577 properties in terms of carrier frequency tunability precision in 578 order to be capable of properly configuring the underlying 579 transceiver. 581 NOTE FROM THE EDITORS: As this description is arbitrarily proposed by 582 the authors to cover a lack of information in IETF and ITU-T, a 583 liaison request to ITU-T is needed. The authors are willing to 584 contribute to Liaison editing and to consider any feedback and 585 proposal from ITU-T. 587 5. Security Considerations 589 RSVP-TE message security is described in [RFC5920]. IPsec and HMAC- 590 MD5 authentication are common examples of existing mechanisms. This 591 document only defines new UNI objects that are carried in existing 592 UNI messages, thus it does not introduce new security considerations. 594 6. IANA Considerations 595 The IANA is requested to create, within the "GMPLS Signaling 596 Parameters" registry, two new sub-registries named "WDM 597 Modulation Formats" and "WDM FEC Types". 599 For both of them: 601 o the value 0 means "Pending selection", 603 o the range 1-65503 follows the Expert Review policy for 604 registration, 606 o the range 65504-65535 is for experimental use. 608 The "WDM Modulation Format" sub-registry is initialized as 609 follows: 611 +-------------+---------------------+ 612 | Value | Modulation Format | 613 +-------------+---------------------+ 614 | 0 | Pending selection | 615 | 1 | DPSK | 616 | 2 | QPSK | 617 | 3 | 8-QAM | 618 | 4 | 16-QAM | 619 | 5 | 32-QAM | 620 | 6 | 64-QAM | 621 | 7-63999 | Unallocated | 622 | 64000-65535 | Vendor specific use | 623 +-------------+---------------------+ 625 The "WDM FEC Types" sub-registry is initialized as follows: 627 +-------------+---------------------+ 628 | Value | FEC Types | 629 +-------------+---------------------+ 630 | 0 | Pending selection | 631 | 1 | Reed Solomon FEC | 632 | 2 | Staircase FEC | 633 | 3 | O-FEC. | 634 | 4-63999 | Unallocated | 635 | 64000-65535 | Vendor specific use | 636 +-------------+---------------------+ 638 7. Contributors 640 Antonello Bonfanti 641 Cisco 642 Via Santa Maria Molgora, 48 c 643 20871 - Vimercate (MB) 644 Italy 645 abonfant@cisco.com 647 Esther Le Rouzic 648 Orange 649 2 avenue Pierre Marzin 650 Lannion 22300 651 France 652 esther.lerouzic@orange.com 654 8. References 656 8.1. Normative References 658 [ITU.G694.1] 659 International Telecommunications Union, ""Spectral grids 660 for WDM applications: DWDM frequency grid"", 661 ITU-T Recommendation G.698.2, February 2012. 663 [ITU.G698.2] 664 International Telecommunications Union, "Amplified 665 multichannel dense wavelength division multiplexing 666 applications with single channel optical interfaces", 667 ITU-T Recommendation G.698.2, November 2009. 669 [ITU.G709] 670 International Telecommunications Union, "Interface for the 671 Optical Transport Network (OTN)", ITU-T Recommendation 672 G.709, June 2016. 674 [ITU.G872] 675 International Telecommunications Union, "Architecture of 676 optical transport networks", ITU-T Recommendation G.872, 677 January 2017. 679 [ITU.G874.1] 680 International Telecommunications Union, "Optical transport 681 network (OTN): Protocol-neutral management information 682 model for the network element view", ITU-T Recommendation 683 G.874.1, November 2016. 685 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 686 Requirement Levels", BCP 14, RFC 2119, 687 DOI 10.17487/RFC2119, March 1997, 688 . 690 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 691 Switching (GMPLS) Signaling Resource ReserVation Protocol- 692 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 693 DOI 10.17487/RFC3473, January 2003, 694 . 696 [RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label 697 Switching (GMPLS) Architecture", RFC 3945, 698 DOI 10.17487/RFC3945, October 2004, 699 . 701 [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, 702 "Generalized Multiprotocol Label Switching (GMPLS) User- 703 Network Interface (UNI): Resource ReserVation Protocol- 704 Traffic Engineering (RSVP-TE) Support for the Overlay 705 Model", RFC 4208, DOI 10.17487/RFC4208, October 2005, 706 . 708 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 709 Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, 710 . 712 [RFC6163] Lee, Y., Ed., Bernstein, G., Ed., and W. Imajuku, 713 "Framework for GMPLS and Path Computation Element (PCE) 714 Control of Wavelength Switched Optical Networks (WSONs)", 715 RFC 6163, DOI 10.17487/RFC6163, April 2011, 716 . 718 [RFC6205] Otani, T., Ed. and D. Li, Ed., "Generalized Labels for 719 Lambda-Switch-Capable (LSC) Label Switching Routers", 720 RFC 6205, DOI 10.17487/RFC6205, March 2011, 721 . 723 [RFC7698] Gonzalez de Dios, O., Ed., Casellas, R., Ed., Zhang, F., 724 Fu, X., Ceccarelli, D., and I. Hussain, "Framework and 725 Requirements for GMPLS-Based Control of Flexi-Grid Dense 726 Wavelength Division Multiplexing (DWDM) Networks", 727 RFC 7698, DOI 10.17487/RFC7698, November 2015, 728 . 730 [RFC7699] Farrel, A., King, D., Li, Y., and F. Zhang, "Generalized 731 Labels for the Flexi-Grid in Lambda Switch Capable (LSC) 732 Label Switching Routers", RFC 7699, DOI 10.17487/RFC7699, 733 November 2015, . 735 [RFC7792] Zhang, F., Zhang, X., Farrel, A., Gonzalez de Dios, O., 736 and D. Ceccarelli, "RSVP-TE Signaling Extensions in 737 Support of Flexi-Grid Dense Wavelength Division 738 Multiplexing (DWDM) Networks", RFC 7792, 739 DOI 10.17487/RFC7792, March 2016, 740 . 742 8.2. Informative References 744 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 745 DOI 10.17487/RFC2629, June 1999, 746 . 748 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 749 "Introduction and Applicability Statements for Internet- 750 Standard Management Framework", RFC 3410, 751 DOI 10.17487/RFC3410, December 2002, 752 . 754 [RFC4181] Heard, C., Ed., "Guidelines for Authors and Reviewers of 755 MIB Documents", BCP 111, RFC 4181, DOI 10.17487/RFC4181, 756 September 2005, . 758 Authors' Addresses 760 Gabriele Galimberti (editor) 761 Cisco 762 Via S. Maria Molgora, 48 c 763 20871 - Vimercate 764 Italy 766 Phone: +390392091462 767 Email: ggalimbe@cisco.com 769 Domenico La Fauci 770 Cisco 771 Via S. Maria Molgora, 48 c 772 20871 - Vimercate 773 Italy 775 Phone: +390392091946 776 Email: dlafauci@cisco.com 777 Andrea Zanardi (editor) 778 FBK 779 via alla Cascata 56/D 780 38123 Povo, Trento 781 Italy 783 Phone: +390461312450 784 Email: azanardi@fbk.eu 786 Lorenzo Galvagni 787 FBK 788 via alla Cascata 56/D 789 38123 Povo, Trento 790 Italy 792 Phone: +390461312427 793 Email: lgalvagni@fbk.eu 795 Julien Meuric 796 Orange 797 2 avenue Pierre Marzin 798 Lannion 22300 799 France 801 Email: julien.meuric@orange.com