QoS Performance Analysis in Deployment of DiffServ-aware MPLS Traffic Engineering

Transcription

1 Eighth ACIS International Conference on Software Engineering, Artificial Intelligence, Networking, and Parallel/Distributed Computing QoS Performance Analysis in Deployment of DiffServ-aware MPLS Traffic Engineering Dongli Zhang and Dan Ionescu School of Information Technology and Engineering University of Ottawa Ottawa, Canada Abstract It is a trend that the integrated voice, video and data will be transported in the converged IP/MPLS core network. The combined use of the differentiated services (DiffServ) and multiprotocol label switching (MPLS) technologies is envisioned to provide guaranteed quality of service (QoS). However, such a scheme only dictates per hop behavior (PHB) and it does not control the end to end path the traffic is taking. If some link of the path is congested, packets will be dropped and QoS can not be guaranteed. Another attractive application of MPLS is for Traffic Engineering (TE), which sets up end to end routing path before forwarding data. Unfortunately, MPLS TE only reserves resource in one aggregated class, so that it can not provide QoS for differentiated services. MPLS DiffServ-aware TE makes MPLS TE aware of QoS, by combining the functionalities of both DiffServ and TE. In this paper, the QoS performance is analyzed for different type of services including VoIP, Real time Video, and best effort data traffic. The results show that the guaranteed bandwidth service can give better QoS for real time traffic such as VoIP, but worse QoS for the variable video traffic. I. INTRODUCTION In a multi-service IP network, many types of services are transported over a same network and therefore the network must provide different QoS assurance for different types of services. Service level agreements (SLAs) define the service quality experienced by traffic transiting the network and are expressed in terms of latency, jitter, bandwidth guarantees, packet loss, resilience in the face of failure, and downtime. During the past several years, numerous mechanisms have surfaced for providing QoS for communication networks. The fundamental objective of any QoS mechanism is to ensure that excessive congestion does not occur for the packets with assured QoS. It is important to keep in mind that QoS mechanisms do not create additional capacity, but only support prioritization of traffic and allocation of capacity under congested conditions, or reduce the source rates to decrease congestion. In today s competitive market, service providers have rolled out revenue-generating services in their networks using Diff- Serv alone [1]. By assigning applications to different classes of service and marking the traffic appropriately at the edge routers, different services are classified into several classes. By defining the per hop behavior in the core router, different scheduling, queuing and drop behavior are taken for the different classes. However, to receive strict scheduling guarantees, it is not enough to mark traffic appropriately. If the traffic follows a path with inadequate resources to meet performance characteristics such as jitter or latency requirements, the SLAs cannot be met. MPLS traffic engineering (MPLS-TE) [2] sets up labelswitched-paths (LSPs) along links with available resources, thus ensuring that bandwidth is always available for a particular flow and avoiding congestion both in the steady state and in failure scenarios. Because LSPs are established only where resources are available, over provisioning is not necessary. Further optimization of transmission resources is achieved by allowing LSPs not to follow the shortest path, if the available resources along the shortest path are not sufficient. However, MPLS TE is not aware of QoS, because it operates on the available bandwidth at an aggregate level across all classes. MPLS DiffServ-TE [3] makes MPLS-TE aware of QoS, allowing resource reservation with class granularity. By combining the functionalities of both DiffServ and TE, MPLS DiffServ-TE delivers the QoS guarantees to meet strict SLAs such as the ones required for voice, ATM, and Frame Relay. This paper evaluates the current implementation of MPLS Diffserv aware TE and gives the QoS analysis based on the experimental results. First, the related background technology is presented. Section 3 gives an in-depth view of the MPLS DiffServ-TE technology as defined in the IETF standards. Then, the testbed is designed and experiments are described. The end to end bandwidth performance is simulated and analyzed for different type of services including VoIP, Real time Video, and WWW traffic. The packet loss parameter is calculated for the guaranteed bandwidth services. Finally, the result is analyzed and potential research is proposed. II. RELATED TECHNOLOGY A. Quality of Service The fundamental objective of any QoS mechanism is to ensure that excessive congestion does not occur for the packets with assured QoS. During the past several years, numerous mechanisms have surfaced for providing QoS for communication networks as shown in Fig. 1. The Internet Engineering Task Force (IETF) has proposed many service models and mechanisms to meet the demand for QoS. Integrated Service (IntServ) and Differentiated Services (DiffServ) models are the most notable /07 $ IEEE DOI /SNPD

