[rbridge] Summary 1 of load-balancing rbridges
zinin at psg.com
Thu Aug 11 11:57:06 PDT 2005
When I looked at it a couple of months ago, it seemed possible to hash
based on the original src+dst MAC addresses. This makes it L3/4-agnostic
and still gives sufficient traffic dispersion.
Thursday, August 11, 2005, 11:12:50 AM, Alia Atlas wrote:
> As per Radia's request, here's my best effort at a summarization.
> The introduction of rbridges implies that rbridges will need to do
> load-balancing among equal-cost paths. To avoid reordering at Layer
> 4, it is very desirable (even necessary) to have the rbridges able to
> identify the micro-flows. There are 3 possible ways of doing this
> that were discussed.
> (1) Each rbridge peeks under the rbridge shim header & encapsulated
> MAC frame to the (potentially) IP packet underneath. If there is an
> IP packet, then an identification as to the micro-flow is made and the
> frame is forwarded based on the micro-flow. Behavior if there isn't
> an IP packet hasn't been discussed.
> (2) The ingress rbridge determines the micro-flow and marks the frame
> with a micro-flow tag in some way. Interior (or midpoint) rbridges
> can use this tag to identify the micro-flow instead of having to peek
> underneath the rbridge shim header. This is an optimization of (1)
> that reduces the complexity of interior rbridges at the cost of
> additional header size.
> (3)Each egress rbridge could have a number of aliases. The ingress
> rbridge identifies a micro-flow & forwards the frame to a particular
> alias, indicating a path. There are some issues here with number of
> paths, handling addresses connected to multiple egress rbridges, etc.
> Option (2) seems promising, but whether it is the correct trade-off
> versus (1) needs more discussion and input. Please comment. :-)
> rbridge mailing list
> rbridge at postel.org
More information about the rbridge