idnits 2.17.1 draft-zhang-ccamp-flexible-grid-rsvp-te-ext-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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 4 characters in excess of 72. 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...' -- The document date (February 14, 2014) is 3717 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 279, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'G.694.1' -- Obsolete informational reference (is this intentional?): RFC 6982 (Obsoleted by RFC 7942) -- No information found for draft-ogrcetal-cammp-flexi-grid-fwk - is the name correct? Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 4 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: August 14, 2014 February 14, 2014 12 RSVP-TE Signaling Extensions in support of Flexible Grid 14 draft-zhang-ccamp-flexible-grid-rsvp-te-ext-04.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 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 August 12, 2014. 46 Copyright Notice 47 Copyright (c) 2014 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with 55 respect to this document. Code Components extracted from this 56 document must include Simplified BSD License text as described in 57 Section 4.e of the Trust Legal Provisions and are provided without 58 warranty as described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction ................................................ 2 63 2. Terminology ................................................. 3 64 2.1. Conventions used in this document .......................3 65 3. Requirements for Flexible Grid Signaling .....................3 66 3.1. Slot Width ............................................. 4 67 3.2. Frequency Slot ......................................... 4 68 4. Protocol Extensions ......................................... 5 69 4.1. Traffic Parameters...................................... 5 70 4.1.1. Applicability to Fixed Grid Networks ...............6 71 4.2. Generalized Label....................................... 6 72 4.3. Signaling Procedures.................................... 7 73 5. IANA Considerations ......................................... 7 74 5.1. RSVP Objects Class Types................................ 7 75 6. Manageability Considerations................................. 8 76 7. Implementation Status........................................ 8 77 7.1. Centre Tecnologic de Telecomunicacions de Catalunya (CTTC)8 78 8. Acknowledgments ............................................ 10 79 9. Security Considerations..................................... 10 80 10. References ................................................ 10 81 10.1. Normative References.................................. 10 82 10.2. Informative References................................ 10 83 11. Contributors' Address...................................... 11 84 12. Authors' Addresses .........................................12 86 1. Introduction 88 [G.694.1] defines the Dense Wavelength Division Multiplexing (DWDM) 89 frequency grids for Wavelength Division Multiplexing (WDM) 90 applications. A frequency grid is a reference set of frequencies 91 used to denote allowed nominal central frequencies that may be used 92 for defining applications that utilize WDM transmission. The channel 93 spacing is the frequency spacing between two allowed nominal central 94 frequencies. All of the wavelengths on a fiber use different central 95 frequencies and occupy a designated range of frequency. 97 Fixed grid channel spacing is selected from 12.5 GHz, 25 GHz, 50 GHz, 98 100 GHz and integer multiples of 100 GHz. But [G.694.1] also defines 99 ''flexible grids'', known as ''flexi-grid''. The terms ''frequency slot'' 100 (i.e., the frequency range allocated to a specific channel and 101 unavailable to other channels within a flexible grid) and ''slot 102 width'' (i.e., the full width of a frequency slot in a flexible grid) 103 are introduced in [G.694.1] to define a flexible grid. 105 [FLEX-FWK] defines a framework and the associated control plane 106 requirements for the GMPLS based control of flexi-grid DWDM networks. 108 [RFC6163] provides a framework for GMPLS and Path Computation 109 Element (PCE) control of Wavelength Switched Optical Networks 110 (WSONs), and [WSON-SIG] describes the requirements and protocol 111 extensions for signaling to set up Label Switched Paths (LSPs) in 112 WSONs. 114 This document describes the additional requirements and protocol 115 extensions for RSVP-TE signaling to set up LSPs in networks that 116 support the flexi-grid. 118 2. Terminology 120 For terminology related to flexi-grid, please refer to [FLEX-FWK] 121 and [G.694.1]. 123 2.1. Conventions used in this document 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in RFC-2119 [RFC2119]. 129 3. Requirements for Flexible Grid Signaling 131 The architecture for establishing LSPs in a flexi-grid network is 132 described in [FLEX-FWK]. 134 An optical spectrum LSP occupies a specific frequency slot, i.e., a 135 range of frequencies. The process of computing a route and the 136 allocation of a frequency slot is referred to as RSA (Routing and 137 Spectrum Assignment). [FLEX-FWK] describes three architectural 138 approaches to RSA: combined RSA, separated RSA, and distributed SA. 140 The first two approaches are referred to as ''centralized SA'' because 141 both routing and spectrum (frequency slot) assignment are performed 142 by a centralized entity before the signaling procedure. 144 In the case of centralized SA the assigned frequency slot is 145 specified in the RSVP-TE Path message during LSP setup. In the case 146 of distributed SA, the slot width of the flexi-grid LSP is specified 147 in the Path message, allowing the network elements to select the 148 frequency slot to be used when they process the RSVP-TE messages. 150 If the capability to switch or convert the whole optical spectrum 151 allocated to an optical spectrum LSP is not available at some nodes 152 along the path of the LSP, the LSP is subject to the Optical 153 ''Spectrum Continuity Constraint'' as described in [FLEX-FWK]. 155 The remainder of this section states the additional requirements for 156 signaling in a flexi-grid network. 158 3.1. Slot Width 160 The slot width is an end-to-end parameter representing how much 161 frequency resource is requested for a flexi-grid LSP. It is the 162 equivalent of optical bandwidth, although the amount of bandwidth 163 associated with a slot width will depend on the signal encoding. 165 Different LSPs may request different amounts of frequency resource 166 in flexible grid networks, so the slot width needs to be carried in 167 the signaling message during LSP establishment. This enables the 168 nodes along the LSP to know how much frequency resource has been 169 requested (in a Path message) and has been allocated (by a Resv 170 message) for the LSP. 172 3.2. Frequency Slot 174 The frequency slot information identifies which part of the 175 frequency spectrum is allocated on each link for an LSP in a flexi- 176 grid network. 178 This information is required in a Resv message to indicate, hop-by- 179 hop, the central frequency of the allocated resource. In combination 180 with the slot width indicated in a Resv message (see Section 3.1) 181 the central frequency carried in a Resv message identifies the 182 resources reserved for the LSP (known as the frequency slot). 184 The frequency slot can be represented by the two parameters as 185 follows: 187 Frequency slot = [(central frequency) - (slot width)/2] ~ 188 [(central frequency) + (slot width)/2] 190 As is common with other resource identifiers (i.e., labels) in GMPLS 191 signaling, it must be possible for the head-end LSP when sending a 192 Path message to suggest or require the central frequency to be used 193 for the LSP. Furthermore, for bidirectional LSPs, the Path message 194 must be able to specify the central frequency to be used for reverse 195 direction traffic. 197 As described in [G.694.1], the allowed frequency slots for the 198 flexible DWDM grid have a nominal central frequency (in THz) defined 199 by: 201 193.1 + n * 0.00625 203 where n is zero or a positive or negative integer. 205 The slot width (in GHz) is defined as: 207 12.5 * m 209 where m is a positive integer. 211 It is possible that implementing a subset of the possible slot 212 widths and central frequencies are supported. For example, an 213 implementation could built where the nominal central frequency 214 granularity is 12.5 GHz (by only requiring values of n that are even) 215 and that only supports slot widths as a multiple of 25 GHz (by only 216 allowing values of m that are even). 218 Further details can be found in [FLEX-FWK]. 220 4. Protocol Extensions 222 This section defines the extensions to RSVP-TE signaling for GMPLS 223 [RFC3473] to support flexible grid networks. 225 4.1. Traffic Parameters 227 In RSVP-TE, the SENDER_TSPEC object in the Path message indicates 228 the requested resource reservation. The FLOWSPEC object in the Resv 229 message indicates the actual resource reservation. 231 As described in Section 3.1, the slot width represents how much 232 frequency resource is requested for a flexi-grid LSP. That is, it 233 describes the end-to-end traffic profile of the LSP. Therefore, the 234 traffic parameters for a flexi-grid LSP encode the slot width. 236 This document defines new C-Types for the SENDER_TSPEC and FLOWSPEC 237 objects to carry Spectrum Switched Optical Network (SSON) traffic 238 parameters: 240 SSON SENDER_TSPEC: Class = 12, C-Type = TBD1. 242 SSON FLOWSPEC: Class = 9, C-Type = TBD2. 244 The SSON traffic parameters carried in both objects have the same 245 format as shown in Figure 1. 247 0 1 2 3 248 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 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | m | Reserved | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 Figure 1: The SSON Traffic Parameters 255 m (16 bits): the slot width is specified by m*12.5 GHz. 257 The Reserved bits MUST be set to zero and ignored upon receipt. 259 4.1.1. Applicability to Fixed Grid Networks 261 Note that the slot width (i.e., traffic parameters) of a fixed grid 262 defined in [G.694.1] can also be specified by using the SSON traffic 263 parameters. The fixed grid channel spacings (12.5 GHz, 25 GHz, 50 264 GHz, 100 GHz and integer multiples of 100 GHz) are also the 265 multiples of 12.5 GHz, so the m parameter can be used to represent 266 these slot widths. 268 Therefore, it is possible to consider using the new traffic 269 parameter object types in common signaling messages for flexi-grid 270 and legacy DWDM networks. 272 4.2. Generalized Label 274 In the case of a flexible grid network, the labels that have been 275 requested or allocated as signaled in the RSVP-TE objects are 276 encoded as described in [FLEX-LBL]. This new label encoding can 277 appear in any RSVP-TE object or sub-object that can carry a label. 279 As noted in Section 4.2 of [FLEX-LBL], the m parameter forms part of 280 the label as well as part of the traffic parameters. 282 4.3. Signaling Procedures 284 There are no differences between the signaling procedure described 285 for LSP control in [FLEX-FWK] and those required for use in a fixed- 286 grid network [WSON-SIG]. Obviously, the TSpec, FlowSpec, and label 287 formats described in Section 3 are used. The signaling procedures 288 for distributed SA and centralized SA can be applied. 290 5. IANA Considerations 292 5.1. RSVP Objects Class Types 294 This document introduces two new Class Types for existing RSVP 295 objects. IANA is requested to make allocations from the "Resource 296 ReSerVation Protocol (RSVP) Parameters" registry using the "Class 297 Names, Class Numbers, and Class Types" sub-registry. 299 Class Number Class Name Reference 300 ------------ ----------------------- --------- 301 9 FLOWSPEC [RFC2205] 303 Class Type (C-Type): 305 (TBD2) SSON FLOWSPEC [This.I-D] 307 Class Number Class Name Reference 308 ------------ ----------------------- --------- 309 12 SENDER_TSPEC [RFC2205] 311 Class Type (C-Type): 313 (TBD1) SSON SENDER_TSPEC [This.I-D] 315 IANA is requested to assign the same value for TBD1 and TBD2, and a 316 value of 8 is suggested. 318 6. Manageability Considerations 320 This document makes minor modifications to GMPLS signaling, but does 321 not change the manageability considerations for such networks. 322 Clearly, protocol analysis tools and other diagnostic aids 323 (including logging systems and MIB modules) will need to be enhanced 324 to support the new traffic parameters and label formats. 326 7. Implementation Status 328 [RFC Editor Note: Please remove this entire seciton prior to 329 publication as an RFC.] 331 This section records the status of known implementations of the 332 protocol defined by this specification at the time of posting of 333 this Internet-Draft, and is based on a proposal described in RFC 334 6982 [RFC6982]. The description of implementations in this section 335 is intended to assist the IETF in its decision processes in 336 progressing drafts to RFCs. Please note that the listing of any 337 individual implementation here does not imply endorsement by the 338 IETF. Furthermore, no effort has been spent to verify the 339 information presented here that was supplied by IETF contributors. 340 This is not intended as, and must not be construed to be, a catalog 341 of available implementations or their features. Readers are advised 342 to note that other implementations may exist. 344 According to RFC 6982, "this will allow reviewers and working groups 345 to assign due consideration to documents that have the benefit of 346 running code, which may serve as evidence of valuable 347 experimentation and feedback that have made the implemented 348 protocols more mature. It is up to the individual working groups to 349 use this information as they see fit." 351 7.1. Centre Tecnologic de Telecomunicacions de Catalunya (CTTC) 353 Organization Responsible for the Implementation: 354 Centre Tecnologic de Telecomunicacions de Catalunya (CTTC) 355 Optical Networks and Systems Department 357 Implementation Name and Details: 358 ADRENALINE testbed 359 http://networks.cttc.es/experimental-testbeds/ 361 Brief Description: 362 Experimental testbed implementation of GMPLS/PCE control plane. 364 Level of Maturity: 365 Implemented as extensions to a mature GMLPS/PCE control plane. 366 It is limited to research / prototyping stages, but it has been 367 used successfully for more than the last five years. 369 Coverage: 370 Support for the Tspec, FlowSpec, and label formats as described 371 version 03 of this document. Label format support extends to the 372 following RSVP-TE objects and sub-objects: 374 - Generalized Label Object 375 - Suggested Label Object 376 - Upstream Label Object 377 - ERO Label Subobjects 379 It is expected that this implementation will evolve to follow the 380 evolution of this document. 382 Licensing: 383 Proprietary 385 Implementation Experience: 386 Implementation of this document reports no issues. 387 General implementation experience has been reported in a number 388 of journal papers. Contact Ramon Casellas for more information or 389 see 391 http://networks.cttc.es/publications/?search=GMPLS&research_area=opt 392 ical-networks-systems 394 Contact Information: 395 Ramon Casellas: ramon.casellas@cttc.es 397 Interoperability: 398 No report. 400 8. Acknowledgments 402 This work was supported in part by the FP-7 IDEALIST project under 403 grant agreement number 317999. 405 9. Security Considerations 407 This document introduces no new security considerations to [RFC3473]. 409 See also [RFC5920] for a discussion of security considerations for 410 GMPLS signaling. 412 10. References 414 10.1. Normative References 416 [RFC2119] S. Bradner, "Key words for use in RFCs to indicate 417 requirements levels", RFC 2119, March 1997. 419 [RFC3473] L. Berger, Ed., "Generalized Multi-Protocol Label 420 Switching (GMPLS) Signaling Resource ReserVation Protocol- 421 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 422 January 2003. 424 [G.694.1] ITU-T Recommendation G.694.1 (revision 2), ''Spectral grids 425 for WDM applications: DWDM frequency grid'', February 2012. 427 [FLEX-LBL]King, D., Farrel, A. and Y. Li, ''Generalized Labels for 428 the Flexi-Grid in Lambda Switched Capable (LSC) Label 429 Switching Routers'', draft-farrkingel-ccamp-flexigrid- 430 lambda-label, work in progress. 432 10.2. Informative References 434 [RFC2205] Braden, R., Zhang L., Berson, S., Herzog, S. and S. Jamin, 435 ''Resource ReServation Protocol (RSVP) -- Version 1, 436 Functional Specification', RFC2205, September 1997. 438 [RFC5920] L. Fang et al., "Security Framework for MPLS and GMPLS 439 Networks", RFC 5920, July 2010. 441 [RFC6163] Y. Lee, G. Bernstein and W. Imajuku, "Framework for GMPLS 442 and Path Computation Element (PCE) Control of Wavelength 443 Switched Optical Networks (WSONs)", RFC 6163, April 2011. 445 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 446 Code: The Implementation Status Section", RFC 6982, July 447 2013. 449 [RFC Editor Note: This reference can be removed when Section 7 is 450 removed] 452 [FLEX-FWK] Gonzalez de Dios, O,, Casellas R., Zhang, F., Fu, X., 453 Ceccarelli, D., and I. Hussain, ''Framework and 454 Requirements for GMPLS based control of Flexi-grid DWDM 455 networks', draft-ogrcetal-cammp-flexi-grid-fwk, work in 456 progress. 458 [WSON-SIG] G. Bernstein, Sugang Xu, Y. Lee, G. Martinelli and 459 Hiroaki Harai, "Signaling Extensions for Wavelength 460 Switched Optical Networks", draft-ietf-ccamp-wson- 461 signaling, work in progress. 463 11. Contributors' Address 465 Ramon Casellas 466 CTTC 467 Av. Carl Friedrich Gauss n7 468 Castelldefels, Barcelona 08860 469 Spain 471 Email: ramon.casellas@cttc.es 473 Felipe Jimenez Arribas 474 Telefonica Investigacion y Desarrollo 475 Emilio Vargas 6 476 Madrid, 28045 477 Spain 478 Email: felipej@tid.es 480 Yi Lin 481 Huawei Technologies Co., Ltd. 482 F3-5-B R&D Center, Huawei Base, 483 Bantian, Longgang District 484 Shenzhen 518129 P.R.China 486 Phone: +86-755-28972914 487 Email: yi.lin@huawei.com 489 Qilei Wang 491 ZTE 492 wang.qilei@zte.com.cn 494 Haomian Zheng 496 Huawei Technologies 497 zhenghaomian@huawei.com 499 12. Authors' Addresses 501 Fatai Zhang 502 Huawei Technologies 503 Email: zhangfatai@huawei.com 505 Xian Zhang 506 Huawei Technologies 507 Email: zhang.xian@huawei.com 509 Adrian Farrel 510 Old Dog Consulting 511 Email: adrian@olddog.co.uk 513 Oscar Gonzalez de Dios 514 Telefonica Investigacion y Desarrollo 515 Emilio Vargas 6 516 Madrid, 28045 517 Spain 519 Phone: +34 913374013 520 Email: ogondio@tid.es 522 Daniele Ceccarelli 523 Ericsson 524 Via A. Negrone 1/A 525 Genova - Sestri Ponente 526 Italy 527 Email: daniele.ceccarelli@ericsson.com