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 methods. 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]
