Link Aggregation Part 1
So I’ve been learning another protocol-still at it. Thought I’d just write about what I’ve already learnt in it. So here goes.
What is link aggregation?
As the name suggests, link aggregation is aggregation of links-several links behaving as one single link.
- Increased Link Capacity: Higher speeds can be handled. Mainly used to replace a single, overloaded link.
- Incremental capacity increase: Usually LAN has speeds in multiple of 10-10Mb/s, 100Mb/s, 1000Mb/s. The intermediate speeds can be achieved only using aggregation.
- High Availability: This is not possible in a single link scenario-if a link fails, entire service is disrupted. But, in case of aggregation, even if a link fails, service is not disrupted.
- Minimal Hardware Changes: Link aggregation involves use of additional ports. This is very handy specially in cases when there several unused ports. It is also possible that a particular model doesn’t support 100 or 1000Mb/s NIC’s.
- Additional LAN interfaces are needed at each end of the aggregation.
- Additional slots may be consumed in the devices being interconnected
- Additional complexity is required in the device drivers to support aggregated links.
- Controls (either manual or automatic) are needed to ensure that aggregations are properly configured and maintained.
To aggregate or to upgrade? That is the question!
It depends on the situation. If the case is that the server can’t support more than say 400Mb/s, then it’s pointless upgrading from 100Mb/s to 1000Mb/s-aggregation might be the better choice since same amount of bandwidth will be available even if it’s 4 100Mb/s links. Higher availability can be ensured in case of aggregation but not in upgrade. But, if aggregation would more expensive than doing an upgrade, then the latter would be the preferred choice. Of course, sometimes aggregation would be the only choice. Eg: Today’s fastest Ethernet offers 1Gb/s. Any greater speeds are required, it’s possible only through aggregation.
Transmission across an aggregated link
Since several links are combined to behave as a single link, all links should transmit frames with the same source MAC address. This is achieved by using the MAC address of one of the NIC’s.
One key property that aids the above is that when a NIC is booted up, the MAC address that is burnt into the ROM(by the manufacturer) is read into an address register and in all frames that is transmitted in future, the source address is read from this register. Thus, in aggregation, one of the ROM’s will be read and that MAC address will be written to the address register of all all the aggregated NIC’s.
Traffic distribution across the aggregated links is the major issue. In the case of WAN, the frames can be split into bits and transmitted across multiple links only to be reconstructed at the receivers’ end. But, this is not possible in the case of LAN i.e. Ethernet frames-it must be transmitted as a whole. Thus the main job in link aggregation is to select the link across which the frame will be transmitted at the transmitting end and performing the collection of LAN frames at the receiving side.
Separating Traffic Flows
Generally, the LAN will be used by several machines and not just a single machine. This means that a flow(referred to as conversation herewith) should be synchronized i.e. frames belonging to a single conversation should be transmitted across a single link. This is done so as to overcome the overhead of adding a sequence number and reconstructing the frames in the correct order at the receiver’s end. Thus each conversation would be associated with one interface. However, different conversation can share the same interface. This approach greatly simplifies collection at the Collector’s end-there is no need to buffer frame(s) since one or more frames are missing-all will arrive in order at the same interface.
They only downside is that if a conversation has frames of very large sizes, it’ll still be transmitted on a single link while other links might have little or no load at all. This means that aggregation is completely useless and is the same as a non-aggregated link.
What constitutes a conversation?
This is an important question that needs to be answered in order to distribute traffic uniformly across the links.
One approach would be to adopt the practice that all frames with the same destination address belong to the same conversation. But this would prove disadvantageous in case the aggregation is between the server and a switch, in which case the destination address would be the same in each frame. Similarly, using the source address instead of the destination address would have a similar disadvantage in case of frames transmitted from the server.
Thus there are two possible solutions depending on implementation
- Depending on the transmission, choose the source or destination address in identifying a conversation.
- Using both source and destination in identifying a conversation.
The latter would be an ideal choice since it’d ensure distribution at the cost of processing while cost of processing is less in the former at the cost of distribution. Ultimately, it’s a tradeoff between uniform distribution and cost of processing.
Of course another issue that arises at this point is that the aggregation might be between two devices only-in which case the source and destination MAC addresses would be the same in all cases. In such cases, the decision would have to be made by determining the upper layer protocol whose data is being transmitted in the frame.
More in part 2 so stay tuned!