QoS Provisioning Using IPv6 Flow Label In the Internet

Transcription

1 QoS Provisioning Using IPv6 Flow Label In the Internet Xiaohua Tang, Junhua Tang, Guang-in Huang and Chee-Kheong Siew Contact: Junhua Tang, lock S2, School of EEE Nanyang Technological University, Singapore, Phone: ; Fax: Abstract Today s Internet only provides best-effort service. Traffic is processed as quickly as possible, but with no commitment as to bandwidth or latency guarantee. This is inadequate for applications requiring timeliness such as video conference, video-on-demand (VOD) and voice over IP (VoIP), etc. For these applications to be widely used, Quality of Service (QoS) must be quantified and managed efficiently by the Internet. This paper focuses on QoS provisioning using IPv6 flow label field. In this paper, we first investigate the flow label specification and its usage in QoS support proposed in the literature, then propose an end-to-end QoS scheme using the IPv6 flow label field, which employs a hybrid approach for flow label specification and a flow label option for IPv4 packet. This proposed QoS scheme is especially designed for transitional IP network containing both IPv4 and IPv6 network nodes, which is the reality in the process of Internet transition from IPv4 to IPv6. Our simulation results show that the proposed QoS scheme can efficiently differentiate various types of traffic to meet differentiated QoS requirements in a transitional network containing IPv4 and IPv6 routers. Keywords: QoS; Flow label; IPv6 1. Introduction Internet traffic has increased at an exponential rate in recent years and shows no signs of slowing down. In the mean time, some new applications (e.g. multimedia applications, real-time applications, network management etc.) raise requirements for the underlying network infrastructure to differentiate classes of service for real- or near-real time traffic, which throws big challenges to the current Internet that provides only best-effort service to all users. Fortunately, Integrated Services (IntServ) and Differentiated Service (DiffServ), together with Multiprotocol Label Switching (MPLS) and Resource Reservation Protocol (RSVP), provide two viable Quality of Service (QoS) architectures for the Internet, and packet classification becomes a key element in the implementation of both architectures. An attempt in IP version 4 (IPv4) to classify traffic according to a Type of Service (ToS) byte in the IP header did not succeed Internet-wide because the ToS byte was based on fair self-classification of applications with respect to other application traffic. Multimedia applications were scarce at that time, so no real efforts were made to address this problem in the early stages of the Internet and the ToS byte was never used widely. The 20-bit flow label field in IP version 6 (IPv6) packet header provides an efficient way for packet marking, flow identification and flow state lookup, and plenty effort was put in exploiting the benefit from this field in QoS support, but how to effectively use the flow label field in IntServ and DiffServ services is still an open issue. This paper focuses on the following issues pertaining to QoS provisioning using IPv6 flow label field: 1) flow label format for IntServ and DiffServ support respectively 2) strategies of defining a uniform flow label field for a heterogeneous network that implements both IntServ and DiffServ (although maybe in different part of the network) 3) strategies of seemless QoS support between IPv6 network that uses the flow label field and IPv4 network that does not have the flow label field in the packet header. This paper is organized as follows. In Section 2, we introduce the flow label specification and its usage in QoS support proposed in the literature. In Section 3, a proposed QoS scheme using the IPv6 flow label field, which employs a hybrid approach for flow label specification and a flow label option for IPv4 packet, is described in detail. The simulation results are presented and analyzed in Section 4. And finally, the conclusions of this paper are drawn in the last Section. 2. IPv6 Flow Label 2.1 IPv6 Flow Label Definition The IPv6 Flow Label [1] is defined as a 20-bit field in the IPv6 header which may be used by a source to label sequences of packets for which it requests special handling by the IPv6 routers, such as non-default quality of service or "real-time" service. According to [1], the nature of that special handling might be conveyed to the routers by a control protocol, such as RSVP, or by information within the flow's packets themselves, e.g., in a hop-by-hop option.

