Hi Shane,
On 4/15/10 1:25 AM, Shane Amante wrote:
>
> More generally, this really raises the question of the practicality
> of searching for Layer-4 protocol, source & destination port info in
> headers and using them as input keys for LAG + ECMP when forwarding
> IPv6, particularly on high-speed core routers. Ultimately, if the
> flow-label was known to denote a proper "microflow" (as defined by
> RFC 2474), then it would make HW implementations much simpler in that
> they have a known & fixed set of header fields, specifically: {dest
> address, src address + flow-label}, they would use as input keys for
> LAG + ECMP. Arguably, it makes adding Extension Headers easier in
> the future, as well, given that we don't have to worry as much about
> intermediate routers being unable to look past them ... Of course,
> the downside is this effectively boxes out any other (future) use of
> the flow-label. Thoughts?
This type of scenario is what prompted my question to Brian C. at the
mic in Anaheim. In a previous life, I was looking at ways to leverage
ECMP for IPv6 traffic when the traditional 5-tuple was unavailable.
Typically, this was due to the payload being encrypted. The only sane
way was to hash <Src Addr, Dst Addr, Flow Label> as long as the Flow
Label was set by the originating host. The prototype I hacked together
on the host side set the flow label per socket. I also threw together a
Quagga-based marking box that did the DPI on unencrypted packets and
assigned a unique Flow Label per <Protocol, Src Port, Dst Port> in order
to allow boxes doing ECMP to use the Flow Label-based 3-tuple. The cost
of doing the DPI to mark the packets was quite heavy given the arbitrary
extension headers I threw at it.
In the long run, I believe we need a way to create ECMP & LAG hashes out
of *just* the base IPv6 header fields given these constraints on finding
the layer-4 information and the limitation that some routers have of not
having the entire packet available for searching.
Regards,
Brian
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
