Network Working Group G. Bernstein Internet Draft Ciena Expiration Date: May 2001 V. Sharma Document: draft-bernstein-gmpls-optical-00.txt Tellabs November 2000 Some Comments on GMPLS and Optical Technologies 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. Abstract GMPLS [2] is being considered as an extension to the MPLS framework to include optical, non-packet switched technologies. This draft reviews the motivation for doing so from an end-userÆs perspective and points out some key requirements/impacts that this will have on the extensions to the routing and label distribution/signaling protocols. Table of Contents Page 1.0 Introduction 1.1 Specification of Requirements 1.2 Abbreviations 2.0 Motivation for MPLS-based Control 2.1 Multi-vendor Topology/Resource Discovery 2.2 Multi-vendor Connection Control 2.3 Path Computation 3.0 Impacts on MPLS Protocols 3.1 TDM Multiplexing Hierarchies and MPLS Protocols 3.1.1 Implications for Routing 3.1.2 Implications for Label Distribution/Signaling Bernstein, G. [Page 1]
draft-bernstein-gmpls-optical-00.txt November 2000 3.2 WDM Hierarchies and MPLS Protocols 3.2.1 Implications for Routing 3.2.2 Implications for Label Distribution/Signaling 4.0 Conclusions and Recommendations 5.0 Security Considerations 6.0 References 7.0 Acknowledgements 8.0 AuthorsÆ Addresses 1. Introduction Multi-Protocol Label Switching (MPLS) has received much attention recently for use as a control plane for non-packet switched technologies. In particular, optical technologies have a need to upgrade their control plane as reviewed in reference [3]. Many different optical switching and multiplexing technologies exist, and more are sure to come. For the purposes of this draft we only consider non-packet (i.e. circuit switching) forms of optical switching. The two main forms of optical multiplexing are wavelength division multiplexing (WDM) and time division multiplexing (TDM). A considerable amount of standards are in place for the optical TDM hierarchy known as SONET/SDH. A framework for controlling SDH by MPLS was presented in [4] and some of the issues concerning SONET and MPLS were presented in [5]. Along with these multiplex structures, which can be quite rich (i.e. complicated), come various types and layers of switching capability. For example, for dealing with WDM multiplexes GMPLS includes the notions of lambda switching (switching individual WDM signals), wave band switching (switching of a group of WDM signals that occupy a contiguous portion of the optical spectrum), and fiber switching (switching of the entire contents of a fiber). Before discussing further examples, and implications of this structure, we review the motivation for an MPLS-based control plane. We present a big-picture view of multiplexing and then discuss the implications for routing and signaling. 1.1. Specification of Requirements 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. 1.2 Abbreviations LSP Label Switched Path (MPLS terminology) MPLS Multi-Protocol Label Switching SDH Synchronous Digital Hierarchy STM(-N) Synchronous Transport Module (-N) SPE Synchronous Payload Envelope (SONET) Bernstein, G. [Page 2]
draft-bernstein-gmpls-optical-00.txt November 2000 STS(-N) Synchronous Transport Signal-Level N (SONET) TU-n Tributary Unit-n (SDH) TUG(-n) Tributary Unit Group (-n) (SDH) VC-n Virtual Container-n (SDH) VTn Virtual Tributary-n (SONET) 2.0. Motivation for MPLS-based Control At a recent MPLS conference, a speaker took a fair amount of time to explicitly differentiate the use of optical technology in support of MPLS, i.e., running MPLS over optical links, versus using MPLS technology to control optical networks. This is a very important distinction that sometimes gets blurred. This draft is concerned with the extension of MPLS for use in controlling non-packet switching networks in a way that is completely agnostic to the content flowing through the network, i.e., it makes no assumptions that the content of the circuits that are setup is IP traffic or any particular form of traffic. We are explicit about this point since we are interested in a general purpose control-plane mechanism and not one that assumes that the contents of the pipes themselves must be IP or MPLS traffic. As reviewed in the following sections the main functionalities that we desire from this control plane are topology/resource discovery and connection control. An area not needing standardization, and one source of vendor/customer added value, is the route computation procedure. 2.1. Multi Vendor Topology/Resource Discovery Optical switching systems currently do not inter-operate in the areas of topology discovery or resource status. This means that it is difficult to get a single overall view of the network that can be used for operations and end-to-end path computation. Link-state routing protocols, such as IS-IS and OSPF, have been used for some time in the IP world to compute destination-based next hops for routes (without routing loops). In non-packet networks, however, their immense value comes from their ability to provide timely topology and network status information in a distributed manner, i.e., at any network node. 2.2. Multi-Vendor Connection Control Traditionally, end-to-end circuit connections 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". A common signaling protocol such as RSVP with TE extensions Bernstein, G. [Page 3]
draft-bernstein-gmpls-optical-00.txt November 2000 or CR-LDP appropriately extended for circuit switching applications could help to solve these interoperability problems. 2.3. 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 bandwidth must be available, however the switches along the path must also be capable, in some way, of transporting the desired signal type, which results in an important additional constraint, not typically found in packet networks. Other constraints may include hop count, total delay (mostly propagation), and link protection type [2],[6]. In addition, it may be desirable to route traffic in such as way as to optimize overall network capacity, or reliability, or some combination of the two. Observe that Dijkstra'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, with the objective of optimizing network link utilization. One can think along the lines of global or local optimization of the network. Due to the complexity of some of the route algorithms (high dimensionality, and non-linear integer programming problems, for example) and various criteria by which one may optimize the network, it may not be possible or desirable to run these algorithms on network nodes. However, it may still be desirable to have some form of path computation ability running on the network nodes, particularly in restoration situations, where quick recovery is required after a fault or failure on the working path. Such an approach is in line with the use of MPLS for traffic engineering, but is much different than typical OSPF or IS-IS usage where all nodes must run the same route computation algorithm. 3.0. Impacts on MPLS Protocols The special nature of SONET/SDH circuits, therefore, impacts both the routing and signaling protocols for MPLS, as discussed briefly below. The information needed to compute paths must be made globally available throughout the network. Since in MPLS-based networks this is done via the link state route protocols, 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. A somewhat more nebulous requirement is that information, such as link protection type [2],[6] needed for a global view of network operations should also be distributed via the route protocol, because they provide a convenient interoperable way to distribute this information. Bernstein, G. [Page 4]
draft-bernstein-gmpls-optical-00.txt November 2000 The information needed to completely specify the signal and its characteristics (which we collectively call the signal type) must be transferred via the label distribution protocol. This is particularly important so that the switches along the path can be configured to correctly handle and switch the signal. Examples from the TDM and WDM multiplex hierarchies are given below. 3.1. TDM Multiplexing Hierarchies and MPLS Protocols Before delving into the details of the TDM and WDM hierarchies, it is important to know why circuit-switched multiplex structures are complicated relative to packet switched multiplex structures (or at least why they seem that way when viewed from the packet switched world, which is the perspective taken here). First, unlike packet switching, when setting up circuits in the TDM world, we are dedicating bandwidth for the exclusive use of the two end systems involved with the connection. Other circuits in the network cannot share this bandwidth -. To make effective use of circuit-switched bandwidth, therefore, the different types of signals have been arranged in multiplexing hierarchies, which include the well known T1 and E1 hierarchies (typically referred to as PDH for plesiochronous digital hierarchy), and the SONET/SDH (synchronous digital hierarchy) hierarchy. In the PDH hierarchies there are about three to four fundamental signals, ranging in speed from 64Kbps to 45Mbps. Unfortunately, due to historical reasons there tend to be a number of different variations of these fundamental signals. This complicates matters, since it produces a number of signals with the same bit rate and same coarse framing. These differences typically have to do with overhead functionality, some of which can be quite intrusive (e.g. robbed bit signaling). In the SONET/SDH hierarchy used in TDM optical networks there are about three levels of multiplexing, with a variety of signals (3-5) within each level. These signals range in speed from about 1.5Mbps to 10Gbps. From this brief description of the common TDM multiplex structures, one can see that packets in many ways are much easier to deal with. One thing that can be said for circuits is the fine grained guaranteed bandwidth that they can provide. 3.1.1. Implications for Routing Given these different TDM hierarchies, we ask what do we need to know from routing? It turns out that we actually need two types of information about a link from the route protocols. The first is static information, describing the switching capabilities of a link, while the second is dynamic information, describing the capacity utilization of the link (which, as we shall see shortly, differs significantly from how it is typically described for packet multiplexed links). 3.1.1.1. Static Link Information Bernstein, G. [Page 5]
draft-bernstein-gmpls-optical-00.txt November 2000 With optical TDM links, we need to know the switching capabilities supported by the end of a link, i.e., which hierarchy does a link support and what types of signals within that hierarchy can it switch. This is of fundamental importance in optical TDM networks, because, unlike packet multiplexed links, each link now supports a small, fixed number of discrete signal types. Therefore, the links that are suitable for carrying a given TDM channel/circuit are only those that can switch the particular type of signal of which the TDM channel/circuit is comprised. As more layers of switching get integrated into a single port this can be a fair amount of information. This information is relevant within the context of the TDM hierarchy that is supported. Note that more than one TDM hierarchy may be supported on an interface. Note that the static capabilities of a link are not an issue in packet-based networks, because the types of signals that a packet or cell multiplexed link can switch are uniform, and because the bandwidth of those signals can take any value up to a maximum value. For example, a packet-over-SONET (POS) link terminates the SONET overhead, and switches the packets within. Thus, it switches only one type of signal, namely IP packets. Further, there is no restriction on the bandwidth of the LSPs that it can accommodate. Thus, the link can switch any packet LSP up to its maximum available bandwidth, or any combination of packet LSPs whose combined bandwidth does not exceed its total bandwidth. Thus, there is not need to separately advertise the switching capability of such links. 3.1.1.2. Dynamic Link Information In order to compute a path, we also need to know, how much capacity is available on a particular link. This is clearly a dynamic parameter, and can get quite involved due to the packing restrictions imposed by some of the hierarchies. Since, in circuit switching, bandwidth is dedicated rather than shared, optimizing of its use is more critical here. This is why "traffic engineering" is a very old notion in the circuit switched world. At a minimum, it is necessary for a path computation algorithm to understand the bandwidth available, in terms of number of supportable signals at various levels in a hierarchy. In other words, what must be advertised in routing is not residual or available bandwidth, but rather the number of connections of each signal type that the link can support at any given time. This is because, depending on the TDM hierarchies supported, in optical TDM networks, a link is capable of switching a certain (fixed) number of connections of each given signal type. Thus, the available capacity of a link is best expressed not in terms of bandwidth, but rather in terms of the number of connections of each given type that it has available. Unfortunately, in optical TDM networks, "fragmentation" of bandwidth (like fragmentation of a disk drive) can occur leading to rather inefficient use of bandwidth. To prevent this, more detailed signal mapping information may be needed. This issue also can come up in WDM switching involving lambdas and wavebands. Bernstein, G. [Page 6]
draft-bernstein-gmpls-optical-00.txt November 2000 Note how much this differs from the statistical notions of bandwidth being considered for packet switched networks, -where a single number such as available "equivalent bandwidth" may suffice to characterize the available resources of a link. 3.1.2 Implications for Label Distribution/Signaling When dealing with a TDM multiplex hierarchy, the most important aspect of the connection, besides the end point, is the signal type. As discussed previously, there may be a number of different types of signals with the same or similar "bandwidth" measure, not all of which can be switched by the same link. This is because each of these signals may require different switching capabilities on the links. Hence, unlike the packet switched case, where a leaky bucket based set of bandwidth parameters are used to characterize the requested flow, no such bandwidth measure is needed in the TDM multiplex case. Rather, the signal type must be explicitly specified along with the label request. This is because the signal type is instrumental in indicating the type of LSP requested, and in enabling the determination of which available links may carry the requested LSP. 3.2. WDM Hierarchies and MPLS Protocols Lambda, waveband, and fiber switching are newer and still developing technologies with relatively few standards in place compared to the optical TDM world. Some refer to these forms of switching as pure optical switching since optical signals are not converted to electrical signals for the purpose of switching. However, this definition is not very clear because some optical switches actually are surrounded by O-E-O (optical electrical optical) converters, thus looking essentially like an electrical-based switch fabric as far as its routing properties would be concerned. In a straightforward application of WDM multiplexing, a digital signal is modulated onto a specific wavelength of light and then these separate wavelengths are combined into a single fiber for transmission. For such a system to be operated correctly regardless of the length of the fiber or nonlinear effects, these separate signals cannot appreciably overlap in the frequency (spectral) domain. In addition, there must be mechanisms available to demultiplex these signals at the reception point. Technology dependencies immediately start to kick in at this point, as explained ahead. Currently, it is easiest and most economical to require the WDM signals to occur at regular intervals in the frequency domain. There are currently a number of international standard or industry standard spacings for WDM systems. These include 100GHz and 50GHz, 25GHz and 12.5GHz. A signal intended for use with 100GHz spacing Bernstein, G. [Page 7]
draft-bernstein-gmpls-optical-00.txt November 2000 system will not work with a 50GHz spacing system. Also, the converse tends to be true for a host of issues beyond the scope of this text. Hence, for a WDM optical link a fundamental characteristic that would need to be advertised in the routing protocol would be the channel spacing (and of course the offset frequency or lambda). 3.2.1. Implications for Routing As explained above, when advertising available capacity in the WDM case, instead of a single bandwidth measure, we typically need to know exactly which channels are populated. This is so that we can compute a route from source to destination for this particular lambda. Note that wavelength converters may be deployed and will certainly complicate this picture with their spectral conversion properties. This is also important in wave-band switching, where very inefficient use of the spectrum can result from switching only partially filled bands. 3.2.2. Implications for Label Distribution/Signaling To request the setup of a LSP for either lambda or waveband switching a key parameter needed to characterize the signal is the center wavelength (or center frequency) of the light wave to be established. Equally important is the signalÆs spectral extent or spectral bandwidth. This is usually the width of the signal in the frequency domain, where the power spectral density has fallen off to a given number of decibels (dBs). This information is important in determining whether the signal is compatible with the grid spacings (WDM signal intervals) of the possible links over which the signal could be routed. This measure is completely different from a signal bit-rate measure (such as the current RSVP bandwidth parameter in bytes per second). The reason for this is that the spectral characteristics are dependent on the modulation format. For a general overview of modulation formats, see reference [7]. For a discussion of some of the modulation formats currently being used for optical communications, see reference [8]. 4.0 Conclusion and Recommendations An overview of two different optical circuit switched hierarchies was given. The implications of using GMPLS as a control plane for such networks was described and contrasted with current MPLS concepts for control of packet-switched networks. Since the goal is to use MPLS to control disparate technologies, it appears that there is no way to avoid technology-specific routing and label distribution extensions - to MPLS protocols. In the description of the WDM hierarchy we focused on only one aspect of WDM systems, i.e., their spectral properties. Many other aspects such as dispersion, loss, and nonlinear effects also come into play and would have to be addressed before optical interoperability could be achieved. With the rapid advances in Bernstein, G. [Page 8]
draft-bernstein-gmpls-optical-00.txt November 2000 optical WDM technology it may be best to focus first on the extensions needed for the optical TDM hierarchy. Due to the technology-specific extensions required when applying GMPLS to a specific transport technology, we recommend a clear delineation between general and technology specific parameters. A general parameter should have significance across all technologies. As the examples given showed, bandwidth in MBps is not a valid parameter for characterizing either a requested WDM or TDM signal. A similar issue arose with the routing protocol extensions describing available capacity of a link. It is our hope that the GMPLS work will follow two general interwoven efforts. One of these is the general extensions needed for MPLS to deal with multi-level, non-packet switched networks. The other is a series of technology specific extensions, developed by parties interested in a specific technology. One of the key requirements is that extensions for a specific technology, say waveband switching WDM, can be updated without impacting the implementation of a different layer technology e.g., SONET/SDH. 5. Security Considerations Security considerations are not discussed in this version of the document. 6. References [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [2] 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. [3] G. Bernstein, J. Yates, D. Saha, "IP-Centric Control and Management of Optical Transport Networks", IEEE Communications Magazine, October 2000. [4] E. Mannie, "MPLS for SDH Control", draft-mannie-mpls-sdh- control-00.txt. Work in progress]. [5] G. Bernstein, "Some Comments on the Use of MPLS Traffic Engineering for SONET/SDH Path Establishment", Internet Draft, draft-bernstein-mpls-sonet-00.txt, Work in Progress, February 2000. [6] B. Mack-Crane, V. Sharma, G. Bernstein, et al, "Enhancements to GMPLS Signaling for Optical Technologies," Internet Draft, draft- mack-crane-gmpls-signaling-enhancements-00.txt, Work in Progress, November 2000. Bernstein, G. [Page 9]
draft-bernstein-gmpls-optical-00.txt November 2000 [7] Bernard Sklar, Digital Communications: Fundamentals and Applications, Prentice Hall, 1988. [8] Rajiv Ramaswami and Kumar N. Sivarajan, Optical Networks: A Practical Perspective, Morgan Kaufman, 1998. 7. Acknowledgments 8. Author's Addresses Greg Bernstein Vishal Sharma Ciena Corporation Tellabs Research Center 10480 Ridgeview Court One Kendall Sq., Bldg. 100 Ste. 121 Cupertino, CA 94014 Cambridge, MA 02139-1562 Phone: (408) 366-4713 Phone: (617) 577-8760 Email: greg@ciena.com Email: Vishal.Sharma@tellabs.com Bernstein, G. [Page 10]