Network work group                                           Fatai Zhang
Internet Draft                                                    Huawei
Intended status: Standards Track                            G. Bernstein
Expires: September 2009                                Grotto Networking
                                                               Young Lee
                                                                  Dan Li
                                                             Jianrui Han
                                                                  Huawei
                                                          March 02, 2009




            OSPF Extensions in Support of Routing and Wavelength
      Assignment (RWA) in Wavelength Switched Optical Networks (WSONs)



              draft-zhang-ccamp-rwa-wson-routing-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 September 02, 2009.

Abstract

   Wavelength switched optical networks (WSONs) are based on Wavelength
   Division Multiplexing (WDM) in which user traffic is carried by data
   channels of different optical wavelengths. In traditional WDM
   Networks, each wavelength path is statically configured. With the



<Zhang>               Expires September 2, 2009               [Page 1]


Internet-Draft        OSPF Extensions for WSON              March 2009


   deployment of Reconfigurable Optical Add-Drop Multiplexers (ROADMs),
   photonic cross-connects (PXCs), and tunable laser, WSONs have become
   more dynamic, and operators can flexibly set up wavelength paths to
   carry user traffic.

   In WSONs where there are no or a limited number of switches capable
   of wavelength conversion paths must be set up subject to the
   "wavelength continuity" constraint. This leads to a path computation
   problem known as routing and wavelength assignment (RWA). In order to
   perform such computations, it is necessary to collect information
   about the available wavelengths within the network.

   This document describes OSPF routing protocols extensions to support
   Wavelength Switched Optical Networks (WSON) under the control of
   Generalized MPLS (GMPLS).

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. Node Information.............................................3
      2.1. Connectivity Matrix.....................................4
         2.1.1. Link Set...........................................5
      2.2. Wavelength Converter Pool Information...................7
   3. Link Information.............................................7
      3.1. WSON Port Wavelength Restrictions.......................8
      3.2. Wavelength Availability Information.....................9
      3.3. Shared Backup Wavelengths..............................11
   4. Procedures for Routing Flooding.............................11
   5. Security Considerations.....................................12
   6. IANA Considerations.........................................12
      6.1. Node Information.......................................12
      6.2. Link Information.......................................12
   7. References..................................................12
   8. Authors' Addresses..........................................15
   Acknowledgment.................................................16







Zhang                  Expires September 2009                 [Page 2]


Internet-Draft        OSPF Extensions for WSON              March 2009


1. Introduction

   Wavelength switched optical networks (WSONs) are based on Wavelength
   Division Multiplexing (WDM) in which user traffic is carried by data
   channels of different optical wavelengths. In traditional WDM
   Networks, each wavelength path is statically configured. With the
   deployment of Reconfigurable Optical Add-Drop Multiplexers (ROADMs),
   photonic cross-connects (PXCs), and tunable laser, WSONs have become
   more dynamic, and operators can flexibly set up wavelength paths to
   carry user traffic.

   In WSONs where there are no or a limited number of switches capable
   of wavelength conversion paths must be set up subject to the
   "wavelength continuity" constraint. This leads to a path computation
   problem known as routing and wavelength assignment (RWA). In order to
   perform such computations, it is necessary to collect information
   about the available wavelengths within the network.

   [WSON-Frame] provides a framework for applying GMPLS [RFC3945] and
   the Path Computation Element (PCE) architecture [RFC4655] to the
   control of WSONs to address the RWA problem. [WSON-Info] describes an
   information model that specifies the information needed at various
   points in a WSON in order to compute paths and establish Label
   Switched Paths (LSPs). Based on the information model of [WSON-Info],
   [WSON-Encode] provides efficient protocol-independent encodings of
   the information needed by the RWA process in a WSON. Such encodings
   can be used to extend GMPLS signaling and routing protocols.

   Therefore, in order to enable GMPLS to control WSON networks, this
   document follows on from [WSON-Info], [WSON-Encode], and [WSON-IGP-
   Eval] to define extensions to the OSPF routing protocol to enhance
   the Traffic Engineering (TE) properties of GMPLS TE which are defined
   in [RFC3630], [RFC4202], and [RFC4203].

   No consideration of optical impairment routing related information is
   included in this document.