2 2.2 Current Status of the IPv6-Specific QoS Standardization As stated by [1], at the time when the IPv6 specifications were written, the IPv6 flow label was still experimental, and subject to change, as the requirements for flow support in the Internet were evolving. The last several years of work in Internet Engineering Task Force (IETF) on Internet Protocols QoS (Intserv, and Diffserv) provide a more solid and ample architectural perspective, and fra mework for the standardization of the IPv6 flow label. A lot of serious work was done around the world in various areas of concern with Flow Label redefinition/specification and usage standardization. There seems already a reasonable degree of consensus at the IETF about the usage of Flow Label for instance and this section discusses the already suggested approaches in [2] for defining the 20-bit Flow Label First Approach In order to preserve compatibility with the random number method of selecting a flow label value defined in [1] (Figure 1), but relax that definition to allow a flow label format that would work with DiffServ, the new format of the flow label in Figure 2 could be used. 0 Pseudo-Random Value Figure 1 Random Number Format 1 DiffServ Flow label Second Approach Figure 2 Flow Label Format DiffServ with multi field classifier containing Flow Label can be used in a more efficient and practical manner as an alternative to IntServ and RSVP. The Flow Label classifier is basically a 3-element tuple - source and destination address and IPv6 Flow Label. The classifier can be defined in any of the following two ways: C = (SA, SAPrefix, DA, DAPrefix, Flow Label) Or C = (SA, SAPrefix, DA, DAPrefix, Flow Label min, Flow Label max). Where SA is source address, SAPrefix is prefix of the source address, DA is destination address and DAPrefix is prefix of the destination address. Incoming packet header (SA, DA, Flow Label) is matched with classification rules table entry C or C Third Approach This approach, as shown in Figure 3, includes the algorithmic mapping of the port numbers and protocol into the Flow Label. It reserves 12 bits for the port number and 8 bits for the protocol. Server Port Number H-to-H Protocol Figure 3 Port Number and Protocol Format 3. Proposed end-to-end QoS Scheme In order to make use of the QoS features in IPv6 to support QoS more efficiently, an end-to-end QoS scheme is proposed using a hybrid approach [3] for defining the 20- bit Flow Label field in IPv6 ase Header, which is applicable to both IntServ and DiffServ service models. Since IPv6 deployment will be a gradual process, there will be a transitional period, during which IPv6 hosts will need to communicate with the global Internet, which currently has majority of IPv4 hosts. Therefore, this proposed QoS scheme also makes use of a Flow Label option in IPv4 packets, to communicate QoS parameters with IPv6 nodes that use the Flow Label field. 3.1 A Hybrid Approach of IPv6 Flow Label Specification A hybrid approach is used in this paper that integrated several approaches mentioned in Section 2. The first 3 bits of the IPv6 Flow Label are used to define the approach used and the rest 17 bits are used in the format defined in a particular approach. As we have learned in Section 2, several approaches are proposed in the literature for defining the Flow Label field, each with its own merits and limitations. This proposed approach serves as a framework to integrate the approaches for better flexibility and possible adoption in various paradigms and applications Specification of the first three bits of the Flow Label Following is the bit pattern for the first 3 bits of Flow Label that define the type of the approach used: Default A random number is used to define the Flow Label The value given in the Hop-by-Hop extension header is used instead of the Flow Label Multi Field Classifier is used A format that includes the port number and the protocol in the Flow Label is used A new definition explained later in this section is used Reserved for future use Reserved for future use.

