idnits 2.17.1 draft-ietf-ccamp-gmpls-g-694-lambda-labels-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 454. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 425. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 432. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 438. 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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document updates RFC3471, but the abstract doesn't seem to directly say this. It does mention RFC3471 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. (Using the creation date from RFC3471, updated by this document, for RFC5378 checks: 2000-10-23) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 27, 2008) is 5785 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: 'G.694' is mentioned on line 203, but not defined Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT Tomohiro Otani 3 Updates: RFC 3471 KDDI R&D Labs 4 Intended status: standard track (Editor) 5 Expires: Nov. 27, 2008 May 27, 2008 7 Generalized Labels for G.694 Lambda-Switching Capable Label Switching 8 Routers 10 Document: draft-ietf-ccamp-gmpls-g-694-lambda-labels-01.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Abstract 35 Technology in the optical domain is constantly evolving and as a 36 consequence new equipment providing lambda switching capability has 37 been developed and is currently being deployed. However, RFC 3471 has 38 defined that a wavelength label (section 3.2.1.1) "only has 39 significance between two neighbors" and global wavelength continuity 40 is not considered. In order to achieve interoperability in a network 41 composed of next generation lambda switch-capable equipment, this 42 document defines a standard lambda label format, being compliant with 43 ITU-T G.694. Moreover some consideration on how to ensure lambda 44 continuity with RSVP-TE is provided. This document is a companion to 45 the Generalized Multi-Protocol Label Switching (GMPLS) signaling. It 46 defines the label format when Lambda Switching is requested in an all 47 optical network. 49 Table of Contents 50 Status of this Memo................................................ 1 51 Abstract........................................................... 1 52 1. Introduction.................................................... 3 53 2. Conventions used in this document............................... 3 54 3. Assumed network model and related problem statement............. 3 55 4. Label Related Formats........................................... 5 56 5. Security consideration.......................................... 8 57 6. Acknowledgement................................................. 8 58 7. References...................................................... 8 59 7.1. Normative References.......................................... 8 60 7.2. Informative References........................................ 8 61 Editor's address................................................... 9 62 Contributors' address.............................................. 9 63 Intellectual property considerations............................... 9 64 Copyright statement............................................... 10 65 1. Introduction 67 As described in [RFC3945], Generalized MPLS (GMPLS) extends MPLS from 68 supporting only packet (Packet Switching Capable - PSC) interfaces 69 and switching to also include support for four new classes of 70 interfaces and switching: 71 o Layer-2 Switch Capable (L2SC) 72 o Time-Division Multiplex (TDM) 73 o Lambda Switch Capable (LSC) 74 o Fiber-Switch Capable (FSC). 75 A functional description of the extensions to MPLS signaling needed 76 to support new classes of interfaces and switching is provided in 77 [RFC3471]. 79 This document presents details that are specific to the use of GMPLS 80 with a new generation of Lambda Switch Capable (LSC) equipment. 81 Technologies such as Reconfigurable Optical Add/Drop Multiplex 82 (ROADM) and Wavelength Cross-Connect (WXC) operate at the wavelength 83 switching level. As such, the wavelength is important information 84 that is necessary to set up a wavelength-based LSP appropriately and 85 the wavelength defined in [G.694] is widely utilized. 87 2. Conventions used in this document 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in RFC-2119 [RFC2119]. 93 3. Assumed network model and related problem statement 95 Figure 1 depicts an all-optically switched network consisting of 96 different vendor's optical network domains. Vendor A's network is a 97 ring topology that consists of ROADM or WXC, and vendor B's network 98 is a mesh topology consisting of PXCs and DWDMs, otherwise both 99 vendors' networks are based on the same technology. 101 In this case, the use of standardized wavelength label information is 102 quite significant to establish a wavelength-based LSP. It is also an 103 important constraint when conducting CSPF calculation for RSVP-TE 104 signaling. The way the CSPF is performed is outside the scope of this 105 document, but defined in [GMPLS-CSPF]. 107 It is needless to say, a LSP must be appropriately provisioned 108 between a selected pair of ports not only within Domain A but also 109 over multiple domains satisfying wavelength constraints. 111 Figure 2 illustrates in detail the interconnection between Domain A 112 and Domain B. 114 | 115 Domain A (or Vendor A) | Domain B (or Vendor B) 116 | 117 Node-1 Node-2 | Node-6 Node-7 118 +--------+ +--------+ | +-------+ +-+ +-+ +-------+ 119 | ROADM | | ROADM +---|------+ PXC +-+D| |D+-+ PXC | 120 | or WXC +========+ or WXC +---|------+ +-+W+=====+W+-+ | 121 | (LSC) | | (LSC) +---|------+ (LSC) +-+D| |D+-+ (LSC) | 122 +--------+ +--------+ | | +-|M| |M+-+ | 123 || || | +++++++++ +-+ +-+ +++++++++ 124 || Node-3 || | ||||||| ||||||| 125 || +--------+ || | +++++++++ +++++++++ 126 ||===| WXC +===|| | | DWDM | | DWDM | 127 | (LSC) | | +--++---+ +--++---+ 128 ||===+ +===|| | || || 129 || +--------+ || | +--++---+ +--++---+ 130 || || | | DWDM | | DWDM | 131 +--------+ +--------+ | +++++++++ +++++++++ 132 | ROADM | | ROADM | | ||||||| ||||||| 133 | or WXC +========+ or WXC +=+ | +-+ +++++++++ +-+ +-+ +++++++++ 134 | (LSC) | | (LSC) | | | |D|-| PXC +-+D| |D+-+ PXC | 135 +--------+ +--------+ +=|==+W|-| +-+W+=====+W+-+ | 136 Node-4 Node-5 | |D|-| (LSC) +-+D| |D+-+ (LSC) | 137 | |M|-| +-+M| |M+-+ | 138 | +-+ +-------+ +-+ +-+ +-------+ 139 | Node-8 Node-9 141 Figure 1 Wavelength-based network model. 143 +-------------------------------------------------------------+ 144 | Domain A | Domain B | 145 | | | 146 | +---+ lambda 1 | +---+ | 147 | | |---------------|---------| | | 148 | WDM | N | lambda 2 | | N | WDM | 149 | =====| O |---------------|---------| O |===== | 150 | O | D | . | | D | O | 151 | T WDM | E | . | | E | WDM T | 152 | H =====| 2 | lambda n | | 7 |===== H | 153 | E | |---------------|---------| | E | 154 | R +---+ | +---+ R | 155 | | | 156 | N +---+ | +---+ N | 157 | O | | | | | O | 158 | D WDM | N | | | N | WDM D | 159 | E =====| O | WDM | | O |===== E | 160 | S | D |=========================| D | S | 161 | WDM | E | | | E | WDM | 162 | =====| 5 | | | 8 |===== | 163 | | | | | | | 164 | +---+ | +---+ | 165 +-------------------------------------------------------------+ 166 Figure 2 Interconnecting details between two domains. 168 In the scenario of Figure 2, consider the setting up of a 169 bidirectional LSP from ingress switch 1 to egress switch 4. In order 170 to satisfy wavelength continuity constraint, a fixed wavelength 171 (lambda 1) needs to be used in domain A and domain B. A Path message 172 will be used for the signaling, the PATH message must contain the 173 upstream label and a label set object; both containing the same 174 lambda. The label set object is made by only one sub channel that 175 must be same as the upstream label. The path setup will continue 176 downstream to switch 4 by configuring each lambda switch based on the 177 wavelength label. This label allows the correct switching of lambda 178 switches and the label contents needs to be used over the inter- 179 domain. As same above, the path setup will continue downstream to 180 switch 7 by configuring lambda switch based on multiple wavelength 181 labels. If the node has a tunable wavelength transponder, the tuning 182 wavelength is considered as a part of wavelength switching operation. 184 Not using a standardized label would add undue burden on the operator 185 to enforce policy as each manufacturer may decide on a different 186 representation and therefore each domain may have its own label 187 formats. Moreover, manual provisioning may lead to misconfiguration 188 if domain-specific labels are used. 190 Therefore, a wavelength label should be standardized in order to 191 allow interoperability between multiple domains; otherwise 192 appropriate existing labels are identified in support of wavelength 193 availability. As identical wavelength information, the ITU-T 194 frequency grid specified in [G.694.1] for Dense WDM (DWDM) and 195 wavelength information in [G.694.2] for Coarse WDM (CWDM) are used by 196 LSRs and should be followed as a wavelength label. 198 4. Label Related Formats 200 To deal with the widening scope of MPLS into the optical and time 201 domains, several new forms of "label" have been defined in [RFC3471]. 202 This section contains clarifications for the Wavelength label based 203 on [G.694] and Label Set definition specific for LSC LSRs. 205 4.1 Wavelength Labels 207 In section 3.2.1.1 of [RFC3471], a Wavelength label is defined to 208 have significance between two neighbors, and the receiver may need to 209 convert the received value into a value that has local significance. 211 LSC equipment uses multiple wavelengths controlled by a single 212 control channel. In such case, the label indicates the wavelength to 213 be used for the LSP. This document proposes to standardize the 214 wavelength label. As an example of wavelength values, the reader is 215 referred to [G.694.1] which lists the frequencies from the ITU-T DWDM 216 frequency grid. The same can be done for CWDM technology by using 217 the wavelength defined in [G.694.2]. In that sense, we can call G.694 218 wavelength labels. 220 Since the ITU-T DWDM grid is based on nominal central frequencies, we 221 need to indicate the appropriate table, the channel spacing in the 222 grid and a value n that allows the calculation of the frequency. 223 That value can be positive or negative. 225 The frequency is calculated as such in [G.694.1]: 227 Frequency (THz) = 193.1 THz + n * channel spacing (THz) 229 , where n is an integer (positive, negative or 0) and channel spacing 230 is defined to be 0.0125, 0.025, 0.05 or 0.1 THz. When wider channel 231 spacing such as 0.2 THz is utilized, the combination of narrower 232 channel spacing and the value n can provide proper frequency with 233 that channel spacing. Channel spacing is not utilized to indicate the 234 LSR capability but only to specify a frequency in signaling. 236 For the other example of the case of the ITU-T CWDM grid, the spacing 237 between different channels was defined to be 20nm, so we need to pass 238 the wavelength value in nm in this case. Examples of CWDM 239 wavelengths are 1470, 1490, etc. nm. 241 The wavelength is calculated as follows 243 Wavelength (nm) = 1470 nm + n * 20 nm 245 The tables listed in [G.694.1] and [G.694.2] are not numbered and 246 change with the changing frequency spacing as technology advances, so 247 an index is not appropriate in this case. 249 4.2 DWDM Wavelength Label 251 For the case of DWDM, the information carried in a Wavelength label 252 is: 254 0 1 2 3 255 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 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 |Grid | C.S |S| Reserved | n | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 (1) Grid: 3 bits 262 The value for grid is set to 1 for ITU-T DWDM Grid as defined in 263 [G.694.1]. 265 +----------+---------+ 266 | Grid | Value | 267 +----------+---------+ 268 |ITU-T DWDM| 1 | 269 +----------+---------+ 270 |ITU-T CWDM| 2 | 271 +----------+---------+ 272 |Future use| 3 - 7 | 273 +----------+---------+ 275 (2) C.S.(channel spacing): 4 bits 277 DWDM channel spacing is defined as follows. 279 +----------+---------+ 280 | C.S(GHz) | Value | 281 +----------+---------+ 282 | 12.5 | 1 | 283 +----------+---------+ 284 | 25 | 2 | 285 +----------+---------+ 286 | 50 | 3 | 287 +----------+---------+ 288 | 100 | 4 | 289 +----------+---------+ 290 |Future use| 5 - 15 | 291 +----------+---------+ 293 (3) S: 1 bit 295 Sign for the value of n, set to 1 for (-) and 0 for (+) 297 (4) n: 16 bits 299 The value used to compute the frequency as shown above. 301 4.3 CWDM Wavelength Label 303 For the case of CWDM, the information carried in a Wavelength label 304 is: 306 0 1 2 3 307 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 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 |Grid | Reserved | n | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 (1) Grid: 3 bits 314 The value for grid is set to 2 for ITU-T CWDM Grid as defined in 315 [G.694.2]. 317 +----------+---------+ 318 | Grid | Value | 319 +----------+---------+ 320 |ITU-T DWDM| 1 | 321 +----------+---------+ 322 |ITU-T CWDM| 2 | 323 +----------+---------+ 324 |Future use| 3 - 7 | 325 +----------+---------+ 326 (2) Lambda: 8 bits 328 The value used to compute the wavelength as shown above. 330 We do not need to define a new type as the information stored is 331 either a port label or a wavelength label. Only the wavelength label 332 as above needs to be defined. 334 5. Security consideration 336 This document introduces no new security considerations to [RFC3473]. 337 GMPLS security is described in section 11 of [RFC3471] and refers to 338 [RFC3209] for RSVP-TE. 340 6. Acknowledgement 342 The authors would like to thank Adrian Farrel, Lawrence Mao and Zafar 343 Ali for the discussion. 345 7. References 347 7.1. Normative References 349 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 350 Requirement Levels", BCP 14, RFC 2119, March 1997. 352 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 353 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 354 3209, December 2001. 356 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 357 (MPLS) Signaling Functional Description", RFC 3471, January 2003. 359 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 360 (MPLS) Signaling - Resource ReserVation Protocol Traffic Engineering 361 (RSVP-TE) Extensions", RFC 3473, January 2003. 363 [RFC3945] Mannie, E., Ed., "Generalized Multiprotocol Label Switching 364 (GMPLS) Architecture", RFC 3945, October 2004. 366 7.2. Informative References 368 [GMPLS-CSPF] Otani, T., et al, "Considering Generalized Multiprotocol 369 Label Switching Traffic Engineering Attributes During Path 370 Computation", draft-otani-ccamp-gmpls-cspf-constraints-07.txt, Nov. 371 2007. 373 [G.694.1] ITU-T Recommendation G.694.1, "Spectral grids for WDM 374 applications: DWDM frequency grid", June 2002. 376 [G.694.2] ITU-T Recommendation G.694.2, "Spectral grids for WDM 377 applications: CWDM wavelength grid", December 2003. 379 Editor's address 381 Tomohiro Otani 382 KDDI R&D Laboratories, Inc. 383 2-1-15 Ohara Kamifukuoka Saitama, 356-8502, Japan 384 Phone: +81-49-278-7357 385 Email: otani@kddilabs.jp 387 Contributors' address 389 Richard Rabbat 390 Google, Inc. 391 1600 Amphitheatre Pkwy 392 Mountain View, CA 94043 393 Email: rabbat@alum.mit.edu 395 Sidney Shiba 396 Email: sidney.shiba@yahoo.com 398 Hongxiang Guo 399 KDDI R&D Laboratories, Inc. 400 2-1-15 Ohara Fujimino Saitama, 356-8502, Japan. 401 Phone: +81-49-278-7864. 402 Email: ho-guo@kddilabs.jp 404 Keiji Miyazaki 405 Fujitsu Laboratories Ltd 406 4-1-1 Kotanaka Nakahara-ku, Kawasaki Kanagawa, 211-8588, Japan 407 Phone: +81-44-754-2765 408 Email: miyazaki.keiji@jp.fujitsu.com 410 Diego Caviglia 411 Ericsson 412 16153 Genova Cornigliano, ITALY 413 Phone: +390106003736 414 Email: diego.caviglia@ericsson.com 416 Intellectual property considerations 418 The IETF takes no position regarding the validity or scope of any 419 Intellectual Property Rights or other rights that might be claimed to 420 pertain to the implementation or use of the technology described in 421 this document or the extent to which any license under such rights 422 might or might not be available; nor does it represent that it has 423 made any independent effort to identify any such rights. Information 424 on the procedures with respect to rights in RFC documents can be 425 found in BCP 78 and BCP 79. 427 Copies of IPR disclosures made to the IETF Secretariat and any 428 assurances of licenses to be made available, or the result of an 429 attempt made to obtain a general license or permission for the use of 430 such proprietary rights by implementers or users of this 431 specification can be obtained from the IETF on-line IPR repository at 432 http://www.ietf.org/ipr. 434 The IETF invites any interested party to bring to its attention any 435 copyrights, patents or patent applications, or other proprietary 436 rights that may cover technology that may be required to implement 437 this standard. Please address the information to the IETF at ietf- 438 ipr@ietf.org. 440 Copyright statement 442 Copyright (C) The IETF Trust (2008). 444 This document is subject to the rights, licenses and restrictions 445 contained in BCP 78, and except as set forth therein, the authors 446 retain all their rights. 448 This document and the information contained herein are provided on an 449 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 450 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 451 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 452 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 453 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 454 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.