[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02 03 04 05 draft-ietf-pce-wson-routing-wavelength

Network Working Group                                            Y. Lee
Internet Draft                                                   Huawei
Intended status: Standard Track                            G. Bernstein
Expires: April 2009                                   Grotto Networking
                                                              T. Takeda
                                                                    NTT
                                                               T. Otani
                                                                   KDDI




                                                       October 27, 2008


     PCEP Requirements and Extensions for WSON Routing and Wavelength
                                Assignment


               draft-lee-pce-wson-routing-wavelength-03.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 April 27, 2009.

Copyright Notice




Lee & Bernstein         Expires April 27, 2009                 [Page 1]


Internet-Draft         PCEP Extension for WSON             October 2008


   Copyright (C) The IETF Trust (2008).

Abstract

   This memo provides application-specific requirements and protocol
   enhancements for the Path Computation Element communication Protocol
   (PCEP) for the support of Wavelength Switched Optical Networks
   (WSON).  Lightpath provisioning in WSONs requires a routing and
   wavelength assignment (RWA) process.  From a path computation
   perspective, wavelength assignment is the process of determining
   which wavelength can be used on each hop of a path and forms an
   additional routing constraint to optical light path computation.
   Different computational architectures for the RWA process are given
   and the PCEP extensions needed to support these architectures are
   defined.





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

Table of Contents


   1. Introduction...................................................3
   2. Background: RWA Computation Architectures......................4
   3. PCECP Requirements.............................................5
      3.1. RWA Computation Options...................................5
      3.2. Same Wavelength Assignment for Primary and backup paths...6
      3.3. Same Wavelength Assignment for Bidirectional LSP..........7
      3.4. Wavelength Assignment in PC Reply.........................7
      3.5. RWA objective functions...................................7
      3.6. Timeliness Characteristics of Lightpath...................8
      3.7. Duration of Lightpath.....................................8
   4. Protocol Extensions for Support of WSON RWA....................8
      4.1. RWA Computation Options...................................8
      4.2. Lightpath Specific Parameter TLV.........................10
      4.3. Objective Functions......................................10
      4.4. Error Indicator..........................................12
      4.5. NO-PATH Indicator........................................12
   5. Manageability Considerations..................................12
      5.1. Control of Function and Policy...........................12


Lee & Bernstein         Expires April 27, 2009                 [Page 2]


Internet-Draft         PCEP Extension for WSON             October 2008


      5.2. Information and Data Models, e.g. MIB module.............13
      5.3. Liveness Detection and Monitoring........................13
      5.4. Verifying Correct Operation..............................13
      5.5. Requirements on Other Protocols and Functional Components13
      5.6. Impact on Network Operation..............................14
   6. Security Considerations.......................................14
   7. IANA Considerations...........................................14
   8. Acknowledgments...............................................14
   9. References....................................................14
      9.1. Normative References.....................................14
      9.2. Informative References...................................15
   Authors' Addresses...............................................16
   Intellectual Property Statement..................................16
   Disclaimer of Validity...........................................17



1. Introduction

   [RFC4655] defines the PCE based Architecture and explains how a Path
   Computation Element (PCE) may compute Label Switched Paths (LSP) in
   Multiprotocol Label Switching Traffic Engineering (MPLS-TE) and
   Generalized MPLS (GMPLS) networks at the request of Path Computation
   Clients (PCCs).  A PCC is shown to be any network component that
   makes such a request and may be for instance an Optical Switching
   Element within a Wavelength Division Multiplexing (WDM) network.  The
   PCE, itself, can be located anywhere within the network, and may be
   within an optical switching element, a Network Management System
   (NMS) or Operational Support System (OSS), or may be an independent
   network server.

   The PCE communications Protocol (PCEP) is the communication protocol
   used between PCC and PCE, and may also be used between cooperating
   PCEs.  [RFC4657] sets out the common protocol requirements for PCEP.
   Additional application-specific requirements for PCEP are deferred to
   separate documents.

   This document provides a set of application-specific PCEP
   requirements and protocol enhancements for support of path
   computation in Wavelength Switched Optical Networks (WSON).  WSON
   refers to WDM based optical networks in which switching is performed
   selectively based on the wavelength of an optical signal.

   The path in WSON is referred to as a lightpath.  A lightpath may span
   multiple fiber links and the path should be assigned a wavelength for
   each link.  A transparent optical network is made up of optical
   devices that can switch but not convert from one wavelength to


Lee & Bernstein         Expires April 27, 2009                 [Page 3]


Internet-Draft         PCEP Extension for WSON             October 2008


   another. In a transparent optical network, a lightpath operates on
   the same wavelength across all fiber links that it traverses. In such
   case, the lightpath is said to satisfy the wavelength-continuity
   constraint. Two lightpaths that share a common fiber link can not be
   assigned the same wavelength.  To do otherwise would result in both
   signals interfering with each other. Note that advanced additional
   multiplexing techniques such as polarization based multiplexing are
   not addressed in this document since the physical layer aspects are
   not currently standardized. Therefore, assigning the proper
   wavelength on a lightpath is an essential requirement in the optical
   path computation process.

   On the other hand, when a switching node has the ability to perform
   wavelength conversion the wavelength-continuity constraint can be
   relaxed, and a lightpath may use different wavelengths on different
   links along its route from origin to destination. It is, however, to
   be noted that wavelength converters may be limited due to their
   relatively high cost, while the number of WDM channels that can be
   supported in a fiber is also limited. As a WSON can be composed of
   network nodes that cannot perform wavelength conversion, nodes with
   limited wavelength conversion, and nodes with full wavelength
   conversion abilities, wavelength assignment is an additional routing
   constraint to be considered in all lightpath computation.

   Optical impairment constraints are not addressed in this document as
   the current scope of the WSON framework [WSON-FRAME] does not include
   them.

   The remainder of this document uses terminology from [RFC4655].



2. Background: RWA Computation Architectures

   The WSON framework [WSON-FRAME] document defines the following RWA
   computation architectures.

   o  Combined RWA --- Both routing and wavelength assignment are
      performed at a single computational entity.  This choice assumes
      that computational entity has sufficient WSON network link/nodal
      and topology information to be able to compute RWA.

   o  Separate Routing and WA --- Separate entities perform routing and
      wavelength assignment.  The path(s) obtained from the routing
      computational entity must be furnished to the entity performing
      wavelength assignment.



Lee & Bernstein         Expires April 27, 2009                 [Page 4]


Internet-Draft         PCEP Extension for WSON             October 2008


   o  Routing with Distributed WA --- Routing is performed at a
      computational entity while wavelength assignment is performed in a
      distributed fashion across the nodes along the path.


   For the Combined RWA architecture, there are two possible computing
   entities: (i) the NE is the computational entity -- in this case,
   there is no separate PCE as the NE assumes PCE function; (ii) a
   separate PCE is the computational entity.  This document is only
   concerned with case (ii). In this case, the PCE should perform both
   routing (R) and wavelength assignment (WA) upon request of the PCC.

   For the Separate Routing and Wavelength architecture, there can be
   two variations:


   o  A separate PCE will perform only wavelength assignment (WA) while
      the NE performs the route calculation based on its local
      knowledge. In this case, the NE should furnish the route list to
      the PCE so that the PCE would be able to assign wavelength to the
      route.

   o  One PCE performs the routing (R) function while another PCE
      performs the Wavelength Assignment (WA) function in a tandem
      fashion.  The fact that two PCEs are involved (one for Routing and
      one for Wavelength Assignment (WA)) could be invisible to the
      original PCC.

   For the Routing with Distributed WA architecture, the PCE is only
   responsible for routing (i.e., path computation), not for exact
   wavelength assignment. The exact assignment of wavelengths would be
   performed at the NEs along the path in a distributed fashion.

3. PCECP Requirements

   This section provides the PCECP requirements to support WSON routing
   and wavelength assignment (RWA) applications.  The requirements
   specified in this section are detailed requirements based on high-
   level specification in [WSON-FRAME].



   3.1. RWA Computation Options

   The following RWA computation options should be conveyed in the PC
   Request:



Lee & Bernstein         Expires April 27, 2009                 [Page 5]


Internet-Draft         PCEP Extension for WSON             October 2008




   o  The request is for both Routing and Wavelength Assignment (R+WA).
      This case may arise when the NE is not capable of either route
      calculation or wavelength assignment at the node level, or when a
      more optimal RWA is desired.

   o  The request is for Routing (R) only.  This case may arise when the
      NE is not capable of route calculation at the node level while
      wavelength assignment is done at the node level in a distributed
      fashion.

   o  The request is for Wavelength Assignment (WA) only.  This case may
      arise when the NE is capable of route calculation at the node
      level (e.g., via an IGP-TE) but with no wavelength information
      is available at the node level, or when two PCEs work in tandem
      with one performing the routing (R) function and another
      wavelength assignment (WA).  In either case, the calculated route
      list at one computing entity should be supplied in the request
      message to the other computing entity where WA is applied.


   The corresponding PC Reply message should include the following
   information:

   o  An indicator that conveys the original request was for (i) Both
      Routing and Wavelength Assignment (R+WA); (ii) Wavelength
      Assignment (WA) only; (iii) Routing (R) only.

   o  The route list for all cases above and the recommended wavelengths
      to be used for the route for cases (i) and (ii).

   o  In the case of failure to find a proper route or wavelengths
      assigned to the route, proper reasons for the failure should be
      conveyed: (i) route not found; (ii) wavelength not found (i.e.,
      wavelength blocking); (iii) both route and wavelength not found.



   3.2. Same Wavelength Assignment for Primary and backup paths

   The PC Request should indicate if the same wavelength assignment for
   the primary and backup paths is required or not.

   o  Same wavelength required

   o  Different wavelength required


Lee & Bernstein         Expires April 27, 2009                 [Page 6]


Internet-Draft         PCEP Extension for WSON             October 2008




   3.3. Same Wavelength Assignment for Bidirectional LSP

   When Bidirectional LSP is requested in the PC Request Message, a
   further indication should be made if the same wavelength should be
   assigned in both directions in each hop. Note that assigning
   different wavelengths for the two directions is assumed as default.

   o  Same wavelengths required

   o  Different wavelengths permitted



   3.4. Wavelength Assignment in PC Reply

   If the original request is either for both Routing and Wavelength
   Assignment (R+WA) or for Wavelength Assignment (WA) only, the exact
   wavelength assignment result should be conveyed to the PCC using the
   ERO object and ERO Label subobject within the ERO. Note that this
   requirement is fulfilled by the Label Set mechanism in [RFC3471].



   3.5. RWA objective functions

   Analogous to [PCE-OF], the RWA computation should support a number of
   objective functions in the PC Request Message. The following RWA
   objective functions should be supported at a minimum:

       o  For a sequential request (i.e., one request):

            . TBD

       o  For a concurrent request (i.e., multi-commodity flows):

            . Minimize the total number of link-wavelength used

            . Minimize the maximum link-wavelength used (load balance)

            . Minimize the path length of all flows

   The PCRep should indicate which objective function has actually been
   applied.




Lee & Bernstein         Expires April 27, 2009                 [Page 7]


Internet-Draft         PCEP Extension for WSON             October 2008


   3.6. Timeliness Characteristics of Lightpath

   The request MAY indicate the specific timeliness of the computation
   request for a lightpath. This will likely be related to the use to
   which the lightpath will be put:

   o  Time Critical: this type of request is useful for those lightpath
      establishment requests used for restoration of service or other
      high priority real time services.

   o  Soft Time Bounds: this type of request is a more typical new
      connection request.  While expected to be responsive, there should
      be more time to take into account network optimization.

   o  Scheduled: this type of request is useful when the requested
      lightpath connections are not time critical (i.e., the request is
      significantly ahead of their intended "in-service" time.  It is to
      be noted that we will not explicitly deal with scheduled case in
      this document but the optimization can be handled via [PCE-GCO].

   The reply should indicate the original timeliness characteristics of
   the lightpath request with path computation results.



   3.7. Duration of Lightpath

   The request MAY indicate specific lightpath duration information
   associated with the request. This may be useful to the PCE since it
   is not worthwhile to optimize lightpaths with relatively short
   duration as compared to pseudo-static paths.




4. Protocol Extensions for Support of WSON RWA

   This section describes PCEP extension necessary to meet the
   requirements set out in the previous section.

   4.1. RWA Computation Options

   The PCC has to include the RWA computation option in the PCReq
   message in order to convey a particular computation option.  To
   support such indication a new flag, the RWA Computation (RC) flag, is
   defined in the RP (Request Parameter) Object.


Lee & Bernstein         Expires April 27, 2009                 [Page 8]


Internet-Draft         PCEP Extension for WSON             October 2008



   The RC flag is defined in the Flags field of the RP (Request
   Parameter) object as follows. Bit number assignment to be confirmed
   by IANA (see Section 8).

      Bit     Name    Description                          Reference

   10-11   RC-bits Routing Wavelength Computation       This document


   RC bits (Routing wavelength Computation bits - 2 bits):

   o  11: Request is for both R (Routing) and Wavelength Assignment
      (WA).

   o  01: Request is for Wavelength Assignment (WA) only.

   o  10: Request is for Routing (R) only.

   When the RC bits are set to 11 in a PCReq message, the requesting PCC
   requires the PCE to provide in the PCRep message the assigned
   wavelength associated with the computed path.  This request is for
   both Routing (R) and Wavelength Assignment (WA).

   When the RC bits are set to 01 in a PCReq message, the requesting PCC
   requires the PCE only to provide wavelength assignment (WA).  In such
   case, the PCC must provide the already computed route (as indicated
   by the ERO and the Bandwidth Object following the RP object) to which
   the PCE would assign the wavelengths.  Note that this option is to
   fulfill one of the RWA computational architectures, namely, the
   Separate Routing and WA option.

   When the RC bits are set to 11 or 01, then additional parameters
   associated with the requested lightpath SHOULD be provided in
   optional Lightpath Specific Parameter TLV (as specified in Section
   3.4) within the RP object. See Section 4.2 for the encoding of
   Lightpath Specific Parameter TLV.

   The RP object in the PCRep message SHOULD properly indicate the
   original request for the RWA Computation (RC) bit that has actually
   been applied by the PCE. The actual route list and wavelength
   assignment is to be found in the ERO within ERO Label subobjects. ERO
   Label subobjects can be used to indicate the wavelength to be used on
   particular links. Note that GMPLS signaling [RFC3473] supports an
   explicit route object (ERO) and with ERO Label subobjects.




Lee & Bernstein         Expires April 27, 2009                 [Page 9]


Internet-Draft         PCEP Extension for WSON             October 2008




   4.2. Lightpath Specific Parameter TLV

   When the RC bit is set to 11 or 01 and the B bit is set to 1 (which
   indicates a bi-directional LSP request) in the RP object in a PCReq
   message, then the following Lightpath Specific Parameter TLV SHOULD
   be included as part of the RP object within the PCReq message.

   The format of the Lightpath Specific Parameter TLV is 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Type              |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |S|                                                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Type     To be defined by IANA (suggested value = x)
              Length   2 bits
              Value    S bit: 0 or 1


   Figure 1    The Lightpath Specific Parameter TLV in the RP object in
                             the PCReq Message



   S bit (Same Wavelength to both directions - 1 bit):

   o  0: Request is for the assignment of the same wavelength to
      upstream and downstream directions.

   o  1: Request is for the assignment of the different wavelength to
      upstream and downstream directions.




   4.3. Objective Functions

   When the RC (RWA Computation) flags in the RP object of a PCReq
   indicate computing wavelength assignment, then the following


Lee & Bernstein         Expires April 27, 2009                [Page 10]


Internet-Draft         PCEP Extension for WSON             October 2008


   Objective Function TLV SHOULD be included in the RP object as an
   optional TLV.

   The format of the Wavelength Selection Preference TLV is 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Type              |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Objective Function                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Type     To be defined by IANA (suggested value = x)
              Length   32 bits
              Value    Objective Function

   Figure 2    The Objective Function TLV in the RP object in the PCReq
                                  Message


   Three objective functions are defined in this document and their
   identifier should be assigned by IANA (suggested value)

      Function
      Code           Description
      --------       ------------
      1              Minimize the total number of link-wavelength used


      2              Minimize the maximum link-wavelength used (load
   balance)
      3              Minimize the path length of all flows













Lee & Bernstein         Expires April 27, 2009                [Page 11]


Internet-Draft         PCEP Extension for WSON             October 2008



   4.4. Error Indicator

   To indicate errors associated with the RWA request, a new Error-Type
   (15) and subsequent error-values are defined as follows for inclusion
   in the PCEP-ERROR object.

   If a PCE receives a RWA computation request and the PCE is not
   capable of RWA, the PCE MUST send a PCErr message with a PCEP ERROR
   object (Error-Type=15) and an Error-Value (Error-Value=1).  The
   corresponding RWA computation request MUST be cancelled.

   To indicate an error associated with policy violation, a new error
   value "RWA not allowed" is added to the existing error code for
   policy violation (Error-Type=6) as defined in [PCEP].

   If a PCE receives a RWA computation request which is not compliant
   with administrative privileges (i.e., the PCE policy does not support
   RWA), the PCE MUST send a PCErr message with a PCEP-ERROR Object
   (Error-Type=6) and an Error-Value (Error-Value=3).  The corresponding
   RWA computation MUST be cancelled.

   4.5. NO-PATH Indicator

   To communicate the reason(s) for not being able to find RWA
   computation, the NO-PATH object MAY be used in the PCRep message. The
   NO-PATH object is defined in [PCEP].

   As defined in [PCEP], the NO-PATH object carries the NO-PATH_VECTOR
   TLV which has a flags field. One new bit flag is defined in this
   document to indicate RWA-specific computation failures as follows:

   0x10: when set, the PCE indicates that no wavelength was found
   associated with RWA computation in the PCRep message.



5. Manageability Considerations

   Manageability of WSON Routing and Wavelength Assignment (RWA) with
   PCE must address the following considerations:

   5.1. Control of Function and Policy

   In addition to the parameters already listed in Section 8.1 of
   [PCEP], a PCEP implementation SHOULD allow configuring the following
   PCEP session parameters on a PCC:


Lee & Bernstein         Expires April 27, 2009                [Page 12]


Internet-Draft         PCEP Extension for WSON             October 2008


   o  The ability to send a WSON RWA request.

   In addition to the parameters already listed in Section 8.1 of
   [PCEP], a PCEP implementation SHOULD allow configuring the following
   PCEP session parameters on a PCE:

   o  The support for WSON RWA.

   o  The maximum number of synchronized path requests associated with
      WSON RWA per request message.

   o  A set of WSON RWA specific policies (authorized sender, request
      rate limiter, etc).


   These parameters may be configured as default parameters for any PCEP
   session the PCEP speaker participates in, or may apply to a specific
   session with a given PCEP peer or a specific group of sessions with a
   specific group of PCEP peers.


   5.2. Information and Data Models, e.g. MIB module

   Extensions to the PCEP MIB module defined in [PCEP-MIB] should be
   defined, so as to cover the WSON RWA information introduced in this
   document. A future revision of this document will list the
   information that should be added to the MIB module.

   5.3. Liveness Detection and Monitoring

   Mechanisms defined in this document do not imply any new liveness
   detection and monitoring requirements in addition to those already
   listed in section 8.3 of [PCEP].


   5.4. Verifying Correct Operation

   Mechanisms defined in this document do not imply any new verification
   requirements in addition to those already listed in section 8.4 of
   [PCEP]


   5.5. Requirements on Other Protocols and Functional Components

   The PCE Discovery mechanisms ([ISIS PCED] and [OSPF PCED]) may be
   used to advertise WSON RWA path computation capabilities to PCCs.



Lee & Bernstein         Expires April 27, 2009                [Page 13]


Internet-Draft         PCEP Extension for WSON             October 2008



   5.6. Impact on Network Operation

   Mechanisms defined in this document do not imply any new network
   operation requirements in addition to those already listed in section
   8.6 of [PCEP].



6. Security Considerations

   This document has no requirement for a change to the security models
   within PCEP [PCEP]. However 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.



7. IANA Considerations

   A future revision of this document will present requests to IANA for
   codepoint allocation.



8. Acknowledgments

   The authors would like to thank Adrian Farrel for many helpful
   comments that greatly improved the contents of this draft.

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



9. References

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




Lee & Bernstein         Expires April 27, 2009                [Page 14]


Internet-Draft         PCEP Extension for WSON             October 2008


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

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

   [RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE)
             Communication Protocol Generic Requirements", RFC 4657,
             September 2006.

   [PCEP]    Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
             Element (PCE) communication Protocol (PCEP) - Version 1",
             draft-ietf-pce-pcep, work in progress.



   9.2. Informative References

   [PCE-OF]  Le Roux, JL., Vasseur, JP., and Y. Lee, "Objective Function
             encoding in Path Computation Element communication and
             discovery protocols", draft-ietf-pce-pce-of, work in
             progress.

   [PCE-GCO] Y. Lee, J.L. Le Roux, D. King, and E. Oki, "Path
             Computation Element Communication Protocol (PCECP)
             Requirements and Protocol Extensions In Support of Global
             Concurrent Optimization", draft-ietf-pce-global-concurrent-
             optimization, work in progress.

   [WSON-FRAME] Bernstein, G. and Lee, Y. (Editors), and W. Imajuku,
             "Framework for GMPLS and PCE Control of Wavelength Switched
             Optical Networks", draft-bernstein-ccamp-wavelength-
             switched, work in progress.

   [ISIS-PCED] Le Roux, J. and JP. Vasseur, "IS-IS protocol extensions
             for Path Computation Element (PCE) Discovery", draft-ietf-
             pce-disco-proto-isis, work in progress.

   [OSPF-PCED] Le Roux, J. and JP. Vasseur, "OSPF protocol extensions
             for Path Computation Element (PCE) Discovery", draft-ietf-
             pce-disco-proto-ospf, work in progress.






Lee & Bernstein         Expires April 27, 2009                [Page 15]


Internet-Draft         PCEP Extension for WSON             October 2008


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 Bernstein (Ed.)
   Grotto Networking
   Fremont, CA, USA
   Phone: (510) 573-2237
   Email: gregb@grotto-networking.com


   Tomonori Takeda
   NTT Corporation
   3-9-11, Midori-Cho
   Musashino-Shi, Tokyo 180-8585, Japan
   Email: takeda.tomonori@lab.ntt.co.jp



   Tomohiro Otani
   KDDI R&D Laboratories, Inc.
   2-1-15 Ohara Kamifukuoka Saitama, 356-8502. Japan
   Phone:  +81-49-278-7357
   Email:  otani@kddilabs.jp

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



Lee & Bernstein         Expires April 27, 2009                [Page 16]


Internet-Draft         PCEP Extension for WSON             October 2008


   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.

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.


















Lee & Bernstein         Expires April 27, 2009                [Page 17]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/