draft-banerjee-flowlabel-ipv6-qos-03.txt

IPv6协议中flow_label的相关RFC

IPv6 Working Group                                        Rahul Banerjee
Internet Draft                                   Sumeshwar Paul Malhotra
                                                              Mahaveer M
                                                    BITS, Pilani (India)
                                                              April 2002        
                                 


    A Modified Specification for use of the IPv6 Flow Label for providing
          An efficient Quality of Service using a hybrid approach.
                draft-banerjee-flowlabel-ipv6-qos-03.txt

Obsoletes 00, 01, 02 versions of this draft.

Status of This Memo

    This document is an Internet Draft and is subject to all provisions
    of Section 10 of RFC 2026. 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 6 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 a "work in progress".

    The list of current Internet Drafts can be accessed at
    http://www.ietf.org/lid-abstracts.html

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

    Copyright(C) The Internet Society (2002).  All Rights Reserved.

Abstract
      
    This memo suggests a pragmatic specification for defining the 20-bit
    Flow Label field using a hybrid approach that includes options to
    provide IntServ as well as DiffServ based support for IPv6 Quality of
    Service. It also compares various suggested approaches for defining
    the 20-bit Flow Label field in IPv6 Base Header based on RFC 2460
    (December 1998) and few other drafts. Addressing the IPv6-Multicast-
    QoS issues also becomes possible as a consequence. This draft clearly
    specifies exactly when and how various options are to be used; and in
    case of the MFC, exactly how a specific action might be taken by the
    suggested implementation. Thus the resultant mechanism is fully
    implementable and unambiguous as even the lower-level details have been
    worked out as may be required for actual implementations. The draft
    also has a pointer to an experimental QoS scheme called MultServ.





Rahul Banerjee                                                 [Page 1]
Internet Draft   A Modified Specification for use of the     April 2002
                 IPv6 Flow Label for providing efficient   
                 Quality of Service using hybrid approach.

Table of Contents

   1. Introduction..................................................3
   2. IPv6 Flow Labels..............................................3
   3. Issues related with IPv6 Flow Label...........................3
      3.1 What should a router do with Flow Labels for which   
          it has no state?..........................................3    
      3.2 How does an internetwork flush old Flow Labels?...........3
      3.3 Which datagrams should carry non-zero Flow Labels?........4
      3.4 Mutable/Non-mutable IPv6 Flow Label.......................5
      3.5 Filtering using Flow Label................................5
   4. A modified specification for the IPv6 Flow Label and related
      implementation mechanism......................................5
      4.1 Overview..................................................5
      4.2 Definition of first three bits of the Flow Label..........6
      4.3 Defining the remaining 17 bits of the IPv6 Flow Label.....6
         4.3.1 Random Number........................................6
         4.3.2 Using Hop-by-Hop extension header....................7
         4.3.3 Using PHB ID.........................................7         
         4.3.4 Using the Port Number and the Protocol...............8
         4.3.5 A new structure and mechanism for the use of the
               Flow Label...........................................9
   5. A possible mechanism for the implementation of the above   
      design.......................................................11
      5.1 Data structures required (at the router).................11
      5.2 Function of the source...................................13
      5.3 Function of each relevant intermediate router............13
         5.3.1 Initial Processing..................................13
         5.3.2 Searching for the entry.............................13
         5.3.3 New Entry...........................................13
   6. When to use which approach...................................14
   7. Where other approaches differ in defining the Flow Label 
      from the proposed approach...................................15
   8. Security Considerations......................................15
   9. Conclusion...................................................15
   Appendix........................................................17
     A.1. Characteristics of IPv6 Flow and Flow Labels.............17
     A.2. Comparison of already suggested approaches in defining
          the IPv6 Flow Label format...............................17
         A.2.1 First approach......................................18
         A.2.2 Second approach.....................................18
         A.2.3 Third approach......................................19
         A.2.4 Fourth approach.....................................20
         A.2.5 Fifth approach......................................20
     A.3. Recent works in progress.................................21
     A.4. QoS through policy based protocol implementation.........22
   Acknowledgements................................................23
   References......................................................23
   Disclaimer......................................................24
   Authors Information.............................................25
   Full Copyright Statement........................................25

