CSMA/CD

CSMA/CD definition: Carrier sense multiple access with collision detection (CSMA/CD) is a media access control (MAC) method used most notably on the early Ethernet where multiple stations, such as computers and peripherals, are connected through a shared physical line. Because the stations can only access the shared line in half-duplex mode, CSMA/CD is used for collision detection and avoidance. Details are as follows:

• CS: carrier sense. Before transmitting data, a station checks to see if the line is idle. By doing so, chances of collision are decreased.

• MA: multiple access. The data sent by a station can be received by multiple other stations at the same time.

• CD: collision detection. A collision occurs if two stations transmit electrical signals simultaneously, because the signals are superimposed, doubling the normal voltage amplitude. The stations stop transmitting after sensing the conflict, and resume after a random amount of time.

CSMA/CD implementation: A station continuously checks whether the shared line is idle. If so, the station sends data. Otherwise, the station waits until the line is idle. If two stations send data simultaneously, a conflict occurs on the line, and the signal becomes unstable. After detecting an instability, the station immediately stops sending data but sends a series of interference pulses.

The pulses inform other stations that a conflict has occurred on the line. After detecting a conflict, the station waits for a random period, and then resumes the data transmission.

Minimum Frame Length

Due to the CSMA/CD algorithm limits, an Ethernet frame cannot be shorter than 64 bytes. This length is determined based on the maximum transmission distance and the collision detection mechanism. The use of a minimum frame length prevents conflicts from occurring in situations in which a station (for example, station A) finishes sending the last bit of a frame, but the first bit has not yet arrived at a faraway station (for example, station B). In this scenario, station B senses that the line is idle and begins to send data.

The upper layer protocol must ensure that each frame's Data field contains at least 46 bytes. In this way, the Data field with a 14-byte Ethernet frame header and 4-byte check code at the end of the frame equals the required minimum frame length of 64 bytes. If the Data field is less than 46 bytes, the upper layer must pad the gap. The maximum length of a frame's Data field has been set to 1500 bytes, as required by the memory cost and buffer of low-cost LAN controllers in 1979.

Maximum Transmission Distance

The maximum transmission distance depends on factors such as line quality and signal attenuation.

Duplex Modes

The Ethernet physical layer can work in either half- or full-duplex mode.

• Half-duplex mode: Data can only be sent or received at any time.

  • The CSMA/CD mechanism is used.

  • The maximum transmission distance is limited.

• Full-duplex mode: Data can be sent and received simultaneously. It has resolved conflicts, eliminated the need for CSMA/CD, and has the following features:

  • The maximum throughput is theoretically twice that of the half-duplex mode.

  • This mode extends the maximum transmission distance of the half-duplex mode.

Auto-Negotiation

Auto-negotiation definition: Auto-negotiation is a capability that enables devices at both ends of a physical link to automatically negotiate a working mode by exchanging information. The negotiated parameters include the half- or full-duplex mode and transmission speed. After the negotiation, the devices operate in negotiated mode.

Auto-negotiation implementation: The auto-negotiation mechanism applies to twisted pair cables only. When no data is transmitted over a twisted pair cable, the cable is not idle. Instead, it keeps transmitting the normal link pulses (NLPs) at a low frequency. Any Ethernet adapter with interfaces for twisted pair cables can identify these pulses. After lower-frequency pulses — fast link pulses (FLPs) — are inserted into the NLPs, the devices at both ends can also identify the pulses. By using FLPs to convey a small amount of data, the devices achieve auto-negotiation. Figure 4-1 shows the pulse insertion process.

Figure 4-1 Pulse insertion

Auto-negotiation priorities on Ethernet duplex links are listed as follows in descending order:

• 1000M full-duplex

• 1000M half-duplex

• 100M full-duplex

• 100M half-duplex

• 10M full-duplex

• 10M half-duplex

A configuration register in a device's network adapter saves the working modes that the adapter supports. For example, if a network adapter supports 100M and 10M working modes, the corresponding content is set in the corresponding register. After the network adapter is powered on, if auto-negotiation is allowed, the network adapter reads its configuration register, encodes the content, and sends it through FLPs. At the same time, it receives auto-negotiation data from the peer. It then compares the received data with the data in its configuration register and selects the optimal working mode. For example, if the device and its peer both support 100M full-duplex, the working mode 100M full-duplex is selected; if the peer supports only 10M full-duplex, the working mode 10M full-duplex is selected. If they do not share any capabilities, auto-negotiation fails, and they cannot communicate.

