3 Network Models
3.4 tcP/IP ProtocoL SuIte
The TCP/IP protocol suite was in vogue before the OSI model. The origi-nal TCP/IP had four layers and obviously did not match the layers of the OSI model. When the OSI model was introduced, there was a belief that it would overwhelm TCP/IP commercially, which it never did. Ultimately, during the 1990s, it became apparent that TCP/IP would dominate the commercial protocol architecture on which further developments would be based.
3.4.1 introDuction
TCP/IP was developed by the Department of Defense before the introduc-tion of the seven-layer OSI model. It is the de facto global standard for the Internet. The Internet (earlier known as ARPANET) was a part of a military project of the Advanced Research Projects Agency (ARPA) and the communication model based thereon is known as the ARPA model.
To presentation layer From presentation layer
User User
Application
layer Application
layer
L7 data L7 data
X.500 FTAM X.400 X.500 FTAM X.400
FIGure 3.13 Operation of application layer. (Available at www.eazynotes.
com/notes/computer-networks/slides/osi-model.pdf.)
Network Models 57
ARPA was developed in the United States before the OSI model was devel-oped in Europe by the ISO. Whereas the OSI model specifies exactly what function(s) each layer has to perform, TCP/IP comprises several relatively independent protocols that can be combined in several ways. Although TCP/IP and OSI were developed at different times by different bodies, they form the basis for data communications having different types and of different complexities.
It is not mandatory to use all the layers in the TCP/IP model; for exam-ple, some application-level protocols operate directly on top of IP. TCP/IP does not include the bottom network interface layer, but it depends on the same for access to the medium.
3.4.2 Protocol architecture
The five-layer TCP/IP reference model is shown in Table 3.1.
The application layer corresponds to the upper three layers of the OSI model, i.e., application, presentation, and session layers. TCP residing in the transport layer ensures data delivery to the proper process. The net-work layer routes data from the host to the destination node via one or more networks, with the help of the IP addresses. The data link layer inter-faces an end system with the network, while the lowest or physical layer is concerned with signal rate, signal encoding, etc.
Figure 3.14 shows the protocols available at different layers in the TCP/
IP protocol suite.
At the different layers, different protocols are available. Among them, TCP and UDP belonging to the transport layer and IP in the network layer are the ones that form the basis for data delivery from one computer sta-tioned at one end of the globe to another computer housed at the other end.
taBLe 3.1
Five-Layer tcP/IP Model
Layer no. Layer name Purpose
5 Application Specifies communication methodology between different processes/applications residing on different hosts 4 Transport Provides end-to-end reliable data transfer
3 Network Routes data between host and destination nodes through one or more networks connected by routers
2 Data link Concerned with logical interface between an end system and a network
1 Physical Concerned with physical transmission medium, signal encoding scheme, signal transmission rate, etc.
3.4.2.1 tcP
TCP is a connection-oriented transport layer protocol. Functionalities include reliable data delivery, congestion control, duplicate data suppres-sion, and flow control. Most of the user application protocols, such as FTP and Telnet, use TCP. Two processes can communicate with each other through the TCP connection with the help of IP datagrams. This is shown in Figure 3.15.
TCP establishes a session between the transmitting process and the receiving process before initiating transmission. There are facilities to check that all packets have been received and arranged for retransmission, in case of packet loss. These involve additional overhead and lead to higher
Process 1 Process 2
FIGure 3.15 Connection establishment between two processes by TCP.
(Available at www.redbooks.ibm.com/redbooks/pdfs/gg243376.pdf.)
ICMP IGMP IP RARP ARP
Session
FIGure 3.14 Protocols in TCP/IP protocol suite.
Network Models 59
processing time and header size. However, at the same time, it makes the system more reliable.
TCP fragments a large chunk of data into smaller segments when neces-sary, numbers the segments, reassembles the whole message, detects and arranges for retransmission in case of failure, issues acknowledgments for data received, and provides socket services for multiple connections to ports on remote hosts. The segmented messages may be received out of order at the receiver, which the TCP reassembles in correct order.
Each and every TCP segment has a header that comprises all the neces-sary information for proper data delivery and retrieval. The TCP header format is shown in Figure 3.16.
The sending and destination ports are each 16 bits. While the former identifies the sending end host, the latter identifies the receiving host. A destination host is identified by its IP number, and the process on the host is identified by its port number. The IP number in conjunction with port number is called socket.
The sequence number, consisting of 32 bits, ensures the sequentiality of data stream that is sent by the sending end host. It specifies the first byte of the user data in the segment. During the initial setup, it represents the Initial Sequence Number (ISN) that identifies the first byte of data in every segment of data sent by TCP. For a particular connection, ISN ensures that data is reassembled in correct order at the receiving host.
Data Options and padding Checksum (16)
Window (16)
Urgent pointer (16) Control
bits (6) Reserved
Offset (4)
Sequence number (32)
Acknowledgment number (32) Source port (16) Destination port (16)
FIGure 3.16 TCP header format. (From N. Mathivanan. PC Based Instru
mentation: Concepts and Practice. Prentice Hall of India, New Delhi, India, p. 549, 2007.)
Acknowledgment number is 32 bits in length and is “sequence number + 1” of the last successfully received data byte. The sending host, while trans-mitting, sets a timer and if the acknowledgments are not received within the specified time, an error is assumed and the data is again retransmitted.
Data offset is 4 bits in length and indicates where the data begins. The six flags, each of 1 bit, control connection and data transfer. These are as follows:
1. URG: Indicates that the header contains the valid urgent pointer.
2. ACK: Indicates that the header contains a valid acknowledgment number.
3. PSH: It is push function forcing TCP to promptly deliver data.
4. RST: Exercising this causes the connection to be reset.
5. SYN: It ensures that sequence numbers are synchronized and handshaking operations occur.
6. FIN: Indicates that there is no more data from the sender.
The window size is 16 bits and provides flow control. The checksum field is used for error control, while the urgent pointer field, in association with URG flag, can insert a block of “urgent” data at the beginning of a segment.
3.4.2.1.1 Window Principle
In TCP, sequence number is assigned to each byte in the data stream, giv-ing rise to a segment and they are sent one after the other. The window principle is applied at the byte level in case of TCP, the segments sent, and the ACKs received. The window size is expressed in terms of number of bytes instead of number of packets.
The receiver determines the window size, and it is a variable one during data transfer. An ACK sent by the receiver is representative of the window size the receiver is capable of handling at that instant of time.
A sender’s data stream at any given instant can look like that shown in Figure 3.17.
1 2 3 4 5 6 7 8 9 10 11 12
A B C D
Window size in bytes
FIGure 3.17 TCP window principle. (Available at www.redbooks.ibm.com/
redbooks/pdfs/gg243376.pdf.)
Network Models 61
In the figure
• A represents the number of bytes transmitted and acknowledged.
• B represents the number of bytes sent but yet to be acknowledged.
• C represents the number of bytes that can be sent without waiting for acknowledgment.
• D represents the number of bytes that cannot be sent at present.
3.4.2.1.2 Congestion Control
TCP uses a very helpful congestion control mechanism that can overcome any possible overwhelming of the receiver by the sender. This is a possi-bility for slow WAN links. TCP congestion control algorithms can adapt the sender to the network capacity at any point of time and thus avoid any potential congestion situation. TCP follows a variety of congestion con-trol algorithms to avoid congestion: slow start, congestion avoidance, fast retransmit, and fast recovery.
Slow start is a process in which, once the connection is established, a sender can send multiple segments depending on the window size as advertised by the receiver. This is fine when two hosts are on the same LAN, but poses a serious problem if there are routers and slow links in between. The consequences are that packets are dropped, performance is degraded, and the situation calls for retransmission.
The slow start algorithm avoids such a situation. It operates on the prin-ciple that packets can be injected into the network only at a rate acknowl-edgments are received from the sender. The slow start algorithm adds another window to the sender’s TCP. This is called congestion window, abbreviated cwnd, and is initialized to one segment only. Each time an ACK is received by the sender, it increases its congestion window by one.
The sender has the option to send the lower value as imposed by the con-gestion window or the advertised window as advertised by the receiving host. The former is controlled by the sender and the latter by the receiver.
The congestion avoidance algorithm is based on the assumption that packet loss due to congestion is very small. Packet loss may be ascertained from the following two conditions: if a time out occurs or duplicate ACKs are received. Although the slow start and congestion avoidance algorithms are independent of each other, loss of packet leads to implementation of both algorithms at the same time. Thus, another algorithm, called a slow start threshold size, abbreviated ssthresh, is used along with cwnd.
In fast retransmit algorithm, TCP does not wait for time out to resend the lost segments.
Fast recovery algorithm is performed by fast retransmit. It is undertaken to allow for high throughput under moderate congestion—particularly for
large windows. The first retransmit and fast recovery algorithms are nor-mally implemented together.
3.4.2.2 udP
UDP is a connectionless protocol. It does not require any connection estab-lishment before data transmission. UDP requires no sequence numbers, no timers, no synchronization parameters, no retransmission of data pack-ets, and no priority options. Thus, it has very little overhead. Its major drawback is that it does not guarantee delivery. UDP is normally used for broadcasting, general network announcements, real-time data, etc.
The UDP header is shown in Figure 3.18. It has only four fields.
The source port is an optional one. When it is used, it indicates the port address of the sending process. When not used, a value of zero is inserted for this field. The destination port indicates the process to which the data is to be delivered. The “length” is the length in bytes of the used datagram, including the header. The checksum is an optional 16-bit field, used for validation purposes.
3.4.2.3 IP
The internetworking layer in TCP/IP has some very important proto-cols: IP, Internet Control Message Protocol (ICMP), Address Resolution Protocol (ARP), and Dynamic Host Configuration Protocol (DHCP). They together perform datagram addressing, routing, delivery, dynamic address configuration, and resolving between internetwork layer addresses and network interface layer addresses.
IP is an unreliable, connectionless, and best-effort packet delivery pro-tocol. Best-effort delivery means that packets sent by IP might be lost, may reach out of order, or even may get duplicated. It is the responsibility of the higher layer to address these concerns. Connectionless network protocol is
0 15 16 31
Source port
Length
Data
Checksum Destination port
FIGure 3.18 UDP header format. (From S. Mackay et al., Practical Industrial Data Networks Design, Installation and Troubleshooting. Newnes An Imprint of Elsevier, U.K., p. 272, 2004.)
Network Models 63
used to minimize the dependence on specific computing centers that uses hierarchical connection-oriented networks.
IP addressing is a must to identify a host on the Internet. Thus each host is assigned an IP address or an Internet address. A host is recognized by this IP address. A host may be connected to more than one network, called multihomed, in which case the host must have a separate address for each network interface.
IP addresses are represented by a 32-bit unsigned binary value and are expressed in a dotted decimal format. Each IP address consists of a network number and a host number. The network number is administered by one of the three Regional Internet Registries: American Registry for Internet Numbers, Reseaux IP Europeans, and Asia Pacific Network Information Centre. For example, 128.3.7.8, is an IP address, where 128.3 represents the network number while 7.8 represents the host number. Sometimes terms such as network address or netID are used instead of network number, while host address or hosteID are used for host number.
An IP datagram (the basic data packet exchanged between hosts) con-tains a source IP address and a destination IP address. For a datagram to be sent to a destination IP address, it must be translated or mapped into a physical address. For example, in LANs, the IP address is translated into a physical MAC address by the ARP.
There are five classes of IP addresses: A, B, C, D, and E. Class A address is suitable for an extremely large number of hosts, class B for a small ber of hosts, and class C for medium-sized networks with moderate num-ber of hosts. Class D is used for multicasting, while class E is for future or experimental use. Delivery of a datagram using IP addresses can be any of the following types: unicast, broadcast, multicast, or any cast. This is shown in Figure 3.19. A connectionless protocol can send a message in any
Unicast Broadcast
FIGure 3.19 Different packet delivery modes. (Available at www.redbooks.
ibm.com/redbooks/pdfs/gg243376.pdf.)
of the above four methods, while a connection-oriented protocol can only use unicast addresses.
IP version 4 (IPv4) is responsible for delivery of data packets (data-grams) between the sending host to the receiving host. Different systems, for example, Ethernet, can handle 1500 bytes while X.25 can handle 576 bytes. Because of this frame size limitation, a message is broken up into fragments, called datagrams. Each datagram from an entire message is given an IP header, which is then sent from the sending host. The receiving host rebuilds the message from the datagrams received. The IPv4 header consists of at least five 32 bit “long words,” i.e., 20 bytes in all, and is shown in Figure 3.20. This IP header is appended to the information that it receives from higher-level protocols.
The “ver” field is 4 bits long and indicates the IP protocol version in use (in this case, it is four). The 4-bit IHL (Internet header length) indicates the length of the IP header. This header length is not a fixed one. The ToS (type of service) field is 8 bits long and its different bit positions corre-spond to minimizing delay and monetary cost and maximizing throughput and reliability. The “total length” corresponds to the length of the data-gram, measured in bytes. This field, along with IHL, determines where
Type of
service Total length
Fragment offset Identifier Flags
Ve r
HI L
Timeto
live Protocol
Source address
Checksum header
15 16 31
0 3 4 7 8
Destination address
Options and padding
FIGure 3.20 IPv4 header. (From S. Mackay et al., Practical Industrial Data Networks Design, Installation and Troubleshooting. Newnes An Imprint of Elsevier, U.K., p. 260, 2004.)
Network Models 65
data starts and ends. Maximum datagram length can be 216 = 65,536 bytes, although such long datagram length is impractical. Datagram lengths up to 576 octets are allowed.
The 16-bit identifier uniquely identifies each datagram sent by the host with its value incremented by one each time a datagram is sent. When frag-mentation of a message is necessary, the identifier is appended to each suc-cessive fragment in order to retrieve the datagram correctly at the receiver.
The 3-bit flag field follows the identifier field and has two flags. These two flags are used in the fragmentation process with DF (do not fragment) set to 1 by the higher-level protocol, in case IP is not allowed to fragment a message. When fragmentation is done, MF = 1 indicates that more frag-ments follow. The last fragment has MF = 0 in its flag field.
The fragment offset is 13 bits long and indicates where in the original datagram a particular datagram belongs. The TTL (time to live) sees to it that datagrams that cannot be delivered are ultimately destroyed. The protocol field is 8 bits long and indicates the next higher-level protocol header present in the data portion of the datagram. The checksum header is a checksum on the header portion only. Both source and destination addresses are 32 bits long each and represent the origin host and target host, respectively.
3.4.3 oPeration
The TCP/IP protocol suite helps in sending a message from a process asso-ciated with a port residing at a host to another process assoasso-ciated with a port at a second host. The receiving host may reside on the same network or on another network. For the latter case, the message has to pass through several routers along its passage to the final destination. It should be kept in mind that IP is implemented in all the end systems and the routers, while TCP is implemented only in the end systems.
As already mentioned in Section 3.2, two levels of addressing are needed for a process data in one host to be sent to another process in another host.
A local port address is needed, which would ensure correct data delivery at the process at the receiving host. Again a network address is needed, which would enable the message to be delivered to the receiving host.
Let’s say a process data residing at a port belonging to a host is to be delivered at another process having its own port address and belonging to another host. The sending end process hands the message down to TCP. It has instructions to send the same to the second host at the particular port.
TCP hands over the message to IP with instructions to deliver the same to the second host. IP is remaining to be totally transparent about the port address of the destination host. All these are managed by control informa-tion appended to the message at each layer of the TCP/IP protocol suite.
3.4.4 PDusin architecture
Control information, in the form of headers and trailers, is appended to the message at the different layers to ensure proper data delivery at the proper destination with utmost reliability. Figure 3.21 shows the data encapsula-tion and PDUs in the TCP/IP architecture. At the TCP layer, control infor-mation, in the form of TCP header, is appended forming a TCP segment or a PDU of TCP. Control information that is included in the TCP header
Control information, in the form of headers and trailers, is appended to the message at the different layers to ensure proper data delivery at the proper destination with utmost reliability. Figure 3.21 shows the data encapsula-tion and PDUs in the TCP/IP architecture. At the TCP layer, control infor-mation, in the form of TCP header, is appended forming a TCP segment or a PDU of TCP. Control information that is included in the TCP header