Wednesday, 25 February 2015

autonegotiation part 2


How Autonegotiation (AN) Works with Fast Link Pulse (FLP)

The purpose of AN is to automatically configure two devices that share a link segment to take maximum advantages of their capabilities. This allows devices at both ends of the link segment to advertise their capabilities, acknowledge receipt and understanding of the common mode of operation that both devices share, and reject the use of modes that are not supported by both devices.AN is performed using a modified link-integrity pulse (called FLP, or Fast Link Pulse) such that no packet or upper protocol overhead is added. Each device capable of AN, issues FLP bursts at power up, on command from the MAC, or due to user interaction. Fast Link Pulse is more than simply a pulse. It is a structured bit sequence that allows for the negotiation process. A pulse is a series of bits within a given period. It is this bit stream that sets up the link.
 
FLP bursts
 Figure1
Each FLP burst consists of 33 pulse positions that provide clock and data information. The 17 odd-numbered pulses are designated as clock pulses, while the 16 even-numbered pulse positions represent data information. A logic one is represented by the presence of a pulse, while the absence of a pulse is represented by a logic zero.
FLP burst encoding
Figure 2
The data pulses in the FLP burst encode a 16-bit link code word (LCW). A device capable of auto-negotiation transmits and receives the FLP. The receiver must identify three identical LCWs before the information is authenticated and used in the arbitration process. The devices decode the base LCW and select capabilities of the highest common denominator supported by both devices. Once the LCWs are properly received, each device transmits a FLP burst with an acknowledge bit. At this point, both devices enable the mode that is the highest common mode negotiated.
The clock pulses are used for timing and recovery of the data pulses. The 17 clock pulses are always present in the FLP burst. The first pulse on the wire is a clock pulse. The 16 data pulses may or may not be present. If the data pulse is present, it represents a value of one in the LCW for that position. The lack of a data pulse indicates a zero in the LCW for that position, as shown in figure. 
Base link code word
The base LCW is transmitted within an FLP burst after power-on, reset, or renegotiation. The DTE and its link partner communicate their capabilities by exchanging LCWs. Figure 3 defines the bit positions of the base LCW. These bit positions map directly to the data pulses in the FLP burst—bits D0 through D15.
Technology ability field
Figure 3
Selector field, which is encoded in bits D0 through D4, indicates which standard is used between IEEE 802.3 and IEEE 802.9.
The technology ability field (TAF), which is encoded in bits D5 through D12 of the FLP burst, is a sequence of bits that encode the possible modes of operations among the 100BASE-T and 10BASE-T modes.
D13: remote fault: this is set to one when the device is detecting a link failure.
D14: 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.
D15: next page: this bit is used to indicate the intention of sending other link code words after the base link code word.
AN also provides for a Parallel Detection function to allow 10Base-T, 100Base-TX, and 100Base-T4 compatible devices to be recognized even in the event that one of both modes do not support AN.
Cisco switches use auto-negotiation by default; it is then disabled if both the speed and
duplex are manually configured. You can set the speed using the speed {auto | 10 | 100 | 1000} interface subcommand, assuming the interface supports multiple speeds. You configure the duplex setting using the duplex {auto | half | full} interface subcommand




-======

Difference Between CatOS and Cisco IOS System Software

CatOS on the Supervisor Engine and Cisco IOS Software on the Multilayer Switch Feature Card (MSFC) (Hybrid): a CatOS image can be used as the system software to run the Supervisor Engine on Catalyst 6500/6000 switches. If the optional MSFC is installed, a separate Cisco IOS Software image is used to run the MSFC.
Cisco IOS Software on both the Supervisor Engine and MSFC (Native): a single Cisco IOS Software image can be used as the system software to run both the Supervisor Engine and MSFC on Catalyst 6500/6000 switches.
Note:  Refer to Comparison of the Cisco Catalyst and Cisco IOS Operating Systems for the Cisco Catalyst 6500 Series Switch for more information.

When to Use Ethernet 10/100 Mb Auto-Negotiation

Auto-negotiation is an optional function of the IEEE 802.3u Fast Ethernet standard that enables devices to automatically exchange information over a link about speed and duplex abilities.
Auto-negotiation is targeted at ports. These ports are allocated to areas where transient users or devices connect to a network. For example, many companies provide shared offices or cubes for Account Managers and System Engineers to use when they are in the office. Each office or cube has an Ethernet port permanently connected to the office network. Because it might not be possible to ensure that every user has either a 10 Mb, a 100 Mb Ethernet, or a 10/100 Mb card in their laptop, the switch ports that handle these connections must be able to negotiate their speed and duplex mode. The alternative is to provide both a 10 Mb and a 100 Mb port in each office, or cube and label them accordingly.
One of the most common causes of performance issues on 10/100 Mb Ethernet links occurs when one port on the link operates at half-duplex while the other port operates at full-duplex. This occurs when one or both ports on a link are reset and the auto-negotiation process does not result in both link partners having the same configuration. It also can occur when users reconfigure one side of a link and forget to reconfigure the other side. Both sides of a link should have auto-negotiation on, or both sides should have it off. Cisco recommends to leave auto-negotiation on for those devices compliant with 802.3u.
Many performance-related support calls are avoided if you correctly configure auto-negotiation. Many Catalyst Ethernet switching modules support 10/100 Mb and half-duplex or full-duplex. Exceptions include the Ethernet Group switch modules. The show port capabilities {mod_num} | {mod_num/port_num} command shows if the module you are working on supports 10/100 Mb and half-duplex or full-duplex. This document uses two WS-X5530 Supervisor Engine IIIs, each with two optional uplink 10/100 BaseTX Ethernet ports installed.
Note: When the WS-6748-GE-TX module is connected to a network tap device, automatic negotiation does not work. In order to resolve this issue, you must configure auto-negotiation manually. Go to the interface mode and execute this command:
Cat6K-IOS(config-if)#speed auto

When to Use Ethernet 1000 Mb Auto-Negotiation

