Network Working Group                                            Y. Lee
Internet Draft                                                   Huawei
Intended status: Standards Track                           G. Bernstein
Expires: April 2010                                   Grotto Networking





                                                       October 12, 2009

     OSPF Enhancement for Signal and Network Element Compatibility for
                   Wavelength Switched Optical Networks


           draft-lee-ccamp-wson-signal-compatibility-ospf-00.txt


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 April 12, 2007.

Copyright Notice

   Copyright (c) 2009 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 in effect on the date of



Lee and Bernstein       Expires April 12, 2010                 [Page 1]


Internet-Draft   Wavelength Switched Optical Networks      October 2009


   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   This document provides GMPLS OSPF routing enhancements to support
   signal compatibility constraints associated with WSON network
   elements. These routing enhancements are required in common optical
   or hybrid electro-optical networks where not all of the optical
   signals in the network are compatible with all network elements
   participating in the network.

   This compatibility constraint model is applicable to common optical
   or hybrid electro optical systems such as OEO switches, regenerators,
   and wavelength converters since such systems can be limited to
   processing only certain types of WSON signals.

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

Table of Contents


   1. Introduction...................................................3
   2. WSON Network Element Compatibility Information Model...........3
      2.1. Modulation Type List......................................4
      2.2. FEC Type List.............................................4
      2.3. Bit Rate Range List.......................................4
      2.4. Acceptable Client Signal List.............................4
   3. GMPLS OSPF Routing Protocol Enhancement to support Compatibility5
      3.1. Modulation Type List sub-TLV..............................5
      3.2. FEC Type List sub-TLV.....................................7
      3.3. Bit Rate Range List sub-TLV...............................9
      3.4. Processing Capability List sub-TLV.......................10
      3.5. Client Signal List sub-TLV...............................12
   4. Security Considerations.......................................12
   5. IANA Considerations...........................................12
   6. Acknowledgments...............................................12
   7. References....................................................13
      7.1. Normative References.....................................13
      7.2. Informative References...................................13
   8. Contributors..................................................14



Lee and Bernstein       Expires April 12, 2010                 [Page 2]


Internet-Draft   Wavelength Switched Optical Networks      October 2009


   Authors' Addresses...............................................14
   Intellectual Property Statement..................................14
   Disclaimer of Validity...........................................15

   1. Introduction

   The document [WSON-Compat] explains how to extend the wavelength
   switched optical network (WSON) control plane to allow both multiple
   WSON signal types and common hybrid electro optical systems. In WSON,
   not all of the optical signals in the network are compatible with all
   network elements participating in the network. Therefore, signal
   compatibility is an important constraint in path computation in a
   WSON.

   This document provides GMPLS OSPF routing enhancements to support
   signal compatibility constraints associated with WSON network
   elements. These routing enhancements are required in common optical
   or hybrid electro-optical networks where not all of the optical
   signals in the network are compatible with all network elements
   participating in the network.

   This compatibility constraint model is applicable to common optical
   or hybrid electro optical systems such as OEO switches, regenerators,
   and wavelength converters since such systems can be limited to
   processing only certain types of WSON signals.

   2. WSON Network Element Compatibility Information Model

   In [WSON-Compat] it was explained that a network element (NE) in a
   WSON may or may not be compatible with a particular optical signal
   based upon the following criteria:

   1. Limited wavelength range -- Already modeled in GMPLS for WSON

   2. Modulation type restriction (including forward error correction -
      FEC- coding)

   3. Bit rate range restriction (includes a particular rate)

   4. Client signal dependence

   In the following we furnish an information model for the above
   properties. This model can be either applied to all ports of a
   network element, i.e., NE wide, or to individual ports, i.e., on a
   link level.




Lee and Bernstein       Expires April 12, 2010                 [Page 3]


Internet-Draft   Wavelength Switched Optical Networks      October 2009


2.1. Modulation Type List

   Modulation type, also known as optical tributary signal class, comes
   in two distinct flavors: (i) ITU-T standardized types; (ii) vendor
   specific types. The permitted modulation type list can include any
   mixture of standardized and vendor specific types.

   <modulation-list>::= [<STANDARD_MODULATION>|<VENDOR_MODULATION>]...

   Where the STANDARD_MODULATION object just represents one of the ITU-T
   standardized optical tributary signal class and the VENDOR_MODULATION
   object identifies one vendor specific modulation type.

