Robert Elz wrote:
> 
>     Date:        Wed, 05 Sep 2001 10:03:24 -0500
>     From:        Brian E Carpenter <[EMAIL PROTECTED]>
>     Message-ID:  <[EMAIL PROTECTED]>
> 
>   | That's why the "well known value/locally unique value" dichotomy seems
>   | more hopeful.
> 
> But that means that a packet is one or the other, and hence inserv
> (which needs a micro-flow ID, not a fixed classifier) or diffserv
> (which needs a classifier, but no micro-flow ID), but never both.
> 
> How can that possibly allow a packet to flow through a local intserv
> domain in my (end-user's net) and then through diffserv in the outside
> ISPs, and then back into intserv processing again when it reaches the
> destination net.
> 
> I don't know how to do that now, but I know I don't want to make it
> impossible.   And given that we have ESP, that only the source/dest
> nodes can decode, all we have left for anyone to look at is what we
> put in the IPv6 header, and other headers before ESP.  At the minute
> the only proposal I have seen is the flow label usage.  And that seems
> to be being designed to preclude using more than one QoS paradigm (for
> one particular packet).

I think that this can be done. In fact, INTServ, could use the current
Diffserv flow label 
as long as Intserv allows non-PRN numbers.

The only issue is that a host MUST NOT set the same label value for the
same pair of
source and destination to be used by one router for both Diffserv and
Intserv. 

Which is to say, that a router, MUST NOT have two identical
classification rules, in two distinct tables, one in the Intserv
classification table, one in the Diffserv classification table. This is
to say that one router MUST have a certain 3 tuple, containing a certain
flow label value, stored in a classification rule either by way of RSVP
(Intserv), or by way, of Configuration/etc... (Diffserv), but not by
both.

> 
>   | Not particularly. But I think we do need to find solutions that minimise
>   | change. As has been said, people are pouring silicon.
> 
> Minimise change because people are making hardware today must mean
> leaving the flow label the way it is in 2460 (or making that text be
> normative instead of an appendix).
> 

That is not acceptable because it excludes Diffserv. Something MUST be
done to have both, and than maximize that (as much as possible).

> [...]
> 
> kre

Alex

S/MIME Cryptographic Signature

Reply via email to