idnits 2.17.1 draft-ggalimbe-ccamp-flexigrid-carrier-label-08.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 (November 4, 2019) is 1632 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'G.959.1' is mentioned on line 135, but not defined == Missing Reference: 'G.709' is mentioned on line 136, but not defined == Missing Reference: 'G.807' is mentioned on line 141, but not defined == Unused Reference: 'ITU.G698.2' is defined on line 617, but no explicit reference was found in the text == Unused Reference: 'ITU.G709' is defined on line 623, but no explicit reference was found in the text == Unused Reference: 'ITU.G874.1' is defined on line 633, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 639, but no explicit reference was found in the text == Unused Reference: 'RFC3473' is defined on line 644, but no explicit reference was found in the text == Unused Reference: 'RFC3945' is defined on line 650, but no explicit reference was found in the text == Unused Reference: 'RFC5920' is defined on line 662, but no explicit reference was found in the text == Unused Reference: 'RFC6163' is defined on line 666, but no explicit reference was found in the text == Unused Reference: 'RFC7699' is defined on line 684, but no explicit reference was found in the text == Unused Reference: 'RFC2629' is defined on line 698, but no explicit reference was found in the text == Unused Reference: 'RFC3410' is defined on line 702, but no explicit reference was found in the text == Unused Reference: 'RFC4181' is defined on line 708, 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: May 7, 2020 A. Zanardi, Ed. 6 L. Galvagni 7 FBK-CreateNet 8 November 4, 2019 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-08 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 May 7, 2020. 46 Copyright Notice 48 Copyright (c) 2019 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (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.2.1. Sub-carrier list content . . . . . . . . . . . . . . 9 70 4.2.2. Sub-carrier sub-TLV . . . . . . . . . . . . . . . . . 11 71 4.3. RSVP Protocol Extensions considerations . . . . . . . . . 13 72 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 74 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15 75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 76 8.1. Normative References . . . . . . . . . . . . . . . . . . 15 77 8.2. Informative References . . . . . . . . . . . . . . . . . 17 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 80 1. Introduction 82 Generalised Multiprotocol Label Switched (GMPLS) is widely used in 83 Wavelength Switched Optical Network (WSON) to support the optical 84 circuits set-up through the signalling between Core Nodes and Edge 85 Nodes. This extension addresses the use cases described by [RFC7698] 86 Ch.3.3 and supports the information, needed in Spectrum Switched 87 Optical Network (SSON), to signal a Media Channel and the associated 88 carriers set request. The new set of parameters is related to the 89 Media Channel and the carrier(s) routed with it and keep the backward 90 compatibility with the WSON signalling. In particular this memo 91 wants do address the use cases where the SSON LSP (the Media Channel 92 in RFC7698) carries multiple carrier (OTSi) containing same Payload. 93 The set of the carriers can be seen as single Logical circuit. This 94 memo can be considered as the extension of [RFC7792]. The contents 95 and the parameters reflect the experimental activity on IP over SSON 96 recently done by some vendors and research consortia. 98 Figure 1 shows how the multiple carrier are mapped into a Media 99 Channel. A set of parameters must be shared on the UNI to allow the 100 GMPLS to do the proper routing and Spectrum Assignment and decide the 101 carrier position. 103 +------+ +------+ _________ +------+ +------+ 104 | E.N. | | C.N. | / /\ | C.N. | | E.N. | 105 | OTS1| ----- | || | || | ----- |OTS1 | 106 ==| OTS2| ----- | || Media | || | ----- |OTS2 |== 107 ==| OTS3| ----- | || Channel| || | ----- |OTS3 |== 108 | OTS4| ----- | || | || | ----- |OTS4 | 109 | | | ROADM| \________\/ | ROADM| | | 110 +------+ +------+ +------+ +------+ 111 ^ ^ ^ ^ 112 | | | | 113 +---UNI---+ +---UNI---+ 115 E.N. = Edge Node - UNI Client 116 C.N. = Core Node - UNI Network 117 ROADM = Lambda/Spectrum switch 118 Media Channel = the optical circuit 119 OTSi = Carriers belonging to the same Network Media Channel (or 120 Super Channel) 121 UNI = Signalig interface 123 Figure 1: Multi carrier LSP 125 2. Client interface parameters 127 The Edge Node interface can have one or multiple carriers (OTSi). 128 All the carrier have the same characteristics and are provisionable 129 in terms of: 131 Number of subcarriers: 132 This parameter indicates the number of subcarriers (OTSi) 133 available for the super-channel (OTSiG) in case the Transceiver 134 can support multiple carrier circuits. The OTSi is defined in 135 ITU-T Recommendation G.959.1, section 3.2.4 [G.959.1]. The OTSiG 136 is currently being moved from ITU-T Recommendation G.709 [G.709] 137 to the new draft Recommendation G.807 (still work in progress) 138 [G.807]. The OTSiG is an electrical signal that is carried by one 139 or more OTSi's. The relationship between the OTSiG and the the 140 OTSi's is described in ITU-T draft Recommendation G.807, section 141 10.2 [G.807]. 143 Central frequency (see G.694.1 Table 1): 144 This parameter indicates the Central frequency value that Ss and 145 Rs will be set to work (in THz). See the details in Section 6/ 146 G.694.1 or based on "n" value explanation and the following "k" 147 values definition in case of multicarrier transceivers. 149 Central frequency granularity: 150 This parameter indicates the Central frequency granularity 151 supported by the transceiver, this value is combined with k and n 152 value to calculate the central frequency of the carrier or sub- 153 carriers. 155 Minimum channel spacing: 156 This is the minimum nominal difference in frequency (in GHz) 157 between two adjacent channels (or carriers) depending on the 158 Transceiver characteristics. 160 Bit rate / Baud rate of optical tributary signals: 161 Optical Tributary Signal bit (for NRZ signals) rate or Symbol (for 162 Multiple bit per symbol) rate . 164 FEC Coding: 165 This parameter indicate what Forward Error Correction (FEC) code 166 is used at Ss and Rs (R/W) (not mentioned in G.698.2). . 168 Wavelength Range (see G.694.1): [ITU.G694.1] 169 This parameter indicate minimum and maximum wavelength spectrum in 170 a definite wavelength Band (L, C and S). 172 Modulation format: 173 This parameter indicates the list of supported Modulation Formats 174 and the provisioned Modulation Format. 176 Inter carrier skew: 177 This parameter indicates, in case of multi-carrier transceivers 178 the maximum skew between the sub-carriers supported by the 179 transceiver. 181 Laser Output power: 182 This parameter provisions the Transceiver Output power, it can be 183 either a setting and measured value. 185 Receiver input power: 187 This parameter provisions the Min and MAX input pover suppotred by 188 the Transceiver, i.e. Receiver Sensitivity. 190 The above parameters are related to the Edge Node Transceiver and are 191 used by the Core Network GMPLS in order to calculate the optical 192 feasibility and the spectrum allocation. The parameters can be 193 shared between the Client and the Network via LMP or provisioned to 194 the Network by an EMS or an operator OSS. 196 3. Use Cases 198 The use cases are described in draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk 199 and [RFC7698] 201 4. Signalling Extensions 203 Some of the above parameters can be applied to RFC7792 (SENDER_TSPEC/ 204 FLOWSPEC). The above parameters could be applied to [RFC4208] 205 scenarios but they are valid also in case of non UNI scenarios. The 206 [RFC6205] parameters remain valid. 208 4.1. New LSP set-up parameters 210 When the E.N. wants to request to the C.N. a new circuit set-up 211 request or the GMPLS wants to signal in the SSON network the Optical 212 Interface characteristics the following parameters will be provided 213 to the C.N.: 215 Number of available subcarriers (c): 216 This parameter is an integer and identifies the number of Client 217 ports connected to the Core ports available to suport the 218 requested circuit, this identify also the number of OTSi in an 219 OTSiG. 221 Total bandwidth request: 222 e.g. 200Gb, 400Gb, 1Tb - it is the bandwidth (payload) to be 223 carried by the multiple carrier circuit (OTSiG). In alternative 224 the OTUCn can be used 226 Policy (strict/loose): 227 Strict/loose referred to B/W and subcarrier number. This is to 228 give some flexibility to the GMPLS in order to commit client 229 request. 231 Subcarrier bandwidth tunability: 232 (optional) e.g. 34Ghz, 48GHz. 234 The TLV define the resource constraints for the requested Media 235 Channel. 237 The format of the this sub-object is as follows: 239 0 1 2 3 240 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 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 |S|B| Reserved | Carrier Number | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | Total Bandwidth | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 Figure 2: SSON LSP set-up request 249 Carrier Number: number of carrier to be allocated for the requested 250 channel (16-bit unsigned integer) 251 If Carrier Number == 0 no constraint set on the number of 252 carriers to be used 254 S strict number of subcarrier 255 - S = 0 the number of requested carriers is the maximum number 256 that can be allocated (a lower value can be allocated if 257 the requested bandwidth is satisfied) 258 - S = 1 the number of requested carriers is strict (must be > 0) 260 Total Bandwidth: the requested total bandwidth to be supported by 261 the Media Channel (32-bit IEEE float, bytes/s) 262 If Total Bandwidth == 0: no bandwidth constraint is defined 263 (B must be 0) 265 B Bandwidth constraints 266 - B = 0: the value is the maximum requested bandwidth (a lower 267 value can be allocated if resources are not available) 268 - B = 1: the requested bandwidth is the minimum value to be 269 allocated (a higher value can be allocated if requested 270 by the physical constraints of the ports) 272 Reserved: unused bit (for future use, should be 0) 273 Note: bandwidth unit is defined in accordance to RFC 3471 274 chap. 3.1.2 Bandwith Encoding specification. Bandwidth higher 275 than 40Gb/s values must be defined (e.g. 100Gb/s, 150Gb/s 276 400Gb/s, etc.) or in alternative the OTUCn defined in 277 ITU-T G.709. 279 TLV Usage: 280 Head UNI-C PATH: requested traffic constraints, the Head UNI-N 281 node must satisfy when reserving the optical resources and 282 defining the carriers configuration 283 The TLV can be omitted: no traffic constraints is defined 284 (resources allocated by UNI-N based on a local policy) 286 4.2. Extension to LSP set-up reservation 288 Once the GMPLS has calculated the Media Channel path, the Spectrum 289 Allocation, the Sub-carrier number and frequency, the modulation 290 format, the FEC and the Transmit power, sends back to the E.N. the 291 path set-up confirmation providing the values of the calculated 292 paramenters: 294 Media Channel: 295 (Grid, C.S., Identifier m and n). as indicated in RFC7699 296 Section 4.1 298 Modulation format: 299 This parameter indicates the Modulation Formats to be set in the 300 Transceivers. 302 FEC Coding: 303 This parameter indicate what Forward Error Correction (FEC) code 304 must be used by the Transceivers (not mentioned in G.698). . 306 Bit rate / Baud rate of optical tributary signals: 307 Optical Tributary Signal bit (for NRZ signals) rate or Symbol (for 308 Multiple bit per symbol) rate. 310 List of subcarriers: 311 This parameter indicates the subcarriers to be used for the super- 312 channel (OTSiG) in case the Transceiver can support multiple 313 carrier Circuits. 315 Central frequency granularity (J): 316 This parameter indicates the Central frequency granularity 317 supported by the transceiver, this value is combined with K and n 318 value to calculate the central frequency on the carrier or sub- 319 carriers. 321 Central frequency (see G.694.1 Table 1): 322 Grid, Identifiers, central frequency and granularity. 324 Laser Output power: 325 This parameter provisions the Transceiver Output power, it can be 326 either a setting and measured value. 328 Circuit Path, RRO, etc: 329 All these info are defined in [RFC4208]. 331 Path Error: 332 e.g. no path exist, all the path error defined in [RFC4208]. 334 The TLV defines the carriers signal configuration. 335 All carriers in a Media Channel MUST have the same configuration. 337 The format of this sub-object (Type = TBA, Length = TBA) is 338 as follows: 340 0 1 2 3 341 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 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | Modulation ID | Bit/Symbol | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | FEC | reserved | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | baud rate (Symbol Rate) | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 Figure 3: OCh_General 352 Traffic Type 353 - Modulation ID (Format) : is the modulation type: 354 BPSK, DC DP BSPSK, QPSK, DP QPSK, 8QAM, 16QAM, 355 32QAM, 64QAM, etc. 356 - (ITU-T reference) 357 - Value > 32768 (first bit is 1): custom defined values 358 - Value 0 is reserved to be used if no value is defined 359 - Bits/Symbol(BPS) this indicates the bit per symbol in case of 360 hybrid modulation format. It is an off-set with values from 0 361 to 127 to be applied to the specified Modulation Format and 362 indicates the mix between the selected Modulation Format and its 363 upper adjacent. 364 (e.g. QPSK + 63 BPS indicates that there is a 50% MIX between 365 QPSK and 8-QAM = 2.5 bits per symbol) If value = 0 the 366 standard Modulation Format is applied 367 - FEC: the signal Forward Error Corrections type (16-bit 368 unsigned integer), the defined values are: 369 - 1 to 32767 (ITU-T reference) 370 - 32768 to 65536 (first bit is 1): custom defined values 371 - Value 0 is reserved to be used if no value is defined 372 - Baud Rate: the signal symbol rate (IEEE 32-bit float, 373 in bauds/s) 374 - Value 0 is reserved to be used if no value is defined 376 Notes: 377 - The PATH request from the Head UNI-C node can specify all or 378 only a subset of the parameters (e.g. the Modulation and the 379 baud rate as required but not the FEC) setting to 0 for the 380 undefined parameters. 381 When forwarding the PATH message, the UNI-N will set the 382 undefined parameters based on the optical impairment calculation 383 and the constraints giveng by the UNI-C 384 - Custom codes (values > 0x8000) interpretation is a local 385 installation matter. 387 TLV Usage: 388 - Head UNI-C PATH: used to force specific transponder 389 configurations 390 - Head UNI-N RESV: set selected configuration on head node 391 - Tail UNI-N PATH: set selected configuration on tail node 393 4.2.1. Sub-carrier list content 394 For Each carrier inside the Media Channel the TLV is used. 396 The format of this sub-object (Type = TBA, Length = TBA) 397 is as follows: 399 0 1 2 3 400 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 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | Carrier Identifier | j | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 | k | 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 | sub-TLVs | 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 Figure 4: Sub-Carrier parameters 411 Carrier set-up: 413 - Carrier identifier field: sub-carrier (OTSi) identifier 414 inside the OTSiG (corresponding to the media channel). 415 Identifies the carrier 416 position inside the Media Channel (16-bit unsigned integer) 417 The Carrier Identifier is the logical circuit sub-lane 418 position, a TLV for each value from 1 to the number of 419 allocated carriers must be present. 420 - J field: granularity of the channel spacing, can be a 421 multiple of 0.01GHz. - default value is 0.1GHz. 422 - K field: positive or negative integer (including 0) to multiply 423 by J and identify the Carrier Position inside the 424 Media Channel, offset from media Channel Central frequency 425 - sub-TLVs: additional information related to carriers if needed 426 and the ports associated to the carrier. 428 In summary Carrier Frequency = MC-C.F. (in THz) + K * J GHz. 430 m=8 431 +-------------------------------X------------------------------+ 432 | | | 433 | sub-carrier sub-carrier | 434 | +----------X----------+ | +----------X----------+ | 435 | | OTSi | | OTSi | | 436 | | o | | | o | | 437 | | | | | | | | 438 -4 -3 -2 -1 0 1 2 3 4 5 6 7 8 9 10 11 12 439 -+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+- 440 | n=4 | 441 K1 -236 | +236 K2 443 <------------------------ Media Channel -----------------------> 445 4.2.2. Sub-carrier sub-TLV 447 The defined sub-TLVs are Port Identifiers and Carrier Power 448 Source Port Identifier 450 The format of this sub-object (Type = TBA, Length = TBD) is 451 as follows: 453 0 1 2 3 454 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 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | Type (TBA) | Length (TBD) | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | Source Port Identifier | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 Figure 5: Source Port Identifier 463 Source Port Identifier: the HEAD UNI-C optical logical source end 464 point identifier (32-bits integer, ifindex) 466 TLV Usage: 467 - Head UNI-C PATH: used to force specific carrier ports 468 [optional use, e.g. with external PCE scenario] 469 - Tail UNI-N PATH: report selected arrier head ports 470 to tail UNI-C 471 - RESV: report selected configuration to HEAD UNI-C node 473 Destination Port Identifier 475 The format of this sub-object (Type = TBA, Length = TBD) is 476 as follows: 478 0 1 2 3 479 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 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | Type (TBA) | Length (TBD) | 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | Destination Port Identifier | 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 Figure 6: Destination Port Identifiers 488 Destination Port Identifier: the local upstream optical logical 489 destination end point identifier (32-bits integer, ifindex) 491 TLV Usage: 492 - Head UNI-C PATH: used to force specific carrier ports 493 [optional use, e.g. with external PCE scenario] 494 - Tail UNI-N PATH: set selected configuration on tail node 495 - RESV: report selected configuration to HEAD UNI-C node 497 Carrier Power 499 The format of this sub-object (Type = TBA, Length = TBD) 500 is as follows: 502 0 1 2 3 503 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 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 | Type (TBA) | Length (TBD) | 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 | carrier power | 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 Figure 7: Carrier Power 512 Carrier Power: the requested carrier transmit power (32-bits IEEE 513 Float, dBm), optionally used to notify the configured 514 power (in UNI client side) or force the power to the 515 to the UNI client). 517 TLV Usage: 518 - Head UNI-C PATH: used to force specific carrier frequency/ports 519 (optional use, e.g. with external PCE scenario) 520 - Head UNI-N RESV: set selected configuration on head node 521 - Tail UNI-N PATH: set selected configuration on tail node 523 4.3. RSVP Protocol Extensions considerations 525 The additional information described in the draft, is related to the 526 Media Channel supported traffic. It could be encoded in the 527 SENDER_TSPEC/FLOW_SPEC objects by extending the SSON_SENDER_TSPEC/ 528 SSON_FLOW_SPEC defined in RFC 7792 (or defining a new C-Type) with an 529 optional TLV list or it could be encoded in a newly defined entry 530 (new OBJECT or new LSP_ATTRIBUTES OBJECT TLV) 532 This solution is consistent with other technology specific extensions 533 (e.g. SDH), but requires the explicit handling of the extensions by 534 all nodes. 536 Beside this, some of the additional information defined is local to 537 the head/tail UNI link (e.g. the carrier/port association), while the 538 traffic spec info should be valid end-to-end. 540 There can be different methods to model and signal the carriers as 541 described in draft-lee-ccamp-optical-impairment-topology-yang. The 542 Media Channel, Network Media Channel and lables are well modelled by 543 the RFC7698, RFC7699 and RFC7792 reflecting the ITU-T Recommendations 544 G.694.1 and G.698.2. 546 Some work is in progress in ITU-T SG15/Q12 to define Network Media 547 Channel (group) that is capable of accommodating the optical 548 tributary signals (OTSi) belonging to optical tributary signal group 549 (OTSiG) (see new ITU-T Draft Recommendation G.807). Currently, no 550 models exist (in the IETF nor ITU-T SG15) that define how the optical 551 tributary signals are described inside the Network Media Channel 552 Group in terms of OTSi identifier, OTSi carrier frequency and OTSi 553 signal width. 555 Other the encoding proposal reported in this draft, there are several 556 at least two other methods to describe the parameters. An option is 557 to describe the OTSi carrier frequency relative to the anchor 558 frequency 193.1THz based on a well-defined granularity (e.g. OTSi 559 carrier frequency = 193100 (GHz) + K * granularity (GHz) where K is a 560 signed integer value). A second option is to explicitly describe the 561 OTSi carrier frequency and the OTSi signal width in GHz with a 562 certain accuracy. 564 The second option which is independent of the n, m values already 565 defined in ITU-T Recommendation G.694.1. The OTSi carrier frequency 566 is described in GHz with 3 fractional digits (decimal 64 fraction 567 digits 3). The OTSi signal width is described in GHz with 3 568 fractional digits (decimal 64 fraction digits 3) and includes the 569 signal roll off as well as some guard band. 571 The accuracy of 0.001 GHz does not impose a requirement on the 572 optical transceiver components (optical transmitter) in terms of 573 carrier frequency tunability precision. Today's components typically 574 provide a tunability precision in the range of 1..1.5GHz (carrier 575 frequency offset compared to the configured nominal carrier 576 frequency). Future components may provide a better precision as 577 technology evolves. If needed, a controller may retrieve the 578 transceiver properties in terms of carrier frequency tunability 579 precision in order to be capable of properly configuring the 580 underlying transceiver. 582 NOTE FROM THE EDITORS: As this description is arbitrarily proposed by 583 the authors to cover a lack of information in IETF and ITU-T, a 584 liaison request to ITU-T is needed. The authors are willing to 585 contribute to Liaison editing and to consider any feedback and 586 proposal from ITU-T. 588 5. Security Considerations 590 GMPLS message security uses IPsec, as described in xxxx. This 591 document only defines new UNI objects that are carried in existing 592 UNI messages, similar to the UNI objects in xxx. This document does 593 not introduce new security considerations. 595 6. IANA Considerations 597 T.B.D. 599 7. Contributors 601 Antonello Bonfanti 602 Cisco 603 Via Santa Maria Molgora, 48 c 604 20871 - Vimercate (MB) 605 Italy 606 abonfant@cisco.com 608 8. References 610 8.1. Normative References 612 [ITU.G694.1] 613 International Telecommunications Union, ""Spectral grids 614 for WDM applications: DWDM frequency grid"", 615 ITU-T Recommendation G.698.2, February 2012. 617 [ITU.G698.2] 618 International Telecommunications Union, "Amplified 619 multichannel dense wavelength division multiplexing 620 applications with single channel optical interfaces", 621 ITU-T Recommendation G.698.2, November 2009. 623 [ITU.G709] 624 International Telecommunications Union, "Interface for the 625 Optical Transport Network (OTN)", ITU-T Recommendation 626 G.709, June 2016. 628 [ITU.G872] 629 International Telecommunications Union, "Architecture of 630 optical transport networks", ITU-T Recommendation G.872, 631 January 2017. 633 [ITU.G874.1] 634 International Telecommunications Union, "Optical transport 635 network (OTN): Protocol-neutral management information 636 model for the network element view", ITU-T Recommendation 637 G.874.1, November 2016. 639 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 640 Requirement Levels", BCP 14, RFC 2119, 641 DOI 10.17487/RFC2119, March 1997, 642 . 644 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 645 Switching (GMPLS) Signaling Resource ReserVation Protocol- 646 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 647 DOI 10.17487/RFC3473, January 2003, 648 . 650 [RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label 651 Switching (GMPLS) Architecture", RFC 3945, 652 DOI 10.17487/RFC3945, October 2004, 653 . 655 [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, 656 "Generalized Multiprotocol Label Switching (GMPLS) User- 657 Network Interface (UNI): Resource ReserVation Protocol- 658 Traffic Engineering (RSVP-TE) Support for the Overlay 659 Model", RFC 4208, DOI 10.17487/RFC4208, October 2005, 660 . 662 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 663 Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, 664 . 666 [RFC6163] Lee, Y., Ed., Bernstein, G., Ed., and W. Imajuku, 667 "Framework for GMPLS and Path Computation Element (PCE) 668 Control of Wavelength Switched Optical Networks (WSONs)", 669 RFC 6163, DOI 10.17487/RFC6163, April 2011, 670 . 672 [RFC6205] Otani, T., Ed. and D. Li, Ed., "Generalized Labels for 673 Lambda-Switch-Capable (LSC) Label Switching Routers", 674 RFC 6205, DOI 10.17487/RFC6205, March 2011, 675 . 677 [RFC7698] Gonzalez de Dios, O., Ed., Casellas, R., Ed., Zhang, F., 678 Fu, X., Ceccarelli, D., and I. Hussain, "Framework and 679 Requirements for GMPLS-Based Control of Flexi-Grid Dense 680 Wavelength Division Multiplexing (DWDM) Networks", 681 RFC 7698, DOI 10.17487/RFC7698, November 2015, 682 . 684 [RFC7699] Farrel, A., King, D., Li, Y., and F. Zhang, "Generalized 685 Labels for the Flexi-Grid in Lambda Switch Capable (LSC) 686 Label Switching Routers", RFC 7699, DOI 10.17487/RFC7699, 687 November 2015, . 689 [RFC7792] Zhang, F., Zhang, X., Farrel, A., Gonzalez de Dios, O., 690 and D. Ceccarelli, "RSVP-TE Signaling Extensions in 691 Support of Flexi-Grid Dense Wavelength Division 692 Multiplexing (DWDM) Networks", RFC 7792, 693 DOI 10.17487/RFC7792, March 2016, 694 . 696 8.2. Informative References 698 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 699 DOI 10.17487/RFC2629, June 1999, 700 . 702 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 703 "Introduction and Applicability Statements for Internet- 704 Standard Management Framework", RFC 3410, 705 DOI 10.17487/RFC3410, December 2002, 706 . 708 [RFC4181] Heard, C., Ed., "Guidelines for Authors and Reviewers of 709 MIB Documents", BCP 111, RFC 4181, DOI 10.17487/RFC4181, 710 September 2005, . 712 Authors' Addresses 714 Gabriele Galimberti (editor) 715 Cisco 716 Via S. Maria Molgora, 48 c 717 20871 - Vimercate 718 Italy 720 Phone: +390392091462 721 Email: ggalimbe@cisco.com 722 Domenico La Fauci 723 Cisco 724 Via S. Maria Molgora, 48 c 725 20871 - Vimercate 726 Italy 728 Phone: +390392091946 729 Email: dlafauci@cisco.com 731 Andrea Zanardi (editor) 732 FBK-CreateNet 733 via alla Cascata 56/D 734 38123 Povo, Trento 735 Italy 737 Phone: +390461312450 738 Email: azanardi@fbk.eu 740 Lorenzo Galvagni 741 FBK-CreateNet 742 via alla Cascata 56/D 743 38123 Povo, Trento 744 Italy 746 Phone: +390461312427 747 Email: lgalvagni@fbk.eu