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

IPv6协议中flow_label的相关RFC

IPng Working Groups                     A. Conta (Transwitch)
INTERNET-DRAFT                          B. Carpenter (IBM)
                                         July 2001


                   A proposal for the IPv6 Flow Label

                             Specification

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

   At the time when the IPv6 specifications were written, the IPv6 flow
   label was still experimental, and subject to change, as the
   requirements for flow support in the Internet were evolving.

   The last several years of work in IETF on Internet Protocols Quality
   of Service (Intserv, and Diffserv) and Multi-Protocol Label Switching
   (MPLS) provide a more solid and ample architectural perspective, and
   framework for the standardization of the IPv6 flow label. The new
   charter of the IPv6 Working Group invites contributions to this
   standardization.

   This memo provides an analysis of the IPv6 definition of the flow
   label, the rules governing its use, and their implications. It



Conta & Carpenter         Expires in six months     [Page 1]




INTERNET-DRAFT        Proposal for IPv6 Flow Label         July 13, 2001


   subsequently makes a proposal for additions/modifications to these
   rules, which improve the usability of the IPv6 flow label, in
   particular with Diffserv, and its acceptance as a standard mechanism.
















































Conta & Carpenter         Expires in six months     [Page 2]




INTERNET-DRAFT        Proposal for IPv6 Flow Label         July 13, 2001


Table of Contents





   1. Introduction....................................................4
   2. IPv6 Flows......................................................5
   3. Other Definitions of Flows......................................5
      3.1 Integrated Services Flows...................................5
      3.2 Differentiated Services Flows...............................6
      3.3 MPLS Flows..................................................7
   4. IPv6 Flow Label.................................................7
   5. IPv6 Flow and Flow Label Discussion.............................9
      5.1 Flow Label Processing by Integrated Services Routers........9
      5.2 Flow Label Processing by Differentiated Services Routers....9
      5.3 Flow Label based Filtering.................................10
      5.4 End-to-end/Hop-by-hop use of the IPv6 Flow Label...........10
      5.5 Mutable/Non-Mutable IPv6 Flow Label........................12
      5.6 Using Random Numbers in setting the IPv6 Flow Label........12
      5.7 IPv6 Multi-Field Classifier Efficiency.....................13
          5.7.1 Classification Rules Memory Requirements.............13
          5.7.2 Pipe-Lined or Parallel Processing Classification.....14
   6. Summary of Proposals for the IPv6 Flow Label...................14
   7. IPv6 Flow Label Definition and Characteristics.................15
      7.1 IPv6 Flow Label Format.....................................17
          7.1.1 Diffserv IPv6 Flow Label Format......................17
          7.1.2 Other Possible IPv6 Flow Label Formats...............18
      7.2 Conceptual Model for Diffserv use of IPv6 Flow Labels......18
   8. Security Considerations........................................21
   9. IANA Considerations............................................21
   10. Acknowledgments...............................................21
   11. References....................................................21
   12. Authors' Addresses............................................23
   Appendix A........................................................24
















Conta & Carpenter         Expires in six months     [Page 3]




INTERNET-DRAFT        Proposal for IPv6 Flow Label         July 13, 2001


