idnits 2.17.1 draft-zhang-ccamp-flexible-grid-rsvp-te-ext-00.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 document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 24 has weird spacing: '... months and ...' == Line 25 has weird spacing: '... at any time...' == Line 26 has weird spacing: '...ference mate...' == Line 455 has weird spacing: '... of these ...' == Line 456 has weird spacing: '...cluding thos...' == (3 more instances...) -- The document date (October 16, 2011) is 4574 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: 'RFC 6163' is mentioned on line 114, but not defined == Unused Reference: 'WSON-PCE' is defined on line 342, but no explicit reference was found in the text == Unused Reference: 'RFC6163' is defined on line 360, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'G.694.1v1' == Outdated reference: A later version (-15) exists of draft-ietf-pce-wson-routing-wavelength-05 ** Downref: Normative reference to an Informational draft: draft-ietf-pce-wson-routing-wavelength (ref. 'WSON-PCE') == Outdated reference: A later version (-12) exists of draft-ietf-ccamp-wson-signaling-02 ** Downref: Normative reference to an Informational RFC: RFC 6163 -- Possible downref: Non-RFC (?) normative reference: ref. 'G.FLEXIGRID' Summary: 3 errors (**), 0 flaws (~~), 12 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 Huawei 3 Intended status: Standards Track Oscar Gonzalez de Dios 4 Telefonica 5 D. Ceccarelli 6 Ericsson 7 Expires: April 16, 2012 October 16, 2011 9 RSVP-TE Signaling Extensions in support of Flexible Grid 11 draft-zhang-ccamp-flexible-grid-rsvp-te-ext-00.txt 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with 16 the provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other 25 documents at any time. It is inappropriate to use Internet-Drafts 26 as reference material or to cite them other than as "work in 27 progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on April 16, 2012. 37 Abstract 39 This memo describes the signaling extensions of GMPLS control of 40 flexible grid network. 42 Conventions used in this document 44 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 45 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 46 document are to be interpreted as described in RFC-2119 [RFC2119]. 48 Table of Contents 50 1. Introduction ................................................. 2 51 2. Requirements for Flexible Grid Signaling ..................... 3 52 2.1. Slot Width .............................................. 3 53 2.2. Frequency Slot .......................................... 3 54 3. Extensions ................................................... 4 55 3.1. WSON Traffic Parameters ................................. 5 56 3.2. Generalized Label ....................................... 5 57 3.3. Signaling Procedures .................................... 7 58 3.3.1. Distributed SA ..................................... 7 59 3.3.2. Centralized SA ..................................... 8 60 4. IANA Considerations .......................................... 8 61 5. Security Considerations ...................................... 8 62 6. References ................................................... 8 63 7. Authors' Addresses ........................................... 9 65 1. Introduction 67 [G.694.1v1] defines the DWDM frequency grids for WDM applications. A 68 frequency grid is a reference set of frequencies used to denote 69 allowed nominal central frequencies that may be used for defining 70 applications. The channel spacing, i.e. the frequency spacing 71 between two allowed nominal central frequencies can be 12.5 GHz, 25 72 GHz, 50 GHz, 100 GHz and integer multiples of 100 GHz as defined in 73 [G.694.1v1]. All of the wavelengths on a fiber SHALL use different 74 central frequencies and occupy a fixed bandwidth of frequency. 76 [G.FLEXIGRID], an updated version of [G.694.1v1] will be consented 77 in December 2011 in support of flexible grids. The terms "frequency 78 slot (i.e. the frequency range allocated to a specific channel and 79 unavailable to other channels within a flexible grid)" and "slot 80 width" (i.e. the full width of a frequency slot in a flexible grid) 81 are introduced to define flexible grid. A channel is represented as 82 an LSC (Lambda Switching Capable) LSP in the control plane and 83 SHOULD occupy a frequency slot on each fiber it traverses. In the 84 case of flexible grid, the different LSC LSPs may have different 85 slot width on a fiber, i.e. the slot width is flexible on a fiber. 87 [WSON-SIG] describes the requirements and extensions for WSON 88 signaling. It focuses on the fixed grids control. This document 89 describes the additional requirements and extensions for signaling 90 control brought by flexible grids. 92 2. Requirements for Flexible Grid Signaling 94 An LSC LSP SHOULD occupy a frequency slot, i.e. a range of frequency. 95 The route computation and frequency slot assignment could be called 96 RSA (Routing and Spectrum Assignment). 98 [FLEXIGRID-REQ] describes three types of architecture approaches to 99 RSA, which are: combined RSA, separated RSA and distributed SA. In 100 the case of combined RSA and separated RSA, both the routing and the 101 spectrum (frequency slot) are provided by the RSA algorithm before 102 the signaling procedure. It could be called "centralized SA". In the 103 case of distributed SA, only the route is provided before the 104 signaling procedure and the spectrum assignment is done during the 105 signaling procedure. 107 In the case of centralized SA, the frequency slot SHOULD be 108 specified in the Path message. In the case of distributed SA, the 109 slot width of the LSC LSP SHOULD be specified in the Path message 110 for the purpose of frequency slot assignment. 112 Similar to fixed grid network, if there is no wavelength converter 113 in an optical network, there is "wavelength continuity constraint" 114 of a LSC LSP which is described as section 4 of [RFC 6163]. 116 2.1. Slot Width 118 The slot width is an end-to-end parameter representing how much 119 spectrum resource is requested for a LSC LSP. Since different LSPs 120 may request different amounts of spectrum portion in flexible grid 121 networks, the slot width SHOULD be carried in the signaling message, 122 so that all the nodes along the LSP can know how much spectrum 123 portion will be allocated for the LSP. 125 2.2. Frequency Slot 127 The frequency slot information represents which part of the spectrum 128 portion is allocated on each link for an LSC LSP. This information 129 SHOULD be carried hop-by-hop in signaling message so that each node 130 can indicate its neighbor the resource reservation on the link 131 between them. 133 The frequency slot can be represented by the two parameters: central 134 frequency and slot width, as follows: 136 Frequency slot = [(central frequency) - (slot width)/2] ~ 137 [(central frequency) + (slot width)/2] 139 Since the slot width information is carried in the signaling message 140 (as described in Section 2.1), also the central frequency parameter 141 SHOULD be carried in the signaling message for frequency slot 142 determination. 144 Figure 1 shows an example of two LSC LSPs traversing a link and 145 illustrates how to determine the frequency slot based on the central 146 frequency and slot width information. 148 Frequency Slot 1 Frequency Slot 2 149 ------------- ------------------- 150 | | | | 151 -9 -8 -7 -6 -5 -4 -3 -2 -1 0 1 2 3 4 5 6 7 8 9 10 11 152 ...+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--... 153 ------------- ------------------- 154 ^ ^ 155 Central F = 193.1THz Central F = 193.14375 THz 156 Slot width = 25 GHz Slot width = 37.5 GHz 158 Figure 1 - Two LSC LSPs traverse a Link 160 The two wavelengths shown in figure 1 have the following meaning: 162 LSC LSP 1: central frequency = 193.1 THz, slot width = 25 GHz. It 163 means the frequency slot [193.0875 THz, 193.1125 THz] is assigned to 164 this LSC LSP. 166 LSC LSP 2: central frequency = 193.14375 THz, slot width = 37.5 GHz. 167 It means the frequency slot [193.125 THz, 193.1625 THz] is assigned 168 to this LSC LSP. 170 Note that the frequency slots of two LSC LSPs on a fiber MUST NOT 171 overlap with each other. 173 3. Extensions 175 This section defines the extensions of signaling for flexible grid. 177 3.1. WSON Traffic Parameters 179 As described in Section 2, the slot width represents how much 180 spectrum resource is requested for an LSC LSP, i.e., it describes 181 the end-to-end traffic profile of the LSP. Therefore, the slot width 182 SHOULD be regarded as a traffic parameter for an LSC LSP. 184 The WSON traffic parameters are organized as follows: 186 0 1 2 3 187 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 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | m | Reserved | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 m (8 bits): the slot width is specified by m*12.5 GHz. 194 Note that the slot width of fixed grid defined in [G.694.1v1] can be 195 also specified by m because the defined channel spacing (12.5 GHz, 196 25 GHz, 50 GHz, 100 GHz and integer multiples of 100 GHz) are also 197 the multiple of 12.5 GHz. Therefore, the traffic parameters are 198 general for WSON including both fixed grid and flexible grid. 200 The WSON traffic parameters SHOULD be carried in SENDER_TSPEC or 201 FLOWSPEC objects: 203 WSON SENDER_TSPEC: Class = 12, C-Type = to be assigned by IANA, 204 preferred 8. 206 WSON FLOWSPEC: Class = 9, C-Type = to be assigned by IANA, preferred 207 8. 209 3.2. Generalized Label 211 In the case of flexible grid, the allowed central frequency is 212 calculated as follows: 214 Central Frequency = (193.1 + n * 0.00625) THz 216 Where n is a two's-complement integer (positive, negative, or 0). 218 The Label object is used to indicate the resource reserved on a link. 219 In Flexible Grid networks, it is used to indicate which frequency 220 slot is allocated on a link for the given LSC LSP. 222 Since the frequency slot assigned to an LSC LSP can be determined by 223 the combination of [central frequency, slot width], while the slot 224 width of an LSC LSP is specified in the traffic parameters, the 225 Label object just needs to carry the assigned central frequency. 226 Therefore, the wavelength label format defined in [RFC6205] can be 227 reused to specify the central frequency of an LSC LSP, without any 228 change on the label format. 230 0 1 2 3 231 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 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 |Grid | C.S. | Identifier | n | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 The meaning of Grid, Identifier and n fields are not changed. The 237 usage of the label format is also not changed. 239 According to [G.FLEXIGRID], flexible grid still belongs to DWDM, so 240 there is no need to introduce a new type of Grid, i.e., Grid=1 (ITU- 241 T DWDM) SHOULD be used for flexible grid. 243 In case of Grid=1 (ITU-T DWDM), a new value of C.S. is defined for 244 flexible 6.25 GHz grid. The C.S.(Channel Spacing) field is defined 245 as follows: 247 +-------------+---------+ 248 |C.S. (GHz) | Value | 249 +-------------+---------+ 250 | Reserved | 0 | 251 +-------------+---------+ 252 | 100 | 1 | 253 +-------------+---------+ 254 | 50 | 2 | 255 +-------------+---------+ 256 | 25 | 3 | 257 +-------------+---------+ 258 | 12.5 | 4 | 259 +-------------+---------+ 260 | 6.25 | 5 (TBA) | 261 +-------------+---------+ 262 |Future use | 6 ~ 15 | 263 +-------------+---------+ 265 The value for flexible 6.25 GHz is to be assigned by IANA, preferred 266 5. 268 3.3. Signaling Procedures 270 This section describes the signaling procedures for distributed SA 271 and centralized SA (See [FLEXIGRID-REQ]). 273 3.3.1. Distributed SA 275 In this case, only the route is provided by a PCE or ingress node 276 before the signaling procedure. The available central frequencies 277 will be collected hop by hop and the egress node SHOULD select a 278 proper central frequency for the LSP. 280 After the route is computed, the ingress node SHOULD find out the 281 available central frequencies for the LSP on the next link of the 282 route. If the frequency slot which is determined by a central 283 frequency and slot width of the LSC LSP (See section 2.2) does not 284 overlap with the existing LSC LSPs, the central frequency is 285 considered to be available for the requesting LSC LSP. 287 Then a Path message is sent to the next node on the route. The Path 288 message MUST contain a Flexible Grid SENDER_TSPEC object to specify 289 the slot width of the LSC LSP. A LABEL_SET object SHALL be added to 290 the Path message, which contains the available central frequencies 291 for the LSP on the next link. 293 When an intermediate node receives a Path message, it can get the 294 slot width from the Flexible Grid SENDER_TSPEC object. Then it 295 SHOULD find the available central frequencies for the LSP on the 296 next link of the route similar to the ingress node. The common part 297 of the two available central frequency sets, i.e. the set received 298 from the Path message and the set of the next link, SHALL be 299 selected as the new available central frequency set for the LSP. If 300 the new set is null, the Path message SHALL be rejected by a PathErr 301 message. Otherwise, the LABEL SET object in the Path message SHALL 302 be updated according to the new set and the Path message is 303 forwarded to the next node on the route. 305 When an egress node receives a Path message, it SHOULD select an 306 available central frequency from the LABEL SET object based on local 307 policy and determine the frequency slot based on the slot width and 308 the selected central frequency (See section 2.2). Then a Resv 309 message is responded so that the nodes along the LSP can establish 310 the optical cross-connect based on the frequency slot determined by 311 the slot width in the traffic parameters and the central frequency 312 in the label. 314 3.3.2. Centralized SA 316 In this case, both of the routing and frequency slot are provided by 317 PCE or ingress node. When signaling the LSP, the slot width is 318 carried in the traffic parameters, and the assigned central 319 frequency is carried in the Label ERO. When the nodes along the LSP 320 receive the Path message carrying these information, they can 321 determine the frequency slot by the slot width and the central 322 frequency and then establish the optical cross-connect based on the 323 central frequency. The procedures of ERO and Label ERO are the same 324 as described in [RFC3209] and [RFC3473]. 326 4. IANA Considerations 328 TBD. 330 5. Security Considerations 332 TBD. 334 6. References 336 [RFC2119] S. Bradner, "Key words for use in RFCs to indicate 337 requirements levels", RFC 2119, March 1997. 339 [G.694.1v1] ITU-T Recommendation G.694.1, Spectral grids for WDM 340 applications: DWDM frequency grid, June 2002. 342 [WSON-PCE] Y. Lee, G. Bernstein, Jonas Martensson, T. Takeda and T. 343 Tsuritani, "PCEP Requirements for WSON Routing and 344 Wavelength Assignment", draft-ietf-pce-wson-routing- 345 wavelength-05, July 2011. 347 [WSON-SIG] G. Bernstein, Sugang Xu, Y. Lee, G. Martinelli and 348 Hiroaki Harai, "Signaling Extensions for Wavelength 349 Switched Optical Networks", draft-ietf-ccamp-wson- 350 signaling-02, September 2011. 352 [RFC3209] D. Awduche et al, "RSVP-TE: Extensions to RSVP for LSP 353 Tunnels", RFC3209, December 2001. 355 [RFC3473] L. Berger, Ed., "Generalized Multi-Protocol Label 356 Switching (GMPLS) Signaling Resource ReserVation Protocol- 357 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 358 January 2003. 360 [RFC6163] Y. Lee, G. Bernstein and W. Imajuku, "Framework for GMPLS 361 and Path Computation Element (PCE) Control of Wavelength 362 Switched Optical Networks (WSONs)", RFC 6163, April 2011. 364 [RFC6205] T. Otani and D. Li, "Generalized Labels for Lambda-Switch- 365 Capable (LSC) Label Switching Routers", RFC 6205, March 366 2011. 368 [FLEXIGRID-REQ] F.Zhang et al, "Requirements for GMPLS Control of 369 Flexible Grids",draft-zhang-ccamp-flexible-grid- 370 requirements, in progress. 372 [G.FLEXIGRID] Draft revised G.694.1 version 1.3, Unpublished ITU-T 373 Study Group 15, Question 6. 375 7. Authors' Addresses 377 Fatai Zhang 378 Huawei Technologies 379 F3-5-B R&D Center, Huawei Base 380 Bantian, Longgang District 381 Shenzhen 518129 P.R.China 383 Phone: +86-755-28972912 384 Email: zhangfatai@huawei.com 386 Oscar Gonzalez de Dios 387 Telefonica Investigacion y Desarrollo 388 Emilio Vargas 6 389 Madrid, 28045 390 Spain 392 Phone: +34 913374013 393 Email: ogondio@tid.es 394 Felipe Jimenez Arribas 395 Telefonica Investigacion y Desarrollo 396 Emilio Vargas 6 397 Madrid, 28045 398 Spain 399 Email: felipej@tid.es 401 Daniele Ceccarelli 402 Ericsson 403 Via A. Negrone 1/A 404 Genova - Sestri Ponente 405 Italy 406 Email: daniele.ceccarelli@ericsson.com 408 Xiaobing Zi 409 Huawei Technologies 410 F3-5-B R&D Center, Huawei Base 411 Bantian, Longgang District 412 Shenzhen 518129 P.R.China 414 Phone: +86-755-28973229 415 Email: zixiaobing@huawei.com 417 Yi Lin 418 Huawei Technologies Co., Ltd. 419 F3-5-B R&D Center, Huawei Base, 420 Bantian, Longgang District 421 Shenzhen 518129 P.R.China 423 Phone: +86-755-28972914 424 Email: yi.lin@huawei.com 426 Intellectual Property 428 The IETF Trust takes no position regarding the validity or scope of 429 any Intellectual Property Rights or other rights that might be 430 claimed to pertain to the implementation or use of the technology 431 described in any IETF Document or the extent to which any license 432 under such rights might or might not be available; nor does it 433 represent that it has made any independent effort to identify any 434 such rights. 436 Copies of Intellectual Property disclosures made to the IETF 437 Secretariat and any assurances of licenses to be made available, or 438 the result of an attempt made to obtain a general license or 439 permission for the use of such proprietary rights by implementers or 440 users of this specification can be obtained from the IETF on-line 441 IPR repository at http://www.ietf.org/ipr 443 The IETF invites any interested party to bring to its attention any 444 copyrights, patents or patent applications, or other proprietary 445 rights that may cover technology that may be required to implement 446 any standard or specification contained in an IETF Document. Please 447 address the information to the IETF at ietf-ipr@ietf.org. 449 The definitive version of an IETF Document is that published by, or 450 under the auspices of, the IETF. Versions of IETF Documents that are 451 published by third parties, including those that are translated into 452 other languages, should not be considered to be definitive versions 453 of IETF Documents. The definitive version of these Legal Provisions 454 is that published by, or under the auspices of, the IETF. Versions 455 of these Legal Provisions that are published by third parties, 456 including those that are translated into other languages, should 457 not be considered to be definitive versions of these Legal 458 Provisions. 460 For the avoidance of doubt, each Contributor to the IETF Standards 461 Process licenses each Contribution that he or she makes as part of 462 the IETF Standards Process to the IETF Trust pursuant to the 463 provisions of RFC 5378. No language to the contrary, or terms, 464 conditions or rights that differ from or are inconsistent with the 465 rights and licenses granted under RFC 5378, shall have any effect 466 and shall be null and void, whether published or posted by such 467 Contributor, or included with or in such Contribution. 469 Disclaimer of Validity 471 All IETF Documents and the information contained therein are 472 provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION 473 HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET 474 SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE 475 DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 476 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION THEREIN 477 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 478 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 480 Full Copyright Statement 482 Copyright (c) 2010 IETF Trust and the persons identified as the 483 document authors. All rights reserved. 485 This document is subject to BCP 78 and the IETF Trust's Legal 486 Provisions Relating to IETF Documents 487 (http://trustee.ietf.org/license-info) in effect on the date of 488 publication of this document. Please review these documents 489 carefully, as they describe your rights and restrictions with 490 respect to this document. Code Components extracted from this 491 document must include Simplified BSD License text as described in 492 Section 4.e of the Trust Legal Provisions and are provided without 493 warranty as described in the Simplified BSD License.