If auto-negotiation succeeds, the Ethernet adapter activates the link to transmit data. If auto-negotiation fails, the link cannot be used.

Auto-negotiation is implemented through physical layer coding and does not require any special data packets or bring upper-layer protocol overheads.

Hierarchical Structure of the Ethernet Data Link Layer

In Ethernet, the following access modes are used according to the duplex mode:

• CSMA/CD is used in half-duplex mode.

• Data is sent and received directly in full-duplex mode without having to detect if the line is idle.

The duplex mode, either half or full, is a physical layer concept, whereas the access mode, varying with the duplex mode, is a data link layer concept. The two layers are related on the Ethernet.

Because of this relationship, a specific data link layer is required for different operation modes at the physical layer. This causes some issues for the design and application of the Ethernet.

To address this issue, some organizations and vendors have proposed dividing the data link layer into two sub-layers: logical link control (LLC) and media access control (MAC). In this case, different physical layers correspond to different MAC sub-layers, and the LLC sub-layer becomes totally independent, as shown in Figure 4-2.

Figure 4-2 Hierarchical structure of the Ethernet data link layer

MAC Sub-layer

Ethernet Frame Structure

Ethernet II and IEEE 802.3 frames are the most common frames on a LAN. In TCP/IP, the Ethernet II frame format is defined in RFC 894, and the IEEE 802.3 frame format is defined in RFC 1042. Currently, the Ethernet II (also called Ethernet DIX) frame format is more widely used. Compared with IEEE 802.3 service access point (SAP) and Sub-Network Access Protocol (SNAP), Ethernet II is more suitable for transmitting a large amount of data. However, Ethernet II lacks control over the data link layer, and is therefore unsuitable for transmitting data that requires strict control.

Ethernet II Frames

Ethernet II frames are the most common types of frames and are generally used by the IP protocol. Figure 4-3 shows the Ethernet II frame format.

Figure 4-3 Ethernet II frame format

An Ethernet II frame has the following fields:

• DMAC: destination MAC address, which specifies the receiver of the frame.

• SMAC: source MAC address, which specifies the sender of the frame.

• Type: The 2-byte Type field identifies the upper layer protocol in the Data field. The receiver can interpret the meaning of the Data field according to the Type field.

  Multiple protocols can coexist on a LAN. The hexadecimal values in the Type field of an Ethernet II frame specify these protocols.

  • 0800 indicates IP.

  • 0806 indicates the Address Resolution Protocol (ARP).

  • 0835 indicates the Reverse Address Resolution Protocol (RARP).

  • 8137 indicates Internetwork Packet Exchange (IPx) and Sequenced Packet Exchange (SPx).

• Data: The minimum length of the Data field is 46 bytes, ensuring that the frame is at least 64 bytes. A 46-byte Data field is required even if a station transmits 1 byte of data.

  If the length of this field is less than 46 bytes, 0s are used for padding.

  The maximum length of the Data field is 1500 bytes.

• CRC: The cyclic redundancy check (CRC) field provides an error detection mechanism.

  Each sending device calculates a CRC code from the DMAC, SMAC, Type, and Data fields. The CRC code is then filled into the 4-byte CRC field.

IEEE 802.3 Frames

Figure 4-4 shows the IEEE 802.3 frame format.

Figure 4-4 IEEE 802.3 frame format

The format of an IEEE 802.3 frame is similar to that of an Ethernet II frame. In an IEEE 802.3 frame, however, the Type field is changed to the Length field, and the LLC field and SNAP field occupy 8 bytes of the Data field.

• Length: specifies the number of bytes of the Data field.

• LLC: consists of three sub-fields – Destination Service Access Point (DSAP), Source Service Access Point (SSAP), and Control.

• SNAP: consists of the Org Code field and Type field. Three bytes of the Org Code field are all 0s. The Type field functions the same as that in Ethernet II frames.

For descriptions of other fields, see Ethernet II frames.

According to the values of DSAP and SSAP, an IEEE 802.3 frame can be as follows:

• If DSAP and SSAP are both 0xff, the IEEE 802.3 frame becomes a NetWare-Ethernet frame carrying NetWare data.