1. Introduction


   As stated by [IPv6], at the time when the IPv6 specifications were
   written, the IPv6 flow label was still experimental, and subject to
   change, as the requirements for flow support in the Internet were
   evolving.

   The last several years of work in IETF on Internet Protocols Quality
   of Service (Intserv, and Diffserv) and Multi-Protocol Label Switching
   (MPLS) provide a more solid and ample architectural perspective, and
   framework for the standardization of the IPv6 flow label. The new
   charter of the IPv6 Working Group invites contributions to this
   standardization.

 Note: The IETF work on Intserv, Diffserv, MPLS is documented in several
 specifications, among which the architecture documents [Intserv],
 [Diffserv], and respectively [MPLS-Arch].  Intserv and Diffserv present
 two alternative solutions to resolving QoS problems in the Internet,
 while MPLS is a technology based on labeling traffic flows.

   The IPv6 flow label is a function that, as it was designed, can be
   used towards a more efficient processing of packets in next hop
   lookup, quality of service, or packet filtering engines in IPv6
   forwarding devices. These devices would normally be IPv6 routers or
   switches. 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
   (Diffserv).

   Diffserv seems to have more potential, and could be used more
   extensively than originally thought. For instance, for IP QoS in
   access networks, Diffserv could be used on individual flows of
   traffic between users and the access networks.  The nature of the
   contractual agreements between the users and the access network
   providers seem to create an environment in which Diffserv with
   Multi-Field (M-F) classifiers could be easier to use, more efficient,
   and more practical as an alternative to Intserv and RSVP.

   However, the Diffserv M-F classifiers, the 5 or 6 element tuple,
   containing host-to-host protocol id, and source and destination
   ports, is a bit of a problem when packets have extension headers
   (IPv4, or IPv6). In IPv6, that is even more of an efficiency problem
   (need for sequential inspection), since extension headers have a much
   wider and frequent use.

   The IPv6 flow label, and the use of IPv6 flow label classifiers would
   be a big help in alleviating this problem. An IPv6 flow label



Conta & Carpenter         Expires in six months     [Page 4]




INTERNET-DRAFT        Proposal for IPv6 Flow Label         July 13, 2001


   classifier is basically a 3 element tuple - source and destination
   IPv6 addresses, and the IPv6 flow label [Diffserv-Flow-Label]. It is
   an alternative to the 5 element tuple (addresses, ports, and
   protocol).  It will help the IPv6 flow label to achieve, as it is
   supposed,  a more efficient processing of packets in quality of
   service engines in IPv6 forwarding devices.

   This specification provides an analysis of the definition of the IPv6
   flow label [IPv6], the rules governing its use, and attempts to make
   clarifications to their implications. It subsequently suggests some
   additions, or modifications to these rules, which in the view of the
   authors, improve the usability of the IPv6 flow label, in particular
   with Diffserv, and its acceptance as a standard mechanism.

   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, or hosts, with a certain
   set of traffic, and 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.  The MPLS architecture also defines a
   technique of labeling flows worth considering.


3.1  Integrated Services Flows

   The Integrated Services architecture [Intserv] 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] defines a



Conta & Carpenter         Expires in six months     [Page 5]




INTERNET-DRAFT        Proposal for IPv6 Flow Label         July 13, 2001


   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
     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] 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 portions 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 [Diffserv-Model] 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.



Conta & Carpenter         Expires in six months     [Page 6]




INTERNET-DRAFT        Proposal for IPv6 Flow Label         July 13, 2001


3.3  MPLS Flows

   As it travels from its source to its final destination, an IP packet
   is being forwarded from one router to the next, each router making an
   independent forwarding decision (next hop) based on the packet's IP
   header, and routing information processed and stored.  Choosing the
   next hop can be thought of as the composition of two functions. The
   first function partitions the entire set of possible packets into a
   set of "Forwarding Equivalence Classes (FECs)" [MPLS-Arch]. The
   second maps each FEC to a next hop.  Insofar as the forwarding
   decision is concerned, different packets, which get mapped into the
   same FEC, are indistinguishable. All packets, which belong to a
   particular FEC, and which travel from a particular node, will follow
   the same path (or if certain kinds of multi-path routing are in use,
   they will all follow one of a set of paths associated with the FEC).
   In MPLS, the assignment of a particular packet to a particular FEC
   results in a label being associated to that FEC. When a packet is
   forwarded to its next hop, the label is sent along with it; that is,
   the packets are "labeled" before they are forwarded. Once a packet is
   labeled, at subsequent hops, the forwarding is done based on the MPLS
   label rather than the information in the IP header. The label is used
   as an index into a table which specifies the next hop, and a new
   label.  The old label is replaced with the new label, and the packet
   is forwarded to its next hop.


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
   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, or the rules that
   govern the flow label functions are further defined in [IPv6]. For
   the purpose of this document the text from one paragraph in [IPv6]
   was rearranged as an item list, as follows:


   (a)  A flow is uniquely identified by the combination of a source