2. Node Information

   According to [WSON-Info] and [WSON-Encode], the node information
   about WSON nodes includes Node ID, connectivity matrix, wavelength
   converter pool information. Except for the Node ID which should
   comply with Routing Address described in [RFC3630], the other pieces
   of information are defined in this document.

   [OSPF-Node] defines a new top TLV named the Node Attribute TLV which
   carries attributes related to a router/node. Connectivity matrix,


Zhang                  Expires September 2009                 [Page 3]


Internet-Draft        OSPF Extensions for WSON              March 2009


   wavelength converter pool information are attributes associated with
   a WSON node, so this document defines the following sub-TLVs of Node
   Attribute TLV:

   (1)Connectivity matrix sub-TLV

   (2)Wavelength converter pool information sub-TLV

2.1. Connectivity Matrix

   Unlike the packet and TDM networks whose switching devices are
   symmetric, the switching devices in a WSON are highly asymmetric.
   Therefore, it is necessary to identify which ingress ports and
   wavelengths can be connected to (the same wavelength on) a specific
   egress port. Detailed descriptions of the Connectivity Matrix can be
   found in the corresponding sections of [WSON-Info] and [WSON-Encode].

   The Connectivity Matrix TLV is a sub-TLV (the type is TBD by IANA) of
   the Node Attribute TLV. The format of this sub-TLV is 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Connectivity  |              Reserved                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Link Set A #1                          |
      :                               :                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Link Set B #1                          |
      :                               :                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Additional Link set pairs as needed       |
      :                     to specify connectivity                   :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Type = TBD

   Connectivity : 8 bits

       The following values are currently defined. All other values are
   reserved and SHOULD be transmitted as zero and ignored on receipt.

       0x01: Fixed Connectivity Matrix


Zhang                  Expires September 2009                 [Page 4]


Internet-Draft        OSPF Extensions for WSON              March 2009


       Indicates that the switching element is a kind of fixed switching
   device, so the connectivity matrix represents the potential
   connectivity matrix. This applies to asymmetric fixed devices or to
   the fixed part of a "hybrid" device [Switch].

       0x02: Switched Connectivity Matrix

       Indicates that the switching element is a kind of switched device
   (e.g., ROADM or OXC). The connectivity matrix represents the
   potential connectivity matrix for an asymmetric switch.

   Reserved: 24 bits

       This field is reserved. It SHOULD be set to zero on transmission
   and MUST be ignored on receipt.

   Link Set: At least one Link Set MUST be present. Multiple Link Sets
   MAY be present. Each one has variable length. The Link set is defined
   in Section 2.2.1..

2.1.1. Link Set

       Link Set identifies a link group and is 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Action     |Dir|  Format   |    Num Links  |    Reserved   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Link Identifier 1                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                               :                               :
      :                               :                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Link Identifier N                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   The Link Set is not a kind of sub-TLV and it is just a part of the
   Connectivity Matrix TLV. (Note that this construct may be reused in
   the Wavelength Converter Pool information in Section 2.3 in a future
   version of this document.)

   Action: 8 bits

       The following values are currently defined. All other values are
   reserved.


Zhang                  Expires September 2009                 [Page 5]


