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

IPv6协议中flow_label的相关RFC

           union format format_value;
         };

    7. Defining the Alloted QoS table.

       struct ALLOTED_QOS_TABLE {
         struct PACKET_INFO packet;
         struct QOS_INFO qos;
       };

5.2 Function of the Source

    The application specifies the desired QoS and the Flow Label field in
    the IPv6 header is filled based on the QoS asked by the application.
    The application has the flexibility of specifying which format it
    wants to use for getting the desired QoS. It can specify any of the
    formats described in this document. The packet is then put on the
    network and it reaches the intermediate routers

5.3 Function of each relevant intermediate router

5.3.1 Initial Processing (Checks for default service)

    It gets the format used by the packet by reading the first three
    bits of the Flow Label. In case the first three bits are 000 or 110
    or 111, it represents the default service. No specific treatment is 
    required for this particular packet. In this case, no further processing
    of the packet is required and the default QoS is provided to the packet.
    If the value given in the first three bits is 010, no further processing  
    is done and the router knows that the required QoS is specified in the  
    hop-by-hop extension header.

5.3.2 Searching for the entry (In case of non-default service)

    1. The ALLOTTED_QOS_TABLE table is searched based on the source address.
    2. If an entry is found, then for that particular source, a search
       is made based on the PACKET_INFO structure defined above. If all  
       the information stored exactly matches with the information contained
       in the incoming packet, the IPv6 packet is processed so that the  
       reserved QoS is met.
     
5.3.3 New Entry
        
1.	If an entry is not found, a new entry is made in the 
       ALLOTTED_QOS_TABLE table for the source and further processing
       of this new entry is done as follows.
    2. All the relevant structures defined above are filled based on the  
       information contained in the packet. Information about the packet  
       is stored in the PACKET_INFO structure.

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


    3. It reads the desired QoS from the packet's header. If the format  
       specifies that a random number is used in the Flow Label field, it  
       reads the RANDOM_NUMBER table. It reads the specified QoS from the 
       table and maintains that in the QOS_INFO structure after updating 
       the RESOURCE structure. It then moves onto step 7.
    4. If the format specifies that PHB ID is used in the Flow Label field,
       it reads the Flow Label and the packet is classified based on the MF 
       classifier described in the previous section and it moves on to the 
       step 7.
    5. If the value in the Flow Label field specifies that the PORT/PROTOCOL
       field is used in defining the QoS required by the packet, it fills the  
       RESOURCE structure and the QOS_INFO structure and moves onto step 7.
    6. If the value in the Flow Label field specifies that the hybrid approach
       is used where the packet specifies the values of the bandwidth, delay
       and buffer requirement. The packet is classified based on the MF 
       classifier described in the previous section and it moves on to the 
       step 7.
    7. It then checks with the QoS Routing table, to find out if the desired
       QoS is possible to be provided to the packet. If yes, it updates the
       new entry in the ALLOTTED_QOS_TABLE table in the memory or else this
       entry is removed.
    8. If any relevant router en-route is not able to guarantee the
       requested QoS, an ICMPv6 message is sent to the source and the
       other routers (that had guaranteed the QoS) are also notified of
       the same so that they delete the corresponding entry from their
       QoS tables.

    This process executes at all the intermediate routers between the
    source and the destination.


6. When to use which approach?

    1. Random Number: This approach supports the pure IntServ based model.
       So if the network uses only IntServ model for QoS, using random 
       numbers in Flow Label is a valid option. But in some conditions
       it is not desirable to use random numbers in Flow Label. If the
       network is required to have a deterministic behavior, using random
       numbers is not a good option as it increases the unpredictability.
       Again, if any load filtering rules have to be designed based on or
       using the Flow Label, random numbers should not be used as the value
       in the Flow Label can not be predicted.

    2. PHB ID: This approach supports the pure DiffServ based model. So
       if the network is designed so as to support DiffServ model for
       QoS, using PHB ID in flow label and using MF classifier as described
       in the previous sections is a valid option.

    3. Hybrid: Again, if the network supports DiffServ model for QoS, using
       this approach is a valid option. Here the application should be 

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


       capable of providing the exact values of bandwidth, delay and buffer
       requirement it needs.

    4. Hop-by-Hop: For using this approach, the application should be capable 
       of specifying the values of QoS parameters. So if the application has 
       these details and the values asked by the application are not supported
       by the hybrid approach, this approach should be used.

    5. Port-Protocol method: If the network is designed so as to perform some
       load filtering based on the port number or the protocol, this approach
       is a valid option.


