Internet Draft


MPLS Working Group                                       Greg Bernstein
Internet Draft                                                    Ciena
Document: 
Category:                                                   Eric Mannie
Expires: May 2001                                                   GTS

                                                          Vishal Sharma
                                                                Tellabs

                                                          November 2000



     Framework for MPLS-based Control of Optical SDH/SONET Networks
          <draft-bms-optical-sdhsonet-mpls-control-frmwrk-00.txt>

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026 [1].

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that
   other groups may also distribute working documents as Internet-
   Drafts. Internet-Drafts are draft documents valid for a maximum of
   six months and may be updated, replaced, or obsoleted by other
   documents at any time. It is inappropriate to use Internet- Drafts
   as reference material or to cite them other than as "work in
   progress."
   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt
   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

1. Abstract

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

Mack-Crane et al           Expires May 2001                          1
 
   draft-bms-sdhsonet-mpls-control-frmwrk-00.txt      November 2000




2. Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
   this document are to be interpreted as described in RFC-2119 [2].


3. Introduction

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

   The MPLS Working Group of the IETF is currently extending MPLS
   protocols to support these non-packet layers and these new services.
   This extended MPLS, which was initially known as Multi-Protocol
   Lambda Switching, is now better referred to as Generalized MPLS (or
   GMPLS). The authors of this work are among the co-authors of the
   GMPLS specifications, and - focus mainly on those aspects of GMPLS
   that relate to the control of SDH/SONET networks.

   The GMPLS effort is, in fact, extending IP technology to control and
   manage lower layers. Using the same framework and the same kinds of
   signaling and routing protocols to control multiple layers not only
   has the potential to reduce the overall complexity of designing,
   deploying and maintaining networks, but also has the potential to
   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 is very suitable for controlling
   each layer completely independently.

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

Bernstein, Mannie, Sharma        Expires May 2001                    2
 
   draft-bms-sdhsonet-mpls-control-frmwrk-00.txt      November 2000


   services as provided today, but using signaling instead of
   provisioning to establish those services. This will allow operators
   to propose new services, and will allow clients to create SONET/SDH
   paths on-demand, in real-time, through the provider network. We
   first review the essential properties of SDH/SONET networks and
   their operations, and we show how the labelÆs of MPLS can be
   extended to the SONET/SDH case. We then look at important
   information to be disseminated by a link state route protocol and
   look at the important signal attributes that need to be conveyed by
   a label distribution protocol.  Finally, we look at some outstanding
   issues and future possibilities. [3], [4], [5], [6], [7],[8], [9],
   [10], [11], [12].

3.1 MPLS Overview

   An advantage of the MPLS architecture is the clear separation
   between the forwarding plane, the signaling plane, and the routing
   plane. This allows the work on MPLS 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.

   In MPLS terminology, an MPLS node is called a Label Switch Router
   (LSR) and a circuit is called a Label Switched Path (LSP). An LSP is
   unidirectional and could be of several different types such as
   point-to-point, point-to-multipoint, and multipoint-to-point. Border
   LSRs in an MPLS cloud, act either as ingress or egress LSRs
   respective to the direction of the traffic being forwarded.

   MPLS allows the establishment of LSPs between ingress and egress
   LSRs. Each LSP is associated with a Fowarding Equivalence Class
   (FEC), which may be thought of as a set of packets that receive
   identical forwarding treatment at an LSR. The simplest example of an
   FEC might be the set of destination addresses lying in a given
   address range. All packets that have a destination address lying
   within this address range are forwarded identically at that LSR.

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

   When a packet enters an MPLS packet-based network, it is classified
   according to its FEC and, possibly,  additional rules, which
   together determine the LSP along which the packet is sent. For that
   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

Bernstein, Mannie, Sharma        Expires May 2001                    3
"
   draft-bms-sdhsonet-mpls-control-frmwrk-00.txt      November 2000


   2 encapsulation of the IP data. In case of SDH/SONET networks, we
   will see that  a label is  simply associated with a segment of a
   circuit, and is mainly used in the signaling plane to identify this
   segment (e.g. a time-slot) between two adjacent nodes.

   When a packet reaches a core packet LSR, this LSR uses the label as
   an index into a forwarding table to determine the next hop and the
   corresponding outgoing label, writes the new label into the packet,
   and forwards the packet to the next hop. When the packet reaches the
   egress LSR, the label is removed and the packet is forwarded using
   adequate forwarding, such as normal IP forwarding. We will see that
   for a SONET/SDH network these operations -do not occur in quite the
   same way.

