Brian,
I totally agree with the notion that for diffserv domains, or multiple ones
with SLAs dealing with DSCPs in between, the DSCP field is enough for
diffserv aggregation and policing. And I agree with Tony in that a second
mutable 'DSCP' field doesn't provide any more additional value, since it
seems that a domain egress always could map from an internal DSCP to an
equivalent standardized DSCP value.
It is the case that Christian brought up for which there could be value for
the PHB-ID flow label: regardless of the DSCP value the packet came in (even
if there is an SLA with the previous operator, or even if the original
source did not pay for any QoS), there might be an SLA with the
operator/customer later in the path that wants to pay for the preferential
treatment.
This treatment could be based on intserv, in which case the ingress would
need to rewrite the incoming packet's flow label to use it for intserv for
the rest of the path, if the source set it to '00000' or to any other
"diffserv value". If it was already set to an intserv value, it doesn't need
to be changed. (Maybe the destination would state in the intserv signaling
method what flow label value to use?).
A second alternative would be to use diffserv to get the preferential
treatment for the rest of the path. The SLA would need to state how to
classify the packets to get the preferential treatment. Christian's example
used "traffic type" indicator (maybe in the flow label field). I believe the
"traffic type" should be application independent, i.e. it should indicate
the desired per-hop-behavior. This would enable SLAs like "if the source
said it's important, I'll pay for the indicated better treatment".
Some more comments inline below:
Brian E Carpenter wrote:
...
> > Speak to your co-author who keeps insisting that they are
> > mutable.
>
> Yes, and I think I disagree with him :-)
>
I guess Alex's point has been that technically they are mutable, since
muting them will not mess AH or any checksums.
And I believe there are cases like what Francis mentioned: If the flow label
is '00000' it might need be changed to some other value by some domain
egress that somehow knows better than the (legacy) source.
>
> All diffserv classifiers require configuration. This would
> mean configuring
> a classifier to look for (say)
>
> Destination IP = Big Customer X
> Source IP = *
> Flow Label = 12345
>
The wildcard in Source IP is dangerous. If there is a wildcard, someone
having knowledge of the SLA could send the X some extra packets every now
and then, if it will result in monetary flow from X to ISP.
> This is a new form of diffserv classifier. Alex has a draft
> ready to ship
> on this, but we decided to wait. Since "12345" would be a
> globally defined,
> well known value, it is just built into the QOS policy
> repository of any
> ISP that wants to support it. (This is what Tony thinks should be done
> with the DSCP values.)
>
There is the case I rephrased on top: Even if the source did not pay enough,
and the packet would not get the treatment the destination would want, the
packet may need to be re-classified and marked again.
> ...
> >
> > I thought the current definition of the MF-classifier in
> intserv would allow
> > usage of the flow label field for classification.
>
> Yes, except that RFC 2460 does not describe this in normative text.
>
Well, it should, and the RSVP specs should allow MF-classifiers based on the
flow label field, if they don't already.
> It's the former; if an ISP chooses to disbelieve the upstream ISP,
> and re-classify the traffic, the semantics of the transport
> header are exactly the information of interest.
But due to the end-to-end nature of the transport headers, it would be the
eventual destination that needs to specify what values to use for
classification. So it is not the ISP who "believes" any bits, but the SLA
(where the parameter values originate from the eventual destination?)
specifies the transport header values to match against. For the ISP the only
semantics these bits have is that in the context of the specific SLA he
believes getting paid for providing preferential treatment.
> The security question is whether revealing a PHB ID is acceptable.
This needs to be stressed in the discussion. It may be that some think that
the equivalent of the port numbers would be revealed in the flow label.
> The SLAs and local policies are database and human driven.
> They need to anticipate
> all ports etc to be used in advance.
>
Unless the classification would not be based on the transport stuff at all,
but to the proposed diffserv flow label?
Another problem for such SLAs could be IPv6 renumbering. Anybody thought of
the implications?
Jarno
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