Basically auto-negotiation in GigabitEthernet covers these items:
  • Duplex settings—While Cisco devices only support full-duplex, the IEEE 802.3z standard does have support for half-duplex GigabitEthernet. Because of this, duplex is negotiated between GigabitEthernet devices.
  • Flow Control—Becuase of the amount of traffic that can be generated by GigabitEthernet, there is a PAUSE functionality built into GigabitEthernet. The PAUSE frame is a packet that tells the far-end device to stop the transmition of packets until the sender is able to handle all the traffic and clear its buffers. The PAUSE frame has a timer included, which tells the far-end device when to start to send packets again. If that timer expires without getting another PAUSE frame, the far-end device can then send packets again. Flow-Control is an optional item and must be negotiated. Devices can be capable of sending or responding to a PAUSE frame, and they possibly do not agree to the flow-control request of the far-end neighbor.
  • Negotiation—Usually built-in Gigabit Ethernet ports are capable of negotiation, but in cases like modular SFP or GBIC types, they do not negotiate. Line protocol will be down for a Gigabit Ethernet port when connected to a Fast Ethernet port. This can be verified via the show inter gig4/3 capabilities command:
    Switch-A#show interface Gig4/3 capabilities
    GigabitEthernet4/3
    Model                    WS-X4516-10GE-Gbic
    Type                     1000BaseT
    Speed                    1000
    Duplex                   full
    
    
Assume that there are two devices, A and B. Assume that each device can have Autonegotiation enabled, or disabled. The correct behaviour of link status with autonegotiation in accordance to the IEEE Std 802.3z-1998 should be like this:
  • If A is enabled and B is enabled, then link status should be reported on both devices as link up.
  • If A is disabled and B is enabled, then A should report link up and B should report link down.
  • If A is enabled and B is disabled, then A should report link down and B should report link up.
By default, all devices are supposed to perform autonegotiation. 802.3z does not specifically define a way to turn Autonegotiation off, for both 1GigabitEthernet and 10GigabitEthernet.

Configure and Troubleshoot Ethernet 10/100Mb Auto-Negotiation on CatOS Switches

