idnits 2.17.1 draft-zhang-ccamp-flexible-grid-rsvp-te-ext-03.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 33 has weird spacing: '... months and ...' == Line 34 has weird spacing: '... at any time...' == Line 35 has weird spacing: '...ference mate...' == Line 442 has weird spacing: '... of these ...' == Line 443 has weird spacing: '...cluding thos...' == (3 more instances...) -- The document date (November 12, 2013) is 3816 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) == Missing Reference: 'FLEX-LBL' is mentioned on line 260, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'G.694.1' -- No information found for draft-ogrcetal-cammp-flexi-grid-fwk - is the name correct? Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Fatai Zhang 2 Internet-Draft Xian Zhang 3 Intended status: Standards Track Huawei 4 Adrian Farrel 5 Old Dog Consulting 6 Oscar Gonzalez de Dios 7 Telefonica 8 D. Ceccarelli 9 Ericsson 10 Expires: May 12, 2014 November 12, 2013 12 RSVP-TE Signaling Extensions in support of Flexible Grid 14 draft-zhang-ccamp-flexible-grid-rsvp-te-ext-03.txt 16 Abstract 18 This memo describes the extensions to RSVP-TE signaling to support 19 Label Switched Paths in a GMPLS-controlled network that includes 20 devices using the new flexible optical grid. 22 Status of this Memo 24 This Internet-Draft is submitted to IETF in full conformance with 25 the provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six 33 months and may be updated, replaced, or obsoleted by other 34 documents at any time. It is inappropriate to use Internet-Drafts 35 as reference material or to cite them other than as "work in 36 progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This Internet-Draft will expire on May 12, 2014. 46 Table of Contents 48 1. Introduction ................................................ 2 49 2. Terminology ................................................. 3 50 2.1. Conventions used in this document .......................3 51 3. Requirements for Flexible Grid Signaling .....................3 52 3.1. Slot Width ............................................. 4 53 3.2. Frequency Slot ......................................... 4 54 4. Protocol Extensions ......................................... 5 55 4.1. Traffic Parameters...................................... 5 56 4.1.1. Applicability to Fixed Grid Networks ...............6 57 4.2. Generalized Label....................................... 6 58 4.3. Signaling Procedures.................................... 6 59 5. IANA Considerations ......................................... 7 60 5.1. RSVP Objects Class Types................................ 7 61 6. Manageability Considerations................................. 7 62 7. Security Considerations...................................... 7 63 8. References .................................................. 8 64 8.1. Normative References.................................... 8 65 8.2. Informative References.................................. 8 66 9. Contributors' Address........................................ 8 67 10. Authors' Addresses ..........................................9 69 1. Introduction 71 [G.694.1] defines the Dense Wavelength Division Multiplexing (DWDM) 72 frequency grids for Wavelength Division Multiplexing (WDM) 73 applications. A frequency grid is a reference set of frequencies 74 used to denote allowed nominal central frequencies that may be used 75 for defining applications. The channel spacing is the frequency 76 spacing between two allowed nominal central frequencies. All of the 77 wavelengths on a fiber use different central frequencies and occupy 78 a fixed bandwidth of frequency. 80 Fixed grid channel spacing is selected from 12.5 GHz, 25 GHz, 50 GHz, 81 100 GHz and integer multiples of 100 GHz. But [G.694.1] also defines 82 "flexible grids", known as "flexi-grid". The terms "frequency slot 83 (i.e. the frequency range allocated to a specific channel and 84 unavailable to other channels within a flexible grid)" and "slot 85 width" (i.e. the full width of a frequency slot in a flexible grid) 86 are introduced to define a flexible grid. 88 [FLEX-FWK] defines a framework and the associated control plane 89 requirements for the GMPLS based control of flexi-grid DWDM networks. 91 [RFC6163] provides a framework for GMPLS and Path Computation 92 Element (PCE) control of Wavelength Switched Optical Networks 93 (WSONs), and [WSON-SIG] describes the requirements and protocol 94 extensions for signaling to set up Label Switched Paths (LSPs) in 95 WSONs. 97 This document describes the additional requirements and protocol 98 extensions for signaling to set up LSPs in networks that support the 99 flexi-grid. 101 2. Terminology 103 For terminology related to flexi-grid, please refer to [FLEX-FWK] 104 and [G.694.1]. 106 2.1. Conventions used in this document 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in RFC-2119 [RFC2119]. 112 3. Requirements for Flexible Grid Signaling 114 The architecture for establishing LSPs in a flexi-grid network is 115 described in [FLEX-FWK]. 117 A optical spectrum LSP occupies a specific frequency slot, i.e. a 118 range of frequencies. The process of computing a route and the 119 allocation of a frequency slot is referred to as RSA (Routing and 120 Spectrum Assignment). [FLEX-FWK] describes three types of 121 architecture approaches to RSA: combined RSA, separated RSA and 122 distributed SA. The first two approaches are referred to as 123 "centralized SA", because both routing and spectrum (frequency slot) 124 assignment are performed by centralized entity before the signaling 125 procedure. 127 In the case of centralized SA, the assigned frequency slot is 128 specified in the Path message during LSP setup. In the case of 129 distributed SA, the slot width of the flexi-grid LSP is specified in 130 the Path message, allowing the involved network elements to select 131 the frequency slot to be used. 133 If the capability of switching or converting the whole optical 134 spectrum allocated to an optical spectrum LSP is not available at 135 nodes along the path of the LSP, the LSP is subject to the Optical 136 "Spectrum Continuity Constraint", as described in [FLEX-FWK]. 138 The remainder of this section states the additional requirements for 139 signaling in a flexi-grid network. 141 3.1. Slot Width 143 The slot width is an end-to-end parameter representing how much 144 frequency resource is requested for a flexi-grid LSP. It is 145 equivalent of optical bandwidth, although the amount of bandwidth 146 associated with a slot width will depend on the encoding. 148 Different LSPs may request different amounts of frequency resource 149 in flexible grid networks, so the slot width needs to be carried in 150 the signaling message during LSP establishment. This enables the 151 nodes along the LSP to know how much frequency resource has been 152 requested (in a Path message) and has been allocated (by a Resv 153 message) for the LSP. 155 3.2. Frequency Slot 157 The frequency slot information identifies which part of the 158 frequency spectrum is allocated on each link for a flexi-LSP. 160 This information is required in Resv message to indicate, hop-by-hop, 161 the central frequency of the allocated resource. In combination with 162 the slot width indicated in a Resv message (see Section 3.1) the 163 central frequency carried in a Resv message identifies the resources 164 reserved for the LSP (known as the frequency slot). 166 The frequency slot can be represented by the two parameters as 167 follows: 169 Frequency slot = [(central frequency) - (slot width)/2] ~ 170 [(central frequency) + (slot width)/2] 172 As is common with other resource identifiers (i.e., labels) in GMPLS 173 signaling, it must be possible for the head-end LSP to suggest or 174 require the central frequency to be used for the LSP. Furthermore, 175 for bidirectional LSPs, the Path message must be able to specify the 176 central frequency to be used for reverse direction traffic. 178 As described in [G.694.1], the allowed frequency slots for the 179 flexible DWDM grid have a nominal central frequency (in THz) defined 180 by: 182 193.1 + n * 0.00625 184 where n is zero or a positive or negative integer. 186 The slot width (in GHz) is defined as: 188 12.5 * m 190 where m is a positive integer. 192 It is possible that implementing a subset of the possible slot 193 widths and central frequencies are supported. For example, an 194 implementation could built where the nominal central frequency 195 granularity is 12.5 GHz (by only requiring values of n that are even) 196 and that only supports slot widths as a multiple of 25 GHz (by only 197 allowing values of m that are even). 199 Further details can be found in [FLEX-FWK]. 201 4. Protocol Extensions 203 This section defines the extensions to RSVP-TE signaling for GMPLS 204 [RFC3473] to support flexible grid networks. 206 4.1. Traffic Parameters 208 In RSVP-TE, the SENDER_TSPEC object in the Path message indicates 209 the requested resource reservation. The FLOWSPEC object in the Resv 210 message indicates the actual resource reservation. 212 As described in Section 3.1, the slot width represents how much 213 frequency resource is requested for a flexi-grid LSP. That is, it 214 describes the end-to-end traffic profile of the LSP. Therefore, the 215 traffic parameters for a flexi-grid LSP encode the slot width. 217 This document defines new C-Types for the SENDER_TSPEC and FLOWSPEC 218 objects to carry Spectrum Switched Optical Network (SSON) traffic 219 parameters: 221 SSON SENDER_TSPEC: Class = 12, C-Type = TBD1. 223 SSON FLOWSPEC: Class = 9, C-Type = TBD2. 225 The SSON traffic parameters carried in both objects have the same 226 format as shown in Figure 1. 228 0 1 2 3 229 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 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | m | Reserved | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 Figure 1: The SSON Traffic Parameters 236 m (8 bits): the slot width is specified by m*12.5 GHz. 238 The Reserved bits MUST be set to zero and ignored upon receipt. 240 4.1.1. Applicability to Fixed Grid Networks 242 Note that the slot width (i.e., traffic parameters) of a fixed grid 243 defined in [G.694.1] can also be specified by using the SSON traffic 244 parameters. The fixed grid channel spacings (12.5 GHz, 25 GHz, 50 245 GHz, 100 GHz and integer multiples of 100 GHz) are also the multiple 246 of 12.5 GHz, so the m parameter can be used to represent these slot 247 widths. 249 Therefore, it is possible to consider using the new traffic 250 parameter object types in common signaling messages for flexi-grid 251 and legacy DWDM networks. 253 4.2. Generalized Label 255 In the case of a flexible grid network, the labels that have been 256 requested or allocated as signaled in the RSVP-TE objects are 257 encoded as described in [FLEX-LBL]. This new label encoding can 258 appear in any RSVP-TE object or sub-object that can carry a label. 260 As noted in Section 4.2 of [FLEX-LBL], the m parameter forms part of 261 the label as well as part of the traffic parameters. 263 4.3. Signaling Procedures 265 There are no differences between the signaling procedure described 266 for LSP control in [FLEX-FWK] and those required for use in a fixed- 267 grid network [WSON-SIG]. Obviously, the TSpec, FlowSpec and label 268 formats described in Section 3 are used. The signaling procedures 269 for distributed SA and centralized SA can be applied. 271 5. IANA Considerations 273 5.1. RSVP Objects Class Types 275 This document introduces two new Class Types for existing RSVP 276 objects. IANA is requested to make allocations from the "Resource 277 ReSerVation Protocol (RSVP) Parameters" registry using the "Class 278 Names, Class Numbers, and Class Types" sub-registry. 280 Class Number Class Name Reference 281 ------------ ----------------------- --------- 282 9 FLOWSPEC [RFC2205] 284 Class Type (C-Type): 286 (TBD2) SSON FLOWSPEC [This.I-D] 288 Class Number Class Name Reference 289 ------------ ----------------------- --------- 290 12 SENDER_TSPEC [RFC2205] 292 Class Type (C-Type): 294 (TBD1) SSON SENDER_TSPEC [This.I-D] 296 IANA is requested to assign the same value for TBD1 and TBD2, and a 297 value of 8 is suggested. 299 6. Manageability Considerations 301 This document makes minor modifications to GMPLS signaling, but does 302 not change the manageability considerations for such networks. 303 Clearly, protocol analysis tools and other diagnostic aids 304 (including logging systems and MIB modules) will need to be enhanced 305 to support the new traffic parameters and label formats. 307 7. Acknowledgments 309 This work was supported in part by the FP-7 IDEALIST project under 310 grant agreement number 317999. 312 8. Security Considerations 314 This document introduces no new security considerations to [RFC3473]. 316 9. References 318 9.1. Normative References 320 [RFC2119] S. Bradner, "Key words for use in RFCs to indicate 321 requirements levels", RFC 2119, March 1997. 323 [RFC3473] L. Berger, Ed., "Generalized Multi-Protocol Label 324 Switching (GMPLS) Signaling Resource ReserVation Protocol- 325 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 326 January 2003. 328 [G.694.1] ITU-T Recommendation G.694.1 (revision 2), "Spectral grids 329 for WDM applications: DWDM frequency grid", February 2012. 331 [FLEX-LBL]King, D., Farrel, A. and Y. Li, "Generalized Labels for 332 the Flexi-Grid in Lambda Switched Capable (LSC) Label 333 Switching Routers", draft-farrkingel-ccamp-flexigrid- 334 lambda-label, work in progress. 336 9.2. Informative References 338 [RFC2205] Braden, R., Zhang L., Berson, S., Herzog, S. and S. Jamin, 339 "Resource ReServation Protocol (RSVP) - Version 1, 340 Functional Specification', RFC2205, September 1997. 342 [RFC6163] Y. Lee, G. Bernstein and W. Imajuku, "Framework for GMPLS 343 and Path Computation Element (PCE) Control of Wavelength 344 Switched Optical Networks (WSONs)", RFC 6163, April 2011. 346 [FLEX-FWK] Gonzalez de Dios, O,, Casellas R., Zhang, F., Fu, X., 347 Ceccarelli, D., and I. Hussain, "Framework and 348 Requirements for GMPLS based control of Flexi-grid DWDM 349 networks', draft-ogrcetal-cammp-flexi-grid-fwk, work in 350 progress. 352 [WSON-SIG] G. Bernstein, Sugang Xu, Y. Lee, G. Martinelli and 353 Hiroaki Harai, "Signaling Extensions for Wavelength 354 Switched Optical Networks", draft-ietf-ccamp-wson- 355 signaling, work in progress. 357 10. Contributors' Address 359 Ramon Casellas 360 CTTC 361 Av. Carl Friedrich Gauss n7 362 Castelldefels, Barcelona 08860 363 Spain 365 Email: ramon.casellas@cttc.es 367 Felipe Jimenez Arribas 368 Telefonica Investigacion y Desarrollo 369 Emilio Vargas 6 370 Madrid, 28045 371 Spain 372 Email: felipej@tid.es 374 Yi Lin 375 Huawei Technologies Co., Ltd. 376 F3-5-B R&D Center, Huawei Base, 377 Bantian, Longgang District 378 Shenzhen 518129 P.R.China 380 Phone: +86-755-28972914 381 Email: yi.lin@huawei.com 383 11. Authors' Addresses 385 Fatai Zhang 386 Huawei Technologies 387 Email: zhangfatai@huawei.com 389 Xian Zhang 390 Huawei Technologies 391 Email: zhang.xian@huawei.com 393 Adrian Farrel 394 Old Dog Consulting 395 Email: adrian@olddog.co.uk 397 Oscar Gonzalez de Dios 398 Telefonica Investigacion y Desarrollo 399 Emilio Vargas 6 400 Madrid, 28045 401 Spain 403 Phone: +34 913374013 404 Email: ogondio@tid.es 406 Daniele Ceccarelli 407 Ericsson 408 Via A. Negrone 1/A 409 Genova - Sestri Ponente 410 Italy 411 Email: daniele.ceccarelli@ericsson.com 413 Intellectual Property 415 The IETF Trust takes no position regarding the validity or scope of 416 any Intellectual Property Rights or other rights that might be 417 claimed to pertain to the implementation or use of the technology 418 described in any IETF Document or the extent to which any license 419 under such rights might or might not be available; nor does it 420 represent that it has made any independent effort to identify any 421 such rights. 423 Copies of Intellectual Property disclosures made to the IETF 424 Secretariat and any assurances of licenses to be made available, or 425 the result of an attempt made to obtain a general license or 426 permission for the use of such proprietary rights by implementers or 427 users of this specification can be obtained from the IETF on-line 428 IPR repository at http://www.ietf.org/ipr 430 The IETF invites any interested party to bring to its attention any 431 copyrights, patents or patent applications, or other proprietary 432 rights that may cover technology that may be required to implement 433 any standard or specification contained in an IETF Document. Please 434 address the information to the IETF at ietf-ipr@ietf.org. 436 The definitive version of an IETF Document is that published by, or 437 under the auspices of, the IETF. Versions of IETF Documents that are 438 published by third parties, including those that are translated into 439 other languages, should not be considered to be definitive versions 440 of IETF Documents. The definitive version of these Legal Provisions 441 is that published by, or under the auspices of, the IETF. Versions 442 of these Legal Provisions that are published by third parties, 443 including those that are translated into other languages, should 444 not be considered to be definitive versions of these Legal 445 Provisions. 447 For the avoidance of doubt, each Contributor to the IETF Standards 448 Process licenses each Contribution that he or she makes as part of 449 the IETF Standards Process to the IETF Trust pursuant to the 450 provisions of RFC 5378. No language to the contrary, or terms, 451 conditions or rights that differ from or are inconsistent with the 452 rights and licenses granted under RFC 5378, shall have any effect 453 and shall be null and void, whether published or posted by such 454 Contributor, or included with or in such Contribution. 456 Disclaimer of Validity 458 All IETF Documents and the information contained therein are 459 provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION 460 HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET 461 SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE 462 DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 463 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION THEREIN 464 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 465 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 467 Full Copyright Statement 469 Copyright (c) 2013 IETF Trust and the persons identified as the 470 document authors. All rights reserved. 472 This document is subject to BCP 78 and the IETF Trust's Legal 473 Provisions Relating to IETF Documents 474 (http://trustee.ietf.org/license-info) in effect on the date of 475 publication of this document. Please review these documents 476 carefully, as they describe your rights and restrictions with 477 respect to this document. Code Components extracted from this 478 document must include Simplified BSD License text as described in 479 Section 4.e of the Trust Legal Provisions and are provided without 480 warranty as described in the Simplified BSD License.