[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

INTERNET-DRAFT   draft-metzler-ipv6-flowlabel-00.txt November 17, 2000

Network Working Group                           Jochen Metzler, Siemens
INTERNET-DRAFT                                   Stephan Hauth, Siemens
Expires: May 2001




                                                      November 17, 2000



               An end-to-end usage of the IPv6 flow label
                  <draft-metzler-ipv6-flowlabel-00.txt>


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   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/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.


Abstract

   IP version 6 is specified in [1], but it specifies not completely the
   usage of the flow label field that is contained in the IPv6 Header.

   This document specifies a potential use of the IPv6 flow label that
   provide to applications access to the flow label so as to distinguish
   between several flows within the application. This results in basic
   requirements on the handling of the flow label within the network.






Table of contents

   1.   Introduction.................................................2
   2.   Terminology..................................................3
   3.   End-to-end usage of the IPv6 flow label......................3
   3.1  Usage from the Application...................................3
   3.2  Flow signalling..............................................4
   3.3  Management of label space and QoS enhancements...............4
   4.   Treatment of the flow label within the network...............4
   5.   Requirements on the choice of the flow label.................5
   6.   Authors' Addresses...........................................5
   7.   References...................................................5


1.  Introduction

   IP version 6 is specified in [1], but it specifies not completely the
   usage of the flow label field that is contained in the IPv6 Header.
   The main statements of [1] are:

     o       "The 20-bit Flow Label field in the IPv6 header may be used by a
        source to label sequences of packets for which it requests special
        handling by the IPv6 routers, such as non-default quality of service or
        "real-time" service."

     o       "Hosts or routers that do not support the functions of the Flow
        Label field are required to 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."

     o       "A flow label is assigned to a flow by the flow's source node.
        New flow labels must be chosen (pseudo-)randomly and uniformly from the
        range 1 to FFFFF hex."

   However, beside those statements there are some aspects quit open
   that prevents applications to benefit from the flow.

   The authors believe that there would be a lot of applications that
   could benefit from both: flow identification and QoS enhancements by
   use of the IPv6 flow label field.

   This document specifies a potential use of the IPv6 flow label that
   provide to applications access to the flow label so as to distinguish
   between several flows within the application. This results in basic
   requirements on the handling of the flow label within the network.

   This document does not specify QoS enhancements for IPv6 by use of
   the flow label. It is the aim of this document to minimise
   restrictions to the IP network in a way that allows the application
   to make use of the flow label at one hand and allows network QoS
   enhancement by a lot of different techniques on the other hand.


2.  Terminology

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

   The understanding of the word "flow" within this document is
   compliant with [1]:

     o       "A flow is a sequence of packets sent from a particular source
        to a particular (unicast or multicast) destination for which the source
        desires special handling by the intervening routers."

     o       The flow is uniquely identified within the network by the flow
        label and its source address.

     o       All packets belonging to one flow should be treated within the
        network in the same way.


3.  End-to-end usage of the IPv6 flow label

   For  the application to make use out of the flow label, the flow
   label must have end-to-end character, at least from an application
   point of view. This does not necessarily mean that the flow label
   must not change within the network, but means that the network must
   ensure that a data sink receives a packet  of the flow with the same
   flow label as it has been sent by  the data source.


3.1     Usage from the Application

   The application must be able to specify the flow label to be used for
   each packet which is to be sent. At least it must be possible for one
   application (e.g. using only one socket) to send packets with
   different flow labels and to distinguish between those different flow
   labels and the corresponding flows.

   Applications must be able to send both: packets with flow label zero
   as well as packets with a non-zero flow label.

   It is assumed that the application can request a new flow label from
   a global instance within its host. This ensures that all requirements
   that are attached to the flow label would be fulfilled (e.g.
   uniqueness, pseudo-randomly, etc Ideally, applications should be
   capable to specify a flow label range when requesting the allocation
   of a new flow label.
   When using the flow label as described here, it can serve for a wide
   range of trunking cases, where peer applications typically exchange
   packets for a large number of mutually indenpendent flows.

   Applications that do not make use out of the flow label MUST set the
   value to zero.

   Applications MUST release unused flow labels. It is ffs. how this
   would be done and what is the behaviour in error cases.

3.2     Flow signalling

   Applications that use the flow label for flow identification may
   signal the flow label between both end points of the flow. This
   signalling should be done within an application layer protocol and
   MUST NOT effect the network layer.


3.3  Management of label space and QoS enhancements

   The label space should be managed by an global instance within a
   host. This ensures that all requirements that are attached to the
   flow label would be fulfilled by this instance.

   The flow label must be uniquely assigned per IP source address. It
   MUST be ensured that a certain label would be assigned to only one
   application. This is not really necessary for flow identification
   (the application itself could take care about it) but to avoid the
   situation when two application use the same flow label on the same
   source address but request different handling for its flow by the
   network (e.g. QoS, different destination, etc.).

   Any mechanism that makes use of the flow label (e.g. QoS enhancements
   in the network) SHOULD NOT reduce the label space by segmenting it in
   a way that reduces the label space significantly.

   How applications can participate on QoS enhancements that use the
   flow label is out of scope of this document.


4.  Treatment of the flow label within the network

   Some basic requirements on the treatment of the flow label within the
   network are necessary to ensure the end-to-end character of the flow
   label:

     o       Network elements that do not support the function of 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.

     o       Network elements that do support the function of the flow label
        field but do not know the specific flow MUST set the field to zero when
        originating a packet, ignore the field when receiving a packet, pass the
        field on unchanged when forwarding a packet and pass the whole packet on
        in a standard way. (This ensures that a host would not send a
        unauthorised flow label and routers would ignore unknown flow labels.)

     o       In the case of a application driven flow label advertisement:
        Network elements that do support the function of the flow label and know
        the specific flow label MUST process that packet in the agreed way. (It
        is assumed that the application does know how the flow label would be
        treated by the network elements.)

     o       In all other cases network elements MUST NOT change the flow
        label or MUST ensure that the original flow label would be re-set before
        the packet reaches its destination.

   All network elements that do support the function of flow labels
   should treat packets containing the same flow label and source
   address as one flow.


5.  Requirements on the choice of the flow label

   The flow label space of each host should be administered by one
   single entity. A flow label should be assigned to only one
   application at one time.

   Regarding [1] "flow labels must be chosen (pseudo-)randomly and
   uniformly from the range 1 to FFFFF hex.  The purpose of the random
   allocation is to make any set of bits within the Flow Label field
   suitable for use as a hash key by routers, for looking up the state
   associated with the flow."


6.  Authors' Addresses

   Jochen Metzler                  Tel: +49.731.9533.390
   Stephan Hauth                   Tel: +49.731.9533.309
   Siemens AG, Mobile Networks     Fax: +49.731.9533.336
   89025 Ulm                       Email: jochen.metzler@icn.siemens.de
   Germany


7. References

   1.        Deering, S. and R. Hinden, Internet Protocol, Version 6
             (IPv6) Specification, in RFC 2460. 1998. p. 37.
   2.        Bradner, S., Key words for use in RFCs to Indicate
             Requirement Levels, in RFC 2119. 1997. p. 3.

Metzler et al.                                                [PAGE 5]


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