> "James Kempf" <[EMAIL PROTECTED]> writes:
> > The most compelling application I've seen is
> > for QoS classification when the packet
> > is encrypted. Most of the other applications
> > people have cited can probably be handled
> > by other means, as you point out.
>
> Can't we do classification by expressing the traffic type in the
> "traffic" field in the encapsulating packet, however?
>
The traffic field gives the classification. The flow label
could serve as a proxy for the port number and
protocol type, according to my understanding of the proposal
to define the flow label field. The traffic field can change when
the packet goes from one provider's network
to another, depending on the type of QoS deployed by the
provider within their network, the flow label would presumably be used
to determine what traffic classification to use when
the packet is being reclassified since
the flow label is being defined to be immutable. If the
packet is not encrypted, the port number and protocol
type can be read directly, of course.
>From a service provider's perspective, it would
be very advatageous to have some way of
assuring QoS classification of encrypted traffic,
since it would greatly reduce the anxiety involved
in peering of voice traffic. This anxiety
seems unreasonable from an engineering
perspective (at least, I find it so), but
perhaps understandable from a business
perspective.
jak
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
