MPOA vs. MPLS in ATM

MPLS is designed to cover the high-performance Internet core. MPOA provides flexible deployment of routing and bridging technology for the campus or intercampus environment. They take very different views about what ATM is and how it should be used.

By Joel M. Halpern

There have been several efforts to provide techniques for running internetworking effectively over ATM. Recently, the ATM Forum completed work on their multiprotocol over ATM (MPOA) specification. Also recently, the IETF began working on what is called the multiprotocol label switching (MPLS) effort. Both of these specifications deal with how things can or should run over ATM. They take very different views about what ATM is and how it should be used. This article will review the technological approaches, and then discuss the treatment of ATM. After the overall discussion, some recent developments that further complicated the users understanding will also be presented.

Over time, many techniques for using ATM as an internetworking data backbone have been advanced. These include classical IP for building IP subnets, ATM Forum LAN emulation network (LANE) for building bridged virtual LAN segments, and NHRP for doing end-to-end VCs for IP over ATM. Various designers have advanced their own proprietary techniques as well.

One confusing aspect of this situation is that "ATM" means different things for different classes of solution. Therefore, a brief overview of MPOA and MPLS will be given. Each provides the capability for running over ATM. After describing the two approaches, what each means in terms of ATM will be compared and contrasted.

Figure 1



Multiprotocol over ATM

The MPOA specification has recently (July, 1997) been approved by the ATM Forum, and covers a number of techniques and their interaction. In overview, MPOA provides a virtual router, supporting virtual subnets, over ATM. There are two general kinds of components in MPOA. The MPOA server (MPS) provides routing support. The MPOA client is either an intelligent ATM-attached host, or a device for connecting ATM to legacy media. Such a device is, in general, an enhanced bridge that understands IP packets and can perform IP forwarding.

MPOA is built upon a base of LANE version 2. This provides a service that runs on ATM and emulates an Ethernet or Token Ring segment. Thus, it supports traditional bridging techniques. MPOA uses this bridging operation as the default forwarding method. As such, devices in the same IP subnet can be attached to different physical ports on MPOA edge devices. The bridging system will make this appear to be a single bridged space. Because the emulate LAN service is a logical service, the bridging spaces can overlap. As shown in Figure 1, one might have one subnet (the red line) on two ports in the system, and another subnet (the green line) on two other ports in the system. In fact, it is actually possible to support two subnets on the same physical interface if the ATM edge device can classify the incoming and outgoing traffic appropriately.

On each of the subnets there will appear one or more MPOA servers. These servers use the LANE services, just as the clients do. The result is that default traffic from legacy hosts is simply bridged, within the appropriate subnet, to the serving MPS. From the legacy device perspective, it is communicating with a router just as it always did.

One of the other points of MPOA is that the separation of the MPS and MPC represents a decomposition of a traditional router. The MPS is functionally very similar to the control processor (and cache exception handler) of a traditional router. The MPC serves as the fast path-forwarding card. In MPOA, when an MPC detects a flow of packets to a given internetworking destination through a single MPS, it asks that MPS for the IP forwarding information for that flow of packets. The MPS then uses NHRP to determine where that flow leaves the ATM network. This information is given back to the MPOA client, which then establishes an ATM virtual circuit (VC) to the appropriate ATM exit.

Obviously, there are additional mechanisms so that the ATM exit knows what to do with the packets sent on these shortcuts. Also, there are mechanisms to make sure that the shortcuts stay properly synchronized to the IP routing.

The result is a system that can perform default forwarding using bridging, and can establish shortcut paths through the ATM fabric for forwarding internetworking datagrams. These shortcuts cross subnet boundaries, and use standard ATM signaling and operation.

MPLS

As the ATM Forum was working on MPOA, there were other activities taking place in the router marketplace. Ipsilon had developed their IP switch. Cascade had started promoting their IP navigator. And folks were looking for better ways to solve a number of technical difficulties. Some of these included building inexpensive high-performance routers, and appropriately managing the bandwidth among a collection of routers.

