information is entered manually, it remains error prone.
A link state GMPLS routing protocol, on the other hand, could perform
automatic topology discovery and disseminate the topology as well as
resource status. This information would be available to all nodes in
the 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 link state routing protocol
applied to the SDH/SONET network does not have any service impacting
implications. This is because in the SDH/SONET case, the circuit is
source-routed (so there can be no loops), and no traffic is
transmitted until a circuit has been established and an
acknowledgement received at the source.
1.4.2. Path Computation (Route Determination)
In the SDH/SONET case, unlike the IP datagram case, there is no need
for network elements to all perform the same path calculation [6].
In addition, path determination is an area for vendors to provide a
potentially significant value addition in terms of network
efficiency, reliability, and service differentiation. In this sense,
a centralized approach to path computation may be easier to operate
and upgrade. For example, new features such as new types of path
diversity or new optimization algorithms can be introduced with a
simple NMS software upgrade. On the other hand, updating switches
with new path computation software is a more complicated task. In
addition, many of the algorithms can be fairly computationally
intensive and 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 element can be particularly useful
for restoring traffic during major network faults.
1.4.3. Connection Establishment (Provisioning)
The actual setting up of circuits, i.e., a coupled collection of
cross connects across a network, can be done either via the NMS
setting up individual cross connects or via a "soft permanent LSP"
(SPLSP) type approach. In the SPLSP approach, the NMS may just kick
off the connection at the "ingress" switch with GMPLS signaling
setting up the connection from that point onward. Connection
establishment is the trickiest part to distribute, however, since
errors in the connection setup/tear down process are service
impacting.
The table below compares the two approaches to connection
establishment.
Table 1. Qualitative comparison between centralized and distributed
approaches.
Distributed approach Centralized approach
Packet-based control plane Management plane like TMN or
(like GMPLS or PNNI) useful? 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
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
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
1.5. Why SDH/SONET Will Not Disappear Tomorrow
As IP traffic becomes the dominant traffic transported over the
transport infrastructure, it is useful to compare the statistical
multiplexing of IP with the time division multiplexing of SDH and
SONET.
Consider, for instance, a scenario where IP over WDM is used
everywhere and lambdas are optically switched. In such a case, a
carrier’s carrier would sell dynamically controlled lambdas with each
customers building their own IP backbones over these lambdas.
This simple model implies that a carrier would sell lambdas instead
of bandwidth. The carrier’s goal will be to maximize the number of
wavelengths/lambdas per fiber, with each customer having to fully
support the cost for each end-to-end lambda whether or not the
wavelength is fully utilized. Although, in the near future, we may
have technology to support up to several hundred lambdas per fiber, a
world where lambdas are so cheap and abundant that every individual
customer buys them, from one point to any other point, appears an
unlikely scenario today.
More realistically, there is still room for a multiplexing technology
that provides circuits with a lower granularity than a wavelength.
(Not everyone needs a minimum of 10 Gbps or 40 Gbps per circuit, and
IP does not yet support all telecom applications in bulk
efficiently.)
SDH and SONET possess a rich multiplexing hierarchy that permits
fairly fine granularity and that provides a very cheap and simple
physical separation of the transported traffic between circuits,
i.e., QoS. Moreover, even IP datagrams cannot be transported
directly over 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 Dense WDM (DWDM) is
defined in RFC1619/RFC2615 and is known as POS (Packet Over
SDH/SONET), i.e., IP over PPP (in High-Level Data Link Control
(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 Gigabit Ethernet (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 results in only 6% overhead.
Any encapsulation of IP over WDM should, in the data plane, at least
provide the following: error monitoring capabilities (to detect
signal degradation); error correction capabilities, such as FEC
(Forward Error Correction) that are particularly needed for ultra
long haul transmission; and sufficient timing information, to allow
robust synchronization (that is, to detect the beginning of a
packet). In the case where associated signaling is used (that is,
where the control and data plane topologies are congruent), the
encapsulation should also provide the capacity to transport
signaling, routing, and management messages, in order to control the
optical switches. Rather, SDH and SONET cover all these aspects
natively, except FEC, which tends to be supported in a proprietary
way. (We note, however, that associated signaling is not a
requirement for the GMPLS-based control of SDH/SONET networks.
Rather, it is just one option. Non associated signaling, as would
happen with an out-of-band control plane network is another equally
valid option.)
Since IP encapsulated in SDH/SONET is efficient and 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, and optical 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. What we are
arguing here is that it makes sense to do switching or forwarding at
all these layers.
2. GMPLS Applied to SDH/SONET
2.1. Controlling the SDH/SONET Multiplex
Controlling the SDH/SONET multiplex implies deciding which of the
different switchable components of the SDH/SONET multiplex we wish to
control using GMPLS. Essentially, every SDH/SONET element that is
referenced by a pointer can be switched. These component signals are
the VC-4, VC-3, VC-2, VC-12, and VC-11 in the SDH case; and the VT
and STS SPEs in the SONET case. The SPEs in SONET do not have
individual names, although they can be referred to simply as VT-N
SPEs. We will refer to them by identifying the structure that
contains them, namely STS-1, VT-6, VT-3, VT-2, and 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, however
SDH’s VC-4 corresponds to SONET’s STS-3c SPE.
In addition, it is possible to concatenate some of the structures
that contain these elements to build 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 GMPLS. SDH also
defines virtual (non-contiguous) concatenation of TU-2s; however, in
that case, each constituent VC-2 is switched individually.
2.2. SDH/SONET LSR and LSP Terminology
Let an SDH or SONET Terminal Multiplexer (TM), Add-Drop Multiplexer
(ADM), or cross-connect (i.e., a switch) be called an SDH/SONET LSR.
An SDH/SONET path or circuit between two SDH/SONET LSRs now becomes a
GMPLS LSP. An SDH/SONET LSP is a logical connection between the
point at which a tributary signal (client layer) is adapted into its
virtual container, and the point at which it is extracted from its
virtual container.
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 is possible with SDH/SONET signals.
To facilitate the signaling and setup of SDH/SONET circuits, an
SDH/SONET LSR must, therefore, 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 LSP and
therefore not all of them need be identified. In fact, only those
signals that can be switched need identification.
3. Decomposition of the GMPLS Circuit-Switching Problem Space
Although those familiar with GMPLS may be familiar with its
application in a variety of application areas (e.g., ATM, Frame
Relay, 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 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 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
protected versus 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 would
have to be distributed via the link state 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,
this information can be thought of as the "virtual" label. For
example, in SONET networks, when distributing information to switches
concerning an 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 those two switches). Hence, the multiplex entry number in
this case can be used as a virtual label. Note that 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
locally on the link between the two switches.
(iii) Information that all switches in the path need to know about a
circuit will also be distributed via the label distribution protocol.
Examples of such information include bandwidth, priority, and
preemption.
(iv) Information intended only for end systems of the connection.
Some of the payload type information may fall into this category.
4. GMPLS Routing for SDH/SONET
Modern SDH/SONET transport networks excel at interoperability in the
performance monitoring (PM) and fault management (FM) areas [7], [8].
They do not, however, interoperate in the areas of topology discovery
or resource status. Although link state routing protocols, such as
IS-IS and OSPF, have been used for some time in the IP world to
compute destination-based next hops for routes (without routing
loops), they are particularly valuable for providing timely topology
and network status information in a distributed manner, i.e., at any
network node. If resource utilization information is disseminated
along with the link status (as done in ATM’s PNNI routing protocol),
then a very complete picture of network status is available to a
network operator for use in planning, provisioning, and operations.
The information needed to compute the path a connection will take
through a network is important to distribute via the routing
protocol. In the TDM 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. This is what is being
proposed in the GMPLS extensions to IP routing protocols [9], [10],
[11].
When applying routing to circuit switched networks, it is useful to
compare and contrast this situation with the datagram routing case
[12]. In the case of routing datagrams, all routes on all nodes must
be calculated exactly the same to avoid loops and "black holes". In
circuit switching, this is not the case since routes are 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 because, to accommodate the optical
layer, routing protocols need to be supplemented with new
information, as compared to the datagram case. This information is
also likely to be used in different ways for implementing different
user services. Due to the increase in information transferred in the
routing protocol, it may be useful to separate the relatively static
parameters concerning a link from those that may be subject to
frequent changes. However, the current GMPLS routing extensions [9],
[10], [11] do not make such a separation.
Indeed, from the carriers’ perspective, the up-to-date dissemination
of all link properties is essential and desired, and the use of a
link-state routing protocol to distribute this information provides
timely and efficient delivery. If GMPLS-based networks got to the
point that bandwidth updates happen very frequently, it makes sense,
from an efficiency point of view, to separate them out for update.
This situation is not yet seen in actual networks; however, if GMPLS
signaling is put into widespread use then the need could arise.
4.1. Switching Capabilities
The main switching capabilities that characterize an SDH/SONET end
system and thus need to be advertised via the link state routing
protocol are: the switching granularity, supported forms of
concatenation, and the level of transparency.
4.1.1. Switching Granularity
From references [2], [3], and the overview section on SDH/SONET we
see that there are a number of different signals that compose the
SDH/SONET hierarchies. Those signals that are referenced via a
pointer (i.e., the VCs in SDH and the SPEs in SONET) will actually be
switched within an SDH/SONET 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, STS-3c SPE
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., down the basic
frame) and above (see Section 5.1.2 on concatenation), but they do
not switch lower order signals. Some of them only allow the
switching of entire aggregates (concatenated or not) of signals such
as 16 VC-4s, i.e., a complete STM-16, and nothing finer. Some go
down to the VC-3 level for SDH. Finally, some offer highly
integrated switches that switch at the VC-3/STS-1 level down to lower
order signals such as VC-12s. In order to cover the needs of all
manufacturers and operators, GMPLS signaling ([4], [5]) covers both
higher order and lower order signals.
4.1.2. Signal Concatenation Capabilities
As stated in the SDH/SONET 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: contiguous standard concatenation,
arbitrary 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,
STS-Mc. The STS-Mc notation is shorthand for describing an STS-M
signal whose SPEs have been concatenated. The multiplexing
procedures for SDH and SONET are given in references [2] and [3],
respectively. 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. That is, they support
concatenation with 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.
Standard and flexible concatenations are network services, while
virtual concatenation is an SDH/SONET end-system service approved by
the Committee T1 of ANSI [3] and the ITU-T [2]. The essence of this
service is to have SDH/SONET end systems "glue" together the VCs or
SPEs of separate signals, rather than requiring that the signals be
carried through the network as a single unit. In one example of
virtual concatenation, two end systems supporting this feature could
essentially "inverse multiplex" two STS-1s into an STS-1-2v for the
efficient transport of 100 Mbps Ethernet traffic. Note that this
inverse multiplexing process (or virtual concatenation) can be
significantly easier to implement with SDH/SONET than packet switched
circuits, because ensuring that timing and in-order frame delivery is
preserved may be simpler to establish using SDH/SONET, rather than
packet switched circuits, where more sophisticated techniques may be
needed.
Since virtual concatenation is provided by end systems, it is
compatible with existing SDH/SONET networks. Virtual concatenation
is defined for both higher order signals and low order signals.
Table 3 shows the nomenclature and capacity for several lower-order
virtually concatenated signals contained within different higher-
order signals.
Table 3. Capacity of Virtually Concatenated VTn-Xv (9/G.707)
Carried In X Capacity In steps
of
VT1.5/ STS-1/VC-3 1 to 28 1600kbit/s to 1600kbit/s
VC-11-Xv 44800kbit/s
VT2/ STS-1/VC-3 1 to 21 2176kbit/s to 2176kbit/s
VC-12-Xv 45696kbit/s
VT1.5/ STS-3c/VC-4 1 to 64 1600kbit/s to 1600kbit/s
VC-11-Xv 102400kbit/s
VT2/ STS-3c/VC-4 1 to 63 2176kbit/s to 2176kbit/s
VC-12-Xv 137088kbit/s
4.1.3. SDH/SONET Transparency
The purposed of SDH/SONET is to carry its payload signals in a
transparent manner. This can include some of the layers of SONET
itself. An example of this is a situation where the path overhead
can never be touched, since it actually belongs to the client. This
was another reason for not coding an explicit label in the 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, SONET overhead is broken into three