Network Working Group                                      G. Bernstein
Internet Draft                                        Grotto Networking
Intended status: Standards Track                              Sugang Xu
                                                                   NICT
Expires: January 2009                                             Y.Lee
                                                                 Huawei
                                                          Hiroaki Harai
                                                                   NICT
                                                                D. King
                                                           July 7, 2008


       Signaling Extensions for Wavelength Switched Optical Networks
                draft-bernstein-ccamp-wson-signaling-02.txt


Status of this Memo

   By submitting this Internet-Draft, each author represents that
   any applicable patent or other IPR claims of which he or she is
   aware have been or will be disclosed, and any of which he or she
   becomes aware will be disclosed, in accordance with Section 6 of
   BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on December 7, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2008).

Abstract

This memo provides extensions to Generalized Multi-Protocol Label
Switching (GMPLS) signaling for control of wavelength switched optical



                       Expires January 7, 2009                 [Page 1]


Internet-Draft        WSON Signaling Extensions               July 2008


networks (WSON).  These extensions build on previous work for the
control of G.709 based networks.

Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC-2119.

Table of Contents


   1. Introduction...................................................3
   2. Terminology....................................................3
   3. Requirements for WSON Signaling................................4
         3.1.1. WSON Signal Characterization.........................4
         3.1.2. Bi-Directional Distributed Wavelength Assignment.....4
         3.1.3. Distributed Wavelength Assignment Method Selection...5
         3.1.4. Out of Scope.........................................6
   4. WSON Signal Types, Forward Error Correction, and Rates.........6
      4.1. Traffic Parameters for WSON signals.......................6
   5. Bidirectional Lightpath using Same Wavelength on Both Directions7
      5.1. Using LSP_ATTRIBUTES Object...............................8
      5.2. Bidirectional Lightpath Signaling Procedure...............8
      5.3. Backward Compatibility Considerations.....................9
   6. Bidirectional Lightpath using Different Wavelengths on Different
   Directions.......................................................10
   7. RWA Method Related............................................10
      7.1. Wavelength Assignment Method Selection...................10
      7.2. Supplemental Information for Wavelength Assignment.......10
      7.3. Least-Loaded Wavelength Assignment (informational).......12
   8. Security Considerations.......................................13
   9. IANA Considerations...........................................13
   10. Acknowledgments..............................................13
   11. References...................................................14
      11.1. Normative References....................................14
      11.2. Informative References..................................14
   Author's Addresses...............................................15
   APPENDIX A: Requirement of Bidirectional Lightpath with the Same
   Wavelength in Both Directions....................................17
      A.1. Introduction.............................................17
      A.2. Port-remapping Problem...................................17
      A.3. Port-remapping with OXC..................................20
      A.4. Avoiding Port-remapping Problem: Bidirectional Lightpath
      using Same Wavelength on Both Directions......................21
   Intellectual Property Statement..................................22
   Disclaimer of Validity...........................................22


Bernstein et al.       Expires January 7, 2009                 [Page 2]


Internet-Draft        WSON Signaling Extensions               July 2008



1. Introduction

   This memo provides extensions to Generalized Multi-Protocol Label
   Switching (GMPLS) signaling for control of wavelength switched
   optical networks (WSON).  In particular, extensions are given to
   characterize optical signal types via traffic parameters, permit
   simultaneous bi-directional wavelength assignment, and control the
   distributed wavelength assignment process. These extensions build on
   previous work for the control of G.709 based networks.

2. Terminology

   CWDM: Coarse Wavelength Division Multiplexing.

   DWDM: Dense Wavelength Division Multiplexing.

   FOADM: Fixed Optical Add/Drop Multiplexer.

   ROADM: Reconfigurable Optical Add/Drop Multiplexer. A reduced port
   count wavelength selective switching element featuring ingress and
   egress line side ports as well as add/drop side ports.

   RWA: Routing and Wavelength Assignment.

   Wavelength Conversion/Converters: The process of converting an
   information bearing optical signal centered at a given wavelength to
   one with "equivalent" content centered at a different wavelength.
   Wavelength conversion can be implemented via an optical-electronic-
   optical (OEO) process or via a strictly optical process.

   WDM: Wavelength Division Multiplexing.

   Wavelength Switched Optical Networks (WSON): WDM based optical
   networks in which switching is performed selectively based on the
   center wavelength of an optical signal.

   AWG: Arrayed Waveguide Grating.

   OXC: Optical Cross Connect.

   Optical Transmitter: A device that has both a laser tuned on certain
   wavelength and electronic components, which converts electronic
   signals into optical signals.





