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

IPv6协议中flow_label的相关RFC

    define the Flow Label. Here a 17-bit random number can be used. The
    random numbers can be generated in the range from 1 to 1FFFF. Keeping
    the IPv6 specifications in mind, the authors of this document believe
    that the random number can be used as one of the approaches. As other
    approaches are defined in the Flow Label, this random number approach
    may not be used whenever not feasible or efficient to do so.

         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9   
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |0 0 1|     Pseudo - Random value       |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4.3.2 Using Hop-by-Hop extension header

    As defined in [draft-banerjee-ipv6-quality-service-02.txt], Hop-by-
    Hop extension header can be used for defining the Flow Label in case   
    IntServ is used. In this case the value in the 20-bit Flow Label is
    ignored. The modified Hop-by-Hop extension has been suggested and
    defined in the reference [draft-banerjee-ipv6-quality-service-02.txt].
    In that draft, the Hop-by-Hop extension header has been defined to
    be used with IntServ. This mechanism applies to define for DiffServ as
    well.
     
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9   
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |0 1 0|         Don't care              |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4.3.3 Using PHB ID

    This defines the DiffServ with MF classifier. In that case the format
    of the Flow Label will be as shown below:
      
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9   
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |0 1 1|     DiffServ IPv6 Flow Label    |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    As suggested in [draft-conta-ipv6-flow-label-02.txt], this Flow Label
    can be a PHB ID (Per Hop Behavior Identification Code). In this case,
    16-bit PHB ID will be used and the remaining 1 bit is reserved for   
    future use.

         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9   
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |0 1 1|  Per Hop Behavior Ident. Code |R|
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      
    'R' is reserved.


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


    Packets coming into the provider network can be policed based on the
    Flow Label. The provider, based on the SLAs, SLSs, TCAs, TCSs agreed
    with the client, configures MF classifiers. This draft specifies the
    classifier which is little different from the one suggested in the           
    [draft-conta-ipv6-flow-label-02.txt]. The classifier looks like:

    C  = (SA/SAPrefix, DA/DAPrefix, Flow-Label).
    Or   
    C` = (SA/SAPrefix, DA/DAPrefix, Flow-Label-Min: Range).

    The range here specifies the difference between the maximum and the
    minimum Flow Label. The significance of using the range instead of   
    Maximum Flow Label is the reduced number of bits. Definitely the
    difference between the two values can be specified in a lesser number
    of bits as compared to the value itself.

    Flow-Label-Classifier:

    IPv6SourceAddressValue/Prefix:  10:11:12:13:14:15:16:17:18::1/128
    IPv6DestAddressValue/Prefix:    1:2:3:4:5:6:7:8::2/128
    IPv6 Flow Label:                50

    Or

    IPv6SourceAddressValue/Prefix:  10:11:12:13:14:15:16:17:18::1/128
    IPv6DestAddressValue/Prefix:    1:2:3:4:5:6:7:8::2/128
    IPv6 Flow Label:Range:          10:20                       


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

4.3.4 Using the Port Number and the Protocol

    This approach defines Flow Label by including the server port number and
    the host-to-host protocol. The "Server Port Number" is the port number
    assigned to the server side of the client/server applications. As   
    specified in [draft-conta-ipv6-flow-label-02.txt], this approach   
    reserves 16 bits for the port number and 1 bit for the protocol with   
    the remaining bits reserved for the future use.   

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

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


    But this approach puts the restriction on the protocol to be used by
    any application.   

    As most of the application seeking Real-time service use TCP or UDP
    as the transport layer protocol, this approach would work fine in most
    of the cases. In case the application requires to use any other host-
    to-host protocol, the other methods for specifying the Flow Label,
    discussed in this section can be used. Anyhow, this method for  
    specifying the port number and the protocol can be exploited further  
    in the future to remove any limitations.

4.3.5 A new structure and mechanism for the use of the Flow Label

    This section describes an innovative approach to define the 20-bit
    Flow Label field in IPv6 header. By the optimal use of the bits in
    the Flow Label, this approach includes various Quality of Service
    parameters in the IPv6 Flow Label that may be requested by any   
    application. The various Quality of Service parameters are:

    1. Bandwidth
    2. Delay or Latency
    3. Jitter
    4. Packet Loss
    5. Buffer Requirements

    As packet loss and the jitter are often desired to be of minimum value   
    by any application, these two parameters may not be defined in the Flow
    Label field itself. Instead, if needed, the Hop-by-Hop EH space can be
    effectively used to specify these parameters. Bits thus saved in the Flow
    Label can be effectively used for more demanding purposes. The Quality
    of Service parameters that are to be included in the Flow Label are:

    1. Bandwidth (to be expressed in multiples of kbps).
    2. Delay     (to be expressed in nanoseconds).
    3. Buffer requirements (to be expressed in bytes).

    As there are only 17 bits left, the optimal use of the bits is very
    important so as to obtain the maximum information out of those 17 bits.
    The first bit out of these 17 bits is used to differentiate between the
    hard real time and soft real time applications. This bit is set to 0 for
    soft real time applications and it is set to 1 for hard real time   
    applications.

    Soft Real time applications:

         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9   
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |1 0 1|0|      Flow Label               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


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


    This service is meant for RTT (Real Time Tolerant) or soft real time
    applications, which have an average bandwidth requirement and an
    intermediate end-to-end delay for an arbitrary packet. Even if the
    minimum or maximum values specified in the Flow Label are not exactly
    met, the application can afford to manage with the QoS provided.   

    Hard Real time applications:

         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9   
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |1 0 1|1|      Flow Label               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    This service is meant for RTI (Real Time Intolerant) or hard real rime
    applications, which demand minimal latency and jitter. For example, a 
    multicast real time application (videoconferencing). Delay is
    unacceptable and ends should be brought as close as possible.  

    For this videoconference (DTVC) case, the required resource reservations
    are
      a. Constant bandwidth for the application traffic.
      b. Deterministic Minimum delay that can be tolerated.

    These types of applications can decrease delay by increasing demands
    for bandwidth. The minimum or maximum values specified in the Flow   
    Label have to be exactly met for these kind of applications.

    After keeping one bit for Hard/Soft real time applications, we are   
    left with 16 bits for defining the Flow Label. The remaining part   
    of this section discusses how to represent the values of bandwidth,
    delay and buffer requirements.

    1. Bandwidth

    This definition specifies 6 bits out of the 16 bits to be used for
    specifying the bandwidth value. 

    Each value in these six bits corresponds to a pre-defined value for 
    bandwidth. Further explanation about this is given at the end of this 
    section.

    2. Buffer Requirements

    This definition specifies next 5 bits out of the 16 bits to be used for
    specifying the buffer value.

    Each value in these six bits corresponds to a pre-defined value for 
    buffer requirement. Further explanation about this is given at the end
    of this section.


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


    3. Delay

    This definition specifies last 5 bits out of the 16 bits to be used for
    specifying the delay value. 

    Each value in these six bits corresponds to a pre-defined value for 
    delay.

    The approach described here is a DiffServ based mechanism for providing
    the QoS as any packet received by any router is classified based on the
    MF Classifier which is a triplet consisting of the source address,
    destination address and (bandwidth, buffer and delay). The packet that 
    arrives at the router is examined for the values specified in bandwidth, 
    buffer and delay fields and is matched with the classifiers corresponding
    to which the packet is provided with the QoS. The classifier looks like:

    C = (src address, dest address, flow label);
    
    Where flow label = (bandwidth, buffer, delay)
    

    MF Classifier        Bandwidth    Buffer      Delay

    0, 0, 0			  32 kbps	 512 bytes    4 ns
    0, 0, 1			  32 kbps    512 bytes    8 ns
    .
    .
    .
    63, 31, 31		  64 tbps    1 tbytes     8 sec

    
5. A possible mechanism for the implementation of the above design.
  
    This section describes one possible mechanism that will allow immediate 
    and practicable implementation of the above design.

5.1 Data structures required (at the router).

    The data structures are specific to the implementations. Different 
    implementations can choose their own data structures that will be
    required to implement the above design.

    Any router that tries to implement QoS maintains a QoS routing table
    and keeps track of the QoS available to each destination through the
    required number of hops [RFC 2676]. Apart from this table, the
    router needs to keep track of the allotted QoS to each and every flow.
    This table is the ALLOTTED_QOS_TABLE.




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


    1. Defining the different approaches.
      
       enum MODEL_ID {
         RANDNUM=1,       // the random number method
         HOPBYHOP=2,      // the hop-by-hop extension header method
         PHB_ID=3,        // the multi-field classifier
         PORT_PROT=4,     // port/protocol method
         HYBRID=5         // the hybrid approach
       };

    2. Defining the different Resource Identifiers.

       enum RES_ID {
         BANDWIDTH=0,     // bandwidth requirement
         DELAY=1,         // delay requirement
         BUFFER=2,        // buffer requirement
       };
  
    3. Defining the value of the resource.

       typedef unsigned int RES_VAL;

       struct RESOURCE {
         RES_ID res_identifier; // identifier of the resource
         RES_VAL res_value;     // 32-bit value of the resource
       };

    4. Defining the Quality of Service.

       struct QOS_INFO {
         MODEL model_id;  
         RESOURCE resource;
       };

    5. Defining the port/protocol and the flow label.

       struct port_protocol {
         unsigned port;      // port number
         unsigned protocol;  // protocol 
       };
     
       union format {
           unsigned flowlabel;             // 20-bit Flow Label value
           struct port_protocol port_prot;
       };

    6.  Defining the packet information.
  
        struct PACKET_INFO {
           struct sockaddr_in6 src_addr;

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


           struct sockaddr_in6 dest_addr;