wdiff draft-bms-optical-sdhsonet-mpls-control-frmwrk-00.txt draft-bms-optical-sdhsonet-mpls-control-frmwrk-01.txt

MPLS Working Group Greg
CCAMP G. Bernstein
Internet Draft Ciena
Document: <draft-bms-optical-sdhsonet-mpls-
control-frmwrk-00.txt>
Category: Eric E. Mannie
Expires: May 2001 GTS

Vishal
control-frmwrk-01.txt> Ebone
Category: Informational V. Sharma
Tellabs

November 2000
Metanoia
Expires January 2002 July 2001

Framework for MPLS-based GMPLS-based Control of Optical SDH/SONET Networks
<draft-bms-optical-sdhsonet-mpls-control-frmwrk-00.txt>
<draft-bms-optical-sdhsonet-mpls-control-frmwrk-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 [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.

1. Abstract

The suite of protocols that define defines Multi-Protocol Label Switching
(MPLS) is in the process of enhancement to generalize its
applicability to the control of non-packet based switching, that is,
optical switching. One area of prime consideration is to use this these
generalized MPLS (GMPLS) protocols in upgrading the control plane of
optical transport networks. This paper document illustrates this process
by describing how
MPLS is being extended those extensions to control MPLS protocols that are directed
towards controlling SONET/SDH networks. SONET/SDH networks are exemplary make
very good examples of this process since they possess a rich
multiplex structure, a variety of protection/restoration options,
are well defined, and are widely deployed. The document discusses
extensions to MPLS routing protocols to disseminate information
needed in transport path computation and network operations are discussed
along together
with the extensions to MPLS label distribution protocols needed for
the provisioning of transport circuits. New capabilities that an
MPLS control plane would bring to SONET/SDH networks, such as new
restoration methods and multi-layer circuit establishment, are also
discussed.

Mack-Crane et al Expires May 2001

Bernstein, Mannie, Sharma Informational - January 2002 1

draft-bms-sdhsonet-mpls-control-frmwrk-00.txt November 2000
2. 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 RFC-2119 [2].

3. Introduction

A few years ago, the Internet Engineering Task Force (IETF) began
work on the specification of a new connection-oriented transport
technology called Multi-Protocol Label Switching (MPLS). The MPLS
forwarding plane was inspired mainly by concepts from virtual
circuit switching in ATM, while its control plane was inspired
mainly by the routing protocols found in IP. As work on defining the
components of MPLS progressed, it soon became apparent that the
principles upon which MPLS technology was based were generic, and
were applicable to multiple layers of the transport network. As
such, MPLS-based control of other network layers, such as the TDM time
division multiplexing (TDM) and optical layers was also possible.
The motivation behind introducing such control was to provide new
services, such as dynamic establishment of TDM and optical circuits,
which were hitherto not possible in transport networks. With MPLS-based MPLS-
based control, transport operators or service providers would be
able to offer on-demand services to their customers, due to the
reduction in provisioning time of their circuits, thus adding
considerable flexibility in their service portfolios.

The MPLS CCAMP Working Group of the IETF is currently working on
extending MPLS protocols to support these non-packet multiple network layers and
these 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 authors of this work are among the
co-authors of the GMPLS specifications, and - focus mainly on those
aspects of GMPLS that relate to the control of SDH/SONET networks.

The GMPLS effort is, in fact, effect, extending IP technology to control
and manage lower layers. Using the same framework and the same kinds of similar
signaling and routing protocols to control multiple layers can not
only
has the potential to reduce the overall complexity of designing, deploying and
maintaining networks, but can also has the potential to make it possible to operate two
contiguous layers by using either an overlay model, a peer model 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 is very suitable
could be used for controlling each layer completely independently.

The goal of this paper work is to highlight how MPLS GMPLS could be used to
dynamically establish, maintain and tear down SDH/SONET circuits.
The objective of using these extended MPLS protocols is to provide
at least the same kind kinds of SDH/SONET

Bernstein, Mannie, Sharma Expires May 2001 2

draft-bms-sdhsonet-mpls-control-frmwrk-00.txt November 2000 services as are provided today,
but using signaling instead of provisioning via centralized

Bernstein, Mannie, Sharma Informational - January 2002 2
management to establish those services. This will allow operators to
propose new services, and will allow clients to create SONET/SDH
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Æs of label concept in MPLS can be
extended to the SONET/SDH case. We then look at important
information to be disseminated by a link state route 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. [3], [4], [5], [6], [7],[8], [9],
[10], [11], [12].

3.1

3.1. MPLS Overview

A major advantage of the MPLS architecture for use as a general
network control plane is the its clear separation between the forwarding plane,
plane (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 terminology, an network consists of MPLS node is nodes called a Label Switch Router
(LSR) and a circuit is Routers
(LSRs) connected via circuits called a Label Switched Path (LSP). Paths (LSPs). An
LSP is unidirectional and could be of several different types such
as point-to-point, point-to-multipoint, and multipoint-to-point.
Border LSRs in an MPLS cloud, network, act either as ingress or egress LSRs
respective to
depending on the direction of the traffic being forwarded.

MPLS allows the establishment of LSPs between ingress and egress
LSRs.

Each LSP is associated with a Fowarding 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 LSR. FEC.

To establish an LSP, a signaling protocol (or label distribution
protocol) such as LDP/CR-LDP or RSVP-TE is required. Between two
adjacent LSRs, an LSP is locally identified by a short, fixed length
identifier called a label. This
label label, which is only significant between these
two LSRs. The signaling protocol is responsible for the inter-node
communication that assigns and maintains these labels.

When a packet enters an MPLS packet-based MPLS-based packet network, it is classified
according to its FEC and, possibly, additional rules, which together
determine the LSP along which the packet is must be sent. For that 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 it may be in
the form of a header encapsulating the packet (the "shim" header) or

Bernstein, Mannie, Sharma Informational - January 2002 3
it may be written in the VPI/VCI field (or DLCI field) of the layer

Bernstein, Mannie, Sharma Expires May 2001 3
"
draft-bms-sdhsonet-mpls-control-frmwrk-00.txt November 2000
2 encapsulation of the IP data. 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 core packet LSR, this LSR uses the label as
an index into a forwarding table to determine the next hop and the
corresponding outgoing label, 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
adequate
appropriate forwarding, such as normal IP forwarding. We will see
that for a SONET/SDH network these operations -do do not occur in quite
the same way.

3.2

3.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. SDH, which was developed by the ETSI and later
standardized by the ITU-T, is now used worldwide, while SONET, which
was standardized by the ANSI, is mainly used in the US. However,
these two standards have several similarities, and to some extent
SONET can be viewed as a subset of SDH. Internetworking between the
two is possible using gateways.

The fundamental signal in SDH is the STM-1 that operates at a rate
of about 155 Mbps Mbps, while the fundamental signal in SONET is the STS-1 STS-
1 that operates at a rate of about 51 Mbps. These two signals are
made of contiguous frames that consist of a transport overhead
(header) and a payload. To solve synchronization issues, the actual
data is not directly 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 Synchronous 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 a SDH/SONET frame is
mainly sub-
divided 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. payload of the overall
STM/SDH frame.

Bernstein, Mannie, Sharma Informational - January 2002 4
The VC/SPE itself is made up of a header (the path overhead) and a
payload. This payload can itself be further subdivided into sub-elements
(signals) in a fairly complex way. In the case of SDH, the STM-1
frame itself may contain either one VC-4 or three multiplexed VC-3s.
Indeed, SDH and SONET both define a complete multiplexing structure. The
SONET multiplex is a pure tree, while the SDH multiplex is not a

Bernstein, Mannie, Sharma Expires May 2001 4

draft-bms-sdhsonet-mpls-control-frmwrk-00.txt November 2000
pure tree tree, since it contains a node that can be attached to two
parent nodes. The structure of the SONET/SDH multiplex is shown in
Figure 1. In addition, we show reference points in this figure that
will be
are explained in later on. sections.

xN x1
STM-N<----AUG<----AU-4<--VC4<------------------------------C-4 E4
^ ^
Ix3 Ix3
I I x1
I -----TUG-3<----TU-3<----VC-3<----I -----TUG-3<----TU-3<---VC-3<---I
I ^ C-3
DS3/T3/E3 DS3/E3
-------AU-3<---VC-3<-- I -----------------------I ---------------------I
^ I
Ix7 Ix7
I I x1
-----TUG-2<----TU-2<----VC-2<---C-2
-----TUG-2<---TU-2<---VC-2<---C-2 DS2/T2
^ ^
I I x3
I I------TU-12<---VC-12<--C-12 I----TU-12<---VC-12<--C-12 E1
I
I x4
I---------TU-11<---VC-11<--C-11
I-------TU-11<---VC-11<--C-11 DS1/T1

xN
STS-N<-------------------SPE<---------------------------------
DS3/T3
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 PDH
payload signals.

Bernstein, Mannie, Sharma Expires May 2001 Informational - January 2002 5

draft-bms-sdhsonet-mpls-control-frmwrk-00.txt November 2000
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 goal MPLS-based control of this paper 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. These The only elements that can be switched are only 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.

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, 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 and
hence this relieves, when possible, an end system of any inverse
multiplexing bonding processes. Different types of concatenations
are defined, with specific rules. defined in SDH/SONET.

For instance, the 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.

3.3

3.3. The Real World Current State of Circuit Establishment with in SDH/SONET Networks

Today, June 2001, SDH and SONET networks are statically configured.
When a client of an operator requests a point-to-point circuit or a ring,
it circuit, the
request sets in motion a process that can last for weeks. several weeks or
more. This process is
indeed 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,. a CPE example, customer premise equipment (CPE) to contact a
SDH/SONET switch to request some
bandwidth. This is, in fact, the ultimate objective that we would
like to achieve using MPLS to control SDH/SONET networks.

In the current setup, however, a circuit. Currently, the provisioning
process involves the following components. tasks.

3.3.1. Administrative Tasks

The administrative tasks represent a significant part of the
provisioning time. Most of them can be automated using IT

Bernstein, Mannie, Sharma Expires May 2001 6

draft-bms-sdhsonet-mpls-control-frmwrk-00.txt November 2000
applications, however, and MPLS does not help in that case. However, 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 step enhancement is

Bernstein, Mannie, Sharma Informational - January 2002 6
to allow the client's equipment to coordinate with the operator's
network directly and request the desired circuit. This has to could be
achieved through a signaling protocol at the interface between the
client equipment and an operator switch, i.e. i.e., at the UNI interface,
where MPLS GMPLS signaling can play a
role. be used.

3.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. To support our fully automated model we
must, of course, assume that CPEs are pre-connected to the
operatorÆs network.

3.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 and/or rings. circuits. These planning tools can
require a significant running time, sometimes of on the order of days.
These simulations are, in general, executed for a set of demands for circuits and/or rings
circuits, i.e., a batch mode, to improve the optimality of the
solution. 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 most probably skip this phase. It not "batch up" as many connection
requests before we plan out the corresponding circuits. This means
that the network will have may need to be re-optimized periodically, implying
that the signaling should support re-optimization without hurting too
much the service. Indeed, the optimization of the network is then
taken out of the chain and becomes a background activity. Smart
circuit re-routing required for re-optimization is available in
MPLS. with minimum
impact to existing services.

3.3.4. Circuit Provisioning

Once the first three steps have been executed, completed, the circuits must be
effectively
provisioned by the operator using the outputs of the planning tool.
process. The time required for this provisioning is varies greatly. It can
be fairly short, on the order of a few minutes. In many cases, 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 more and each
vendor is a significant burden on the service provider. A
standardized interface for provisioning, such as GMPLS signaling,
could significantly reduce or less automatically. eliminate this development burden. In
general, the provisioning is a grouped batched activity, i.e., a few times per
week an operator
launches the provisioning of provisions a set of circuits in one shot. MPLS circuits. GMPLS will reduce
this provisioning time from a few minutes to a few seconds and will could
help to transform this periodic process into a real-time process.

Bernstein, Mannie, Sharma Expires May 2001 7

draft-bms-sdhsonet-mpls-control-frmwrk-00.txt November 2000

When a circuit or a ring is provisioned provisioned, it is not delivered directly to a
client. First, Rather, the operator first tests its performance and
behavior is tested by the
operator and if this is successful, delivers the circuit is delivered to the client. This

Bernstein, Mannie, Sharma Informational - January 2002 7
testing phase lasts, in general, for up to 24 hours. The operator instalsl
installs test equipment at each end and uses pre-
defined pre-defined test
streams to verify the performance. If successful, the circuit is
officially accepted by the client. Thus, to To speed up this the verification
(sometimes known as "proving") process, brief automated performance testing will have to be
supported in some way.

So, it results that most of the time that can would be saved is mainly due necessary to the fact that we change the work model of an operator. In
addition, note that signaling other than MPLS can achieve the same
result. Even an architecture based on a centralized management
achieves the same without MPLS. The benefits of using MPLS can,
however, be realized both with the use
support some form of a distributed architecture
or a centralized architecture, since MPLS supports explicit routing
(and a centralized architecture with signaling support, could
compute the route and then use signaling to establish it). Below
we will briefly look at both the centralized and the distributed
approaches to circuit provisioning. automated performance testing.

3.4. Centralized Approach versus Distributed Approach

The debate between

Whether a centralized approach and or a distributed approach will be
used to control an SDH/SONET network or an optically switched network is
still on-going. There networks is probably no outstanding characteristic any
approache that will make it the universal solution. Each an open question, since Eech
approach has advantages and disadvantages. Depending on the particular
network to be controlled and operator requirements, either solution
could be the right one. The application of MPLS GMPLS
to SONET/SDH networks does not preclude either model although MPLS
is itself a distributed technology. In particular, the explicit route
capability in MPLS combined with a "soft permanent LSP" (SPLSP) type
functionality could fully support a centralized approach to circuit
provisioning that would also be interoperable.

The centralized approach is typically implemented using a Network
Management System dynamically provisioning circuits. Although no
signaling protocol is used, a routing protocol is used to route the
management messages. Indeed, the management protocol acts as a
signaling protocol. Network elements stay relatively simple and are
not involved in decision making. CPEÆs can implement a simple
signaling interface with the NMS, such as the one being proposed in
the ODSI. This approach has a number of advantages in basic tradeoff between the short
term. The typical network management model used today for TDM
networks is TMN.
A distributed approach consists of using one or more distributed
routing protocols, such as IP routing protocols, centralized and a distributed
signaling protocol. The MPLS architecture fits very well in that
case. This solution has the potential to be scalable and robust, and
enable future services like inter-domain routing. Obviously, it adds

Bernstein, Mannie, Sharma Expires May 2001 8

draft-bms-sdhsonet-mpls-control-frmwrk-00.txt November 2000

more complexity but this
approaches is the "price" to pay if we want to build a
network of SDH/SONET networks, i.e. an SDH/SONET inter-network.

A centralized approach can benefit from the management information that is collected constantly, e.g. performance alarms, failure
alarms and traps. Once filtered and analyzed, this information can
be used to detect failure in almost real-time. However, sometimes
this approach can also be penalized if the number of management
messages is not controlled appropriately, as we will see later.

On the other hand, a distributed routing protocol relies mainly on
timers and missing routing PDUs to detect a failure between two
adjacent switching nodes. It can also use indications from complexity of the
underlying layer, if available, but it does not communicate directly
with some network elements, like amplifiers, and transponders, elements versus that
could detect problems sooner.

In addition, a NMS maintains a consistent view of all the layers,
including the physical topology, at any time. Centralized decisions
can be taken based on accurate information and can use physical
information about fibers and ducts. On the other hand, a routing
protocol builds and maintain a logical model of the network. Not all
routing entities have the same view
of the network at all times, and
re-routing and crank-back are needed for the signaling protocol.

A centralized management is easier system (NMS). Since adding functionality
to operate, new features can be
introduced with a simple upgrade. On the contrary, updating switches
with new routing software is harder. One could easily change the
parameters of the constrained routing algorithm or the metrics of
the links. These changes will take effect instantaneously. Several
added-value tools can run in the background and easilty easily
information with the centralized decision point. Such tools might
be, circuit planning tools (for network optimization, diversity
design, performance analysis), circuit reservation tools, and VPN
tools,for example.

Finally, this approach fits well with the current network operation
structure. The major upgrade is a an IT upgrade at the operatorÆs existing
SDH network operations center. The DCN used to transport the management
protocol now becomes now a critical part of the operator
infrastructure and consequently must elements may not be protected. Its availability
has possible, a direct impact on the on-demand circuit provisioning. Of
course, ideally new SDH/SONET non-blocking switching fabrics need to
be deployed in the network. Note that this centralized approach could have been
supported since years with the actual SDH/SONET switching fabrics,
if we took into consideration the limitations of these fabrics.

The DCN used to transport management PDUs can may
be a mix of out-of-
band links and in-band communication links needed in the SDH/SONET overhead
(like the DCC). A routing protocol is run over these links to route
the management PDUs. The TMN model uses CMIP as the network
management protocol. The interface between a NE and the NMS is
referred to as the Q3 interface and is based on the OSI model. some cases. The

Bernstein, Mannie, Sharma Expires May 2001 9

draft-bms-sdhsonet-mpls-control-frmwrk-00.txt November 2000

upper part of the protocol stack at the Q3 interface is defined in
Q.812. Different profiles are defined in Q.811 for the lower part,
they cover LAN and WAN interfaces. Note that the upper part can also
be supported over main issue facing centralized control
via an IP infrastructure. In general, IS-IS is the
network layer routing protocol that is used.

The topology of the DCN is more complex than the topology considered
for the distributed approach, since all network elements, and not
just the switches, must be reached. In case of failures in a
SDH/SONET network, bursts of hundreds or thousands of alarms can be
sent to the management system over the DCN. In that case,
provisioning related messages can be delayed by the treatment of the
alarms if no mediation function filtering and message aggregation is
available between the NMS and NEs.

In the case of the distributed approach, the routing protocol must
only abstract the physical links between the switches and the
signaling protocol must only flow between these switches. The DCN
used for the management of the network could be re-used, or a
separate signaling network could be setup. Surprisingly, the
requirements is one of a DCN could be much higher than the requirements for
the distributed signaling network.

An NMS has scalability limitations. scalability. For instance, it can this approach may be
limited in the number of network elements that can be managed (e.g.
one thousand). It is is, therefore, quite common for operators to
deploy several NMSÆs NMS’s 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 at the Service Management Layer must be built
NMS’s to take care of end-to-end on-demand services. On the contrary, the
scalability is much better in the distributed approach, clients are
co-located with switches and distributed among these switches.

An NMS can also be a bottleneck, it has already to deal with all
traditional management messages; now in addition, it has to take
care of reliably handling provisioning messages, and, sometimes, UNI
messages as well. The load due to additional and more dynamic
operations, such as dynamic circuit establishment and fast
restoration is also not negligible. Indeed, the distributed approach
has the advantage of being isolated from the burden that can be
placed on the NMS due to network conditions.

It could be expected that other
hand, in a complex and/or dense network, restoration could be faster
with a distributed approach than with a centralized approach. In

Let's now look at how the first case, signaling messages travel
over exactly major control plane functional components
are handled via the same path centralized and distributed approaches:

3.4.1. Topology Discovery and Resource Dissemination

Currently NMS's maintain a consistent view of all the networking
layers under their purview. This can include the physical topology,
such as information about fibers and ducts. Since most of this
information is entered manually, it remains error prone.
A link state GMPLS routing protocol, on the affected circuits other hand, could
perform automatic topology discovery and only through dissemination the affected. In topology
as well as resource status. This information would be available to
all nodes in the second network, and hence also the NMS. Hence one can
look at a continuum of functionality between manually provisioned
topology information (of which there will always be some) and fully
automated discovery and dissemination as in a link state protocol.
Note that, unlike the IP datagram case, a signaling message has to go
first link state routing
protocol applied to the NMS , which transmits signaling messages (in parallel)
to all concerned nodes. However, this comparison requires further
investigations.

In general , an NMS is SDH/SONET network does not a single point of failure, since all
operators have systems in hot stand-by and disaster recovery plans any service
impacting implications.

Bernstein, Mannie, Sharma Expires May 2001 10

draft-bms-sdhsonet-mpls-control-frmwrk-00.txt November 2000

for Informational - January 2002 8
3.4.2. Path Computation (Route Determination)

In the NMS. The DCN must now be as well protected as SDH/SONET case, unlike the transport IP datagram case, there is no need
for network itself. However, elements to all perform the survivability same path calculation. In
addition, path determination is an area for vendors to provide a
potentially significant value addition in terms of the distributed network
efficiency, reliability, and service differentiation. In this sense,
a centralized approach to path computation is likely easier to operate and
upgrade. For example, new features such as new types of path
diversity or new optimization algorithms can be better since introduced with a
simple NMS software upgrade. On the intelligence other hand, updating switches
with new path computation software is
distributed, a more complicated task. In
addition, many of the algorithms are quite computationally intensive
and could even survive may be completely unsuitable for the embedded processing
environment available on most switches. In restoration scenarios
the ability to perform a reasonably sophisticated level of path
computation on the network partitioning.

A distributed signaling and routing approach also appears a
reasonable solution element can be particularly useful for inter-domain operations. Having hundreds
restoring traffic during major network faults.

3.4.3. Connection Establishment (provisioning)

The actual setting up of
NMSs organized in circuits, i.e., a tree with coupled collection of
cross connects across a root NMS that controls the various
NMSs from different operators network, can be rather difficult, especially in done either via the absence of adequate NMS interoperability standards. This is
probably a significant motivation for resorting to
setting up individual cross connects or via a distributed "soft permanent LSP"
(SPLSP) type approach.

Having signaling and routing In the SPLSP approach, the NMS may just kick
off the connection at each inter-domain interface does not
imply that we need the same inside each individual domain. However,
inter-working between intra- and inter-domain operations will be
greatly facilitated if we a distributed approach is also supported
internal to a domain. This "ingress" switch with GMPLS signaling
setting up the connection from that point onward. Connection
establishment is particularly true for the signaling,
using trickiest part to distribute, however, since
errors in the same protocol for both intra and inter-domain operations -
seems a sensible approach. connection setup/tear down process are service
impacting.

Distributed approach Centralized approach

Control plane like MPLS or Management plane like TMN or
PNNI SNMP
Do we really need it? Being Always needed! Already there,
added/specified by several proven and understood.
standardization bodies

High survivability (e.g. in Potential single point(s) of
case of partition) failure

Distributed load Bottleneck: #requests and
actions to/from NMS

Individual local routing Centralized routing decision,
decision can be done per block of
requests
Routing scalable as for the Assumes a few big

Bernstein, Mannie, Sharma Informational - January 2002 9
Internet administrative domains

Complex to change routing Very easy local upgrade (non-
protocol/algorithm intrusive)

Requires enhanced routing Better consistency
protocol (traffic
engineering)

Ideal for inter-domain Not inter-domain friendly

Suitable for very dynamic For less dynamic demands
demands (longer lived)

Probably faster to restore, Probably slower to restore, but

Bernstein, Mannie, Sharma Expires May 2001 11

draft-bms-sdhsonet-mpls-control-frmwrk-00.txt November 2000 restore,but
but more difficult to have could effect reliable
reliable restoration. restoration.

High scalability Limited scalability: #nodes,
(hierarchical) links, circuits, messages

Planning (optimization) Planning is a background
harder to achieve centralized activity

Easier future integration
with other control plane
layers
Table 1. Qualitative comparison between centralized and distributed
approaches.

3.5

3.5. Why SDH/SONET will not Disappear Tomorrow

If the

As IP traffic becomes the unique dominant traffic transported over any
transmission network, we could consider that the
transport infrastructure, it is useful to compare the statistical
multiplexing of IP would completely replace with the time division multiplexing of SDH and
SONET. In that case,

Consider a scenario where IP over WDM will be is used everywhere and lambdas could be
are optically switched. A In such a case, a carrier's carrier will would
sell dynamically controlled lambdas with each customer building its
his/her own IP backbone over these lambdas.

This simple model implies that a carrier will would sell lambdas instead
of bandwidth. The carrier carrier’s goal will try be to maximize the number of lambdas
wavelengths/lambdas per fiber and fiber, with each customer will have having to fully
support the cost for each of his end-to-end lambdas. Inthe lambda whether or not the
wavelength is fully utilized. Although, inn the near future, we may
have technology to support up to several hundreds of hundred lambdas per fiber.
However, fiber,
a world where lambdas are so cheap and abundant that every
individual customer can buy buys them, from one point to any other point,
appears an unlikely scenario today.

Bernstein, Mannie, Sharma Informational - January 2002 10
More realistically, there is still room stillroom for a multiplexing technology
that provides circuits with a lower granularity than a wavelength. Not
(Not everyone needs a minimum of 10 Gbps or 40 Gbps per circuit, and
IP does not yet support all the telecom applications
(e.g. telephony). in bulk
efficiently.)

SDH and SONET possess a rich multiplexing hierarchy that permits a
finer
fairly fine granularity and that provides a very cheap and simple
physical separation of the transported traffic between circuits. We can
easily multiplex any kind of traffic, IP or not, synchronous or
asynchronous. circuits,
i.e., QoS.
Moreover, even IP is datagrams are not used transported directly over a wavelength, a
wavelength. A framing or encapsulation is always required to delimit
IP datagrams. The Total Length field of an IP header cannot be
trusted to find the start of a new datagram, since it could be
corrupted and would result in a loss of synchronization. The typical
framing used today for IP over DWDM is defined in RFC1619/RFC2615
and is also known as POS (Packet

Bernstein, Mannie, Sharma Expires May 2001 12

draft-bms-sdhsonet-mpls-control-frmwrk-00.txt November 2000 Over SONET/SDH). It is indeed SONET/SDH), i.e., IP over PPP (in HDLC like
HDLC-like format) over SDH/SONET. SDH and SONET are actually
efficient encapsulations for IP. For instance, with an average IP
datagram length of 350 octets, an IP over GBE encapsulation using an
8B/10B encoding results in 28% overhead, an IP/ATM/SDH encapsulation
results in 22% overhead and an IP/PPP/SDH encapsulation result results in
only 6% overhead. New (New simplified encapsulations could reduce this
overhead to as low as 3%, but the gain is not huge compared to SDH
and SONET -, which have other benefits as well. well.)

Any encapsulation of IP over WDM should at least provide error
monitoring capabilities (to detect signal degradation), error
correction capabilities, such as FEC (Forward Error Correction) that
are particularly needed for ultra long hau haul transmission, sufficient
timing information, to allow robust synchronization (that is, to
detect the beginning of a packet), and capacity to transport
signaling, routing and management messages, in order to control the
optical switches. SDH and SONET cover all these aspects natively,
except FECs that can FEC, which tends to be (are) supported in a proprietary way.

Since the IP encapsulated in SDH/SONET encapsulation is a good candidate efficient and is anyway widely used, the
only real difference between an IP over WDM network and an IP over
SDH over WDM network is the layers at which the switching or
forwarding can take place. In the first case, it can take place at
the IP and optical layers. In the second case, it can take place at
the IP, SDH/SONET SDH/SONET, and optical layers. What we are arguing here is
that it makes sense to do switching or forwarding at all these
layers.
Almost all transmission networks today are based on SDH or SONET. A
client is connected either directly through an SDH or SONET
interface or through a PDH interface, the PDH signal being
transported between the ingress and the egress interfaces over SDH
or SONET. The SDH and SONET technologies What we are widespread, very well
understood arguing here is that it makes sense to do
switching or forwarding at all these layers.

4. MPLS GMPLS Applied to SDH/SONET

Bernstein, Mannie, Sharma Informational - January 2002 11
4.1. Controlling the SDH/SONET Multiplex

Different parts

Controlling the SDH/SONET multiplex implies deciding which of the
different components of the SDH/SONET multiplex that can be switched, and we
have to decide which of these switched
do we would like wish to control through MPLS.
Basically, using GMPLSEssentially, every SDH/SONET
element that is referenced by a pointer can be switched, through pointer adjustment. switched. These elements
component signals are the VC-4, VC-3s, VC-2s, VC-12s VC-3, VC-2, VC-12 and VC-11s VC-11 in the
SDH case; and the VT and STS SPEs in the SONET case. The SONET case
is more a bit difficult to explain since, unlike in SDH, SPEs in SONETdo SONET do
not have individual names. We will refer to them by identifying the
structure that contains them, namely the STS-1, VT-6s, VT-3s, VT-2s VT-6, VT-3, VT-2 and VT-1.5s.

Bernstein, Mannie, Sharma Expires May 2001 13

draft-bms-sdhsonet-mpls-control-frmwrk-00.txt November 2000
VT-1.5.

The STS-1 SPE corresponds to a VC-3, a VT-6 SPE corresponds to a VC-
2, a VT-2 SPE corresponds to a VC-12, and a VT-1.5 SPE corresponds
to a VC-11. The SONET VT-3 SPE has no correspondence in SDH, and the
SDH however
SDH's VC-4 has no correspondence in SONET. A continuous flow of one of
such elements constitutes an SDH or SONET signal. corresponds to SONET's STS-3c SPE.

In addition, it is possible to concatenate some of the structures
that contain these elements to build bigger larger elements. For instance,
SDH allows the concatenation of X contiguous AU-4s to build a VC-4-
Xc and of m contiguous TU-2s to build a VC-2-mc. In that case, a VC-
4-Xc or a VC-2-mc can be switched and controlled by MPLS. Note that
SDH defines also the defines virtual (non-contiguous) concatenation of TU- 2s,
but in that case each constituent VC-2 is switched individually.

4.2. SDH/SONET LSR and LSP Terminology

Let a SDH or SONET Terminal Multiplexer (TM), Add-Drop Multiplexer
(ADM) or cross-connect (i.e. a switch) be called an SDH/SONET LSR. A
SDH/SONET path or circuit between two SDH/SONET LSRs now becomes an
MPLS a
GMPLS LSP. An SDH/SONET LSP is a logical connection between the
point at which a tributary signal (client layer) is assembled adapted into its
virtual container, and the point at which it is disassembled extracted from
the its
virtual container. The position taken r by a tributary signal in
a virtual container will be referred to as an SDH/SONET signal.

To establish such an LSP, a signaling protocol is required to
configure the input interface, switch fabric, and output interface
of each SDH/SONET LSR along the path. An SDH/SONET LSP can be point-
to-point or point-to-multipoint, but not multipoint-to-point, since
no merging capability is possible. possible with SDH/SONET signals.

To facilitate the signaling and setup of SDH/SONET circuits, an
SDH/SONET LSR, LSRmust, therefore, must identify each possible signal
individually per interface, since each signal corresponds to a
potential LSP that can be established through the SDH/SONET LSR. It
turns out, however, that not all SDH signals correspond to an LSPs LSP
and therefore not all of them need be identified. In fact, only
those signals that can be switched need identification.

5. Decomposition of the MPLS Circuit-Switching Problem Space

Bernstein, Mannie, Sharma Informational - January 2002 12
Although those familiar with MPLS may be familiar with its
application in a variety of application areas, e.g., ATM, Frame
Relay, etc. and so on, here we quickly review its decomposition when
applied to the optical 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 routing 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 it is
desirable to offer different levels of service in a network based on
whether a circuit is routed over SDH/SONET lines that are ring

Bernstein, Mannie, Sharma Expires May 2001 14

draft-bms-sdhsonet-mpls-control-frmwrk-00.txt November 2000
protected versus not being routed over those that are not ring protected
(differentiation based on reliability), the type of protection on
a SDH/SONET line would be an important topological parameter that should
would have to be distributed via the link state route protocol.. routing protocol.

(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 fact,
this information may form can be thought of as the "virtual" label. For example
example, in SONET
if we are networks, when distributing information to
switches concerning an end-to-
end end-to-end STS-1 path traversing a network,
it is critical that adjacent switches agree on the multiplex entry
used by this STS-1 (but this information is only of local
significance between the those two switches). Hence, the multiplex
entry number in this case can be used as a virtual label. Note
that it the label is virtual in that it is not appended to the payload
in any way, but it is still a label in the sense that it uniquely
identifies the signal local to locally on the link between the two switches.

(iii) Information that all switches in the path will need to know about a
circuit will also be distributed via the label distribution
protocol. Example Examples of such information can include bandwidth, priority,
and preemption information. for instance.

(iv) Information intended only for end systems of the connection.
Some of the payload type information in may fall into this category.
[8],[10].

6. MPLS Routing for SDH/SONET

Modern transport networks based on SONET/SDH excel at
interoperability in the performance monitoring (PM) and fault
management (FM) areas, however, they areas., They do not not, however, inter-operate in the
areas of topology discovery or resource status. Although link state
route
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), 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

Bernstein, Mannie, Sharma Informational - January 2002 13
network status is available to a network operator for use in
planning, provisioning and operations.

Information

The information needed to compute the path a connection will take
through a network is important to distribute via the routing
protocol. In the optical TDM case case, this information includes, but
is not limited to: the available capacity of the network links, the
switching and termination capabilities of the nodes and interfaces,
and the protection properties of the link.

When applying routing to circuit switched situations networks it is useful to
compare and contrast this situation with the datagram routing case.

Bernstein, Mannie, Sharma Expires May 2001 15

draft-bms-sdhsonet-mpls-control-frmwrk-00.txt November 2000
In the case of routing for datagrams all routes on all nodes must be
calculated exactly the same to avoid loops and "blackholes". "black holes". In the
circuit switching, this is not the case since routes are establish established
per circuit and are fixed for that circuit. Hence, unlike the
datagram case, routing is not service impacting in the circuit
switched case. This is helpful, since because to accommodate the optical
layer new information must routing protocols need to be supplemented to the routing protocols, with new
information, much more than the datagram case. This information will is
also likely to be used in different ways for implementing different
user services. Due to the increase in information transferred in
the route protocol routing protocol, it is important to separate the relatively
static parameters concerning a link with from those that may be subject
to frequent changes. This is particularly important in the case of
available capacity advertisements.

6.1. Switching Capabilities

The main switching capabilities that characterize a SONET/SDH end
system and thus get need to be advertised into via the link state route routing
protocol are: the switching granularity, supported forms of
concatenation, and the level of transparency.

6.1.1. Switching Granularity

From Error! Reference source not found. and references [3], [4]and the overview section on SONET/SDH we see
that there are a number of different signals that compose the
SONET/SDH hierarchies. Those signals that are referenced via a
pointer, i.e., the VCs in SDH and the SPEs in SONET are those that
will actually be switched within a SONET/SDH network. These signals
are subdivided into lower order signals and higher order signals as
shown in Table 2.

Table 2. SDH/SONET switched signal groupings.

Signal Type SDH SONET

Lower Order VC-11, VC-12, VC-2 VT-1.5 SPE, VT-2 SPE,
VT-3 SPE, VT-6 SPE

Higher VC-3, VC-4 STS-1 SPE

Bernstein, Mannie, Sharma Informational - January 2002 14
Order

Manufacturers today differ in the types of switching capabilities
their systems support. Many manufacturers today switch signals
starting at VC-4 for SDH or STS-1 for SONET (i.e. the basic
frame) and above (see concatenation section), but they don't allow to do not
switch lower order signals. Some of them allow only to switch allow the switching
of entire aggregates (concatenated or not) of signals such as 16 VC-4s, VC-
4s, i.e. a complete STM-16, and nothing below. finer. Some manufacturers go down to the
VC-3 level for SDH. Finally, some
manufacturers allow to go lower than offer highly integrated switches
that switch at the VC-3/STS-1, VC-3/STS-1 level down to lower order signals such
as VC-12s. Some combinations are also possible,
such as down to VC-12 for unprotected circuits and nothing below VC-
4 for fast restoration.

Bernstein, Mannie, Sharma Expires May 2001 16

draft-bms-sdhsonet-mpls-control-frmwrk-00.txt November 2000

We can see that very different granularities can be considered.
These granularities can even vary between services. In order to cover the needs of all manufacturers and
operators, we don't limit
the scope of our work to GMPLS must consider both higher order signals and we consider that
we have to design a solution able to control the complete SDH/SONET
multiplex. Of course, one could just use it to control the higher lower order
signals.

6.1.2. Signal Concatenation Capabilities

As stated in the SONET/SDH overview, to transport tributary signals
with rates in excess of the basic STM-1/STS-1 signal, the VCs/SPEs
can be concatenated, i.e., glued together. Different types of
concatenations are defined: contiguious contiguous standard concatenation,
arbitrary contiguous concatenation, and virtual concatenation with different
rules concerning their size, placement, and binding.

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. The multiplexing
procedures for SONET and SDH are given in references [3], [4], [5], [3]and [4].
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
SDH); (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 disadvantages 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).

Due to these disadvantages some SONET framer manufacturers now
support "flexible" or 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, i.e., the signals can use any
combination of available time slots.

Bernstein, Mannie, Sharma Informational - January 2002 15
Standard and flexible concatenations are network services, while
virtual concatenation is a SONET/SDH end system end-system service recently
approved by the committee T1 of ANSI and ITU-T. The essence of this
service is to have SONET/SDH end systems "glue" together the VCs or
SPEs of separate signals rather than the requiring that he signals being be
carried through the network as a single unit. In one example of
virtual
concatenation concatenation, two end systems supporting this feature could
essentially "inverse multiplex" two STS-1s into a virtual STS-2c for

Bernstein, Mannie, Sharma Expires May 2001 17

draft-bms-sdhsonet-mpls-control-frmwrk-00.txt November 2000
the efficient transport of 100Mbps Ethernet traffic. Note that this
inverse multiplexing process can be significantly easier to
implement with SONET/SDH signals rather than for packets. Virtual concatenation,
being Since virtual
concatenationis provided by end systems, it is compatible with
existing SONET/SDH networks. Virtual concatenation is defined for
both higher order signals and low order signals. Table 3 shows the
nomenclature and capacity for several low order lower-order virtually
concatenated signals contained in within different higher order higher-order
signals.

