Master degree report Study and implementation of QoS techniques in IP/MPLS networks Molka GHARBAOUI In partial fulfilment of the requirements for the Degree of International Master on Communication Networks Engineering Tutors Barbara MARTINI Isabella CERUTTI Anna Lina Ruscelli Gabriele Cecchetti
Abstract Abstract In multi-service IP networks, it is a key challenge to provide Quality of Service (QoS) to end-user applications while effectively using network resources. As nowadays the interest is related to guarantee QoS for the multi-media services i.e. voice and video traffic which have specific requirements to be efficiently handled, networks based on only best-effort traffic become insufficient. This work presents a study of Quality of Service techniques in IP/MPLS networks on a perapplication basis. The study shows the relevance of an architecture where DiffServ, MPLS and Traffic Engineering would cooperate to overcome the challenges for QoS-capable IP networks. In fact, the DiffServ architecture has emerged as a solution to guarantee quality of service. In addition to that, the use of the MultiProtocol Label Switching (MPLS) and Traffic Engineering (TE) gives the ability on the one hand to efficiently use the network resources and on the other hand to classify and prioritize traffic. The study is then followed by a theoretical and experimental activity. The theoretical part includes an analysis of voice traffic characteristics as the need for Quality of Service techniques is particularly emphasized while handling multimedia traffic. It is followed by an experimental activity to demonstrate the results obtained theoretically. For that, a configuration of the studied techniques is applied to a testbed where voice traffic is injected into the network in addition to besteffort traffic. The differentiated treatment on a per-application basis is obtained by setting MPLS DiffServ-aware Traffic Engineering capabilities. Keywords: QoS, MPLS, TE, DiffServ. IMCNE thesis i
Acknowledgement Acknowledgement This thesis presents the work done to obtain the degree of International Master on Communications Networks Engineering (IMCNE). It was realized in the Centre of Excellence for Information and Communication Engineering (CEIIC) with the goal of studying and implementing Quality of Service techniques in IP/MPLS networks. I thank my tutors Mrs Barbara MARTINI, Ms Isabella CERUTTI, Ms Anna Lina Ruscelli and Mr Gabriele Cecchetti for their availability, precious help and advice. I thank Valerio MARTINI, the PhD student at the Scuola Superiore Sant Anna for his support. I thank also Claudio Manfroni, tutor of the IMCNE master, for all the help that he presented to me during all the master duration. IMCNE thesis ii
List of Tables and Figures List of Tables and Figures Figures Figure 1.MPLS Label Switching... 04 Figure 2. Basic Resource Reservation Setup Operations of RSVP signalling protocol... 08 Figure 3. Redefinition of the ToS field in the IP header... 09 Figure 4. Per-Class Queuing Node (Edge)... 11 Figure 5. Mapping DSCP to EXP... 11 Figure 6. DiffServ-Aware MPLS Traffic Engineering (DS-TE)... 12 Figure 7. MAM Constraint Model Example... 14 Figure 8. RDM Constraint Model Example... 15 Figure 9. Classifying and Marking... 17 Figure 10. Policing and Shaping... 17 Figure 11. Scheduling and Queuing... 18 Figure 12. A standard voice packet... 21 Figure 13. The testbed... 23 Figure14. IP packet configuration... 24 Figure 15. RTP packet configuration... 25 Figure 16. Traffic capture... 26 Figure 17. Packets listing... 26 Figure 18. CoS components... 27 Figure 19. Access to the router... 28 Figure 20. Interfaces configuration... 28 Figure 21. Routing protocols configuration... 29 Figure 22. Forwarding Classes configuration... 30 Figure 23. Configuration of LSPs... 31 Figure 24. Configuration of the multi-field classifier... 31 Figure 25. Configuration of a BA classifier... 32 Figure 26. Schedulers configuration... 33 Figure 27. Marking outgoing packets... 34 Tables Table 1. Packetization delay... 21 Table 2. LSPs characteristics... 27 IMCNE thesis iii
Contents Contents Introduction... 01 Chapter 1: Background... 03 I. Network architecture... 03 II. MPLS network... 03 II.1. MPLS Terminology... 03 II.2. MPLS-TE... 04 III. Need for Quality of Service... 04 Chapter2: QoS in MPLS networks... 06 I. Quality of Service... 06 I.1. Why QoS?... 06 I.2. QoS parameters... 07 II. QoS in IP networks... 08 II.1. IntServ with RSVP... 08 II.2. DiffServ... 09 III. QoS in MPLS networks... 10 III.1. MPLS Support of DiffServ... 10 III.2. Mapping DSCP to the EXP field... 11 III.3. DiffServ-Aware MPLS Traffic Engineering... 12 III.3.1. Definition... 12 III.3.2. Bandwidth Constraint Models... 13 III.3.3. Deploying the DiffServ-TE solution... 16 IV. QoS operations... 16 Chapter 3: Experimental activity... 20 I. Characterization of QoS for voice traffic... 20 I.1. Voice traffic characteristics... 20 I.2. QoS requirement for voice traffic... 22 II. Experimental setup... 23 II.1. Testbed schema... 23 II.2. Software... 23 II.3 Tests... 24 II.4 Router configuration... 27 Conclusion... 34 References... 35 Glossary... 36 IMCNE thesis iv
Introduction Introduction The recent evolution of the telecommunications has witnessed the birth and the development of many technologies and protocols, to best offer a variety of services in geographically distinct areas. Moreover, networks delivering multimedia contents such as video and voice are facing the problem of how to guarantee the quality of service (QoS) requested by the user in the contract stipulated with the service provider. QoS must be in conformity with applications requirements which do not answer any more the criteria of the services carried out by the best effort and then allow having the appropriate and available resources in order to support these kinds of specific services. Consequently, the need for a QoS control on a per-application basis was noticed. IP/MPLS networks are a QoS-enabled technology capable to provide mechanisms for traffic engineering and bandwidth guarantees. In fact, MPLS provides a connection-oriented environment which, combined with technologies that provide traffic flows with application-specific treatment can lead to guarantee end-to-end quality of service. In recent years, two kinds of frameworks have emerged from the IETF standards processes which are IntServ and DiffServ services. Inserv is a per-flow basis architecture that specifies the elements to guarantee QoS on networks by making individual reservations on every network element. On the contrary the Diffserv architecture is a class-based mechanism that operates on the principle of placing each packet into a limited number of traffic classes. For various reasons, IntServ never scaled to the level it needed to get to for Internet-size networks and we turned towards DiffServ which, associated to MPLS and Traffic Engineering (TE) came up with the concept of DiffServ-aware Traffic Engineering (DS-TE). MPLS inherently does not support QoS mechanisms but thanks to the connection-oriented approach, the class differentiation and the resource optimization capabilities given by TE methods, DS-TE allowed network operators to provide services that require strict QoS performance guarantees. The primary goal of this project is to study the QoS techniques in IP/MPLS networks for a differentiated treatment on per-application basis. As a second step, some router configurations done over an MPLS testbed will be used to evaluate the Quality of Service of voice traffic. This work is realized in the Centre of Excellence for Information and Communication Engineering (CEIIC). The centre was established in 2001, thanks to the joint effort that Sant'Anna School for Advanced Studies decided to undertake in the telecommunications sector in collaboration with Marconi Communications SpA (now Ericsson). ). These two parties, in partnership with CNIT (National Inter-University Consortium for Telecommunications) are aiming to address a major demand for integrating education, basic and applied research in the area of optical networks and technologies. IMCNE thesis
Introduction This report is organized as follows: the first chapter named Background presents a theoretical overview of the concepts that are tightly related to the developed work. The second chapter named QoS in MPLS networks is mainly devoted to the deployment of quality of service mechanisms in MPLS networks. The third chapter named Experimental activity and results is dedicated to the practical aspect of the project which includes a presentation of voice traffic characteristics and requirements for QoS, routers configuration, tests and obtained results. Finally some conclusions are drawn. IMCNE thesis 2
Chapter 1: Background Chapter 1: Background This chapter presents the terminology and basic concepts related to the developed work. In fact, it defines the network architecture, MPLS networks, Quality of Service, and the Traffic Engineering. I. Network architecture Telecommunication networks consist of two principal components transport or core network and access network. An access network is the part which connects subscribers to their immediate service provider. In many networks, it is still largely predominated by the copper cable based pointto-point connections, resulting in a large proportion of passive, inflexible and relatively unreliable networks that are tailored to traditional services such as the voice, leased lines, and low rate data transmission. On the other hand, the core network is the central part of the telecom network that provides various services to customers who are connected by the access network. As circuit switched networks are getting replaced by packet-switched networks, many service providers are turning to IP/MPLS technology as a common core for existing and next-generation services and this is due to its future flexibility, network scalability, and a reduction in the cost of new service deployment. II. MPLS network II.1. MPLS Terminology MPLS stands for "Multi-Protocol Label Switching". It is a switching technology based on forwarding the packets according to a short, fixed length identifier termed as a label, instead of the network-layer address with variable length match. As showed in Figure 1, the labels are assigned to the packets at the ingress node of an MPLS domain. Inside the MPLS domain, the labels attached to packets are used to make forwarding decisions. The labels are finally popped out from the packets when they leave the MPLS domain at the egress nodes. Routers which support MPLS are known as "Label Switched Routers", or "LSRs" [1]. IMCNE thesis 3
Chapter 1: Background Figure 1.MPLS Label Switching II.2. MPLS-TE In traditional networks, Traffic Engineering is used to achieve performance objectives such as optimization of network resources and placement of traffic on particular links. The explicit routing capabilities of MPLS allow the originator of the LSP to do the path computation, establish the MPLS forwarding state along the path, and map packets onto that LSP. Once a packet is mapped onto an LSP, forwarding is done based on the label, and none of the intermediate hops makes any independent forwarding decisions based on the IP destination address of the packet [4]. MPLS can provide additional benefits for the support of real-time communications. The use of DiffServ alone does not guarantee adequate bandwidth resources for a specific application. If voice traffic follows a network path with insufficient resources to meet the performance criteria for jitter and latency, for example, voice quality will not be adequate. In principle, this problem could be solved by over-provisioning resources to avoid congestion altogether. III. Need for Quality of Service The internet and IP protocol were designed to provide best-effort traffic where all packets are treated equally. But as applications load is getting higher and network traffic is becoming highly diverse, just increasing the amount of resources such as available bandwidth to avoid congestion does not provide proper resource utilization and is not sufficient to meet applications requirements. To handle this, the use of QoS mechanisms ensures that packets will receive appropriate treatment as they travel through the network. This helps applications and end users to be in line with their expectations and with the commitments contracted by the customer with the network operator. IMCNE thesis 4
Chapter 1: Background Indeed, the use of MPLS and MPLS-TE alone is not enough anymore to guarantee the quality of service in the network. For this reason, those mechanisms which can ensure a differentiated packet treatment according to applications requirements became necessary. IMCNE thesis 5
Chapter 2: QoS in MPLS networks Chapter2: QoS in MPLS networks The previous chapter presented the concepts that are related to the present work. This chapter exposes the Quality of Service solutions offered to handle voice traffic. It defines voice traffic characteristics, QoS requirements and provides a general overview of the needed QoS operations. I. Quality of Service I.1. Why QoS? Today s networks are a mix of different types of traffic, each with very different requirements. Applications are expecting that their traffic can be properly supported in the IP network regardless to their specificities. This need for Quality of Service is especially important in presence of network congestion where the necessity for an adequate bandwidth to meet the demands of the offered load comes from the fact that excess packets in the network cause their delay and loss. Some solutions were proposed to handle this congestion: Over-provisioning Consist in adding more bandwidth and over-provision the network to ensure that the need for bandwidth can be satisfied at all times. It looks like an ideal solution but can lead to wastage of valuable resources. Separate networks Set up a separate network for each application type (voice, video and data for example) to avoid sharing resources between traffic types. Like over-provisioning this leads to a poor utilization of resources and does not solve the problem for example of having more voice traffic than there is bandwidth for voice network. Class differentiation The class differentiation enables network nodes to differentiate among several classes of incoming traffic and satisfy their own requirements. This permits to recognize the traffic belonging to certain users and applications such that preferential services may be provided to them. QoS parameters can allow to define the various classes. IMCNE thesis 6
Chapter 2: QoS in MPLS networks I.2. QoS parameters The service needs of different applications can be represented as a set of parameters, including bandwidth, delay, jitter, and packet loss [2]. I.2.1. Bandwidth The first thing needed to guarantee Quality of Service is having an adequate bandwidth. Since it is an expensive resource, its amount should be given after a good understanding of the network capabilities and requirements. I.2.2. End-to-end delay It is the delay needed by a packet to cross the infrastructure from source to destination. Its influence depends on the type of the traffic carried by the packets. For example, concerning voice which is a real-time traffic; if there is a too long delay in voice packet delivery, speech will be unrecognizable. This delay comprises four components: The sampling delay: concerns analogical traffic and consists in the duration of digitalization at the emission and of conversion at the reception. The propagation delay: duration of transmission of the digitized data. It is about a few milliseconds. The transmission delay: duration spent across the routers, the switches and other components of the network. The order of magnitude is from several tens of milliseconds to hundreds of milliseconds. The jitter's buffers delay: delay introduced at the reception in order to reduce the jitter. The order of magnitude is of 50 ms. I.2.3. Jitter Jitter is the variation of delay between the moment when two packets should have arrived and the moment of their effective arrival. It is due to the fact that the packets do experience different delays at the node buffers. It is independent from the transmission delay and is a consequence of momentary congestions on the network which cannot transport any more the data in a constant way in time. The value of the jitter goes from a few ms to a few tens of ms. I.2.4. Packet loss Packet loss occurs when one or more packets of data travelling across a computer network fail to reach their destination. It is distinguished as one of the main error types encountered in digital communications. It can be caused by a number of factors, including signal degradation over the network medium, oversaturated network links, corrupted packets rejected in-transit, faulty networking hardware, maligned system drivers or network applications, or normal routing routines. IMCNE thesis 7
Chapter 2: QoS in MPLS networks Lost or dropped packets can result in highly noticeable performance and can affect all network applications to a certain degree. II. QoS in IP networks II.1. IntServ with RSVP The fundamental idea of Integrated Services (IntServ) architecture is to reserve resources such as bandwidth and buffers. IntServ develops architecture for resource allocation to meet the requirements of real-time applications which have a deadline for data to arrive by, after which the data become less useful. As shown in Figure 2, to receive performance assurance from the network, an application must set up the resources reservation along its path before it can start to transmit packets by sending and receiving PATH and RESV messages. This is based on the use of the ReSource reservation Protocol (RSVP) which is a signalling protocol for applications to reserve resources [6]. IntServ provides two service classes in addition to best-effort service, that are the Guaranteed Service which is defined to provide an assured level of bandwidth, a firm end-to-end delay bound and no queuing loss and is intended for real-time applications such as voice and video; and a Controlled Load Service, for applications requiring a reliable and enhanced best-effort service and that could tolerate a limited amount of loss and delay[3]. Figure 2. Basic Resource Reservation Setup Operations of RSVP signalling protocol The IntServ architecture has satisfied both necessary conditions for the network QoS; however, its problems are as follows: The amount of state information increases proportionally with the number of flows which needs a huge storage and processing load on the routers. All routers must have RSVP, admission control, packet classification and packet scheduling. Therefore, the IntServ model was implemented only in a limited number of networks, and naturally the IETF moved to develop DiffServ as an alternative QoS approach with minimal complexity. IMCNE thesis 8
Chapter 2: QoS in MPLS networks II.2. DiffServ DiffServ determines the QoS behaviour of a packet at a particular node in the network. This is called the per-hop behaviour (PHB) and is expressed in terms of the Forwarding Class that a packet experiences. The PHB translates to the packet queue used for forwarding, the resources (buffers and bandwidth) allocated to each queue, the frequency at which a queue is serviced, as well as the drop probability in case the queue exceeds a certain limit [2]. The four general per-hop behaviour categories are: Best effort (BE) traffic: receives no special treatment. Expedited forwarding (EF) traffic: encounters minimal delay, low loss, low jitter, and assured bandwidth end to end. From a practical point of view, this means a queue dedicated to EF traffic for which the arrival rate of packets is less than the service rate, so delay, jittand loss due to congestion is unlikely. Voice and video streams can be mapped to EF: they have constant rates and require minimal delay and loss. Assured forwarding (AF) traffic: offers finer Class of Service (CoS) granularity. A queue number and a drop profile can define each PHB. The AF PHBs are applicable for traffic that requires rate assurance but not bounds on delay or jitter. Network control (NC) traffic: carries routing protocol exchanges. These packets cannot tolerate loss, but can accept delay. DiffServ provides differential forwarding treatment to the traffic, thus enforcing QoS for different traffic flows. It is a scalable solution that does not require per-flow signalling or maintenance of the state parameters in the core. However, it cannot guarantee QoS if the path followed by the traffic does not have adequate resources to meet the QoS requirements. The DiffServ model is based on redefining the meaning of the 8-bit ToS field in the IP header. The Figure 3 shows the redefinition of the original ToS which is split into the 6-bit DiffServ Code Point (DSCP) value and the 2-bit Explicit Congestion Notification (ECN) part. Figure 3. Redefinition of the ToS field in the IP header IMCNE thesis 9
Chapter 2: QoS in MPLS networks The IP Type of Service octet is composed of the following fields: delay (D), throughput (T), reliability (R), cost (C) and explicit congestion notification (ECN). The disadvantage of the DiffServ architecture is that it suggests only mechanisms for relative packet forwarding treatment to aggregate flows, traffic management and conditioning, however it does not provide architecture for end-to-end QoS. Furthermore, there is no traffic engineering provision in DiffServ. As a result some links in the domain might experience congestion while others could be unutilized or underutilized. III. QoS in MPLS networks The MPLS technology provides a unified data-carrying service for both circuit-based and packetswitching clients and gives networks a more efficient way to move information between locations. However this is not sufficient to insure Quality of Service that s why the support of DiffServ architecture has emerged as a solution to guarantee QoS. Combining that with Traffic Engineering (TE) gave rise to DiffServ-aware MPLS Traffic Engineering which ensures the efficient use of network resources and prioritize traffic. III.1. MPLS Support of DiffServ MPLS Diffserv TE combines the advantages of both DiffServ and MPLS-TE. MPLS Diffserv TE makes MPLS-TE aware of classes of service, allowing resource reservation with Class of Service (CoS) granularity and providing the fault-tolerance properties of MPLS at a CoS level, thus ensuring adequate resources are available on a per-application level [1]. MPLS priorities can be established to ensure that voice traffic, for example, follows paths with the proper resources to forward it and pass it efficiently through the network. These priorities can give voice MPLS LSPs greater importance than others, allowing them to use whatever resources are necessary to take the shortest path across the network or find the fastest alternative route in the event of a link failure. Priorities are assigned by indicating an LSP's importance relative to other LSPs. As stipulated in Figure 4, in differentiated service model, each packet is classified at network entrance. Routers put then each classified packet into a specific queue in order to be treated by a per-class scheduler. Only the simple mapping of DSCP and PHB is preserved at core routers of the network. Flow status information do not need to be stored, thus the scalability of the network is improved. IMCNE thesis 10
Chapter 2: QoS in MPLS networks Figure 4. Per-Class Queuing Node (Edge) III.2. Mapping DSCP to the EXP field In MPLS domain, the packets are routed based on the assigned label rather than the original packet header. To support the differentiated service according to each DiffServ class in an MPLS network, MPLS shim header must infer the PHB (Per-Hop Behaviour) information of DSCP. Figure 5. Mapping DSCP to EXP The IETF proposed to codify the DiffServ information expressed in a 6-bit DSCP in MPLS domain by mapping it, as shown in Figure 5, to the EXP bits in the MPLS header. There are two ways to achieve this, depending on these ways the label header is encoded [1]: E-LSP (Exp-inferred LSPs): LSR can use the three bit EXP field in MPLS shim header for supporting fewer than eight PHBs. If the required number of classes is lower than 8 there is no IMCNE thesis 11
Chapter 2: QoS in MPLS networks problem to map the DSCP in IP packet header. The mapping is straightforward: a particular DSCP is equivalent to a particular EXP combination and maps to a particular PHB (scheduling and drop priority). L-LSP (Label-only-inferred LSPs): It is to use the label field itself as the information carrier about different PHBs. L-LSPs can carry packets from a single PHB, or from several PHBs that have the same scheduling regimen but differ in their drop priorities. The packets belonging to a common PHB scheduling class must travel on the same LSP. III.3. DiffServ-Aware MPLS Traffic Engineering III.3.1. Definition MPLS-TE (Traffic Engineering based on MPLS) and DiffServ (Differentiated Services) can be deployed concurrently. Thus, DiffServ provide packets with a preferential treatment using different code-points in their header to enable performing routing with class-based constraint and MPLS networks are configured to offer different QoSs to different paths through the network. This combination of MPLS and DiffServ is called DS-TE (DiffServ aware MPLS Traffic Engineering) [1]. DS-TE mechanisms must decide how to distribute the resources differently to each class. The link capacity can be divided to be used by each traffic class with appropriate rate which can be achieved by Bandwidth Constraint models (BC models). Figure 6. DiffServ-Aware MPLS Traffic Engineering (DS-TE) The Figure 6 shows an example of DS-TE mechanism based on MPLS LSPs. When a traffic demand arrives at an ingress router, it is classified and marked according to its DSCP (DiffServ Code Point) in the packet header. Thus, the ingress calls an appropriate routing algorithm to find the IMCNE thesis 12
Chapter 2: QoS in MPLS networks best path for the current demand. For example, it gives the shortest path for an LSP request which requires low-delay, and the longer and big-capacity path for best effort traffic. By using different paths according to traffic class, DS-TE can give different Quality of Service to the users and it can use efficiently its network resources. The basic DiffServ Aware TE requirement is to be able to make separate bandwidth reservations for different classes of traffic and give different forwarding behaviour 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. III.3.2. Bandwidth Constraint Models Bandwidth Constraint (BC) models describe how to allocate the bandwidth to the individual Class Types (CTs). The concept of a Class Type was introduced as 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. The IETF requires support of up to eight CTs referred to as CT0 through CT7 [1]. In the context of DS-TE, there are mandatory requirements for any practical BC model. The first is concerning bandwidth utilization: the bandwidth needs to be efficiently shared by multiple CTs under the normal as well as the overload conditions. The second is associated with bandwidth isolation: a CT cannot hog the bandwidth of other CTs under the overload condition. In fact, the set of bandwidth constraints (BC) defines the rules that a node uses to allocate bandwidth to different CTs. Each link in the DS-TE network has a set of BCs that applies to the CTs in use. This set may contain up to eight BCs. When a node using DS-TE admits a new TE LSP on a link, that node uses the BC rules to update the amount of unreserved bandwidth for each TE- Class. Next, three proposed model for the support of BC are presented. III.3.2.1. The Maximum Allocation Model (MAM) The MAM defines a one-to-one relationship between BCs and Class-Types. It offers limited bandwidth sharing between CTs. A CT cannot make use of the bandwidth left unused by another CT. From a practical point of view, the link bandwidth is simply divided among the different CTs [1]. The Figure 7 shows an example of a set of BCs using MAM. This DS-TE configuration uses three CTs with their corresponding BCs. In this case, BC0 limits CT0 bandwidth to 15 percent of the maximum reservable bandwidth. BC1 limits CT1 to 50 percent, and BC2 limits CT2 to 10 percent. The sum of BCs on this link is less than its maximum reservable bandwidth. Each CT will always receive its bandwidth share without the need for preemption. IMCNE thesis 13
Chapter 2: QoS in MPLS networks Figure 7. MAM Constraint Model Example The MAM has a number of advantages: It guarantees the bandwidth isolation across multiple CTs, thus, no priorities need to be configured between LSPs carrying traffic from different CTs. It ensures the bandwidth efficiency and the protection against QoS degradation of the premium CT. It does not require much revision of the current protocols. The problem with MAM is that because it is not possible to share unused bandwidth between CTs, bandwidth may be wasted instead of being used for carrying other CTs. III.3.2.2. The Russian Dolls Model (RDM) The RDM improves bandwidth efficiency over the MAM model by allowing CTs to share bandwidth. It defines a cumulative set of constraints that group CTs. Subsequent lower BCs define the total bandwidth allocation for the CTs at equal or higher levels. BC0 always defines the maximum bandwidth allocation across all CTs and is equal to the maximum reservable bandwidth of the link. The recursive definition of BCs improves bandwidth sharing between CTs. A particular CT can benefit from bandwidth left unused by higher CTs. A DS-TE network using RDM can rely on TE LSP preemption to guarantee that each CT gets a fair share of the bandwidth [1]. The Figure 8 shows an example of a set of BCs using RDM. This DS-TE implementation uses three CTs with their corresponding BCs. In this case, BC2 limits CT2 to 30 percent of the maximum reservable bandwidth. BC1 limits CT2+CT1 to 70 percent. BC0 limits CT2+CT1+CT0 to 100 percent of the maximum reservable bandwidth, as is always the case with RDM. CT0 can use up to 100 percent of the bandwidth in the absence of CT2 and CT1 TE LSPs. Similarly, CT1 can use up to 70 percent of the bandwidth in the absence of TE LSPs of the other two CTs. CT2 will always be limited to 30 percent when no CT0 or CT1 TE LSPs exist. IMCNE thesis 14
Chapter 2: QoS in MPLS networks Figure 8. RDM Constraint Model Example The advantage of RDM relative to MAM is that it provides efficient bandwidth usage through sharing. It is a good match to the way many network operators manage QoS in the data plane, e.g., voice in Low Latency Queuing (LLQ), business data in a high weight Class-Based Weighted Fair Queuing (CBWFQ) class, and best effort getting whatever is left. RDM provides for good isolation between classes, and efficient use of bandwidth. It can also simultaneously provide the bandwidth efficiency and the protection against QoS degradation of all CTs, whether preemption is enabled or not. Besides, similar to the MAM, the RDM does not require much revision of the current protocols. The disadvantage of RDM relative to MAM is that there is no isolation between the different CTs, and preemption must be used to ensure that each CT is guaranteed its share of bandwidth no matter the level of contention by other CTs. III.3.2.3. The Maximum Allocation with Reservation Model (MAR) The MAR model can be regarded as an extension of the MAM. Like the MAM, each CT has a corresponding bandwidth constraint in the MAR model. However, unlike the MAM, the CTs are allowed to exceed their constraints, provided that no congestion or overload occurs. A new parameter, denoted by RBT, was introduced into MAR to characterize the Threshold of Bandwidth Reservation [5]. The bandwidth allocation control for each CT is based on estimated bandwidth needs, bandwidth use, and status of links. The Label Edge Router (LER) makes needed bandwidth allocation changes, and uses (for example, to determine if link bandwidth can be allocated to a CT). Bandwidth allocated to individual CTs is protected as needed, but otherwise it is shared. Under normal, noncongested network conditions, all CTs/services fully share all available bandwidth. When congestion occurs for a particular CTc, bandwidth reservation prohibits traffic from other CTs from seizing the allocated capacity for CTc. IMCNE thesis 15
Chapter 2: QoS in MPLS networks The IETF does not mandate usage of the same BC model on all links in the network. However, it is easier to configure, maintain, and operate a network where the same bandwidth constraint model is used. III.3.3. Deploying the DiffServ-TE solution To summarize the previous sections, MPLS DiffServ-aware TE makes MPLS-TE aware of Quality of Service, by combining the functionalities of both DiffServ and Traffic Engineering. This solution handles the problems of providing guaranteed QoS by enabling the reservation of bandwidth on a per-class basis. To ensure this, the following steps are required: - Partition the link bandwidth among the different CTs -Configure the LSPs with the desired CT and bandwidth reservation -Choose a BC model that ensures the needed requirements -Setup the queue and scheduling policies -Map the EXP-to-PHB throughout the DiffServ domain if the DiffServ treatment is determined from the EXP bit. IV. QoS operations QoS management architecture of voice traffic can be partitioned into two planes: data plane and control plane. Mechanisms in data plane include packet classification, shaping, policing, buffer management, and scheduling. They implement the actions the network needs to take on user packets, in order to enforce different class services. Mechanisms in control plane consist of resource provisioning, traffic engineering, admission control, resource reservation and connection management [9]. IV.1. Classification, Shaping and Policing When a packet is received, a packet classifier determines which flow or class it belongs to, effectively partitioning network traffic into different levels. Figure 9 shows that all packets belonging to the same flow/class obey a predefined rule and are processed in a similar manner. For example, for voice traffic applications, the basic criteria of classification could be IP address, TCP/UDP port, protocol, input port, IP precedence, DiffServ code points (DSCP), or Ethernet 802.1p class of service (CoS). IMCNE thesis 16
Chapter 2: QoS in MPLS networks Figure 9. Classifying and Marking After classification, the packet is passed on to a traffic conditioner, which may contain meter, marker, shaper, and dropper. A meter is to decide whether the packet is in a traffic profile. This information may be used by other elements to trigger a particular action. In-profile packets are put in different service queues for further processing. A shaper or a dropper delays or drops out-of-profile packets in a packet stream in order to bring the stream into compliance with its traffic profile. The function of a dropper is known as traffic policing. A marker marks the certain field in the packet, such as DS field, to label the packet type for differential treatment later. After the traffic conditioner, a buffer is used to store packets that wait for transmission. Figure 10. Policing and Shaping Policers allow limiting traffic of a certain class to a specified bandwidth and bursting size. Packets exceeding the policer limits can be discarded, or can be assigned to a different forwarding class, a different loss priority, or both. But traditionally, packets are dropped only when the queue is full. IV.2. Scheduling An individual router interface has multiple queues assigned to store packets. The router decides which queue to service based on a particular method of scheduling. This process often involves a determination of which type of packet should be transmitted before another. As shown in Figure 11, a scheduler defines the queuing parameters of the FC (Forwarding Class), specifically its IMCNE thesis 17
Chapter 2: QoS in MPLS networks transmission rate, buffer size, and priority. It is where the queuing specifics and buffer depth are configured. IV.2.1. Transmission rate A transmission rate is assigned to each FC proportionally to the bandwidth credit the queue has. It can be specified as either exact or remainder. If exact is specified, the FC cannot exceed the configured transmission rate. If it is specified as remainder, the FC is allowed to use unallocated bandwidth (the queue can borrow bandwidth from the others). IV.2.2. Buffer size It defines the amount of memory allocated to the outbound transmission queue. This parameter is particularly useful for real-time traffic where it is desirable to forcibly eliminate the delivery of stale packets. IV.2.3. Priority A Forwarding Class associated with a queue has a priority of low, high, or strict high associated with it. The scheduler examines queues in a round robin fashion. If two queues or more have a packet to send and have enough bandwidth credit, then the queues with high priority are serviced first. Scheduling policy is primarily to control queuing delay and bandwidth sharing. The aggregate bandwidth of a link can be shared among multiple entities. Figure 11. Scheduling and Queuing IV.3. Queuing After a packet is sent to the outgoing interface on a router, it is queued for transmission on the physical media. The amount of time a packet is queued on the router is determined by the availability of the outgoing physical media as well as the amount of traffic using the interface. Queuing generally is used to give voice priority over data traffic. IMCNE thesis 18
Chapter 2: QoS in MPLS networks Queuing delay can be reduced by introduction of advanced queuing features such as: FCFS: First Come First Serve WFQ: Weighted Fair Queuing: WFQ applies priority (or weights) to identified traffic to classify traffic into conversations and determine how much bandwidth each conversation is allowed relative to other conversations. WFQ classifies traffic into different flows based on such characteristics as source and destination address, protocol, and port and socket of the session. CBWFQ: Class-Based WFQ: CBWFQ extends the standard WFQ functionality to provide support for user-defined traffic classes. It allows specifying the exact amount of bandwidth to be allocated for a specific class of traffic. Taking into account available bandwidth on the interface, we can configure up to 64 classes and control distribution among them. IMCNE thesis 19
Chapter 3: Experimental activity Chapter 3: Experimental activity I. Characterization of QoS for voice traffic The previous chapters gave an overview of Quality of Service techniques in IP/MPLS networks. This chapter presents a special case which is how to use those mechanisms to handle voice traffic. The first part presents voice traffic characteristics and its QoS requirements. The second describes the testbed set-up needed for configuring QoS parameters as well as the software implemented for generating and capturing the traffic. The last part deals with the tests we carried out and the obtained results. I.1. Voice traffic characteristics Voice traffic imposes stringent QoS requirement. Thus, the support of voice traffic in MPLS networks is challenging. Indeed, traditional data transmission does not support any loss under penalties for the interpretation and the use of these data by the receiving equipment, but it supports on the other hand an important delay in term of routing time. In fact, the expected behaviour of voice is exactly opposite: 1% or 2% of data loss of voice are not too much awkward for the quality of the service, but on the other hand 100 ms as a frequent variation on the time of transit is catastrophic and makes the service unusable for the voice calls [8]. Voice data is carried by the Real-time Transport Protocol (RTP) [2] which defines a standardized packet format for delivering audio and video over the Internet. RTP does not have a standard Transmission Control Protocol (TCP) or User Datagram Protocol (UDP) [2] port on which it communicates but as voice data is very time-sensitive, in this case it relies on UDP to take benefit from its lower latency providing both sequencing information so that packets are delivered in the correct order, and timing information so that issues such as network delay can be accounted and compensated for. Before sending voice traffic, the data has to be compressed according to a given audio file format by means of a codec (coder-decoder) to reduce the storage space and the bandwidth required for the transmission of the audio file. Many voice codecs are used in IP telephony with different bit rates and complexities. The standard payload of a voice packet contains a sample of 20 ms of voice which is usually in the vicinity of 20 bytes (with the G.729 codec and can reach 40-60 bytes with G.726 and 160-byte payload for G.711) [8]. IMCNE thesis 20
Chapter 3: Experimental activity Figure 12. A standard voice packet The Figure 12 shows that the combined headers of RTP, UDP, and IP of a standard voice packet add up to a total of 40 bytes, meaning that overhead accounts for approximately 66% of the size of a packet with a 20-byte voice payload. When MPLS labels are added, the voice packet header changes to voice/rtp/udp/ip/mpls-labels, and becomes 44 bytes. The Table 1 below summarizes the packetization delay according to some codecs. It shows that IP and MPLS headers are constant regardless to the codec used (respectively of 40 and 44 bytes) and that the MPLS packets transmit rate is always higher than IP packets transmit rate [8]. Codec PCM,G.711 ADPCM G.726 CS-ACELP, G.729 MP-MLQ, G.723.1 MP-ACELP,G.723.1 Codec Bandwidth (kbps) Payload Size (Bytes) Packetization Delay (ms) IP Header Size (Bytes) MPLS Header Size (Bytes) Transmit Rate (pps) IP packets Transmit rate (kbps) MPLS packets Transmit rate (kbps) 64 160 20 40 44 50 80 81.6 32 80 20 40 44 50 48 49.6 8 20 20 40 44 50 24 25.6 6.3 24 24 40 44 32.8125 21.334 22.667 5.3 20 30 40 44 33.125 16 17.067 Table 1. Packetization delay IMCNE thesis 21
Chapter 3: Experimental activity Notes: Voice packets per second (pps) = codec bit rate / voice payload size IP packet size = IP Header + payload MPLS packet size = MPLS Header + payload Transmit Rate (bps) = Packet size (bits) / Packetization delay (sec) I.2. QoS requirement for voice traffic QoS is a major issue for voice traffic transmission which consists in how to guarantee that packet traffic for voice will not be delayed or dropped due to interferences with other lower priority traffics. To avoid this degradation of the traffic, some parameters have to be considered: Latency Latency is the delay needed for packet delivery. Large delays are burdensome and can cause bad echoes. ITU-T G.114 recommends a maximum of a 150 ms one-way latency. Since this includes the entire voice path, part of which may be on the public Internet, the network should have transit latencies of considerably less than 150 ms. Jitter Jitter consists in the variations in delay of packet delivery. Jitter causes strange sound effects, but can be handled to some degree with "jitter buffers" included in most VoIP endpoint devices (e.g. VoIP phones). Jitter buffers (also known as playout buffers) are used to change asynchronous packet arrivals into a synchronous stream by turning variable network delays into constant delays at the destination end systems. The role of the jitter buffer is to trade off between delay and the probability of interrupted playout because of late packets. Packet loss The voice transmission is based on RTP protocol. The real-time constraints of the transmission delay make the retransmission of the lost packets useless: even retransmitted, a RTP datagram would arrive too much late to be useful to the reconstitution process of the voice. These data losses may due to the congestions on the network, which involve rejections of packets throughout the network, or to an excessive jitter which will cause rejections of packets in the jitter's buffers of the receiver. A regular but weak data loss is less awkward than the peaks of loss which are spaced but high. Indeed, human listening can be accustomed to an average but constant quality and on the other hand will not support sudden degradations of QoS. IMCNE thesis 22
Chapter 3: Experimental activity II. Experimental setup II.1. Testbed schema Figure 13. The testbed The experimental setup for this work is presented in the Figure 13 and consists in two physical M10 Juniper routers, used as edge routers. On this two physical routers are configured two virtual routers used as core routers. The two M10 routers are connected by three unidirectional Label Switched Paths: voice, network control and best-effort LSPs. Each LSP is used to transport one category of traffic. On each router (edge and core routers), queuing and scheduling mechanisms are implemented to handle voice and best-effort packets. II.2. Software To generate voice traffic, the software packeth was used. PackETH is a Linux GUI packet generator tool for Ethernet. It allows to create and send any possible packet or sequence of packets on the Ethernet. In our case, RTP packets are generated to simulate the voice traffic (the payload of voice packets can be configured with different options to send waves of any frequency and with different codecs). In addition to voice traffic, best-effort traffic is generated by a router test to emphasize the differentiation in treatment between the two kinds of traffic. IMCNE thesis 23
Chapter 3: Experimental activity An analyzer of protocols, Wireshark, allowing to examine the data transiting through the network is used to capture the packets and give some statistics through a graphical interface. II.3 Tests The software packeth is used to generate RTP packets. As the goal of this thesis is to study the Quality of Service techniques in IP/MLPS networks, only voice traffic in the core network will be studied and the step of call set-up will not be considered in the tests. Figure 14 shows how to generate the packets. As a first step, the software creates a sample of an IP packet by specifying source and destination IP addresses of both concerned hosts. Then, the transport protocol has to be set: in the case of the study, the UDP protocol is used and so the ports and payload are configured. Figure14. IP packet configuration The object of the tests is voice traffic, so the payload of the UDP datagram will contain an RTP packet. Figure 15 shows the parameters that can be configured by packeth in order to generate RTP packets such as the version, the codec, and the RTP payload. IMCNE thesis 24
Chapter 3: Experimental activity Figure 15. RTP packet configuration After elaborating the sample, the number of packets needed is set and the sending is now possible. As the links used have a capacity of 100M and that while configuring the schedulers in the several nodes of the network the transmit-rate of voice traffic was set at 90 percent, 3 tests will be carried out: sending 50M, 90M and 100M of traffic. In order to analyse the traffic sent, the software wireshark is used. Wireshark allows, as showed in Figure 16 to capture the incoming traffic on a specified interface. IMCNE thesis 25
Chapter 3: Experimental activity Figure 16. Traffic capture Figure 17 indicates how incoming traffic is organized by wireshark. Each received packet is listed according to its reception time, source address, and protocol. In the study, only RTP packets will be taken into consideration. Figure 17. Packets listing IMCNE thesis 26
Chapter 3: Experimental activity In order to create congestion in the network and not to send only voice traffic, best-effort traffic is also sent at the same time on the network using a Router Test. II.4 Router configuration Classification allows to divide traffic into classes and offer various levels of throughput and packet loss. It is a way of managing traffic in a network by grouping similar types of traffic (for example, e-mail, streaming video, voice, large document file transfer) together and treating each type as a class with its own level of service priority. In our case we will have 2 CoS: Voice and Data. The CoS components are summarized in the following figure: Figure 18. CoS components On the routing platform, 3 Forwarding Classes (FC) will be configured for transmitting packets (expedited-forwarding, best-effort and network control), define which packets are placed into each output queue and schedule the transmission service level for each queue. To configure the voice traffic, the following steps are needed: Classification of the packet: associate incoming packets with a forwarding class and loss priority and, based on the associated forwarding class, assign packets to output queues. For that we will use Behavior aggregate (BA) or code point traffic classifiers which determine the forwarding class and the loss priority of each packet. BA classifiers allow to set the forwarding class and loss priority of a packet based on DiffServ code point (DSCP) bits. Configure a scheduler for each FC: the expedited-forwarding class has a strict high priority queue Mark the packets II.3.1. Pre-configuration Before starting to configure the routers, we need to access to them in the configuration mode using the appropriate login and password (Figure 19). IMCNE thesis 27
Chapter 3: Experimental activity Figure 19. Access to the router II.3.2. Configuration of the network interfaces The network testbed is composed of a set of interfaces, each one having an interface name represented by a physical part, a channel part (optional) and a logical part. The physical part which corresponds to a single physical connector has the following format: type-fpc/pic/port (with: type: identifies the network device, fpc: number of FPC card, pic: number of PIC on which the physical interface is located, port: a specific port on a PIC). The Figure 20 shows the configuration of some interfaces of the testbed. Figure 20. Interfaces configuration II.3.3. Routing protocols configuration To automatically forward MPLS traffic, the Open Shortest Path First (OSPF) need to be configured to advertise the forwarding adjacency to the other routers in the network and add the forwarding adjacency to the traffic engineering database (TED). OSPF is the only supported interior gateway protocol (IGP). The following figure describes the configuration of MPLS and OSPF protocols. IMCNE thesis 28
Chapter 3: Experimental activity II.3.4. Forwrding classes Figure 21. Routing protocols configuration The Forwarding Class (FC) plus the loss priority define the per-hop behaviour which specifies the policy and priority applied to a packet when traversing a hop (such as a router) in a DiffServ network. Four categories of forwarding classes are supported: best effort, expedited forwarding, assured forwarding, and network control. To configure FCs we have to define them and then to assign them to the outgoing queues. Figure 22. Forwarding Classes configuration IMCNE thesis 29
Chapter 3: Experimental activity II.3.5. Label Switched Path configuration Three Label Switched Paths are configured in the network each, as described in the Table 2 below, is associated to a Forwarding Class. As we will not take into consideration the assured-forwarding class, only the other three are described. Class-Name Network Control Expedited Forwarding (voice) Best Effort LSP topap-nc topap-voice topap-be Table 2. LSPs characteristics Figure 23 shows how each LSP is associated, in the outgoing interface of the ingress edge router, to a Forwarding-Class by giving the address of the destination edge router. Figure 23. Configuration of LSPs II.3.6. The classification of packets The multifield classifier sets the Forwarding Class of incoming packets which are then assigned to an outbound transmission queue. The scheduler receives the forwarding class settings, and queues the outgoing packet based on those settings. The Figure 24 shows how the classifier is applied to the traffic generator interface (using its IP address) so that the packets can be filtered according to their source address. IMCNE thesis 30
Chapter 3: Experimental activity Figure 24. Configuration of the multi-field classifier The multi-field classifier is only configured in the edge router. For the core routers, we use Behavior aggregate (BA) or code point traffic classifiers which determine each packet s forwarding class and loss priority. As showed in Figure 25 BA classifiers allow to set the forwarding class and loss priority of a packet based on DiffServ code point (DSCP) bits. Figure 25. Configuration of a BA classifier II.3.7. Scheduler configuration Juniper routers support Weighted Round Robin (WRR) scheduling in order to achieve service differentiation. Each queue is assigned a certain weight indicating the amount of guaranteed capacity. WRR will serve the different queues according to these weights. The high priority packets are served before any low priority packets. As showed in the figure below, for each queue the following parameters are set: IMCNE thesis 31
Chapter 3: Experimental activity 'transmit-rate percent x' assigns x% of the port capacity to the queue: determines the actual traffic bandwidth. 'buffer size percent x' assigns x% of the total buffer to the queue: large queues may increase latency during congestion whether smaller queues may be more appropriate for delay sensitive traffic. 'queue priority' may take three values: low, high or strict-high: determines the order in which an output interface transmits traffic from the queues. JUNOS supports low, high, and Stricthigh priority. Figure 26. Schedulers configuration After setting the parameters, each scheduler has to be associated to a queue (a Forwarding Class). This mapping is configured and then binded to the related interfaces. II.3.8. Mark outgoing packets The marking of packets with a DSCP value is the last QoS action performed before the transmission of the packet. Juniper M-series routers can only mark packets at the output interface. Indeed, there are no markers at the input interface. IMCNE thesis 32
Chapter 3: Experimental activity Figure 27. Marking outgoing packets IMCNE thesis 33
Conclusion Conclusion The growth of multimedia applications over wide area networks has increased research interest in Quality of Service. Just increasing the amount of resources such as available bandwidth to avoid congestion is not enough to provide proper resource utilization and the setup of QoS parameters become necessary. Traffic Engineering is concerned with the performance optimization of operational networks. Its main objective is to reduce congestion hot spots and improve resource utilization through carefully managing the traffic distribution inside a network. MPLS associated with the DiffServ architecture allow the implementation of evolved TE mechanisms by providing the possibility of establishing source routed paths that are carrying traffic on a per-class basis This work is dedicated to the study of those mechanisms and their configuration. After an overview of the different QoS mechanisms supported in MPLS network, and as a case of study, the report considered the set-up of LSPs carrying voice traffic and the configuration of Quality of Service parameters allowing to handle this kind of specific traffic in case of adding other kinds of traffic (mainly best effort) in the network. Regarding the adopted methodology, the need for Quality of Service in IP/MPLS networks was first demonstrated and the concepts necessary to establish QoS in the network such as DiffServ-aware Traffic Engineering, Bandwidth Constraint models and QoS operations were then studied. As a second step, those mechanisms were configured over a testbed and voice traffic was taken as an example. This configuration was implemented in order to offer a treatment that goes more adequately with voice traffic requirements. There are still many works remaining in the progress of end-to-end QoS management for multiservice in IP networks. Those configurations can in fact be extended and refined to carry out all kinds of traffic, add more restrictions on QoS parameters and extend the configurations to a large network, composed of several and heterogeneous domains. IMCNE thesis 34
References References [1] I.Minei, J.Lucek, "MPLS-Enabled Applications. Emerging Developments and New Technologies ", John Wiley & Sons, Ltd, 2005. [2] W.Stallings, "High-Speed Networks and Internets: Performance and Quality of Service ", Prentice-Hall, Inc, 2002. [3] Paul P.White. "RSVP and Integrated Services in the Internet ", IEEE Communications Magazine, 1997. [4] J. Malcolm, J. Agogbua, M. O'Dell, J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999 [5] J. Ash, "Max Allocation with Reservation Bandwidth Constraints", RFC 4126, June 2005 [6]R.Braden, L.Zhang, S.Berson, S.Herzog, "Resource ReSerVation Protocol (RSVP)", RFC 2205, September 1997 [7] S.Capshaw, "Applying JUNOS Class-of-service Features ", Juniper Networks, Inc, 2002. [8] "Traffic Analysis for Voice over IP", CISCO document, 2001 [9] B.Enders, "Quality of Service for Voice over IP ", Chesapeake NetCraftsmen, 2003. [10] http://packeth.sourceforge.net/ [11] http://www.wireshark.org/ IMCNE thesis 35
Glossary Glossary AF: Assured Forwarding BC: Bandwidth Constraint BE: Best Effort CoS: Class of Service CT: Class Type DSCP: DiffServ Code Point EF: Expedited Forwarding EXP bit: Multiprotcol Label Switching Experimental bit FC: Forwarding Class IETF: Internet Engineering Task Force IP: Internet Protocol ITU-T: International Telecommunication Union - Telecommunication Standardization Bureau LSP: Label Switched Path LSR: Label Switched Router MAM: Maximum Allocation Model MAR: Maximum Allocation with Reservation Model MPLS: Multi Protocol Label Switching NC: Network Control PDA: Personal Digital Assistant PHB: per-hop behaviour QoS: Quality of Service RAT: Robust Audio Tool RDM: Russian Dolls Model RSVP: ReSource reservation Protocol RTP: Real-time Transport Protocol TCP: Transmission Control Protocol TE: Traffic Engineering VoIP: Voice over IP UDP: User Datagram Protocol IMCNE thesis 36