May I offer an updated set of text which focuses on a consistent
use of the term FLOW and tries to issolate it from discussions of
state or the mechanisms to establish that:
>>>-----------------------------------------------------
IPv6 Working Group J. Rajahalme
...
Abstract
The IPv6 flow label field has been intentionally ambiguous to date.
This document will define it to allow eliminating
protocol layer violations and the related problems from flow specific
packet classifiers.
The appendix of this document provides an analysis of the current
state of the IPv6 flow label field definition.
This document proposes new text to be included in the next revision
of the IPv6 specification specifically to define the field.
This document will not specify state establishment mechanisms which
might be associated with a flow.
...
Introduction
Overview
At the time when the IPv6 specification [RFC2460] was written, the
requirements for flow label field usage were unclear.
The last several years of work in IETF provide new perspective and
framework for the standardization of the IPv6 flow label. Also, the
new charter of the IPv6 Working Group invites contributions to flow
label standardization.
A detailed problem statement is provided in section 1.2, and the
goals for the flow label definition in 1.3. Section 2 provides an
analysis of the current definition of the IPv6 flow label [RFC2460,
RFC1809, RFC2205]. Section 3 details the new definition with its
implications, with proposed text to be included in the next revision
of the IPv6 specification. Finally, section 4 provides some useful
background information on the topic.
Terminology
Flow A collection or sequence of packets which the
origin application or host has declared to be
associated. This declaration is intended to
establish equal treatment of the set, but
the mechanism for deciding what that treatment
might be is outside the scope of this
document.
Classifier An entity which selects packets based on the
content of packet headers according to defined
rules.
Control plane Part of the router taking care of router
control functions, such as routing protocols
and flow set-up signaling protocols. Controls
the functions of the forwarding plane.
Forwarding plane Part of the router receiving and forwarding
user packets; also known as "fast path".
Multi-Field (MF) A classifier which selects packets based on
Classifier the content of some arbitrary number of header
fields.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
Problem Statement
The IPv6 flow label field is designed to enable efficient
classification of packets that should receive consistent treatment.
Current IPv4 attempts to accomplish this without the flow label are
based on snooping the transport header information (port numbers).
Snooping in the transport header is problematic due to several
factors:
- The transport header may be unavailable because of either
fragmentation,
or IPsec encryption.
- Usage of IPv6 extension headers make finding the transport header
expensive, even if it is available.
- Finally, reliance on the transport header information is a layer
violation and hinders introduction of new transport layer protocols
(e.g. SCTP).
Requirements
The IPv6 protocol specification MUST state architectural rules, if
any, governing the use of the flow label field by any flow state
establishment method, and SHOULD enable co-existence of different
flow
state establishment methods in IPv6 hosts and routers.
The space of possible flow state establishment methods SHOULD NOT be
restricted to signaling protocols. For example, the IPv6
protocol specification should allow for future definition of
administratively provisioned flow handling.
The models for the use of the flow label and their specific state
establishment methods should enable eliminating the layer violations
in flow specific packet classifiers, thus facilitating evolution of
the higher protocol layers independent of the specific flow state
establishment method.
Changes to the current specification SHOULD be kept minimal, and
backwards compatibility MUST be maintained.
Discussion
For the purpose of this document the rules from the Appendix A of
[RFC2460] are rearranged 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.
(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).
*** I left this in, but I think it needs to go because this would appear
to preclude an in-line signaling protocol which wanted to
establish/refresh state without requiring every packet in the flow to be
hop-by-hop.
(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).
x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-
(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.
This has to go... we are defining the field here, not a state
establishment mechansim.
x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-
(j) A source SHOULD 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.
*** Again, we are defining the lable here, not state establishment
policy. I don't have a problem changing the text to SHOULD NOT, but the
open question is why is reuse of a flow label a problem?
Applicability of the RFC 2460 Flow Label Definition
As stated in [RFC2460], the motivation for the Flow Label field is to
request special handling for the packets belonging to a flow. The
flow label value itself has no globally recognized semantics,
but it can be used by
routers to determine the appertaining of a packet to a certain flow
(classification), and to find the state containing the definition for
the "special handling" admitted for that flow. The exact nature of
the "special handling" is defined through means other than the flow
label itself.
At the time of the definition of the rules in [RFC2460] the major
method for defining the "special handling" by routers was the
resource reservation signaling protocol (RSVP) of the "Integrated
Services" architecture [RFC1633, RFC2205]. With the hindsight it
seems that some of the flow label rules set in [RFC2460] Appendix A
are quite specific to the Integrated Services model, and block the
way forward for definition of other flow state establishment methods.
Some specific points are raised in the following subsections.
Lacking Support for RSVP WF Reservation Style
The Wildcard-Filter (WF) reservation style allows the RSVP session
destination to reserve resources for transmission by any of the
senders of the RSVP session. All the state that can be utilized for
packet classification with the WF-style session is in the RSVP
Session object, since the WF-style reservations have no Filter Specs
[RFC2205].
Currently, for end-to-end flows, the Session object can only be
specified in the terms of the destination address, transport protocol
identifier (Id), and the destination port number. This results in
layer violation in packet classification with all the identified
problems (inefficiency, fragmentation, IPsec) in spite of using the
flow label Filter Specs.
For WF-style sessions this situation could be remedied with a new
type (or "C-Type") of a Session object, where only the destination
IPv6 address and the flow label are specified (quite much like the
Session object defined in [RFC3175] for aggregated flows). For other
flow styles it might be more appropriate to have the session object
to specify the destination address only, and have each Filter Spec to
contain the source's flow label.
The problem with the current flow label rules is that if the flow
label is set according to information received from the destination
(e.g. through the Session Announcement Protocol (SAP)), it becomes
possible that the same flow label value should be used for two
different flows from the same source simultaneously. This can happen
if the source is taking part to two different sessions with different
destinations, and the flow label number generators in the
destinations happen to pick up the same number. This is in direct
contrast with the rule (a) above.
Requesting the destination to pick another flow label would be
infeasible, if the RSVP sessions already have other senders.
New Flow Label Specification
The section proposes new text to be included in the IPv6
Specification. The section 3.1 is intended to provide a new version
of the text in [RFC2460] section 6. The text in sections 3.2 and 3.3
could go to different parts of the IPv6 specification.
Proposed Flow Label Text for IPv6 Specification
The 20-bit Flow Label field in the IPv6 header MAY be used by a
source to label sequences of packets for which it requests special
handling. A non-zero flow label indicates that the IPv6 packet is
labeled. IPv6 nodes receiving a labeled IPv6 packet can use the
Source Address, Flow Label, Destination Address triplet to classify
the packet. A flow may be given some specific treatment
based on the state established on a set of IPv6 routers. The
nature of the specific treatment and the methods for the state
establishment are out of scope for this specification.
The host MUST keep track of the Flow Label values in use to avoid
trying to establish conflicting state. The Flow Label value,
when set, is end-to-end immutable.
Hosts or routers that do not support the functions of the Flow Label
field MUST set the field to zero when originating a packet, and
ignore
the field when receiving a packet. Routers MUST pass the field on
unchanged when forwarding a packet.
Requirements for State Establishment Methods
The following MUST be considered by all state establishment
methods:
(1) A flow is uniquely identified by the combination of the source
address, non-zero flow label, and the destination address.
(2) All state MUST be created with a state establishment
method. All such methods are out of scope for this
specification.
(3) Flow state with the flow label value zero SHALL NOT be created.
*** this seems like a bogus point. If someone wants to create a state
for the zero label there is no reason to preclude that.
(4) Host implementations SHOULD keep track of the flow label values
used by any state establishment methods and avoid reuse for a
given
destination.
(5) A flow label value is end-to-end immutable.
(6) The maximum lifetime of any established state must be
specified as part of the state establishment method.
*** We are defining the lable here, not state establishment policy.
(7) A source MAY reuse a flow label value any time, unless otherwise
specified by the state establishment method for the new
flow.
(8) All state establishment methods MUST allow for the case
where a router determines the offered flow to be in conflict
with state created with an other state establishment
method. If a conflict is detected, it SHOULD be reported by the
state establishment method.
*** Again, we are defining the label here, not state establishment
policy.
Implications of the New Definition
- The same flow label value can be used for different flows with the
same source addresses, provided that the destination addresses are
different (1).
- Each (source address, flow label, destination address) triplet can
uniquely determine a flow which may be used to identify the
relevant
state, if any (1).
x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-
However, multiple different triplets MAY determine the same flow,
and refer to the same flow state, depending on how the flow was
defined with the flow state establishment method.
This is an example of the confused definition for flow in this document.
A flow is an end-to-end association of packets between a src/dst pair.
There is no way multiple triplets could define the same flow. The intent
here is obvoiusly to allow multiple flows to share some established
state, but that does not mean we are redefining the context of a flow.
This text has to go.
x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-
- The only requirement for a flow label value used for the flow is
that it MUST be non-zero (3). However, specific state
establishment methods MAY expect (non-zero) pseudo-random numbers
as
flow label values.
- A non-zero flow label value is guaranteed to be received by the
destination. If the source sends the packet with a zero flow label
value, a router in the network MAY set the flow label value to a
non-zero value (5).
x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-
- A non-zero flow label value MAY be changed in transit by a router,
but the original value MUST be restored before the packet leaves
the domain of the flow state establishment method defining such a
temporary change (5).
This text is unnecessary and needs to be removed.
x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-
- state lifetime may also be indefinite, if so specified by a
state establishment method. The method MUST also provide the
means to guarantee no dangling state (6).
**** This is defining state policy, not the flow label characteristics.
Remove the last sentence at least, and the first makes no sense in
isolation.
x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-
- If new flow state is signaled through a certain path, the routers
can flush any old state they might have, and install the new flow
state (7).
*** This is bogus ... if separate apps on the same src/dst pair are
establishing flows, one MUST NOT be able to affect the other. Remove
this.
x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-
- Some host implementations of state establishment methods might
be impractical or impossible to synchronize in a host environment
(e.g., the host OS may implement one method in the kernel with no
interface to user space, where another state establishment method
is residing). Therefore the routers MUST be able to return an error
as part of the state establishment response, if the offered flow is
deemed conflicting with a state created by another state
establishment method. Local policy at the router MAY set a
precedence between the state establishment methods, and MAY be able
to cancel a lower precedence flow in favor of the new flow (8).
Again, this is defining state establishment policy, not the label. In
addition, if it is intended as a modifier to the previous bogus point,
it needs to go as well.
This is as good a place as any to note that all references to
establishing state have the word flow removed, and in several places the
individual use of the term flow has been replaced by the term state
because that is the correct context.
x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-
x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-
Conceptual Models Relating to the Flow Label
About Packet Classification
This section briefly summarizes issues relating to packet
classification relating to the use of the flow label.
Packet classification happens in a context of an agreement
("contract") between a "customer" and a "provider". The only fields
in the IP packet header that the provider can utilize in mapping a
packet to a specific customer's contract are the source and
destination address fields. We call this "customer classification".
Other information, such as incoming link, can also be used to map
packets to the customer's contract.
In the context of the contract governing the packet, the packet can
be further classified to a flow. The packet filter rules for the flow
classifiers in the network are part of the flow state. The flow state
also specifies what kind of "special handling" the packets of the
flow should get, and what are the flow traffic parameters (e.g.
bandwidth, delay, etc.) and contains the flow usage counters.
It should be noted that the actual values of the header fields
specified in a flow classifier are immaterial to the network operator
- the operator assigns no specific semantics to any of the fields.
Actual implementations will likely combine the "customer
classification" and flow classification into one filter rule, but the
conceptual separation between the two is essential.
Usage of the IPv6 flow label greatly simplifies the filter rules, as
the classification can be done on the basis of the IP addresses and
the flow label alone.
A packet classified to a flow can be further mapped to a Behavior
Aggregate (BA), enabling other routers in the network bypass flow
classification. The Differentiated Services Code Point (DSCP) field
is used to identify the selected BA [RFC2475].
The paragraphs in this section appear to be statements of fact that have
no value in defining the FL field. Either this is introductory material
about why we would even define the field, or it is irrelevant and needs
to go.
x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-
Host Considerations for the Flow Label
Choosing Flow Label Values
A specific flow state establishment method MAY set requirements on
the flow label values to be used. In any case, the host
implementation SHOULD keep track of the actual flow label values
being used between a local source address and any destination
addresses. The same facility keeping track of the flow label values
SHOULD be utilized to check whether the flow label value chosen by
the flow state establishment method is currently in use or not
between the given source and destination address pair, and SHOULD
also return a flow label value assigned by host implementation
specific algorithm, if the flow state establishment method did not
specify any specific value.
End-to-End Negotiation
Flow label values for flows SHOULD be included as part of any end-to-
end signaling dealing with the flow, e.g. RSVP for resource
reservation, or SIP/SDP for end-to-end session establishment.
RSVP usage is analogous to the familiar MF classifier, but now the
flow label replaces the need to specify the transport protocol and
port numbers for the flow classifier.
In the case of SIP either the source or the destination could have a
preference for the flow label value to be used. For example, the
destination could have an agreement with its access provider
effecting flow state for "special handling" for all packets marked
with a certain flow label value towards the destination. Therefore
the source SHOULD honor the destination's request to mark the packets
with the flow label value specified.
Relation to the Other Packet Header Fields
A flow is uniquely identified by the (source address, flow label,
destination address) triplet. Any possible constraints for the rest
of the IPv6 header fields or extension headers are to be specified by
the flow state establishment method defining the flow semantics.
Flow state establishment methods SHOULD include the Mobile IP Home
Addresses of the source and the destination in the state
establishment process, if available. This enables avoiding state
duplication on fixed portions of the path when either end changes its
Care-of Address.
Router Considerations for the Flow Label
Flow Label is End-to-End Immutable
Routers MUST NOT change the end-to-end flow label value. The
flow state establishment method SHOULD be able to tell the
destination
which value to expect on the received packets.
Flow Label Values Have No Globally Known Properties
The router MUST NOT assume any specific property on the flow label
values assigned by hosts. Router performance SHOULD NOT be dependent
on the overall distribution of the flow label values of the
established flows.
x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-
State mechanisms are not being defined here.
Conceptual Model for Flow State
This section lays out a simple conceptual model for minimal flow
state in the router forwarding plane. Actual implementations may
choose any implementation methods they like.
Router forwarding plane needs to maintain at least the following
information (flow state) for each defined flow:
Source Address, The triplet identifying the flow.
Flow Label,
Destination
Address
Flow Accounting Counter of the number of bytes or packets of
Information the flow data forwarded. The router control
plane can see from this if the flow has been
active (since it was last checked), and how
much data has been forwarded (useful for
accounting purposes).
Forwarding Defines the actual "special handling" the flow
Treatment packets are subjected to.
The flow state is created by the router control plane via a flow
state establishment method. The flow state establishment method
definitions are out of scope for this specification.
Stale flow state is deleted by the router control plane after the
flow expires, or when a new flow state overriding the old is created.
The flow state can also be explicitly deleted via the flow state
establishment method.
Classification
Packet classification is done by the router forwarding plane on the
flat 20-bit flow label, and the source and destination address
fields.
When matching flow state has been found, the router will be able to
update the Flow Accounting Information and forward the packet with
the "special handling" as specified by the Forwarding Treatment in
the flow state.
If flow state can not be located for a packet it is forwarded as if
the flow label was zero, but the flow label is left intact. No flow
state is maintained for unknown flows.
x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-
**** This text was moved from the begining, and should become an
appendix to explain why this document is doing something different.
There is no need for a laborious analysis of history as part of the base
definition for the FL field. At this point there is enough hacking on
the text that further effort needs to be done in context of a rewritten
draft.
Current non-normative text in the Appendix A of [RFC2460] seems to be
specific to the Integrated Services service model, unnecessarily
restricting future work on defining new state establishment methods,
but at the same time falls short in enabling flow label based
classification of RSVP defined end-to-end flows in all cases.
The current normative specification of the flow label field in
[RFC2460] is providing inadequate guidance for different flow state
establishment methods to be defined.
See section 2.2 for more detailed analysis of the problems with
Appendix A definition.
2. Analysis of the RFC 2460 Flow Label Specification
2.1 RFC 2460 Definition of the Flow Label
The IPv6 Flow Label is defined in [RFC2460] 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.
The Flow Label aspect of IPv6 is stated to be "still experimental and
subject to change". The only rule set for the flow label in the main
body of the [RFC2460] is that if the Flow Label field use is not
supported, it is set to zero when originating the packet, passed on
unchanged when forwarding the packet, and ignored when receiving the
packet.
2.1.1 Appendix A - Semantics and Usage of the Flow Label Field
The characteristics of IPv6 flows and flow labels, and the rules that
govern the flow label functions are further defined in [RFC2460]
Appendix A (non-normative text).
Background information on the documented semantics can be found in
[RFC1809].
According to [RFC2460], the nature of the 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.
Too Restricted Flow Classifier
The rule (a) states that a flow is uniquely identified by the source
address and the flow label. Rule (e) states that all the packets in
the flow must also have the same destination address.
This means that the source may not use the same flow label value for
flows to two different destination addresses. As stated above, this
is in violation with RSVP model, but also is unnecessarily hindering
introduction of other flow state establishment methods.
2.2.3 RSVP/Integrated Services Specific Rules
The rules (f) and (g) state that any hop-by-hop or routing headers
must be the same for all packets in a flow. This matches the Intserv
practice of nailing down the path for the flow. The intent has
probably been to enable the router to by-pass next-hop look-up and to
supply pre-processed routing header contents for the packets in the
flow.
These rules are clearly specific to the RSVP flow state establishment
method, and should not be required of flows in general. The RSVP flow
state establishment method would still mandate these rules for
Integrated Services flows. The forwarding path of a IntServ capable
router would also be able to enforce these rules for IntServ flows.
2.2.4 Too Restricting Rule for Flow Label Value Re-use
The rule (j) defines guard periods on re-use of flow label values.
This is too restrictive even in the case of Intserv flows. There
would be no harm in a (rebooted) node reusing a flow label value, as
the RSVP signaling would enable the routers to flush any old state
for the same flow classifier.
2.2.5 Unnecessary Rule for Flow Label Value Selection
Finally, it has been concluded that routers can't actually rely on
the random distribution of the flow label values as required by the
rule (d). In practice routers MUST be able to utilize algorithms that
do not depend on the statistical distribution of the flow label
values. Therefore, the rule (d) SHOULD be relaxed for flow labels in
general. However, specific flow state establishment methods MAY still
use pseudo-random numbers as flow label values.
Appendix A: Why no Flow Label Format?
The choice to not introduce any internal format for the flow label
represents the "minimal modification" policy and is intended to ease
the process of the acceptance of this specification by the IPv6
community.
This is also in line with the removal of any "flags" from the IPv6
main header design, and the recent deprecation of the term "format
prefix" in conjunction of IPv6 addresses.
In the same way as next-hop lookup should function independent of any
"format prefixes" or administrative boundaries in the IPv6 addresses,
the flow label lookup should remain independent of any possible
internal structure for the flow label values themselves.
Abstaining from eating in to the 20 bits of the flow label also keeps
maximal possibilities open for future refinement of this
specification.
Appendix B: Why no Pseudo-Random Values?
[RFC2460] motivates the requirement for pseudo random flow label
field with easing the hash key computation in routers doing flow
classification. Hashing has to deal with the problem of large hash
buckets due to unbalanced hash key distribution. If the router trusts
on the hosts to generate good hash keys, it places itself on the
mercy of the hosts. A not-so-good generator in any widely used host
platform may become problematic for the router.
In recent years the hardware implementations of the classifiers have
advanced, and schemes like search trees and Content Addressable
Memory (CAM) are widely used for classification. It is the authors'
view that the flow label specification SHOULD NOT favor any
individual classification implementation strategy, especially when it
provides no functional value for the purpose of the flow label
itself, and seems to hinder future use of the flow label for non-
signaled flow state establishment methods.
Hash implementations in routers can compute a hash key over the
(source address, flow label, destination address) triplet.
References
...
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
