Internet DRAFT - draft-bernstein-gmpls-optical
draft-bernstein-gmpls-optical
Network Working Group G. Bernstein
Internet Draft Ciena
Expiration Date: May 2001 V. Sharma
Document: draft-bernstein-gmpls-optical-00.txt Tellabs
November 2000
Some Comments on GMPLS and Optical Technologies
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
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.
Abstract
GMPLS [2] is being considered as an extension to the MPLS framework
to include optical, non-packet switched technologies. This draft
reviews the motivation for doing so from an end-userĘs perspective
and points out some key requirements/impacts that this will have on
the extensions to the routing and label distribution/signaling
protocols.
Table of Contents Page
1.0 Introduction
1.1 Specification of Requirements
1.2 Abbreviations
2.0 Motivation for MPLS-based Control
2.1 Multi-vendor Topology/Resource Discovery
2.2 Multi-vendor Connection Control
2.3 Path Computation
3.0 Impacts on MPLS Protocols
3.1 TDM Multiplexing Hierarchies and MPLS Protocols
3.1.1 Implications for Routing
3.1.2 Implications for Label Distribution/Signaling
Bernstein, G. [Page 1]
draft-bernstein-gmpls-optical-00.txt November 2000
3.2 WDM Hierarchies and MPLS Protocols
3.2.1 Implications for Routing
3.2.2 Implications for Label Distribution/Signaling
4.0 Conclusions and Recommendations
5.0 Security Considerations
6.0 References
7.0 Acknowledgements
8.0 AuthorsĘ Addresses
1. Introduction
Multi-Protocol Label Switching (MPLS) has received much attention
recently for use as a control plane for non-packet switched
technologies. In particular, optical technologies have a need to
upgrade their control plane as reviewed in reference [3]. Many
different optical switching and multiplexing technologies exist, and
more are sure to come. For the purposes of this draft we only
consider non-packet (i.e. circuit switching) forms of optical
switching.
The two main forms of optical multiplexing are wavelength division
multiplexing (WDM) and time division multiplexing (TDM). A
considerable amount of standards are in place for the optical TDM
hierarchy known as SONET/SDH. A framework for controlling SDH by
MPLS was presented in [4] and some of the issues concerning SONET
and MPLS were presented in [5].
Along with these multiplex structures, which can be quite rich (i.e.
complicated), come various types and layers of switching capability.
For example, for dealing with WDM multiplexes GMPLS includes the
notions of lambda switching (switching individual WDM signals), wave
band switching (switching of a group of WDM signals that occupy a
contiguous portion of the optical spectrum), and fiber switching
(switching of the entire contents of a fiber).
Before discussing further examples, and implications of this
structure, we review the motivation for an MPLS-based control plane.
We present a big-picture view of multiplexing and then discuss the
implications for routing and signaling.
1.1. Specification of Requirements
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.
1.2 Abbreviations
LSP Label Switched Path (MPLS terminology)
MPLS Multi-Protocol Label Switching
SDH Synchronous Digital Hierarchy
STM(-N) Synchronous Transport Module (-N)
SPE Synchronous Payload Envelope (SONET)
Bernstein, G. [Page 2]
draft-bernstein-gmpls-optical-00.txt November 2000
STS(-N) Synchronous Transport Signal-Level N (SONET)
TU-n Tributary Unit-n (SDH)
TUG(-n) Tributary Unit Group (-n) (SDH)
VC-n Virtual Container-n (SDH)
VTn Virtual Tributary-n (SONET)
2.0. Motivation for MPLS-based Control
At a recent MPLS conference, a speaker took a fair amount of time to
explicitly differentiate the use of optical technology in support of
MPLS, i.e., running MPLS over optical links, versus using MPLS
technology to control optical networks. This is a very important
distinction that sometimes gets blurred. This draft is concerned
with the extension of MPLS for use in controlling non-packet
switching networks in a way that is completely agnostic to the
content flowing through the network, i.e., it makes no assumptions
that the content of the circuits that are setup is IP traffic or any
particular form of traffic. We are explicit about this point since
we are interested in a general purpose control-plane mechanism and
not one that assumes that the contents of the pipes themselves must
be IP or MPLS traffic. As reviewed in the following sections the
main functionalities that we desire from this control plane are
topology/resource discovery and connection control. An area not
needing standardization, and one source of vendor/customer added
value, is the route computation procedure.
2.1. Multi Vendor Topology/Resource Discovery
Optical switching systems currently do not inter-operate in the
areas of topology discovery or resource status. This means that it
is difficult to get a single overall view of the network that can be
used for operations and end-to-end path computation.
Link-state routing protocols, such as IS-IS and OSPF, have been used
for some time in the IP world to compute destination-based next hops
for routes (without routing loops). In non-packet networks, however,
their immense value comes from their ability to provide timely
topology and network status information in a distributed manner,
i.e., at any network node.
2.2. Multi-Vendor Connection Control
Traditionally, end-to-end circuit connections have been set up
via network management systems (NMSs), which issue commands (usually
under the control of a human operator) to the various network
elements involved in the circuit via an equipment vendor's element
management system (EMS). Very little multi-vendor interoperability
has been achieved via management systems. Hence, end-to-end circuits
in a multi-vendor environment typically require the use of multiple
management systems and the infamous configuration via "yellow sticky
notes". A common signaling protocol such as RSVP with TE extensions
Bernstein, G. [Page 3]
draft-bernstein-gmpls-optical-00.txt November 2000
or CR-LDP appropriately extended for circuit switching applications
could help to solve these interoperability problems.
2.3. Path Computation
Although a link-state route protocol can be used to obtain
network topology and resource information, this does not imply the
use of an "open shortest path first" route. The path must be open,
in the sense that the bandwidth must be available, however the
switches along the path must also be capable, in some way, of
transporting the desired signal type, which results in an important
additional constraint, not typically found in packet networks.
Other constraints may include hop count, total delay (mostly
propagation), and link protection type [2],[6]. In addition, it may
be desirable to route traffic in such as way as to optimize overall
network capacity, or reliability, or some combination of the two.
Observe that Dijkstra's algorithm computes the shortest path with
respect to link weights for a single connection at a time. This can
be much different than the paths that would be selected in response
to a request to set up a batch of connections between a set of
endpoints, with the objective of optimizing network link
utilization. One can think along the lines of global or local
optimization of the network. Due to the complexity of some of the
route algorithms (high dimensionality, and non-linear integer
programming problems, for example) and various criteria by which one
may optimize the network, it may not be possible or desirable to run
these algorithms on network nodes. However, it may still be
desirable to have some form of path computation ability running on
the network nodes, particularly in restoration situations, where
quick recovery is required after a fault or failure on the working
path. Such an approach is in line with the use of MPLS for traffic
engineering, but is much different than typical OSPF or IS-IS usage
where all nodes must run the same route computation algorithm.
3.0. Impacts on MPLS Protocols
The special nature of SONET/SDH circuits, therefore, impacts both the
routing and signaling protocols for MPLS, as discussed briefly below.
The information needed to compute paths must be made globally
available throughout the network. Since in MPLS-based networks this
is done via the link state route protocols, any information of this
nature must either be in the existing link state advertisements
(LSAs) or the LSAs must be supplemented to convey this information.
A somewhat more nebulous requirement is that information, such as
link protection type [2],[6] needed for a global view of network
operations should also be distributed via the route protocol,
because they provide a convenient interoperable way to distribute
this information.
Bernstein, G. [Page 4]
draft-bernstein-gmpls-optical-00.txt November 2000
The information needed to completely specify the signal and its
characteristics (which we collectively call the signal type) must be
transferred via the label distribution protocol. This is
particularly important so that the switches along the path can be
configured to correctly handle and switch the signal. Examples from
the TDM and WDM multiplex hierarchies are given below.
3.1. TDM Multiplexing Hierarchies and MPLS Protocols
Before delving into the details of the TDM and WDM hierarchies, it
is important to know why circuit-switched multiplex structures are
complicated relative to packet switched multiplex structures (or at
least why they seem that way when viewed from the packet switched
world, which is the perspective taken here). First, unlike packet
switching, when setting up circuits in the TDM world, we are
dedicating bandwidth for the exclusive use of the two end systems
involved with the connection. Other circuits in the network cannot
share this bandwidth -. To make effective use of circuit-switched
bandwidth, therefore, the different types of signals have been
arranged in multiplexing hierarchies, which include the well known
T1 and E1 hierarchies (typically referred to as PDH for
plesiochronous digital hierarchy), and the SONET/SDH (synchronous
digital hierarchy) hierarchy.
In the PDH hierarchies there are about three to four fundamental
signals, ranging in speed from 64Kbps to 45Mbps. Unfortunately, due
to historical reasons there tend to be a number of different
variations of these fundamental signals. This complicates matters,
since it produces a number of signals with the same bit rate and
same coarse framing. These differences typically have to do with
overhead functionality, some of which can be quite intrusive (e.g.
robbed bit signaling). In the SONET/SDH hierarchy used in TDM
optical networks there are about three levels of multiplexing, with
a variety of signals (3-5) within each level. These signals range in
speed from about 1.5Mbps to 10Gbps.
From this brief description of the common TDM multiplex structures,
one can see that packets in many ways are much easier to deal with.
One thing that can be said for circuits is the fine grained
guaranteed bandwidth that they can provide.
3.1.1. Implications for Routing
Given these different TDM hierarchies, we ask what do we need to
know from routing? It turns out that we actually need two types of
information about a link from the route protocols. The first is
static information, describing the switching capabilities of a link,
while the second is dynamic information, describing the capacity
utilization of the link (which, as we shall see shortly, differs
significantly from how it is typically described for packet
multiplexed links).
3.1.1.1. Static Link Information
Bernstein, G. [Page 5]
draft-bernstein-gmpls-optical-00.txt November 2000
With optical TDM links, we need to know the switching capabilities
supported by the end of a link, i.e., which hierarchy does a link
support and what types of signals within that hierarchy can it
switch. This is of fundamental importance in optical TDM networks,
because, unlike packet multiplexed links, each link now supports a
small, fixed number of discrete signal types. Therefore, the links
that are suitable for carrying a given TDM channel/circuit are only
those that can switch the particular type of signal of which the TDM
channel/circuit is comprised. As more layers of switching get
integrated into a single port this can be a fair amount of
information. This information is relevant within the context of the
TDM hierarchy that is supported. Note that more than one TDM
hierarchy may be supported on an interface.
Note that the static capabilities of a link are not an issue in
packet-based networks, because the types of signals that a packet or
cell multiplexed link can switch are uniform, and because the
bandwidth of those signals can take any value up to a maximum value.
For example, a packet-over-SONET (POS) link terminates the SONET
overhead, and switches the packets within. Thus, it switches only
one type of signal, namely IP packets. Further, there is no
restriction on the bandwidth of the LSPs that it can accommodate.
Thus, the link can switch any packet LSP up to its maximum available
bandwidth, or any combination of packet LSPs whose combined
bandwidth does not exceed its total bandwidth. Thus, there is not
need to separately advertise the switching capability of such links.
3.1.1.2. Dynamic Link Information
In order to compute a path, we also need to know, how much capacity
is available on a particular link.
This is clearly a dynamic parameter, and can get quite involved due
to the packing restrictions imposed by some of the hierarchies.
Since, in circuit switching, bandwidth is dedicated rather than
shared, optimizing of its use is more critical here. This is why
"traffic engineering" is a very old notion in the circuit switched
world. At a minimum, it is necessary for a path computation
algorithm to understand the bandwidth available, in terms of number
of supportable signals at various levels in a hierarchy. In other
words, what must be advertised in routing is not residual or
available bandwidth, but rather the number of connections of each
signal type that the link can support at any given time. This is
because, depending on the TDM hierarchies supported, in optical TDM
networks, a link is capable of switching a certain (fixed) number of
connections of each given signal type. Thus, the available capacity
of a link is best expressed not in terms of bandwidth, but rather in
terms of the number of connections of each given type that it has
available. Unfortunately, in optical TDM networks, "fragmentation"
of bandwidth (like fragmentation of a disk drive) can occur leading
to rather inefficient use of bandwidth. To prevent this, more
detailed signal mapping information may be needed. This issue also
can come up in WDM switching involving lambdas and wavebands.
Bernstein, G. [Page 6]
draft-bernstein-gmpls-optical-00.txt November 2000
Note how much this differs from the statistical notions of bandwidth
being considered for packet switched networks, -where a single
number such as available "equivalent bandwidth" may suffice to
characterize the available resources of a link.
3.1.2 Implications for Label Distribution/Signaling
When dealing with a TDM multiplex hierarchy, the most important
aspect of the connection, besides the end point, is the signal type.
As discussed previously, there may be a number of different types of
signals with the same or similar "bandwidth" measure, not all of
which can be switched by the same link. This is because each of
these signals may require different switching capabilities on the
links. Hence, unlike the packet switched case, where a leaky bucket
based set of bandwidth parameters are used to characterize the
requested flow, no such bandwidth measure is needed in the TDM
multiplex case. Rather, the signal type must be explicitly specified
along with the label request. This is because the signal type is
instrumental in indicating the type of LSP requested, and in
enabling the determination of which available links may carry the
requested LSP.
3.2. WDM Hierarchies and MPLS Protocols
Lambda, waveband, and fiber switching are newer and still developing
technologies with relatively few standards in place compared to the
optical TDM world. Some refer to these forms of switching as pure
optical switching since optical signals are not converted to
electrical signals for the purpose of switching. However, this
definition is not very clear because some optical switches actually
are surrounded by O-E-O (optical electrical optical) converters,
thus looking essentially like an electrical-based switch fabric as
far as its routing properties would be concerned.
In a straightforward application of WDM multiplexing, a digital
signal is modulated onto a specific wavelength of light and then
these separate wavelengths are combined into a single fiber for
transmission. For such a system to be operated correctly regardless
of the length of the fiber or nonlinear effects, these separate
signals cannot appreciably overlap in the frequency (spectral)
domain. In addition, there must be mechanisms available to
demultiplex these signals at the reception point. Technology
dependencies immediately start to kick in at this point, as
explained ahead.
Currently, it is easiest and most economical to require the WDM
signals to occur at regular intervals in the frequency domain.
There are currently a number of international standard or industry
standard spacings for WDM systems. These include 100GHz and 50GHz,
25GHz and 12.5GHz. A signal intended for use with 100GHz spacing
Bernstein, G. [Page 7]
draft-bernstein-gmpls-optical-00.txt November 2000
system will not work with a 50GHz spacing system. Also, the
converse tends to be true for a host of issues beyond the scope of
this text. Hence, for a WDM optical link a fundamental
characteristic that would need to be advertised in the routing
protocol would be the channel spacing (and of course the offset
frequency or lambda).
3.2.1. Implications for Routing
As explained above, when advertising available capacity in the WDM
case, instead of a single bandwidth measure, we typically need to
know exactly which channels are populated. This is so that we can
compute a route from source to destination for this particular
lambda. Note that wavelength converters may be deployed and will
certainly complicate this picture with their spectral conversion
properties. This is also important in wave-band switching, where
very inefficient use of the spectrum can result from switching only
partially filled bands.
3.2.2. Implications for Label Distribution/Signaling
To request the setup of a LSP for either lambda or waveband
switching a key parameter needed to characterize the signal is the
center wavelength (or center frequency) of the light wave to be
established. Equally important is the signalĘs spectral extent or
spectral bandwidth. This is usually the width of the signal in the
frequency domain, where the power spectral density has fallen off to
a given number of decibels (dBs). This information is important in
determining whether the signal is compatible with the grid spacings
(WDM signal intervals) of the possible links over which the signal
could be routed. This measure is completely different from a signal
bit-rate measure (such as the current RSVP bandwidth parameter in
bytes per second). The reason for this is that the spectral
characteristics are dependent on the modulation format. For a
general overview of modulation formats, see reference [7]. For a
discussion of some of the modulation formats currently being used
for optical communications, see reference [8].
4.0 Conclusion and Recommendations
An overview of two different optical circuit switched hierarchies
was given. The implications of using GMPLS as a control plane for
such networks was described and contrasted with current MPLS
concepts for control of packet-switched networks. Since the goal is
to use MPLS to control disparate technologies, it appears that there
is no way to avoid technology-specific routing and label
distribution extensions - to MPLS protocols.
In the description of the WDM hierarchy we focused on only one
aspect of WDM systems, i.e., their spectral properties. Many other
aspects such as dispersion, loss, and nonlinear effects also come
into play and would have to be addressed before optical
interoperability could be achieved. With the rapid advances in
Bernstein, G. [Page 8]
draft-bernstein-gmpls-optical-00.txt November 2000
optical WDM technology it may be best to focus first on the
extensions needed for the optical TDM hierarchy.
Due to the technology-specific extensions required when applying
GMPLS to a specific transport technology, we recommend a clear
delineation between general and technology specific parameters. A
general parameter should have significance across all technologies.
As the examples given showed, bandwidth in MBps is not a valid
parameter for characterizing either a requested WDM or TDM signal.
A similar issue arose with the routing protocol extensions
describing available capacity of a link.
It is our hope that the GMPLS work will follow two general
interwoven efforts. One of these is the general extensions needed
for MPLS to deal with multi-level, non-packet switched networks. The
other is a series of technology specific extensions, developed by
parties interested in a specific technology. One of the key
requirements is that extensions for a specific technology, say
waveband switching WDM, can be updated without impacting the
implementation of a different layer technology e.g., SONET/SDH.
5. Security Considerations
Security considerations are not discussed in this version of the
document.
6. References
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
[2] Peter Ashwood-Smith and Lou Berger, Editors, "Generalized MPLS:
Signaling Functional Description, " Internet Draft, draft-ietf-
mpls-generalized-signaling-01.txt, Work in Progress, November
2000.
[3] G. Bernstein, J. Yates, D. Saha, "IP-Centric Control and
Management of Optical Transport Networks", IEEE Communications
Magazine, October 2000.
[4] E. Mannie, "MPLS for SDH Control", draft-mannie-mpls-sdh-
control-00.txt. Work in progress].
[5] G. Bernstein, "Some Comments on the Use of MPLS Traffic
Engineering for SONET/SDH Path Establishment", Internet Draft,
draft-bernstein-mpls-sonet-00.txt, Work in Progress, February
2000.
[6] B. Mack-Crane, V. Sharma, G. Bernstein, et al, "Enhancements to
GMPLS Signaling for Optical Technologies," Internet Draft, draft-
mack-crane-gmpls-signaling-enhancements-00.txt, Work in Progress,
November 2000.
Bernstein, G. [Page 9]
draft-bernstein-gmpls-optical-00.txt November 2000
[7] Bernard Sklar, Digital Communications: Fundamentals and
Applications, Prentice Hall, 1988.
[8] Rajiv Ramaswami and Kumar N. Sivarajan, Optical Networks: A
Practical Perspective, Morgan Kaufman, 1998.
7. Acknowledgments
8. Author's Addresses
Greg Bernstein Vishal Sharma
Ciena Corporation Tellabs Research Center
10480 Ridgeview Court One Kendall Sq., Bldg. 100 Ste. 121
Cupertino, CA 94014 Cambridge, MA 02139-1562
Phone: (408) 366-4713 Phone: (617) 577-8760
Email: greg@ciena.com Email: Vishal.Sharma@tellabs.com
Bernstein, G. [Page 10]