2 Time Best Effort Original IP QoS None IP QoS Timeline Diff Serv Simplicity & Scale Class Based Fig. 1. MPLS Diff Serv & DS-TE MPLS Guaranteed Bandwidth QOS States Flow Aggregated QoS Model Int Serv Strict IP QoS Per-flow IntServ, along with the Resource Reservation Protocol (RSVP), can provide end-to-end service guarantees in connectionless IP networks. Two additional services are proposed in this model: Guaranteed Service [4] and Controlled Load Service [5]. The first service can be used for the real time applications with strict bandwidth and latency requirements. With guaranteed service, no packets should be lost due to buffer overflow and there must be a specified upper bound on the queuing delay through the network. The latter service can support the traditional applications that want the network performance to be equivalent to a lightly loaded best-effort network. That is, the controlled load service ensures that a very high percentage of the packets do not experience delays that greatly exceed the minimum transit delay. However there is no specified upper bound on the queuing delay through the network. The main problem with the IntServ architecture is the scalability issue. In the control plane, per-flow information is kept. In the data forwarding plane, per-flow classification, perflow buffer management and per-flow scheduling are required, which places a huge storage and processing overhead on the routers. The Differentiated Services architecture [1] is designed to provide differing levels of QoS to different traffic flows. It cannot provide per flow bandwidth and delay guarantees. But it makes the stateless network scalable and robust. By marking the DiffServ fields of packets and handling them differently, several differentiated service classes can be supported. That is, differentiated service is essentially a qualitative QoS scheme. The following services are defined [6]: Premium Service, which is for applications requiring low delay and low jitter service. Assured Service, whichisfor applications requiring better reliability than best-effort service. Olympic Service, which provides three tiers of services: gold, silver, and bronze with decreasing quality. Such a scheme is more scalable since the amount of state information is proportional to the number of classes and the supporting data structures rather than the number of flows. Further, the classification, marking and policing operations are only needed at the boundary of the networks. B. MPLS QoS Multiprotocol Label Switching (MPLS) [7], [8] integrates a label swapping framework with network layer routing. The basic idea involves assigning short fixed length labels to packets at the ingress to an MPLS cloud (based on the concept of forwarding equivalence classes). Throughout the interior of the MPLS domain, the labels attached to packets are used to make forwarding decisions. More importantly, it provides an efficient tunneling mechanism for the connectionless IP network. That is to say, it creates end-to-end connection for the connectionless IP network. In a DiffServ domain, all IP packets crossing a link and requiring the same DiffServ behavior are said to constitute a Behavior Aggregate (BA). At the ingress node of the DiffServ domain packets are classified and marked with a DiffServ Code Point (DSCP) which corresponds to their BA. At each transit node, the DSCP is used to select the Per Hop Behavior (PHB) that determines the scheduling treatment and, in some cases, drop probability for each packet. RFC 3270 [9] specifies a solution for supporting the Diff- Serv BAs whose corresponding PHBs are currently defined over an MPLS network [10], [6]. This solution also offers flexibility for easy support of PHBs that may be defined in the future. In addition, two types of Label Switched Paths (LSPs) have been defined; E-LSP and L-LSP. An E-LSP can carry up to 8 PHBs. The EXP value of an MPLS label (used for packet classification and marking) identifies PHB. Label value is not used for QoS treatment (classification, queuing, dropping, and marking). An L-LSP carries packets belonging to a single PHB Scheduling Class (PSC) identified by the label value. A PSC consists of one or more PHBs where PHBs within a PSC are differentiated by EXP value on the label. The PSC of an L- LSP is explicitly signaled during LSP establishment. In L-LSP, PSC and EXP determine the QoS treatment. PSC determines the queue and EXP determines the WRED profile within that queue. Packet marking is done on EXP field. Using the MPLS Diff-Serv model, an MPLS service provider can offer differentiated services to customers sending IP traffic or MPLS traffic. C. MPLS Traffic Engineering (TE) Traffic Engineering [2] is the process of controlling how traffic flows through ones network so as to optimize resource utilization and network performance. Its motivation is to reduce the overall cost of operations by more efficient use of bandwidth resources. The explicit routing capabilities of MPLS allow the originator of the LSP to do the path computation, establish MPLS forwarding state along the path, and map packets into that LSP. Once a packet is mapped onto an LSP, forwarding is done based on the label, and none of the intermediate hops makes