3.2 SDH/SONET Overview

   SDH and SONET are two TDM standards widely used by operators to
   transport and multiplex different tributary signals over optical
   links, thus creating a multiplexing structure, which we call the
   SDH/SONET multiplex. SDH, which was developed by the ETSI and later
   standardized by the ITU-T, is now used worldwide, while SONET, which
   was standardized by the ANSI, is mainly used in the US. However,
   these two standards have several similarities, and to some extent
   SONET can be viewed as a subset of SDH. Internetworking between the
   two is possible using gateways.

   The fundamental signal in SDH is the STM-1 that operates at a rate
   of about 155 Mbps 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 a transport overhead (header)
   and a payload. To solve synchronization issues, the actual data is
   not directly transported in the payload but rather in another
   internal frame that is allowed to float over two successive
   SDH/SONET payloads. This internal frame is named a Virtual Container
   (VC) in SDH and a Synchronous Payload Envelope (SPE) in SONET.

   The SDH/SONET architecture identifies three different layers, each
   of which corresponds to one level of communication between SDH/SONET
   equipment. These are, starting with the lowest, the regenerator
   section/section layer, the multiplex section/line layer, and (at the
   top) the path layer. Each of these layers has its own overhead
   (header). The transport overhead of a 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.

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

Bernstein, Mannie, Sharma        Expires May 2001                    4
 
   draft-bms-sdhsonet-mpls-control-frmwrk-00.txt      November 2000


   pure tree since it contains a node that can be attached to two
   parent nodes. The structure of the SONET/SDH multiplex is shown in
   Figure 1. In addition, we show reference points in this figure that
   will be explained later on.



          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/T3/E3
              -------AU-3<---VC-3<-- I -----------------------I
                              ^      I
                              Ix7    Ix7
                              I      I    x1
                              -----TUG-2<----TU-2<----VC-2<---C-2
   DS2/T2
                                   ^  ^
                                   I  I   x3
                                   I  I------TU-12<---VC-12<--C-12 E1
                                   I
                                   I      x4
                                   I---------TU-11<---VC-11<--C-11
   DS1/T1


            xN
   STS-N<-------------------SPE<---------------------------------
   DS3/T3
                             ^
                             Ix7
                             I            x1
                             I---VT-Group<---VT-6<----SPE
   DS2/T2
                                 ^  ^  ^
                                 I  I  I  x2
                                 I  I  I-----VT-3<----SPE          DS1C
                                 I  I
                                 I  I     x3
                                 I  I--------VT-2<----SPE          E1
                                 I
                                 I        x4
                                 I-----------VT-1.5<--SPE
   DS1/T1



   Figure 1. SDH and SONET multiplexing structure and typical PDH
   payload signals.

Bernstein, Mannie, Sharma        Expires May 2001                    5
 
   draft-bms-sdhsonet-mpls-control-frmwrk-00.txt      November 2000





   The leaves of these multiplex structures are time slots (positions)
   of different sizes that can contain tributary signals. These
   tributary signals (e.g. E1, E3, etc) are mapped into the leaves
   using standardized mapping rules. In general, a tributary signal
   does not fill a time slot completely, and the mapping rules define
   precisely how to fill it.

   What is important for the goal of this paper is to identify the
   elements that can be switched from an input multiplex on one
   interface to an output multiplex on another interface. These
   elements are only those that can be re-aligned via a pointer, i.e. a
   VC-x in the case of SDH and a SPE in the case of SONET.

   An STM-N/STS-N signal is formed from N x STM-1/STS-1 signals via
   byte interleaving.  The VCs/SPEs in the N interleaved frames are
   independent and float according to their own clocking.  To transport
   tributary signals in excess of the basic STM-1/STS-1 signal, the
   VCs/SPEs can be concatenated, i.e., glued together. In this case
   their relationship with respect to each other is fixed in time and
   hence this relieves, when possible, an end system of any inverse
   multiplexing bonding processes. Different types of concatenations
   are defined, with specific rules.

   For instance, the standard SONET concatenation allows the
   concatenation of M x STS-1 signals within an STS-N signal with M <=
   N, and M = 3, 12, 48, 192,...). The SPEs of these M x STS-1s can be
   concatenated to form an STS-Mc. The STS-Mc notation is short hand
   for describing an STS-M signal whose SPEs have been concatenated.


3.3 The Real World of Circuit Establishment with SDH/SONET

   Today, SDH and SONET networks are statically configured. When a
   client of an operator requests a point-to-point circuit or a ring,
   it sets in motion a process that can last for weeks. This process is
   indeed a chain of shorter administrative and technical tasks, some
   of which can be fully automated, resulting in significant
   improvements in provisioning time and in operational savings. In the
   best case, the entire process can be fully automated allowing, for
   example,. a CPE to contact  a SDH/SONET switch to request some
   bandwidth. This is, in fact, the ultimate objective that we would
   like to achieve using MPLS to control SDH/SONET networks.

   In the current setup, however, the provisioning process involves the
   following components.