Bernstein et al.       Expires January 7, 2009                 [Page 3]


Internet-Draft        WSON Signaling Extensions               July 2008


   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.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...),
   links (WDM systems) and end systems (detectors, demodulators,
   etc...). The details of any local configuration are out of the scope
   of this document.

3.1.2. Bi-Directional Distributed Wavelength Assignment

   WSON signaling MAY support distributed wavelength assignment
   consistent with the wavelength continuity constraint for bi-
   directional connections. The following two cases MAY be separately
   supported: (a) Where the same wavelength is used for both upstream
   and downstream directions, and (b) Where different wavelengths can be
   used for both upstream and downstream directions.

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




Bernstein et al.       Expires January 7, 2009                 [Page 4]


Internet-Draft        WSON Signaling Extensions               July 2008


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

   On the other hand, with the mapping re-configurability at edges, the
   edge nodes can use different wavelengths in different directions. For
   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 re-configurability
   we can relax the constraint, but have higher costs.

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

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

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

3.1.3. Distributed Wavelength Assignment Method Selection

   WSON signaling MAY support the selection of a specific distributed
   wavelength assignment method.

   As discussed in the [WSON-Frame] a variety of different wavelength
   assignment algorithms have been developed. A number of these are
   suitable for use in distributed wavelength assignment. This feature
   would allow the specification of a particular approach when more than
   one are implemented in the systems along the path.


Bernstein et al.       Expires January 7, 2009                 [Page 5]


Internet-Draft        WSON Signaling Extensions               July 2008


3.1.4. Out of Scope

   This draft does not address signaling information related to optical
   impairments.

4. WSON Signal Types, Forward Error Correction, and Rates

   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 WSON signals

   As in [RFC4606] and [RFC4328] the following traffic parameters would
   become the contents for the RSVP SENDER_TSPEC and FLOWSPEC objects.
   The WSON traffic parameters SHOULD be defined as follows:

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Mod Type     |     Mod Params|         Reserved              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              BitRate/Analog Bandwidth                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Reserved                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Modulation (Mod) Types:

   We have potentially the following:

















Bernstein et al.       Expires January 7, 2009                 [Page 6]


Internet-Draft        WSON Signaling Extensions               July 2008


     Value     Type
     -----     ----
       0        Unspecified or Unknown
       1        NRZ
       2        RZ


   Modulation Parameters(Mod Params):
   RZ 0 - 33%, 1 -  50%, 2 - 67% duty cycles

   See [G.959.1] and [Winzer06].

   These are specific to the modulation type employed and may or may not
   be used.  For example NRZ modulation typically doesn't have extra
   parameters, while RZ modulation has a duty cycle parameter.


   Bitrate/Analog Bandwidth:
   For digital signals this is the bit rate given as a 32 bit IEEE
   floating point number.

   For analog signals or when modulation type is given as 0
   (unspecified), this is the bandwidth of the signal around the center
   frequency (c/lambda) and not the bit/byte rate. This is given as a 32
   bit IEEE floating point number that represents the bandwidth in
   Hertz. The exact definition of bandwidth, e.g., 3dB power bandwidth,
   etc. is TBD and may be network specific.


5. Bidirectional Lightpath using Same Wavelength on Both Directions

   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.1.2(a) gives us another constraint on wavelength usage in data
   plane, in particular, it requires the same wavelength to be used in
   both directions.




Bernstein et al.       Expires January 7, 2009                 [Page 7]


Internet-Draft        WSON Signaling Extensions               July 2008


   The simplest and efficient way is to only define an extension to the
   processing of Label Set [RFC3473], and leave the other processes
   untouched.  The issues related to this new functionality including an
   LSP_ATTRIBUTES object defined in [RFC4420] and the new procedure are
   described in the following sections. This approach would have a lower
   blocking probability and a shorter provisioning time.  In cases of
   equipment failure, etc., fast provisioning used in quick recovery is
   critical to protect Carriers/Users against system loss.

5.1. Using LSP_ATTRIBUTES Object

   To trigger the new functionality at each GMPLS node, it is necessary
   to notify the receiver the new type lightpath request.  One multi-
   purpose flag/attribute parameter container object called
   LSP_ATTRIBUTES object and related mechanism defined in [RFC4420] meet
   this requirement. One bit in Attributes Flags TLV which indicates the
   new type lightpath, say, the bidirectional same wavelength lightpath
   will be present in an LSP_ATTRIBUTES object.  Please refer to
   [RFC4420] for detailed descriptions of the Flag and related issues.

5.2. Bidirectional Lightpath Signaling Procedure

   Considering the system configuration mentioned above, it is needed to
   add a new function into RSVP-TE to support bidirectional lightpath
   with same wavelength on both directions.

   The lightpath setup procedure is described below:

   1. Ingress node adds the new type lightpath indication in an
      LSP_ATTRIBUTES object.  It is propagated in the Path message in
      the same way as that of a Label Set object for downstream;

   2. On reception of a Path message containing both the new type
      lightpath indication in an LSP_ATTRIBUTES object and Label Set
      object, the receiver of message along the path checks the local
      LSP database to see if the Label Set TLVs are acceptable on both
      directions jointly.  If there are acceptable wavelengths, then
      copy the values of them into new Label Set TLVs, and forward the
      Path message to the downstream node.  Otherwise the Path message
      will be terminated, and a PathErr message with a "Routing
      problem/Label Set" indication will be generated;

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



Bernstein et al.       Expires January 7, 2009                 [Page 8]


Internet-Draft        WSON Signaling Extensions               July 2008


      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 [RFC4420], an LSR that does not
   recognize a TLV type code carried in this object MUST reject the Path
   message using a PathErr message with Error Code "Unknown Attributes
   TLV" and Error Value set to the value of the Attributes Flags TLV
   type code.

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








Bernstein et al.       Expires January 7, 2009                 [Page 9]


Internet-Draft        WSON Signaling Extensions               July 2008


6. Bidirectional Lightpath using Different Wavelengths on Different
   Directions

   TBD

7. RWA Method Related

7.1. Wavelength Assignment Method Selection

   As discussed in [HZang00] a number of different wavelength assignment
   algorithms maybe employed. In addition as discussed in [WSON-Frame]
   the wavelength assignment can be either for a unidirectional
   lightpath or for a bidirectional lightpath constrained to use the
   same lambda in both directions. A simple TLV could be used to
   indication wavelength assignment directionality and wavelength
   assignment method. This would be placed in an LSP_REQUIRED_ATTRIBUTES
   object per [RFC4420]. The use of a TLV in the LSP required attributes
   object was pointed out in [Xu].

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

   Directionality: 0 unidirectional, 1 bidirectional

   Wavelength Assignment Method: 0 unspecified (any), 1 First-Fit, 2
   Random, 3 Least-Loaded (multi-fiber).  Others TBD.



       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Direction  |    WA Method  |           Reserved            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


7.2. Supplemental Information for Wavelength Assignment

   Distributed wavelength assignment makes extensive use of the label
   set object/TLV of [RFC3471]. Some higher performance algorithms
   suitable for multi-fiber networks such as Least-Loaded assignment
   require supplemental information concerning the potential lambdas to
   be used. An ordered set of TLVs in correspondence with the group of
   one or more label set TLVs can be used to convey this information in
   the form of a general wavelength "acceptability" metric.




Bernstein et al.       Expires January 7, 2009                [Page 10]


