IPng Working Groups                     A. Conta (Transwitch)INTERNET-DRAFT                                          May 2001                   A proposal for the IPv6 Flow Label                             Specification                   draft-conta-ipv6-flow-label-01.txtStatus 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   This memo provides an analysis and describes a proposal for the IPv6   Flow Label, that may be regarded as creating a certain degree of   limitations.1. Introduction   This document contains an analysis of the current definition of the   IPv6 flow label, and its implications.  It further specifies a   proposal for the IPv6 Flow Label. At this point, it is rather a place   holder, a stake in the ground, for a couple of ideas that have to be   further discussed, and developed.Conta                       Expires in six months   [Page 1]INTERNET-DRAFT        Proposal for IPv6 Flow Label         May 25, 19101   The IPv6 flow label is a function that, as it was designed, can be   used towards a more efficient processing of packets in lookup, or   quality of service engines in IPv6 forwarding devices. However the   current IPv6 flow label definition and specification can be further   clarified or even improved in particular in regards to Differentiated   Services Quality of Service. So, this specification attempts to make   clarifications, and suggests some additions or modifications to the   definition and specification of the IPv6 flow label, which in the   view of the author would be an improvement.   The keywords MUST, MUST NOT, MAY, OPTIONAL,  REQUIRED, RECOMMENDED,   SHALL, SHALL NOT, SHOULD, SHOULD NOT  are to be interpreted as   defined in [KEYWORDS].2. IPv6 Flows   A flow is a sequence of packets sent from a particular source, and a   particular application running on the source host, using a particular   host-to-host protocol for the transmission of data over the Internet,   to a particular (unicast or multicast) destination, and particular   application running on the destination host, with a certain set of   quality of service requirements.3. Other Definitions of Flows   As IPv6 relies on Quality of Service Mechanisms defined by the   Integrated Services Architecture or the Differentiated Services   Quality of Service Architecture, it is worth considering those   architectures flow definitions:3.1  Integrated Services Flows   The Integrated Services architecture [Intserv-Arch] defines a flow as   an abstraction which is a distinguishable stream of related datagrams   that results from a single user activity and requires the same QoS.   For example, a flow might consist of one transport connection or one   video stream between a given host pair.  It is the finest granularity   of packet stream distinguishable by the Integrated Services.   Furthermore, the Integrated Services architecture [Intserv-Arch]   defines a classifier:     For the purpose of traffic control (and accounting), each incoming     packet must be mapped into some class; all packets in the same     class get the same treatment from the packet scheduler.  ThisConta                       Expires in six months   [Page 2]INTERNET-DRAFT        Proposal for IPv6 Flow Label         May 25, 19101     mapping is performed by the classifier. Choice of a class may be     based upon the contents of the existing packet header(s) and/or     some additional classification number added to each packet.     A class might correspond to a broad category of flows, e.g., all     video flows or all flows attributable to a particular organization.     On the other hand, a class might hold only a single flow.  A class     is an abstraction that may be local to a particular router; the     same packet may be classified differently by different routers     along the path.  For example, backbone routers may choose to map     many flows into a few aggregated classes, while routers nearer the     periphery, where there is much less aggregation, may use a separate     class for each flow.3.2  Differentiated Services Flows   The Differentiated Services architecture [Diffserv-Arch] defines a   flow or microflow as a single instance of an application-to-   application flow of packets, which is identified by the source   address, source port, destination address, destination port and   protocol id (fields in the IP and host-to-host protocol headers).   Furthermore, this architecture defines a classifier as a mechanism   that selects packets in a traffic stream based on the content of some   portion of the packet header.  Two types of classifiers are defined.   The BA (Behavior Aggregate) Classifier classifies packets based on   the DS codepoint only.  The MF (Multi-Field) classifier selects   packets based on the value of a combination of one or more header   fields, such as source address, destination address, DS field,   protocol ID, source port and destination port numbers, and other   information such as incoming interface.   Classifiers are used to "steer" packets matching some specified rule   to an element of a traffic conditioner for further processing.   Classifiers must be configured by some management procedure in   accordance with the appropriate TCA.   Note: For the purpose of this document, only a portion of the   definition of the classifier from the architecture [Diffserv] is   mentioned.4. IPv6 Flow Label   The IPv6 Flow Label is defined [IPv6] as a 20 bit field in the IPv6   header which may be used by a source to label sequences of packets   for which it requests special handling by the IPv6 routers, such asConta                       Expires in six months   [Page 3]INTERNET-DRAFT        Proposal for IPv6 Flow Label         May 25, 19101   non-default quality of service or "real-time" service.  According to   [IPv6], the nature of that special handling might be conveyed to the   routers by a control protocol, such as a resource reservation   protocol, or by information within the flow's packets themselves,   e.g., in a hop-by-hop option.   The characteristics of IPv6 flows and flow labels are further defined   in [IPv6]:   (a)  A flow is uniquely identified by the combination of a source        address and a non-zero flow label.   (b)  Packets that do not belong to a flow carry a flow label of zero.   (c)  A flow label is assigned to a flow by the flow's source node.   (d)  New 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.   (e)  All packets belonging to the same flow must be sent with the        same source address, destination address, and flow label.   (f)  If packets of a flow include a Hop-by-Hop Options header, then        they all must be originated with the same Hop-by-Hop Options        header contents (excluding the Next Header field of the Hop-by-        Hop Options header).   (g)  If packets of a flow include a Routing header, then they all        must be originated with the same contents in all extension        headers up to and including the Routing header (excluding the        Next Header field in the Routing header).   (h)  The routers or destinations are permitted, but not required, to        verify that these conditions are satisfied.  If a violation is        detected, it should be reported to the source by an ICMP        Parameter Problem message, Code 0, pointing to the high-order        octet of the Flow Label field (i.e., offset 1 within the IPv6Conta                       Expires in six months   [Page 4]INTERNET-DRAFT        Proposal for IPv6 Flow Label         May 25, 19101        packet).   (i)  The maximum lifetime of any flow-handling state established        along a flow's path must be specified as part of the description        of the state-establishment mechanism, e.g., the resource        reservation protocol or the flow-setup hop-by-hop option.   (j)  A source must not reuse a flow label for a new flow within the        maximum lifetime of any flow-handling state that might have been        established for the prior use of that flow label. When a node        stops and restarts (e.g., as a result of a "crash"), it must be        careful not to use a flow label that it might have used for an        earlier flow whose lifetime may not have expired yet.5. IPv6 Flow and Flow Label Discussion   This section is going to discuss several aspects of the flow label,   which are the target of clarifications or improvement.5.1  End-to-end/hop-by-hop use of the IPv6 Flow Label   The definition in [IPv6] gives a definite hop-by-hop characteristic   to the flow label. The flow label is supposed to help the routing   system in processing packets whether during packet forwarding, or   whether during QoS processing. However, controversial discussion took   place around the end-to-end use and character of the flow label.   For instance it was stated that the label should be used as a   mechanism for identifying a flow by the destination end-node. Such   statements seem to be warranted by the use of the IPv6 pair of source   and destination addresses as component fields in a host-to-host   connection (virtual circuit oriented communication) or communication   (connectionless oriented) identifiers, and thus the flow label would   just be an addition or a replacement to such identifiers. However, if   the routers' packet processing is more performance critical then   end-nodes' processing, it would seem to make more sense to use the   flow label for that purpose, that is to use the flow label hop-by-hop   significance.   Using a flow label end-to-end or hop-by-hop seem to be fine in the   context of the  current definition of the flow label, as long as the   non-mutable character of the flow label is maintained. The issue of   mutable or non-mutable is going to be discussed in a separate   section.Conta                       Expires in six months   [Page 5]INTERNET-DRAFT        Proposal for IPv6 Flow Label         May 25, 19101   The discussion around the end-to-end, or hop-by-hop use of a flow   label becomes irrelevant if a certain negotiation mechanism amongst   routers and end-nodes takes place. There are examples of technologies   in which such negotiations around flow labels and flows labeling take   place. For instance the Label Distribution Protocol of MPLS is used   to exchange labels among neighboring Label Distribution Routers,   including the source and the destination of the labeled packets.   Furthermore, the Resource Reservation Protocol (RSVP) [RSVP],[RSVP-   TE] Has been extended to exchange labels between neighboring labels.   But such a mechanism, at the time of writing this specification, does   not exist for IPv6 flow labels, or as part of the IPv6 set of   specifications. However, such a mechanism could be specified in the   future, therefore the specification or the definition of the IPv6   flow label should not restrict the use of the flow label in one way   or another relative to its end-to-end or hop-by-hop characteristic.   In conclusion, the flow label could have a bivalent character in the   type of its usage, or in its significance: (i)end-to-end, and   (ii)hop-by-hop. The end-to-end significance should not preclude its   hop-by-hop significance, and vice-versa. If a node which sends   packets, associates a certain end-to-end significance to the flow   label of those packets, that significance can be meaningful also   hop-by-hop to each downstream router, all the way to the final   destination. Furthermore, the flow label could be changed in the   packet headers by the en-route routers, and restored or not to its   original value by the last hop router, as long as the end-node is   aware of what the value of the flow label should be. Certainly such a   behavior would need negotiation and state storing in the en-route   routers, in particular the last hop one.5.2  Mutable or non-mutable IPv6 Flow Label   Another topic of controversial discussion is whether the flow label   should be mutable or non-mutable, that is it should be read-only for   routers or not.   Statements that advocate a non-mutable characteristic are certainly   based on the advantage of the simplicity implied by such a   characteristic.   Opposite statements, that the flow label should be mutable, are based   on the flexibility that this provides, in particular if the label has   a hop-by-hop significance. However, using mutable flow labels would   not work without a certain agreement, or negotiation between   neighboring nodes, or certain configuration of those routers. This   would require the use of a negotiation mechanism between neighboring   routers, or a certain setup through router management orConta                       Expires in six months   [Page 6]INTERNET-DRAFT        Proposal for IPv6 Flow Label         May 25, 19101   configuration, to make sure that the values or the changes made to   the flow label are known to all routers on the portion of the path of   the packet, in which the flow label changes. Some of these   mechanisms, such as MPLS LDP, or RSVP-TE, were described in the   previous section. Such a mechanism could be specified for IPv6 flow   labels.   As the hop-by-hop significance of the flow label can be enhanced by a   mutable characteristic, the specification or definition of the flow   label should not preclude this.   A mutable flow label though requires the relaxation or elimination of   the rule marked (a), (c), (d), and (j) in Section 4. These rules were   extracted from [IPv6], Appendix A.5.3  Randomness in setting Flow Label values   The rule marked (d) in Section 4, extracted from [IPv6], Appendix A,   specifies the requirement of pseudo-randomness in setting the value   of a flow label. The reason given is the use of a hashing function,   and table for flow lookup by routers.   The use of a hashing is one possible choice for the flow lookup in   routers, or hosts.   Another possible choice is to use the label as an index in an array,   which is a direct and much faster lookup, or retrieval of the flow,