Network Working Group Y. Lee Internet Draft Huawei Intended status: Standard Track Expires: December 2008 G. Bernstein Grotto Networking June 27, 2008 PCEP Requirements and Extensions for WSON Routing and Wavelength Assignment draft-lee-pce-wson-routing-wavelength-02.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on December 27, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract This memo provides application-specific requirements and protocol enhancements for the Path Computation Element communication Protocol Lee & Bernstein Expires December 27, 2008 [Page 1] Internet-Draft PCEP Extension for WSON June 2008 (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..........6 3.4. Wavelength Assignment in PC Reply.........................7 3.5. RWA objective functions...................................7 4. Protocol Extensions for Support of WSON RWA....................7 4.1. RWA Computation Options...................................8 4.2. Lightpath Specific Parameter TLV..........................9 4.3. Objective Functions......................................10 4.4. Error Indicator..........................................11 4.5. NO-PATH Indicator........................................11 5. Manageability Considerations..................................11 5.1. Control of Function and Policy...........................12 5.2. Information and Data Models, e.g. MIB module.............12 5.3. Liveness Detection and Monitoring........................12 5.4. Verifying Correct Operation..............................12 5.5. Requirements on Other Protocols and Functional Components13 5.6. Impact on Network Operation..............................13 6. Security Considerations.......................................13 7. IANA Considerations...........................................13 8. Acknowledgments...............................................13 Lee & Bernstein Expires December 27, 2008 [Page 2] Internet-Draft PCEP Extension for WSON June 2008 9. References....................................................14 9.1. Normative References.....................................14 9.2. Informative References...................................14 Authors' Addresses...............................................15 Intellectual Property Statement..................................15 Disclaimer of Validity...........................................16 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 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 Lee & Bernstein Expires December 27, 2008 [Page 3] Internet-Draft PCEP Extension for WSON June 2008 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. 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 Lee & Bernstein Expires December 27, 2008 [Page 4] Internet-Draft PCEP Extension for WSON June 2008 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: 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. Lee & Bernstein Expires December 27, 2008 [Page 5] Internet-Draft PCEP Extension for WSON June 2008 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 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 Lee & Bernstein Expires December 27, 2008 [Page 6] Internet-Draft PCEP Extension for WSON June 2008 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. 4. Protocol Extensions for Support of WSON RWA This section describes PCEP extension necessary to meet the requirements set out in the previous section. Lee & Bernstein Expires December 27, 2008 [Page 7] Internet-Draft PCEP Extension for WSON June 2008 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. 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. Lee & Bernstein Expires December 27, 2008 [Page 8] Internet-Draft PCEP Extension for WSON June 2008 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. 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. Lee & Bernstein Expires December 27, 2008 [Page 9] Internet-Draft PCEP Extension for WSON June 2008 4.3. Objective Functions When the RC (RWA Computation) flags in the RP object of a PCReq indicate computing wavelength assignment, then the following 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 December 27, 2008 [Page 10] Internet-Draft PCEP Extension for WSON June 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: Lee & Bernstein Expires December 27, 2008 [Page 11] Internet-Draft PCEP Extension for WSON June 2008 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: 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] Lee & Bernstein Expires December 27, 2008 [Page 12] Internet-Draft PCEP Extension for WSON June 2008 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. 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. Lee & Bernstein Expires December 27, 2008 [Page 13] Internet-Draft PCEP Extension for WSON June 2008 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. [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. Lee & Bernstein Expires December 27, 2008 [Page 14] Internet-Draft PCEP Extension for WSON June 2008 [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. 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 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. Lee & Bernstein Expires December 27, 2008 [Page 15] Internet-Draft PCEP Extension for WSON June 2008 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 December 27, 2008 [Page 16]