Mpls Qos vs. ATM Qos

MLPS QOS vs. ATM QOS Quality of Service (QOS) is best defined as the performance attributes of an end-to-end flow of data (Zheng, 2001). The particular elements of QOS depend on the information that is being transported. For example, QOS for voice defines limits on specific parameters such as delay, delay variation, packet loss, and availability. In the past, networks were engineered based on providing fixed bandwidth for relatively short duration voice calls. Today, the traffic on networks is based on statistical or bursty data.

Therefore, it has become necessary to develop new statistical models to build new networks. Functions of QOS QOS applications are used in networks for many reasons, including to: Guarantee a fixed amount of bandwidth for various applications. Control latency and jitter, and ensure bandwidth for voice. Provide specific, guaranteed and quantifiable service level agreements (SLAs). Configure varying degrees of quality of service for multiple network customers. However, today's connectionless networks cannot provide absolute, hard QOS, only "relative" class-of-service transport (p. 211).

For services like voice and video, which need a network with high predictability, this is unacceptable. MPLS adds a connection-oriented behavior to IP, making it connection-oriented so that hard QOS can be delivered. Differences Between ATM and MPLS Simply put, multi-label switching (MPLS) brings the traffic engineering capabilities of asynchronous transfer mode (ATM) to packet-based network by tagging IP packets with "labels" that specify a route and priority (Flannaghan, 2001). MPLS unites the scalability and flexibility of routing with the performance and traffic management of layer 2 switching.

MPLS can run over nearly any transport medium, including ATM and Ethernet, rather than being tied to a specific layer-2 encapsulation. Because it uses Internet protocol (IP) for addressing, it uses common routing and signaling protocols. MPLS was not designed to replace ATM but rather to compliment it. MPLS eases complexity by mapping IP addressing and routing information directly into ATM switching tables. The MPLS label-swapping paradigm employs the same mechanism that ATM switches use to forward ATM cells.

In the case of ATM-LSR, the ATM forwarding component performs the label swapping function. Label information is carried in the ATM Header. MPLS has the ability to run over routers in addition to ATM switches, while providing the control component for IP on both the ATM switches and routers. For ATM switches PNNI, ATM ARP Server, and NHRP Server are replaced with MPLS for IP services yet the ATM control plane remains preserved (Zheng, 2001). PNNI is still used on ATM switches to provide ATM services.

Therefore, an IP+ATM switch delivers both ATM for fast switching and IP protocols for IP services in a single switch. In the past, at a specific performance level, the price of a router was usually higher than the equivalent ATM switch. With IP+ATM LSRs, the forwarding performance is determined by the capabilities of the ATM switches, whereas the functionality is comparable to a router. Moreover, IP+ATM switches may also have similar price and performance characteristics to ATM switches.

Values of MPLS QOS and ATM QOS As a means to join otherwise parallel IP and ATM networks without requiring essential changes to the characteristics of either, MPLS holds value to major carriers. Maintaining two separate networks (IP and ATM) has obvious disadvantages in terms of cost, whereas running IP over ATM fails to scale over time (Paw, 2002). These issues do not explain why carriers would want to converge all their traffic over an all-IP backbone.

Often the main draw of MPLS is how it supplements IP through quality of service (QOS) and traffic engineering (TE). MPLS is often referred to as a "QOS protocol," because, on its own, the standard does not have a complete means of quality assurance or traffic differentiation (p. 178).

However, it does provide is an opportunity for mapping DiffServ fields onto an MPLS label, d for conveying this information through the core of the network in a way that is more efficient and easy to use with other protocols than a pure IP/DiffServ implementation would be. MPLS also allows users to recognize and prioritize different types of applications, while reserving network resources to support of them and defining explicit routes to carry them out.

MPLS standards rely on other protocols to achieve this result, defining only a generic need for an LDP to communicate between the label router nodes. Still, the two main options that have been suggested for the role of LDP - CR-LDP (Constraint-based Routing) and RSVP-TE (an extended version of the Resource ReSerVation Protocol) - are similar in that they describe methods for allocating bandwidth and establishing dedicated virtual routes based on QOS rules or application-specific limitations (p. 196).

