Supporting Differentiated Services with Per-Class Traffic Engineering in MPLS

Transcription

1 Supporting Differentiated Services with Per-Class Traffic Engineering in MPLS Melody Moh sjsu. edu Dept of Math. & Computer Science Belle Wei Dept of Electrical Engineering San Jose State University San Jose, CA Jane Huijing Zhu Dept of Math. & Computer Science Abstract - Differentiated services (DiffServ) and MPLS are two major building blocks for providing multi-class services over IP networks. The performance and efficiency of Diierv architecture can be enhanced with per-class traffic engineering. In this paper, we propose a new MPLS traffic engineering scheme. Based on a constraint-based routing modified from our previously proposed QoS routing algorithm, it enhances the original E-LSP with per-class traffic engineering and load balancing. Major components of the scheme including labeling, load balancing, and routing are described; its features are carefully analyzed against desired traffic engineering requirements. With detailed simulation, we evaluate and compare the proposed scheme with two other schemes: the original E-LSP and E-LSP with load balancing, for their support of EF, AF, and BE service classes. We found that, through better utilization of network resources, the proposed scheme is able to accommodate more QoS flows with desired requirements; at the same time it offers better delay and delay jitter for existing EF and AF classes, and improves the overall performance of BE class. We believe that the proposed scheme is an important step for providing scalable, multi-service solution in future IP networks. 1. INTRODUCTION In today s rapidly growing networking environment, more and more traffic are transported over networks where the lp protocol plays a key role. Existing IP networks offer flexibility and scalability; they however provides mainly best-effort services. The IETF has proposed many service models and mechanisms to meet the demand for Quality of Service (QoS); including integrated services (IntServ), RSVP, etc. Among them the differentiated service (DiffServ) and multi-protocol label switching (MPLS) proposals are most promising. Diff-Serv architecture achieves scalability by implementing complex classification and conditioning functions only at network boundary nodes, and by applying per-hop behaviors (PHB) to traffic aggregates that have been appropriately marked [7]. This feature makes Diff-Serv suitable to be used in network backbones. The services provided by the DiftServ architecture may be classified into three main categories: Expedited Forwarding (EF), Assured Forwarding (AF), and Best Effort (BE). MPLS is a technology that integrates label-switching forwarding paradigm with network layer routing [13, 151. In MPLS, packets are encapsulated with labels at ingress points; these labels are then used to forward the packets along label switched paths (LSPs). These LSPs can be explicitly routed along specific paths. The key purpose of trafftc engineering (TE) is efficient network usage. The explicit routing feature of MPLS allows routes to be set up for better use of network infrastructure. It has therefore been suggested that TE is one of the most significant initial applications of MPLS [2]. Explicit routes (LSPs) in MPLS can be computed by constraint-based routing [ 1, 5, 151. Constraint-based routing offers the opportunity to extend the information used to setup paths beyond what is available for the routing protocol. It considers not only network topology, but also requirements of the flow (or of the specific class type), resource availability of the links, and possibly other administrative policies; it therefore meets the major requirements of TE [2]. In a DiffServ architecture based on MPLS, constraint-based routing has been widely accepted for the computing of paths that best meet the QoS requirements. The performance and efficiency of DiffServ architecture achieved through providing QoS at the aggregated level is limited. It may be enhanced by implementing TE at a perclass level. By mapping a traffic trunk in a given class (or class type [3]) on a separate LSP, it allows traffic trunks to better utilize resources, and to follow paths that meet constraints specific to the given class [6]. In this paper, we propose a new TE scheme that enhances the existing E-LSP mechanism in MPLS. It distributes trafftc trunks of the same class type onto the same LSP, and thus have the similar strengths as the recently, independently proposed per-class TE, also referred to as Diff- Serv-aware Traffic Engineering (DS-TE) [6]. We use a constraint-based routing that is based on a QoS-based routing algorithm we previously developed [ 111. This is a continuation of our research in QoS and DiffServ-based protocols [ 10-12, BACKGROUND Due to page limitation, background information and related studies on MPLS [7, 131, DiffServ [4], traffic engineering [2, 3, 6, 8, 151, and constraint-based routing [l, 5, 151 are not included. Interested readers please refer to relevant publications. Per-class TE is also independently proposed by Le Faucheur, et. al. [6] in which they referred the scheme as DS-TE. They described several network scenarios that would * Supported in part by NSF (NCR ) and KDDI R&D Labs, Japan /01/$10.00 (C)

2 benefit from DS-TE, detailed requirements of implementation, and evaluation criteria. They, however, have not proposed any actual mechanisms. 3. PROPOSED SCHEME The proposed scheme enhances E-LSP with TE. Before describe the scheme, for clarity we describe E-LSP and L- LSP mechanisms proposed for providing DiffServ in MPLS [7, 131:. E-LSP - These LSPs transport multiple Ordered Aggregates, so that the EXP field of the MPLS Shim Header conveys to the label-switch router (LSR) the PHB to be applied to the packet (covering both information about the packet s scheduling treatment and its drop precedence).. L-LSP - These LSPs only transport a single Ordered Aggregate, so that the packet s scheduling treatment is inferred by the LSR exclusively from the packet s label value while the packet s drop precedence is conveyed in the EXP field of the MPLS Shim Header or in the encapsulating linklayer-specific selective drop mechanism (as in ATM, Frame Relay, 802.1, etc.). The E-LSP is simple; it carries up to eight behavior aggregates (BAs) on an LSP for a given Forward Equivalence Class (FEC). When more traffic needs to be accommodated, 3. Routing In order to guarantee QoS for the trafftc between each ingress and egress pair, we propose a simple constraint-based routing algorithm that is modified from an optimal QoS routing algorithm previously developed [lo]. Routing that takes delay and loss metrics directly into account is difficult computationally (and has been proven to be NP hard [lo]); it also requires information such as nodal load versus delay characteristics that are difficult to acquire [13]. Our previously proposed algorithm guarantees maximum bandwidth utilization with delay constraint. In the modified algorithm used in this paper, we consider the setting up of LSPs with delay constraint and bandwidth guarantees. Delay and bandwidth requirements for each path can be. extracted from the service level agreement (SLA). The high level description of our algorithm is given below: 2. Prunes the topology database of all links that don t have sufficient residuallreservable bandwidth or that is administratively forbidden (including excess delay) for the LSP; ii. Find the minimum-cost path towards the LSP s egress router (use propagation delay as the cost for each link); iii Zf several equal-cost paths remain, select the one with however, load sharing is needed. Using this scheme, packets the fewest number of hops; from certain traffic flow may go through different paths. If several equal-cost paths remain, apply the loadexperiencing different delays, thereby cause packet- rv balancing rule: choose the path that has the maximum reordering problem [14]. On the other hand, the L-LSP uses residual bandwidth; separate labels for the support of each PSC (PHB scheduling Steps i to iv are repeated for each LSP computation, class), it therefore introduces more signaling operations and * beginningfrom the highest service class; label management complexity. 3.1 Per-Class Traffic Engineering We propose a mechanism that enhances E-LSP with perclass TE, and improves the weakness of E-LSP and L-LSP discussed above. The main features of the proposed mechanism are as follows: 1. Labeling Labels are used to encode both the FEC and the service class (or class type) information. The class types may be Type 0 of BE, Type 1 of real-time traffic including EF, and Type 2 of low loss including AFl and AF2 [6]. They may be further subdivided into finer categories. The EXP field encodes scheduling treatment and drop precedence just as in E-LSP. 2. Load Balancing by Service Classes We propose to distribute traffic flows of different service classes to different LSPs. In this way, not only the QoS requirements can be better guaranteed, load balancing may also be achieved. This is similar to the per-class TE independently proposed [6]. In the case that multiple paths are needed for a certain FEC and service-class-category pair, traffic is distributed on these paths by hashing source and destination address to avoid packet reorder problem [ 141. Since this mechanism distributes traffic in a balanced way, and each LSP is associated with certain service class, it can carry more QoS trafftc flows (refer to the performance evaluation section for details) without involving micro-flow reordering problem as in E-LSP. In addition, this mechanism allows traffic trunks associated with the highest service class to choose the best LSPs, their QoS may therefore be best met. Note that the above mechanism is applicable to networks that provide up to eight service classes (or class types). It may also be integrated into L-LSP to provide more service classes. 3.2 Qualitative Analysis Awdache et al. [2] and Kodialam et al [9] suggested some requirements for TE and the underlying routing algorithms. In the following, we analyze the proposed TE scheme against the most relevant requirements:. Computational Requirement - The proposed routing algorithm makes use of the usual shortest-path and minimumhop computation. It also consults with the data base of link bandwidth, and finds the path with the maximum residual bandwidth, which are simple comparison operations. 355

3 Table 1. S ummary of Three Simulated Schemes Scheme No. DifIServ Simulation Strengths Weaknesses L? Mechanisms Cases Description 1. Original Diff-Serv without Case 1 Simple; one LSP accommodates (1) Inefficient use of network resources E-LSP traffic engineering up to eight classes of service. (2) Fewer QoS flows can be supported (Default mechanism) (3) BE service has poor throughput 2. E-LSP Diff-Set-v with Cases 2a, 1) Efficient use of network 1) Packet reorder problem with multi- packet-based 2b, and 2c resources 2) More computation and signaling path load multiple path 2) Best effort service has good operations than Scheme 1 balancing mechanism) performance 3) More network management complexity 3. E-LSP Diff-Serv with Cases 3a, 1) Efficient use of network 1) More computation and signaling with per- traffic engineering 3b, and 3c resources operations than Scheme 1 class traffic (Proposed 2) More QoS flows can be carried engineering mechanism) without degrading the existing traffic 3) Label maintenance is simpler than Scheme 2. Labeling and Signaling Overhead - The proposed mechanism uses both FEC and service class in the label, which is slightly more complicated than E-LSP, but simpler than L-LSP; similar argument can be held for signaling overhead. Please refer to [6] for a detailed discussion of protocol requirements for supporting per-class TE.. Routing without trafic splitting - Route splitting is avoided by distributing traffic flows based on their service classes. Even if splitting is unavoidable for load balancing, we suggest to use source-destination hashing to avoid packet reordering problem [ 141. n Good rerouting performance upon link failure - A dynamic version of the proposed routing algorithm has been presented [lo]; it has the same computational complexity but is much more efficient than re-computing routes from anew.. Information useful for aggregation - The proposed label contains both FEC and service class; it is extremely useful for routing and communication among multiple domains.. Re-optimization - The dynamic version of the proposed routing algorithm re-optimizes bandwidth utilization whenever node or link failure occurs [lo}.. Policy constraint - Step (i) of the routing algorithm is used to incorporate any policy constraints. 4. PERFORMANCE EVALUATION To evaluate the effectiveness of the proposed mechanism, in the section we simulate the mechanism along with two other methods. All three schemes are based on the E-LSP. Scheme 1 is the original E-LSP in which labels represent only the FEC. From ingress to egress, for certain FEC, there is only one LSP, and there is neither TE nor load balancing. In Scheme 2, multiple-path load sharing based on load ratio (but not on service class) is used; routing follows the proposed routing algorithm. Scheme 3 is the proposed mechanism. The three schemes are summarized in Table 1. (Their strengths and weaknesses are partly analyzed from simulation results.) 4.1 Simulation Topology The network topology used in our simulation is shown in Figure 1. Senders 1,2,3, and 4 send data to Receivers 1,2,3, and 4 respectively, and Sender 5 sends data to Receiver 1. R41, R42, and R45 are leaf routers in the source domain; they will classify and shape traffic based on traffic profiles. R4 and R16 are ingress routers, and R8 and R32 are egress routers. The ingress routers assign labels to the incoming packets and perform traffic conditioning. For EF (Expedited Forwarding) service, there is a token-bucket policer at the Token Bucket 356

4 incoming interface of the ingress. For AF (Assured Forwarding) service, we attach a policer instead of a remarker at the ingress s incoming interface to differentiate them from BE (Best Effort) packets for simulation purpose. sell&f4?i Figure 1. Network topology used in the simulation Table 3. Summary of simulation cases I Simulation Case Summary Case 1 1 Scheme 1 1 FlowSisBE Cases 2a, 1 Scheme Simulation Results The performance comparison among all seven cases is discussed in the following subsections. For each flow, we measure its delay, delay jitter, and throughput. l Flow 1 (EF Service) Figures 2, 3, and 4 show the delay, delay jitter, and throughput of Flow 1. The abrupt increase in both delay and delay jitter in time slots (l-2) and (3-4) is due to source traffic changing from CBR to VBR. We see that delay and throughput for Flow 1 in all seven cases are similar. Note that the proposed scheme (used in Cases 3a, 3b, and 3c) results in the smallest delay and delay jitter. With the proposed scheme, EF service has the highest priority in selecting LSP; it can therefore choose a feasible path with shortest propagation delay. The delay difference between the DiffServ scheme without TE (Case 1) and the proposed scheme (Cases 3a, 3b, and 3c) is mainly the propagation delay difference between LSP and LSP We also observe that the delay jitter in Cases 2a, 2b, and 2c are higher than in other cases, since packets from Flow 1 traverse on two paths of different propagation delay. Finally, the throughput remains the same in all schemes shows that EF traffic may be well supported (guaranteed peak-rate) in all the schemes. and 3c, respectively 4.2 Overview of Simulation Cases Traffic flows and their corresponding traffic profiles are listed in Table 2. Traffic QoS requirements of each sender is guaranteed by a token bucket. For example, Sender 1 is EF service, the Internet service provider (ISP) promises to carry up to the peak rate. The token bucket associated with Flow 1 is a peak-rate regulator in which the token rate is mbps - the peak rate allowed for Flow 1; and the bucket size is the maximum packet size. A fixed packet size of 400 bytes is used throughout the simulation; the bucket size for EF service is one packet to avoid delay jitter. In all simulation cases, the total simulation time is 4 seconds, which is divided into four periods evenly. For each flow, the sending rate and traffic model within each period may change, as indicated in the Traffic Model column. The simulation cases are designed to evaluate the effectiveness of the proposed scheme for various service classes, and are summarized in Table 3. The first four flows stay in the same service class for all cases, except for Flow 5 whose service class changes from case to case. In our simulation, we measure the throughput, delay and delay jitter every 0.25s. Time (second) Figure 2. Delay of Flow 1 Figure 3. Delay jitter of Flow 1 357

5 Throughput VI time In Flow1 2.BOE+07 Throughput VI time In Flow2 B.OOE+OB *.OOE Figure 4. Throughput of Flow 1 Figure 7. Throughput of Flow 2 l Flow 2 (AF Service) l Flow 3 ( BE Service) Figures 5, 6, and 7 show delay, delay jitter, and throughput for Flow 2. We see from Figure 5 that the delay curves fluctuated greatly. This is due to the characteristics of the VBR source traffic. Observed also that the delay curves for all simulation cases are almost identical. The proposed scheme allows more bandwidth for bursty packets from Flow 2, results in a decrease in delay jitter. Figures 5 and 6 also manifest that while facing more AF (Case 3b) or EF traffic (Case 3c), the proposed scheme still yields better delay jitter than Scheme 1 (Case 1). Throughput performance is the same for all seven cases since AF service guarantees bandwidth up to its average rate. 1.OE+m I Delay Y. tlm. in Flows Figure 8. Delay of Flow 3 Figures 8, 9, and 10 show that the BE traffic in Flow 3 performs differently under different schemes. Compared with Scheme 1, the proposed scheme reduces delay and delay jitter dramatically, and improves throughput. While facing more QoS flows (Cases 3b and 3c), the proposed scheme still yields higher throughput and lower delay and delay jitter than Schemes 1 and 2. Delay jlttor vs tlma In Flow Figure 5. Delay of Flow 2 Time Isecond Figure 9. Delay jitter of Flow 3 Throughput s time in Flows Figure 6. Delay jitter of Flow 2,.OOE+O0 l. I Time Isecond Figure 10. Throughput of Flow 3 358

6 l Flow 4 (BE Service) Figures 11, 12, and 13 show the performance of BE traffic in Flow 4. Comparing to DiffServ mechanism without traffic engineering (Case l), given same traffic scenario, our proposed mechanism (Case 3a) dramatically reduces delay and delay jitter, while improve throughput. While facing more AF flows (Case 3b), with the proposed mechanism the throughput, delay, and delay jitter of Flow 4 are very closed to those of Case 1. While facing more PRE service (Case 3c), since more traffic flows have been shifted from away from LSP , link 6-7 has more bandwidth available for Flow 4, its delay and delay jitter reduced and its throughput greatly improved. The ingress and egress pair of Flow 4 is ingress 16 and egress 32. The LSP taken by Flow 4 is , and it shares link 6-7 with LSP This link is the bottleneck for Flow 4 in all simulation cases, and available bandwidth for Flow 4 is impacted by the traffic on LSP Flow 5 (BE/AF/EF Services) The class of service for Flow 5 changes from case to case (referring to Tables 2 and 3); its performance is shown in Figures When Flow 5 is BE service (Cases 1,2a and 3a), its performance using different mechanisms is similar to Flow 3. When Flow 5 becomes AF service (Cases 2b and 3b), the BE traffic Flow 3 in Scheme 3 (the proposed scheme, shown in Case 3b) still has much better performance in terms of delay, delay jitter, and throughput than in Scheme 1. When Flow 5 becomes EF service (Cases 2c and 3c), using the proposed scheme it would be shifted to LSP 4-9-8; Flows 2,3 and 4 then have more bandwidth available, and their delay and delay jitter both decrease (as shown in Case 3c), and the throughput of Flow 3 is close to its sending rate. These demonstrate that the proposed mechanism can accommodate more QoS (EF and AF) traffic flows, and at the same time improves the existing BE service. Figure 11. Delay of Flow 4 Figure 14. Delay of Flow 5 I I Time (second) Figure 12. Delay jitter of Flow 4 Figure 15. Delay jitter of Flow 5,.OOE+08 - I Tlme (second) J Figure 13. Throughput of Flow 4 Figure 16. Throughput of Flow 5 The major simulation results are summarized in Table

7 Table 4. Summary of major simulation results Major Simulation Results Observed Case 1 BE has poor performance in terms of delay, delay jitter, and throughput. Case 2a 1) EF traffic has longer delay and delay jitter compared to Cases 1,3a, 3b, and 3c 2) AF has larger delay jitter than Cases 1, 3a, 3b, and 3c 3) BE has the best performance in Case 2a. Case 2b When Flow 5 is promoted to AF (Case 2b) or Case 2c EF (Case 2c), performance of the existing BE flow is worsen. Case 3a When Flow 5 is BE service: 1) EF service has shortest delay and delay jitter 2) AF has the smallest delay jitter 3) BE traffic has much better throughput, delay and delay jitter compared to Case 1 Case 3b When Flow 5 is promoted to be AF or EF: Case 3c 1) Existing AF traffic (Flow 2) still has decreased delay and delay than, and similar throughput as, Cases 1 and 3a 2) Existing BE traffic still has shorter delay, delay jitter, and larger throughput than Case 1 5. CONCLUSION We have proposed a per-class TE scheme that enhances E- LSP. The labeling, load balancing, and constraint-based routing components are described; the new scheme is carefully analyzed against TE requirements. Simulation results demonstrated that the new scheme effectively utilizes network resources; as a result, is able to accommodate more QoS flows while offering better performance to existing flows. The proposed scheme may be applied to either traffic flows per service class or traffic trunks per class type. In the first case, a fine-granularity labeling is needed; both signaling operation and management complexity would be increased. The second case, on the other hand, simplifies signaling operations and improves scalability. Another related issue in per-class TE is traffic protection. Each LSP requires a preestablished backup path or bypath to deal with link or router failures. This would involve more computations and traffic management. Given a fixed topology and source-destination matrix of traffic to be carried, when we divide the service categories and decide the label semantics, we are bound to balance the tradeoff between the effective use of the available bandwidth and the overhead of labeling, computation, and traffic protection. All these require further investigation. REFERENCES Aboul-Magd, et al., Constraint-Based LSP Setup using LDP, draft-ietf-mpls-cr-ldp+l.txt, July D. 0. Awduche, et al., Requirements for Traffic Engineering over MPLS, RFC 2702, Sept D. 0. Awduche, et al., A Framework for internet traffic engineering, draft-ietf-tewg-framework-04.txt, April S. Blake et al., An Architecture for Differentiated Services, RFC E. Crawley et al., A Framework for QoS-based Routing in the Internet, RFC 2386, August F. Le Faucheur, et al., Requirements for support of DiffServ-aware MPLS Traffic Engineering, draft-ietftewg-diff-te-reqts-00&t, Feb F. Le Faucheur, et al., MPLS Support of Differentiated Services, draft-ietf-mpls-diff-ext-09&t, April A. Ghanwani, et al., Traffic Engineering Standards in IP Networks Using MPLS, 1EEE Communications Magazine, December 1999, pp M. Kodialam, T. V. Lakshman, Minimum Interference Routing with Application to MPLS Traffic Engineering, Proc. INFOCOM, March W. M. Moh, L. Xiang, and X. Zhao, Differentiated service-based inter-domain multicast routing: enhancement of MBGP Proc. of ZCCCN, Las Vegas, NV, Oct W. M. Moh and B. Nguyen, An Optimal QoS- Guaranteed Multicast Routing Algorithm with Dynamic Membership Support, Proc. of IEEE ICC, pp , Vancouver, Canada, June An extended version has been accepted by Computer Communications, Spring W. M. Moh, L. Xiang, and X. Zhao, Extending BGMP for QoS-based inter-domain multicasting over the Internet, Proc. of ZEEE ICC, New Orleans, LA, June An extended version appeared in Optical Networks, Vol. 2, No. 2, March/April 2001, pp E. C. Rosen, et al., Multiprotocol Label Switching Architecture, Internet draft, draft-ietf-mpls-arch-06.txt, April, 1999 httn:// 14. C. Villamizar, MPLS Optimized Multipath (MPLS-- OMP), Internet draft, draft-ietf-mpls-omp-00, August httn://tictitious.org/mnls-omn/mnls-omntxt 15. X. Xiao, et al., Traffic Engineering with MPLS in the Internet, IEEE network, March/April 2000, pp J. Mao, W. Moh, and B. Wei, PQWRR Scheduling Algorithm in Supporting of DiffServ, Proc. of IEEE ICC, Helsinki, June