3.3.1. Administrative Tasks

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

Bernstein, Mannie, Sharma        Expires May 2001                    6
 
   draft-bms-sdhsonet-mpls-control-frmwrk-00.txt      November 2000


   applications, however, and MPLS does not help in that case. However,
   a client still has to fill a form to request a circuit. This form
   can be filled via a Web-based application and can be automatically
   processed by the operator. A further step is to allow the client's
   equipment to coordinate with the operator's network directly and
   request the desired circuit. This has to be achieved through a
   signaling protocol at the interface between the client equipment and
   an operator switch, i.e. at the UNI interface, where MPLS can play a
   role.

3.3.2. Manual Operations

   Another significant part of the time may be consumed by manual
   operations that involve installing the right interface in the CPE
   and installing the right cable or fiber between the CPE and the
   operator switch. This time can be especially significant when a
   client is in a different time zone than the operator's main office.
   This first-time connection time is frequently accounted for in the
   overall establishment time. To support our fully automated model we
   must, of course, assume that CPEs are pre-connected to the
   operatorÆs network.

3.3.3. Planning Tool Operation

   Another portion of the time is consumed by planning tools that run
   simulations using heuristic algorithms to find an optimized
   placement for the required circuits and/or rings. These planning
   tools can require a significant running time, sometimes of the order
   of days. These simulations are, in general, executed for a set of
   demands for circuits and/or rings to improve the optimality of the
   solution. Today, we do not really have a means to reduce this
   simulation time. On the contrary, to support fast, on-line, circuit
   establishment, we will most probably skip this phase. It means that
   the network will have to be re-optimized periodically, implying that
   the signaling should support re-optimization without hurting too
   much the service. Indeed, the optimization of the network is then
   taken out of the chain and becomes a background activity. Smart
   circuit re-routing required for re-optimization is available in
   MPLS.

3.3.4. Circuit Provisioning

   Once the first three steps have been executed, the circuits must be
   effectively provisioned by the operator using the outputs of the
   planning tool. The time required for this provisioning is fairly
   short, on the order of a few minutes. In many cases, operators
   already have tools that help them to do the provisioning over
   heterogeneous equipment more or less automatically. In general, the
   provisioning is a grouped activity, a few times per week an operator
   launches the provisioning of a set of circuits in one shot. MPLS
   will reduce this provisioning time from a few minutes to a few
   seconds and will help to transform this periodic process into a
   real-time process.

Bernstein, Mannie, Sharma        Expires May 2001                    7
 
   draft-bms-sdhsonet-mpls-control-frmwrk-00.txt      November 2000



   When a circuit or a ring is provisioned it is not delivered directly
   to a client. First, its performance and behavior is tested by the
   operator and if this is successful, the circuit is delivered to the
   client. This testing phase lasts, in general, for  up to 24 hours.
   The operator instalsl test equipment at each end and uses pre-
   defined test streams to verify the performance. If successful, the
   circuit is officially accepted by the client. Thus, to speed up this
   process, brief automated performance testing will have to be
   supported in some way.

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

3.4. Centralized Approach versus Distributed Approach

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

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

Bernstein, Mannie, Sharma        Expires May 2001                    8
 
   draft-bms-sdhsonet-mpls-control-frmwrk-00.txt      November 2000


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

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

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

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

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

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

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

Bernstein, Mannie, Sharma        Expires May 2001                    9
 
   draft-bms-sdhsonet-mpls-control-frmwrk-00.txt      November 2000


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

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

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

   An NMS has scalability limitations. For instance, it can be limited
   in the number of network elements that can be managed (e.g. one
   thousand). It is quite common for operators to deploy several NMSÆs
   in parallel at the Network Management Layer, each managing a
   different zone. In that case, a layer on the top of several
   individual NMS at the Service Management Layer must be built to take
   care of end-to-end on-demand services. On the contrary, the
   scalability is much better in the distributed approach, clients are
   co-located with switches and distributed among these switches.

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

   It could be expected that in a complex and/or dense network,
   restoration could be faster with a distributed approach than with a
   centralized approach. In the first case, signaling messages travel
   over exactly the same path as the affected circuits and only through
   the affected. In the second case, a signaling message has to go
   first to the NMS , which transmits signaling messages (in parallel)
   to all concerned nodes. However, this comparison requires further
   investigations.

   In general , an NMS is not a single point of failure, since all
   operators have systems in hot stand-by and disaster recovery plans