Internet-Draft        OSPF Extensions for WSON              March 2009


       0x01: Inclusive List

       Indicates that one or more link identifiers are included in the
   Link Set. Each identifies a separate link that is part of the set.

       0x02: Inclusive Range

       Indicates that the Link Set defines a range of links.  It
   contains two link identifiers. The first identifier indicates the
   start of the range (inclusive). The second identifier indicates the
   end of the range (inclusive). All links with numeric values between
   the bounds are considered to be part of the set. A value of zero in
   either position indicates that there is no bound on the corresponding
   portion of the range. Note that the Action field could be set to
   0x02(Inclusive Range) only when unnumbered link identifier is used.

   Directionality of the Link Set (Dir): 2 bits

       The following values are currently defined. All other values are
   reserved.

       0x01: Bidirectional

       Indicates that the links in the Link Set are bidirectional.

      0x02: Incoming

       Indicates that the links in the Link Set are from the incoming
   direction with respect to the node advertising the information.

      0x03: Outgoing

       Indicates that the links in the Link Set are to the outgoing
   direction with respect to the node advertising the information.

   Format: 6 bits

   This field identifies the format of the link identifier. The
   following values are currently defined. All other values are reserved.

      0x01: Link Local Identifier with IPv4 address

       Indicates that the links in the Link Set are identified by link
   local identifiers which are IPv4 numbered. All link local identifiers
   are supplied in the context of the advertising node.

      0x02: Link Local Identifier with unnumbered interface


Zhang                  Expires September 2009                 [Page 6]


Internet-Draft        OSPF Extensions for WSON              March 2009


       Indicates that the links in the Link Set are identified by link
   local identifiers which are unnumbered interface IDs. All link local
   identifiers are supplied in the context of the advertising node.

   Num Links: 8 bits

   This field indicates the total number of the links in the Link Set.

   Reserved: 8 bits

       This field is reserved. It MUST be set to zero on transmission
   and MUST be ignored on receipt.

   Link Identifier: 32 bits for each link

      If the Format field is set to 0x01 (Link Local Identifier with
   IPv4 address), the link identifier is the interface IP address used
   to identify the incoming or outgoing port corresponding to the link.
   The format of the Link Identifier should comply with the format of
   the Local/Remote Interface IP Address described in [RFC3630].

       If the Format field is set to 0x02 (Link Local Identifier with
   unnumbered interface), the link identifier is unnumbered.

   An example about Connectivity Matrix representation could be referred
   to the Section 3.2 of [WSON-Encode].

2.2. Wavelength Converter Pool Information

     TBD.

3. Link Information

   The most common link sub-TLVs are already defined in [RFC3630],
   [RFC4203]. For example, Link ID, Administrative Group, Interface
   Switching Capability Descriptor (ISCD), Link Protection Type, Shared
   Risk Link Group Information (SRLG), and Traffic Engineering Metric.

   For WSONs, per [WSON-Info] and [WSON-Encode], the following
   additional link sub-TLVs are defined in this document.

   (1) WSON Port Wavelength Restrictions sub-TLV

   (2) Wavelength Availability sub-TLV

   (3) Shared Backup Wavelengths sub-TLV



Zhang                  Expires September 2009                 [Page 7]


Internet-Draft        OSPF Extensions for WSON              March 2009


3.1. WSON Port Wavelength Restrictions

   In WSONs, there may be wavelength restrictions on a link or port. For
   example, a WSON link might only be able to support switching some
   specific wavelengths. These restrictions are distributed by OSPF to
   be convenient for wavelength path computation.

   The WSON Port Wavelength Restrictions TLV is a sub-TLV (the type is
   TBD by IANA) of the Link TLV. The format of this sub-TLV is 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |RestrictionKind|T|  Reserved   |       MaxNumChannels          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     Wavelength Set                            |
     |                      (variable)                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type = TBD

   RestrictionKind: 8 bits

       The following values are currently defined. All other values are
   reserved.

       0x01: Simple wavelength selective restriction

       In this case, MaxNumChannels indicates the maximum number of
   wavelengths permitted on the port, and the accompanying Wavelength
   Set indicates the specific permitted wavelengths.

       0x02: Waveband device with a tunable center frequency and
   passband.

       In this case, MaxNumChannels indicates the maximum width of the
   waveband in terms of the channels spacing given in the Wavelength Set.
   The corresponding wavelength set is used to indicate the overall
   tuning range. Specific center frequency tuning information can be
   obtained from dynamic channel in use information.

   MaxNumChannels indicates the maximum number of channels supported on
   the port/waveband dependent on the setting of the RestrictionKind
   field.




