Network Working Group Greg Bernstein
Internet Draft Ciena Networks
Expiration Date: August 2000
Some Comments on the Use of MPLS Traffic Engineering for
SONET/SDH Path Establishment
draft-bernstein-mpls-sonet-00.txt
1. Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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.
2. Abstract
In [Awduche] the MPLS Traffic Engineering control plane was applied
to the creation of light paths (optical circuits). Due to the general
hierarchical capabilities of MPLS, and the flexibility of the label
switching paradigm the same techniques used to apply the MPLS control
plane to the optical layer can be used to apply it to the SONET/SDH
path layer and in fact any form of circuit switching. This note
discusses advantages of such an approach and some of the issues
involved in its application.
3. Introduction
In [Awduche] the MPLS Traffic Engineering control plane was applied
to the creation of light paths (optical circuits). This initial work
along with the formation of a new optical signaling working group at
the Optical Internetworking Forum (OIF), and a new industry
coalition, the Optical Domain Service Interconnect(ODSI)has very much
underscored the desire to automate the control of optical networks.
Due to the hierarchical capabilities of MPLS and the flexibility of
the MPLS paradigm, MPLS techniques can be applied to the general
problem of control of hierarchical circuit switched networks. Given
the number of recent internet drafts concerning the optical domain
[Kompella, Wang, Fan, Krishna] the comments here will be
concentrated on time division multiplexed hierarchies. Before
focusing on some SONET specific issues (note that [Mannie] gives a
good overview of the SDH specific issues) we review some of the
problems to be solved.
3.1 Transport Network Issues
3.1.1 Multi Vendor Topology/Resource Discovery
Although modern transport networks based on SONET/SDH excel at
interoperability in the performance monitoring (PM) and fault
management (FM) areas, they do not inter-operate in the areas of
topology discovery or resource status. Although link state route
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). Their value in providing timely topology and
network status information in a distributed manner, i.e., at any
network node, is immense. If resource utilization information is
disseminated along with the link status (as was done in ATM's PNNI
routing protocol) then a very complete picture of network status is
available to a network operator for use in planning, provisioning and
operations. Note that in the circuit switch domain bandwidth
utilization and connection admission control is much simplified over
similar concepts in the packet switching world.
Other items of interest for circuit based network control include
switching capabilities of the nodes (granularity, signal types,
etc.), protection properties of the links (linear 1+1, linear 1:N,
ring), failure risk of the links (which links have a tendency to fail
at the same time - ). At this point the main difference in this
application of link state routing versus that for IP is that no
routes have actually be calculated.
3.1.2 Multi Vendor Connection Control
Traditionally end-to-end circuit connections have been set up via an
equipment vendor's element management system (EMS). Only limited
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 or CR-LDP appropriately extended for circuit
switching applications can solve this interoperability problem.
3.1.3 Customer/Edge Connection Control
This is the case where the edge device, by desire, does not fully
participate in the routing protocol, i.e., does not receive or share
topology information with the rest of the network. Such a device
would typically be discovered/register through a separate protocol
from the routing protocol. The edge device would then typically use
a signaling protocol similar to that used in the network to request
services associated with circuits (setup, clear, query). Note that
the multiplex hierarchy used in TDM networks generally alleviates the
scaling issues that could otherwise be troublesome, i.e., a core
SONET switch with OC-192 trunks will not be dealing with signals of
DS0 or DS1 granularity. Defining some these protocols is the type of
work of initial interest at both ODSI and the OIF's signaling working
group.
3.1.4 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, i.e., we've got an additional constraint. Other
constraints may include hop count, total delay (mostly propagation),
and hop count. In addition, in addition it may be desirable to route
traffic in order to optimize overall network capacity, reliability or
some combination of the two. Dikstra'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 in order to optimize network link
utilization. One can think along the line of global or local
optimization of the network. Due to the complexity of some of the
route algorithms (high dimensionality non-linear integer programming
problems) and various criteria by which one may optimize their
network it may not be possible or desirable to run these algorithms
on network nodes. However, it may still be desirable to have some
basic path computation ability running on the network nodes,
particularly in restoration situations. 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 algorithm.
3.2 Decomposition of the MPLS/Circuit Switching Problem Space
Although those familiar with MPLS may be familiar with its
application in a variety of application areas, e.g., ATM, Frame
Relay, etc. We quickly review its decomposition when applied to the
circuit switching problem space.
(i) Information needed to compute paths must be made globally
available throughout the network. Since this is done via the
link state route protocol 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. For
example, if its desirable to offer different levels of service
in a network based on whether a circuit is routed over SONET
lines are Ring protected vs. not being protected
(differentiation based on reliability). Then the type of
protection on a SONET line would be an important topological
parameter that should be distributed via the link state route
protocol. Other important parameters are described in
[Kompella].
(ii) Information that is only needed between two "adjacent" switches
for the purposes of connection establishment is appropriate for
distribution via one of the label distribution protocols. In
fact this information may form the "virtual" label. For example
in SONET if we are distributing information to switches
concerning an end-to-end STS-1 path traversing a network. It is
critical that adjacent switches agree on the "time slot" used
by this STS-1 (but this information is only of local
significance between the two switches). Hence the time slot
number in this case can be used as a virtual label. Note that
it is virtual in that it is not appended to the payload in
anyway, but it is still a label in the sense that it uniquely
identifies the signal local to the link between the two
switches.
(iii) Information that all switches in the path will need to know
about a connection will also be distributed via the label
distribution protocol. Example of such information can include
bandwidth, priority, and preemption information.
(iv) Information intended only for end systems of the connection.
Some of the payload type information in [Mannie] may fall into
this category.
4. SONET Considerations
SONET/SDH is a a TDM based multiplexing technology that has a number
of standard options that a network user may choose to use. In
addition a number of extensions have been proposed [Jones] or are
beneficial for network operations, e.g., eliminate the need for link
grooming. This draft reviews the SONET multiplex structure, options
and possible extensions with respect to the information that is
required to be shared between MPLS LSRs working at the SONET layer
for the establishment of SONET layer LSPs.
4.1 SONET Structure and Extensions
The fundamental signal in SONET is the STS-1 (about 51 Mbps). This
signal consists of a transport overhead and a Synchronous Payload
Envelope (SPE). The SPE floats within its alloted space within the
SONET frame structure with the pointer bytes (H1, H2 and H3) in the
Line Overhead of the SONET transport overhead pointing to the
begining of the SPE. An STS-N signal is formed from a SONET STS-(N-
1) signal and an STS-1 signal via byte interleaving. The transport
overhead structures are frame aligned prior to interleaving but this
is not required of the SPEs, i.e., there is no special relationship
between the payload envelopes. To transport signals in excess of
about 50Mbps the SPEs can be concatenated, i.e., glued together. In
this case their relationship with respect to each other is fixed in
time and hence this relieves, when possible, and end system of any
inverse multiplexing bonding processes.
Due to the previously describe structure the end points of SONET
connections can be identified by the "time slots" (position) that
they occupy within the interleaved frame structure. In the standard
SONET case we are concerned with which of the M STS-1 paths within an
STS-N signal will be used to transport our data (M <= N, and N = 3,
12, 48, 192,...). The SPEs of these M STS-1s can be concatenated to
form an STS-Mc. The STS-Mc notation is really a short hand way of
describing an STS-M signal whose SPEs have been concatenated.
In BellCore GR-253 [GR-253] section 6.1.2 (requirement R6-3) two
conventions are given for identifying an STS-1 within an STS-N:
- A two-level "STS-3 #, STS-1 #"
- A single-level "1 to N in order of appearance at the input to
the byte-interleaver"
For example STS-1 number 23 within an OC-48 can also be represented
by the tuple (8, 2). We will be using the single-level numbering
scheme in our discussion, but this is not imply an encoding format.
A second complication is in dealing with concatenated signals. In
Bellcore GR-253 section 5.1 the multiplexing procedures for SONET are
given. Constraints are imposed on the size of STS-Mc signals, i.e.,
they must be a multiple of 3, and on their starting location and
interleaving. This has the following advantages: (a) restriction to
multiples of 3 helps with SDH compatibility (there is no STS-1
equivalent signal in STS-1 an STM-1 is equivalent (essentially) to an
STS-3c); (b) the restriction to multiples of 3 reduces the number of
connection types; (c) the restriction on the placement and
interleaving could allow more compact representation of the "label";
The major disadvantage of these restrictions are: (a) Limited
flexibility in bandwidth assignment (somewhat inhibits finer grained
traffic engineering). (b) The lack of flexibility in starting time
slots for STS-Mc signals and in their interleaving (where the rest of
the signal gets put in terms of STS-1 slot numbers) leads to the
requirement for re-grooming (due to bandwidth fragmentation).
4.2 SONET Concatenation Extensions
Due to these disadvantages some SONET framer manufacturers now
support "arbitrary" concatenation, i.e., no restrictions on the size
of an STS-Mc (as long as M <= N) and no constraints on the STS-1
timeslots used to convey it. It is recommended that arbitrary
concatenation be supported in the format for SONET labels. It is also
recommended that the use of arbitrary concatenation or "standard"
concatenation be negotiated as part of the label assignment process
between two SONET LSRs.
Note that arbitrary concatenation as used here is a network service
that is similar in nature to the SONET end system service of higher
order virtual concatenation [Jones],[Mannie]. In one example of
virtual concatenation two end systems supporting this feature could
essentially "inverse multiplex" two STS-1s into a virtual STS-2c for
the efficient transport of 100Mbps Ethernet traffic. The burden in
virtual concatenation is on the end systems while in arbitrary
concatenation it is on the network. In addition arbitrary
concatenation includes arbitrary interleaving which avoids the need
for link regrooming between any pair of nodes supporting this
feature.
4.3 SONET Connection Bundling
Connection Bundling is the process of routing a set of non-
concatenated STS-1s together as a group, i.e., they are all contained
within the same SONET line (or WDM signal) and receive essentially
the same delay and propagation. This simplifies connection
establishment (especially for batches of DS-3s that are being
wholesaled) and speeds re-routes. Such bundling may be important when
establishing STS-1s that will be used between end systems
implementing virtual concatenation. It is recommended that the labels
chosen for SONET paths can incorporate the concept of STS-1 bundling.
Whether it is desirable to bundle larger signals, i.e., groups of
STS-Mc, is for further study.
4.4 SONET Transparency
One last transport technique that bears mentioning since it can be
viewed as a service is that of transparent multiplexing or switching.
The SONET over head is broken into three layers: Section, Line and
Path. All these layers are concerned with fault and performance
monitoring. Section overhead is primarily concerned with framing and
Line overhead is primarily concerned with multiplexing and
protection. To perform multiplexing a SONET network element should be
line terminating. However not all SONET multiplexers/switches perform
SONET pointer adjustments on all the STS-1s contained within them or
if they perform the pointer adjustments they do not terminate the
line overhead. For example a multiplexer may take four SONET STS-48
signals and multiplex them onto an STS-192 without performing
standard line pointer adjustments on the individual STS-1s. This can
be looked at as a service since it may be desirable to pass SONET
signals, like an STS-12 or STS-48, with some level of transparency
through a network and still take advantage of TDM. Transparent
multiplexing and switching can also be viewed as a constraint since
some multiplexers and switches may not switch at as fine a
granularity as others. The levels of transparency and their
representation is for further study.
4.5 SONET Protection
SONET and SDH networks offer a variety of protection options at both
the SONET line and SONET path level. Standardized SONET line level
protection techniques include Linear 1+1 and Linear 1:N automatic
protection switching (APS)[GR-253] and both two fiber and four fiber
bi-directional line switched rings (BLSRs) [GR-1230]. At the path
layer SONET offers uni-directional path switched ring protection.
Both ring and 1:N line protection also allow for "extra traffic" to
be carried over the protection line when it is not being used, i.e.,
not carrying traffic for a failed working line. It may be desirable
to route some connections over lines with protection of a given type,
unprotected lines, or primarily over protection lines as "extra
data". In order to do this the method of protecting a line (if any)
or whether a line is a protection line is useful topology information
that can be disseminated via the link state route protocol. In
addition, a signaling protocol should allow the optional
specification of link protection types as one of the connection
attributes.
5. Summary
This note has discussed some of the advantages of a circuit switching
control plane based on MPLS in terms of the current interoperability
problems that MPLS can help solve. An overview of the application of
MPLS to circuit switching and its decomposition into routing and
label distribution components was presented. And, finally a few of
the subtleties particular to SONET that need to be taken into account
when an MPLS control plane is applied to this application were
detailed.
6. Acknowledgements
The author would like to thank Yakov Rekhter and Jeff Weiss for a
number of enlightening and stimulating discussions that prompted
these notes.
7. References
[Awduche] Awduche, D., Rekhter, Y., Drake, J., Coltun, R., "Multi-
Protocol Lambda Switching: Combining MPLS Traffic Engineering Control
With Optical Crossconnects", draft-awduche-mpls-te-optical-01.txt
[Jones] Jones, N., Murton, C., "Extending PPP over SONET/SDH, with
virtual concatenation, high order and low order payloads", draft-
ietf-pppext-posvcholo-01.txt
[GR-253] Bellcore Generic Requirements, GR-253-CORE, Synchronous
Optical Network (SONET) Transport Systems: Common Generic Criteria,
Issue 2, December 1995.
[Mannie] Mannie, E., "MPLS for SDH control", draft-mannie-mpls-sdh-
control-00.txt.
[Kompella] Kireeti Kompella, et. al., "Extensions to IS-IS/OSPF and
RSVP in support of MPL(ambda)S", draft-kompella-mpls-optical-00.txt.
[Wang] Gouqiand Wang, et. al., "Extensions to OSPF/IS-IS for Optical
Routing", March 2000, Internet Draft, draft-wang-ospf-isis-lambda-te-
routing-00.txt.
[Fan] Yanhe Fan, et. al., "Extensions to CR-LDP and RSVP-TE for
Optical Path Set-up", March 2000, draft-fan-mpls-lambda-signaling-
00.txt.
[Krishna] Murali Krishnaswamy, et. al., "MPLS control plane for
Switched Optical Networks",2/25/00,draft-krishnaswamy-mpls-son-
00.txt.
8. Author Information
Greg Bernstein
Ciena Core Switching Division
10201 Bubb Road
Cupertino, CA 95014
e-mail: Greg@ciena.com
Phone: (408) 865-6213