2.2. FEC Type List

   Some devices can handle more than one FEC type and hence a list is
   needed.

   <fec-list>::= [<FEC>]

   Where the FEC object represents one of the ITU-T standardized FEC
   defined in [G.709] and [G.707] or vendor-specific FEC.

2.3. Bit Rate Range List

   Some devices can handle more than one particular bit rate range and
   hence a list is needed.

   <rate-range-list>::= [<rate-range>]...

   <rate-range>::=<START_RATE><END_RATE>

   Where the START_RATE object represents the lower end of the range and
   the END_RATE object represents the higher end of the range.

2.4. Acceptable Client Signal List

   The list is simply:

   <client-signal-list>::=[<GPID>]...

   Where the Generalized Protocol Identifiers (GPID) object represents
   one of the IETF standardized GPID values as defined in [RFC3471] and
   [RFC4328].





Lee and Bernstein       Expires April 12, 2010                 [Page 4]


Internet-Draft   Wavelength Switched Optical Networks      October 2009


   3. GMPLS OSPF Routing Protocol Enhancement to support Compatibility

   This section describes GMPLS OSPF Routing protocol enhancement based
   on network element compatibility information model defined in the
   previous section. Note that the encoding defined in this section is
   specific for OSPF extension, but similar encoding can be applied to
   IS-IS and alternative methods distributing traffic engineering
   information.

   In [RFC4202], Routing extensions for GMPLS, the concept of an
   Interface Switching Capability Descriptors is defined. In particular
   a "Lambda-Switch Capable" (LSC) descriptor is listed. Reference
   [RFC4202] also states: "Depending on a particular Interface Switching
   Capability, the Interface Switching Capability Descriptor may include
   additional information, as specified below." However no mention is
   made of the compatibility criteria discussed in [WSON-Compat], i.e.,
   modulation type, FEC type, bit rate range, or client signal. The only
   additional information currently defined is "reservable bandwidth per
   priority".

   In references [RFC4203] and [RFC5307] a variable length sub-TLV type
   for Interface Switching Capability Descriptors (ISCD) is defined.
   There is a section in the general ISCD sub-TLV called "Switching
   Capability-specific information". They then state: "When the
   Switching Capability field is LSC, there is no Switching Capability
   specific information field present."

   [It is an open question whether we can add new information to the
   existing LSC ISCD. In either case the following suggests an encoding
   that could be used within the switching capability specific
   information field or as separate sub-TLVs.]



3.1. Modulation Type List sub-TLV

   The modulation type list sub-TLV may consist of two different types
   of fields: 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               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




Lee and Bernstein       Expires April 12, 2010                 [Page 5]


Internet-Draft   Wavelength Switched Optical Networks      October 2009


   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 it is an input modulation constraint
   and I bit set to 0 indicates it is an output modulation constraint.

   Note that if an output modulation is not specified then it is implied
   that it is the same as the input modulation. In such case, no
   modulation conversion is performed.

   The format for the standardized type for the input 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |1|1|       Modulation ID         |           Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Possible additional modulation parameters depending upon    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :   the modulation ID                                           :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


      Modulation ID (S bit = 1); Input modulation (I bit = 1)

   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.






Lee and Bernstein       Expires April 12, 2010                 [Page 6]


Internet-Draft   Wavelength Switched Optical Networks      October 2009


   The format for vendor specific modulation field (for input
   constraint) 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|1|  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.

3.2. FEC Type List sub-TLV

   The FEC type list sub-TLV may consist of two different types of
   fields: 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                                                  :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+





Lee and Bernstein       Expires April 12, 2010                 [Page 7]


Internet-Draft   Wavelength Switched Optical Networks      October 2009


   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 I bit set to 1 indicates it is an input FEC constraint and I
   bit set to 0 indicates it is an output FEC constraint.

   Note that if an output FEC is not specified then it is implied that
   it is the same as the input FEC. In such case, no FEC conversion is
   performed.



   The length is the length in bytes of the entire FEC type field.

   The format for input 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|1|       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



   The format for input vendor-specific FEC field is given by:







Lee and Bernstein       Expires April 12, 2010                 [Page 8]


