2012 IEEE Seventh International Conference on Networking, Architecture, and Storage

Optimizing Bandwidth by Employing MPLS AToM with QoS Support

Rashid Hassani
Department of Computer Science University of Rostock Rostock, Germany rashid.hassani@uni-rostock.de

Amirreza Fazely, Peter Luksch

Department of Computer Science University of Rostock Rostock, Germany amirreza.fazelyhamedani@uni-rostock.de peter.luksch@uni-rostock.de

AbstractMPLS is a growing highly scalable mechanism for the delivery of Internet services in today's high performance telecommunication networks. MPLS AToM (so called MPLS pseudowire) provides efficient bandwidth utilization between routers of network service providers for transporting Layer 2 packets over a single, integrated, MPLS VPN enabled Cloud. In this paper we propose a solution which provides feasible end-to-end QoS (Quality of Service) guarantees offered to DSL subscribers of an ISP. We will conclude that efficient bandwidth based on QoS parameters can be achieved by employing AToM and DiffServ combination rather than VPDN to transport layer 2 PPPoE traffic. Our results reveal that AToM and DiffServ can be combined to provide a feasible end-to-end QoS. Keywords-MPLS; VPDN; AToM; QoS; DiffServ.

I.

INTRODUCTION

The rapid growth of Internet is creating a demand for delivery of new capabilities and Internet services in IP-based networks. Virtual Private Network (VPN) is a foundation technology to transform Internet into a secure global network. Using VPNs, large scale-connectivity can be established between sites across a shared infrastructure. Virtual Private Dial-up Network (VPDN) is a VPN network to make point-to-point connection using layer 2 tunnel technology[1]. VPDN uses a shared infrastructure (e.g., Internet) to extend remote access across an ISP network to a private network. Multiprotocol Label Switching (MPLS) is a label-based technology which creates end-to-end connection using any transport protocol[5]. MPLS improves scalability in the network in comparison with enhancement solutions proposed to VPDN. Recently there has been an increasing market demand for ISPs to provide innovated applications on top of their VPN transport networks. To achieve this goal, Internet service providers looked for a solution in such a way that they would like to protect their existing infrastructures as well as providing different types of connection without need for separate networks with different network management environments. This led to the introduction of AToM which addresses this market requirement. Any Transport over MPLS (AToM) is an open standard-based architecture which provides a VPN across MPLS backbone and allows providers to carry Layer-2 and Layer-3 traffic across a common, single infrastructure without changing the existing service models.
978-0-7695-4722-0/12 $26.00 2012 IEEE DOI 10.1109/NAS.2012.18 104

By using this technology, the service providers can keep their MPLS backbone and the customers also retain their privacy. Quality of Service (QoS) classifies packet into different classes of traffic. In this way, the proper resources will be allocated to specific traffic based on different criteria. DiffServ is a widely used networking architecture mechanism for traffic management and provides QoS on modern IP networks. For an IP packet, the DSCP field specifies the QoS. Therefore in case of MPLS network, the IP Precedence bits are copied into the MPLS Experimental bits (EXP) at the edge of the network. AToM and DiffServ share some common characteristics. E.g., both models do aggregation of traffic at the edge and processing of the traffic only at the core. AToM facilitates great control over the way when DiffServ offers services such as offering services within well-defined QoS parameters by the operators[2]. In this paper, we propose a solution to provide costeffective and feasible end-to-end QoS using dynamic traffic differentiation without changing the existing service model. In Section II, the former topology of Internet service provider will be presented. Section III describes the detailed implementation of MPLS AToM as a new topology in combination with DiffServ mechanism to provide a feasible end-to-end QoS. Section IV and V present experimental results and conclusion respectively. II. PROBLEM STATEMENT AND PROPOSSED SOLUTION

The Point-to-Point Protocol over Ethernet (PPPoE) is widely used network protocol in DSL networks. It encapsulates layer-2 PPP frames inside Ethernet frames. In our scenario we considered a DSL topology provided by an ISP for provinces, each containing different cities. Each city in province has one Central transit Exchange so called CX and some Local Exchange so called LXs in Public Switching Telephone Network. Each LX covers a particular zone in the city to provide DSL service in that area. ISP installs its DSL equipment such as DSLAM (Digital Subscriber Line Access Multiplexer) and router LAC (L2TP Access Concentrator) in the LXs and consequently some equipment in the CX such as BRAS (Broadband Remote Access Server) router to handle aggregated traffic (voice and data) of all LXs and routes them to its core network in to the city or to Internet. In this topology, users commonly begin a point to point PPPoE session and lead all their leaving traffic

