[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

Diffserv Working Group                A. Conta (Transwitch)
INTERNET-DRAFT                          J. Rajahalme (Nokia)
                                          November 2001


            A model for Diffserv use of the IPv6 Flow Label
                             Specification

               draft-conta-diffserv-ipv6-fl-classifier-01.txt


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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 six 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 "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

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

Abstract

   This document specifies a conceptual model for using IPv6 flow labels
   with Differentiated Services. It also specifies an IPv6 flow label
   classifier for Diffserv, and a set of rules for using the IPv6 flow
   label with Diffserv.













Conta & Rajahalme           Expires in May 2002     [Page 1]


INTERNET-DRAFT      Diffserv use of IPv6 Flow Label    November 21, 2001


Table of Contents



   1. Introduction....................................................3
   2. Diffserv use of IPv6 Flow Label - Conceptual Model..............3
   2.1 Host Conceptual Model for the Diffserv Flow Label..............5
   2.1.1 Selecting the Host Flow Label Value..........................5
   2.1.2 Setting the Host Flow Label Value............................6
   2.1.2.1 Host Flow Label Value API..................................7
   2.2 Router Conceptual Model for the Diffserv Flow Label............7
   2.2.1 IPv6 Diffserv Flow Label Classifier..........................8
   2.3 Applicability of Flow Label Classifiers - examples of use......9
   2.3.2.1 Example 1 - User Outgoing Traffic..........................9
   2.3.2.2 Example 2 _ Access Networks Incoming Traffic..............10
   2.3.2.3 Example 3 - Network Incoming Traffic......................11
   3. Rules for using the IPv6 Flow Label with Diffserv..............12
   4. The Diffserv Flow Label Conceptual Model: Conclusions..........13
   4.1 IPv6 Flow Label in mixed Intserv, Diffserv Networks...........15
   4.1.1 Intserv-Diffserv Control Plane Processing...................17
   4.1.1.1 Intserv Control Plane processing in domain A..............17
   4.1.1.2 Diffserv Control Plane processing in domain B.............17
   4.1.1.3 Intserv Control Plane processing in host Rx...............17
   4.1.1.4 Diffserv Control Plane processing in domain B.............17
   4.1.1.5 Intserv Control Plane processing in domain A..............18
   4.1.2 Intserv-Diffserv Data Plane Processing......................18
   5. Security Considerations........................................19
   6. IANA Considerations............................................19
   7. Acknowledgments................................................19
   8. References.....................................................19
   9. Authors' Addresses.............................................21




















Conta & Rajahalme           Expires in May 2002     [Page 2]


INTERNET-DRAFT      Diffserv use of IPv6 Flow Label    November 21, 2001


1. Introduction


   This document specifies a conceptual model for using IPv6 flow labels
   with Differentiated Services [Diffserv]. It also defines a IPv6 flow
   label classifier for Differentiated Services (Diffserv), and a set of
   rules for the use of the IPv6 flow label with Diffserv. It also
   suggests an API to be used to set/get IPv6 flow label values for
   Diffserv. Ultimately, the document provides the specifics of the
   mechanisms for using IPv6 flow labels with Differentiated Services.

   The use of the IPv6 flow label with Diffserv will help achieve, as
   the flow label is supposed, a more efficient processing of packets in
   Diffserv quality of service engines in IPv6 forwarding devices.

   The keywords MUST, MUST NOT, MAY, OPTIONAL,  REQUIRED, RECOMMENDED,
   SHALL, SHALL NOT, SHOULD, SHOULD NOT  are to be interpreted as
   defined in [KEYWORDS].


2. Diffserv use of IPv6 Flow Label - Conceptual Model

   The Differentiated Services QoS model (Diffserv) can be used anywhere
   in a network. A particular case is the use of Diffserv in a IPv6
   access network. In such a case, Diffserv would provide Quality of
   Service (QoS) functions for IPv6 traffic generated by users and
   carried by the access network towards the final destinations. It
   would also provide QoS functions for IPv6 traffic generated by remote
   sources and carried by various networks, including the access
   network, which is the last hop network. Part of these QoS functions
   are those that are typically employed at the edge of a Diffserv
   network. In fact, the nature of the contractual agreements between
   the users and the access network providers - service level and
   traffic conditioning agreements (SLAs and TCAs) -- are such that
   Diffserv could be easy to use, more efficient, and practical than
   other models. Obviously, in such a case, the Diffserv QoS functions
   would begin or would include at the edge routers traffic
   classification, which could be multi-field packet classification. The
   IPv6 flow label can play a major role in this multi-field packet
   classification. The IPv6 flow label, along with other fields in the
   main IPv6 header, can constitute the elements of the classifiers that
   are used to differentiate packets belonging to various traffic flows.
   We call such a classifier a "Diffserv IPv6 flow label classifier".

   The "Diffserv IPv6 flow label classifier" is basically a 3 element
   tuple: source and destination IPv6 addresses, and the IPv6 flow
   label. The flow label classifier is an alternative to the 5 element
   tuple (addresses, ports, and protocol).  It provides, higher



Conta & Rajahalme           Expires in May 2002     [Page 3]


INTERNET-DRAFT      Diffserv use of IPv6 Flow Label    November 21, 2001


   efficiency for packet classification in quality of service engines in
   forwarding devices. This is particularly so in the case of IPv6
   packets, because it is eliminating the examining or lookup of
   extension and transport headers during the multi-field packet
   classification.

   As a key element of the IPv6 flow label classifier, the IPv6 flow
   label value, is matched along with the values of the other elements
   of the classifier against the packet headers fields.

   The value of the IPv6 flow label that is set in a IPv6 header can be
   chosen by various means (further discussed later).

   However, in the case of Diffserv, whatever the means used to chose a
   value, the "flow_label value" or range of values MUST be known, and
   agreed by two sides:

       - the network client/user, which needs, pays and expects certain QoS
         from the network, for the traffic it sends into the network, and

       - the network provider, which implements mechanisms to satisfy the
         user's needs regarding the user's traffic sent into and carried by
         the provider's network.

   On the network user side, "flow label values" are set by traffic
   sources and carried in the IPv6 flow label field of the IPv6 packet
   headers. We call these "host flow label values".

   On the network provider side, "flow label values" of flow label
   classifiers are configured into the providers' routers that forward
   the user's traffic into the network. We call this "router flow label
   values".

   These flow label values are captured in contractual agreements
   between users and network providers, the so called Service Level and
   Traffic Conditioning Agreements and Specifications (SLAs, SLSs, TCAs,
   TCSs).

   For a further description and understanding of the mechanisms
   employing the IPv6 Flow label for Diffserv, we are considering a
   Diffserv conceptual model, which can be further broken apart into two
   conceptual models, one for entities that are the source and
   destination of packets, i.e. hosts, and one for entities that are
   forwarding the packets, i.e. routers:

       -  the conceptual model for the use of the IPv6 flow label with
          Diffserv in a host, and




Conta & Rajahalme           Expires in May 2002     [Page 4]


INTERNET-DRAFT      Diffserv use of IPv6 Flow Label    November 21, 2001


       -  the conceptual model for the use of the IPv6 flow label with
          Diffserv in a router.


2.1. Host Conceptual Model for the Diffserv Flow Label

   The conceptual model for the use of the IPv6 flow label with Diffserv
   in a host describes the mechanisms that are implemented and employed
   in hosts. The hosts are the source and final destination of the IPv6
   packets. These mechanisms select what we called above the "host flow
   label values", and then fill in those selected values into the main
   IPv6 headers of packets that are sent into the network.

   For the use of the IPv6 flow labels with Diffserv, there is one major
   requirement for selecting the values to set into the flow label: the
   values must be conforming to the contractual agreements between users
   and network providers (SLAs, SLSs, TCAS, TCSs). The selecting of the
   values can be done by any possible means as long as the above
   requirement is followed strictly. As examples, we have considered the
   following possible means for selecting the host flow label values:

      a. arbitrary number,
      b. random number,
      c. IANA number of some sort,

   A further discussion of these follows:


2.1.1. Selecting the Host Flow Label Value

   a. As an "arbitrary number", the "host flow label value" can be any
   value between 1 and the maximum value allowed for a IPv6 flow label
   used by Diffserv. If the arbitrary selected flow label value is
   intended for use with Diffserv in traffic sent over a set of
   networks, that value must be specified in the contractual agreements
   between the user and the network providers that will carry the user's
   traffic. Obviously, the arbitrary value will be used, and will not
   change for a particular flow or set of flows, as long as the
   contractual agreements are valid. This can be days, weeks, months or
   longer. The arbitrary value can be stored on the host, in a system,
   group, individual user, or application data base. It can be also
   stored in a network distributed data base.

   b. As a "random number", the "host flow label value" can be any value
   between 1 and the maximum value allowed for a IPv6 flow label. Once
   the random generated number is selected as a flow label value, as it
   is intended for use with Diffserv in traffic sent over a set of
   networks, it must be specified in the contractual agreements between



Conta & Rajahalme           Expires in May 2002     [Page 5]


INTERNET-DRAFT      Diffserv use of IPv6 Flow Label    November 21, 2001


   the user and the network providers that will carry the user's
   traffic. Obviously, the randomly selected value will be used, and
   will not change for a particular flow or set of flows, as long as the
   contractual agreements are valid. This can be days, weeks, months or
   longer. The random number value can be stored on the host, in a
   system, group, individual user, or application data base.

   c. As a "IANA number", the "host flow label value" can be any value
   between 1 and the maximum value allowed for the IPv6 flow label.
   Since it is a IANA number, it is set and held by IANA, in association
   with a certain flow or flows, characterized by various elements that
   are carried in packet headers, such as addresses, protocol
   identifiers, ports, etc.,  and the type of application or
   applications exchanging packets of that flow or those flows, or the
   type of service, or services which the application(s) are delivering
   to users. As a IANA number, this association has a permanent
   character. Once a IANA number has been selected as a flow label
   value, as it is intended for use with Diffserv in traffic sent over a
   set of networks, it must be specified in the contractual agreements
   between the user and the network providers that will carry the user's
   traffic. Obviously, the "IANA number" value will be used, and will
   not change for a particular flow or set of flows, as long as the
   contractual agreements are valid. The IANA number value can be stored
   on the host, in a system, group, individual user, or application data
   base.

     Note: it is not in the scope of this document to specify a certain
     IANA number, or family of numbers. The IANA number mechanism is
     mentioned only as one of the possible ways in which a host flow
     label value can be selected.


2.1.2. Setting the Host Flow Label Value

   The host flow label value selected by mechanisms described in the
   previous section, can be stored on a host, in a system, group,
   individual user, or application data base. It can also be stored in a
   network distributed data base. A host can fetch the host flow label
   value from the data base, and cache it or configure it in on-line
   memory:

       - In the IPv6 protocol stack information base, or
       - In a application information base.

   A host flow label value cached in the IPv6 protocol stack information
   base is filled in the IPv6 main header of every packet that belongs
   to a flow or set of flows that the host flow label value is
   associated with. This association is defined by a set of elements



Conta & Rajahalme           Expires in May 2002     [Page 6]


INTERNET-DRAFT      Diffserv use of IPv6 Flow Label    November 21, 2001


   such as source and destination addresses, protocol identifiers, TCP,
   or UDP port numbers, etc... Typically, the host flow label value
   would be cached adjacent to the source and destination addresses in a
   structure such as a protocol control block, or in a flow label member
   of a structure pointed by the protocol control block. A host could
   cache also a default flow label value for a certain flow or set of
   flows. Normally the default value would be zero (0).

   A host flow label value cached in a application information base is
   communicated to the IPv6 protocol stack as part of a communication
   setup, in case of a "connected type of communication". Typically,
   such a communication is a TCP connection, or a UDP communication in
   which the source and destination ports and source and destination
   addresses are setup for the entire duration of the communication,
   before any packet transmission takes place. In case of a "un-
   connected type of communication", the host flow label value can be
   communicated to the IPv6 protocol stack with each message that is
   passed to the stack. Typically, such a communication is a UDP
   communication in which the source address and the destination address
   and port are specified with each message being transmitted.


2.1.2.1. Host Flow Label Value API

   The API to be used for setting a Diffserv host flow label value is
   the IPv6 API [Basic-Socket]. The field used to pass the value is the
   "sin6_flowinfo" which is a member of the IPv6 socket address
   structure "sockaddr_in6".

   For the "connected communications", the host flow label value can be
   passed in a "bind", or "connect" call. The host flow label value
   associated with a connected communication can be extracted from the
   IPv6 protocol stack using a "accept", or "getpeername", and
   "getsockname".

   For "un-connected communications", the host flow label value can be
   passed in a  "sendto", "sendmsg" or "writev" call.

   The host flow label value associated with a cun-connected
   ommunication can be extracted from the IPv6 protocol stack using a
   "recvfrom", "recvmsg", "readv", or "getpeername", and "getsockname"


2.2. Router Conceptual Model for the Diffserv Flow Label

   The conceptual model for the use of the IPv6 flow label with Diffserv
   in a router describes the mechanisms that are implemented and
   employed by the routers that are forwarding the IPv6 packets in the



Conta & Rajahalme           Expires in May 2002     [Page 7]


INTERNET-DRAFT      Diffserv use of IPv6 Flow Label    November 21, 2001


   network towards their destinations. These mechanisms consist
   basically in configuring or setting up flow label classifiers
   (classification rules), and the classification processing done by the
   classification engines


2.2.1. IPv6 Flow Label Diffserv Classifier

   The IPv6 Flow Label is an additional element that MAY be included in
   a Diffserv classifier [Diffserv]. A precise representation or
   expression of a Diffserv classifier, including the IPv6 flow label
   classifier, is given in [Diffserv-MIB], specifically
   "DiffservMultiFieldClfrEntry", and "DiffservMultiFieldClrfrFlowId".

   A flow label classifier can be described as a tuple "C" that contains
   the following:

       C = (Source Address, Source Address Prefix,
            Destination Address, Destination Address Prefix Length,
            Flow-Label)

   Another representation of a flow label classifier can be:

           Flow-label-classifier:
           Type:                   IPv6-3-tuple
           IPv6DestAddrValue:      IPv6 address
           IPv6DestPrefixLength:   byte value
           IPv6SrcAddrValue:       IPv6 address
           IPv6SrcPrefixLength:    byte value
           IPv6FlowLabel:          20 bit value


   The values set in the fields of the classifiers (or classification
   rules) are strictly according to the contractual agreements between
   users and network providers: SLAs, SLSs, TCAs, TCSs.

   The mechanisms used in a router to setup the classifiers can be
   manual configuration, dynamic scripts, NMS provisioning, COPS
   provisioning, or others. These mechanisms are beyond the scope of
   this specification.

   The classification engines in a QoS engine or engines in routers
   would match packet header information, which includes the "host flow
   label value" to flow label classification rules, which includes the
   "router flow label value" as follows:






Conta & Rajahalme           Expires in May 2002     [Page 8]


INTERNET-DRAFT      Diffserv use of IPv6 Flow Label    November 21, 2001


             Incoming packet header (Source Address,
                                     Destination Address,
                                     Flow Label)
           Match
             Classification rules table entry (C)

   From the classification step, the Diffserv processing continues the
   same way as for any other MF Classifier [Diffserv-Model].


2.3. Applicability of Flow Label Classifiers - examples of use

   Differentiated Services QoS model (Diffserv) can be used anywhere in
   a network. Three examples will be presented, in which, the use of
   flow label classifiers seem to be useful. In each example, Diffserv
   would provide Quality of Service (QoS) functions for both outgoing
   and incoming IPv6 traffic, but each example will discuss particularly
   incoming or outgoing traffic.


2.3.2.1. Example 1 - User Outgoing Traffic

   The first example is an access network, and the Diffserv QoS applied
   to the user outgoing traffic. The outgoing traffic is generated by
   the direct users of the access network. The access network carries
   the users' traffic towards various downstream networks which will
   further carry the traffic towards the final destinations. Part of the
   QoS functions performed by the access network include those that are
   typically employed at the edge of a Diffserv network. The contractual
   agreements between the users and the access network providers -_
   service level and traffic conditioning agreements (SLAs, TCAs, SLSs,
   TCSs) - specify the set of parameters for the QoS, as well as the
   parameters for particular functions. One particular function that
   this specification is focusing on for this example is classification.

   If the users' hosts are setting the DSCP field in the IPv6 headers of
   the packets sent, with values that are according to the
   SLA/TCA/SLS/TCS, than access network Diffserv routers can perform
   directly DSCP based packet classification.

   If the users' hosts are not setting the DSCP field, then a multi-
   field packet classification can be employed at the edge of the access
   network. The IPv6 flow label can play a major role. User hosts would
   set the "host flow label value" according to the SLAs/TCAs/SLSs/TCSs.
   The access network edge routers would be configured with flow label
   classification rules, which would contain "router flow label values"
   according to the SLAs/TCAs/SLSs/TCSs.




Conta & Rajahalme           Expires in May 2002     [Page 9]


INTERNET-DRAFT      Diffserv use of IPv6 Flow Label    November 21, 2001


                    ________
                   /        \
                  /          \
   |----|         |          |  Outgoing
   |User|->|------|          |  User Data
   |----|  |Access| Flow A   |  Traffic
    ...    |(edge)| Flow B   |--------------->
   |----|  |Router| Flow C   |
   |User|->|------|          |
   |----|         |          |
                  \          /
                   \________/
             Diffserv Access Network

   Figure 1. Use of flow label classifier in a Diffserv Network


2.3.2.2. Example 2 - Access Networks Downstream Traffic

   Another example is a carrier network that performs QoS functions for
   downstream  traffic from several access networks.

   The incoming traffic is generated by direct users of access networks,
   which are customers of the carrier network. The carrier network,
   carries the users' traffic towards various downstream networks which
   will further carry the traffic towards the final destinations. Part
   of the QoS functions performed by the carrier network include those
   that are typically employed at the edge of a Diffserv network.

   The contractual agreements between the access network providers and
   the carrier network provider -_ service level and traffic
   conditioning agreements (SLAs, TCAs, SLSs, TCSs) - are specifying the
   set of parameters for the QoS, as well as the parameters for
   particular functions, such as classification.

   If the exit routers from the access networks are setting the DSCP
   field in the IPv6 headers of the packets sent, to values that are
   according to the SLA/TCA/SLS/TCS, than carrier network Diffserv
   routers can perform directly DSCP based packet classification.

   If the access networks exit routers are not setting the DSCP field,
   then a multi-field packet classification can be employed at the edge
   of the carrier network. The carrier network edge router could be
   configured with flow label classification rules, which would contain
   "router flow label values" according to the SLAs/TCAs/SLSs/TCSs
   between the access networks and the carrier network. These values
   would be a reflection of the "router flow label values" agreed upon
   in the SLAs/TCAs/SLSs/TCSs between users and access network



Conta & Rajahalme           Expires in May 2002    [Page 10]


INTERNET-DRAFT      Diffserv use of IPv6 Flow Label    November 21, 2001


   providers, and set by users as "host flow label values" in packets.

                    ________
                   /        \
   |----|         /          \  User Incoming
   |User|->|------|          |  Data Traffic
   |----|  |Access| Flow A   |------|
    ...    |(edge)| Flow B   |      |
   |----|  |Router| Flow C   |      |
   |User|         |          |      |     --------
   |----|         \          /      |    /        \
                   \________/       V   /          \ User Outgoing
                 Access Network  |------| Flow M   | Data Traffic
                                 | Edge | Flow N   |-------------->
                    --------     |Router| Flow O   |
                   /        \    |------|          |
                  /          \      ^   \          /
   |----|         |          |      |    \        /
   |User|->|------|          |      |     --------
   |----|  |Access| Flow X   |      |
    ...    |(edge)| Flow Y   |-------  Carrier Network
   |----|  |Router| Flow Z   |
   |User|->|------|          |
   |----|         \          /
                   \________/
                 Access Network

   Figure 2. Use of flow label classifier in a Diffserv Network


2.3.2.3. Example 3 - Network Incoming Traffic

   The last example is an access network, and the Diffserv QoS applied
   to the network incoming (upstream) traffic on its way to the users.

   The incoming traffic is generated by remote sources and carried by
   various networks all the way to the access network, which is the last
   hop network, before the final destination, the user. As typically,
   the DSCP field value changes in transit, the flow label classifier
   can play a particularly useful role in restarting the Diffserv QoS
   machinery in the access network for incoming traffic, that is,
   differentiate packets belonging to various incoming traffic flows. A
   access network user, which is a final destination of the incoming
   traffic, can have a contractual agreement with the access network
   provider - service level and traffic conditioning agreement or
   specification (SLA, TCA, SLS, TCS) that specifies certain type of QoS
   for incoming traffic from certain sources, or range of sources.
   Please see Figure 3.



Conta & Rajahalme           Expires in May 2002    [Page 11]


INTERNET-DRAFT      Diffserv use of IPv6 Flow Label    November 21, 2001


             ________
            /        \
           /          \
   |----|  | Flow A<--|------|
   |User|<-| Flow B<--|Edge  |
   |----|  | Flow C<--|Router|<--- incoming traffic
           | Flow C<--|------|
           \          /
            \________/
     Diffserv Access Network

   Figure 3. Use of flow label classifier in a Diffserv Network


3. Rules for using the IPv6 Flow Label with Diffserv.

   The rules for using the IPv6 flow label with Diffserv are as follows:



   (a)  A flow is uniquely identified by the combination of source
        address, destination address and a non-zero flow label. Diffserv
        flows MAY be aggregated by specifying a range of addresses
        and/or a range of flow labels (see further in (e)).


   (b)  A flow label of zero means that the flow label has no
        significance, the field is unused, and therefore has no effect
        on, or for the packet processing by forwarding, QOS, or
        filtering engines.


   (c)  A flow label is assigned to a flow by the flow's source node. It
        can be changed en-route, with the condition that its original
        significance be maintained, or restored, when necessary. For
        instance if the source of the flow intended that the flow label
        has a certain significance to the destination end-node, than the
        nodes en-route, that process and eventually change the value of
        the flow label, should make sure, in conjunction with the
        destination end-node, that even when the value or significance
        has changed en-route, the original information and significance
        is restored when or before the packet arrives to its
        destination.

        If the action to be performed on a particular flow label value
        in context with the packet's source and destination addresses is
        not known, a router MUST not change the value of that flow
        label.



Conta & Rajahalme           Expires in May 2002    [Page 12]


INTERNET-DRAFT      Diffserv use of IPv6 Flow Label    November 21, 2001


   (d)  The flow label must have a value between 1 and FFFFF in hex. It
        is used with other fields in the header to identify a flow. It
        is a preset value. No particular method is preferred for
        choosing the value. However, the value MUST satisfy the
        following requirements:

        It can be configured, uploaded, or transmitted to a router or a
        group of routers in any possible way, as long as it can be
        stored in the classification rules tables of the forwarding
        engines of routers along the path of the flow to the final
        destination. The flow label values are preset or agreed upon,
        and specified in a Service Level Agreement (SLA), Service Level
        Specification (SLS), Traffic Conditioning Agreement (TCA), or
        Traffic Conditioning Specification (TCS) [Diffserv]. This model
        is typical of Differentiated Services.


   (e)  In general, all packets belonging to the same flow are sent with
        the same source address, destination address, and flow label.
        However, flows can be trunked, or aggregated in macro-flows. The
        flows, members of a macro-flow, may have different source or
        destination addresses. The trunking, or aggregation of flows is
        achieved by simply wildcarding some bits or all bits in some of
        the fields of the flow label classification rules, which contain
        source address, destination address, and flow label. In other
        words range addresses and/or flow labels can be used.



4. The Diffserv Flow Label Conceptual Model: Conclusions

   The general Diffserv flow conceptual model described in the above
   sections draws the very basic mechanisms. In relationship with these
   basic mechanisms, one important question can be raised: could the
   flow label numbering space be shared, regardless of which specific
   QoS model, Intserv, or Diffserv, a flow or aggregation of flows is
   using?  The answer is YES, It is possible.

   There is no difference in the use of TCP or UDP port numbers with
   Intserv and Diffserv classifiers, in that, the TCP and UDP headers,
   which are the Intserv classifiers' "host" elements, do not carry any
   information indicating that they are Intserv classifier elements, or
   not. Therefore it can be inferred that a model in which there is no
   difference between Intserv flow labels and Diffserv host flow labels
   is valid. This means that the IPv6 flow label numbering space can be
   shared by Intserv and Diffserv.

   The acceptance of such a model, in which a flow label value does not



Conta & Rajahalme           Expires in May 2002    [Page 13]


INTERNET-DRAFT      Diffserv use of IPv6 Flow Label    November 21, 2001


   carry information regarding its use by Intserv, or Diffserv has an
   important consequence. It allows a certain "host flow label value" be
   used with both Intserv, and Diffserv, on distinct Intserv, and/or
   Diffserv QoS segments of a flow's or aggregation of flows' path.

   Note 1: a segment is a number of interconnected routers; at minimum a
   segment has one router.

   Note 2: It is obvious that in order to use the same host flow label
   value, as both Intserv, and Diffserv value, the selection of the
   value MUST be done in such a way that it does not preclude the use of
   the flow label with one model or the other. Using pseudo-random
   numbers that are generated on the fly and are short lived, for
   instance, regenerated each time an application starts execution and
   establishes a communication, will certainly prohibit the use of the
   flow label with Diffserv.

   The "host flow label value" for the use with Intserv is going to be
   included in a "filter spec" and signaled with RSVP messages to the
   Intserv/RSVP routers. The Intserv/RSVP routers will include the
   "filter spec" in the classification rules tables used by the Intserv
   traffic classifiers.

   The same "host flow label value" is going to be included in
   SLSs/TCSs, SLAs/TCAs and configured manually, or via automated
   scripts, or dynamically via COPS provisioning into the Diffserv
   routers' classification rules tables used by Diffserv flow label
   classifiers.

   Careful consideration must be given to situations in which the same
   "host flow label value" in the same source and destination address
   context is used for both Intserv, and Diffserv on the same router, or
   rather on the same interface. We call this "sharing the flow label
   numbering space between Intserv and Diffserv". Obviously, to avoid
   confusion/collisions, a choice could be to not allow sharing the flow
   label numbering space for Intserv, and Diffserv, but that IS NOT a
   method that this specification recommends.  If the EXACTLY same
   classifier rule with the same source and destination addresses, and
   the same flow label value is set in an SLA/TCA for Diffserv, and in
   the same time, the same flow label value, and source and destination
   addresses are signaled through RSVP for Intserv, it definitely seems
   possible that the router would configure in the forwarding plane only
   the Intserv filter rule, and restore the Diffserv rule when the
   Intserv flow expires or the reservation is torn down. This could be
   thought of as giving precedence to the most dynamic method of setting
   up the flow state. It is also possible that the Diffserv rule is more
   generic (i.e. matches address prefixes instead of complete
   addresses). In this case it would be possible to keep both rules in



Conta & Rajahalme           Expires in May 2002    [Page 14]


INTERNET-DRAFT      Diffserv use of IPv6 Flow Label    November 21, 2001


   the forwarding path classifier, but to arrange a "longest-prefix
   match", so that the most specific filter rule matching a given packet
   would take precedence.


4.1  IPv6 Flow Label in Mixed Intserv, Diffserv Networks

   To illustrate the elements being discussed in the previous section,
   let's consider a network which includes a Diffserv QoS domain
   adjacent to a domain supporting the Intserv model - see Figure 4.
   This example has some similarities with the example give in
   [Intserv-Diffserv].

   The Diffserv domain contains a mesh of routers, and attached hosts.
   Additional to Diffserv, the hosts support also RSVP/Intserv. A domain
   adjacent to the Diffserv domain (Intserv region) contains a mesh of
   routers and attached hosts, which support RSVP/Intserv.

   This model network can be extended in two opposite directions. At one
   extreme the Diffserv domain is pushed all the way to the periphery,
   with hosts alone having full RSVP/Intserv capability.  At the other
   extreme, Intserv is pushed all the way to the other end, with no
   Diffserv region.

               ________               ________
              /        \             /        \
             /          \           /          \
   |---| |---|          |---|   |---|          |---|   |---|
   |Tx |-|IR1|-IRx--IRy-|IR2|---|DR1|-DRx--DRy-|DR2|---|Rx |
   |---| |---|          |-- |   |---|          |---|   |---|
             \          /           \          /
              \___A____/             \____B___/

           Intserv domain A       Diffserv domain B

   Figure 4. Intserv-Diffserv Network

   Explanations to Figure 4:

   For simplicity we consider a single QoS sender, Tx, which is part of
   the Intserv Domain A, and is communicating across the network
   composed of A, and B regions with a single QoS receiver, Rx, which is
   part of the B region, but also supports Intserv and RSVP.

   The Intserv domain A is adjacent to the Diffserv domain B. Its edge
   router IR2 is direct neighbor to the Diffserv domain B edge router
   DR1.  Routers IRx, IRy are core routers in domain A. IR1 is a next
   hop router to host TX.



Conta & Rajahalme           Expires in May 2002    [Page 15]


INTERNET-DRAFT      Diffserv use of IPv6 Flow Label    November 21, 2001


   The Diffserv network domain B supports aggregate (BA) traffic control
   in the core, in routers DRx, and DRy, and is performing MF flow label
   classification, policing, and shaping at the edges in routers DR1,
   and DR2. DR2 is a next hop router to host Rx. If devices in the
   Diffserv domain are not RSVP aware, they will pass RSVP messages
   transparently. The Diffserv network domain B provides Diffserv levels
   of service, to the Intserv region. Diffserv QoS information
   (SLSs/TCSs, SLA/TCAs) is configured in routers (DR1, DRx, DRy, DR2)
   manually, or via automated scripts, or dynamically using COPS
   provisioning.

   There is no signaling between the Diffserv network domain B and
   network elements outside it. IR2 optionally can be configured with
   the information represented by the SLS/TCS, SLA/TCA and as such, it
   is able to act as an admission and traffic control agent for the
   Diffserv network domain B. Such configuration does not readily
   support dynamically changing SLS/TCSs, SLA/TCAs since IR2 requires
   reconfiguration each time the SLS/TCS, SLA/TCA changes.

   Intserv service requests specify an Intserv service type, a set of
   quantitative parameters known as a "flowspec", and a set of
   identifiers for the flow (RSVP session, sender_template,
   filter_spec). The filter_spec is flow label based. As at each hop in
   the Intserv network A, the Intserv service requests are interpreted
   in a form meaningful to the specific link layer medium. Requests for
   Intserv services must be mapped onto the underlying capabilities of
   the Diffserv network domain B, analogous to the Intserv mapping into
   802.1p capable switched segments described in [RFC 2815].

   The Diffserv network domain B is statically provisioned via manual
   configuration of routers, via automated scripts, or dynamically using
   COPS provisioning. The customer(s) of the Diffserv network region,
   which includes network domain A, and the user owner of host Rx, and
   the owner/provider of the Diffserv network domain B, have negotiated
   static contracts (service level agreement or specification, SLA or
   SLS) for the transmit capacity to be provided at each of a number of
   Diffserv service levels.  The "transmit capacity" may be simply an
   amount of bandwidth or it could be a more complex "profile" involving
   a number of factors such as burst size, peak rate, time of day etc.

   The Diffserv edge routers DR1, and DR2 do a MF flow label
   classification, policing and scheduling of traffic according to the
   levels negotiated in the SLS/TCSs, SLA/TCAs.

   The following sequence illustrates the process by which an
   application obtains Intserv end-to-end QoS when RSVP is used by the
   hosts.




Conta & Rajahalme           Expires in May 2002    [Page 16]


INTERNET-DRAFT      Diffserv use of IPv6 Flow Label    November 21, 2001


4.1.1. Intserv Control Plane Processing


4.1.1.1. Intserv Control Plane Processing in Domain A

   1. The QoS process on the sending host Tx generates an RSVP PATH
   message that describes the traffic offered by the sending
   application. The sender template contains a flow label based filter
   spec that identifies the traffic flow.

   2. The PATH message is carried toward the receiving host, Rx.  In the
   network domain A, to which the sender is attached, standard
   RSVP/Intserv processing is applied at capable network elements,
   including IR1, IRx, IRy, IR2, which install Intserv/RSVP state in the
   routers.

   3. At the edge router IR2, the PATH message is sent onward to the
   Diffserv network region.


4.1.1.2. Diffserv Control Plane Processing in Domain B

   4. The PATH message is ignored by routers in the Diffserv network
   domain B.

   5. The Diffserv QoS information (SLSs/TCSs) has been configured in
   edge and core routers manually, or via automated scripts, or
   dynamically using COPS provisioning.


4.1.1.3. Intserv Control Plane Processing in Host Rx

   6. When the PATH message reaches the receiving host Rx, the RSVP
   module, and the networking stack in the operating system of the
   receiving host RX generates an RSVP RESV message, indicating interest
   in offered traffic of a certain Intserv service type.

   7. The RESV message is carried back by the Diffserv network domain B
   towards network domain A, and the sending host Tx.  Consistent with
   standard RSVP/Intserv processing, the RESV message may be rejected at
   any RSVP-capable node in the path if resources are deemed
   insufficient to carry the traffic requested.


4.1.1.4. Diffserv Control Plane Processing in Domain B

   8. The Diffserv network domain B ignores the RESV message.




Conta & Rajahalme           Expires in May 2002    [Page 17]


INTERNET-DRAFT      Diffserv use of IPv6 Flow Label    November 21, 2001


4.1.1.5. Intserv Control Plane Processing in Domain A

   9. In IR2, the RESV message triggers admission control processing, if
   it was configured so. IR2 compares the resources requested in the
   RSVP/Intserv request to the resources available in the Diffserv
   network domain at the corresponding Diffserv service level.  The
   corresponding service level is determined by the Intserv to Diffserv
   mapping discussed previously.  The availability of resources is
   determined by the capacity provisioned in the SLS/TCS, SLA/TCA.  IR2
   may also apply a policy decision such that the resource request may
   be rejected based on the customer's specific policy criteria, even
   though the aggregate resources are determined to be available per the
   SLS/TCS, SLA/TCA.

   10. If IR2 approves the request, the RESV message is admitted and is
   allowed to continue upstream towards the sender.  If IR2 rejects the
   request, the RESV is not forwarded and the appropriate RSVP error
   messages are sent.  If the request is approved, IR2 updates its
   internal tables to indicate the reduced capacity available at the
   admitted service level on its transmit interface.

   11. The RESV message proceeds through the network domain A, through
   routers IRy, IRx, and IR1, undergoing RSVP processing, towards the
   sender Tx.  Any RSVP node in this domain may reject the reservation
   request due to inadequate resources or policy.  If the request is not
   rejected, the RESV message will arrive at the sending host, Tx.

   11. At Tx, the QoS process receives the RESV message.  It interprets
   receipt of the message as indication that the specified traffic flow
   has been admitted for the specified Intserv service type (in the
   Intserv-capable nodes).  Tx can now send traffic to Rx.


4.1.2. Intserv-Diffserv Data Plane Processing

   1. Tx sends packets to Rx. The traffic from Tx through IR1, IRx, IRy,
   to IR2, in domain A, is processed for QoS purposes according to
   Intserv - it is flow label classified, policed, and shaped/scheduled.

   2. The DR1 applies MF flow label classification, policing, marking,
   shaping/scheduling to the TX->RX traffic according to the SLS/TCS,
   SLA/TCA.

   3. Routers DRx, DRy in the core of the Diffserv domain (region) B,
   and DR2, apply Diffserv QoS to the TX-> traffic. This includes BA
   classification, policing, shaping/scheduling.

   4. The traffic arrives from DR2 to Rx.



Conta & Rajahalme           Expires in May 2002    [Page 18]


INTERNET-DRAFT      Diffserv use of IPv6 Flow Label    November 21, 2001


   In this manner, we obtain end-to-end QoS through a combination of
   networks that support flow label RSVP/Intserv and networks that
   support flow label Diffserv.


5. Security Considerations

   This document introduces no new security concerns. The security
   concerns are essentially identical to those concerning the diffserv
   field (traffic class) itself, as outlined in [DSCP-Def], {Diffserv],
   and [Differv-Tun].

   When IPv6 packets are encrypted using ESP Transport or Tunnel Mode
   [IPSec-ESP], the port and protocol numbers are hidden, but the flow
   label is not. Thus MF classification remains possible even for
   encrypted traffic.


6. IANA Considerations

   No IANA considerations need be made.


7. Acknowledgments

   The discussion on the topic in the IPv6 WG mailing list has been
   instrumental for the definition of this specification. The authors
   want to thank Steve Blake, Jim Bound, Francis Dupont, Robert Elz,
   Tony Hain, Christian Huitema, Frank Kastenholz, Hesham Soliman,
   Michael Thomas, Jun-ichiro itojun Hagino, and others that
   unintentionally perhaps were omitted, for their tireless
   contributions on the list.

   Very special thanks to Brian Carpenter for his patient participation,
   guidance, sharing of ideas, and highly principled actions.


8. References

   [IPv6] S. Deering, R. Hinden, "Internet Protocol Version 6
   Specification", RFC 2460, December 1998.


   [Diffserv] M. Carlson, W. Weiss, S. Blake, Z. Wang, D. Black, and E.
   Davies, "An Architecture for Differentiated Services", RFC 2475,
   December 1998





Conta & Rajahalme           Expires in May 2002    [Page 19]


INTERNET-DRAFT      Diffserv use of IPv6 Flow Label    November 21, 2001


   [DSCP-Def] K. Nichols, S. Blake, F. Baker, D. Black, "Definition of
   the Differentiated Services Field (DS Field) in the IPv4 and IPv6
   Headers", RFC 2474, December 1998.


   [PHB-ID] D. Black, S. Brim, B. Carpenter, F. Le Faucheur, "Per Hop
   Behavior Identification Codes", RFC 3140, June 2001.


   [Diffserv-Tun] D. Black, "Differentiated Services and Tunnels", RFC
   2983, October 2000.


   [Diffserv-PIB] M. Fine, K. McCloghrie, J. Seligson, K. Chan, S. Hahn,
   A. Smith, "Differentiated Services Policy Information Base", Work in
   Progress.


   [DiffServ-MIB]  F. Baker, K. Chan, A. Smith "Management Information
   Base for the Differentiated Services Architecture", Work in Progress.


   [Diffserv-model] Y. Bernet, S. Blake, D. Grossman, A. Smith "An
   Informal Management Model for Diffserv Routers", Work in Progress.


   [IPv6-flow-label]J. Rahajalme, A. Conta, " An IPv6 Flow Label
   Specification Proposal", Work in Progress.


   [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate
   Requirement Levels", BCP 14, RFC 2119, March 1997.


   [CONS] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
   Considerations Section in RFCs", RFC 2434, October 1998.


   [Basic Socket] R. Gilligan, S. Thomson, J. Bound, W. Stevens. "Basic
   Socket Interface Extensions for IPv6," RFC 2533 March 1999.


   [Intserv-Diffserv] Y. Bernet, P. Ford, R. Yavatkar, F. Baker, L.
   Zhang, M. Speer, R. Braden, B. Davie, J. Wroclawski, E. Felstaine. "A
   Framework for Integrated Services Operation over Diffserv Networks",
   RFC 2998, November 2000





Conta & Rajahalme           Expires in May 2002    [Page 20]


INTERNET-DRAFT      Diffserv use of IPv6 Flow Label    November 21, 2001


9. Authors' Addresses

   Alex Conta
   Transwitch Corporation
   3 Enterprise Drive
   Shelton, CT 06484
   USA
   Email: aconta@txc.com


   Jarno Rajahalme
   Nokia Research Center
   P.O. Box 407
   FIN-00045 NOKIA GROUP
   Finland
   E-mail: jarno.rajahalme@nokia.com



































Conta & Rajahalme           Expires in May 2002    [Page 21]

1239


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/