IPng Working Groups A. Conta (Transwitch)
INTERNET-DRAFT
May 2001
A proposal for the IPv6 Flow Label
Specification
draft-conta-ipv6-flow-label-01.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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 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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This memo provides an analysis and describes a proposal for the IPv6
Flow Label, that may be regarded as creating a certain degree of
limitations.
1. Introduction
This document contains an analysis of the current definition of the
IPv6 flow label, and its implications. It further specifies a
proposal for the IPv6 Flow Label. At this point, it is rather a place
holder, a stake in the ground, for a couple of ideas that have to be
further discussed, and developed.
Conta Expires in six months [Page 1]
INTERNET-DRAFT Proposal for IPv6 Flow Label May 25, 19101
The IPv6 flow label is a function that, as it was designed, can be
used towards a more efficient processing of packets in lookup, or
quality of service engines in IPv6 forwarding devices. However the
current IPv6 flow label definition and specification can be further
clarified or even improved in particular in regards to Differentiated
Services Quality of Service. So, this specification attempts to make
clarifications, and suggests some additions or modifications to the
definition and specification of the IPv6 flow label, which in the
view of the author would be an improvement.
The keywords MUST, MUST NOT, MAY, OPTIONAL, REQUIRED, RECOMMENDED,
SHALL, SHALL NOT, SHOULD, SHOULD NOT are to be interpreted as
defined in [KEYWORDS].
2. IPv6 Flows
A flow is a sequence of packets sent from a particular source, and a
particular application running on the source host, using a particular
host-to-host protocol for the transmission of data over the Internet,
to a particular (unicast or multicast) destination, and particular
application running on the destination host, with a certain set of
quality of service requirements.
3. Other Definitions of Flows
As IPv6 relies on Quality of Service Mechanisms defined by the
Integrated Services Architecture or the Differentiated Services
Quality of Service Architecture, it is worth considering those
architectures flow definitions:
3.1 Integrated Services Flows
The Integrated Services architecture [Intserv-Arch] defines a flow as
an abstraction which is a distinguishable stream of related datagrams
that results from a single user activity and requires the same QoS.
For example, a flow might consist of one transport connection or one
video stream between a given host pair. It is the finest granularity
of packet stream distinguishable by the Integrated Services.
Furthermore, the Integrated Services architecture [Intserv-Arch]
defines a classifier:
For the purpose of traffic control (and accounting), each incoming
packet must be mapped into some class; all packets in the same
class get the same treatment from the packet scheduler. This
Conta Expires in six months [Page 2]
INTERNET-DRAFT Proposal for IPv6 Flow Label May 25, 19101
mapping is performed by the classifier. Choice of a class may be
based upon the contents of the existing packet header(s) and/or
some additional classification number added to each packet.
A class might correspond to a broad category of flows, e.g., all
video flows or all flows attributable to a particular organization.
On the other hand, a class might hold only a single flow. A class
is an abstraction that may be local to a particular router; the
same packet may be classified differently by different routers
along the path. For example, backbone routers may choose to map
many flows into a few aggregated classes, while routers nearer the
periphery, where there is much less aggregation, may use a separate
class for each flow.
3.2 Differentiated Services Flows
The Differentiated Services architecture [Diffserv-Arch] defines a
flow or microflow as a single instance of an application-to-
application flow of packets, which is identified by the source
address, source port, destination address, destination port and
protocol id (fields in the IP and host-to-host protocol headers).
Furthermore, this architecture defines a classifier as a mechanism
that selects packets in a traffic stream based on the content of some
portion of the packet header. Two types of classifiers are defined.
The BA (Behavior Aggregate) Classifier classifies packets based on
the DS codepoint only. The MF (Multi-Field) classifier selects
packets based on the value of a combination of one or more header
fields, such as source address, destination address, DS field,
protocol ID, source port and destination port numbers, and other
information such as incoming interface.
Classifiers are used to "steer" packets matching some specified rule
to an element of a traffic conditioner for further processing.
Classifiers must be configured by some management procedure in
accordance with the appropriate TCA.
Note: For the purpose of this document, only a portion of the
definition of the classifier from the architecture [Diffserv] is
mentioned.
4. IPv6 Flow Label
The IPv6 Flow Label is defined [IPv6] as a 20 bit field in the IPv6
header which may be used by a source to label sequences of packets
for which it requests special handling by the IPv6 routers, such as
Conta Expires in six months [Page 3]
INTERNET-DRAFT Proposal for IPv6 Flow Label May 25, 19101
non-default quality of service or "real-time" service. According to
[IPv6], the nature of that special handling might be conveyed to the
routers by a control protocol, such as a resource reservation
protocol, or by information within the flow's packets themselves,
e.g., in a hop-by-hop option.
The characteristics of IPv6 flows and flow labels are further defined
in [IPv6]:
(a) A flow is uniquely identified by the combination of a source
address and a non-zero flow label.
(b) Packets that do not belong to a flow carry a flow label of zero.
(c) A flow label is assigned to a flow by the flow's source node.
(d) New flow labels must be chosen (pseudo-)randomly and uniformly
from the range 1 to FFFFF hex. The purpose of the random
allocation is to make any set of bits within the Flow Label
field suitable for use as a hash key by routers, for looking up
the state associated with the flow.
(e) All packets belonging to the same flow must be sent with the
same source address, destination address, and flow label.
(f) If packets of a flow include a Hop-by-Hop Options header, then
they all must be originated with the same Hop-by-Hop Options
header contents (excluding the Next Header field of the Hop-by-
Hop Options header).
(g) If packets of a flow include a Routing header, then they all
must be originated with the same contents in all extension
headers up to and including the Routing header (excluding the
Next Header field in the Routing header).
(h) The routers or destinations are permitted, but not required, to
verify that these conditions are satisfied. If a violation is
detected, it should be reported to the source by an ICMP
Parameter Problem message, Code 0, pointing to the high-order
octet of the Flow Label field (i.e., offset 1 within the IPv6
Conta Expires in six months [Page 4]
INTERNET-DRAFT Proposal for IPv6 Flow Label May 25, 19101
packet).
(i) The maximum lifetime of any flow-handling state established
along a flow's path must be specified as part of the description
of the state-establishment mechanism, e.g., the resource
reservation protocol or the flow-setup hop-by-hop option.
(j) A source must not reuse a flow label for a new flow within the
maximum lifetime of any flow-handling state that might have been
established for the prior use of that flow label. When a node
stops and restarts (e.g., as a result of a "crash"), it must be
careful not to use a flow label that it might have used for an
earlier flow whose lifetime may not have expired yet.
5. IPv6 Flow and Flow Label Discussion
This section is going to discuss several aspects of the flow label,
which are the target of clarifications or improvement.
5.1 End-to-end/hop-by-hop use of the IPv6 Flow Label
The definition in [IPv6] gives a definite hop-by-hop characteristic
to the flow label. The flow label is supposed to help the routing
system in processing packets whether during packet forwarding, or
whether during QoS processing. However, controversial discussion took
place around the end-to-end use and character of the flow label.
For instance it was stated that the label should be used as a
mechanism for identifying a flow by the destination end-node. Such
statements seem to be warranted by the use of the IPv6 pair of source
and destination addresses as component fields in a host-to-host
connection (virtual circuit oriented communication) or communication
(connectionless oriented) identifiers, and thus the flow label would
just be an addition or a replacement to such identifiers. However, if
the routers' packet processing is more performance critical then
end-nodes' processing, it would seem to make more sense to use the
flow label for that purpose, that is to use the flow label hop-by-hop
significance.
Using a flow label end-to-end or hop-by-hop seem to be fine in the
context of the current definition of the flow label, as long as the
non-mutable character of the flow label is maintained. The issue of
mutable or non-mutable is going to be discussed in a separate
section.
Conta Expires in six months [Page 5]
INTERNET-DRAFT Proposal for IPv6 Flow Label May 25, 19101
The discussion around the end-to-end, or hop-by-hop use of a flow
label becomes irrelevant if a certain negotiation mechanism amongst
routers and end-nodes takes place. There are examples of technologies
in which such negotiations around flow labels and flows labeling take
place. For instance the Label Distribution Protocol of MPLS is used
to exchange labels among neighboring Label Distribution Routers,
including the source and the destination of the labeled packets.
Furthermore, the Resource Reservation Protocol (RSVP) [RSVP],[RSVP-
TE] Has been extended to exchange labels between neighboring labels.
But such a mechanism, at the time of writing this specification, does
not exist for IPv6 flow labels, or as part of the IPv6 set of
specifications. However, such a mechanism could be specified in the
future, therefore the specification or the definition of the IPv6
flow label should not restrict the use of the flow label in one way
or another relative to its end-to-end or hop-by-hop characteristic.
In conclusion, the flow label could have a bivalent character in the
type of its usage, or in its significance: (i)end-to-end, and
(ii)hop-by-hop. The end-to-end significance should not preclude its
hop-by-hop significance, and vice-versa. If a node which sends
packets, associates a certain end-to-end significance to the flow
label of those packets, that significance can be meaningful also
hop-by-hop to each downstream router, all the way to the final
destination. Furthermore, the flow label could be changed in the
packet headers by the en-route routers, and restored or not to its
original value by the last hop router, as long as the end-node is
aware of what the value of the flow label should be. Certainly such a
behavior would need negotiation and state storing in the en-route
routers, in particular the last hop one.
5.2 Mutable or non-mutable IPv6 Flow Label
Another topic of controversial discussion is whether the flow label
should be mutable or non-mutable, that is it should be read-only for
routers or not.
Statements that advocate a non-mutable characteristic are certainly
based on the advantage of the simplicity implied by such a
characteristic.
Opposite statements, that the flow label should be mutable, are based
on the flexibility that this provides, in particular if the label has
a hop-by-hop significance. However, using mutable flow labels would
not work without a certain agreement, or negotiation between
neighboring nodes, or certain configuration of those routers. This
would require the use of a negotiation mechanism between neighboring
routers, or a certain setup through router management or
Conta Expires in six months [Page 6]
INTERNET-DRAFT Proposal for IPv6 Flow Label May 25, 19101
configuration, to make sure that the values or the changes made to
the flow label are known to all routers on the portion of the path of
the packet, in which the flow label changes. Some of these
mechanisms, such as MPLS LDP, or RSVP-TE, were described in the
previous section. Such a mechanism could be specified for IPv6 flow
labels.
As the hop-by-hop significance of the flow label can be enhanced by a
mutable characteristic, the specification or definition of the flow
label should not preclude this.
A mutable flow label though requires the relaxation or elimination of
the rule marked (a), (c), (d), and (j) in Section 4. These rules were
extracted from [IPv6], Appendix A.
5.3 Randomness in setting Flow Label values
The rule marked (d) in Section 4, extracted from [IPv6], Appendix A,
specifies the requirement of pseudo-randomness in setting the value
of a flow label. The reason given is the use of a hashing function,
and table for flow lookup by routers.
The use of a hashing is one possible choice for the flow lookup in
routers, or hosts.
Another possible choice is to use the label as an index in an array,
which is a direct and much faster lookup, or retrieval of the flow,
and so a contiguous set of values, starting from 1, would be more
helpful. However, the author of this document believes that the
specification of the flow label should not mandate certain
implementation choices. This would certainly require the relaxation
or elimination of rule marked (d).
5.4 Flow Label processing by Integrated Services Routers
The Integrated Services traffic classification based on flow label in
conjunction with the use of the Resource Reservation Protocols (RSVP)
for propagating the flow label value seem to be in synchronism. This
topic does not require further discussion.
5.5 Flow Label processing by Differentiated Services Routers
At the time of the writing of this document, the Differentiated
Services architecture definition of classifiers [Diffserv] does not
seem to include the classification of IPv6 packets based on flow
Conta Expires in six months [Page 7]
INTERNET-DRAFT Proposal for IPv6 Flow Label May 25, 19101
labels.
In order to support the Flow Label, a Differentiated Services IPv6
classifier definition should be added. This classifier would be a
multi-field classifier, which would include as classification fields
at least, the flow label, and the source address. To allow a wild
card source address is perhaps debatable.
Secondly, the Differentiated Services architecture does not make a
direct assumption about how flow label information gets propagated or
set in routers. Furthermore, according to the afore mentioned
architecture, the classification fields have values according to the
SLAs, and TCAs, which are contractual agreements between clients and
service providers. Therefore, the fields are known a priori, before
traffic is being generated by a source of packets. Furthermore, as
these values could be configured, or uploaded into the routers, long
before traffic is generated, it seems that the pseudo-random
character of the flow label values contradicts the model assumed by
the Differentiated Architecture. In order to resolve this
contradiction, rule marked (d) in Section 4, extracted from [IPv6],
Appendix A, should be relaxed or removed.
5.6 IPv6 classifiers efficiency
This section will address classification engines efficiency issues
5.6.1 Classifier pipe-lined or parallel processing.
As it was stated above, an IPv4 QoS multi-field classification
engine, performs a lookup of 5 or 6 fields of the IP and Host-to-host
protocol headers, in the classification rules table. As most of the
time, these headers are contiguous, the processing can be pipelined
or parallelized efficiently. Certainly, the existence of one or more
IPv4 security headers, disturbs the contiguity of the headers, but as
an encrypted packet would have the host-to-host header encrypted, it
is likely that its fields would not be part of a classification rule
for that packet's flow.
In IPv6, the potential extension headers between the IPv6 header and
the host-to-host protocols, which need to be processed sequentially,
adds a certain degree of difficulty in designing a pipe-lining or
parallel processing mechanism. The use of the flow label as a
replacement of the host-by-host fields in the classification rules
certainly alleviates this issue. Furthermore, the use of the flow
label, relaxes the issue mentioned previously with security headers.
Conta Expires in six months [Page 8]
INTERNET-DRAFT Proposal for IPv6 Flow Label May 25, 19101
5.6.2 Classification Rules Memory Requirements
One possible issue is that the classification rules that contain flow
label values are different than the classification rules that contain
host-to-host headers, and this possibly would require more memory to
store the classification rules, in particular if one aggregates IPv4,
and IPv6 classification rules. However, this issue seems to be minor.
A possible solution to the issue discussed in this section is to
compress or encode the host-to-host header information, and the
host-to-host protocol type in the flow label value. There are several
ways in which this could be achieved, but only two are suggested in
this section:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Server Port Number | H-to-H protocol|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
or:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IANA Assigned Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The "Server Port Number" is the port number assigned to the server
side of the application. This provides an identification of the
application. Obviously it does not provide the higher granularity
within an application that the use of source and destination port
provides. The reduced number of bits (12 bits out of 16) also reduces
the specification to "well-known" ports only, and applications.
The "H-to-H protocol" is the host-to-host protocol identifier, that
is, TCP, UDP, etc.... It has the same significance and would be used
the same way as the protocol identifier from a Differentiated
Services multi-field classification rule.
The "IANA Assigned Value" is a value that is assigned by IANA for a
particular application that is using a particular host-to-host
protocol, and has certain quality of service requirements. Further
to be refined.
Conta Expires in six months [Page 9]
INTERNET-DRAFT Proposal for IPv6 Flow Label May 25, 19101
Note that there is no differentiation between the two flow labels,
that is there is no field that would indicate one versus the other.
It does not need one.
5.7 Summary
In summary the following are the actions being proposed:
(i) Write a document that defines a flow label based classifier. This
is going to be a separate document.
(ii) A slight change of the flow label definition.
(iii) Removing characteristics (a), (d), (i), (j)
(iv) Relaxation of (c ), (e), (f), (g)
(v) Redefinition of (b)
As it follows:
Flow Label Definition
The IPv6 Flow Label is a 20 bit field in the IPv6 header which may be
used by a source to label sequences of packets for which it requests
special handling by the IPv6 routers, such as non-default quality of
service or "real-time" service. According to [IPv6], the nature of
that special handling might be conveyed to the routers by a control
protocol, such as a resource reservation protocol, or by information
within the flow's packets themselves, e.g., in a hop-by-hop option.
It can also be configured in routers, or simply uploaded through
management procedures.
The characteristics of IPv6 flows and flow labels are further defined
as:
(a) A flow label of zero means that the flow label field is
unused, and therefore has no significance for the packet
processing.
(b) A flow label is assigned to a flow by the flow's source node.
It can be changed en-route, with the condition that its
original significance be maintained, or restored, when
necessary. For instance if the source of the flow intended
Conta Expires in six months [Page 10]
INTERNET-DRAFT Proposal for IPv6 Flow Label May 25, 19101
that the flow label has a certain significance to the
destination end-node, than the nodes en-route, that process
and eventually change the value of the flow label, should make
sure, in conjunction with the destination end-node, that even
that if the value or significance has changed en-route, the
original information gets to its destination.
(c) The flow label must have a value between 1 and FFFFF in hex.
It identifies a flow.
It can be chosen (pseudo-)randomly in case of use with the
Integrated Services QoS model, in which the flow label is
transmitted to all routers on the path of the packet to the
final destination. The purpose of the random allocation is to
make any set of bits within the Flow Label field suitable for
use as a hash key by routers, for looking up the state
associated with the flow.
It can have a preset value, from 1 to FFFFF, if used with
Differentiated Services QoS model. The preset value of the
flow label can be configured, uploaded, or transmitted in any
other possible way, as long as it is stored in the
classification rules of the classification rules tables stored
in the forwarding engines of routers along the path of the
flow.
(d) In general, all packets belonging to the same flow are sent
with the same source address, destination address, and flow
label. However, flows can be trunked, or aggregated in
macro-flows. The flows, members of a macro-flow, may have
different source or destination addresses. The trunking, or
aggregation of flows is achieved by simply wildcarding some
bits or all bits in some of the fields of the multi-field
classification rules, which contain source address,
destination address, and flow label.
(h) The routers or destinations are permitted, but not required,
to verify that these conditions are satisfied. If a violation
is detected, it should be reported to the source by an ICMP
Parameter Problem message, Code 0, pointing to the high-order
octet of the Flow Label field (i.e., offset 1 within the IPv6
packet).
(i) There is no lifetime associated with a flow label.
Conta Expires in six months [Page 11]
INTERNET-DRAFT Proposal for IPv6 Flow Label May 25, 19101
5. Security Considerations
[tbd]
6. IANA Considerations
[tbd]
7. Acknowledgments
[tbd]
8. References
[IPv6] S. Deering, R. Hinden, "Internet Protocol Version 6
Specification", RFC 2460, December 1998.
[MPLS-Arch] Rosen, E., Viswanathan, A., and Callon, R.,
"Multiprotocol Label
Switching Architecture", Work in Progress, July 2000.
[MPLS-LDP] L. Anderson, P. Doolan, N. Feldman, A. Fredette, R.
Thomas,
"Label Distribution Protocol", Work in Progress, June 2000.
[MPLS-Encaps] Rosen, E., Rekhter, Y., Tappan, D., Farinacci, D.,
Fedorkow, G.,
Li, T., Conta, A., "MPLS Label Stack Encoding", Work in Progress,
June 2000.
[MPLS-ATM] Davie, B., Lawrence, J., McCloghrie, K., Rekhter, Y.,
Rosen, E.
and Swallow G., "MPLS Using LDP and ATM VC Switching", Work in
Progress, June 2000.
[MPLS-FR] Conta, A., Doolan, P., Malis A. "MPLS Using LDP and ATM VC
Switching", Work in
Progress, June 2000.
Conta Expires in six months [Page 12]
INTERNET-DRAFT Proposal for IPv6 Flow Label May 25, 19101
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
9. Authors' Addresses
Alex Conta
Transwitch Corporation
3 Enterprise Drive
Shelton, CT 06484
email: aconta@txc.com
Conta Expires in six months [Page 13]
767