Bernstein, Mannie, Sharma        Expires May 2001                   10
 
   draft-bms-sdhsonet-mpls-control-frmwrk-00.txt      November 2000


   for the NMS. The DCN must now be as well protected as the transport
   network itself. However, the survivability of the distributed
   approach is likely to be better since the intelligence is
   distributed, and could even survive to a network partitioning.

   A distributed signaling and routing approach also appears a
   reasonable solution for inter-domain operations. Having hundreds of
   NMSs organized in a tree with a root NMS that controls the various
   NMSs from different operators can be rather difficult, especially in
   the absence of adequate NMS interoperability standards. This is
   probably a significant motivation for resorting to a distributed
   approach.

   Having signaling and routing at each inter-domain interface does not
   imply that we need the same inside each individual domain. However,
   inter-working between intra- and inter-domain operations will be
   greatly facilitated if we a distributed approach is also supported
   internal to a domain. This is particularly true for the signaling,
   using the same protocol for both intra and inter-domain operations -
   seems a sensible approach.

       Distributed approach              Centralized approach

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

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

       Distributed load                  Bottleneck: #requests and
                                         actions to/from NMS
       Individual local routing          Centralized routing decision,
       decision                          can be done per block of
                                         requests
       Routing scalable as for the       Assumes a few big
       Internet                          administrative domains

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

       Requires enhanced routing         Better consistency
       protocol (traffic
       engineering)

       Ideal for inter-domain            Not inter-domain friendly

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

       Probably faster to restore,       Probably slower to restore, but

Bernstein, Mannie, Sharma        Expires May 2001                   11
 
   draft-bms-sdhsonet-mpls-control-frmwrk-00.txt      November 2000


       but more difficult to have        could effect reliable
       reliable restoration.             restoration.

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

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

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


3.5 Why SDH/SONET will not Disappear Tomorrow

   If the IP traffic becomes the unique traffic transported over any
   transmission network, we could consider that the statistical
   multiplexing of IP would completely replace the time division
   multiplexing of  SDH and SONET.  In that case, IP over WDM will be
   used everywhere and lambdas could be optically switched. A carrier's
   carrier will sell dynamically controlled lambdas with each customer
   building its own IP backbone over these lambdas.

   This simple model implies that a carrier will sell lambdas instead
   of bandwidth. The carrier will try to maximize the number of lambdas
   per fiber and each customer will have to fully support the cost for
   each of his end-to-end lambdas. Inthe near future, we may have
   technology to support several hundreds of lambdas per fiber.
   However, a world where lambdas are so cheap and abundant that every
   customer can buy 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 the telecom applications
   (e.g. telephony).

   SDH and SONET possess a rich multiplexing hierarchy that permits a
   finer granularity and provides a very cheap and simple physical
   separation of the transported traffic between circuits. We can
   easily multiplex any kind of traffic, IP or not, synchronous or
   asynchronous.

   Moreover, IP is not used 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
   DWDM is defined in RFC1619/RFC2615 and is also known as POS (Packet

Bernstein, Mannie, Sharma        Expires May 2001                   12
 
   draft-bms-sdhsonet-mpls-control-frmwrk-00.txt      November 2000


   Over SONET/SDH). It is indeed IP over PPP (in HDLC like format) over
   SDH/SONET.

   SDH and SONET are actually efficient encapsulations for IP. For
   instance, with an average IP datagram length of 350 octets, an IP
   over GBE encapsulation using an 8B/10B encoding results in 28%
   overhead, an IP/ATM/SDH encapsulation results in 22% overhead and an
   IP/PPP/SDH encapsulation result in 6% overhead. New simplified
   encapsulations could reduce this overhead to as low as 3%, but the
   gain is not huge compared to SDH and SONET -, which  have other
   benefits as well.

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

   Since the SDH/SONET encapsulation is a good candidate and is anyway
   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. What we are arguing here is
   that it makes sense to do switching or forwarding at all these
   layers.

   Almost all transmission networks today are based on SDH or SONET. A
   client is connected either directly through an SDH or SONET
   interface or through a PDH interface, the PDH signal being
   transported between the ingress and the egress interfaces over SDH
   or SONET. The SDH and SONET technologies are widespread, very well
   understood

4. MPLS Applied to SDH/SONET

4.1. Controlling the SDH/SONET Multiplex

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



Bernstein, Mannie, Sharma        Expires May 2001                   13
 
   draft-bms-sdhsonet-mpls-control-frmwrk-00.txt      November 2000


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

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

4.2. SDH/SONET LSR and LSP Terminology

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

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

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