Internet-Draft   Wavelength Switched Optical Networks      October 2009


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



3.3. Bit Rate Range List sub-TLV

   The bit rate range list sub-TLV makes use of the following bit rate
   range field:

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          Starting Bit Rate                    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            Ending Bit Rate                    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   The starting and ending bit rates are given as 32 bit IEEE floating
   point numbers in bits per second. Note that the starting bit rate is
   less than or equal to the ending bit rate.




Lee and Bernstein       Expires April 12, 2010                 [Page 9]


Internet-Draft   Wavelength Switched Optical Networks      October 2009




   The bit rate range list sub-TLV is then 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+ Bit Range Field #1  +-+-+-+-+-+-+-+-+-+
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :                               :                               :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+ Bit Range Field #M  +-+-+-+-+-+-+-+-+-+
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


3.4. Processing Capability List sub-TLV

   The processing capability list sub-TLV is a list of WSON network
   element (NE) that can perform signal processing functions including:

     1. Regeneration capability

     2. Fault and performance monitoring

     3. Vendor Specific capability

   Note that the code points for Fault and performance monitoring and
   vendor specific capability are subject to further study.

   The processing capability list sub-TLV is then given by:















Lee and Bernstein       Expires April 12, 2010                [Page 10]


Internet-Draft   Wavelength Switched Optical Networks      October 2009


      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Processing Cap ID     |         Length               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Possible additional capability parameters depending upon    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :   the processing ID                                           :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   When the processing Cap ID is "regeneration capability", the
   following additional capability parameters are provided in the sub-
   TLV:

   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 when the capability of regenerator is indicated to be
   Selective Regeneration Pools, regeneration pool properties such as
   ingress and egress restrictions and availability need to be
   specified. This encoding is to be determined in the later revision.





Lee and Bernstein       Expires April 12, 2010                [Page 11]


Internet-Draft   Wavelength Switched Optical Networks      October 2009


3.5. Client Signal List sub-TLV

   The acceptable client signal list sub-TLV is a list of Generalized
   Protocol Identifiers (GPIDs). GPIDs are assigned by IANA and many are
   defined in [RFC3471] and [RFC4328].

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |       Number of GPIDs         |          GPID #1              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :                               |                               :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            GPID #N            |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Where the number of GPIDs is an integer greater than or equal to one.



   4. Security Considerations

   This document does not introduce any further security issues other
   than those discussed in [RFC 3630], [RFC 4203].

   5. IANA Considerations

   TBD.

   6. Acknowledgments

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
















Lee and Bernstein       Expires April 12, 2010                [Page 12]


Internet-Draft   Wavelength Switched Optical Networks      October 2009




   7. References

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

   [G.694.1] ITU-T Recommendation G.694.1, "Spectral grids for WDM
             applications: DWDM frequency grid", June, 2002.

   [RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing Extensions
             in Support of Generalized Multi-Protocol Label Switching
             (GMPLS)", RFC 4202, October 2005

   [RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions in
             Support of Generalized Multi-Protocol Label Switching
             (GMPLS)", RFC 4203, October 2005.

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

   [RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS Extensions
             in Support of Generalized Multi-Protocol Label Switching
             (GMPLS)", RFC 5307, October 2008.



7.2. Informative References

   [WSON-Compat]   G. Bernstein, Y. Lee, B. Mack-Crane, "WSON Signal
             Characteristics and Network Element Compatibility
             Constraints for GMPLS ", draft-bernstein-ccamp-wson
             compatibility, work in progress.









Lee and Bernstein       Expires April 12, 2010                [Page 13]


Internet-Draft   Wavelength Switched Optical Networks      October 2009


   8. Contributors




Authors' Addresses

   Young Lee (ed.)
   Huawei Technologies
   1700 Alma Drive, Suite 100
   Plano, TX 75075
   USA

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


   Greg M. Bernstein (ed.)
   Grotto Networking
   Fremont California, USA

   Phone: (510) 573-2237
   Email: gregb@grotto-networking.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



Lee and Bernstein       Expires April 12, 2010                [Page 14]


Internet-Draft   Wavelength Switched Optical Networks      October 2009


   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.






























Lee and Bernstein       Expires April 12, 2010                [Page 15]