idnits 2.17.1 draft-ggalimbe-ccamp-flexigrid-carrier-label-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([ITU.G872], [ITU.G694.1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (March 11, 2019) is 1871 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'ITU.G698.2' is defined on line 597, but no explicit reference was found in the text == Unused Reference: 'ITU.G709' is defined on line 603, but no explicit reference was found in the text == Unused Reference: 'ITU.G874.1' is defined on line 613, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 619, but no explicit reference was found in the text == Unused Reference: 'RFC3473' is defined on line 624, but no explicit reference was found in the text == Unused Reference: 'RFC3945' is defined on line 630, but no explicit reference was found in the text == Unused Reference: 'RFC5920' is defined on line 642, but no explicit reference was found in the text == Unused Reference: 'RFC6163' is defined on line 646, but no explicit reference was found in the text == Unused Reference: 'RFC7699' is defined on line 664, but no explicit reference was found in the text == Unused Reference: 'RFC2629' is defined on line 678, but no explicit reference was found in the text == Unused Reference: 'RFC3410' is defined on line 682, but no explicit reference was found in the text == Unused Reference: 'RFC4181' is defined on line 688, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 1 error (**), 0 flaws (~~), 14 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force G. Galimberti, Ed. 3 Internet-Draft D. La Fauci 4 Intended status: Experimental Cisco 5 Expires: September 12, 2019 A. Zanardi, Ed. 6 L. Galvagni 7 FBK-CreateNet 8 March 11, 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-06 15 Abstract 17 This memo defines the signaling extensions for managing Spectrum 18 Switched Optical Network (SSON) parameters shared between the Client 19 and the Network and inside the Network in accordance to the model 20 described in RFC 7698. The extensions are in accordance and 21 extending the parameters defined in ITU-T Recommendation 22 G.694.1.[ITU.G694.1] and its extensions and G.872.[ITU.G872]. 24 Copyright Notice 26 Copyright (c) 2011 IETF Trust and the persons identified as the 27 document authors. All rights reserved. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on September 12, 2019. 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 . . . . . . . . . . . . . . . . . 10 71 4.3. RSVP Protocol Extensions considerations . . . . . . . . . 12 72 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 74 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14 75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 76 8.1. Normative References . . . . . . . . . . . . . . . . . . 14 77 8.2. Informative References . . . . . . . . . . . . . . . . . 16 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 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 available for 133 the super-channel in case the Transceiver can support multiple 134 carrier circuits. 136 Central frequency (see G.694.1 Table 1): 137 This parameter indicates the Central frequency value that Ss and 138 Rs will be set to work (in THz). See the details in Section 6/ 139 G.694.1 or based on "n" value explanation and the following "k" 140 values definition in case of multicarrier transceivers. 142 Central frequency granularity: 143 This parameter indicates the Central frequency granularity 144 supported by the transceiver, this value is combined with k and n 145 value to calculate the central frequency of the carrier or sub- 146 carriers. 148 Minimum channel spacing: 149 This is the minimum nominal difference in frequency (in GHz) 150 between two adjacent channels (or carriers) depending on the 151 Transceiver characteristics. 153 Bit rate / Baud rate of optical tributary signals: 154 Optical Tributary Signal bit (for NRZ signals) rate or Symbol (for 155 Multiple bit per symbol) rate . 157 FEC Coding: 158 This parameter indicate what Forward Error Correction (FEC) code 159 is used at Ss and Rs (R/W) (not mentioned in G.698.2). . 161 Wavelength Range (see G.694.1): [ITU.G694.1] 162 This parameter indicate minimum and maximum wavelength spectrum in 163 a definite wavelength Band (L, C and S). 165 Modulation format: 166 This parameter indicates the list of supported Modulation Formats 167 and the provisioned Modulation Format.. 169 Inter carrier skew: 170 This parameter indicates, in case of multi-carrier transceivers 171 the maximum skew between the sub-carriers supported by the 172 transceiver. 174 Laser Output power: 175 This parameter provisions the Transceiver Output power, it can be 176 either a setting and measured value. 178 receiver input power: 179 This parameter provisions the Min and MAX input pover suppotred by 180 the Transceiver, i.e. Receiver Sensitivity. 182 The above parameters are related to the Edge Node Transceiver and are 183 used by the Core Network GMPLS in order to calculate the optical 184 feasibility and the spectrum allocation. The parameters can be 185 shared between the Client and the Network via LMP or provisioned to 186 the Network by an EMS or an operator OSS. 188 3. Use Cases 190 The use cases are described in draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk 191 and [RFC7698] 193 4. Signalling Extensions 195 Some of the above parameters can be applied to RFC7792 (SENDER_TSPEC/ 196 FLOWSPEC). The above parameters could be applied to [RFC4208] 197 scenarios but they are valid also in case of non UNI scenarios. The 198 [RFC6205] parameters remain valid. 200 4.1. New LSP set-up parameters 202 When the E.N. wants to request to the C.N. a new circuit set-up 203 request or the GMPLS wants to signal in the SSON network the Optical 204 Interface characteristics the following parameters will be provided 205 to the C.N.: 207 Number of available subcarriers (c): 208 This parameter is an integer and identifies the number of Client 209 ports connected to the Core ports available to suport the 210 requested circuit 212 Total bandwidth request: 213 e.g. 200Gb, 400Gb, 1Tb - it is the bandwidth (payload) to be 214 carried by the multiple carrier circuit 216 Policy (strict/loose): 217 Strict/loose referred to B/W and subcarrier number. This is to 218 give some flexibility to the GMPLS in order to commit client 219 request. 221 Subcarrier bandwidth tunability: 222 (optional) e.g. 34Ghz, 48GHz. 224 The TLV define the resource constraints for the requested Media 225 Channel. 227 The format of the this sub-object is as follows: 229 0 1 2 3 230 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 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 |S|B| Reserved | Carrier Number | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | Total Bandwidth | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 Figure 2: SSON LSP set-up request 239 Carrier Number: number of carrier to be allocated for the requested 240 channel (16-bit unsigned integer) 241 If Carrier Number == 0 no constraint set on the number of 242 carriers to be used 244 S strict number of subcarrier 245 - S = 0 the number of requested carriers is the maximum number 246 that can be allocated (a lower value can be allocated if 247 the requested bandwidth is satisfied) 248 - S = 1 the number of requested carriers is strict (must be > 0) 250 Total Bandwidth: the requested total bandwidth to be supported by 251 the Media Channel (32-bit IEEE float, bytes/s) 252 If Total Bandwidth == 0: no bandwidth constraint is defined 253 (B must be 0) 255 B Bandwidth constraints 256 - B = 0: the value is the maximum requested bandwidth (a lower 257 value can be allocated if resources are not available) 258 - B = 1: the requested bandwidth is the minimum value to be 259 allocated (a higher value can be allocated if requested 260 by the physical constraints of the ports) 262 Reserved: unused bit (for future use, should be 0) 263 Note: bandwidth unit is defined in accordance to RFC 3471 264 chap. 3.1.2 Bandwith Encoding specification. Bandwidth higher 265 than 40Gb/s values must be defined (e.g. 100Gb/s, 150Gb/s 266 400Gb/s, etc.) 268 TLV Usage: 269 Head UNI-C PATH: requested traffic constraints, the Head UNI-N node 270 must satisfy when reserving the optical resources and defining 271 the carriers configuration 272 The TLV can be omitted: no traffic constraints is defined (resources 273 allocated by UNI-N based on a local policy) 275 4.2. Extension to LSP set-up reservation 277 Once the GMPLS has calculated the Media Channel path, the Spectrum 278 Allocation, the Sub-carrier number and frequency, the modulation 279 format, the FEC and the Transmit power, sends back to the E.N. the 280 path set-up confirmation providing the values of the calculated 281 paramenters: 283 Media Channel: 284 (Grid, C.S., Identifier m and n). as indicated in RFC7699 285 Section 4.1 287 Modulation format: 288 This parameter indicates the Modulation Formats to be set in the 289 Transceivers. 291 FEC Coding: 292 This parameter indicate what Forward Error Correction (FEC) code 293 must be used by the Transceivers (not mentioned in G.698). . 295 Bit rate / Baud rate of optical tributary signals: 296 Optical tributary signal bit (for NRZ signals) rate or Symbol (for 297 Multiple bit per symbol) rate. 299 List of subcarriers: 300 This parameter indicates the subcarriers to be used for the super- 301 channel in case the Transceiver can support multiple carrier 302 Circuits. 304 Central frequency granularity (J): 305 This parameter indicates the Central frequency granularity 306 supported by the transceiver, this value is combined with K and n 307 value to calculate the central frequency on the carrier or sub- 308 carriers. 310 Central frequency (see G.694.1 Table 1): 312 Grid, Identifiers, central frequency and granularity. 314 Laser Output power: 315 This parameter provisions the Transceiver Output power, it can be 316 either a setting and measured value. 318 Circuit Path, RRO, etc: 319 All these info are defined in [RFC4208]. 321 Path Error: 322 e.g. no path exist, all the path error defined in [RFC4208]. 324 The TLV defines the carriers signal configuration. 325 All carriers in a Media Channel MUST have the same configuration. 327 The format of this sub-object (Type = TBA, Length = TBA) is 328 as follows: 330 0 1 2 3 331 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 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | Modulation Format | FEC | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | baud rate (Symbol Rate) | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 Figure 3: OCh_General 340 Traffic Type 341 - Modulation Format: is the modulation type: 342 BPSK, DC DP BSPSK, QPSK, DP QPSK, 8QAM, 16QAM, 64QAM, 343 Hybrid, etc. 344 - (ITU-T reference) 345 - value > 32768 (first bit is 1): custom defined values 346 Value 0 is reserved to be used if no value is defined 347 - FEC: the signal Forward Error Corrections type (16-bit 348 unsigned integer), the defined values are: 349 - (ITU-T reference) 350 - 32768 (first bit is 1): custom defined values 351 Value 0 is reserved to be used if no value is defined 352 - Baud Rate: the signal symbol rate (IEEE 32-bit float, 353 in bauds/s) 354 Value 0 is reserved to be used if no value is defined 356 Notes: 357 - The PATH request from the Head UNI-C node can specify all or 358 only a subset of the parameters (e.g. the Modulation and the 359 baud rate as required but not the FEC) setting to 0 for the 360 undefined parameters. 361 When forwarding the PATH message, the UNI-N will set the 362 undefined parameters based on the optical impairment calculation 363 and the constraints giveng by the UNI-C 364 - Custom codes (values > 0x8000) interpretation is a local 365 installation matter. 367 TLV Usage: 368 - Head UNI-C PATH: used to force specific transponder 369 configurations 370 - Head UNI-N RESV: set selected configuration on head node 371 - Tail UNI-N PATH: set selected configuration on tail node 373 4.2.1. Sub-carrier list content 375 For Each carrier inside the Media Channel the TLV is used. 377 The format of this sub-object (Type = TBA, Length = TBA) 378 is as follows: 380 0 1 2 3 381 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 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | Carrier Identifier | j | 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | k | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | sub-TLVs | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 Figure 4: Sub-Carrier parameters 392 Carrier set-up: 394 - Carrier identifier field: sub-carrier 395 identifier inside the mediachannel. Identifies the carrier 396 position inside the Media Channel (16-bit unsigned integer) 397 The Carrier Identifier is the logical circuit sub-lane 398 position, a TLV for each value from 1 to the number of 399 allocated carriers must be present. 400 - J field: granularity of the channel spacing, can be a 401 multiple of 0.01GHz. - default value is 0.1GHz. 402 - K field: positive or negative integer (including 0) to multiply 403 by J and identify the Carrier Position inside the 404 Media Channel, offset from media Channel Central frequency 405 - sub-TLVs: additional information related to carriers if needed 406 and the ports associated to the carrier. 408 In summary Carrier Frequency = MC-C.F. (in THz) + K * J GHz. 410 m=8 411 +-------------------------------X------------------------------+ 412 | | | 413 | sub-carrier sub-carrier | 414 | +----------X----------+ | +----------X----------+ | 415 | | OTSi | | OTSi | | 416 | | o | | | o | | 417 | | | | | | | | 418 -4 -3 -2 -1 0 1 2 3 4 5 6 7 8 9 10 11 12 419 --+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+- 420 | n=4 | 421 K1 -236 | +236 K2 423 <------------------------ Media Channel -----------------------> 425 4.2.2. Sub-carrier sub-TLV 427 The defined sub-TLVs are Port Identifiers and Carrier Power 428 Source Port Identifier 430 The format of this sub-object (Type = TBA, Length = TBD) is 431 as follows: 433 0 1 2 3 434 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 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 | Type (TBA) | Length (TBD) | 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 | Source Port Identifier | 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 Figure 5: Source Port Identifier 443 Source Port Identifier: the HEAD UNI-C optical logical source end 444 point identifier (32-bits integer, ifindex) 446 TLV Usage: 447 - Head UNI-C PATH: used to force specific carrier ports 448 [optional use, e.g. with external PCE scenario] 449 - Tail UNI-N PATH: report selected arrier head ports 450 to tail UNI-C 451 - RESV: report selected configuration to HEAD UNI-C node 453 Destination Port Identifier 455 The format of this sub-object (Type = TBA, Length = TBD) is 456 as follows: 458 0 1 2 3 459 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 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 | Type (TBA) | Length (TBD) | 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | Destination Port Identifier | 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 Figure 6: Destination Port Identifiers 468 Destination Port Identifier: the local upstream optical logical 469 destination end point identifier (32-bits integer, ifindex) 471 TLV Usage: 472 - Head UNI-C PATH: used to force specific carrier ports 473 [optional use, e.g. with external PCE scenario] 474 - Tail UNI-N PATH: set selected configuration on tail node 475 - RESV: report selected configuration to HEAD UNI-C node 477 Carrier Power 479 The format of this sub-object (Type = TBA, Length = TBD) 480 is as follows: 482 0 1 2 3 483 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 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 | Type (TBA) | Length (TBD) | 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | carrier power | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 Figure 7: Carrier Power 492 Carrier Power: the requested carrier transmit power (32-bits IEEE 493 Float, dBm), optionally used to notify the configured 494 power (in UNI client side) or force the power to the 495 to the UNI client). 497 TLV Usage: 498 - Head UNI-C PATH: used to force specific carrier frequency/ports 499 (optional use, e.g. with external PCE scenario) 500 - Head UNI-N RESV: set selected configuration on head node 501 - Tail UNI-N PATH: set selected configuration on tail node 503 4.3. RSVP Protocol Extensions considerations 505 The additional information described in the draft, is related to the 506 Media Channel supported traffic. It could be encoded in the 507 SENDER_TSPEC/FLOW_SPEC objects by extending the SSON_SENDER_TSPEC/ 508 SSON_FLOW_SPEC defined in RFC 7792 (or defining a new C-Type) with an 509 optional TLV list or it could be encoded in a newly defined entry 510 (new OBJECT or new LSP_ATTRIBUTES OBJECT TLV) 512 This solution is consistent with other technology specific extensions 513 (e.g. SDH), but requires the explicit handling of the extensions by 514 all nodes. 516 Beside this, some of the additional information defined is local to 517 the head/tail UNI link (e.g. the carrier/port association), while the 518 traffic spec info should be valid end-to-end. 520 There can be different methods to model and signal the carriers as 521 described in draft-lee-ccamp-optical-impairment-topology-yang. The 522 Media Channel, Network Media Channel and lables are well modelled by 523 the RFC7698, RFC7699 and RFC7792 reflecting the ITU-T Recommendations 524 G.694.1 and G.698.2. 526 Some work is in progress in ITU-T SG15/Q12 to define Network Media 527 Channel (group) that is capable of accommodating the optical 528 tributary signals (OTSi) belonging to optical tributary signal group 529 (OTSiG) (see new ITU-T Draft Recommendation G.807). Currently, no 530 models exist (in the IETF nor ITU-T SG15) that define how the optical 531 tributary signals are described inside the Network Media Channel 532 Group in terms of OTSi identifier, OTSi carrier frequency and OTSi 533 signal width. 535 Other the encoding proposal reported in this draft, there are several 536 at least two other methods to describe the parameters. An option is 537 to describe the OTSi carrier frequency relative to the anchor 538 frequency 193.1THz based on a well-defined granularity (e.g. OTSi 539 carrier frequency = 193100 (GHz) + K * granularity (GHz) where K is a 540 signed integer value). A second option is to explicitly describe the 541 OTSi carrier frequency and the OTSi signal width in GHz with a 542 certain accuracy. 544 The second option which is independent of the n, m values already 545 defined in ITU-T Recommendation G.694.1. The OTSi carrier frequency 546 is described in GHz with 3 fractional digits (decimal 64 fraction 547 digits 3). The OTSi signal width is described in GHz with 3 548 fractional digits (decimal 64 fraction digits 3) and includes the 549 signal roll off as well as some guard band. 551 The accuracy of 0.001 GHz does not impose a requirement on the 552 optical transceiver components (optical transmitter) in terms of 553 carrier frequency tunability precision. Today's components typically 554 provide a tunability precision in the range of 1..1.5GHz (carrier 555 frequency offset compared to the configured nominal carrier 556 frequency). Future components may provide a better precision as 557 technology evolves. If needed, a controller may retrieve the 558 transceiver properties in terms of carrier frequency tunability 559 precision in order to be capable of properly configuring the 560 underlying transceiver. 562 NOTE FROM THE EDITORS: As this description is arbitrarily proposed by 563 the authors to cover a lack of information in IETF and ITU-T, a 564 liaison request to ITU-T is needed. The authors are willing to 565 contribute to Liaison editing and to consider any feedback and 566 proposal from ITU-T. 568 5. Security Considerations 570 GMPLS message security uses IPsec, as described in xxxx. This 571 document only defines new UNI objects that are carried in existing 572 UNI messages, similar to the UNI objects in xxx. This document does 573 not introduce new security considerations. 575 6. IANA Considerations 577 T.B.D. 579 7. Contributors 581 Antonello Bonfanti 582 Cisco 583 Via Santa Maria Molgora, 48 c 584 20871 - Vimercate (MB) 585 Italy 586 abonfant@cisco.com 588 8. References 590 8.1. Normative References 592 [ITU.G694.1] 593 International Telecommunications Union, ""Spectral grids 594 for WDM applications: DWDM frequency grid"", 595 ITU-T Recommendation G.698.2, February 2012. 597 [ITU.G698.2] 598 International Telecommunications Union, "Amplified 599 multichannel dense wavelength division multiplexing 600 applications with single channel optical interfaces", 601 ITU-T Recommendation G.698.2, November 2009. 603 [ITU.G709] 604 International Telecommunications Union, "Interface for the 605 Optical Transport Network (OTN)", ITU-T Recommendation 606 G.709, June 2016. 608 [ITU.G872] 609 International Telecommunications Union, "Architecture of 610 optical transport networks", ITU-T Recommendation G.872, 611 January 2017. 613 [ITU.G874.1] 614 International Telecommunications Union, "Optical transport 615 network (OTN): Protocol-neutral management information 616 model for the network element view", ITU-T Recommendation 617 G.874.1, November 2016. 619 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 620 Requirement Levels", BCP 14, RFC 2119, 621 DOI 10.17487/RFC2119, March 1997, 622 . 624 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 625 Switching (GMPLS) Signaling Resource ReserVation Protocol- 626 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 627 DOI 10.17487/RFC3473, January 2003, 628 . 630 [RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label 631 Switching (GMPLS) Architecture", RFC 3945, 632 DOI 10.17487/RFC3945, October 2004, 633 . 635 [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, 636 "Generalized Multiprotocol Label Switching (GMPLS) User- 637 Network Interface (UNI): Resource ReserVation Protocol- 638 Traffic Engineering (RSVP-TE) Support for the Overlay 639 Model", RFC 4208, DOI 10.17487/RFC4208, October 2005, 640 . 642 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 643 Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, 644 . 646 [RFC6163] Lee, Y., Ed., Bernstein, G., Ed., and W. Imajuku, 647 "Framework for GMPLS and Path Computation Element (PCE) 648 Control of Wavelength Switched Optical Networks (WSONs)", 649 RFC 6163, DOI 10.17487/RFC6163, April 2011, 650 . 652 [RFC6205] Otani, T., Ed. and D. Li, Ed., "Generalized Labels for 653 Lambda-Switch-Capable (LSC) Label Switching Routers", 654 RFC 6205, DOI 10.17487/RFC6205, March 2011, 655 . 657 [RFC7698] Gonzalez de Dios, O., Ed., Casellas, R., Ed., Zhang, F., 658 Fu, X., Ceccarelli, D., and I. Hussain, "Framework and 659 Requirements for GMPLS-Based Control of Flexi-Grid Dense 660 Wavelength Division Multiplexing (DWDM) Networks", 661 RFC 7698, DOI 10.17487/RFC7698, November 2015, 662 . 664 [RFC7699] Farrel, A., King, D., Li, Y., and F. Zhang, "Generalized 665 Labels for the Flexi-Grid in Lambda Switch Capable (LSC) 666 Label Switching Routers", RFC 7699, DOI 10.17487/RFC7699, 667 November 2015, . 669 [RFC7792] Zhang, F., Zhang, X., Farrel, A., Gonzalez de Dios, O., 670 and D. Ceccarelli, "RSVP-TE Signaling Extensions in 671 Support of Flexi-Grid Dense Wavelength Division 672 Multiplexing (DWDM) Networks", RFC 7792, 673 DOI 10.17487/RFC7792, March 2016, 674 . 676 8.2. Informative References 678 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 679 DOI 10.17487/RFC2629, June 1999, 680 . 682 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 683 "Introduction and Applicability Statements for Internet- 684 Standard Management Framework", RFC 3410, 685 DOI 10.17487/RFC3410, December 2002, 686 . 688 [RFC4181] Heard, C., Ed., "Guidelines for Authors and Reviewers of 689 MIB Documents", BCP 111, RFC 4181, DOI 10.17487/RFC4181, 690 September 2005, . 692 Authors' Addresses 694 Gabriele Galimberti (editor) 695 Cisco 696 Via S. Maria Molgora, 48 c 697 20871 - Vimercate 698 Italy 700 Phone: +390392091462 701 Email: ggalimbe@cisco.com 702 Domenico La Fauci 703 Cisco 704 Via S. Maria Molgora, 48 c 705 20871 - Vimercate 706 Italy 708 Phone: +390392091946 709 Email: dlafauci@cisco.com 711 Andrea Zanardi (editor) 712 FBK-CreateNet 713 via alla Cascata 56/D 714 38123 Povo, Trento 715 Italy 717 Phone: +390461312450 718 Email: azanardi@fbk.eu 720 Lorenzo Galvagni 721 FBK-CreateNet 722 via alla Cascata 56/D 723 38123 Povo, Trento 724 Italy 726 Phone: +390461312427 727 Email: lgalvagni@fbk.eu