5. Decomposition of the MPLS Circuit-Switching Problem Space

   Although those familiar with MPLS may be familiar with its
   application in a variety of application areas, e.g., ATM, Frame
   Relay, etc.  we quickly review its decomposition when applied to the
   optical switching problem space.

   (i) Information needed to compute paths must be made globally
   available throughout the network.  Since this is done via the link
   state route protocol, any information of this nature must either be
   in the existing link state advertisements (LSAs) or the LSAs must be
   supplemented to convey this information.  For example, if its
   desirable to offer different levels of service in a network based on
   whether a circuit is routed over SDH/SONET lines that are ring

Bernstein, Mannie, Sharma        Expires May 2001                   14
 
   draft-bms-sdhsonet-mpls-control-frmwrk-00.txt      November 2000


   protected versus not being protected (differentiation based on
   reliability),  the type of protection on a SDH/SONET line would be
   an important topological parameter that should be distributed via
   the link state route 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 may form the "virtual" label. For example in SONET
   if we are 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 the two switches).
   Hence, the multiplex entry number in this case can be used as a
   virtual label. Note that it is virtual in that it is not appended to
   the payload in any way, but it is still a label in the sense that it
   uniquely identifies the signal local to the link between the two
   switches.

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

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

6. MPLS Routing for SDH/SONET

   Modern transport networks based on SONET/SDH excel at
   interoperability in the performance monitoring (PM) and fault
   management (FM) areas, however, they do not inter-operate in the
   areas of topology discovery or resource status.  Although link state
   route protocols, such as IS-IS and OSPF, have been used for some
   time in the IP world to compute destination-based next hops for
   routes (without routing loops), their value in providing timely
   topology and network status information in a distributed manner,
   i.e., at any network node, is immense. If resource utilization
   information is disseminated along with the link status (as was done
   in ATM's PNNI routing protocol) then a very complete picture of
   network status is available to a network operator for use in
   planning, provisioning and operations.

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

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

Bernstein, Mannie, Sharma        Expires May 2001                   15
 
   draft-bms-sdhsonet-mpls-control-frmwrk-00.txt      November 2000


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


6.1. Switching Capabilities

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

6.1.1. Switching Granularity

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

   Table 2.  SDH/SONET switched signal groupings.

      Signal Type    SDH                       SONET

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

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

   Many manufacturers today  switch signals starting at VC-4 for SDH or
   STS-1 for SONET (i.e. the basic frame) and above (see concatenation
   section), but they don't allow to switch lower order signals. Some
   of them allow only to switch aggregates (concatenated or not) of
   signals such as 16 VC-4s, i.e. a complete STM-16, and nothing below.
   Some manufacturers go down to the VC-3 for SDH. Finally, some
   manufacturers allow to go lower than the VC-3/STS-1, down to lower
   order signals such as VC-12s. Some combinations are also possible,
   such as down to VC-12 for unprotected circuits and nothing below VC-
   4 for fast restoration.

Bernstein, Mannie, Sharma        Expires May 2001                   16
 
   draft-bms-sdhsonet-mpls-control-frmwrk-00.txt      November 2000



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

6.1.2. Signal Concatenation Capabilities

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

   Standard SONET concatenation allows the concatenation of M x STS-1
   signals within an STS-N signal with M <= N, and M = 3, 12, 48,
   192,...). The SPEs of these M x STS-1s can be concatenated to form
   an STS-Mc. The STS-Mc notation is short hand for describing an STS-M
   signal whose SPEs have been concatenated.  The multiplexing
   procedures for SONET and SDH are given in references [3], [4], [5],
   Constraints are imposed on the size of STS-Mc signals, i.e., they
   must be a multiple of 3, and on their starting location and
   interleaving.  This has the following advantages: (a) restriction to
   multiples of 3 helps with SDH compatibility (there is no STS-1
   equivalent signal in SDH); (b) the restriction to multiples of 3
   reduces the number of connection types; (c) the restriction on the
   placement and interleaving could allow more compact representation
   of the "label"; The major disadvantages of these restrictions are:
   (a) Limited flexibility in bandwidth assignment (somewhat inhibits
   finer grained traffic engineering). (b) The lack of flexibility in
   starting time slots for STS-Mc signals and in their interleaving
   (where the rest of the signal gets put in terms of STS-1 slot
   numbers) leads to the requirement for re-grooming (due to bandwidth
   fragmentation).

   Due to these disadvantages some SONET framer manufacturers now
   support "flexible"  or  arbitrary concatenation, i.e., no
   restrictions on the size of an STS-Mc (as long as M <= N) and no
   constraints on the STS-1 timeslots used to convey it, i.e., the
   signals can use any combination of available time slots.

   Standard and flexible concatenations are network services, while
   virtual concatenation is a SONET/SDH end system service recently
   approved by the committee T1 of ANSI and ITU-T.  The essence of this
   service is to have SONET/SDH end systems "glue" together the VCs or
   SPEs of separate signals rather than the signals being 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 a virtual STS-2c for

