LACP

From IEEE 802.1AX Link Aggregation (Initial release 802.3ad in 2000)

http://standards.ieee.org/getieee802/download/802.1AX-2008.pdf

5.2.3 Frame Collector
A Frame Collector is responsible for receiving incoming frames (i.e., AggMuxN:MA_DATA.indications) from the set of individual links that form the Link Aggregation Group (through each link’s associated Aggregator Parser/Multiplexer) and delivering them to the MAC Client. Frames received from a given port are delivered to the MAC Client in the order that they are received by the Frame Collector. Since the Frame Distributor is responsible for maintaining any frame ordering constraints, there is no requirement for the Frame Collector to perform any reordering of frames received from multiple links.

5.2.4 Frame Distributor

The Frame Distributor is responsible for taking outgoing frames from the MAC Client and transmitting them through the set of links that form the Link Aggregation Group. The Frame Distributor implements a distribution function (algorithm) responsible for choosing the link to be used for the transmission of any given frame or set of frames.

This standard does not mandate any particular distribution algorithm(s); however, any distribution algorithm shall ensure that, when frames are received by a Frame Collector as specified in 5.2.3, the algorithm shall not cause:

A) Misordering of frames that are part of any given conversation, or
B) Duplication of frames.

The above requirement to maintain frame ordering is met by ensuring that all frames that compose a given conversation are transmitted on a single link in the order that they are generated by the MAC Client; hence, this requirement does not involve the addition (or modification) of any information to the MAC frame, nor any buffering or processing on the part of the corresponding Frame Collector in order to reorder frames. This approach to the operation of the distribution function permits a wide variety of distribution and load balancing algorithms to be used, while also ensuring interoperability between devices that adopt differing algorithms.

So what vendor uses what algorithm since there is no mandate?

Netapp:

http://now.netapp.com/NOW/knowledge/docs/ontap/rel7311/pdfs/ontap/nag.pdf

There are 2 user defined options, IP or MAC based. The last byte of the source and destination address (IP address or MAC address) is used to determine the interface to use for the outgoing frame. The following formula is used:

((source_address XOR destination_address) % number_of_links)

HP Virtual Connect:

http://bizsupport.austin.hp.com/bc/docs/support/SupportManual/c01598869/c01598869.pdf

VC’s algorithm for frame load balancing within a LAG (port trunk/channel) is automatic based on the protocol information in the frame. If the frame contains Layer 4 information (for example, TCP, UDP), Virtual Connect will use it and Layer 3 information (source and destination IP addresses) to determine conversation streams and statistically load balance individual streams on different ports in the LAG. If a frame only contains Layer 3 information (IP addresses), Virtual Connect will use the source and destination IP addresses to determine the conversations to load balance. For all Layer 2 only frames, VC simply uses the Source and Destination MAC addresses to determine conversations to load balance across the different ports in the LAG. When multiple LAGs are configured in a single vNet, VC determines the active LAG based on LAG bandwidth. The LAG with the most bandwidth (port speed + number of active ports) becomes the active LAG. All other LAGs in the vNet are put in standby mode (like NIC Teaming). If all LAGs are equal, VC Enet module ID (MAC address) and uplink port numbers are used to break the tie.

Cisco:

http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/catos/7.x/configuration/guide/channel.html#wp1020899

The load-balancing policy (frame distribution) can be based on a MAC address (Layer 2), an IP address (Layer 3), or a port number (Layer 4). These policies can be activated, respectively, by the mac, ip and session keywords. The load balancing can be based solely on the source address (source keyword), destination address (destination keyword), or both source and destination addresses (both keyword).

If a packet does not belong to a selected category, the next lower level category is considered. If the hardware cannot support the frame distribution method selected, a "Feature not supported" error message is displayed.

Foundry/Brocade:

Configuring Trunk Groups and Dynamic Link Aggregation (PDF 809KB)

Traffic Type Load Balancing Method

Layer 2 bridged non-IP Source and destination MAC addresses.

Layer 2 bridged TCP/UDP Source and destination IP addresses and Source and Destination TCP/UDP ports.

Layer 2 bridged IP (non-TCP/UDP) Source and destination IP addresses.

Layer 3 routed traffic Source and destination IP addresses and protocol field.

Most vendors seem to use a dynamic approach when it comes to load sharing, based on traffic type it will use a different algorithm. The Frame Disributer and Frame Collector functions built within LACP do not change. It is part of the standard. Having one device load share different than it's partner is not an issue. LACP ensures all frames are managed correctly.