[tom_m898]

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.

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?

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.

[AjEe]

Nice topics ... Reputation added .. 25 points donated for the topic.....