End-to-end QOS in an IP network has been of utmost importance for service providers, and it is probably the area where MPLS has had its biggest impact. The potential of highly differentiated and guarantee-able IP QOS is something that both enterprise users and service providers would like to see come from MPLS deployment. However, this goal has yet to be realized. However, MPLS has proven itself to be beneficial in traffic engineering.

Traffic Engineering The ATM world has a rich feature set that is used for traffic engineering, which is a process by which traffic is optimized to follow certain paths based on specific requirements. The Internet Protocol (IP) world also has features, although not as extensive as ATM, to provide for traffic engineering (Swallow, 1999). The problem experienced by service providers is how to combine the traffic engineering of IP with the traffic engineering of ATM. Since they are two entirely different technologies, it is difficult to implement combined end-to-end traffic engineering.

Both IP and ATM have QOS capabilities. The difference between the two has to do with their operation. IP is connectionless and ATM is connection-oriented. Again, the problem experienced by a service provider is how to combine these two different ways of implementing QOS into a firm end-to-end solution. MPLS, as a technology, evolved from early attempts to glue the IP and ATM worlds together. Today, MPLS, for the most part, is a standardized version of Cisco's proprietary tag switching.

The MPLS label, or label stack, is made up of four octets (32 bits). The label is the core of MPLS. 2 3-4 5-6 7-8 9-0 1-2 3-4 5-6 7-8 9-0 1-2 3-4 5-6 7-8 9-0 1 Label EXP |S| TTL Figure 1 -- MPLS LABEL STACK (Swallow, 1999) Traffic engineering deals with the performance of a network in supporting the network's customers and their QOS needs. The focus of traffic engineering for MPLS networks is: the measurement of traffic, and the control of traffic.

Control of traffic deals with operations that ensure that the network hs the resources to support the user's QOS requirements. Traffic engineering in an MPLS environment establishes objectives with regard to two performance functions: traffic oriented objectives, and resource-oriented objectives. Traffic oriented performance supports the QOS operations of user traffic. In a single-class, best-effort Internet service model, the key traffic-oriented performance objectives include minimizing traffic loss and delay; maximizing thoroughput; and enforcing service level agreements.

Resource-oriented performance objectives deal with the network resources, such as communication links, router and services -- those entities that contribute to the realization of traffic-oriented objectives. Efficient management of these resources is vital to the attainment of resource-oriented performance objectives. Available bandwidth is the bottom line; without bandwidth, any number of traffic engineering operations is worthless, and the efficient management of the available bandwidth is the essence of traffic engineering. Traffic engineering is a major aspect of QOS (Zheng, 2001).

The ability of MPLS to do traffic engineering lays the groundwork for its QOS potential, even though carriers see immediate benefits from traffic engineering in the internal operation of their network, not in their customer-facing service offerings. Still, carriers hope that the infrastructure they are investing in today will enable revenue-generating services tomorrow. And MPLS offers a rather straightforward way of solving traffic management problems such as network bottlenecks, caused by congestion on certain router paths.

Here, the flexibility of MPLS in choosing the "best" path for a certain traffic flow can be leveraged to more evenly distribute traffic throughout the network. Congestion Problem Any network that admits traffic and users on demand (such as the Internet) must deal with the problem of congestion (Paw, 2002). The management of all user traffic to prevent congestion is an important aspect of the QOS picture. Simply stated, congestion translates into reduced thoroughput and increased delays. Congestion is a huge problem for effective QOS.

Many networks provide transmission rules for their users, including agreements on how much traffic can be sent to the network before the traffic flow is regulated (flow controlled). Flow control is an essential ingredient in preventing congestion. MPLS defines two major network elements, a Label Edge Router (LER) and a Label Switch Router (LSR). These entities are functional descriptions, not system-level definitions.

