Network Working Group G. Bernstein Internet Draft Grotto Networking Intended status: Standards Track Sugang Xu NICT Expires:
MarchSeptember 2012 Y.Lee Huawei G. Martinelli Cisco Hiroaki Harai NICT September 13, 2011March 7, 2012 Signaling Extensions for Wavelength Switched Optical Networks draft-ietf-ccamp-wson-signaling-02.txtdraft-ietf-ccamp-wson-signaling-03.txt Abstract This memo provides extensions to Generalized Multi-Protocol Label Switching (GMPLS) signaling for control of wavelength switched optical networks (WSON). Such extensions are necessary 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 bidirectional LSPs, and choice in distributed wavelength assignment algorithms. These extensions build on previous work for the control of lambda and G.709 based networks. 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 March 13, 2007.September 7, 2012. Copyright Notice Copyright (c) 20112012 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 Element Processing Configuration..........5 3.3. Bi-Directional Distributed Wavelength Assignment..........5WSON LSPs..................................5 3.4. Distributed Wavelength Assignment Support.................6 3.5. Out of Scope..............................................6 4. WSON Signal Traffic Parameters, Attributes and Processing......6 4.1. Traffic Parameters for Optical Tributary Signals..........6 4.2. Signal Attributes and Processing..........................6Processing..........................7 4.2.1. Modulation Type sub-TLV..............................7 4.2.2. FEC Type sub-TLV.....................................9 4.2.3. RegenerationWSON Processing TLV.........................12Object Encoding......................8 5. Bidirectional Lightpath Setup.................................13 5.1. Possible Solutions for Bidirectional Lightpath...........13 5.2. Bidirectional Lightpath Signaling Procedure..............14 5.3. Backward Compatibility Considerations....................15Setup..................................8 6. RWA Related...................................................15Related....................................................9 6.1. Wavelength Assignment Method Selection...................15Selection....................9 7. Security Considerations.......................................16Considerations.......................................10 8. IANA Considerations...........................................17Considerations...........................................11 9. Acknowledgments...............................................17Acknowledgments...............................................11 10. References...................................................18References...................................................12 10.1. Normative References....................................18References....................................12 10.2. Informative References..................................18References..................................12 Author's Addresses...............................................21Addresses...............................................14 Intellectual Property Statement..................................22Statement..................................15 Disclaimer of Validity...........................................23Validity...........................................16 1. Introduction This memo provides extensions to Generalized Multi-Protocol Label Switching (GMPLS) signaling for control of wavelength switched optical networks (WSON). Fundamental extensions are given to permit simultaneous bi-directional 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 These extensions build on previous work for the control of lambda and 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. 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 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. 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]. This leaves two new parameters: modulation format and FEC type, needed to fully characterize the optical signal. 3.2. Per LSP Network Element Processing Configuration In addition to configuring a network element (NE) along an LSP to input or output a signal with specific attributes, we may need to signal the NE to perform specific processing, such as 3R regeneration, on the signal at a particular NE. In [RFC6163] we discussed three types of processing not currently covered by GMPLS: (A) Regeneration (possibly different types) (B) Fault and Performance Monitoring (C) Attribute Conversion The extensions here MUST provide for the configuration of these types of processing at nodes along an LSP. 3.3. Bi-Directional Distributed Wavelength AssignmentWSON LSPs WSON signaling MAY support distributed wavelength assignmentLSP setup consistent with the wavelength continuity constraint for bi- directionalbi-directional connections. The following cases MAY be separately supported: (a)Where(a) Where the same wavelength is used for both upstream and downstream directions (b)Where(b) Where different wavelengths can be used for both upstream and downstream directions. (Editor's Note: an evaluation of current GMPLS bidirectional solutions should be evaluated if they would fit to the current WSON needs.) 3.4. Distributed Wavelength Assignment Support WSON signaling MAY 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 [HZang00] and [Sambo11]the [RFC6163] different computational approaches for distributedwavelength assignment are available. Hence it may be advantageous toOne method is the use of distributed wavelength assignment. This feature would allow the specification of a particular approach when more than one mechanismis implemented in the systems along the path. WSON signaling MAY support the selection of a specific distributed wavelength assignment method.3.5. Out of Scope 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 systems it can be important to include key lightpath characteristics as traffic parameters in signaling [RFC6163]. 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. Signal Attributes and Processing Section 3.2. gave the requirements for signaling to indicate to a particular NE along an LSP what type of processing to perform on an optical signal or how to configure that NE to accept or transmit an optical signal with particular attributes. One way of accomplishing this is via a new EXPLICIT_ROUTE subobject. Reference [RFC3209] defines the EXPLICIT_ROUTE object (ERO) and a number of subobjects, while reference [RFC5420] defines general mechanisms for dealing with additional LSP attributes. Although reference [RFC5420] defines a RECORD_ROUTE object (RRO) attributes subobject, it does not define an ERO subobject for LSP attributes. Regardless of the exact coding for the ERO subobject conveying the input, output, or processing instructions. This new "processing" subobject would follow a subobject containing the IP address, or the interface identifier [RFC3477], associated with the link on which it is to be used along with any label subobjects [RFC3473]. The contents ofWSON Signal Processing object is defined as an LSP_ATTRIBUTES and extends the PATH message. It is defined as the following: <WSON Processing> ::= <hop information> <Transmitter Capabilities> <Receiver Capabilities> [<RegenerationCapabilities>] <Receiver Capabilities> ::= <ModulationTypeList> <FECTypeList> <BitRateRange> <Transmitter Capabilities> ::= (ModulationTypeList> <FECTypeList> <BitRateRange> Where: <hop information>: Ipv4,Ipv6 address. Note: this new "processing" subobject would be a list of TLVs that could include: o Modulation Type TLV (input and/or output) o FEC Type TLV (input and/or output) onot required if WSON Processing Instruction TLV Currentlyobject become part of the only processing instruction TLV currentlyERO <Transmitter Capabilities> is defined in [WSON-Encode]. <ReceiverCapabilities> is defined in [WSON-Encode]. <ModulationTypeList> is for regeneration. The [WSON-Info] anddefined in[WSON-Encode] <FECTypeList> is defined in [WSON-Encode] provides the details for these specifics sub-TLVs. Possible encodings and values for these TLV are given<BitRateRange> is defined in below. 4.2.1. Modulation Type sub-TLV The encoding for modulation type sub-TLV[WSON-Encode] <RegenerationCapabilities> is defined in [WSON-Encode] Section 4.2.1. It may come<RegenerationCapabilities> are only applied in two different formats: a standard modulation field or a vendor specific modulation field. Both start withthe same 32 bit header shown below.intermediate nodes of the LSP. The head and tail nodes will ignore regeneration capability processing. 4.2.1. WSON Processing Object Encoding 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S|I| Modulation ID| Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where S bit set| | ~ Value ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: to 1 indicates a standardized modulation format and S bit set to 0 indicates a vendor specific modulation format. The length is the length in bytes of the entire modulation type field. Where I bit set to 1 indicates an input modulation format and where I bit set to 0 indicates an output modulation format. Note that the source modulation type is implied when I bit is set to 0 and that the sink modulation type is implied when I bit is set to 1. For signaling purposes only the output form (I=0) is needed. The format for the standardized type is given by: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|I| Modulation ID | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Possible additional modulation parameters depending upon | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : the modulation ID : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Modulation ID Takes on the following currently defined values: 0 Reserved 1 optical tributary signal class NRZ 1.25G 2 optical tributary signal class NRZ 2.5G 3 optical tributary signal class NRZ 10G 4 optical tributary signal class NRZ 40G 5 optical tributary signal class RZ 40G Note that future modulation types may require additional parameters in their characterization. The format for vendor specific modulation is given by: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|I| Vendor Modulation ID | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Enterprise Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Any vendor specific additional modulation parameters : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vendor Modulation ID This is a vendor assigned identifier for the modulation type. Enterprise Number A unique identifier of an organization encoded as a 32-bit integer. Enterprise Numbers are assigned by IANA and managed through an IANA registry [RFC2578]. Vendor Specific Additional parameters There can be potentially additional parameters characterizing the vendor specific modulation. 4.2.2. FEC Type sub-TLV The encoding for FEC Type TLV is defined in [WSON-Encode] Section 4.3.1. It indicates the FEC type output at particular node along the LSP. The FEC type sub-TLV comes in two different types: a standard FEC field or a vendor specific FEC field. Both start with the same 32 bit header shown below. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S|I| FEC ID | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Possible additional FEC parameters depending upon | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : the FEC ID : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where S bit set to 1 indicates a standardized FEC format and S bit set to 0 indicates a vendor specific FEC format. The length is the length in bytes of the entire FEC type field. Where the length is the length in bytes of the entire FEC type field. Where I bit set to 1 indicates an input FEC format and where I bit set to 0 indicates an output FEC format. Note that the source FEC type is implied when I bit is set to 0 and that the sink FEC type is implied when I bit is set to 1. Only the output form (I=0) is used in signaling. The format for standard FEC field is given by: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|I| FEC ID | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Possible additional FEC parameters depending upon | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : the FEC ID : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Takes on the following currently defined values for the standard FEC ID: 0 Reserved 1 G.709 RS FEC 2 G.709V compliant Ultra FEC 3 G.975.1 Concatenated FEC (RS(255,239)/CSOC(n0/k0=7/6,J=8)) 4 G.975.1 Concatenated FEC (BCH(3860,3824)/BCH(2040,1930)) 5 G.975.1 Concatenated FEC (RS(1023,1007)/BCH(2407,1952)) 6 G.975.1 Concatenated FEC (RS(1901,1855)/Extended Hamming Product Code (512,502)X(510,500)) 7 G.975.1 LDPC Code 8 G.975.1 Concatenated FEC (Two orthogonally concatenated BCH codes) 9 G.975.1 RS(2720,2550) 10 G.975.1 Concatenated FEC (Two interleaved extended BCH (1020,988) codes) Where RS stands for Reed-Solomon and BCH for Bose-Chaudhuri- Hocquengham. The format for vendor-specific FEC field is given by: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|I| Vendor FEC ID | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Enterprise Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Any vendor specific additional FEC parameters : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vendor FEC ID This is a vendor assigned identifier for the FEC type. Enterprise Number A unique identifier of an organization encoded as a 32-bit integer. Enterprise Numbers are assigned by IANA and managed through an IANA registry [RFC2578]. Vendor Specific Additional FEC parameters There can be potentially additional parameters characterizing the vendor specific FEC. 4.2.3. Regeneration Processing TLV The Regeneration Processing TLV is used to indicate that this particular node is to perform the specified type of regeneration processing on the signal. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | T | C | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where T bit indicates the type of regenerator: T=0: Reserved T=1: 1R Regenerator T=2: 2R Regenerator T=3: 3R Regenerator Where C bit indicates the capability of regenerator: C=0: Reserved C=1: Fixed Regeneration Point C=2: Selective Regeneration Pools Note that the use of the C field is optional in signaling. 5. Bidirectional Lightpath Setup 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. 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. [RFC6163] in section 6.1 reports on the implication to GMPLS signaling related to both bi- directionality and Distributed Wavelengths Assignment. 5.1. Possible Solutions for Bidirectional Lightpath A first classification is using a unique bidirectional LSP (as defined by [RFC3471]) two unidirectional LSPs as per [RFC2205] approach, so possible options are the following: o Bidirectional LSP 1. Current [RFC3471], [RFC3473] co-routed approach. The label distribution is based on Label_Set and Upstream_Label objects. In case of specific constraints such as the same wavelengths in both directions, it may require several signaling attempts using information from the Acceptable_Label_Set received from path error messages. 2. Using a specific LSP_ATTRIBUTE or a newly defined Upstream_Label_Set object. This mechanism seems to be more efficient (i.e. one signaling attempt) in case of distributed wavelength assignment and same wavelength in both directions. o Two Unidirectional LSPs. This solution has been always available as per [RFC3209] however recent work introduces the association concept [RFC4872] and [ASSOC-Info]. Recent transport evolutions [ASSOC-ext] provide a way to associate two unidirectional LSPs as a bidirectional LSP. In line with this, a small extension can make this approach work for the WSON case. 5.2. Bidirectional Lightpath Signaling Procedure [TO BE UPDATED ACCORDING TO THE BIDIRECTIONAL METHOD CHOOSEN FOR WSON either new objects or assoc ] 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 willbe 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 setdefined by IANA Value: sub-TLVS according to section 4.1. 5. Bidirectional Lightpath Setup With the value of the new type lightpath TLV type code; 4. On reception of a Path message containing both the new type lightpath indicationwavelength continuity constraint in an LSP_ATTRIBUTES object and Label Set object,CI-incapable [RFC3471] WSONs, where the egress node verifies whethernodes in the Label Set TLVs are acceptable, if one or more wavelengths are available on both directions, then any one availablenetworks cannot support 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 allocatesconversion, the label to interfaces on both directions and update internal database for this bidirectionalsame 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. 5.3. Backward Compatibility Considerations Due to the introduction of new processingon Label Set object, it is required thateach node in the lightpath is able to recognize the new typelink along a unidirectional 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. Accordingshould be reserved. In addition to the descriptionswavelength continuity constraint, requirement 3.2 gives us another constraint on wavelength usage in [RFC5420], an LSR that does not recognize a TLV type code carrieddata plane, in this object MUST rejectparticular, it requires the Path message using a PathErr message with Error Code "Unknown Attributes TLV" and Error Value setsame wavelength to the value of the Attributes Flags TLV type code. An LSR that does not recognize a bit setbe used in both directions. [RFC6163] in section 6.1 reports on the Attributes Flags TLV MUST reject the Path message usingimplication to GMPLS signaling related to both bi-directionality and Distributed Wavelengths Assignment. Current GMPLS solution defines a PathErr message with Error Code "Unknown Attributes Bit"bidirectional LSP (as defined by [RFC3471]). The label distribution is based on Label_Set and Error Value set to the bit numberUpstream_Label objects. In case of specific constraints such as the new type lightpath Flagsame wavelengths in both directions, it may require several signaling attempts using information from the Attributes Flags. The reader is referredAcceptable_Label_Set received from path error messages. Some implementations may prefer using two unidirectional LSPs. This solution has been always available as per [RFC3209] however recent work introduces the association concept [RFC4872] and [ASSOC-Info]. Recent transport evolutions [ASSOC-ext] provide a way to associate two unidirectional LSPs as a bidirectional LSP. In line with this, a small extension can make this approach work for the detailed backward compatibility considerations expressed in [RFC5420].WSON case. 6. RWA Related 6.1. Wavelength Assignment Method Selection Routing + Distributed wavelength 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-hophop-by-hop basis. Under this hypothesis 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] and [Sambo11]a number of different wavelength assignment algorithms maybe 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 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] Unique Wavelength: 0 same wavelength in both directions, 1 may use different wavelengths [TBD: shall we use only 1 bit] 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unique WL | WA Method | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7. 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. 8. IANA Considerations TBD. Once finalized in our approach we will need identifiers for such things and modulation types, modulation parameters, wavelength assignment methods, etc... 9. Acknowledgments Anyone who provide comments and helpful inputs 10. References 10.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, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [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. [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 of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)", RFC 5420, February 2006. 10.2. Informative References [RFC6163][WSON-CompOSPF] Y. Lee, G. Bernstein, W. Imajuku, "Framework"OSPF Enhancement for GMPLS and PCE Control of Wavelength Switched Optical Networks", RFC 6163, April, 2011. [WSON-Info] Y. Lee, G. Bernstein, D. Li, W. Imajuku, "RoutingSignal and Wavelength Assignment Information ModelNetwork Element Compatibility for Wavelength Switched Optical Networks", draft-ietf-ccamp-rwa-infowork in progress. [WSON-Encode] G. Bernstein,progress: draft-lee-ccamp-wson- signal-compatibility-OSPF. [RFC6163] Y. Lee, D. Li,G. Bernstein, W. Imajuku, "Routing and Wavelength Assignment Information Encoding"Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks", draft-ietf-ccamp-rwa-wson- encode,work in progress.progress: draft-bernstein-ccamp-wavelength- switched-03.txt, February 2008. [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. [Sambo11] "Wavelength Preference in GMPLS-controlled Wavelength Switched Optical Networks," 01-Sep-2011. [Online]. Available: http://macrothink.org/journal/index.php/npa/article/view/81 9/0.[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, [ASSOC-Info] Berger, L., Faucheur, F., and A. Narayanan, "Usage of The RSVP Association Object", draft-ietf-ccamp-assoc-info, work in progress.draft-ietf-ccamp-assoc-info- 00 (work in progress), October 2010. [ASSOC-Ext] Zhang, F., Jing, R., "RSVP-TE Extension to Establish Associated Bidirectional LSP", draft-zhang-mpls-tp-rsvp-te- ext-associated-lsp, workdraft-zhang-mpls-tp-rsvp- te-ext-associated-lsp-03 (work in progress.progress), February 2011. Author's Addresses Greg M. Bernstein (editor) Grotto Networking Fremont California, USA Phone: (510) 573-2237 Email: firstname.lastname@example.org Nicola Andriolli Scuola Superiore Sant'Anna, Pisa, Italy Email: email@example.com Alessio Giorgetti Scuola Superiore Sant'Anna, Pisa, Italy Email: firstname.lastname@example.org 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: email@example.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: firstname.lastname@example.org 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: email@example.com Daniel King Old Dog Consulting Email: firstname.lastname@example.org Young Lee (editor) Huawei Technologies 1700 Alma Drive, Suite 100 Plano, TX 75075 USA Phone: (972) 509-5599 (x2240) Email: email@example.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: firstname.lastname@example.org Giovanni Martinelli Cisco Via Philips 12 20052 Monza, IT Phone: +39 039-209-2044 Email: email@example.com 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 firstname.lastname@example.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 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.