Derek Fawcus wrote:
>
> On Thu, Aug 16, 2001 at 08:44:59AM -0500, Brian E Carpenter wrote:
> > I think the WG needs to decide once and for all whether the flow label is
> > a) a CATNIP or MPLS-like routing handle
> > or b) a QOS hint for intserv only
> > or c) a QOS hint for intserv and diffserv
> > or d) a waste of bits
> >
> > We can get back to the details once we have a consensus on this.
>
> I'd suggest e) A flow identifier for router optimisation.
>
> I sort of see this as a variation of b), i.e. it identifies a flow using
> a PRN but does not imply any QoS usage. However it doesn't preclude the
> flow label being used in scenario b).
>
> Specifically - I see it as a way of replacing the srcPort/dstPort tuple
> that routers peek at in the TCP/UDP header. Currently I only see this
> being used in one scenario, that is for load balancing across multiple
> paths.
Can't parse. By "currently I only see" do you mean
-- this is what I see happening in the real world today
or -- this is what I envisage for the future ?
The fact is that port numbers are used for both intserv and diffserv
classifucation, and this won't go away.
>
> At the moment (for v4) if a lookup on the dst address address leads to
> a route with multiple paths, and the route is appropriatly marked,
> the flows of packets can be shared across these multiple paths. This
> is done (for min size IPv4 headers, carrying TCP or UDP) by hashing
> the srcIP/dstIP/srcPort/dstPort and using this to help choose which
> path to forward the packet over.
Yes, such hacks are not unknown. I don't think we should endorse this
sort of thing in the design of the IPv6 header.
>
> Given that for IPv6 we can't guarentee the TCP/UDP header is at any
> given offset, or even that it's readable. One would need some other
> way of identifying flows if the above load balancing was to be performed.
>
> For v6 a core router engine (either s/w path, or ASIC [as fix logic
> or programable device as someone suggested]) one will not be looking
> beyond the base IPv6 header. For an edge rouer engine, one may well
> be looking inside the packet for say classification.
>
> Hence use the flowID. Without this we could only hash based upon the
> srcIP/dstIP and hence all flows between a given src/dst pair will hit
> the same path.
>
> With this info in the flow label, one would be able to hash together
> the srcIP/flowLabel to find the correct path. As a router in this
> situation one would always have to combine the src IP address, but
> if the flow label was defined to uniquely distinguish a given
> dstIP/srcPort/dstPort flow, one could skip compining the dstIP at
> the router.
>
> The reason for specifying that it be a PRN is simply to make the hashing
> cheaper at the router.
>
> I said above that this doesn't preclude using the flow label for scenario
> b), this can be achieved simply by picking a PRN for scenario b) from
> the same number pool as for scenario e). Thus if intserv QoS is being
> used, a (set of) routers would have been informed (via RSVP)
> about the relationship between that flow label and certain QoS
> requirements, any other routers in the path of the packet flow that
> don't know about intserv/RSVP will simply treat packets in the flow as
> scenario e).
Unfortunately your suggestion does preclude diffserv classification for
encrypted traffic. Since it's also in support of a hack, I'm against it.
>
> So the usage becomes one that is (potentially) orthogonal to QoS. It
> will be usable for non QoS'ed (intserv or diffserv) packets, as well
> as with both intserv and diffserv.
No, it is of no value for diffserv. The only way the flow label
can be of use to diffserv is if it has semantics.
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]
--------------------------------------------------------------------