Therefore, the types of systems that can fulfill the LER or LSR functions are not limited, and, while they are separate, a single box could also act as either or both, depending on the application. One-way network elements deal with an overflow of traffic is to use a queuing algorithm to manage the traffic, determining how to prioritize it onto an output link. The QOS service policy maintains the queue depth, marks traffic, and identifies non-critical traffic on a per-VC basis.

The QOS service policy aims to achieve the following: Employ Network-Based Application Recognition to classify non-business-critical traffic. Apply Weighted Random Early Detection to manage queue depth. Apply class-based marking using the set command to mark IP precedence values based on traffic type. PRECEDENCE VALUE TYPE OF TRAFFIC Non-business critical Default, used for normal traffic Future real-time traffic, such as voice over IP (VoIP). Reserved for network control traffic. FIGURE 2 -- PRECEDENCE LEVELS (Paw, 2002) Basically, the potential congestion points are the ATM VCs that enable the DSL-connected users.

IP flows arrive at the Ethernet interface at high speeds and flow out of the ATM VCs. These are configured for the unspecified bit rate (UBR) ATM service category with a default peak cell rate (PCR) of the T1 interface. Therefore, the QOS service-policy tracks traffic arriving on the Ethernet interface (p. 257). The remarked values then are used by WRED to create service classes based on IP precedence and to provide differentiated service through individual drop levels per class.

Figure 3-- Priority queuing places data into four levels of queues: high, medium, normal, and low. (Pulse, 2002) Levels of Hierarchy There is a need to manage critical resources in the nodes of both an ATM or MPLS network (Zheng, 2001). One way of simplifying the management of the trunk capacity is through the use of aggression. ATM's fixed-format cell header allows only two levels of hierarchy: the virtual path (VP) and the virtual channel (VC). MPLS, on the other hand, allows for an essentially unlimited level of hierarchy using label stacking.

Nodes in MPLS and ATM networks employ label switching. This means that the packer header labels need only to be unique on an individual link. Label switching involves mapping an incoming label to an outgoing label on a per-connection basis. An end-to-end connection is then a concatenation of such label-switching actions. Label stacking occurs when a switch maps a number of connections into another aggregate connection at a higher hierarchical level. Therefore, the next higher level flow contains the aggregate of many lower-level flows.

Such flow aggregation eases the task of network routing traffic engineering by reducing the number of required connections. Determining QOS An ATM VP contains many VCs. VP cell relaying operates only on the VPI portion of the cell header (Zheng). Assuming that every node in a network is interconnected to every other node by a VPC, then only the total available entry-to-exit VPC bandwidth need be considered in admission control decisions. A VPC is easier to manage as a large aggregate than multiple, individual VCCs.

The complexity and number of changes required when implementing routing, restoration and measurement are also required by VPCs as compared to VCCs. It is important to note that QOS is determined by the VCC with the most stringent QOS in a VPC. One might envision a network of nodes interconnected by a VPC for each QOS class. However, this could quickly exhaust the VPI address space if there are more than a few QOS classes. Unfortunately, a full-mesh design does not scale well (Paw, 2002).

Even in partial mesh networks, allocating VPC capacity efficiently is a challenge. The principal issue is the static nature of VPC allocation in current ATM standards. There are some analogies for traffic engineering between ATM VPCs and using label-stacked MPLS LSPs. The notion in using MPLS for IP traffic engineering is that of a traffic trunk, which is a set of IP packets between a pair of nodes. For example, the packets offered to a traffic trunk may be completely defined by a set of destination IP addresses.

AN MPLS LPS could be set up as a traffic trunk from every ingress router to the egress router that handles this set of destination IP addresses. The notion of traffic trunks can also be done at one or more levels in the hierarchy. For example, in order to reduce the full mesh of LSPs to improve scalability, a set of traffic trunks formed by aggregate LSPs between core LSRs could be established, over which other LSPs could be label stacked.

