Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools

Problem, Formatting or Query -  Send Feedback

Was this page helpful?-10+1


Network Working Group G. Bernstein Request for Comments: 4257 Grotto Networking Category: Informational E. Mannie

                                                             V. Sharma
                                                        Metanoia, Inc.
                                                               E. Gray
                                              Marconi Corporation, plc
                                                         December 2005
           Framework for Generalized Multi-Protocol Label
       Switching (GMPLS)-based Control of Synchronous Digital
   Hierarchy/Synchronous Optical Networking (SDH/SONET) Networks

Status of This Memo

 This memo provides information for the Internet community.  It does
 not specify an Internet standard of any kind.  Distribution of this
 memo is unlimited.

Copyright Notice

 Copyright (C) The Internet Society (2005).


 Generalized Multi-Protocol Label Switching (GMPLS) is a suite of
 protocol extensions to MPLS to make it generally applicable, to
 include, for example, control of non packet-based switching, and
 particularly, optical switching.  One consideration is to use GMPLS
 protocols to upgrade the control plane of optical transport networks.
 This document illustrates this process by describing those extensions
 to GMPLS protocols that are aimed at controlling Synchronous Digital
 Hierarchy (SDH) or Synchronous Optical Networking (SONET) networks.
 SDH/SONET networks make good examples of this process for a variety
 of reasons.  This document highlights extensions to GMPLS-related
 routing protocols to disseminate information needed in transport path
 computation and network operations, together with (G)MPLS protocol
 extensions required for the provisioning of transport circuits.  New
 capabilities that an GMPLS control plane would bring to SDH/SONET
 networks, such as new restoration methods and multi-layer circuit
 establishment, are also discussed.

Bernstein, et al. Informational [Page 1] RFC 4257 GMPLS based Control of SDH/SONET December 2005

Table of Contents

 1. Introduction ....................................................3
    1.1. MPLS Overview ..............................................3
    1.2. SDH/SONET Overview .........................................5
    1.3. The Current State of Circuit Establishment in
         SDH/SONET Networks .........................................7
         1.3.1. Administrative Tasks ................................8
         1.3.2. Manual Operations ...................................8
         1.3.3. Planning Tool Operation .............................8
         1.3.4. Circuit Provisioning ................................8
    1.4. Centralized Approach versus Distributed Approach ...........9
         1.4.1. Topology Discovery and Resource Dissemination ......10
         1.4.2. Path Computation (Route Determination) .............10
         1.4.3. Connection Establishment (Provisioning) ............10
    1.5. Why SDH/SONET Will Not Disappear Tomorrow .................12
 2. GMPLS Applied to SDH/SONET .....................................13
    2.1. Controlling the SDH/SONET Multiplex .......................13
    2.2. SDH/SONET LSR and LSP Terminology .........................14
 3. Decomposition of the GMPLS Circuit-Switching Problem Space .....14
 4. GMPLS Routing for SDH/SONET ....................................15
    4.1. Switching Capabilities ....................................16
         4.1.1. Switching Granularity ..............................16
         4.1.2. Signal Concatenation Capabilities ..................17
         4.1.3. SDH/SONET Transparency .............................19
    4.2. Protection ................................................20
    4.3. Available Capacity Advertisement ..........................23
    4.4. Path Computation ..........................................24
 5. LSP Provisioning/Signaling for SDH/SONET .......................25
    5.1. What Do We Label in SDH/SONET?  Frames or Circuits? .......25
    5.2. Label Structure in SDH/SONET ..............................26
    5.3. Signaling Elements ........................................27
 6. Summary and Conclusions ........................................29
 7. Security Considerations ........................................29
 8. Acknowledgements ...............................................30
 9. Informative References .........................................31
 10. Acronyms ......................................................33

Bernstein, et al. Informational [Page 2] RFC 4257 GMPLS based Control of SDH/SONET December 2005