Table 3 Capacity of Virtually Concatenated VTn-Xv ( 9/G.707)

Carried In X Capacity In steps
of

VT1.5/V

VT1.5/ STS-1/VC-3 1 to 28 1600kbit/s to 1600kbit/s
C-11-Xv
VC-11-Xv 44800kbit/s

VT2/VC-

VT2/ STS-1/VC-3 1 to 21 2176kbit/s to 2176kbit/s
12-Xv
VC-12-Xv 45696kbit/s

VT1.5/V

VT1.5/ STS-3c/VC-4 1 to 64 1600kbit/s to 1600kbit/s
C-11-Xv
VC-11-Xv 102400kbit/s

VT2/VC-

VT2/ STS-3c/VC-4 1 to 63 2176kbit/s to 2176kbit/s
12-Xv
VC-12-Xv 137088kbit/s

6.1.3. SDH/SONET Transparency

The purposed of SONET/SDH is to carry its payload signals in a
transparent manner. This can include some of the layers of SONET
itself, i.e.,
itself. For example, situations where the path overhead can never be touched
touched, since it actually belongs to the client. This was another
reason is why we
didnÆt want to code any for not coding an explicit label in SDH/SONET path overhead.
It may be useful to transport, multiplex and/or switch lower layers
of the SONET signal transparently.

