Network Working Group                                      G. Bernstein
Internet Draft                                        Grotto Networking
Updates: 6205                                                 Sugang Xu
Intended status: Standards Track                              Sugang Xu                                   NICT
Expires: September 2014
                                                                  Y.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.txt
                 draft-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 networks Wavelength 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] as networks, 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 Element Node Processing Configuration..........5 Configuration.........................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.............8 Resource Block Information Sub-TLV........................8
      4.4. Wavelength Assignment Method Selection TLV Encoding.......9 Sub-TLV..............................9
   5. Security Considerations.......................................10 Considerations.......................................11
   6. IANA Considerations...........................................10 Considerations...........................................12
   7. Acknowledgments...............................................11 Acknowledgments...............................................13
   8. References....................................................12 References....................................................14
      8.1. Normative References.....................................12 References.....................................14
      8.2. Informative References...................................13 References...................................15
   Author's Addresses...............................................15 Addresses...............................................16
   Intellectual Property Statement..................................16 Statement..................................17
   Disclaimer of Validity...........................................17 Validity...........................................18

1. Introduction

   This memo provides extensions to Generalized Multi-Protocol Label
   Switching (GMPLS) signaling for control of wavelength switched
   optical networks Wavelength 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 Element Node 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 NE node 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: processing:

     (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. 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 current existing 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 systems systems, 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 extend extends [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 NE node along an LSP what type of processing to perform on
   an optical signal or how to configure that NE node to accept or
   transmit an optical signal with particular attributes.

   To target a specific node, this section defines a WSON_Processing
   object as part of WSON Processing
   HOP Attribute TLV, which is carried in the LSP_REQUIRED_ATTRIBUTE and follows procedures subobjects defined in
   [RSVP-RO]. The content Type value of the WSON Processing HOP Attribute TLV
   is TBD by IANA.

   The contents of this TLV is defined in the subsequent sections. (See
   Section 4.3 for <RBInformation> TLV ResourceBlockInfo sub-TLV and Section 4.4 for
   <WavelengthSelection> TLV, respectively.)

   <WSON_Processing
   WavelengthSelection 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-TLVs HOP Attribute TLV is a type of the same format as a HOP Attributes
   TLV, as defined in [RSVP-RO].

4.3. Signal If 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 Capabilities TLV (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,
   the Resource 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.1 4 of [WSON-Encode].

     Type        Sub-TLV Name

   1 (TBA)      <RBInformation>      ResourceBlockInfo

   At least one <RBInformation> ResourceBlockInfo sub-TLV MUST always be present in the
   WSON_Processing HOP Attribute TLV.. TLV. At most two <RBInformation> sub-
   TLVs ResourceBlockInfo
   sub-TLVs MAY be present in the WSON_Processing HOP Attribute TLV . TLV. If
   more than two objects sub-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
   one
   of 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-object ResourceBlockInfo
   sub-TLV MUST be processed and  I/E I/O bits can be safely ignored.

   In case of signaling a bidirectional signaling: LSP: if only one RBInformartion
   ResourceBlockInfo is available, included, bits I and E O MUST be both set to 1,
   if two RBInformation sub-objects ResourceBlockInfo sub-TLVs are available, included, bits I and E O 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-object ResourceBlockInfo sub-TLV
   is Optical Interface Class List, Input Bit Range Rate List and Processing
   Capability List. Lists These lists MAY contain one or more elements. The
   usage of WSON Processing object HOP Attribute TLV for the bidirectional
   case is the same as per unidirectional. When an intermediate node
   uses information from this object TLV 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 Method Selection TLV Encoding Sub-TLV

   Routing + Distributed wavelength assignment 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-hop basis.

   Under this hypothesis 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] [HZang00], a number of different wavelength
   assignment algorithms maybe may 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 used

   In order to indication indicate wavelength assignment directionality and
   wavelength assignment method as method, a TLV new Wavelength Selection, or
   WavelengthSelection, sub-TLV is defined to be carried in the LSP
   Attributes Object, as WSON
   Processing HOP Attribute TLV defined in [RFC5420]. Section 4.2 of this draft.
   The type value of the Sub-TLV is:

      Type               Sub-TLV

       TDB Name

      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 use denotes 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 Considerations This document is builds WA method selects the
   wavelength that has the largest residual capacity on the mechanisms defined most loaded
   link along the route. This method is used in  [RFC3473], and
   only differs multi-fiber networks.
   If used in specific information communicated. As such, this
   document introduces no new security considerations single-fiber networks, it is equivalent to the existing
   GMPLS signaling protocols. See [RFC3473], for FF 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 will is 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 type defined
   in [RFC5226 <http://tools.ietf.org/html/rfc5226>].

   Upon approval of this document, IANA is required requested 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-TLV          Meaning                    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]

   One sub-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 within value for the LSP_Attributes Object existing "Sub-Codes . 24 Routing
   Problem" registry located at http://www.iana.org/assignments/rsvp-
   parameters/rsvp-parameters.xml:

   Value             Sub-TLV        Description                            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 and Berger, 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 Management W. 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 RSVP Network 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,work
             ccamp-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 Signal MPLS and Network Element Compatibility for Wavelength Switched
             Optical GMPLS
             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: gregb@grotto-networking.com

   Nicola Andriolli
   Scuola Superiore Sant'Anna, Pisa, Italy
   Email: nick@sssup.it

   Alessio 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
   Old Dog Consulting

   Email: daniel@olddog.co.uk

   Young Lee (editor)
   Huawei Technologies
   5360 Legacy Dr. Building 3
   Plano, TX 75024
   USA

   Phone: (469) 277-5838
   Email: leeyoung@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

   Giovanni Martinelli
   Cisco
   Via Philips 12
   20052 Monza, IT

   Phone: +39 039-209-2044
   Email: giomarti@cisco.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 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
   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.