Network Working Group                                      G. Bernstein
Internet Draft                                        Grotto Networking
Intended status: Standards Track                              Sugang Xu
                                                                   NICT
Expires: April September 2011                                           Y.Lee
                                                                 Huawei
                                                          G. Martinelli
                                                                  Cisco
                                                          Hiroaki Harai
                                                                   NICT

                                                        October 7, 2010

                                                         March 12, 2011

     Signaling Extensions for Wavelength Switched Optical Networks
                 draft-ietf-ccamp-wson-signaling-00.txt
                 draft-ietf-ccamp-wson-signaling-01.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 August 7, 2010. September 12, 2011.

Copyright Notice

   Copyright (c) 2010 2011 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.

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.

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..........5
      3.4. Distributed Wavelength Assignment Support.................7
      3.5. Out of Scope..............................................7
   4. WSON Signal Traffic Parameters, Attributes and Processing......7
      4.1. Traffic Parameters for Optical Tributary Signals..........7
      4.2. Signal Attributes and Processing..........................7 Processing..........................8
         4.2.1. Modulation Type sub-TLV..............................8
         4.2.2. FEC Type sub-TLV....................................10
         4.2.3. Regeneration Processing TLV.........................12 TLV.........................13
   5. Bidirectional Lightpath using Same Wavelength.................13 Setup.................................14
      5.1. Using LSP_ATTRIBUTES Object..............................13 Possible Solutions for Bidirectional Lightpath...........14
      5.2. Bidirectional Lightpath Signaling Procedure..............14 Procedure..............15
      5.3. Backward Compatibility Considerations....................15 Considerations....................16
   6. Bidirectional Lightpath using Different Wavelengths...........15
   7. RWA Related...................................................15
      7.1. Related...................................................16
      6.1. Wavelength Assignment Method Selection...................15
   8. Selection...................16
   7. Security Considerations.......................................16
   9. Considerations.......................................17
   8. IANA Considerations...........................................16 Considerations...........................................18
   9. Acknowledgments...............................................18
   10. Acknowledgments..............................................16
   11. References...................................................17
      11.1. References...................................................19
      10.1. Normative References....................................17
      11.2. References....................................19
      10.2. Informative References..................................17 References..................................19
   Author's Addresses...............................................19 Addresses...............................................21
   Intellectual Property Statement..................................20 Statement..................................22
   Disclaimer of Validity...........................................20 Validity...........................................23

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 [WSON-
   Frame] 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 [WSON-Frame] 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 [WSON-Frame] 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 Assignment

   WSON signaling MAY support distributed wavelength assignment
   consistent with the wavelength continuity constraint for bi-
   directional connections. The following two cases MAY be separately
   supported: (a) Where

   (a)Where the same wavelength is used for both upstream and downstream directions, and (b) Where
        directions

   (b)Where different wavelengths can be used for both upstream and
        downstream directions.

   The need for the same wavelength on both directions mainly comes from
   the color constraint on some edges' hardware. In fact, the edges can
   be classified into two types, i.e. without and with the wavelength-
   port mapping re-configurability.

   Without the mapping re-configurability at edges, the edge nodes must
   use the same wavelength in both directions.  For example, (1)
   transponders are only connected to fixed AWGs (i.e. multiplexer/de-
   multiplexer) ports directly and fixedly, directly, or (2) transponders are connected to the
   add/drop ports of ROADM and each port is mapped to a fixed dedicated wavelength fixedly.
   wavelength.

   On the other hand, with the mapping re-configurability at edges, the edge
   nodes can use different wavelengths in different directions. For
   example, in edge nodes, transponders are connected to add/drop ports
   of colorless ROADM. Thus, the wavelength-port remapping problem can
   be solved locally by appropriately configuring the colorless ROADM.
   If the colorless ROADM consists of OXC and AWGs, the OXC is
   configured appropriately.

   The edges of data-plane in WSON can be constructed in different types
   based on cost and flexibility concerns.  Without re-configurability
   we should consider the constraint of the same wavelength usage on
   both directions, but have lower costs. While, with wavelength-port
   mapping re-configurability we can relax the constraint, but have
   higher costs.

   These two types of edges will co-exist in WSON mesh, till all the
   edges are unified by the same type. The existence of the first type
   edges presents a requirement of the same wavelength usage on both
   directions, which must be supported.

   Moreover, if some carriers prefer an easy management of lightpath usage,
   say use the same wavelength on both directions to reduce the burden
   on lightpath management, the same wavelength usage would be
   beneficial.

   In cases of equipment failure, etc., fast provisioning used in quick
   recovery is critical to protect Carriers/Users against system loss.
   This requires efficient signaling which supports distributed
   wavelength assignment, in particular when the centralized wavelength
   assignment capability is not available.