Zhang                  Expires September 2009                 [Page 8]


Internet-Draft        OSPF Extensions for WSON              March 2009


   Wavelength Set information is carried as defined in Section 3.4 of
   [WSON-Encode].

3.2. Wavelength Availability Information

   The requirements for a global semantic for wavelength labels and the
   corresponding standardized wavelength label can be found in [Lambda-
   Labels].

   Because the wavelength continuity along the wavelength Label Switched
   Path (LSP) should be ensured without wavelength conversion or with
   wavelength conversion at some switches along the path, the
   information about wavelength availability and wavelength connectivity
   is very important when computing a wavelength LSP. For example, if
   the wavelength label range [lambda 1, lambda 5] of fiber 1 can be
   connected to the same wavelength label range of fiber 2, but only
   lambda 3 is available on fiber 2 because other wavelength labels are
   occupied, lambda 3 must be selected on fiber 1.

   If the wavelength availability information is not known by the node
   performing the path computation, then the computation can only be
   performed at the level of TE links, and wavelength assignment must be
   resolved locally by the switches on a hop-by-hop basis enhanced by
   signaling protocol mechanisms used to negotiate label selection.
   However, this case may be very inefficient in the signaling protocol,
   and can easily lead to blocking problems where a path is selected for
   which there is no suitable wavelength availability, unless some or
   all of the switches along the path are capable of full wavelength
   conversion. In the general case of limited or no wavelength
   conversion, information on wavelength availability is essential to
   perform efficient and accurate path computation.

   It is possible to consider reporting the statuses of each wavelength
   on a link using implicit wavelength identification based on the link-
   local knowledge of wavelengths supported and a well-known sequence.
   However, this information would be of no use in a wider context (i.e.,
   away from the link ends). On the other hand, if the standardized
   label format described in [Lambda-Labels] is used to identify every
   wavelength when its status is reported, the wavelength information
   will be a little larger (or the order of one wavelength label per
   status advertised). This may have a significant affect on the total
   information advertised in a network because a WSON link often
   supports many wavelengths (e.g., 80 or 160 wavelength systems).

   To minimize the size of information, a bitmap wavelength set is
   defined in [WSON-Encode] to indicate the wavelength availability
   information for a fiber, i.e., only one bit is used to indicate the


Zhang                  Expires September 2009                 [Page 9]


Internet-Draft        OSPF Extensions for WSON              March 2009


   status of a certain wavelength (the wavelength is either available or
   not available).

   Note that there are five approaches for Wavelength Set which is used
   to represent the wavelength availability information described in
   Section 3.4 of [WSON-Encode]. Considering that the continuity of the
   available or unavailable wavelength set can be scattered for the
   dynamic wavelength availability, so it may burden the routing to
   reorganize the wavelength set information when the Inclusive
   (/Exclusive) List (/Range) approaches are used to represent
   wavelength availability information. Therefore, it is RECOMMENDED
   that only the Bitmap Set be used for representation wavelength
   availability information as follows.

   The Wavelength Availability  TLV is a sub-TLV (the type is TBD by
   IANA) of the Link TLV. The format of this sub-TLV is 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Num Wavelengths      |         Reserved              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Grid |  C.S. |     Reserved    |    n  for lowest frequency    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Bit Map Double-word #1 (Lowest frequency channels)         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :                                                               :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Bit Map Double-word #N (Highest frequency channels)|Padded bits|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type = TBD

   The three fields (Grid, C.S. and n) are defined in [Lambda-Label].

   Num Wavelengths: 8 bits

       Indicates the number of the wavelengths represented by the bit
   map.

   Each bit in the bit map represents a particular frequency with a
   value of 1/0 indicating whether the frequency is available or not.
   Bit position zero represents the lowest frequency, while each
   succeeding bit position represents the next frequency a channel
   spacing (C.S.) above the previous. The values of the bit map are
   defined as follows:


Zhang                  Expires September 2009                [Page 10]


Internet-Draft        OSPF Extensions for WSON              March 2009


       1 = Available

       0 = Assigned (in use, or failed, or administratively down, or
   under testing)

   The valid length of the bit map is clearly Num Wavelengths bits, but
   the bit map should be padded to make the whole number of the bits in
   bitmap be the time of 32 bits so that the TLV is a multiple of four
   bytes. Padded bit SHOULD be set to 0 and MUST be ignored.

   Bits that do not represent wavelengths (i.e., those in positions (Num
   Wavelengths - 1) and beyond) SHOULD be set to zero and MUST be
   ignored.

3.3. Shared Backup Wavelengths

   TBD.



4. Procedures for Routing Flooding

   The advertisement for the node attributes SHOULD comply with the
   procedures described in [OSPF-Node].

   In the WSON networks, the node information can be classified as two
   kinds: one is static information comparatively such as Node ID,
   Connectivity Matrix information; the other is dynamic information
   such as Wavelength Converter Pool Status information. For the static
   node information, the router announces the static node information in
   the node attribute TLV which could be advertised during the node
   starts or periodically for some configurable time (e.g., per hour or
   several hours). For the dynamic node information, the router
   announces this information in the separate node attribute TLV which
   SHOULD be advertised during node starts or when the corresponding
   node information is changed.

   For the WSON link information, the procedures for the routing
   flooding SHOULD comply with [RFC3630], [RFC4203] and the other
   existing family standards, and there is no extended process for the
   link attributes advertisement, except that some link sub-TLVs are
   defined in this document.

   Note that as with other TE information, an implementation SHOULD take
   measures to avoid rapid and frequent updates of routing information
   that could cause the routing network to become swamped. A threshold
   mechanism MAY be applied such that updates are only flooded when a


Zhang                  Expires September 2009                [Page 11]


Internet-Draft        OSPF Extensions for WSON              March 2009


   number of changes have been made to the wavelength availability
   information within a specific time. Such mechanisms MUST be
   configurable if they are implemented.

5. Security Considerations

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

6. IANA Considerations

   [RFC3630] says that the top level Types in a TE LSA and Types for
   sub-TLVs for each top level Types must be assigned by Expert Review,
   and must be registered with IANA.

   IANA is requested to allocate new Types for the sub-TLVs as defined
   in Sections 2.1, 3.1, and 3.2 as follows:

6.1. Node Information

   This document introduces the following sub-TLV of Node Attribute TLV
   (Value TBD, see [OSPF-Node])

   Type   sub-TLV

   TBD    Connectivity matrix

6.2. Link Information

   This document introduces the following sub-TLV of TE Link TLV (Value
   2)

   Type   sub-TLV

   TBD    WSON Port Wavelength Restrictions

   TBD    Wavelength Availability

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



Zhang                  Expires September 2009                [Page 12]