As mentioned in the introduction introduction, SONET overhead is broken into
three layers: Section, Line and Path. All Each of these layers are is
concerned with fault and performance monitoring. The Section
overhead is primarily concerned with framing and framing, while the 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

Bernstein, Mannie, Sharma Informational - January 2002 16
SONET pointer adjustments on all the STS-1s contained within them or a
higher order SONET signal passing through them. Alternatively, if
they perform the pointer
adjustments 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. TDM
technology. Transparent multiplexing and switching can also be
viewed as a constraint, since some multiplexers and switches may

Bernstein, Mannie, Sharma Expires May 2001 18

draft-bms-sdhsonet-mpls-control-frmwrk-00.txt November 2000 not
switch at with as fine a granularity as others. Table 4 summarizes the
levels of SONET/SDH transparency.

Table 4. SONET/SDH transparency types and their properties.

Transparency Type Comments

Path Layer (or Line Standard higher order SONET path
Terminating) switching. Line overhead is terminated
or modified.

Line Level (or Section Preserves line overhead and switches the
Terminating) the entire line multiplex as a whole.
Section overhead is terminated or
modified.

Section layer Preserves all section overhead, basically
Basically does not touch any of the
SONET/SDH bits.

6.2. Protection

SONET and SDH networks offer a variety of protection options at both
the SONET line (SDH multiplex section) and SONET SONET/SDH path level.
level[5][6]. Standardized SONET line level protection techniques
include Linear 1+1 and Linear 1:N automatic protection switching
(APS) and both two-fiber and four-fiber bi-
directional bi-directional line switched
rings (BLSRs). 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 that line is not being used, i.e., when it is not carrying
traffic for a failed working line. These protection methods are
summarized in Table 5. It should be noted that these protection
methods are completely separate of from any MPLS layer protection or
restoration mechanisms.

