Network Working Group G. Bernstein Internet Draft Grotto Networking Intended status: Standards Track Sugang Xu NICT Expires: January 2010 Y.Lee Huawei Hiroaki Harai NICT D. King July 8, 2009 Signaling Extensions for Wavelength Switched Optical Networks draft-bernstein-ccamp-wson-signaling-04.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 This Internet-Draft will expire on December 8, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Expires January 8, 2010 [Page 1] Internet-Draft WSON Signaling Extensions July 2009 Abstract This memo provides extensions to Generalized Multi-Protocol Label Switching (GMPLS) signaling for control of wavelength switched optical networks (WSON). These extensions build on previous work for the control of G.709 based networks. 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 [RFC2119]. Table of Contents 1. Introduction...................................................2 2. Terminology....................................................3 3. Requirements for WSON Signaling................................4 3.1. WSON Signal Characterization..............................4 3.2. Bi-Directional Distributed Wavelength Assignment..........4 3.3. Distributed Wavelength Assignment Support.................5 3.4. Out of Scope..............................................5 4. WSON Signal Types, Forward Error Correction, and Rates.........6 4.1. Traffic Parameters for Optical Tributary Signals..........6 5. Bidirectional Lightpath using Same Wavelength..................7 5.1. Using LSP_ATTRIBUTES Object...............................7 5.2. Bidirectional Lightpath Signaling Procedure...............8 5.3. Backward Compatibility Considerations.....................9 6. Bidirectional Lightpath using Different Wavelengths............9 7. RWA Related....................................................9 7.1. Wavelength Assignment Method Selection....................9 8. Security Considerations.......................................10 9. IANA Considerations...........................................10 10. Acknowledgments..............................................10 11. References...................................................11 11.1. Normative References....................................11 11.2. Informative References..................................11 Author's Addresses...............................................13 Intellectual Property Statement..................................14 Disclaimer of Validity...........................................14 1. Introduction This memo provides extensions to Generalized Multi-Protocol Label Switching (GMPLS) signaling for control of wavelength switched optical networks (WSON). In particular, extensions are given to Bernstein et al. Expires January 8, 2010 [Page 2] Internet-Draft WSON Signaling Extensions July 2009 characterize optical signal types via traffic parameters, permit simultaneous bi-directional wavelength assignment, and control the distributed wavelength assignment process. These extensions build on previous work for the control of G.709 based networks. 2. Terminology CWDM: Coarse Wavelength Division Multiplexing. DWDM: Dense Wavelength Division Multiplexing. FOADM: Fixed Optical Add/Drop Multiplexer. ROADM: Reconfigurable Optical Add/Drop Multiplexer. A reduced port count wavelength selective switching element featuring ingress and egress line side ports as well as add/drop side ports. RWA: Routing and Wavelength Assignment. Wavelength Conversion/Converters: The process of converting an information bearing optical signal centered at a given wavelength to one with "equivalent" content centered at a different wavelength. Wavelength conversion can be implemented via an optical-electronic- optical (OEO) process or via a strictly optical process. WDM: Wavelength Division Multiplexing. Wavelength Switched Optical Networks (WSON): WDM based optical networks in which switching is performed selectively based on the center wavelength of an optical signal. AWG: Arrayed Waveguide Grating. OXC: Optical Cross Connect. Optical Transmitter: A device that has both a laser tuned on certain wavelength and electronic components, which converts electronic signals into optical signals. Optical Responder: A device that has both optical and electronic components. It detects optical signals and converts optical signals into electronic signals. Optical Transponder: A device that has both an optical transmitter and an optical responder. Bernstein et al. Expires January 8, 2010 [Page 3] Internet-Draft WSON Signaling Extensions July 2009 Optical End Node: The end of a wavelength (optical lambdas) lightpath in the data plane. It may be equipped with some optical/electronic devices such as wavelength multiplexers/demultiplexer (e.g. AWG), optical transponder, etc., which are employed to transmit/terminate the optical signals for data transmission. 3. Requirements for WSON Signaling The following requirements for GMPLS based WSON signaling are in addition to the functionality already provided by existing GMPLS signaling mechanisms. 3.1. WSON Signal Characterization WSON signaling MUST convey sufficient information characterizing the signal to allow systems along the path to determine compatibility and perform any required local configuration. Examples of such systems include intermediate nodes (ROADMs, OXCs, Wavelength converters, Regenerators, OEO Switches, etc...), links (WDM systems) and end systems (detectors, demodulators, etc...). The details of any local configuration are out of the scope of this document. 3.2. Bi-Directional Distributed Wavelength Assignment WSON signaling MAY support distributed wavelength assignment consistent with the wavelength continuity constraint for bi- directional connections. The following two cases MAY be separately supported: (a) Where the same wavelength is used for both upstream and downstream directions, and (b) Where different wavelengths can be used for both upstream and downstream directions. The need for the same wavelength on both directions mainly comes from the color constraint on some edges' hardware. In fact, the edges can be classified into two types, i.e. without and with the wavelength- port mapping re-configurability. Without the mapping re-configurability at edges, the edge nodes must use the same wavelength in both directions. For example, (1) transponders are only connected to AWGs (i.e. multiplexer/de- multiplexer) ports directly and fixedly, or (2) transponders are connected to the add/drop ports of ROADM and each port is mapped to a dedicated wavelength fixedly. On the other hand, with the mapping re-configurability at edges, the edge nodes can use different wavelengths in different directions. For Bernstein et al. Expires January 8, 2010 [Page 4] Internet-Draft WSON Signaling Extensions July 2009 example, in edge nodes, transponders are connected to add/drop ports of colorless ROADM. Thus, the wavelength-port remapping problem can be solved locally by appropriately configuring the colorless ROADM. If the colorless ROADM consists of OXC and AWGs, the OXC is configured appropriately. The edges of data-plane in WSON can be constructed in different types based on cost and flexibility concerns. Without re-configurability we should consider the constraint of the same wavelength usage on both directions, but have lower costs. While, with wavelength-port mapping re-configurability we can relax the constraint, but have higher costs. These two types of edges will co-exist in WSON mesh, till all the edges are unified by the same type. The existence of the first type edges presents a requirement of the same wavelength usage on both directions, which must be supported. Moreover, if some carriers prefer an easy management lightpath usage, say use the same wavelength on both directions to reduce the burden on lightpath management, the same wavelength usage would be beneficial. In cases of equipment failure, etc., fast provisioning used in quick recovery is critical to protect Carriers/Users against system loss. This requires efficient signaling which supports distributed wavelength assignment, in particular when the centralized wavelength assignment capability is not available. 3.3. Distributed Wavelength Assignment Support WSON signaling MAY support the selection of a specific distributed wavelength assignment method. As discussed in the [WSON-Frame] a variety of different wavelength assignment algorithms have been developed. A number of these are suitable for use in distributed wavelength assignment. This feature would allow the specification of a particular approach when more than one are implemented in the systems along the path. 3.4. Out of Scope This draft does not address signaling information related to optical impairments. Bernstein et al. Expires January 8, 2010 [Page 5] Internet-Draft WSON Signaling Extensions July 2009 4. WSON Signal Types, Forward Error Correction, and Rates As discussed in [WSON-Comp] single channel optical signals used in WSONs are called "optical tributary signals" and come in a number of classes characterized by modulation format and bit rate. Although WSONs are fairly transparent to the signals they carry, to ensure compatibility amongst various networks devices and end systems it can be important to include key lightpath characteristics as traffic parameters in signaling [WSON-Comp]. 4.1. Traffic Parameters for Optical Tributary Signals As in [RFC4606] and [RFC4328] the following traffic parameters would become the contents for the RSVP SENDER_TSPEC and FLOWSPEC objects. The WSON traffic parameters SHOULD be defined as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mod Type | Mod Params| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bit Rate | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Modulation (Mod) Types: Value Type ----- ---- 0 Unspecified or Unknown 1 NRZ 2 RZ Modulation Parameters(Mod Params): Are specific to the modulation type. For RZ modulation type we have the following modulation parameters and meanings. RZ 0 - 33%, 1 - 50%, 2 - 67% duty cycles Bernstein et al. Expires January 8, 2010 [Page 6] Internet-Draft WSON Signaling Extensions July 2009 See [G.959.1] and [Winzer06]. These are specific to the modulation type employed and may or may not be used. For example NRZ modulation typically doesn't have extra parameters, while RZ modulation has a duty cycle parameter. Bitrate: This is the bit rate given as a 32 bit IEEE floating point number. 5. Bidirectional Lightpath using Same Wavelength With the wavelength continuity constraint in CI-incapable [RFC3471] WSONs, where the nodes in the networks cannot support wavelength conversion, the same wavelength on each link along a unidirectional lightpath should be reserved. Per the definition in [RFC3471], a bidirectional lightpath can be seen as a pair of unidirectional lightpaths, which are provisioned along the same route simultaneously by the RSVP-TE signaling with Upstream Label and Label Set Objects in the messages [RFC3473]. This does not necessarily require the same wavelength in both directions. In addition to the wavelength continuity constraint, requirement 3.2 gives us another constraint on wavelength usage in data plane, in particular, it requires the same wavelength to be used in both directions. The simplest and efficient way is to only define an extension to the processing of Label Set [RFC3473], and leave the other processes untouched. The issues related to this new functionality including an LSP_ATTRIBUTES object defined in [RFC5420] and the new procedure are described in the following sections. This approach would have a lower blocking probability and a shorter provisioning time. In cases of equipment failure, etc., fast provisioning used in quick recovery is critical to protect Carriers/Users against system loss. 5.1. Using LSP_ATTRIBUTES Object To trigger the new functionality at each GMPLS node, it is necessary to notify the receiver the new type lightpath request. One multi- purpose flag/attribute parameter container object called LSP_ATTRIBUTES object and related mechanism defined in [RFC5420] meet this requirement. One bit in Attributes Flags TLV which indicates the new type lightpath, say, the bidirectional same wavelength lightpath will be present in an LSP_ATTRIBUTES object. Please refer to [RFC5420] for detailed descriptions of the Flag and related issues. Bernstein et al. Expires January 8, 2010 [Page 7] Internet-Draft WSON Signaling Extensions July 2009 5.2. Bidirectional Lightpath Signaling Procedure Considering the system configuration mentioned above, it is needed to add a new function into RSVP-TE to support bidirectional lightpath with same wavelength on both directions. The lightpath setup procedure is described below: 1. Ingress node adds the new type lightpath indication in an LSP_ATTRIBUTES object. It is propagated in the Path message in the same way as that of a Label Set object for downstream; 2. On reception of a Path message containing both the new type lightpath indication in an LSP_ATTRIBUTES object and Label Set object, the receiver of message along the path checks the local LSP database to see if the Label Set TLVs are acceptable on both directions jointly. If there are acceptable wavelengths, then copy the values of them into new Label Set TLVs, and forward the Path message to the downstream node. Otherwise the Path message will be terminated, and a PathErr message with a "Routing problem/Label Set" indication will be generated; 3. On reception of a Path message containing both such a new type lightpath indication in an LSP_ATTRIBUTES object and an Upstream Label object, the receiver MUST terminate the Path message using a PathErr message with Error Code "Unknown Attributes TLV" and Error Value set to the value of the new type lightpath TLV type code; 4. On reception of a Path message containing both the new type lightpath indication in an LSP_ATTRIBUTES object and Label Set object, the egress node verifies whether the Label Set TLVs are acceptable, if one or more wavelengths are available on both directions, then any one available wavelength could be selected. A Resv message is generated and propagated to upstream node; 5. When a Resv message is received at an intermediate node, if it is a new type lightpath, the intermediate node allocates the label to interfaces on both directions and update internal database for this bidirectional same wavelength lightpath, then configures the local ROADM or OXC on both directions. Except the procedure related to Label Set object, the other processes will be left untouched. Bernstein et al. Expires January 8, 2010 [Page 8] Internet-Draft WSON Signaling Extensions July 2009 5.3. Backward Compatibility Considerations Due to the introduction of new processing on Label Set object, it is required that each node in the lightpath is able to recognize the new type lightpath indication Flag carried by an LSP_ATTRIBUTES object, and deal with the new Label Set operation correctly. It is noted that this new extension is not backward compatible. According to the descriptions in [RFC5420], an LSR that does not recognize a TLV type code carried in this object MUST reject the Path message using a PathErr message with Error Code "Unknown Attributes TLV" and Error Value set to the value of the Attributes Flags TLV type code. An LSR that does not recognize a bit set in the Attributes Flags TLV MUST reject the Path message using a PathErr message with Error Code "Unknown Attributes Bit" and Error Value set to the bit number of the new type lightpath Flag in the Attributes Flags.The reader is referred to the detailed backward compatibility considerations expressed in [RFC5420]. 6. Bidirectional Lightpath using Different Wavelengths TBD 7. RWA Related 7.1. Wavelength Assignment Method Selection As discussed in [HZang00] a number of different wavelength assignment algorithms maybe employed. In addition as discussed in [WSON-Frame] the wavelength assignment can be either for a unidirectional lightpath or for a bidirectional lightpath constrained to use the same lambda in both directions. A simple TLV could be used to indication wavelength assignment directionality and wavelength assignment method. This would be placed in an LSP_REQUIRED_ATTRIBUTES object per [RFC5420]. The use of a TLV in the LSP required attributes object was pointed out in [Xu]. [TO DO: The directionality stuff needs to be reconciled with the earlier material] Directionality: 0 unidirectional, 1 bidirectional Bernstein et al. Expires January 8, 2010 [Page 9] Internet-Draft WSON Signaling Extensions July 2009 Wavelength Assignment Method: 0 unspecified (any), 1 First-Fit, 2 Random, 3 Least-Loaded (multi-fiber). Others TBD. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Direction | WA Method | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8. Security Considerations This document has no requirement for a change to the security models within GMPLS and associated protocols. That is the OSPF-TE, RSVP-TE, and PCEP security models could be operated unchanged. However satisfying the requirements for RWA using the existing protocols may significantly affect the loading of those protocols. This makes the operation of the network more vulnerable to denial of service attacks. Therefore additional care maybe required to ensure that the protocols are secure in the WSON environment. Furthermore the additional information distributed in order to address the RWA problem represents a disclosure of network capabilities that an operator may wish to keep private. Consideration should be given to securing this information. 9. IANA Considerations TBD. Once finalized in our approach we will need identifiers for such things and modulation types, modulation parameters, wavelength assignment methods, etc... 10. Acknowledgments This document was prepared using 2-Word-v2.0.template.dot. Bernstein et al. Expires January 8, 2010 [Page 10] Internet-Draft WSON Signaling Extensions July 2009 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003. [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol- Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. [RFC4328] Papadimitriou, D., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control", RFC 4328, January 2006. [RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, J.-P., and A. Ayyangar, " Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)", RFC 5420, February 2006. [RFC4606] Mannie, E. and D. Papadimitriou, "Generalized Multi- Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control", RFC 4606, August 2006. 11.2. Informative References [WSON-Comp] G. Bernstein, Y. Lee, Ben Mack-Crane, "WSON Signal Characteristics and Network Element Compatibility Constraints for GMPLS", work in progress: draft-bernstein- ccamp-wson-signal. [WSON-Frame] G. Bernstein, Y. Lee, W. Imajuku, "Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks", work in progress: draft-bernstein-ccamp-wavelength- switched-03.txt, February 2008. Bernstein et al. Expires January 8, 2010 [Page 11] Internet-Draft WSON Signaling Extensions July 2009 [HZang00] H. Zang, J. Jue and B. Mukherjeee, "A review of routing and wavelength assignment approaches for wavelength-routed optical WDM networks", Optical Networks Magazine, January 2000. [Xu] S. Xu, H. Harai, and D. King, "Extensions to GMPLS RSVP-TE for Bidirectional Lightpath the Same Wavelength", work in progress: draft-xu-rsvpte-bidir-wave-01, November 2007. [Winzer06] Peter J. Winzer and Rene-Jean Essiambre, "Advanced Optical Modulation Formats", Proceedings of the IEEE, vol. 94, no. 5, pp. 952-985, May 2006. [G.959.1] ITU-T Recommendation G.959.1, Optical Transport Network Physical Layer Interfaces, March 2006. [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. [G.Sup43] ITU-T Series G Supplement 43, Transport of IEEE 10G base-R in optical transport networks (OTN), November 2006. [RFC4427] Mannie, E., Ed., and D. Papadimitriou, Ed., "Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4427, March 2006. Bernstein et al. Expires January 8, 2010 [Page 12] Internet-Draft WSON Signaling Extensions July 2009 Author's Addresses Greg M. Bernstein (editor) Grotto Networking Fremont California, USA Phone: (510) 573-2237 Email: gregb@grotto-networking.com Nicola Andriolli Scuola Superiore Sant'Anna, Pisa, Italy Email: a.giorgetti@sssup.it Aessio Giorgetti Scuola Superiore Sant'Anna, Pisa, Italy Email: a.giorgetti@sssup.it Lin Guo Key Laboratory of Optical Communication and Lightwave Technologies Ministry of Education P.O. Box 128, Beijing University of Posts and Telecommunications, P.R.China Email: guolintom@gmail.com Hiroaki Harai National Institute of Information and Communications Technology 4-2-1 Nukui-Kitamachi, Koganei, Tokyo, 184-8795 Japan Phone: +81 42-327-5418 Email: harai@nict.go.jp Yuefeng Ji Key Laboratory of Optical Communication and Lightwave Technologies Ministry of Education P.O. Box 128, Beijing University of Posts and Telecommunications, P.R.China Email: jyf@bupt.edu.cn Daniel King (editor) Old Dog Consulting Email: daniel@olddog.co.uk Young Lee (editor) Huawei Technologies Bernstein et al. Expires January 8, 2010 [Page 13] Internet-Draft WSON Signaling Extensions July 2009 1700 Alma Drive, Suite 100 Plano, TX 75075 USA Phone: (972) 509-5599 (x2240) Email: ylee@huawei.com Sugang Xu National Institute of Information and Communications Technology 4-2-1 Nukui-Kitamachi, Koganei, Tokyo, 184-8795 Japan Phone: +81 42-327-6927 Email: xsg@nict.go.jp Intellectual Property Statement The IETF Trust 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 any IETF 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. Copies of Intellectual Property 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 any standard or specification contained in an IETF Document. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity All IETF Documents and the information contained therein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY Bernstein et al. Expires January 8, 2010 [Page 14] Internet-Draft WSON Signaling Extensions July 2009 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Bernstein et al. Expires January 8, 2010 [Page 15]