Subject: [rbridge] Summary 1 of load-balancing rbridges

From: Vishwas at sinett.com (Vishwas Manral)
Date: Thu, 11 Aug 2005 21:13:43 -0700

Hi,

There are two things that need to be considered: -

1. When there are fragments we cannot get the Layer-4 information (flow
reordering can happen - unless we keep states).
2. Not all packets may have layer-4 information; some could be
applications running over Layer-2/ Layer-3.

Currently different switches can use different criteria for doing load
balancing. However if the criteria is a tag in the header it becomes
easier and more consistent (like flow id). 

I am not sure if we want to define a criterion for load balancing; we
can however have a field in the header for the same (and let the ingress
node decide the criteria, which could be configurable).

Thanks,
Vishwas
-----Original Message-----
From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
Behalf Of Alia Atlas
Sent: Thursday, August 11, 2005 11:43 PM
To: Radia.Perlman at sun.com; Developing a hybrid router/bridge.
Cc: Joe Touch
Subject: [rbridge] Summary 1 of load-balancing rbridges

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

---

From: touch at ISI.EDU (Joe Touch)
Date: Fri, 12 Aug 2005 14:47:54 -0700

> reordering can happen - unless we keep states).

That's not new for rbridges. Again, it seems useful not to have rbridges
try to solve every problem under the sun, but rather only the ones it
creates ;-)

> easier and more consistent (like flow id). 

That just moves the problem to tag assignment, which may reduce
complexity for inner (non ingress/egress) rbridges, but does so at the
expense of a larger shim header.

It does not matter if different switches use different criteria for load
balancing, though - it matters only that each switch is consistent.
That's sufficient to avoid reordering throughout.

> node decide the criteria, which could be configurable).

I still do not see the particular utility of reinventing MPLS-ish tags
in the shim header; if you want MPLS, you can use that. If not, then let
the interior rbridges decide how they want to handle load balancing
themselves. None of the peeking we're talking about is extraordinarily
complex.

Joe

---

From: stephen at dino.dnsalias.com (Stephen J. Bevan)
Date: Fri, 19 Aug 2005 20:03:11 -0700

Joe Touch writes:
 > It does not matter if different switches use different criteria for
 > load balancing, though - it matters only that each switch is
 > consistent.

True, but if one can arrange for the switches to, optionally, use the
same criteria then it opens up the possiblity of doing split
multi-link trunking (to use Nortel's term for this) in a vendor
neutral manner.

---

From: touch at ISI.EDU (Joe Touch)
Date: Fri, 19 Aug 2005 22:33:27 -0700

> multi-link trunking (to use Nortel's term for this) in a vendor

Wouldn't that happen as the result of a consistent, multi-path routing
protocol? I.e., what I'm proposing is that switches MAY use local
criteria for balancing or supporting multipath, but MAY also use a
coordinated system if they agree to.

Joe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/rbridge/attachments/20050819/4f48acf8/signature.bin