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