Derek Fawcus wrote:
> 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.
>
> 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.
>
> 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.
Including srcPort/dstPort in a load-balancing hash is generally a bad idea,
as documented in RFC2991 pg. 3.
Regards,
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Steven L. Blake <[EMAIL PROTECTED]>
Ericsson IP Infrastructure (919)472-9913
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
