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

IPv6协议中flow_label的相关RFC

    C = (SA, SAPrefix, DA, DAPrefix, Flow Label).

    C` = (SA, SAPrefix, DA, DAPrefix, Flow Label min: Flow Label max).

    Incoming packet header (SA, DA, Flow Label) is matched with
    classification rules table entry C or C`.

    Advantages:

    Helps the IPv6 Flow Label to achieve, as it is supposed, in a more
    efficient processing of packets in QoS engines in IPv6 forwarding
    devices.

    Disadvantages:

    When packets are transmitted, the end nodes have to force the
    correct Flow Label in the IPv6 headers of outgoing packets or the
    first hop routers have to do this job. To accomplish these rules,   
    these routers will be configured with MF classifiers. This puts
    extra computations to be done by the routers.

A.2.3 Third approach

    Includes the algorithmic mapping of the port numbers and protocol
    into the Flow Label. It reserves 12 bits for the port number and 8
    bits for the protocol.

         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        | Server port number   | H-to-H protocol|
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Advantages:

    Classification rule is 5 or 6 element tuple format of a DiffServ MF
    classifier, containing the source and the destination address, the
    source and the destination ports, the host-to-host protocol. So no
    new classification rule format is needed.

    Disadvantages:

    It cannot differentiate among multiple instances of the same
    application running on the same two communication end nodes.



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


    The reduced number of bits (12 out of 16) limits the value of ports.
    12 bits can represent only the "IANA well-known ports", that is from
    1 to 1023 and a subset of "IANA registered ports", that is from 1024
    to 4095. Registered ports have values between 1024 and 65535.

A.2.4 Fourth approach

    The field occupied by host-to-host protocol could be reduced to 1,
    as TCP and UDP are the only well known protocols.

         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |    TCP Server port number      |Res |0|
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |    UDP Server port number      |Res |1|
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


    The "Res" bits are reserved.

    The "TCP Server Port Number" or "UDP Server Port Number" is the 16-
    bit port number assigned to the server side of the client/server
    application.

    Advantages:

    Again the classification field is a 5 or 6 element tuple. So no new
    classification rule is needed.

    This approach keeps 16 bits for the port number so that all the
    "IANA well-known ports" and "IANA registered ports" can be
    accommodated in these 16 bits.

    Disadvantages:

    This approach, too, cannot differentiate among multiple instances
    of the same application running on the same two communication end
    nodes.

    Reserving only 1 bit for the protocol field in the Flow Label
    restricts the use of any protocol other than TCP and UDP.

A.2.5 Fifth approach

    Header length format:

    Another possible solution is to store the length of IPv6 headers

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


    length that is the length of the IPv6 Base Headers and IPv6   
    extension headers preceding the host-to-host or transport header.
    The length of IPv6 headers in the Flow Label value would provide   
    the information, which a DiffServ QoS engine classifier could use
    to locate and fetch the source and destination ports and apply   
    those along with the source and destination address and host-to-
    host protocol from the Flow Label, to match the source and   
    destination address, the source and destination ports and the
    protocol identifier elements of a DiffServ MF classifier.

         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |Length of IPv6 headers| H-to-H protocol|
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Advantages:

    "Length of IPv6 headers" allows skipping the IPv6 headers to access
    directly the host-by-host header for other purposes. This format is
    useful for classifying packets that are not TCP or UDP, and have no
    source and destination ports.

    Disadvantages:

    IPv6 header does not include "Total Headers Length" field. So
    introducing this new field in the Flow Label puts extra computation
    to be done that may result in the processing delays.

    Including "Length of IPv6 headers" in the Flow Label does not carry
    any significance in case ESP is used for IP Security.

    This approach is not preferred because of the reasons given above.
    Again, it does not carry any direct advantage in keeping the
    "Length of IPv6 headers" in the Flow Label.