Bernstein, Mannie, Sharma        Expires May 2001                   17
 
   draft-bms-sdhsonet-mpls-control-frmwrk-00.txt      November 2000


   the efficient transport of 100Mbps Ethernet traffic. Note that this
   inverse multiplexing process can be significantly easier with
   SONET/SDH signals rather than for packets. Virtual concatenation,
   being provided by end systems, is compatible with existing SONET/SDH
   networks. Virtual concatenation is defined for higher order signals
   and low order signals.  Table 3 shows the nomenclature and capacity
   for several low order virtually concatenated signals contained in
   different higher order signals.

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

                  Carried In      X           Capacity       In steps
                                                              of

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

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

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

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


6.1.3. SDH/SONET Transparency

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

   As mentioned in the introduction SONET overhead is broken into three
   layers: Section, Line and Path. All these layers are concerned with
   fault and performance monitoring. Section overhead is primarily
   concerned with framing and Line overhead is primarily concerned with
   multiplexing and protection. To perform multiplexing, a SONET
   network element should be line terminating. However, not all SONET
   multiplexers/switches perform SONET pointer adjustments on all the
   STS-1s contained within them or if they perform the 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.  Transparent multiplexing and switching can also
   be viewed as a constraint, since some multiplexers and switches may


Bernstein, Mannie, Sharma        Expires May 2001                   18
 
   draft-bms-sdhsonet-mpls-control-frmwrk-00.txt      November 2000


   not switch at as fine a granularity as others. Table 4 summarizes
   the levels of SONET/SDH transparency.

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

      Transparency Type         Comments

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

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

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


6.2. Protection

   SONET and SDH networks offer a variety of protection options at both
   the SONET line and SONET path level.  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. Both ring and
   1:N line protection also allow for "extra traffic" to be carried
   over the protection line when that line is not being used, i.e.,
   when it is not carrying traffic for a failed working line. These
   protection methods are summarized in Table 5. It should be noted
   that these protection methods are completely separate of any MPLS
   layer protection or restoration mechanisms.

   Table 5. Common SONET/SDH 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


Bernstein, Mannie, Sharma        Expires May 2001                   19
 
   draft-bms-sdhsonet-mpls-control-frmwrk-00.txt      November 2000


                                          by N working lines. N @ 
                                                                  1
                                                                   4

       4F-BLSR (4          Yes            Dedicated protection, with
       fiber bi-                          alternative ring path.
       directional
       line switched
       ring)
       2F-BLSR (2          Yes            Dedicated protection, with
       fiber bi-                          alternative ring path
       directional
       line switched
       ring)
       UPSR (uni-          No             Dedicated protection via
       directional                        alternative ring path.
       path switched                      Typically used in access
       ring)                              networks.


   It may be desirable to route some connections over lines that
   support protection of a given type, while others may be routed over
   unprotected lines, or as "extra data" 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 route protocol.  For example suppose that a 1:N
   protection group is being configured via two nodes.  One must make
   sure that the lines are "numbered the same" with respect to both end
   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


Bernstein, Mannie, Sharma        Expires May 2001                   20
 
   draft-bms-sdhsonet-mpls-control-frmwrk-00.txt      November 2000



                           SONET then this parameter is unneeded,
                           otherwise it would indicate the signal
                           layer that the protection is applied.


   How much information to disseminate concerning protection is an open
   issue with the contents of Table 6 representing one extreme and a
   simple enumerated list of: Extra-Traffic/Protection line,
   Unprotected, Shared (1:N)/Working line, Dedicated (1:1, 1+1)/Working
   Line, Enhanced (Ring) /Working Line, representing the other.

   There is also a potential implication for link bundling, that is,
   for each link, the routing protocol could advertise whether it 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.


6.3. Available Capacity Advertisement

   Internally to each SDH/SONET LSR interface, a table is maintained
   indicating each signal allocated in the multiplex structure. This is
   the most complete and accurate view of the link usage and available
   capacity.

   This information needs to be advertised in some way to all others
   SONET/SDH LSRs in the same domain for use in path computation. There
   is a trade off to be reached concerning:
   the amount of detail in the available capacity information to be
   reported via a link state routing protocol,
   the frequency or conditions under which this information is updated,
   the percentage of connection establishments that are unsuccessful on
   their first attempt,
   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