Table 5. Common SONET/SDH protection mechanisms.

Protection Type Extra Comments
Traffic
Optionally

Bernstein, Mannie, Sharma Informational - January 2002 17
Supported

1+1 No Requires no coordination
Unidirectional between the two ends of the
circuit. Dedicated
protection line.

1+1 Bi- No Coordination via K byte
directional protocol. Lines must be
consistently configured.
Dedicated protection line.

1:1 Yes Dedicated protection.

1:N Yes One Protection line shared

Bernstein, Mannie, Sharma Expires May 2001 19

draft-bms-sdhsonet-mpls-control-frmwrk-00.txt November 2000
by N working lines. N @
1
4

4F-BLSR (4 Yes Dedicated protection, with
fiber bi- alternative ring path.
directional
line switched
ring)

2F-BLSR (2 Yes Dedicated protection, with
fiber bi- alternative ring path
directional
line switched
ring)

UPSR (uni- No Dedicated protection via
directional alternative ring path.
path switched Typically used in access
ring) networks.

It may be desirable to route some connections over lines that
support protection of a given type, while others may be routed over
unprotected lines, or as "extra data" traffic" over protection lines. Also
Also, to assist in the configuration of these various protection
methods it can be extremely valuable to advertise the link
protection attributes in the route routing protocol. For example suppose
that a 1:N protection group is being configured via two nodes. One
must make sure that the lines are "numbered the same" with respect
to both end ends of the connection or else the APS (K1/K2 byte) protocol
will not correctly operate.

Table 6. Parameters defining protection mechanisms.

Protection Comments
Related Link

Bernstein, Mannie, Sharma Informational - January 2002 18
Information

Protection Type Indicates which of the protection types
delineated in Table 5.

Protection Indicates which of several protection
Group Id groups (linear or ring) that a node belongs
to. Must be unique for all groups that a
node participates in

Working line Important in 1:N case and to differentiate
number between working and protection lines

Protection line Used to indicate if the line is a
number protection line.

Extra Traffic Yes or No
Supported

Layer If this protection parameter is specific to

Bernstein, Mannie, Sharma Expires May 2001 20

draft-bms-sdhsonet-mpls-control-frmwrk-00.txt November 2000
SONET then this parameter is unneeded,
otherwise it would indicate the signal
layer that the protection is applied.

How much information to disseminate

An open issue concerning protection is an open
issue with the extent of information
regarding protection that must be disseminated. The contents of
Table 6 representing represent one extreme and a whilea simple enumerated list of:
Extra-Traffic/Protection line, Unprotected, Shared (1:N)/Working
line, Dedicated (1:1, 1+1)/Working Line, Enhanced (Ring) /Working
Line, representing represents the other.

There is also a potential implication for link bundling, that is,
for each link, the routing protocol could advertise whether it that
link is a working or protection link and possibly some parameters
from Table 6. A possible drawback of this scheme is that the routing
protocol would be burdened with advertising properties even for
those protection links in the network that could not not, in fact fact, be
used for routing working traffic, e.g., dedicated protection links.
An alternative method, would be to bundle the working and protection
links together together, and advertise the bundle instead. Now, for each
bundled link, the protocol would have to advertise the amount of
bandwidth available on its working links, as well as the amount of
bandwidth available on those protection links within the bundle that
were capable of carrying "extra traffic." This would reduce the
amount of information to be advertised. An issue here would be to
decide which types of working and protection links to bundle
together. For instance, it might be preferable to bundle working

Bernstein, Mannie, Sharma Informational - January 2002 19
links (and their corresponding protection links) that are "shared"
protected separately from working links that are "dedicated"
protected.

6.3. Available Capacity Advertisement

Internally to each

Each SDH/SONET LSR interface, a must maintain an internal table is maintained
indicating per interface
that indicates each signal allocated in the multiplex structure. structure that is
allocated at that interface. This internal table is the most
complete and accurate view of the link usage and available capacity.

This

For use in path computation, this information needs to be advertised
in some way to all others SONET/SDH LSRs in the same domain for use in path computation. . There
is a trade off to be reached concerning: the amount of detail in the
available capacity information to be reported via a link state
routing protocol, the frequency or conditions under which this
information is updated, the percentage of connection establishments
that are unsuccessful on their first attempt, attempt due to the granularity
of the advertised information, and the extent to which network
resources can be optimized. There are different levels of
summarization that are being considered today for the available
capacity information. At one
extreme extreme, all signals that are allocated
on an interface could be

Bernstein, Mannie, Sharma Expires May 2001 21

draft-bms-sdhsonet-mpls-control-frmwrk-00.txt November 2000 advertised, or on while at the other extreme, an a
single aggregated value of the available bandwidth per link could be
advertised.

Consider first the relatively simple structure of SONET and its most
common current and planned usage. DS1s and DS3s are the signals most
often carried within a SONET STS-1. Either a single DS3 occupies
the STS-1 or up to 28 DS1s (4 each within the 7 VT groups) are
carried within the STS-1. With a reasonable VT1.5 placement
algorithm within each node it may be possible to just report on
aggregate bandwidth usage in terms of number of whole STS-1s
(dedicated to DS3s) used and the number of STS-1s dedicated to
carrying DS1sallocated DS1s allocated for this purpose. . This way a network
optimization program could try to determine the optimal placement of
DS3s and DS1s to minimize wasted bandwidth due to half-empty STS-1s
at various places within the transport network. Similarly consider
the set of super rate SONET signals (STS-Nc). If the links between
the two switches support flexible concatenation then the reporting
is particularly straightforward since any of the STS-1s within an
STS-M can be used to comprise the transported STS- Nc. However, if
only standard concatenation is supported then reporting gets
trickier since there are constraints on where the STS-1s can be
placed. SDH has still more options and constraints constraints, hence it is not
yet clear yet which is the best way to advertise bandwidth resource
availability/usage in SONET/SDH. However, due to the multiplexed
nature of the signals reporting of bandwidth particular to signal
types rather than as a single aggregate bit rate is highly
desirable.

Bernstein, Mannie, Sharma Informational - January 2002 20
6.4. Path Computation

Although a link state route routing 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 links must be capable of supporting the desired signal type
and that capacity must be available to carry the signal. Other
constraints may include hop count, total delay (mostly propagation),
and hop count. In underlying protection.In addition, it may be desirable to route
traffic in order to optimize overall network capacity, or
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 of this along the line lines of global or
local optimization of the network. network in time.

Due to the complexity of some of the route connectionrouting algorithms
(high
dimensionality dimensionality, non-linear integer programming problems) and
various criteria by which one may optimize their network a 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 for
use during restoration situations. Such an approach is in line
with the use of

Bernstein, Mannie, Sharma Expires May 2001 22

draft-bms-sdhsonet-mpls-control-frmwrk-00.txt November 2000 MPLS for traffic engineering engineering, but is much
different than typical OSPF or IS-IS usage where all nodes must
run the same route algorithm.

6.5. Link Bundling in Routing: Reducing Adjacencies

A brief mention is in order here about how the SDH/SONET links can
be advertised in routing protocols. We have alluded to routing
issues before, but a point worth advertising that link bundling may
be used to announce bundles of SDH/SONET links. This would
considerably reduce the amount of information advertised in routing,
as well as the number of IP addresses actually consumed by SDH/SONET
links and interfaces. Furthermore, bundled links could, in turn, be
advertised in IGP routing tables as forwarding adjacencies (Fas) for
use by subsequent lower speed circuits.

While the issue of exactly how to bundle links and the specifics of
how to advertise them have received attention in the IETF for
packet-based links, some of the details of this process, especially
for SDH/SONET networks is still under study. algorithm.

7. LSP Provisioning/Signaling for SDH/SONET

Traditionally, end-to-end circuit connections in SDH/SONET networks
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". As discussed in Section 2,
a common signaling protocol, such as RSVP with TE extensions or CR-
LDP appropriately extended for circuit switching applications, could
therefore help to solve these interoperability problems. In this
section, we examine the various components involved in the automated
provisioning of SONET/SDH LSPs and the associated signaling. LSPs.

7.1.1. What do we Label in SDH/SONET? Frames or Circuits?

MPLS was initially introduced to control asynchronous technologies
like IP, where a label was attached to each individual block of
data, such as an IP packet or a Frame Relay frame. SONET and SDH,

Bernstein, Mannie, Sharma Informational - January 2002 21
however, are synchronous technologies that define a multiplexing
structure (see Section 1.2), 3.2), which we referred to as the SDH (or
SONET) multiplex in Section 1.2. multiplex. This multiplex involves a hierarchy of signals,
lower order signals embedded within successive higher order ones
(see Fig. 1). Thus, depending on its level in the hierarchy, each
signal consists of frames that repeat periodically, with a certain
number of byte time slots per frame, and these signals can be
controlled using MPLS.

Bernstein, Mannie, Sharma Expires May 2001 23

draft-bms-sdhsonet-mpls-control-frmwrk-00.txt November 2000 frame.

The question then arises: is it these frames that we label in MPLS? GMPLS?
It will be seen in what follows that we do not consider that each SONET or SDH "frame" has
need not have its own label and that we label, nor is it necessary to switch frames
individually. Rather, the unit that is switched is a "flow"
comprised of a continuous sequence of time slots that appear at a
given position in such a frame. That is, we switch an individual SONET or
SDH signal, with and a label associated with each given signal.

