[rbridge] Summary 1 of load-balancing rbridges

[Alex Zinin]

Alia,

 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.

-- 
Alex
http://www.psg.com/~zinin

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.  :-)

> Alia
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://www.postel.org/mailman/listinfo/rbridge