over this session. After the layer-2 PPPoE sessions are ended in BRAS, layer-3 traffic is routed toward the Internet. Here (in former topology), VPDN protocol was used to transport PPPoE traffic from a router LAC to LNS (L2TP Network Server). It should be noted that, in this traditional topology in which the VPDN tunnel is used, PPPoE traffic is being transferred over a distinct VPDN tunnel whereas the other traffic for the same LX passes through the GRE Tunnel[3], therefore provisioning QoS in one interface is not feasible. Figure 1 shows the former topology diagram.

Figure 1. Old topology diagram (two distinct tunnels)

As tested in our LAB, according to the former topology for connectivity between CX and LX, the bandwidth differentiation for the LX is not feasible. We have to determine the best way to enable QoS on the BRAS router. Therefore, this paper proposes a new solution to enable QoS on CXs with the purpose of giving priority to ISP network management applications (NMS). As a result, QoS mechanism will be provisioned on the GRE tunnel interface and the traffic will be differentiated by QoS dynamically. Therefore all traffic will pass through a single pipe without changing the existing service model. III. MPLS ATOM WITH QOS SUPPORT OVER GRE TUNNEL

In this paper, PPPoE traffic is sometimes referred as users layer-2 traffic. PPPoE frames are handled between layer-2 and layer-3 so that network IP protocol is not applied on transporting PPPoE traffic from user to BRAS, because there is no need for routing in a point to point link. But from BRAS over, the traffic should be routed (e.g., to Internet Cloud) so the PPPoE traffic will be turned into layer-3 (IP) traffic. In order to apply feasible QoS on the MPLS Cloud (MC), the traffic of each LX needs to be differentiated dynamically in the CX. The main objective of setting all these technologies and techniques together is to provide a way to transfer all traffic of one LX over one link. Therefore, the former VPDN tunnels could be replaced by AToM circuits to transfer PPPoE traffic of the LX to CX and vice versa over the MC using GRE as an encapsulation tunnel. A. Scenario The consideration in our scenario is as follows: providers want to carry Layer-2 and Layer-3 traffic across a common, single infrastructure without changing the existing service model. Therefore the total traffic of each LX passes through

a GRE tunnel which was used in former topology. Under the test, the CX devices should be able to handle different levels of QoS for the whole traffic of each LX. Therefore, per session QoS and persistent shaping need to be activated in the BRAS router in advance. Furthermore to examine packet loss rate, an extra QoS policy should be applied on a selected traffic (e.g., management traffic) efficiently when MPLS Cloud (MC) link is congested. Careless of the LXs, the QoS mechanisms could be applied on different CX routers based on CXs network topology in different methods. One method is to configure it on the BRASs PPPoE enabled subinterface to prioritize the entire PPPoE traffic of a single LX so that the LX intranet link will never be congested. Other method is to configure QoS on the ingress interface which is cross-connected to the BRASs PPPoE enabled interface. The advantage of second method is that we do not need to apply the similar QoS mechanisms on the same interface to what is applied on the PPPoE enabled interface for per PPPoE session QoS for the whole LX pipe. The third method which is proposed in this scenario is to apply QoS on the tunnel interface for all traffic containing both PPPoE and management traffic pass through the same interface. Shaping also can be applied in different ways on the tunnel interface either by using explicit traffic shaping command or by using service-policy which is chosen in this paper. The scenario simulates LX-CX networks but instead of establishing VPDN tunnels for relaying PPPoE traffic to LNS (acts as BRAS), AToM circuits are used. For this purpose, first a GRE tunnel is established and LX routers form an LDP neighborhood with the CX over this tunnel. Later, the AToM link is configured on a distinct subinterface of the BRAS router which is cross connected to another interface. A distinct sub interface is configured on the cross-connected interfaces on BRAS for each LX. Therefore, the traffic of each LX is terminated on a designated sub-interface related to that LX. The topology diagram is shown on Figure 2.

Figure 2. New topology diagram (single tunnel)

B. Procedure Each LX-CX pair routers form a route adjacency and a GRE tunnel is established between them. Then the targeted MPLS LDP adjacency is established over the GRE tunnel. An AToM virtual-circuit (VC) is established between the customer side sub-interface on the LX and a sub-interface on the CX (See Figure 4 ).

105

