Tony Hain wrote:
>
> Brian,
>
> > But in the diffserv case, which is stateless (no signalling,
>
> There is RFC2996 to fix this problem...
That only works up to the first diffserv domain on the traffic path.
As the packets enters a 2nd, 3rd etc. diffserv domain, the problem
reappears. By the way, the absence of signalling is a virtue, not a
problem, from the scaling viewpoint.
>
> > 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 isn't. By construction, DSCPs are "SHOULDs" and are always mappable.
PHB IDs are meta-values.
> > 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.
This is exactly what ISPs have always said they will not do in
the general case, although of course they will if the SLA
in place says so.
>
> > ... 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?
Because the diffserv architecture requires the option to
reclassify traffic, because that's what the ISPs say they need.
I don't like the word "usurp". If the flow label was already
standardised and in habitual use, it would be appropriate,
but then we wouldn't be having this conversation anyway. Since
it is not standardised, there is nothing to usurp.
Brian
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
