draft-conta-ipv6-flow-label-01.txt

IPv6协议中flow_label的相关RFC

IPng Working Groups                     A. Conta (Transwitch)
INTERNET-DRAFT
                                          May 2001


                   A proposal for the IPv6 Flow Label

                             Specification

                   draft-conta-ipv6-flow-label-01.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

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



Conta                       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 as



Conta                       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 IPv6



Conta                       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 or



Conta                       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,