NWay (TM) Auto-Negotiation is a technology which was introduced by National Semiconductor to the IEEE 802.3u 100BASE-T working group in the Spring of 1994 as a result of the need for a mechanism to accommodate multi-speed network devices. National's NWay technology was chosen as the basis for this mechanism due to its simplicity, low cost, flexibility, interoperation with the installed base, and adaptability to future technologies. Currently, the Auto-Negotiation mechanism is defined in Clause 28 of the D4 draft of the ANSI/IEEE Std 802.3 MAC Parameters, Physical Layer, Medium Attachment Units and Repeater for 100 Mb/s Operation. This draft has been approved by the IEEE 802.3 Working Group. Refer to section 8.0 for definitions used in this document.
Auto-Negotiation is a mechanism that takes control of the cable when a connection is established to a network device. Auto-Negotiation detects the various modes that exist in the device on the other end of the wire, the Link Partner, and advertises it own abilities to automatically configure the highest performance mode of interoperation. As a standard technology, this allows simple, automatic connection of devices that support a variety of modes from a variety of manufacturers.
Auto-Negotiation acts like a rotary switch that automatically switches to the correct technology, such as 10BASE-T, 100BASE-TX, 100BASE-T4, or a corresponding Full Duplex mode. Once the highest performance common mode is determined, Auto-Negotiation passes control of the cable to the appropriate technology and becomes transparent until the connection is broken.
Auto-Negotiation leverages the proven link function of 10BASE-T to provide robust operation over Category 3, 4, or 5 Unshielded Twisted Pair (UTP.)
There are two basic cases that Auto-Negotiation accounts for as shown in Figure 1:
The key to Auto-Negotiation's interoperation with installed, legacy LANs is the Parallel Detection function. The Parallel Detection function accounts for the case where only one end of a twisted-pair link has Auto-Negotiation. For example, consider an installed 10BASE-T node connected to a hub that supports 10BASE-T, 100BASE-TX, and Auto-Negotiation (see Figure 1). In this case, the hub recognizes the unique signals that the 10BASE-T only device produces and switches to 10BASE-T operation.
In addition to the basic connection mechanism, Auto-Negotiation also provides the following optional additional features:
The serial management interface of the Media Independent Interface (MII) register set provides a mechanism for additional control of Auto-Negotiation. It also provides a means to gather network status information.
After exchanging the Base Page, which contains the information to make a connection automatically, if both ends of the link indicate support for the Next Page function, additional data may be exchanged. This allows extensions to the standard and proprietary extensions to exist without affecting interoperability.
The basic transport mechanism for simple fault information is built into Auto-Negotiation, but the detection and advertisement of any particular fault is not required. Remote Fault Indication allows a device that is able to detect faults (e.g. wrong cable type, wiring fault, etc.) to advertise the presence of the fault to the Link Partner.
The Remote Fault Indication may be used in conjunction with the Next Page function to transfer more information about the type of fault that occurred.
The primary benefit of Auto-Negotiation is the automatic connection of the highest performance technology available without any intervention from a user, manager, or management software.
If Auto-Negotiation exists at only one end of a twisted-pair link, it determines that the Link Partner does not support the Auto-Negotiation mechanism. Instead of exchanging configuration information, it examines the signal it is receiving. If Auto-Negotiation discovers that the signal matches a technology that the device supports, it will automatically connect that technology. This function, known as Parallel Detection, gives Auto-Negotiation the ability to be compatible with any device that does not support Auto-Negotiation, yet supports: 10BASE-T, 100BASE-TX, or 100BASE-T4. Connection to any technology via Parallel Detection other than those listed above is not supported by Auto-Negotiation.
In the event that no common technology exists, Auto-Negotiation will not make a connection. This ensures preservation of network integrity and minimization of network down time.
In particular, hubs are a primary beneficiary of this feature. For example, if a user connects a 100BASE-T4 device into a 10BASE-T/100BASE-TX switch, the result could be catastrophic for all the users connected through that switch. However, if the hub has Auto-Negotiation, it would refuse the connection and allow the rest of the network to proceed as usual. In fact, with Auto-Negotiation in the hub the network users are protected from any connection that the hub cannot recognize or accept.
If Auto-Negotiation exists on both ends of a twisted-pair link, then both ends advertise their abilities to the other. Auto-Negotiation incorporates a robust handshake that ensures data integrity. The devices compare their abilities and connect at the highest performance common technology shared.
Auto-Negotiation has been defined for flexibility. Standard technologies can use the basic Auto-Negotiation logic with their own definitions for the information to be exchanged (see section 5.0 for details). Currently, the IEEE 802.3 and 802.9 Working Groups each have their own, independent codes which allows the technologies to define which abilities can be advertised; In total, 32 of these codes can exist.
IEEE 802.3 currently supports:
New nodes on the market will have 100Mb/s functionality as well as the traditional 10BASE-T. This means that there will be some latent performance available as these new nodes are added to an old 10BASE-T network. When the performance issue becomes critical, the latent ability can be tapped into by upgrading the hub. Auto-Negotiation enables the upgrade to occur without reconfiguring each node and/or each port on the new hub.
While no management intervention is required for automatic connection, a management interface has been provided to give optional control and status of Auto-Negotiation. The management interface provides the following capabilities:
These capabilities are useful in a managed-hub application since they give the manager remote access to all the above information and control. These functions are useful for node solutions with Auto-Negotiation as well. However, in the case of a node, the information is only available to the user of that node and not to the network at large. This information would be useful in installation and diagnostic software to help guide the user in resolving any difficulties.
Auto-Negotiation has the option to send additional pieces of information after the "base" negotiation that determines the network connection before enabling the data service. This is known as the Next Page function. Among other things, it can be used to send information that corresponds to an Organizationally Unique Identifier so that extra features could be implemented on a proprietary basis, yet not conflict with standard operation. Both ends of a twisted-pair link must have Auto-Negotiation with support for the Next Page function in order to take advantage of this feature.
Specific remote fault type information transfer can also be supported using this flexible mechanism.
To support the many different technologies that are on the market today or will be available in the future, Auto-Negotiation has been architected in a way that provides extensibility and flexibility.
Basically, an Auto-Negotiation device advertises its abilities and detects the abilities of the remote device that it is connected to, known as the Link Partner. Once Auto-Negotiation has received the Link Partner's abilities in a robust manner and it receives acknowledgment that its abilities have also been received by the Link Partner, Auto-Negotiation compares the two sets of abilities and decides which technology to connect. This decision is based upon a pre-agreed priority of technologies. Auto-Negotiation attaches the highest performance common technology to the medium and becomes transparent until the link goes down or is reset.
The basic mechanism that Auto-Negotiation uses to advertise a device's abilities is a series of link pulses which encode a 16 bit word, known as a Fast Link Pulse (FLP) Burst. An FLP Burst is composed of 17 to 33 link pulses which are identical to the link pulses used in 10BASE-T to determine whether a link has a valid connection (sometimes referred to as Normal Link Pulses or NLPs.) FLP Bursts occur at the same interval as NLPs, 16.8ms. An FLP Burst has a nominal duration of 2 ms. Figure 2 shows the nominal timing of FLP Bursts.
An FLP Burst interleaves clock pulses with data pulses to encode a 16 bit word. The absence of a pulse within a time window following a clock pulse encodes a logic zero and a pulse within the time window following a clock pulse encodes a logic one.
The key to Auto-Negotiation's flexibility and expandability is the encoding of the 16 bit word. The 16 bit word is referred to as the Link Code Word (LCW). The LCW is encoded as shown in figure 3.
The Selector Field, S[4:0], allows 32 different definitions of the Technology Ability Field to coexist. The intention is to allow standard technologies to leverage the basic Auto-Negotiation mechanism. Currently, S[4:0]=< 00001 > is assigned to IEEE 802.3 and S[4:0]=< 00010 > is assigned to IEEE 802.9. Two more codes are reserved for expansion of Auto-Negotiation. The remaining codes are reserved to be assigned to standard technologies that wish to leverage this mechanism, yet fall outside the scope of the currently defined Selector Field values.
The Technology Ability Field, A[7:0], is defined relative to the Selector Field value of the Link Code Word. For IEEE 802.3 there are bits defined to advertise:
The above list also defines the priority hierarchy for resolving multiple common abilities. That is, if both devices support both 10BASE-T and 100BASE-TX, Auto-Negotiation at both ends will connect 100BASE-TX instead of 10BASE-T.
Priority resolution works such that when the 3 remaining bits in the Technology Ability Field are eventually defined, the new technology can be inserted anywhere in the list without disturbing the existing hierarchy. This means that the 3 reserved bits can be assigned without causing interoperability problems with any Auto-Negotiation device produced before these bits were defined.
The Remote Fault bit, RF, allows transmission of simple fault information to the Link Partner.
The Acknowledge bit, Ack, is used by the synchronization mechanism to ensure robust data transfer.
The Next Page bit, NP, advertises to the Link Partner whether the Next Page function is supported. The Next Page function is used to send additional information beyond the basic configuration information. Both ends must have this ability in order to exchange this type of information.
Auto-Negotiation must ensure that the Link Partner receives the Link Code Word correctly and that the Link Partner's Link Code Word is received correctly in order to make a connection decision. Auto-Negotiation uses the Arbitration function to accomplish this. Figure 4 illustrates the following example.
The Local Device begins by transmitting its Link Code Word, LCW[LD], with the Ack bit not set. Once three consecutive, matching Link Code Words are received from the Link Partner LCW[LP] (ignoring Ack), the Local Device sets the Ack bit in the transmitted Link Code Word to indicate that it has received the Link Partner's Link Code Word correctly.
The Local Device continues transmitting its Link Code Word. Upon receiving three consecutive, matching Link Code Words from the Link Partner with the Ack bit set, the Local Device knows that the Link Partner has also received the Link Code Word correctly. The Local Device transmits the Link Code Word with the Ack bit set 6-8 additional times to ensure that a complete handshake has taken place.
Now, both the Local Device and the Link Partner have exchanged their base Link Code Words. Each device compares their abilities and the highest performance common technology as determined by priority resolution is connected to the medium.
To account for technologies that existed prior to Auto-Negotiation, Auto-Negotiation passes the signals present on the receiver to the 100BASE-TX and 100BASE-T4 Link Monitor functions. If Auto-Negotiation determines that exactly one Link Monitor function indicates that the link is good, then it can connect that technology to the media. Note, however, that this function is only implemented for 10BASE-T, 100BASE-TX, and 100BASE-T4. Future multi-mode devices will use Auto-Negotiation as the basis of automatic mode switching.
Auto-Negotiation incorporates a modified 10BASE-T Link Integrity Test function in order to interoperate properly with installed 10BASE-T devices. The modifications ensure that Auto-Negotiation can control the function such that 10BASE-T devices are always correctly detected.
If the Next Page bit is set in both the outgoing and incoming Link Code Words, then both the Local Device and the Link Partner are able to support the Next Page function and will participate in Next Page exchange. Once the first Link Code Word has been exchanged, both sides have the information required to configure the highest common technology. However, if Next Page exchange occurs then Auto-Negotiation does not configure the highest common technology until Next Page exchange has completed.
Next Page exchange works in the same way that the `base' Link Code Words were exchanged. The main difference is the encoding of the exchanged Link Code Words which is shown in figure 5.
The Next Page bit, NP, indicates that an additional Next Page will be exchanged.
The Acknowledge, Ack bit works the same as for the base Link Code Word exchange.
Message Page, MP, indicates whether the Message Code Field, M[10:0], will be interpreted as a Message Code or an Unformatted Code. Message Codes are pre-defined messages in the IEEE 802.3 standard, Clause 28. Unformatted Codes are arbitrary pieces of data. Following a base Link Code Word exchange with the IEEE 802.3 Selector Field value, Unformatted Codes follow Message Codes with information required by the Message Code.
There are two different ways of interpreting a received Next Page. If the Message Page bit is set, then the Message Code Field, M[10:0], is a binary code that corresponds to a pre-defined message in the IEEE 802.3 standard, Clause 28. There are 2048 possible message codes. Of these, 8 codes are defined (all other codes are undefined at present): 2 codes are reserved for Auto-Negotiation expansion and the remaining 6 codes are defined as follows:
The Acknowledge 2 bit, Ack2, is set by the receiving device to indicate that the device supports the function indicated by the message.
The Toggle bit, T, is set by the Arbitration function within Auto-Negotiation to ensure proper synchronization with the Link Partner during Next Page exchange.
A basic remote fault status transport mechanism is built into the Auto-Negotiation function (i.e. mandatory). However, the ability to sense and categorize fault types is not required. To transfer simple remote fault status, a device which has detected a remote fault will set the Remote Fault bit in the Auto-Negotiation Advertisement Register (ANAR), and renegotiate. This will advertise to the Link Partner that a remote fault has been detected. If negotiation subsequently completes, the Remote Fault bit in the ANAR will be reset to clear the fault condition.
Upon detection of the Remote Fault bit in the Auto-Negotiation Link Partner Advertisement Register (ANLPAR), the device will set the Remote Fault bit in the MII status register.
Note: All registers are defined as part of the MII register set.
Devices may implement any remote fault detection mechanism desired and use this transport mechanism to inform the Link Partner of a fault. The meaning of the fault to the receiver is limited, however. Reception of remote fault status only informs a device that something is wrong with the link rather than specifying the type of fault that has occurred.
As an example, a device could detect a fault as follows. If a device is attempting to Auto-Negotiate yet "never" receives a valid set of signals that will allow it to connect, management software could detect this as being caused by a fault in making a connection. The device could then set the Remote Fault bit in the ANAR and renegotiate. The scenario described above could be caused by: (see Figure 6).
The Link Partner would have received the remote fault information and set the status bit informing management that a fault has occurred.
The Link Partner could never receive the remote fault information. If the Link Partner also supported this type of remote fault sensing, then the situation would be equivalent to example 1, where the Local Device would inform management of the fault status.
In this case, the Local Device will detect that the Link Partner is Auto-Negotiation able and set its outgoing Ack bit. The Local Device will "never" receive Ack set from the Link Partner. Since the Local Device's management agent knows that both devices are Auto-Negotiating, but cannot complete since there is no acknowledgment from the Link Partner, there must be something wrong with the transmission path.
Since the Link Partner does not support Auto-Negotiation, the remote fault information is not received by the Link Partner. Note that no connection should be allowed since there are no common technologies between the devices. The Local Device will continue to send link pulses indefinitely. Software may determine that a fault continues to persist and notify any local management agent.
It is possible for Auto-Negotiation to complete, even though some type of remote fault is present that can be detected. For example, a device may be jabbering, the wire may not support the 100Mb/s technology, or there is excessive noise present.
While this type of fault could be transferred using the simple Remote Fault transport mechanism, it may be beneficial to inform the Link Partner which type of fault is being experienced. This can be accomplished if both ends of the link participate in a Next Page exchange to transfer the fault type information. The wire connection must be such that an Auto-Negotiation page exchange can complete.
Auto-Negotiation has been architected to provide extensive code space that will allow the basic mechanism to be leveraged and remain interoperable regardless of the nature of new technologies.
Auto-Negotiation is easily adaptable to virtually any technology that uses twisted pair wiring. While not standardized, the same mechanism could be used over media types other than twisted pair by replacing the encoding method with one that is compatible with the given media. For example, since link pulses do not directly translate onto fiber, an alternate coding scheme could be defined to replace the link pulses. The algorithm and Link Code Word encodings would all remain the same.
The Next Page function is architected to provide virtually unlimited code space. The Message Code space has 2040 codes that may be defined. Implementations need only consider what is an acceptable time to make a connection.
Within a given Selector Field, the base page has enough space for 8 different technologies (assuming they are to be advertised independently). If all of the base page bits are defined, the Next Page function can be used to extend this to support additional technologies. Thus far, codes have been reserved to support up to 16 additional bits dedicated to providing technology information.
The Next Page function also provides the flexibility for manufacturers to define any additional information that may be used to provide control and/or status to a management agent.
Through the Selector Field code space, 30 fundamentally different network types can be accommodated by the Auto-Negotiation function. Currently, IEEE 802.3, CSMA/CD LANs, and IEEE 802.9 Integrated Services LAN have adopted Auto-Negotiation and reside in this code space. Token Ring, Wireless, and others could conceivably leverage all or part of Auto-Negotiation to provide a greater level of interoperability.
Auto-Negotiation is a standard, simple, low cost, flexible mechanism for providing connection interoperability between IEEE 802.3 LANs. Auto-Negotiation forms the basis for a highest common performance link configuration mechanism. In addition, Auto-Negotiation provides management control and is a valuable network status tool. Auto-Negotiation's simplicity facilitates implementing cost effective multi-function nodes and/or hubs. Auto-Negotiation's flexible architecture ensures that future technology interoperability needs can be met.
National Semiconductor provided its NWay(tm) technology and expertise to create Clause 28 of ANSI/IEEE Std 802.3u Draft D4 which embodies the Auto-Negotiation Function. This draft specifically supports configuring the highest performance common mode between 10BASE-T and 100BASE-T devices, enabling multi-vendor, standard interoperability a reality for IEEE 802.3 compatible LANs.
International Standard ISO/IEC 8802-3: 1992, 3rd. ed., ANSI/IEEE Std 802.3
IEEE Std 802.3u/D4-1995 (Draft supplement to ISO/IEC 8802-3:1993 ANSI/IEEE Std 802.3-1993 ed.)