Catching up after some delay and being able to discuss this
in person with Francis yesterday...
Steve Deering wrote:
>
> At 5:30 PM -0600 12/1/00, Brian E Carpenter wrote:
> >Francis Dupont wrote:
> >...
> > > => just associate a QoS to a SPI and send the information (ie. how to
> > > classify packets (addresses, ..., SPI) and the QoS) to the classifier
> > > (which is by definition on-path).
> >
> >Wrong model. That requires signalling; diffserv doesn't have signalling.
> >
> >This works for RSVP as itojun explained, but it doesn't work for diffserv.
>
> I'm getting confused. The Flow label is intended for intserv, so why
> are you talking about subverting it (or the SPI) for diffserv?
Because diffserv has a problem if it needs to re-classify encrypted
traffic, since the port & protocol #s are hidden. However, the idea
of an extension header is *much* better than subverting the flow
label.
>
> If diffserv requires en-route inspection of the 5-tuple in order to set
> the DSCP bits (and therefore you are trying to overload the Flow Label
> with port semantics in order to avoid the cost of finding the ports),
> that ought only to be done near the source edge (where parsing multiple
> headers is less onerous), if at all, because of the ease with which one
> could lie about one's port numbers to obtain better service. Are core
> routers really going to provide different qualities of service to packets
> based on an easily "forged" 8-bit integer?
No, as has been said this will happen (if at all) in border routers.
Theft of service is an issue - we don't want to pay authentication
overhead in a real-time classifier. But traffic policing can take
care of most cases. See RFC 2474 and 2475.
> I thought core routers classified packets for diffserv packets according
> to the arrival interface and the arriving DSCP bits, *not* the 5-tuple.
Absolutely. It's only at the borders.
So the model that probably works is an optional extension header that
can be used for encrypted packets where the source doesn't mind exposing
the port and protocol #s. However, people building classifier hardware
may have something to say about this in terms of real time efficiency.
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]
--------------------------------------------------------------------