This section of the document explains how to examine the behavior of an 10/100 Mb Ethernet port that supports auto-negotiation. This procedure shows how to make changes to its default behavior and how to restore it to the default behavior. Complete these steps:
  1. Connect the two switches together.
    Ethernet port 1/1 on switch A is connected to Ethernet port 1/1 on switch B using an Ethernet crossover cable. See Appendix B for more information on crossover cables.
    Note: Your actual mod_num/port_num numbers might be different.
  2. Examine the capabilities of the ports.
    The show port capabilities 1/1 command displays the capabilities of an Ethernet 10/100 BaseTX 1/1 port on switch A.
    Issue this command for both of the ports you are troubleshooting. Both ports must support the speed and duplex capabilities if they are supposed to use auto-negotiation.
    The bold text in this output shows where the information on the speed and duplex mode capabilities are found.
    Switch-A> (enable) show port capabilities 1/1
    Model                    WS-X5530
    Port                     1/1
    Type                     10/100BaseTX
    Speed                    auto,10,100
    Duplex                   half,full
    
    
  3. Configure auto-negotiation for port 1/1 on both switches.
    Issue the set port speed 1/1 auto command to configure auto-negotiation for both speed and duplex mode on port 1/1 of both switches. Auto is the default for ports that support auto-negotiation.
    Switch-A> (enable) set port speed 1/1 auto
    Port(s) 1/1 speed set to auto detect.
    Switch-A (enable)
    Note: The set port speed {mod_num/port_num} auto command also sets the duplex mode to auto. There is no set port duplex {mod_num/port_num} auto command.
    Also, this command is redundant because the configurations of the switches had been cleared to their defaults before starting this procedure. The default behavior for Ethernet 10/100 BaseTX ports is auto-negotiation.
  4. Determine if the speed and duplex mode are set to auto-negotiate.
    Issue the show port 1/1 command to display the status of ports 1/1 on switches A and B.
    Switch-A> (enable) show port 1/1
    Port  Name               Status     Vlan       Level  Duplex Speed Type
    ----- ------------------ ---------- ---------- ------ ------ ----- ------------
     1/1                     connected  1          normal  a-full a-100 10/100BaseTX
    
    
    Switch-B> (enable) show port 1/1  
    Port  Name               Status     Vlan       Level  Duplex Speed Type
    ----- ------------------ ---------- ---------- ------ ------ ----- -----------
     1/1                     connected  1          normal a-full  a-100 10/100BaseTX
    The bold text in the preceding output shows where the information on the current status of a port can be found. Most of the normal output from the show port {mod_num/port_num} command is omitted. See Appendix C for further explanation of the fields in the output of this command.
    The a prefixes on the full and 100 indicate that this port is not hard coded (configured) for a specific duplex mode or speed. Therefore, it auto-negotiates the duplex mode and speed if the device it is connected to also auto-negotiates duplex mode and speed.
    The status is connected on both ports, which means that a link pulse is detected from the other port. The status can be connected even if duplex is incorrectly negotiated or incorrectly configured.
  5. Change the speed on port 1/1 in switch A to 10 Mb.
    In order to demonstrate what occurs when one link partner auto-negotiates and the other link partner does not, the speed on port 1/1 in switch A must be set to 10 Mb. Issue the set port speed 1/1 10 command to set this speed.
    Switch-A> (enable) set port speed 1/1 10
    Port(s) 1/1 speed set to 10Mbps.
    Switch-A> (enable)
    Note: Hard coding the speed on a port disables all auto-negotiation functionality on the port for speed and duplex.
    When a port is configured for a speed, the duplex mode is automatically configured for the mode it previously negotiated. In this case, the mode is full-duplex. Therefore, the set port speed 1/1 10 command causes the duplex mode on port 1/1 to be configured as if the command set port duplex 1/1 full is also issued. This is explained in step 6.
  6. Understand the meaning of the a prefix on the duplex and speed status fields.
    The absence of the a prefix in the status fields of the output from the show port 1/1 command on switch A shows that the duplex mode is configured for full and the speed is configured for 10.
    Switch-A> (enable) show port 1/1
    Port  Name               Status     Vlan       Level  Duplex Speed Type
    ----- ------------------ ---------- ---------- ------ ------ ----- ------------
     1/1                     connected  1          normal  full  10    10/100BaseTX
  7. View the duplex status of port 1/1 on switch B.
    The show port 1/1 command on switch B indicates that the port operates at half-duplex and 10 Mb.
    Switch-B> (enable) show port 1/1
    Port  Name               Status     Vlan       Level  Duplex Speed Type
    ----- ------------------ ---------- ---------- ------ ------ ----- ------------
     1/1                     connected  1          normal a-half a-10  10/100BaseTX
    This step shows that it is possible for a link partner to detect the speed at which the other link partner operates, even though the other link partner is not configured for auto-negotiation. In order to detect the speed, the link partner senses the type of electrical signal that arrives and sees if it is 10 Mb or 100 Mb. This is how switch B determines that port 1/1 operates at 10 Mb.
    It is not possible to detect the correct duplex mode in the same method that the correct speed can be detected. In this case, where the 1/1 port of switch B is configured for auto-negotiation and the 1/1 port of switch A is not, the 1/1 port of switch B is forced to select the default duplex mode. On Catalyst Ethernet ports, the default mode is auto-negotiate. If auto-negotiation fails, the default mode is half-duplex.
    This example also shows that a link can be successfully connected when there is a mismatch in the duplex modes. Port 1/1 on switch A is configured for full-duplex while port 1/1 on switch B is defaulted to half-duplex. Configure both link partners to avoid this.
    The a prefix on the Duplex and Speed status fields does not always mean that the current behavior is negotiated. Sometimes it can mean that the port is not configured for a speed or duplex mode.
    The previous output from switch B shows duplex as a-half and speed as a-10. This indicates that the port operates at 10 Mb in half-duplex mode. In this example, however, the link partner on this port (port 1/1 on switch A) is configured for full and 10 Mb. Therefore, it is not possible for port 1/1 on switch B to auto-negotiate current behavior. This proves that the a prefix only indicates a willingness to perform auto-negotiation, and not that auto-negotiation actually took place.
  8. Understand the duplex mismatch error.
    This message about a duplex mode mismatch is displayed on switch A after the speed on port 1/1 is changed to 10 Mb. This mismatch occurs because the 1/1 port of switch B defaults to half-duplex when it senses its link partner no longer performs auto-negotiation.
    %CDP-4-DUPLEXMISMATCH:Full/half-duplex mismatch detected o1
    It is important to note that this message is created by the Cisco Discovery Protocol (CDP), not the 802.3 auto-negotiation protocol. CDP can report problems it discovers, but it typically does not automatically fix them.
    A duplex mismatch might or might not result in an error message. Another indication of a duplex mismatch is the rapid increase of FCS and alignment errors on the half-duplex side, and runts on the full-duplex port. This can be seen in a show port {mod_num/port_num} command.
  9. Understand the spanning tree error messages.
    In addition to the duplex mismatch error message in step 8, you might also see these spanning tree messages when you change the speed on a link.
    %PAGP-5-PORTFROMSTP:Port 1/1 left bridge port 1/1
    %PAGP-5-PORTTOSTP:Port 1/1 joined bridge port 1/1
    Note: Refer to Understanding and Configuring Spanning Tree Protocol (STP) on Catalyst Switches for more information on spanning tree.
  10. Change the duplex mode to half on port 1/1 on switch A.
    Issue the set port duplex 1/1 half command to set the mode on port 1/1 in switch A to half. This demonstrates what occurs when the duplex mode is configured.
    Switch-A> (enable) set port duplex 1/1 half
    Port(s) 1/1 set to half-duplex.
    Switch-A> (enable)
    The show port 1/1 command displays the change in the duplex mode on this port.
    Switch-A> (enable) show port 1/1
    Port  Name               Status     Vlan       Level  Duplex Speed Type
    ----- ------------------ ---------- ---------- ------ ------ ----- ------------
     1/1                     connected  1          normal   half    10 10/100BaseTX
    At this point, ports 1/1 on both switches operate at half-duplex. Port 1/1 on switch B, however, is still configured to auto-negotiate, as displayed in this output of the show port 1/1 command.
    Switch-B> (enable) show port 1/1
    Port  Name               Status     Vlan       Level  Duplex Speed Type
    ----- ------------------ ---------- ---------- ------ ------ ----- ------------
     1/1                     connected  1          normal a-half a-10  10/100BaseTX
    Step 11 shows how to configure the duplex mode on port 1/1 in switch B to half. This is the recommended policy of always configuring both link partners in the same way.
  11. Set the duplex mode and speed of port 1/1 on switch B.
    This step sets the duplex mode to half and speed to 10 on port 1/1 in switch. This implements the policy of always configuring both link partners for the same behavior.
    This is the output when you issue the set port duplex 1/1 half command on switch B.
    Switch-B> (enable) set port duplex 1/1 half
    Port 1/1 is in auto-sensing mode.
    Switch-B> (enable)
    The set port duplex 1/1 half command fails because this command does not work if auto-negotiation is enabled. This also means that this command does not disable auto-negotiation. Auto-negotiation can only be disabled when you issue the set port speed {mod_num/port_num {10 | 100}} command.
    This is the output when you issue the set port speed 1/1 10 command on switch B.
    Switch-B> (enable) set port speed 1/1 10
    Port(s) 1/1 speed set to 10Mbps.
    Switch-B> (enable)
    Now the set port duplex 1/1 half command on switch B works.
    Switch-A> (enable) set port duplex 1/1 half
    Port(s) 1/1 set to half-duplex.
    Switch-A> (enable)
    The show port 1/1 command on switch B shows that the ports is configured for half-duplex and 10 Mb.
    Switch-B> (enable) show port 1/1
    Port  Name               Status     Vlan       Level  Duplex Speed Type
    ----- ------------------ ---------- ---------- ------ ------ ----- ------------
     1/1                     connected  1          normal   half    10 10/100BaseTX
    Note: The set port duplex {mod_num/port_num {half | full }} command is dependent on the set port speed {mod_num/port_num {10 | 100 }} command. In other words, you must set the speed before you can set the duplex mode.
  12. Restore the default duplex mode and speed to ports 1/1 on both switches.
    Issue the set port speed 1/1 auto command to configure ports 1/1 on both switches to auto-negotiate.
    Switch-A> (enable) set port speed 1/1 auto
    Port(s) 1/1 speed set to auto detect.
    Switch-A> (enable)
    Note: Once the duplex mode of a port is configured to something other than auto, the only method to configure the port to auto-sense the duplex mode is to issue the set port speed {mod_num/port_num} auto command. There is no set port duplex {mod_num/port_num} auto command. In other words, issuing the set port speed {mod_num/port_num} auto command has the effect of resetting both port speed sensing and duplex mode sensing to auto.
  13. View the changes of the port status on both switches.
    Issue the show port 1/1 command to examine the status of ports 1/1 on both switches.
    Switch-A> (enable) show port 1/1
    Port  Name               Status     Vlan       Level  Duplex Speed Type
    ----- ------------------ ---------- ---------- ------ ------ ----- ------------ 
     1/1                     connected  1          normal a-full a-100 10/100BaseTX
    
    
    Switch-B> (enable) show port 1/1
    Port  Name               Status     Vlan       Level  Duplex Speed Type
    ----- ------------------ ---------- ---------- ------ ------ ----- ------------
     1/1                     connected  1          normal a-full a-100 10/100BaseTX
    Both ports are now set to their default behavior of auto-negotiation. Both ports negotiate full-duplex and 100 Mb.