3 Traffic Engineering Tunnel Creation R1 R8 PATH message 49 R2 27 R6 R3 22 R4 R7 32 R9 Pop R5 RESV message BC0 BC1 BC2 Class0 All Classes Maximum Reservable Bandwidth (MRB) RSVP PATH: R8 R2 R3 R4 R5 RSVP RESV: RSVP communicates labels and and reserves bandwidth on each link Fig. 3. Maximum Allocation Model Fig. 2. TE Tunnel Creation any independent forwarding decisions based on the packets IP destination. Calculating a path that satisfies some constraints, such as bandwidth and number of hops, requires that constrain information is available for each link, and this information be distributed to all the nodes that perform path calculation. This is achieved by adding TE-specific extensions to the link-state protocols that allow them to advertise not just the state (up/down) of the links, but also the links administrative attributes and the available bandwidth. In this way, each node has knowledge of the current properties of all the links in the network. Once this information is available, a modified version of the shortest-path-first (SPF) algorithm, called constrained SPF (CSPF), can be used by the ingress node to calculate a path that complies with the given constraints. Finally, after a path has been successfully calculated, MPLS forwarding state is established along that path by using RSVP- TE as a label distribution protocol [11]. Since the flow along an LSP is completely identified by the label applied at the ingress node of the path, these paths are treated as tunnels as showninfig.2. Although MPLS TE uses the same RSVP mechanism, it avoids the scalability issue of the InteServ. In MPLS TE scenario, state information applies to a collection of flows (i.e. a traffic trunk), rather than to a single (micro) flow. Moreover, RSVP sessions are created between routers, not hosts, which limit the number of RSVP sessions. Sessions in MPLS TE are long-lived, usually up to a few weeks. III. DIFFSERV-AWARE TRAFFIC ENGINEERING MPLS TE operates at an aggregate level across all classes of service and as a result it cannot give bandwidth guarantees on a per class basis. The basic DiffServ aware TE requirement is to be able to make separate bandwidth reservations for different classes of traffic and give different forwarding behavior based on the class. This implies keeping track of how much bandwidth is available for each type of traffic at any given time on all routers throughout the network. BC0 BC1 BC2 Fig. 4. All Classes (Class0 ) Russian Doll Model Maximum Reservable Bandwidth (MRB) For this purpose, the concept of a class type (CT) is introduced [3] as follows: The set of traffic trunks crossing a link, which is governed by a specific set of bandwidth constraints. CT is used for the purposes of link bandwidth allocation; constraint based routing, and admission control. A given traffic trunk belongs to the same CT at all links. The IETF requires support of up to eight CTs referred to as CT0 through CT7. DiffServ-TE adds the available bandwidth for each of the eight CTs as a constraint that can be applied to a path. Therefore, CSPF is enhanced to take into account CT-specific bandwidth at a given priority as a constraint when computing a path. For the computation to succeed, the available bandwidth per-ct at all priority levels must be known for each link. One of the most important aspects of the available bandwidth calculation is the allocation of bandwidth among the different CTs. The percentage of the links bandwidth that a CT (or a group of CTs) may take up is called a bandwidth constraint (BC). There are two BC models: Maximum allocation model (MAM): each class is dedicated an amount of bandwidth and other classes cannot take advantage of unused bandwidth as shown in Fig. 3. Russian Dolls Model (RDM) [12]: each class gets an amount of bandwidth but lower priority classes can use the bandwidth of higher priority classes when that bandwidth is available as shown in Fig 4. To summarize, the BC model determines the available