1. Introduction

 The CCAMP Working Group of the IETF has the goal of extending MPLS
 [1] protocols to support multiple network layers and new services.
 This extended MPLS, which was initially known as Multi-Protocol
 Lambda Switching, is now better referred to as Generalized MPLS (or
 The GMPLS effort is, in effect, extending IP/MPLS technology to
 control and manage lower layers.  Using the same framework and
 similar signaling and routing protocols to control multiple layers
 can not only reduce the overall complexity of designing, deploying,
 and maintaining networks, but can also make it possible to operate
 two contiguous layers by using either an overlay model, a peer model,
 or an integrated model.  The benefits of using a peer or an overlay
 model between the IP layer and its underlying layer(s) will have to
 be clarified and evaluated in the future.  In the mean time, GMPLS
 could be used for controlling each layer independently.
 The goal of this work is to highlight how GMPLS could be used to
 dynamically establish, maintain, and tear down SDH/SONET circuits.
 The objective of using these extended IP/MPLS protocols is to provide
 at least the same kinds of SDH/SONET services as are provided today,
 but using signaling instead of provisioning via centralized
 management to establish those services.  This will allow operators to
 propose new services, and will allow clients to create SDH/SONET
 paths on-demand, in real-time, through the provider network.  We
 first review the essential properties of SDH/SONET networks and their
 operations, and we show how the label concept in GMPLS can be
 extended to the SDH/SONET case.  We then look at important
 information to be disseminated by a link state routing protocol and
 look at the important signal attributes that need to be conveyed by a
 label distribution protocol.  Finally, we look at some outstanding
 issues and future possibilities.

1.1. MPLS Overview

 A major advantage of the MPLS architecture [1] for use as a general
 network control plane is its clear separation between the forwarding
 (or data) plane, the signaling (or connection control) plane, and the
 routing (or topology discovery/resource status) plane.  This allows
 the work on MPLS extensions to focus on the forwarding and signaling
 planes, while allowing well-known IP routing protocols to be reused
 in the routing plane.  This clear separation also allows for MPLS to
 be used to control networks that do not have a packet-based
 forwarding plane.

Bernstein, et al. Informational [Page 3] RFC 4257 GMPLS based Control of SDH/SONET December 2005

 An MPLS network consists of MPLS nodes called Label Switch Routers
 (LSRs) connected via Label Switched Paths (LSPs).  An LSP is uni-
 directional and could be of several different types such as point-
 to-point, point-to-multipoint, and multipoint-to-point.  Border LSRs
 in an MPLS network act as either ingress or egress LSRs, depending on
 the direction of the traffic being forwarded.
 Each LSP is associated with a Forwarding Equivalence Class (FEC),
 which may be thought of as a set of packets that receive identical
 forwarding treatment at an LSR.  The simplest example of an FEC might
 be the set of destination addresses lying in a given address range.
 All packets that have a destination address lying within this address
 range are forwarded identically at each LSR configured with that FEC.
 To establish an LSP, a signaling protocol (or label distribution
 protocol) such as LDP or RSVP-TE is required.  Between two adjacent
 LSRs, an LSP is locally identified by a fixed length identifier
 called a label, which is only significant between those two LSRs.  A
 signaling protocol is used for inter-node communication to assign and
 maintain these labels.
 When a packet enters an MPLS-based packet network, it is classified
 according to its FEC and, possibly, additional rules, which together
 determine the LSP along which the packet must be sent.  For this
 purpose, the ingress LSR attaches an appropriate label to the packet,
 and forwards the packet to the next hop.  The label may be attached
 to a packet in different ways.  For example, it may be in the form of
 a header encapsulating the packet (the "shim" header) or it may be
 written in the VPI/VCI field (or DLCI field) of the layer 2
 encapsulation of the packet.  In case of SDH/SONET networks, we will
 see that a label is simply associated with a segment of a circuit,
 and is mainly used in the signaling plane to identify this segment
 (e.g., a time-slot) between two adjacent nodes.
 When a packet reaches a packet LSR, this LSR uses the label as an
 index into a forwarding table to determine the next hop and the
 corresponding outgoing label (and, possibly, the QoS treatment to be
 given to the packet), writes the new label into the packet, and
 forwards the packet to the next hop.  When the packet reaches the
 egress LSR, the label is removed and the packet is forwarded using
 appropriate forwarding, such as normal IP forwarding.  We will see
 that for an SDH/SONET network these operations do not occur in quite
 the same way.

Bernstein, et al. Informational [Page 4] RFC 4257 GMPLS based Control of SDH/SONET December 2005

1.2. SDH/SONET Overview

 There are currently two different multiplexing technologies in use in
 optical networks: wavelength-division multiplexing (WDM) and time
 division multiplexing (TDM).  This work focuses on TDM technology.
 SDH and SONET are two TDM standards widely used by operators to
 transport and multiplex different tributary signals over optical
 links, thus creating a multiplexing structure, which we call the
 SDH/SONET multiplex.
 ITU-T (G.707) [2] includes both the European Telecommunications
 Standards Institute (ETSI) SDH hierarchy and the USA ANSI SONET
 hierarchy [3].  The ETSI SDH and SONET standards regarding frame
 structures and higher-order multiplexing are the same.  There are
 some regional differences in terminology, on the use of some overhead
 bytes, and lower-order multiplexing.  Interworking between the two
 lower-order hierarchies is possible using gateways.
 The fundamental signal in SDH is the STM-1 that operates at a rate of
 about 155 Mbps, while the fundamental signal in SONET is the STS-1
 that operates at a rate of about 51 Mbps.  These two signals are made
 of contiguous frames that consist of transport overhead (header) and
 payload.  To solve synchronization issues, the actual data is not
 transported directly in the payload, but rather in another internal
 frame that is allowed to float over two successive SDH/SONET
 payloads.  This internal frame is named a Virtual Container (VC) in
 SDH and a SONET Payload Envelope (SPE) in SONET.
 The SDH/SONET architecture identifies three different layers, each of
 which corresponds to one level of communication between SDH/SONET
 equipment.  These are, starting with the lowest, the regenerator
 section/section layer, the multiplex section/line layer, and (at the
 top) the path layer.  Each of these layers, in turn, has its own
 overhead (header).  The transport overhead of an SDH/SONET frame is
 mainly sub-divided in two parts that contain the regenerator
 section/section overhead and the multiplex section/line overhead.  In
 addition, a pointer (in the form of the H1, H2, and H3 bytes)
 indicates the beginning of the VC/SPE in the payload of the overall
 STM/STS frame.
 The VC/SPE itself is made up of a header (the path overhead) and a
 payload.  This payload can be further subdivided into sub-elements
 (signals) in a fairly complex way.  In the case of SDH, the STM-1
 frame may contain either one VC-4 or three multiplexed VC-3s.  The
 SONET multiplex is a pure tree, while the SDH multiplex is not a pure
 tree, since it contains a node that can be attached to two parent

Bernstein, et al. Informational [Page 5] RFC 4257 GMPLS based Control of SDH/SONET December 2005

 nodes.  The structure of the SDH/SONET multiplex is shown in Figure
 1.  In addition, we show reference points in this figure that are
 explained in later sections.
 The leaves of these multiplex structures are time slots (positions)
 of different sizes that can contain tributary signals.  These
 tributary signals (e.g., E1, E3, etc) are mapped into the leaves
 using standardized mapping rules.  In general, a tributary signal
 does not fill a time slot completely, and the mapping rules define
 precisely how to fill it.
 What is important for the GMPLS-based control of SDH/SONET circuits
 is to identify the elements that can be switched from an input
 multiplex on one interface to an output multiplex on another
 interface.  The only elements that can be switched are those that can
 be re-aligned via a pointer, i.e., a VC-x in the case of SDH and a
 SPE in the case of SONET.
           xN       x1
 STM-N<----AUG<----AU-4<--VC4<------------------------------C-4  E4
            ^              ^
            Ix3            Ix3
            I              I           x1
            I              -----TUG-3<----TU-3<---VC-3<---I
            I                      ^                       C-3 DS3/E3
 STM-0<------------AU-3<---VC-3<-- I ---------------------I
                            ^      I
                            Ix7    Ix7
                            I      I    x1
                            -----TUG-2<---TU-2<---VC-2<---C-2 DS2/T2
                                 ^  ^
                                 I  I   x3
                                 I  I----TU-12<---VC-12<--C-12 E1
                                 I      x4
                                 I-------TU-11<---VC-11<--C-11 DS1/T1

Bernstein, et al. Informational [Page 6] RFC 4257 GMPLS based Control of SDH/SONET December 2005

                              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        x4
                                  I-----------VT-1.5<--SPE DS1/T1
 Figure 1.  SDH and SONET multiplexing structure and typical
 Plesiochronous Digital Hierarchy (PDH) payload signals.
 An STM-N/STS-N signal is formed from N x STM-1/STS-1 signals via byte
 interleaving.  The VCs/SPEs in the N interleaved frames are
 independent and float according to their own clocking.  To transport
 tributary signals in excess of the basic STM-1/STS-1 signal rates,
 the VCs/SPEs can be concatenated, i.e., glued together.  In this
 case, their relationship with respect to each other is fixed in time;
 hence, this relieves, when possible, an end system of any inverse
 multiplexing bonding processes.  Different types of concatenations
 are defined in SDH/SONET.
 For example, standard SONET concatenation allows the concatenation of
 M x STS-1 signals within an STS-N signal with M <= N, and M = 3, 12,
 48, 192, .... The SPEs of these M x STS-1s can be concatenated to
 form an STS-Mc.  The STS-Mc notation is short hand for describing an
 STS-M signal whose SPEs have been concatenated.

1.3. The Current State of Circuit Establishment in SDH/SONET Networks

 In present day SDH and SONET networks, the networks are primarily
 statically configured.  When a client of an operator requests a
 point-to-point circuit, the request sets in motion a process that can
 last for several weeks or more.  This process is composed of a chain
 of shorter administrative and technical tasks, some of which can be
 fully automated, resulting in significant improvements in
 provisioning time and in operational savings.  In the best case, the
 entire process can be fully automated allowing, for example, customer
 premise equipment (CPE) to contact an SDH/SONET switch to request a
 circuit.  Currently, the provisioning process involves the following

Bernstein, et al. Informational [Page 7] RFC 4257 GMPLS based Control of SDH/SONET December 2005

1.3.1. Administrative Tasks

 The administrative tasks represent a significant part of the
 provisioning time.  Most of them can be automated using IT
 applications, e.g., a client still has to fill a form to request a
 circuit.  This form can be filled via a Web-based application and can
 be automatically processed by the operator.  A further enhancement is
 to allow the client's equipment to coordinate with the operator's
 network directly and request the desired circuit.  This could be
 achieved through a signaling protocol at the interface between the
 client equipment and an operator switch, i.e., at the UNI, where
 GMPLS signaling [4], [5] can be used.

1.3.2. Manual Operations

 Another significant part of the time may be consumed by manual
 operations that involve installing the right interface in the CPE and
 installing the right cable or fiber between the CPE and the operator
 switch.  This time can be especially significant when a client is in
 a different time zone than the operator's main office.  This first-
 time connection time is frequently accounted for in the overall
 establishment time.

1.3.3. Planning Tool Operation

 Another portion of the time is consumed by planning tools that run
 simulations using heuristic algorithms to find an optimized placement
 for the required circuits.  These planning tools can require a
 significant running time, sometimes on the order of days.
 These simulations are, in general, executed for a set of demands for
 circuits, i.e., a batch mode, to improve the optimality of network
 resource usage and other parameters.  Today, we do not really have a
 means to reduce this simulation time.  On the contrary, to support
 fast, on-line, circuit establishment, this phase may be invoked more
 frequently, i.e., we will not "batch up" as many connection requests
 before we plan out the corresponding circuits.  This means that the
 network may need to be re-optimized periodically, implying that the
 signaling should support re-optimization with minimum impact to
 existing services.

1.3.4. Circuit Provisioning

 Once the first three steps discussed above have been completed, the
 operator must provision the circuits using the outputs of the
 planning process.  The time required for provisioning varies greatly.
 It can be fairly short, on the order of a few minutes, if the
 operators already have tools that help them to do the provisioning

Bernstein, et al. Informational [Page 8] RFC 4257 GMPLS based Control of SDH/SONET December 2005

 over heterogeneous equipment.  Otherwise, the process can take days.
 Developing these tools for each new piece of equipment and each
 vendor is a significant burden on the service provider.  A
 standardized interface for provisioning, such as GMPLS signaling,
 could significantly reduce or eliminate this development burden.  In
 general, provisioning is a batched activity, i.e., a few times per
 week an operator provisions a set of circuits.  GMPLS will reduce
 this provisioning time from a few minutes to a few seconds and could
 help to transform this periodic process into a real-time process.
 When a circuit is provisioned, it is not delivered directly to a
 client.  Rather, the operator first tests its performance and
 behavior and, if successful, delivers the circuit to the client.
 This testing phase lasts, in general, up to 24 hours.  The operator
 installs test equipment at each end and uses pre-defined test streams
 to verify performance.  If successful, the circuit is officially
 accepted by the client.  To speed up the verification (sometimes
 known as "proving") process, it would be necessary to support some
 form of automated performance testing.

1.4. Centralized Approach versus Distributed Approach

 Whether a centralized approach or a distributed approach will be used
 to control SDH/SONET networks is an open question, since each
 approach has its merits.  The application of GMPLS to SDH/SONET
 networks does not preclude either model, although GMPLS is itself a
 distributed technology.
 The basic tradeoff between the centralized and distributed approaches
 is that of complexity of the network elements versus that of the
 network management system (NMS).  Since adding functionality to
 existing SDH/SONET network elements may not be possible, a
 centralized approach may be needed in some cases.  The main issue
 facing centralized control via an NMS is one of scalability.  For
 instance, this approach may be limited in the number of network
 elements that can be managed (e.g., one thousand).  It is, therefore,
 quite common for operators to deploy several NMS in parallel at the
 Network Management Layer, each managing a different zone.  In that
 case, however, a Service Management Layer must be built on the top of
 several individual NMS to take care of end-to-end on-demand services.
 On the other hand, in a complex and/or dense network, restoration
 could be faster with a distributed approach than with a centralized
 Let's now look at how the major control plane functional components
 are handled via the centralized and distributed approaches:

Bernstein, et al. Informational [Page 9] RFC 4257 GMPLS based Control of SDH/SONET December 2005

1.4.1. Topology Discovery and Resource Dissemination

 Currently, an NMS maintains a consistent view of all the networking
 layers under its purview.  This can include the physical topology,
 such as information about fibers and ducts.  Since most of this
 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

Bernstein, et al. Informational [Page 10] RFC 4257 GMPLS based Control of SDH/SONET December 2005

 establishment is the trickiest part to distribute, however, since
 errors in the connection setup/tear down process are service
 The table below compares the two approaches to connection
 Table 1.  Qualitative comparison between centralized and distributed
     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
     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
     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

Bernstein, et al. Informational [Page 11] RFC 4257 GMPLS based Control of SDH/SONET December 2005

     Planning (optimization)           Planning is a background
     harder to achieve                 centralized activity
     Easier future integration
     with other control plane

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
 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
 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

Bernstein, et al. Informational [Page 12] RFC 4257 GMPLS based Control of SDH/SONET December 2005

 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

Bernstein, et al. Informational [Page 13] RFC 4257 GMPLS based Control of SDH/SONET December 2005

 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.

Bernstein, et al. Informational [Page 14] RFC 4257 GMPLS based Control of SDH/SONET December 2005

 (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
 (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.

Bernstein, et al. Informational [Page 15] RFC 4257 GMPLS based Control of SDH/SONET December 2005

 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],
 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

Bernstein, et al. Informational [Page 16] RFC 4257 GMPLS based Control of SDH/SONET December 2005

 switched within an SDH/SONET network.  These signals are subdivided
 into lower order signals and higher order signals as shown in Table
 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
 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.

Bernstein, et al. Informational [Page 17] RFC 4257 GMPLS based Control of SDH/SONET December 2005

 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
 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
 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.

Bernstein, et al. Informational [Page 18] RFC 4257 GMPLS based Control of SDH/SONET December 2005

    Table 3.  Capacity of Virtually Concatenated VTn-Xv (9/G.707)
                Carried In      X           Capacity       In steps
   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
 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.

Bernstein, et al. Informational [Page 19] RFC 4257 GMPLS based Control of SDH/SONET December 2005

    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
    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.

Bernstein, et al. Informational [Page 20] RFC 4257 GMPLS based Control of SDH/SONET December 2005

    Table 5.  Common SDH/SONET protection mechanisms.
     Protection Type     Extra          Comments
     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.
     line switched
     2F-BLSR (2          Yes            Dedicated protection, with
     fiber bi-                          alternative ring path
     line switched
     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

Bernstein, et al. Informational [Page 21] RFC 4257 GMPLS based Control of SDH/SONET December 2005

 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
     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
     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

Bernstein, et al. Informational [Page 22] RFC 4257 GMPLS based Control of SDH/SONET December 2005

 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"

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
 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

Bernstein, et al. Informational [Page 23] RFC 4257 GMPLS based Control of SDH/SONET December 2005

 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

Bernstein, et al. Informational [Page 24] RFC 4257 GMPLS based Control of SDH/SONET December 2005

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.

Bernstein, et al. Informational [Page 25] RFC 4257 GMPLS based Control of SDH/SONET December 2005

 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

Bernstein, et al. Informational [Page 26] RFC 4257 GMPLS based Control of SDH/SONET December 2005

 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.

Bernstein, et al. Informational [Page 27] RFC 4257 GMPLS based Control of SDH/SONET December 2005

 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):
  1. Contiguous concatenation (by using the RCC and NCC fields) can

be optionally applied on the Elementary Signal, resulting in a

      contiguously concatenated signal.
  1. Then, virtual concatenation (by using the NVC field) can be

optionally applied on the Elementary Signal, resulting in a

      virtually concatenated signal.
  1. 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.
  1. 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 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
 requested transparency type; it may also be used to setup the
 transparency process to be applied at each intermediate LSR.
 Finally, the profile field is intended to specify particular
 capabilities that must be supported for the LSP, for example
 monitoring capabilities.  However, no standard profile is currently
 3. UPSTREAM_LABEL for Bi-directional LSP's (as in [4], [5]).
 4. Local Link Selection, e.g., IF_ID_RSVP_HOP Object (as in [5]).

Bernstein, et al. Informational [Page 28] RFC 4257 GMPLS based Control of SDH/SONET December 2005

6. Summary and Conclusions

 We provided a detailed account of the issues involved in applying
 generalized GMPLS-based control (GMPLS) to TDM networks.
 We began with a brief overview of GMPLS and SDH/SONET networks,
 discussing current circuit establishment in TDM networks, and arguing
 why SDH/SONET technologies will not be "outdated" in the foreseeable
 future.  Next, we looked at IP/MPLS applied to SDH/SONET networks,
 where we considered why such an application makes sense, and reviewed
 some GMPLS terminology as applied to TDM networks.
 We considered the two main areas of application of IP/MPLS methods to
 TDM networks, namely routing and signaling, and discussed how
 Generalized MPLS routing and signaling are used in the context of TDM
 networks.  We reviewed in detail the switching capabilities of TDM
 equipment, and the requirement to learn about the protection
 capabilities of underlying links, and 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 and how this label
 should be structured; and we focused on the importance of
 hierarchical label allocation in a TDM network.  Finally, we reviewed
 the signaling elements involved when setting up a 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.

7. Security Considerations

 The use of a control plane to provision connectivity through a
 SONET/SDH network shifts the security burden significantly from the
 management plane to the control plane.  Before the introduction of a
 control plane, the communications that had to be secured were between
 the management stations (Element Management Systems or Network
 Management Systems) and each network element that participated in the
 network connection.  After the introduction of the control plane, the
 only management plane communication that needs to be secured is that
 to the head-end (ingress) network node as the end-to-end service is
 requested.  On the other hand, the control plane introduces a new
 requirement to secure signaling and routing communications between
 adjacent nodes in the network plane.

Bernstein, et al. Informational [Page 29] RFC 4257 GMPLS based Control of SDH/SONET December 2005

 The security risk from impersonated management stations is
 significantly reduced by the use of a control plane.  In particular,
 where unsecure versions of network management protocols such as SNMP
 versions 1 and 2 were popular configuration tools in transport
 networks, the use of a control plane may significantly reduce the
 security risk of malicious and false assignment of network resources
 that could cause the interception or disruption of data traffic.
 On the other hand, the control plane may increase the number of
 security relationships that each network node must maintain.  Instead
 of a single security relationship with its management element, each
 network node must now maintain a security relationship with each of
 its signaling and routing neighbors in the control plane.
 There is a strong requirement for signaling and control plane
 exchanges to be secured, and any protocols proposed for this purpose
 must be capable of secure message exchanges.  This is already the
 case for the existing GMPLS routing and signaling protocols.

8. Acknowledgements

 We acknowledge all the participants of the MPLS and CCAMP WGs, whose
 constant enquiry about GMPLS issues in TDM networks motivated the
 writing of this document, and whose questions helped shape its
 contents.  Also, thanks to Kireeti Kompella for his careful reading
 of the last version of this document, and for his helpful comments
 and feedback, and to Dimitri Papadimitriou for his review on behalf
 of the Routing Area Directorate, which provided many useful inputs to
 help update the document to conform to the standards evolutions since
 this document passed last call.

Bernstein, et al. Informational [Page 30] RFC 4257 GMPLS based Control of SDH/SONET December 2005

9. Informative References

 In the ITU references below, please see for
 availability of ITU documents.  For ANSI references, please see the
 Library available through
 [1]  Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label
      Switching Architecture", RFC 3031, January 2001.
 [2]  G.707, Network Node Interface for the Synchronous Digital
      Hierarchy (SDH), International Telecommunication Union, March
 [3]  ANSI T1.105-1995, Synchronous Optical Network (SONET) Basic
      Description including Multiplex Structure, Rates, and Formats,
      American National Standards Institute.
 [4]  Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS)
      Signaling Functional Description", RFC 3471, January 2003.
 [5]  Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS)
      Signaling Resource ReserVation Protocol-Traffic Engineering
      (RSVP-TE) Extensions", RFC 3473, January 2003.
 [6]  Bernstein, G., Yates, J., Saha, D.,  "IP-Centric Control and
      Management of Optical Transport Networks," IEEE Communications
      Mag., Vol. 40, Issue 10, October 2000.
 [7]  ANSI T1.105.01-1995, Synchronous Optical Network (SONET)
      Automatic Protection Switching, American National Standards
 [8]  G.841, Types and Characteristics of SDH Network Protection
      Architectures, ITU-T, July 1995.
 [9]  Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions in
      Support of Generalized Multi-Protocol Label Switching (GMPLS)",
      RFC 4202, October 2005.
 [10] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in
      Support of Generalized Multi-Protocol Label Switching (GMPLS)",
      RFC 4203, October 2005.
 [11] Kompella, K., Ed. and Y. Rekhter, Ed., "Intermediate System to
      Intermediate System (IS-IS) Extensions in Support of Generalized
      Multi-Protocol Label Switching (GMPLS)", RFC 4205, October 2005.