There are obviously many ways to go about achieving some of these goals. In fact, it can be argued that MPOA is also an attempt to address these goals. In the MPLS sense, though, the intention is to address the goals with IP routing technology. However, it is also desireable to reuse all that clever switching hardware that people have been developing for ATM, Frame Relay, and other switching applications.

Ipsilon arguably started this trend when they developed IFMP. They took an ATM switch, bolted on an IP router, and gave the router control over the switching fabric. Then, they used a proprietary signaling protocol to communicate about VCs and their relationship to IP traffic.

Cascade used another related approach. Building on a base mesh of ATM virtual paths (VPs), Cascade used OSPF to distribute communication and path information so that the devices could use the VPs effectively.

Cisco then observed that it could be helpful even in LAN environments to have the same kinds of short labels that ATM and Frame Relay have. So they developed a tag distribution protocol and a methodology for sending tagged packets over LANs.

Other companies such as IBM, 3Com, and Cabletron have also developed approaches to this kind of problem. All of these approaches are based on distributing the workload for classifying packets. All routers classify packets into forwarding equivalence classes, and then forward the packets based on that classification. The idea with these techniques is to reduce the number of times that classification needs to be done. If you can label the packet with an understandable label describing the classification result, other devices could then use the label to reduce their work. There are two concepts that should be kept in mind in understanding this. The first term is the forwarding equivalence class. A collection of packets can be said to be in the same forwarding equivalence class for a given router if they are all handled the same way. This is the important notion in distributing router work. If one router can indicate to another the class of handling of a set of packets, then less work has to be done at the second step.

The second term is label path. MPLS uses labels to indicate the forwarding equivalence class of a packet. As will be seen, successive switches will perform forwarding based on the label. While the switches will rewrite the value of the label, a packet with a given starting label will always take a certain path through the system (until routing changes). The path through the MPLS devices that packets with a certain label will take is referred to as the label path. This can be established in many ways, but once established, the packets simply follow the pathway, much like cells following a virtual circuit, or packets in a Frame Relay network.

As this developed, a number of the companies involved realized that multiple proprietary techniques were not going to be a service to the customer. Thereupon, they came to the Internet Engineering Task Force (IETF) and requested a working group. That working group, and design teams working with its members, have been attempting to devise a common approach to this operation so that multivendor implementation and interoperability can occur.

These specifications deal with all the aspects of a label-based routing system. The approach that is emerging is based on a model in which all cooperating devices are running the IP routing code. The devices then use a label-distribution protocol to exchange labels with neighbors. Because all of the devices are routers, the label path that results from this can be constrained to follow the routing path.

When a packet enters such a system, the ingress router will label it with an appropriate label, as ex-changed with the next hop router. Assuming that the label path extends through multiple routers, each one will examine the incoming label and use that information to replace the label with a new outgoing label, much the way an ATM or Frame Relay switch replaces the virtual circuit identifiers.

Given the stage of development of the work, there are many open issues, and much may still be subject to change. The basic model being used, however, is one where the tag assignment and distribution is done based on topology information, not traffic flows. Each router gives its upstream neighbor a set of labels, and each label applies to a set of internetworking destinations. In general, the set of destinations covered by a single label will be the set of destinations that leave the MPLS system through a single egress. One of the open issues is how to determine what is the right granularity for labels, and how to cope when new information changes the granularity. One interesting property of MPLS label paths is that they are designed to merge (Figure 2). That is, if there are several ingress routers sending packets to the same egress, the paths come together. From the point where the paths merge, using a single label is desireable. This clearly improves the scaling properties of the system by reducing the number of labels that are needed. Of course, most ATM switches do not know how to do this.

The specifications cover the handling of labels on multiple media, including Ethernet and ATM. The specifications also cover the protocol for distributing labels and the system operation. Other aspects remain to be resolved. While the system can manage the paths and the allocation of bandwidth to them, techniques for actually doing so have not yet been proposed. Both of these approaches say they can run over ATM. But do they?

Figure 2



MPOA and ATM

