CCAMP Working Group S. Shiba Internet Draft Fujitsu Updates: RFC 3471 R. Rabbat Proposed Status: Standards Track Fujitsu Expires: September 2006 T. Otani KDDI R&D Laboratories, Inc. March 5, 2006 Generalized Labels of Lambda-Switching Capable Label Switching Routers (LSR) draft-shiba-ccamp-gmpls-lambda-labels-01.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. This document may only be posted in an Internet-Draft. 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 This Internet-Draft will expire on September 5, 2006. 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. RFC 3471 [RFC3471] Shiba Expires September 5, 2006 [Page 1] Internet-Draft Generalized Labels for LSC LSRs March 2006 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 generation of lambda switch-capable equipment, this document explains new models that require standardization of the label. It highlights new operator requirements and describes signaling and routing extensions to satisfy those requirements. 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. Conventions used in this document 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 [RFC2119]. Table of Contents 1. Introduction...................................................2 2. Changes from version -00.......................................5 3. Operator Requirements on Label Identification..................5 4. Label Related Formats..........................................5 4.1. Wavelength Labels.........................................6 5. Advertising Wavelength Availability............................8 5.1. Wavelength Mask in OSPF-TE................................8 5.2. Wavelength Mask in ISIS-TE...............................10 6. IANA Considerations...........................................10 7. Security Considerations.......................................10 8. Acknowledgments...............................................11 9. References....................................................12 9.1. Normative References.....................................12 9.2. Informative References...................................13 Author's Addresses...............................................13 Intellectual Property Statement..................................14 Disclaimer of Validity...........................................14 Copyright Statement..............................................14 Acknowledgment...................................................14 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 for four new classes of interfaces and switching: Layer-2 Switch Capable (L2SC), Time- Division Multiplex (TDM), Lambda Switch Capable (LSC) and Fiber- Shiba Expires September 5, 2006 [Page 2] Internet-Draft Generalized Labels for LSC LSRs March 2006 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]. This document presents details that are specific to the use of GMPLS with a new generation of Lambda Switch Capable (LSC) equipment. Technologies such as Reconfigurable Optical Add/Drop Multiplex (ROADM) operate at the wavelength switching level. As such, the wavelength is important information that is necessary to set up a wavelength LSP successfully. +--------------------------------------------------------------+ | Domain A | Domain B | | | alien lambda | | | | | | v | | +---+ +---+ lambda 1 +-----+ lambda 1' +---+ +---+ | | | | | |----------|G.709|---------- | | | | | | |L S| |L S| +-----+ | |L S| |L S| | | |A W| |A W| lambda 2 +-----+ lambda 2' |A W| |A W| | | |M I|WDM|M I|----------|G.709|-----------|M I|WDM|M I| | | |B T|===|B T| . +-----+ | |B T|===|B T| | | |D C| |D C| . . | |D C| |D C| | | |A H| |A H| lambda n +-----+ lambda n' |A H| |A H| | | | 1| | 2|----------|G.709|-----------| 3| | 4| | | | | | | +-----+ | | | | | | | +---+ +---+ tunable | +---+ +---+ | | lasers | | +--------------------------------------------------------------+ Figure 1 Interconnecting ROADMs between two domains Consider the architecture described in Figure 1. This architecture shows two domains A and B. In domain A, there are two wavelength switches, connected through WDM. So is the case in domain B. At the interface between domains A and B is a battery of G.709 transponders. These transponders are operated in domain A. The wavelengths coming from domain B to the G.709 transponders are considered alien wavelengths. G.709 Transponders can support tunable lasers on both sides and as is seen in the figure, only one node needs to provide the G.709 interfacing capability. The alien wavelength is a narrow band optical signal provided by a 3rd party node. This setup simplifies the network design vs. the use of transponders on each of the domain A and domain B sides. It is expected that a network design tool will compute wavelength paths based on a number of optical constraints as well as wavelength Shiba Expires September 5, 2006 [Page 3] Internet-Draft Generalized Labels for LSC LSRs March 2006 availability. The computation and communication of the results of the computation are outside the scope of this draft. The results of the computation can be used as Explicit Route Object (ERO) for signaling. In the scenario of Figure 1, consider the setting up of a bidirectional LSR from ingress switch 1 to egress switch 4. A certain wavelength (lambda-i) will be used in domain A up to the G.709 transponder, whose tunable laser in domain A will be tuned to lambda-i. A Path message will be used for the signaling. The Path setup will continue downstream to switch 4. The tunable laser facing downstream at the G.709 transponder need not be tuned immediately. Note that the Path message may contain a Label Set in the Path message to indicate the tuning range of the laser but that's not a requirement. The nodes in domain B select a different wavelength (lambda-i') for domain B. The transponder ultimately needs to know the wavelength it should tune to in the direction of the egress switch 4. The egress will then send back a Resv message toward switch 1. The Resv message will carry the wavelength information (lambda-i') to the G.709 transponder using an Upstream Label. This label allows the correct tuning of the lasers of the G.709 transponders in addition to being able to switch the correct wavelength. While previously, wavelength label information was only required intra-domain, the label contents need to be used inter-domain in this case. In addition, for the intra-domain case, there are more motivations for standardizing the wavelength label including: 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. port, wavelength label or waveband label. In order to be able to generate that wavelength information, it is important to have a common understanding of the wavelength information. 2. Not using a standardized label would add undue burden on the operator to enforce policy as each manufacturer may decide on a different representation and therefore each domain may have its own label formats. 3. Manual provisioning may lead to misconfiguration if domain- specific labels are used. Shiba Expires September 5, 2006 [Page 4] Internet-Draft Generalized Labels for LSC LSRs March 2006 2. Changes from version -00 o Removed the discussion about global meaning o Removed the use of the suggested IEEE format as it gives rounding errors o Added co-author o Added an interoperability scenario that GMPLS should support o Added a section that clarifies operator requirements o Defined new sub-TLVs for advertising wavelength availability 3. Operator Requirements on Label Identification We list some operator requirements in this section. 1. A wavelength label SHOULD be standardized in order to allow interoperability between multiple domains; otherwise appropriate existing labels are identified in support of wavelength availability. 2. The ITU-T frequency grid specified in [G.694.1] for Dense WDM (DWDM) and wavelength information in [G.694.2] for Coarse WDM (CWDM) SHOULD be used by LSC LSRs when setting up LSPs. 3. Labels SHOULD be stable and not allow for rounding errors 4. An operator MAY want to advertise wavelength availability in the network 5. Care SHOULD be taken if advertising the wavelength availability in order to reduce impact on the existing OSPF-TE. 6. To decrease the probability of operators' error or difficulties, it is RECOMMENDED that advertising using OSPF-TE/ISIS-TE be standardized to simplify management 7. Existing labels should be still utilized appropriately even if wavelength availability is advertised. 4. 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]. Shiba Expires September 5, 2006 [Page 5] Internet-Draft Generalized Labels for LSC LSRs March 2006 This section contains clarifications for the Wavelength label and Label Set definition specific for LSC LSRs. 4.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. LSC equipment uses multiple wavelengths controlled by a single control channel. In such case, the label indicates the wavelength to be used for the LSP. This document proposes to standardize the wavelength label. 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]. Since the ITU-T DWDM grid is based on nominal central frequencies, we will indicate the appropriate table, the channel spacing in the grid and a value n that allows the calculation of the frequency. That value can be positive or negative. The frequency is calculated as such in [G.694.1]: Frequency (THz) = 193.1 THz + n * channel spacing (THz) Where n is an integer (positive, negative or 0) Channel spacing is defined to be 0.0125, 0.025, 0.05 or 0.1 THz For the other example of the case of the ITU-T CWDM grid, the spacing between different channels was defined to be 20nm, so we need to pass the wavelength value in nm in this case. Examples of CWDM wavelengths are 1271, 1291, etc. nm. The tables listed in [G.694.1] and [G.694.2] are not numbered and change with the changing frequency spacing as technology advances, so an index is not appropriate in this case. 4.1.1. DWDM Wavelength Label For the case of DWDM, the information carried in a Wavelength label is: Shiba Expires September 5, 2006 [Page 6] Internet-Draft Generalized Labels for LSC LSRs March 2006 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Grid | C.S.|S| n | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Grid: 3 bits The value for grid is set to 1 for ITU-T DWDM Grid as defined in [G.694.1] C.S.: 3 bits DWDM channel spacing +----------+---------+ | C.S(GHz) | Value | +----------+---------+ | 12.5 | 1 | +----------+---------+ | 25 | 2 | +----------+---------+ | 50 | 3 | +----------+---------+ | 100 | 4 | +----------+---------+ S: 1 bit Sign for the value of n, set to 1 for (-) and 0 for (+) n: 9 bits The value used to compute the frequency as shown above. 4.1.2. CWDM Wavelength Label For the case of CWDM, 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Grid | Lambda | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Shiba Expires September 5, 2006 [Page 7] Internet-Draft Generalized Labels for LSC LSRs March 2006 Grid: 3 bits The value for grid is set to 2 for ITU-T CWDM Grid as defined in [G.694.2] Lambda: 11 bits Integer value of lambda in nm We do not need to define a new type as the information stored is either a port label or a wavelength label. Only the wavelength label as above needs to be defined. 5. Advertising Wavelength Availability Wavelength availability may be thought of as a constraint in an optical network and may also be thought of as bandwidth availability. WDM (Wavelength Division Multiplexing) is comparable to TDM (Time Division Multiplexing). But LSPs in WDM networks require bandwidth continuity unlike SONET/SDH networks where TSI (Time Slot Interchange) has allowed any-to-any mapping between slots. The corresponding wavelength conversion is not a simple matter and cannot be done all-optically with currently deployed technology. In addition, another difference with SONET/SDH networks is that several optical constraints have to be taken into consideration in computing paths in addition to wavelength continuity. Nevertheless, some of the optical constraints are constant or node properties while others may be manually configured (fiber distances, placement of EDFAs, etc.). Wavelength availability is therefore a bit different and while it may be collected through an EMS/NMS system, operators may want to have it advertised using GMPLS routing. The objective of this section is to standardize the information advertised using OSPF-TE and ISIS-TE if an operator wishes to have it advertised. This allows the operator to parse LSA information without regard to the applied policy in different manufacturer domains. 5.1. Wavelength Availability in OSPF-TE We use an Opaque LSA to advertise in a new TE link sub-TLV the availability of lambdas in one of the grids, by identifying the grid, then setting a bit to 1 or 0 for each lambda entry if the lambda exists or not. Irregular lambdas have to be advertised in separate sub-TLVs. Shiba Expires September 5, 2006 [Page 8] Internet-Draft Generalized Labels for LSC LSRs March 2006 Sub-TLV Type Length Name TBD 4 Irregular Wavelength TBD variable Wavelength mask 5.1.1. Irregular Wavelength in OSPF-TE In the case of DWDM, we advertise in the opaque LSA the same information shown in 4.1.1. In the case of CWDM, we advertise in the opaque LSA the same information shown in 4.1.2. 5.1.2. Wavelength Mask in OSPF-TE In the case of DWDM, the following information will be stored 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Grid | C.S.|S| smallest n |S| largest n | Mask Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|2|3|... | | | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Grid, Channel Spacing, S and n have been defined in section 4.1.1. In the advertisement, we use two values of n, the smallest and the largest values for the lambdas supported. Mask Size: 6 bits Specifies the size of the wavelength mask in bits. For each entry in the octets following, a bit set to 1 means the wavelength is available; 0 means it is not. For the case of CWDM, the information carried in the opaque LSA is: Shiba Expires September 5, 2006 [Page 9] Internet-Draft Generalized Labels for LSC LSRs March 2006 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Grid | Smallest Lambda | Largest Lambda |R| Mask size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|2|3|... | | | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Grid and lambda are as defined in section 4.1. The smallest and largest lambda are obviously the values for smallest and largest wavelength respectively in the network. R: 1 bit Reserved Mask size: 6 bits Specifies the size of the wavelength mask in bits. For each entry in the octets following, a bit set to 1 means the wavelength is available; 0 means it is not. 5.2. Wavelength Mask in ISIS-TE In IS-IS/TE, we define new sub-TLVs for the extended IS reachability TLV. They carry the same information for irregular wavelengths as well as wavelength masks as shown in 5.1. 6. IANA Considerations IANA is requested to assign two new sub-TLV types for irregular wavelength and wavelength map. 7. Security Considerations 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. [RFC4203] specifies security considerations for OSPF-TE and [RFC4205] specifies those for ISIS/TE. Shiba Expires September 5, 2006 [Page 10] Internet-Draft Generalized Labels for LSC LSRs March 2006 8. Acknowledgments The authors would like to thank Adrian Farrel for his feedback and comments and Igor Bryskin for suggesting an advertising scheme. Shiba Expires September 5, 2006 [Page 11] Internet-Draft Generalized Labels for LSC LSRs March 2006 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [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. [RFC3945] Mannie, E., Ed., "Generalized Multiprotocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004. [RFC4203] Kompella, K. and Y. Rekhter (Eds.), "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, October 2005. Shiba Expires September 5, 2006 [Page 12] Internet-Draft Generalized Labels for LSC LSRs March 2006 [RFC4205] Kompella, K. and Y. Rekhter (Eds.), "Intermediate System to Intermediate System (IS-IS) Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4205, October 2005. 9.2. Informative 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. Author's Addresses Sidney Shiba Fujitsu 2801 Telecom Parkway Richardson, TX 75082 United States of America Phone: +1-972-479-6041 Email: sidney.shiba@us.fujitsu.com Richard Rabbat Fujitsu Laboratories of America 1240 East Arques Ave, M/S 345 Sunnyvale, CA 94085 United States of America Phone: +1-408-530-4537 Email: richard@us.fujitsu.com Tomohiro Otani KDDI R&D Laboratories, Inc. 2-1-15 Ohara Fujimino-shi Saitama, 356-8502. Japan Phone: +81-49-278-7357 Email: otani@kddilabs.jp Shiba Expires September 5, 2006 [Page 13] Internet-Draft Generalized Labels for LSC LSRs March 2006 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. 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. Copyright Statement Copyright (C) The Internet Society (2006). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Shiba Expires September 5, 2006 [Page 14]