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