IPv6 Working Group                                        Rahul BanerjeeInternet 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.txtObsoletes 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........................................25Rahul 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.13. 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 assumeRahul 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 work4.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 ofRahul 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 toRahul 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.