Packet-switch mechanism based on QoS class mapping using flow label for overlay network

Packet-switch mechanism based on QoS class mapping using flow label for overlay network

The Journal of China Universities of Posts and Telecommunications July 2010, 17(Suppl.): 17–23 www.sciencedirect.com/science/journal/10058885 http://...

221KB Sizes 0 Downloads 3 Views

The Journal of China Universities of Posts and Telecommunications July 2010, 17(Suppl.): 17–23 www.sciencedirect.com/science/journal/10058885

http://www.jcupt.com

Packet-switch mechanism based on QoS class mapping using flow label for overlay network HUANG Xiao-hong1 (), HE Zheng1, MA Yan1,2, SUN Qiong1 1. Institute of Networking Technology, Beijing University of Posts and Telecommunications, Beijing 100876, China 2. Beijing Key Laboratory of Intelligent Telecommunications, Beijing University of Posts and Telecommunications, Beijing 100876, China

Abstract

In the past few years, overlay networks have emerged as an alternative option for supporting value-added services such as fault tolerance, multicasting, and security. In this paper, we describe a quality of service (QoS) overlay network architecture for scalable, efficient and practical QoS support. In this architecture, we propose a flow label (FL)-based QoS class mapping method for QoS implementation, which can offer better scalability for applications and provide users with more refined QoS. Based on this method, a packet-switch mechanism using flow label is presented, depending on which, packets can be transmitted fast according to label, and more optimal paths can be chosen to guarantee the QoS requirement. Keywords

1

packet switch, QoS class mapping, flow label, overlay network

Introduction1

During the last decade, the Internet community has witnessed the proliferation of multimedia services such as voice over IP (VoIP), videoconference, live Internet television (TV)/radio and video on demand (VoD). A common feature for these services is the requirement for network paths that satisfies constraints on specific QoS parameters e.g. available bandwidth, maximum delay and delay jitter. The goal is to ensure that enough resources are available such that the end-user is satisfied with the quality of the received service. Currently, there are two different QoS architectures for Internet protocol (IP)-based networks: IntServ [1] and DiffServ [2]. IntServ defines a fine-grained system with per-flow management. DiffServ defines a course-grained system, where flows belonging to a specific QoS class are managed as a group. Neither architecture has been widely deployed to date due to reasons amply discussed in Refs. [3–5]. Several research organizations or projects have therefore attempted to provide some alternate methods to Received date: 30-04-2010 Corresponding author: HUANG Xiao-hong, E-mail: [email protected] DOI: 10.1016/S1005-8885(09)60613-0

resolve the problem, such as overlay-based QoS solutions on top of IP’s best-effort service [6–9] and QoS provisioning models or schemes using Internet protocol version 6 (IPv6) FLs [7–15]. The common overlay network architecture is shown in Fig. 1.

Fig. 1

Overlay network architecture

In this paper, a QoS overlay network architecture is proposed, which aims to provide scalable, efficient and practical QoS

18

The Journal of China Universities of Posts and Telecommunications

support. Meanwhile, an FL-based QoS class mapping method is proposed to provide better performance of QoS. Based on this method, a new packet-switch mechanism using FL is introduced, with which packets can be transmitted fast based on FL. And a more optimal path can be chosen as well. The rest of this paper is organized as follows. In Sect. 2, we take a closer look at the existing overlay-based QoS solutions and some related conception of IPv6 FLs. Sect. 3 presents an FL-based QoS class mapping method. Sect. 4 introduces FL definition and generation. The detailed design of the packet-switch mechanism using flow label is described in Sect. 5. The ideas for enhancements and possible next steps for discussion followed by the conclusion are presented in Sect. 6.