For instance, the payload of an SDH STM-1 frame does not fully
contain a complete unit of user data. In fact, the user data is
contained in a virtual container (VC) that is allowed to float over
two contiguous frames for synchronization purposes. A pointer in the
Section Overhead (SOH) indicates the beginning of the VC in the
payload. Thus, frames are now inter-related, since each consecutive
pair may share a common virtual container. From the point of view of
MPLS,
GMPLS, therefore, it is not the successive frames that are treated
independently or labeled, but rather the entire user signal. An
identical argument applies to SONET.

Observe also that the MPLS GMPLS signaling used to control the SDH/SONET
multiplex must honor its hierarchy. In other words, the SDH/SONET
layer should not be viewed as homogeneous and flat, because this
would limit the scope of the services that it SDH/SONET can provide.
Instead,
MPLS GMPLS tunnels should be used to dynamically and
hierarchically control the SDH/SONET multiplex. For example, one
unstructured VC-4 LSP may be established between two nodes, and
later lower order LSPs (e.g. VC-12) may be created within that
higher order LSP. This VC-4 LSP can, in fact, be established
between two non-adjacent internal nodes in an SDH network, and
later advertised by a routing protocol as a new (virtual) link
called a Forwarding Adjacency (FA).

A SONET/SDH-LSR will have to identify each possible signal
individually per interface to fulfill the MPLS GMPLS operations. In order
to stay transparent the LSR obviously should not touch the SONET/SDH
overheads; this is why an explicit label is not encoded in the
SDH/SONET overheads. Rather, a label is associated with each
individual signal. This approach is similar to the one considered
for lambda switching, except that it is more complex, since SONET
and SDH define a richer multiplexing structure. Therefore a label
is associated with each signal, and is local and locally unique for each
signal at each interface. This signal could, and will most probably,
occupy different time-slots at different interfaces.

Bernstein, Mannie, Sharma Informational - January 2002 22
7.2. Label Structure in SDH/SONET

The signaling protocol used to establish an SDH/SONET LSP must have
specific information elements in it to map a label to the particular
signal type that it represents represents, and to the position of that signal
in the SONET/SDH multiplex. As we will see shortly, however, with a
carefully chosen label structure, the label itself can be made to
function as this information element.

Bernstein, Mannie, Sharma Expires May 2001 24

draft-bms-sdhsonet-mpls-control-frmwrk-00.txt November 2000

In general, there are two ways to assign labels for signals between
neighboring SDH/SONET LSRs. One way is for the labels to be
allocated completely independently of any SDH/SONET semantics; e.g.
labels could just be unstructured 16 or 32 bit numbers. In that
case, in the absence of appropriate binding information, a label
gives no visible information about the flow that it represents. From
a management and debugging point of view, therefore, it becomes
difficult to match a label with the corresponding signal, since , as
we saw in Section 4.1.1, 7.1.1, the label is not coded in the SDH/SONET
overhead(s)of
overhead of the signal.

Another way is to use the well defined welldefined and finite structure of the
SDH/SONET multiplexing tree to devise a clever signal numbering scheme that
makes use of the multiplex as a naming tree, and assigns each
multiplex entry a unique associated value. This allows the
unequivocal unique
identification of each multiplex entry (signal) in terms of its type
and position in the multiplex tree. By using this multiplex entry
value itself as the label, we automatically add SDH/SONET semantics
to the label! Thus, simply by examining the label, one can now
directly deduce the signal that it represents, as well as its
position in the SDH/SONET multiplex. We refer to this as
multiplex-based labeling. This is the idea that was incorporated in
the GMPLS signaling specifications.

In the following sections, we look at this label structure in more
detail.

7.2.1. SDH/SONET Multiplex Entry Name

We will use the SDH multiplex, defined in recommendation G.707
Figure 6-1, as the basic reference to identify signals. It defines a
tree, whose root is an STM-Nsignal, and whose leaves are the signals
that can be transported (hierarchically) within the STM-N. This tree
will be used as a naming tree to create unique multiplex entry
values as discussed in the previous subsection. This entry will
identify at the same time the type of signal and its position in the
multiplex. Figure 1 shows the SDH and SONET multiplexes.

The possible leaves of that tree are VC-4, VC-3, VC-2, VC-12 or VC-
11. According to the multiplex structure there is a maximum of 1 VC-
4, 3 VC-3s, 21 VC-2s, 63 VC-12s or 84 VC-11s in one STM-1. Of
course, different VCs may be combined according to the combination
rules of the SDH multiplex.

A maximum of 172 (1+3+21+63+84) different signals, therefore, may be
identified in one STM-1. Although some of them use the same
physical space, and are therefore incompatible, for simplicity we
will give a unique name to each of them. For that purpose we extend
the well-known (K, L, M) numbering scheme defined in G.707 section
7.3..N STM-1 signals may be interleaved together to form an STM-
Nsignal. It results that we must identify the STM-1 that is itself
decomposed in sub-signals. We discuss concatenation in Section 4.3.

Bernstein, Mannie, Sharma Expires May 2001 25

draft-bms-sdhsonet-mpls-control-frmwrk-00.txt November 2000

This method is directly applicable to SONET as shown in Fig. 1,
since the SONET multiplex can be seen as a sub-tree of the SDH
multiplex tree.

7.2.2. SDH/SONET Multiplex Entry Notation

We propose the - following hierarchical multiplex entry notation:

(S, U, K, L, M) or S.U.K.L.M (in dot notation), where

S: 1 -> N : indicates a specific STM-1/STS-1 inside an STM-N/STS-
N multiplex.

U: 0 -> 4 : index of an SDH Administrative Unit (AU-4 or AU-3).
K: 0 -> 4 : index indicating the content of a VC-4.
L: 0 -> 8 : index indicating the content of a TUG-3, VC-3 or STS-
1 SPE.

M: 0 -> 10 : index indicating the content of a TUG-2 or VT Group.

Each letter indicates a possible branch number starting at the
parent node in the naming tree. Branches are numbered in the
increasing order, starting from the top of the naming tree. The
numbering starts at 1, and zero is used to indicate a non-
significant field.

S is the index of a particular STM-1/STS-1. S=1->N indicates a
specific STM-1/STS-1 inside an STM-N/STS-N multiplex. For example,
S=1 indicates the first STM-1/STS-1, and S=N indicates the last STM-
1/STS-1 of this multiplex.

U is only significant for SDH and must be ignored for SONET. It
indicates a specific VC inside a given STM-1. U=1 indicates a single
VC-4, while U=2->4 indicates a specific VC-3 inside the given STM-1.

K is only significant for SDH and must be ignored for SONET. It
indicates a specific branch of a VC-4. K=1 indicates that the VC-4
is not further sub-divided and contains a C-4. K=2->4 indicates a
specific TUG-3 inside the VC-4. K is not significant when the STM-1
is divided into VC-3s (and is easy to read and test).

L indicates a specific branch of a TUG-3, VC-3 or STS-1 SPE. It is
not significant for an unstructured VC-4. L=1 indicates that the
TUG-3/VC-3/STS-1 SPE is not further sub-divided and contains a VC-
3/C-3 in SDH or the equivalent in SONET. L=2->8 indicates a specific
TUG-2/VT Group inside the corresponding higher order signal.

M indicates a specific branch of a TUG-2/VT Group. It is not
significant for an unstructured VC-4, TUG-3, VC-3 or STS-1 SPE. M=1
indicates that the TUG-2/VT Group is not further sub-divided and
contains a VC-2/VT-6. M=2->3 indicates a specific VT-3 inside the
corresponding VT Group, these values MUST NOT be used for SDH since

Bernstein, Mannie, Sharma Expires May 2001 26

draft-bms-sdhsonet-mpls-control-frmwrk-00.txt November 2000

there is no equivalent of VT-3 with SDH. M=4->6 indicates a specific
VC-12/VT-2 inside the corresponding TUG-2/VT Group. M=7->10
indicates a specific VC-11/VT-1.5 inside the corresponding TUG-2/VT
Group. Note that M=0 denotes an unstructured VC-4, VC-3 or STS-1 SPE
(easy for debugging).

SDH SONET

unstructured VC-4/VC-3 unstructured STS-1 SPE

VC-2 VT-6
1st VT-3
2nd VT-3
1st VC-12 1st VT-2
2nd VC-12 2nd VT-2
3rd VC-12 3rd VT-2
1st VC-11 1st VT-1.5
2nd VC-11 2nd VT-1.5
3rd VC-11 3rd VT-1.5
4th VC-11 4th VT-1.5
Table 7. Encoding of the M field in the SDH/SONET multiplex entry.

This may be illustrated with the following examples.

Example 1: S>0, U=1, K=1, L=0, M=0
Denotes the unstructured VC-4 of the Sth STM-1.

Example 2: S>0, U=1, K>1, L=1, M=0
Denotes the unstructured VC-3 of the Kth-1 TUG-3 of the Sth STM-1.

Example 3: S>0, U=0, K=0, L=0, M=0
Denotes the unstructured STS-1 SPE of the Sth STS-1.

Example 4: S>0, U=0, K=0, L>1, M=1
Denotes the VT-6 in the Lth-1 VT Group in the Sth STS-1.

Example 5: S>0, U=0, K=0, L>1, M=9
Denotes the 3rd VT-1.5 in the Lth-1 VT Group in the Sth STS-1.

7.2.3. SDH/SONET Multiplex Entry Encoding:

A multiplex entry name may be used directly as a label, or may be
used in an information element of a signaling protocol to associate
a label with the corresponding multiplex entry (signal). In both
cases, a multiplex entry can be coded as described in Figure 3 .This
coding has also been proposed for the SDH/SONET labels in GMPLS.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Bernstein, Mannie, Sharma Expires May 2001 27

draft-bms-sdhsonet-mpls-control-frmwrk-00.txt November 2000

| S | U | K | L | M |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The current SDH standards only allow N to take the discrete values
0, 1, 4, 16 or 64. Today, in practice all of them are used: STM-0
(51.840 Mb/s), STM-1 (155.52 Mb/s), STM-4 (622.08 Mb/s), STM-16
(2488.32 Mb/s) and STM-64 (9953.26 Mb/s). In the future, it is
likely that N will grow up to 256 or 1024. This fixes the number of
possible different multiplex entry names to 1024 x 172 = 176128.
Note that an SDH LSR does not need to maintain a table of this
size, it just needs to maintain a list of multiplex entries that it
has allocated at any given time.

