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]