Rahul Banerjee                                                 [Page 2]
Internet Draft   A Modified Specification for use of the     April 2002
                 IPv6 Flow Label for providing efficient   
                 Quality of Service using hybrid approach.


1. Introduction

    This draft addresses the design and implementation-specific issues 
    pertaining to the Quality of Service (QoS) support in the Flow Label
    field of the IPv6 Base Header. It provides support for IntServ and 
    DiffServ Quality-of-Service. Though the IPv6 Base Header has a 20-bit 
    Flow Label field for QoS implementation purposes, it has not yet been 
    exploited. Very few Internet Drafts address these long-standing issues 
    and attempt to present solutions in the form of a clear specification
    of the 20-bit Flow Label in IPv6. This work attempts to provide an 
    analysis of these definitions and subsequently suggests a modified 
    IPv6 Flow Label specification, which in view of the authors can provide
    an efficient Quality-of-Service.


2. IPv6 Flow Labels

    The IPv6 Flow Label [RFC 2460] is defined 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.
    The nature of that special handling might be conveyed to the routers
    by a control protocol, such as RSVP, 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 given in the 
    Appendix A.1


3. Issues related with IPv6 Flow Label

    According to RFC 1809, the IPv6 specification originally left open a
    number of issues, of which the following are important.

3.1 What should a router do with Flow Labels for which it has no state?

    [RFC 1809] and the author's view suggest that the default rule should
    be that if a router receives a datagram with an unknown Flow Label, it
    treats the datagram as if the Flow Label is zero. Unknown flow labels 
    may also occur if a router crashes and loses its state. As part of
    forwarding, the router will examine any hop-by-hop options and learn
    if the datagram requires special handling.  The options could include
    simply the information that the datagram is to be dropped if the Flow
    Label is unknown or could contain the flow state the router should have.

3.2 How does an internetwork flush old Flow Labels?

    Stale Flow Labels can occur in a number of ways, even if we assume



Rahul Banerjee                                                 [Page 3]
Internet Draft   A Modified Specification for use of the     April 2002
                 IPv6 Flow Label for providing efficient   
                 Quality of Service using hybrid approach.


    that the source always sends a message deleting a Flow Label when   
    the source finishes using a Flow.   

    1. The deletion message may be lost before reaching all routers.    

    2. Furthermore, the source may crash before it can send out a Flow
       Label deletion message.    

    The authors of the document suggest the following approach as a
    solution to this problem:

    1. The MRU (Most Recently Used) algorithm should be used for
       maintaining the Flow Labels. At any point of time, the most   
       recently used Labels alone will be kept and the remaining should   
       be flushed.   

    2. Before flushing a label, the router should send an ICMP message
       to the source saying that the particular label is going to be
       flushed. So the source should send a KEEPALIVE Message to the
       router saying not to flush the Flow Label in case the source
       requires the Flow Label to be used again. On the other hand, if
       the source agrees with the router to delete the Flow Label, it
       should send a GOAHEAD Message to the router. On receiving the
       GOAHEAD Message, the router immediately deletes the label for
       that particular source. These messages are also sent to all the
       intermediate routers, so that, those routers can as well flush
       the Flow Labels for that particular source.   

    3. In case, the router does not receive any consent from the
       source, it will re-send the ICMP message for at most two or
       three times. If the router does not receive any reply from the
       source, it can flush the particular Label assuming that the
       Flow Label was not important for the source or any other
       intermediate router. The intermediate routers will also delete
       that Flow Label as they didn't receive any message from the
       source. The policy of sending the ICMP message to the source
       two or three times ensures the proper behavior of the method
       of flushing Flow Labels in case of packet loss. This method
       assumes that the ICMP message would not be lost all the three
       times. Hence, if the router doesn't receive any reply from the
       source even after sending the ICMP message three times, it
       deletes the label.

3.3 Which datagrams should carry non-zero Flow Labels?

    According to RFC 1809, following were some points of basic agreement.

    1. Small exchanges of data should have a zero Flow Label since it
       is not worth creating a flow for a few datagrams.