Internet-Draft        WSON Signaling Extensions               July 2008


   Note that the label set syntax of [RFC3471] allows group of
   wavelengths into ranges. For the purpose of supplementing this
   information with wavelength count only those wavelengths with the
   same counts could be grouped.

   The general format for supplemental wavelength selection information
   could be as follows:

   The information carried in a Wavelength Set Metric TLV is:


       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Info Type   | Metric Size   |   Num Metrics                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Wavelength Metric Info               |
      |   From lowest to highest frequency if more that one value     |
      |                              ...                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



      Info Type: 8 bits

         0 - Single Value

   The enclosed single value for the wavelength metric is given to all
   wavelengths in the corresponding wavelength set.

         1 - List

   The enclosed list gets applied in a one-to-one fashion to each
   wavelength in the corresponding wavelength set. An error occurs if
   the number of metrics in this list and the number of wavelengths in
   the wavelength set is not equal.

   Metric Size:

   Indicates the size of the wavelength metric information as follows

         0 - 8 bits

         1 - 16 bits

         2 - 32 bits



Bernstein et al.       Expires January 7, 2009                [Page 11]


Internet-Draft        WSON Signaling Extensions               July 2008


   Number 0f Metrics: 24 bits

   Wavelength Metric: (1, 2, or 4 octets)

         The wavelength metric represents in some fashion the
   desirability or lack thereof to use this wavelength over another
   available wavelength. Different wavelength assignment algorithms may
   use this information differently.

7.3. Least-Loaded Wavelength Assignment (informational)

   The Least-Loaded wavelength assignment algorithm [HZang00] can be
   implemented in a distributed fashion via signaling with the addition
   of channel count metric information. Least-loaded assignment applies
   to multi-fiber links hence the supplemental information pertains to
   the number of available channels at a particular wavelength. Hence
   the subchannel metric of section 7.2. would simple be the channel
   count of a particular wavelength.

   The per node processing to implement the least-loaded assignment
   algorithm consists of receiving the label set and supplementary
   information TLVs (wavelengths and their channel counts) and taking
   the minimum of the received channel counts and the egress channel
   counts on a per wavelength basis. Where wavelengths with zero
   available channels will be discarded from the label set.  The
   resulting channel counts and wavelength set will then be forwarded on
   to the next node for processing. For more details on least loaded
   wavelength assignment see [WSON-Frame] and [HZang00].

   Example of Wavelength set and wavelength channel count metric.
   Suppose that in a 40 channel multi-fiber system and that the
   wavelengths (frequencies) have the following number of channels (this
   is a multi-fiber system) available:

            Frequency(THz)    channels available
         -----------------------------------------
            192.0             3
            192.5             2
            193.1             1
            193.9             2
            194.0             2
            195.2             1
            195.8             1






Bernstein et al.       Expires January 7, 2009                [Page 12]


Internet-Draft        WSON Signaling Extensions               July 2008


   We can then represent this list of available frequencies using the
   standard label set inclusive list. The wavelength metric list
   corresponding to this wavelength set would be 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Info Type=1   | M.Size = 0    |   Num Metrics = 7             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        3      |        2      |          1    |      2        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        2      |        1      |          1    |  Padded to 0  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




8. Security Considerations

   This document has no requirement for a change to the security models
   within GMPLS and associated protocols. That is the OSPF-TE, RSVP-TE,
   and PCEP security models could be operated unchanged.

   However satisfying the requirements for RWA using the existing
   protocols may significantly affect the loading of those protocols.
   This makes the operation of the network more vulnerable to denial of
   service attacks. Therefore additional care maybe required to ensure
   that the protocols are secure in the WSON environment.

   Furthermore the additional information distributed in order to
   address the RWA problem represents a disclosure of network
   capabilities that an operator may wish to keep private. Consideration
   should be given to securing this information.



9. IANA Considerations

   TBD. Once finalized in our approach we will need identifiers for such
   things and modulation types, modulation parameters, wavelength
   assignment methods, etc...

10. Acknowledgments

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




Bernstein et al.       Expires January 7, 2009                [Page 13]


