Brian,
> But in the diffserv case, which is stateless (no signalling,
There is RFC2996 to fix this problem...
> the only out-of-band mechanism that works is if the flow label has
> intrinsic semantics. The fact that the packet belongs to a class is
> useless information on its own; you need to know what that
> class means,
> and that can only be conveyed by an encoded field, since there is no
> signalling or state.
No argument about needing an immutable encoded field, just that
it doesn't need to be the Flow Label. There is still the opportunity
for the diffserv WG to create a standard set of encodings for the
TC field that are immutable end-to-end, and as you note below that
is in process.
> No, it's the whole point: the classifier at a domain ingress must
> choose an appropriate DSCP value to write into the TC field, and that
> *requires* the classifier to interpret the semantics of some set of
> fields in the packet header.
Or simply to expect that the value in the TC already is the
classifier and configure the local PHBs accordingly.
> ... The proposed solution is to use
> the globally
> defined PHB ID to drive the classifier.
So why do we also need to usurp part of the FL field, when a
global PHB will result in an end-to-end consistent TC field?
Tony
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
