CCAMP Working Group Sidney Shiba (Fujitsu) Internet Draft Richard Rabbat (Fujitsu) Updates: 3471 Proposed Category: Standards Track Expires: March 2006 September 2005 Generalized Labels of Lambda-Switching Capable Label Switching Routers (LSR)s draft-shiba-ccamp-gmpls-lambda-labels-00.doc.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119, reference [RFC2119]. Abstract Technology in the optical domain is constantly evolving and as a consequence new equipment providing lambda switching capability has been developed and is currently being deployed. [RFC3471] has defined that a wavelength label (section 3.2.1.1) "only has significance between two neighbors". However, in a network composed of a new Expires March 2006 [Page 1] Generalized Labels for LSC-Capable LSRs October 2005 generation of lambda switch-capable equipment, this document explains why the label should have global meaning similarly to the label defined for SONET/SDH technology (SUKLM format defined in [RFC3946]) and describes extensions to enable global meaning. This document is a companion to the Generalized Multi-Protocol Label Switching (GMPLS) signaling. It defines the Label Switching Capable (LSC) technology specific information needed when using GMPLS. Table of Contents 1. Introduction.....................................................2 1.1. Problem Description............................................2 2. Label Related Formats............................................4 2.1. Wavelength Labels..............................................4 2.2. Label Set Wavelength Subchannel................................4 2.3. RSVP-TE Extensions.............................................5 3. IANA Considerations..............................................5 4. Security Considerations..........................................5 5. Acknowledgements.................................................6 6. References.......................................................7 6.1. Normative References...........................................7 6.2. Informative Reference..........................................8 7. Copyright Statement.............................................10 8. Intellectual Property Statement.................................11 1. Introduction As described in [RFC3945], Generalized MPLS (GMPLS) extends MPLS from supporting only packet (Packet Switching Capable - PSC) interfaces and switching to also include support of four new classes of interfaces and switching: Layer-2 Switch Capable (L2SC), Time- Division Multiplex (TDM), Lambda Switch Capable (LSC) and Fiber- Switch Capable (FSC). A functional description of the extensions to MPLS signaling needed to support new classes of interfaces and switching is provided in [RFC3471]. 1.1. Problem Description This document presents details that are specific to the use of GMPLS with a new generation of Lambda Switch Capable (LSC) equipment as opposed to a the prior generation of LSC equipment composed of of Wavelength Division Multiplexing (WDM) + Photonic Cross Connect (PXC) combined system (shown below) that was originally considered at the time of writing of RFC 3471. Expires October 2005 [Page 2] Generalized Labels for LSC-Capable LSRs October 2005 Technologies such as Reconfigurable Optical Add/Drop Multiplex (ROADM) and Dynamic-OADM operate at the wavelength switching level. As such, the wavelength is important information that is necessary to successfully setup a wavelength LSP. _______ _______ _______ /|_|6 1|_|\ /|_|5 1|_|\ /|_|5 1|_|\ | |_|7 PXC 2|_| | WDM | |_|6 PXC 2|_| | WDM | |_|6 PXC 2|_| | WDM ===| |_|8 (1) 3|_| |=====| |_|7 (2) 3|_| |======| |_|7 (3) 3|_| |==== | |_|9 4|_| | | |_|8 4|_| | | |_|8 4|_| | \| |_______| |/ \| |_______| |/ \| |_______| |/ For technologies such as the ROADM and DOADM, the WDM port mapping does not provide sufficient information for selecting the required wavelength for an LSP. Here are four cases that highlight where it is important to have wavelength information available globally. 1. Label Set: A Label Set object may be used to limit the label choices of a downstream node (section 3.5 of RFC 3471). This Label Set object needs to carry one of the labels defined in section 3.2 of that same document, i.e. either port, wavelength label or waveband label. In order to be able to generate that wavelength information, it is important to have global dissemination of wavelength information. 2. Explicit Route Object/Record Route Object: Here as well, any meaningful information should be global, which implies the use of wavelength since a locally-significant label will have no meaning. 3. In SONET/SDH, one can think of the label with the set values of SUKLM bits as locally significant and set their values as a matter of policy to have global meaning. This would add undue burden on the operator to enforce policy. In addition, manual provisioning may lead to misconfiguration. 4. Finally, the values for the wavelengths need to be out of the same pool of values to have global meaning. Any representation of the lambdas needs to be the same on all nodes irrespective of the manufacturer. _______ _______ _______ | | | | | | WDM | LSC | WDM | LSC | WDM | LSC | WDM =======|1 2|=========|1 2|=========|1 2|======= | | | | | | |_______| |_______| |_______| Expires October 2005 [Page 3] Generalized Labels for LSC-Capable LSRs October 2005 The ITU-T frequency grid specified in [G.694.1] for Dense WDM (DWDM) and [G.694.2] for Coarse WDM (CWDM) are the labels that SHOULD be used by these LSC LSRs. 2. Label Related Formats To deal with the widening scope of MPLS into the optical and time domains, several new forms of "label" have been defined in [RFC3471]. This section contains clarifications for the Wavelength label and Label Set definition specific for LSC LSRs. 2.1. Wavelength Labels In section 3.2.1.1 of [RFC3471], a Wavelength label is defined to have significance between two neighbors, and the receiver may need to convert the received value into a value that has local significance. Equipment providing "true" lambda switching (LSC) uses multiple wavelengths controlled by a single control channel. In such case, the label indicates the wavelength to be used for the LSP. In order to allow global meaning, this document redefines the Wavelength label as being an IEEE floating point encoding of the wavelength. As an example of wavelength values, the reader is referred to [G.694.1] which lists the frequencies from the ITU-T DWDM frequency grid. The same can be done for CWDM technology by using the wavelength defined in [G.694.2]. The information carried in a Wavelength label is: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Label: 32 bits The label indicates the frequency value to be used. The value is IEEE Floating point encoded. This may be an ITU-T DWDM frequency. For convenience, Appendix 1 provides the list of IEEE Floating point values for the ITU-T DWDM frequency grid. 2.2. Label Set Wavelength Subchannel This document aligns with the general definition of Label Set in section 3.5 of [RFC3471]. However, it provides a clarification Expires October 2005 [Page 4] Generalized Labels for LSC-Capable LSRs October 2005 related to the subchannel value to be used by an LSC LSR. For this type of equipment the subchannel field SHOULD represent the Wavelength label (ITU-T DWDM frequency grid). 2.3. RSVP-TE Extensions In other to distinguish Wavelength label with local significance from the Wavelength label with global meaning, the latter SHOULD use the same format as the generalized label with the new C-Type (TBA). In the context of "true" lambda switching, the generalized label has the following format: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Class-Num (16)| C-Type (TBA) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ITU-T DWDM Frequency Grid Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3. IANA Considerations IANA assigns values to RSVP protocol parameters. Within the current document an object is defined. This object contains a C-Type. This section defines the rules for the assignment of the related C-Type value. This section uses the terminology of BCP 26 "Guidelines for Writing an IANA Considerations Section in RFCs" [BCP26]. As per [RFC2205], C-Type is an 8-bit number that identifies the function of an object. All possible values except zero are available for assignment. The assignment of the C-Type value of the object defined in this document inherits C-Type from the Label object, i.e., object class number 16 [RFC3209]. The Wavelength Switching Label defined in this document has the following C-Type value to be assigned by IANA: o RSVP_LABEL (Class-Num = 16) - Wavelength Switching Label (C-Type = To Be Assigned) 4. Security Considerations Expires October 2005 [Page 5] Generalized Labels for LSC-Capable LSRs October 2005 There may be an argument that by giving the label global meaning, one would decrease security. The closest example of using global meaning is the label setting for SONET/SDH. By using a global meaning for its labels, SONET/SDH did not introduce any new security considerations. This serves as an indication that this document introduces no new security considerations to either [RFC3473] or [RFC3472]. GMPLS security is described in section 11 of [RFC3471] and refers to [RFC3209] for RSVP-TE and to [RFC3212] for CR-LDP. 5. Acknowledgements The authors would like to thank Adrian Farrel for his feedback and comments. Expires October 2005 [Page 6] Generalized Labels for LSC-Capable LSRs October 2005 6. References 6.1. Normative References [G.694.1] ITU-T Recommendation G.694.1, "Spectral grids for WDM applications: DWDM frequency grid", June 2002. [G.694.2] ITU-T Recommendation G.694.2, "Spectral grids for WDM applications: CWDM wavelength grid", December 2003. [IEEE754] "Standard for Binary Floating-Point Arithmetic", IEEE- 754, 1985. [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) - Version 1 Functional Specification", RFC 2205, September 1997. [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RFC3212] Jamoussi, B., Andersson, L., Callon, R., Dantu, R., Wu, L., Doolan, P., Worster, T., Feldman, N., Fredette, A., Girish, M., Gray, E., Heinanen, J., Kilty, T., and A. Malis, "Constrained-Based LSP Setup using LDP", RFC 3212, January 2002. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels," BCP 14, IETF RFC 2119, March 1997. [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (MPLS) Signaling Functional Description", RFC 3471, January 2003. [RFC3472] Ashwood-Smith, P. and L. Berger, "Generalized Multi- Protocol Label Switching (MPLS) Signaling - Constraint- based Routed Label Distribution Protocol (CR-LDP) Extensions", RFC 3472, January 2003. [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (MPLS} Signaling - Resource ReserVation Protocol Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. Expires October 2005 [Page 7] Generalized Labels for LSC-Capable LSRs October 2005 [RFC3945] Mannie, E., Ed., "Generalized Multiprotocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004. 6.2. Informative Reference [BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC2026] Bradner, S., "The Internet Standards Process - Revision 3", BCP 9, RFC 2026, October 1996. Appendix 1 - ITU-T DWDM frequency grid and IEEE floating point The list below illustrates some nominal central frequencies within the C and L bands of the DWDM grid (12.5THz spacing) taken from [G.694.1]and their respective IEEE floating point (32 bits encoding) value [IEEE754]. Nominal central Wavelength label Frequency (THz) (IEEE Floating point) --------------------- ------------------------ . . . . . . 195.9375 0x4343F000 195.9250 0x4343ECCD 195.9125 0x4343E99A 195.9000 0x4343E666 195.8875 0x4343E333 195.8750 0x4343E000 195.8625 0x4343DCCD 195.8500 0x4343D99A 195.8375 0x4343D666 195.8250 0x4343D333 195.8125 0x4343D000 195.8000 0x4343CCCD 195.7875 0x4343C99A 195.7750 0x4343C666 195.7625 0x4343C333 195.7500 0x4343C000 195.7375 0x4343BCCD 195.7250 0x4343B99A 195.7125 0x4343B666 195.6875 0x4343B000 195.6750 0x4343ACCD Expires October 2005 [Page 8] Generalized Labels for LSC-Capable LSRs October 2005 195.6625 0x4343A99A . . . . . . . . . . . . 193.2375 0x43413CCD 193.2250 0x4341399A 193.2125 0x43413666 193.2000 0x43413333 193.1875 0x43413000 193.1750 0x43412CCD 193.1625 0x4341299A 193.1500 0x43412666 193.1375 0x43412333 193.1250 0x43412000 193.1125 0x43411CCD 193.1000 0x4341199A 193.0875 0x43411666 193.0750 0x43411333 193.0625 0x43411000 193.0500 0x43410CCD 193.0375 0x4341099A 193.0250 0x43410666 193.0125 0x43410333 193.0000 0x43410000 192.9875 0x4340FCCD 192.9750 0x4340F99A 192.9625 0x4340F666 . . . . . . . . . . . . 184.7750 0x4338C666 184.7625 0x4338C333 184.7500 0x4338C000 184.7375 0x4338BCCD 184.7250 0x4338B99A 184.7125 0x4338B666 184.7000 0x4338B333 184.6875 0x4338B000 184.6750 0x4338ACCD 184.6625 0x4338A99A 184.6500 0x4338A666 184.6375 0x4338A333 Expires October 2005 [Page 9] Generalized Labels for LSC-Capable LSRs October 2005 184.6250 0x4338A000 184.6125 0x43389CCD 184.6000 0x4338999A 184.5875 0x43389666 184.5750 0x43389333 184.5625 0x43389000 184.5500 0x43388CCD 184.5375 0x4338899A 184.5250 0x43388666 184.5125 0x43388333 184.5000 0x43388000 . . . . . . Authors' Addresses Sidney Shiba (Fujitsu) 2801 Telecom Parkway Richardson, TX 75082, USA Phone: +1 972 479 6041 Email: sidney.shiba@us.fujitsu.com Richard Rabbat (Fujitsu) 1240 East Arques Ave, MS 345 Sunnyvale, CA 94085, USA Phone: +1 408 530 4537 Email: richard@us.fujitsu.com Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 7. Copyright Statement Expires October 2005 [Page 10] Generalized Labels for LSC-Capable LSRs October 2005 Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 8. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Expires October 2005 [Page 11]