Local Area Network design/Advanced features on Ethernet networks

Autonegotiation

Autonegotiation is a plug-and-play oriented feature: when a network card connects to a network, it sends impulses by a particular encoding to try to determine network characteristics:

• mode: half-duplex or full-duplex (over twisted pair);
• transmission speed: starting from the highest speed down to the lowest one (over twisted pair and optical fiber).

Negotiation sequence

• 1 Gb/s full-duplex
• 1 Gb/s half-duplex
• 100 Mb/s full-duplex
• 100 Mb/s half-duplex
• 10 Mb/s full-duplex
• 10 Mb/s half-duplex

Issues

Autonegotiation is possible only if the station connects to another host or to a bridge: hubs in fact work at fixed speed, hence they can not negotiate anything. If during the procedure the other party does not respond, the negotiating station assumes it is connected to a hub → it automatically sets the mode to half-duplex.

If the user manually configures his own network card to work always in full-duplex mode disabling the autonegotiation feature, when he connects to a bridge the latter, not receiving reply from the other party, assumes to be connected to a hub and sets the half-duplex mode → the host considers sending and receiving at the same time over the channel as possible, while the bridge considers that as a collision on the shared channel → the bridge detects a lot of collisions which are false positives, and erroneously discards a lot of frames → every discarded frame is recovered by TCP error-recovery mechanisms, which however are very slow → the network access speed is very low. Very high values in collision counters on a specific bridge port are symptom of this issue.

Increasing the maximum frame size

The original Ethernet specification defines:

• maximum frame size: 1518 bytes;
• maximum payload size (MTU): 1500 bytes.

However in several cases it would be useful to have a frame larger than normal:

• additional headers: #Baby Giant frames
• bigger payload: #Jumbo Frames
• less CPU interrupts: #TCP offloading

Baby Giant frames

Baby Giant frames are frames having sizes bigger than the maximum size of 1518 bytes defined by the Ethernet original specification, because of inserting new data-link-layer headers in order to transport additional information about the frame:

• frame VLAN tagging (IEEE 802.1Q) adds 4 bytes: Local Area Network design/Virtual LANs#Frame tagging;
• VLAN tag stacking (IEEE 802.1ad) adds 8 bytes: Local Area Network design/Virtual LANs#Tag stacking;
• MPLS adds 4 bytes per stacked label: Computer network technologies and services/MPLS#MPLS header.

In Baby Giant frames the maximum payload size (e.g. IP packet) is unchanged → a router, when receiving a Baby Giant frame, in re-generating the data-link layer can envelop the payload into a normal Ethernet frame → interconnecting LANs having different supported frame maximum sizes is not a problem.

The IEEE 802.3as standard (2006) proposes to extend the maximum frame size to 2000 bytes, keeping the MTU size unchanged.

Jumbo Frames

Jumbo Frames are frames having sizes bigger than the maximum size of 1518 bytes defined by the Ethernet original specification:

• Mini Jumbos: frames having MTU size equal to 2500 bytes;
• Jumbos (or 'Giant' or 'Giant Frames'): frames having MTU size up to 9 KB;

because of enveloping bigger payloads in order to:

• transport storage data: typically elementary units of storage data are too big to be transported in a single Ethernet frame:
  • the NFS protocol for NASes transports data blocks of about 8 KB;
  • the FCoE protocol for SANs and the FCIP protocol for SAN interconnection transport Fibre Channel frames of about 2.5 KB;
  • the iSCSI protocol for SANs transports SCSI commands of about 8 KB;
• reduce the header overhead in terms of:
  • saving for bytes: it is not very significant, especially considering the high available bandwidth in today's networks;
  • processing capability for TCP mechanisms (sequence numbers, timers...): every TCP packet triggers a CPU interrupt.

If a LAN using Jumbo Frames is connected to a LAN not using Jumbo Frames, all Jumbo Frames will be fragmented at the IP layer, but IP fragmentation is not convenient from the performance point of view → Jumbo Frames are used in independent networks within particular scopes.

TCP offloading

Network cards with the TCP offloading feature can automatically condense on-the-fly multiple TCP payloads into a single IP packet before turning it to the operating system (sequence numbers and other parameters are internally handled by the network card) → the operating system, instead of having to process multiple small packets by triggering a lot of interrupts, sees a single bigger IP packet and can make the CPU process it at once → this reduces overhead due to TCP mechanisms.

PoE

Bridges having the Power over Ethernet (PoE) feature are able to distribute electrical power (up to few tens of Watts) over Ethernet cables (only twisted copper pairs), to connect devices with moderate power needs (VoIP phones, wi-fi access points, surveillance cameras, etc.) avoiding additional cables for electrical power.

Non-PoE stations can be connected to PoE sockets.

Issues

• energy consumption: a PoE bridge consumes a lot more electrical power (e.g. 48 ports each one at 25 W consume 1.2 kW) and is more expensive than a traditional bridge;
• service continuity: a failure of the PoE bridge or a power blackout cause telephones, which instead are an important service in case of emergency, to stop working → uninterruptible power supplies (UPS) need to be set but they, instead of providing just traditional telephones with electrical power, have to provide the whole data infrastructure with electrical power.