The MPOA specifications have been developed by the ATM Forum. The Forum's view of ATM is that it consists of many elements. It includes the formats for sending cells on individual wires, and a lot more: such elements as the ATM Forum signaling specifications for establishing VCs; the traffic management specifications for how traffic can be handled on different kinds of circuits; the ATM Forum network management and monitoring techniques, including "OAM" cells that can monitor virtual circuits, virtual paths, or wire segments; and all of the elements that are required to build an operational system.

The MPOA specifications are designed to work with all of these things. MPOA devices are fully compliant ATM users; MPOA shortcuts cross subnet boundaries and can make use of large scale ATM networks. The ATM switches used by MPOA are not in any sense special, as switches that can work with standard ATM signaling can be used by MPOA.

MPLS and ATM

When the MPLS specifications available to date refer to ATM, they do not mean ATM Forum signaling, OAM, network management, PNNI, or any of those elements. All that MPLS means by ATM is "cells on a wire." As defined, every MPLS switch must be running IP routing. Every MPLS device must understand the MPLS label distribution.

Fortunately, there are ways that this can work with the ATM standards. In particular, it is quite possible, based on partitioning VC space, for two neighboring devices to be both MPLS switches and ATM Forum-cognizant ATM switches. This lets you use two software stacks to manage one infrastructure for two different purposes.

There are some interesting questions that arise, however. Do you really want to use two software stacks to manage one set of hardware? More interestingly, suppose that you are just interested in MPLS. Do you want the rest of the ATM Forum capabilities? Many people will argue that MPLS label handling is simpler and less burdensome than the ATM Forum specifications. But the ATM Forum mechanisms were not developed to make life complicated, they were developed to fill a user need. In fact, some have argued that most of those tools will be needed for managing MPLS systems. Time will tell.

Recently, some of the people working on MPLS have taken steps to allow somewhat better integration with standard ATM. This work was presented at the August 1997 IETF meeting, and represents an interesting extension of the capabilities.

Suppose that you had a set of MPLS supporting routers communicating over ATM. Suppose that they were actually using standard ATM switches, standard signaling, and many tools. It would still be desirable to be able to establish MPLS label paths between these routers over the ATM switches that connect them.

The proposal consists of two parts. One step is to decouple the label distribution from the actual label used on the packets. The label distribution over standard ATM would distribute not the actual packet label, but a virtual circuit identification (VCID) used for control purposes. Then, when using standard signaling to establish a VC, the MPLS devices would use an additional information element in the signaling to indicate what signaling should be associated with the VC being established by this VCID message. This allows the receiving MPLS router to know what forwarding equivalence class to use with all of the packets coming over that VC. Thus, it can perform hardware concatenation between an incoming VC and the appropriate outgoing VC.

The result is operation of MPLS over real ATM. The ATM virtual circuits are restricted to those peerings where one pre-establishes routing relationships. But it does operate. Thus, MPLS is moved closer to the realm where MPOA is aimed. However, the two still have significant differences in applicability and purpose. MPLS is designed to cover the high performance Internet core. MPOA provides flexible deployment of routing and bridging technology for the campus or intercampus environment.

Joel M. Halpern is the director of internetworking architecture for Newbridge Networks Inc. He provides assistance and consultation to many ongoing IP-related developments within Newbridge, along with assistance with ATM technology, particularly as it relates to routing and addressing. Halpern is also the routing area director in the IETF, where he assists the operation of all routing-related working groups, including such topics as support for IP mobility and the MPLS working group.