According to the nature of the MPLS, virtual-circuit information is stored on the provider-edge routers and the core routers do not store any information of virtual-circuit. So the amount of forwarding information that the core routers have to store is minimal. As a result the AToM would be a scalable solution to create multiple VCs/VPNs. The PPPoE traffic leaves the PC and passes through a switch in LX. This traffic is tagged by relative dot1q value so that it could enter to the proper sub-interface on the LX router. The packets are encapsulated by GRE tunnel (inner label) in order to transit to the BRAS router. To enable routing of AToM packet, the xconnect command between sub-interfaces of LX1, LX2 and sub-interface of BRAS is configured. So, the PPPoE traffic is re-encapsulated in AToM tunnel (outer label). The AToM traffic is entered to the CX router and directed to an egress sub-interface where the AToM is de-capsulated to the original PPPoE traffic. In BRAS router, the GRE tunnel ends up on the FastEthernet interface that in real cases, this is connected to ISP intranet. The MPLS label is stripped out and the GRE packets are decapsulated. To allow PPPoE session termination on BRAS, RADIUS server is used to provide the required AVPs (Attribute Value Pairs). Therefore, the traffic produced in the PCs pass through the AToM link and reaches to the related subinterface in BRAS and carried to the other interface where PPPoE traffic is being terminated. As shown in the Figure 4, the connected PCs create a bunch of different traffic types such as PPPoE, TCP, UDP, FTP and ICMP to be moved between BRAS and LX so that the link of LX-CX is congested and the BRAS router is stressed. To validate that the QoS is conserved for a particular type of service, the ICMP protocol is assigned by a higher priority in order to monitor the ping performance on PCs. By considering the ISP ADSL network design, the PPPoE session that is established amongst user and BRAS is layer2 traffic. According to best performs of QoS over MPLS AToM, DiffServ not only reduces the flow state overhead, but also enhances the performance of AToM by reducing the number of labels to be managed. Here we implemented PWFQ (Priority Weighted Fair Queuing) as a flow aggregation model (DiffServ) to offer QoS mechanism for Per Session Queuing[4]. Per Session Queuing: By establishing a PPPoE connection, a session is created between BRAS and each user. In per session QoS policy defined on the BRAS, the total data transfer rate for each session is detected and compared it to assigned bandwidth. If these two values are equal, then BRAS considers the congestion is happened in that particular session.

Five different queues per each session start to assist traffic proficiently to the user according to defined PWFQ algorithm as show in Figure 3. queue 0 priority 0 weight 80 queue 1 priority 1 weight 80 queue 2 priority 2 weight 60 queue 3 priority 2 weight 60 queue 4 priority 3 weight 30
Figure 3. Five- per session Queues

These commands describe five queues for a session. Queue 0 has highest priority and is a strict priority queue so that in congestion time, the traffic in queue 0 will be served before other types of traffic. Queue 1 is also a strict priority queue and will use all the bandwidth after queue 0 gets empty. Queue 2 and 3 with equal priority number and finally queue 4 will get bandwidth according to the specified weight. In this scenario, we specified mapping parameters using 5-queues, so packets are located on each queue according to DSCP, IP Precedence, MPLS Experimental bits or 802.1p values. BRAS organizes a pre-classification for the traffic which enters to a specific session prior to execution of other policies. Pre-classification is achieved by a QoS policy that uses an access-list rule to match and allocate preferred packets on accurate classes. This access-list chooses the traffic on the basis of its situations and then places them on specified class. Furthermore, we defined the QoS policy which marks DSCP values on every IP packet to be matched by access-list. This QoS policy must be applied for each PPPoE session through its first establishment. To achieve this, we can use two techniques: The first is to apply policy for all the sessions connected to BRAS and second, which is used in our scenario, is to drive policies by Radius server. To avoid requirement to add new elements in AAA (Radius) server the policy can be applied by default for all the subscribers. At the existing ISP DSL network, BRAS applies two policies for each session based on conventional attributes from AAA server. One for downlink data and the other is for uplink data. These two policies tell BRAS about the amount of the bandwidth requirement to be allocated for that user. To make a test environment simple, QoS is applied only for downlink of user. So, queuing configurations will be added to downlink service policy. In TABLE I, you can see some service policies in old and new format (PWFQ). As you can see in this table, the number of queues and configuration of queues weight and priority have been changed to the new format. The new format provides congestion management for all queues defined by the policy as well. Congestion avoidance is used in each queue to drop packets randomly once the queue is going to be overflowed. According to our specification, in queue 0, ICMP traffic is forwarded alongside real time traffic.

106

TABLE I. Service policy in new (PWFQ) and old format Old format qos policy mypolicy pwfq rate maximum 1152 rate minimum 128 num-queues 1 queue 0 priority 0 weight 80 New format (PWFQ) qos policy mypolicy pwfq rate maximum 1152 rate minimum 128 num-queues 5 congestion-map CONGEST queue 0 priority 0 weight 80 queue 1 priority 1 weight 80 queue 2 priority 2 weight 60 queue 3 priority 2 weight 60 queue 4 priority 3 weight 30

The new format provides congestion management for all queues defined by the policy as well. Congestion avoidance is used in each queue to drop packets randomly once the queue is going to be overflowed. According to our specification, in queue 0, ICMP traffic is forwarded alongside real time traffic. In regular condition while queue 0 is not congested, then both ICMP and RTP are forwarded without being dropped at all. However each time the queue capacity reaches to a minim threshold of each flow, then BRAS starts to drop the packets randomly to avoid congestion in that queue. IV. EXPERIMENTAL RESULTS

