Re: FW: Load sharing on the ring
>The discussion is whether we need load balancing capabilities
>in RPR.
>
>The issue is of load balancing on both the east and west interfaces.
>1. RPR selects the working direction for a given destination MAC address
>and never changes it unless required for protection.
>OR
>2. RPR may load balance over the working and the protection path.
Packet ordering is a treacherous area.
Not all packets need stay in order. Packets between different source
and destination pairs can generally be reordered. Packets between
the same source and destination need to stay in order, or bad things
can happen (TCP slows down, simpler sliding window protocols can
deadlock).
Unfortunately the definition of source and destination can vary.
Certainly, packets between different L2 destinations should be
safe to reorder, so MAC address based load sharing is fine.
For TCP/IP, the layer 4 source/destination (based on TCP port number)
must stay in order, but different TCP connections can be reordered
even if they are going between the same L2 source/destination pair.
This sort of load sharing isn't practical to do at the MAC layer,
which shouldn't require knowledge of port numbers.
My opinion:
I think the RPR should choose the direction based on MAC address, and
not change direction except in case of protection events. However, the
RPR should make allowances for a single node on the ring to publish
multiple MAC addresses, to allow load sharing. Policies of when to use
a particular MAC address out of the set would depend on the upper
layer protocol in use, and not be written into the RPR MAC spec.