7. Where other approaches differ in defining the Flow Label from the proposed
   approach


   Few internet drafts have differentiated between the control and forwarding
   plane. [draft-ietf-ipv6-flow-label-00.txt] defines the Control plane as
   part of an IP node taking care of control functions, such as routing
   protocols and flow establishment protocols and Forwarding plane as part
   of an IP node receiving and forwarding IP packets; also known as the 
   "datapath". Having a separation of control plane and forwarding plane does
   have an advantage as explained in that draft. But it may not be completely
   beneficial as the TCP/IP architecture itself is not fully layered. Moreover
   this approach might require some changes in the existing architecture as
   opposed to the proposed solution given in this draft.
   

8. Security Considerations
     
    The specifications of this draft do not raise any new security issues.
    The Flow Label field in the IPv6 header cannot be encrypted because
    of the known reasons. If encrypted, each in between router has to
    decrypt the header for providing the required QoS to the packet. As  
    the QoS specification requires minimum delay for the packet, decrypting
    each packet's header at each router will not be a good idea because of
    the time required in processing the packet.

9. Conclusion

    This report has dealt extensively with all the suggested formats for
    defining the 20-bit IPv6 Flow Label and finally has suggested a
    hybrid approach for efficiently defining the 20-bit IPv6 Flow Label.
    
    One of the major reasons why the current solution proposed in this draft
    provides choice for IntServ/DiffServ based quality of service is the fact
    that a few representative research experiments in many places including
    those in Europe ( www.bits-pilani.ac.in/ngni) have shown that while
   

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


    DiffServ is definitely an attractive solution due to its scalability, 
    IntServ has been found to be fair and reasonably efficient under a real
    life situation constraints that were stimulated in these experiments.
  
    In the meanwhile, yet another Quality of Service approach is gradually
    evolving (Appendix A.3) that aims to provide a seamless application
    transparency based solution to provide end-to-end quality of service
    support. Inspired from the initiative in the distributed operating system
    research and policy-based QoS mechanisms,this approach is still evolving 
    and refined. It is hoped that once this approach becomes verifiable and   
    viable, an alternate protocol independent quality of service strategy shall 
    be possible to be implemented in the near future.
    
    The emphasis of this work is to result into a practically acceptable  
    specification that could be effectively used for a reasonably long
    period of time for implementing IPv6 Quality of Service that so far
    has been elusive in absence of a clear, verifiable and complete  
    specification. A separate ID is under preparation specifically building  
    upon these specifications so as to explicitly address the scalability
    issues related to the IPv6-Multicast-QoS.

    





























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


Appendix

A.1. Characteristics of IPv6 flows and Flow Labels

    The characteristics of IPv6 flows and Flow Labels as given in RFC 2460
    are rearranged as follows:

    (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 flow include a Hop-by-Hop options header, then
        they all must be originated with the same Hop-by-Hop options

    (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.
        header contents.

    (h) The maximum's 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.

    (i) The 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.


A.2. Comparison of already suggested approaches in defining the IPv6 Flow
     Label format

    This section discusses the already suggested approaches in [draft-conta-
    ipv6-flow-label-02.txt] for defining the 20-bit Flow Label. It discusses
    the advantages and disadvantages of these approaches. Finally it tells
    about accepting or not preferring these approaches and includes the



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


    accepted approaches (with modifications wherever required) in the final
    definition of the Flow Label discussed in the next section.

A.2.1 First approach

    Following format can be used for the Flow Label:

        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        | 0 |   Pseudo - Random value               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        | 1 |   DiffServ IPv6 Flow Label            |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    The DiffServ IPv6 Flow Label is a number that is constructed based
    on the Differentiated services "Per Hop Behavior Identification
    Code".
   
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        | 1 |   Per Hop Behavior Ident. Code|  Res. |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   

    The "Res" bits are reserved.
      
    The PHB ID is either directly derived from a standard differentiated  
    services code point, or it is an "IANA Assigned Value".   

    Advantages:

    Preserves compatibility with the random number method of selecting
    a Flow Label value defined in IPv6 specification.

    Captures the differentiated services treatment intended to be   
    applied to the packet.

    Unlike the value of the traffic class field, it is not locally
    mapped and hence suitable for use in an end-to-end header field.

    Disadvantages:

    It captures less information than the port number and protocol
    number normally used in multi field classifier.

A.2.2 Second Approach

    DiffServ with multi field classifier can be used in a more efficient
    and practical manner as an alternative to IntServ and RSVP. The Flow



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


    Label classifier is basically a 3-element tuple - source and
    destination address and IPv6 Flow Label.

    The classifier can be defined in any of the following two ways: