Network Working Group G. Bernstein Internet Draft Grotto Networking Updates: 6205 Sugang Xu Intended status: Standards Track
Sugang XuNICT Expires: September 2014Y.Lee Huawei Expires: November 2015 G. Martinelli Cisco Hiroaki Harai NICT March 5,July 3, 2014 Signaling Extensions for Wavelength Switched Optical Networks draft-ietf-ccamp-wson-signaling-07.txtdraft-ietf-ccamp-wson-signaling-08.txt Abstract This memo provides extensions to Generalized Multi-Protocol Label Switching (GMPLS) signaling for control of wavelength switched optical networksWavelength Switched Optical Networks (WSON). Such extensions are applicable in WSONs under a number of conditions including: (a) when optional processing, such as regeneration, must be configured to occur at specific nodes along a path, (b) where equipment must be configured to accept an optical signal with specific attributes, or (c) where equipment must be configured to output an optical signal with specific attributes. In addition this memo provides mechanisms to support distributed wavelength assignment with choice in distributed wavelength assignment algorithms. These extensions build on previous work for the control of lambda and G.709 based networks. This document updates [RFC6205] asnetworks, i.e. update RFC6205, to make it applicable to WSON-LSC capable equipment. 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 September 5, 2014.January 3, 2007. Copyright Notice Copyright (c) 2014 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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...................................................3 2. Terminology....................................................3 3. Requirements for WSON Signaling................................4 3.1. WSON Signal Characterization..............................4 3.2. Per LSP Network ElementNode Processing Configuration..........5Configuration.........................5 3.3. Bidirectional WSON LSPs...................................6 3.4. Distributed Wavelength Assignment Selection Method........6 3.5. Optical Impairments.......................................6 4. WSON Signal Traffic Parameters, Attributes and Processing......6 4.1. Traffic Parameters for Optical Tributary Signals..........7 4.2. WSON Processing HOP Attribute TLV Encoding................7 4.3. Signal Attributes and Processing Capabilities.............8Resource Block Information Sub-TLV........................8 4.4. Wavelength Assignment MethodSelection TLV Encoding.......9Sub-TLV..............................9 5. Security Considerations.......................................10Considerations.......................................11 6. IANA Considerations...........................................10Considerations...........................................12 7. Acknowledgments...............................................11Acknowledgments...............................................13 8. References....................................................12References....................................................14 8.1. Normative References.....................................12References.....................................14 8.2. Informative References...................................13References...................................15 Author's Addresses...............................................15Addresses...............................................16 Intellectual Property Statement..................................16Statement..................................17 Disclaimer of Validity...........................................17Validity...........................................18 1. Introduction This memo provides extensions to Generalized Multi-Protocol Label Switching (GMPLS) signaling for control of wavelength switched optical networksWavelength Switched Optical Networks (WSON). Fundamental extensions are given to permit simultaneous bidirectional wavelength assignment while more advanced extensions are given to support the networks described in [RFC6163] which feature connections requiring configuration of input, output, and general signal processing capabilities at a node along a LSP.Label Switched Path (LSP). These extensions build on previous work for the control of lambda and G.709 based networks [RFC3471].networks. This document updates [RFC6205] as make it applicable to WSON-LSC capable equipment. Related references with this document are [WSON-info][WSON-Info] that provides a high-level information model and and [WSON-Encode] that provides common encodings that can be applicable to other protocol extensions such as routing. 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 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. 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 needs to 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 processes are out of the scope of this document. From [RFC6163] we have the following list of WSON signal characteristic information: List 1. WSON Signal Characteristics 1. Optical tributary signal class (modulation format). 2. FEC: whether forward error correction is used in the digital stream and what type of error correcting code is used 3. Center frequency (wavelength) 4. Bit rate 5. G-PID: General Protocol Identifier for the information format The first three items on this list can change as a WSON signal traverses a network with regenerators, OEO switches, or wavelength converters. These parameters are summarized in the Optical Interface Class as defined in the [WSON-Info] and the assumption is that a class always includes signal compatibility information. An ability to control wavelength conversion already exists in GMPLS signaling along with the ability to share client signal type information (G-PID). In addition, bit rate is a standard GMPLS signaling traffic parameter. It is referred to as Bandwidth Encoding in [RFC3471]. 3.2. Per LSP Network ElementNode Processing Configuration In addition to configuring a network element (NE)node along an LSP to input or output a signal with specific attributes, we may need to signal the NEnode to perform specific processing, such as 3R regeneration, on the signal at a particular NE. In[RFC6163] wediscussed three types of processing not currently covered by GMPLS:processing: (A) Regeneration (possibly different types) (B) Fault and Performance Monitoring (C) Attribute Conversion The extensions here MUSTprovide for the configuration of these types of processing at nodes along an LSP. 3.3. Bidirectional WSON LSPs WSON signaling can support LSP setup consistent with the wavelength continuity constraint for bidirectional connections. The following cases need to be separately supported: (a) Where the same wavelength is used for both upstream and downstream directions (b) Where different wavelengths can be used for both upstream and downstream directions. This document will review currentexisting GMPLS bidirectional solutions according to WSON case. 3.4. Distributed Wavelength Assignment Selection Method WSON signaling can support the selection of a specific distributed wavelength assignment method. This method is beneficial in cases of equipment failure, etc., where 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. As discussed in the [RFC6163] different computational approaches for wavelength assignment are available. One method is the use of distributed wavelength assignment. This feature would allow the specification of a particular approach when more than one is implemented in the systems along the path. 3.5. Optical Impairments This draft does not address signaling information related to optical impairments. 4. WSON Signal Traffic Parameters, Attributes and Processing As discussed in [RFC6163] 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 systemssystems, it can be important to include key lightpath characteristics as traffic parameters in signaling [RFC6163]. LSPs signaled through extensions provided in this document MUST apply the following signaling parameters: . Switching Capability = WSON-LSC ([WSON-OSPF]). . Encoding Type = Lambda ([RFC3471]) . Label Format = as defined in [RFC6205] [RFC6205] defines the label format as applicable to LSC capable device. This document extendextends [RFC6205] as make its label format applicable also to WSON-LSC capable devices. 4.1. Traffic Parameters for Optical Tributary Signals In [RFC3471] we see that the G-PID (client signal type) and bit rate (byte rate) of the signals are defined as parameters and in [RFC3473] they are conveyed Generalized Label Request object and the RSVP SENDER_TSPEC/FLOWSPEC objects respectively. 4.2. WSON Processing HOP Attribute TLV Encoding Section 3.2. provided the requirements for signaling to indicate to a particular NEnode along an LSP what type of processing to perform on an optical signal or how to configure that NEnode to accept or transmit an optical signal with particular attributes. To target a specific node, this section defines a WSON_Processing object as part ofWSON Processing HOP Attribute TLV, which is carried in the LSP_REQUIRED_ATTRIBUTE and follows proceduressubobjects defined in [RSVP-RO]. The contentType value of the WSON Processing HOP Attribute TLV is TBD by IANA. The contents of this TLV is defined in the subsequent sections. (SeeSection 4.3 for <RBInformation> TLVResourceBlockInfo sub-TLV and Section 4.4 for <WavelengthSelection> TLV, respectively.) <WSON_ProcessingWavelengthSelection sub-TLV, respectively. The TLV can be represented in Reduced Backus-Naur Form (RBNF) [RFC5511] syntax as: <WSON Processing HOP Attribute> ::= <RBInformation> [<RBInformation>]< ResourceBlockInfo> [<ResourceBlockInfo>] <WavelengthSelection> The WSON Processing carries sub-TLVsHOP Attribute TLV is a type of the same format asa HOP Attributes TLV, as defined in [RSVP-RO]. 4.3. SignalIf a receiving node does not recognize a sub-TLV, it will follow the procedure defined in [RFC5420], i.e., it MUST generate a PathErr with a new error value of the existing Error Code "Unknown Attributes and Processing CapabilitiesTLV (Sub-codes - 29)". 4.3. Resource Block Information Sub-TLV The [WSON-Encode] already provides all necessary definitions and encoding for WSON information required for signaling. In particular, theResource block information , or ResourceBlockInfo, sub-TLV contains, among others,contains a list of available Optical Interface Classes and processing capabilities. <RBInformation>The format of the ResourceBlockInfo sub-TLV value field is defined in Section 4.14 of [WSON-Encode]. Type Sub-TLV Name 1 (TBA) <RBInformation>ResourceBlockInfo At least one <RBInformation>ResourceBlockInfo sub-TLV MUST alwaysbe present in the WSON_Processing HOP Attribute TLV..TLV. At most two <RBInformation> sub- TLVsResourceBlockInfo sub-TLVs MAY be present in the WSON_Processing HOP Attribute TLV .TLV. If more than two objectssub-TLVs are encountered, the first two MUST be processed and the rest SHOULD be ignored. The <RBInformation><ResourceBlockInfo> contains several information as defined by [WSON-Encode]. The following processing rules apply:apply to the sub-TLV: RB Set Field MAY contain more than one RB Indetifier.Identifier. Only the first oneof which MUST be processed, the others SHOULD be ignored. The I an E flags MUST be set according to bidirectional LSP signaling and the numbers of RBInformation subobjects available.In case of signalin a unidirectional signaling,LSP, only one RBInformartion sub-objectResourceBlockInfo sub-TLV MUST be processed and I/EI/O bits can be safely ignored. In case of signaling a bidirectional signaling:LSP: if only one RBInformartionResourceBlockInfo is available,included, bits I and EO MUST be both set to 1, if two RBInformation sub-objectsResourceBlockInfo sub-TLVs are available,included, bits I and EO MUST have different values.values, i.e., only one bit can be set in each ResourceBlockInfo sub-TLV. Any violation of these detected by a transit or egress node will incur a processing error and SHOULD NOT trigger any RSVP message but can be logged locally, and perhaps reported through network management mechanisms. The rest of information available within RBInformation sub-objectResourceBlockInfo sub-TLV is Optical Interface Class List, Input Bit RangeRate List and Processing Capability List. ListsThese lists MAY contain one or more elements. The usage of WSON Processing objectHOP Attribute TLV for the bidirectional case is the same as per unidirectional. When an intermediate node uses information from this objectTLV to instruct a node about wavelength regeneration, the same information applies to both downstream and upstream directions. This sub-TLV is constructed by an ingress node and the processing is applied to all nodes (transit and egress) whose R bit is set in the ERO HOP ATTRIBUTE subobject according to [RSVP-RO]. When the R bit is set, a node MUST examine the ResourceBlockInfo sub-TLV present in the subobject following the rule described in [RFC5420]. If a node processing an ERO HOP ATTRIBUTE subobject with WSON Processing HOP Attributes TLV (which may include the ResourceBlockInfo sub-TLVs) longer than the ERO subobject SHOULD return a PathErr with an error code "Routing Error" and error value "Bad EXPLICT_ROUTE object" with the EXPLICIT_ROUTE object included as defined in [RSVP-RO] Section 3.3. Once a node properly parsed the Sub-TLV, the node applies the selected regeneration pool (at that hop) for the LSP. In addition, the node SHOULD report compliance by adding a RRO_HOP_ATTRIBUTE subobject with the WSON Processing HOP Attribute TLV (and its sub- TLVs) which describes the attributes to be reported. 4.4. Wavelength Assignment MethodSelection TLV EncodingSub-TLV Routing + Distributed wavelength assignmentWavelength Assignment (R+DWA) is one of the options defined by the [RFC6163]. The output from the routing function will be a path but the wavelength will be selected on a hop-by-hop basis. Under this hypothesishypothesis, the node initiating the signaling process needs to declare its own wavelength availability (through a label_set object). Each intermediate node may delete some labels due to connectivity constraints or its own assignment policy. At the end, the destination node has to make the final decision on the wavelength assignment among the ones received through the signaling process. As discussed in [HZang00][HZang00], a number of different wavelength assignment algorithms maybemay be employed. In addition as discussed in [RFC6163] 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 sub-TLV could be usedIn order to indicationindicate wavelength assignment directionality and wavelength assignment method asmethod, a TLVnew Wavelength Selection, or WavelengthSelection, sub-TLV is defined to be carried in the LSP Attributes Object, asWSON Processing HOP Attribute TLV defined in [RFC5420].Section 4.2 of this draft. The type value of the Sub-TLV is: Type Sub-TLV TDBName 2(TDA) <WavelengthSelection> The WavlengthSelection sub-TLV value field is defined as: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |W| WA Method | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where: .W is a bit,(1 bit): 0 denotes requiring the same wavelength in both directions, 1 may usedenotes that different wavelengths .on both directions are allowed. Wavelength Assignment (WA) Method:Method (7 bits): 0 - unspecified (any),(any); This does not constrain the WA method used by a specific node. 1 First-Fit,- First-Fit. All the wavelengths are numbered and this WA method chooses the available wavelength with the lowest index. 2 Random,- Random. This WA method chooses an available wavelength randomly. 3 - Least-Loaded (multi-fiber). Others TBD. 5. Security ConsiderationsThis document is buildsWA method selects the wavelength that has the largest residual capacity on the mechanisms definedmost loaded link along the route. This method is used in [RFC3473], and only differsmulti-fiber networks. If used in specific information communicated. As such, this document introduces no new security considerationssingle-fiber networks, it is equivalent to the existing GMPLS signaling protocols. See [RFC3473], forFF WA method. 4- 127: Unassigned. The processing rules of this TLV are as follows: If a receiving node does not support the attribute(s), its behaviors are specified below: - W bit not supported: a PathErr MUST be generated with the Error Code "Routing Problem" (24) with error sub-code "Unsupported WavelengthSelection Symmetry value" (value to be assigned by IANA, suggested value: 107). - WA method not supported: a PathErr MUST be generated with the Error Code "Routing Problem" (24) with error sub-code "unsupported Wavelength Assignment value" (value to be assigned by IANA, suggested value: 108). This sub-TLV is constructed by an ingress node and the processing is applied to all nodes (transit and egress) whose R bit is set in the ERO HOP ATTRIBUTE subobject according to [RSVP-RO]. When the R bit is set, a node MUST examine the WavelengthSelection sub-TLV present in the subobject following the rule described in [RFC5420]. If a node processing an ERO HOP ATTRIBUTE subobject with WSON Processing HOP Attributes TLV (which may include the WavelengthSelection sub-TLVs) longer than the ERO subobject SHOULD return a PathErr with an error code "Routing Error" and error value "Bad EXPLICT_ROUTE object" with the EXPLICIT_ROUTE object included as defined in [RSVP-RO] Section 3.3. Once a node properly parsed the Sub-TLV, the node applies wavelength assignment method (at that hop) for the LSP. In addition, the node SHOULD report compliance by adding a RRO_HOP_ATTRIBUTE subobject with the WSON Processing HOP Attribute TLV (and its sub-TLVs) which describes the attributes to be reported. 5. Security Considerations This document is builds on the mechanisms defined in [RFC3473], and only differs in specific information communicated. As such, this document introduces no new security considerations to the existing GMPLS signaling protocols. See [RFC3473], for details of the supported security measures. Additionally, [RFC5920] provides an overview of security vulnerabilities and protection mechanisms for the GMPLS control plane. 6. IANA Considerations Upon approval of this document, IANA willis requested to make the assignment of a new value for the existing "Attributes TLV Space" registry located at http://www.iana.org/assignments/rsvp-te- parameters/rsvp-te-parameters.xhtml: Type Name Allowed on Allowed on Reference LSP ATTRIBUTES LSP REQUIRED_ ATTRIBUTES 4 (Suggested) WSON No No [This.I-D] Processing HOP Attribute TLV Upon approval of this document, IANA is requested to create a new registry named "Sub-TLV Types for WSON Processing HOP Attribute TLV" located at http://www.iana.org/assignments/rsvp-te-parameters/rsvp- te-parameters.xhtml. The following entries are to be added: Value Length Sub-TLV Type Reference 1 (suggested) variable ResourceBlockInfo [This.I-D] 2 (Suggested) 4 WavelengthSelection [This.I-D] All assignments are to be performed via Standards Action as follows: A new LSP_REQUIRED_ATTRIBUTE typedefined in [RFC5226 <http://tools.ietf.org/html/rfc5226>]. Upon approval of this document, IANA is requiredrequested to create a new registry named "Values for Wavelength Assignment Method field in WavelengthSelection Sub-TLV" located at http://www.iana.org/assignments/rsvp-te-parameters/rsvp-te- parameters.xhtml. The following entries are to be added: Value Sub-TLVMeaning Reference 0 unspecified [This.I-D] 1 First-Fit [This.I-D] 2 Random [This.I-D] 3 (Suggested)Least-Loaded (multi-fiber) [This.I-D] 4-127 unassigned All assignments are to be performed via Standards Action as defined in [RFC5226 <http://tools.ietf.org/html/rfc5226>]. Upon approval of this document, IANA is requested to make the assignment of a new value for the existing "Error Codes and Globally-Defined Error Value Sub-Codes - 29 Unknown Attribute TLV" registry located at http://www.iana.org/assignments/rsvp- parameters/rsvp-parameters.xml: Value Meaning Reference 41 (suggested) Unknown WSON Processing HOP Attribute TLV [This ID] Onesub-TLV type [This.I-D] Upon approval of this document, IANA is requested to make the assignment of a new type sub-TLV is allowed withinvalue for the LSP_Attributes Objectexisting "Sub-Codes . 24 Routing Problem" registry located at http://www.iana.org/assignments/rsvp- parameters/rsvp-parameters.xml: Value Sub-TLVDescription Reference 4 (Suggested)107 Unsupported WavelengthSelection symmetry value [This.I-D] 108 Unsupported Wavelength Selection [This ID]Assignment value [This.I-D] 7. Acknowledgments Authors would like to thanks Lou Berger andBerger, Cyril Margaria and Xian Zhang for comments and suggestions. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Perkins,[RFC6205] T. Otani, H. Guo, K. Miyazaki, D. Caviglia, "Generalized Labels for G.694 Lambda-Switching Capable Label Switching Routers", RFC 6205, March 2011. [WSON-Encode] Bernstein G., Lee Y., Li D., and J. Schoenwaelder, "Structure of ManagementW. Imajuku, "Routing and Wavelength Assignment Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,Encoding for Wavelength Switched Optical Networks", draft-ietf-ccamp- rwa-wson-encode, work in progress. [WSON-OSPF] Lee, Y, Bernstein G., "GMPLS OSPF Enhancement for Signal and G. Swallow, "RSVP-TE: Extensions to RSVPNetwork Element Compatibility for LSP Tunnels",Wavelength Switched Optical Networks", draft-ietf-ccamp-wson-signal- compatibility-ospf, work in progress. [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications", RFC 3209, December 2001.5511, April 2009. [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. [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)", RFC 3477, January 2003.[RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, J.-P., and A. Ayyangar, " Encoding"Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)", RFC 5420, February 2006. [RFC5920] Luyuan Fang(Ed.), "Security Framework for MPLS and GMPLS Networks", RFC5920, July 2010. [WSON-Encode] Bernstein G., Lee Y., Li D., and W. Imajuku, "Routing and Wavelength Assignment Information Encoding for Wavelength Switched Optical Networks", draft-ietf-ccamp-rwa-wson-encode, work in progress. [RFC6205] T. Otani, H. Guo, K. Miyazaki, D. Caviglia, "Generalized Labels for G.694 Lambda-Switching Capable Label Switching Routers", RFC 6205, March 2011.2009. [RSVP-RO] Margaria, C., et al, "LSP Attribute in ERO", draft-ietf- ccamp-lsp-attribute-ro,workccamp-lsp-attribute-ro, work in progress. 8.2. Informative References [WSON-CompOSPF] Y. Lee, G. Bernstein, "OSPF Enhancement[RFC5920] Fang, L., Ed., "Security Framework for SignalMPLS and Network Element Compatibility for Wavelength Switched OpticalGMPLS Networks", work in progress: draft-lee-ccamp-wson- signal-compatibility-OSPF.RFC5920, July 2010. [RFC6163] Y. Lee, G. Bernstein, 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. [WSON-Info] G. Bernstein, Y. Lee, D. Li, W. Imajuku, "Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks", work in progress: draft-ietf- ccamp-rwa-info, work in progress. [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. [RFC4872] Lang, J., Rekhter, Y., and Papadimitriou, D., "RSVP-TE Extensions in Support of End-to-End Generalized Multi- Protocol Label Switching (GMPLS) Recovery", RFC 4872,Author's Addresses Greg M. Bernstein (editor) Grotto Networking Fremont California, USA Phone: (510) 573-2237 Email: email@example.com Nicola Andriolli Scuola Superiore Sant'Anna, Pisa, Italy Email: firstname.lastname@example.org Alessio Giorgetti Scuola Superiore Sant'Anna, Pisa, Italy Email: email@example.com 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: firstname.lastname@example.org 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: email@example.com 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: firstname.lastname@example.org Daniel King Old Dog Consulting Email: email@example.com Young Lee (editor) Huawei Technologies 5360 Legacy Dr. Building 3 Plano, TX 75024 USA Phone: (469) 277-5838 Email: firstname.lastname@example.org 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: email@example.com Giovanni Martinelli Cisco Via Philips 12 20052 Monza, IT Phone: +39 039-209-2044 Email: firstname.lastname@example.org 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 email@example.com. 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 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.