[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-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]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/