A Look at Next-generation SARs. By Warren Andrews The good news for ATM equipment designers is how quickly ATM is gaining support in the WAN infrastructure. Perhaps not so comforting, though, is the growing realization that today's WAN environment is a patchwork of converging technologies and topologies in which ATM must play any one of dozens of roles at various edges and linkage points within a rapidly evolving WAN landscape. Indeed, part of ATM's allure is its inherent ability to provide the underpinnings for anything from Frame Relay to leased line to transparent LAN networks. It has been heralded as the strongest hope for integrating all of the many voice, video, and data services that could be delivered via the Internet. ATM also is being used to upgrade and save the core of the original Internet infrastructure, and has the potential to provide a uniform transport protocol for all of the various new residential access lines, whether they be DSL, HFC, FTTC, etc. Until now, designers have been forced to choose between hard-wired silicon that dictates a rather narrow product-definition path, or alternative RISC-based solutions that impose prohibitively cumbersome code-development work. On the horizon, however, is a whole new approach to equipment design that leverages a new generation of multiprocessor-based ATM segmentation and reassembly (SAR) chips that support high channel counts, per-connection traffic scheduling, and all popular service classes. This silicon consolidates them onto a single chip, and adds key architectural innovations that simultaneously minimize host traffic congestion while optimizing ATM network performance. With these new silicon developments, designers are now tackling a diverse array of sophisticated new ATM end stations ranging from ATM routers, hubs, and switch control modules to WAN service access muxes and platforms. As a result of the flexibility of the new SAR silicon, these multiservice boxes can be configured so that new classes of service can actually be inexpensively provisioned on demand in the field. Consider the example of multiservice access concentrators that provide transparent LAN services to single-customer locations with FDDI or Token Ring LANs. They allow service providers to offer integrated suites of ATM-based services directly from the edge of the provider's ATM backbone network to a customer's LAN. These offerings can be provided to customers over a single connection at native LAN speed, and can include transparent LAN service, Internet access, intranet/extranet services, and circuit emulation services for various voice and video applications. The key to the success of these boxes is the ability to configure each subscriber port's service parameters with respect to the transport network. Next-generation ATM SAR devices must be able to implement the critical traffic management capability for these boxes. Another example is the DSL-access multiplexer (DSLAM), advocated by the regional Bells' Joint Procurement Consortium. DSLAMs allow various subscriber services to be selectable per line, and may have anywhere from a few to hundreds of customer-side ADSL and HDSL interface lines, each at various speeds, using ATM to route cells to the carrier for connection to the service providers. Various terminal types can be mixed, and cards can be inserted and extracted from a live backplane. Assuming that ATM becomes a preferred interface for today's DSLAM, there will be an important transition period during which central offices will combine DSLs in T1 or T3 channels in the simplest way possible. This is where today's next-generation ATM SAR silicon comes in. ATM SARs convert the legacy data services, such as Frame Relay or X.25 to ATM, inside the line card of the DSLAM. Again, of critical importance in these applications is the ability to provide per-connection traffic scheduling. Because the latest ATM TM 4.0 traffic-management specifications call for bandwidth to be dynamically allocated between active connections, today's SAR controller must perform all traffic-management, performance-monitoring, and general AAL processing duties at 155 Mbps on high numbers of active channels, all within a single cell time of roughly 2700 ns. This requires that ATM SAR silicon have on-chip logic that is capable of calculating and maintaining individual rate parameters for each connection. In this way, the SAR chip can manage individual connections, perform dynamic rate allocation, and implement new performance-monitoring specifications, thereby providing system-level service guarantees even in networks with thousands of simultaneously open connections. There are a few things to look for when specifying ATM SAR silicon for your next generation network box: Does it supports all industry-standard traffic-management services, including constant bit rate (CBR), unassigned bit rate (UBR), and variable bit rate (VBR) services? Does it offer a powerful and flexible host interface to optimize data transfer and reduce PCI bus loading? Does it allow the designer to build congestion control directly into the system, so that host buffers can be used to isolate congestion from one connection to the next for optimum overall network service and performance? Does the SAR silicon have built-in, service-specific support for accelerating and enhancing SAR performance during such important protocol interworking tasks as UNI/NNI addressing, virtual path networking, optional local processing of ATM management traffic, and ABR traffic management? Does it support a complete development system with working reference design, a sample software driver and ATM traffic generation/termination tools, plus programmable traffic-management templates so that you can tune scheduling performance without imposing the code-development burdens of software-based solutions? These and other issues will all become increasingly important in this new era of performance oriented, yet highly flexible ATM edge equipment design. Andrews is the product line manager of ATM strategy at Rockwell Semiconductor Systems, network access division.