2 Related work In this section, we briefly review some related QoS overlay architectures and some related conception of IPv6 FL. Recently, overlay networks are proposed to support value-added services without making changes to network routers. End-user overlays rely on end systems to implement QoS features. For example, resilient overlay networks (RONs) are proposed to detect and recover from Internet path failures by actively monitoring the quality of overlay links and routing packets based on application-specific metrics [16]. The Spine architecture applies transmission control protocol (TCP)-like loss recovery and congestion control on each overlay link to reduce the latency and jitter of reliable connections [17]. Though highly flexible, end-user overlays usually cannot provide end-to-end QoS guarantees, since they normally cross many uncontrolled intermediate domains. Moreover, it is difficult to design an effective economic model for Internet service providers (ISPs) to adopt end-user overlays. To solve these problems, backbone overlays managed by third party providers are advocated. Some example proposals are service overlay network (SON) [18], OverQoS [19], QoS-aware routing in overlay network (QRON) [20], and QoS-assured composeable service infrastructure (QUEST) [21]. Unlike QoS-aware SON (QSON), which well combines the benefits of overlay networks and QoS-aware IP networks, these proposals either assume the guaranteed services from underlying networks, such as SON [18], QRON [20], and QUEST [21], or try to infer the statistical bandwidth and loss rate assurance along overlay links, e.g. OverQoS [19]. In IPv6, it has added two new fields that can be used to support QoS. These two fields are 8 bit class of service (CoS) and a 20 bit flow identification field. CoS field (terms of service (ToS) in IPv4) has been used to

2010

differentiate traffic flows. Another field, FL is used to distinguish between traffic flows. The advantage of FL for QoS is straightforward. First, it can achieve less lookup time (low end-to-end delay) since the router can use the combination of source address, destination address and FL in optimizing routing, rather than traditional 5-tuple one. Second, the classification process with FL can also get rid of layer violation problem, which means extracting information from upper layers for forwarding or processing packets purposes. Layer violation will cause problems when packets are encrypted or port numbers are hidden. Third, FL has the finest granularity of packet stream to differentiate QoS treatment. Finally, FL locates in the main header of IPv6; thus, it can be easily implemented in IPsec and virtual private network (VPN).

3

FL-based QoS class mapping method

In this section, we will discuss details about QoS class mapping problem, together with existing QoS class mapping solutions. And then, we will propose FL-based QoS class mapping (FL-QCM) method. 3.1 QoS class mapping problem QoS class usually defines a specific combination of bounds on performance parameters and objectives. Global standardization organizations i.e. International Telecommunication Union (ITU), Internet Engineering Task Force (IETF), the 3rd Generation Partnership Project (3GPP), Institute of Electrical and Electronics Engineers (IEEE) recommend using on the concept of QoS classes for the network and the application level. Since different QoS classes have been defined separately, when the end-to-end paths can concatenate different networks, QoS class mapping between different technologies is needed to support end-to-end QoS. In general, previous studies on QoS mapping between different networks technologies are categorized as mapping between parameters and mapping between classes in each different technology. With regard to mapping between parameters, QoS parameter mapping between asynchronous transfer mode (ATM) and IP is discussed in Ref. [22]. Ref. [23] deals with QoS parameter (loss and delay) mapping between DiffServ and IntServ. Ref. [24] presents parameter mapping between ATM and frame relay (FR). It shows us the transferred bound value of performance parameters according transport network

Supplement

HUANG Xiao-hong, et al. / Packet-switch mechanism based on QoS class mapping using…

technology. But it would be too complicated to implement on an interworking function. There are also many researches related with mapping between classes. Ref. [25] in 3GPP show Universal Mobile Telecommunications System (UMTS) QoS classes are mapped into IP QoS classes based on Y.1541 and DiffServ per hop behaviors (PHBs). Relationship between IP QoS classes and DiffServ PHBs is presented in Ref. [26] of International Telecommunication Union-Telecommunication Standardization (ITU-T). Ref. [27] presents two QoS classes mapping between DiffServ and 802.11e, between 802.11e and 802.1d, and between 802.1d and DiffServ. 3.2 FL-QCM method 3.2.1 Overall consideration FL-QCM is an opposite way to deal with QoS class