Bernstein, Mannie, Sharma        Expires May 2001                   21
 
   draft-bms-sdhsonet-mpls-control-frmwrk-00.txt      November 2000


   advertised, or on the other extreme, an single aggregated value of
   the available bandwidth could be advertised.

   Consider first the relatively simple structure of SONET and its most
   common current and planned usage. DS1s and DS3s are the signals most
   often carried within a SONET STS-1.  Either a single DS3 occupies
   the STS-1 or up to 28 DS1s (4 each within the 7 VT groups) are
   carried within the STS-1. With a reasonable VT1.5 placement
   algorithm within each node it may be possible to just report on
   aggregate bandwidth usage in terms of number of whole STS-1s
   (dedicated to DS3s) used and the number of STS-1s dedicated to
   carrying DS1sallocated 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 yet the best way to advertise bandwidth
   resource availability/usage in SONET/SDH. However, due to the
   multiplexed nature of the signals reporting of bandwidth particular
   to signal types rather than as a single aggregate bit rate is highly
   desirable.

6.4. Path Computation

   Although a link state route protocol can be used to obtain network
   topology and resource information, this does not imply the use of an
   "open shortest path first" route. The path must be open in the sense
   that the links must be capable of supporting the desired signal type
   and that capacity must be available to carry the signal.  Other
   constraints may include hop count, total delay (mostly propagation),
   and hop count. In addition, it may be desirable to route traffic in
   order to optimize overall network capacity, 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 along the line of global or local optimization of the network.
   Due to the complexity of some of the route algorithms (high
   dimensionality non-linear integer programming problems) and various
   criteria by which one may optimize their network it may not be
   possible or desirable to run these algorithms on network nodes.
   However, it may still be desirable to have some basic path
   computation ability running on the network nodes, particularly in
   restoration situations. Such an approach is in line with the use of



Bernstein, Mannie, Sharma        Expires May 2001                   22
 
   draft-bms-sdhsonet-mpls-control-frmwrk-00.txt      November 2000


   MPLS for traffic engineering but is much different than typical OSPF
   or IS-IS usage where all nodes must run the same route algorithm.

6.5. Link Bundling in Routing: Reducing Adjacencies

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

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


7. LSP Provisioning/Signaling for SDH/SONET

   Traditionally, end-to-end circuit connections in SDH/SONET networks
   have been set up via network management systems (NMSs), which issue
   commands (usually under the control of a human operator) to the
   various network elements involved in the circuit, via an equipment
   vendor's element management system (EMS). Very little multi-vendor
   interoperability has been achieved via management systems. Hence,
   end-to-end circuits in a multi-vendor environment typically require
   the use of multiple management systems and the infamous
   configuration via "yellow sticky notes". As discussed in Section 2,
   a common signaling protocol, such as RSVP with TE extensions or CR-
   LDP appropriately extended for circuit switching applications, could
   therefore help to solve these interoperability problems. In this
   section, we examine the various components involved in the automated
   provisioning of SONET/SDH LSPs  and the associated signaling.


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

   MPLS was initially introduced to control asynchronous technologies
   like IP, where a label was attached to each individual block of
   data, such as an IP packet or a Frame Relay frame. SONET and SDH,
   however, are synchronous technologies that define a multiplexing
   structure (see Section 1.2), which we referred to as the SDH (or
   SONET) multiplex in Section 1.2. 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 slots per frame, and these signals can be
   controlled using MPLS.



Bernstein, Mannie, Sharma        Expires May 2001                   23
 
   draft-bms-sdhsonet-mpls-control-frmwrk-00.txt      November 2000


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

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

   Observe also that the MPLS signaling used to control the SDH/SONET
   multiplex must honor its hierarchy. In other words, the SDH/SONET
   layer should not be viewed as homogeneous and flat, because this
   would limit the scope of the services that it can provide. Instead,
   MPLS 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).

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

7.2. Label Structure in SDH/SONET

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



Bernstein, Mannie, Sharma        Expires May 2001                   24
 
   draft-bms-sdhsonet-mpls-control-frmwrk-00.txt      November 2000


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

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

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


7.2.1. SDH/SONET Multiplex Entry Name

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

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

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

Bernstein, Mannie, Sharma        Expires May 2001                   25
 
   draft-bms-sdhsonet-mpls-control-frmwrk-00.txt      November 2000



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

7.2.2. SDH/SONET Multiplex Entry Notation

   We propose the - following hierarchical multiplex entry notation:

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

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

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

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

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

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

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

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

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

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


Bernstein, Mannie, Sharma        Expires May 2001                   26
 
   draft-bms-sdhsonet-mpls-control-frmwrk-00.txt      November 2000


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


             SDH                       SONET

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

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

   This may be illustrated with the following examples.

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

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

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

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

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


7.2.3.  SDH/SONET Multiplex Entry Encoding:

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


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


Bernstein, Mannie, Sharma        Expires May 2001                   27
 
   draft-bms-sdhsonet-mpls-control-frmwrk-00.txt      November 2000


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

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