3.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 the [WSON-Frame] a variety of different computational approaches
   for wavelength assignment algorithms have been developed. A number of these are
   suitable for available. One method is the use in of
   distributed wavelength assignment. This feature would allow the
   specification of a particular approach when more than one are is
   implemented in the systems along the path.

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 [WSON-Frame] single channel optical signals used in
   WSONs are called "optical tributary signals" and come in a number of
   classes characterized by modulation format and bit rate. Although
   WSONs are fairly transparent to the signals they carry, to ensure
   compatibility amongst various networks devices and end systems it can
   be important to include key lightpath characteristics as traffic
   parameters in signaling [WSON-Frame].

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 of 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)

   o  Processing Instruction TLV

   Currently the only processing instruction TLV currently defined is
   for regeneration. The [WSON-Info] and [WSON-Encoding] provides the
   details for these specifics sub-TLVs.

   Possible encodings and values for these TLV are given in below.

4.2.1. Modulation Type sub-TLV

   The encoding for modulation type sub-TLV is defined in [WSON-Encode]
   Section 4.2.1.

   It may come in two different formats: a standard modulation field or
   a vendor specific modulation 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|     Modulation ID           |        Length               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Where S bit set 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 using Same Wavelength 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.  Per the definition in [RFC3471], a
   bidirectional lightpath can be seen as a pair of unidirectional
   lightpaths, which are provisioned along the same route simultaneously
   by the RSVP-TE signaling with Upstream Label and Label Set Objects in
   the messages [RFC3473]. This does not necessarily require the same
   wavelength in both directions. In addition to the wavelength
   continuity constraint, requirement 3.2 gives us another constraint on
   wavelength usage in data plane, in particular, it requires the same
   wavelength to be used in both directions.

   The simplest and efficient way is to only define an extension to the
   processing of Label Set [RFC3473], and leave [WSON-Frame] in section 6.1
   reports on the other processes
   untouched.  The issues implication to GMPLS signaling related to this new functionality including an
   LSP_ATTRIBUTES object defined in [RFC5420] and the new procedure are
   described in the following sections. This approach would have a lower
   blocking probability both bi-
   directionality and a shorter provisioning time.  In cases of
   equipment failure, etc., fast provisioning used in quick recovery is
   critical to protect Carriers/Users against system loss. Distributed Wavelengths Assignment.

5.1. Using LSP_ATTRIBUTES Object

   To trigger 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 new functionality at each GMPLS node, it following:

      o  Bidirectional LSP

           1.  Current [RFC3471], [RFC3473] co-routed approach. The
             label distribution is necessary
   to notify based on Label_Set and
             Upstream_Label objects. In case of specific constraints
             such as the receiver same wavelengths in both directions, it may
             require several signaling attempts using information from
             the new type lightpath request.  One multi-
   purpose flag/attribute parameter container object called
   LSP_ATTRIBUTES object and related mechanism 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 [RFC5420] meet
   this requirement. One bit in Attributes Flags TLV which indicates the
   new type lightpath, say, the bidirectional case of
             distributed wavelength assignment and same wavelength lightpath
   will be present in an LSP_ATTRIBUTES object.  Please refer
             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
   [RFC5420] associate two
        unidirectional LSPs as a bidirectional LSP. In line with this,
        a small extension can make this approach work for detailed descriptions of the Flag and related issues. 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 will be generated;

   3. On reception of a Path message containing both such a new type
      lightpath indication in an LSP_ATTRIBUTES object and an Upstream
      Label object, the receiver MUST terminate the Path message using
      a PathErr message with Error Code "Unknown Attributes TLV" and
      Error Value set to the value of the new type lightpath TLV type
      code;

   4. On reception of a Path message containing both the new type
      lightpath indication in an LSP_ATTRIBUTES object and Label Set
      object, the egress node verifies whether the Label Set TLVs are
      acceptable, if one or more wavelengths are available on both
      directions, then any one available wavelength could be selected.
      A Resv message is generated and propagated to upstream node;

   5. When a Resv message is received at an intermediate node, if it is
      a new type lightpath, the intermediate node allocates the label
      to interfaces on both directions and update internal database for
      this bidirectional same wavelength lightpath, then configures the
      local ROADM or OXC on both directions.

   Except the procedure related to Label Set object, the other processes
   will be left untouched.

