[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]
Versions: (draft-rajahalme-ipv6-flow-label)
00 01 02 03 04 05 06 07 08 09 RFC 3697
IPv6 Working Group J. Rajahalme
INTERNET-DRAFT Nokia
<draft-ietf-ipv6-flow-label-01.txt> A. Conta
Transwitch
B. Carpenter
IBM
S. Deering
Cisco
Expires: September 2002 March 2002
IPv6 Flow Label Specification
draft-ietf-ipv6-flow-label-01.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.
Rajahalme, et al. Expires: September 2002 [Page 1]
INTERNET-DRAFT draft-ietf-ipv6-flow-label-01.txt March 2002
1. Terminology and Definitions
Classifier An IP layer entity that selects packets based
on the content of packet headers according to
defined rules.
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.
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.
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 node control (e.g.
RSVP),
- Quasi-dynamic, under network management
control, or
- Static, through manual configuration.
- 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.
Traditionally, flow classifiers have been based on the 5-tuple of the
Source and Destination Addresses, ports and the transport protocol
type. However, 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
Rajahalme, et al. Expires: September 2002 [Page 2]
INTERNET-DRAFT draft-ietf-ipv6-flow-label-01.txt March 2002
layer headers by the IP layer represents a layer violation, possibly
hindering the introduction of new transport 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 e.g. receiver oriented
resource reservations [RSVP]. 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 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 IPv6 node assigning a Flow Label value MUST keep track of all the
Flow Label, Source Address, and Destination Address triplets in use
to avoid creating conflicting classifiers.
The Flow Label value set by the source MUST be delivered unchanged to
the destination(s).
IPv6 nodes MUST NOT assume any specific property on 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: September 2002 [Page 3]
INTERNET-DRAFT draft-ietf-ipv6-flow-label-01.txt March 2002
4. Flow Labeling Requirements
To support e.g. receiver oriented flow state establishment, IPv6
source nodes SHOULD label known flows. Known flows may include e.g.
transport connections, or media streams.
The IPv6 source node MUST provide a facility for verifying and
assigning new Flow Label values, and for storing the Flow Label,
Source Address, Destination Address triplets currently in use. The
facility MUST be used whenever a label needs to be assigned for a new
flow. The facility MUST provide a programming interface with at least
three functions:
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 free the Flow Label value of a specific flow.
The interface definition is beyond the scope of this document.
Flow Label values for flows MUST be included along with the Source
and Destination addresses as part of any flow related signaling
dealing with the flow, e.g. transport layer connection set up, RSVP
for resource reservation, or SDP for media session parameters.
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 multicast destination 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 flow 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.
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 (see the RSVP Wildcard-Filter
example in section 4 above). Usage of any additional header
Rajahalme, et al. Expires: September 2002 [Page 4]
INTERNET-DRAFT draft-ietf-ipv6-flow-label-01.txt March 2002
fields for flow classification is beyond the scope of this
specification.
(2) The IPv6 node facility keeping track of the Flow Label, Source
Address, Destination Address triplets 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) The method MUST provide the means for an IPv6 node to return an
indication, if the requested flow state cannot be supported.
(6) Flow state establishment methods SHOULD include the Mobile IP
Home Addresses of the source and the destination in the state
establishment process in addition to the Care-of Addresses, if
available. This enables avoiding state duplication on fixed
portions of the path when either end changes its Care-of
Address.
Security Considerations
Anything that facilitates flow classification also increases the
vulnerability to traffic analysis.
The use of the Flow Label field in general enables flow
classification also in the presence of ESP 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.
Rajahalme, et al. Expires: September 2002 [Page 5]
INTERNET-DRAFT draft-ietf-ipv6-flow-label-01.txt March 2002
Normative References
[IPv6] S. Deering, R. Hinden, "Internet Protocol Version 6
Specification", RFC 2460, December 1998.
Informative References
[Rajahalme] J. Rajahalme, A. Conta, "An IPv6 Flow Label Specification
Proposal", Internet Draft <draft-rajahalme-ipv6-flow-
label-00.txt>, November 2001, expires May 2002, Work in
progress.
[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: jarno.rajahalme@nokia.com
Alex Conta
Transwitch Corporation
3 Enterprise Drive
Shelton, CT 06484
USA
Email: aconta@txc.com
Brian E. Carpenter
IBM Zurich Research Laboratory
Saeumerstrasse 4 / Postfach
8803 Rueschlikon
Switzerland
Email: brian@hursley.ibm.com
Steve Deering
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
USA
Email: deering@cisco.com
Rajahalme, et al. Expires: September 2002 [Page 6]
INTERNET-DRAFT draft-ietf-ipv6-flow-label-01.txt March 2002
Expiration Date
This memo is filed as <draft-ietf-ipv6-flow-label-01.txt> and expires
in September 2002.
Rajahalme, et al. Expires: September 2002 [Page 7]
Html markup produced by rfcmarkup 1.129d, available from
https://tools.ietf.org/tools/rfcmarkup/