• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Multi-Protocol Lambda Switching: The Role of IP Technologies in Controlling and Managing Future Optical Networks

Multi-Protocol Lambda Switching: The Role of IP Technologies in Controlling and Managing Future Optical Networks



This is an early short tutorial from back in 2001 that focuses on the control of dynamic (or agile) optical networks. We begin by highlighting the motivation for such networks, their basic ...

This is an early short tutorial from back in 2001 that focuses on the control of dynamic (or agile) optical networks. We begin by highlighting the motivation for such networks, their basic requirements, and the advantages of agility. We examine the functionality needed for routing and connection establishment in such dynamic networks, and compare possible candidates for the design of such a...



Total Views
Views on SlideShare
Embed Views



1 Embed 1

http://www.linkedin.com 1


Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment
  • Multi-protocol lambda switching , is a term coined by the IP networking community, and has been the recent focus of a fair amount of activity in various standards bodies. It refers to the integration of the routing and signaling protocols developed for multi-protocol label switching (MPLS) in IP networks with the new generation of “intelligent” optical (and digital) cross-connects. The objective of such an integration is to build a seamless, dynamically provisioned, transport network. Our aim in this tutorial is to take a systematic look at this proposal, and try to expose the rationale behind the integration, understand its operation and benefits, and highlight some of the difficulties that must be overcome before it can be implemented.
  • The phrase “dynamic network” refers to a core (or transport) network where channels can be established and torn down, on demand, at fairly short time scales (on the order of minutes, for example). We will begin by looking first at the concept of a “dynamic” optical network, and ask what is the motivation to have them. After providing some rationale for them, we will look at the basic control components needed to realize a dynamic network, as well as the advantages of making the network dynamic. Having established the motivation behind, the requirements for, and the advantages of dynamic optical networks, we’ll look at possible candidates for the control plane of such networks, and examine some of the reasons behind considering an IP-based MPLS control plane. The next step will be to see how the IP protocols as well as the optical elements (which includes optical cross-connects [OXCs], digital cross-connects [DCSs], and add-drop multiplexers [ADMs]) need to be enhanced to support this integration. Finally, we’ll look at possible implementation choices and architectural considerations, and close by looking at some open issues in this deployment.
  • A natural question to ask first is, “What is the purpose of building dynamic optical networks?” The answer to it comes from the following. (i) First, with the rapid growth in the number of wavelengths and fibers, there is a need to minimize the complexity of network provisioning and decrease provisioning time. This requires a shift from operator-initiated, manual configuration (which currently takes anywhere from several weeks to months before a new circuit/channel can be configured) to an automated, signaling-based establishment process (which is expected to take minutes). The ability to perform rapid provisioning also allows a service provider to offer several new types of services (some examples of which we’ll see later) that rely on quick connection setup and teardown. (ii) Second, with electronic packet/cell processing speeds lagging behind the tremendous increase in link speeds, there is a need to eliminate packet processing at intermediate nodes. This can be done by switching and routing entire channels at the optical level , rather than individual packets/cells at the electronic level. So, if all the packets in a big stream of data are routed identically, there is no need to switch each packet. Rather the entire stream can be switched without examining and routing each packet separately.
  • What then are the basic components for agility in an optical network? There are five basic components: 1. The first is the discovery of network interconnections (topology) and resources (fibers, wavelengths, and switch capabilities), which happens by talking to one’s neighbors. 2. Then there is the distribution and maintenance of pertinent network state information (the amount of used capacity per link, status of links and fibers, etc.) via routing protocols. 3. Path selection algorithms, which use the advertised network state to pick appropriate paths for connections, based on policy and resource constraints. 4. Having picked a path, one must program the intermediate nodes to reserve switching resources. This involves the instantiation and maintenance of paths by programming intermediate nodes. 5. Finally, since we are talking of a transport network, which carries large aggregates of data, we need adequate protection/restoration mechanisms to ensure reliability of the established paths.
  • So what does dynamic operation buy us? i) As shown in the figure, it enables the virtual topology between routers to be altered on a short time scale. This simplifies L3 routing, because the virtual topology can be made to match the traffic patterns between routers, and thereby eliminate multiple hops between them. For example, in the example, the 3-hop path formed by the original lightpaths between routers R1 and R4 is replaced, by altering the lightpaths, by a single-hop path. ii) The service providers can now offer new services, such as bandwidth on demand or virtual private networks (VPNs) that were not feasible in a static network, because connectivity between routers could not be altered in within the needed time frame. iii) Intelligence in the network also enables smooth interworking between OXCs, DCSs, O-ADMs, and IP routers. iv) Finally, the network operator gains sophisticated configuration mechanisms that can be used to control the network.
  • Thus, based on what we have seen, the components that an optical network needs for agility are: 1) an addressing/naming scheme to identify network elements, 2) enhanced routing protocols to distribute network topology and resource availability information, 3) algorithms for computing paths and selecting those that satisfy certain setup criteria, 4) protocols to signal the establishment of the selected paths, and 5) schemes for protection and restoration of established paths.
  • Before proceeding further, it is instructive to focus briefly on the traditional “control plane” for transport networks and see why it cannot adequately provide the functionality we just saw. Network management refers to the control actions initiated by an operator via a network management system (NMS), using independent contact with each concerned element. A major drawback of this is that, following a failure, the network has no way of converging automatically to a stable state. (This is because there is no autodiscovery of topology, and no dynamic way of communicating changed topology information to the network elements.) Furthermore, there is no mechanism to facilitate quick provisioning in the network. The absence of distributed dynamic routing and signaled provisioning, complicates the inter-working of equipment from different vendors, because each piece of equipment has its own element management system (EMS) that is controlled by its own NMS. Also, no standardization of NMSs currently exists.
  • So what are the likely options for the control plane? One option could be to devise a new routing and signaling plane, based on the needs we’ve discussed earlier. Clearly, this introduces yet another layer, and thus increases maintenance costs, complicates interoperation with data (IP) networks, and requires co-ordination with higher layer restoration schemes. A second option is to improve network management to make it dynamic. A third option might be to turn to data networks, where routing and signaling protocols already exist, and try to adapt some of these protocols for use with optical networks. Due to its complexity, let us set the first option aside, and examine the viability of the other two.
  • Network management (NM) schemes rely on a NM station talking individually to each network element. As such, they lack hop-by-hop signaling for connection setup. The figure shows the sequence of communications that is needed to establish a path through two networks. The lack of a common NMS for a cloud with multi-vendor equipment means that yet another layer of common control over the disparate NMSs is necessary, in order for their individual differences to be hidden. Further, establishing a connection across networks requires NMS-to-NMS communication, which is not standardized and is quite difficult to come to an agreement on. Also, with different NMSs one can see that soon the topology and resilience of the NMS network is itself an issue. Since network management systems (NMSs) are usually closely tied to specific device architectures, obtaining agreement on standardization has proven to be rather difficult. In other words, there is a close coupling between the design of the NMS and the underlying device architecture. Furthermore, with an NMS-based approach, recovery and its associated signaling becomes more complex. In the example shown, a link failure must first be communicated to the NMS. This causes the NMS to set up an alternate path by communicating individually with each of the elements concerned. Once the path is established, the NMS informs the source that it may switch to the alternate path.
  • Network management (NM) schemes rely on a NM station talking individually to each network element. As such, they lack hop-by-hop signaling for connection setup. The figure shows the sequence of communications that is needed to establish a path through two networks. The lack of a common NMS for a cloud with multi-vendor equipment means that yet another layer of common control over the disparate NMSs is necessary, in order for their individual differences to be hidden. Further, establishing a connection across networks requires NMS-to-NMS communication, which is not standardized and is quite difficult to come to an agreement on. Also, with different NMSs one can see that soon the topology and resilience of the NMS network is itself an issue. Since network management systems (NMSs) are usually closely tied to specific device architectures, obtaining agreement on standardization has proven to be rather difficult. In other words, there is a close coupling between the design of the NMS and the underlying device architecture. Furthermore, with an NMS-based approach, recovery and its associated signaling becomes more complex. In the example shown, a link failure must first be communicated to the NMS. This causes the NMS to set up an alternate path by communicating individually with each of the elements concerned. Once the path is established, the NMS informs the source that it may switch to the alternate path.
  • By contrast, a distributed control plane has several advantages. It allows for easier connection setup because it enables a single endpoint to initiate it, and lets the request trickle through the elements in the path (as opposed to having the NMS communicate with each element sequentially). Since a component of the control plane sits on each element, there is a tighter coupling between the control plane and the element. Thus, the health of the control plane is easier to monitor. Finally, there is agreement that such a setup must have uniform semantics to enable inter- working across different vendors and networks. Thus, the required protocols can be standardized.
  • Before we proceed further, it would be useful to first examine the basic operation and features of multi-protocol label switching (MPLS). In an MPLS network, each router has a label that it appends to packets of a given class (defined, for example, by an address prefix). The label forwarding table at a router is created by a combination of routing and signaling as follows. The routing tables at the routers are filled first, via the routing protocols (This is Step 1 in the figure). In the example above, the routing tables for R1 and R2 are shown. Each row of the routing table consists of a destination address (DA) and the next hop router and outgoing interface through which this DA is reachable from the current router. Each of the routers R3 and R4 then advertises a binding between the address prefixes reachable via it and the label that it would like its upstream router (R2) to use when forwarding packets for this address prefix (Step 2 in the figure). Router R2 uses these bindings to populate its forwarding table as follows. It initializes the address prefix and the corresponding label to use when forwarding packets for this address prefix, to the values received from its downstream neighbors. R2, in turn, advertises its bindings (Step 4 in the figure), which R1 incorporates into its forwarding table (Step 5 in the figure). Once the label forwarding tables at all routers are filled, label-based forwarding is enabled in the network.
  • Once the label forwarding tables are populated, label-based packet forwarding proceeds as follows. For each incoming packet, router R1 examines the packet’s destination address (Step 1 in the figure) and, based on its forwarding table, appends an appropriate outgoing label to the packet (Step 2 in the figure). Each intermediate router, such as R2, then forwards the packet, using label swapping. At the egress router, R3, the label is removed (“popped”), and the packet is routed using the Layer 3 (or IP) routing table at R3, as shown.
  • Thus, MPLS has both data plane and control plane components. As explained earlier, the data plane involves packet forwarding based on labels. The label may appear in a L2 header (for example, in the VPI/VCI field in ATM or the DLCI field in frame relay), or it may appear as a “shim” header between the L2 and L3 headers (for technologies such as Ethernet or PPP, where the L2 header has no field that can be adapted to carry a label). The control plane components are responsible for the creation of labels, the binding of labels to address prefixes, and the distribution of those label bindings to neighboring routers. Label distribution may be piggybacked on update messages generated by the routing protocols, or they may be distributed using protocols specially designed for label distribution. Two protocols of the latter type are the label distribution protocol (LDP) (and its companion the constraint-based routing label distribution protocol CR-LDP) and a modification of the Resource ReServation Protocol, called RSVP-TE.
  • Let us now look at what motivates the re-use of the routing and signaling protocols of MPLS networks (namely, the MPLS control plane ) in dynamic optical networks. It turns out that there are close similarities between the routing and signaling functions needed in optical networks and those available in MPLS networks, which we will look at next. Consider first the similarities between a label switch router (LSR) and an optical cross connect (OXC). In both cases, the path setup and table configuration uses the control plane, while the data is forwarded in the data plane. The actions performed in the data plane are similar as well. The label swapping function performed by the LSR is similar to the cross-connect function performed by an OXC.
  • Both LSRs and OXCs establish a mapping between an input port and incoming label/channel and an output port and outgoing label/channel, and this mapping remains invariant unless changed by an action in the control plane. That is, it cannot be altered by the data packets (in the case of an LSR), or the contents of a wavelength (in the case of an OXC).
  • As shown, there are also striking similarities between label switched paths (LSPs) and optical channels. Both are, in essence, abstractions that represent point-to-point virtual paths. Also, as shown, both form a virtual topology connecting their respective network nodes. Further, their payload (data packets for LSPs and an optical signal for optical channels) is passed transparently by the intermediate nodes.
  • Thus, we see that the control planes in MPLS networks and those in optical networks perform very nearly the same functions. Therefore, some of the same constructs as found in MPLS networks can be adapted for controlling optical elements. Furthermore, OXC implementations with specific hardware features can use a form of the MPLS control plane that has been adapted locally to match the characteristics of the particular OXC.
  • MPLS routing and signaling protocols require modifications to account for the characteristics of optical networks. The MPLS control plane must handle a variety of link types, because the capabilities of the links and switches found in optical networks can differ widely. For example, the network may consist of optical cross-connects (OXCs), which only space switch between fibers or between wavelengths, of SONET cross-connects (SXCs), which terminate SONET channels and may switch at sub-channel rates, and of IP routers, which switch individual packets and can therefore switch at any rate. The example shows how a packet stream between R1-R2 is transported in an OC-48 channel multiplexed on to an OC-192 SONET channel, which, in turn, is transported on a wavelength within a fiber. Suppose R1 received application data destined for R2. That data is inserted in appropriate time slots in OC-48 frames on the outgoing link at R1. At the SXC, the OC-48 channel is multiplexed on to a higher rate OC-192 channel. This OC-192 SONET channel itself is transported on wavelength  1 (red) to the first OXC. Wavelength  1 is space-switched between the OXCs, and emerges on the output side, where is it directed into the second SXC. The SXC can interpret the OC-192 SONET signal carried on  1, and demultiplex it into four OC-48 channels, one of which is directed to R2. R2, in turn, terminates the OC-48 channel, extracts from it packet data arriving from the particular application on R1, and processes/forwards it appropriately.
  • Additional enhancements needed in signaling are an ability to associate control channels with the data channels . This is not an issue in pure packet networks, because each link between two routers carries both control packets (such as routing update messages or signaling messages) and data packets, and since routers examine each packet, they can distinguish between the two types of information. In optical networks, however, it will often be the case that the control and data channels are on separate wavelengths or on separate SONET channels, so it will be essential to know which control channels correspond to which data channels. In addition, one needs mechanisms to activate/deactivate data or control channels, and, in case of a common control channel, to distinguish between control information for the various data channels. The routing protocols must now handle links with different granularities, ranging from coarse granularity (fiber or wavelength) to fine granularity (sub-SONET channel rates or arbitrary packet data rates). Thus, distribution of bandwidth availability information via routing becomes a challenge. In addition, routing protocols must be enhanced to carry selected information about the characteristics of the optical link, which a path computation algorithm can use for route selection. (For instance, paths with excessive dispersion or loss may not be candidates even if they have the required bandwidth to service a request for an optical channel.) Also, information about which optical channels are physically diverse (useful for setting up backup channels) must also be communicated by the routing protocols, and should be usable by signaling.
  • Of course, enhancing only the routing and signaling protocols themselves is not sufficient to create a dynamic optical network. The optical network elements themselves also need additional capabilities. Clearly, the optical elements must be capable of exchanging control information with each other, so that they can accomplish the functions of topology/resource discovery, route selection, and path setup that we talked about at the start of the tutorial. This exchange may be done in several ways. 1) It may use “out-of-band” signaling, either on a separate wavelength dedicated to transmit control information (the optical supervisory channel (OSC)), or use a separate IP network that connects the controllers at the optical elements. 2) Alternatively, the exchange may be done “in band”, for example by reading and processing control messages sent in the overhead bytes (such as the K1/K2 bytes) in a SONET frame or a digital wrapper. (The digital wrapper is a generic name for some new framing formats being proposed for optical networks. The essential idea is to carry data in variable-sized frames encapsulated with a header and trailer. Of course, the use of a digital wrapper is possible only in elements capable of OEO conversion.)
  • There are several implementation choices for the control channel mentioned earlier. One way is to use out-of-band (OOB) signaling. An OOB control channel on an OXC that has been implemented using a dedicated wavelength works as shown. 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 wavelength crossconnect, 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. As discussed earlier, 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. 1) 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 wavelengths, 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. 2) 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. 3) 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.
  • A question when deploying an MPLS-based control plane is how the control planes of the different networks interact with one another. One deployment option is to have two instances of a control plane. That is, two independent instances of the routing and signaling protocols, one of which is used within the router network (denoted by the brown arrows), while the other is used within the OTN (denoted by the green arrows), with there being no interaction between the two instances. This can be thought of as a client-server model , with the IP network being a client of the OTN. Thus, the IP network makes requests for paths through the optical network, which in turn provides point-to-point optical links for transporting IP data. An advantage of this model is that the two networks are completely isolated from a control viewpoint, and could be managed by different service providers more or less independently. Furthermore, there is no need for the two networks to run exactly the same control plane. In other words, it would technically possible for the OTN to run an entirely different set of routing and signaling protocols from those run in the router network.
  • An alternate model for deploying the control plane is the peer model, in which single instance of the routing and signaling protocols runs on both the optical domain and the IP domain (shown by the green arrows). Thus, the optical network elements have reachability information about the IP routers. The link state database maintained by the routing protocols now contains a wide variety of links such as fiber links, wavelength links, logical links (SONET channels), and ordinary packet-based label switched paths. The use of a single control plane instance also implies that a common addressing scheme will be used for the elements in the OTN and the router network, which simplifies network management.
  • As we can see, a uniform control plane for both packet (IP) networks and optical transport networks have several advantages. It provides the service provider with tools for managing optical channels and bandwidth in near real-time, and in addition simplifies network management by providing a common command and control structure for both data networks and transport networks. This in turn facilitates interworking of equipment from different manufacturers (since each piece of equipment understands common protocols and commands), and also makes it easier to provision paths or channels across different provider networks.
  • As work continues on developing this MPLS-based control plane further, there are several issues currently being discussed and developed. One is the issue of allowing bi-directional path setup . While this is not a prime concern in data networks (where the two directions of a path are often asymmetric in terms of their data flow), it is important in transport networks, which carry aggregated traffic, and therefore often have symmetric data flow along a path. One development being worked on is to enhance signaling protocols (such as the ReSource reserVation Protocol [RSVP] or the Label Distribution Protocol [LDP]) to enable the two directions of a path to be established simultaneously, in one round of signaling. The advantage of this is that the two directions of a path can be routed through the same ports and links, allowing them to have similar characteristics and making recovery and protection easier. Another is to have in the setup message an optical path descriptor that describes the characteristics of the channel being established, and allows each intermediate node to check that the nature of the links that the path traverses is compatible with the characteristics specified in the descriptor.
  • An important issue in a dynamic optical network is the ability to provision links between OXCs and the ability to isolate faults (that is, for a given path, determining the exact link at which a fault occurred). While provisioning can be done by manual configuration, it is clearly more efficient to have a protocol that will allow for the discovery of one’s neighbors and the switching capabilities of their interfaces. In addition, adjacent OXCs may often have to negotiate the meaning of the labels that each uses for the same optical channels. For instance, adjacent OXCs may use different local labels for a wavelength between them, and should therefore know what label each of them uses to index that common wavelength. A link monitoring and provisioning protocol will also be useful to enable adjacent OXCs to discover which of their ports are connected to one another, and which set of wavelengths passes through those ports.
  • Finally, we highlight a few issues related to the development of the control plane that have been recognized by the community as being important, but which are still unresolved. The first is to extend the control plane protocols to ensure high reliability. This requires the ability to diversely route paths, and the development of algorithms that can incorporate information distributed by the routing protocols to compute such diverse paths. An equally important issue is the discovery of path characteristics of optical paths, which requires development of optical performance monitoring techniques. While digital overhead bits (as in SONET or the proposed digital wrapper) could alert the provider to the presence of a fault, they do not help in determining the cause of the fault or the current performance level of the channel (in terms of dispersion, attenuation, power levels or laser biases, for example). This requires techniques for monitoring the signal at the optical level . The characteristics and performance of various paths are required for dynamic bandwidth provisioning, since a subset of the possible paths may actually be infeasible based on their performance levels. Another challenging area of work is alarm correlation, since a failed fiber or wavelength could trigger a flood of alarms from all OXCs downstream of the failure (all of whom will detect the loss of light). Thus, the capability to isolate the fault and correlate alarms that refer to the same fault, thus reducing the number of alarms propagated is extremely important.
  • To summarize, we have taken a close look at the issues involved in the design of a control plane for agile optical networks. We began by understanding some of the factors motivating the move towards dynamic optical networks, and then analyzed the components needed for dynamic operation. We then analyzed why existing network management systems do not provide the functionality needed for dynamic control. We then motivated why an MPLS-based control plane is an appropriate candidate for future optical networks, and considered the enhancements needed in the existing MPLS control plane as well as enhancements needed in optical network elements themselves. Finally, we discussed some implementation choices for the control plane, and some architectural issues in its deployment, and we examined some open issues pertaining to control-plane design that would be useful to resolve as this effort moves forward.

