[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: QoS selectors (was LAST CALL: IKE)
At 2:38 PM +0200 6/30/03, Francis Dupont wrote:
> In your previous mail you wrote:
> I'm also open to suggestions from IPv6 experts about what to do
> there, for flows.
>=> IPv6 traffic class are DiffServ bits and should be handled exactly
>as in IPv4.
> The IPv6 Flow Label is very different: it is clearly designed as
>an alternative to traditional 5-tuple filters, so IMHO IPsec/IKE should
>include it as a possible selector.
> BTW RFC 2460 (IPv6 specs) doesn't really define Flow Labels, the
>document to read is draft-ietf-ipv6-flow-label-07.txt,
>here is the beginning of its introduction:
> A flow is a sequence of packets sent from a particular source to a
> particular unicast, anycast or multicast destination that the source
> desires to label as a flow. A flow could consist of all packets in a
> specific transport connection or a media stream. However, a flow is
> not necessarily 1:1 mapped to a transport connection.
> Traditionally, flow classifiers have been based on the 5-tuple of the
> source and destination addresses, ports and the transport protocol
> type. However, some of these fields may be unavailable due to either
> fragmentation or encryption, or locating them past a chain of IPv6
> option headers may be inefficient. Additionally, if classifiers
> depend only on IP layer headers, later introduction of alternative
> transport layer protocols will be easier.
> The usage of the 3-tuple of the Flow Label and the Source and
> Destination Address fields enables efficient IPv6 flow
> classification, where only IPv6 main header fields in fixed positions
> are used.
Thanks for the clarification.
It looks like it makes sense to use the IPv6 traffic class as the
equivalent of the DiffServ bits, if the WG agrees that we ought to
use these are a new selector type.
What do other folks think about this suggestion to offer the Flow
Label as another selector type, for the reasons cited above by