(a) Traditional class mapping method Fig. 2

19

mapping which can overcome the shortcomings mentioned above. In FL-QCM, each QoS class does not need to find its corresponding class in all different networks anymore; rather, it only needs to find its position in a uniform QoS spaceFL. In this way, not only do all existing networks with different QoS solutions can find their division in FL-space, but also newly emerging application or QoS class can find its position in this uniform space based on QoS performance requirement. Since the QoS performance requirement is always the same in heterogeneous networks, there will be no more QoS classes mapping for each two of these different networks individually. And its corresponding QoS class in different technologies can be selected due to FL-space to satisfy user’s demand. Fig. 2 depicts FL-QCM methods, with the comparison traditional methods. In FL-QCM, different applications and different QoS classes can also find their position in their uniform FL space.

(b) FL QoS space in network 1

(c) FL QoS space in network 2

QoS class division in a uniform FL space

3.2.2 Parameter selection On account of the layered architecture of network, QoS also has a layered structure. Internet levels of QoS are cataloged as Ref. [22]: physical-level, node-level, networklevel, end-to-end level, application-level, and user-level. Since FL is a network layer mechanism which aims to provide a uniform platform for the underlying networks, we choose FL to carry some specific meanings for transport level QoS parameter. The main objective to choose QoS parameter is as follows. 1) These parameters should represent general QoS requirement for different applications. 2) These parameters should reflect QoS class definition for existing networks and have the finest possible granularity. 3) The parameters should only occupy a limited length since the total length of FL is limited to 20 bit. To define transport layer QoS, different parameters can been taken into account, e.g. end-to-end delay, delay variation, packet loss rate, packet error ratio, transfer require rate,

transfer peak rate, bit rate, buffer requirement, bandwidth, etc. Since some of these parameters are used to define traffic profile in traffic description, the first three or four parameters are just enough to define QoS class, e.g. transfer delay, delay variation, packet loss rate and packet error rate, etc. Fig. 4 depicts a QoS class definition example in Ref. [26]. From this definition, we can see that packet loss rate and packet error rate are synchronous in application QoS requirement, and many other proposals [27–28] only use one of these two parameters, e.g. packet loss rate, etc. to weigh the packet correctness. Based on the above discussion and due to the limited length in FL, we use three parameters to define QoS requirement for different application traffic  delay, delay variation and loss rate. Since the length of FL-QoS is rather limited and each of these three parameters has a wide range for possible values, e.g. from 150 ms to 30 s for delay, etc., we should determine appropriate models for these three parameters and find the finest granularity that FL can denote. Table 1 concludes the preferred bounds of delay, delay variation and loss rate for current typical applications with the

20

The Journal of China Universities of Posts and Telecommunications

summation from [25–26,28–29]. Table 1

QoS requirement of different applications

Applications

Delay/s

Conversional voice Voice message(playback) Voice message(record) Video phone Video conference High quality streaming audio One way streaming Web-browsing Bulk data transfer Transaction service Still image Interactive games Telnet E-mail

0.1 1 2 0.15 0.005 10 0.15 2 15 2 15 0.2 0.2 2

Delay variation/ms 1 1 1 130 1 * * * * * * * * *

Loss rate 10–2–10–4 10–2–10–4 10–2–10–4 10–4 10–4 10–4 10–3–10–6 0 0 0 0 0 0 0

* not available

4 Proposed FL definition and generation

2010

Second, each Internet path between two nodes is called a virtual link. Generally speaking, an overlay link is usually composed of multiple physical links, which still have different path metrics, such as jitter, loss rate, delay and so on. However, overlay nodes are difficult to obtain that kind of information, access the network resource and select a path a second time, since they cannot directly understand the situation of routers. Therefore, in order to take advantage of the characteristic, we propose a method to mark the virtual path and physical path using flow label. In detail, we take 6 bit of FL as virtual link identification (VL ID) to indicate virtual path and 7 bit of FL as physical link (PL) ID to indicate physical path. According to the feature of overlay network, each VL is usually composed of multiple PL, just like virtual path identifier (VPI) and virtual channel identifier (VCI) in ATM. 4.2 FL related problem