5.3. Backward Compatibility Considerations

   Due to the introduction of new processing on Label Set object, it is
   required that each node in the lightpath is able to recognize the new
   type lightpath indication Flag carried by an LSP_ATTRIBUTES object,
   and deal with the new Label Set operation correctly.  It is noted
   that this new extension is not backward compatible.

   According to the descriptions in [RFC5420], an LSR that does not
   recognize a TLV type code carried in this object MUST reject the Path
   message using a PathErr message with Error Code "Unknown Attributes
   TLV" and Error Value set to the value of the Attributes Flags TLV
   type code.

   An LSR that does not recognize a bit set in the Attributes Flags TLV
   MUST reject the Path message using a PathErr message with Error Code
   "Unknown Attributes Bit" and Error Value set to the bit number of the
   new type lightpath Flag in the Attributes Flags.The Flags. The reader is
   referred to the detailed backward compatibility considerations
   expressed in [RFC5420].

6. Bidirectional Lightpath using Different Wavelengths

   TBD

7. RWA Related

7.1.

6.1. Wavelength Assignment Method Selection

   Routing + Distributed wavelength assignment (R+DWA) is one of the
   options defined by the [WSON-Frame]. 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 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] a number of different wavelength assignment
   algorithms maybe employed. In addition as discussed in [WSON-Frame]
   the wavelength assignment can be either for a unidirectional
   lightpath or for a bidirectional lightpath constrained to use the
   same lambda in both directions.

   A simple TLV could be used to indication wavelength assignment
   directionality and wavelength assignment method. This would be placed
   in an LSP_REQUIRED_ATTRIBUTES object per [RFC5420]. The use of a TLV
   in the LSP required attributes object was pointed out in [Xu].

   [TO DO: The directionality stuff needs to be reconciled with the
   earlier material]

   Directionality:

   Unique Wavelength: 0 unidirectional, same wavelength in both directions, 1 bidirectional 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Direction    Unique WL  |    WA Method  |           Reserved            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

8.

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.

9.

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...

10.

9. Acknowledgments

   This document was prepared using 2-Word-v2.0.template.dot.

11.

   Anyone who provide comments and helpful inputs

10. References

11.1.

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.

11.2.

10.2. Informative References

   [WSON-CompOSPF] Y. Lee, G. Bernstein, "OSPF Enhancement for Signal
             and Network Element Compatibility for Wavelength Switched
             Optical Networks", work in progress: draft-lee-ccamp-wson-
             signal-compatibility-OSPF.

   [WSON-Frame] G. Bernstein, 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.

   [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,

   [ASSOC-Info] Berger, L., Faucheur, F., and A. Narayanan, "Usage of
             The RSVP Association Object", 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-03 (work in progress), February 2011.

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
   1700 Alma Drive, Suite 100
   Plano, TX 75075
   USA

   Phone: (972) 509-5599 (x2240)
   Email: ylee@huawei.com

   Sugang Xu
   National Institute of Information and Communications Technology
   4-2-1 Nukui-Kitamachi, Koganei,
   Tokyo, 184-8795 Japan

   Phone: +81 42-327-6927
   Email: xsg@nict.go.jp

   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.