Internet Draft
Internet Engineering Task Force
INTERNET-DRAFT
Daniel O. Awduche
Expiration Date: May 2000 UUNET (MCI Worldcom)
Yakov Rekhter
Cisco Systems
John Drake
Fore Systems (Marconi)
Rob Coltun
Siara Systems
November 1999
Multi-Protocol Lambda Switching:
Combining MPLS Traffic Engineering Control With Optical Crossconnects
draft-awduche-mpls-te-optical-01.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 except that the right to
produce derivative works is not granted.
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.
Awduche/Rekhter et al [Page 1]
draft-awduche-mpls-te-optical-01.txt May 2000
Abstract
This document describes an approach to the design of control planes
for optical crossconnects (OXCs), which leverages existing control
plane techniques developed for MPLS Traffic Engineering. The
proposed approach combines recent advances in MPLS traffic
engineering control plane constructs with OXC technology to: (1)
provide a framework for real-time provisioning of optical channels in
automatically switched optical networks, (2) foster the expedited
development and deployment of a new class of versatile OXCs, and (3)
allow the use of uniform semantics for network management and
operations control in hybrid networks consisting of OXCs and label
switching routers (LSRs). The proposed approach is particularly
advantageous for OXCs intended for data-centric optical
internetworking systems. In such environments, it will help to
simplify network administration. This approach also paves the way
for the eventual incorporation of DWDM multiplexing capabilities in
IP routers.
1. Introduction
This document describes an approach to the design of control planes
for optical crossconnects (OXCs), which is based on the Multiprotocol
Label Switching (MPLS) traffic engineering control plane model. In
this approach, the main idea it to leverage recent advances in
control plane technology developed for MPLS traffic engineering (see
[1,2,3,4,8,9,10]). This approach is driven by pragmatic
considerations, as it exploits an existing technology base to foster
rapid development and deployment of a new class versatile OXCs that
address the optical transport needs of the rapidly evolving Internet.
This approach will assist in optical channel layer bandwidth
management, dynamic provisioning of optical channels, and network
survivability through enhanced protection and restoration
capabilities in the optical domain.
As used in this document, an OXC is a path switching element in an
optical transport network that establishes routed paths for optical
channels by locally connecting an optical channel from an input port
(fiber) to an output port (fiber) on the switch element. Additional
characteristics of OXCs, as used in this document, are discussed in
Section 4.1.
The proposed OXC control plane uses the IGP extensions for MPLS
traffic engineering (with additional enhancements) to distribute
relevant optical transport network state information, including
topology state information. This state information is subsequently
Awduche/Rekhter et al [Page 2]
draft-awduche-mpls-te-optical-01.txt May 2000
used by a constraint-based routing system to compute paths for
point-to-point optical channels through the optical transport
network. The proposed OXC control plane also uses an MPLS signaling
protocol (see [3,4]) to instantiate point-to-point optical channels
between access points in the optical transport network.
This document does not specify the details of the extensions and
domain specific adaptations required to map the MPLS traffic
engineering control plane model onto the optical domain. These
aspects will be covered in a number of supplementary documents that
will follow. However, in Section 7 of this memo, we provide a high
level overview of the architectural issues involved in making such
adaptations.
2. Advantages
The advantages of the proposed approach are numerous.
- It offers a framework for optical bandwidth management
and the real-time provisioning of optical channels in
automatically switched optical networks.
- It exploits recent advances in MPLS control plane technology
and also leverages accumulated operational experience with IP
distributed routing control.
- It obviates the need to reinvent a new class of control
protocols for optical transport networks and allows reuse
of software artifacts originally developed for the MPLS
traffic engineering application. Consequently, it fosters
the rapid development and deployment of a new class of
versatile OXCs.
- It facilitates the introduction of control coordination concepts
between data network elements and optical network elements.
- It simplifies network administration in facilities based service
provider networks by providing uniform semantics for network
management and control in both the data and optical domains.
- It paves the way for the eventual introduction of DWDM
multiplexing capabilities on IP routers
- Lastly, it establishes a preliminary framework for the notion
of an optical Internet.
Awduche/Rekhter et al [Page 3]
draft-awduche-mpls-te-optical-01.txt May 2000
3. Background
The growth, performance, and survivability requirements of the
Internet (which is also becoming very mission critical) are mandating
IP-centric networks to be cost effective, survivable, scalable, and
to provide control capabilities that facilitate network performance
optimization. Some of these requirements are being addressed by the
Multiprotocol Label Switching (MPLS) traffic engineering capabilities
under development by the IETF [1,2,3,4].
The underlying optical transport network also needs to be versatile,
reconfigurable, cost effective, and to support a variety of
protection and restoration capabilities due to the rapidly changing
requirements of the Internet.
A result of these trends, therefore, is the evolution of optical
transport networks from simple linear and ring topologies to mesh
topologies. By a mesh (not necessarily fully meshed) topology, we
mean a connected (not necessarily fully connected) network of
arbitrary topology in which the node degree is typically more than
two. In mesh optical networks, optical crossconnects engender
versatility and reconfigurability by performing switching and
rearrangement functions.
Under-scoring the importance of versatile networking capabilities in
the optical domain, a number of standardization organizations and
interoperability forums have initiated work items to study the
requirements and architectures for reconfigurable optical networks.
Refer, for example, to ITU-T recommendation G.872 [5]. This document
defines a functional architecture for an optical transport network
(OTN) that supports the transport of digital client signals. ITU-T
G.872 speaks of an OTN as "a transport network bounded by optical
channel access points"[5]. The ITU-T G.872 OTN architecture is based
on a layered structure, which includes:
(a) an optical channel (OCh) layer network,
(b) an optical multiplex section (OMS) layer network, and
(c) an optical transmission section (OTS) layer network.
The optical channel layer is the most relevant to the discussions in
this document. The optical channel layer network supports end-to-end
networking of optical channel trails between access points. The OCh
layer network provides the following functions: routing, monitoring,
grooming, and protection and restoration of optical channels. In
this situation, programmable Optical crossconnects, with
rearrangeable switch fabrics and relatively smart control planes,
will be critical to the realization of the OCh layer functions,
especially in mesh optical networks. In the data network domain,
Awduche/Rekhter et al [Page 4]
draft-awduche-mpls-te-optical-01.txt May 2000
routing, monitoring, and survivability are crucial functions
performed by the MPLS traffic engineering control plane (see
[1,2,3,4,8,9,10]).
Note: Although we mention the ITU-T recommendation G.872, the OXC
control plane design approach described here is not restricted to
G.872 compliant networks. Instead, it can be applied to any mesh
optical network that uses programmable and reconfigurable OXCs.
Other standards organizations and interoperability forums that are
actively pursuing projects related to dynamically reconfigurable
optical networks include the ANSI T1X1.5 committee, the Optical
Internetworking Forum (OIF), and now by virtue of this memo the IETF.
Recent contributions to ANSI T1X1.5 emphasize the need for automation
of the OCh layer network by using appropriate signaling protocols to
establish optical channels in real time (see [14] and [15]).
The Optical Internetworking Forum (http://www.oiforum.com), an
international organization engaged in the development and promotion
of interoperability agreements for optical internetworking systems,
is also evaluating architectural options related to reconfigurable
optical internetworks. At a technical meeting held in California on
October 19, 1999, the Architecture Working Group of the OIF adopted a
motion to define requirements for signaling protocols that allow
rapid provisioning and efficient restoration in optical
internetworking systems.
In all these cases, the successful realization of the vision of
versatile optical networking depends very much on the synthesis of
appropriate control plane technologies with programmable and
reconfigurable OXCs.
4. OXCs, LSRs, Optical Trails, and Explicit LSPs
Consider a hybrid, IP-centric optical internetworking environment
consisting of both label switching routers (LSRs) and OXCs, where the
OXCs are programmable and support wavelength conversion/translation.
At a level of abstraction, an LSR and an OXC exhibit a number of
isomorphic relations. It is important to enumerate these relations
because they help to expose the reusable software artifacts from the
MPLS traffic engineering control plane model. Architecturally, both
LSRs and OXCs emphasize problem decomposition by decoupling the
control plane from the data plane.
The data plane of an LSR uses the label swapping paradigm to transfer
Awduche/Rekhter et al [Page 5]
draft-awduche-mpls-te-optical-01.txt May 2000
a labeled packet from an input port to an output port (see e.g.,
[6,7]). The data plane of an OXC uses a switching matrix to connect
an optical channel trail from an input port to an output port.
An LSR performs label switching by first establishing a relation
between an tuple and an