[rbridge] load-balancing rbridges
akatlas at gmail.com
Wed Aug 10 16:39:11 PDT 2005
On 8/10/05, Joe Touch <touch at isi.edu> wrote:
> >>IMO, the goal is to reuse existing solutions as much as possible here...
> > Yes, I agree. The problem is that no hardware is used to digging that
> > far into the packet, as far as I know.
> > In the back of my mind is the following. First, assume that the shim
> > header has the structure of an MPLS shim header. Second, assume that
> > the egress rbridge is represented by an MPLS label. (For now, let's
> > not worry about the label distribution pieces yet or the
> > multicast/broadcast where the ingress rbridge is needed.)
> > Third, what is underneath the shim header is not an IP packet & will
> > not be identified as one.
> But anything we can't parse we can't assign to a specific flow, unless
> we send all such things to a single default path. Otherwise those
> packets will be reordered.
I am assuming that the ingress is capable of doing more parsing. For
instance, the ingress gets the frame before encapsulation & can use
current peeking technology to look inside it.
> > So, for hardware that supports, say, MPLS
> > pseudo-wires, the frame would be forwarded based on a hash of the MPLS
> > label stack. This implies that the ingress rbridge could put a hash
> > as the inner label (under the egress rbridge label) & the good
> > load-balancing could happen.
> The only flows you will have a hash for are those that the ingress can
> parse, i.e., those with an inner IP/transport header. If the ingress can
> parse them sufficiently to create a hash, then so can the interior
> rbridge nodes. The only difference is that the interior nodes need to go
> past the shim header, but that's just an offset.
First, the question is whether one is trading off the interior
complexity for the edge. It's certainly possible for the interior to
have to dig further down, and maybe that's necessary for the
broadcast/multicast, but if it is avoidable, that might be good.
Getting past the shim header may or may not be completely trivial. It
depends on the forwarding path architecture. For instance, once could
store most of the frame & only pass the beginning to the hardware that
makes a forwarding decision.
> > Of course, this assumes that the egress rbridge can pop off the 2
> > labels and that the inner label isn't actually ever used for
> > forwarding, but that seems somewhat reasonable to me.
> > Thoughts?
> I'm not sure what it buys to do the hash only at the ingress vs. at the
> interior nodes. Both have the same amount of info. It doesn't seem to
> hurt anything; it trades edge complexity for interior (which is good)
> but costs bandwidth by making the shim larger (which is bad). Seems like
> a toss-up to me...
For bw, we're talking an extra 32 bits. I think of it as more a
question of complexity in implementation for the interior nodes & how
much functionality can be preserved.
More information about the rbridge