4 DVD1 DVD2 AX/4000 Decoder R1 R7 R3 Receiver PC R2 R5 MPLS Core Network R6 R Fig. 5. Testbed Topology bandwidth for each CT at each priority level. MAM and RDM are two possible BC models. They differ in the degree of sharing between the different CTs and the degree of reliance on preemption priorities necessary to achieve bandwidth guarantees for a particular CT. DiffServ provides the correct scheduling behavior for each type of traffic. The combination of DiffServ and per-ct traffic engineering ensures strict service guarantees. Three components for MPLS DiffServ aware TE: per-class traffic engineering, Per-class input policing at the edge and per-class scheduling at the core. IV. PERFORMANCE ANALYSIS A. The Testbed Design All of the experiments in the paper are obtained from a specially designed test network supported by the NCCT [13] and Hyperchip Inc. Fig. 5 displays the network topology used in this experimental study. Backbone is MPLS enabled. Two hyperchip PBR1280 are used as the Provider Edge (PE) devices shown as R5 and R6. R7 is a Cisco GSR router running MPLS. MPLS QoS and DiffServ-Aware Traffic Engineering (DS-TE) need to be implemented on the core network. Using a packet traffic generator, different traffic flows can be defined, generated and multiplexed. In the experiments conducted, a traffic generator built by AX/4000 is used, which can simulate the WWW data traffic. The MPEG 2 real time video traffic flow is generated by the Multimedia Access Concentrator 500 (MAC 500), which receives the real time DVD images from the DVD player and transcodes to MPEG 2 format digital data. The video traffic is then transmitted using RTP/RTCP protocol. The traffic rate can be adjusted when initializing the flow; its range in this experiment is set from 1.5M to 100M. A laptop is used to generate the VoIP traffic by running the VoIP software. In the experiments, three classes of service are provided: Premium, Business and Best Effort. Premium traffic has a minimum bandwidth guarantee with low latency, low jitter and no packet loss. Premium traffic received from CE devices should be limited to a certain amount. Any excess traffic should be dropped. VoIP traffic is defined as the Premium service in the experiment. Business traffic should have a minimum bandwidth guarantee with low packet loss for nonexcess 1. Inject EF and AF21 traffic 2. Inject BE (brown) traffic 3. Inject AF11 (light blue) traffic 4. Inject AF13 (purple) traffic 5. Inject AF21 (red) traffic Fig. 6. QoS result EF (Voice, CBR) AF21 (rt-vbr) AF11 (nrt-vbr, FR) AF13 BE (UBR, IP BE) traffic. Business traffic received from CE devices should be limited to a certain amount. Any excess traffic should be dropped first than the non-excess traffic in case of congestion. Here, the real time video traffic is defined as business service. Best Effort traffic shouldnt provide any guarantees and CE devices should only be limited by the link capacity on the amount of Best Effort traffic they can transmit. The simulated WWW data traffic from the traffic generator is used as the best effort service. We defined some explicit thresholds for the service guarantees. Bandwidth and packet loss are measured for the different classes during a period of time to be able to evaluate the actual performances [14]. B. Bandwidth Results In the scenario, 4 TE tunnels with different bandwidth requirements are set up. EF, AF11, AF13 and AF21 are assigned for each tunnel. Tunnels are created at different time showing in Fig. 6. The received packets rates are calculated and the performance shows that the bandwidth can be guaranteed end to end for each created TE tunnel. TABLE I SERVICE DEFINITION Class Guarantees Limit (Mbps) Application Premium Bandwidth, no packet loss 1.28 VoIP Business Bandwidth, low packet loss 30 Video Best Effort None None WWW C. Packet Loss Results In the scenario, VoIP, Video and Data traffic are generated. The traffic rate, bandwidth requirement and packet loss are shownintablei.thevoiptraffichasaconstbitrate,so that with the required bandwidth guarantee, there is no packet

