Request for Comments: 4257 Grotto Networking
Category: Informational E. Mannie
Perceval
V. Sharma
Metanoia, Inc.
E. Gray
Marconi Corporation, plc
December 2005
Framework for Generalized Multi-Protocol Label
Switching (GMPLS)-based Control of Synchronous Digital
Hierarchy/Synchronous Optical Networking (SDH/SONET) Networks
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
Generalized Multi-Protocol Label Switching (GMPLS) is a suite of
protocol extensions to MPLS to make it generally applicable, to
include, for example, control of non packet-based switching, and
particularly, optical switching. One consideration is to use GMPLS
protocols to upgrade the control plane of optical transport networks.
This document illustrates this process by describing those extensions
to GMPLS protocols that are aimed at controlling Synchronous Digital
Hierarchy (SDH) or Synchronous Optical Networking (SONET) networks.
SDH/SONET networks make good examples of this process for a variety
of reasons. This document highlights extensions to GMPLS-related
routing protocols to disseminate information needed in transport path
computation and network operations, together with (G)MPLS protocol
extensions required for the provisioning of transport circuits. New
capabilities that an GMPLS control plane would bring to SDH/SONET
networks, such as new restoration methods and multi-layer circuit
establishment, are also discussed.
Table of Contents
1. Introduction ....................................................3
1.1. MPLS Overview ..............................................3
1.2. SDH/SONET Overview .........................................5
1.3. The Current State of Circuit Establishment in
SDH/SONET Networks .........................................7
1.3.1. Administrative Tasks ................................8
1.3.2. Manual Operations ...................................8
1.3.3. Planning Tool Operation .............................8
1.3.4. Circuit Provisioning ................................8
1.4. Centralized Approach versus Distributed Approach ...........9
1.4.1. Topology Discovery and Resource Dissemination ......10
1.4.2. Path Computation (Route Determination) .............10
1.4.3. Connection Establishment (Provisioning) ............10
1.5. Why SDH/SONET Will Not Disappear Tomorrow .................12
2. GMPLS Applied to SDH/SONET .....................................13
2.1. Controlling the SDH/SONET Multiplex .......................13
2.2. SDH/SONET LSR and LSP Terminology .........................14
3. Decomposition of the GMPLS Circuit-Switching Problem Space .....14
4. GMPLS Routing for SDH/SONET ....................................15
4.1. Switching Capabilities ....................................16
4.1.1. Switching Granularity ..............................16
4.1.2. Signal Concatenation Capabilities ..................17
4.1.3. SDH/SONET Transparency .............................19
4.2. Protection ................................................20
4.3. Available Capacity Advertisement ..........................23
4.4. Path Computation ..........................................24
5. LSP Provisioning/Signaling for SDH/SONET .......................25
5.1. What Do We Label in SDH/SONET? Frames or Circuits? .......25
5.2. Label Structure in SDH/SONET ..............................26
5.3. Signaling Elements ........................................27
6. Summary and Conclusions ........................................29
7. Security Considerations ........................................29
8. Acknowledgements ...............................................30
9. Informative References .........................................31
10. Acronyms ......................................................33
1. Introduction
The CCAMP Working Group of the IETF has the goal of extending MPLS
[1] protocols to support multiple network layers and new services.
This extended MPLS, which was initially known as Multi-Protocol
Lambda Switching, is now better referred to as Generalized MPLS (or
GMPLS).
The GMPLS effort is, in effect, extending IP/MPLS technology to
control and manage lower layers. Using the same framework and
similar signaling and routing protocols to control multiple layers
can not only reduce the overall complexity of designing, deploying,
and maintaining networks, but can also make it possible to operate
two contiguous layers by using either an overlay model, a peer model,
or an integrated model. The benefits of using a peer or an overlay
model between the IP layer and its underlying layer(s) will have to
be clarified and evaluated in the future. In the mean time, GMPLS
could be used for controlling each layer independently.
The goal of this work is to highlight how GMPLS could be used to
dynamically establish, maintain, and tear down SDH/SONET circuits.
The objective of using these extended IP/MPLS protocols is to provide
at least the same kinds of SDH/SONET services as are provided today,
but using signaling instead of provisioning via centralized
management to establish those services. This will allow operators to
propose new services, and will allow clients to create SDH/SONET
paths on-demand, in real-time, through the provider network. We
first review the essential properties of SDH/SONET networks and their
operations, and we show how the label concept in GMPLS can be
extended to the SDH/SONET case. We then look at important
information to be disseminated by a link state routing protocol and
look at the important signal attributes that need to be conveyed by a
label distribution protocol. Finally, we look at some outstanding
issues and future possibilities.
1.1. MPLS Overview
A major advantage of the MPLS architecture [1] for use as a general
network control plane is its clear separation between the forwarding
(or data) plane, the signaling (or connection control) plane, and the
routing (or topology discovery/resource status) plane. This allows
the work on MPLS extensions to focus on the forwarding and signaling
planes, while allowing well-known IP routing protocols to be reused
in the routing plane. This clear separation also allows for MPLS to
be used to control networks that do not have a packet-based
forwarding plane.
An MPLS network consists of MPLS nodes called Label Switch Routers
(LSRs) connected via Label Switched Paths (LSPs). An LSP is uni-
directional and could be of several different types such as point-
to-point, point-to-multipoint, and multipoint-to-point. Border LSRs
in an MPLS network act as either ingress or egress LSRs, depending on
the direction of the traffic being forwarded.
Each LSP is associated with a Forwarding Equivalence Class (FEC),
which may be thought of as a set of packets that receive identical
forwarding treatment at an LSR. The simplest example of an FEC might
be the set of destination addresses lying in a given address range.
All packets that have a destination address lying within this address
range are forwarded identically at each LSR configured with that FEC.
To establish an LSP, a signaling protocol (or label distribution
protocol) such as LDP or RSVP-TE is required. Between two adjacent
LSRs, an LSP is locally identified by a fixed length identifier
called a label, which is only significant between those two LSRs. A
signaling protocol is used for inter-node communication to assign and
maintain these labels.
When a packet enters an MPLS-based packet network, it is classified
according to its FEC and, possibly, additional rules, which together
determine the LSP along which the packet must be sent. For this
purpose, the ingress LSR attaches an appropriate label to the packet,
and forwards the packet to the next hop. The label may be attached
to a packet in different ways. For example, it may be in the form of
a header encapsulating the packet (the "shim" header) or it may be
written in the VPI/VCI field (or DLCI field) of the layer 2
encapsulation of the packet. In case of SDH/SONET networks, we will
see that a label is simply associated with a segment of a circuit,
and is mainly used in the signaling plane to identify this segment
(e.g., a time-slot) between two adjacent nodes.
When a packet reaches a packet LSR, this LSR uses the label as an
index into a forwarding table to determine the next hop and the
corresponding outgoing label (and, possibly, the QoS treatment to be
given to the packet), writes the new label into the packet, and
forwards the packet to the next hop. When the packet reaches the
egress LSR, the label is removed and the packet is forwarded using
appropriate forwarding, such as normal IP forwarding. We will see
that for an SDH/SONET network these operations do not occur in quite
the same way.
1.2. SDH/SONET Overview
There are currently two different multiplexing technologies in use in
optical networks: wavelength-division multiplexing (WDM) and time
division multiplexing (TDM). This work focuses on TDM technology.
SDH and SONET are two TDM standards widely used by operators to
transport and multiplex different tributary signals over optical
links, thus creating a multiplexing structure, which we call the
SDH/SONET multiplex.
ITU-T (G.707) [2] includes both the European Telecommunications
Standards Institute (ETSI) SDH hierarchy and the USA ANSI SONET
hierarchy [3]. The ETSI SDH and SONET standards regarding frame
structures and higher-order multiplexing are the same. There are
some regional differences in terminology, on the use of some overhead
bytes, and lower-order multiplexing. Interworking between the two
lower-order hierarchies is possible using gateways.
The fundamental signal in SDH is the STM-1 that operates at a rate of
about 155 Mbps, while the fundamental signal in SONET is the STS-1
that operates at a rate of about 51 Mbps. These two signals are made
of contiguous frames that consist of transport overhead (header) and
payload. To solve synchronization issues, the actual data is not
transported directly in the payload, but rather in another internal
frame that is allowed to float over two successive SDH/SONET
payloads. This internal frame is named a Virtual Container (VC) in
SDH and a SONET Payload Envelope (SPE) in SONET.
The SDH/SONET architecture identifies three different layers, each of
which corresponds to one level of communication between SDH/SONET
equipment. These are, starting with the lowest, the regenerator
section/section layer, the multiplex section/line layer, and (at the
top) the path layer. Each of these layers, in turn, has its own
overhead (header). The transport overhead of an SDH/SONET frame is
mainly sub-divided in two parts that contain the regenerator
section/section overhead and the multiplex section/line overhead. In
addition, a pointer (in the form of the H1, H2, and H3 bytes)
indicates the beginning of the VC/SPE in the payload of the overall
STM/STS frame.
The VC/SPE itself is made up of a header (the path overhead) and a
payload. This payload can be further subdivided into sub-elements
(signals) in a fairly complex way. In the case of SDH, the STM-1
frame may contain either one VC-4 or three multiplexed VC-3s. The
SONET multiplex is a pure tree, while the SDH multiplex is not a pure
tree, since it contains a node that can be attached to two parent
nodes. The structure of the SDH/SONET multiplex is shown in Figure
1. In addition, we show reference points in this figure that are
explained in later sections.
The leaves of these multiplex structures are time slots (positions)
of different sizes that can contain tributary signals. These
tributary signals (e.g., E1, E3, etc) are mapped into the leaves
using standardized mapping rules. In general, a tributary signal
does not fill a time slot completely, and the mapping rules define
precisely how to fill it.
What is important for the GMPLS-based control of SDH/SONET circuits
is to identify the elements that can be switched from an input
multiplex on one interface to an output multiplex on another
interface. The only elements that can be switched are those that can
be re-aligned via a pointer, i.e., a VC-x in the case of SDH and a
SPE in the case of SONET.
xN x1
STM-N<----AUG<----AU-4<--VC4<------------------------------C-4 E4
^ ^
Ix3 Ix3
I I x1
I -----TUG-3<----TU-3<---VC-3<---I
I ^ C-3 DS3/E3
STM-0<------------AU-3<---VC-3<-- I ---------------------I
^ I
Ix7 Ix7
I I x1
-----TUG-2<---TU-2<---VC-2<---C-2 DS2/T2
^ ^
I I x3
I I----TU-12<---VC-12<--C-12 E1
I
I x4
I-------TU-11<---VC-11<--C-11 DS1/T1
xN
STS-N<-------------------SPE<------------------------------DS3/T3
^
Ix7
I x1
I---VT-Group<---VT-6<----SPE DS2/T2
^ ^ ^
I I I x2
I I I-----VT-3<----SPE DS1C
I I
I I x3
I I--------VT-2<----SPE E1
I
I x4
I-----------VT-1.5<--SPE DS1/T1
Figure 1. SDH and SONET multiplexing structure and typical
Plesiochronous Digital Hierarchy (PDH) payload signals.
An STM-N/STS-N signal is formed from N x STM-1/STS-1 signals via byte
interleaving. The VCs/SPEs in the N interleaved frames are
independent and float according to their own clocking. To transport
tributary signals in excess of the basic STM-1/STS-1 signal rates,
the VCs/SPEs can be concatenated, i.e., glued together. In this
case, their relationship with respect to each other is fixed in time;
hence, this relieves, when possible, an end system of any inverse
multiplexing bonding processes. Different types of concatenations
are defined in SDH/SONET.
For example, standard SONET concatenation allows the concatenation of
M x STS-1 signals within an STS-N signal with M <= N, and M = 3, 12,
48, 192, .... The SPEs of these M x STS-1s can be concatenated to
form an STS-Mc. The STS-Mc notation is short hand for describing an
STS-M signal whose SPEs have been concatenated.
1.3. The Current State of Circuit Establishment in SDH/SONET Networks
In present day SDH and SONET networks, the networks are primarily
statically configured. When a client of an operator requests a
point-to-point circuit, the request sets in motion a process that can
last for several weeks or more. This process is composed of a chain
of shorter administrative and technical tasks, some of which can be
fully automated, resulting in significant improvements in
provisioning time and in operational savings. In the best case, the
entire process can be fully automated allowing, for example, customer
premise equipment (CPE) to contact an SDH/SONET switch to request a
circuit. Currently, the provisioning process involves the following
tasks.
1.3.1. Administrative Tasks
The administrative tasks represent a significant part of the
provisioning time. Most of them can be automated using IT
applications, e.g., a client still has to fill a form to request a
circuit. This form can be filled via a Web-based application and can
be automatically processed by the operator. A further enhancement is
to allow the client’s equipment to coordinate with the operator’s
network directly and request the desired circuit. This could be
achieved through a signaling protocol at the interface between the
client equipment and an operator switch, i.e., at the UNI, where
GMPLS signaling [4], [5] can be used.
1.3.2. Manual Operations
Another significant part of the time may be consumed by manual
operations that involve installing the right interface in the CPE and
installing the right cable or fiber between the CPE and the operator
switch. This time can be especially significant when a client is in
a different time zone than the operator’s main office. This first-
time connection time is frequently accounted for in the overall
establishment time.
1.3.3. Planning Tool Operation
Another portion of the time is consumed by planning tools that run
simulations using heuristic algorithms to find an optimized placement
for the required circuits. These planning tools can require a
significant running time, sometimes on the order of days.
These simulations are, in general, executed for a set of demands for
circuits, i.e., a batch mode, to improve the optimality of network
resource usage and other parameters. Today, we do not really have a
means to reduce this simulation time. On the contrary, to support
fast, on-line, circuit establishment, this phase may be invoked more
frequently, i.e., we will not "batch up" as many connection requests
before we plan out the corresponding circuits. This means that the
network may need to be re-optimized periodically, implying that the
signaling should support re-optimization with minimum impact to
existing services.
1.3.4. Circuit Provisioning
Once the first three steps discussed above have been completed, the
operator must provision the circuits using the outputs of the
planning process. The time required for provisioning varies greatly.
It can be fairly short, on the order of a few minutes, if the
operators already have tools that help them to do the provisioning
over heterogeneous equipment. Otherwise, the process can take days.
Developing these tools for each new piece of equipment and each
vendor is a significant burden on the service provider. A
standardized interface for provisioning, such as GMPLS signaling,
could significantly reduce or eliminate this development burden. In
general, provisioning is a batched activity, i.e., a few times per
week an operator provisions a set of circuits. GMPLS will reduce
this provisioning time from a few minutes to a few seconds and could
help to transform this periodic process into a real-time process.
When a circuit is provisioned, it is not delivered directly to a
client. Rather, the operator first tests its performance and
behavior and, if successful, delivers the circuit to the client.
This testing phase lasts, in general, up to 24 hours. The operator
installs test equipment at each end and uses pre-defined test streams
to verify performance. If successful, the circuit is officially
accepted by the client. To speed up the verification (sometimes
known as "proving") process, it would be necessary to support some
form of automated performance testing.
1.4. Centralized Approach versus Distributed Approach
Whether a centralized approach or a distributed approach will be used
to control SDH/SONET networks is an open question, since each
approach has its merits. The application of GMPLS to SDH/SONET
networks does not preclude either model, although GMPLS is itself a
distributed technology.
The basic tradeoff between the centralized and distributed approaches
is that of complexity of the network elements versus that of the
network management system (NMS). Since adding functionality to
existing SDH/SONET network elements may not be possible, a
centralized approach may be needed in some cases. The main issue
facing centralized control via an NMS is one of scalability. For
instance, this approach may be limited in the number of network
elements that can be managed (e.g., one thousand). It is, therefore,
quite common for operators to deploy several NMS in parallel at the
Network Management Layer, each managing a different zone. In that
case, however, a Service Management Layer must be built on the top of
several individual NMS to take care of end-to-end on-demand services.
On the other hand, in a complex and/or dense network, restoration
could be faster with a distributed approach than with a centralized
approach.
Let’s now look at how the major control plane functional components
are handled via the centralized and distributed approaches:
1.4.1. Topology Discovery and Resource Dissemination
Currently, an NMS maintains a consistent view of all the networking
layers under its purview. This can include the physical topology,
such as information about fibers and ducts. Since most of this