I hope that after three weeks of exchanges, everybody is convinced that
we will not get any consensus on whether the best handling of QoS is
diffserv, intserv, or maybe no QoS at all. Let's try to be practical. We
have a simple problem to solve, the definition of the flow label in the
IPv6 specification. I propose the following compromise:
The flow label is comprised of 20 bits, divided between a four bit label
type and a 16 bit label value. IPv6 sources may set the flow label type
and the flow label value to label sequences of packets for which they
request special handling by the IPv6 routers, such as non-default
quality of service or "real-time" service; the label type defines how
the label value shall be used in the production of these services.
Label types may be defined in IETF standards and registered with the
IANA. This specification (i.e. IPv6) defines only one label type, the
basic label, whose value in binary is 0000. Sources that do not require
any specific service should set the label type to the basic label and
the label value to a null value.
When the label type is the basic label and the label value to a non null
value, IPv6 routers are expected to treat identically all packets that
carry the same source address, destination address and flow label. For
example, when traffic is load balanced along several alternate paths,
these packets should all sent on a single path; when classification is
performed for the purpose of quality of service, these packets should
all be classified in the same class. If the label type is set to the
basic type, IPv6 routers SHOULD NOT rewrite or alter the flow label
value.
Processing of the flow label, and possibly rewriting of the label value,
is specified in the IETF standard defining the label type. When a router
encounters a packet with an unknown flow label type, it should treat the
packet as if the label type was the basic value and the label value was
the null value. Routers SHOULD NOT rewrite or alter the flow label value
if the flow label type is unknown.
I believe it captures most of our discussions: we get a basic label that
is roughly equivalent to the label currently assumed by RSVP/Intserv; we
get reserved bits for the future generations; and we get an extension
mechanism that can possibly used by Diffserv, charge to them to describe
exactly how they intend to use it.
-- Christian Huitema
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
