idnits 2.17.1 draft-ggalimbe-ccamp-flexigrid-carrier-label-04.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 (June 28, 2018) is 2129 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'ITU.G698.2' is defined on line 549, but no explicit reference was found in the text == Unused Reference: 'ITU.G709' is defined on line 555, but no explicit reference was found in the text == Unused Reference: 'ITU.G874.1' is defined on line 565, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 571, but no explicit reference was found in the text == Unused Reference: 'RFC3473' is defined on line 576, but no explicit reference was found in the text == Unused Reference: 'RFC3945' is defined on line 582, but no explicit reference was found in the text == Unused Reference: 'RFC5920' is defined on line 594, but no explicit reference was found in the text == Unused Reference: 'RFC6163' is defined on line 598, but no explicit reference was found in the text == Unused Reference: 'RFC7699' is defined on line 616, but no explicit reference was found in the text == Unused Reference: 'RFC2629' is defined on line 630, but no explicit reference was found in the text == Unused Reference: 'RFC3410' is defined on line 634, but no explicit reference was found in the text == Unused Reference: 'RFC4181' is defined on line 640, 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: December 30, 2018 A. Zanardi, Ed. 6 L. Galvagni 7 FBK-CreateNet 8 June 28, 2018 10 Signaling extensions for Media Channel sub-carriers configuration in 11 Spectrum Switched Optical Networks (SSON) in Lambda Switch Capable (LSC) 12 Optical Line Systems. 13 draft-ggalimbe-ccamp-flexigrid-carrier-label-04 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 December 30, 2018. 46 Copyright Notice 48 Copyright (c) 2018 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Client interface parameters . . . . . . . . . . . . . . . . . 3 65 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 4. Signalling Extensions . . . . . . . . . . . . . . . . . . . . 5 67 4.1. New LSP set-up parameters . . . . . . . . . . . . . . . . 5 68 4.2. Extension to LSP set-up reservation . . . . . . . . . . . 7 69 4.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 . . . . . . . . . . . . . . . . . . . 13 73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 74 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13 75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 76 8.1. Normative References . . . . . . . . . . . . . . . . . . 13 77 8.2. Informative References . . . . . . . . . . . . . . . . . 15 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 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 5. Security Considerations 522 GMPLS message security uses IPsec, as described in xxxx. This 523 document only defines new UNI objects that are carried in existing 524 UNI messages, similar to the UNI objects in xxx. This document does 525 not introduce new security considerations. 527 6. IANA Considerations 529 T.B.D. 531 7. Contributors 533 Antonello Bonfanti 534 Cisco 535 Via Santa Maria Molgora, 48 c 536 20871 - Vimercate (MB) 537 Italy 538 abonfant@cisco.com 540 8. References 542 8.1. Normative References 544 [ITU.G694.1] 545 International Telecommunications Union, ""Spectral grids 546 for WDM applications: DWDM frequency grid"", 547 ITU-T Recommendation G.698.2, February 2012. 549 [ITU.G698.2] 550 International Telecommunications Union, "Amplified 551 multichannel dense wavelength division multiplexing 552 applications with single channel optical interfaces", 553 ITU-T Recommendation G.698.2, November 2009. 555 [ITU.G709] 556 International Telecommunications Union, "Interface for the 557 Optical Transport Network (OTN)", ITU-T Recommendation 558 G.709, February 2012. 560 [ITU.G872] 561 International Telecommunications Union, "Architecture of 562 optical transport networks", ITU-T Recommendation G.872, 563 October 2012. 565 [ITU.G874.1] 566 International Telecommunications Union, "Optical transport 567 network (OTN): Protocol-neutral management information 568 model for the network element view", ITU-T Recommendation 569 G.874.1, October 2012. 571 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 572 Requirement Levels", BCP 14, RFC 2119, 573 DOI 10.17487/RFC2119, March 1997, 574 . 576 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 577 Switching (GMPLS) Signaling Resource ReserVation Protocol- 578 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 579 DOI 10.17487/RFC3473, January 2003, 580 . 582 [RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label 583 Switching (GMPLS) Architecture", RFC 3945, 584 DOI 10.17487/RFC3945, October 2004, 585 . 587 [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, 588 "Generalized Multiprotocol Label Switching (GMPLS) User- 589 Network Interface (UNI): Resource ReserVation Protocol- 590 Traffic Engineering (RSVP-TE) Support for the Overlay 591 Model", RFC 4208, DOI 10.17487/RFC4208, October 2005, 592 . 594 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 595 Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, 596 . 598 [RFC6163] Lee, Y., Ed., Bernstein, G., Ed., and W. Imajuku, 599 "Framework for GMPLS and Path Computation Element (PCE) 600 Control of Wavelength Switched Optical Networks (WSONs)", 601 RFC 6163, DOI 10.17487/RFC6163, April 2011, 602 . 604 [RFC6205] Otani, T., Ed. and D. Li, Ed., "Generalized Labels for 605 Lambda-Switch-Capable (LSC) Label Switching Routers", 606 RFC 6205, DOI 10.17487/RFC6205, March 2011, 607 . 609 [RFC7698] Gonzalez de Dios, O., Ed., Casellas, R., Ed., Zhang, F., 610 Fu, X., Ceccarelli, D., and I. Hussain, "Framework and 611 Requirements for GMPLS-Based Control of Flexi-Grid Dense 612 Wavelength Division Multiplexing (DWDM) Networks", 613 RFC 7698, DOI 10.17487/RFC7698, November 2015, 614 . 616 [RFC7699] Farrel, A., King, D., Li, Y., and F. Zhang, "Generalized 617 Labels for the Flexi-Grid in Lambda Switch Capable (LSC) 618 Label Switching Routers", RFC 7699, DOI 10.17487/RFC7699, 619 November 2015, . 621 [RFC7792] Zhang, F., Zhang, X., Farrel, A., Gonzalez de Dios, O., 622 and D. Ceccarelli, "RSVP-TE Signaling Extensions in 623 Support of Flexi-Grid Dense Wavelength Division 624 Multiplexing (DWDM) Networks", RFC 7792, 625 DOI 10.17487/RFC7792, March 2016, 626 . 628 8.2. Informative References 630 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 631 DOI 10.17487/RFC2629, June 1999, 632 . 634 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 635 "Introduction and Applicability Statements for Internet- 636 Standard Management Framework", RFC 3410, 637 DOI 10.17487/RFC3410, December 2002, 638 . 640 [RFC4181] Heard, C., Ed., "Guidelines for Authors and Reviewers of 641 MIB Documents", BCP 111, RFC 4181, DOI 10.17487/RFC4181, 642 September 2005, . 644 Authors' Addresses 646 Gabriele Galimberti (editor) 647 Cisco 648 Via S. Maria Molgora, 48 c 649 20871 - Vimercate 650 Italy 652 Phone: +390392091462 653 Email: ggalimbe@cisco.com 654 Domenico La Fauci 655 Cisco 656 Via S. Maria Molgora, 48 c 657 20871 - Vimercate 658 Italy 660 Phone: +390392091946 661 Email: dlafauci@cisco.com 663 Andrea Zanardi (editor) 664 FBK-CreateNet 665 via alla Cascata 56/D 666 38123 Povo, Trento 667 Italy 669 Phone: +390461312450 670 Email: azanardi@fbk.eu 672 Lorenzo Galvagni 673 FBK-CreateNet 674 via alla Cascata 56/D 675 38123 Povo, Trento 676 Italy 678 Phone: +390461312427 679 Email: lgalvagni@fbk.eu