I can live with this.
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Christian Huitema
> Sent: Thursday, September 06, 2001 3:34 PM
> To: Brian E Carpenter; Michael Thomas
> Cc: ipng
> Subject: refocusing: what about the flow label?
>
>
> 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]
> --------------------------------------------------------------------
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