Multi-Protocol Lambda Switching: The Role of IP Technologies in Controlling and Managing Future Optical Networks Multi-Protocol Lambda Switching: The Role of IP Technologies in Controlling and Managing Future Optical Networks Presentation Transcript

  • Multi-Protocol λ Switching: The Role of IP Technologies in Controlling and Managing Future Optical Networks† Dr. Vishal Sharma†A version of this seminar appeared in the First On-line Symposium forElectronics Engineers (OSEE), 9 January 2001 v.sharma@ieee.org
  • Organization of the Talk Agile (or dynamic) optical networks  Motivation  Analysis of basic requirements for agility  Advantages of having dynamic optical networks Control Plane  Possible candidates for the control plane  Motivation for adopting/re-using an MPLS-based control plane  What enhancements does this reuse/integration entail?  Implementation choices for the control plane  Architectural considerations in deployment  Some open issues: path characterization, link management, survivabilityCopyright 2001 2
  • Motivation for agile optical networks Reduce expense and complexity of network provisioning  Growth in fibers and λs complicates path provisioning  Shift from manual configuration to automatic signaled setup Increase responsiveness of optical transport network (OTN)  Reduce provisioning time: weeks/months to hrs/minutes or less  Facilitate deployment of new services that require quick setup Limit electronic termination and processing  Today, higher aggregate link speeds (esp. with WDM), but limited electronic processing ⇒ switch and route at optical channel level (not on a per-packet level) Copyright 2001 3
  • Basic requirements for agile optical networks Topology/resource discovery Distributed routing  Dissemination of network state 3. Path Selection information Path selection 1. Resource 2. Routing Discovery  Traffic engineering based on resource/policy constraints. Signaling 4. Signaling  Connection establishment and path management OXCs Survivability mechanisms Copyright 2001 4
  • Advantages of dynamic optical networks Flexible connectivity via timely Initial virtual links between Router Network R2 virtual topology reconfiguration routers  Simplifies higher-layer routing  Allows wider range of services Optical light-paths R1 R4 Final virtual topology Enables interworking of: DCSs, Optical Transport R3 OXCs, DWDM gear, routers Network Eases management & controlCopyright 2001 5
  • Required components for agile opticalnetworks Addressing/naming scheme Routing protocols Path computation and selection algorithms Signaling protocols Protection and restoration schemesCopyright 2001 6
  • Drawbacks of the traditional “controlplane”: a.k.a. network management Slow convergence following failure  Except for pre-provisioned, dedicated protection channels No instantaneous service provisioning Complicates interworking of equipment from different manufacturers  Incompatible EMSs cause integration problems Complicates inter-network provisioning  Lack of EDI between operator NMSs causes significant operator interventionCopyright 2001 7
  • So what are likely options for the controlplane? Devise new routing and signaling protocols for the optical layer ⇒ Increased operation and maintenance cost ⇒ Significant interoperability concerns ⇒ Need careful coordination with higher layer restoration mechanisms Modify network management to make it “dynamic” Adapt existing protocols from data networks. For example, protocols from IP-based networksCopyright 2001 8
  • Issues in modifying a networkmanagement system Lacks hop-by-hop signaling Multiple messages between NMS and network elements No common NMS for multi-vendor equipment Setup 6Request NMS NMS 1 4 7 11 2 9EMS 3 5 8 10 12 Copyright 2001 9
  • Issues in modifying a network management system  NMS network topology and resilience is itself an issue  NMS subject to vagaries of device architectures ⇒ Agreement on stds. complex  Channel recovery & associated signaling can be complex 2. Failure Indication NMS Setup 3. Recovery pathRequest NMS configuration NMS 1. Failure Original pathEMS 4. Switchover Recovery path Copyright 2001 10
  • Issues in having a distributed controlplane Allows easier end-point  Standardization of signaling initiated channel setup and routing is not subject to debate Element in service ⇒ control ⇒ Control plane protocols are plane is in use being worked on in Control message traffic is standards bodies (IETF, OIF, limited ITU) Signal to program switching element Control Plane Signaling messages between elements 2 3 4 6 7 1 9 5 8Copyright 2001 11
  • Basic Concept of MPLS Step 1DA Next hop N/w DA Next hop N/w router Int. router Int.129.89.10.x 1 129.89.10.x 1 Routing Table179.69.x.x 1 179.69.x.x 2 128.89.10.xIn Out Address Prefix N/w In Out Address Prefix N/w label Step 3 label Label Int. label Int. X 5 1 Forwarding 2 3 128.89.10.x 1 3 128.89.10.x Table X 4 179.69.x.x 1 4 7 179.69.x.x 2 R3 Step 5 Advertises binding 1 <5, 128.89.10.x> R1 1 R2 Step 2 2 Step 4 Advertises bindings Advertises binding <3, 128.89.10.x> <7, 179.69.x.x> <4, 179.69.x.x> 179.69.x.x  Routing fills routing table. R4  Signaling fills label forwarding table. 12
  • Basic Concept of MPLS Step 5 Step 4 Pop label 5 In Out Address Prefix N/w In Out Address Prefix N/w Forward label label Int. label label Int. packet X 3 1 3 5 5 128.89.10.x 1 5 128.89.10.x 3 128.89.10.x X 4 179.69.x.x 1 4 7 179.69.x.x 2 2 Step 3 R3 Swap Label 5 3 1 R1 1 R2 Step 2 2 3 Push LabelPacket arrivesDA= Step 1 179.69.x.x At ingress, unlabeled packets are prepended with label R4 At egress, labels are removed and packets are routed 13
  • Elements of MPLS  Label Forwarding:  Use data link addressing. E.g. ATM VPI/VCI, FR DLCIData  Put “shim” header between data link and IP header Variable 4 bytes 20 bytesPlane MPLS “shim” Higher Layers L2 header L3 IP header header Label CoS S TTL 20 bits 3 bits 8 bits  Label Creation and Binding.Control Plane  Label Assignment and Distribution:  Ride piggyback on routing protocols, where possible (BGP).  Use separate label distrn. protocol:RSVP-TE, LDP/CR-LDP 14
  • Motivation for MPLS control plane:Similarities between LSRs and OXCs LSR OXC Controller Switching Matrix De-couple control plane from data plane  Path is setup using control plane  Data is forwarded using data plane Analogous data plane processing  LSR uses label swapping to transfer labeled pkt. from I/P to O/P  OXC uses switching matrix to connect channel from I/P to O/PCopyright 2001 15
  • Motivation for MPLS control plane:Similarities between LSRs and OXCs Controller 1 1 2 2 Switching Matrix <1, label > → <2, label > <1, λ > → <2, λ > Data plane relationships  LSR: <in_port, in_label> → <out_port, out_label>  OXC: <in_port, in_channel> → <out_port, out_channel>Copyright 2001 16
  • Motivation for MPLS control plane:Similarities between LSPs and channels LSPs Optical ChannelsIP Routers OXCs Induced virtual graph Induced virtual graph Point-to-point, virtual path connection abstractions Induce a virtual graph on the underlying topology Payload is transparent to intermediate nodes Constraint-based routing (CBR) used to select pathsCopyright 2001 17
  • Similarities between the MPLS and opticalnetwork control planes The two control planes have nearly identical functions:  Addressing  Resource discovery  Routing  Signaling/connection management⇒ Constructs from MPLS-TE can be adapted for OXCs  Local adaptation can be used to tailor the control plane to specific OXC implementations with different hardware capabilitiesCopyright 2001 18
  • What adaptations does this reuse entail? Enhancements to signaling and routing  Handle links with different capabilities  Termination incapable  Termination capable  Fiber switch capable  SONET capable  Wavelength switch capable  Packet switch capable OC-48 Router SONET frames λ2 RouterR1 R2 OC-48 λ1 OC-48 Wavelength λ 1 OC-192 OC-48 OC-192 SXC SXC OC-48 OXC OC-192 SONET Fiber OC-192 SONET frame frame Copyright 2001 19
  • What adaptations does this reuse entail?Enhancements to signaling and routing Bind the control and data (bearer) channels  Activate/deactivate bearer channels  Assign bearer channels to optical paths  De-multiplex control traffic for different bearer channels Handle links with disparate bandwidth granularities  Fiber, wavelength, and SONET channels  Have routing protocol distribute info. on available b/w resources Enhance routing to carry info. about physical fiber plant diversityCopyright 2001 20
  • What adaptations does this reuse entail?Enhancements to optical elements Mechanism to exchange control informationOut-of-band In-band  Via an optical supervisory  Via overhead in “digital wrapper” channel (OSC) or SONET overhead bytes  Via a separate IP network  Via sub-carrier modulation (SCM) on the optical channel Control PlaneSeparatenetwork OSC Digital wrapper or SONET overhead bytesCopyright 2001 21
  • Implementation choices for the control channel: Out-of-band signaling Use a separate λ as an OSC  Possible when the wavelength count is large MPLS O-E E-O Control signaling wavelength Wavelength switching Outgoing Incoming fiber fiber Data wavelengths Use physically separate control network Copyright 2001 22
  • Implementation choices for the control channel: In-band signaling Control MPLS Reserve part of bandwidth of a Packets signaling O-E λ for MPLS signaling Label E-O Control Processing  Useful when λ count is small wavelength  Assumes O-E-O at node Incoming Outgoing fiber fiber Use sub-carrier modulation Subcarrier Subcarrier Extraction MPLS Insertion  Gives control channel with Mb/ signaling s of bandwidth Use overhead in “digital wrapper” or SONET frame  Assumes all O-E-O devices Copyright 2001 23
  • Architectural considerations indeployment: Overlay model IP Router Network Use different instances of the control plane in the OTN and IP domains  IP domain a client of optical domain  OTN provides p2p optical channels between IP network elements  Gives maximal control isolation Optical Transport Network Overlay ModelCopyright 2001 24
  • Architectural considerations in deployment: Peer model Use single instance of control plane in optical and IP domain  Both domains run common signaling and routing protocol stacks  IP reachability info. is passed around within optical domain IP Router Network Optical Transport Network Copyright 2001 Peer Model 25
  • Advantages of a uniform controlinfrastructure Provides a framework for:  Optical bandwidth management  Real-time optical channel provisioning Allows uniform semantics for network management and operational control in both transport and data networks Enables inter-working of network elements from different vendors Simplifies inter-network provisioningCopyright 2001 26
  • Some control plane issues currently underdevelopment Setting up of symmetric, bi-directional channels (e.g. SONET or GbE)  Current signaling does not allow a bi-directional path to be setup in a single reservation round. Optical path descriptor  Describes the characteristics of the channel (a fiber,λ, or SONET channel) to be established  Useful to verify that all links along the the path can support the descriptor (compatibility check)  E.g. OC-48 channel reservation wishing to cross an OC-192 link will be successful if the link supports OC-48 multiplexingCopyright 2001 27
  • Some control plane issues currently underdevelopment Need protocols for link provisioning and fault isolation  Discovery of OXC adjacency and port interconnections  Negotiation of acceptable label ranges btwn. neighbors  Setting up of port map tables (consulted during setting up and tearing down channels)Copyright 2001 28
  • Unresolved issues in control planedevelopment Need to extend protocols for high-reliability  Require diverse routing, associated path computation algorithms  Fault detection/isolation is an issue, esp. in pure OXCs Need characteristics and performance of paths for dynamic bandwidth provisioning  Digital overhead bits do not give channel performance data ∴ Identifying causes of degradation is difficult Setting appropriate threshold values for alarms is difficult  Alarm correlation is imp. For e.g., a failed λ could trigger alarms from all downstream OXCs.Copyright 2001 29
  • Summary Explored the need for agile optical networks. Examined components needed for agility. Analyzed drawbacks of existing network management systems for providing dynamic control. Motivated choice of MPLS control plane as possible candidate for adoption in optical networks. Examined optics-specific enhancements needed in MPLS control plane, and control enhancements needed in optical network elements. Discussed implementation choices and architectural considerations Overviewed some open and unresolved issues.Copyright 2001 30