5 Packet Loss Probability packet loss probability 4.5 x Muanx Nature News Guaranteed Bandwidth(Mbps) Fig. 7. Packet Loss with different guaranteed bandwidth time x 10 5 Fig. 8. Packet Loss Probability History loss. The QoS is pretty good for such type of service. However, the video traffic has some burst period, with the guaranteed bandwidth, there is still some packet loss happened. To investigate the required bandwidth for different video type, several different movies are played. In the scenario, three types of video traffic are played with different tunnel bandwidth setup as shown in Table II. From the measured result shown in Fig. 7, it can verify that only bandwidth guarantee can not give the packet loss probability guarantees. With the 30M bps bandwidth guarantee, the packet loss probability is , and , respectively. With the increasing reserved bandwidth, the packet loss probability decreases. Even though for the same movie, at different time stage, the packet loss probability is also variable as shown in Fig. 8. The variable loss is due to the burst traffic. TABLE II STATISTICS SYNOPSIS OF TRAFFIC FLOWS Number Video Name Traffic Average Rate Peak Rate 1 Mutanx Nature News V. CONCLUSION The combined use of the MPLS DiffServ and MPLS TE is envisioned to provide end to end guaranteed quality of service (QoS) for multiservice traffic in IP networks. A number of experiments are devised on the live network to evaluate the QoS performance of the applications proposed by MPLS Diffservaware TE under different traffic type. Voice traffic has a lower bandwidth and almost constant rate requirement, which is easily guaranteed accordingly by allocating the enough bandwidth and priority for this type of traffic. However, the video traffic has variable-bit-rate (VBR) property. So, counting only on the bandwidth parameter guarantee cannot satisfy the real QoS. That is, the packet loss ratio will be variable for different types of video or at different time for the same flow. Appropriate bandwidth should be calculated and allocated for such type of traffic. REFERENCES [1] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, and W. Weiss, An Architecture for Differentiated Service, RFC 2475, Dec [2] D. Awduche, J. Malcolm, J. Agogbua, M. O Dell, and J. McManus, Requirements for Traffic Engineering Over MPLS, RFC 2702 (Informational), Sept [3] F. L. Faucheur and W. Lai, Requirements for Support of Differentiated Services-aware MPLS Traffic Engineering, RFC 3564, July [4] S. Shenker, C. Partridge, and R. Guerin, Specification of Guaranteed Quality of Service, RFC 2212 (Proposed Standard), Sept [5] J. Wroclawski, Specification of the Controlled-Load Network Element Service, RFC 2211 (Proposed Standard), Sept [6] J. Heinanen, F. Baker, W. Weiss, and J. Wroclawski, Assured Forwarding PHB Group, RFC 2597 (Proposed Standard), June 1999, updated by RFC [7] E. Rosen, A. Viswanathan, and R. Callon, Multiprotocol Label Switching Architecture, RFC 3031 (Proposed Standard), Jan [8] C. Perkins and P. Calhoun, Mobile IPv4 Challenge/Response Extensions, RFC 3012 (Proposed Standard), Nov. 2000, obsoleted by RFC [9] F. L. Faucheur, L. Wu, B. Davie, S. Davari, P. Vaananen, R. Krishnan, P. Cheval, and J. Heinanen, Multi-Protocol Label Switching (MPLS) Support of Differentiated Services, RFC 3270 (Proposed Standard), May [10] K. Nichols, S. Blake, F. Baker, and D. Black, Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers, RFC 2474 (Proposed Standard), Dec. 1998, updated by RFCs 3168, [11] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, and G. Swallow, RSVP-TE: Extensions to RSVP for LSP Tunnels, RFC 3209 (Proposed Standard), Dec. 2001, updated by RFCs 3936, [12] F. L. Faucheur, Russian Dolls Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering, RFC 4127 (Experimental), June [13] B. I. et al., A testbed and research network for next generation services over next generation networks, in Tridentcom 2005, [14] D. Zhang and D. Ionescu, On packet loss estimation for virtual private networks services, in ICCCN 2004, Chicago, IL, USA