idnits 2.17.1 draft-ietf-ccamp-grid-property-lmp-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 ([G.694.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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: And for ports on a link that do not have any grid properties in common, the link and its properties SHOULD not be advertised. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: As described in [RFC7698], the control plane MAY include support for neighbor discovery such that a flexi-grid network can be constructed in a "plug-and-play" manner. The control plane SHOULD allow the nodes at opposite ends of a link to correlate the properties that they will apply to the link. Such a correlation SHOULD include at least the identities of the nodes and the identities that they apply to the link. As described in this draft, for ports on a link that do not have any grid properties in common, the link and its properties SHOULD not be advertised to the PCE or other nodes in the same domain. Especially in the scenario of inter-domain, LMP can not be replaced by some other protocol. For example, if Path Computation Element (PCE) or a serial of PCEs coordinate to compute an end-to-end path which crosses more than one domain, it should take the inter-domain grid properties into consideration. Given the OSPF can not advertise the attributes of the border device on the other side, the inter-domain attributes must be negotiated in advance, otherwise the end-to-end path may not be set up successfully. -- The document date (September 22, 2016) is 2772 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '25' on line 208 -- Looks like a reference, but probably isn't: '200' on line 208 -- Possible downref: Non-RFC (?) normative reference: ref. 'G.694.1' -- Possible downref: Non-RFC (?) normative reference: ref. 'G.694.2' Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Q. Wang, Ed. 3 Internet-Draft ZTE 4 Intended status: Standards Track G. Zhang, Ed. 5 Expires: March 26, 2017 CAICT 6 Y. Li 7 Nanjing University 8 R. Casellas 9 CTTC 10 Y. Wang 11 CAICT 12 September 22, 2016 14 Link Management Protocol Extensions for Grid Property Negotiation 15 draft-ietf-ccamp-grid-property-lmp-04 17 Abstract 19 ITU-T [G.694.1] introduces the flexible-grid DWDM technique, which 20 provides a new tool that operators can implement to provide a higher 21 degree of network optimization than is possible with fixed-grid 22 systems. This document describes the extensions to the Link 23 Management Protocol (LMP) to negotiate link grid property between the 24 adjacent DWDM nodes before the link is brought up. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on March 26, 2017. 43 Copyright Notice 45 Copyright (c) 2016 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Requirements for Grid Property Negotiation . . . . . . . . . 3 64 3.1. Flexi-fixed Grid Nodes Interworking . . . . . . . . . . . 3 65 3.2. Flexible-Grid Capability Negotiation . . . . . . . . . . 4 66 3.3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 4. Application of Grid Property Negotiation . . . . . . . . . . 5 68 5. LMP extensions . . . . . . . . . . . . . . . . . . . . . . . 6 69 5.1. Grid Property Subobject . . . . . . . . . . . . . . . . . 6 70 6. Messages Exchange Procedure . . . . . . . . . . . . . . . . . 7 71 6.1. Flexi-fixed Grid Nodes Messages Exchange . . . . . . . . 7 72 6.2. Flexible Nodes Messages Exchange . . . . . . . . . . . . 9 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 74 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 75 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 76 10. Contributing Authors . . . . . . . . . . . . . . . . . . . . 10 77 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 78 11.1. Normative References . . . . . . . . . . . . . . . . . . 10 79 11.2. Informative References . . . . . . . . . . . . . . . . . 11 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 82 1. Introduction 84 ITU-T [G.694.1] introduces the flexible-grid DWDM technique, which 85 provides a new tool that operators can implement to provide a higher 86 degree of network optimization than is possible with fixed-grid 87 systems. A flexible-grid network supports allocating a variable- 88 sized spectral slot to a channel. Flexible-grid DWDM transmission 89 systems can allocate their channels with different spectral 90 bandwidths/slot widths so that they can be optimized for the 91 bandwidth requirements of the particular bit rate and modulation 92 scheme of the individual channels. This technique is regarded to be 93 a promising way to improve the spectrum utilization efficiency and 94 can be used in the beyond 100Gbit/s transport systems. 96 Fixed-grid DWDM system is regarded as a special case of Flexi-grid 97 DWDM. It is expected that fixed-grid optical nodes will be gradually 98 replaced by flexible nodes and interworking between fixed-grid DWDM 99 and flexible-grid DWDM nodes will be needed as the network evolves. 100 Additionally, even two flexible-grid optical nodes may have different 101 grid properties based on the filtering component characteristics, 102 thus need to negotiate on the specific parameters to be used during 103 neighbor discovery process [RFC7698]. This document describes the 104 extensions to the Link Management Protocol (LMP) to negotiate a link 105 grid property between two adjacent nodes before the link is brought 106 up. 108 1.1. Conventions Used in This Document 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in [RFC2119]. 114 2. Terminology 116 For the flexible-grid DWDM, the spectral resource is called frequency 117 slot which is represented by the central frequency and the slot 118 width. The definition of nominal central frequency, nominal central 119 frequency granularity, slot width and slot width granularity can be 120 referred to [RFC7698]. 122 In this contribution, some definitions are listed below except those 123 defined in [RFC7698]: 125 Tuning range: It describes the supported spectrum slot range of the 126 switching nodes or interfaces. It is represented by the supported 127 minimal slot width and the maximum slot width. 129 Channel spacing: It is used in traditional fixed-grid network to 130 identify spectrum spacing between two adjacent channels. 132 3. Requirements for Grid Property Negotiation 134 3.1. Flexi-fixed Grid Nodes Interworking 136 Figure 1 shows an example of interworking between flexible and fixed- 137 grid nodes. Node A, B, D and E support flexible-grid. All these 138 nodes can support frequency slots with a central frequency 139 granularity of 6.25 GHz and slot width granularity of 12.5 GHz. 140 Given the flexibility in flexible-grid nodes, it is possible to 141 configure the nodes in such a way that the central frequencies and 142 slot width parameters are backwards compatible with the fixed DWDM 143 grids (adjacent flexible frequency slots with channel spacing of 144 8*6.25 and slot width of 4*12.5 GHz is equivalent to fixed DWDM grids 145 with channel spacing of 50 GHz). 147 As node C can only support the fixed-grid DWDM property with channel 148 spacing of 50 GHz, to establish a LSP through node B, C, D, the links 149 between B to C and C to D must set to align with the fixed-grid 150 values. This link grid property must be negotiated before 151 establishing the LSP. 153 +---+ +---+ +---+ +---+ +---+ 154 | A |---------| B |=========| C |=========| D +--------+ E | 155 +---+ +---+ +---+ +---+ +---+ 157 Figure 1: Interworking between flexible and fixed-grid nodes 159 ^ ^ ^ ^ 160 ------->|<----50GHz---->|<----50GHz---->|<----50GHz---->|<------ 161 ..... | | | | ..... 162 +-------+-------+-------+-------+-------+--------+------+-------+- 163 n=-2 -1 0 1 2 164 Fixed channel spacing of 50 GHz (Node C) 165 ^ ^ ^ ^ 166 | | | | 167 --------+---------------+---------------+---------------+--------- 168 ..... | n=-8, m=4 | n=0, m=4 | n=8, m=4 | ..... 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 170 n=-16 -14 -12 -10 -8 -6 -4 -2 0 2 4 6 8 10 12 14 16 171 |_| 172 Flexi-grid (Nodes B,D) 6.25 GHz 173 Central frequency granularity=6.25 GHz 174 Slot width granularity=12.5 GHz 176 Figure 2: Fixed grid channel spacing and flexi-grid spectrum slot 178 3.2. Flexible-Grid Capability Negotiation 180 The updated version of ITU-T [G.694.1] has defined the flexible-grid 181 with a central frequency granularity of 6.25 GHz and a slot width 182 granularity of 12.5 GHz. However, devices or applications that make 183 use of the flexible-grid may not be able to support every possible 184 slot width or position. In other words, applications may be defined 185 where only a subset of the possible slot widths and positions are 186 required to be supported. Taking node G in figure 3 as an example, 187 an application could be defined where the nominal central frequency 188 granularity is 12.5 GHz (by only requiring values of n that are even) 189 requiring slot widths being multiple of 25 GHz (the values of m 190 SHOULD be even). Therefore the link between two optical node F and G 191 with different grid granularity must be configured to align with the 192 larger of both granularities. Besides, different nodes may have 193 different slot width tuning ranges. For example, in figure 3, node F 194 can only support slot width with tuning change from 12.5 to 100 GHz, 195 while node G supports tuning range from 25 GHz to 200 GHz. The link 196 property of slot width tuning range for the link between F and G 197 should be chosen as the range intersection, resulting in a range from 198 25 GHz to 100 GHz. 200 +---+ +---+ 201 | F +------------| G | 202 +---+ +---+ 203 +------------------+-------------+-----------+ 204 | Unit (GHz) | Node F | Node G | 205 +------------------+-------------+-----------+ 206 | Grid granularity | 6.25 (12.5) | 12.5 (25) | 207 +------------------+-------------+-----------+ 208 | Tuning range | [12.5, 100] | [25, 200] | 209 +------------------+-------------+-----------+ 211 Figure 3: Flexible-grid capability negotiation 213 Note: we should avoid the use of LMP in the case that a DWDM or Flex 214 port is connected to a CWDM port, for this it is likely to cause the 215 upgrade of hardware and LMP can not work in a "plug-and-play" way. 217 3.3. Summary 219 In summary, in a DWDM Link between two nodes, the following 220 properties should be negotiated: 222 o Grid capability: flexible grid or fixed grid DWDM. 224 o Nominal central frequency granularity: a multiplier of 6.25 GHz. 226 o Slot width granularity: a multiplier of 12.5 GHz. 228 o Slot width tuning range: two multipliers of 12.5GHz, each indicate 229 the minimal and maximal slot width supported by a port respectively. 231 And for ports on a link that do not have any grid properties in 232 common, the link and its properties SHOULD not be advertised. 234 4. Application of Grid Property Negotiation 236 As described in [RFC7698], the control plane MAY include support for 237 neighbor discovery such that a flexi-grid network can be constructed 238 in a "plug-and-play" manner. The control plane SHOULD allow the 239 nodes at opposite ends of a link to correlate the properties that 240 they will apply to the link. Such a correlation SHOULD include at 241 least the identities of the nodes and the identities that they apply 242 to the link. As described in this draft, for ports on a link that do 243 not have any grid properties in common, the link and its properties 244 SHOULD not be advertised to the PCE or other nodes in the same 245 domain. Especially in the scenario of inter-domain, LMP can not be 246 replaced by some other protocol. For example, if Path Computation 247 Element (PCE) or a serial of PCEs coordinate to compute an end-to-end 248 path which crosses more than one domain, it should take the inter- 249 domain grid properties into consideration. Given the OSPF can not 250 advertise the attributes of the border device on the other side, the 251 inter-domain attributes must be negotiated in advance, otherwise the 252 end-to-end path may not be set up successfully. 254 5. LMP extensions 256 5.1. Grid Property Subobject 258 According to [RFC4204], the LinkSummary message is used to verify the 259 consistency of the link property on both sides of the link before it 260 is brought up. The LinkSummary message contains negotiable and non- 261 negotiable DATA_LINK objects, carrying a series of variable-length 262 data items called subobjects, which illustrate the detailed link 263 properties. The subobjects are defined in Section 13.12.1 in 264 [RFC4204]. 266 To meet the requirements stated in section 3, this draft extends the 267 LMP protocol by introducing a new DATA_LINK subobject called "Grid 268 property", allowing the grid property correlation between adjacent 269 nodes. The encoding format of this new subobject is as follows: 271 0 1 2 3 272 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 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | Type | Length | Grid | C.F.G | S.W.G | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Min Width | Reserved | Max Width | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 Figure 4 281 Type=TBD, Grid property type. 283 Grid: 4 bits 285 The value is used to represent which grid the node/interface 286 supports. Values defined in RFC 6205 [RFC6205] identify DWDM 288 [G.694.1] and CWDM [G.694.2]. The value defined in [RFC7699] 289 identifies flexible DWDM. 291 +---------------+-------+ 292 | Grid | Value | 293 +---------------+-------+ 294 | Reserved | 0 | 295 +---------------+-------+ 296 | ITU-T DWDM | 1 | 297 +---------------+-------+ 298 | ITU-T CWDM | 2 | 299 +---------------+-------+ 300 | ITU-T Flex | 3 | 301 +---------------+-------+ 302 | Future use | 4-16 | 303 +---------------+-------+ 305 C.F.G (central frequency granularity): 307 It is a positive integer. Its value indicates the multiple of 6.25 308 GHz in terms of central frequency granularity. 310 S.W.G (Slot Width Granularity): 312 It is a positive integer value which indicates the slot width 313 granularity which is the multiple of 12.5 GHz. 315 Min Width and Max Width: 317 Min Width and Max Width are positive integers. Their value indicate 318 the multiple of 12.5 GHz in terms of the slot width tuning range the 319 interface supports. For example, for slot width tuning range from 25 320 GHz to 100 GHz (with regard to a node with slot width granularity of 321 12.5 GHz), the values of Min Width and Max Width should be 2 and 8 322 respectively. For fixed-grid nodes, these two fields are meaningless 323 and should be set to zero. 325 6. Messages Exchange Procedure 327 6.1. Flexi-fixed Grid Nodes Messages Exchange 329 To demonstrate the procedure of grid property correlation, the model 330 shown in Figure 1 is reused. Node B starts sending messages. 332 o After inspecting its own node/interface property, node B sends node 333 C a LinkSummary message including the MESSAGE ID, TE_LINK ID and 334 DATA_LINK objects. The setting and negotiating of MESSAGE ID and 335 TE_link ID can be referenced to [RFC4204]. As node B supports 336 flexible-grid property, the Grid and C.F.G values in the grid 337 property subobject are set to be 3 (i.e., ITU-T Flex) and 1 338 (i.e.,1*6.25GHz) respectively. The slot width tuning range is from 339 12.5 GHz to 200 GHz (i.e., Min Width=1, Max Width=16). Meanwhile, 340 the N bit of the DATA_LINK object is set to 1, indicating that the 341 property is negotiable. 343 o When node C receives the LinkSummary message from B, it checks the 344 Grid, C.F.G, Min and Max values in the grid property subobject. Node 345 C can only support fixed-grid DWDM and realizes that the flexible- 346 grid property is not acceptable for the link. Since the receiving N 347 bit in the DATA_LINK object is set, indicating that the Grid property 348 of B is negotiable, node C responds to B with a LinkSummaryNack 349 containing a new Error_code object and state that the property of the 350 interface connected to node B needs further negotiation. Meanwhile, 351 an accepted grid property subobject (Grid=2, C.F.G=4, fixed DWDM with 352 channel spacing of 50 GHz) is carried in LinkSummaryNack message. At 353 this moment, the N bit in the DATA_LINK object is set to 0, 354 indicating that the grid property subobject is non-negotiable. 356 o As the channel spacing and slot width of the corresponding 357 interface of node B can be configured to be any integral multiples of 358 6.25 GHz and 12.5 GHz respectively, node B supports the fixed DWDM 359 values announced by node C. Consequently, node B will resend the 360 LinkSummary message carrying the grid property subobject with values 361 of Grid=2 and C.F.G=4. 363 o Once received the LinkSummary message from node B, node C replies 364 with a LinkSummaryACK message. After the message exchange, the link 365 between node B and C is brought up with a fixed channel spacing of 50 366 GHz. 368 In the above mentioned grid property correlation scenario, the node 369 supporting a flexible-grid is the one that starts sending LMP 370 messages. The procedure where the initiator is the fixed-grid node 371 is as follows: 373 o After inspecting its own interface property, Node C sends B a 374 LinkSummary message containing a grid property subobject with Grid=2, 375 C.F.G=4. The N bit in the DATA_LINK object is set to 0, indicating 376 that it is non-negotiable. 378 o As the channel spacing and slot width of node B can be configured 379 to be any integral multiples of 6.25 GHz and 12.5 GHz respectively, 380 node B is able to support the fixed DWDM parameters. Then, node B 381 will make appropriate configuration and reply node C the 382 LinkSummaryACK message 383 o After the message exchange, the link between node B and C is 384 brought up with a fixed channel spacing of 50 GHz. 386 6.2. Flexible Nodes Messages Exchange 388 To demonstrate the procedure of grid property correlation between two 389 flexi-grid capable nodes, the model shown in figure 3 is reused. The 390 procedure of grid property correlation (negotiating the grid 391 granularity and slot width tuning range) is similar to the scenarios 392 mentioned above. 394 o The Grid, C.F.G, Min and Max values in the grid property subobject 395 sent from node F to G are set to be 3,1,1,8 respectively. Meanwhile, 396 the N bit of the DATA_LINK object is set to 1, indicating that the 397 grid property is negotiable. 399 o When node G has received the LinkSummary message from F, it will 400 analyze the Grid, C.F.G, Min and Max values in the Grid property 401 subobject. But the corresponding interface of node G can only 402 support grid granularity of 12.5 GHz and a slotwdith tuning range 403 from 25 GHz to 200 GHz. Considering the interface property of node 404 F, node G will first match these property with its corresponding 405 interface, and then judge the mismatch of the property of the link 406 between node F and G, then respond F a LinkSummaryNack containing a 407 new Error_code object and state that the property need further 408 negotiation. Meanwhile, an accepted grid property subobject (Grid=3, 409 C.F.G=2, Min=2, Max=8, the slot width tuning range is set to the 410 intersection of Node F and G) is carried in LinkSummaryNack message. 411 Meanwhile, the N bit in the DATA_LINK object is set to 1, indicating 412 that the grid property subobject is non-negotiable. 414 o As the channel spacing and slot width of the corresponding 415 interface of node F can be configured to be any integral multiples of 416 6.25 GHz and 12.5 GHz respectively, node F can support the lager 417 granularity. The suggested slot width tuning range is acceptable for 418 node F. In consequence, node F will resend the LinkSummary message 419 carrying the grid subobject with values of Grid=3, C.F.G=2, Min=2 and 420 Max=8. 422 o Once received the LinkSummary message from node F, node G replies 423 with a LinkSummaryACK message. After the message exchange, the link 424 between node F and G is brought up supporting central frequency 425 granularity of 12.5 GHz and slot width tuning range from 25 GHz to 426 100 GHz. 428 From the perspective of the control plane, once the links have been 429 brought up, wavelength constraint information can be advertised and 430 the wavelength label can be assigned hop-by-hop when establishing a 431 LSP based on the link grid property. 433 7. IANA Considerations 435 This draft introduces the following new assignments: 437 LMP Sub-Object Class names: 439 o under DATA_LINK Class name (as defined in [RFC4204]) 441 - Grid property type (sub-object Type = TBD.) 443 8. Acknowledgments 445 This work was supported in part by the China NSFC Project 61201260. 447 9. Security Considerations 449 LMP message security uses IPsec, as described in [RFC4204]. This 450 document only defines new LMP objects that are carried in existing 451 LMP messages. As such, this document introduces no other new 452 security considerations not covered in [RFC4204]. 454 10. Contributing Authors 456 Wenjuan He 457 ZTE 458 he.wenjuan1@zte.com.cn 460 11. References 462 11.1. Normative References 464 [G.694.1] International Telecomunications Union, "Spectral grids for 465 WDM applications: DWDM frequency grid", Recommendation 466 G.694.1 , June 2002. 468 [G.694.2] International Telecomunications Union, "Spectral grids for 469 WDM applications: CWDM wavelength grid", Recommendation 470 G.694.2 , December 2003. 472 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 473 Requirement Levels", BCP 14, RFC 2119, 474 DOI 10.17487/RFC2119, March 1997, 475 . 477 [RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC 4204, 478 DOI 10.17487/RFC4204, October 2005, 479 . 481 [RFC6205] Otani, T., Ed. and D. Li, Ed., "Generalized Labels for 482 Lambda-Switch-Capable (LSC) Label Switching Routers", 483 RFC 6205, DOI 10.17487/RFC6205, March 2011, 484 . 486 11.2. Informative References 488 [RFC7698] Gonzalez de Dios, O., Ed., Casellas, R., Ed., Zhang, F., 489 Fu, X., Ceccarelli, D., and I. Hussain, "Framework and 490 Requirements for GMPLS-Based Control of Flexi-Grid Dense 491 Wavelength Division Multiplexing (DWDM) Networks", 492 RFC 7698, DOI 10.17487/RFC7698, November 2015, 493 . 495 [RFC7699] Farrel, A., King, D., Li, Y., and F. Zhang, "Generalized 496 Labels for the Flexi-Grid in Lambda Switch Capable (LSC) 497 Label Switching Routers", RFC 7699, DOI 10.17487/RFC7699, 498 November 2015, . 500 Authors' Addresses 502 Qilei Wang (editor) 503 ZTE 505 Email: wang.qilei@zte.com.cn 507 Guoying Zhang (editor) 508 CAICT 510 Email: zhangguoying@catr.cn 512 Yao Li 513 Nanjing University 515 Email: wsliguotou@hotmail.com 517 Ramon Casellas 518 CTTC 520 Email: ramon.casellas@cttc.es 521 Yu Wang 522 CAICT 524 Email: wangyu@catr.cn