Auto-Negotiation on Catalyst Switches that Run Cisco IOS Software

The commands described in this section apply to these types of switch products: Catalyst 2900XL, 3500XL, 2950, 3550, 2948G-L3, 4908G-L3, Catalyst 4500/4000 that runs Cisco IOS System Software (Supervisor Engine III), and the Catalyst 6500/6000 that runs Cisco IOS System Software.
The switches that run Cisco IOS Software (as opposed to CatOS) default to auto-negotiation for speed and are set to on for the duplex. Issue the show interface slot/port status command to verify this.
This output is taken from a Catalyst 6500/6000 that runs Cisco IOS Software Release 12.1(6)E. It shows a connected port that auto-negotiates a link to 100 Mbps and half-duplex. The configuration that runs for this switch has no duplex or speed commands underneath interface FastEthernet 3/1 because auto-negotiation is the default. Issue the show interface slot/port command (without the status keyword) to see the port speed and duplex.
NativeIOS#show interfaces fastethernet 3/1 status

Port    Name               Status       Vlan       Duplex Speed Type
Fa3/1                      connected    routed     a-half a-100 10/100BaseTX

NativeIOS#show run
...
!
interface FastEthernet3/1
ip address 172.16.84.110 255.255.255.0

!--- Notice there is no speed or duplex commands under this interface because
!--- it is in the default configuration of auto-negotiate speed and duplex.


NativeIOS#show interfaces fastethernet 3/1
FastEthernet3/1 is up, line protocol is up 
 Hardware is C6k 100Mb 802.3, address is 0002.7ef1.36e0 (bia 0002.7ef1.36e0)
 Internet address is 172.16.84.110/24
 MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec, 
    reliability 255/255, txload 1/255, rxload 1/255
 Encapsulation ARPA, loopback not set
 Keepalive set (10 sec)
 Half-duplex, 100Mb/s
 ...
If you want to hard code the speed and duplex on a switch that runs Cisco IOS Software (turn off auto-negotiation), issue the speed and duplex commands underneath the specific interface. Duplex is subservient to speed in the sense that if speed is set to auto, then the duplex cannot be manually set. You might see cyclic redundancy check (CRC) error messages when both the speed and duplex settings are hardcoded on the two devices. This might be because any one of the devices runs an earlier version of Cisco IOS. You can upgrade the Cisco IOS or set the speed and duplex to auto on both devices in order to resolve this.
NativeIOS#show run
...
interface FastEthernet3/2
no ip address
!         
NativeIOS#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
NativeIOS(config)#interface fastethernet3/2
NativeIOS(config-if)#duplex full
Duplex will not be set until speed is set to non-auto value

!--- Error: On this platform, you must set the speed before the duplex.
!--- Not all switch platforms have this command ordering requirement.

NativeIOS(config-if)#speed 100
NativeIOS(config-if)#duplex full
NativeIOS(config-if)#^Z
NativeIOS#show interfaces fastethernet 3/2 status

Port    Name               Status       Vlan       Duplex Speed Type
Fa3/2                      notconnect   routed       full   100 10/100BaseTX

NativeIOS#NativeIOS#show run
...
interface FastEthernet3/2
no ip address
duplex full
speed 100

!--- Notice that the speed and duplex commands appear in the configuration
!--- now because they have been manually set to a non-default behavior.

autonegotiation FLP

Autonegotiation
From Wikipedia, the free encyclopedia
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. For Ethernet over twisted pair it is defined in clause 28 of IEEE 802.3.[1]
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 twisted pair.[2]

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, 1000BASE-TX and 10GBASE-T 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

