This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the ICC 2008 proceedings.
Providing Guaranteed Packet Loss Probability Service in IP/MPLS-based Networks Dongli Zhang
Dan Ionescu
School of Information Technology and Engineering University of Ottawa Ottawa, Canada Email:
[email protected]
School of Information Technology and Engineering University of Ottawa Ottawa, Canada Email:
[email protected]
Abstract—Differentiated Services (DiffServ) define the perhop-behavior (PHB) to enable scalable network designs with QoS support for multiple classes. MPLS Traffic Engineering (MPLS TE) enables resource reservation, fault-tolerance, and optimization of network resources. From the implementation point of view, the QoS is provided on the forwarding plane while the reservation and admission control happen on the control plane. There is no communication between the two modules to guarantee the bandwidth for the end to end tunnels. Furthermore, the video traffic has a variable-bit-rate (VBR), so the effective bandwidth is required for satisfying the real QoS. This paper will propose a novel framework to provide an integrated QoS provisioning, where packet loss probability is guaranteed for the video traffic. The design and implementation prototype is based on Hyperchip PBR 1280 core router system.
I. I NTRODUCTION In the recent years, there has been a trend towards network convergence where services and applications communicate over the IP backbone network. Such core network is expected to aggregate heterogeneous traffic, for instance, data, real-time voice and video traffic. When diverse traffic operates under the same best-effort network, they tend to react unfavorable together. Provision of QoS is a key element in designing the next generation network. The Internet Engineering Task Force (IETF) has proposed many service models and mechanisms to meet the demand for QoS shown in Fig. 1. Integrated Service (IntServ), Differentiated Services (DiffServ) [1] and the latest MPLS DiffServ and Traffic Engineering. IntServ, along with the Resource Reservation Protocol (RSVP), can provide end-to-end service guarantees in connectionless IP networks. The main problem with the IntServ architecture is the scalability issue. In the control plane, perflow information is kept. In the data forwarding plane, perflow classification, per-flow buffer management and per-flow scheduling are required, which places a huge storage and processing overhead on the routers. The Differentiated Services architecture is designed to provide differing levels of QoS to different traffic flows. By marking the DiffServ fields of packets and handling them differently, several differentiated service classes are supported. 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.
The classification, marking and policing operations are only needed at the boundary of the networks. However, to provide the end-to-end service, the provider must maintain and synchronize lots of QoS configurations for each router in the network. Furthermore, traffic can only be differentiated into a limited number of classes. The same class of traffic from different clients has to be integrated together, where they will interact and no guarantees for the individual client. In some failure scenarios, if the traffic follows a path with inadequate resources to meet performance characteristics such as jitter or latency requirements, the Service Level Agreements (SLAs) cannot be met. In the meantime, Multiprotocol Label Switching (MPLS) [2] integrates a label-swapping framework with network layer routing. It provides an efficient tunneling mechanism for the connectionless IP network. Currently, MPLS is supported by the most of the vendors. MPLS traffic engineering (MPLSTE) [3] sets up label-switched-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. MPLS DiffServTE [4] makes MPLS-TE aware of Class of Service (CoS), allowing resource reservation with CoS granularity and providing the fault-tolerance properties of MPLS at a per-CoS level. The Diffser-aware TE model determines the available bandwidth for each Class Type (CT) at each priority level. DiffServ provides the correct scheduling behavior for each type of traffic. The combination of DiffServ and per-CT traffic engineering ensures strict service guarantees. Unfortunately, in the current network, the QoS module in the data-forwarding plane is not aware of the dynamically created TE tunnel, so that QoS will not be guaranteed on each router even though it is permitted in the control plane. With the deployment of IPTV and Web 2.0, the video traffic will consume most of the bandwidth in the network. Video traffic usually has a variable bit rate and typically exhibits burstiness over multiple time scales. For example, burstiness of MPEG sources on a shorter time scale is due to I, B, and P frame structures, and burstiness on a longer time scale is due to considerable scene changes and luminance changes. At the ingress of the service provider’s network, all of the
978-1-4244-2075-9/08/$25.00 ©2008 IEEE
This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the ICC 2008 proceedings.
IP QoS Timeline MPLS Diff Serv & DS-TE MPLS Guaranteed Bandwidth
2002
Diff Serv
1998 Time
Simplicity & Scale Int Serv
1994
Strict IP QoS
Best Effort Original IP QoS None
Class Based
Flow Aggregated
Per-flow
QOS States
Fig. 1.
QoS Model
Control Plane DiffServ TE Provider Edge Router Forwarding Plane Customer Edge Router
Provider Core Router QoS
Edge Link
Core Link
Fig. 2.
Core Link
Framework
and maintain. The TE module is required to run on each node of the whole network. TE module not only allows the configuration of a global pool for bandwidth accounting but also provides a restrictive subpool configuration for highpriority network traffic, such as voice and real-time video. Both the available bandwidth on the global pool and the available bandwidth in the sub pool are advertised by OSPF TE [7], thus ensuring that each router keeps track of the available bandwidth when admitting new LSPs. Standard DS-TE feature has now been defined in IETF with corresponding OSPF, ISIS and RSVP-TE extensions. There are several bandwidth constraints models (BCM) defined in IETF drafts that can be used with DS-TE, including the Russian Doll Model (RDM) and the Maximum Allocation Model (MAM). The IETF DS-TE standards also define support for up to 8 bandwidth pools. This part describes general functional specification for the implementation of IETF-compliant DSTE feature. After the bandwidth is allocated and tunnel is created, the TE module will communicate with the QoS module. The QoS module will create the policing policy for each admitted tunnel and mark the traffic into different class according to the SLA. The QoS module then apply the correspond policy to guarantee the bandwidth for each traffic class on the forwarding plane by programming the hardware resource such as the queue and bandwidth allocation. The followings are the required parameters sent by the DSTE module: Traffic class, priority, Minimal bandwidth and interface. B. Control Flow
video traffic can be aggregated into one class and get the same PHB in the core network. DiffServ-aware MPLS TE can provide end-to-end bandwidth guarantee for this type of class. Therefore, the effective bandwidth allocation is a key problem to provide this type of service. It must support the QoS, such as 10−7 packet loss probability, and on the other hand, it must efficiently utilize the network resources(i.e., network bandwidth) at the same time. This paper firstly proposes a framework for the integrated provisioning of DiffServ in the MPLS based network, where the guaranteed bandwidth is provisioned by combining the MPLS TE and QoS module. Then it extends the prior research [5], [6] and tries to provide packet loss probability guarantees for the video traffic on the previously build tunnels. The design and implementation prototype is based on Hyperchip PBR-1280 core router system. II. T HE I NTEGRATED P ROVISIONING OF Q O S The framework combines the MPLS TE with the QoS module in order to provide an integrated QoS provisioning. Features are categorized in two types: control-plane features and forwarding-plane features as shown in Fig. 2. A. Major Components In the control plane, TE control module is responsible for the per-class traffic bandwidth allocation, tunnel creation
In the tunnel setup process, the following steps provides a basic control flow scenario show in Fig. 3, where TE Control, OSPF, RSVP, QoS and ACL/Queue driver are the components for implementing the supposed services. 1) At the headend and mid-point routers, the user configures the the TE-classes (mapping between ClassType and Priority), and the bandwidth constraints on each link. On the headend router, the user configures the tunnel interfaces and its associated Class-Type and setup/hold preemption priorities. 2) The TE module on all routers floods the link bandwidth status in each TE-class to the IGP. In this paper, OSPF is used, which then floods it throughout the network. This will build TE topology database. 3) The TE-control headend finds the path for the tunnel (taking into account all relevant constraints/attributes such as its tail end, required bandwidth and TE-class) and signals tunnel via RSVP. 4) At each node, the TE control performs admission control for the TE tunnel being established in given TE-class. 5) RSVP signals tunnel path from node to node and identifies the Class-Type in Path Messages (using new CLASSTYPE object when the Class-Type is different to Class-Type 0) 6) At the tail end, the TE-control identifies the end of the tunnel and returns a Resv message in RSVP, but
This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the ICC 2008 proceedings.
Fig. 3.
Control Flow
Headend of the TE tunnel TE Control
OSPF
2 3
OSPF
2
QoS
ACL
6
RSVP
8
QoS
7
9
MPLS
TE Control 4
5
7 CLI
2
8
RSVP
1
Midpoint or Tailend of the TE tunnel
9
MPLS
Queue
ACL
Queue
MPLS TE Tunnel
CLASSTYPE object is not added in Resv. 7) At each node, the TE control programs the forwarding infrastructure with label bindings resulting from the point to point signaling RSVP-TE. The TE control also calls MPLS API to allocate local labels. 8) TE control will notify the QoS that the required bandwidth for the created tunnel. 9) QoS generate the correspond policy and apply it on the forwarding place by programming the hardware resource through the call to the drivers, such as ACL and queue. III. G UARANTEED PACKET L OSS P ROBABILITY The goal of provisioning packet loss probability guarantee is achieved by using dynamic bandwidth allocation and reservation. In the previous framework, the bandwidth of the tunnel is dynamicly adjusted based on the measurement. A. Packet Loss Probablity Estimation The previous estimators [8] assume that the VPN traffic can be modeled as a stochastic process and the packet loss probability is derived from the moment generating function of the process. The formulae are then simplified by adopting a Gaussian model to represent the VPN traffic. Aggregate traffic approximation is studied to reduce the computational complexity of the traffic estimation system, because in such an approach, the traffic is evaluated as an aggregate of the VPN sources. Only the loss for the aggregate is sought, so the calculation is simplified and the packet loss probability is given as follows: Ploss =
e
−2b(c−µ) σ2
2µ(1−µ) σ2
4π 2b(c−µ) σ2
(1)
where c is the maximum amount of traffic that the multiplexer can output over a period of length t, and b is the buffer size available at the multiplexer. µ is defined as the traffic mean, and σ 2 is the variance of the traffic process. After applying the logarithm and replacing the estimated values, the following estimator can be derived. 2b(c − µ ˆ) 2ˆ µ(1 − µ ˆ) log(e) − log( ) σ ˆ2 σ ˆ2 2(c − µ ˆ)b 1 − log(4π ) 2 σ ˆ2 B. Bandwidth Calculation ate = −
(2)
Then considering the left hand side to be known and c to be unknown, an exponential equation is generated that can be solved numerically. The calculated value of c can then be used to allocate the related bandwidth for the real-time video class. Consider that the equation unknown is the term 2b(c − µ ˆ) (3) σ ˆ2 and that the right hand side is obtained by the preset loss parameters. We rewrite the equation in x as x=
µ ˆ 1 (4) Ploss = −xlog(e) − log(4πx) − log(x ) 2 b Solving (7) in x gives an expression that involves the first branch of the Lamberts W function [10]. Although it is a transcendent function with no analytical form, it can be evaluated numerically. In our work we used the C code generated by Maple as a solution for the equation. Then: c=
σ ˆ2 x+µ ˆ 2b
(5)
This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the ICC 2008 proceedings.
ISIS
CPU & Memory
OSPF
RTM
iTM
MPLS
Traffic Engineering BGP
LAT IP
FIT
Control Card
LIB
eTM
FTN ILM
TCP/UDP
SWITCH FABRIC
Line Card 1
Line Card 2
iTM CPU
Mem
Mem IP FIT
iNP FIT
Data packet
CPU IP FIT
Control packet
FIT
iNP
eNP Interface Specific Chipset
eTM
iTM
eTM
eNP
FIT
Legend:
Control packet
Interface Specific Chipset
Data packet
Data flow Control messages Route update
Fig. 4.
The Architecture of Hyperchip Router
C. Tunnel Setup and Resource Reserve After the estimated bandwidth requirement is obtained, it is used to reserve the resources with RSVP protocol. The queueing mecahnism, such as Class-Based Weighted Fair Queueing (CBWFQ) can be configured to provide the bandwidth guarantee on each router. For CBWFQ, the weight specified for the class becomes the weight of each packet that meets the match criteria of the class. The packet is enqueueed in in the appropriate class queue. CBWFQ uses the weights assigned to the queued packets to ensure that the calss queue is serviced fairly. CBWFQ provides coarser granuarity and scalability. You do not need to maintain traffic classification on a flow basis. It allows to specify the exact amount of bandwidth to be allocated for a specific class of traffic. IV. P ROTOTYPE I MPLEMENTATION The project is implemented using the HeliOS routing protocol source code to be provided by Hyperchip, and is applied to the PBR-1280 core router platform developed by Hyperchip. HeliOS is a distributed, scalable and fault tolerant solution for almost all routing protocol modules destined to core routers. Source code development is done using the development environment available at Hyperchip based on PCs, and modules development is integrated to it using the current procedures put in place. A. Hardware Architecture of PBR 1280 The hardware architecture of the next generation routers is made of three types of cards illustrated in Fig. 4: Line cards: The line card provides multiple gigabit interfaces. The ingress Network Processor (iNP) is programmable with parallel processing capability. It does packet forwarding, classification and flow policing. The iNP contains a FIT
Fig. 5.
The Architecutre of MPLS TE Module
(Forwarding Information Table) that is used to determine the destination of data packets. The ingress Traffic Manager (iTM) forwards the packets from iNP to the switch fabric while maintaining traffic load balancing using traffic access control, buffer management and packet scheduling mechanisms. The egress Traffic Manager (eTM) receives packets from the switch fabric planes directly connected to its line card, performs packet re-ordering and controls congestion. The egress Network Processor (eNP) sends out the packets with per-egressport output scheduling mechanisms. Control cards: The control card or route processor is designed to run the main routing protocol modules (i.e., BGP, OSPF, ISIS and MPLS), RTM (Routing Table Manager) and CLI (Command Line Interface). Switch Fabric: The control and line cards are interconnected by a scalable switch fabric which is distributed into identical and independent switching planes. The switch fabric is made of so called matrix cards which provide data switching functions. Per-flow scheduling, path balancing and congestion management within the switch fabric are achieved by the Fabric Traffic Manager chipsets integrated on the matrix card. Each line card or control card has an ingress port and an egress port connecting to a matrix card. Each switching plane is made of the same number of matrix cards. B. MPLS TE Module In a MPLS network, packets are forwarded hop-by-hop on Label Switched Paths (LSP) based on fixed-length labels. The routing process is done only in edge routers (Label Edge Router - LER), then the packet is simply switched over transit routers (Label Switch Router - LSR); consequently, the forwarding speed is improved. Based on labels, MPLS provides flow management, traffic engineering and QoS functions. Basically, an MPLS architecture implemented in a router consists of two parts Fig. 5: data plane and control plane. The data plane forwards MPLS data packets based on information provided by the control plane. The control plane, on the other hand, is implemented at the software level and can easily be
This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the ICC 2008 proceedings.
Measured Packet Loss Ratio Router D
Router A
7
Router E Router G Router B
Router C
Fig. 6.
-log(Packet Loss Probability)
Router F 6
Tunnel1 Tunnel2
5 4 3 2 1
Testbed Design 0 1
3
5
7
9
11
13
15
17
19
Time Scale
reconfigured and upgraded. There is a Forwarding Information Table (FIT) on the data plane which contains information about the LSPs. The FIT is updated by the signaling protocols located on the control plane.
Fig. 7.
Data History for the Measured Packet Loss Ratio
V. E XPERIMENTAL D ESIGN AND N UMERIC R ESULT
VI. C ONCLUSION
The experimental testbed is designed as the Fig. 6. Two tunnels are setup, one is from the router A to Router F, and the other one is from router C to router G. There is also background best effort traffic from router B to router G. All of the traffic will be aggregated on the link between Router D and router E. The MPEG 2 video traffic flow is generated by transcoding the MPEG2 format digital data. The video traffic is then transmitted using RTP/RTCP protocol. In the scenario, five data samples are recorded with different types of video traffic. This traffic is transported on tunnel1. The preset packet loss probability is 0.5%. Each sample is composed of 500 points which is captured from a 120-minute real-time traffic. The packet loss probability and packet rate are listed in Table I. From the measured result, it can verify that final packet loss probability meets the preset target.
The combined use of the DiffServ and MPLS technologies is envisioned to provide guaranteed QoS for multimedia traffic in IP/MPLS networks. This paper proposed a framework for the integrated provisioning of DiffServ in the MPLS based network, where the guaranteed bandwidth is provisioned by combining the MPLS TE in the control plane and QoS module in the forwarding plane. Then it provided packet loss probability guarantees for the video traffic on the previously tunnels. The design and implementation prototype is based on Hyperchip core router system. The experimental results showed the different type of videos can get the same QoS from the end user’s point of view.
TABLE I S TATISTICS S YNOPSIS OF T RAFFIC F LOWS #
Video Name
Packet Rate (Mbps)
ACKNOWLEDGMENT The authors would like to thank Rick Snow, Marc Lanonue and Sebastien Cote from Hyperchip inc. for their supporting and suggestions. This work was also supported by Natural Sciences and Engineering Research Council of Canada.
Packet Loss Probability
R EFERENCES
0.437%
[1] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, and W. Weiss, “An Architecture for Differentiated Service,” RFC 2475 (Informational), Dec. 1998, updated by RFC 3260. [Online]. Available: http://www.ietf.org/rfc/rfc2475.txt [2] E. Rosen, A. Viswanathan, and R. Callon, “Multiprotocol Label Switching Architecture,” RFC 3031 (Proposed Standard), Jan. 2001. [Online]. Available: http://www.ietf.org/rfc/rfc3031.txt [3] D. Awduche, J. Malcolm, J. Agogbua, M. O’Dell, and J. McManus, “Requirements for Traffic Engineering Over MPLS,” RFC 2702 (Informational), Sep. 1999. [Online]. Available: http://www.ietf.org/rfc/rfc2702.txt [4] F. L. Faucheur and W. Lai, “Requirements for Support of Differentiated Services-aware MPLS Traffic Engineering,” RFC 3564 (Informational), Jul. 2003. [5] D. Zhang and D. Ionescu, “Recursive parameter estimation for the dynamic packet loss system,” in Globecom 2005, St. Louis, USA. [6] ——, “Robust and optimal control of packet loss probability,” in Globecom 2006, San Francisco, USA. [7] D. Katz, K. Kompella, and D. Yeung, “Traffic Engineering (TE) Extensions to OSPF Version 2,” RFC 3630 (Proposed Standard), Sep. 2003, updated by RFC 4203. [8] D. Zhang and D. Ionescu, “On packet loss estimation for virtual private networks services,” in ICCCN 2004, Chicago, IL, USA.
1
Mutanx
54.01
2
Star War
64.13
0.414%
3
MTV
44.13
0.372%
4
Nature
34.82
0.395%
5
Sports
45.76
0.348%
In order to show the varions of the different traffic classes, two tunnels with different packet loss probability guarantees are setup. The first one has a preset value of 10−6 and the second one has 10−3.5 . The measured packet loss ratio for both are plotted in Fig. 7, from which it can be verified tha the preset value is guaranteed. The preset probability is changed and the test is repeat. The analysis of the probability density function shows that the system can keep the actual loss close to the target loss in all cases. About 90% of the errors are in the region [-0.02, 0.04], which shows the effectiveness of the system.
