One document matched: draft-ietf-ipv6-flow-label-00.txt-18267.txt
IPv6 Working Group J. Rajahalme
INTERNET-DRAFT Nokia
<draft-ietf-ipv6-flow-label-00.txt> A. Conta
Transwitch
B. Carpenter
IBM
S. Deering
Cisco
Expires: August 2002 February 2002
IPv6 Flow Label Specification
draft-ietf-ipv6-flow-label-00.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 hosts labeling flows, and the requirements for flow
state establishment m
Rajahalme, et al. Expires: August 2002 [Page 1]
INTERNET-DRAFT draft-ietf-ipv6-flow-label-00.txt February 2002
1. Terminology and Definitions
Classifier A forwarding plane entity which selects
packets based on the content of packet headers
according to defined rules.
Control plane Part of an IP node taking care of control
functions, such as routing protocols and flow
state establishment protocols. Controls the
functions of the forwarding plane.
Flow A sequence of related packets sent from a
source to a unicast or multicast destination.
A flow could consist of all packets in a
specific transport connection, media stream,
or any other aggregate known to the source.
Flow processing The flow-specific handling performed by the
forwarding plane on each packet of a flow
being processed. May include meters, droppers,
shapers, schedulers, etc.
Flow state The information stored in an IP node driving
the flow classification and processing. The
required information is specified by the
method defining the flow-specific handling
(e.g. diffserv, intserv).
Flow state Control plane mechanism used to set up the
establishment flow state. A flow state establishment method
can be either
- Dynamic, under host control (e.g. RSVP),
- Quasi-dynamic, under network management
control, or
- Static, through manual configuration.
Forwarding plane Part of an IP node receiving and forwarding IP
packets; also known as the "datapath"
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
Rajahalme, et al. Expires: August 2002 [Page 2]
INTERNET-DRAFT draft-ietf-ipv6-flow-label-00.txt February 2002
2. Introduction
A flow is a sequence of related packets sent from a source to a
unicast or multicast destination. To enable flow classification by
the nodes providing flow-specific handling, flow state needs to be
established.
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 behind a chain of IPv6
option headers may be inefficient. Additionally, dependence on higher
layer headers on the forwarding plane 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 hosts can label known flows (e.g. TCP connections, RTP
streams), even if the host itself would not require any flow-specific
handling. 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 hosts
and routers are set forth in section 5.
Finally, a conceptual framework for flow processing based on the flow
label is given in section 6.
3. IPv6 Flow Label Specification
The 20-bit Flow Label field in the IPv6 header MAY be used by a
source to label sequences of related packets sent to a specific
unicast 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 Source Address, Flow Label, 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 host MUST keep track of the Flow Label values in use between
specific source and destination addresses to avoid trying to
Rajahalme, et al. Expires: August 2002 [Page 3]
INTERNET-DRAFT draft-ietf-ipv6-flow-label-00.txt February 2002
establish conflicting flow state. The Flow Label value set by the
source MUST be delivered unchanged to the destination.
IPv6 nodes MUST NOT assume any specific property on the flow label
values assigned by hosts. 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.
IPv6 nodes not supporting the Flow Label field MUST set the field to
zero when originating a packet, pass the field on unchanged when
forwarding a packet, and ignore the field when receiving a packet.
4. Flow Labeling Requirements
To support e.g. receiver oriented flow state establishment, IPv6
hosts MAY label known flows. Known flows may include transport
connections, media streams, or any other aggregate known to the
source.
The IPv6 host supporting the flow label SHOULD provide a facility for
picking up unused flow label values for new flows. Specific flow
state establishment methods MAY set requirements on the flow label
values to be used. All such methods must coordinate the flow label
value usage via the host facility to avoid choosing ambiguous values.
Applications and transport protocols SHOULD use such facility to
label all new flows with unused flow label values. The Application
Programming Interface (API) to the flow label facility is beyond the
scope of this document.
Implementations MAY use the flow label value from the initial packet
from the source also for the return flow towards the source, provided
that the resulting value is not ambiguous. For example, TCP could use
the flow label value from the original SYN packet for the packets
sent in the new TCP connection.
Flow label values for flows SHOULD be included along with the source
and destination addresses as part of any end-to-end signaling dealing
with the flow, e.g. transport layer connection set up, RSVP for
resource reservation, or SDP for media session parameters.
RSVP usage is analogous to the traditional 5-tuple 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 SDP either the source or the destination of the flow
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 with specific 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.
Rajahalme, et al. Expires: August 2002 [Page 4]
INTERNET-DRAFT draft-ietf-ipv6-flow-label-00.txt February 2002
5. Flow State Establishment Requirements
To enable flow-specific handing, flow state needs to be established
on all or a subset of the IPv6 nodes on the path from the source to
the destination. The methods for the state establishment, as well as
the models for flow-specific treatment are defined in separate
specifications. These methods may be either per-flow signaled (e.g.
[RSVP]), or administratively configured (e.g. via a MIB [DSMIB]).
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 source address, non-zero flow label, and the destination
address fields. Depending on the method semantics multiple such
triplets MAY indicate the same flow state. This includes the
case where a flow state establishment method wildcards either of
the addresses. Usage of any additional header fields for flow
classification is beyond the scope of this specification.
(2) Specific methods MAY set requirements on the flow label values
to be used. In any case, the host facility keeping track of the
flow label values SHOULD be utilized to check whether the chosen
flow label value is unambiguous
(3) The Flow Label value 0 is reserved for non-labeled packets.
(4) The method MUST provide the means to guarantee no dangling flow
state. Both soft- and hard-state methods are possible.
(5) The method MUST detect the case where an IPv6 node determines
the offered flow classifier to be in conflict with flow state
created with an other method. Rules MUST be defined for
resolving such conflicts, e.g. via prioritization among the
methods or classifiers. Generally, the most specific classifier
matching the packet should take precedence, equivalent to the
longest prefix match used in making the forwarding decision. If
a conflict cannot be detected, it SHOULD be reported to the
originator by the method.
(6) Flow state establishment methods SHOULD include the Mobile IP
Home Addresses of the source and the destination in the state
establishment process, if available and if the address(es) are
not wildcarded by the method. This enables avoiding state
duplication on fixed portions of the path when either end
changes its Care-of Address.
Rajahalme, et al. Expires: August 2002 [Page 5]
INTERNET-DRAFT draft-ietf-ipv6-flow-label-00.txt February 2002
6. Flow Processing Overview
This section lays out an high-level overview for flow label based
flow processing in the router forwarding plane. Actual
implementations may choose any implementation methods they like and
will likely include many functionalities not detailed here.
The router forwarding plane needs to maintain at least the following
information (flow state) for each defined flow:
Source Address, The triplet identifying the flow. The addresses
Flow Label, can be full addresses, prefixes (ranges), or
Destination wildcards.
Address
Flow Statistics Counter of the number of bytes or packets of
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 flow-specific handling the
Treatment flow packets are subjected to.
The flow state is created by the router control plane via a flow
state establishment method.
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.
Packet classification is done by the router forwarding plane on the
flat 20-bit flow label, and the source and destination address
fields, matched against the triplets for the defined flows.
When matching flow state has been found, the router will be able to
update the flow statistics and forward the packet with the flow-
specific handling as specified by the flow state. As an example, the
packet may be mapped to a Behavior Aggregate (BA) [DiffServ],
enabling other routers in the network bypass the flow classification.
If there is no classifier match 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.
For a more detailed information model for diffserv routers, see
[DSMIB].
Rajahalme, et al. Expires: August 2002 [Page 6]
INTERNET-DRAFT draft-ietf-ipv6-flow-label-00.txt February 2002
Security Considerations
Anything that facilitates flow classification also increases the
vulnerability to traffic analysis.
The use of flow label in general enables flow classification also in
the presence of ESP headers. 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 currently 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, Christian Huitema, Frank Kastenholz, Charles Perkins,
Hesham Soliman, and Michael Thomas for their contributions.
Normative References
[IPv6] S. Deering, R. Hinden, "Internet Protocol Version 6
Specification", RFC 2460, December 1998.
Informative References
[RFC1809] C. Partridge, "Using the Flow Label Field in IPv6", RFC
1809, June 1995.
[DiffServ] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W.
Weiss, "An Architecture for Differentiated Service", RFC
2475, December 1998.
[DSMIB] F. Baker, K. Chan, A. Smith, "Management Information Base
for the Differentiated Services Architecture", Internet
Draft <draft-ietf-diffserv-mib-16.txt>, November 2001,
expires May 2002, Work in progress.
[RSVP] R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin,
"Resource Reservation Protocol (RSVP) Version 1
Functional Specification", RFC 2205, September 1997.
Rajahalme, et al. Expires: August 2002 [Page 7]
INTERNET-DRAFT draft-ietf-ipv6-flow-label-00.txt February 2002
[Conta] A. Conta, B. Carpenter, "A proposal for the IPv6 Flow
Label Specification", Internet Draft <draft-conta-ipv6-
flow-label-02.txt>, July 2001, expires January 2002, Work
in progress.
[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.
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
Expiration Date
This memo is filed as <draft-ietf-ipv6-flow-label-00.txt> and expires
in August 2002.
Rajahalme, et al. Expires: August 2002 [Page 8]
| PAFTECH AB 2003-2026 | 2026-04-23 17:41:08 |