Network Working Group D. Shimazaki Internet Draft R. Hayashi Intended status: Standards Track K. Shiomoto Expires: January 4, 2012 NTT Corporation July 3, 2011 Requirement and protocol for WSON and non-WSON interoperability draft-shimazaki-ccamp-wson-interoperability-00.txt Abstract GMPLS protocol enabled network operator to setup optical path network rapidly and dynamically. Recently, WSON [8] is standardized to achieve WDM core network. However, it is difficult that all network equipment supports WSON protocol. Therefore, interoperability between WSON and non-WSON nodes is needed to construct path network. This document describes requirement for interoperability between WSON node and non-WSON nodes and functions that routing and signaling protocol should support. 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 December, 2011. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. Shimazaki, et al. [Page 1] Internet-Draft WSON and non-WSON interoperability June 2011 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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 RFC2119. Shimazaki, et al. [Page 2] Internet-Draft WSON and non-WSON interoperability June 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Requirements for non-WSON nodes . . . . . . . . . . . . . . . 4 2.2. Requirements for WSON nodes . . . . . . . . . . . . . . . . . 5 3. Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. OSPF-TE . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. RSVP-TE . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.3. PCE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Path setup scenario . . . . . . . . . . . . . . . . . . . . . 6 5. Security considerations . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 8 Shimazaki, et al. [Page 3] Internet-Draft WSON and non-WSON interoperability June 2011 1. Introduction This document proposes interoperability mechanism between non-WSON nodes and WSON nodes. GMPLS [1] defines routing and signaling protocol extension to control multilayer network. [2] describes GMPLS extended OSPF. [2] added four sub-TLVs to Link TLV that is defined in OSPF-TE [3]. [4] describes GMPLS extended RSVP-TE. [4] added new object to RSVP-TE [5]. [6] defines PCE basic architecture. It defines path computation entity separated from network element for traffic engineering. WSON network consists of WDM link, tunable transmitter receiver, ROADM, wavelength converter, and electro-optical network elements. [8] defines control framework of these components with GMPLS and PCE protocol. WSON protocol extension is extension to GMPLS protocols [2], [5]. For example, WSON extended OSPF draft mentions that wavelength Availability information is added to Link TLV of GMPLS extended OSPF-TE, as well as GMPLS extended OSPF added four sub-TLVs to Link TLV of OSPF-TE [3]. The Wavelength Switched Optical Network (WSON), referring to Wavelength Division Multiplexing (WDM) based optical network in which switching is performed selectively based on the wavelength of an optical signal, is a promising optical network in that it provides broadband and energy-saving transmission. Recently, WSON-supported ROADMs and OXCs appear and interoperating experiments have been demonstrated. On the other hand, there are few commercially- available routers working in WSON. This document describes requirement for interoperability between WSON and non-WSON nodes and functions that routing and signaling protocol should support. Under the proposed operation, non-WSON nodes (ex. routers sending/receiving electrical signal) do not send GMPLS protocol messages related to WSON, while necessary message objects are exchanged and relayed among WSON nodes (ex. ROADMs and OXCs). 2. Requirements 2.1. Requirements for non-WSON nodes Non-WSON nodes need to have no impact on interoperating WSON nodes. Detail is described in below. When non-WSON node receives routing protocol information that includes WSON extended information, the node should ignore the WSON Shimazaki, et al. [Page 4] Internet-Draft WSON and non-WSON interoperability June 2011 extended information and understand the conventional GMPLS information and add this information to traffic engineering database (TED). It must transfer routing information to neighbor node. Non-WSON node should combine two TEDs, WSON and non-WSON and make one TED. Non-WSON node can calculate the path route under the whole network topology including WSON network. In WSON network, both route and wavelength should be determined. However, non-WSON node does not have wavelength information in the TED, so it calculates only route without considering available wavelength information. Non-WSON node can send signaling message to next hop node and setup path strictly or loosely. When non-WSON node receive path request message of signaling protocol with WSON information in explicit route object, such as lambda label, the node should cancel the signaling and send path error message to source node. In the other hand, it receives path request message with WSON information in record route object, the node can ignore the incomprehensible information and continue path setup procedure. 2.2. Requirements for WSON nodes WSON nodes need to handle not only WSON-extended information but also no WSON information. WSON nodes at the border of WSON need to compute available wavelength along the assigned path by non-WSON nodes, or compute both a route and available wavelength at the same time if non-WSON nodes doesn't assign a route in WSON strictly or there are no available wavelength along the assigned route by non- WSON nodes. WSON nodes at the border of WSON need to add WSON-extended objects to a signalling protocol messages after receiving them from non-WSON nodes. WSON nodes at the border of WSON need to take WSON-extended objects from a signalling protocol before relaying them to non-WSON nodes. Note that this function is optional if non-WSON nodes neglect WSON-extended information in a signalling protocol received. 3. Protocols 3.1. OSPF-TE Non-WSON nodes ignore available lambda information. When LSA include both lambda and other information, for example adjacency or SC information in Link-TLV, it is desirable that non-WSON nodes ignore only lambda information. ROADMs/OXCs advertise and share available lambda information. Shimazaki, et al. [Page 5] Internet-Draft WSON and non-WSON interoperability June 2011 3.2. RSVP-TE Non-WSON nodes send RSVP-TE PATH message including just route information. WSON nodes add lambda information to be used in WSON to RSVP-TE PATH message. Additionally, it is desirable that OXC at the egress border delete lambda information from PATH message. 3.3. PCE There are several computation models in terms of "who computes what". non-WSON nodes calculate just path route. In WSON area, WSON nodes or PCE calculate wavelength selection or RWA problem. +-------------------+------------------------------------+ | What | Who | +-------------------+------------------------------------+ | Path route | non-WSON nodes | | Wavelength or RWA | Nodes at the border of WSON or PCE | +-------------------+------------------------------------+ Table 1: Function deployment model 4. Path setup scenario Under the proposed path set-up control, a source non-WSON nodes compute a path route with constraint shortest path fast (CSPF). A border node of WSON computes an available wavelength and, if necessary, a route. Then, the border node adds wavelength information, which is used in WSON, to signaling message. The other border node of WSON takes the wavelength information from the signaling message and sends it to a node outside WSON. One of recommended GMPLS RSVP-TE signaling scenarios is described as follows based on Fig.1, in which non-WSON nodes don't support WSON and are outside WSON, while ROADMs are in WSON. Firstly, a source non-WSON node R1 sends RSVP-TE signaling by assigning only R2 loosely as a path route and switching type as Label Switching Capable (LSC). Here, R1 is assumed to understand a topology in LSC region including all of the non-WSON nodes and ROADMs with OSPF-TE. When a ROADM O1 receives the signaling message from R1, it sends path computation request to PCE with the route information which R1 calculates to select the wavelength in WSON. When a PCE receives the path computation request, its routing and wavelength assignment (RWA) algorithm computes one of available wavelengths along the route O1-O2 which R1 calculates. If there is no available wavelength, the PCE's RWA algorithm computes both a route and one of available wavelengths. After calculation, PCE replies the route and wavelength to O1. When Shimazaki, et al. [Page 6] Internet-Draft WSON and non-WSON interoperability June 2011 O1 receives route wavelength reply message from PCE, then sends the signaling which assigns explicit route object (ERO) and wavelength label to the next node. +----+ |PCE | +----+ | +----+ +----+ +----+ +----+ | R1 | -------| O1 | ----| O2 | ------- | R2 | +----+ +----+ +----+ +----+ | | +----+ +----+ +----+ +----+ | R4 | -------| O4 | ----| O3 | ------- | R3 | +----+ +----+ +----+ +----+ |____| |___________________| |____| non-WSON WSON non-WSON Figure 1 WSON including ROADMs and non-WSON including routers 5. Security considerations This document does not require changes to the security models within GMPLS and associated protocols. That is, the OSPF-TE, RSVP-TE, and PCEP security models could be operated unchanged. 6. IANA Considerations TBD. Once finalized in our approach we will need identifiers for such things and modulation types, modulation parameters, wavelength assignment methods, etc... 7. Acknowledgments Anyone who provide comments and helpful inputs. 8. References [1] Mannie, E., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004. [2] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, Shimazaki, et al. [Page 7] Internet-Draft WSON and non-WSON interoperability June 2011 October 2005. [3] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003. [4] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. [5] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [6] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006. [7] Vasseur, JP. and JL. Le Roux, "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009. [8] Lee, Y., Bernstein, G., and W. Imajuku, "Framework for GMPLS and Path Computation Element (PCE) Control of Wavelength Switched Optical Networks (WSONs)", RFC 6163, April 2011. [9] Otani, T. and D. Li, "Generalized Labels for Lambda-Switch- Capable (LSC) Label Switching Routers", RFC 6205, March 2011. [10] Lee, Y., Casellas, R., Margaria, C., and O. Dios, "PCEP Extension for WSON Routing and Wavelength Assignment", draft-lee-pce-wson-rwa-ext-01 (work in progress), March 2011. [11] Zhang, F., Lee, Y., Han, J., Bernstein, G., Xu, Y., Zhang, G., Li, D., Chen, M., and Y. Ye, "OSPF Extensions in Support of Routing and Wavelength Assignment (RWA) in Wavelength Switched Optical Networks (WSONs)", draft-zhang-ccamp-rwa-wson-routing-ospf-03 (work in progress), March 2010. [12] Bernstein, G., Lee, Y., Li, D., and W. Imajuku, "General Network Element Constraint Encoding for GMPLS Controlled Networks", draft-ietf-ccamp-general-constraint-encode-05 (work in progress), May 2011. [13] Katz, D., "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 9999, September 2003. Shimazaki, et al. [Page 8] Internet-Draft WSON and non-WSON interoperability June 2011 Authors' Addresses Shimazaki Daisaku NTT Corporation 3-9-11, Midori-Cho Musashino-Shi, Tokyo 180-8585 Japan Phone: +81 422 59 7443 Email: shimazaki.daisaku@lab.ntt.co.jp Hayashi Rie NTT Corporation 3-9-11, Midori-Cho Musashino-Shi, Tokyo 180-8585 Japan Phone: +81 422 59 3180 Email: hayashi.rie@lab.ntt.co.jp Shiomoto Kohei NTT Corporation 3-9-11, Midori-Cho Musashino-Shi, Tokyo 180-8585 Japan Phone: +81 422 59 4402 Email: shiomoto.kohei@lab.ntt.co.jp Shimazaki, et al. [Page 9]