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-flow-label-02.txt>
[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".
<draft-rajahalme-ipv6-flow-label-00.txt>
[ietf-flow-label]
J. Rajahalme et al
"An IPv6 Flow Label Specification".
<draft-ietf-ipv6-flow-label-00.txt>
[draft-conta]
A. Conta, B. Carpenter,
"A proposal for the IPv6 Flow Label".
<draft-conta-ipv6-flow-label-02.txt>
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]