A.3. Recent works in progress
    
    An emerging packet switched QoS approach for providing end-to-end 
    quality of service transparent to the application programs is in the
    verge of becoming a realistic solution for the IPv6 based WAN-QoS
    requirements. Known as MultServ, this approach finds its inspiration
    from the initiatives and the results of the distributed operating
    system research. Some fundamental initial work has been done by the
    IPv6-QoS research group at the Center for Software Development, BITS,
    Pilani (India).(http://ipv6.bits-pilani.ac.in/ngni/NGNI-MMI-QoS-D4-
    v1.3-secure.pdf). It is expected that an IETF document shall soon be
    submitted to the QoS community for their inputs and review of the 
    emergent approach.


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


A.4. QoS through policy based protocol implementation
    
    For quite sometime now , an interesting and promising approach that is
    generic in nature has been suggested and even implemented in parts in 
    terms of quality of service. This approach called policy based control
    protocol has already one standardized protocol known as Common Open
    Policy Service (COPS). COPS implementation has been available in
    several newer routers. Ths policy based quality of service framework
    permits the network administrators to define QoS Policies that 
    explicitly define rules pertaining to handling aggregated flows at a
    network node known as the Policy Enforcement Point (PEP). The policy
    servers known as the Policy Decision Point (PDP) computes or determine
    the exact QoS enforcement action to be taken on the policy-classified
    packets to be executed at the PEPs. Although very useful, this approach
    exhibits certain basic flaws. For instance, PDPs could be the point of
    failures and building redundancy by providing more PDPs may lead to
    network degradation (due to possible overheads and synchronisation
    issues) unless it is very carefully designed. [Qos_pol113]

    Acutally this policy based QoS solution augments the DiffServ approach,
    since in this case the PDPs are expected to map the flow information
    to specific DiffServ traffic conditioning action meta data which is
    communicated back to PEP; which thereafter uses this information for
    future processing. However this approach has one advantage that
    qualifies for an honourable slot in the QoS strategies and that is
    because such a mechanism does not require the application themselves
    to be QoS aware. This also happens to be the strong point of the 
    MultServ approach, but it does not operate on the client-server
    methodology. 

    The Quality of Service has one aspect called C&A (Charging and
    Accounting) which the commercial providers of the service require to
    support in case they have to charge their customers on the basis of
    QoS requirements. As of now, most of these service providers either
    do not provide QoS or provide certain flat tariff rates based on the
    explicit choices made by the customers that requires the customers to
    be QoS aware. All this is due to the fact that there is no C&A
    provision in the majority of the proposed mechanisms pertaining to QoS.

    The management of the QoS capable networks (QoS WANs) is yet another
    area that has not been adequately addressed by most of the existing
    proposed QoS mechanisms (with or without IPv6). The key problem here is
    that since the routers do offer a variety of packet handling mechanisms,
    the operator has to specifically select and combine the required traffic
    conditioning components at the Edge Routers and even at the Core Routers
    at the service provider's end. Although the aggregated end-to-end flow
    can be implemented in such cases, the task to define the exact router
    configuration remains an increasing complex job particularlyy in wide area
    heterogeneous networks. A related issue is scalability of management of
    such QoS-capable networks.

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

    
    The abovementioned issues are the two areas that are specifically
    being attempted to be addressed as built-in features of the MultServ
    quality of service mechanism, which may eventually be implemented in
    IPv6 WANs and which will not require any major change in the basic
    protocol itself.


Acknowledgements

    Authors acknowledge technical inputs and support from the members of
    the "Project IPv6@BITS" as well as the graduate students registered in
    EA C451 Internetworking Technology course at the Birla Institute of
    Technology & Science, Pilani, India, Dr. Latif Ladid of Ericsson 
    Telebit, (Luxembourg); Dr. Torsten Braun of University of Bern
    (Switzerland); Dr. Pascal Lorenz of I.U.T. at the University of Haute
    Alsace, Colmar (France); Dr. S. Rao of Telscom A.G. (Switzerland); 
    Dr. Bernardo Martinez of Versaware Inc. (Spain); Dr. Juan Quemada of
    UPM, Madrid (Spain); Dr. Merce and Dr. Paulo Desousa at the EC; 
    Dr. Zoubir Mammeri of IRIT (France) and Dr. Brian Carpenter of IBM.
    The IPv6-QoS team wishes to explicitly acknowledge the support from 
    Dr. S.Venkateswaran of BITS, Pilani (India).

    Authors gratefully acknowledge the works of many dedicated brains
    at the IETF, ETSI and elsewhere, sections or extracts of which have 
    helped us to shape this document.