4.1 Characteristic of overlay network 4.2.1 FL definition As shown in Fig. 3, first, overlay nodes, deployed at various locations on the Internet, form an application-layer overlay to cooperatively route packets for each other. Each node obtains the path metrics using a combination of active probing experiments and passive observations of on-going data transfers, monitors the quality of the Internet paths between it and the other nodes, and uses this information to intelligently select paths for packets. To discover the topology of the overlay network and obtain information about the topology, every overlay node exchanges information about a variety of quality metrics.

We propose this FL-based architecture to supply scalable, reliable and practical QoS support for overlay network. To realize the objective, a modified IPv6 FL specification is presented, depending on profound analysis, which can achieve efficient QoS provision with little modifications to existing architecture. The modified FL format is shown in Fig. 4.

Fig. 4

Fig. 3

An overlay link composed of multiple physical links

Modified FL format

According to the investigation of different QoS class definition of ITU-T [26], ATM [27], IntServ [28], DiffServ [30], multi-protocol label switching (MPLS) [31], 802.1d [27] and 802.11e [27], a table of QoS requirement for different applications is obtained, which concludes the preferred bounds of delay, DV and LR for current typical applications with the summation from Refs. [25–26,28]. Therefore, based on the table and due to the limited length of FL, DV has 2 bit, LR has 2 bit and delay has 3 bit, which represent the path metrics. The last 13 bit, called Flow ID, is divided into two parts to reflect routing information, among which, VL indicates virtual path and PL indicates physical path, utilized in packet-switch mechanism in Sect. 4. On the basis of Ref. [16],

Supplement

HUANG Xiao-hong, et al. / Packet-switch mechanism based on QoS class mapping using…

to facilitate aggressive path maintenance via probing without excessive bandwidth overhead, each overlay network is explicitly designed to be limited in size between two and fifty nodes. So, each overlay node has 49 virtual links at most. Furthermore, under the same VL value, PL value is corresponding to QoS value, and both of them have 7 bit. Therefore, the digit of VL and PL is enough to indicate all of the combination of virtual path and physical path.

process has done. By the way, one 2-tuple QoS-VL value can determine one PL value exclusively.

Fig. 6

FL-nexthop table

5 Packet-switch mechanism using FL for overlay network

4.2.2 FL generation The FL generator at each overlay node examines every incoming packet of each flow to provide different FLs depending on the overlay application layer routing, underlay network layer routing and different QoS requirements. First, overlay nodes, deployed at various locations on the Internet, using a combination of active probing experiments and passive observations to obtain the path metrics, form an application-layer overlay to cooperatively route packets for each other. When a packet of per flow enters the overlay, the overlay node uses the overlay application routing information to intelligently select path for packets, after that, the VL value is given, which is shown in Fig. 5(a). A virtual link, which is directed, is determined by one source-destination pair exclusively.

(a) VL generation

(b) QoS class generation

(c) PL generation Fig. 5

21

In this section, we will introduce the packet-switch mechanism in detail, the main goal of which is to provide desirable QoS-aware routing service to multimedia applications ensuring that the communication among the overlay nodes meet different applications’ QoS requirement. The QoS architecture is on the basis of two assumptions: 1) Overlay nodes, deployed at various locations on the Internet, using a combination of active probing experiments and passive observations to obtain the path metrics, form an application-layer overlay to cooperatively route packets for each other. In the process of FL generation, VL value can be determined by taking advantage of the application layer routing information. 2) All of the overlay nodes and intermediate routers maintain an FL-nexthop table in order to record FL value to retain state of per-flow. In addition, each overlay node needs to keep a VL-value table, as shown in Fig. 7, in order to make use of application layer routing information to get VL value corresponding to related destination overlay node. Each router can perform router-based network measurement to obtain link states of their direct connections. The QoS class part of FL has a global meaning among the whole network. On the other hand, the path information part of FL has a local meaning among all the overlay nodes, and routers cannot understand it. A virtual link, which is directed, is determined by one source-destination pair exclusively.