Bernstein, et al. Informational [Page 31] RFC 4257 GMPLS based Control of SDH/SONET December 2005

 [12] Bernstein, G., Sharma, V., Ong, L., "Inter-domain Optical
      Routing," OSA J. of Optical Networking, vol. 1, no. 2, pp.  80-
 [13] Kompella, K., Rekhter, Y. and L. Berger, "Link Bundling in MPLS
      Traffic Engineering (TE)", RFC 4201, October 2005.
 [14] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP)
      Hierarchy with Generalized Multi-Protocol Label Switching
      (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.
 [15] Mannie, E. and D. Papadimitriou, "Generalized Multi-Protocol
      Label Switching (GMPLS) Extensions for Synchronous Optical
      Network (SONET) and Synchronous Digital Hierarchy (SDH)
      Control", RFC 3946, October 2004.
 [16] G.7715.1, ASON Routing Architecture and Requirements for Link-
      State Protocols, International Telecommunications Union,
      February 2004.
 [17] Bernstein, G., Rajagopalan, R., and Saha, D., "Optical Network
      Control: Protocols, Architectures, and Standards," Addison-
      Wesley, July 2003.

Bernstein, et al. Informational [Page 32] RFC 4257 GMPLS based Control of SDH/SONET December 2005

10. Acronyms

 ANSI     - American National Standards Institute
 APS      - Automatic Protection Switching
 ATM      - Asynchronous Transfer Mode
 BLSR     - Bi-directional Line Switch Ring
 CPE      - Customer Premise Equipment
 DLCI     - Data Link Connection Identifier
 ETSI     - European Telecommunication Standards Institute
 FEC      - Forwarding Equivalency Class
 GMPLS    - Generalized MPLS
 IP       - Internet Protocol
 IS-IS    - Intermediate System to Intermediate System (RP)
 LDP      - Label Distribution Protocol
 LSP      - Label Switched Path
 LSR      - Label Switching Router
 MPLS     - Multi-Protocol Label Switching
 NMS      - Network Management System
 OSPF     - Open Shortest Path First (RP)
 PNNI     - Private Network Node Interface
 PPP      - Point to Point Protocol
 QoS      - Quality of Service
 RP       - Routing Protocol
 RSVP     - ReSerVation Protocol
 SDH      - Synchronous Digital Hierarchy
 SNMP     - Simple Network Management Protocol
 SONET    - Synchronous Optical NETworking
 SPE      - SONET Payload Envelope
 STM      - Synchronous Transport Module (or Terminal Multiplexer)
 STS      - Synchronous Transport Signal
 TDM      - Time Division Multiplexer
 TE       - Traffic Engineering
 TMN      - Telecommunication Management Network
 UPSR     - Uni-directional Path Switch Ring
 VC       - Virtual Container (SDH) or Virtual Circuit
 VCI      - Virtual Circuit Identifier (ATM)
 VPI      - Virtual Path Identifier (ATM)
 VT       - Virtual Tributary
 WDM      - Wavelength-Division Multiplexing

Bernstein, et al. Informational [Page 33] RFC 4257 GMPLS based Control of SDH/SONET December 2005

Author's Addresses

 Greg Bernstein
 Grotto Networking
 Phone: +1 510 573-2237
 Eric Mannie
 Rue Tenbosch, 9
 1000 Brussels
 Phone: +32-2-6409194
 Vishal Sharma
 Metanoia, Inc.
 888 Villa Street, Suite 500
 Mountain View, CA 94041
 Phone: +1 650 641 0082
 Eric Gray
 Marconi Corporation, plc
 900 Chelmsford Street
 Lowell, MA  01851
 Phone: +1 978 275 7470

Bernstein, et al. Informational [Page 34] RFC 4257 GMPLS based Control of SDH/SONET December 2005

Full Copyright Statement

 Copyright (C) The Internet Society (2005).
 This document is subject to the rights, licenses and restrictions
 contained in BCP 78, and except as set forth therein, the authors
 retain all their rights.
 This document and the information contained herein are provided on an

Intellectual Property

 The IETF takes no position regarding the validity or scope of any
 Intellectual Property Rights or other rights that might be claimed to
 pertain to the implementation or use of the technology described in
 this document or the extent to which any license under such rights
 might or might not be available; nor does it represent that it has
 made any independent effort to identify any such rights.  Information
 on the procedures with respect to rights in RFC documents can be
 found in BCP 78 and BCP 79.
 Copies of IPR disclosures made to the IETF Secretariat and any
 assurances of licenses to be made available, or the result of an
 attempt made to obtain a general license or permission for the use of
 such proprietary rights by implementers or users of this
 specification can be obtained from the IETF on-line IPR repository at
 The IETF invites any interested party to bring to its attention any
 copyrights, patents or patent applications, or other proprietary
 rights that may cover technology that may be required to implement
 this standard.  Please address the information to the IETF at ietf-


 Funding for the RFC Editor function is currently provided by the
 Internet Society.

Bernstein, et al. Informational [Page 35]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4257.txt · Last modified: 2005/12/05 23:58 (external edit)