- Autonegotiation
-
Autonegotiation is an Ethernet procedure by which two connected devices choose common transmission parameters, such as speed, duplex mode, and flow control. In this process, the connected devices first share their capabilities regarding these parameters and then choose the highest performance transmission mode they both support. In the OSI model, autonegotiation resides in the physical layer.
Autonegotiation was originally defined as an optional component in the fast Ethernet standard. It is backwards compatible with 10BASE-T. The protocol was significantly extended in the gigabit Ethernet standard, and is mandatory for 1000BASE-T gigabit Ethernet over copper.[1]
Contents
Overview
In 1995, a standard was released to allow connected network adapters to negotiate the best possible shared mode of operation. The initial autonegotiation standard contained a mechanism for detecting the speed but not the duplex setting of Ethernet peers that did not use autonegotiation.[citation needed]
Autonegotiation can be used by devices that are capable of different transmission rates, different duplex modes (half duplex and full duplex), and/or different standards at the same speed (though in practice only one standard at each speed is widely supported). Each device declares its technology abilities, that is, its possible modes of operation, and the best mode is chosen from those shared by them, with higher speed preferred over lower, and full duplex preferred over half duplex at the same speed.
Parallel detection is used when a device that is capable of autonegotiation is connected to one that is not. This happens if the other device does not support autonegotiation or autonegotiation is administratively disabled. In this condition, the device that is capable of autonegotiation can determine and match speed with the other device. This procedure cannot determine the presence of full duplex, so half duplex is always assumed.
The standards for 1000BASE-T and 1000BASE-TX require autonegotiation to be always present and enabled. Other than speed and duplex mode, autonegotiation is used to communicate the port type (single port or multiport) and the master-slave parameters (whether it is manually configured or not, whether the device is master or slave if this is the case, and the master-slave seed bit otherwise).
Electrical signals
Autonegotiation is based on pulses similar to those used by 10BASE-T devices to detect the presence of a connection to another device. These pulses are sent by a device when it is not sending or receiving any data. They are unipolar positive-only electrical pulses of a duration of 100 ns nominally, with a maximum pulse width of 200 ns,[2] generated at intervals of 16 ms (with a tolerance of 8 ms). These pulses are called link integrity test (LIT) pulses in the 10BASE-T terminology, and are referred to as normal link pulses (NLP) in the autonegotiation specification.
A device detects the failure of a link (which can be due to a failure of the transmission medium or a failure of the other device) if neither a packet nor one of the pulses is received for 50-150 ms. The presence of a valid link is signaled by the receipt of a valid frame or two consecutive link integrity test pulses. For this to work, devices send link integrity test pulses even when not receiving any.
Autonegotiation uses similar pulses. These are still unipolar, positive-only, and of the duration of 100 ns, but each one is replaced by a train of between 17 and 33 pulses. Each such train is called a fast link pulse (FLP) burst. The time interval between the start of each burst is the same as the distance between normal link pulses, that is, 16 ms with a tolerance of 8 ms.
The fast link pulse burst is made as follows: there are 17 clock pulses at a distance of 125 µs (with a tolerance of 14 µs). Between each set of two consecutive clock pulses, a data pulse may or may not be present. The presence of a data pulse represents a logical 1, the absence a logical 0. As a result, every burst represents a logical word of 16 bits. This word is called a link code word (LCW). The bits of the link code word are numbered from 0 to 15, where bit 0 corresponds to the first possible pulse in time and bit 15 to the last.
The base link code word
Every fast link pulse burst transmits a word of 16 bits known as a link code word. The first such word is known as a base link code word, and its bits are used as follows:
- 0–4: selector field: it indicates which standard is used between IEEE 802.3 and IEEE 802.9;
- 5–12: technology ability field: this is a sequence of bits that encode the possible modes of operations among the 100BASE-T and 10BASE-T modes;
- 13: remote fault: this is set to one when the device is detecting a link failure;
- 14: acknowledgement: the device sets this to one to indicate the correct reception of the base link code word from the other party; this is detected by the reception of at least three identical base code words;
- 15: next page: this bit is used to indicate the intention of sending other link code words after the base link code word;
The technology ability field is composed of eight bits. For IEEE 802.3, these are as follows:
- bit 0: device supports 10BASE-T
- bit 1: device supports 10BASE-T in full duplex
- bit 2: device supports 100BASE-TX
- bit 3: device supports 100BASE-TX in full duplex
- bit 4: device supports 100BASE-T4
- bit 5: pause
- bit 6: asymmetric pause for full duplex
- bit 7: reserved
The acknowledgement bit is used to signal the correct reception of the base code word. This corresponds to having received three identical copies of the base code word. Upon receiving these three identical copies, the device sends a link code word with the acknowledge bit set to one from six times to eight times.
The link code words are also called pages. The base link code word is therefore called a base page. The next page bit of the base page is 1 when the device intends to send other pages, which can be used to communicate other abilities. These additional pages are sent only if both devices have sent base pages with a next page bit set to 1. The additional pages are still encoded as link code words (using 17 clock pulses and up to 16 bit pulses).
Message and unformatted next page
The base page (the base link code word) is sufficient for devices to advertise which ones among the 10BASE-T, 100BASE-TX and 100BASE-T4 modes they support. For gigabit Ethernet, two other pages are required. These pages are sent if both devices have sent base pages with a next page bit set to one.
The additional pages are of two kinds: message pages and unformatted pages. These pages are still 16-bit words encoded as pulses in the same way as the base page. Their first eleven bits are data, while their second-to-last bit indicates whether the page is a message page or an unformatted page. The last bit of each page indicates the presence of an additional page.
The 1000BASE-T supported modes and master-slave data (which is used to decide which of the two devices acts as the master, and which one acts as the slave) are sent using a single message page, followed by a single unformatted page. The message page contains:
- half duplex capability
- whether the device is single port or multiport
- whether master/slave is manually configured or not
- whether the device is manually configured as master or slave
The unformatted page contains a 10-bit word, called a master-slave seed value.
Priority
Upon receipt of the technology abilities of the other device, both devices decide the best possible mode of operation supported by both devices. The priority among modes specified in the 2002 edition of 802.3 is as follows:
- 1000BASE-T full duplex
- 1000BASE-T half duplex
- 100BASE-T2 full duplex
- 100BASE-TX full duplex
- 100BASE-T2 half duplex
- 100BASE-T4
- 100BASE-TX half duplex
- 10BASE-T full duplex
- 10BASE-T half duplex
In other words, among the modes that are supported by both devices, each device chooses the one that is the topmost in this list.
Interoperability problems
The first version of the autonegotiation specification, IEEE 802.3u, was open to different interpretations. Although most manufacturers implemented this standard in one way, some others, including network giant Cisco, implemented it in a different way. Autonegotiation between devices that implemented it differently failed. This led many network administrators to not depend on autonegotiation and instead manually set the speed and duplex mode of each network interface card. Even Cisco recommended its customers not to use autonegotiation. However, the use of manually set configuration often led to duplex mismatches, in particular when two connected devices are:
- One manually set to half duplex and one manually set to full duplex
- One set to autonegotiation and one manually set to full duplex
- Both sides manually set to full duplex where one side still expects an autonegotiating link partner and the other side has autonegotiation completely disabled (the side that expects an autonegotiating link partner will fall back to half duplex because it does not detect a partner capable of full duplex)[citation needed]
Duplex mismatch problems are difficult to diagnose because the network is apparently working, and simple programs used for network tests such as ping report a valid connection; however, the network is much slower than expected.
The debatable portions of the autonegotiation specifications were eliminated by the 1998 release of 802.3. This was later followed by the release of IEEE 802.3ab in 1999. The new standard specified that gigabit Ethernet over copper wiring requires autonegotiation. Currently, all network equipment manufacturers—including Cisco[3]—recommend to use autonegotiation on all access ports. Cisco also recommends that you check back with them yearly for any potential changes in their recommendation as this has caused much confusion over the years. [4]
In some large installations that have had to deal with negotiation issues, network staff may believe that "autonegotiation doesn't work", and consider turning it off a best-practice. This should be avoided - once autonegotiation is turned off, it will not work by definition, creating a self-enforcing problem.
Duplex mismatch
Main article: Duplex mismatchA duplex mismatch occurs when two connected devices are configured in different duplex modes. This may happen for example if one is configured for autonegotiation while the other one has a fixed mode of operation that is full duplex (no autonegotiation). In such conditions, the autonegotiation device correctly detects the speed of operation, but is unable to correctly detect the duplex mode. As a result, it sets the correct speed but starts using the half duplex mode.
When a device is operating in full duplex while the other one operates in half duplex, the connection works at a very low speed if both devices attempt to send frames at the same time. This is because data can be sent in both directions at the same time in full duplex mode, but only in one direction at a time in half duplex mode. As a result, a full duplex device may transmit data while it is receiving. However, if the other device is working in half duplex, it does not expect to receive data (because it is currently sending); therefore, it senses a collision and attempts to resend the frame it was sending. Depending on timing the half duplex device may sense a late collision, which it will interpret as a hard error rather than a normal consequence of CSMA/CD and will not attempt to resend the frame. On the other hand, the full duplex device does not detect any collision and does not resend the frame, even if the other device has discarded it as corrupted by collision. Still, the full duplex device, not expecting incoming frames to be truncated by collision detection, will report frame check sequence errors. This combination of late collisions reported at the half-duplex end and FCS errors reported by the full duplex end can be used as an indication that a duplex mismatch is present.
This packet loss happens when both devices are transmitting at the same time. This may happen even when the link is used, from the user's perspective, in one direction only. A TCP stream requires all packets sent to be acknowledged by the receiving device. As a result, even if actual data is sent in one direction only, collision may be generated with acknowledgement packets traveling in the other direction.
History
The protocol that became IEEE 802.3 clause 28 was developed from a patented technology by National Semiconductor known as NWay. The company gave a letter of assurance for anyone to use their system for a one time license fee.[5] Another company has since bought the rights to that patent.[6]
Patents
Autonegotiation is covered by the US patents U.S. Patent 5,617,418; U.S. Patent 5,687,174; E U.S. Patent RE39,405 E; E U.S. Patent RE39,116 E; 971,018 (filed 1992-11-02); 146,729 (filed 1993-11-01); 430,143 (filed 1995-04-26) [6]
European Patent Applications SN 93308568.0 (DE, FR, GB, IT, NL); Korean Patent No. 286791, Taiwanese Patent No. 098359, Japanese Patent No. 3705610; Japanese Patent 4234. Applications SN H5-274147; Korean Patent Applications SN 22995/93; Taiwanese Patent Applications SN 83104531;
See also
- Auto-MDIX for automatic configuration of straight-through or crossover-cable connection
References
- ^ IEEE. "Part 3: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) access method and Physical Layer specifications". SECTION TWO: This section includes Clause21 through Clause 33 and Annex 22A through Annex 33E.. http://standards.ieee.org/getieee802/download/802.3-2008_section2.pdf. Retrieved 2010-02-18.
- ^ "IEEE Link Task Force Autodetect, Specification for NWay Autodetect". p. 57. http://www.negotiateddata.com/files/NWay_Specification_041094.pdf. 100615 negotiateddata.com
- ^ "Catalyst 2970 Switch Software Configuration Guide, 12.2(18)SE - Configuring Interface Characteristics [Cisco Catalyst 2970 Series Switches] - Cisco Systems". Cisco.com. http://www.cisco.com/en/US/docs/switches/lan/catalyst2970/software/release/12.2_18_se/configuration/guide/swint.html#wp1080632. Retrieved 2009-03-13.
- ^ "Best Practices for Catalyst 4500/4000, 5500/5000, and 6500/6000 Series Switches Running CatOS Configuration and Management". http://www.cisco.com/en/US/products/hw/switches/ps663/products_tech_note09186a0080094713.shtml#auto_neg.
- ^ http://www.negotiateddata.com/files/Grant_Letter_060794.pdf
- ^ a b Negotiated Data Solutions LLC. "NWay/IEEE Standard Patent License Offer | Negotiated Data Solutions LLC". Negotiateddata.com. http://www.negotiateddata.com/node/2. Retrieved 2010-02-02.
External links
Categories:- Ethernet
- Network protocols
Wikimedia Foundation. 2010.