FL generation process

Second, different multimedia applications have different QoS requirements. FL generator makes use of FL-based QCM, which is presented in Sect. 3, to map the QoS requirement to the corresponding QoS class. After that, QoS value, including DV, LR and delay, is given, which is shown in Fig. 5(b). Third, each overlay node has an FL-nexthop table. According to VL value and QoS value that are already fixed, overlay node inquires the mapping table to find the suitable PL value, which is shown in Fig. 6. After that, FL generation

Fig. 7

VL-value table

5.1 Packet-switch process When a packet of per flow enters the overlay, according to the application layer routing, the destination overlay node is obtained, based on which, FL generator looks up the

22

The Journal of China Universities of Posts and Telecommunications

VL-value table to find the corresponding VL value. If the item exists, VL value, which is indicated by α, is given. If not, when the table is empty, α=αinitial=1; when the table is not empty, α=αmax+1. On the basis of QoS requirement, based on FL-QCM, the QoS class value is given. The situation of PL is almost the same with that of VL. FL generator looks up the FL-nexthop table, according to VL and QoS class. If the item exists, PL value, which is indicated by β, is given. If not, when the table is empty, β=βinitial=1; when the table is not empty, β=βmax+1. After that, the generation of FL has completed. And then, overlay node looks up the FL-nexthop table again, if FL value has already there, packet will be transmitted based on the corresponding next-hop address. If not, packet will be transmitted based on the normal network layer routing, and the corresponding address is going to be recorded in the next-hop field of FL-nexthop table.

Fig. 8

2010

When the packet arriving at intermediate routers, if the FL is already in the FL-nexthop table, the packet will be transmitted based on the corresponding next-hop address. If not, routers choose a suitable path that satisfies the QoS requirement, depending on the router-based network measurement results, and the corresponding next hop will be recorded in the next-hop field of FL-nexthop table. At the initial state, VL-value table and FL-nexthop table are empty, which is called routing discovery stage. The performance is as normal as that of conventional routing. However, when system has becoming stable, the packetswitch mechanism works, which is able to offer more desirable QoS-aware routing service to multimedia applications ensuring that the communication among the overlay nodes meet different applications’ QoS requirement. A complete working process of the packet-switch mechanism is presented in Fig. 8.

An illustrative example of packet-switch mechanism

5.2 Path-selection strategy It is supposed that, at the beginning, there is a high-quality flow that requires the highest level QoS class; therefore, a low-delay, low-loss-rate and large bandwidth path is established. Thus, all the following packets of different flows of different QoS requirement with the same VL value will just go through the same high quality path, without building their different links of corresponding QoS class. In order to avoid this situation, path-selection strategy is proposed: each QoS class is only compatible with its secondary class. For example, a path of class 1, which is the

highest level, is established, and the flow of class 2 with the same VL value is able to use that path, however, class 3 cannot.

6 Conclusions and future works In this paper, we propose a packet-switch mechanism based on FL-QoS class mapping method using FL for overlay network. FL-QCM solution can offer a uniform platform for heterogeneous networks with better scalability more refined QoS provision ability. The packet-switch mechanism is able to provide desirable QoS-aware routing service to multimedia applications ensuring that the communication among the overlay nodes meet different applications’ QoS requirement.

Supplement

HUANG Xiao-hong, et al. / Packet-switch mechanism based on QoS class mapping using…

