I have gone through all the flow label related issues raised on the list during the
last month. In my opinion there were no big issues, but some clarifications in the
text were necessary. I have included a new revision of the text, with the summary of
the changes below.
I'd like you to raise any objections you may have against the changes ASAP, so that we
can get the document finished.
Jarno
<<draft-ietf-ipv6-flow-label-xx.txt>>
Summary of changes since -02:
Abstract:
- Added a paragraph to the Abstract to shortly motivate the Flow Label usage
1. Terminology and Definitions:
- Changed the definition of "Classifier" to the definition of a "Flow classifier"
- Flow: Deleted "(s)" from "destination(s)", as a multicast destination does not need
the plural form. This change applied elsewhere as well.
- Flow state: added "More than one flow can map to the same flow state." to clarify
the relation between a flow and flow state.
- Flow state establishment method: Changed "source" to "source or destination"
4. Flow Labeling Requirements:
- Added "in the order of precedence" before the numbered list of ways of labeling
flows to clarify that e.g. (1) (if implemented and applicable!) takes precedence over
(4), even though (1) is a MAY and (4) is a SHOULD.
- Added "If multiple flow classifiers map to the same flow state it may be desirable
to minimize the amount of state and use the same Flow Label value with all such
classifiers."
- to clarify the text about using the same Flow Label value for multiple address
pairs.
- Changed language from "verifying" and "new" to "selecting" and "unique" in relation
to the 'facility' to be more precise.
- Changed from:
"When a dynamically instantiated flow terminates, its Flow Label value MUST NOT be
reused until it is certain that all associated state has been deleted from all nodes
on the path. With some flow state establishment methods signaling new state may be
sufficient. A mechanism with a sufficiently long timeout period before reusing the
Flow Label values can also be used."
to:
"Any Flow Label value not currently assigned by the facility can be assigned by the
facility at any time. Accidental Flow Label value reuse SHOULD be prevented by not
deleting the flow from the facility before it is certain that all associated flow
specific state has been deleted from all relevant nodes. Collisions due to accidental
node reboots SHOULD be minimized by utilizing a random initial value for the Flow
Label being assigned by the facility.
The method by which the flow state is cleared from the IPv6 nodes is to be defined by
the flow state establishment method used to set up the state. This implies that IPv6
nodes SHOULD NOT establish any flow-specific state unless so instructed by a specific
flow state establishment method. With some flow state establishment methods, signaling
new state simultaneously clearing the old state from the new path may be sufficient. A
mechanism with a sufficiently long timeout period before reusing the Flow Label values
can also be used."
This should settle the discussion on the list about flow label value reuse, timeouts,
etc.
5. Flow State Establishment Requirements:
- Changed from:
"(e.g. SCTP flows with multiple addresses at either end-points, or a diffserv
classifier with an address range. See ..."
to:
"(e.g. an SCTP connection between nodes with multiple addresses, or a classifier with
an address range, see ..."
to clarify the text.
- Removed the requirement (6). This was due to feedback from the NSIS WG, and due to
the realization that exact method by which a migrating flow is identified is
immaterial to the flow label spec itself. Any form of a globally unique "session id"
could be used, and it does not need to be related to IP addresses. Furthermore, it is
up to the flow state establishment methods to define if they support flow migration or
not.
Security Considerations:
- Removed the first paragraph. The argument against it was that the flow label field
does not add any new vulnerability, compared to the case without the flow label field
usage. Finer granularity analysis can already be performed based on the other
protocols fields.
Informative References:
- Removed the reference to the personal draft
IPv6 Working Group J. Rajahalme
INTERNET-DRAFT Nokia
<draft-ietf-ipv6-flow-label-xx.txt> A. Conta
Transwitch
B. Carpenter
IBM
S. Deering
Cisco
Expires: February 2003 August 2002
IPv6 Flow Label Specification
draft-ietf-ipv6-flow-label-xx.txt
Status of this memo
This document is an Internet-Draft and is subject to 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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
This document specifies the usage of the IPv6 Flow Label field, the
requirements for IPv6 source nodes labeling flows, and the
requirements for flow state establishment methods.
The usage of the Flow Label field enables efficient IPv6 flow
classification based only on IPv6 main header fields in fixed
positions.
Rajahalme, et al. Expires: February 2003 [Page 1]
INTERNET-DRAFT draft-ietf-ipv6-flow-label-xx.txt August 2002
1. Terminology and Definitions
Flow A sequence of related packets sent from a
source to a unicast, anycast, or multicast
destination. A flow could consist of all
packets in a specific transport connection or
a media stream. However, a flow is not
necessarily 1:1 mapped to a transport
connection.
This definition should not be confused with
the more restrictive definitions for "flow"
and "microflow" in [RSVP] and [DiffServ],
respectively. This definition includes, but is
not limited to them.
Flow classifier An IP layer entity that selects packets
belonging to a flow based on the content of IP
header fields according to defined rules.
Flow state The information stored in an IP node driving
the flow classification and the flow-specific
treatment. The required information is
specified by the method defining the flow-
specific treatment. More than one flow can map
to the same flow state.
Flow state A control mechanism used to set up the flow
establishment method state. A flow state establishment method can
be either
- Dynamic, under source or destination node
control (e.g. RSVP),
- Quasi-dynamic, under network management
control,
- Static, through manual configuration, or
- Algorithmic (e.g. load spreading)
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.
2. Introduction
A flow is a sequence of related packets sent from a source to a
unicast, anycast, or multicast destination. To enable specific
processing for the flow, flow state needs to be established on the
nodes providing the flow-specific treatment. The flow state defines
what kind of treatment should be provided, and how to classify the
packets to the flow.
Rajahalme, et al. Expires: February 2003 [Page 2]
INTERNET-DRAFT draft-ietf-ipv6-flow-label-xx.txt August 2002
Traditionally, flow classifiers have been based on the 5-tuple of the
source and destination addresses, ports and the transport protocol
type (e.g. the "microflow" definition in [DiffServ]). However, some
of these fields may be unavailable due to either fragmentation or
encryption, or locating them past a chain of IPv6 option headers may
be inefficient. Additionally, dependence on higher layer headers by
the IP layer represents a layer violation, possibly hindering the
introduction of new transport layer protocols.
The 3-tuple of the Flow Label and the Source and Destination Address
fields enables efficient IPv6 flow classification, where only IPv6
main header fields in fixed positions are used. The specification of
the IPv6 Flow Label field is given in section 3 below.
The minimum level of IPv6 flow support consists of labeling the
flows. IPv6 source nodes can label known flows (e.g. TCP connections,
RTP streams), even if the node itself would not require any flow-
specific treatment. Doing this enables load spreading and receiver
oriented resource reservations, for example. Requirements for flow
labeling are given in section 4.
Specific flow state establishment methods and the related service
models are out of scope for this specification, but the generic
requirements enabling co-existence of different methods in IPv6 nodes
are set forth in section 5.
3. IPv6 Flow Label Specification
The 20-bit Flow Label field in the IPv6 header SHOULD be used by a
source to label sequences of related packets sent to a specific
unicast, anycast, or multicast destination. A non-zero Flow Label
indicates that the IPv6 packet is labeled. IPv6 nodes forwarding or
receiving a labeled IPv6 packet can use the Flow Label and Source and
Destination Address fields to classify the packet to a certain flow.
The packet MAY be given some flow-specific treatment based on the
flow state established on a set of IPv6 nodes. The nature of the
specific treatment and the methods for the flow state establishment
are out of scope for this specification.
The Flow Label value set by the source MUST be delivered unchanged to
the destination node(s).
IPv6 nodes MUST NOT assume mathematical or other non-standardized
properties of the Flow Label values assigned by source nodes. Router
performance SHOULD NOT be dependent on the distribution of the Flow
Label values. Especially, the Flow Label bits alone make poor
material for a hash key.
If an IPv6 node is not providing flow-specific treatment, it MUST
ignore the field when receiving or forwarding a packet.
Rajahalme, et al. Expires: February 2003 [Page 3]
INTERNET-DRAFT draft-ietf-ipv6-flow-label-xx.txt August 2002
4. Flow Labeling Requirements
To enable Flow Label based classification, sources MUST label all
packets belonging to a flow.
The assignment of a packet to a flow takes various forms, presented
below in the order of precedence:
(1) The source MAY take part in a signaling protocol that results in
assigning certain transport connection(s) or application data
stream(s) to specific flow(s).
(2) The source MAY be configured to assign certain transport
connection(s) or application data stream(s) to specific flow(s).
(3) The source SHOULD assign each new application data stream (e.g.
RTP streams) to a new flow.
(4) The source SHOULD assign each new transport connection (e.g.
TCP, SCTP) to a new flow.
It is necessary that flow classifiers downstream from the source can
classify packets unambiguously, i.e. that all packets which the
source has chosen to label as a single flow can be efficiently
identified as such.
To enable this, the source node MUST keep track of the Flow Label
values it is currently using or has recently used. When a new flow is
instantiated, a unique Flow Label MUST be selected for it. A Flow
Label value is considered unique if it is not currently in use with
the same Source and Destination addresses. If multiple flow
classifiers map to the same flow state it may be desirable to
minimize the amount of state and use the same Flow Label value with
all such classifiers. In this case the requirement for uniqueness
extends to all possible (Source, Destination) address pairs.
The IPv6 source node MUST provide a facility for selecting and
assigning unique Flow Label values, and for storing the Flow Label
and the associated Source and Destination Addresses currently in use.
The facility MUST be used whenever a label needs to be assigned for a
new flow. The facility SHOULD provide a programming interface with at
least the following functionality:
(1) to assign any Flow Label value for a new flow
(2) to assign a specific Flow Label for a new flow, and
(3) to delete a flow, i.e. to free a Flow Label no longer in use.
The interface definition for the facility is beyond the scope of this
document.
Rajahalme, et al. Expires: February 2003 [Page 4]
INTERNET-DRAFT draft-ietf-ipv6-flow-label-xx.txt August 2002
Any Flow Label value not currently assigned by the facility can be
assigned by the facility at any time. Accidental Flow Label value
reuse SHOULD be prevented by not deleting the flow from the facility
before it is certain that all associated flow specific state has been
deleted from all relevant nodes. Collisions due to accidental node
reboots SHOULD be minimized by utilizing a random initial value for
the Flow Label being assigned by the facility.
The method by which the flow state is cleared from the IPv6 nodes is
to be defined by the flow state establishment method used to set up
the state. This implies that IPv6 nodes SHOULD NOT establish any
flow-specific state unless so instructed by a specific flow state
establishment method. With some flow state establishment methods,
signaling new state simultaneously clearing the old state from the
new path may be sufficient. A mechanism with a sufficiently long
timeout period before reusing the Flow Label values can also be used.
With [RSVP] or [SDP] either the source or the destination of the flow
could have a preference for the Flow Label value to be used. For
example, a destination with multiple sources sending packets to it
could require all the sources to use the same Flow Label value in
order to collapse the classifier state to a single flow state entry,
instead of having separate classifier state for each source (ref. the
Wildcard-Filter reservation style in [RSVP]). Therefore the source
SHOULD honor the destination's request to mark the packets with the
Flow Label value specified.
To enable the peer(s) to know the assigned or requested Flow Label
value, the value SHOULD be included along with the Source and
Destination addresses as part of any signaling dealing with the flow,
e.g. transport layer connection set up, RSVP for resource
reservation, or SDP for media session parameters.
5. Flow State Establishment Requirements
To enable flow-specific treatment, flow state needs to be established
on all or a subset of the IPv6 nodes on the path from the source to
the destination(s). The methods for the state establishment, as well
as the models for flow-specific treatment are defined in separate
specifications.
To enable co-existence of different methods in IPv6 nodes, the
methods MUST meet the following basic requirements:
(1) A packet is classified unambiguously to a flow on the basis of
the Flow Label, and the Source and Destination Address fields.
Depending on the method semantics, multiple such triplets MAY
identify the same flow state (e.g. an SCTP connection between
nodes with multiple addresses, or a classifier with an address
range, see the RSVP Wildcard-Filter example in section 4 above).
The flow state establishment method MUST convey this classifying
information to the IPv6 nodes that need to perform the
Rajahalme, et al. Expires: February 2003 [Page 5]
INTERNET-DRAFT draft-ietf-ipv6-flow-label-xx.txt August 2002
classification. Usage of any additional header fields for flow
classification is beyond the scope of this specification.
(2) The IPv6 node facility keeping track of the Flow Label and the
associated Source and Destination Addresses MUST be utilized
when assigning Flow Label values to new flows (see section 4
above).
(3) The Flow Label value 0 is reserved for non-labeled packets.
(4) The method MUST provide the means for flow state clean-up from
the IPv6 nodes providing the flow-specific treatment. Both soft-
and hard-state methods are possible.
(5) Flow state establishment methods SHOULD be able to recover from
the case where the requested flow state cannot be supported.
Security Considerations
The use of the Flow Label field enables flow classification also in
the presence of encryption of IPv6 payloads. This allows the
transport header values to remain confidential, which may lessen the
possibilities for some forms of traffic analysis.
IANA Considerations
This specification does not define any well-known values.
Acknowledgements
The discussion on the topic in the IPv6 WG mailing list has been
instrumental for the definition of this specification. The authors
want to thank Steve Blake, Jim Bound, Francis Dupont, Robert Elz,
Tony Hain, Bob Hinden, Christian Huitema, Frank Kastenholz, Charles
Perkins, Hesham Soliman, Michael Thomas, and Margaret Wasserman for
their contributions.
Normative References
[IPv6] S. Deering, R. Hinden, "Internet Protocol Version 6
Specification", RFC 2460, December 1998.
Informative References
[DiffServ] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W.
Weiss, "An Architecture for Differentiated Service", RFC
2475, December 1998.
Rajahalme, et al. Expires: February 2003 [Page 6]
INTERNET-DRAFT draft-ietf-ipv6-flow-label-xx.txt August 2002
[RFC1809] C. Partridge, "Using the Flow Label Field in IPv6", RFC
1809, June 1995.
[RSVP] R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin,
"Resource Reservation Protocol (RSVP) Version 1
Functional Specification", RFC 2205, September 1997.
[SDP] M. Handley, V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
Authors' Addresses
Jarno Rajahalme
Nokia Research Center
P.O. Box 407
FIN-00045 NOKIA GROUP,
Finland
E-mail: [EMAIL PROTECTED]
Alex Conta
Transwitch Corporation
3 Enterprise Drive
Shelton, CT 06484
USA
Email: [EMAIL PROTECTED]
Brian E. Carpenter
IBM Zurich Research Laboratory
Saeumerstrasse 4 / Postfach
8803 Rueschlikon
Switzerland
Email: [EMAIL PROTECTED]
Steve Deering
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
USA
Email: [EMAIL PROTECTED]
Expiration Date
This memo is filed as <draft-ietf-ipv6-flow-label-xx.txt> and expires
in February 2003.
Rajahalme, et al. Expires: February 2003 [Page 7]
