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