When the network system becomes stable, the packets will be fast-switched according to the FL to obtain good performance, just like MPLS. Furthermore, during the packet-switch process, routers are capable to modify the path, without any FL changes, to adjust the QoS quality on the basis of the router-based network measurement results, without sending any informing messages. Therefore, the packet-switch mechanism based on FL-QoS class mapping method using FL is self- organizing. However, there are still a lot of work to do for development, enhancement and completeness. Our next possible steps include traffic balance problem and multipath problem. Acknowledgements This work was supported by the Fundamental Research Funds for the Central Universities (2009RC0501), the National Natural Science Foundation of China (60772111), the NSFC-KOSEF (60811140347), and the National Basic Research Program of China (2007CB310700, 2009CB320505).

Reference 1. Braden R, Clark D D, Shenker S. Integrated services in the Internet architecture: an overview. IETF RFC 1633. 1994 2. Blake S, Black D L, Carlson M A, et al. An architecture for differentiated services. IETF RFC 2475. 1998 3. Armitage G J. Revisiting IP QOS. ACM SIGCOMM Computer Communications Review, 2003, 33(5): 81–88 4. Bell G. Failure to thrive: QoS and the culture of operational networking. Proceedings of the Conference on Applications, Technologies, Architectures, and Protocols for Computer Communication (SIGCOMM’03), Aug 25–29, 2003, Karlsruhe, Germany. New York, NY, USA: ACM, 2003: 115–120 5. Burgsthaler L, Dolzer K, Hauser C, et al. Beyond technology: the missing pieces for QoS success. Proceedings of the Conference on Applications, Technologies, Architectures, and Protocols for Computer Communication (SIGCOMM’03), Aug 25–29, 2003, Karlsruhe, Germany. New York, NY, USA: ACM, 2003: 121–130 6. Andersen D G. Resilient overlay networks. Master’s thesis. Cambridge, MA, USA: Dept of Electrical Engineering and Computer Science, Massachusetts Institute of Technology, 2001 7. Subramanian L, Stoica I, Balakrishnan H,et al. OverQoS: an overlay based architecture for enhancing internet QoS. Proceedings of the 1st Conference on Symposium on Networked Systems Design and Implementation (NSDI’04), Mar 29–31, 2004, San Francisco, CA, USA. Berkeley, CA, USA: USENIX Association, 2004: 71–84 8. Li Z, Mohapatra P. QRON: QoS-aware routing in overlay networks. IEEE Journal on Selected Areas in Communications, 2004, 22(1): 29–40 9. Castro M, Jones M B, Kermarrec A M, et al. An evaluation of scalable application-level multicast built using peer-to-peer overlays. Proceedings of the IEEE 22nd Annual Joint Conference of the IEEE Computer and Communications Societies (INFOCOM’03): Vol 2, Mar 30–Apr 3, 2003, San Francisco, CA, USA. Piscataway, NJ, USA: IEEE, 2003: 1510–1520 10. Conta A, Rajahalme J. A model for diffserv use of the IPv6 flow label specification. IETF Internet Draft. 2001 11. Banerjee R, Malhotra S P, Mahaveer M. A modified specification for use of the IPv6 flow label for providing efficient quality of service using a hybrid approach. Internet Draft. 2002 12. Conta A, Rajahalme J. A model for diffserv use of the IPv6 flow label specification. IETF Internet Draft. 2001

23

