Addition of QoS Services to an MPLS-enabled Network An OPNET Methodology OPNET Technologies, Inc. 7255 Woodmont Avenue Bethesda, MD 20814 240.497.3000 http://www.opnet.com Last Modified Jun 26, 2002 Disclaimer: This paper contains statements based on the author s experience using and testing the products. Unless specified, statements related to products are those of the author and not facts or information directly from a third party. Therefore, the statements and results in this paper are subject to risks and uncertainties. The following are examples of risks and uncertainties that may cause results to differ: integration of other products, application to different networks (e.g., network size), changes in the products, and/or accuracy of imported data or data files. Despite best efforts to verify the information, text and graphics in this paper may contain technical and typographical errors.
Contents 1 Problem Definition...4 2 Methodology Steps...6 2.1 Group Flows Based on CoS... 7 2.2 Tag flows with the Traffic Class... 7 2.3 Define PHB for each Class... 9 2.4 Assign Queuing Parameters...9 2.5 Run Simulations, Analyze Results... 10 Page 2 of 10
Introduction This is one in a series of papers that describes how to use simulation technologies to solve network and application problems. This document provides a methodology for analyzing QoS infrastructures in MPLS-enabled networks. To maintain focus on the proposed methodology, this paper does not contain feature-by-feature documentation. You can find detailed descriptions of various features used in this methodology in the online documentation that comes with the OPNET products. Abstract This solution is designed to take the user through a step-by-step process for analysis of MPLS infrastructures and deployment of new customer services such as QoS classes of service using the OPNET family of products assuming that you have a network with MPLS already deployed. MPLS provides extensive support for both integrated services/rsvp and diff-serv QoS classes. Service providers may use MPLS to define various classes of service (gold, premium, best-effort, etc.) and to define per-hop behavior (PHB) for each class to support the service. The OPNET MPLS model can be used to study the impact of creating a new class of service on existing applications and on applications that use the new class of service. Application end-to-end statistics can be monitored for various classes to ensure that they meet the expected service level agreements. This document assumes that you have a basic understanding of the MPLS technology. MPLS-related acronyms are used throughout this document. Please refer to any standard MPLS text for their definitions and descriptions. Page 3 of 10
1 Problem Definition MPLS provides a number of features that allow new revenue-generating customer services to be added to existing networks. Popular customer services include adding a QoS class of service. A service provider network, based on its size can carry multiple classes of services. Any change in the network configuration that results from adding or removing a customer impacts the network and the existing customers. Hence, it is important to study such a network environment in its current state and every time there is a change in the configuration. The questions that arise when dealing with QoS in MPLSenabled network are: Can the network accommodate a new class of service? What will be the impact of the new class of service on existing classes? Does the new class provide the necessary QoS guarantees? MPLS QoS Architecture The QoS architecture in OPNET allows you to differentiate traffic based on the Type of Service (ToS) bit specification. The ToS is carried within the IP header. Normal IP routers that do not have MPLS enabled use the ToS bits to differentiate traffic and queue traffic based on the queuing schemes configured on the router (WFQ, PQ etc.). In an MPLS-enabled router (or an LSR), traffic is routed onto an LSP based on the specified FEC table. At the ingress point, traffic can be associated with a traffic trunk that specifies characteristics such as the traffic class, bandwidth requirements and the drop policies. The traffic class value (also referred to as the Diff Serv Code Point or DSCP) specified in the traffic trunk is assigned to the EXP bits or experimental field bits in the MPLS header. MPLS enabled routers use the EXP bits to decide how to enqueue the packet. Normal IP routers on the other hand use the ToS bit in the IP header. This architecture is illustrated in the figure below. Page 4 of 10
Figure 1. MPLS/QoS Architecture Assigned By Application Application Traffic ToS Bits IP Datagram. Assigned By Traffic Trunk Parameters Ingress LSR MPLS Enabled Router (LSR) Normal IP Router EXP Bits ToS Bits IP Datagram. Queuing Based on PHB which is based on EXP->PHB Mapping Queuing Based on ToS Bits Each router provides a mapping between the EXP bits and a PHB class. Packets are differentiated based on the PHB value specified as part of the queue configuration. OPNET provides the EXP->PHB mapping in the global MPLS configuration. Once you create a mapping in the global configuration object, you can apply this mapping on any router by referencing the mapping name. Note that you can have a different mapping on each router. Page 5 of 10
Figure 2. Mapping EXP Bits to PHB Classes (MPLS Global Configuration Object) 2 Methodology Steps The steps for adding a new class of service are described below: Page 6 of 10
Figure 3. Define a New Class of Service Start Group Flows Based on CoS Tag Flows with the Traffic Class Define PHB for each Class Assign Queuing Parameters Run Simulations, Analyze Results 2.1 Group Flows Based on CoS Traffic defined in OPNET should be grouped according to the class of service it belongs to. Traffic may be modeled using different techniques (explicit traffic, background traffic). Refer to the Representing Network Traffic methodology document for details on traffic modeling techniques. OPNET provides a traffic class specification for all traffic types. Define classes of services such as premium, gold and best effort that you would like to classify your traffic into. Decide which class of service the modeled traffic belongs to. 2.2 Tag flows with the Traffic Class There are two techniques you can use to tag packets with the respective classes. The first technique is to set the ToS bits in the IP header for each traffic flow (For background traffic flows, edit the traffic flows in the flows browser and set the ToS field, for explicit traffic flows, edit the application generating traffic and set the ToS field). The EXP-PHB mapping allows you to map the IP ToS bits to the MPLS EXP bits. The mapping is performed at the ingress LER. The second technique is to specify traffic trunks with the specified class of service and associate traffic to the trunk at the ingress router using FEC binding. Page 7 of 10
The traffic trunk is a collection of flows that share the same class of service and the same path or LSP. Traffic trunk profiles are defined in the global MPLS configuration object. The profile consists of a trunk name, traffic class (DSCP value) and other traffic requirements (bandwidth, drop policies etc.). The figure below demonstrates three different trunks configured for premium, gold and best effort services. Figure 4. Traffic Trunks on the MPLS Global Configuration Object Traffic Class AF21 assigned to Best Effort. [Not shown in this figure, AF11 is assigned to the Gold Trunk and EF is assigned to the Premium Trunk] The trunk is associated with the traffic on the ingress router using the trunk name. In order to associate traffic with a traffic trunk, edit attributes on the ingress router, edit the MPLS parameters and subsequently edit the Traffic Mapping Configuration attribute. The table allows you to associate multiple traffic-fec-trunk bindings with the same LSP. Page 8 of 10
Figure 5. Traffic-Trunk Association The router sets the EXP or experimental bits in the MPLS header based on the class specified in the traffic trunk and the EXP->PHB Mapping defined on this router. Figure 6. EXP-PHB Mapping Specified on the Router "MPLS Parameters" 2.3 Define PHB for each Class To ensure that a class of service can achieve its SLAs, the service provider needs to define per-hop behavior (PHB) for that class. The IP diffserv model, which includes queuing schemes such as WFQ, PQ, and RED etc., allows the user to specify per-hop behaviors. For example, premium traffic may be granted highest priority; best effort may be granted low priority using WFQ. In this step, you should decide which scheme would satisfy your traffic requirements best and how would the queuing scheme work for each traffic class. 2.4 Assign Queuing Parameters IP QoS parameters should be defined for each PHB. If you choose WFQ as the technique for granting priorities, you should configure WFQ to classify packets based on the diffserv code point for the respective classes. Each queue is then assigned a specific weight Page 9 of 10
and the higher the relative weight, the larger the amount of bandwidth assigned to the queue. Figure 7. WFQ Configuration Based on PHBs 2.5 Run Simulations, Analyze Results To study the impact of QoS, you can measure the ETE delays or response times of any applications that you have configured within that class. You can modify QoS parameters and traffic-qos mappings to optimize your configuration so that you get the best performance for all traffic classes. CONFIDENTIAL INFORMATION DO NOT DISCLOSE, FORWARD, DISTRIBUTE, SHARE, OR MAKE COPIES OF THIS DOCUMENT IN WHOLE OR IN PART. This document contains confidential information and may contain information that is proprietary, privileged, and/or exempt from disclosure under applicable law. This document is intended for the exclusive use of the person to whom it is disclosed. If you are an unauthorized person, you are hereby notified that any viewing, copying, disclosure or distribution of this information may be subject to legal action. All unauthorized persons must immediately destroy the original documentation without making any copies or further unauthorized disclosure. Page 10 of 10