IPv6 Working Group Harshavardhan Jagadeesan Internet Draft Tuhina Singh BITS, Pilani (India) March 2002 A Radical Approach in providing Quality-of-Service over the Internet using the 20-bit IPv6 Flow Label field. draft-jagadeesan-rad-approach-service-00.txt Status of This Memo This document is an Internet Draft and is subject to all provisions of Section 10 of RFC 2026. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of 6 months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet Drafts as reference material or to cite them other than as a "work in progress". The list of current Internet Drafts can be accessed at http://www.ietf.org/lid-abstracts.html The list of Internet Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright(C) The Internet Society (2002). All Rights Reserved. Abstract This memo suggest a radical and a generic approach in using the 20-bit IPv6 Flow label field to provide Quality-of-Service on the Internet. The approach is generic in the sense it does not enforce any specific implementation features on the developers, the only thing that will have specific semantics is the flow-label field. The other methods of information storage and processing in the routers are router specific and can be implemented in a number of ways. Thus the resulting mechanism suggested here is fully and easily implementable and unambiguous as may be required for real implementations Harshavardhan Jagadeesan & Tuhina Singh [Page 1] Internet Draft A Radical Approach in providing March 2002 Quality-of-Service over the Internet using the 20-bit IPv6 Flow Label field. Table of Contents 1. Introduction..................................................3 2. Terminology and definitions...................................3 3. Flow-label specification......................................4 4. Flow-label requirements.......................................5 4.1 At the Host ..............................................6 4.2 At the Routers ...........................................7 4.2.1 Control Plane ......................................7 4.2.2 Forwarding Plane ...................................7 4.3 Flow Re-Routing ..........................................8 5. Issues related with IPv6 Flow Label...........................8 5.1 What should a router do with Flow Labels for which it has no state?..........................................8 5.2 How does the Router flush out stale flow labels? .........8 5.3 Which datagrams should carry non-zero Flow Labels? .......9 5.4 Whether to use Mutable/Non-Mutable flow labels............9 5.5 What if a Router in the Path is not able to satisfy the QoS requirements ?............................9 6. Conclusion ...................................................9 Acknowledgements.................................................10 References.......................................................10 Disclaimer.......................................................10 Author Information...............................................11 Full Copyright Statement.........................................11 Harshavardhan Jagadeesan & Tuhina Singh [Page 2] Internet Draft A Radical Approach in providing March 2002 Quality-of-Service over the Internet using the 20-bit IPv6 Flow Label field. 1. Introduction This draft provides a radical and generic view of the design and implementation-specific issues pertaining to the Quality of Service (QoS) support in the 20-bit Flow Label field of the IPv6 Base Header. The design has been suggested keeping in mind the heterogeneous nature of the Internet. The design suggested is simple, scalable and modular. The implementation details are generic and thus gives a lot of freedom to the implementors. The 20-bit flow label field is the only field that follows definite semantics. Thus the information that is exchanged between the routers[i.e. the flow label] is specific whereas the information that is stored and processed at the routers is generic [implementation dependent] i.e. the way the routers store and process the information is left to the individual vendors, but the flow label that is passed between different nodes has a specific semantics. 2.Terminology and Definitions Flow A sequence of related packets sent from a source to a unicast or multicast destination. A flow could consist of all packets in a specific transport connection, media stream, or any other aggregate known to the source. Flow Label The 20-bit field in the IPv6 Base header which may be used by the source to label a sequence of packets for which it requests special handling by the routers. Classifier A forwarding plane entity which selects packets based on the content of packet headers according to defined rules. Control plane Part of an IP node taking care of control functions, such as routing protocols and flow state establishment protocols. Controls the functions of the forwarding plane. Flow processing The flow-specific handling performed by the forwarding plane on each packet of a flow being processed. May include meters, droppers, shapers, schedulers, etc. Harshavardhan Jagadeesan & Tuhina Singh [Page 3] Internet Draft A Radical Approach in providing March 2002 Quality-of-Service over the Internet using the 20-bit IPv6 Flow Label field. Flow state The information stored in an IP node driving the flow classification and processing. The required information is specified by the method defining the flow-specific handling Flow state Control plane mechanism used to set up the establishment flow state. A flow state establishment method can be either - Dynamic, under host control (e.g. RSVP), - Quasi-dynamic, under network management control, or - Static, through manual configuration. Forwarding plane Part of an IP node receiving and forwarding IP packets; also known as the "data path". 3.Flow Label Specification : This section speaks about making an optimal use of the 20-bits in the flow label to provide details about basic QoS parameter like BANDWIDTH,BUFFER REQUIREMENTS,MAXIMUM DELAY that any application needs. Jitter and Packet loss are also other parameters that need to be kept minimum so they do not have to be defined here in the flow label. Instead if needed Hop-by-Hop options header can be effectively used to specify these parameters. A non-zero flow label indicates that the IPv6 packet is labeled. The zero flow label [for which the host is not able to identify QoS] is reserved to specify default best-effort service. The flow label values set by the source has to be delivered unchanged to the destination. This reduces the processing time involved in using a mutable flow label. The distribution of the 20-bits are as follows: 1. The first 8-bits specify the bandwidth requirements. The bandwidth will be specified 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 1-bit specifies whether bandwidth is minimum or maximum. The other seven 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 Bandwidth = (2^B) * 32 Where B, is the decimal equivalent of the bandwidth specified in 7-bits. Harshavardhan Jagadeesan & Tuhina Singh [Page 4] Internet Draft A Radical Approach in providing March 2002 Quality-of-Service over the Internet using the 20-bit IPv6 Flow Label field. 2. The next 5 bits are used to specify the maximum delay that the application can stand. The formula used to calculate the delay is Delay (in decimal) = (2^B) * 4 nanoseconds Where B, is the decimal equivalent of the delay specified in the 5-bits. Only five bits are used in this case because using them we can specify a maximum of 8 seconds which is more than the delay any application can demand. And any application prefers a minimum delay. In future we expect the delay to reduce further. 3. The last 7 bits are employed to specify the buffer requirements of the application. The formula used to calculate the buffer requirements is: Buffer Requirements = (2^B) * 512 bytes where B, is the decimal equivalent of the buffer specified in the 7-bits. The distribution is shown below : +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | BANDWIDTH | DELAY | BUFFER | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 The formula approach used here reduces the storage requirements at the router that is associated with the table look-up and provides different slabs for QoS parameter which helps in structured handling of these parameters in the network. 4. Flow Label Requirements The requirements to provide Quality-of-Service using Flow label can be viewed from two perspectives, one at the host and another at the router. Harshavardhan Jagadeesan & Tuhina Singh [Page 5] Internet Draft A Radical Approach in providing March 2002 Quality-of-Service over the Internet using the 20-bit IPv6 Flow Label field. 4.1 At The Host All the previous drafts regarding IPv6 flow label specifications speak about Applications providing the QoS Parameters: There are possible problems associated with this approach: 1. The Internet consists of lots of heterogeneous applications written in many languages. Each platform requires API's for all these different languages. 2. Porting these applications to different environments/platforms requires that each application has multiple compatible APIs. 3. The API development time is long and a costly affair and this prevents any one from providing QoS in the near future. 4. We are supposed to maintain backward compatibility with applications that are already running. Porting these applications to use these APIs is difficult and impossible in many cases. 5. Allowing the Application developer to specify resources can result in a serious misuse of resources and even DOS attacks on the Internet.(malicious users/developers) 6. This can also become an overhead to the programmer and non-transparent to the user. This also requires network engineering knowledge on the developers side. Hence we believe that doing this using a MANUAL CONFIGURATION in the nodes can be a better choice. The scenario would be like, while configuring the system the administrator specifies default QoS for certain recognized flows [RTP,TCP etc.] and application specific QoS, which will be used as input while filling the flow label field in the IPv6 header. These default values can be re-configured using some config files [e.g./etc/qos.conf] and configuration tools [e.g. qosconfig]. Any new application that is added to the host can also be given QoS parameters by adding to the configuration files. When the application starts running the values are taken from the configuration files. This way the applications will be portable and backward compatible. This method is generic enough to allow implementers to do it in their own way. By specifying QoS parameters for all flows we also ensure better TRAFFIC ENGINEERING at the overall network. This also guarantees better than best-effort delivery. A PDP-PEP [Policy Decision Point - Policy Enforcement Point] type of approach can also be used to make the Quality-of-Service parameters configurable at a central point of control in the network. Harshavardhan Jagadeesan & Tuhina Singh [Page 6] Internet Draft A Radical Approach in providing March 2002 Quality-of-Service over the Internet using the 20-bit IPv6 Flow Label field. 4.2 At the Routers At the router we can have twin distinct perspectives for providing QoS. The whole procedure can be divided into two phases. One the flow state establishment[Control Plane] and the other per-hop forwarding behavior [Forwarding plane]. The implementations can be specific to hosts (i.e.)the way they store the state information and process it. The flow label field will be the only consistent field with a well defined semantics which will be understood by all IPv6 compliant nodes. 4.2.1 Control plane This plane is responsible for establishing the flow and storing the state Information and mapping it to specific forwarding behaviors. This phase decides the exact physical interface mapping for a particular flow and maintain a data structure that includes 1. Flow label, Source address -- 3-tuple flow identifier. The and destination address. addresses can be full addresses, pre- fixes, ranges or wild cards. 2.The forwarding treatment -- Defines the actual flow specific handling the flow packets are subjected to. 3. Flow statistics -- Counter of number of bytes or packets of flow data forwarded. 4. The Flow time -- The router stores the 'flow-expiry' time here. ['Flow expiry' time is the time between the current time and the time when the router got a "GO AHEAD" packet ] 4.2.2 Forwarding Plane Flow state is created by the router control plane. All the state information is stored in the router. Packet classification is done by the router forwarding plane on flat 20-bit flow label and the source and destination address fields, matched against the triplets for the defined flows. [Pattern matching]When the matching flow state has been found the router will be able to update the statistics and forward the packet with the specific handling as specified by the flow states. Harshavardhan Jagadeesan & Tuhina Singh [Page 7] Internet Draft A Radical Approach in providing March 2002 Quality-of-Service over the Internet using the 20-bit IPv6 Flow Label field. 4.3 Flow re-routing Flow re-routing is a very efficient technique in providing QoS in the network layer. This can be achieved with the above mentioned technique without involving any overhead. 5. Issues related with IPv6 Flow Label According to RFC 1809 [C.Partridge], the IPv6 specification originally left Open a number of questions, of which the following are important. 5.1 What should a router do with Flow Labels for which it has no state? This scenario can happen in many cases one being router crash or flow re-routing. When such a scenario is encountered, the state information is read from the flow label and a new flow state information is created. Since this state information lasts only till the flow lasts the chances of any possible cache explosion at the routers in minimal. Although such an explosion can be handled using efficient replacement techniques. Thus the router takes care that it provides the Quality-of Service requirements even in case of loss of state information. 5.2 How does the router flush out stale flow labels? Each IPv6 compliant node should be able to understand the ICMP message that tells the host that the router will be deleting the state information about a particular flow. Such a packet is sent after the flow time expires .The host should reply with a KEEP ALIVE or a GO AHEAD signal. If no reply comes back to the router it should retransmit the ICMP packet three times. If no acknowledgement is elicited from the host the flow state can be deleted. The time(which is stored) after which ICMP message is sent, is implementation specific. As long as the nodes understand the ICMP message and replies there would be no problems. This helps in eliminating STALE FLOW STATES. Harshavardhan Jagadeesan & Tuhina Singh [Page 8] Internet Draft A Radical Approach in providing March 2002 Quality-of-Service over the Internet using the 20-bit IPv6 Flow Label field. 5.3 Which datagrams should carry non-zero Flow Labels? The flows that are common [RTP,TCP] flows can be given flow labels by the Host apart from the special applications whose QoS requirements are explicitly set. Any flow that cannot be identified with common flows need not be given flow label. [Small exchange of data]But the authors suggest giving flow label to most of the packets which will help in achieving better than best-effort delivery. This will also aid in better overall traffic engineering at the network. 5.4 Whether to use Mutable/Non-Mutable flow labels ? The authors feel that using mutable flow labels adds an extra overhead because there has to be negotiations between the routers and the implementation becomes complex. So having a non-mutable flow label is the best option since it goes with the IPv6 specification of flow label. 5.5 What if a Router in the path is not able to satisfy the QoS Requirement? While establishing control if a router is not able to satisfy the QoS requirements then it sends an ICMP message to the previous node saying it cannot satisfy the QoS requirements. The previous node on receiving such a packet will then try to find an alternate path. If it is not able to do so it sends back a similar ICMP packet to its previous node. This goes on until either a path is established between the source and the destination or an ICMP packet reaches the source host. In such a case the source host would scale down the QoS requirements and re-negotiate. The amount of scaling down can be implementation specific. The QoS path [Path which can provide required QoS] between the nodes can be found along with the path MTU discovery. 6.0 Conclusion On concluding the effectiveness of this approach is analyzed, Since most of the QoS processing is done at the Network Layer by just parsing through the 20-bit flow label field it reduces the processing time at the routers. Any additional QoS parameters can always be added in the Hop-by-Hop options header using the TLV options as specified in [draft-banerjee-hop-by-hop]. Harshavardhan Jagadeesan & Tuhina Singh [Page 9] Internet Draft A Radical Approach in providing March 2002 Quality-of-Service over the Internet using the 20-bit IPv6 Flow Label field. Acknowledgements The Authors kow-tow their guruji Prof.Rahul Banerjee who has provided ample guidance and constant support. Authors acknowledge technical inputs and support from the members of the "Project IPv6@BITS" at the Birla Institute of Technology and Science, Pilani, India, Authors gratefully acknowledge the works of many dedicated brains at the IETF and elsewhere, sections or extracts of which have helped us to shape this document. References [RFC 2460] S. Deering and Bob Hinden, "The Internet Protocol Specification", RFC 2460, Internet Protocol version 6 Specification. [RFC 1809] C. Partridge, RFC 1809, "Using the Flow Label Field in IPv6". References to the works in progress [draft-banerjee-ipv6-flow-label-02.txt] Rahul Banerjee, Sumeshwar Paul Malhotra,Mahaveer M, "A Modified Specification for use of the IPv6 Flow Label for providing efficient Quality of Service using hybrid approach." [draft-banerjee-ipv6-quality-service-02.txt] Rahul Banerjee, N. Preethi, M. Sethuraman, "Design and Implementation of the Quality-of-Service in IPv6 using the modified Hop-by-Hop Extension header - A Practicable Mechanism". [draft-rajahalme-ipv6-flow-label-00.txt] J. Rajahalme, A. Conta, "An IPv6 Flow Label Specification proposal". [draft-ietf-ipv6-flow-label-00.txt] J. Rajahalme et al "An IPv6 Flow Label Specification". [draft-conta-ipv6-flow-label-02.txt] A. Conta, B. Carpenter, "A proposal for the IPv6 Flow Label". Disclaimer The views and specification here are those of the authors and are not necessarily those of their employers. The authors and their employers specifically disclaim responsibility for any problems arising from correct or incorrect implementation or use of this specification. Harshavardhan Jagadeesan & Tuhina Singh [Page 10] Internet Draft A Radical Approach in providing March 2002 Quality-of-Service over the Internet using the 20-bit IPv6 Flow Label field. Author Information Harshavardhan Jagadeesan/Tuhina Singh Centre for Software Development BITS, Pilani 333031, Rajasthan, India. Phone: +91-159-7645073 Ext. 335 Email: f1998233@bits-pilani.ac.in / f1998372@bits-pilani.ac.in Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Harshavardhan Jagadeesan & Tuhina Singh [Page 11]