7.2.4. Hierarchical Label Allocation:

At any particular point in time, a given position in the SDH/SONET
multiplex may either be a valid position or not, according to the
signals already allocated, and if valid, may either be used or be
free. Thus, a multiplex entry (time-slot) must be interpreted in
relation tothe already allocated multiplex entries (time-slots).

The fact that two neighboring SDH/SONET LSRs allocate a label for a
particular LSP implies that the corresponding time-slot will be
enabled in the multiplex between the two LSRs. When an SDH/SONET LSP
is removed, the corresponding local label is released, and the
corresponding multiplex space may be re-used. An MPLS conservative
label retention mode must be implemented when using multiplex based
labeling.

For instance, for a downstream-on-demand label allocation, the
upstream LSR must indicate the type of signal it wants to forward.
The downstream SDH-LSR must check if such a signal is available in
its multiplex, and, if it is available, return the corresponding
label. With multiplex-based labeling, the upstream SDH/SONET LSR
can easily verify if the right type of signal was allocated by the
downstream SDH/SONET LSR , just by looking at the label.

In this case, the downstream SDH-LSR is applying a straightforward
SDH/SONET call admission control (CAC) function based on the space
available in the multiplex. Note that the two SDH/SONET LSRs should
have identical multiplex tables, so that even before requesting a
label, the upstream SDH/SONET LSR could even check its own multiplex
table for that particular interface, to see if space is available
for that signal.

The two neighboring SDH/SONET LSRs could also have a mechanism to
periodically check if their multiplex tables are identical, i.e.
fully synchronized. This can be achieved through the MPLS signaling
simply by exchanging the complete multiplex tables or the list of
currently allocated signals (labels). If the neighboring SDH-LSRs
discover that their multiplex tables are not identical, a fault
should immediately be triggered to alert a NMS

Bernstein, Mannie, Sharma Expires May 2001 28

draft-bms-sdhsonet-mpls-control-frmwrk-00.txt November 2000

Note that since an SDH-LSR may have a neighbor relationship at
different levels of the SDH/SONET hierarchy, the multiplex table
that is common between two neighboring SDH/SONET LSRs should be
understood in the context of that relationship. That is,
neighboring SDH-LSRs should compare only the list of LSPs that they
negotiated as peers at a particular level of the hierarchy

For instance, in Figure 3 (please refer to pdf document; available
from authors), SDH/SONET LSR2 and SDH/SONET LSR3 may have an
unstructured VC-4 established between them, while SDH/SONET LSRs 1
and 4 may have a VC-12 established within that VC-4. If LSR2 and
LSR21 compare their multiplex tables, LSR2 must ensure that is sends
just the view that LSR21 has of the multiplex. For example, LSR21
knows nothing about the contents of the VC-4, and so should not be
sent information about it. specifications [7].

7.3. Signaling Elements

In the preceding sections, we defined the meaning of a SDH/SONET
label and specified its structure. A question that arises naturally
at this point is the following. In an LSP or connection setup
request, how do we specify the signal for which we want to establish
a path (and for which we desire a label)?

Clearly, information that is required to completely specify the
desired signal and its characteristics must be transferred via the
label distribution protocol, so that the switches along the path can
be configured to correctly handle and switch the signal. As we
explain ahead, this This
information is specified in three parts, each of which refers to a
different network layer.

The first specifies the nature/type of the LSP or the desired
SDH/SONET channel, in terms of the particular signal (or collection
of signals) within the SDH/SONET multiplex that the LSP represents,
and is used by all the nodes along the path of the LSP.

Bernstein, Mannie, Sharma Informational - January 2002 23
The second specifies the payload carried by the LSP or SDH/SONET
channel, in terms of the termination and adaptation functions
required at the end points, and is used by the source and
destination nodes of the LSP.

The third specifies certain link selection constraints, which
control, at each hop, the selection of the underlying link that is
used to transport this LSP.
In the following subsections, we discuss each of these in more
detail.

7.3.1. Nature of the LSP: LSP Encoding Type, Signal Type, and
Connection Bundling

The nature of the SDH/SONET signal is specified collectively by the
LSP encoding type and signal type fields, which identify (via
appropriate rules) the specific connection point types on a
particular interface/port that may be used to switch this signal or
LSP. Another element specifying the nature of the desired LSP is the

Bernstein, Mannie, Sharma Expires May 2001 29

draft-bms-sdhsonet-mpls-control-frmwrk-00.txt November 2000

extent, if any, of connection grouping, which is specified by a
combination of two fields that denote respectively, the type of
grouping requested by the LSP and the number of components in that
grouping.

Recall that in TDM networks, the link connection points (or the
type of signals within a SDH/SONET multiplex that the link can
switch) provided by a link are limited to a fixed, discrete set.
Thus, the link connection points that are suitable for carrying a
given LSP are limited to those that match the LSP type and the
signal type, or to which the LSP type and signal type can be readily
adapted (by mapping to a container).

7.3.1.1. LSP Encoding Type and Signal Type

In particular, the LSP encoding type indicates the technology of the
LSP being requested, and includes, for example, ANSI PDH, ETSI PDH,
SDH, and SONET. The signal type field indicates the specific signal
type of the LSP being requested, and is interpreted in the context
of the technology specified in the LSP encoding type. Thus, the
signal type provides transit switches with information required to
determine the connection point types (timeslots/labels) that can
suppor t this LSP. As an example, the permitted LSP encoding types
with their permitted signal types for SDH are shown in Table 8. A
detailed discussion of the encoding types appears in [7].

LSP Encoding Type Signal Type

SDH
1 VC-11
2 VC-12
3 VC-2
4 TUG-2
5 VC-3
6 TUG-3
7 VC-4
8 STM-1
9 STM-1 MS
10 STM-1 RS
12 STM-4
13 STM-4 MS
14 STM-4 RS
16 STM-16
17 STM-16 MS
18 STM-16 RS
20 STM-64
21 STM-64 MS
22 STM-64 RS
24 STM-256
25 STM-256 MS
26 STM-256 RS

Bernstein, Mannie, Sharma Expires May 2001 30

draft-bms-sdhsonet-mpls-control-frmwrk-00.txt November 2000

Table 8 Permitted LSP encoding types and their corresponding signal
types for SDH.

By way of example, a DS3 LSP can be supported by link connections of
type DS3, or by link connections of type STS-1, if a DS3/STS-1
adaptation function is available at the source (and a corresponding
one is available at the destination of the DS3 LSP). A DS3 LSP
cannot, for instance, be routed on link connections of type VT1.5,
no matter how many are available, since the associated links do not
have the capability to switch DS3 signals. Therefore the LSP
encoding type and signal type are fundamental in indicating the
nature of the LSP requested, and in enabling the determination of
which available link connections may carry the signal.

7.3.1.2. Connection Bundling

Since a number of non concatenated STS-1s may be routed together as
a group (that is, all contained within the same SONET line or WDM
signal) and receive essentially the same delay and propagation, they
are specified by a requested grouping type (RGT) field in GMPLS.
This denotes how many connections of a given signal type are
requested together, which ensures that they meet similar routing
constraints. Since the specific group routing constraints depend on
technology, this parameter also is interpreted in the context of the
LSP encoding type. The values for SONET/SDH are no grouping, virtual
concatenation, and continuous arbitrary concatenation (or flexible
concatenation), and continuous standard concatenation, as explained
in Section 3.1.2. For virtual concatenation, all components in the
group must be routed via the same higher order container. For
contiguous standard concatenation, there must be a standard number
of components (3, 12, 48, etc.), and they must be in one higher
order container. For contiguous arbitrary concatenation, the number
of components is arbitrary (2, 3, 4, à) and they still must be
routed in one higher order container.

Such concatenation simplifies connection establishment (especially
for batches of DS-3s that are being wholesaled) and speeds re-
routes. Since 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 be capable of incorporating the concept of STS-1 bundling. The
bundling of larger signals, i.e., groups of STS-Mc, is for further
study.

Finally, there is also a field that indicates the requested number
of components (RNT), that is, the number of identical signal types
that are requested to be grouped into an LSP, as specified in the
RGT field. All components are assumed to have identical
characteristics, of course, and the field is set to zero when no
grouping is requested.

7.3.2 Payload Type

Bernstein, Mannie, Sharma Expires May 2001 31

draft-bms-sdhsonet-mpls-control-frmwrk-00.txt November 2000

As discussed earlier, the label request must also carry an
identifier of the payload that is carried by the LSP. The payload
identifies the client layer of that LSP, is interpreted in the
context of the LSP encoding type, and is used by the end-points of
the LSP. As an example, Table 9 depicts a suggested organization of
the generalized payload identifier (GPID) values for SDH and SONET..

LSP Encoding Type Payload/Client Type

SDH Unknown
Asynchronous mapping of E4
Asynchronous mapping of DS3
Asynchronous mapping of E3
Bit synchronous mapping of E3
Byte synchronous mapping of E3
Asynchronous mapping of DS2
Bit synchronous mapping of DS2
Byte synchronous mapping of DS2
Asynchronous mapping of E1
Byte synchronous mapping of E1
Byte synchronous mapping of 31 *
DS0
Asynchronous mapping of DS1
Bit synchronous mapping of DS1
Byte synchronous mapping of DS1
ATM mapping

SONET Unknown
DS1 SF Asynchronous
DS1 ESF Asynchronous
DS3 M23 Asynchronous
DS3 C-Bit Parity Asynchronous
VT
STS
ATM
POS

Table 9. The payload type indicator in the context of the LSP
encoding type for SDH/SONET.

A value of "unknown" indicates that the payload carried by the LSP
is either unknown or not relevant to know for the end points of the
current LSP.

7.3.3. Link Protection Type

The link protection type carried in the label request indicates the
level of protection that an LSP desires on the links at each hop
along its path. In other words, the link protection is local to the
interface between two adjacent nodes, and controls how the
underlying link at a particular hop is protected. It is, therefore,
distinct from MPLS-level protection (see [12]), which involves

