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