One document matched: draft-hu-flow-label-cases-00.txt
Independent Submission Q. Hu
Internet-Draft B. Carpenter
Intended status: Informational Univ. of Auckland
Expires: October 21, 2010 April 19, 2010
Survey of proposed use cases for the IPv6 flow label
draft-hu-flow-label-cases-00
Abstract
The IPv6 protocol includes a flow label in every packet header, but
it is not used in practice. This paper describes the flow label
standard and discusses the implementation issues that it raises. It
then describes various published proposals for using the flow label,
and shows that most of them are inconsistent with the standard.
Methods to address this problem are briefly reviewed. We also
question whether the standard should be revised.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six 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 "work in progress."
This Internet-Draft will expire on October 21, 2010.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Hu & Carpenter Expires October 21, 2010 [Page 1]
Internet-Draft Flow label use cases April 2010
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Flow label definition and issues . . . . . . . . . . . . . . . 4
3. Documented proposals for the flow label . . . . . . . . . . . 6
3.1. Specify the flow label as a pseudo-random value . . . . . 6
3.2. Specify QoS parameters in the flow label . . . . . . . . . 7
3.3. Use flow label to control switching . . . . . . . . . . . 8
3.4. Diffserv use of IPv6 flow label . . . . . . . . . . . . . 10
4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
9. Change log . . . . . . . . . . . . . . . . . . . . . . . . . . 13
10. Informative References . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Hu & Carpenter Expires October 21, 2010 [Page 2]
Internet-Draft Flow label use cases April 2010
1. Introduction
For many years it has been recognized that real-time Internet traffic
requires a different quality of service from general data traffic,
and this remains true in the era of network neutrality. Thus an
alternative to uniform best-effort service is needed, requiring
packets to be classified as belonging to a particular class of
service or flow. Currently, this leads to a layer violation problem,
since usually, a 5-tuple is used to classify each packet. The
5-tuple includes source and destination addresses, port numbers, and
the transport protocol type, so when we want to forward or process
packets, we need to extract information from the layers above IP.
This may cause problems when packets are encrypted so that port
numbers are hidden, or when packets are fragmented.
IPv6 will progressively replace the current IPv4 protocol. This will
solve the Internet's address shortage, but it also offers a new
feature to resolve the above difficulty, i.e., the flow label field
in the IPv6 packet header. The flow label is not encrypted by IPsec,
and is present in all fragments. It was reserved in the IPv6 packet
header in 1995 [RFC1883], and general rules governing its use were
defined in 2004 [RFC3697], but it is still rarely set in IPv6
packets. This paper reviews the syntax and semantics of the flow
label, and then describes various proposals that have been made for
its use.
The flow label was included in the IPv6 packet header during the
preliminary design of IPv6, which followed an intense period of
debate about several competing proposals. The final choice was made
in 1994 [RFC1752]. In particular, the IETF rejected a proposal known
as CATNIP [RFC1707], which included so-called 'cache handles' to
identify the next hop in high performance routers. We recognize this
today as a precursor of the MPLS label, and it introduced the notion
of a header field that would be shared by all packets belonging to a
flow, on a hop-by-hop basis. The IETF decided instead to develop a
proposal known as SIPP into IP version 6. SIPP included "labeling of
packets belonging to particular traffic 'flows' for which the sender
requests special handling, such as non-default quality of service or
'real-time' service" [RFC1710]. In 1994, this was a 28-bit flow
label field. In 1995 it was down to 24 bits [RFC1883] and it was
finally reduced to 20 bits [RFC2460] to accommodate the IPv6 Traffic
Class, which is fully compatible with the IPv4 Type of Service byte.
There was considerable debate in the IETF about the very purpose of
the flow label. Was it to be a handle for fast switching, as in
CATNIP, or was it to be meaningful to applications and for quality of
service? Must it be set by the sending host, or could it be set by
routers? Could it be modified en route, or must it be delivered with
Hu & Carpenter Expires October 21, 2010 [Page 3]
Internet-Draft Flow label use cases April 2010
no change? Because of these uncertainties, and more urgent work, the
flow label was consistently ignored by implementors, and today is set
to zero in almost every IPv6 packet. In fact, [RFC2460] defined it
as "experimental and subject to change." After preliminary work such
as [I-D.metzler-ipv6-flowlabel], [I-D.conta-ipv6-flow-label],
[I-D.conta-diffserv-ipv6-fl-classifier] and
[I-D.itojun-ipv6-flowlabel-api], the standard [RFC3697] intended to
clarify this situation by providing precise boundary conditions for
use of the flow label.
This paper summarizes the resulting definition of the flow label and
some open issues about its use, and then describes and analyses
various use cases that have been proposed, before drawing conclusions
and suggesting a strategy.
2. Flow label definition and issues
The flow label occupies bits 12 through 31 of the IPv6 packet header,
providing an easy way to mark a packet, identify a flow, and look up
the flow state. [RFC3697] standardizes properties of the flow label,
including:
o If the packets are not part of any flow, the flow label value is
zero.
o The 3-tuple {source address, destination address, flow label}
uniquely identifies which packets belong to which particular flow.
o Packets can receive flow-specific treatment if the node has been
set up with flow-specific state.
o The flow label set by the source node must be delivered to the
destination node.
o The same pair of source and destination must not use the same flow
label value again within 120 seconds or more.
One effect of these rules is to avoid the layer violation problem.
By using the 3-tuple, we only use the IP layer to classify packets.
Also we can reduce the lookup time if flow-based treatment is
required, and we can do this even with IPsec encryption and
fragmentation. Therefore, for traffic needing other than best-effort
service, such as real-time applications, the flow label can be used
to set different values to represent different flows, and each node
may provide different flow-specific treatments by looking at the flow
label value. This is more fine-grained than differentiated services
(Diffserv) [Carpenter], [RFC2474] but need not be less efficient.
An additional important rule in the standard [RFC3697] effectively
forbids any encoding of meaning in the bits of the flow label. To be
exact, the standard states that "IPv6 nodes MUST NOT assume any
mathematical or other properties of the flow Label values assigned by
Hu & Carpenter Expires October 21, 2010 [Page 4]
Internet-Draft Flow label use cases April 2010
source nodes." Without this rule, if a packet with a non-zero flow
label that is not from a source using a particular encoding method
reaches a node that is following that method, and if by chance its
bits would be meaningful in that method, the label would be
misinterpreted.
The standard also states "Router performance SHOULD NOT be dependent
on the distribution of the Flow Label values. Especially, the Flow
Label bits alone make poor material for a hash key." The problem
this rule is intended to avoid is that if a source uses a simple
method of choosing flow labels (e.g., counting up from 1), any router
that assumes pseudo-randomness, e.g., to choose alternative routes
for load-balancing, will be misled.
Note that there is no easy escape from these two rules, which we will
call the dependency prohibition. Unlike Diffserv code points, flow
labels are not locally significant within a single administrative
domain; they must be preserved end-to-end. In general, a router
cannot know whether a particular packet originated in a host
supporting a specific usage of the flow label. Therefore, any method
that breaks one or both of these rules will only work if there is
some method for the routers concerned to determine at line speed
which sources use the same method.
How to use flow label most effectively is not discussed in [RFC3697]
and remains the major open issue, but many researchers believe that
it can be used with reserved bandwidth to achieve customized Quality
of Service (QoS) provision. Coupled with admission control at the
edge router, this should limit congestion. However, as we will see
below, this is not the only use case proposed.
We now introduce some other open issues.
Unknown flow labels: [RFC1809] proposed that when a router receives a
datagram with an unknown flow label, it should treat it as zero.
However, the standard [RFC3697] is silent on this issue. Indeed,
some methods of flow state establishment might choose to use an
unknown label as the trigger for creating flow state.
Deleting old flow labels: When a flow finishes, how does the router
know the flow label has expired? Should this be based on a timeout,
on observation of the transport layer, or on explicit signalling?
For example, [I-D.banerjee-flowlabel-ipv6-qos] suggested that a
router will send an ICMP message to the source to delete a particular
label. The source node can then either send a KEEPLIVE message to
the router, or it can allow the router to release that label.
Choosing when to set the flow label: For what kinds of application
Hu & Carpenter Expires October 21, 2010 [Page 5]
Internet-Draft Flow label use cases April 2010
should we set up non-zero flow labels? [RFC1809] suggested not
setting it for short flows containing few bytes, but using it for
long TCP connections and some real-time applications. However, this
does not really define clear use cases.
Can we modify the flow label? [RFC3697] states that the flow label
must be delivered unchanged. There are several advantages of non-
mutable flow labels, apart from respecting the standard: the rule is
easy to understand, does not require extra processing in routers or a
signalling protocol, and allows for very simple host implementations.
Also, it is straightforward for hosts and routers to simply ignore
the flow label. However, this rule does appear to exclude any MPLS-
like or CATNIP-like use for optimized packet switching. Some authors
have objected to this feature, suggesting that switches should change
the flow label for routing purposes. We will describe these and
other proposed mechanisms in next section, and we will discuss their
advantages and disadvantages.
3. Documented proposals for the flow label
In the following, we do not intend to recommend or criticise various
proposals. The intention is only to show the variety of proposals
that have been published, and how they relate to the standard. We
consider that published proposals for the flow label fall into three
broad categories, i.e., (1) improve routing performance by using
random flow label values; (2) define a QoS requirement in the flow
label field; (3) use the flow label to extend existing QoS
architectures such as Diffserv. Across these categories, we observe
various options to set up the flow label value.
3.1. Specify the flow label as a pseudo-random value
For example, [LinTseng] specifies a 17-bit pseudo-random value. The
following figure shows the proposed flow label structure, which
assumes that routers can support flow label and DiffServ
architectures.
o The Label Flag (LF) bit: 1 means this type of flow label is
present. We note that this encoding breaks the dependency
prohibition in [RFC3697], since a source that does not use this
method may also set the LF bit.
o The Label type (LT): 2 bits which describe the type of packet.
o The Label Number (LN): which is randomly generated by the source
node.
[LinTseng] also describes a signalling process between source,
routing and destination nodes based on this label structure and on
the IPv6 traffic class byte, in order to reserve and release router
Hu & Carpenter Expires October 21, 2010 [Page 6]
Internet-Draft Flow label use cases April 2010
resources for a given flow within a given traffic class. The pseudo-
random value is used to uniquely identify a given flow.
Flow Label Specification (figure simplified from [LinTseng])
+--+----+-----------------------------+
| 1| 2 | 17 bits |
+--+----+-----------------------------+
|LF| LT | LN |
+--+----+-----------------------------+
LF 0 Disable
1 Enable
LT 00 Flow label requested by source
01 Flow label returned by destination
10 Flow label for data delivery
11 Flow label terminates connection
LN Random number created by source
[I-D.blake-ipv6-flow-label-nonce] states that the off-path spoofing
attack has become a big issue for TCP and other transport-layer
applications, and claims that in IPv6 we can set a random value in
the flow label to make the packet header more complex and less easy
for the attacker to guess. The two ends of the session will agree on
flow label values during the SYN/ACK exchange, but off-path attackers
will be unlikely to guess the agreed value. Naturally, on-path
attackers who can observe the flow labels in use can trivially defeat
this protection.
There have been numerous informal discussions of using random flow
labels to allow load-balancing or at least load-sharing. However,
concerns about the dependency prohibition have generally prevented
such proposals from being written up until recently
[I-D.carpenter-flow-ecmp].
3.2. Specify QoS parameters in the flow label
[Prakash] is an example proposing to utilize the flow label to
indicate required QoS parameters in detail. It uses the first few
bits of the flow label field as codes to support different
approaches, as summarized in following table. Again, this breaks the
dependency prohibition in [RFC3697], since a source that does not use
this method may also set the first two bits to non-zero.
Classification for various approaches (from [Prakash])
Hu & Carpenter Expires October 21, 2010 [Page 7]
Internet-Draft Flow label use cases April 2010
Bit Pattern Approach
------------------------------------------------------------------
00 No QoS requirement (Default QoS value)
01 Pseudo-Random value used for the value of Flow-Label
10 Support for Direct Parametric Representation
1100 Support for the DiffServ Model
1101 Reserved for future use
111 Reserved for future use
This method does allow for a pseudo-random option, but also adds
options for a direct QoS request and for Diffserv. In the direct QoS
parameters approach, 18 bits are used to encode requirements for one
way delay, IP delay variation, bandwidth and one way packet loss.
The proposal appears to assume that RSVP mechanisms are used to
actually implement these QoS parameters.
This proposal allows use of flow label for various important QoS
models, so the end user and service provider can choose the most
suitable model for their situation; [Prakash] claims that "this
proposal is simple, scalable, modular and generic implementation to
provide for QoS using the IPv6 flow label field".
Similarly, [LeeKim] defines the flow label field in five parts, with
the first 3 bits used as an approach type, because the authors have
defined two approaches: Random number and Hybrid. If the first 3
bits equal "001" that means the flow label will be used as the random
identifier of the flow, or if they equal "101", it means the
remaining bits will include the QoS requirement for this packet,
subdivided into traffic type (stringent or best effort), bandwidth,
buffer, and delay requirements. Once again the dependency
prohibition in [RFC3697] is broken. This proposal also includes
throughput monitoring and dynamic capacity allocation. Effectively
this proposal uses the flow label both to signal Intserv-like QoS
requirements and to classify traffic into Diffserv-like virtual
label-switched paths. Note that packets with a "random" flow label
are mapped into a generic (best effort) virtual path.
After simulating this architecture, the authors claim that the scheme
improves capacity utilization for QoS traffic and performance for
real-time traffic, whereas the "random" traffic experiences best
effort service.
3.3. Use flow label to control switching
[I-D.chakravorty-6lsa] and [Chakravorty] describe an architectural
framework called "IPv6 Label Switching Architecture" (6LSA). In
6LSA, network components identify a flow by looking at the flow label
field in the IPv6 packet header; all packets with the same flow label
Hu & Carpenter Expires October 21, 2010 [Page 8]
Internet-Draft Flow label use cases April 2010
must receive the same treatment and be sent to the same next hop.
However, 6LSA resembles MPLS by considering that a label only has
meaning between 6LSA routers, and setting the flow label at each hop.
If the original source sets a non-zero flow label, there is no
mechanism to restore it before delivery, a fundamental breach of
[RFC3697]. The authors of [I-D.chakravorty-6lsa] did at one stage
discuss using an IPv6 hop-by-hop option to correct this problem, but
this has not been documented. This is a more serious problem than
simply breaking the dependency prohibition
Unlike traditional routing algorithms, but like MPLS, 6LSA packets
are classified into a Forwarding Equivalence Class (FEC), and routers
forward packets on different paths by looking at the FEC. Like
previous solutions, the authors divide the flow label field into
three parts. The first 3 bits identify the FEC, which will help the
router or 6LSA nodes to group the IP packets that receive the same
forwarding treatment and forwarding them on the same virtual path.
The following 4 bits describe the application type, and the final 13
bits (defined by each node or a group of nodes) specify the hop-
specific label. From the table below, we can see the FEC has 6 major
categories, each with up to 16 subcategories.
Flow Label Specification (shortened from [I-D.chakravorty-6lsa])
Hu & Carpenter Expires October 21, 2010 [Page 9]
Internet-Draft Flow label use cases April 2010
+--------------------------+-------------+--------------------------+
| FEC (First 3 Bits) | Next 4 Bits | Purpose |
+--------------------------+-------------+--------------------------+
| No FEC (000) | 0000 | |
| Domain Specific (000) | 0001 - 1111 | |
| ------------------------ | | |
| VPN (001) | 0001 | (IPSec - Tunnel Mode) |
| | 0010 | (IPSec - Transport Mode) |
| | 0011 | (Special Encryption) |
| | 0100 | (VRF) |
| | 0101 | (End Network Specific) |
| | 0110 - 1111 | (Reserved) |
| ------------------------ | | |
| TE Subset/ | 0001 | (DiffServ) |
| QoS Enhancement (010) | 0010 | (RSVP) |
. . .
| | 1111 | (Reserved) |
| ------------------------ | | |
| Encapsulation (011) | 0001 | (IPv6 in IPv6) |
| | 0010 | (IPv4 in IPv6) |
| | 0011 | (Other in IPv6) |
| | 0100 | (Enterprise Specific) |
| | 0101 - 1111 | (Reserved) |
| ------------------------ | | |
| Enterprise Specific(111) | 0000 - 1111 | (Reserved) |
+--------------------------+-------------+--------------------------+
The authors claim that fast switching using 20-bit labels instead of
128-bit IPv6 addresses will provide memory and processing savings, as
well as network management advantages. "It also allows a network
management entity updating available label tables, across the network
to reduce man-in-the-middle attacks [sic]" [I-D.chakravorty-6lsa].
We note that a similar proposal for QoS-based switching of IPv6
packets [I-D.roberts-inband-qos-ipv6] is designed to use a hop-by-hop
option, which has not so far been allocated by the IETF. Proposals
related to this have been discussed by the Telecommunications
Industry Association and the ITU-T
[I-D.adams-tsvwg-flow-signalling-codepoint].
3.4. Diffserv use of IPv6 flow label
[I-D.banerjee-flowlabel-ipv6-qos] uses the flow label field instead
of the traffic class; this proposal suggests the incoming flow label
can indicate the QoS requirement by matching a Diffserv classifier.
The authors have used the first three bits to indicate this, and the
following 16 bits to indicate Differentiated Services Per-Hop
Behavior Identification code (Diffserv PHB-ID) [RFC3140]; the last
Hu & Carpenter Expires October 21, 2010 [Page 10]
Internet-Draft Flow label use cases April 2010
bit is reserved for future use. This method too breaks the
dependency prohibition in [RFC3697].
[I-D.martinbeckman-ietf-ipv6-fls-ipv6flowswitching] blends the flow
label as an MPLS-like switching tag with Diffserv. Unlike 6LSA, the
method attempts to overcome the dependency prohibition by using one
bit in the Diffserv Code Point [RFC2474] to indicate that the flow
label is a switching tag. In this way, a router can determine
whether the flow label conforms to [RFC3697] or to
[I-D.martinbeckman-ietf-ipv6-fls-ipv6flowswitching]. In
[I-D.martinbeckman-ietf-ipv6-amp-ipv6hcamp], the same author proposes
using the flow label as a way of compressing IPv6 headers by hashing
the addresses into the flow label, again using the Diffserv Code
Point to mark the packets accordingly.
We are not aware of any proposals combining the flow label with the
other two Internet QoS architectures (Integrated Services [RFC2210]
and Next Steps in Signaling (NSIS) [RFC4080]), except for generic
recognition that the flow label can be inspected by a packet
classifier. There has been some discussion of possible flow label
use in both the ROLL (Routing Over Low power and Lossy networks) and
MEXT (Mobility EXTensions for IPv6) working groups of the IETF.
4. Discussion
Firstly we notice that three aspects of the current standard
[RFC3697] have caused problems to many designers:
1. The non-mutability of labels
2. "Nodes MUST NOT assume any mathematical or other properties of
the Flow Label"
3. "Router performance SHOULD NOT be dependent on the distribution
of the Flow Label values."
Taken together, these rules essentially forbid any encoding of the
semantics of a flow, or of any information about its path, in the
flow label. This was intentional, in accordance with the stateless
nature of the Internet architecture and with the end-to-end principle
[Saltzer]. It was also felt that QoS encoding via Diffserv was
sufficient, and that the requirement for high-speed switching could
be met by MPLS. But this means that the majority of the proposals
described above breach the standard and the intent of the standard.
The authors often appear to be using the flow label either as an
MPLS-like switching handle, or as an encoded QoS signal. In fact, we
consider that only [I-D.blake-ipv6-flow-label-nonce], and possibly
[I-D.martinbeckman-ietf-ipv6-fls-ipv6flowswitching] and
[I-D.martinbeckman-ietf-ipv6-amp-ipv6hcamp], strictly respect the
intention of the standard. [I-D.carpenter-flow-ecmp] is also
Hu & Carpenter Expires October 21, 2010 [Page 11]
Internet-Draft Flow label use cases April 2010
intended to conform to the standard.
What would designers need to do, if they wish to respect the
standard? There appear to be two choices. One is to simply accept
the above rules at face value, which as noted appears to be the case
in few proposals. This limits the application of the flow label. It
can be used as a nonce as in [I-D.blake-ipv6-flow-label-nonce] or as
part of the material for a hash used to share load among alternate
paths. It cannot be the only material for such a hash, because of
the dependency prohibition. The flow label could also be used, if an
application designer so chose, as a way to associate all packets
belonging to a given application session between two hosts, across
multiple transport sessions.
The other choice, for designers who wish to use the flow label to
control switching or QoS directly, is to bypass the rules within a
given domain (a set of cooperating nodes) in a way that nodes outside
the domain cannot detect. In this case, any deviation from [RFC3697]
has no possible effect outside the domain in question.
For example, to emulate the non-mutability of labels, we could
arrange that within the domain all hosts set the label to zero, the
routers set and interpret the label in any way they wish, and the
last hop router always sets the label back to zero. If a packet
arrives from outside the domain with a non-zero label, there would
need to be a method (such as a special Diffserv code) to mark this
packet so that its label would be ignored and delivered unchanged.
An alternative approach would be to standardize a hop-by-hop option
to carry the original flow label across the domain, so that it could
be changed within the domain but restored before forwarding the
packet beyond the domain.
Once we have bypassed non-mutability, we can safely bypass the
dependency prohibition for labels within the domain, because it is
now possible to ensure that the bits in the label are set according
to defined rules. Within the domain, we can treat the label as an
expanded Diffserv field, or a 6LSA label, or a random value, etc. In
fact most of the proposed designs discussed above could be "rescued."
Given the considerable number of designers who have proposed such
solutions, and the almost complete lack of designs using the standard
rules [RFC3697], it seems reasonable to ask whether the current
standard has value.
5. Conclusion
As real time traffic increases, the delay and packet loss problem for
Hu & Carpenter Expires October 21, 2010 [Page 12]
Internet-Draft Flow label use cases April 2010
real time streams has become too serious to be neglected, and many
researchers have claimed that the flow label field in the IPv6 header
would be a possible solution. Various proposals assert that the flow
label field will improve QoS. However, we find that such proposals
breach the IETF standard for use of the flow label. More work is
required to find a new structure which will respect the standard and
also provide an effective way to use the flow label. If this cannot
be achieved, this aspect of the IPv6 standard may need to be revised.
6. Security Considerations
The flow label is not protected in any way and can be forged by an
on-path attacker. Off-path attackers may be able to guess a valid
flow label unless a pseudo-random value is used. Specific usage
models for the flow label need to allow for these exposures. For
further discussion, see [RFC3697].
7. IANA Considerations
This document requests no action by IANA.
8. Acknowledgements
Valuable comments and contributions were made by ...., and others.
This document was produced using the xml2rfc tool [RFC2629].
9. Change log
draft-hu-flow-label-cases-00: first I-D version, 2010-04-19
10. Informative References
[Carpenter]
Carpenter, B. and K. Nichols, "Differentiated Services in
the Internet", Proc IEEE 90 (9) 1479-1494, 2002.
[Chakravorty]
Chakravorty, S., "Challenges of IPv6 Flow Label
implementation", Proc IEEE MILCOM2008 , 2008.
[I-D.adams-tsvwg-flow-signalling-codepoint]
song, j., Adams, J., and J. Joung, "Progress and future
Hu & Carpenter Expires October 21, 2010 [Page 13]
Internet-Draft Flow label use cases April 2010
development of Flow State Aware standards, and a proposal
for alerting nodes or end-systems on data related to a
flow", draft-adams-tsvwg-flow-signalling-codepoint-00
(work in progress), June 2008.
[I-D.banerjee-flowlabel-ipv6-qos]
Banerjee, R., "A Modified Specification for use of the
IPv6 Flow Label for providing An efficient Quality of
Service using hybrid approach",
draft-banerjee-flowlabel-ipv6-qos-03 (work in progress),
April 2002.
[I-D.blake-ipv6-flow-label-nonce]
Blake, S., "Use of the IPv6 Flow Label as a Transport-
Layer Nonce to Defend Against Off-Path Spoofing Attacks",
draft-blake-ipv6-flow-label-nonce-02 (work in progress),
October 2009.
[I-D.carpenter-flow-ecmp]
Carpenter, B. and S. Amante, "Using the IPv6 flow label
for equal cost multipath routing and link aggregation in
tunnels", draft-carpenter-flow-ecmp-02 (work in progress),
April 2010.
[I-D.chakravorty-6lsa]
Chakravorty, S., Bush, J., and J. Bound, "IPv6 Label
Switching Architecture", draft-chakravorty-6lsa-03 (work
in progress), July 2008.
[I-D.conta-diffserv-ipv6-fl-classifier]
Conta, A. and J. Rajahalme, "Amodel for Diffserv use of
the IPv6 Flow Label Specification",
draft-conta-diffserv-ipv6-fl-classifier-01 (work in
progress), November 2001.
[I-D.conta-ipv6-flow-label]
Conta, A. and B. Carpenter, "A proposal for the IPv6 Flow
Label Specification", draft-conta-ipv6-flow-label-02 (work
in progress), July 2001.
[I-D.itojun-ipv6-flowlabel-api]
Hagino, J., "Socket API for IPv6 flow label field",
draft-itojun-ipv6-flowlabel-api-01 (work in progress),
April 2001.
[I-D.martinbeckman-ietf-ipv6-amp-ipv6hcamp]
Beckman, M., "IPv6 Header Compression via Addressing
Mitigation Protocol (IPv6 AMP)",
Hu & Carpenter Expires October 21, 2010 [Page 14]
Internet-Draft Flow label use cases April 2010
draft-martinbeckman-ietf-ipv6-amp-ipv6hcamp-01 (work in
progress), March 2007.
[I-D.martinbeckman-ietf-ipv6-fls-ipv6flowswitching]
Beckman, M., "IPv6 Dynamic Flow Label Switching (FLS)",
draft-martinbeckman-ietf-ipv6-fls-ipv6flowswitching-03
(work in progress), March 2007.
[I-D.metzler-ipv6-flowlabel]
Metzler, J. and S. Hauth, "An end-to-end usage of the IPv6
flow label", draft-metzler-ipv6-flowlabel-00 (work in
progress), November 2000.
[I-D.roberts-inband-qos-ipv6]
Roberts, L. and J. Harford, "In-Band QoS Signaling for
IPv6", draft-roberts-inband-qos-ipv6-00 (work in
progress), July 2005.
[LeeKim] Lee, I. and S. Kim, "A QoS Improvement Scheme for Real-
Time Traffic Using IPv6 Flow Labels", Lecture Notes in
Computer Science Vol. 3043, 2004.
[LinTseng]
Lin, C., Tseng, P., and W. Hwang, "End-to-End QoS
Provisioning by Flow Label in IPv6", JCIS , 2006.
[Prakash] Prakash, B., "Using the 20 bit flow label field in the
IPv6 header to indicate desirable quality of service on
the internet", University of Colorado (M.Sc. Thesis),
2004.
[RFC1707] McGovern, M. and R. Ullmann, "CATNIP: Common Architecture
for the Internet", RFC 1707, October 1994.
[RFC1710] Hinden, R., "Simple Internet Protocol Plus White Paper",
RFC 1710, October 1994.
[RFC1752] Bradner, S. and A. Mankin, "The Recommendation for the IP
Next Generation Protocol", RFC 1752, January 1995.
[RFC1809] Partridge, C., "Using the Flow Label Field in IPv6",
RFC 1809, June 1995.
[RFC1883] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 1883, December 1995.
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated
Services", RFC 2210, September 1997.
Hu & Carpenter Expires October 21, 2010 [Page 15]
Internet-Draft Flow label use cases April 2010
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474,
December 1998.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999.
[RFC3140] Black, D., Brim, S., Carpenter, B., and F. Le Faucheur,
"Per Hop Behavior Identification Codes", RFC 3140,
June 2001.
[RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering,
"IPv6 Flow Label Specification", RFC 3697, March 2004.
[RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den
Bosch, "Next Steps in Signaling (NSIS): Framework",
RFC 4080, June 2005.
[Saltzer] Saltzer, J., Reed, D., and D. Clark, "End-To-End Arguments
in System Design", ACM TOCS 2 (4) 277-288, 1984.
Authors' Addresses
Qinwen Hu
Department of Computer Science
University of Auckland
PB 92019
Auckland, 1142
New Zealand
Email: qhu009@aucklanduni.ac.nz
Brian Carpenter
Department of Computer Science
University of Auckland
PB 92019
Auckland, 1142
New Zealand
Email: brian.e.carpenter@gmail.com
Hu & Carpenter Expires October 21, 2010 [Page 16]
| PAFTECH AB 2003-2026 | 2026-04-23 05:50:48 |