Bernstein, Mannie, Sharma Expires May 2001 32

draft-bms-sdhsonet-mpls-control-frmwrk-00.txt November 2000

protection of the actual LSP (which may be done either end-to-end,
via path-based protection, or locally, via bypass tunnels).

The link protection may be represented as a vector of flags, where
one or more protection levels may be turned on simultaneously. A
value of 0 implies that this connection does not care about which,
if any, link protection is used. More than one bit may be set to
indicate when multiple protection types are acceptable. When
multiple bits are set and multiple protection types are available,
the choice of protection type is a local (policy) decision. The
following flags are defined:

Extra Traffic
Indicates that links that are reserved for automatic recovery in
case of a fault elsewhere in the network may be used for this LSP.
Observe that this means that the LSP can be disrupted whenever such
a link is needed for its assigned recovery purpose. In other words,
the LSP can be dropped even if there is not fault on the links along
which this LSP is routed.

Unprotected
"Unprotected" indicates that unprotected links may be used by this
LSP. This means that the LSP will only lose service on this hop, if
there is a fault along this particular link (a fault elsewhere will
not affect this link and therefore this LSP). In other words,
"unprotected" can be regarded as a "neutral" form of protection. The
LSP does not lose service as long as the link is up, but loses
service once this link goes down, since the link itself is not
protected by a backup link.

Shared
Indicates that protected (working) links whose protection resources
are shared with some number, say N, of other working links may be
used by this LSP.

This means that if there is a fault along this particular link, the
LSP will lose service on this hop, only if the backup link is
already in use by traffic from one of the remaining N-1 working
links (due to an earlier fault on one of those links). Thus, the
"shared" option can be regarded as a better form of protection,
since the LSP is protected as long as there is no fault on any of
the remaining N-1 working links that share the same backup link.

Dedicated
Indicates that links with dedicated protection, e.g., 1:1 or 1+1
protection, may be used by this LSP.

This means that a protection link is reserved for the working link
over which this LSP is routed, so that this LSP is always protected
against any fault on its working link. Thus, the "dedicated" option
offers a higher form of link-level protection.

Enhanced

Bernstein, Mannie, Sharma Expires May 2001 33

draft-bms-sdhsonet-mpls-control-frmwrk-00.txt November 2000

Indicates that links that are multiply protected, such as via a ring
switch and a span switch in a 4-fiber BLSR/MS-SPRING.

Thus, the LPFs represent both a property of a link (which needs to
be appropriately advertised in routing), as well as a constraint on
which links may be used for a given path (which is signaled during
connection setup as specified above).

8. Choices for Control Channel Implementation

One question that we have not yet addressed is how the so-called
MPLS "control channel" is implemented?

It turns out that there are several implementation choices for the
control channel. One way is to use out-of-band (OOB) signaling. An
OOB control channel that has been implemented using a dedicated
wavelength works as follows.

The incoming signal on a fiber is first demultiplexed into the data
bearing wavelengths and the control bearing wavelength. While the
data wavelengths are switched by the cross-connect, the control
wavelength is passed to a control element, where it undergoes O/E
conversion to produce a digital bit stream. This bit stream is
interpreted and processed by the MPLS signaling/control element, and
the resulting control bits are converted via E/O conversion, back
into a optical signal that is multiplexed onto the outgoing fiber.
An alternative implementation is to use a dedicated network (such as
an IP network) as a control network connecting the controllers on
the optical elements.

An alternative to OOB signaling is to implement the control channel
using in-band signaling. Again, there are several ways to accomplish
this:

The first is to use a portion of a wavelength to carry control
information, which is useful when the number of wavlengths is
limited and it is not possible to dedicate an entire wavelength for
carrying control information. Essentially, the incoming signal is
demultiplexed into the data channels, which are switched by the
cross-connect, and the control bearing wavelength, which undergoes
O/E conversion to produce a data stream and control information. The
data stream is switched electronically while the control information
is interpreted and processed by the MPLS signaling/control element.
The resulting control bits and the data stream are both converted
back, via E/O conversion, into a optical signal that is multiplexed
onto the outgoing fiber.

A second option is to use sub-carrier modulation, modulating the
data carrying wavelength with an additional sub-carrier that carries
control information. This sub-carrier signal is split from the data
carrying wavelength, and processed (after O/E conversion) by the
MPLS signaling/control element, and then is used to re-modulate the
outgoing wavelength.

Bernstein, Mannie, Sharma Expires May 2001 34

draft-bms-sdhsonet-mpls-control-frmwrk-00.txt November 2000

A third option is to use the overhead bytes in SONET frames or
overhead bits in a digital wrapper. This requires, of course, that
all devices be O-E-O capable.

9. Summary and Conclusions

In this paper, we gave

We provided a detailed account of the issues involved in applying
MPLS-based control to TDM networks (a general overview of
these issues for applying GMPLS to optical networks appears in
[11]). networks.

We began with a brief overview of MPLS and SDH/SONET networks,
discussing current circuit establishment in TDM networks, and
arguing why SDH/SONET technologies will not be "outdated" in the
forseable
foreseeable future. We then looked at MPLS applied to SDH/SONET
networks, where we consider considered why such an application makes sense,
and reviewed some MPLS terminology as applied to TDM networks. We
then considered the two main areas of application of MPLS methods to
TDM networks, namely routing and signaling. We considered in detail
the switching capabilities of TDM equipment, and the requirement to
learn about the protection capabilities of underlying links, and at how
these influence the available capacity advertisement in TDM
networks. We focused briefly on path computation methods, pointing
out that these were not subject to standardization. We then examined
optical path provisioning or signaling, considering the issue of
what constitutes an appropriate label for TDM circuits, how this
label should be structured, and we focused on the importance of
hierarchical label allocation in a TDM network. We then reviewed the
signaling elements involved when setting up an optical TDM circuit,
focusing on the nature of the LSP, the type of payload it carries,
and the characteristics of the links that the LSP wishes to use at
each hop along its path, for achieving a certain reliability.

We believe our work provides a comprehensive overview of the issues
arising in the dynamic control of optical SDH/SONET networks, and
points to several issues that will certainly require more work and
industry consensus to realize interoperable implementations of a
dynamically controlled transport network.

10.

9. Security Considerations

This draft raises no new security issues in the MPLS specifications.

11. References

10.References

[1] Bradner, S., "The Internet Standards Process -- Revision 3",
BCP 9, RFC 2026, October 1996.

[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997

Bernstein, Mannie, Sharma Informational - January 2002 24

[3] Synchronous Optical Network (SONET) Basic Description including
Multiplex Structure, Rates, and Formats, ANSI T1.105-1995.

[4] G.707, Network Node Interface for the Synchronous Digital
Hierarchy (SDH), International Telecommunication Union, 03/96.

[5] ANSI T1.105.01-1995, Synchronous Optical Network (SONET) Transport Systems: Common
Generic Criteria, Bellcore GR-253-CORE, Issue 2, December 1995.
Synchronous Optical Opical Network (SONET) Transport Systems: Common Generic
Criteria, Bellcore GR-253-CORE, Issue 2, December 1995.
Automatic Protection Switching, American National Standards
institute.
[6] G.841, Types and Characteristics of SDH Network Protection
Architectures, ITU-T, 07/95.

[7] Peter Ashwood-Smith and Lou Berger, Editors, "Generalized MPLS:
Signaling Functional Description," Internet Draft,
draft-ietf-mpls-generalized-signaling-01.txt, Draft,draft-ietf-mpls-
generalized-signaling-04.txt, Work in Progress,
November 2000.

[7] Ben Mack-Crane, V. Sharma, Greg Bernstein, Eric May 2001.

[8] E. Mannie, et al,
Enhancements to GMPLS Signaling Editor, "GMPLS Extensions for Optical Technologies, SONET and SDH
Control", Internet Draft, draft-ietf-ccamp-gmpls-sonet-sdh-01.txt,
Work in Progress,
draft-mack-crane-gmpls-signaling-enhancements-00.txt, November 2000.

[8] June 2001.

[9] E. Mannie, Greg Bernstein "Extensions to OSPF and IS-IS in
support of MPLS for SDH/SONET Control", Internet Draft, Work in
Progress, draft-mannie-mpls-sdh-ospf-isis-00.txt, July 2000.

[9]

11.Acknowledgments

12.Author's Addresses

Greg Bernstein
Ciena Corporation
10480 Ridgeview Court
Cupertino, CA 94014
Phone: +1 510 573-2237
E-mail: greg@ciena.com

Eric Mannie
EBONE
Terhulpsesteenweg 6A
1560 Hoeilaart - Belgium
Phone: +32 2 658 56 52
Mobile: +32 496 58 56 52
Fax: +32 2 658 51 18
E-mail: eric.mannie@ebone.com

Bernstein, "Some Comments on the Use of MPLS Traffic
Engineering for SONET/SDH Path Establishment", Internet Draft, Work in
Progress, draft-bernstein- mpls-sonet-00.txt, March 2000.

[10] E. Mannie, "MPLS for SDH Control", Sharma Informational - January 2002 25
Vishal Sharma
Metanoia, Inc.
335 Elan Village Lane, Unit 203
San Jose, CA 95134
Phone: +1 408 943 1794
Email: v.sharma@ieee.org

Bernstein, Mannie, Sharma Informational - January 2002 26
Full Copyright Statement

"Copyright (C) The Internet Draft, Work Society (date). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in
Progress, draft-mannie-mpls-sdh- control-00.txt. March 2000.

[11] Greg Bernstein its implmentation may be prepared, copied, published
and Vishal Sharma, Some Comments distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on GMPLS all such copies and
Optical Technologies, Internet Draft, Work derivative works. However, this
document itself may not be modified in Progress,
draft-bernstein-gmpls-optical-00.txt, November 2000.

[12] Vas Makam, V. Sharma, Ben Mack-Crane, et al, Framework any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for
MPLS-based Recovery, the purpose of
developing Internet Draft, Work standards in Progress,
draft-ietf-mpls-recovery-frmwrk-00.txt, September 2000. which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into

Bernstein, Mannie, Sharma Expires May 2001 35 Informational - January 2002 27
Bernstein, Mannie, Sharma Informational - January 2002 28