idnits 2.17.1 draft-ietf-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 20, 2015) is 3079 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'G.694.1' -- Obsolete informational reference (is this intentional?): RFC 6982 (Obsoleted by RFC 7942) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 CCAMP 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 19, 2016 November 20, 2015 12 RSVP-TE Signaling Extensions in support of Flexi-grid DWDM networks 14 draft-ietf-ccamp-flexible-grid-rsvp-te-ext-04.txt 16 Abstract 18 This memo describes the extensions to the Resource reSerVation 19 Protocol Traffic Engineering (RSVP-TE) signaling protocol to support 20 Label Switched Paths (LSPs) in a GMPLS-controlled network that 21 includes devices using the flexible optical grid. 23 Status of this Memo 25 This Internet-Draft is submitted to IETF in full conformance with 26 the provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six 34 months and may be updated, replaced, or obsoleted by other documents 35 at any time. It is inappropriate to use Internet-Drafts as 36 reference material or to cite them other than as "work in 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 19, 2016. 46 Copyright Notice 47 Copyright (c) 2015 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' Addresses.................................... 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 Generalized Multi-Protocol Label Switching 107 (GMPLS) [RFC3945] based control of flexi-grid DWDM networks. 109 [RFC6163] provides a framework for GMPLS and Path Computation 110 Element (PCE) control of Wavelength Switched Optical Networks 111 (WSONs), and [WSON-SIG] describes the requirements and protocol 112 extensions for signaling to set up Label Switched Paths (LSPs) in 113 WSONs. 115 This document describes the additional requirements and protocol 116 extensions to Resource reSerVation Protocol-Traffic Engineering 117 (RSVP-TE) [RFC3473] to set up LSPs in networks that support the 118 flexi-grid. 120 2. Terminology 122 For terminology related to flexi-grid, please refer to [FLEX-FWK] 123 and [G.694.1]. 125 2.1. Conventions used in this document 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 129 document are to be interpreted as described in RFC-2119 [RFC2119]. 131 3. Requirements for Flexible Grid Signaling 133 The architecture for establishing LSPs in a flexi-grid network is 134 described in [FLEX-FWK]. 136 An optical spectrum LSP occupies a specific frequency slot, i.e., a 137 range of frequencies. The process of computing a route and the 138 allocation of a frequency slot is referred to as Routing and 139 Spectrum Assignment (RSA). [FLEX-FWK] describes three architectural 140 approaches to RSA: combined RSA, separated RSA, and distributed SA. 141 The first two approaches are referred to as "centralized SA" because 142 both routing and spectrum (frequency slot) assignment are performed 143 by a centralized entity before the signaling procedure. 145 In the case of centralized SA, the assigned frequency slot is 146 specified in the RSVP-TE Path message during LSP setup. In the case 147 of distributed SA, the slot width of the flexi-grid LSP is specified 148 in the Path message, allowing the network elements to select the 149 frequency slot to be used when they process the RSVP-TE messages. 151 If the capability to switch or convert the whole optical spectrum 152 allocated to an optical spectrum LSP is not available at some nodes 153 along the path of the LSP, the LSP is subject to the Optical 154 "Spectrum Continuity Constraint" as described in [FLEX-FWK]. 156 The remainder of this section states the additional requirements for 157 signaling in a flexi-grid network. 159 3.1. Slot Width 161 The slot width is an end-to-end parameter representing how much 162 frequency resource is requested for a flexi-grid LSP. It is the 163 equivalent of optical bandwidth, although the amount of bandwidth 164 associated with a slot width will depend on the signal encoding. 166 Different LSPs may request different amounts of frequency resource 167 in flexible grid networks, so the slot width MUST be carried in the 168 signaling message during LSP establishment. This enables the nodes 169 along the LSP to know how much frequency resource has been requested 170 (in a Path message) and has been allocated (by a Resv message) for 171 the LSP. 173 3.2. Frequency Slot 175 The frequency slot information identifies which part of the 176 frequency spectrum is allocated on each link for an LSP in a flexi- 177 grid network. 179 This information MUST be present in a Resv message to indicate, hop- 180 by-hop, the central frequency of the allocated resource. In 181 combination with the slot width indicated in a Resv message (see 182 Section 3.1) the central frequency carried in a Resv message 183 identifies the resources reserved for the LSP (known as the 184 frequency slot). 186 The frequency slot can be represented by the two parameters as 187 follows: 189 Frequency slot = [(central frequency) - (slot width)/2] ~ 190 [(central frequency) + (slot width)/2] 192 As is common with other resource identifiers (i.e., labels) in GMPLS 193 signaling, it must be possible for the head-end LSP when sending a 194 Path message to suggest or require the central frequency to be used 195 for the LSP. Furthermore, for bidirectional LSPs, the Path message 196 MUST be able to specify the central frequency to be used for reverse 197 direction traffic. 199 As described in [G.694.1], the allowed frequency slots for the 200 flexible DWDM grid have a nominal central frequency (in THz) defined 201 by: 203 193.1 + n * 0.00625 205 where n is zero or a positive or negative integer. 207 The slot width (in GHz) is defined as: 209 12.5 * m 211 where m is a positive integer. 213 It is possible that an implementation supports only a subset of the 214 possible slot widths and central frequencies. For example, an 215 implementation could be built where the nominal central frequency 216 granularity is 12.5 GHz (by only allowing values of n that are even) 217 and that only supports slot widths as a multiple of 25 GHz (by only 218 allowing values of m that are even). 220 Further details can be found in [FLEX-FWK]. 222 4. Protocol Extensions 224 This section defines the extensions to RSVP-TE signaling for GMPLS 225 [RFC3473] to support flexible grid networks. 227 4.1. Traffic Parameters 229 In RSVP-TE, the SENDER_TSPEC object in the Path message indicates 230 the requested resource reservation. The FLOWSPEC object in the Resv 231 message indicates the actual resource reservation. 233 As described in Section 3.1, the slot width represents how much 234 frequency resource is requested for a flexi-grid LSP. That is, it 235 describes the end-to-end traffic profile of the LSP. Therefore, the 236 traffic parameters for a flexi-grid LSP encode the slot width. 238 This document defines new C-Types for the SENDER_TSPEC and FLOWSPEC 239 objects to carry Spectrum Switched Optical Network (SSON) traffic 240 parameters: 242 SSON SENDER_TSPEC: Class = 12, C-Type = TBD1. 244 SSON FLOWSPEC: Class = 9, C-Type = TBD2. 246 The SSON traffic parameters carried in both objects MUST have the 247 same format as shown in Figure 1. 249 0 1 2 3 250 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 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | m | Reserved | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 Figure 1: The SSON Traffic Parameters 257 m (16 bits): a positive integer and the slot width is specified by 258 m*12.5 GHz. 260 The Reserved bits MUST be set to zero and ignored upon receipt. 262 4.1.1. Applicability to Fixed Grid Networks 264 Note that the slot width (i.e., traffic parameters) of a fixed grid 265 defined in [G.694.1] can also be specified by using the SSON traffic 266 parameters. The fixed grid channel spacings (12.5 GHz, 25 GHz, 50 267 GHz, 100 GHz and integer multiples of 100 GHz) are also the 268 multiples of 12.5 GHz, so the m parameter can be used to represent 269 these slot widths. 271 Therefore, it is possible to consider using the new traffic 272 parameter object types in common signaling messages for flexi-grid 273 and legacy DWDM networks. 275 4.2. Generalized Label 277 In the case of a flexible grid network, the labels that have been 278 requested or allocated as signaled in the RSVP-TE objects are 279 encoded as described in [FLEX-LBL]. This new label encoding can 280 appear in any RSVP-TE object or sub-object that can carry a label. 282 As noted in Section 4.2 of [FLEX-LBL], the m parameter forms part of 283 the label as well as part of the traffic parameters. 285 As described in Section 4.3 of [FLEX-LBL], a "compound label", 286 constructed from a concatenation of the flexi-grid LABELs, is used 287 when signaling an LSP that uses multiple flexi-grid slots. 289 4.3. Signaling Procedures 291 There are no differences between the signaling procedure described 292 for LSP control in [FLEX-FWK] and those required for use in a fixed- 293 grid network [WSON-SIG]. Obviously, the TSpec, FlowSpec, and label 294 formats described in Sections 4.1 and 4.2 are used. The signaling 295 procedures for distributed SA and centralized SA can be applied. 297 5. IANA Considerations 299 5.1. RSVP Objects Class Types 301 This document introduces two new Class Types for existing RSVP 302 objects. IANA is requested to make allocations from the "Resource 303 ReSerVation Protocol (RSVP) Parameters" registry using the "Class 304 Names, Class Numbers, and Class Types" sub-registry. 306 Class Number Class Name Reference 307 ------------ ----------------------- --------- 308 9 FLOWSPEC [RFC2205] 310 Class Type (C-Type): 312 (TBD2) SSON FLOWSPEC [This.I-D] 314 Class Number Class Name Reference 315 ------------ ----------------------- --------- 316 12 SENDER_TSPEC [RFC2205] 318 Class Type (C-Type): 320 (TBD1) SSON SENDER_TSPEC [This.I-D] 322 IANA is requested to assign the same value for TBD1 and TBD2, and a 323 value of 8 is suggested. 325 6. Manageability Considerations 327 This document makes minor modifications to GMPLS signaling, but does 328 not change the manageability considerations for such networks. 329 Clearly, protocol analysis tools and other diagnostic aids 330 (including logging systems and MIB modules) will need to be enhanced 331 to support the new traffic parameters and label formats. 333 7. Implementation Status 335 [RFC Editor Note: Please remove this entire seciton prior to 336 publication as an RFC.] 338 This section records the status of known implementations of the 339 protocol defined by this specification at the time of posting of 340 this Internet-Draft, and is based on a proposal described in RFC 341 6982 [RFC6982]. The description of implementations in this section 342 is intended to assist the IETF in its decision processes in 343 progressing drafts to RFCs. Please note that the listing of any 344 individual implementation here does not imply endorsement by the 345 IETF. Furthermore, no effort has been spent to verify the 346 information presented here that was supplied by IETF contributors. 347 This is not intended as, and must not be construed to be, a catalog 348 of available implementations or their features. Readers are advised 349 to note that other implementations may exist. 351 According to RFC 6982, "this will allow reviewers and working groups 352 to assign due consideration to documents that have the benefit of 353 running code, which may serve as evidence of valuable 354 experimentation and feedback that have made the implemented 355 protocols more mature. It is up to the individual working groups to 356 use this information as they see fit." 358 7.1. Centre Tecnologic de Telecomunicacions de Catalunya (CTTC) 360 Organization Responsible for the Implementation: 361 Centre Tecnologic de Telecomunicacions de Catalunya (CTTC) 362 Optical Networks and Systems Department 364 Implementation Name and Details: 365 ADRENALINE testbed 366 http://networks.cttc.es/experimental-testbeds/ 368 Brief Description: 369 Experimental testbed implementation of GMPLS/PCE control plane. 371 Level of Maturity: 372 Implemented as extensions to a mature GMLPS/PCE control plane. 373 It is limited to research / prototyping stages, but it has been 374 used successfully for more than the last five years. 376 Coverage: 377 Support for the Tspec, FlowSpec, and label formats as described 378 version 03 of this document. Label format support extends to the 379 following RSVP-TE objects and sub-objects: 381 - Generalized Label Object 382 - Suggested Label Object 383 - Upstream Label Object 384 - ERO Label Subobjects 386 It is expected that this implementation will evolve to follow the 387 evolution of this document. 389 Licensing: 390 Proprietary 392 Implementation Experience: 393 Implementation of this document reports no issues. 394 General implementation experience has been reported in a number 395 of journal papers. Contact Ramon Casellas for more information or 396 see 398 http://networks.cttc.es/publications/?search=GMPLS&research_area=opt 399 ical-networks-systems 401 Contact Information: 402 Ramon Casellas: ramon.casellas@cttc.es 404 Interoperability: 405 No report. 407 8. Acknowledgments 409 This work was supported in part by the FP-7 IDEALIST project under 410 grant agreement number 317999. 412 9. Security Considerations 414 This document introduces no new security considerations to [RFC3473]. 416 See also [RFC5920] for a discussion of security considerations for 417 GMPLS signaling. 419 10. References 421 10.1. Normative References 423 [RFC2119] S. Bradner, "Key words for use in RFCs to indicate 424 requirements levels", RFC 2119, March 1997. 426 [RFC3473] L. Berger, Ed., "Generalized Multi-Protocol Label 427 Switching (GMPLS) Signaling Resource ReserVation Protocol- 428 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 429 January 2003. 431 [G.694.1] ITU-T Recommendation G.694.1 (revision 2), "Spectral grids 432 for WDM applications: DWDM frequency grid", February 2012. 434 [FLEX-LBL] King, D., Farrel, A. and Y. Li, "Generalized Labels for 435 the Flexi-Grid in Lambda Switched Capable (LSC) Label 436 Switching Routers", draft-ietf-ccamp-flexigrid-lambda- 437 label, work in progress. 439 10.2. Informative References 441 [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching 442 (GMPLS)" Architecture, RFC3945, October 2004. 444 [RFC2205] Braden, R., Zhang L., Berson, S., Herzog, S. and S. Jamin, 445 "Resource ReServation Protocol (RSVP) -- Version 1, 446 Functional Specification", RFC2205, September 1997. 448 [RFC5920] L. Fang et al., "Security Framework for MPLS and GMPLS 449 Networks", RFC 5920, July 2010. 451 [RFC6163] Y. Lee, G. Bernstein and W. Imajuku, "Framework for GMPLS 452 and Path Computation Element (PCE) Control of Wavelength 453 Switched Optical Networks (WSONs)", RFC 6163, April 2011. 455 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 456 Code: The Implementation Status Section", RFC 6982, July 457 2013. 459 [RFC Editor Note: This reference can be removed when Section 7 is 460 removed] 462 [FLEX-FWK] Gonzalez de Dios, O, Casellas R., Zhang, F., Fu, X., 463 Ceccarelli, D., and I. Hussain, "Framework and 464 Requirements for GMPLS based control of Flexi-grid DWDM 465 networks", draft-ietf-ccamp-flexi-grid-fwk, work in 466 progress. 468 [WSON-SIG] G. Bernstein, Sugang Xu, Y. Lee, G. Martinelli and 469 Hiroaki Harai, "Signaling Extensions for Wavelength 470 Switched Optical Networks", draft-ietf-ccamp-wson- 471 signaling, work in progress. 473 11. Contributors' Addresses 475 Ramon Casellas 476 CTTC 477 Av. Carl Friedrich Gauss n7 478 Castelldefels, Barcelona 08860 479 Spain 481 Email: ramon.casellas@cttc.es 483 Felipe Jimenez Arribas 484 Telefonica Investigacion y Desarrollo 485 Emilio Vargas 6 486 Madrid, 28045 487 Spain 488 Email: felipej@tid.es 490 Yi Lin 491 Huawei Technologies Co., Ltd. 492 F3-5-B R&D Center, Huawei Base, 493 Bantian, Longgang District 494 Shenzhen 518129 P.R.China 496 Phone: +86-755-28972914 497 Email: yi.lin@huawei.com 498 Qilei Wang 499 ZTE 500 wang.qilei@zte.com.cn 502 Haomian Zheng 503 Huawei Technologies 504 zhenghaomian@huawei.com 506 12. Authors' Addresses 508 Fatai Zhang 509 Huawei Technologies 510 Email: zhangfatai@huawei.com 512 Xian Zhang 513 Huawei Technologies 514 Email: zhang.xian@huawei.com 516 Adrian Farrel 517 Old Dog Consulting 518 Email: adrian@olddog.co.uk 520 Oscar Gonzalez de Dios 521 Telefonica Investigacion y Desarrollo 522 Emilio Vargas 6 523 Madrid, 28045 524 Spain 525 Phone: +34 913374013 526 Email: ogondio@tid.es 528 Daniele Ceccarelli 529 Ericsson 530 Via A. Negrone 1/A 531 Genova - Sestri Ponente 532 Italy 533 Email: daniele.ceccarelli@ericsson.com