average time is about 350 ms. The cause for such long delay is that the link from LX1 to CX is totally congested and on the other hand, the 350 kbps bandwidth is not really sufficient for the largely chosen ping datagram thus they are queued on the interfaces. By employing MPLS AToM tunnel interface, the ping diagram remains steady without any drops along the time and its delay average time is about 88 ms (improved approximately by 70 percent). The graphs in Figure 5 and Figure 6 show the percentages of packet loss on MPLS AToM and VPDN tunnels with QoS support respectively. By comparing these two graphs, we conclude that the average packet loss is reduced significantly by using MPLS AToM in which as a result the total bandwidth according to packet loss is optimized by 40 percent. V. CONCLUSION AND FUTURE WORK

In Figure 4, the test bed, traffic flows and pipe capacities among each node are shown. The scenario is planned such a way that after applying MPLS AToM, the ping traffic besides the PPPoE traffic in addition to all other traffic such as management(MGT), routing protocol information and so on pass through the LX-CX tunnel interface. PC2 and PC1 are straight connected to CX BRAS and LX1 router respectively. To simulate the actual situation and study per session QoS functionality, a PPPoE link is established and dummy traffic is generated up to the maximum acceptable rate for the subscriber. First, they start to exchange light traffic using a TCP/UDP traffic generator by creating numerous concurrent connections. To check the QoS performance, the QoS is applied on ICMP protocol and common pings are executed on these two PCs. Additionally, some Telnet sessions are established between PC1 and PC2 for stressing the link. Furthermore, PC1 and PC2 start to generate heavy traffic by interchanging huge amount of ICMP packets with each other. PC3 and PC4 as PPPoE users also exchange some dummy traffic (like Telnet) by each other. During the test while applying the QoS over heavy traffic, the pipes bandwidth of each LX are assigned to huge amounts such as 10 mbps or more. This leaded to a very high CPU load so that the router was not capable to accurately apply the QoS even when a fair flow of different types of traffic had been flooded to the router. This problem was solved by permitting interrupt context switching on ingress interface and those which were burden with traffic. Roughly 300 kbps ping traffic is created on both PC1 and PC2. According to the ping outcome of former topology (VPDN tunnel interface) while a 350 kbps bandwidth is assured for the ping traffic (MGT), the ping replies started to be dropped continuously and its delay

AToM offers many advantages to service providers. ISPs can promote to AToM to transfer all types of traffic over the MPLS backbone without any interruption in service to the customer. Sites in different cities can work together transparently over an MPLS network as though they are on a public Ethernet network. This is not the case for other layer2 solutions because they are limited in scalability[6]. Our test result demonstrates that by using MPLS AToM instead of VPDN, The ICMP packets are delivered to the destination with preserved QoS on point-to-point connectivity while the CPU load of BRAS remains stable and finally the bandwidth is improved by about 40 percent. The LLQ (Low Latency Queuing) as a recent scheduling QoS mechanism is also tested in the lab. The LLQ makes the delay time quite short but due to maximum rate made by LLQ in traffic delivery, the exceeding traffic will be dropped, that is indeed undesirable for management traffic (MGT). So LLQ is not recommended to be used for MGT QoS unless a short latency is desired. According to the many shared characteristics between AToM and DiffServ, AToM provides great control over implemented services by DiffServ technology. Therefore their combination provides feasible end-to-end QoS. AToM-based Traffic Engineering is an additional important improvement to DiffServ. As a future work, related try outs can be done to emphasize this improvement. REFERENCES
[1] [2] [3] [4] Tran Cong Hung, Le Quoc Cuong, Tran Thi Thuy Mai Layer 2 Tunneling Protocol (L2TP), RFC5641, 2009. Tran Cong Hung, Le Quoc Cuong, Tran Thi Thuy Mai A Study on Any Transport over MPLS, ISBN 978-89-5519-146-2, ICACT 2010. Y. Rekhter, R. Bonica, E. Rosen Generic Routing Encapsulation, RFC4797, January 2007. IP Services and Security Operations Guide. Available online at:http://www.frameip.com/forum/publication-de-piecejointe/redback/IP-Services-and-Security-Operations-Guide.pdf Rosen, E., Viswanathan, A., and R. Callon," Label Edge Router Forwarding", RFC 6178, March 2011. F. Palmieri "VPN scalability over high performance backbones Evaluating MPLS VPN against traditional approaches", ISCC03, Italy, July 2003.

[5] [6]

107

Figure 4. Sample network topology for proposed scenario

Figure 5. Packet loss rate in MPLS AToM tunnel with QoS support

Figure 6. Packet loss rate in VPDN tunnel with QoS support

108