A sequence of normal link pulses, used by 10BASE-T devices to establish link integrity.
Auto-negotiation (formerly "NWay") is based on pulses similar to those used by 10BASE-T devices to detect the presence of a connection to another device. These connection present pulses are sent by Ethernet devices when they are not sending or receiving any frames. They are unipolar positive-only electrical pulses of a nominal duration of 100 ns, with a maximum pulse width of 200 ns,[3] generated at a 16 ms time interval (with a timing variation 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 auto-negotiation specification.
A device detects the failure of a link if neither a frame nor two of the LIT pulses is received for 50-150 ms. For this scheme to work, devices must send LIT pulses regardless of receiving any.
Three bursts of Fast Link Pulses, used by autonegotiating devices to declare their capabilities.
Auto-negotiation uses similar pulses labeled as NLP. NLP are still unipolar, positive-only, and of the nominal duration of 100 ns; but each LIT is replaced by a pulse burst consisting of 17 to 33 pulses sent 125 µs apart. Each such pulse burst is called a fast link pulse (FLP) burst. The time interval between the start of each FLP burst is the same 16 milliseconds as between normal link pulses (variation tolerance of 8 ms).
How a link code word (a 16 bit word) is encoded in a fast link pulse burst
The FLP burst consists of 17 NLP at a 125 µs time interval (with a tolerance of 14 µs). Between each pair of two consecutive NLP (i.e. at 62.5 µs after first NLP of the pulse pair) an additional positive pulse may be present. The presence of this additional pulse indicates a logical 1, its absence a logical 0. As a result, every FLP contains a data word of 16 bits. This data 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 2012 edition of 802.3 is as follows:[4]
  1. 10GBASE-T full duplex
  2. 1000BASE-T full duplex
  3. 1000BASE-T half duplex
  4. 100BASE-T2 full duplex
  5. 100BASE-TX full duplex
  6. 100BASE-T2 half duplex
  7. 100BASE-T4 half duplex
  8. 100BASE-TX half duplex
  9. 10BASE-T full duplex
  10. 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. Problems like this with autonegotiation led many network administrators to manually set the speed and duplex mode of each network interface card, and even Cisco recommended its customers not to use autonegotiation. However, the use of manually set configuration may also lead 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, many network equipment manufacturers recommend using autonegotiation on all access ports.

Duplex mismatch

Main article: Duplex mismatch
A 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 MDI-X for automatic configuration of straight-through or crossover-cable connection

References


  • http://standards.ieee.org/getieee802/download/802.3-2012_section2.pdf IEEE 802.3, clause 28, page 221, "Physical Layer link signaling for Auto-Negotiation on twisted pair" Note: Download of PDF is free, but behind a Captive portal.

  • 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. Retrieved 2014-06-03.

  • "IEEE Link Task Force Autodetect, Specification for NWay Autodetect". p. 57. Archived from the original on 2011-07-14.

  • IEEE 802.3 Annex 28B

  • http://www.negotiateddata.com/files/Grant_Letter_060794.pdf

    1. Negotiated Data Solutions LLC. "NWay/IEEE Standard Patent License Offer | Negotiated Data Solutions LLC". Negotiateddata.com. Retrieved 2010-02-02.

    External links

    Tuesday, 10 February 2015

    High Level Data Link control



    High-Level Data Link Control
    From Wikipedia, the free encyclopedia
    reference 
    http://en.wikipedia.org/wiki/High-Level_Data_Link_Control

    High-Level Data Link Control (HDLC) is a bit-oriented code-transparent synchronous data link layer protocol developed by the International Organization for Standardization (ISO). The original ISO standards for HDLC are:
    • ISO 3309 – Frame Structure
    • ISO 4335 – Elements of Procedure
    • ISO 6159 – Unbalanced Classes of Procedure
    • ISO 6256 – Balanced Classes of Procedure
    The current standard for HDLC is ISO 13239, which replaces all of those standards.
    HDLC can be used for point to multipoint connections, but is now used almost exclusively to connect one device to another, using what is known as Asynchronous Balanced Mode (ABM). The original master-slave modes Normal Response Mode (NRM) and Asynchronous Response Mode (ARM) are rarely used.
    Contents
    History
    HDLC is based on IBM's SDLC protocol, which is the layer 2 protocol for IBM's Systems Network Architecture (SNA). It was extended and standardized by the ITU as LAP, while ANSI named their essentially identical version ADCCP.
    Derivatives have since appeared in innumerable standards. It was adopted into the X.25 protocol stack as LAPB, into the V.42 protocol as LAPM, into the Frame Relay protocol stack as LAPF and into the ISDN protocol stack as LAPD.
    HDLC was the inspiration for the IEEE 802.2 LLC protocol, and it is the basis for the framing mechanism used with the PPP on synchronous lines, as used by many servers to connect to a WAN, most commonly the Internet.
    A mildly different version is also used as the control channel for E-carrier (E1) and SONET multichannel telephone lines. Some vendors, such as Cisco, implemented protocols such as Cisco HDLC that used the low-level HDLC framing techniques but added a protocol field to the standard HDLC header. More importantly, HDLC is the default encapsulation for serial interfaces on Cisco routers. It has also been used on Tellabs DXX for destination of Trunk.
    Framing
    HDLC frames can be transmitted over synchronous or asynchronous serial communication links. Those links have no mechanism to mark the beginning or end of a frame, so the beginning and end of each frame has to be identified. This is done by using a frame delimiter, or flag, which is a unique sequence of bits that is guaranteed not to be seen inside a frame. This sequence is '01111110', or, in hexadecimal notation, 0x7E. Each frame begins and ends with a frame delimiter. A frame delimiter at the end of a frame may also mark the start of the next frame. A sequence of 7 or more consecutive 1-bits within a frame will cause the frame to be aborted.
    When no frames are being transmitted on a simplex or full-duplex synchronous link, a frame delimiter is continuously transmitted on the link. Using the standard NRZI encoding from bits to line levels (0 bit = transition, 1 bit = no transition), this generates one of two continuous waveforms, depending on the initial state:

    This is used by modems to train and synchronize their clocks via phase-locked loops. Some protocols allow the 0-bit at the end of a frame delimiter to be shared with the start of the next frame delimiter, i.e. '011111101111110'.
    For half-duplex or multi-drop communication, where several transmitters share a line, a receiver on the line will see continuous idling 1-bits in the inter-frame period when no transmitter is active.
    Since the flag sequence could appear in user data, such sequences must be modified during transmission to keep the receiver from detecting a false frame delimiter. The receiver must also detect when this has occurred so that the original data stream can be restored before it is passed to higher layer protocols. This can be done using bit stuffing, in which a "0" is added after the occurrence of every "11111" in the data. When the receiver detects these "11111" in the data, it removes the "0" added by the transmitter.
    Synchronous framing
    On synchronous links, this is done with bit stuffing. Any time that 5 consecutive 1-bits appear in the transmitted data, the data is paused and a 0-bit is transmitted. This ensures that no more than 5 consecutive 1-bits will be sent. The receiving device knows this is being done, and after seeing 5 1-bits in a row, a following 0-bit is stripped out of the received data. If, after 5 consecutive 1-bits, the following bit is also a 1-bit, the receiving device knows that either a flag has been found (if the sixth 1-bit is followed by a 0-bit) or an error has occurred (if the sixth 1-bit is followed by seventh 1-bit). In the latter case, the frame receive procedure, depending on state, is generally either aborted or restarted.
    This also (assuming NRZL with transition for 0 encoding of the output) provides a minimum of one transition per 6 bit times during transmission of data, and one transition per 7 bit times during transmission of flag, so the receiver can stay in sync with the transmitter. Note however, that for new protocols, newer encodings such as 8b/10b encoding are better suited.
    HDLC transmits bytes of data with the least significant bit first (not to be confused with little-endian order, which refers to byte ordering within a multi-byte field).
    Asynchronous framing
    When using asynchronous serial communication such as standard RS-232 serial ports, bits are sent in groups of 8, and bit-stuffing is inconvenient. Instead they use "control-octet transparency", also called "byte stuffing" or "octet stuffing". The frame boundary octet is 01111110, (7E in hexadecimal notation). A "control escape octet", has the bit sequence '01111101', (7D hexadecimal). If either of these two octets appears in the transmitted data, an escape octet is sent, followed by the original data octet with bit 5 inverted. For example, the data sequence "01111110" (7E hex) would be transmitted as "01111101 01011110" ("7D 5E" hex). Other reserved octet values (such as XON or XOFF) can be escaped in the same way if necessary.
    Structure
    The contents of an HDLC frame are shown in the following table:
    Flag
    Address
    Control
    Information
    FCS
    Flag
    8 bits
    8 or more bits
    8 or 16 bits
    Variable length, 0 or more bits
    16 or 32 bits
    8 bits
    Note that the end flag of one frame may be (but does not have to be) the beginning (start) flag of the next frame.
    Data is usually sent in multiples of 8 bits, but only some variants require this; others theoretically permit data alignments on other than 8-bit boundaries.
    The frame check sequence (FCS) is a 16-bit CRC-CCITT or a 32-bit CRC-32 computed over the Address, Control, and Information fields. It provides a means by which the receiver can detect errors that may have been induced during the transmission of the frame, such as lost bits, flipped bits, and extraneous bits. However, given that the algorithms used to calculate the FCS are such that the probability of certain types of transmission errors going undetected increases with the length of the data being checked for errors, the FCS can implicitly limit the practical size of the frame.
    If the receiver's calculation of the FCS does not match that of the sender's, indicating that the frame contains errors, the receiver can either send a negative acknowledge packet to the sender, or send nothing. After either receiving a negative acknowledge packet or timing out waiting for a positive acknowledge packet, the sender can retransmit the failed frame.
    The FCS was implemented because many early communication links had a relatively high bit error rate, and the FCS could readily be computed by simple, fast circuitry or software. More effective forward error correction schemes are now widely used by other protocols.
    Types of Stations (Computers), and Data Transfer Modes
    Synchronous Data Link Control (SDLC) was originally designed to connect one computer with multiple peripherals. The original "normal response mode" is a master-slave mode where the computer (or primary terminal) gives each peripheral (secondary terminal) permission to speak in turn. Because all communication is either to or from the primary terminal, frames include only one address, that of the secondary terminal; the primary terminal is not assigned an address. There is no strong distinction between commands sent by the primary to a secondary, and responses sent by a secondary to the primary. Commands and responses are in fact indistinguishable; the only difference is the direction in which they are transmitted.
    Normal response mode allows operation over half-duplex communication links, as long as the primary is aware that it may not transmit when it has given permission to a secondary.
    Asynchronous response mode is an HDLC addition[1] for use over full-duplex links. While retaining the primary/secondary distinction, it allows the secondary to transmit at any time.
    Asynchronous balanced mode added the concept of a combined terminal which can act as both a primary and a secondary. There are some subtleties about this mode of operation; while many features of the protocol do not care whether they are in a command or response frame, some do, and the address field of a received frame must be examined to determine whether it contains a command (the address received is ours) or a response (the address received is that of the other terminal).
    Some HDLC variants extend the address field to include both source and destination addresses, or an explicit command/response bit.
    HDLC Operations, and Frame Types
    There are three fundamental types of HDLC frames.
    • Information frames, or I-frames, transport user data from the network layer. In addition they can also include flow and error control information piggybacked on data.
    • Supervisory Frames, or S-frames, are used for flow and error control whenever piggybacking is impossible or inappropriate, such as when a station does not have data to send. S-frames do not have information fields.
    • Unnumbered frames, or U-frames, are used for various miscellaneous purposes, including link management. Some U-frames contain an information field, depending on the type.
    Control Field
    The general format of the control field is:
    HDLC control fields
    7
    6
    5
    4
    3
    2
    1
    0

    N(R)
    Receive sequence no.
    P/F
    N(S)
    Send sequence no.
    0
    I-frame
    N(R)
    Receive sequence no.
    P/F
    type
    0
    1
    S-frame
    type
    P/F
    type
    1
    1
    U-frame
    There are also extended (2-byte) forms of I and S frames. Again, the least significant bit (rightmost in this table) is sent first.
    Extended HDLC control fields
    15
    14
    13
    12
    11
    10
    9
    8

    7
    6
    5
    4
    3
    2
    1
    0

    N(R)
    Receive sequence no.
    P/F

    N(S)
    Send sequence no.
    0
    Extended I-frame
    N(R)
    Receive sequence no.
    P/F
    0
    0
    0
    0
    type
    0
    1
    Extended S-frame
    The P/F bit
    Poll/Final is a single bit with two names. It is called Poll when set by the primary station to obtain a response from a secondary station, and Final when set by the secondary station to indicate a response or the end of transmission. In all other cases, the bit is clear.
    The bit is used as a token that is passed back and forth between the stations. Only one token should exist at a time. The secondary only sends a Final when it has received a Poll from the primary. The primary only sends a Poll when it has received a Final back from the secondary, or after a timeout indicating that the bit has been lost.
    • In NRM, possession of the poll token also grants the addressed secondary permission to transmit. The secondary sets the F-bit in its last response frame to give up permission to transmit. (It is equivalent to the word "Over" in radio voice procedure.)
    • In ARM and ABM, the P bit forces a response. In these modes, the secondary need not wait for a poll to transmit, so need not wait to respond with a final bit.
    • If no response is received to a P bit in a reasonable period of time, the primary station times out and sends P again.
    • The P/F bit is at the heart of the basic checkpoint retransmission scheme that is required to implement HDLC; all other variants (such as the REJ S-frame) are optional and only serve to increase efficiency. Whenever a station receives a P/F bit, it may assume that any frames that it sent before it last transmitted the P/F bit and not yet acknowledged will never arrive, and so should be retransmitted.
    When operating as a combined station, it is important to maintain the distinction between P and F bits, because there may be two checkpoint cycles operating simultaneously. A P bit arriving in a command from the remote station is not in response to our P bit; only an F bit arriving in a response is.
    N(R), the receive sequence number
    Both I and S frames contain a receive sequence number N(R). N(R) provides a positive acknowledgement for the receipt of I-frames from the other side of the link. Its value is always the first frame not received; it acknowledges that all frames with N(S) values up to N(R)-1 (modulo 8 or modulo 128) have been received and indicates the N(S) of the next frame it expects to receive.
    N(R) operates the same way whether it is part of a command or response. A combined station only has one sequence number space.
    N(S), the sequence number of the sent frame
    This is incremented for successive I-frames, modulo 8 or modulo 128. Depending on the number of bits in the sequence number, up to 7 or 127 I-frames may be awaiting acknowledgment at any time.
    I-Frames (user data)
    Information frames, or I-frames, transport user data from the network layer. In addition they also include flow and error control information piggybacked on data. The sub-fields in the control field define these functions.
    The least significant bit (first transmitted) defines the frame type. 0 means an I-frame. Except for the interpretation of the P/F field, there is no difference between a command I frame and a response I frame; when P/F is 0, the two forms are exactly equivalent.
    S-Frames (control)
    Supervisory Frames, or 'S-frames', are used for flow and error control whenever piggybacking is impossible or inappropriate, such as when a station does not have data to send. S-frames do not have information fields.
    The S-frame control field includes a leading "10" indicating that it is an S-frame. This is followed by a 2-bit type, a poll/final bit, and a sequence number. If 7-bit sequence numbers are used, there is also a 4-bit padding field.
    The first 2 bits mean it is an S-frame. All S frames include a P/F bit and a receive sequence number as described above. Except for the interpretation of the P/F field, there is no difference between a command S frame and a response S frame; when P/F is 0, the two forms are exactly equivalent.
    1|0 |S|S|P(F)|N(R)| The 2-bit type field encodes the type of S frame.
    Receive Ready (RR)
    • Bit Value = 00 (0x00 to match above table type field bit order[2])
    • Indicate that the sender is ready to receive more data (cancels the effect of a previous RNR).
    • Send this packet if you need to send a packet but have no I frame to send.
    • A primary station can send this with the P-bit set to solicit data from a secondary station.
    • A secondary terminal can use this with the F-bit set to respond to a poll if it has no data to send.
    Receive Not Ready (RNR)
    • Bit value = 01 (0x04 to match above table type field bit order[3])
    • Acknowledge some packets and request no more be sent until further notice.
    • Can be used like RR with P bit set to solicit the status of a secondary station.
    • Can be used like RR with F bit set to respond to a poll if the station is busy.
    Reject (REJ)
    • Bit value = 10 (0x08 to match above table type field bit order[4])
    • Requests immediate retransmission starting with N(R).
    • Sent in response to an observed sequence number gap. After seeing I1/I2/I3/I5, send REJ4.
    • Optional to generate; a working implementation can use only RR.
    Selective Reject (SREJ)
    • Bit value = 11 (0x0c to match above table type field bit order)
    • Requests retransmission of only the frame N(R).
    • Not supported by all HDLC variants.
    • Optional to generate; a working implementation can use only RR, or only RR and REJ.
    U-Frames
    Unnumbered frames, or U-frames, are used for link management, and can also be used to transfer user data. They exchange session management and control information between connected devices, and some U-frames contain an information field, used for system management information or user data. The first 2 bits (11) mean it is a U-frame. The 5 type bits (2 before P/F bit and 3 bit after P/F bit) can create 32 different types of U-frame
    • Mode settings (SNRM, SNRME, SARM, SARME, SABM, SABME, UA, DM, RIM, SIM, RD, DISC)
    • Information Transfer (UP, UI)
    • Recovery (FRMR, RSET)
      • Invalid Control Field
      • Data Field Too Long
      • Data field not allowed with received Frame Type
      • Invalid Receive Count
    • Miscellaneous (XID, TEST)
    Link Configurations
    Link configurations can be categorized as being either:
    • Unbalanced, which consists of one primary terminal, and one or more secondary terminals.
    • Balanced, which consists of two peer terminals.
    The three link configurations are:
    • Normal Response Mode (NRM) is an unbalanced configuration in which only the primary terminal may initiate data transfer. The secondary terminal transmits data only in response to commands from the primary terminal. The primary terminal polls the secondary terminal(s) to determine whether they have data to transmit, and then selects one to transmit.
    • Asynchronous Response Mode (ARM) is an unbalanced configuration in which secondary terminals may transmit without permission from the primary terminal. However, the primary terminal still retains responsibility for line initialization, error recovery, and logical disconnect.
    • Asynchronous Balanced Mode (ABM) is a balanced configuration in which either station may initiate the transmission.
    An additional link configuration is Disconnected mode. This is the mode that a secondary station is in before it is initialized by the primary, or when it is explicitly disconnected. In this mode, the secondary responds to almost every frame other than a mode set command with a "Disconnected mode" response. The purpose of this mode is to allow the primary to reliably detect a secondary being powered off or otherwise reset..
    HDLC Command and response repertoire
    • Commands (I, RR, RNR, (SNRM or SARM or SABM), DISC)
    • Responses (I, RR, RNR, UA, DM, FRMR)
    Basic Operations
    • Initialization can be requested by either side. When the six-mode set-command is issued. This command:
      • Signals the other side that initialization is requested
      • Specifies the mode, NRM, ABM, ARM
      • Specifies whether 3 or 7 bit sequence numbers are in use.
    The HDLC module on the other end transmits (UA) frame when the request is accepted. And if the request is rejected it sends (DM) disconnect mode frame.
    Functional Extensions (Options)
    • For Switched Circuits
      • Commands: ADD – XID
      • Responses: ADD – XID, RD
    • For 2-way Simultaneous commands & responses are ADD – REJ
    • For Single Frame Retransmission commands & responses: ADD – SREJ
    • For Information Commands & Responses: ADD – Ul
    • For Initialization
      • Commands: ADD – SIM
      • Responses: ADD – RIM
    • For Group Polling
      • Commands: ADD – UP
    • Extended Addressing
    • Delete Response I Frames
    • Delete Command I Frames
    • Extended Numbering
    • For Mode Reset (ABM only) Commands are: ADD – RSET
    • Data Link Test Commands & Responses are: ADD – TEST
    • Request Disconnect. Responses are ADD – RD
    • 32-bit FCS
    HDLC Command/Response Repertoire
    Type Of Frame
    Name
    Command/
    Response
    Description
    Info
    C-Field Format
    7
    6
    5
    4
    3
    2
    1
    0
    Information(I)

    C/R
    User exchange data

    N(R)
    P/F
    N(S)
    0
    Supervisory (S)
    Receive Ready (RR)
    C/R
    Positive Acknowledgement
    Ready to receive I-frame N(R)
    N(R)
    P/F
    0
    0
    0
    1

    Receive Not Ready (RNR)
    C/R
    Positive Acknowledgement
    Not ready to receive
    N(R)
    P/F
    0
    1
    0
    1

    Reject (REJ)
    C/R
    Negative Acknowledgement
    Retransmit starting with N(R)
    N(R)
    P/F
    1
    0
    0
    1

    Selective Reject (SREJ)
    C/R
    Negative Acknowledgement
    Retransmit only N(R)
    N(R)
    P/F
    1
    1
    0
    1
    Unnumbered Frames
    Unnumbered frames are identified by the low two bits being 1. With the P/F flag, that leaves 5 bits as a frame type. Even though fewer than 32 values are in use, some types have different meanings depending on the direction they are sent: as a request or as a response. The relationship between the DISC (disconnect) command and the RD (request disconnect) response seems clear enough, but the reason for making SARM command numerically equal to the DM response is obscure.
    Name
    Command/
    Response
    Description
    Info
    C-Field Format
    7
    6
    5
    4
    3
    2
    1
    0
    Set normal response SNRM
    C
    Set mode
    Use 3 bit sequence number
    1
    0
    0
    P
    0
    0
    1
    1
    Set normal response extended mode SNRME
    C
    Set mode; extended
    Use 7 bit sequence number
    1
    1
    0
    P
    1
    1
    1
    1
    Set asynchronous response SARM
    C
    Set mode
    Use 3 bit sequence number
    0
    0
    0
    P
    1
    1
    1
    1
    Set asynchronous response extended mode SARME
    C
    Set mode; extended
    Use 7 bit sequence number
    0
    1
    0
    P
    1
    1
    1
    1
    Set asynchronous balanced mode SABM
    C
    Set mode
    Use 3 bit sequence number
    0
    0
    1
    P
    1
    1
    1
    1
    Set asynchronous balanced extended mode SABME
    C
    Set mode; extended
    Use 7 bit sequence number
    0
    1
    1
    P
    1
    1
    1
    1
    Set initialization mode SIM
    C
    Initialize link control function in the addressed station
    0
    0
    0
    P
    0
    1
    1
    1
    Disconnect DISC
    C
    Terminate logical link connection
    Future I and S frames return DM
    0
    1
    0
    P
    0
    0
    1
    1
    Unnumbered Acknowledgment UA
    R
    Acknowledge acceptance of one of the set-mode commands.
    0
    1
    1
    F
    0
    0
    1
    1
    Disconnect Mode DM
    R
    Responder in Disconnect Mode
    mode set required
    0
    0
    0
    F
    1
    1
    1
    1
    Request Disconnect RD
    R
    Solicitation for DISC Command

    0
    1
    0
    F
    0
    0
    1
    1
    Request Initialization Mode RIM
    R
    Initialization needed
    Request for SIM command
    0
    0
    0
    F
    0
    1
    1
    1
    Unnumbered Information UI
    C/R
    Unacknowledged data
    has a payload
    0
    0
    0
    P/F
    0
    0
    1
    1
    Unnumbered Poll UP
    C
    Used to solicit control information
    0
    0
    1
    P
    0
    0
    1
    1
    Reset RSET
    C
    Used for recovery
    Resets N(R) but not N(S)
    1
    0
    0
    P
    1
    1
    1
    1
    Exchange Identification XID
    C/R
    Used to Request/Report capabilities
    1
    0
    1
    P/F
    1
    1
    1
    1
    Test TEST
    C/R
    Exchange identical information fields for testing
    1
    1
    1
    P/F
    0
    0
    1
    1
    Frame Reject FRMR
    R
    Report receipt of unacceptable frame
    1
    0
    0
    F
    0
    1
    1
    1
    Nonreserved 0 NR0
    C/R
    Not standardized
    For application use
    0
    0
    0
    P/F
    1
    0
    1
    1
    Nonreserved 1 NR1
    C/R
    Not standardized
    For application use
    1
    0
    0
    P/F
    1
    0
    1
    1
    Nonreserved 2 NR2
    C/R
    Not standardized
    For application use
    0
    1
    0
    P/F
    1
    0
    1
    1
    Nonreserved 3 NR3
    C/R
    Not standardized
    For application use
    1
    1
    0
    P/F
    1
    0
    1
    1
    Configure for test CFGR
    C/R
    Not part of HDLC
    Was part of SDLC
    1
    1
    0
    P/F
    0
    1
    1
    1
    Beacon BCN
    R
    Not part of HDLC
    Was part of SDLC
    1
    1
    1
    F
    1
    1
    1
    1
    The UI, XID and TEST frames contain a payload, and can be used as both commands and responses.
    • A UI frame contains user information, but unlike an I frame it is not acknowledged or retransmitted if lost.
    • The XID frame is used to exchange terminal capabilities. IBM Systems Network Architecture defined one format, but the variant defined in ISO 8885 is more commonly used. A primary advertises its capabilities with an XID command, and a secondary returns an XID response.
    • The TEST frame is simply a ping command for debugging purposes. The payload of the TEST command is returned in the TEST response.
    The FRMR frame contains a payload describing the unacceptable frame. The first 1 or 2 bytes are a copy of the rejected control field, the next 1 or 2 contain the current send and receive sequence numbers, and the following 4 or 5 bits indicate the reason for the rejection.
    See also
    Notes
    1.       
    ·  (Friend 1988, p. 191)
    References
    • Friend, George E.; John L. Fike; H. Charles Baker; John C. Bellamy (1988). Understanding Data Communications (2nd ed.). Indianapolis: Howard W. Sams & Company. ISBN 0-672-27270-9.
    • Stallings, William (2004). Data and Computer Communications (7th ed.). Upper Saddle River: Pearson/Prentice Hall. ISBN 978-0-13-100681-2.
    • S. Tanenbaum, Andrew (2005). Computer Networks (4th ed.). 482,F.I.E., Patparganj, Delhi 110 092: Dorling Kindersley(India)Pvt. Ltd.,licenses of Pearson Education in South Asia. ISBN 81-7758-165-1.
    External links