13. Fgee E B, Kenney J D, Phillips W J, et al. Implementing an IPv6 QoS management scheme using flow label & class of service fields. Proceedings of the Canadian Conference on Electrical and Computer Engineering (CCECE’04): Vol 2, May 2–5, 2004, Niagara Falls, Canada. Piscataway, NJ, USA: IEEE, 2004: 1049–1052 14. Tang X, Tang J, Huang G B, et al. QoS provisioning using IPv6 flow label in the Internet. Proceedings of the 2003 Joint Conference of the 4th International Conference on Information, Communications and Signal Processing and 4th Pacific-Rim Conference on Multimedia (ICICS-PCM’03): Vol 2, Dec 15–18, 2003, Singapore. Piscataway, NJ, USA: IEEE, 2003: 1253–1257 15. Lee I H, Kim S J. A QoS improvement scheme for real-time traffic using IPv6 flow labels. Proceedings of the International Conference on Computational Science and Its Applications (ICCSA’04), May 14–17, 2004, Assisi, Italy. LNCS 3043. Berlin, Germany: Springer-Verlag, 2004: 278–285 16. Andersen D, Balakrishnan , Kaashoek M F, et al. Resilient overlay networks. Proceedings of the 18th ACM SIGOPS Symposium on Operating Systems Principles (SOSP’01), Oct 21–24, 2001, Banff, Canada. New York, NY, USA: ACM, 2001: 131–145 17. Amir Y, Danilov C. Reliable communication in overlay networks. Proceedings of the 37th International Conference on Dependable Systems and Networks (DSN’03), Jun 22–25, 2003, San Francisco, CA, USA. Los Alamitos, CA, USA: IEEE Computer Society, 2003: 511–520 18. Duan Z, Zhang Z L, Hou Y T. Service overlay networks: SLAs, QoS, and bandwidth provisioning. IEEE/ACM Transactions on Networking, 2003, 11(6):870-883 19. Subramanian L, Stoica I, Balakrishnan H,et al. Overqos: An overlay based architecture for enhancing internet qos. Proceedings of the 1st Conference on Symposium on Networked Systems Design and Implementation (NSDI’04), Mar 29–31, 2004, San Francisco, CA, USA. Berkeley, CA, USA: USENIX Association, 2004: 71–84 20. Li Z, Mohapatra P. QRON: QoS-aware routing in overlay networks. IEEE Journal on Selected Areas in Communications, 2004, 22(1): 29–40 21. Gu X H, Nahrstedt K, Chang R N, et al. Qos-assured service composition in managed service overlay networks. Proceedings of the 23rd International Conference on Distributed Computing Systems (ICDCS’03), Mar 19–22, 2003, Providence, Rhode Island, USA. Piscataway, NJ, USA: IEEE, 2003: 194–203 22. DaSilva L A. QoS mapping along the protocol stack: Discussion and preliminary results. Proceedings of the IEEE International Conference on Communications (ICC’00): Vol 2, Jun 18–22, 2000, New Orleans, LA, USA. Piscataway, NJ, USA: IEEE, 2000: 713–717 23. Chahed T, Hebuterne G, Fayet C. Mapping of loss and delay between intserv and diffserv. Proceedings of the 1st European Conference on Universal Multiservices Networks (ECUMN’00), Oct 2–4, 2000, Colmar, France. Piscataway, NJ, USA: IEEE, 2000: 48–55 24. Dixit S S, Kumar S. Traffic descriptor mapping and traffic control for frame relay over ATM network. IEEE/ACM Transations on Networking, 1998, 6(1): 56–70 25. 3GPP TS 29. 207-640 26. ITU-T Recommendation Y.1541. Network performance objectives for IP-based services. 2006 27. Park S, Kim K, Kim D C, et al. Collaborative QoS architecture between diffServ and 802.11e Wireless LAN. Proceedings of the 57th Vehicular Technology Conference (VTC-Spring’03) : Vol 2, Apr 22–25, 2003, Jeju, Korea. Piscataway, NJ, USA: IEEE, 2003: 945–949 28. Marchese M. QoS over heterogeneous networks.New York,NY,USA: John Wiley & Sons, 2007 29. Skorin-Kapov L, Huljenic D, Mikic D, et al. Analysis of end-to-end QoS for networked virtual reality services in UMTS. IEEE Communications Magazine, 2004, 42(4): 49–55 30. Blake S, Black D, Carlson M, et al. An architecture for differentiated services. IETF RFC 2475. 1998 31. Rosen E, Callon R. Multiprotocol label switching architecture. IETF RFC 3031. 2001