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-01.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 that 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 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.......................................6 4.1 At the Host ..............................................6 4.2 At the Routers ...........................................7 4.2.1 Control Plane ......................................7 4.2.2 Forwarding Plane ...................................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.2.1 Structure of ICMPv6 Message .ààààààààààààààààààààà..9 5.3 Which datagrams should carry non-zero Flow Labels? .......10 5.4 Whether to use Mutable/Non-Mutable flow labels............10 6. Conclusion ...................................................10 Acknowledgements.................................................10 References.......................................................11 Disclaimer.......................................................11 Author Information...............................................12 Full Copyright Statement.........................................12 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 (as described in [draft-ietf-flowlabel]) 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 talks about making an optimal use of the 20-bits in the flow label field to provide details about basic QoS parameters like BANDWIDTH,BUFFER REQUIREMENTS and 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.(Inspired by [draft-banerjee-flowlabel]) 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 value 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 can be changed (to say Mbps) to suit the future requirements. The first 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 to calculate bandwidth in decimal from the bit-pattern is: (first described in [draft- banerjee-flowlabel]) 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. Bandwidth = (2^B) * 32 Where B, is the decimal equivalent of the bandwidth specified in 7-bits. 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: (first described in [draft-banerjee-flowlabel]) 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 by using them we can specify a maximum delay of 8 seconds which is greater than the delay any application can demand. 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: (first described in [draft-banerjee-flowlabel]) 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 A lookup table approach can also be used that maps the value mentioned in the bandwidth/delay/buffer field of the Flow Label to the value already defined in the lookup table. These values have to be universally accepted and uniformly defined in all the routers and end-nodes. However, the formula approach used here reduces the storage requirements at the router that is associated with the table look-up and also provides slabs for QoS parameters which helps in structured handling of these parameters in the network. 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. 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. 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 many heterogeneous applications written in various 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 for each platform. 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. Changing 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 on 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 this: while configuring the system the administrator specifies default QoS for certain recognized flows [RTP,TCP etc.] and some specific QoS for specific applications, 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 implement it in their own way. 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. 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. 4.2 At the Routers At the router the process of providing QoS can be divided into two phases. One the flow state establishment phase [in Control Plane] and the other per-hop forwarding phase [in Forwarding plane]. The way the hosts store the state information and process it can be host specific. 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, storing the state information and mapping it to specific forwarding behaviors. For this the routers maintain a data structure that includes [draft-ietf-flowlabel] 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. 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. Flow time -- The router stores the 'flow-expiry' time here. ['Flow expiry' time is the difference between the current time and the time when the router is to send ICMPv6 message to the host, telling the host that it is going to delete the state information for this flow] 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.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.(inspired by [draft-ietf-flowlabel]). 5. Issues related with the 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? The method to delete stale flow labels is largely derived from [draft- banerjee-flowlabel]. Each IPv6 compliant node should be able to understand the ICMPv6 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 ICMPv6 packet three times. If no acknowledgement is elicited from the host the flow state can be deleted. The time after which ICMPv6 message is sent, is implementation specific (depending on how long a router wants to maintain a flow state). As long as the nodes understand the ICMP message and reply there would be no problem. 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.2.1 Structure of ICMPv6 Message The structure of the ICMPv6 message to be exchanged between the nodes to achieve this end is as follows : 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (135)| Code(0,1,2) | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flow Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | As much of invoking packet | + as will fit without the ICMPv6 packet + | exceeding 576 octets | IPv6 Fields: Destination Address (Code = 0) Taken from the Source Address field in the 3-tuple flow identifier. (Codes 1 and 2) Taken from the Source Address field of the invoking packet. ICMPv6 Fields: Type 135 Code 0 û Flow state will be deleted message 1 û GO AHEAD Signal 2 û KEEP ALIVE Signal Flow Label Identifies the flow label, taken from the 3-tuple flow identifier, for which the flow state is to be deleted. Description The router will send the ICMPv6 message with the type 135 and code 0 to tell the host that it will be deleting the flow state associated with the flow label included in the "flow label" field of the message. Since by definition a source must have unique flow labels associated with each of its flows, it will be able to identify the flow being referred to. 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. The host on receiving such a message must reply with ICMPv6 message of type 135 and code 1 to tell the router to delete the flow state or with type 135 and code 2 to tell the router to retain the information as the case may be. If the host does not respond even after the router has retransmitted the message thrice, the router can delete the flow state. 5.3 Which datagrams should carry non-zero Flow Labels? The flows that are common (RTP,TCP) 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 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 have 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. 6.0 Conclusion To be able to deploy QoS routing capabilities in the internet in a very short time, it is important that it takes into account the heterogeneous nature of internet, the wide variety to vendors, introduces minimal possible impact on the existing applications and architecture and has the smallest possible computing overhead. An overhead is unavoidable but the costs must be kept as low as possible. The authors believe that using flowlabel field as suggested in this document would help to achieve this end. 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. 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. 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-flowlabel] 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] 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-banerjee-ipv6-quality-service-02.txt> [draft-rajahalme] J. Rajahalme, A. Conta, "An IPv6 Flow Label Specification proposal". [ietf-flow-label] J. Rajahalme et al "An IPv6 Flow Label Specification". [draft-conta] 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 11] 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 12]