Internet Draft


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]