IPng Working Groups A. Conta (Transwitch)
INTERNET-DRAFT B. Carpenter (IBM)
July 2001
A proposal for the IPv6 Flow Label
Specification
draft-conta-ipv6-flow-label-02.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
At the time when the IPv6 specifications were written, the IPv6 flow
label was still experimental, and subject to change, as the
requirements for flow support in the Internet were evolving.
The last several years of work in IETF on Internet Protocols Quality
of Service (Intserv, and Diffserv) and Multi-Protocol Label Switching
(MPLS) provide a more solid and ample architectural perspective, and
framework for the standardization of the IPv6 flow label. The new
charter of the IPv6 Working Group invites contributions to this
standardization.
This memo provides an analysis of the IPv6 definition of the flow
label, the rules governing its use, and their implications. It
Conta & Carpenter Expires in six months [Page 1]
INTERNET-DRAFT Proposal for IPv6 Flow Label July 13, 2001
subsequently makes a proposal for additions/modifications to these
rules, which improve the usability of the IPv6 flow label, in
particular with Diffserv, and its acceptance as a standard mechanism.
Conta & Carpenter Expires in six months [Page 2]
INTERNET-DRAFT Proposal for IPv6 Flow Label July 13, 2001
Table of Contents
1. Introduction....................................................4
2. IPv6 Flows......................................................5
3. Other Definitions of Flows......................................5
3.1 Integrated Services Flows...................................5
3.2 Differentiated Services Flows...............................6
3.3 MPLS Flows..................................................7
4. IPv6 Flow Label.................................................7
5. IPv6 Flow and Flow Label Discussion.............................9
5.1 Flow Label Processing by Integrated Services Routers........9
5.2 Flow Label Processing by Differentiated Services Routers....9
5.3 Flow Label based Filtering.................................10
5.4 End-to-end/Hop-by-hop use of the IPv6 Flow Label...........10
5.5 Mutable/Non-Mutable IPv6 Flow Label........................12
5.6 Using Random Numbers in setting the IPv6 Flow Label........12
5.7 IPv6 Multi-Field Classifier Efficiency.....................13
5.7.1 Classification Rules Memory Requirements.............13
5.7.2 Pipe-Lined or Parallel Processing Classification.....14
6. Summary of Proposals for the IPv6 Flow Label...................14
7. IPv6 Flow Label Definition and Characteristics.................15
7.1 IPv6 Flow Label Format.....................................17
7.1.1 Diffserv IPv6 Flow Label Format......................17
7.1.2 Other Possible IPv6 Flow Label Formats...............18
7.2 Conceptual Model for Diffserv use of IPv6 Flow Labels......18
8. Security Considerations........................................21
9. IANA Considerations............................................21
10. Acknowledgments...............................................21
11. References....................................................21
12. Authors' Addresses............................................23
Appendix A........................................................24
Conta & Carpenter Expires in six months [Page 3]
INTERNET-DRAFT Proposal for IPv6 Flow Label July 13, 2001
1. Introduction
As stated by [IPv6], at the time when the IPv6 specifications were
written, the IPv6 flow label was still experimental, and subject to
change, as the requirements for flow support in the Internet were
evolving.
The last several years of work in IETF on Internet Protocols Quality
of Service (Intserv, and Diffserv) and Multi-Protocol Label Switching
(MPLS) provide a more solid and ample architectural perspective, and
framework for the standardization of the IPv6 flow label. The new
charter of the IPv6 Working Group invites contributions to this
standardization.
Note: The IETF work on Intserv, Diffserv, MPLS is documented in several
specifications, among which the architecture documents [Intserv],
[Diffserv], and respectively [MPLS-Arch]. Intserv and Diffserv present
two alternative solutions to resolving QoS problems in the Internet,
while MPLS is a technology based on labeling traffic flows.
The IPv6 flow label is a function that, as it was designed, can be
used towards a more efficient processing of packets in next hop
lookup, quality of service, or packet filtering engines in IPv6
forwarding devices. These devices would normally be IPv6 routers or
switches. 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
(Diffserv).
Diffserv seems to have more potential, and could be used more
extensively than originally thought. For instance, for IP QoS in
access networks, Diffserv could be used on individual flows of
traffic between users and the access networks. The nature of the
contractual agreements between the users and the access network
providers seem to create an environment in which Diffserv with
Multi-Field (M-F) classifiers could be easier to use, more efficient,
and more practical as an alternative to Intserv and RSVP.
However, the Diffserv M-F classifiers, the 5 or 6 element tuple,
containing host-to-host protocol id, and source and destination
ports, is a bit of a problem when packets have extension headers
(IPv4, or IPv6). In IPv6, that is even more of an efficiency problem
(need for sequential inspection), since extension headers have a much
wider and frequent use.
The IPv6 flow label, and the use of IPv6 flow label classifiers would
be a big help in alleviating this problem. An IPv6 flow label
Conta & Carpenter Expires in six months [Page 4]
INTERNET-DRAFT Proposal for IPv6 Flow Label July 13, 2001
classifier is basically a 3 element tuple - source and destination
IPv6 addresses, and the IPv6 flow label [Diffserv-Flow-Label]. It is
an alternative to the 5 element tuple (addresses, ports, and
protocol). It will help the IPv6 flow label to achieve, as it is
supposed, a more efficient processing of packets in quality of
service engines in IPv6 forwarding devices.
This specification provides an analysis of the definition of the IPv6
flow label [IPv6], the rules governing its use, and attempts to make
clarifications to their implications. It subsequently suggests some
additions, or modifications to these rules, which in the view of the
authors, improve the usability of the IPv6 flow label, in particular
with Diffserv, and its acceptance as a standard mechanism.
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, or hosts, with a certain
set of traffic, and 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. The MPLS architecture also defines a
technique of labeling flows worth considering.
3.1 Integrated Services Flows
The Integrated Services architecture [Intserv] 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] defines a
Conta & Carpenter Expires in six months [Page 5]
INTERNET-DRAFT Proposal for IPv6 Flow Label July 13, 2001
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
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] 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 portions 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 [Diffserv-Model] 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.
Conta & Carpenter Expires in six months [Page 6]
INTERNET-DRAFT Proposal for IPv6 Flow Label July 13, 2001
3.3 MPLS Flows
As it travels from its source to its final destination, an IP packet
is being forwarded from one router to the next, each router making an
independent forwarding decision (next hop) based on the packet's IP
header, and routing information processed and stored. Choosing the
next hop can be thought of as the composition of two functions. The
first function partitions the entire set of possible packets into a
set of "Forwarding Equivalence Classes (FECs)" [MPLS-Arch]. The
second maps each FEC to a next hop. Insofar as the forwarding
decision is concerned, different packets, which get mapped into the
same FEC, are indistinguishable. All packets, which belong to a
particular FEC, and which travel from a particular node, will follow
the same path (or if certain kinds of multi-path routing are in use,
they will all follow one of a set of paths associated with the FEC).
In MPLS, the assignment of a particular packet to a particular FEC
results in a label being associated to that FEC. When a packet is
forwarded to its next hop, the label is sent along with it; that is,
the packets are "labeled" before they are forwarded. Once a packet is
labeled, at subsequent hops, the forwarding is done based on the MPLS
label rather than the information in the IP header. The label is used
as an index into a table which specifies the next hop, and a new
label. The old label is replaced with the new label, and the packet
is forwarded to its next hop.
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
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, or the rules that
govern the flow label functions are further defined in [IPv6]. For
the purpose of this document the text from one paragraph in [IPv6]
was rearranged as an item list, as follows:
(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.
Conta & Carpenter Expires in six months [Page 7]
INTERNET-DRAFT Proposal for IPv6 Flow Label July 13, 2001
(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
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.
Conta & Carpenter Expires in six months [Page 8]
INTERNET-DRAFT Proposal for IPv6 Flow Label July 13, 2001
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 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.
The capability to specify a filter based on source, and destination
addresses, and flow label presents the advantage of having all the
filtering elements in one header, as opposed to multiple headers.
5.2 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, nor to exclude explicitly the classification of IPv6
packets based on flow labels. The definition in [Diffserv-Model] is
general enough to invite the use of the flow label.
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, as the IPv6
specification [IPv6] suggests. To allow and use a wild card source
address is perhaps debatable. The MF classifier could be extended
with the destination address, so it would be a 3 element tuple:
source and destination addresses, and flow label. Range of addresses,
or range of flow labels may be specified.
The definition of a MF classifier based on source, and destination
addresses, and flow label presents the advantage of having all the
classification elements in one packet header, as opposed to scattered
in one packet's multiple headers, that is, the IPv6 main header, and
transport (or host-to-host) header.
According to the Differentiated Services architecture [Diffserv] the
classification fields have values according to the Service Level
Agreemnts (SALs), and Traffic Conditioning Agreements (TCAs),
(Service Level Specifications -- SLSs, and Traffic Conditioning
Specifications -- TCSs) which are contractual agreements between
network clients and network service providers. The flow label based
Diffserv MF classifier would follow the same model, and would rely on
Conta & Carpenter Expires in six months [Page 9]
INTERNET-DRAFT Proposal for IPv6 Flow Label July 13, 2001
the flow label which is a field with a value or range of values on
which clients and service providers would have to agree on. That
value, or value ranges of the flow labels would be reflected in SLAs,
TCAs, SLSs, and TCSs.
As the Diffserv classifier fields are known a priori, before traffic
is being generated by a source of packets, the same should apply to
the flow label classifier and the flow label value. This is
contradicted by a random generation of the flow label value. In order
to resolve this contradiction, rule marked (d) in Section 4,
extracted from [IPv6], Appendix A, which states that the flow label
should be pseudo-random, must be relaxed or removed (a subsequent
section is a summary of proposals).
5.3 Flow Label based Filtering
A similar problem as the Multi-Field classifier contradiction
described in the section above occurs with any type of filtering that
a forwarding engine may have to perform, in which the filtering rules
are configured by a network manager, or are loaded in the forwarding
engine by methods other than a resource reservation protocol, or hop
by hop signaling. Note that the filtering may have just internal
purposes to a forwarding engine, or to a router (which is assumed may
have several forwarding engines), or to a segment of the network, or
to a network. In all of the cases enumerated above, the expectation,
or assumption is that the IPv6 header carries in its fields a set of
predictable, or well determined values. This is not the case, if the
flow label has a randomly chosen value.
This problem of not being able to configure or load filtering rules,
which are based or are including the flow label, can be resolved
simply by relaxing or removing the rule marked (d) in Section 4,
extracted from [IPv6], Appendix A, which is that the flow label must
be a random number.
5.4 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
Conta & Carpenter Expires in six months [Page 10]
INTERNET-DRAFT Proposal for IPv6 Flow Label July 13, 2001
and destination addresses as component fields in 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, as the author of this document believes, 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.
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 [MPLS-
LDP] is used to exchange labels among neighboring MPLS Routers,
including the source and the destination of the labeled packets.
Furthermore, the Resource Reservation Protocol (RSVP) [RSVP] has been
extended [RSVP-TE] to exchange labels between neighboring label
switch (MPLS) routers. 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
Conta & Carpenter Expires in six months [Page 11]
INTERNET-DRAFT Proposal for IPv6 Flow Label July 13, 2001
need negotiation and state storing in the en-route routers, in
particular the last hop one.
5.5 Mutable/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 (routers), 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 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 Label Distribution Protocol
[MPLS-LDP], or RSVP extensions for Traffic Engineering [RSVP-TE},
were briefly mentioned 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 rules marked (a), (c), (d), and (j) in Section 4. These rules
were extracted from [IPv6], Appendix A.
5.6 Using Random Numbers in setting the IPv6 Flow Label
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 hashing table for flow lookup by routers. Randomness certainly
helps if the flow label is the only criterion used in the flow
lookup.
The use of a hashing mechanism is one possible choice for the flow
Conta & Carpenter Expires in six months [Page 12]
INTERNET-DRAFT Proposal for IPv6 Flow Label July 13, 2001
lookup in routers, or hosts.
Another possible choice is to use the label as an index in an array,
which is a direct and faster lookup, or retrieval of the flow state,
and so a contiguous set of values, starting from 1, would be more
helpful, in particular if the flow label is not the only criterion
used.
However, the authors of this document believe that the specification
of the flow label should not mandate any implementation choices,
whether they are random values, with hashing functions, or just
contiguous values, with array indexing.
Furthermore, a random value in the header is introducing the
unpredictability of the field. Although this may be an argument of
philosophical nature, predictability is a necessary condition for
deterministic behavior. Deterministic behavior is a MUST in a
network. Network operators may require that packets of a flow have
always the same IPv6 content. Random values in the IPv6 flow label
certainly break such a requirement.
To resolve these issues would certainly require the relaxation or
elimination of rule marked (d), in Section 4, extracted from Appendix
A of [IPv6].
5.7 IPv6 Multi-Field Classifiers Efficiency
This section will address multi-field classification engines
efficiency issues.
5.7.1 Classification Rules Memory Requirements
When the flow label value is completely independent from host-to-host
protocol id and source and destination port information, the
classification rules that contain MF flow label classifiers are at
least partially independent from the classification rules that
contain regular MF classifiers. If somewhat the flow label could
capture the port and host-to-host protocol information, then the flow
label classifier values could be in their entirety inferred from a
regular M-F classifier values. This could help in storing
classification rules in encoding, and perhaps aggregating information
in ways in which memory consumption could be minimized. However, the
issue and the gain could be categorized as minor.
Conta & Carpenter Expires in six months [Page 13]
INTERNET-DRAFT Proposal for IPv6 Flow Label July 13, 2001
5.7.2 Pipe-Lined or Parallel Processing Classification.
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 back to back (contiguous), the position of
the fields is well-known, and therefore 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, in case of a Multi-Field Classifier, the IPv6 extension
headers that are potentially located between the IPv6 header and the
host-to-host protocol header, need to be processed sequentially,
before having access to the host-to-host protocol id, and the host-
to-host source and destination ports. This 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 (source and destination ports and protocol id) in the
classification rules certainly alleviates this issue. Furthermore,
the use of the flow label, relaxes the issue mentioned previously
with security headers.
6. Summary of Proposals for the IPv6 Flow Label
In summary, the following are the actions being proposed:
1. For the Differentiated Services M-F Classification rules to
include the IPv6 flow label classifer:
(i) Write a document that defines a flow label based classifier. This
is going to be a separate document, a Differentiated Services
specification.
(ii)Make a slight change to the flow label definition, by introducing
the Diffserv flow label format.
(iii)Rules in Appendix A of [IPv6], do not apply to Diffserv IPv6
flow labels.
2. For the Diffserv IPv6 flow labels:
(i) Redefine characteristics or rules (a), (b), (c), (i), (j) for
Diffserv IPv6 Flow Labels.
Conta & Carpenter Expires in six months [Page 14]
INTERNET-DRAFT Proposal for IPv6 Flow Label July 13, 2001
(ii) Remove characteristics (e), (f), (g) for Diffserv IPv6 flow
labels. They prevent certain ways of aggregating flows into one flow.
The following section, contains the text that specifies the newly
suggested IPv6 flow label definition and rules. They would apply to
Diffserv flows, and to the use of flow label based non-QoS filtering.
They could also apply to Intserv flows, since there is no technical
reason that would prevent that.
7. IPv6 Flow Label Definition and Characteristics
The IPv6 Flow Label is a 20 bit field in the IPv6 header which may be
used to label packets of the same packet flow, or aggregation of
flows. This labeling can be used by IPv6 Quality of Service engines
in routers, for packet classification, policing, and scheduling. It
can also be used by IPv6 filtering engines in routers, that use
filtering for various purposes. Documenting such filtering purposes
is beyond the scope of this document.
The flow label values can be communicated to routers through a
resource reservation protocol, by a flow label distribution protocol,
or by information within the flow's packets themselves, e.g., in a
hop-by-hop option. They can also be configured in routers, manually,
or by ways of some automated procedures, or simply uploaded through
management or policy control procedures.
The characteristics of IPv6 flows and flow labels are further defined
as:
(a) A flow is uniquely identified by the combination of source
address, destination address and a non-zero flow label. Diffserv
flows MAY be aggregated by specifying a range of addresses
and/or a range of flow labels (see further in (e)).
(b) A flow label of zero means that the flow label has no
significance, the field is unused, and therefore has no effect
on, or for the packet processing by forwarding, QOS, or
filtering engines.
(c) 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 that the flow label
Conta & Carpenter Expires in six months [Page 15]
INTERNET-DRAFT Proposal for IPv6 Flow Label July 13, 2001
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 when the value or significance
has changed en-route, the original information and significance
is restored when or before the packet arrives to its
destination.
If the action to be performed on a particular flow label is not
known, a router MUST not change the value of that flow label.
(d) The flow label must have a value between 1 and FFFFF in hex. It
identifies a flow. It is a preset value. No particular method is
preferred for choosing the value. However, the value MUST
satisfy the following requirements:
(i) It can be communicated to all routers on the path of the
flow to the final destination, as well as the destination node,
by ways of a resource reservation protocol, a flow label
distribution protocol, a signaling mechanism, or by any other
means. The first method is typical for the Integrated Services
model.
(ii) It can be configured, uploaded, or transmitted to a router
or a group of routers in any other possible way, as long as it
can be stored in the classification rules tables of the
forwarding engines of routers along the path of the flow to the
final destination. If the flow label is used within a
Differentiated Services framework, the values of the flow labels
are preset or agreed upon, and specified in a Service Level
Agreement (SLA), Service Level Specification (SLS), Traffic
Conditioning Agreement (TCA), or Traffic Conditioning
Specification (TCS) [Diffserv]. This model is typical of
Differentiated Services.
(e) 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. In
other words range addresses and/or flow labels can be used.
Conta & Carpenter Expires in six months [Page 16]
INTERNET-DRAFT Proposal for IPv6 Flow Label July 13, 2001
(f) 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).
(g) The Diffserv flow labels to not have a time to live rule.
However, changes to the value of a flow label of a flow, and/or
the correspondent flow label classifier values MUST be
synchronized. When the flow label value of a flow is changed,
the change must be reflected in the change of the value of the
flow label in the multi-Field flow label classifier.
7.1 IPv6 Flow Label Format
In order to preserve compatibility with the random number method of
selecting a flow label value defined in [IPv6], but relax that
definition to allow a flow label format that would work with
Diffserv, the following new format of the flow label could be used:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Pseudo-Random Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Diffserv IPv6 Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
7.1.1 Diffserv IPv6 Flow Label Format
The Diffserv IPv6 Flow Label is a number that is constructed based on
the Differentiated Services "Per Hop Behavior Identification Code"
(PHB ID) [PHB ID]:
Conta & Carpenter Expires in six months [Page 17]
INTERNET-DRAFT Proposal for IPv6 Flow Label July 13, 2001
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Per Hop Behavior Ident. Code | Res |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The "Res" bits are reserved.
Conforming to [PHB ID], the PHB ID is either directly derived from a
standard differentiated services code point [DSCP-Def], or it is an
"IANA Assigned Value". In either case, it captures the differentiated
services treatment intended to be applied to the packet. Unlike the
value of the traffic class field, it is not locally mapped and is
therefore suitable for use in an end to end header field. Although it
captures less specific information than the port numbers and protocol
number normally used in an MF classifier, it nevertheless allows for
MF classification at a differentiated service domain ingress.
7.1.2 Other Possible IPv6 Flow Label Formats
There are various other ways in which a Flow Label can be encoded,
each way with its advantages and disadvantages. Several ideas of flow
label encoding are enumerated in Appendix A.
7.2 Conceptual Model for Diffserv use of IPv6 Flow Label
Diffserv can be used in IPv6 access networks for IPv6 QoS of
individual flows of traffic between users and the access networks.
The nature of the contractual agreements between the users and the
access network providers create an environment in which Diffserv with
Multi-Field (M-F) classifiers could be easier to use, more efficient,
and more practical as an alternative to Intserv and RSVP.
The IPv6 flow label classifier is basically a 3 element tuple -
source and destination IPv6 addresses, and the IPv6 flow label
[Diffserv-Flow-Label]. It is an alternative to the 5 element tuple
(addresses, ports, and protocol). It helps the IPv6 flow label to
achieve, as it is supposed, a more efficient processing of packets
in quality of service engines in IPv6 forwarding devices.
Whether using algorithmic mapping of port numbers and protocol, IANA
values, or just a number randomly chosen, the key for the flow label
to work with Diffserv is that the "flow_label value" or range of
values MUST be known, and agreed by two sides: the network client and
the network provider. The "flow label value" is captured in SLAs,
SLSs, TCAs, TCSs. For the mechanism to work several things have to
Conta & Carpenter Expires in six months [Page 18]
INTERNET-DRAFT Proposal for IPv6 Flow Label July 13, 2001
happen:
(1.) Packets leaving the client networks carry the correct flow label
value. This can be achieved in several ways:
a. end-node IPv6 protocol stacks, and/or IPv6 applications can be
configured with the flow label "value". The flow label "value" is
set first by an application. If the application has not set a flow
label "value", then the "value" is set by the protocol stack. The
default values would be hard-coded in applications and protocol
stacks, or could result from "algorithmic mapping", if such
mappings exists. The default value could be zero, in which case the
flow label would have no significance. According to this model,
when packets are transmitted, end-nodes will force the correct flow
label in the IPv6 headers of outgoing packets.
if a. is not TRUE, then
b. the first hop routers would have to force the correct flow
label on packets leaving the network. To accomplish this role,
these routers would be configured with MF classifiers. These
routers would classify the traffic that is forwarded downstream
from, and away from the originating end-nodes. The action
subsequent to the classification would be to set the correct flow
label in each packet. Classification on such a router's input
line card, or interface would result, for the matching packets, in
a correct flow label being forced in the IPv6 headers of packets
when they are transmitted on the output interface or line card.
while it is likely that "b." would not be needed, "a." or "b." would
provide the correct flow label in packets leaving the client's
network.
(2.) Packets coming into the provider network can be policed based on
flow label. The provider, based on the SLAs, SLSs, TCAs, TCSs
agreed with the client, configures MF classifiers that look like:
C = (SA, SAPrefix, DA, DAPrefix, Flow-Label)
or
C' = (SA, SAPrefix, DA, DAPrefix, Flow-label-Min:FLow-label-Max)
Another representation of the classifier for example is:
Conta & Carpenter Expires in six months [Page 19]
INTERNET-DRAFT Proposal for IPv6 Flow Label July 13, 2001
Flow-label-classifier:
Type: IPv6-3-tuple
IPv6DestAddrValue: 1:2:3:4:5:6:7:8::1
IPv6DestPrefixLength: 128
IPv6SrcAddrValue: 8:7:6:5:4:3:2:1::2
IPv6SrcPrefixLength: 128
IPv6FlowLabel: 57
or
Flow-label-classifier:
Type: IPv6-3-tuple
IPv6DestAddrValue: 1:2:3:4:5:6:7:8::1
IPv6DestPrefixLength: 128
IPv6SrcAddrValue: 8:7:6:5:4:3:2:1::2
IPv6SrcPrefixLength: 128
IPv6FlowLabelMin: 1
IPv6FlowLabelMax: 57
and
Flow-label-classifier:
Type: IPv6-4-tuple
IPv6DestAddrValue: 1:2:3:4:5:6:7:8::1
IPv6DestPrefixLength: 128
IPv6SrcAddrValue: 8:7:6:5:4:3:2:1::2
IPv6SrcPrefixLength: 128
IPv6FlowLabel: 57
IPv6DSCP: 28
or
Flow-label-classifier:
Type: IPv6-4-tuple
IPv6DestAddrValue: 1:2:3:4:5:6:7:8::1
IPv6DestPrefixLength: 128
IPv6SrcAddrValue: 8:7:6:5:4:3:2:1::2
IPv6SrcPrefixLength: 128
IPv6FlowLabelMin: 1
IPv6FlowLabelMax: 57
IPv6DSCP: 28
The classifiers are configured in the network provider's edge
routers, etc...
The classification engines in those routers would match packet
header information to classification rules as follows:
Conta & Carpenter Expires in six months [Page 20]
INTERNET-DRAFT Proposal for IPv6 Flow Label July 13, 2001
Incoming packet header (SA, DA, Flow Label)
Match
Classification rules table entry (C or C')
From this step, the Diffserv processing continues the same way as for
any other MF Classifier [Diffserv-Model].
8. Security Considerations
This document introduces no new security concerns when the pseudo-
random flow label format is used. In the case of a diffserv flow
label, the security concerns are essentially identical to those
concerning the diffserv field (traffic class) itself, as outlined in
[DSCP-Def], {Diffserv], and [Differv-Tun].
When IPv6 packets are encrypted using ESP Transport or Tunnel Mode
[IPSec-ESP], the port and protocol numbers are hidden, but the flow
label is not. Thus MF classification remains possible even for
encrypted traffic.
9. IANA Considerations
The IPv6 flow label format specified in this document, is based on
the Differentiated Services Per Hop Behavior Identification Code (PHB
ID), specified in [PHB ID]. The PHB ID can be a IANA assigned number.
[PHD ID] contains a "IANA Considerations Section", following
guidelines stated in [CONS]. No additional IANA considerations have
to be made.
10.Acknowledgments
Some of the ideas in this draft were discussed with Thomas Eklund,
and Walter Weiss. Jochen Metzler reviewed the specification and
provided good feedback. The continued scrutiny of Steve Deering
helped refining the document.
11.References
[IPv6] S. Deering, R. Hinden, "Internet Protocol Version 6
Specification", RFC 2460, December 1998.
[Intserv] R. Braden, D. Clark, S. Shenker, "Integrated Services in
Conta & Carpenter Expires in six months [Page 21]
INTERNET-DRAFT Proposal for IPv6 Flow Label July 13, 2001
the Internet Architecture: an Overview", RFC 1633, June 1994.
[Diffserv] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W.
Weiss, "An Architecture for Differentiated Service", RFC 2475,
December 1998.
[DSCP-Def] K. Nichols, S. Blake, F. Baker, D. Black, "Definition of
the Differentiated Services Field (DS Field) in the IPv4 and IPv6
Headers", RFC 2474, December 1998.
[PHB-ID] D. Black, S. Brim, B. Carpenter, F. Le Faucheur, "Per Hop
Behavior Identification Codes", RFC 3140, June 2001.
[Diffserv-Tun] D. Black, "Differentiated Services and Tunnels", RFC
2983, October 2000.
[Diffserv-PIB] M. Fine, K. McCloghrie, J. Seligson, K. Chan, S. Hahn,
A. Smith, "Differentiated Services Policy Information Base", Work in
Progress.
[DiffServ-MIB] F. Baker, K. Chan, A. Smith "Management Information
Base for the Differentiated Services Architecture", Work in Progress.
[Diffserv-Model] Y. Bernet, S. Blake, A. Smith, D. Grossman, "An
Informal Management Model for Diffserv Routers", Work in Progress.
[Diffserv-Flow-Label] A. Conta, B. Carpenter, "A Definition of a IPv6
Flow Label Classifier", Work in Progress.
[RSVP] R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, S. Jamin.
"Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
Specification", RFC 2205, September 1997.
[MPLS-Arch] Rosen, E., Viswanathan, A., and Callon, R.,
"Multiprotocol Label Switching Architecture", RFC 3031, January
2001.
Conta & Carpenter Expires in six months [Page 22]
INTERNET-DRAFT Proposal for IPv6 Flow Label July 13, 2001
[MPLS-LDP] L. Anderson, P. Doolan, N. Feldman, A. Fredette, R.
Thomas, "Label Distribution Protocol", RFC 3036, January 2001.
[RSVP-TE] D. O. Awduche, L. Berger, D. Gan. Tony Li, Vijay
Srinivasan, George Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", Work in progress.
[IPSec-ESP] S. Kent, R. Atkinson, "IP Encapsulating Security Protocol
(ESP)", RFC 2406, November 1998.
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[CONS] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", RFC 2434, October 1998.
[Assign] Postel, J., etc.. "Assigned Numbers", STD 2, RFC 1700,
October 1994.
12.Authors' Addresses
Alex Conta
Transwitch Corporation
3 Enterprise Drive
Shelton, CT 06484
USA
Email: aconta@txc.com
Brian Carpenter
IBM
c/o iCAIR
Suite 150
1890 Maple Avenue
Evanston, IL 60201
USA
Email: brian@hursley.ibm.com
Conta & Carpenter Expires in six months [Page 23]
INTERNET-DRAFT Proposal for IPv6 Flow Label July 13, 2001
Appendix A: Other Possible IPv6 Flow Label Formats
This section enumerates several ideas, each with its positive and
negative aspects.
A possible solution to the issues discussed in section 5.7 is to
compress or encode the host-to-host header information, and the
host-to-host protocol type in the flow label value. This is an
algorithmic mapping of the port numbers and protocol into the flow
label. There are several ways in which this could be achieved, but
only two are suggested in this section.
Another format mentioned further down in this section is one in which
the length of the IPv6 headers helps locating in one step the host-
to-host header for accessing the port information.
A.1 Server Port Format - Short Format
A possible solution to the issues discussed in section 5.7 is to
compress or encode the host-to-host header information, and the
host-to-host protocol type in the flow label value. This is an
algorithmic mapping of the port numbers and protocol into the flow
label. There are several ways in which this could be achieved, but
only three are suggested in this section:
The Server Port Format is a format which is based on carrying in
the flow label the server port number of a client/server
application/communication.
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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The "Server Port Number" is the port number assigned to the server
side of the client/server application. This provides an
identification of the application, and the type of application, which
is a quite good indication of the type of QoS characteristics needed
for the traffic generated or accepted by that application. Obviously
it does not provide the finer granularity within the use of one
application on the same end-nodes, that the use of both source and
destination ports provide. That is, it cannot differentiate among
multiple instances of the same application running on the same two
communicating end-nodes. But for Differentiated services purposes, it
does not seem to really matter, since it is expected that the several
instances of an application running on the same two end-nodes, would
Conta & Carpenter Expires in six months [Page 24]
INTERNET-DRAFT Proposal for IPv6 Flow Label July 13, 2001
generate or accept traffic which is of same category, class, or
behavior.
The reduced number of bits (12 bits out of 16) limits the value to
"IANA Well-known ports", that is ports from 1 to 1023, and a subset
of "IANA registered ports" that is, from 1024 to 4095. Registered
ports have values between 1024 and 65535 [Assign].
The "H-to-H protocol" is the host-to-host protocol identifier
[Assign], that is, TCP, UDP, etc....
Advantage
The advantage of this flow label format is that the classification
rule is the typical 5 or 6 tuple format of a Diffserv M-F Classifier
[Diffserv-Model], containing the source, and destination addresses,
the source and destination ports (in which one of the two is
wildcard), the host to host protocol, and the DSCP field. So no new
classification rule format is needed, and further, it is possible to
aggregate parts of the IPv4, and IPv6 classification rules. Note that
for classifying traffic in both directions, two classification rules
must be configured. For instance a classification rule for TCP flows
on port 80, between node A, and node B:
Source Address:A
Destination Address:B
Source Port:*
Destination Port:80
Host-to-Host Protocol 6 (TCP)
would be used for all traffic outgoing, from any port, to port 80.
Source Address:A
Destination Address:B
Source Port:80
Destination Port:*
Host-to-Host Protocol 6 (TCP)
would be used for all traffic outgoing from port 80, to any port.
A.2 Server Port Format - Long Format
Observation: Since TCP, and UDP are the two major host-to-host
protocols that carry port numbers in their protocol headers, the
field occupied by the "host-to-host" protocol could be reduced to 1
bit, indicating TCP or UDP, as it follows:
.sp
Conta & Carpenter Expires in six months [Page 25]
INTERNET-DRAFT Proposal for IPv6 Flow Label July 13, 2001
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TCP Server Port Number | Res |0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP Server Port Number | Res |1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The "Res" bits are reserved.
The "TCP Server Port Number" or "UDP Server Port Number is the 16 bit
port number assigned to the server side of the client/server
application.
A.3 Header Length Format
Another possible solution to the issues discussed in section 5.7 is
to store the IPv6 headers length, that is the length of the IPv6 main
headers and IPv6 extensions headers preceding the host-to-host, or
transport header. The length of the IPv6 headers in the flow label
value would provide the information which a Diffserv QOS engine
classifier could use to locate and fetch the source and destination
ports, and apply those, along with the source and destination address
and the host-to-host protocol from the flow label, to match the
source and destination address, the source and destination ports and
the protocol identifier elements of a Diffserv M-F classifier
[Diffserv-Model].
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Length of IPv6 Headers |H-to-H protocol|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The "Length of the IPv6 Headers" allows also skipping the IPv6
headers to access directly the host-by-host header for other
purposes.
Additionally, this format is useful for classifying packets that are
not TCP or UDP, and have no source and destination ports.
With this 12 bit encoding the maximum length of the IPv6 headers that
Conta & Carpenter Expires in six months [Page 26]
INTERNET-DRAFT Proposal for IPv6 Flow Label July 13, 2001
could be represented is 4Kbytes. However, the restriction on headers
length can be significantly reduced. IPv6 headers are 8byte aligned,
therefore the length could be represented as the number of 8byte
chunks occupied by the headers, in which case the maximum length
would be 32Kbytes.
If all of the above formats would be used, then there are two ways to
separate this last type of encoding from the other two mentioned
above:
(i) always use a signaling mechanism to distribute the flow label
values, and so the type of the format would be stored as part of the
flow state.
(ii) use a bit field to discriminate the formats. For instance, a two
bit field could be used to indicate the first, second, or third type
of format.
Note:
The suggestions described in this section are in fact an exploration
of possible solutions. Each suggestion has advantages and
disadvantages. They are kept in this section at least for recording
purposes.
Conta & Carpenter Expires in six months [Page 27]
1593