References


    [RFC 2460]    S. Deering and Bob Hinden, "The Internet Protocol
                  Specification", RFC 2460, Internet Protocol version 6
                  Specification.

    [RFC 1809]    C. Partridge, RFC 1809, "Using the Flow Label Field   
                  in IPv6".

    [RFC 2676]    RFC 2676, QoS Routing Mechanisms and OSPF Extensions.

    [RFC 1633]    RFC 1633, Integrated Services in the Internet   
                  Architecture: an overview.

    [RFC 2475]    RFC 2475, An Architecture for Differentiated Services.

    [RFC 2676]    RFC 2676, QoS Routing Mechanisms and OSPF Extensions.






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

   [Qos_pol113] QoS Forum: "Whitepaper in QoS Policy", available at the URL: 
http://www.gt-er.cg.org.br/sgt-qos/documents/qospol_v11.pdf

References to the works in progress

   [draft-banerjee-ipv6-quality-service-02.txt]       Rahul Banerjee,   
               N.Preethi, M. Sethuraman, "Design and Implementation of
               the Quality-of-Service in IPv6 using the modified   
               Hop-by-Hop Extension header - A Practicable Mechanism".

   [draft-conta-ipv6-flow-label-02.txt]         A. Conta, B. Carpenter,   
               "A proposal for the IPv6 Flow Label".

   [draft-rajahalme-ipv6-flow-label-00.txt]     J. Rajahalme, A. Conta,   
               "An IPv6 Flow Label Specification".
 
   [draft-banerjee-flowlabel-ipv6-qos-02.txt]   Rahul Banerjee, Sumeshwar
               Paul Malhotra, Mahaveer M, "A Modified Specification
               for use of the IPv6 Flow Label for providing an efficient
               Quality of Service using a hybrid approach".

   [draft-jagadeesan-rad-approach-service-01.txt]         Harshavardhan 
              Jagadeesan, Tuhina Singh, "A Radical Approach in providing
              Quality-of-Service over the Internet using the 20-bit IPv6
              Flow Label field".
 

    [NGNI-MMI-QoS: D1] Rahul Banerjee (BITS), Juan Quemda (UPM), P.
    Lorenz (UHA), Torsten Braun (UoB), Bernardo Martinez (Versaware):
    "Use of Various Parameters for Attaining QoS in IPv6-based
    Multimedia Internetworks", Feb. 2002 readily available at the URL: 
    http://ipv6.bits-pilani.ac.in/ngni/.

    [NGNI-MMI-QoS: D3] Rahul Banerjee (BITS), Juan Quemada (UPM), P.
    Lorenz (UHA), Torsten Braun (UoB), Bernardo Martinez (Versaware):
    "Quality of Service Directions, Bench Marking and Roadmaps for
    IPv6 Oriented NGN Multimedia Internetworks".
    http://ipv6.bits-pilani.ac.in/ngni/.

    [NGNI-MMI-QoS: D4] Rahul Banerjee (BITS), Juan Quemada (UPM), P.
    Lorenz (UHA), Torsten Braun (UoB), Bernardo Martinez (Versaware):
    http://ipv6.bits-pilani.ac.in/ngni/NGNI-MMI-QoS-D4-v1.3-secure.pdf

Disclaimer

    The views and specification here are those of the authors and are not
    necessarily those of their employers.  The authors and their employers
    specifically disclaim responsibility for any problems arising from   
    correct or incorrect implementation or use of this specification.



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


Authors Information

    Rahul Banerjee
    3256, Center for Software Development
    BITS, Pilani