idnits 2.17.1 draft-ggalimbe-ccamp-flexigrid-carrier-label-11.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 (July 1, 2021) is 1027 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 139, but not defined == Missing Reference: 'G.807' is mentioned on line 143, but not defined == Missing Reference: 'I-D.draft-meuric-ccamp-tsvmode-signaling' is mentioned on line 347, but not defined == Missing Reference: 'RFC7689' is mentioned on line 542, but not defined == Unused Reference: 'ITU.G698.2' is defined on line 668, but no explicit reference was found in the text == Unused Reference: 'ITU.G709' is defined on line 674, but no explicit reference was found in the text == Unused Reference: 'ITU.G874.1' is defined on line 684, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 690, but no explicit reference was found in the text == Unused Reference: 'RFC3473' is defined on line 695, but no explicit reference was found in the text == Unused Reference: 'RFC3945' is defined on line 701, but no explicit reference was found in the text == Unused Reference: 'RFC6163' is defined on line 717, but no explicit reference was found in the text == Unused Reference: 'RFC6205' is defined on line 723, but no explicit reference was found in the text == Unused Reference: 'RFC2629' is defined on line 749, but no explicit reference was found in the text == Unused Reference: 'RFC3410' is defined on line 753, but no explicit reference was found in the text == Unused Reference: 'RFC4181' is defined on line 759, 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 (~~), 18 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: January 2, 2022 A. Zanardi, Ed. 6 L. Galvagni 7 FBK 8 J. Meuric 9 Orange 10 July 1, 2021 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-11 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 January 2, 2022. 48 Copyright Notice 50 Copyright (c) 2021 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 or OTSiA) in case the 136 Transceiver can support multiple carrier circuits. The OTSi is 137 defined in ITU-T Recommendation G.959.1, section 3.2.4 [G.959.1]. 138 The OTSiG is currently being moved from ITU-T Recommendation G.709 139 [G.709] to the new draft Recommendation G.807 (still work in 140 progress) [G.807]. The OTSiG is an electrical signal that is 141 carried by one or more OTSi's. The relationship between the OTSiG 142 and the OTSi's is described in ITU-T draft Recommendation G.807, 143 section 10.2 [G.807]. This draft specifies the case where the 144 each carrier (OTSi) is terminated on a physical port so the 145 transceiver can have multiple ports. In future editions also the 146 case where multiple carriers are terminated on the same port will 147 be 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 Carriers 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 Carrier Central frequency (see G.694.1 Table 1) (k): 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 It is aligned with TLV in 3.2.1 section in 347 [I-D.draft-meuric-ccamp-tsvmode-signaling]. 349 The format of this sub-object (Type = TBA, Length = TBA) is 350 as follows: 352 0 1 2 3 353 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 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | Modulation ID | Bit/Symbol | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | FEC | Min OSNR Threshold | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | baud rate (Symbol Rate) | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 Figure 3: OCh_General 364 Traffic Type 365 - Modulation ID (Format) : is the modulation type: 366 BPSK, DC DP BSPSK, QPSK, DP QPSK, 8QAM, 16QAM, 367 32QAM, 64QAM, etc. 368 - Bits/Symbol(BPS) this indicates the bit per symbol in case of 369 hybrid modulation format. It is an off-set with values from 0 370 to 127 to be applied to the specified Modulation Format and 371 indicates the mix between the selected Modulation Format and its 372 upper adjacent modulation format. 373 (e.g. QPSK + 63 BPS indicates that there is a 50% MIX between 374 QPSK and 8-QAM = 2.5 bits per symbol) If value = 0 the 375 standard Modulation Format is applied. 376 - FEC: the signal Forward Error Corrections type (16-bit 377 unsigned integer), the defined values are: 378 - Value 0 is reserved to be used if no value is defined 379 - Min OSNR Threshold: An integer specifying the minimum accepted 380 threshold for the Optical Signal-Noise Ratio in 0.1 nm. 381 - Baud Rate: the signal symbol rate (IEEE 32-bit float, 382 in bauds/s) 383 - Value 0 is reserved to be used if no value is defined 385 Notes: 386 - The Path message from the E.C. can specify all or 387 only a subset of the parameters (e.g. the Modulation and the 388 baud rate as required but not the FEC) setting to 0 for the 389 undefined parameters. 390 When forwarding the Path message, the C.N. will set the 391 undefined parameters based on the optical impairment calculation 392 and the constraints given by the E.N. 393 - Custom codes (values > 0x8000) interpretation is a local 394 installation matter. 396 TLV Usage in RSVP-TE messages: 397 - Path from the head E.N.: used to force specific transponder 398 configurations 399 - Path from the tail C.N.: set selected configuration on head node 400 - Resv from the head C.N.: set selected configuration on tail node 402 4.2.2. Sub-carrier List Content TLV 403 For Each carrier inside the Media Channel the TLV is used. 405 The format of this sub-object (Type = TBA, Length = TBA) 406 is as follows: 408 0 1 2 3 409 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 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | Carrier Index | j | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | k | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | sub-TLVs | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 Figure 4: Sub-Carrier parameters 420 Carrier setup: 422 - Carrier Index field: sub-carrier (OTSi) index 423 inside the OTSiG (corresponding to the media channel). 424 Identifies the carrier 425 position inside the Media Channel (16-bit unsigned integer) 426 The Carrier Index is the logical circuit sub-lane 427 position, a TLV for each value from 1 to the number of 428 allocated carriers must be present. 429 - J field: granularity of the channel spacing, can be a 430 multiple of 0.01GHz. - default value is 0.1GHz. 431 - K field: positive or negative integer (including 0) to multiply 432 by J and identify the Carrier Position inside the 433 Media Channel, offset from Media Channel Central frequency 434 - sub-TLVs: additional information related to carriers if needed 435 and the ports associated to the carrier. 437 In summary Carrier Frequency = MC-C.F. (in THz) + K * J GHz. 439 m=8 440 +-------------------------------X------------------------------+ 441 | | | 442 | sub-carrier sub-carrier | 443 | +----------X----------+ | +----------X----------+ | 444 | | OTSi | | OTSi | | 445 | | o | | | o | | 446 | | | | | | | | 447 -4 -3 -2 -1 0 1 2 3 4 5 6 7 8 9 10 11 12 448 -+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+- 449 | n=4 | 450 K1 -236 | +236 K2 452 <------------------------ Media Channel -----------------------> 454 4.2.3. Sub-carrier sub-TLV 456 The defined sub-TLVs are Port Identifiers and Carrier Power 457 Source Port Identifier 459 The format of this sub-object (Type = TBA, Length = 8) is 460 as follows: 462 0 1 2 3 463 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 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 | Type (TBA) | reserved | Length = 8 | 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 | Source Port Identifier | 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 Figure 5: Source Port Identifier 472 Source Port Identifier: the HEAD E.N. optical logical source end 473 point identifier (32-bits integer, ifindex). In case ot UUID usage 474 the parameter could be extended to 128 bits) 476 TLV Usage in RSVP-TE message: 477 - path from the head E.N.: used to force specific carrier ports 478 [optional use, e.g. with external PCE scenario] 479 - Path from the tail C.N.: report selected carrier head ports 480 to tail C.N. 481 - Resv: report selected configuration to head E.N. 483 Destination Port Identifier 485 The format of this sub-object (Type = TBA, Length = 8) is 486 as follows: 488 0 1 2 3 489 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 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | Type (TBA) | reserved | Length = 8 | 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 | Destination Port Identifier | 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 Figure 6: Destination Port Identifiers 498 Destination Port Identifier: the local upstream optical logical 499 destination end point identifier (32-bits integer, ifindex), 500 In case ot UUID usage the parameter could be extended to 501 128 bits) 503 TLV Usage in RSVP-TE messages: 504 - Path from head E.N.: used to force specific carrier ports 505 [optional use, e.g. with external PCE scenario] 506 - Path from tail C.N.: set selected configuration on tail node 507 - Resv: report selected configuration to the head E.N. 509 Carrier Power 511 The format of this sub-object (Type = TBA, Length = 8) 512 is as follows: 514 0 1 2 3 515 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 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 | Type (TBA) | reserved | Length = 8 | 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 | carrier power | 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 Figure 7: Carrier Power 524 Carrier Power: the requested carrier transmit power (32-bits IEEE 525 Float, dBm), optionally used to notify the configured 526 power (from E.N. to C.N.) or force the power to from 527 the C.N. to the E.N. 529 TLV Usage in RSVP-TE messages: 530 - Path from head the E.N.: used to force specific carrier 531 frequency/ports (optional use, e.g. with external PCE scenario) 532 - Path from tail C.N.: set selected configuration on tail node 533 - Resv from the head C.N.: set selected configuration on head node 535 4.3. RSVP Protocol Extensions Considerations 537 The additional information described in the draft, is related to the 538 Media Channel supported traffic. The parameters to be used by the 539 egress transceivers are carried in Path messages. In RSVP-TE 540 signaling, hop-specific information is encoded within the ERO as hop 541 attributes and WDM parameters are to be carried as sub-TLVs within 542 the Type 4 TLV [RFC7689], in the Hop Attributes SubObject 543 Beside, some of the additional information defined is local to the 544 head/tail UNI link (e.g. the carrier/port association), while the 545 traffic spec info should be valid end-to-end. 547 There can be different methods to model and signal the carriers as 548 described in draft-ietf-ccamp-optical-impairment-topology-yang. The 549 Media Channel, Network Media Channel and lables are well modelled by 550 the RFC7698, RFC7699 and RFC7792 reflecting the ITU-T Recommendations 551 G.694.1 and G.698.2. 553 Some work is in progress in ITU-T SG15/Q12 to define Network Media 554 Channel (group) that is capable of accommodating the optical 555 tributary signals (OTSi) belonging to optical tributary signal group 556 (OTSiG) (see new ITU-T Draft Recommendation G.807). 558 Other the encoding proposal reported in this draft, there are several 559 at least two other methods to describe the parameters. An option is 560 to describe the OTSi carrier frequency relative to the anchor 561 frequency 193.1THz based on a well-defined granularity (e.g. OTSi 562 carrier frequency = 193100 (GHz) + K * granularity (GHz) where K is a 563 signed integer value). A second option is to explicitly describe the 564 OTSi carrier frequency and the OTSi signal width in GHz with a 565 certain accuracy. 567 The second option which is independent of the n, m values already 568 defined in ITU-T Recommendation G.694.1. The OTSi carrier frequency 569 is described in GHz with 3 fractional digits (decimal 64 fraction 570 digits 3). The OTSi signal width is described in GHz with 3 571 fractional digits (decimal 64 fraction digits 3) and includes the 572 signal roll off as well as some guard band. 574 The accuracy of 0.001 GHz does not impose a requirement on the 575 optical transceiver components (optical transmitter) in terms of 576 carrier frequency tunability precision. Today's components typically 577 provide a tunability precision in the range of 1..1.5GHz (carrier 578 frequency offset compared to the configured nominal carrier 579 frequency). 580 Future components may provide a better precision as technology 581 evolves. If needed, a controller may retrieve the transceiver 582 properties in terms of carrier frequency tunability precision in 583 order to be capable of properly configuring the underlying 584 transceiver. 586 NOTE FROM THE EDITORS: As this description is arbitrarily proposed by 587 the authors to cover a lack of information in IETF and ITU-T, a 588 liaison request to ITU-T is needed. The authors are willing to 589 contribute to Liaison editing and to consider any feedback and 590 proposal from ITU-T. 592 5. Security Considerations 594 RSVP-TE message security is described in [RFC5920]. IPsec and HMAC- 595 MD5 authentication are common examples of existing mechanisms. This 596 document only defines new UNI objects that are carried in existing 597 UNI messages, thus it does not introduce new security considerations. 599 6. IANA Considerations 600 The IANA is requested to create, within the "GMPLS Signaling 601 Parameters" registry, two new sub-registries named "WDM 602 Modulation Formats" and "WDM FEC Types". 604 For both of them: 606 o the value 0 means "Pending selection", 608 o the range 1-65503 follows the Expert Review policy for 609 registration, 611 o the range 65504-65535 is for experimental use. 613 The "WDM Modulation Format" sub-registry is initialized as 614 follows: 616 +-------------+---------------------+ 617 | Value | Modulation Format | 618 +-------------+---------------------+ 619 | 0 | Pending selection | 620 | 1 | DPSK | 621 | 2 | QPSK | 622 | 3 | 8-QAM | 623 | 4 | 16-QAM | 624 | 5 | 32-QAM | 625 | 6 | 64-QAM | 626 | 7-63999 | Unallocated | 627 | 64000-65535 | Vendor specific use | 628 +-------------+---------------------+ 630 The "WDM FEC Types" sub-registry is initialized as follows: 632 +-------------+---------------------+ 633 | Value | FEC Types | 634 +-------------+---------------------+ 635 | 0 | Pending selection | 636 | 1 | Reed Solomon FEC | 637 | 2 | Staircase FEC | 638 | 3 | O-FEC. | 639 | 4-63999 | Unallocated | 640 | 64000-65535 | Vendor specific use | 641 +-------------+---------------------+ 643 7. Contributors 645 Antonello Bonfanti 646 Cisco 647 Via Santa Maria Molgora, 48 c 648 20871 - Vimercate (MB) 649 Italy 650 abonfant@cisco.com 652 Esther Le Rouzic 653 Orange 654 2 avenue Pierre Marzin 655 Lannion 22300 656 France 657 esther.lerouzic@orange.com 659 8. References 661 8.1. Normative References 663 [ITU.G694.1] 664 International Telecommunications Union, ""Spectral grids 665 for WDM applications: DWDM frequency grid"", 666 ITU-T Recommendation G.698.2, February 2012. 668 [ITU.G698.2] 669 International Telecommunications Union, "Amplified 670 multichannel dense wavelength division multiplexing 671 applications with single channel optical interfaces", 672 ITU-T Recommendation G.698.2, November 2009. 674 [ITU.G709] 675 International Telecommunications Union, "Interface for the 676 Optical Transport Network (OTN)", ITU-T Recommendation 677 G.709, June 2016. 679 [ITU.G872] 680 International Telecommunications Union, "Architecture of 681 optical transport networks", ITU-T Recommendation G.872, 682 January 2017. 684 [ITU.G874.1] 685 International Telecommunications Union, "Optical transport 686 network (OTN): Protocol-neutral management information 687 model for the network element view", ITU-T Recommendation 688 G.874.1, November 2016. 690 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 691 Requirement Levels", BCP 14, RFC 2119, 692 DOI 10.17487/RFC2119, March 1997, 693 . 695 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 696 Switching (GMPLS) Signaling Resource ReserVation Protocol- 697 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 698 DOI 10.17487/RFC3473, January 2003, 699 . 701 [RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label 702 Switching (GMPLS) Architecture", RFC 3945, 703 DOI 10.17487/RFC3945, October 2004, 704 . 706 [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, 707 "Generalized Multiprotocol Label Switching (GMPLS) User- 708 Network Interface (UNI): Resource ReserVation Protocol- 709 Traffic Engineering (RSVP-TE) Support for the Overlay 710 Model", RFC 4208, DOI 10.17487/RFC4208, October 2005, 711 . 713 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 714 Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, 715 . 717 [RFC6163] Lee, Y., Ed., Bernstein, G., Ed., and W. Imajuku, 718 "Framework for GMPLS and Path Computation Element (PCE) 719 Control of Wavelength Switched Optical Networks (WSONs)", 720 RFC 6163, DOI 10.17487/RFC6163, April 2011, 721 . 723 [RFC6205] Otani, T., Ed. and D. Li, Ed., "Generalized Labels for 724 Lambda-Switch-Capable (LSC) Label Switching Routers", 725 RFC 6205, DOI 10.17487/RFC6205, March 2011, 726 . 728 [RFC7698] Gonzalez de Dios, O., Ed., Casellas, R., Ed., Zhang, F., 729 Fu, X., Ceccarelli, D., and I. Hussain, "Framework and 730 Requirements for GMPLS-Based Control of Flexi-Grid Dense 731 Wavelength Division Multiplexing (DWDM) Networks", 732 RFC 7698, DOI 10.17487/RFC7698, November 2015, 733 . 735 [RFC7699] Farrel, A., King, D., Li, Y., and F. Zhang, "Generalized 736 Labels for the Flexi-Grid in Lambda Switch Capable (LSC) 737 Label Switching Routers", RFC 7699, DOI 10.17487/RFC7699, 738 November 2015, . 740 [RFC7792] Zhang, F., Zhang, X., Farrel, A., Gonzalez de Dios, O., 741 and D. Ceccarelli, "RSVP-TE Signaling Extensions in 742 Support of Flexi-Grid Dense Wavelength Division 743 Multiplexing (DWDM) Networks", RFC 7792, 744 DOI 10.17487/RFC7792, March 2016, 745 . 747 8.2. Informative References 749 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 750 DOI 10.17487/RFC2629, June 1999, 751 . 753 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 754 "Introduction and Applicability Statements for Internet- 755 Standard Management Framework", RFC 3410, 756 DOI 10.17487/RFC3410, December 2002, 757 . 759 [RFC4181] Heard, C., Ed., "Guidelines for Authors and Reviewers of 760 MIB Documents", BCP 111, RFC 4181, DOI 10.17487/RFC4181, 761 September 2005, . 763 Authors' Addresses 765 Gabriele Galimberti (editor) 766 Cisco 767 Via S. Maria Molgora, 48 c 768 20871 - Vimercate 769 Italy 771 Phone: +390392091462 772 Email: ggalimbe@cisco.com 774 Domenico La Fauci 775 Cisco 776 Via S. Maria Molgora, 48 c 777 20871 - Vimercate 778 Italy 780 Phone: +390392091946 781 Email: dlafauci@cisco.com 782 Andrea Zanardi (editor) 783 FBK 784 via alla Cascata 56/D 785 38123 Povo, Trento 786 Italy 788 Phone: +390461312450 789 Email: azanardi@fbk.eu 791 Lorenzo Galvagni 792 FBK 793 via alla Cascata 56/D 794 38123 Povo, Trento 795 Italy 797 Phone: +390461312427 798 Email: lgalvagni@fbk.eu 800 Julien Meuric 801 Orange 802 2 avenue Pierre Marzin 803 Lannion 22300 804 France 806 Email: julien.meuric@orange.com