Sorry if this is redundant; it's been a hard thread
to keep up with.
Brian E Carpenter writes:
> > There is absolutly no reason to tie the
> > Flow Label field and the Traffic Class field together, which is
> > the only point of defining diffserv semantics for the Flow Label.
>
> No, the point is to provide partial replacement of the {port, protocol}
> semantics that are hidden by ESP. There is no tying together of
> Traffic Class and Flow Label. They remain orthogonal.
I've got what may be a pertinent question: do the re-classifiers
require actual knowledge of the contents of the encrypted headers,
or do they just require the ability to differentiate the unique
flows associated with a particular DSCP?
If it's the former, I think I object to requiring a node to
_have_ to reveal information (quite valuable information, if
you consider it) in order to obtain QoS. At the very least,
how is a non-signaled diffserv host to know whether it
should or should not insert the revealing information into
the flow label? If the answer is that it always has to do
that, you have effectively defeated one of the useful
protections of ESP. This would be very bad.
> > The set of packets identified as a
> > flow will be the same with either QoS mechansim, so why is there
> > a need to have distinct semantics unless someone in the middle wants
> > to interpret them?
>
> Diffserv is blind to microflows; there is no flow identification.
> However, diffserv classifiers in the middle *do* need to (re)interpret
> packet headers. That is how diffserv works.
I'm afraid that this makes no sense at all. A
microflow is nothing more than a tuple made up
of some set of fields in the packet. If part of
the protocol(s) takes some action based on that
tuple, I'd say that it is certainly microflow
aware, unless you add to the definition that
a microflow also requires saved state in the
router too. Even with that restriction, you
are merely drawing the slim difference between
frozen uflow classifer state (eg, provisioned
ACL's...) vs. dynamic classifer state (ala
intserv).
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
