Christian,
While you intended to stay outside of the different QoS schemes, you still
wanted to cover the intserv/RSVP use of the flow label. Some clarifying
questions:
Assuming that you proposed intserv to use the label type basic: With the
label type basic and a non-null label value, are routers supposed to do what
you propose regardless of the presence of intserv state? I.e. to nail down
the path even if intserv is not used?
Could routers not interested in QoS classification based on the flow label
at all (e.g. diffserv interior routers) safely use just the 16 bit label
value for path distribution (ignoring the label type)?
With the current flow label semantics the routers can avoid doing intserv
state lookup if the flow label is null. If the flow label is used for path
distribution, the router will be searching for the intserv state for all the
packets (assuming the router does intserv at all). So from this
point-of-view it might be better to designate a separate label type for
intserv?
Or maybe intserv should be able to use whatever label type it wishes. Some
other type could allow for example rewrite at the intserv domain egress,
allowing the flow label to be mapped a value meaningful for some other
QoS/forwarding domain. (The value itself could be either carried in RSVP or
decided by the SLA between the intserv domain egress and the next domain).
What I'm aiming at is to see if a classifying router (intserv, diffserv, or
other) could be ignorant of the different flow label types when doing the
lookup based on the 3-tuple of the source address, destination address and
the 20 bit flow label. What state is then found based on the lookup would
tell the router what to do with the packet (which flow it belongs to, how to
police it, queue it, possibly remark DSCP and/or flow label, which interface
to use for output, etc.). In this scenario all the difference of the
different label types would be in the control plane (i.e. population of the
state found by the lookup engine). The silicon doing the classification
would remain the same regardless of the label type.
Or will the definition of the label type result in specialized silicon for
the different type values?
Jarno
Christian Huitema wrote:
> 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]
--------------------------------------------------------------------