ATM QOS The guarantees of the connection-oriented ATM QOS enable the coexistence of delay sensitive applications, including real-time video and voice with bursty file transfers and transactional data traffic (Flannaghan, 2001). In an ATM network, QOS play a key part in providing consistent results for all network users. ATM performs QOS by using three general approaches when servicing any connection: When a required level of connection service quality is required, ATM guarantees and enforces that all devices providing the connections meet the required level of service consistently.

When a preferred QOS is requested for a connection, ATM tries to acquire resources available throughout the network to accommodate the requested level of service, while preserving and maintaining service guarantees for connections that require them. When quality of service is unspecified for a connection, ATM tries to use available network resources in a "best-effort" attempt to provide a form of service similar to what is available in other transfer modes. Combining and using defined ATM QOS parameters in a variety of ways have established ATM service categories.

All ATM connections fit into one of these four service categories, which are indicated indirectly as a result of VPI/VCI information in each individual ATM cell header. Switches use the VPI/VCI to figure out priority for individual cells within the connection stream whenever connections using differing service categories are multiplexed. To control the various types of network traffic, ATM standards have been modified to define the types of services most commonly used (Hesselbach, 1998).

The four general ATM service categories are: Constant bit rate (CBR) -- Connections that require a guaranteed continuous rate of transfer, such as real-time voice or video, and connections that will tolerate only minimal transfer delays, such as circuit emulation for leased lines and T1 or T3 carrier services.

Variable bit rate (VBR)-- Connections that require a lower bounded rate (such as their minimum rate of transfer), but can tolerate variation at their upper bounded rate (such as their maximum rate of transfer) to permit periods of burst transfer to occur. Available bit rate (ABR)-- Connections not requiring a guaranteed rate of transfer, such as file transfer and e-mail. Connections that are generally more tolerant of highly unpredictable or burst traffic patterns, such as ATM interconnection with emulated Ethernet and Token Ring LANs.

Unspecified bit rate (UBR)-- Connections requiring route establishment but no guaranteed commitment of bandwidth, such as batch file transfers and lower priority bulk e-mail. Connections for programs that have no delivery constraints and perform their own error checking and flow control. MPLS QOS Both MPLS QOS and bandwidth management and DiffServ priority queuing management are important elements when making sure that multiservice network performance objectives are met under a range of network conditions (Paw, 2002).

Both mechanisms work together to make sure QOS resource allocation mechanisms (bandwidth allocation, protection, and priority queuing) are achieved. Basically, MPLS supports the same QOS protocols as IP does, which include IP Precedence, Committed Access Rate (CAR), Random Early Detection (RED), Weighted RED, Weighted Fair Queuing (WFQ), Class-based WFQ, and Priority Queuing. Proprietary and non-standard QOS mechanisms can also be supported with MPLS (p. 144). However, these are not guaranteed to interoperate with other non-proprietary vendors.

Since MPLS also supports the reservation of Layer 2 resources, MPLS is able deliver finely grained quality of service, similar to the manner of ATM. It is assumed that both MPLS and Differentiated Services (DiffServ) will both be deployed in networks. DiffServ can support up to 64 classes while the MPLS shim label supports up to 8 classes. This shim header has a 3-bit field defined "for experimental use." This can pose a problem. This Exp field is only 3 bits long, while the DiffServ field is 6 bits.

To deal with this problem, there are different ways to work around it. The two main alternatives that address this problem are called Label-LSP and Exp-LSP models, yet both make the architecture complex (p. 177). The DiffServ model fundamentally defines the interpretation of the TOS bits. Assuming that the IP precedence bits map to the Exp bits the same interpretation as the DiffServ model, they can be applied to these bits.

If additional bits are used in the DiffServ model, the label value must be used to interpret the meaning of the remaining bits. Because three bits are enough to identify the required number of classes, the remaining bits in the DiffServ model are used for identifying the drop priority, which can be mapped into an L-LSP in which case the label identifies the drop priority while the Exp bits identify the class of the packet. Some service providers have or add just a few classes.

This small enhancement is often hard to provision, manage and sell. Yet.