Internet-Draft        OSPF Extensions for WSON              March 2009


   [RFC3630] Katz, D., Kompella, K., and Yeung, D., "Traffic
             Engineering (TE) Extensions to OSPF Version 2", RFC
             3630, September 2003.

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

   [RFC3945] E. Mannie, Ed., "OGeneralized Multi-Protocol Label Switching (GMPLS)
             Architecture", RFC 3945, October 2004.

   [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
             Computation Element (PCE)-Based Architecture ", RFC 4655,
             August 2006.

   [OSPF-Node] R. Aggarwal and K. Kompella, "Advertising a Router's
               Local Addresses in OSPF TE Extensions", draft-ietf-ospf-
               te-node-addr, work in progress.

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

   [WSON-Frame] G. Bernstein, Y. Lee, W. Imajuku, "Framework for GMPLS
                and PCE Control of Wavelength Switched Optical
                Networks", work in progress: draft-ietf-ccamp-rwa-WSON-
                Framework-00.txt, December 2008.

   [WSON-Info] Y. Lee, G. Bernstein, D. Li, W. Imajuku, "Routing and
               Wavelength Assignment Information Model for Wavelength
               Switched Optical Networks", work in progress: draft-ietf-
               ccamp-rwa-info-01.txt, October 2008.

   [WSON-Encode]                     G. Bernstein, Y. Lee, D. Li, W. Imajuku, "Routing and
                Wavelength Assignment Information Encoding for
                Wavelength Switched Optical Networks", work in progress:
                draft-ietf-ccamp-rwa-wson-encode-00.txt, December 2008.






Zhang                  Expires September 2009                [Page 13]


Internet-Draft        OSPF Extensions for WSON              March 2009


   [WSON-IGP-Eval] Dan Li, J. Gao, Y. Lee, "Evaluation of Possible
                    Interior Gateway Protocol Extensions for Wavelength
                    Switching Optical Networks", work in progress:
                    draft-li-ccamp-wson-igp-eval-01.txt, July 2008.

    [Switch] G. Bernstein, Y. Lee, A. Gavler, J. Martensson, " Modeling
             WDM Wavelength Switching Systems for use in Automated Path
             Computation", http://www.grotto-
             networking.com/wson/ModelingWSONswitchesV2a.pdf , June,
             2008






































Zhang                  Expires September 2009                [Page 14]


Internet-Draft        OSPF Extensions for WSON              March 2009


8. Authors' Addresses


   Fatai Zhang
   Huawei Technologies
   F3-5-B R&D Center, Huawei Base
   Bantian, Longgang District
   Shenzhen 518129 P.R.China

   Phone: +86-755-28972912
   Email: zhangfatai@huawei.com


   Greg Bernstein
   Grotto Networking
   Fremont CA, USA

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


   Young Lee
   Huawei Technologies
   1700 Alma Drive, Suite 100
   Plano, TX 75075
   USA

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


   Dan Li
   Huawei Technologies Co., Ltd.
   F3-5-B R&D Center, Huawei Base,
   Bantian, Longgang District
   Shenzhen 518129 P.R.China

   Phone: +86-755-28973237
   Email: danli@huawei.com


   Jianrui Han
   Huawei Technologies Co., Ltd.
   F3-5-B R&D Center, Huawei Base,
   Bantian, Longgang District
   Shenzhen 518129 P.R.China



Zhang                  Expires September 2009                [Page 15]


Internet-Draft        OSPF Extensions for WSON              March 2009


   Phone: +86-755-28972913
   Email: hanjianrui@huawei.com

Acknowledgment

   TBD.

Intellectual Property

   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.

   The definitive version of an IETF Document is that published by, or
   under the auspices of, the IETF. Versions of IETF Documents that are
   published by third parties, including those that are translated into
   other languages, should not be considered to be definitive versions
   of IETF Documents. The definitive version of these Legal Provisions
   is that published by, or under the auspices of, the IETF. Versions of
   these Legal Provisions that are published by third parties, including
   those that are translated into other languages, should not be
   considered to be definitive versions of these Legal Provisions.

   For the avoidance of doubt, each Contributor to the IETF Standards
   Process licenses each Contribution that he or she makes as part of
   the IETF Standards Process to the IETF Trust pursuant to the
   provisions of RFC 5378. No language to the contrary, or terms,
   conditions or rights that differ from or are inconsistent with the
   rights and licenses granted under RFC 5378, shall have any effect and



Zhang                  Expires September 2009                [Page 16]


Internet-Draft        OSPF Extensions for WSON              March 2009


   shall be null and void, whether published or posted by such
   Contributor, or included with or in such Contribution.


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.


Full Copyright Statement

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






















Zhang                  Expires September 2009                [Page 17]