A network protocol is a standard that allows computers to communicate with each other across some form of link. The protocol needs to define how the computers interact with the network and then how they find the device they want to communicate with. A good protocol should also define how to handle damaged transmissions. IPX, TCP/IP, DECnet, AppleTalk, LAT, X.25, Netware/IPX, and NetBEUI are all well-known examples of network protocols.

We start by looking at how the computer gets on to the network in the first place. The precursor to Ethernet-ALOHA-had the simplest possible scheme for gaining access to a shared medium. When a terminal had something to send, it simply sent it, regardless of what anyone else was doing. If another computer tried to send at the same time, the two messages would collide, both would be corrupted, and everyone would have to back off for a while before starting again. It was only when you received an acknowledgement to your message that you could be sure that it had arrived safely and there had been no collision. Of course, you might have had to wait for the acknowledgment as it, too, could have suffered a collision. This was not an efficient way to control access, so a more sophisticated mechanism was sought.

Enter slotted ALOHA. Now transmissions were constrained to occur in frames, rather than at any time. This meant that collisions only occurred when two terminals chose to transmit in the same frame (rather than when there was any overlap at all between the two transmissions). This simple modification led to a significant improvement in throughput, allowing up to 35% of the channel capacity to be used, compared with a previous peak utilization of less than 20%.

Ethernet interface built on the lessons of ALOHA by enforcing the following regime:

Terminals always listen before they send.

They do not send when someone else is doing so.

When they do send, they limit the amount of data that is transmitted.

If they find themselves sending at the same time as someone else, they back off.

These are much the same set of rules that govern a (polite) telephone conference. The main addition to the ALOHA practice is to listen before sending. If the medium is free, the terminal can transmit immediately. If it is busy, it backs off for a random time before trying again.

Collisions still occur, of course, as it takes a finite time for frames to travel from one point of connection to another. Therefore, two terminals may start to send, both believing the medium to be free, only to find out that someone else has already started to send at the same time.

The fundamental physics of transmission speed have an impact on the range of frame sizes that are specified for use on an Ethernet interface. If two stations are at opposite ends of the network they need to know when the other one is transmitting. If the frame length is too short, then this is compromised. The listening station is unaware that the medium is busy, so it would feel free to send. A collision would then happen close by this station. Meanwhile, the station that had already sent the frame would be blissfully ignorant of what was going on at the other end of the network and would have to wait to find out if there had been a collision.

In order to remove the indeterminacy caused by frames in transit, a minimum frame size is needed. This is equal to twice the propagation time from one end of the network to the other. With multiple sections joined by repeaters, there can be up to 2.5 km between the two end stations. Hence, with signals traveling at a speed of about 2 × 108 m/sec, the “there and back” propagation time is just over 50 ms. At a bit rate of 10 Mbps, this equates to a minimum frame size of 64 bytes.

The mechanism for controlling access described above is known as collision sense multiple access/collision detect (CSMA/CD). It has proved a simple yet effective way of admitting traffic on to the network. Adjusting the back-off time after a collision and the maximum frame size that can be sent both help to ensure fair access and increase the achievable throughput of data across the network. In practice, CSMA/CD Ethernets could cope perfectly well with traffic loads that previously used up to 70% of available bandwidth.

Now that we have a solution to the main problem of accessing shared media, the issue of getting the right connection remains. This is where the address resolution protocol (ARP) for IP comes in handy.

All stations attached to an Ethernet have a physical address-a 48-bit (or 6-byte) identifier known as the hardware or media access control (MAC) address. When user A wants to communicate with user B at another station, it must know both the MAC address and the destination station’s higher level protocol address (i.e., its IP address). To obtain station B’s IP address, user A’s computer composes a packet known as an ARP request, encapsulates this within an Ethernet frame, and “broadcasts” this to all stations on the Ethernet.

Typically, the ARP request contains the destination IP address of the intended host, since this is the most commonly recognized form of identification these days. However, ARP variants have been developed for nearly every protocol operated over Ethernet, including Novell/Netware, AppleTalk, and DECnet.

The hardware location of the addressee is not known to start with, so the hardware address field in the broadcast message is set to zero. The frame containing the ARP request is broadcast to all devices connected to the Ethernet by setting the destination Ethernet address to all ones (FF FF FF FF FF FF). All stations on an Ethernet must listen for and process frames having this broadcast address as the destination MAC address.

When the broadcast frame is received, the station (B) whose upper level address (i.e., its IP address) matches the address encoded in the ARP request is the only one that responds to the broadcasting station. It returns an ARP reply message containing its hardware (MAC) address, which is inserted in the field that was previously set to zero.

When computer A receives and processes the ARP response message, it will maintain association of the logical IP address of the intended recipient with its physical MAC address in what is called an ARP cache. Once this step is complete, IP packets can be sent between the two without further concern; a logical path now exists between the sender and receiver.

Fetch practical knowledge about AVR microcontrollers – make sure to go through this web site. The times have come when proper information is really only one click of your mouse, use this possibility.