• If DSAP and SSAP are both 0xaa, the IEEE 802.3 frame becomes an Ethernet_SNAP frame.

  An Ethernet_SNAP frame can be used for multi-protocol transmission. Therefore, SNAP can be considered as an extension of the Ethernet protocol and allows vendors to invent their own Ethernet transmission protocols.

  The Ethernet_SNAP standard is defined by IEEE 802.1 to help ensure compatibility between the operations of an IEEE 802.3 LAN and Ethernet.

• Other values of DSAP and SSAP indicate pure IEEE 802.3 frames.

LLC Sub-layer

As described, the MAC sub-layer supports both IEEE 802.3 and Ethernet II frames. In the latter, the Type field identifies the upper layer protocol. In this case, the LLC sub-layer is not needed, and only the MAC sub-layer is required.

In an IEEE 802.3 frame, useful features are defined at the LLC sub-layer in addition to the traditional services of the data link layer. These features are specified by the sub-fields of DSAP, SSAP, and Control.

For example, the LLC sub-layer supports the following types of P2P data transmission services:

• Connectionless service. Currently implemented by Ethernet.

• Connection-oriented service. Specifically, a connection is set up before data is transmitted, thereby ensuring reliability.

• Connectionless service with data acknowledgment. Specifically, a connection is not required before data transmission. However, an acknowledgment mechanism is adopted to improve reliability.

The following is an example to describe SSAP and DSAP applications. Assuming that terminals A and B use connection-oriented services, data is transmitted through the following process:

1. A sends a frame to B to request a connection.

2. After receiving the frame, if B has enough resources, it returns an acknowledgment message that contains a SAP. The SAP identifies the connection required by A.

3. After receiving the acknowledgment message, A knows that B has set up a local connection between them. After creating a SAP, A sends a message containing the SAP to B. The connection is then set up.

4. The LLC sub-layer of A encapsulates the data to be transmitted into a frame. The DSAP field is filled in with the SAP sent by B, and the SSAP field is filled in with that created by A. The LLC sub-layer of A then transfers the data to its MAC sub-layer.

5. The MAC sub-layer of A adds the MAC address and Length fields to the frame, before transferring it to the data link layer.

6. After receiving the frame at the MAC sub-layer of B, the MAC sub-layer transfers the frame to the LLC sub-layer, which identifies the connection that the frame belongs to according to the DSAP field.

7. After checking and acknowledging the frame based on the connection type, the LLC sub-layer of B transfers the frame to the upper layer.

8. After data transmission is complete, A sends B a frame, instructing B to tear down the connection. At this time, the communication ends.

Interface Rate

In auto-negotiation mode, interfaces at both ends of a link negotiate an interface rate.

If the automatically negotiated interface rate does not meet requirements or the peer device does not support auto-negotiation, you need to manually set an interface rate in non-auto-negotiation mode. The interface rates set on both ends of a link must be the same.

Interface IFG

The inter-frame gap (IFG) is used to differentiate two Ethernet frames, as shown in Figure 4-5. It can affect the packet forwarding capability on an interface.

The packet forwarding capability, also called interface throughput, refers to the data forwarding capability on an interface, which is expressed in packets per second (pps). The packet forwarding capability is calculated based on the number of 64-byte data packets (smallest packets) sent in a certain period. During calculation, the lengths of the preamble and IFG must be taken into account.

It is recommended that the default IFG of 12 bytes is used. If you set the IFG to a smaller value, after receiving one data frame, a device may not be well prepared to receive the next one. This could result in frame loss. If the length of a data frame to be sent exceeds 8000 bytes, it is recommended that you change the IFG to 16 bytes.

Figure 4-5 IFG

Traffic Statistics Collection

You can check the running status and traffic statistics of an interface by running the display interface command. The Last 300 seconds input rate and Last 300 seconds output rate fields in the command output indicate the inbound and outbound traffic rates on the interface in the last 300 seconds.

• To obtain the total number of bytes (including the number of packet bytes and the fixed lengths of the IFG and preamble) passing through an interface per second, configure collection of traffic statistics that include the IFG and preamble. The interface's traffic rate is then calculated as follows: Interface's traffic rate = (Original packet length + IFG length + Preamble length) x Number of packets passing through the interface per second
• To obtain only the number of packet bytes (excluding the fixed lengths of the IFG and preamble) passing through an interface per second, configure collection of traffic statistics that exclude the IFG and preamble. The interface's traffic rate is then calculated as follows: Interface's traffic rate = Original packet length x Number of packets passing through the interface per second