7.2.4. Hierarchical Label Allocation:

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

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

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

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

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


Bernstein, Mannie, Sharma        Expires May 2001                   28
 
   draft-bms-sdhsonet-mpls-control-frmwrk-00.txt      November 2000



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

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


7.3. Signaling Elements

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

   Clearly, information that is required to completely specify the
   desired signal and its characteristics must be transferred via the
   label distribution protocol, so that the switches along the path can
   be configured to correctly handle and switch the signal. As we
   explain ahead, this information is specified in three parts, each of
   which refers to a different network layer. The first specifies the
   nature/type of the LSP or the desired SDH/SONET channel, in terms of
   the particular signal (or collection of signals) within the
   SDH/SONET multiplex that the LSP represents, and is used by all the
   nodes along the path of the LSP. The second specifies the payload
   carried by the LSP or SDH/SONET channel, in terms of the termination
   and adaptation functions required at the end points, and is used by
   the source and destination nodes of the LSP.  The third specifies
   certain link selection constraints, which control, at each hop, the
   selection of the underlying link that is used to transport this LSP.
   In the following subsections, we discuss each of these in more
   detail.


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

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


Bernstein, Mannie, Sharma        Expires May 2001                   29
 
   draft-bms-sdhsonet-mpls-control-frmwrk-00.txt      November 2000


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

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

7.3.1.1. LSP Encoding Type and Signal Type

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


                LSP Encoding Type     Signal Type

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



Bernstein, Mannie, Sharma        Expires May 2001                   30
 
   draft-bms-sdhsonet-mpls-control-frmwrk-00.txt      November 2000


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

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

7.3.1.2. Connection  Bundling

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

   Such concatenation simplifies connection establishment  (especially
   for batches of DS-3s that are being wholesaled) and speeds re-
   routes. Since bundling may be important when establishing STS-1s
   that will be used between end-systems implementing virtual
   concatenation, it is recommended that the labels chosen for SONET
   paths be capable of incorporating the concept of STS-1 bundling. The
   bundling of larger signals, i.e., groups of STS-Mc, is for further
   study.

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

7.3.2 Payload Type



Bernstein, Mannie, Sharma        Expires May 2001                   31
 
   draft-bms-sdhsonet-mpls-control-frmwrk-00.txt      November 2000


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


         LSP Encoding Type      Payload/Client Type


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


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


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

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

7.3.3. Link Protection Type

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


Bernstein, Mannie, Sharma        Expires May 2001                   32
 
   draft-bms-sdhsonet-mpls-control-frmwrk-00.txt      November 2000


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

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

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

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

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

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

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

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

   Enhanced

Bernstein, Mannie, Sharma        Expires May 2001                   33
 
   draft-bms-sdhsonet-mpls-control-frmwrk-00.txt      November 2000


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

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

8. Choices for Control Channel Implementation

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

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

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

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

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

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

Bernstein, Mannie, Sharma        Expires May 2001                   34
 
   draft-bms-sdhsonet-mpls-control-frmwrk-00.txt      November 2000



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


9. Summary and Conclusions

   In this paper, we gave a detailed account of the issues involved in
   applying MPLS-based control to TDM networks (a general overview of
   these issues for applying GMPLS to optical networks appears in
   [11]).

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

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

10. Security Considerations

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


11. References


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

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

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

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

[5] Synchronous Optical Network (SONET) Transport Systems: Common
Generic Criteria, Bellcore GR-253-CORE, Issue 2, December 1995.
Synchronous Optical Network (SONET) Transport Systems: Common Generic
Criteria, Bellcore GR-253-CORE, Issue 2, December 1995.


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

[7] Ben Mack-Crane, V. Sharma, Greg Bernstein, Eric Mannie, et al,
Enhancements to GMPLS Signaling for Optical Technologies, Internet
Draft, Work in Progress,
draft-mack-crane-gmpls-signaling-enhancements-00.txt, November 2000.

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

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

[10] E. Mannie, "MPLS for SDH Control", Internet Draft, Work in
Progress, draft-mannie-mpls-sdh- control-00.txt. March 2000.

[11] Greg Bernstein and Vishal Sharma, Some Comments on GMPLS and
Optical Technologies, Internet Draft, Work in Progress,
draft-bernstein-gmpls-optical-00.txt, November 2000.

[12] Vas Makam, V. Sharma, Ben Mack-Crane, et al, Framework for
MPLS-based Recovery, Internet Draft, Work in Progress,
draft-ietf-mpls-recovery-frmwrk-00.txt, September 2000.





Bernstein, Mannie, Sharma        Expires May 2001                   35