Introduction to TCP/IP

Jump to: navigation, search

Table of Contents


Short Background of the Internet

The TCP/IP protocol suite is also known as the "Internet" Protocol Suite since it is used to move data across the Internet. The Internet is a worldwide network of computers located at many different companies, institutions, and government offices. The Internet was started over three decades ago. Realizing the need for a common method to share data and send messages in electronic form, the US Department of Defense (DOD) started the Internet project within the Defense Advanced Research Projects Agency. The first Internet was called ARPANET and started operation in 1968. As more and more researchers joined ARPANET, people started to realize the need for a global network. In 1979, a group called the Internet Control and Configuration Board (ICCB) was founded by ARPA and met to coordinate and structure the architecture of the now growing ARPANET. In 1980, the ARPANET was extended to a global network when the computers that needed network connectivity were outfitted with the TCP/IP protocol suite. In 1983, the MILNET was created to allow military sites to have a separate network from the researchers. Both of these networks (ARPANET for researchers and MILNET for the Military) used TCP/IP for network communication. Now that the military was on its own network, ARPA decided to encourage universities to use the new TCP/IP protocols and utilize the new ARPANET. At most universities at that time, the computer science departments were using the UNIX operating system. ARPA then funded a project to adapt the TCP/IP protocol suite to the BSD (Berkeley Software Distribution) UNIX operating system and provided a low cost means to allow the universities to connect to the ARPANET. The BSD variant of UNIX also had many new tools for the TCP/IP Protocol Suite that was integrated with it. These tools allowed the user to use simple UNIX commands to move files across the network with ease. It was so simple to use that it became popular very quickly. The BSD UNIX also included a new application program interface (API) to allow programmers to access the TCP/IP protocols. This new API was called sockets and allowed the user a uniform way to program network applications without regard to the type of computer that it was running on. This allowed researchers to write new programs and protocols to run on top of the TCP/IP protocol. Since BSD UNIX was so popular within computer science departments, TCP/IP was also used for local area networking. The ARPANET became so popular that in 1986 the National Science Foundation funded the first wide area backbone network called NSFNET.

This new backbone network allowed even more educational institutions to connect to what was now being called the Internet (although the term ARPANET was still being used). Because the National Science Foundation funded NSFNET, universities used it almost exclusively. As commercial sites needed local area connectivity to share files within their company, most of them turned to the IPX/SPX protocols developed by Novell. In fact at one time, Novell was being used by more than 80% of commercial sites using local area networking. As the need for Electronic Mail (e-mail) and wide area networking grew in the commercial sector, companies turned to the Internet and the TCP/IP protocols that it used. New companies were formed to create new commercial backbone networks. One of the first of these was UUNET. Over the past few years, the Internet has exploded onto the commercial scene because of a new way of advertising called web pages. Today, it is difficult to watch television without being bombarded with web page addresses.

What is a Protocol?