Rahul Banerjee                                                 [Page 4]
Internet Draft   A Modified Specification for use of the     April 2002
                 IPv6 Flow Label for providing efficient   
                 Quality of Service using hybrid approach.


    2. Real-time flows must always have a Flow Label.

    One option specified in [RFC 1809] is to use Flow Labels for all
    long-term TCP connections. The option is not feasible in the view
    of the authors as it will force all the applications on that   
    particular connection to use the Flow Labels which in turn will   
    force routing vendors to deal with cache explosion issue.

3.4 Mutable/Non-mutable IPv6 Flow Label

    The Flow Labels should be non-mutable because of the following
    reasons:

    1. Using mutable Flow Labels would require certain negotiation
    mechanism between neighboring routers, or a certain setup through
    router management or configuration, to make sure that the values or
    the changes made to the Flow Label are known to all the routers on
    the path of the packets, in which the Flow Label changes. On the
    other hand, the non-mutable Flow Labels certainly have the advantage
    of the simplicity implied by such a characteristic.

    2. A mutable Flow Label characteristic goes against the IPv6   
    specification of the Flow Label explained in section 2 and the IPv6
    Flow Label characteristics explained in the coming sections.

3.5 Filtering using Flow Label
     
    If, at all, any filtering has to be done based on the Flow Label
    field in the IPv6 header, the expectation is that the IPv6 Flow
    Label field carries a predictable or well-determined value. This is
    not the case if the Flow Label has randomly chosen values.

    Supporting the arguments given in [draft-conta-ipv6-flow-label-02.txt],
    the authors of this document suggest that the problem of not being able
    to configure load-filtering rules, which are based or are including the
    Flow Label, can be resolved by relaxing IPv6 specification of having a 
    random number in the Flow Label field. Exactly how can it be done has
    been suggested later.


4. A modified specification for the IPv6 Flow Label and related
   implementation mechanism: A hybrid approach suggested by this work

4.1 Overview

    Appendix A.2 gives a comparison on various approaches suggested in
    [draft-conta-ipv6-flow-label-02.txt] on defining the 20-bit Flow Label. 
    This section specifies a modified Flow Label for IPv6 for providing
    efficient Quality of Service that utilizes the results of some of


Rahul Banerjee                                                 [Page 5]
Internet Draft   A Modified Specification for use of the     April 2002
                 IPv6 Flow Label for providing efficient   
                 Quality of Service using hybrid approach.


    the works referred in Appendix A.2, extends some of these suggested
    mechanisms and finally presents an integrated hybrid approach.

4.2 Definition of first three bits of the Flow Label

    The hybrid approach suggested in this section includes various  
    approaches which are mentioned in Appendix A.2. The 20-bits of the
    Flow Label should be defined in an appropriate manner so that various
    approaches can be included to produce a more efficient hybrid solution. 
    Hence, for this purpose, the first three bits of the IPv6 Flow Label 
    are used to define the approach used and the next 17 bits are used to
    define the format used in a particular approach.

    Following is the bit pattern for the first 3 bits of Flow Label
    that defines the type of the approach used:

    0 0 0       Default.

    0 0 1       A random number is used to define the Flow Label.

    0 1 0       The value given in the Hop-by-Hop extension header is   
                used instead of the Flow Label.

    0 1 1       PHB ID.

    1 0 0       A format that includes the port number and the protocol   
                in the Flow Label is used.

    1 0 1       A new definition explained later in this section is used.

    1 1 0       Reserved for future use.

    1 1 1       Reserved for future use.


    This definition of Flow Label includes IntServ, DiffServ and other
    approaches for defining the Flow Label. A further explanation of these
    options is provided in the remaining part of this section. The default
    value specifies that the datagram does not need any special Quality of 
    Service.

4.3 Defining the remaining 17 bits of the IPv6 Flow Label

    The remaining 17 bits of the IPv6 Flow Label are defined based on
    the approach defined in the first three bits of the Flow Label.

4.3.1 Random Number

    As specified in IPv6 specification, a random number can be used to


Rahul Banerjee                                                 [Page 6]
Internet Draft   A Modified Specification for use of the     April 2002
                 IPv6 Flow Label for providing efficient   
                 Quality of Service using hybrid approach.