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]