The definition of a protocol is "A set of formal rules describing how to transmit data, especially across a network." What are these rules? Well these rules consist of how the packet is formatted, how much data it carries, if and how it can be sure that the remote computer has actually received the data, as well as any additional information that the protocol needs to send to the remote side. In our software, we utilize the TCP/IP (or Internet) protocol suite set of rules. These rules are outlined in loose specifications called Request for Comments (RFC's). An RFC is submitted by anyone who thinks that some change or addition to the Internet protocol suite needs to happen. This proposed RFC is sent to the appropriate working group at the Internet Engineering Task Force (IETF) for comments by others who are involved with that working group. If others in the working group agree with the proposed idea, then they may ask for some changes and adopt the RFC as a "Standards Track" document.

If they reject the idea, then the RFC can still be published as an "Informational" RFC. Standards Track documents describe what the protocol should do in all implementations. Informational RFC's describe what a vendor would like others to implement. There are other types of RFC's, but most are beyond the scope of this document. You can visit the IETF web site at If you are looking for a particular RFC, it is always easier to locate the repository closest to you via a web search engine (such as AltaVista, Infoseek, and Yahoo).

The TCP/IP Protocol Stack

A "stack" architecture divides out the functionality of a data communications capability into several separate layers. Each layer then communicates with its peer layer on remote machine or on the same machine. Rather than tightly coupling the hardware interface with addressing, the stack model identifies a separate interface through which these functions shall cooperate. Figure 1-1 shows a sample of an OSI architecture model. The lower levels of the stack consist of independent protocols that support specific hardware interfaces, transport mechanisms, and so forth while the higher layer protocols are interfaces into the user application code.

7 Application
6 Presentation
5 Session
4 Transport
3 Network
2 Data Link
1 Physical

Fig. 1-1 The OSI Architecture Model

Figure 1-2 shows the TCP/IP model. We have mapped some of the protocols in use with TCP/IP into the OSI reference model. Note that BSD Sockets is at the session layer. BSD Sockets is not a protocol. It is a user API to allow access to the protocol stack beneath.

7 Application Your Application and/or Treck Applications
6 Presentation Host/Network Byte Order Conversion
5 Session RPC
4 Transmission TCP UDP
3 Network IP ICMP ARP
2 Data Link Ethernet PPP SLIP
1 Physical Your Network Hardware

Fig. 1-2 The TCP/IP Model

The TCP/IP stack layers perform the following functions:

Media Access (Physical) Protocols Protocols Specify the mechanisms for client and server nodes on a network to interface to the transmission media.
Data-Link Protocols Specify the control characters and the lowest level mechanisms for transmitting packets of data in successive small segments (called frames) between nodes.
Network Protocols Means by which packets of data are routed through the network from sender to receiver. This level is more concerned with the path the packets take not the content of those packets.
Transport Protocols Assume responsibility for the delivering of a potentially large message from the sending application on one network to the receiving destination.
Session Protocols Responsible for negotiating parameters for the link (i.e. which layer 3 protocol to use).
Presentation Protocols Responsible for making sure that data is viewed the same on both ends of the communication. Can also be used for encryption and compression.
Application Protocols In the original TCP/IP stack, the network layer consisted of the Internet Protocol (IP), and the transport layer consisted of the Transport Control Protocol (TCP) for reliable delivery of application messages and User Datagram Protocol for (UDP) for efficient exchange of small packets-primarily for control and administrative purposes.

The Ethernet Protocol

From its inception in 1978 by the Xerox Corporation, Intel Corporation, and Digital Equipment Corporation, Ethernet has become a very popular LAN technology. It has grown to be one of the most widely used methods of packet switching between computers.

The original configuration of Ethernet technology involved setting up a connection between two computers using a coaxial cable. This cable was generally 1/2" diameter and could be up to 500 meters long. (See figure 1-3.)

Fig. 1-3: Cross Section of a Coaxial Cable Used in the Original Ethernet

Fig. 1-3 Cross Section of a Coaxial Cable Used in the Original Ethernet

The cable itself was completely passive. It carried no electrical current. The only active electrical components that made the network function were associated with the computers attached to the network. The connection between a computer and an Ethernet cable required a piece of hardware called a transceiver. Looking at the physical cable, there needed to be a hole in the outer layers for placement of the transceiver. This was commonly referred to as a tap. Usually small metal pins mounted to the transceiver would go through the hole in the cable to provide electrical contacts to the center wire and the braided shield. Some manufactures made "T's" that required the cable to be cut and inserted. Besides the transceiver, there also needed to be a host interface or host adapter that would plug into the computer's bus. This enabled the connection to be made from the computer to the network. The transceiver is a small piece of hardware that was placed adjacent to the ether. It contains digital circuitry that allows it communicate with a digital computer. The transceiver can sense if the ether is in use and can translate analog signals to and from digital form. The cable that connects the transceiver and the host adapter is called the Attachment Unit Interface (AUI). This cable contains many wires. These wires carry electrical current needed to operate the transceiver, the signals that control the transceiver operation, and the contents of the packet being sent or received. (See fig. 1-4.)

Fig. 1-4: Host to Ethernet Connection

Fig. 1-4 Host to Ethernet Connection

The AUI cable connects the host interface and the transceiver. It carries power, signals, and transmitting or receiving packets. Because of several obvious reasons, like a big, hard to bend, bulky wire, and the chance of electrical interference, engineers developed a new method of Ethernet wiring. It is called thin wire Ethernet or thinnet. This cabling system proved to be more flexible, thinner, and less expensive. However, because of using such a thin wire, the cable provided less protection against electrical interference. It could not be placed near powerful electrical equipment, like that found in a factory. It also covers shorter distances and supports fewer computer connections per network than thick Ethernet. On a thin-wire Ethernet network, the costly, bulky transceivers were replaced with digital, high-speed circuits. That enabled direct connection from a computer to the Ethernet. Now instead, the computer contains both the circuitry and the host interface. This is beneficial to manufacturers of small computers and workstations because they can integrate Ethernet hardware into single board computers and mount connectors directly to the back of the computer. This method is also beneficial if many computers occupy a single room. The thinnet cable runs from one computer workstation directly to another. Another computer can be added by simply connecting that computer to another on the thinnet chain. The disadvantage to this is that it enables users to manipulate the ether. If it is disconnected, all the computers in the chain are unable to communicate. However, in most cases the advantages outweigh the disadvantages. This method uses BNC connectors to connect to the Ethernet. This is much simpler that coaxial cable. A BNC connector can be installed easily without the use of any tools. Therefore, a user can connect to the Ethernet without the aid of a technician.

Twisted Pair Ethernet

In the last few years, technology has made advancements that have made it possible to construct an Ethernet that no longer needs electrical shielding of a coaxial cable. This type of Ethernet technology is called twisted pair Ethernet. This technology allows the user to connect to the Ethernet using a pair of conventional unshielded copper wires similar to the wires used to connect telephones. One obvious advantage to this method is reduced cost, but it also protects other computers on the network from a user who disconnects a single computer. Sometimes it is even possible to use existing telephone wiring for the Ethernet. Known technically as 10Base-T, a twisted pair wiring scheme connects each computer on a network using Ethernet hubs. An Ethernet hub is an electronic device that simulates the signals on an Ethernet cable. The physical unit is a small box or hub that usually resides in the wiring closet or telephone room.

Fig. 1-5: Exploded View of Twisted Pair Cable

Fig. 1-5 Exploded View of Twisted Pair Cable

Using this method only allows for a connection to be made between a computer and a hub within 100 meters. A hub requires power, and can be set up for authorized personnel to monitor and control its operation over the network. An Ethernet hub provides the same communication capability as a thin or thick Ethernet. They merely allow for alternative wiring schemes.

As we have discussed, when using a thick Ethernet setup, the connection requires an AUI connection. When using a thin Ethernet setup, the connection requires a BNC connector, and when using a 10Base-T connection, an RJ-45 connector must be used. The connectors resemble a modular telephone plug. Many Ethernet manufacturers provide the option for the user to select which one of the three they want to use. Although only one connector can be used at a time, this allows the user to integrate easily between the three options.

Note Note: Pairs 1 and 2 and pairs 3 and 6 are "twisted". This is done for noise cancellation.

Pin 1 Outgoing Data 1 (+)
Pin 2 Outgoing Data 2 (-)
Pin 3 Incoming Data 1 (+)
Pin 4 No connection
Pin 5 No connection
Pin 6 Incoming Data 2 (-)
Pin 7 No connection
Pin 8 No connection

Fig. 1-6 Pin Assignment of an RJ-45 Connector

Properties of an Ethernet

The Ethernet is a 10 Mbps broadcast bus technology with best-effort delivery semantics and distributed access control. It is a bus because all stations share a single communication channel. However, it is also a broadcast system because all transceivers receive every transmission. It is important to know that all transceivers do not distinguish among transmissions.

A transceiver passes all packets from the cable to the host interface. The host interface then chooses which packets the computer should receive, and filters out all others. It is called a best-effort delivery system because the hardware provides no information to the sender about whether the packet was successfully delivered. With that in mind, if a destination machine happens to be powered down, the packets sent to that machine will be lost without notifying the sender of that fact. Later, we will see how the TCP/IP protocols accommodate best effort delivery systems.

Ethernet has no central authority to grant access; therefore we say that access control is distributed. The Ethernet access scheme is called Carrier Sense Multiple Access with Collision Detect. It is CSMA because multiple machines can access the Ethernet simultaneously and each machine determines whether the ether is idle by sensing if there is a carrier wave present. Before a host interface sends a packet, it listens to the ether to see if a message is already being transmitted. We call this carrier sensing. If there is no transmission sensed, then it begins transmitting. Each transmission is limited in duration, because there is a maximum packet size (which we will discuss later).

Also, the hardware must observe a minimum idle time between transmissions. That means that no single pair of communicating machines can use the network without giving other machines an opportunity for access.

Collision Detect and Recovery

When a transceiver begins transmission, the signal does not reach all parts of the network at the same time. A transmission travels along the cable at approximately 80% the speed of light. It is possible that two machines can sense that the ether is idle and begin transmitting at the same time. When two electrical signals get crossed they become scrambled, such that neither is meaningful. These incidents are called collisions.

The Ethernet makes provisions for this happening. Each transceiver is constantly monitoring the cable while it is transmitting to see if a foreign signal interferes with its transmission. Technically, this monitoring is called collision detect. When a collision is detected, the host interface aborts transmission, and then waits for activity to subside, and then tries to transmit again. Care must be taken however, or the network could wind up with all the transceivers busily trying to transmit resulting in collisions. This is where the Ethernet excels, it uses a binary exponential back-off policy where a sender delays a random time after the first collision, twice as long if a second collision occurs, fours times as long if a third attempt results in a collision, and so on. The logic behind exponential back-off is that in the unlikely event that many stations try to transmit simultaneously, a severe "traffic jam" could occur. In such a jam, there is a very good chance that two stations will choose very similar back-off times, resulting in a high chance for another collision. By doubling the random delay time, the exponential back-off strategy quickly spreads the attempts to retransmit over a reasonably long period of time, therefore resulting in fewer collisions.

Because an Ethernet is a bus with the possibility of collisions, one should not over utilize the Ethernet. 80% utilization is about the maximum any Ethernet should be loaded with. Collision Detect and Recovery When a transceiver begins transmission, the signal does not reach all parts of the network at the same time. A transmission travels along the cable at approximately 80% the speed of light. It is possible that two machines can sense that the ether is idle and begin transmitting at the same time. When two electrical signals get crossed they become scrambled, such that neither is meaningful. These incidents are called collisions.

The Ethernet makes provisions for this happening. Each transceiver is constantly monitoring the cable while it is transmitting to see if a foreign signal interferes with its transmission. Technically, this monitoring is called collision detect. When a collision is detected, the host interface aborts transmission, and then waits for activity to subside, and then tries to transmit again. Care must be taken however, or the network could wind up with all the transceivers busily trying to transmit resulting in collisions. This is where the Ethernet excels, it uses a binary exponential back-off policy where a sender delays a random time after the first collision, twice as long if a second collision occurs, fours times as long if a third attempt results in a collision, and so on. The logic behind exponential back-off is that in the unlikely event that many stations try to transmit simultaneously, a severe "traffic jam" could occur. In such a jam, there is a very good chance that two stations will choose very similar back-off times, resulting in a high chance for another collision. By doubling the random delay time, the exponential back-off strategy quickly spreads the attempts to retransmit over a reasonably long period of time, therefore resulting in fewer collisions.

Because an Ethernet is a bus with the possibility of collisions, one should not over utilize the Ethernet. 80% utilization is about the maximum any Ethernet should be loaded with.

Ethernet Capacity

The standard Ethernet is rated at 10 Mbps. That means that data can be transmitted onto the cable at 10 million bits per second. Although computers can generate data at Ethernet speed, raw network speed should not be thought of as the rate at which two computers can exchange data. Instead, network speed should be thought of as a measure of the network's traffic capacity. Think of a network as a water supply line in a house, and think of packets as the water. A large diameter pipe can carry a large quantity of water, while a small diameter pipe can only carry a small amount of water. So if you have a 1/2" supply line to 20 sinks, chances are that it will not work efficiently if all the sinks are turned on at the same time. However, if you have a 3" supply line to those same 20 sinks, it could easily handle supplying water if those sinks were all turned on at the same time. This is the same way with an Ethernet. For example, a 10Mbps Ethernet can handle a few computers that generate heavy loads or many computers generating light loads.

Ethernet Hardware Addressing

An Ethernet uses a 48-bit addressing scheme. Each computer that attached to an Ethernet network is assigned a unique 48-bit number that is known as its Ethernet Address. To assign an Ethernet address, Ethernet hardware manufacturers request blocks of Ethernet addresses and assign them in sequence as they manufacture Ethernet interface hardware. Therefore, no two hardware interfaces have the same Ethernet address. The first 24 bits in an Ethernet Frame are the manufacturer's ID.

48 bits
Manufacturer ID Sequence Numbers
24 bits 24 bits

Fig. 1-7 Ethernet Addressing Scheme

Usually, the Ethernet address is fixed in machine-readable code on the host interface hardware. Because Ethernet addresses belong to hardware devices, they are sometimes called hardware address or Physical Addresses.

Note Note: Physical addresses are associated with the Ethernet interface hardware; moving the hardware interface to a new machine or replacing a hardware interface that has failed changes that machines physical address.

Knowing that Ethernet physical addresses can change will make it clear why higher levels of the network software are designed to accommodate such changes.

The host interface hardware examines packets and determines which packets should be sent to the host. Remember that each interface receives a copy of every packet, even those addressed to other machines. The host interface uses the destination address field in the packet as a filter. The interface ignores those packets that are addressed to other machines, and passes to the host only those packets addressed to it. The addressing mechanism and the hardware filter are needed to prevent the computer from becoming overwhelmed with incoming data. Although the computer's CPU could perform the check, doing so in the host interface keeps the traffic on the Ethernet from slowing down processing on all computers.

A 48-bit Ethernet address can do more than specify a single destination computer. An address can be one of three types:

  • The physical address of one network interface (a unicast address)
  • The network broadcast address
  • A multicast address

We typically write the Ethernet address in Hexadecimal.

For example: 0x0ce134121978

By convention, the broadcast address (all 1's) is reserved for sending to all stations simultaneously.

48 bits
11111111 11111111 11111111 11111111 11111111 11111111

or in hexadecimal:

48 bits

Fig. 1-8 Broadcast Address

Multicast addresses provide a limited form of broadcast in which a subset of the computers on the network agree to listen to a given multicast address. This set of computers is called a multicast group. To join a multicast group, the computer must instruct its host interface to accept the group's multicast address. The advantage of multicasting lies in the ability to limit broadcasts. Every computer in a multicast group can be reached with a single packet transmission. Computers that choose not to participate in a particular multicast group do not receive packets sent to the group. To accommodate broadcast and multicast addressing, Ethernet interface hardware must recognize more than its physical address. A host interface usually accepts at least two kinds of packets: those addressed to the interface's physical address, and those addressed to the network broadcast address. Some interfaces can be programmed to recognize multicast addresses or even alternate physical addresses. When the operating system starts, it initializes the Ethernet interface, giving it a set of addresses to recognize. The interface then examines the destination address field in each packet, passing on to the host only those transmissions designated for one of the specified addresses.

Special Bits of an Ethernet Address

Under universally administrated addressing, a unique address is embedded in ROM on each network interface. The first three bytes of the 48-bit address identify the manufacturer of the adapter; the remaining bits identify the adapter card number. Under locally administrated addressing, the user is responsible for configuring the source address of each workstation.

0 8 16 24
Hardware Type Protocol Type
Hardware Address Length Protocol Address Length Operation
Sender Hardware Address (Bytes 0-3)
Sender Hardware Address (Bytes 4-5) Sender IP Address (Bytes 0-1)
Sender IP Address (Bytes 2-3) Target Hardware Address (Bytes 0-1)
Target Hardware Address (Bytes 2-5)
Target IP Address (Bytes 0-3)

Fig. 1-9 Ethernet and IEEE 802.3 Source/Destination Address Fields

Obtaining an Ethernet Address Block

To obtain an Ethernet address block for your company, you need to contact IEEE Standards or visit their website at This will provide information on getting a Company ID/OUI.

Ethernet Frame Format

The Ethernet should be thought of as a link-level connection among machines. Thus, it makes sense to view the data transmitted as a frame. The term frame originated from communication over serial lines in which the sender frames the data by adding special characters before and after the transmitted data. Ethernet frames are variable lengths, with no frame smaller than 64 bytes or larger than 1518 bytes (header, data, and CRC). As in all packet switched networks, each Ethernet frame includes a field that contains the address of its destination. Figure 1-10 shows that the Ethernet frame format contains the physical source address as well as the destination address.

Preamble Destination Address Source Address Frame Type Frame Data CRC
8 bytes 6 bytes 6 bytes 2 bytes 46-1500 bytes 4 bytes

Fig. 1-10 Ethernet Frame Format

In addition to identifying the source and destination, each frame transmitted across the Ethernet contains a preamble, type field, data field, and Cyclic Redundancy Check (CRC). The preamble consists of 64 bits of alternating 0's and 1's to help receiving nodes synchronize. The 32-bit CRC helps the interface detect the transmission errors. The sender computes the CRC as a function of the data in the frame, and the receiver recomputes the CRC to verify that the packet has been received intact.

The frame type field contains a 16-bit integer that identifies the type of data being carried in the frame. From the Internet point of view, the frame type field is essential because it means that Ethernet frames are self-identifying. When a frame arrives at a given machine, the operating system uses the frame type to determine which protocol software module should process the frame. The chief advantage of self-identifying frames is that they allow multiple protocols to be intermixed on the same physical network without interference. For example, one frame could have an application program using Internet protocols while another is used for local experimental protocol. The operating system uses the type field of an arriving frame to decide how to process the contents. We will see that TCP/IP uses self-identifying Ethernet frames to distinguish among several protocols.

The Address Resolution Protocol (ARP)

The Address Resolution Protocol (ARP) is a low-level protocol used to bind addresses dynamically. To better understand this concept, look at Figure 1-11. This shows that the host (H) wants to know a machines IP address (B). To resolve this, host (H) broadcasts a special packet that asks the host with a specific IP address to respond with its physical address. All hosts receive the request, but only (B) recognizes its IP address and sends a reply that contains its physical address. When host (H) receives the reply from host (B), it uses its physical address to send the Internet packet directly to (B).

Fig. 1-11: ARP Transmission Sequence

Fig. 1-11 ARP Transmission Sequence

When a host makes a broadcast to all the machines on a network, it makes every machine on the network process the broadcast data. This can be very costly and time consuming. To reduce communication costs and time, machines that ARP maintains a cache of recently acquired IP-to-physical address bindings so they do not have to use ARP repeatedly. Whenever a computer receives an ARP reply, it saves the senders IP address and corresponding hardware address in its cache for successive lookups. When transmitting a packet, a computer always looks in its cache for a binding before sending an ARP request. If a computer finds the desired binding in its ARP cache, it need not send a broadcast on the network. Experience shows that because most network communication involves more than one packet transfer, even a small cache is beneficial.

There are several important points to remember about ARP. First, notice that when one machine is about to use ARP (because it needs to send information to another machine), there is a high probability that the second machine will need to communicate with the first machine in the near future. To anticipate the need of the second machine, and to reduce network traffic, the first machine sends its IP-to-physical address binding when sending a request to that machine. That machine then extracts the first machine's binding from the request and saves that information in its ARP cache. It then sends a reply to the first machine. Because the first machine broadcasts its initial request, all machines on the network receive it and can extract the IP-to-physical address and store it their cache. This saves time in future transmissions. When a computer has its host interface replaced (e.g., because the hardware has failed) its physical address changes. Other computers on the network that have stored a binding in their ARP cache must be notified of the change. A system can notify others of a new address by sending an ARP broadcast when it boots.

To summarize, remember: The sender's IP-to-physical address binding is included in every ARP broadcast; receivers update the IP-to-physical address binding information in their cache before processing an ARP packet.

ARP is a low-level protocol that hides the underlying network physical addressing, permitting one to assign an arbitrary IP address to every machine. We think of ARP as a part of the physical network system and not as a part of the Internet protocols.

ARP Implementation

Functionally, ARP is divided into two parts. The first part maps an IP address to a physical address when sending a packet. The second part answers requests from other machines. Address resolution for outgoing packets may seem to be pretty straightforward, but some small details can complicate an implementation. When given a destination IP address, the software consults its ARP cache to see if it knows the mapping from IP address to physical address. If it does, the software extracts the physical address, places the data in a frame using that address, and transmits the frame. If it does not know the mapping, then the software must broadcast an ARP request and wait for a reply.

Many things can happen to complicate an address mapping. The target machine can be down, or just too busy to accept the request. If so, the sender may not receive a reply, or the reply may be delayed. Because an Ethernet is best-effort delivery system, the initial ARP broadcast can also be lost (if this happens, then the sender should retransmit, at least once). Meanwhile, the sender must store the original outgoing packet so that it can be sent once the address has been resolved. In fact, the host must decide whether to allow other application programs to proceed while it processes an ARP request.

The second part of the ARP code handles ARP packets that arrive from the network. When an ARP packet arrives, the software first extracts the sender's IP address and hardware address pair, and examines the local cache to see if it already has an entry for that sender. If the cache entry exists for the given IP address, the handler updates that entry by overwriting the physical address with the physical address obtained from the packet. The receiver then processes the rest of the ARP packet. It is important to understand this, for reference to the next section.

ARP Encapsulation and Identification

Before we continue, it is important to know just what encapsulation is. Encapsulation is treating a collection of structured information as a whole without affecting, or taking notice of its internal structure. This means that we can take any information, and essentially put it in between pertinent information. There are guidelines to follow that dictate the format of encapsulation. Keeping that in mind, when ARP messages travel from one machine to another, they must be carried in physical frames.

Fig. 1-12: ARP Message Encapsulated in a Physical Network Frame

Fig. 1-12 ARP Message Encapsulated in a Physical Network Frame

To identify the frame as carrying an ARP message, the sender assigns a special value to the type field in the frame header and places the ARP message in the frames data field. When a frame arrives at a computer, the network software uses the frame type to determine its contents. In most technologies, a single type value is used for all frames that carry an ARP message. Network software in the receiver must then further examine the ARP message to distinguish between ARP requests and ARP replies.

ARP Protocol Format

Unlike most protocols, the data in ARP packets does not have a fixed format header. Instead to make ARP useful for a variety of network technologies, the length of fields that contain addresses depend on the type of network. To make it possible to interpret an arbitrary ARP message, the header includes the fixed fields near the beginning that specify the lengths of the addresses found in the succeeding fields. In fact, the ARP message format is general enough to allow it to be used with arbitrary physical addresses and arbitrary protocol addresses. Fig. 1.13 shows an ARP message with 4 bytes per line.

0 8 16 24
Hardware Type Protocol Type
Hardware Address Length Protocol Address Length Operation
Sender Hardware Address (Bytes 0-3)
Sender Hardware Address (Bytes 4-5) Sender IP Address (Bytes 0-1)
Sender IP Address (Bytes 2-3) Target Hardware Address (Bytes 0-1)
Target Hardware Address (Bytes 2-5)
Target IP Address (Bytes 0-3)

Fig. 1-13 Example of ARP Format when Used for IP-to-Ethernet Address Resolution

The length fields depend on the hardware and protocol address lengths, which are 6 bytes for an Ethernet address and 4 bytes for an IP address.

Hardware Type Specifies a hardware interface type for which the sender seeks an answer. Contains a value of 1 for Ethernet.
Protocol Type Specifies the type of high-level protocol address the sender has supplied. It contains 0800 for IP addresses.
Operation Specifies an ARP Request (1), ARP Response (2), Reverse ARP (RARP) Request (3), or RARP Response (4).
Hardware Address Length Specifies the length of the hardware address.
Protocol Address Length Specifies the length of the high-level protocol address.
Sender Hardware Address Specifies the sender's hardware address if known.
Sender IP Address Specifies the sender's Internet Protocol address if known.
Target Hardware Address When making a request specifies the sender's hardware address.
Target IP Address When making a request specifies the sender's IP address.

Unfortunately, the variable length fields in ARP packets do not align neatly on 32-bit boundaries, making Figure 1-13 difficult to read. For example, the sender's hardware address, labeled Sender Hardware Address, occupies 6 contiguous bytes, so it spans two lines in the diagram. Field Hardware Type specifies a hardware interface type for which the sender seeks an answer; it contains the value 1 for Ethernet. Similarly, field Protocol Type specifies the type of high-level protocol address the sender has supplied; it contains 0800 for IP addresses. Field Operation specifies an ARP request or ARP response. Fields Hardware Address Length and Protocol Address Length allow ARP to be used with arbitrary networks because they specify the length of the hardware address and the length of the high-level protocol address. The sender supplies its hardware address and IP address, if known, in the fields Sender Hardware Address and Sender IP Address.

When making a request, the sender also supplies the target IP address or target hardware address using fields Target Hardware Address and Target IP Address. Before the target machine responds, it fills in the missing addresses, swaps the target and sender pairs, and changes the operation to a reply. Therefore a reply carries the IP and hardware addresses of the original requester, as well as the IP and hardware addresses of the machine for which a binding was sought.

Big Endian/Little Endian

To create an Internet that is independent of any particular vendor's machine architecture or network hardware, the software must define a standard representation for data. To illustrate that point, consider what happens when software on one computer sends a 32-bit binary integer to another computer. The physical transport hardware moves the sequence of bits from the first machine to the second without changing the order. However, not all machines store 32 and/or 16-bit integers in the same way. On some machines, referred to as Little Endian, the lowest memory address contains the low-order byte of the integer. On others, referred to as Big Endian, the lowest memory address holds the high-order byte of the integer. Thus, direct copying of bytes from one machine to another may change the value of the number. Standardizing byte-order for integers is especially important in an Internet because Internet packets carry binary numbers that specify information like destination addresses and packet lengths. Both the senders and receivers must understand such quantities. The TCP/IP protocols solve the byte-order problem by defining a network standard byte order that all machines must use for binary fields in Internet packets. Each host converts numeric items from the host specific order to network standard byte order before sending a packet, and converts from network byte order to the host-specific order when a packet arrives. Naturally, the user data field in a packet is exempt from this standard - users are free to format their own data however they choose. Of course, most application programs use the Big Endian format as well. This is why we transfer packets using the Big Endian method. The Internet standard for byte order specifies that the most significant byte is sent first (i.e. Big Endian style). If one considers the successive bytes in a packet as it travels from one machine to another, a binary integer in that packet has its most significant byte nearest the beginning of the packet and its least significant byte nearest the end of the packet. Motorola processors are typically Big Endian types, while Intel processors are typically Little Endian types. We transfer packets using the Big Endian format.

Short Integer 16 Bits
Long Integer 32Bits

12 34 56 78

Fig. 1-14 Difference between Big Endian & Little Endian

MSB = Most Significant Byte
LSB = Least Significant Byte

To illustrate the difference between Big Endian and Little Endian, look at Figure 1-15. If we store the number 0x12345678 at memory location 2000 it would look like this:

Memory Location Big Endian Little Endian
2000 12 78
2001 34 56
2002 56 34
2003 78 12

Fig. 1-15 Example of a Number Stored in a Big and Little Endian Processor

The Point to Point Protocol (PPP)

PPP or Point-to-Point protocol is designed to transport datagrams from multiple protocols over point-to-point links in a dynamically changing network. As a result, the design of PPP addresses has three areas of functionality:

Encapsulation How PPP nests within the stack of protocols that make up the entire communications environment in a network.
Link Control Protocol How PPP establishes, configures, and monitors the data-link connection.
Network Control Protocols How PPP interacts with a variety of network-layer protocols, including IP.

PPP requires that both sides negotiate a link for what they both will accept and how the link will operate. Characteristics such as the maximum size of the datagram that a given peer will accept, the authentication protocol (if any) that should be applied to datagrams originating from that sender, and compression schemes are all open to negotiations between the two systems being linked via PPP. This negotiation takes the form of a series of packet exchanges until both systems have agreed to the parameters under which the link will operate.

PPP is intended for use in simple links that transport datagrams between two peers. PPP supports full-duplex lines with simultaneous bi-directional traffic. Unlike some link-level protocols, PPP assumes that datagrams arrive in the order they were sent. Within this limitation, PPP offers an easy connection protocol between hosts, bridges, routers, and client computers. Previously SLIP was the preferred protocol for dial-up links. Now however, PPP is almost exclusively used for dial-up links because of its flexibility. In particular, the link-testing features of PPP enable more detailed transfer of graphics, binary files, and World Wide Web pages to and from PC's and the public Internet or private Intranets.

Link Control Protocol

When we use PPP the first thing we need to use is LCP or Link Control Protocol. LCP sends a packet, or a configuration request. A configuration request establishes what specifics it needs for this request. Both sides of a connection go through the same procedures. Sometimes, one side will wait for the other side; sometimes both machines will transmit this information simultaneously. The configuration request is simply a packet that specifies certain information about how it is going to utilize the link. If we were to look at a sample frame format it would look similar to this:

Code Identifier Total Length Option Length Value ...
1 Byte 1 Byte 2 Bytes 1 Byte 1 Byte Variable

Fig. 1-16 Sample Configuration Request Format

This frame could be variable length depending on the number of options that are requested.

PPP Encapsulation

PPP allows the peers on a given link to establish the encapsulation to be used for datagrams. Frames transmitted via PPP have three fields as shown in Figure 1-17.

Protocol Information Padding (optional)

Fig. 1-17 PPP Encapsulation

The fields in a PPP frame are used as follows:

Protocol Field Establishes the network protocol that sent that datagram and with regard to which it should be interpreted.
Information Field The packet received from the network-level protocol to be transmitted over the physical medium under the control of the PPP.
Padding Establishes the network protocol that sent that datagram and with regard to which it should be interpreted.

The Protocol Field

By default, the protocol field is two bytes in length. But, it may optionally shorten to one byte if both peers agree. It is transmitted in Big Endian (most significant byte first). Notice that in the protocol values in the following table, the first byte is always even and the second byte is always odd. The reason for this is field compression.

Protocol field values are defined in RFC 1700, "Assigned Numbers." The following values (given in hexadecimal) are of special interest when PPP is used along with TCP and IP:

0021 Internet Protocol
002d Van Jacobson Compressed TCP/IP
002f Van Jacobson Uncompressed TCP/IP
8021 Internet Protocol Control Protocol
c021 Link Control Protocol
c023 Password Authentication Protocol
c025 Link Quality Report
c223 Challenge Handshake Authentication Protocol
0000-02ff Network Layer Protocols
8000-bfff Network Control Protocols
c000-ffff Link-Layer Control Protocols

Fig. 1-18 Protocol Field Values

The Information Field

The information field contains the packet sent down by the network level. As is usual in stacked protocols, PPP encapsulates the packet without interpreting it. Unless otherwise established by peer - to - peer negotiation, the default Maximum Receive Unit length for the information field is 1500 bytes including any padding but excluding the Protocol field.

The Padding Field

The padding field supports protocols and equipment that prefer (or require) that the overall packet length be extended to a 32-bit boundary or be otherwise fixed. Its use is not mandatory except as implied by configuration options negotiated between the peers in the link.

PPP Link Operation

Before user information can be sent across a point-to-point link, each of the two endpoint systems comprising the desired link must test the link and negotiate how the link will be configured and maintained.

These functions are performed using the Link Control Protocol. The PPP software on each peer (endpoint) system creates packets for this purpose, framed with the standard PPP protocol field. Once the link has been established, each peer authenticates the other if so requested. Finally, PPP must send Network Control Protocol packets to negotiate the network-layer protocol(s) that will be supported in this link.

Once the link has been established and both peers have agreed to support a given network-layer protocol on this link, datagrams from that network-layer protocol may be sent over the link.

The link will remain available for communications until it is explicitly closed. This can happen at the LCP or NCP level, either by administrator intervention or through a time-out interrupt. Specific network-layer protocols can be enabled and disabled on the link at any time without affecting the capability of the PPP link to support other network-layer protocol transmissions.

Understanding IP Addresses

This section describes the underlying concepts if IP addresses. We will discuss the format of an IP address, the concepts of a sub-netting and super-netting, and why we use them. Let's first look at basic IP address formatting.

IP Address Format

IP addresses are a standard 32 bits long. Figure 1-19 shows the format of an IP address:

Fig. 1-19 Sample IP Address Format

The class field can be defined by the first three numbers of the IP address. In our example, the number would be 1. There are three types of classes. They are Class A, Class B, and Class C. Think of an Internet as a large network like any other physical network. The difference is that the Internet is a virtual structure that is implemented entirely in software. This allows the designers to choose packet formats and sizes, addresses, delivery techniques, and so on. Nothing is dictated by hardware. For addresses, designers of TCP/IP chose a scheme similar to physical network addressing in which each host on the Internet is assigned a 32-bit integer address, called its IP Address. The clever part of IP addressing is that the integers are carefully chosen to make routing efficient. An IP address encodes the identification of the network to which a host attaches as well as the identification of a unique host on that network.

We can follow some guidelines to break this up and analyze the format for following the rules of IP addressing:

Class Network Host

Each address is a pair: both network and host on that network. Given an IP address, its class can be determined from the three high-order bits, with two bits being sufficient to distinguish among the three primary classes. Class A addresses, which are used for a small amount of networks that have more than 65,536 hosts, devote 7 bits to network and 24 bits to the host. Class B addresses, which are used for intermediate size networks that have between 256 and 65,536 hosts, allocate 14 bits to the network and 16 bits to the host. Class C addresses, which are used for networks with less than 256 hosts, allocate 21 bits to the network and only 8 bits to the host. Note that the IP address has been defined in such a way that it is possible to extract the host or network portions quickly. Routers, which use the network portion of an address when deciding where to send a packet, depend on efficient extraction to achieve high speed.

Network and Broadcast Addresses

We have already said that the major advantage of encoding network information in Internet addresses is that it makes efficient routing possible. Another advantage is that Internet addresses can refer to networks as well as hosts. By convention, host 0 is never assigned to an individual host. Instead, an IP address with host 0 is used to refer to the network itself.

Another significant advantage of the Internet addressing scheme is that it includes a broadcast address that refers to all hosts on the network. According to the standard, any host containing all 1's is reserved for broadcast. On many network technologies, broadcasting can be as efficient as normal transmission; on others, broadcasting is supported by the network software, but requires substantially more delay than a single transmission. Some networks do not support broadcast at all. Therefore, having an IP address does not guarantee the availability or efficiency of broadcast delivery.

Limited Broadcast

Technically, the broadcast address we just described is called a directed broadcast address because it contains both a valid network ID and the broadcast host ID. A directed broadcast can be interpreted unambiguously at any point on the Internet because it uniquely identifies the target network in addition to specifying broadcasts on that network. Directed broadcast addresses provide a powerful (and somewhat dangerous) mechanism that allows a remote system to send a single packet that will be broadcast on the specified network.

From an addressing point of view, the chief disadvantage of directed broadcast is that it requires knowledge of the network address. A limited broadcast address provides a broadcast address for the local network independent of the assigned IP address. The local broadcast address consists of 32 1's (it is sometimes called the all 1's broadcast address). A host may use the limited broadcast address as part of a start-up procedure before it learns its IP address or the IP address for the local network. Once the host learns the correct IP address for the local network, it should use the directed broadcast. As a general rule, TCP/IP protocols restrict broadcasting to the smallest possible set of machines.

Drawbacks in Internet Addressing

Encoding network information in an Internet address does have some disadvantages. The most obvious disadvantage is that addresses refer to network connections, not to the host computer. Another weakness of the Internet addressing scheme is that when any Class C network grows to more than 255 hosts, it must have its address changed to a Class B address.

Note Note: If a host computer moves from one network to another, its IP address must change.

Dotted Decimal Notation

When communicating to humans, in either technical documents or through application programs, IP addresses are written as four decimal integers separated by decimal points. Each integer gives the value of one byte of the IP address. For example:

10000000 00001010 00000010 00011110

is written:

When we express IP addresses, we will use dotted decimal notation. This table summarizes the range of values for each class of IP addresses:

Class Lowest Address Highest Address

Fig. 1-20 IP Address Denotations

Loopback Address

In Figure 1-20 we see that not all-possible addresses have been assigned to classes. For example, address, a value from the class A range, is reserved for loopback; and is intended for use in testing TCP/IP and for inter-process communication on the local machine. When any program uses the loopback address for the destination, the computer returns the data without sending the traffic across any network. A host or router should never propagate routing or reachability information for network number 127; it is not a network address.

Special Address Conventions

In practice, IP uses only a few combinations of 0's or 1's.

Fig. 1-21: Special Forms of IP Addresses

Fig. 1-21 Special Forms of IP Addresses.

1Allowed only at system startup and is never a valid destination address.
2Never a valid source address.
3Never a valid source address.
4Never a valid source address.
5Should never appear on a network.

IP Addressing Format

Let's look at the physical setup of an IP address. If we have an IP address number of:



This number represents the address of a particular machine on a network. This is that machines personal "identification" number. Each machine on that network will have the same first three numbers. For example, a machine with the address:, would still be on the same network and would still be a class C address. However, this would denote a different machine.

Note Note: When an IP address ends in 0, it denotes the physical network, or wire. For Example:


Netmasking allows the grouping together and breaking-up of IP address space. To illustrate this point lets look at the format of IP addressing in binary:

11010000 11100101 11001001 01000010

Fig. 1-22 Standard IP Address in Binary

110 10000 11100101 11001001 01000010

Fig. 1-23 Class Identifying Digits for an IP Address (i.e. Class A, B, or C)

If we were to set up a netmask, we would essentially be creating an "overlay" for an IP address. It would look similar to this (in binary):

11111111 11111111 11111111 00000000
Network Host

Fig. 1-24 Sample Netmask

11010000 11100101 11001001 01000010
11111111 11111111 11111111 00000000
Network Host

Fig. 1-25 Netmasking Example

The all 1's side represents the network side. The all 0's side represents the host side. If you were to take this netmask and "overlay" it on the IP address format like Fig. 1.25, you can see that the default "line" between the network and the host falls between the third and fourth number.

Note Note: Every machine on a network wire must agree on the value of the netmask. The values must be identical for the netmask to operate correctly.

Reserved Addresses

In a netmask, there are guidelines that must be followed for correct setup with no errors. The most important thing to remember is this:

If the host or network portion of the IP Address (after applying the netmask) is all 1's or 0's, it cannot be assigned as a machine's IP address. Any combination of numbers that translate into binary as being all 1's or 0's also cannot be used. Depending on where the netmask is setup, the reserved numbers will change. For example:

192 0 0 X
128 0 X X
127 X X X
0 X X X

Fig. 1-26 Reserved Addresses

In these examples the network portion of the IP address is 0, except for 127.X.X.X which is reserved for loopback. In the next section, we will see how we can "change" the position of the bits in the network section of the netmask to manipulate our network for our personal needs.

Sub-Netting & Super-Netting

Let's look at an example to explain the use of sub-netting and super-netting. Suppose that we have applied for an IP address, and we received a class C address. In our business, we have 20 machines in the shipping department, 20 machines in the engineering department, and 50 machines in the clerical department. We want all those machines to be able to access the network independently based on their departments. Instead of applying for 3 separate class C addresses, we can manipulate our current class C address to accommodate our needs. We know that we have 254 physical addresses available, but because we do not want them all on the same physical network, we need to find an alternative way to use our current address. What we need to do is essentially "break-up" our current address. We do this by what is referred to as sub-netting. We know that in the structure of an IP address anything that is a 1 (in binary), is referenced as the network, and anything that is a 0 is referenced as the host. We can restructure the netmask to move where the division is between the network portion and the host portion.

IP Address 208 229 201 0
Netmask 11111111 11111111 11111111 00000000
Hexidecimal FF FF FF 00

IP Address 208 229 201 0
Netmask 11111111 11111111 11111111 11000000
Hexidecimal FF FF FF C0

Fig. 1-27 Illustration of Sub-Netting

In the first chart of Figure 1-27, we see the default setup for a class C netmask. We see the result of sub-netting in the second chart of Figure 1-27. We have essentially changed the location of the bar between the third and fourth integers of our IP address. We changed the location by changing the value of the netmask from:

FF FF FF 00 to FF FF FF C0

Notice that we have changed the first two bits of the last byte to represent the network address. In order to achieve super-netting the same procedure is followed with the exception that we move the bar between the third and fourth bytes to the left instead of to the right. It allows us to group several class X addresses together to be one network address.

The Internet Protocol (IP)

By concept, a TCP/IP Internet provides three sets of services as shown in Figure 1-28; by the way they are arranged in the figure, we can see that there seems to be a dependency among them.

Application Services
Reliable Transport Service
Connectionless Packet Delivery Service

Fig. 1-28 Three Conceptual Layers of Internet Services

At the lowest level, a connectionless delivery service provides a foundation on which everything rests. At the next level, a reliable transport service provides a higher-level platform on which applications depend. We will explore these services in more detail to see what each one provides and which protocols are associated with them.

Connectionless Packet Delivery Service

The most fundamental Internet service consists of a packet delivery system. Technically, the service is defined as an unreliable, best effort connectionless packet delivery system; similar to the service provided by network hardware that operates on a best-effort delivery pattern. The service is called unreliable because delivery is not guaranteed. The packet may be lost, duplicated, delayed, or delivered out of order. The service will not detect such conditions, nor will it inform the sender or receiver. The service is called connectionless because each packet is treated independently from all others. A sequence of packets sent from one computer to another may travel over different paths, or some may be lost while others are delivered. Finally, the service is referred to as best-effort delivery because the Internet software makes an earnest attempt to deliver packets. That is, the Internet does not discard packets arbitrarily. Unreliability arises only when resources are exhausted or underlying networks fail.

Purpose of the Internet Protocol

The protocol that defines the unreliable, connectionless delivery mechanism is called the Internet Protocol and is usually referred to by its initials IP. IP provides three important definitions. First, the IP protocol defines the basic unit of data transfer used throughout a TCP/IP Internet. Thus, it specifies the exact format of all data as it passes across a TCP/IP Internet. Second, IP software performs the routing function, choosing a path over which data will be sent. Third, in addition to the precise, formal specification of data formats and routing, IP includes a set of rules that embody the idea of unreliable packet delivery. The rules characterize how hosts and routers should process packets, how and when error messages should be generated, and the conditions under which packets can be discarded. IP is such a fundamental part of the design that a TCP/IP Internet is sometimes called an IP-based technology. IP is designed for routing traffic between networks, or across a network of networks. An application running on a client machine generates messages or data to be sent to a machine located on another network. IP receives these messages from the transport layer software residing on a server that provides a gateway from the LAN (Local Area Network) or WAN (World Area Network) onto the Internet (or other TCP/IP network). Not all terminals on the network are end-user machines or gateways to LANs and WANs. Some terminals are devoted to routing packets along various potential pathways from the sending terminal to the receiving terminal.

The Internet Datagram

On a physical network, the unit of transfer is a frame that contains a header and data, where the header gives information such as the (physical) source and destination addresses. The Internet calls its basic transfer unit an Internet datagram, sometimes referred to as an IP datagram or merely a datagram. Like a typical physical network frame, a datagram is divided into header and data areas. Also like a frame, the datagram header contains the source and destination addresses and a field type that identifies the contents of the datagram. The difference is that the datagram header contains IP addresses whereas the frame header contains physical addresses.

Datagram Header Datagram Data Area

Fig. 1-29 General form of an IP datagram

IP specifies the header format including the source and destination IP addresses. IP does not specify the format of the data area; it can be used to transport arbitrary data.

Datagram Format

Now that we have described the general layout of an IP datagram, we can look at the contents in more detail. Figure 1-30 shows the arrangement fields in a datagram:

0 4 8 12 16 20 24 28
VER HLEN TOS Total Length
Identification FLG Fragment Offset
TTL Protocol Header Checksum
Source IP Address
Destination IP Address
IP Options (If Any) Followed by DATA

Fig. 1-30 Internet Datagram Format Basic Unit of Transfer in a TCP/IP Internet

Because datagram processing occurs in software, the contents and format are not restricted by any hardware. For instance, the first 4-bit field in a datagram (VER) contains the version of the IP protocol that was used to create the datagram. It is used to verify that the sender, receiver, and any routers in between them agree on the format of the datagram. All IP software is required to check the version field before processing a datagram to ensure it matches the format the software expects. If standards change, machines will reject datagrams with protocol versions that differ from theirs, preventing them from misinterpreting datagram contents according to an outdated format.

The header length field (HLEN), also 4 bits, gives the datagram header length measured in 32-bit words. As we will see, all fields in the header have fixed length except for IP OPTIONS and corresponding PADDING fields. The most common header, which contains no options or padding, measures 20 bytes and has a header length field equal to 5.

The TOTAL LENGTH field gives the length of the IP datagram measured in bytes, including bytes in the header and data. The size of the data area can be computed by subtracting the length of the header (HLEN) from the TOTAL LENGTH. Because the TOTAL LENGTH field is 16 bits long, the maximum possible size of an IP datagram is 65,535 bytes. It may become more important if future networks can carry data packets larger than 65,535 bytes.

Datagram Type of Service and Datagram Precedence

Informally called Type of Service (TOS), the 8-bit SERVICE TYPE field specifies how the datagram should be handled and is broken down into five subfields.

Three PRECEDENCE bits specify datagram precedence, with values ranging from 0 (normal precedence) through 7 (network control), allowing senders to indicate the importance of each datagram. Although most host and router software ignores type of service, it is an important concept because it provides a mechanism that can allow control information to have precedence over data. For example, if all hosts and routers honor precedence, it is possible to implement congestion control algorithms that are not affected by the by the congestion they are trying to control.

Bits D, T, and R specify the type of transport the datagram desires. When set, the D bit requests low delay, the T bit requests high throughput, and the R bit requests high reliability. Of course, it may not be possible for an Internet to guarantee the type of transport requested (i.e. it could be that no path to the destination has the requested property). Thus, we think of the transport request as a hint to the routing algorithms, not as a demand. If a router knows more than one possible route to a given destination, it can use the type of transport field to select one with characteristics closest to those desired. For example, suppose a router can select between a low capacity leased line and a high bandwidth (but high delay) satellite connection. Datagrams carrying a keystroke from a user to a remote computer could have the D bit set requesting that they be delivered as quickly as possible, while datagrams carrying a bulk file transfer could have the T bit set requesting that they travel across the high capacity satellite path.

Datagram Encapsulation

Before we can understand the next fields in the datagram, it is important to consider how datagrams relate to physical network frames. One question that you may have is "How large can a datagram be?" Unlike physical network frames that must be recognized by hardware, datagrams are handled by software. They can be any length the protocol designers choose. The current datagram format allows for 16 bits to the total length field, limiting the datagram to at most 65,535 bytes.

More fundamental limits on datagram size arise in practice. We know that as datagrams move from one machine to another, the underlying physical network must always transport them. To make internet transportation efficient, we would like to guarantee that each datagram travels in a distinct physical frame.

The idea of carrying one datagram in one network frame is called encapsulation. To the underlying network, a datagram is like any other message sent from one machine to another. The hardware does not recognize the datagram format, nor does it understand the IP destination address. Therefore, when one machine sends an IP datagram to another, the entire datagram travels in the data portion of the network frame.

Understanding Checksums


A checksum allows information to follow a set of guidelines that is pertinent to the correct sending and receiving of data. Checksums are used in several different types of protocols. For example, UDP, TCP, and IP, all use variations of a checksum. A good way to understand the meaning and the use of the checksum is to analyze the format. Look at the chart below; we can see that the format of an IP header provides us with certain information.

VER HLEN TOS Total Length
Identification FLG Fragment Offset
TTL Protocol Header Checksum
Source IP Address
Destination IP Address
IP Options (If Any) Followed by DATA

For our example, we will plug in the following information for each of these fields:

VER (Version) 4
HLEN (Header Length) 5
TOS (Type of Service) 0
Total Length 14
Identification 1
FLG (Flag)/Fragment Offset 0
TTL (Time to Live) 255
Protocol 17 (UDP)
Header Checksum 0
Source IP Address
Destination IP Address

Explanation of Checksums

If you notice, the value for the header checksum equals 0. To begin with, the value for the checksum is always set to zero and then simple addition is done. Now if we take the values in hexadecimal and simply add them we get a result. That result is then plugged back into the original checksum computation and then sent. This is all done in the format of 16-bit words.

4500 +
000E +
0001 +
0000 +
FF11 +
0102 +
0304 +
0102 +
= 14C2D

Our result is larger than 16 bits so we must perform the carry function.

+ 0001
= 4C2E

Now we must perform the ones complement:

= B3D1

This is the interesting part of what the checksum does. Once the value has been calculated, the system takes the ones complement of that result. The ones complement is a function that takes the value of the result in binary and essentially switches the value. If the binary unit has a value of 1, it becomes 0. And if the binary unit has a value of 0, it becomes 1. That value then becomes the value for the checksum field.

The receiver also uses the ones complement function when checking the information that was received. After the value is calculated and all the necessary carries are done, the system then takes the ones complement of the number. This number will always be equal to zero.

To illustrate this point:

4500 +
000E +
0001 +
0000 +
FF11 +
B3D1 + (This is the checksum field)
0102 +
0304 +
0102 +

Our result is larger than 16 bits so we must perform the carry function.

+ 0001

Now we must perform the ones complement:

= 0000

When the checksum is configured, as we mentioned earlier, the value of the checksum is set to 0. Then after the addition is done, the result is then sent to the receiver in the checksum field. The receiver then calculates the data for itself. The result that the receiver gets should be equal to zero. If this is the case then the information will follow. After the values have been calculated, there may be an instance where the value is larger than a 16-bit word. As we mentioned earlier, the calculations are done in short word format. If the result is larger than a 16-bit word, the system performs a carry that allows the value to be shown as a 16-bit word.

This function can be done a maximum of 2 times.

The Internet Control Message Protocol (ICMP)

The previous section shows how the Internet Protocol software provides an unreliable connectionless datagram delivery service by arranging for each router to forward datagrams. A datagram travels from router to router until it reaches one that can deliver the datagram directly to its final destination. If a router cannot route or deliver a datagram or if the router detects an unusual condition that affects its ability to forward the datagram, the router needs to inform the original source to take action to avoid or correct the problem. In this section we will discuss a mechanism that Internet routers and hosts use to communicate control or error information. We will see that routers use the mechanism to report problems, and the hosts use it to test whether destinations are reachable.

The Internet Control Message Protocol

In the connectionless system we have described so far, each router operates autonomously, routing or delivering datagrams that arrive without coordinating with the original sender. This system works well if all machines operate correctly all the time. Aside from communication lines or processors failing; there are a variety of conditions that will impede IP's ability to deliver datagrams: when the destination machine is temporarily or permanently disconnected from the network, when the time-to-live counter expires, or when intermediate routers become so congested that they cannot process the incoming traffic. The important difference between having a single network implemented with dedicated hardware and an internet implemented with software is that in the former, the designer can add special hardware to inform attached hosts when problems arise. In an internet, which has no such hardware mechanism, a sender cannot tell whether a delivery failure resulted from a local malfunction or a remote one. This can make debugging difficult. The IP protocol itself contains nothing to help the sender test connectivity or learn about such failures.

Designers added a special-purpose message mechanism to the TCP/IP protocols to allow routers in an internet to report errors or provide information about unexpected circumstances. This mechanism, known as the Internet Control Message Protocol (ICMP), is considered a required part of IP and must be included in every IP implementation.

Like all other traffic, ICMP messages travel across the Internet in the data portion of IP datagrams. The ultimate destination of an ICMP message is not an application program or user on the destination machine, but the Internet Protocol software on that machine. That is, when an ICMP error message arrives, the ICMP software modules handle it. Of course, if ICMP determines that a particular higher-level protocol or application program has caused a problem, it will inform the appropriate module.

So in other words: The Internet Control Message Protocol allows routers to send error or control messages to other routers or hosts; ICMP provides communication between the Internet Protocol software on one machine to the Internet Protocol software on another.

Initially designed to allow routers to report the cause of delivery errors to hosts, ICMP is not restricted to routers. Although guidelines restrict the use of some ICMP messages, an arbitrary machine can send an ICMP message to any other machine. Thus, a host can use ICMP to correspond with a router or another host. The chief advantage of allowing hosts to use ICMP is that it provides a single mechanism used for all control and information messages.

Error Reporting vs. Error Correction

Technically, ICMP is an error reporting mechanism. It provides a way for routers that encounter an error to report the error to the original source. Although the protocol specification outlines intended uses of ICMP and suggests possible actions to take in response to error reports, ICMP does not fully specify the action to be taken for each possible error. When a datagram causes an error, ICMP can only report the error condition back to the original source of the datagram; the source must relate the error to an individual application program or take other action to correct the problem.

Most errors stem from the original source, but some do not. Because ICMP reports problems to the original source, it cannot be used to inform intermediate routers about problems. Unfortunately, the original source has no responsibility for the problem or control over a misbehaving router. In fact, the source may not be able to determine which router caused the problem.

You might ask, "Why restrict ICMP to communication with the original source?"

Well, to answer that question, we know that a datagram only contains fields that specify the original source and the ultimate destination. It does not contain a complete record of its trip through the Internet (except for unusual cases where the record route option is used). Furthermore, because routers can establish and change their own routing tables, there is no global knowledge of routes. Thus, when a datagram reaches a given router, it is impossible to know the path it has taken to get there. If the router detects a problem, it cannot know the set of intermediate machines that processed the datagram, so it cannot inform them of the problem. Instead of silently discarding the datagram, the router uses ICMP to inform the original source that a problem has occurred, and trusts that host administrators will cooperate with network administrators to locate and repair the problem.

ICMP Message Delivery

ICMP messages require two levels of encapsulation as Figure 1-31 shows. Each ICMP message travels across the Internet in the data portion of an IP datagram, which itself travels across each physical network in the data portion of a frame. Datagrams carrying ICMP messages are routed exactly like datagrams carrying information for users; there is no additional reliability or priority. Thus, error messages themselves may be lost or discarded. Furthermore, in an already congested network, the error messages may cause additional congestion. An exception is made to the error handling procedures if an IP datagram carrying an ICMP message causes an error. The exception, established to avoid the problem of having error messages about error messages, specifies that ICMP messages are not generated from errors that result from datagrams carrying ICMP error messages.

Fig. 1-31: Two Levels of ICMP Encapsulation

Fig. 1-31 Two Levels of ICMP Encapsulation

The ICMP message is encapsulated in an IP datagram, and then is encapsulated into a frame datagram. To identify the ICMP, the datagram protocol field contains the value 1. It is important to keep in mind that even though ICMP messages are encapsulated and sent using IP datagrams, it is not considered a higher-level protocol - it is a required part of IP. The reason for using IP to deliver ICMP messages is that they may need to travel across several physical networks to reach their final destination. Thus, they cannot be delivered by the physical transport alone.

ICMP Message Format

Although each ICMP message has its own format, they all begin with the same three fields. These are an 8-bit integer message TYPE field that identifies the message, an 8-bit CODE field that provides further information about the message type, and a 16-bit CHECKSUM field (ICMP uses the same additive checksum algorithm as IP but the ICMP checksum only covers the ICMP message). In addition, ICMP messages that report errors always include the header and the first 64 data bits of the datagram causing the problem.

The reason for returning more than the datagram header alone is to allow the receiver to determine which protocol(s) and which application program were responsible for the datagram. Higher-level protocols in the TCP/IP suite are designed so that crucial information is encoded in the first 64 bits.

The TYPE field defines the meaning of the message as well as its format. The types include:

Type Field ICMP Message Type
0 Echo Reply
3 Destination Unreachable
4 Source Quench
5 Redirect (change a route)
8 Echo Request
11 Time Exceeded for a Datagram
12 Parameter Problem on a Datagram
13 Timestamp Request
14 Timestamp Reply
15 Information Request (obsolete)
16 Information Reply (obsolete)
17 Address Mask Request
18 Address Mask Reply

Fig. 1-32 ICMP Message Types

Testing Destination Reachability and Status (Ping)

TCP/IP protocols provide facilities to help network managers or users to identify network problems. One of the most frequently used debugging tools invokes the ICMP echo request and echo reply messages. A host or router sends an ICMP echo request message to a specified destination. Any machine that receives an echo request formulates an echo reply and returns it to the original sender. The request sends an optional data area; the reply contains a copy of the data sent in the request. The echo request and associated reply can be used to ensure that a destination is reachable and responding. Because both the request and reply travel in IP datagrams, successful receipt of a reply verifies that major pieces of the transport system work. First, IP software on the source computer must route the datagram. Second, intermediate routers between the source and destination must be operating and must route the datagram correctly. Third, the destination machine must be running (it must at least respond to interrupts), and both ICMP and IP software must be working. Finally, all routers along the return path must have correct routes.

On many systems, the command users invoke to send ICMP echo requests is referred to as ping. A sophisticated version of ping can send a series of ICMP echo requests, capture responses, and provide statistics about datagram loss. It allows the user to specify the length of the data being sent and the interval between requests. Less sophisticated versions merely send one ICMP echo request and await a reply. Figure 1-33 shows the format of an echo request and reply messages:

0 8 16 24
Type (8 or 0) Code (0) Checksum
Identifier Sequence Number
Optional Data

Fig. 1-33 Format of an Echo Request and Reply

The field OPTIONAL DATA is a variable length field that contains data to return to the sender. An echo reply always returns the same data that was received in the request. The sender, to match replies to the requests, uses fields SEQUENCE NUMBER and IDENTIFIER. The value of the TYPE field specifies whether the message is a request (8) or a reply (0).


Normal communication across an internet involves sending messages from an application on one host to an application on another host. Routers may need to communicate directly with the network software on a particular host to report abnormal conditions or to send the host new routing information. The Internet Control Message Protocol provides for the extra-normal communication among routers and hosts; it is an integral, required part of IP.

The User Datagram Protocol (UDP)

The User Datagram Protocol or UDP is the primary mechanism that application programs use to send datagrams to other application programs. UDP messages contain both destination port numbers and source port numbers in addition to the data being sent. This makes it possible for the UDP software at the destination to deliver information to the correct recipient and for the recipient to send a reply.

UDP utilizes the underlying IP to transport information from one machine to another. By using the IP format for delivery, UDP inherits the same characteristics of an IP message. It is an unreliable, connectionless datagram service. For example, it does not use acknowledgments to makes sure messages have arrived. It does not order incoming messages, and it does not provide feedback to control the rate at which information passes between machines. From this we can gather that UDP messages can be lost, duplicated, or arrive out of order. We also know that packets can be sent faster than the recipient can process them. To reiterate:

The User Datagram Protocol (UDP) provides an unreliable, connectionless delivery service using IP to transport messages between machines. It uses IP to carry messages, but utilizes the distinction among multiple destinations.

An application program that relies on UDP accepts full responsibility for the problems of reliability, including message loss, duplication, delay, and even out-of-order delivery. However, we can look at certain applications that do not need to utilize these strict options. For example, if a connection is made over the Internet that needs to transmit voice and video applications, we can see that speed is more important than reliability. Because packets are transmitted at such a high rate of speed, we are willing to sacrifice the reliability for rate of transfer.

If we were using a reliable method for voice and video, we would have to wait for two machines to exchange information to ensure that the information will not be lost, sacrificing time. However, if we were to make the same connection using UDP there would be a steady steam of packets entering the application, because there is no use of acknowledgements. If two packets were to get discarded or sent out-of-order, or even lost, the result that we might see would be very minimal. Again the important thing to decide is which is more important speed, or reliability.

UDP Message Format

Each UDP message is referred to as a user datagram. A user datagram consists of two parts: a UDP header and a UDP data area. As we can see in Figure 1-34, a UDP header is divided into four parts: a 16-bit field that specifies the port from which it originated, the port that it is going to, the size of the message (or message length), and the UDP checksum.

0 16
UDP Source Port UDP Destination Port
UDP Message Length UDP Checksum

Fig. 1-34 Format of Fields in a UDP Datagram

The SOURCE PORT and DESTINATION PORT fields contain 16-bit UDP protocol numbers, which are used as application identifiers among the processes waiting to receive them. The SOURCE PORT is optional. However, when it is used, it specifies the port to which replies should be sent. If the field is not used, it should be set to zero. The LENGTH field contains a count of bytes in the UDP datagram, including the header and the user data. The minimum number that can be in this field is eight, the length of the header by itself. As we mentioned earlier the CHECKSUM field is optional. A value of zero in the checksum field indicates that the checksum has not been computed.

UDP Pseudo-Header

To compute a checksum, UDP attaches a pseudo-header to the UDP datagram, and pads the datagram with one byte of zeros and then computes the checksum over the entire object. It is important to remember that the padding of zeros and the pseudo-header are not transmitted with the UDP datagram, nor are they included in the length. The purpose of using a pseudo-header is to verify that the UDP datagram has reached the appropriate destination. The pseudo header is not transmitted to the recipient. The receiver takes the information contained in the IP header and places it into the pseudo-header format for the purpose of computing the checksum.

Source IP Address
Destination IP Address
Zero Protocol UDP Length

Fig. 1-35 Pseudo Header Format Used to Compute a Checksum.

UDP Encapsulation

The UDP encapsulation format is one that works in the transport protocol layer. UDP lies in the layer above the Internet Protocol Layer. By concept, application programs access UDP, which use IP to send and receive datagrams. We can see an illustration of this in Figure 1-36.

Conceptual Layering
User Datagram (UDP)
Internet (IP)
Network Interface

Fig. 1-36 Conceptual Layering of UDP between Application Programs and IP

By layering UDP above IP, we can encapsulate a complete UDP message, including the UDP header and data, into an IP datagram.

As we learned earlier, encapsulation means that the protocol, UDP in this case, basically "inserts" the information into a frame, and then sends it across the network. In the example of UDP, it takes the information and attaches its own header to it and sends it to the network.

The Transport Control Protocol (TCP)

The first thing we need to remember is that TCP is a connection-oriented protocol. This means that when the TCP protocol is used, both sides need send each other some type of recognition that they have established a connection. This is different from the earlier mentioned section describing such protocols as UDP, which is a connectionless oriented protocol, where information is sent out without the need for acknowledgement. Commonly, TCP is known to be a very reliable protocol because of this fact.

Reliable Stream Delivery

Why do we need reliable stream delivery? To answer this question at the lowest level, computer communication networks provide unreliable packet delivery. As we have mentioned in previous sections, packets can be lost or destroyed when transmission errors interfere with data, when network hardware fails, or when networks become too heavily loaded. Networks that deliver packets dynamically, such as UDP, can deliver them out of order, deliver them after a substantial delay, or even deliver duplicates. Also, underlying network technologies may dictate optimal packet size or invoke other constraints needed to achieve efficient transfer rates.

At the highest level, application programs may need to send large volumes of data from one computer to another. Using a connectionless delivery system for large volume transfers can be tedious, and also requires programmers to incorporate error detection and recovery into each application program. All these problems and inconveniences have caused a necessity to find a general-purpose solution to providing reliable stream delivery. This will make it possible for experts to build a single instance of stream protocol software that all application programs use. The advantage of this is to help isolate application programs from the details of networking, and it also makes it possible to define a uniform interface for stream transfer service.


Reliable stream delivery service guarantees to deliver a stream of data from one machine to another without duplication or loss. This statement brings up an interesting question, "How can protocol software provide reliable transfer if the underlying communication system offers only unreliable packet delivery?"

Most reliable protocols use a single fundamental technique known as positive acknowledgement with retransmission. This technique requires a recipient to communicate with the source by sending an acknowledgement (ACK) message as it receives data. The sender keeps the report of each packet it sends and then waits for an acknowledgement before sending the next packet. The sender also starts a timer when it sends a packet and retransmits a packet if the timer expires before a packet arrives. The following diagram shows how the simplest positive acknowledgement protocol transfers data.

Fig. 1-37: Simple Positive Acknowledgment with Retransmission

Fig. 1-37 Simple Positive Acknowledgment with Retransmission

The final reliability problem arises when an underlying packet delivery system duplicates a packet. Duplicates can also arise when networks experience high delays that cause premature retransmission. Solving duplication problems requires careful consideration because both packets and acknowledgements can be duplicated. Usually, reliable protocols can detect duplicate packets by assigning each packet a sequence number and requiring the receiver to remember which sequence numbers it has received. We will explore this further in an upcoming section. To avoid confusion caused by delayed or duplicate acknowledgements, positive acknowledgement protocols send sequence numbers back in acknowledgements. Therefore, the receiver can correctly associate acknowledgements with packets.

Fig. 1-38: Packet Loss and Retransmission

Fig. 1-38 Packet Loss and Retransmission

Sliding Windows

As we continue in the explanation of the TCP protocol suite we need to examine the concept of a sliding window. A sliding window enables stream transmission to be efficient. To understand this concept, we need to keep in mind Figure 1-37. It shows how a sender transmits a packet and waits for an acknowledgement from the receiver before transmitting another. Also, we can gather from this illustration that data only flows from one machine to another in one direction at any given time, even if the network is capable of simultaneous communications in both directions. The network will be completely idle during times the machines delay responses, for example, when computing a checksum.

When dealing with a network with high transmission delays, we must remember that a simple positive acknowledgement protocol wastes a substantial amount of network bandwidth. This is because it must wait to send another packet until it receives an acknowledgement for the original packet that was sent. The solution to this problem is the Sliding Window Concept. Sliding window protocols use network bandwidth more efficiently because they allow the user to transmit multiple packets before waiting to receive an acknowledgement. To illustrate this point, look at Figure 1-39. If we think of a sequence of packets to be transmitted, the protocol places a small fixed-size window on the sequence and transmits all packets that lie inside of that window.

Fig. 1-39: Sliding Window Protocol

Fig. 1-39 Sliding Window Protocol

The first half of this illustration shows a sliding window protocol with an eight-packet window. The second part of the illustration shows the window sliding, so that packet 9 can be sent when an acknowledgement has been received for packet 1. Remember: Only unacknowledged packets are retransmitted.

When we say a packet is unacknowledged, it means the packet has been transmitted, but no acknowledgement has been received. Technically, the number of packets that can be unacknowledged at any given time is constrained to the window size and is limited to a small fixed number. For example, as in our illustration, a window that has the size of eight, the sender has permission to transmit 8 packets before it receives an acknowledgement. Once the sender has received an acknowledgement for the first packet, the window essentially "slides", and sends the next packet. The window continues to slide as long as acknowledgements are received.

The performance of sliding window protocols depends on the window size and the speed at which the network accepts packets. In our next illustration, you can see an operation of a sliding window protocol when sending three packets. Note that the sender transmits all the packets before receiving any acknowledgments.

With a window size of 1, a sliding window protocol is the same as our simple positive acknowledgement protocol. By increasing our window size, it is possible to eliminate network idle time completely. Simply put, the sender can transmit packets as fast as the network can transfer them. We need to remember that a finely tuned sliding window protocol keeps the network completely saturated with packets

The timer is an important part of this protocol. By design, the sliding window protocol remembers which packets have been acknowledged and keeps a separate timer for each unacknowledged packet. If a packet is lost, the timer expires and the sender retransmits that packet. When a sliding window slides, it moves past all acknowledged packets. On the receiving end, the protocol software keeps its own window, accepting and acknowledging packets as they arrive. Thus, the window breaks the packets up into three sets: packets to the left of the window that have been successfully transmitted, received and acknowledged, packets to the right of the window that have not yet been sent, and packets that lie in the window that are being transmitted.

Fig. 1-40: Three Packets Transmitted Using a Sliding Window Protocol

Fig. 1-40 Three Packets Transmitted Using a Sliding Window Protocol

Transmission Control Protocol

Now that we have discussed and understand the sliding window principle, we can look at the reliable stream service provided by the TCP/IP Internet protocol suite. The service is defined by the Transmission Control Protocol or TCP. This reliable stream service is so important that the entire protocol suite is referred to as TCP/IP. It is important to remember that TCP is not a piece of software, it is a communication protocol. People seem to encounter TCP software much more than they do the communication protocol, so it is natural that to think of a particular implementation as the standard

TCP is both a connection-oriented protocol, and a byte stream oriented protocol. What this means is that TCP transmits a set of bytes at a time. These are called TCP segments. Until now, we have discussed only packet-oriented delivery of information. For example, if we were to make a call to the stack with two 100-byte pieces of information, using TCP, it would send the information as a 200-byte piece. Unlike other protocols, it does not break the information into packets, and then send it. There is no packet delineation. By using this method, data transfer can be likened to a modem connection. The method is essentially the same but the commands we use are different. We use the connect function from the sender. The receiver uses the listen function to receive incoming data.

TCP Header

We say that TCP is very reliable. The way TCP achieves reliability is in the format of the header. As we mentioned earlier, the unit of transfer between two machines using TCP software is called a segment. Segments are exchanged to establish connections, to transfer data, to send acknowledgements, to advertise window sizes, and to close connections. Let's look at the format of a TCP segment including the TCP header:

0 8 16 24
Source Port Destination Port
Sequence Numbers
Acknowledgment Number
HLEN Reserved Code Bits Window
Checksum Urgent Pointer
Options (If Any) Padding

Fig. 1-41 Format of a TCP Segment Including the TCP Header

Each segment is divided into two parts, a header followed by data. The header, also called the TCP header, carries the expected identification and control information. The Fields, SOURCE PORT and DESTINATION PORT contain the TCP port numbers that identify application programs at the ends of the connection. The SEQUENCE NUMBER field identifies the sender's byte stream of data in the segment. The ACKNOWLEDGEMENT NUMBER specifies the number of bytes the source expects to receive next. The sequence number refers to the stream flowing in the same direction as the segment while the acknowledgement field refers to the stream flowing in the opposite direction. The following chart shows examples of currently assigned port numbers:

Decimal Keyword Description
7 ECHO Echo
9 DISCARD Discard
21 FTP File Transfer Protocol
23 TELNET Terminal Connection

Fig. 1-42 Example of Well-Known Ports

The HLEN field contains an integer value that specifies the length of the segment header in 32-bit multiples. It is needed because the OPTIONS field varies in length, depending on which options have been included. The 6-bit field marked as RESERVED is reserved for future use.

Some segments carry only acknowledgements while others carry data. Others carry requests to establish or close a connection. TCP software uses the field CODE BITS to determine the purpose and contents of the segment. These six bits tell how to interpret other fields in the header according to the table in Figure 1-43.

Bit (Left to Right) Meaning if bit is set to 1
URG Urgent pointer field is valid
ACK Acknowledgment field is valid
PSH This segment requests a push
SYN Reset the connection
FIN Sender has reached the end of its byte stream

Fig. 1-43 Components of the Code Bits Header Field

TCP software advertises how much data it is willing to accept every time it sends a segment by specifying its buffer size in the WINDOW field. This field contains a 16-bit integer in network standard byte order. Window advertisements accompany all segments, including those carrying data, as well as those carrying only an acknowledgement.

TCP/IP and Client/Server Relationships

The TCP/IP protocol stack is designed around the concept of client machines that receive service from other machines on a network. For example, a personal computer that accesses the Internet through a LAN (Local Area Network) gateway relies on that gateway server to "talk TCP/IP" across the Internet on its behalf.

With that in mind, we can analyze the TCP/IP stack and find that each successively higher layer is a client to the layer beneath it.

Fig. 1-44: Client/Server Relationships in TCP/IP

Fig. 1-44 Client/Server Relationships in TCP/IP

IP is a client of the data link layer software. It uses that software's services to achieve its physical transmission of packets. UDP and TCP are clients of IP. They use they use the IP routing mechanisms to move messages across a switched network.


Anything that depends on the transmission of data from one terminal to another can efficiently use TCP/IP to get it there reliably. When ARPANET was established, the need for reliable transmission was a must. By today's standards, TCP/IP has become the leading means of getting information from one place to another.

Table of Contents