MAC refers to protocols that determine which computer on a shared-medium environment, or collision domain, is allowed to transmit the data. MAC, with LLC, comprises the IEEE version of the OSI Layer 2. MAC and LLC are sublayers of Layer 2. There are two broad categories of Media Access Control, deterministic (taking turns) and non-deterministic (first come, first served).
Examples of deterministic protocols include Token Ring and FDDI. In a Token Ring network, individual hosts are arranged in a ring and a special data token travels around the ring to each host in sequence. When a host wants to transmit, it seizes the token, transmits the data for a limited time, and then forwards the token to the next host in the ring. Token Ring is a collisionless environment as only one host is able to transmit at any given time.
Non-deterministic MAC protocols use a first-come, first-served approach. CSMA/CD is a simple system. The NIC listens for an absence of a signal on the media and starts transmitting. If two nodes transmit at the same time a collision occurs and none of the nodes are able to transmit.
Three common Layer 2 technologies are Token Ring, FDDI, and Ethernet. All three specify Layer 2 issues, LLC, naming, framing, and MAC, as well as Layer 1 signaling components and media issues. The specific technologies for each are as follows: 
- Ethernet – logical bus topology (information flow is on a linear bus) and physical star or extended star (wired as a star)
- Token Ring – logical ring topology (in other words, information flow is controlled in a ring) and a physical star topology (in other words, it is wired as a star)
- FDDI – logical ring topology (information flow is controlled in a ring) and physical dual-ring topology (wired as a dual-ring)
Ethernet is a shared-media broadcast technology. The access method CSMA/CD used in Ethernet performs three functions:
- Transmitting and receiving data packets
- Decoding data packets and checking them for valid addresses before passing them to the upper layers of the OSI model
- Detecting errors within data packets or on the network
In the CSMA/CD access method, networking devices with data to transmit work in a listen-before-transmit mode. This means when a node wants to send data, it must first check to see whether the networking media is busy. If the node determines the network is busy, the node will wait a random amount of time before retrying. If the node determines the networking media is not busy, the node will begin transmitting and listening. The node listens to ensure no other stations are transmitting at the same time. After completing data transmission the device will return to listening mode. 
Networking devices detect a collision has occurred when the amplitude of the signal on the networking media increases. When a collision occurs, each node that is transmitting will continue to transmit for a short time to ensure that all devices see the collision. Once all the devices have detected the collision a backoff algorithm is invoked and transmission is stopped. The nodes stop transmitting for a random period of time, which is different for each device. When the delay period expires, all devices on the network can attempt to gain access to the networking media. When data transmission resumes on the network, the devices that were involved in the collision do not have priority to transmit data.
Ethernet timing
| The basic rules and specifications for proper operation of Ethernet are not particularly complicated, though some of the faster physical layer implementations are becoming so. Despite the basic simplicity, when a problem occurs in Ethernet it is often quite difficult to isolate the source. Because of the common bus architecture of Ethernet, also described as a distributed single point of failure, the scope of the problem usually encompasses all devices within the domain. In situations where repeaters are used, this can include devices up to four segments away. Any station on an Ethernet network wishing to transmit a message first “listens” to ensure that no other station is currently transmitting. If the cable is quiet, the station will begin transmitting immediately. The electrical signal takes time to travel down the cable (delay), and each subsequent repeater introduces a small amount of latency in forwarding the frame from one port to the next. Because of the delay and latency, it is possible for more than one station to begin transmitting at or near the same time. This results in a collision. If the attached station is operating in full duplex then the station may send and receive simultaneously and collisions should not occur. Full-duplex operation also changes the timing considerations and eliminates the concept of slot time. Full-duplex operation allows for larger network architecture designs since the timing restriction for collision detection is removed. In half duplex, assuming that a collision does not occur, the sending station will transmit 64 bits of timing synchronization information that is known as the preamble. The sending station will then transmit the following information:
Stations receiving the frame recalculate the FCS to determine if the incoming message is valid and then pass valid messages to the next higher layer in the protocol stack. 10 Mbps and slower versions of Ethernet are asynchronous. Asynchronous means that each receiving station will use the eight octets of timing information to synchronize the receive circuit to the incoming data, and then discard it. 100 Mbps and higher speed implementations of Ethernet are synchronous. Synchronous means the timing information is not required, however for compatibility reasons the Preamble and SFD are present. For all speeds of Ethernet transmission at or below 1000 Mbps, the standard describes how a transmission may be no smaller than the slot time. Slot time for 10 and 100-Mbps Ethernet is 512 bit-times, or 64 octets. Slot time for 1000-Mbps Ethernet is 4096 bit-times, or 512 octets. Slot time is calculated assuming maximum cable lengths on the largest legal network architecture. All hardware propagation delay times are at the legal maximum and the 32-bit jam signal is used when collisions are detected. The actual calculated slot time is just longer than the theoretical amount of time required to travel between the furthest points of the collision domain, collide with another transmission at the last possible instant, and then have the collision fragments return to the sending station and be detected. For the system to work the first station must learn about the collision before it finishes sending the smallest legal frame size. To allow 1000-Mbps Ethernet to operate in half duplex the extension field was added when sending small frames purely to keep the transmitter busy long enough for a collision fragment to return. This field is present only on 1000-Mbps, half-duplex links and allows minimum-sized frames to be long enough to meet slot time requirements. Extension bits are discarded by the receiving station. On 10-Mbps Ethernet one bit at the MAC layer requires 100 nanoseconds (ns) to transmit. At 100 Mbps that same bit requires 10 ns to transmit and at 1000 Mbps only takes 1 ns. As a rough estimate, 20.3 cm (8 in) per nanosecond is often used for calculating propagation delay down a UTP cable. For 100 meters of UTP, this means that it takes just under 5 bit-times for a 10BASE-T signal to travel the length the cable. For CSMA/CD Ethernet to operate, the sending station must become aware of a collision before it has completed transmission of a minimum-sized frame. At 100 Mbps the system timing is barely able to accommodate 100 meter cables. At 1000 Mbps special adjustments are required as nearly an entire minimum-sized frame would be transmitted before the first bit reached the end of the first 100 meters of UTP cable. For this reason half duplex is not permitted in 10-Gigabit Ethernet. |
The minimum spacing between two non-colliding frames is also called the interframe spacing. This is measured from the last bit of the FCS field of the first frame to the first bit of the preamble of the second frame.
After a frame has been sent, all stations on a 10-Mbps Ethernet are required to wait a minimum of 96 bit-times (9.6 microseconds) before any station may legally transmit the next frame. On faster versions of Ethernet the spacing remains the same, 96 bit-times, but the time required for that interval grows correspondingly shorter. This interval is referred to as the spacing gap. The gap is intended to allow slow stations time to process the previous frame and prepare for the next frame.
A repeater is expected to regenerate the full 64 bits of timing information, which is the preamble and SFD, at the start of any frame. This is despite the potential loss of some of the beginning preamble bits because of slow synchronization. Because of this forced reintroduction of timing bits, some minor reduction of the interframe gap is not only possible but expected. Some Ethernet chipsets are sensitive to a shortening of the interframe spacing, and will begin failing to see frames as the gap is reduced. With the increase in processing power at the desktop, it would be very easy for a personal computer to saturate an Ethernet segment with traffic and to begin transmitting again before the interframe spacing delay time is satisfied.
After a collision occurs and all stations allow the cable to become idle (each waits the full interframe spacing), then the stations that collided must wait an additional and potentially progressively longer period of time before attempting to retransmit the collided frame. The waiting period is intentionally designed to be random so that two stations do not delay for the same amount of time before retransmitting, which would result in more collisions. This is accomplished in part by expanding the interval from which the random retransmission time is selected on each retransmission attempt. The waiting period is measured in increments of the parameter slot time.
If the MAC layer is unable to send the frame after sixteen attempts, it gives up and generates an error to the network layer. Such an occurrence is fairly rare and would happen only under extremely heavy network loads, or when a physical problem exists on the network.
Error handling
The most common error condition on an Ethernet is the collision. Collisions are the mechanism for resolving contention for network access. A few collisions provide a smooth, simple, low overhead way for network nodes to arbitrate contention for the network resource. When network contention becomes too great, collisions can become a significant impediment to useful network operation.
Collisions result in network bandwidth loss that is equal to the initial transmission and the collision jam signal. This is consumption delay and affects all network nodes possibly causing significant reduction in network throughput.
The considerable majority of collisions occur very early in the frame, often before the SFD. Collisions occurring before the SFD are usually not reported to the higher layers, as if the collision did not occur. As soon as a collision is detected, the sending stations transmit a 32-bit “jam” signal that will enforce the collision. This is done so that any data being transmitted is thoroughly corrupted and all stations have a chance to detect the collision.
In Figure two stations listen to ensure that the cable is idle, then transmit. Station 1 was able to transmit a significant percentage of the frame before the signal even reached the last cable segment. Station 2 had not received the first bit of the transmission prior to beginning its own transmission and was only able to send several bits before the NIC sensed the collision. Station 2 immediately truncated the current transmission, substituted the 32-bit jam signal and ceased all transmissions. During the collision and jam event that Station 2 was experiencing, the collision fragments were working their way back through the repeated collision domain toward Station 1. Station 2 completed transmission of the 32-bit jam signal and became silent before the collision propagated back to Station 1 which was still unaware of the collision and continued to transmit. When the collision fragments finally reached Station 1, it also truncated the current transmission and substituted a 32-bit jam signal in place of the remainder of the frame it was transmitting. Upon sending the 32-bit jam signal Station 1 ceased all transmissions.
A jam signal may be composed of any binary data so long as it does not form a proper checksum for the portion of the frame already transmitted. The most commonly observed data pattern for a jam signal is simply a repeating one, zero, one, zero pattern, the same as Preamble. When viewed by a protocol analyzer this pattern appears as either a repeating hexadecimal 5 or A sequence. The corrupted, partially transmitted messages are often referred to as collision fragments or runts. Normal collisions are less than 64 octets in length and therefore fail both the minimum length test and the FCS checksum test.
Types of collisions
Collisions typically take place when two or more Ethernet stations transmit simultaneously within a collision domain. A single collision is a collision that was detected while trying to transmit a frame, but on the next attempt the frame was transmitted successfully. Multiple collisions indicate that the same frame collided repeatedly before being successfully transmitted. The results of collisions, collision fragments, are partial or corrupted frames that are less than 64 octets and have an invalid FCS. Three types of collisions are:
To create a local collision on coax cable (10BASE2 and 10BASE5), the signal travels down the cable until it encounters a signal from the other station. The waveforms then overlap, canceling some parts of the signal out and reinforcing or doubling other parts. The doubling of the signal pushes the voltage level of the signal beyond the allowed maximum. This over-voltage condition is then sensed by all of the stations on the local cable segment as a collision. In the beginning the waveform in Figure On UTP cable, such as 10BASE-T, 100BASE-TX and 1000BASE-T, a collision is detected on the local segment only when a station detects a signal on the RX pair at the same time it is sending on the TX pair. Since the two signals are on different pairs there is no characteristic change in the signal. Collisions are only recognized on UTP when the station is operating in half duplex. The only functional difference between half and full duplex operation in this regard is whether or not the transmit and receive pairs are permitted to be used simultaneously. If the station is not engaged in transmitting it cannot detect a local collision. Conversely, a cable fault such as excessive crosstalk can cause a station to perceive its own transmission as a local collision. The characteristics of a remote collision are a frame that is less than the minimum length, has an invalid FCS checksum, but does not exhibit the local collision symptom of over-voltage or simultaneous RX/TX activity. This sort of collision usually results from collisions occurring on the far side of a repeated connection. A repeater will not forward an over-voltage state, and cannot cause a station to have both the TX and RX pairs active at the same time. The station would have to be transmitting to have both pairs active, and that would constitute a local collision. On UTP networks this is the most common sort of collision observed. There is no possibility remaining for a normal or legal collision after the first 64 octets of data has been transmitted by the sending stations. Collisions occurring after the first 64 octets are called “late collisions". The most significant difference between late collisions and collisions occurring before the first 64 octets is that the Ethernet NIC will retransmit a normally collided frame automatically, but will not automatically retransmit a frame that was collided late. As far as the NIC is concerned everything went out fine, and the upper layers of the protocol stack must determine that the frame was lost. Other than retransmission, a station detecting a late collision handles it in exactly the same way as a normal collision. |
Ethernet errors
| Knowledge of typical errors is invaluable for understanding both the operation and troubleshooting of Ethernet networks. The following are the sources of Ethernet error:
While local and remote collisions are considered to be a normal part of Ethernet operation, late collisions are considered to be an error. The presence of errors on a network always suggests that further investigation is warranted. The severity of the problem indicates the troubleshooting urgency related to the detected errors. A handful of errors detected over many minutes or over hours would be a low priority. Thousands detected over a few minutes suggest that urgent attention is warranted. Jabber is defined in several places in the 802.3 standard as being a transmission of at least 20,000 to 50,000 bit times in duration. However, most diagnostic tools report jabber whenever a detected transmission exceeds the maximum legal frame size, which is considerably smaller than 20,000 to 50,000 bit times. Most references to jabber are more properly called long frames. A long frame is one that is longer than the maximum legal size, and takes into consideration whether or not the frame was tagged. It does not consider whether or not the frame had a valid FCS checksum. This error usually means that jabber was detected on the network. A short frame is a frame smaller than the minimum legal size of 64 octets, with a good frame check sequence. Some protocol analyzers and network monitors call these frames “runts". In general the presence of short frames is not a guarantee that the network is failing. The term runt is generally an imprecise slang term that means something less than a legal frame size. It may refer to short frames with a valid FCS checksum although it usually refers to collision fragments. |
| A received frame that has a bad Frame Check Sequence, also referred to as a checksum or CRC error, differs from the original transmission by at least one bit. In an FCS error frame the header information is probably correct, but the checksum calculated by the receiving station does not match the checksum appended to the end of the frame by the sending station. The frame is then discarded. High numbers of FCS errors from a single station usually indicates a faulty NIC and/or faulty or corrupted software drivers, or a bad cable connecting that station to the network. If FCS errors are associated with many stations, they are generally traceable to bad cabling, a faulty version of the NIC driver, a faulty hub port, or induced noise in the cable system. A message that does not end on an octet boundary is known as an alignment error. Instead of the correct number of binary bits forming complete octet groupings, there are additional bits left over (less than eight). Such a frame is truncated to the nearest octet boundary, and if the FCS checksum fails, then an alignment error is reported. This is often caused by bad software drivers, or a collision, and is frequently accompanied by a failure of the FCS checksum. A frame with a valid value in the Length field but did not match the actual number of octets counted in the data field of the received frame is known as a range error. This error also appears when the length field value is less than the minimum legal unpadded size of the data field. A similar error, Out of Range, is reported when the value in the Length field indicates a data size that is too large to be legal. Fluke Networks has coined the term ghost to mean energy (noise) detected on the cable that appears to be a frame, but is lacking a valid SFD. To qualify as a ghost, the frame must be at least 72 octets long, including the preamble. Otherwise, it is classified as a remote collision. Because of the peculiar nature of ghosts, it is important to note that test results are largely dependent upon where on the segment the measurement is made. Ground loops and other wiring problems are usually the cause of ghosting. Most network monitoring tools do not recognize the existence of ghosts for the same reason that they do not recognize preamble collisions. The tools rely entirely on what the chipset tells them. Software-only protocol analyzers, many hardware-based protocol analyzers, hand held diagnostic tools, as well as most remote monitoring (RMON) probes do not report these events. |
As Ethernet grew from 10 to 100 and 1000 Mbps, one requirement was to make each technology interoperable, even to the point that 10, 100, and 1000 interfaces could be directly connected. A process called Auto-Negotiation of speeds at half or full duplex was developed. Specifically, at the time that Fast Ethernet was introduced, the standard included a method of automatically configuring a given interface to match the speed and capabilities of the link partner. This process defines how two link partners may automatically negotiate a configuration offering the best common performance level. It has the additional advantage of only involving the lowest part of the physical layer.
10BASE-T required each station to transmit a link pulse about every 16 milliseconds, whenever the station was not engaged in transmitting a message. Auto-Negotiation adopted this signal and renamed it a Normal Link Pulse (NLP). When a series of NLPs are sent in a group for the purpose of Auto-Negotiation, the group is called a Fast Link Pulse (FLP) burst. Each FLP burst is sent at the same timing interval as an NLP, and is intended to allow older 10BASE-T devices to operate normally in the event they should receive an FLP burst.
Auto-Negotiation is accomplished by transmitting a burst of 10BASE-T Link Pulses from each of the two link partners. The burst communicates the capabilities of the transmitting station to its link partner. After both stations have interpreted what the other partner is offering, both switch to the highest performance common configuration and establish a link at that speed. If anything interrupts communications and the link is lost, the two link partners first attempt to link again at the last negotiated speed. If that fails, or if it has been too long since the link was lost, the Auto-Negotiation process starts over. The link may be lost due to external influences, such as a cable fault, or due to one of the partners issuing a reset.
Link establishment and full and half duplex
| Link partners are allowed to skip offering configurations of which they are capable. This allows the network administrator to force ports to a selected speed and duplex setting, without disabling Auto-Negotiation. Auto-Negotiation is optional for most Ethernet implementations. Gigabit Ethernet requires its implementation, though the user may disable it. Auto-Negotiation was originally defined for UTP implementations of Ethernet and has been extended to work with other fiber optic implementations. When an Auto-Negotiating station first attempts to link it is supposed to enable 100BASE-TX to attempt to immediately establish a link. If 100BASE-TX signaling is present, and the station supports 100BASE-TX, it will attempt to establish a link without negotiating. If either signaling produces a link or FLP bursts are received, the station will proceed with that technology. If a link partner does not offer an FLP burst, but instead offers NLPs, then that device is automatically assumed to be a 10BASE-T station. During this initial interval of testing for other technologies, the transmit path is sending FLP bursts. The standard does not permit parallel detection of any other technologies. If a link is established through parallel detection, it is required to be half duplex. There are only two methods of achieving a full-duplex link. One method is through a completed cycle of Auto-Negotiation, and the other is to administratively force both link partners to full duplex. If one link partner is forced to full duplex, but the other partner attempts to Auto-Negotiate, then there is certain to be a duplex mismatch. This will result in collisions and errors on that link. Additionally if one end is forced to full duplex the other must also be forced. The exception to this is 10-Gigabit Ethernet, which does not support half duplex. Many vendors implement hardware in such a way that it cycles through the various possible states. It transmits FLP bursts to Auto-Negotiate for a while, then it configures for Fast Ethernet, attempts to link for a while, and then just listens. Some vendors do not offer any transmitted attempt to link until the interface first hears an FLP burst or some other signaling scheme. There are two duplex modes, half and full. For shared media, the half-duplex mode is mandatory. All coaxial implementations are half duplex in nature and cannot operate in full duplex. UTP and fiber implementations may be operated in half duplex. 10-Gbps implementations are specified for full duplex only. In half duplex only one station may transmit at a time. For the coaxial implementations a second station transmitting will cause the signals to overlap and become corrupted. Since UTP and fiber generally transmit on separate pairs the signals have no opportunity to overlap and become corrupted. Ethernet has established arbitration rules for resolving conflicts arising from instances when more than one station attempts to transmit at the same time. Both stations in a point-to-point full-duplex link are permitted to transmit at any time, regardless of whether the other station is transmitting. Auto-Negotiation avoids most situations where one station in a point-to-point link is transmitting under half-duplex rules and the other under full-duplex rules. In the event that link partners are capable of sharing more than one common technology, refer to the list in Figure Fiber-optic Ethernet implementations are not included in this priority resolution list because the interface electronics and optics do not permit easy reconfiguration between implementations. It is assumed that the interface configuration is fixed. If the two interfaces are able to Auto-Negotiate then they are already using the same Ethernet implementation. However, there remain a number of configuration choices such as the duplex setting, or which station will act as the Master for clocking purposes, that must be determined Cisco Systems, Inc. |
0 comments:
Post a Comment