Internet-Draft        WSON Signaling Extensions               July 2008


11. References

11.1. Normative References

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching
             (GMPLS) Signaling Functional Description", RFC 3471,
             January 2003.

   [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
             Switching (GMPLS) Signaling Resource ReserVation Protocol-
             Traffic Engineering (RSVP-TE) Extensions", RFC 3473,
             January 2003.

   [RFC4328] Papadimitriou, D., "Generalized Multi-Protocol Label
             Switching (GMPLS) Signaling Extensions for G.709 Optical
             Transport Networks Control", RFC 4328, January 2006.

   [RFC4420] Farrel, A., Ed., Papadimitriou, D., Vasseur, J.-P., and A.
             Ayyangar, "Encoding of Attributes for Multiprotocol Label
             Switching (MPLS) Label Switched Path (LSP) Establishment
             Using Resource ReserVation Protocol-Traffic Engineering
             (RSVP-TE)", RFC 4420, February 2006.

   [RFC4606] Mannie, E. and D. Papadimitriou, "Generalized Multi-
             Protocol Label Switching (GMPLS) Extensions for Synchronous
             Optical Network (SONET) and Synchronous Digital Hierarchy
             (SDH) Control", RFC 4606, August 2006.



11.2. Informative References

   [WSON-Frame] G. Bernstein, Y. Lee, W. Imajuku, "Framework for GMPLS
             and PCE Control of Wavelength Switched Optical Networks",
             work in progress: draft-bernstein-ccamp-wavelength-
             switched-03.txt, February 2008.

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





Bernstein et al.       Expires January 7, 2009                [Page 14]


Internet-Draft        WSON Signaling Extensions               July 2008


   [Otani]  T. Otani, H. Guo, K. Miyazaki, D. Caviglia, "Generalized
             Labels for G.694 Lambda-Switching Capable Label Switching
             Routers (LSR)", work in progress: draft-ietf-ccamp-gmpls-g-
             694-lambda-labels-01.txt, May 2008.

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

Author's Addresses

   Greg Bernstein
   Grotto Networking
   Fremont, CA, USA

   Phone: (510) 573-2237
   Email: gregb@grotto-networking.com
















Bernstein et al.       Expires January 7, 2009                [Page 15]


Internet-Draft        WSON Signaling Extensions               July 2008


   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

   Daniel King
   Aria Networks
   44/45 Market Place,
   Chippenham, SN15 3HU, United Kingdom

   Phone: +44 7790 775187
   Email: daniel.king@aria-networks.com

   Young Lee (ed.)
   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
















Bernstein et al.       Expires January 7, 2009                [Page 16]


Internet-Draft        WSON Signaling Extensions               July 2008


APPENDIX A: Requirement of Bidirectional Lightpath with the Same
Wavelength in Both Directions



A.1. Introduction

   With the Lambda Switch (LSC) support defined in GMPLS [RFC3471] and
   RSVP-TE signaling [RFC3473], by properly configuring the wavelength
   selective switching elements such as ROADMs or OXCs at the transit
   nodes, both unidirectional and bidirectional wavelength (optical
   lambdas) lightpaths can be established in a wavelength switched
   optical network (WSON).

   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, there is another
   constraint on wavelength usage, say, require the same wavelength on
   both directions. This constraint might be introduced by carriers for
   a simplified management to reduce the OPEX. Moreover, according to
   some network hardware configurations, users' bidirectional lightpath
   has to use the same wavelength in both directions. For example, only
   a specific wavelength among the multiplexed wavelengths could be
   added/dropped to an optical end node. Some type of ROADMs may
   add/drop the same wavelength simultaneously.  In particular, with
   some WSONs, if different wavelengths in two inverse directions are
   used, this brings a port-remapping problem, which is stated as
   follows.

A.2. Port-remapping Problem

   This problem occurs in the following situations:



   (1) Fixed wavelength multiplexer/demultiplexer like AWGs may be
   employed in data plane at each node.  Each incoming and outgoing
   wavelength is with a dedicated fixed port of AWG. For example,



Bernstein et al.       Expires January 7, 2009                [Page 17]


Internet-Draft        WSON Signaling Extensions               July 2008


   wavelength lambda 1 is on port 1, and wavelength lambda 2 is on port
   2, and so on. See Fig.2.1.

      +--+
      |  |--->  lambda 1: port 1
   -->|  |--->  lambda 2: port 2
      |  |--->  lambda 3: port 3
      +--+
   A. AWG Demultiplexer case.

      +--+
      |  |<---  lambda 1: port 1
   <--|  |<---  lambda 2: port 2
      |  |<---  lambda 3: port 3
      +--+
   B. AWG Multiplexer case.

   Fig.2.1. The fixed wavelength-port mapping of AWG
   Multiplexer/Demultiplexer.

   (2) Compared to a wavelength-tunable optical transponder array, low
   cost fixed-tuned optical transponder array may be employed at the
   edge node. In an optical transponder, the optical responder is bound
   with the transmitter.  Each of the optical transmitters and
   responders are physically connected to one port of AWG or OXC
   according to the hardware configuration. See Fig.2.2.



      +--+               +----+
      |  |<---lambda 1---| T1 |
   <--|  |<---lambda 2---| T2 |
      |  |<---lambda 3---| T3 |
      +--+               +----+
   AWG Multiplexer       optical transmitter array

   A. The configuration with the optical transmitters connecting AWG.



      +--+               +----+
      |  |---lambda 1--->| R1 |
   -->|  |---lambda 2--->| R2 |
      |  |---lambda 3--->| R3 |
      +--+               +----+
   AWG Demultiplexer     optical responder array



Bernstein et al.       Expires January 7, 2009                [Page 18]


Internet-Draft        WSON Signaling Extensions               July 2008


   B. One possible configuration with the optical responders connecting
   AWG.


      +--+    +-----+    +----+
      |  |--->|     |--->| R1 |
   -->|  |--->| OXC |--->| R2 |
      |  |--->|     |--->| R3 |
      +--+    +-----+    +----+
   AWG Demultiplexer     optical responder array
   C. One possible configuration with the optical responders connecting
   OXC.

   Fig.2.2. The fixed optical transmitter/responder- AGW/OXC port
   mapping at the optical end nodes.

   Consider a bidirectional lightpath with different wavelengths on two
   directions. The optical transmitter of which output wavelength is the
   same as the outgoing-wavelength (say lambda 1) is chosen first for
   using the lightpath. Then, the optical responder attached to that
   transmitter should be selected for receiving the incoming wavelength
   (say lambda 2). The responder generally can receive any of different
   wavelengths. Therefore, if another bidirectional lightpath is
   assigned the same outgoing wavelength (lambda 1) but with a different
   incoming wavelength (say lambda 3), the same transmitter and
   responder pair is selected. See Fig.2.3.

                +----+
   <-lambda 1---| T1 |
                +----+
   A. Optical transmitter T1 sends optical signals on lambda 1.


                +----+
   -lambda 2--->| R1 |
                +----+
   B. Optical responder R1 receives optical signals on lambda 2 for one
   bidirectional lightpath.



                +----+
   -lambda 3--->| R1 |
                +----+
   C. Optical responder R1 can receive optical signals on lambda 3 for
   another bidirectional lightpath.



Bernstein et al.       Expires January 7, 2009                [Page 19]


Internet-Draft        WSON Signaling Extensions               July 2008


   Fig.2.3. Transmitter sends optical signals on the fixed-tuned
   wavelength; the responder can receive data on different wavelengths.

   However, the communication using the transponder and the
   bidirectional lightpath with different wavelengths will not succeed
   under the situations (1) and (2) mentioned above. Remember the fixed
   port mapping that each incoming wavelength is fixed on a unique port
   of AWG due to the situation (1), and the optical responder is also
   fixedly connected to a unique port of AWG or OXC due to the situation
   (2). Conversely, the incoming wavelength may change every lightpath
   (see lambda 2 and lambda 3 in the above case) for the same outgoing
   wavelength (lambda 1). The current incoming wavelength (lambda 3) is
   not on the port of AWG to which the optical responder connects
   originally (lambda 2), see Fig. 2.4.  To connect the optical
   responder to the proper port on which the incoming wavelength is,
   even in different outgoing wavelengths, a port-remapping process
   between the optical responder and AWG ports may be required.



      +--+               +----+
      |  |<---lambda 1---| T1 |
   <--|  |<---lambda 2---| T2 |
      |  |<---lambda 3---| T3 |
      +--+               +----+
      AWG Multiplexer
   A. Optical transmitter T1 sends optical signals on lambda 1.

      +--+
      |  |--            +----+
   -->|  |--lambda2---->| R1 |
      |  |--lambda3-X   +----+
      +--+
   AWG Demultiplexer
   B. Optical responder R1 cannot receive optical signals on lambda 3
   due to the fixed port mapping, in case of that R1 is physically
   connected to the port 2 of lambda 2 on AWG.

   Fig.2.4. Port-remapping problem occurs due to the fixed port-mapping
   between the optical responder and AWG port.

A.3. Port-remapping with OXC

The port-remapping capability depends on the system configurations at
users' optical end nodes.  For example, an OXC may be employed to switch
the incoming wavelength from the port of AWG to the port which the
optical responder is connected physically, see Fig. 3.1.


Bernstein et al.       Expires January 7, 2009                [Page 20]


Internet-Draft        WSON Signaling Extensions               July 2008


   However, equipping users' optical end nodes with OXCs introduces
   extra costs.  There exists a trade-off between port-remapping
   capability and cost/system complexity.

      +--+            +-------+    +----+
      |  |-lambda 1-->|    /--|--->| R1 |
   -->|  |-lambda 2-->|---/   |--->| R2 |
      |  |-lambda 3-->|  OXC  |--->| R3 |
      +--+            +-------+    +----+
   AWG Demultiplexer
   A. The optical responder R1 can receive the optical signals on lambda
   2.


         +--+            +-------+    +----+
         |  |-lambda 1-->|   /---|--->| R1 |
      -->|  |-lambda 2-->|  /    |--->| R2 |
         |  |-lambda 3-->|-/ OXC |--->| R3 |
         +--+            +-------+    +----+
   AWG Demultiplexer
   B. The optical responder R1 can receive the optical signals on lambda
   3.

   Fig.3.1. The port-remapping capability provided by OXC.

   Users have various types of optical end node configurations to choose
   from.  Some configurations such as those equipped with OXCs might
   provide flexibility but could be costly and potentially complicated.
   Equally, while other configurations without OXCs might lack the
   flexibility they may be inexpensive and easy to use and maintain.

A.4. Avoiding Port-remapping Problem: Bidirectional Lightpath using
Same Wavelength on Both Directions

   Which solution will be employed depends on the considerations of the
   flexibility and cost/complexity trade-off.  If users do not have
   port-remapping capability at optical end nodes, then it is necessary
   to avoid the port-remapping, and find a feasible approach to provide
   users full-duplex transmission capability with bidirectional
   lightpath.

   A feasible approach is to establish a bidirectional lightpath with
   the same wavelength on both directions.  At the optical end node,
   fixed-tuned transponder array is connected to the proper ports of AWG
   according to the wavelength.  Optical transmitter and responder pair
   connecting the selected outgoing and incoming wavelength ports of AWG
   will be assigned to the bidirectional lightpath.  In this situation,


Bernstein et al.       Expires January 7, 2009                [Page 21]


Internet-Draft        WSON Signaling Extensions               July 2008


   the bidirectional lightpath with the same wavelength on both
   directions is required.









Intellectual Property Statement

   The IETF 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
   this 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.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR 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
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Disclaimer of Validity

   This document and the information contained herein 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 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.





Bernstein et al.       Expires January 7, 2009                [Page 22]


Internet-Draft        WSON Signaling Extensions               July 2008


Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.





































Bernstein et al.       Expires January 7, 2009                [Page 23]