3 This specification can be used for IntServ and DiffServ services. The default value (000) specifies that the packet does not need any QoS. The detail of these options is provided in the remaining of this section Defining the remaining 17 bits of the IPv6 Flow Label y making the optimal use of the bits in the Flow Label, this section describes an innovative format that includes various QoS parameters in the IPv6 Flow Label. The QoS parameters may include the following based on the requirements of the applications: 1)andwidth 2)Delay or Latency 3)Delay Jitter 4)Packet Loss 5)uffer Requirements. Packet loss and the delay jitter may not be specified in the Flow Label itself because these two parameters are often kept minimum. Instead, if needed, using the Hop-by-Hop options header to specify these parameters is a good choice. So the QoS parameters that are to be included in the Flow label are: 1)andwidth 2)Delay 3)uffer Requirements To make the best use of the remaining 17 bits, we use the first bit out of these 17 bits to differentiate between the hard real time and soft real time applications. We set this bit to 0 for soft real time applications and 1 for hard real time applications Flow Label Soft Realtime Applications Soft real time applications have an average bandwidth requirements and an intermediate end-to-end delay requirement. These application can afford to manage with the QoS provided even if the minimum or maximum values specified in the Flow Label are not exactly met Flow Label Hard Realtime Applications Hard real time applications have strong constraints both in terms of delay and jitter. The remaining 16 bits are used to specify the bandwidth, buffer requirements and the delay. 1.andwidth The first 6 bits out of the 16 bits specify the bandwidth requirements. The bandwidth will be expressed in multiples of Kbps. For scalability in the future when bandwidth becomes abundant, the scale i.e. Kbps, Mbps etc. can be changed to suit the specific requirements. The first bit is used to specify whether bandwidth is minimum or maximum. The other five bits can be exploited by using a simple formula to specify a value for bandwidth. The formula used here to calculate bandwidth in decimal from the bit-pattern is andwidth = 2 * 32 Kbps Where, is the decimal equivalent of the bandwidth specified in 5-bits. 2.uffer Requirements The next 5 bits out of the 16 bits specify the buffer requirements of the application. The formula used to calculate the buffer requirements is: uffer Requirements = 2 *512 ytes Where, is the decima l equivalent of the buffer specified in the 5-bits. 3.Delay The last 5 bits out of the 16 bits specify the maximum delay that the application can tolerate. The formula used to calculate the delay is Delay = 2 * 4 nanoseconds Where, is the decimal equivalent of the delay specified in the 5-bits. The bits distribution is shown below: /1 andwidth uffer Delay This approach is a DiffServ based mechanism for providing the QoS as packets coming into the router is classified based on the MF Classifier. The MF Classifier consists of the source address, destination address and Flow label which is specified in bandwidth, buffer and delay. The MF Classifier in this case looks like: C = (SA/SAPrefix, DA/DAPrefix, Flow-Label) Or C = (SA/SAPrefix, DA/DAPrefix, Flow-Label-Min: Range). Where Flow Label = (bandwidth, buffer, delay) Incoming Packet header (SA, DA, Flow Label) is matched against classification rules table entry (C or C ). 3.2 Mapping of the IPv6 Flow Label in IPv4 nodes Since there is no counterpart of the 20-bit IPv6 Flow Label in IPv4 header, this section introduces a flow label option to IPv4 header for IPv4 nodes to exchange the QoS information with IPv6 nodes that use the Flow Label field Definition of IPv4 Flow Label Option IPv4 [4] already defines an option header for a 16 bits STAMENT stream identifier. Since this identifier is incompatible with the 20-bit IPv6 Flow Label, a new one is defined in following [5]:

4 Flow Label Type=143 Length=5 Flow Label: 20 bits All definitions of the above sections for the IPv6 flow label are also valid for this field. A value of zero denotes that no flow label is used. Note that, since the option header contains 3 bytes and therefore 24 bits. The first 4 bits are unused and must be set to Simulation Parameters Key Parameters Sending Rate (Mbps) Period (Second) andwidth (Mbps) GS s-70s 0.2 AS s- 100s S 1.0 0s- 130s uffer Size (ytes) Delay (Second Mapping of the IPv6 Flow Label in IPv4 nodes General analysis of the results Since the new IPv4 Flow Label option is fully compatible with the IPv6 Flow Label, a router can easily map the Flow Label value of IPv6 packets to the Flow Label option of IPv4 packets and vice versa. 4. Simulations Results In this case, we inject traffic from all the three service classes, Guaranteed Service (GS), Assured Service (AS) and est-effort Service (S), into the network to verify that service differentiation is correctly implemented. Simulations have been conducted in this research project to evaluate the performance of the proposed QoS scheme in a DiffServ network consisting of both IPv6 and IPv4 network segments. QoS simulator (QoSSim) has been used as the main simulation tool for this research project. QoSSim is developed to evaluate the performance of QoS scheme in DiffServ-based network, it can be divided into 3 subsystems: network subsystem, control subsystem and GUI subsystem. These building blocks interact with each other as shown in Figure 4.The network subsystem represents physical network components, including senders, receivers, nodes and links. The control subsystem can be used to set parameters and collect statistics during simulation. The GUI subsystem provides a user-friendly interface for setting parameters and monitoring simulation. Control Subsystem -Monitor -Stopper -Data Files GUI Subsystem Network Subsystem -Sender -Receiver -Node -Link Figure 4 uilding locks of QoS Sim 4.1 Case I Service Differentiation etween the Three Service Classes Figure 5 Regular Routers Figure 6 Flow Label Classifier Routers Figure 5 shows the result with regular routers. We note that the GS traffic rate is not guaranteed, since the regular routers do not discriminate the GS traffic from the AS and S traffic so that all traffics have to contend for the bandwidth. Figure 6 shows the result with our Flow Label Classifier routers. It shows clearly that the GS traffic has the highest priority and its rate is guaranteed with the expense of the AS and S rates (from 20s through 70s, The GS rate remains 0.6 Mbps without any degradation). During the interval from 70s through 100s, where there is no GS traffic, the AS traffic has a higher priority than the S traffic. Its rate is guaranteed with the expense of dropping the S packets. After 100s, both GS and AS traffics shut down. The S traffic grabs all the bandwidth from then on. This test case shows clearly that our Flow Label Classifier router can efficiently differentiate the three service classes. 4.2 Case II Effect of Varying the GS Traffic Simulation Parameters Key andwidth Parameters (Mbps) uffer Requirements (ytes) Delay (Second) GS AS S

5 4.2.2 General analysis of the results In this experiment, we observe the delay behavior and the packet loss behavior in response to the change in GS traffic intensity. Here, the GS traffic intensity is defined as the proportion of the incoming traffic rate to the amount of bandwidth assigned to this service. For instance, in our experiment the GS traffic intensity of 1 represents the ratio of incoming GS traffic of 0.2 Mbps to the assigned GS bandwidth which is 20% of the 1.0 Mbps total link bandwidth. QoSSim simulator. We conducted a number of simulations based on our Flow Label Classifier routers. Through these simulations, we not only verified the correctness of our design and implementation, but also verified the effectiveness of using the Flow Label field to provide a better QoS. The hybrid approach for defining the 20-bit Flow label field can be used in IntServ as well as DiffServ based network support for QoS provisioning. In this paper, we only use one of the definition in the DiffServ networks. One may further the study on how to integrate the IntServ and DiffServ to provide an end-to-end QoS guarantees. The computation complexity of processing the label will be considered in the future work. References [1] S. Deering and R. Hinden, Internet Protocol Version 6 Specification, IETF Network Working Group RFC 2460, December Figure 7 Delay ehavior as a Function of GS Traffic Figure 7 shows the delay behavior as a function of GS traffic intensity. While the GS traffic intensity increases, the GS delay does not change significantly. However, the AS delay and the S delay increase. The S delay is longer than the AS delay since S packets have the lowest priority to get the chance to be transmitted. Similar trend of packet loss behavior can be observed in Figure 8. [2] A. Conta and. Carpenter, A proposal for the IPv6 Flow Label, IETF IPng Working Group INTERNET- DRAFT <draft-conta-ipv6-flow-label-02.txt>, July [3] R. anerjee, S. P. Malhotra, and M. Mahaveer, A Modified Specification for use of the IPv6 Flow Label for providing An efficient Quality of Service using a hybrid approach, IETF IPv6 Working Group INTERNET- DRAFT <draft-banerjee-flowlabel-ipv6-qos-03.txt>, April [4] J. Postel, Internet Protocol, IETF RFC 791, September [5] T. Dreibholz, An IPv4 Flowlabel Option, IETF Network Working Group INTERNET-DRAFT <draftdreibholz-ipv4-flowlabel-00.txt>, April Figure 8 Packet Loss ehavior as a Function of GS Traffic 5. Conclusions and Future Work In this paper, we introduced the flow label definition and its usage in QoS support proposed in the literature. We also proposed an end-to-end QoS scheme using the IPv6 flow label field. In order to observe the feasibility of the proposed scheme, we have designed and implemented a