Jumbo Frame Length Allowed on an Interface

Ethernet frames longer than 1518 bytes and VLAN frames longer than 1522 bytes are called jumbo frames.

When exchanging a large amount of data (for example, when transmitting files), Ethernet interfaces may receive jumbo frames whose length exceeds that of common packets. However, if the length of the received Jumbo frame exceeds the default data frame length, it is directly discarded by the device. To address this issue, you can adjust the jumbo frame length allowed on an interface.

After adjustment, the common Ethernet frame length no longer restricts the allowed packet length limit. In this way, flexible packet forwarding can be achieved. Jumbo frames also improve bandwidth utilization. When transmitting data packets, common Ethernet frames introduce a lot of overheads such as IFGs and headers. In contrast, jumbo frames reduce this number and therefore improve bandwidth utilization.

The jumbo frame lengths allowed on interfaces cannot all be set to the maximum value, as extra packet encapsulation must be considered. After an interface receives protocol packets such as VLAN packets, it encapsulates packet headers containing certain bytes to the packets. The length of the outgoing packets then exceeds that of the incoming packets, which may cause packet loss. To prevent this, the packet header length must be considered when you configure the maximum frame length on an interface.

Alarm Threshold for Outbound/Inbound Bandwidth Usage

You can configure a threshold for outbound/inbound bandwidth usage. When this threshold is exceeded, an alarm is generated. This helps you to expand bandwidth in advance and prevent service interruptions. For best effect, the threshold must be set to an appropriate value. If it is too high, for example, 95%, you may not have enough time to expand the bandwidth after the alarm is generated, which may cause service interruptions.

Alarms for Sudden Traffic Rate Changes on Interfaces

To notify users that the incoming or outgoing traffic rate on an interface suddenly increases or decreases, the device supports hwInputRateChangeOverThresholdNotice or hwOutputRateChangeOverThresholdNotice alarm.

Control-Flap

The flapping of routing protocols and other protocols caused by frequent changes of the interface status affects the stability of the whole network. To resolve this problem, you can configure the control-flap function.

Only Layer 3 interfaces support the control-flap function.

Delay to Report Interfaces' Physical Status Changes

An Ethernet interface can be physically up or down. When the physical status of an interface changes, the device where the interface resides notifies upper-layer protocol modules, such as the routing and forwarding modules, of the change to guide packet receiving and forwarding. In addition, the device automatically generates traps and logs to remind users to perform the corresponding operations on physical links.

After you configure a delay in reporting changes in interfaces' physical status, the device will not detect physical status changes during that delay. After the delay, if the physical status has not resumed its original status, the physical status changes are reported to the device.

Link Flapping Causing Interfaces to Enter the Error-Down State

A device sets the status of an interface to error-down when it detects a fault on the interface. An interface in error-down state cannot send or receive packets, and the interface indicator is off. Link flapping is one possible cause of an interface entering the error-down state. To address this issue, link flapping protection shuts down the interfaces whose physical status frequently alternates between up and down, thereby preventing network topologies from frequently changing and affecting user communication. For example, if the physical status of the active link's interface frequently alternates between up and down, services are frequently switched between the active and standby links. This increases the load on the device and may cause service data loss. To prevent this issue, configure link flapping protection on the active link's interface. If this function is configured and the device detects that the physical status of the active link's interface frequently changes, the device shuts down this interface to trigger an active/standby link switchover. The standby link then takes over to steadily transmit services. The link flapping protection function involves the following parameters:

• Number of link flaps: One interface up/down transition is recorded as one link flap.

• Link flapping detection interval: a period during which a device counts the number of link flaps.

If the number of link flaps on an interface reaches a preset threshold within a link flapping interval, a device disables the interface and records its status as ERROR DOWN(link-flap).

Threshold for the Number of Received CRC Error Packets that Cause an Interface to Enter the Error-Down State

A device sets the status of an interface to error-down when it detects a fault on the interface. An interface in error-down state cannot send or receive packets, and the interface indicator is off. Receiving excessive CRC error packets is one of the possible causes of an interface entering the Error-Down state. If this function is not enabled, an interface that encounters a fault may be still up, preventing traffic from being switched to a configured backup link. To avoid impact on services, you can configure the interface to enter the error-down state when it receives excessive CRC error packets. When the number of received error packets on the interface exceeds the upper alarm threshold, the device disables the interface and records its status as error-down. Services are then switched to the backup link immediately.