layers: Section, Line, and Path. Each of these layers is concerned
with fault and performance monitoring. The Section overhead is
primarily concerned with framing, while the Line overhead is
primarily concerned with multiplexing and protection. To perform
pipe multiplexing (that is, multiplexing of 50 Mbps or 150 Mbps
chunks), a SONET network element should be line terminating.
However, not all SONET multiplexers/switches perform SONET pointer
adjustments on all the STS-1s contained within a higher order SONET
signal passing through them. Alternatively, if they perform pointer
adjustments, they do not terminate the line overhead. For example, a
multiplexer may take four SONET STS-48 signals and multiplex them
onto an STS-192 without performing standard line pointer adjustments
on the individual STS-1s. This can be looked at as a service since
it may be desirable to pass SONET signals, like an STS-12 or STS-48,
with some level of transparency through a network and still take
advantage of TDM technology. Transparent multiplexing and switching
can also be viewed as a constraint, since some multiplexers and
switches may not switch with as fine a granularity as others. Table
4 summarizes the levels of SDH/SONET transparency.
Table 4. SDH/SONET 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
Terminating) the entire line multiplex as a whole.
Section overhead is terminated or
modified.
Section layer Preserves all section overhead,
Basically does not modify/terminate any
of the SDH/SONET overhead bits.
4.2. Protection
SONET and SDH networks offer a variety of protection options at both
the SONET line (SDH multiplex section) and SDH/SONET path level [7],
[8]. 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 line switched rings
(BLSRs). At the path layer, SONET offers uni-directional path
switched ring protection. Likewise, standardized SDH multiplex
section protection techniques include linear 1+1 and 1:N automatic p
protection switching and both two-fiber and four-fiber bi-directional
MS-SPRings (Multiplex Section-Shared Protection Rings).
At the path layer, SDH offers SNCP (sub-network connection
protection) 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 from any
GMPLS layer protection or restoration mechanisms.
Table 5. Common SDH/SONET protection mechanisms.
Protection Type Extra Comments
Traffic
Optionally
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
by N working lines
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 traffic" over protection lines.
Also, to assist in the configuration of these various protection
methods, it can be extremely valuable to advertise the link
protection attributes in the routing protocol, as is done in the
current GMPLS routing protocols. 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 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
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
SONET then this parameter is unneeded,
otherwise it would indicate the signal
layer that the protection is applied.
An open issue concerning protection is the extent of information
regarding protection that must be disseminated. The contents of
Table 6 represent one extreme, while a simple enumerated list
(Extra-Traffic/Protection line, Unprotected, Shared (1:N)/Working
line, Dedicated (1:1, 1+1)/Working Line, Enhanced (Ring) /Working
Line) represents the other.
There is also a potential implication for link bundling [13], [15]
that is, for each link, the routing protocol could advertise whether
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, in
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, 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 links (and their corresponding protection links) that are
"shared" protected separately from working links that are "dedicated"
protected.
4.3. Available Capacity Advertisement
Each SDH/SONET LSR must maintain an internal table per interface that
indicates each signal in the multiplex structure that is allocated at
that interface. This internal table is the most complete and
accurate view of the link usage and available capacity.
For use in path computation, this information needs to be advertised
in some way to all other SDH/SONET LSRs in the same domain. 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 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, all signals that are allocated
on an interface could be advertised; while at the other extreme, 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 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, hence it is not yet clear which is the
best way to advertise bandwidth resource availability/usage in
SDH/SONET. At present, the GMPLS routing protocol extensions define
minimum and maximum values for available bandwidth, which allows a
remote node to make some deductions about the amount of capacity
available at a remote link and the types of signals it can
accommodate. However, due to the multiplexed nature of the signals,
reporting of bandwidth particular to signal types, rather than as a
single aggregate bit rate, may be desirable. For details on why this
may be the case, we refer the reader to ITU-T publications G.7715.1
[16] and to Chapter 12 of [17].
4.4. Path Computation
Although a link state 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 [6]. 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 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 lines of global or
local optimization of the network in time.
Due to the complexity of some of the connection routing algorithms
(high dimensionality, non-linear integer programming problems) and
various criteria by which one may optimize 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 for
use during restoration situations. Such an approach is in line with
the use of GMPLS for traffic engineering, but is much different than
typical OSPF or IS-IS usage where all nodes must run the same routing
algorithm.
5. 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 3, 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 SDH/SONET LSPs.
5.1. What Do We Label in SDH/SONET? Frames or Circuits?
GMPLS 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, however,
are synchronous technologies that define a multiplexing structure
(see Section 3), which we referred to as the SDH (or SONET)
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.
The question then arises: is it these frames that we label in GMPLS?
It will be seen in what follows that each SONET or SDH "frame" need
not have its own 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 a frame. That is, we switch an individual SONET or
SDH signal, 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. The H1-H2-H3
Au-n pointer bytes in the SDH overhead 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 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 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 SDH/SONET can provide.
Instead, 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) [14].
An SDH/SONET-LSR will have to identify each possible signal
individually per interface to fulfill the GMPLS operations. In order
to stay transparent, the LSR obviously should not touch the SDH/SONET
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 locally unique for each signal at
each interface. This signal could, and will most probably, occupy
different time-slots at different interfaces.
5.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, and to the position of that signal in
the SDH/SONET multiplex. As we will see shortly, with a carefully
chosen label structure, the label itself can be made to function as
this information element.
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 6.1, the label is not coded in the SDH/SONET
overhead of the signal.
Another way is to use the well-defined and finite structure of the
SDH/SONET multiplexing tree to devise a 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 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 for SDH/SONET [15].
5.3. Signaling Elements
In the preceding sections, we defined the meaning of an 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. This
information is specified in three parts [15], each of which refers to
a different network layer.
1. GENERALIZED_LABEL REQUEST (as in [4], [5]), which contains three
parts: LSP Encoding Type, Switching Type, and G-PID.
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.
The second specifies certain link selection constraints, which
control, at each hop, the selection of the underlying link that is
used to transport this LSP.
The third 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.
2. SONET/SDH TRAFFIC_PARAMETERS (as in [15], Section 2.1) used as a
SENDER_TSPEC/FLOWSPEC, which contains 7 parts: Signal Type,
(Requested Contiguous Concatenation (RCC), Number of Contiguous
Components (NCC), Number of Virtual Components (NVC)), Multiplier
(MT), Transparency, and Profile.
The Signal Type indicates the type of elementary signal comprising
the LSP, while the remaining fields indicate transforms that can be
applied to the basic signal to build the final signal that
corresponds to the LSP actually being requested. For instance (see
[15] for details):
- Contiguous concatenation (by using the RCC and NCC fields) can
be optionally applied on the Elementary Signal, resulting in a
contiguously concatenated signal.
- Then, virtual concatenation (by using the NVC field) can be
optionally applied on the Elementary Signal, resulting in a
virtually concatenated signal.
- Third, some transparency (by using the Transparency field) can
be optionally specified when requesting a frame as a signal
rather than an SPE- or VC-based signal.
- Fourth, a multiplication (by using the Multiplier field) can be
optionally applied either directly on the Elementary Signal or
on the contiguously concatenated signal obtained from the first
phase, or on the virtually concatenated signal obtained from the
second phase, or on these signals combined with some
transparency.
Transparency indicates precisely which fields in these overheads must
be delivered unmodified at the other end of the LSP. An ingress LSR
requesting transparency will pass these overhead fields that must be
delivered to the egress LSR without any change. From the ingress and
egress LSRs point of views, these fields must be seen as unmodified.
Transparency is not applied at the interfaces with the initiating and
terminating LSRs, but is only applied between intermediate LSRs.
The transparency field is used to request an LSP that supports the