Download presentation
Presentation is loading. Please wait.
1
Internet Protocol Suite
Instructor: Prof. Ruay-Shiung Chang Department of Computer Science and Information Engineering National Dong Hwa University, Hualien, TAIWAN
2
Textbook TCP/IP Protocol Suite, Third edition, McGraw-Hill
By Behrouz A. Forouzan
3
References
4
Course Outline Chapter 1: Introduction
Chapter 2: The OSI model and TCP/IP protocol suite Chapter 4: IP addresses: classful addressing Chapter 5: Subnetting/Supernetting and classless addressing Chapter 6: Delivery and routing of IP packets Chapter 7: ARP and RARP Chapter 8: Internet Protocol (IP) Chapter 9: Internet Control Message Protocol (ICMP) Chapter 11: User Datagram Protocol (UDP) Chapter 12: Transmission Control Protocol (TCP) Chapter 13: Unicast Routing Protocols (RIP, OSPF, BGP)
5
Any Questions?
6
Chapter 1 Introduction
7
CONTENTS A BRIEF HISTORY PROTOCOLS AND STANDARDS
STANDARDS ORGANIZATIONS INTERNET STANDARDS INTERNET ADMINISTRATION
8
1.1 A BRIEF HISTORY
9
Time Line The following is a list of important Internet events in chronological order: 1969. Four-node ARPANET established. 1970. ARPA hosts implement NCP. 1973. Development of TCP/IP suite begins. 1977. An internet tested using TCP/IP. 1978. UNIX distributed to academic sites.
10
1983. TCP/IP becomes the official protocol 1983. MILNET was born.
1981. CSNET established. 1983. TCP/IP becomes the official protocol 1983. MILNET was born. 1986. NSFNET established. 1990. ARPANET replaced by NSFNET. 1995. NSFNET became a research network. 1995. ISPs started. (Internet Service Providers) Question: Find out ASP, ICP, IAP?
11
Figure 1-1 Internet today Network Access Points
12
Internet History Internet Society Webpage (http://www.isoc.org)
Internet Society History Webpage ( Computer History (
13
1.2 PROTOCOLS AND STANDARDS
14
Protocols Syntax Semantics Timing
15
Standards De facto: e.g., TCP/IP De jure: e.g., ISO OSI
16
1.3 STANDARDS ORGANIZATIONS
17
Standards Creation Committees
International Standards Organization (ISO) International Telecommunications Union– Telecommunication Standards Sector (ITU-T) American National Standards Institute (ANSI) Institute of Electrical and Electronics Engineers (IEEE) Electronic Industries Association (EIA)
18
Forums Regulatory Agencies Frame Relay Forum ATM Forum
Federal Communications Commission (FCC) National Communications Commission (NCC)
19
The websites for the above organizations are given in Appendix G.
20
1.4 INTERNET STANDARDS
21
Maturity levels of an RFC
Figure 1-2 Maturity levels of an RFC
22
Requirement levels of an RFC
Figure 1-3 Requirement levels of an RFC
23
1.5 INTERNET ADMINISTRATION
24
Internet Administration
Figure 1-4 Internet Administration Internet Architecture Board Internet Research Task Force Internet Engineering Task Force SG: Steering Group
25
Internet Numbers IP addresses Protocol numbers Domain names …
IANA (Internet Assigned Numbers Authority) ICANN (Internet Corporation for Assigned Names and Numbers)
26
The OSI Model and TCP/IP Protocol Suite
Chapter 2 The OSI Model and TCP/IP Protocol Suite
27
CONTENTS THE OSI MODEL LAYERS IN THE OSI MODEL TCP/IP PROTOCOL SUITE
ADDRESSING TCP/IP VERSIONS
28
2.1 THE OSI MODEL
29
ISO is the organization. OSI is the model.
30
Figure 2-1 OSI Model
31
Figure 2-2 OSI layers
32
Headers are added to the data at layers 6, 5, 4, 3, and 2
Headers are added to the data at layers 6, 5, 4, 3, and Trailers are usually added only at layer 2.
33
An exchange using the OSI model
Figure 2-3 An exchange using the OSI model
34
2.2 LAYERS IN THE OSI MODEL
35
Figure 2-4 Physical Layer
36
Figure 2-5 Data Link Layer
37
Node-to-node delivery
Figure 2-6 Node-to-node delivery
38
Figure 2-7 Network Layer
39
Figure 2-8 End-to-end delivery
40
Figure 2-9 Transport Layer
41
Reliable end-to-end delivery of a message
Figure 2-10 Reliable end-to-end delivery of a message
42
Figure 2-11 Session Layer
43
Figure 2-12 Presentation Layer
44
Application Layer X.400: Message handling services
Figure 2-13 Application Layer X.400: Message handling services X.500: Directory services FTAM: File transfer, access, and management
45
Figure 2-14 Summary of layers
46
2.3 TCP/IP PROTOCOL SUITE
47
TCP/IP and OSI model Figure 2-15
48
2.4 ADDRESSING
49
Figure 2-16 Addresses in TCP/IP
50
Figure 2-17 Relation- ship of layers and addresses in TCP/IP
51
Figure 2.18 shows an example of physical addresses.
52
Figure 2-18 Physical addresses
53
Example 2 Most local area networks use a 48-bit (6 bytes) physical address written as 12 hexadecimal digits, with every 2 bytes separated by a hyphen as shown below: C-4B A 6-byte (12 hexadecimal digits) physical address
54
Figure 2.19 shows an example of Internet addresses.
55
Figure 2-19 IP addresses Note the changes in physical address!!
56
Example 4 As we will see in Chapter 4, an Internet address (in IPv4) is 32 bits in length, normally written as four decimal numbers, with each number representing 1 byte. The numbers are separated by a dot. Below is an example of such an address.
57
Figure 2.20 shows an example of transport layer communication.
58
Figure 2-20 Port addresses
59
Example 6 As we will see in Chapters 11 and 12, a port address is a 16-bit address represented by one decimal number as shown below. A 16-bit port address
60
2.5 TCP/IP VERSIONS
61
Versions: Version 4 (current): 32-bit IP address Version 5
Version 6 (in promotion): 128-bit IP address
62
IP Addresses: Classful Addressing
Chapter 4 IP Addresses: Classful Addressing
63
CONTENTS INTRODUCTION CLASSFUL ADDRESSING OTHER ISSUES
A SAMPLE INTERNET
64
4.1 INTRODUCTION
65
An IP address is a 32-bit address.
66
The IP addresses are unique.
One IP address points to one computer. But a computer may have many IP addresses.
67
Address Space ………….. addr1 addr15 addr2 ………….. ………….. ………….. addr226
68
RULE: If a protocol uses N bits to define an address,
………….. ………….. addr1 If a protocol uses N bits to define an address, the address space is 2N because each bit can have two different values (0 and 1) and N bits can have 2N values. addr15 addr2 ………….. ………….. ………….. addr41 addr226 addr31 ………….. …………..
69
The address space of IPv4 is
or 4,294,967,296.
70
Binary Notation
71
Dotted-decimal notation
Figure 4-1 Dotted-decimal notation
72
Hexadecimal Notation D EA 0x75951DEA
73
The binary, decimal, and hexadecimal number systems are reviewed in Appendix B.
74
Example 1 Change the following IP address from binary notation to dotted-decimal notation. Solution
75
Example 2 Change the following IP address from dotted-decimal notation to binary notation. Solution
76
Find the error, if any, in the following IP address: 111.56.045.78
Example 3 Find the error, if any, in the following IP address: Solution There are no leading zeroes in dotted-decimal notation (045).
77
Find the error, if any, in the following IP address: 75.45.301.14
Example 3 (continued) Find the error, if any, in the following IP address: Solution In dotted-decimal notation, each number is less than or equal to 255; 301 is outside this range.
78
Example 4 Change the following IP addresses from binary notation to hexadecimal notation. Solution 0X810B0BEF or B0BEF16
79
4.2 CLASSFUL ADDRESSING
80
Occupation of the address space
Figure 4-2 Occupation of the address space 231(50%) 230(25%) 229(12.5%) 228(6.25%)
81
In classful addressing, the address space is divided into five classes: A, B, C, D, and E.
82
Finding the class in binary notation
Figure 4-3 Finding the class in binary notation
83
Finding the address class
Figure 4-4 Finding the address class
84
How can we prove that we have 2,147,483,648 addresses in class A?
Example 5 How can we prove that we have 2,147,483,648 addresses in class A? Solution In class A, only 1 bit defines the class. The remaining 31 bits are available for the address. With 31 bits, we can have 231 or 2,147,483,648 addresses.
85
Find the class of the address: 00000001 00001011 00001011 11101111
Example 6 Find the class of the address: Solution The first bit is 0. This is a class A address.
86
Find the class of the address: 11000001 10000011 00011011 11111111
Example 6 (Continued) Find the class of the address: Solution The first 2 bits are 1; the third bit is 0. This is a class C address.
87
Finding the class in decimal notation
Figure 4-5 Finding the class in decimal notation
88
Find the class of the address: 227.12.14.87
Example 7 Find the class of the address: Solution The first byte is 227 (between 224 and 239); the class is D.
89
Find the class of the address: 193.14.56.22
Example 7 (Continued) Find the class of the address: Solution The first byte is 193 (between 192 and 223); the class is C.
90
The addresses in class A range from 0.0.0.0 to
Example 8 In Example 4 we showed that class A has 231 (2,147,483,648) addresses. How can we prove this same fact using dotted-decimal notation? Solution The addresses in class A range from to We notice that we are dealing with base 256 numbers here.
91
Each byte in the notation has a weight. The weights are as follows:
Solution (Continued) Each byte in the notation has a weight. The weights are as follows: 2563 , 2562, 2561, 2560 Last address: 127 2563 + 255 2562 + 2561 + 255 2560 = 2,147,483,647 First address: = 0 If we subtract the first from the last and add 1, we get 2,147,483,648.
92
Figure 4-6 Netid and hostid
93
Figure 4-7 Blocks in class A
94
Millions of class A addresses are wasted.
95
Figure 4-8 Blocks in class B
96
Many class B addresses are wasted.
97
Figure 4-9 Blocks in class C
98
The number of addresses in a class C block is smaller than the needs of most organizations.
99
Class D addresses are used for multicasting; there is only one block in this class.
100
Class E addresses are reserved for special purposes; most of the block is wasted.
101
Network Addresses The network address is the first address.
The network address defines the network to the rest of the Internet. Given the network address, we can find the class of the address, the block, and the range of the addresses in the block
102
In classful addressing, the network address (the first address in the block) is the one that is assigned to the organization.
103
The class is A because the first byte is between
Example 9 Given the network address , find the class, the block, and the range of the addresses. Solution The class is A because the first byte is between 0 and 127. The block has a netid of 17. The addresses range from to
104
The class is B because the first byte is between
Example 10 Given the network address , find the class, the block, and the range of the addresses. Solution The class is B because the first byte is between 128 and 191. The block has a netid of The addresses range from to
105
The class is C because the first byte is between
Example 11 Given the network address , find the class, the block, and the range of the addresses. Solution The class is C because the first byte is between 192 and 223. The block has a netid of The addresses range from to
106
Mask A mask is a 32-bit binary number that gives the first address in the block (the network address) when bitwise ANDed with an address in the block.
107
Figure 4-10 Masking concept
108
Figure 4-11 AND operation
109
The network address is the beginning address of each block
The network address is the beginning address of each block. It can be found by applying the default mask to any of the addresses in the block (including itself). It retains the netid of the block and sets the hostid to zero.
110
Mask in dotted-decimal
Default Masks Class Mask in Binary Mask in dotted-decimal A …0 B …0 C 1…
111
The default mask is 255.0.0.0, which means
Example 12 Given the address and the default class A mask, find the beginning address (network address). Solution The default mask is , which means that only the first byte is preserved and the other 3 bytes are set to 0s. The network address is
112
The default mask is 255.255.0.0, which means
Example 13 Given the address and the default class B mask, find the beginning address (network address). Solution The default mask is , which means that the first 2 bytes are preserved and the other 2 bytes are set to 0s. The network address is
113
which means that the first 3 bytes are
Example 14 Given the address and the class C default mask, find the beginning address (network address). Solution The default mask is , which means that the first 3 bytes are preserved and the last byte is set to 0. The network address is
114
We must not apply the default mask of one class to an address belonging to another class.
115
CIDR (Classless Inter-Domain Routing) Notation
/8 /16 /24 Number of 1’s in the mask Address Depletion We have run out of class A and B addresses, and a class C block is too small for most middle-sized organizations.
116
4.13 OTHER ISSUES
117
Figure 4-12 Multihomed devices
118
Location, Not Names An internet address defines the network location of a device, not its identify. Movement of computer from one network to another means that its IP address must be changed. Flat addressing vs. hierarchical addressing
119
Special Addresses Special Address Netid Hostid Source or Destination
Network address Specific All 0s None Direct broadcast address All 1s Destination Limited broadcast address The host on this network Source Specific host on this network Loopback address 127 Any
120
Figure 4-13 Network addresses
121
Example of direct broadcast address
Figure 4-14 Example of direct broadcast address
122
Example of limited broadcast address
Figure 4-15 Example of limited broadcast address
123
Example of this host on this address
Figure 4-16 Example of this host on this address
124
Example of specific host on this network
Figure 4-17 Example of specific host on this network
125
Example of loopback address
Figure 4-18 Example of loopback address
126
Private Addresses A number of blocks in each class are assigned for private use. They are not recognized globally. These blocks are depicted in Table 4.4 Class Netids Blocks A 10.0.0 1 B to 16 C to 256
127
Unicast, Multicast, and Broadcast Addresses
Unicast communication is one-to-one. Multicast communication is one-to-many. Broadcast communication is one-to-all.
128
Multicast delivery will be discussed in depth in Chapter 15.
129
4.4 A SAMPLE INTERNET WITH CLASSFUL ADDRESSES
130
Figure 4-19 Sample internet
131
4.4 SUBNETTING
132
IP addresses are designed with two levels of hierarchy.
133
A network with two levels of hierarchy (not subnetted)
Figure 4.20 A network with two levels of hierarchy (not subnetted) Why subnetting? 1. The transmissions of these hosts will affect one another. 2. Class B too large, wasteful. 3. Not easy to manage. (e.g., where is host ?)
134
A network with three levels of hierarchy (subnetted)
Figure 4.21 A network with three levels of hierarchy (subnetted)
135
Addresses in a network with and without subnetting
Figure 4.22 Addresses in a network with and without subnetting
136
Hierarchy concept in a telephone number
Figure 4.23 Hierarchy concept in a telephone number
137
Default mask and subnet mask
Figure 4.24 Default mask and subnet mask
138
Finding the Subnet Address
Given an IP address, we can find the subnet address the same way we found the network address. We apply the mask to the address. We can do this in two ways: straight or short-cut.
139
Straight Method In the straight method, we use binary notation for both the address and the mask and then apply the AND operation to find the subnet address.
140
Example 15 What is the subnetwork address if the destination address is and the subnet mask is ?
141
The subnetwork address is 200.45.32.0.
Solution The subnetwork address is
142
Short-Cut Method ** If the byte in the mask is 255, copy the byte in the address. ** If the byte in the mask is 0, replace the byte in the address with 0. ** If the byte in the mask is neither 255 nor 0, we write the mask and the address in binary and apply the AND operation.
143
What is the subnetwork address if the destination address is and the mask is ?
144
Comparison of a default mask and
Figure 4.25 Comparison of a default mask and a subnet mask
145
The number of subnets must be a power of 2.
146
The number of 1s in the default mask is 24 (class C).
A company is granted the site address (class C). The company needs six subnets. Design the subnets. Solution The number of 1s in the default mask is 24 (class C).
147
The total number of 0s is 5 (32 - 27). The mask is
Solution (Continued) The company needs six subnets. This number 6 is not a power of 2. The next number that is a power of 2 is 8 (23). We need 3 more 1s in the subnet mask. The total number of 1s in the subnet mask is 27 (24 + 3). The total number of 0s is 5 ( ). The mask is
148
The number of subnets is 8.
Solution (Continued) or The number of subnets is 8. The number of addresses in each subnet is 25 (5 is the number of 0s) or 32.
150
The number of 1s in the default mask is 16 (class B).
A company is granted the site address (class B). The company needs 1000 subnets. Design the subnets. Solution The number of 1s in the default mask is 16 (class B).
151
The total number of 1s in the subnet mask is 26 (16 + 10).
Solution (Continued) The company needs 1000 subnets. This number is not a power of 2. The next number that is a power of 2 is 1024 (210). We need 10 more 1s in the subnet mask. The total number of 1s in the subnet mask is 26 ( ). The total number of 0s is 6 ( ).
152
The number of subnets is 1024.
Solution (Continued) The mask is or The number of subnets is 1024. The number of addresses in each subnet is 26 (6 is the number of 0s) or 64.
154
Variable-length subnetting
Without counting the all 0’s and all 1’s hosts
155
SUPERNETTING
156
A supernetwork Why supernetwork? 1. Class C too small
Figure 4.26 A supernetwork Why supernetwork? 1. Class C too small 2. Routing table efficiency
157
Rules: ** The number of blocks must be a power of 2 (1, 2, 4, 8, 16, . . .). ** The blocks must be contiguous in the address space (no gaps between the blocks). ** The third byte of the first address in the superblock must be evenly divisible by the number of blocks. In other words, if the number of blocks is N, the third byte must be divisible by N.
158
A company needs 600 addresses
A company needs 600 addresses. Which of the following set of class C blocks can be used to form a supernet for this company?
159
Solution 1: No, there are only three blocks. 2: No, the blocks are not contiguous. 3: No, 31 in the first block is not divisible by 4. 4: Yes, all three requirements are fulfilled.
160
In subnetting, we need the first address of the subnet and the subnet mask to define the range of addresses.
161
In supernetting, we need the first address of the supernet and the supernet mask to define the range of addresses.
162
Comparison of subnet, default,
Figure 4.27 Comparison of subnet, default, and supernet masks
163
We need to make a supernetwork out of 16 class C blocks
We need to make a supernetwork out of 16 class C blocks. What is the supernet mask? Solution We need 16 blocks. For 16 blocks we need to change four 1s to 0s in the default mask. So the mask is or
164
A supernet has a first address of 205. 16. 32
A supernet has a first address of and a supernet mask of A router receives three packets with the following destination addresses: Which packet belongs to the supernet?
165
Solution We apply the supernet mask to see if we can find the beginning address. AND AND AND Only the first address belongs to this supernet.
166
A supernet has a first address of 205. 16. 32
A supernet has a first address of and a supernet mask of How many blocks are in this supernet and what is the range of addresses? Solution The supernet has 21 1s. The default mask has 24 1s. Since the difference is 3, there are 23 or 8 blocks in this supernet. The blocks are to The first address is The last address is
167
IP Addresses: Classless Addressing
Chapter 5 IP Addresses: Classless Addressing Objectives Upon completion you will be able to: Understand the concept of classless addressing Be able to find the first and last address given an IP address Be able to find the network address given a classless IP address Be able to create subnets from a block of classless IP addresses Understand address allocation and address aggregation TCP/IP Protocol Suite
168
5.1 VARIABLE-LENGTH BLOCKS
In classless addressing variable-length blocks are assigned that belong to no class. In this architecture, the entire address space (232 addresses) is divided into blocks of different sizes. The topics discussed in this section include: Restrictions Finding the Block Granted Block TCP/IP Protocol Suite
169
Figure 5.1 Variable-length blocks
TCP/IP Protocol Suite
170
Number of Addresses Number of Addresses in a Block
There is only one condition on the number of addresses in a block; it must be a power of 2 (2, 4, 8, . . .). A household may be given a block of 2 addresses. A small business may be given 16 addresses. A large organization may be given 1024 addresses. TCP/IP Protocol Suite
171
Beginning Address Beginning Address
The beginning address must be evenly divisible by the number of addresses. For example, if a block contains 4 addresses, the beginning address must be divisible by 4. If the block has less than 256 addresses, we need to check only the rightmost byte. If it has less than 65,536 addresses, we need to check only the two rightmost bytes, and so on. TCP/IP Protocol Suite
172
Example 1 Which of the following can be the beginning address of a block that contains 16 addresses? a b c d Solution Only two are eligible (a and c). The address is eligible because 32 is divisible by 16. The address is eligible because 80 is divisible by 16. TCP/IP Protocol Suite
173
Example 2 Which of the following can be the beginning address of a block that contains 256 addresses? a b c d Solution In this case, the right-most byte must be 0. As we mentioned in Chapter 4, the IP addresses use base 256 arithmetic. When the right-most byte is 0, the total address is divisible by 256. Only two addresses are eligible (b and c). TCP/IP Protocol Suite
174
Example 3 Which of the following can be the beginning address of a block that contains 1024 addresses? a b c d Solution In this case, we need to check two bytes because = 4 × 256. The right-most byte must be divisible by 256. The second byte (from the right) must be divisible by 4. Only one address is eligible (c). TCP/IP Protocol Suite
175
Figure 5.2 Format of classless addressing address
TCP/IP Protocol Suite
176
Table 5.1 Prefix lengths TCP/IP Protocol Suite
177
Classful addressing is a special case of classless addressing.
Note: Classful addressing is a special case of classless addressing. TCP/IP Protocol Suite
178
Example 4 What is the first address in the block if one of the addresses is /27? Solution The prefix length is 27, which means that we must keep the first 27 bits as is and change the remaining bits (5) to 0s. The following shows the process: Address in binary: Keep the left 27 bits: Result in CIDR notation: /27 TCP/IP Protocol Suite
179
Example 5 What is the first address in the block if one of the addresses is /20? Solution Figure 5.3 shows the solution. The first, second, and fourth bytes are easy; for the third byte we keep the bits corresponding to the number of 1s in that group. The first address is /20. See Next Slide TCP/IP Protocol Suite
180
Figure Example 5 TCP/IP Protocol Suite
181
Example 6 Find the first address in the block if one of the addresses is /20. Solution The first, second, and fourth bytes are as defined in the previous example. To find the third byte, we write 84 as the sum of powers of 2 and select only the leftmost 4 (m is 4) as shown in Figure 5.4. The first address is /20. See Next Slide TCP/IP Protocol Suite
182
Figure Example 6 TCP/IP Protocol Suite
183
Example 7 Find the number of addresses in the block if one of the addresses is /20. Solution The prefix length is 20. The number of addresses in the block is 232−20 or 212 or Note that this is a large block with 4096 addresses. TCP/IP Protocol Suite
184
Example 8 Using the first method, find the last address in the block if one of the addresses is /20. Solution We found in the previous examples that the first address is /20 and the number of addresses is To find the last address, we need to add 4095 (4096 − 1) to the first address. See Next Slide TCP/IP Protocol Suite
185
Example 8 (Continued) To keep the format in dotted-decimal notation, we need to represent 4095 in base 256 (see Appendix B) and do the calculation in base 256. We write 4095 as We then add the first address to this number (in base 255) to obtain the last address as shown below: The last address is /20. TCP/IP Protocol Suite
186
Example 9 Using the second method, find the last address in the block if one of the addresses is /20. Solution The mask has twenty 1s and twelve 0s. The complement of the mask has twenty 0s and twelve 1s. In other words, the mask complement is or We add the mask complement to the beginning address to find the last address. See Next Slide TCP/IP Protocol Suite
187
Example 9 (Continued) We add the mask complement to the beginning address to find the last address. The last address is /20. TCP/IP Protocol Suite
188
Find the block if one of the addresses is 190.87.140.202/29.
Example 10 Find the block if one of the addresses is /29. Solution We follow the procedure in the previous examples to find the first address, the number of addresses, and the last address. To find the first address, we notice that the mask (/29) has five 1s in the last byte. So we write the last byte as powers of 2 and retain only the leftmost five as shown below: See Next Slide TCP/IP Protocol Suite
189
The leftmost 5 numbers are ➡ 128 + 64 + 0 + 0 + 8
Example 10 (Continued) ➡ The leftmost 5 numbers are ➡ The first address is /29 The number of addresses is 232−29 or 8. To find the last address, we use the complement of the mask. The mask has twenty-nine 1s; the complement has three 1s. The complement is If we add this to the first address, we get /29. In other words, the first address is /29, the last address is /29. There are only 8 addresses in this block. TCP/IP Protocol Suite
190
Example 11 Show a network configuration for the block in the previous example. Solution The organization that is granted the block in the previous example can assign the addresses in the block to the hosts in its network. However, the first address needs to be used as the network address and the last address is kept as a special address (limited broadcast address). Figure 5.5 shows how the block can be used by an organization. Note that the last address ends with 207, which is different from the 255 seen in classful addressing. See Next Slide TCP/IP Protocol Suite
191
Figure Example 11 TCP/IP Protocol Suite
192
Note: In classless addressing, the last address in the block does not necessarily end in TCP/IP Protocol Suite
193
Note: In CIDR notation, the block granted is defined by the first address and the prefix length. TCP/IP Protocol Suite
194
5.2 SUBNETTING When an organization is granted a block of addresses, it can create subnets to meet its needs. The prefix length increases to define the subnet prefix length. The topics discussed in this section include: Finding the Subnet Mask Finding the Subnet Addresses Variable-Length Subnets TCP/IP Protocol Suite
195
In fixed-length subnetting, the number of subnets is a power of 2.
Note: In fixed-length subnetting, the number of subnets is a power of 2. TCP/IP Protocol Suite
196
Example 12 An organization is granted the block /26. The organization needs 4 subnets. What is the subnet prefix length? Solution We need 4 subnets, which means we need to add two more 1s (log2 4 = 2) to the site prefix. The subnet prefix is then /28. TCP/IP Protocol Suite
197
Solution Figure 5.6 shows one configuration.
Example 13 What are the subnet addresses and the range of addresses for each subnet in the previous example? Solution Figure 5.6 shows one configuration. See Next Slide TCP/IP Protocol Suite
198
Figure Example 13 TCP/IP Protocol Suite
199
Example 13 (Continued) The site has 232−26 = 64 addresses. Each subnet has 232–28 = 16 addresses. Now let us find the first and last address in each subnet. 1. The first address in the first subnet is /28, using the procedure we showed in the previous examples. Note that the first address of the first subnet is the first address of the block. The last address of the subnet can be found by adding 15 (16 −1) to the first address. The last address is /28. See Next Slide TCP/IP Protocol Suite
200
Example 13 (Continued) 2.The first address in the second subnet is /28; it is found by adding 1 to the last address of the previous subnet. Again adding 15 to the first address, we obtain the last address, /28. 3. Similarly, we find the first address of the third subnet to be /28 and the last to be /28. 4. Similarly, we find the first address of the fourth subnet to be /28 and the last to be /28. TCP/IP Protocol Suite
201
See Next Slide For One Solution
Example 14 An organization is granted a block of addresses with the beginning address /24. There are 232−24= 256 addresses in this block. The organization needs to have 11 subnets as shown below: a. two subnets, each with 64 addresses. b. two subnets, each with 32 addresses. c. three subnets, each with 16 addresses. d. four subnets, each with 4 addresses. Design the subnets. See Next Slide For One Solution TCP/IP Protocol Suite
202
Figure Example 14 TCP/IP Protocol Suite
203
Example 14 (Continuted) 1. We use the first 128 addresses for the first two subnets, each with 64 addresses. Note that the mask for each network is /26. The subnet address for each subnet is given in the figure. 2. We use the next 64 addresses for the next two subnets, each with 32 addresses. Note that the mask for each network is /27. The subnet address for each subnet is given in the figure. See Next Slide TCP/IP Protocol Suite
204
Example 14 (Continuted) 3. We use the next 48 addresses for the next three subnets, each with 16 addresses. Note that the mask for each network is /28. The subnet address for each subnet is given in the figure. 4. We use the last 16 addresses for the last four subnets, each with 4 addresses. Note that the mask for each network is /30. The subnet address for each subnet is given in the figure. TCP/IP Protocol Suite
205
Example 15 As another example, assume a company has three offices: Central, East, and West. The Central office is connected to the East and West offices via private, point-to-point WAN lines. The company is granted a block of 64 addresses with the beginning address /26. The management has decided to allocate 32 addresses for the Central office and divides the rest of addresses between the two offices. Figure 5.8 shows the configuration designed by the management. See Next Slide TCP/IP Protocol Suite
206
Figure Example 15 TCP/IP Protocol Suite
207
See Next Slide Example 15 (Continued)
The company will have three subnets, one at Central, one at East, and one at West. The following lists the subblocks allocated for each network: a. The Central office uses the network address /27. This is the first address, and the mask /27 shows that there are 32 addresses in this network. Note that three of these addresses are used for the routers and the company has reserved the last address in the sub-block. The addresses in this subnet are /27 to /27. Note that the interface of the router that connects the Central subnet to the WAN needs no address because it is a point-to-point connection. See Next Slide TCP/IP Protocol Suite
208
See Next Slide Example 15 (Continued)
b. The West office uses the network address /28. The mask /28 shows that there are only 16 addresses in this network. Note that one of these addresses is used for the router and the company has reserved the last address in the sub-block. The addresses in this subnet are /28 to /28. Note also that the interface of the router that connects the West subnet to the WAN needs no address because it is a point-to- point connection. See Next Slide TCP/IP Protocol Suite
209
Example 15 (Continued) c. The East office uses the network address /28. The mask /28 shows that there are only 16 addresses in this network. Note that one of these addresses is used for the router and the company has reserved the last address in the sub-block. The addresses in. this subnet are /28 to /28. Note also that the interface of the router that connects the East subnet to the WAN needs no address because it is a point-to-point connection. TCP/IP Protocol Suite
210
5.3 ADDRESS ALLOCATION Address allocation is the responsibility of a global authority called the Internet Corporation for Assigned Names and Addresses (ICANN). It usually assigns a large block of addresses to an ISP to be distributed to its Internet users. TCP/IP Protocol Suite
211
Example 16 An ISP is granted a block of addresses starting with /16 (65,536 addresses). The ISP needs to distribute these addresses to three groups of customers as follows: a. The first group has 64 customers; each needs 256 addresses. b. The second group has 128 customers; each needs addresses c. The third group has 128 customers; each needs 64 addresses. See Next Slide TCP/IP Protocol Suite
212
Solution Figure 5.9 shows the situation.
Example 16 (Continued) Design the subblocks and find out how many addresses are still available after these allocations. Solution Figure 5.9 shows the situation. See Next Slide TCP/IP Protocol Suite
213
Figure Example 16 TCP/IP Protocol Suite
214
Example 16 (Continued) Group 1 For this group, each customer needs 256 addresses. This means the suffix length is 8 (28 =256). The prefix length is then 32 − 8 = 24. The addresses are: 1st Customer / /24 2nd Customer / / th Customer / /24 Total = 64 × 256 = 16,384 See Next Slide TCP/IP Protocol Suite
215
Example 16 (Continued) Group 2 For this group, each customer needs 128 addresses. This means the suffix length is 7 (27 =128). The prefix length is then 32 − 7 = 25. The addresses are: 1st Customer / /25 2nd Customer / /25 · · · 128th Customer / /25 Total = 128 × 128 = 16,384 See Next Slide TCP/IP Protocol Suite
216
Example 16 (continued) Group 3 For this group, each customer needs 64 addresses. This means the suffix length is 6 (26 = 64). The prefix length is then 32 − 6 = 26. The addresses are: 1st Customer / /26 2nd Customer / /26 · · · 128th Customer / /26 Total = 128 × 64 = 8,192 See Next Slide TCP/IP Protocol Suite
217
Number of granted addresses to the ISP: 65,536
Example 16 (continued) Number of granted addresses to the ISP: 65,536 Number of allocated addresses by the ISP: 40,960 Number of available addresses: 24,576 TCP/IP Protocol Suite
218
Delivery, Forwarding, and Routing of IP Packets
Chapter 6 Delivery, Forwarding, and Routing of IP Packets Objectives Upon completion you will be able to: Understand the different types of delivery and the connection Understand forwarding techniques in classful addressing Understand forwarding techniques in classless addressing Understand how a routing table works Understand the structure of a router TCP/IP Protocol Suite
219
6.1 DELIVERY The network layer supervises delivery, the handling of the packets by the underlying physical networks. Two important concepts are the type of connection and direct versus indirect delivery. The topics discussed in this section include: Connection Types Direct Versus Indirect Delivery TCP/IP Protocol Suite
220
IP is a connectionless protocol.
Note: IP is a connectionless protocol. TCP/IP Protocol Suite
221
Figure 6.1 Direct delivery
TCP/IP Protocol Suite
222
Figure 6.2 Indirect delivery
TCP/IP Protocol Suite
223
6.2 FORWARDING Forwarding means to place the packet in its route to its destination. Forwarding requires a host or a router to have a routing table. . The topics discussed in this section include: Forwarding Techniques Forwarding with Classful Addressing Forwarding with Classless Addressing Combination TCP/IP Protocol Suite
224
Figure 6.3 Next-hop method
TCP/IP Protocol Suite
225
Routing table too large
Figure Network-specific method Routing table too large TCP/IP Protocol Suite
226
Figure 6.5 Host-specific routing
TCP/IP Protocol Suite
227
Figure 6.6 Default routing
TCP/IP Protocol Suite
228
Figure 6.7 Simplified forwarding module in classful address without subnetting
TCP/IP Protocol Suite
229
Example 1 Figure 6.8 shows an imaginary part of the Internet. Show the routing tables for router R1. See Next Slide TCP/IP Protocol Suite
230
Figure 6.8 Configuration for routing, Example 1
TCP/IP Protocol Suite
231
Example 1 (Continued) Solution Figure 6.9 shows the three tables used by router R1. Note that some entries in the next-hop address column are empty because in these cases, the destination is in the same network to which the router is connected (direct delivery). In these cases, the next-hop address used by ARP is simply the destination address of the packet as we will see in Chapter 7. See Next Slide TCP/IP Protocol Suite
232
Figure 6.9 Tables for Example 1
TCP/IP Protocol Suite
233
Example 2 Router R1 in Figure 6.8 receives a packet with destination address Show how the packet is forwarded. Solution The destination address in binary is A copy of the address is shifted 28 bits to the right. The result is or 12. The destination network is class C. The network address is extracted by masking off the leftmost 24 bits of the destination address; the result is The table for Class C is searched. The network address is found in the first row. The next-hop address and the interface m0 are passed to ARP. TCP/IP Protocol Suite
234
Example 3 Router R1 in Figure 6.8 receives a packet with destination address Show how the packet is forwarded. Solution The destination address in binary is A copy of the address is shifted 28 bits to the right. The result is or 10. The class is B. The network address can be found by masking off 16 bits of the destination address, the result is The table for Class B is searched. No matching network address is found. The packet needs to be forwarded to the default router (the network is somewhere else in the Internet). The next-hop address and the interface number m0 are passed to ARP. TCP/IP Protocol Suite
235
Figure 6.10 Simplified forwarding module in classful address with subnetting
TCP/IP Protocol Suite
236
Figure 6.11 shows a router connected to four subnets.
Example 4 Figure 6.11 shows a router connected to four subnets. See Next Slide TCP/IP Protocol Suite
237
Example 4 (Continued) Note several points. First, the site address is /16 (a class B address). Every packet with destination address in the range to is delivered to the interface m4 and distributed to the final destination subnet by the router. Second, we have used the address x.y.z.t/n for the interface m4 because we do not know to which network this router is connected. Third, the table has a default entry for packets that are to be sent out of the site. The router is configured to apply the mask /18 to any destination address. TCP/IP Protocol Suite
238
Figure 6.11 Configuration for Example 4
TCP/IP Protocol Suite
239
Example 5 The router in Figure 6.11 receives a packet with destination address Show how the packet is forwarded. Solution The mask is /18. After applying the mask, the subnet address is The packet is delivered to ARP with the next-hop address and the outgoing interface m0. TCP/IP Protocol Suite
240
Example 6 A host in network in Figure 6.11 has a packet to send to the host with address Show how the packet is routed. Solution The router receives the packet and applies the mask (/18). The network address is The table is searched and the address is not found. The router uses the address of the default router (not shown in figure) and sends the packet to that router. TCP/IP Protocol Suite
241
In classful addressing we can have a routing table with three columns;
Note: In classful addressing we can have a routing table with three columns; in classless addressing, we need at least four columns. TCP/IP Protocol Suite
242
Figure 6.12 Simplified forwarding module in classless address
TCP/IP Protocol Suite
243
Solution Table 6.1 shows the corresponding table.
Example 7 Make a routing table for router R1 using the configuration in Figure 6.13. See Next Slide Solution Table 6.1 shows the corresponding table. See the table after the figure. TCP/IP Protocol Suite
244
Figure 6.13 Configuration for Example 7
TCP/IP Protocol Suite
245
Table 6.1 Routing table for router R1 in Figure 6.13
TCP/IP Protocol Suite
246
Solution The router performs the following steps:
Example 8 Show the forwarding process if a packet arrives at R1 in Figure 6.13 with the destination address Solution The router performs the following steps: 1. The first mask (/26) is applied to the destination address. The result is , which does not match the corresponding network address. See Next Slide TCP/IP Protocol Suite
247
Example 8 (Continued) 2. The second mask (/25) is applied to the destination address. The result is , which matches the corresponding network address. The next-hop address (the destination address of the packet in this case) and the interface number m0 are passed to ARP for further processing. TCP/IP Protocol Suite
248
Solution The router performs the following steps:
Example 9 Show the forwarding process if a packet arrives at R1 in Figure 6.13 with the destination address Solution The router performs the following steps: See Next Slide TCP/IP Protocol Suite
249
Example 9 (Continued) 1. The first mask (/26) is applied to the destination address. The result is , which does not match the corresponding network address (row 1). 2. The second mask (/25) is applied to the destination address. The result is , which does not match the corresponding network address (row 2). 3. The third mask (/24) is applied to the destination address. The result is , which matches the corresponding network address. The destination address of the package and the interface number m3 are passed to ARP. TCP/IP Protocol Suite
250
Example 10 Show the forwarding process if a packet arrives at R1 in Figure 6.13 with the destination address Solution This time all masks are applied to the destination address, but no matching network address is found. When it reaches the end of the table, the module gives the next-hop address and interface number m2 to ARP. This is probably an outgoing package that needs to be sent, via the default router, to some place else in the Internet. TCP/IP Protocol Suite
251
Example 11 Now let us give a different type of example. Can we find the configuration of a router, if we know only its routing table? The routing table for router R1 is given in Table 6.2. Can we draw its topology? See Next Slide TCP/IP Protocol Suite
252
Table 6.2 Routing table for Example 11
TCP/IP Protocol Suite
253
Example 11 (Continued) Solution We know some facts but we don’t have all for a definite topology. We know that router R1 has three interfaces: m0, m1, and m2. We know that there are three networks directly connected to router R1. We know that there are two networks indirectly connected to R1. There must be at least three other routers involved (see next-hop column). We know to which networks these routers are connected by looking at their IP addresses. So we can put them at their appropriate place. See Next Slide TCP/IP Protocol Suite
254
Example 11 (Continued) We know that one router, the default router, is connected to the rest of the Internet. But there is some missing information. We do not know if network is directly connected to router R2 or through a point-to-point network (WAN) and another router. We do not know if network is connected to router R3 directly or through a point-to-point network (WAN) and another router. Point-to-point networks normally do not have an entry in the routing table because no hosts are connected to them. Figure 6.14 shows our guessed topology. See Next Slide TCP/IP Protocol Suite
255
Figure 6.14 Guessed topology for Example 6
TCP/IP Protocol Suite
256
Figure 6.15 Address aggregation
TCP/IP Protocol Suite
257
Figure 6.16 Longest mask matching
TCP/IP Protocol Suite
258
Example 12 As an example of hierarchical routing, let us consider Figure A regional ISP is granted addresses starting from The regional ISP has decided to divide this block into four subblocks, each with 4096 addresses. Three of these subblocks are assigned to three local ISPs, the second subblock is reserved for future use. Note that the mask for each block is /20 because the original block with mask /18 is divided into 4 blocks. See Next Slide TCP/IP Protocol Suite
259
Figure 6.17 Hierarchical routing with ISPs
TCP/IP Protocol Suite
260
See Next Slide Example 12 (Continued)
The first local ISP has divided its assigned subblock into 8 smaller blocks and assigned each to a small ISP. Each small ISP provides services to 128 households (H001 to H128), each using four addresses. Note that the mask for each small ISP is now /23 because the block is further divided into 8 blocks. Each household has a mask of /30, because a household has only 4 addresses (232−30 is 4). The second local ISP has divided its block into 4 blocks and has assigned the addresses to 4 large organizations (LOrg01 to LOrg04). Note that each large organization has 1024 addresses and the mask is /22. See Next Slide TCP/IP Protocol Suite
261
Example 12 (Continued) The third local ISP has divided its block into 16 blocks and assigned each block to a small organization (SOrg01 to SOrg15). Each small organization has 256 addresses and the mask is /24. There is a sense of hierarchy in this configuration. All routers in the Internet send a packet with destination address to to the regional ISP. The regional ISP sends every packet with destination address to to Local ISP1. Local ISP1 sends every packet with destination address to to H001. TCP/IP Protocol Suite
262
6.3 ROUTING Routing deals with the issues of creating and maintaining routing tables. The topics discussed in this section include: Static Versus Dynamic Routing Tables Routing Table TCP/IP Protocol Suite
263
Figure 6.18 Common fields in a routing table
TCP/IP Protocol Suite
264
Example 13 One utility that can be used to find the contents of a routing table for a host or router is netstat in UNIX or LINUX. The following shows the listing of the contents of the default server. We have used two options, r and n. The option r indicates that we are interested in the routing table and the option n indicates that we are looking for numeric addresses. Note that this is a routing table for a host, not a router. Although we discussed the routing table for a router throughout the chapter, a host also needs a routing table. See Next Slide TCP/IP Protocol Suite
265
$ netstat -rn Kernel IP routing table
Example 13 (continued) $ netstat -rn Kernel IP routing table Destination Gateway Mask Flags Iface U eth0 U lo UG eth0. See Next Slide TCP/IP Protocol Suite
266
See Next Slide Example 13 (continued)
More information about the IP address and physical address of the server can be found using the ifconfig command on the given interface (eth0). $ ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:B0:D0:DF:09:5D inet addr: Bcast: Mask: .... From the above information, we can deduce the configuration of the server as shown in Figure 6.19. See Next Slide TCP/IP Protocol Suite
267
Figure 6.19 Configuration of the server for Example 13
TCP/IP Protocol Suite
268
6.4 STRUCTURE OF A ROUTER We represent a router as a black box that accepts incoming packets from one of the input ports (interfaces), uses a routing table to find the departing output port, and sends the packet from this output port. The topics discussed in this section include: Components TCP/IP Protocol Suite
269
Figure 6.20 Router components
TCP/IP Protocol Suite
270
Figure Input port TCP/IP Protocol Suite
271
Figure Output port TCP/IP Protocol Suite
272
Figure 6.23 Crossbar switch
TCP/IP Protocol Suite
273
Figure A banyan switch TCP/IP Protocol Suite
274
(1->6) and (5->7) will conflict with each other.
Figure Examples of routing in a banyan switch (1->6) and (5->7) will conflict with each other. TCP/IP Protocol Suite
275
Prevent blocking in banyan switch
Figure Batcher-banyan switch sorter 6 7 6 6 7 7 Prevent blocking in banyan switch TCP/IP Protocol Suite
276
(Address Resolution Protocol and Reverse ARP)
Chapter 7 ARP and RARP (Address Resolution Protocol and Reverse ARP) Objectives Upon completion you will be able to: Understand the need for ARP Understand the cases in which ARP is used Understand the components and interactions in an ARP package Understand the need for RARP TCP/IP Protocol Suite
277
Figure ARP and RARP TCP/IP Protocol Suite
278
Figure 7.2 Position of ARP and RARP in TCP/IP protocol suite
279
7.1 ARP ARP associates an IP address with its physical address. On a typical physical network, such as a LAN, each device on a link is identified by a physical or station address that is usually imprinted on the NIC. The topics discussed in this section include: Packet Format Encapsulation Operation ARP over ATM Proxy ARP TCP/IP Protocol Suite
280
Figure ARP operation TCP/IP Protocol Suite
281
Figure ARP packet TCP/IP Protocol Suite
282
Figure 7.5 Encapsulation of ARP packet
TCP/IP Protocol Suite
283
Figure 7.6 Four cases using ARP
TCP/IP Protocol Suite
284
An ARP request is broadcast; an ARP reply is unicast.
Note: An ARP request is broadcast; an ARP reply is unicast. TCP/IP Protocol Suite
285
Example 1 A host with IP address and physical address B2:34:55:10:22:10 has a packet to send to another host with IP address and physical address A4:6E:F4:59:83:AB (which is unknown to the first host). The two hosts are on the same Ethernet network. Show the ARP request and reply packets encapsulated in Ethernet frames. See Next Slide TCP/IP Protocol Suite
286
Example 1 (Continued) Solution Figure 7.7 shows the ARP request and reply packets. Note that the ARP data field in this case is 28 bytes, and that the individual addresses do not fit in the 4-byte boundary. That is why we do not show the regular 4-byte boundaries for these addresses. Also note that the IP addresses are shown in hexadecimal. For information on binary or hexadecimal notation see Appendix B. See Next Slide TCP/IP Protocol Suite
287
Figure Example 1 TCP/IP Protocol Suite
288
Figure Proxy ARP TCP/IP Protocol Suite
289
7.2 ARP PACKAGE In this section, we give an example of a simplified ARP software package to show the components and the relationships between the components. This ARP package involves five modules: a cache table, queues, an output module, an input module, and a cache-control module. The topics discussed in this section include: Cache Table Queues Output Module Input Module Cache-Control Module TCP/IP Protocol Suite
290
Figure ARP components TCP/IP Protocol Suite
291
Table 7.1 Original cache table used for examples
TCP/IP Protocol Suite
292
Example 2 The ARP output module receives an IP datagram (from the IP layer) with the destination address It checks the cache table and finds that an entry exists for this destination with the RESOLVED state (R in the table). It extracts the hardware address, which is ACAE32, and sends the packet and the address to the data link layer for transmission. The cache table remains the same. TCP/IP Protocol Suite
293
Example 3 Twenty seconds later, the ARP output module receives an IP datagram (from the IP layer) with the destination address It checks the cache table and does not find this destination in the table. The module adds an entry to the table with the state PENDING and the Attempt value 1. It creates a new queue for this destination and enqueues the packet. It then sends an ARP request to the data link layer for this destination. The new cache table is shown in Table 7.2. See Next Slide TCP/IP Protocol Suite
294
Table 7.2 Updated cache table for Example 3
TCP/IP Protocol Suite
295
Example 4 Fifteen seconds later, the ARP input module receives an ARP packet with target protocol (IP) address The module checks the table and finds this address. It changes the state of the entry to RESOLVED and sets the time-out value to 900. The module then adds the target hardware address (E ACA) to the entry. Now it accesses queue 18 and sends all the packets in this queue, one by one, to the data link layer. The new cache table is shown in Table 7.3. See Next Slide TCP/IP Protocol Suite
296
Table 7.3 Updated cache table for Example 4
TCP/IP Protocol Suite
297
Example 5 Twenty-five seconds later, the cache-control module updates every entry. The time-out values for the first three resolved entries are decremented by 60. The time-out value for the last resolved entry is decremented by 25. The state of the next-to-the last entry is changed to FREE because the time-out is zero. For each of the three pending entries, the value of the attempts See Next Slide TCP/IP Protocol Suite
298
Table 7.4 Updated cache table for Example 5
TCP/IP Protocol Suite
299
7.3 RARP RARP finds the logical address for a machine that only knows its physical address. The topics discussed in this section include: Packet Format Encapsulation RARP Server Alternative Solutions to RARP TCP/IP Protocol Suite
300
The RARP request packets are broadcast;
Note: The RARP request packets are broadcast; the RARP reply packets are unicast. TCP/IP Protocol Suite
301
Figure RARP operation TCP/IP Protocol Suite
302
Figure RARP packet TCP/IP Protocol Suite
303
Figure 7.12 Encapsulation of RARP packet
TCP/IP Protocol Suite
304
Internet Protocol Objectives Chapter 8
Upon completion you will be able to: Understand the format and fields of a datagram Understand the need for fragmentation and the fields involved Understand the options available in an IP datagram Be able to perform a checksum calculation Understand the components and interactions of an IP package TCP/IP Protocol Suite
305
Figure 8.1 Position of IP in TCP/IP protocol suite
306
8.1 DATAGRAM A packet in the IP layer is called a datagram, a variable-length packet consisting of two parts: header and data. The header is 20 to 60 bytes in length and contains information essential to routing and delivery. TCP/IP Protocol Suite
307
Figure IP datagram TCP/IP Protocol Suite
308
Figure 8.3 Service type or differentiated services
TCP/IP Protocol Suite
309
The precedence subfield was designed, but never used in version 4.
Note: The precedence subfield was designed, but never used in version 4. TCP/IP Protocol Suite
310
Table 8.1 Types of service TCP/IP Protocol Suite
311
Table 8.2 Default types of service
TCP/IP Protocol Suite
312
Table 8.3 Values for codepoints
TCP/IP Protocol Suite
313
Supplementary Material
Quality of Service TCP/IP Protocol Suite
314
Motivation Internet currently provides only single class of “best-effort” service. No admission control and no assurances about delivery Existing applications are elastic. Tolerate delays and losses Can adapt to congestion Future “real-time” applications may be inelastic. Should we modify these applications to be more adaptive or should we modify the Internet to support inelastic behavior? TCP/IP Protocol Suite
315
Application Types Elastic applications.
Wide range of acceptable rates, although faster is better E.g., data transfers such as FTP Continuous media applications. Lower and upper limit on acceptable performance Sometimes called “tolerant real-time” since they can adapt to the performance of the network E.g., changing frame rate of video stream “Network-aware” applications Hard real-time applications. Require hard limits on performance – “intolerant real-time” E.g., control applications TCP/IP Protocol Suite
316
Improving QOS in IP Networks
IETF groups are working on proposals to provide better QOS control in IP networks, i.e., going beyond best effort to provide some assurance for QOS. Work in Progress includes RSVP, Differentiated Services, and Integrated Services. TCP/IP Protocol Suite
317
Principles for QOS Guarantees
Simple model for sharing and congestion studies (“dumbbell topology”): TCP/IP Protocol Suite
318
Principles for QOS Guarantees (more)
Consider a phone application at 1Mbps and an FTP application sharing a 1.5 Mbps link. Bursts of FTP can congest the router and cause audio packets to be dropped. Want to give priority to audio over FTP. PRINCIPLE 1: Marking of packets is needed for router to distinguish between different classes; and new router policy to treat packets accordingly. TCP/IP Protocol Suite
319
Principles for QOS Guarantees (more)
Applications misbehave (audio sends packets at a rate higher than 1Mbps assumed above). PRINCIPLE 2: provide protection (isolation) for one class from other classes. Require Policing Mechanisms to ensure sources adhere to bandwidth requirements; Marking and Policing need to be done at the edges: TCP/IP Protocol Suite
320
Principles for QOS Guarantees (more)
Alternative to Marking and Policing: allocate a set portion of bandwidth to each application flow; can lead to inefficient use of bandwidth if one of the flows does not use its allocation. PRINCIPLE 3: While providing isolation, it is desirable to use resources as efficiently as possible. TCP/IP Protocol Suite
321
Principles for QOS Guarantees (more)
Cannot support traffic beyond link capacity. PRINCIPLE 4: Need a Call Admission Process; application flow declares its needs, network may block call if it cannot satisfy the needs . TCP/IP Protocol Suite
322
Summary TCP/IP Protocol Suite
323
How to achieve QoS? Per flow (connection) basis Per class basis
Too costly Integrated services Per class basis Easy to implement Router will be less complicated Differentiated services TCP/IP Protocol Suite
324
Figure IP datagram TCP/IP Protocol Suite
325
Note: The total length field defines the total length of the datagram including the header. TCP/IP Protocol Suite
326
Figure 8.4 Encapsulation of a small datagram in an Ethernet frame
TCP/IP Protocol Suite
327
Figure Multiplexing TCP/IP Protocol Suite
328
Table 8.4 Protocols TCP/IP Protocol Suite
329
Example 1 An IP packet has arrived with the first 8 bits as shown: The receiver discards the packet. Why? Solution There is an error in this packet. The 4 left-most bits (0100) show the version, which is correct. The next 4 bits (0010) show the header length; which means (2 × 4 = 8), which is wrong. The minimum number of bytes in the header must be 20. The packet has been corrupted in transmission. TCP/IP Protocol Suite
330
Example 2 In an IP packet, the value of HLEN is 1000 in binary. How many bytes of options are being carried by this packet? Solution The HLEN value is 8, which means the total number of bytes in the header is 8 × 4 or 32 bytes. The first 20 bytes are the base header, the next 12 bytes are the options. TCP/IP Protocol Suite
331
Example 3 In an IP packet, the value of HLEN is 516 and the value of the total length field is How many bytes of data are being carried by this packet? Solution The HLEN value is 5, which means the total number of bytes in the header is 5 × 4 or 20 bytes (no options). The total length is 40 bytes, which means the packet is carrying 20 bytes of data (40 − 20). TCP/IP Protocol Suite
332
Example 4 An IP packet has arrived with the first few hexadecimal digits as shown below: How many hops can this packet travel before being dropped? The data belong to what upper layer protocol? Solution To find the time-to-live field, we skip 8 bytes (16 hexadecimal digits). The time-to-live field is the ninth byte, which is 01. This means the packet can travel only one hop. The protocol field is the next byte (02), which means that the upper layer protocol is IGMP (see Table 8.4). TCP/IP Protocol Suite
333
8.2 FRAGMENTATION The format and size of a frame depend on the protocol used by the physical network. A datagram may have to be fragmented to fit the protocol regulations. The topics discussed in this section include: Maximum Transfer Unit (MTU) Fields Related to Fragmentation TCP/IP Protocol Suite
334
Figure MTU TCP/IP Protocol Suite
335
Table 8.5 MTUs for some networks
TCP/IP Protocol Suite
336
Figure Flags field TCP/IP Protocol Suite
337
Figure 8.8 Fragmentation example
TCP/IP Protocol Suite
338
Figure 8.9 Detailed fragmentation example
TCP/IP Protocol Suite
339
Example 5 A packet has arrived with an M bit value of 0. Is this the first fragment, the last fragment, or a middle fragment? Do we know if the packet was fragmented? Solution If the M bit is 0, it means that there are no more fragments; the fragment is the last one. However, we cannot say if the original packet was fragmented or not. A nonfragmented packet is considered the last fragment. TCP/IP Protocol Suite
340
Example 6 A packet has arrived with an M bit value of 1. Is this the first fragment, the last fragment, or a middle fragment? Do we know if the packet was fragmented? Solution If the M bit is 1, it means that there is at least one more fragment. This fragment can be the first one or a middle one, but not the last one. We don’t know if it is the first one or a middle one; we need more information (the value of the fragmentation offset). See also the next example. TCP/IP Protocol Suite
341
Example 7 A packet has arrived with an M bit value of 1 and a fragmentation offset value of zero. Is this the first fragment, the last fragment, or a middle fragment?. Solution Because the M bit is 1, it is either the first fragment or a middle one. Because the offset value is 0, it is the first fragment. TCP/IP Protocol Suite
342
Example 8 A packet has arrived in which the offset value is 100. What is the number of the first byte? Do we know the number of the last byte? Solution To find the number of the first byte, we multiply the offset value by 8. This means that the first byte number is 800. We cannot determine the number of the last byte unless we know the length of the data. TCP/IP Protocol Suite
343
Example 9 A packet has arrived in which the offset value is 100, the value of HLEN is 5 and the value of the total length field is 100. What is the number of the first byte and the last byte? Solution The first byte number is 100 × 8 = 800. The total length is 100 bytes and the header length is 20 bytes (5 × 4), which means that there are 80 bytes in this datagram. If the first byte number is 800, the last byte number must be 879. TCP/IP Protocol Suite
344
8.3 OPTIONS The header of the IP datagram is made of two parts: a fixed part and a variable part. The variable part comprises the options that can be a maximum of 40 bytes. The topics discussed in this section include: Format Option Types TCP/IP Protocol Suite
345
Figure Option format TCP/IP Protocol Suite
346
Figure 8.11 Categories of options
TCP/IP Protocol Suite
347
Figure 8.12 No operation option
TCP/IP Protocol Suite
348
Figure 8.13 End of option option
TCP/IP Protocol Suite
349
Figure 8.14 Record route option
TCP/IP Protocol Suite
350
Figure 8.15 Record route concept
TCP/IP Protocol Suite
351
Figure 8.16 Strict source route option
TCP/IP Protocol Suite
352
Figure 8.17 Strict source route concept
TCP/IP Protocol Suite
353
Figure 8.18 Loose source route option
Can visit other routers besides those listed. TCP/IP Protocol Suite
354
Figure 8.19 Timestamp option
TCP/IP Protocol Suite
355
Figure 8.20 Use of flag in timestamp
TCP/IP Protocol Suite
356
Figure 8.21 Timestamp concept
TCP/IP Protocol Suite
357
Which of the six options must be copied to each fragment?
Example 10 Which of the six options must be copied to each fragment? Solution We look at the first (left-most) bit of the code for each option. a. No operation: Code is ; not copied. b. End of option: Code is ; not copied. c. Record route: Code is ; not copied. d. Strict source route: Code is ; copied. e. Loose source route: Code is ; copied. f. Timestamp: Code is ; not copied. TCP/IP Protocol Suite
358
Solution We look at the second and third (left-most) bits of the code.
Example 11 Which of the six options are used for datagram control and which are used for debugging and management? Solution We look at the second and third (left-most) bits of the code. a. No operation: Code is ; datagram control. b. End of option: Code is ; datagram control. c. Record route: Code is ; datagram control. d. Strict source route: Code is ; datagram control. e. Loose source route: Code is ; datagram control. f. Time stamp: Code is ; debugging and management control. TCP/IP Protocol Suite
359
Example 12 One of the utilities available in UNIX to check the travelling of the IP packets is ping. In the next chapter, we talk about the ping program in more detail. In this example, we want to show how to use the program to see if a host is available. We ping a server at De Anza College named fhda.edu. The result shows that the IP address of the host is $ ping fhda.edu PING fhda.edu ( ) 56(84) bytes of data. 64 bytes from tiptoe.fhda.edu ( ): .... The result shows the IP address of the host and the number of bytes used. TCP/IP Protocol Suite
360
The result shows the interfaces and IP addresses.
Example 13 We can also use the ping utility with the -R option to implement the record route option. $ ping -R fhda.edu PING fhda.edu ( ) 56(124) bytes of data. 64 bytes from tiptoe.fhda.edu ( ): icmp_seq=0 ttl=62 time=2.70 ms RR: voyager.deanza.fhda.edu ( ) Dcore_G0_3-69.fhda.edu ( ) Dbackup_V13.fhda.edu ( ) tiptoe.fhda.edu ( ) Dbackup_V62.fhda.edu ( ) Dcore_G0_1-6.fhda.edu ( ) voyager.deanza.fhda.edu ( ) The result shows the interfaces and IP addresses. TCP/IP Protocol Suite
361
The result shows the three routers visited.
Example 14 The traceroute utility can also be used to keep track of the route of a packet. $ traceroute fhda.edu traceroute to fhda.edu ( ), 30 hops max, 38 byte packets 1 Dcore_G0_1-6.fhda.edu ( ) ms ms ms 2 Dbackup_V69.fhda.edu ( ) ms ms ms 3 tiptoe.fhda.edu ( ) ms ms ms The result shows the three routers visited. TCP/IP Protocol Suite
362
$ traceroute -g 153.18.251.4 fhda.edu.
Example 15 The traceroute program can be used to implement loose source routing. The -g option allows us to define the routers to be visited, from the source to destination. The following shows how we can send a packet to the fhda.edu server with the requirement that the packet visit the router $ traceroute -g fhda.edu. traceroute to fhda.edu ( ), 30 hops max, 46 byte packets 1 Dcore_G0_1-6.fhda.edu ( ) ms ms ms 2 Dbackup_V69.fhda.edu ( ) ms ms ms TCP/IP Protocol Suite
363
$ traceroute -G 153.18.251.4 fhda.edu.
Example 16 The traceroute program can also be used to implement strict source routing. The -G option forces the packet to visit the routers defined in the command line. The following shows how we can send a packet to the fhda.edu server and force the packet to visit only the router , not any other one. $ traceroute -G fhda.edu. traceroute to fhda.edu ( ), 30 hops max, 46 byte packets 1 Dbackup_V69.fhda.edu ( ) ms ms ms TCP/IP Protocol Suite
364
8.4 CHECKSUM The error detection method used by most TCP/IP protocols is called the checksum. The checksum protects against the corruption that may occur during the transmission of a packet. It is redundant information added to the packet. The topics discussed in this section include: Checksum Calculation at the Sender Checksum Calculation at the Receiver Checksum in the IP Packet TCP/IP Protocol Suite
365
Note: To create the checksum the sender does the following:
❏ The packet is divided into k sections, each of n bits ❏ All sections are added together using 1’s complement arithmetic ❏ The final result is complemented to make the checksum. TCP/IP Protocol Suite
366
Figure 8.22 Checksum concept
TCP/IP Protocol Suite
367
Figure 8.23 Checksum in one’s complement arithmetic
TCP/IP Protocol Suite
368
Example 17 Figure 8.24 shows an example of a checksum calculation for an IP header without options. The header is divided into 16-bit sections. All the sections are added and the sum is complemented. The result is inserted in the checksum field. See Next Slide TCP/IP Protocol Suite
369
Figure 8.24 Example of checksum calculation in binary
TCP/IP Protocol Suite
370
IP Checksum Calculation
TCP/IP Protocol Suite
371
Example 18 Let us do the same example in hexadecimal. Each row has four hexadecimal digits. We calculate the sum first. Note that if an addition results in more than one hexadecimal digit, the right-most digit becomes the current-column digit and the rest are carried to other columns. From the sum, we make the checksum by complementing the sum. However, note that we subtract each digit from 15 in hexadecimal arithmetic (just as we subtract from 1 in binary arithmetic). This means the complement of E (14) is 1 and the complement of 4 is B (11). Figure 8.25 shows the calculation. Note that the result (8BB1) is exactly the same as in Example 17. See Next Slide TCP/IP Protocol Suite TCP/IP Protocol Suite 371
372
Figure 8.25 Example of checksum calculation in hexadecimal
TCP/IP Protocol Suite TCP/IP Protocol Suite 372
373
Note: Check Appendix C for a detailed description of checksum calculation and the handling of carries. TCP/IP Protocol Suite TCP/IP Protocol Suite 373
374
8.5 IP PACKAGE We give an example of a simplified IP software package to show its components and the relationships between the components. This IP package involves eight modules. The topics discussed in this section include: Header-Adding Module Processing Module Queues Routing Table Forwarding Module MTU Table Fragmentation Module Reassembly Table Reassembly Module TCP/IP Protocol Suite
375
Figure IP components TCP/IP Protocol Suite
376
Figure MTU table TCP/IP Protocol Suite
377
Figure 8.28 Reassembly table
TCP/IP Protocol Suite
378
Internet Control Message Protocol
Chapter 9 Internet Control Message Protocol Objectives Upon completion you will be able to: Be familiar with the ICMP message format Know the types of error reporting messages Know the types of query messages Be able to calculate the ICMP checksum Know how to use the ping and traceroute commands Understand the modules and interactions of an ICMP package TCP/IP Protocol Suite
379
Figure 9.1 Position of ICMP in the network layer
TCP/IP Protocol Suite
380
Figure 9.2 ICMP encapsulation
TCP/IP Protocol Suite
381
9.1 TYPES OF MESSAGES ICMP messages are divided into error-reporting messages and query messages. The error-reporting messages report problems that a router or a host (destination) may encounter. The query messages get specific information from a router or another host. TCP/IP Protocol Suite
382
Figure ICMP messages TCP/IP Protocol Suite
383
Table 9.1 ICMP messages TCP/IP Protocol Suite
384
9.2 MESSAGE FORMAT An ICMP message has an 8-byte header and a variable-size data section. Although the general format of the header is different for each message type, the first 4 bytes are common to all. TCP/IP Protocol Suite
385
Figure 9.4 General format of ICMP messages
TCP/IP Protocol Suite
386
9.3 ERROR REPORTING IP, as an unreliable protocol, is not concerned with error checking and error control. ICMP was designed, in part, to compensate for this shortcoming. ICMP does not correct errors, it simply reports them. The topics discussed in this section include: Destination Unreachable Source Quench Time Exceeded Parameter Problem Redirection TCP/IP Protocol Suite
387
ICMP always reports error messages to the original source.
Note: ICMP always reports error messages to the original source. TCP/IP Protocol Suite
388
Figure 9.5 Error-reporting messages
TCP/IP Protocol Suite
389
The following are important points about ICMP error messages:
Note: The following are important points about ICMP error messages: ❏ No ICMP error message will be generated in response to a datagram carrying an ICMP error message. ❏ No ICMP error message will be generated for a fragmented datagram that is not the first fragment. ❏ No ICMP error message will be generated for a datagram having a multicast address. ❏ No ICMP error message will be generated for a datagram having a special address such as or TCP/IP Protocol Suite
390
Figure 9.6 Contents of data field for the error messages
TCP/IP Protocol Suite
391
Figure 9.7 Destination-unreachable format
TCP/IP Protocol Suite
392
ICMP Destination Unreachable
Code 0 = net unreachable; 1 = host unreachable; 2 = protocol unreachable; 3 = port unreachable; 4 = fragmentation needed and DF set; 5 = source route failed. TCP/IP Protocol Suite
393
Other destination-unreachable messages can be created only by routers.
Note: Destination-unreachable messages with codes 2 or 3 can be created only by the destination host. Other destination-unreachable messages can be created only by routers. TCP/IP Protocol Suite
394
Note: A router cannot detect all problems that prevent the delivery of a packet. TCP/IP Protocol Suite
395
There is no flow-control mechanism in the IP protocol.
Note: There is no flow-control mechanism in the IP protocol. TCP/IP Protocol Suite
396
Figure 9.8 Source-quench format
TCP/IP Protocol Suite
397
Note: A source-quench message informs the source that a datagram has been discarded due to congestion in a router or the destination host. The source must slow down the sending of datagrams until the congestion is relieved. TCP/IP Protocol Suite
398
Note: One source-quench message is sent for each datagram that is discarded due to congestion. TCP/IP Protocol Suite
399
Figure 9.9 Time-exceeded message format
TCP/IP Protocol Suite
400
Note: Whenever a router decrements a datagram with a time-to-live value to zero, it discards the datagram and sends a time-exceeded message to the original source. TCP/IP Protocol Suite
401
Note: When the final destination does not receive all of the fragments in a set time, it discards the received fragments and sends a time-exceeded message to the original source. TCP/IP Protocol Suite
402
Note: In a time-exceeded message, code 0 is used only by routers to show that the value of the time-to-live field is zero. Code 1 is used only by the destination host to show that not all of the fragments have arrived within a set time. TCP/IP Protocol Suite
403
Figure 9.10 Parameter-problem message format
If code = 0, the Pointer field identifies the octet where an error was detected. For example, 1 indicates something is wrong with the Type of Service, and (if there are options present) 20 indicates something is wrong with the type code of the first option. TCP/IP Protocol Suite
404
Note: A parameter-problem message can be created by a router or the destination host. TCP/IP Protocol Suite
405
0 = Redirect datagrams for the Network.
Figure Redirection message format Code 0 = Redirect datagrams for the Network. 1 = Redirect datagrams for the Host. 2 = Redirect datagrams for the Type of Service and Network. 3 = Redirect datagrams for the Type of Service and Host. TCP/IP Protocol Suite
406
Figure 9.11 Redirection concept
TCP/IP Protocol Suite
407
Note: A host usually starts with a small routing table that is gradually augmented and updated. One of the tools to accomplish this is the redirection message. TCP/IP Protocol Suite
408
Note: A redirection message is sent from a router to a host on the same local network. TCP/IP Protocol Suite
409
9.4 QUERY ICMP can also diagnose some network problems through the query messages, a group of four different pairs of messages. In this type of ICMP message, a node sends a message that is answered in a specific format by the destination node. The topics discussed in this section include: Echo Request and Reply Timestamp Request and Reply Address-Mask Request and Reply Router Solicitation and Advertisement TCP/IP Protocol Suite
410
Figure Query messages TCP/IP Protocol Suite
411
Note: An echo-request message can be sent by a host or router. An echo-reply message is sent by the host or router which receives an echo-request message. TCP/IP Protocol Suite
412
Note: Echo-request and echo-reply messages can be used by network managers to check the operation of the IP protocol. TCP/IP Protocol Suite
413
Note: Echo-request and echo-reply messages can test the reachability of a host. This is usually done by invoking the ping command. TCP/IP Protocol Suite
414
Figure 9.14 Echo-request and echo-reply messages
TCP/IP Protocol Suite
415
Figure 9.15 Timestamp-request and timestamp-reply message format
Milliseconds from midnight in Universal Time TCP/IP Protocol Suite
416
Round trip time Sending time=(receiver receive timestamp)-(original timestamp) Receiving time=(sender receive time)-(transmit timestamp) RTT=(sending time) + (receiving time) TCP/IP Protocol Suite
417
Note: Timestamp-request and timestamp-reply messages can be used to calculate the round-trip time between a source and a destination machine even if their clocks are not synchronized. TCP/IP Protocol Suite
418
Sending time=(receiver receive timestamp)+t-(original timestamp)
With clock difference t: (sender clock)=(receiver-clock)+t Sending time=(receiver receive timestamp)+t-(original timestamp) Receiving time=(sender receive time)-[(transmit timestamp)+t] RTT=(sending time) + (receiving time) TCP/IP Protocol Suite
419
Note: The timestamp-request and timestamp- reply messages can be used to synchronize two clocks in two machines if the exact one-way time duration is known. Time difference= receive time-(original time+one-way time duration) TCP/IP Protocol Suite
420
Figure 9.16 Mask-request and mask-reply message format
TCP/IP Protocol Suite
421
Figure 9.17 Router-solicitation message format
TCP/IP Protocol Suite
422
=0 default router Figure 9.18 Router-advertisement message format
TCP/IP Protocol Suite
423
9.5 CHECKSUM In ICMP the checksum is calculated over the entire message (header and data). The topics discussed in this section include: Checksum Calculation Checksum Testing TCP/IP Protocol Suite
424
Example 1 Figure 9.19 shows an example of checksum calculation for a simple echo-request message (see Figure 9.14). We randomly chose the identifier to be 1 and the sequence number to be 9. The message is divided into 16-bit (2-byte) words. The words are added together and the sum is complemented. Now the sender can put this value in the checksum field. See Next Slide TCP/IP Protocol Suite
425
Figure 9.19 Example of checksum calculation
TCP/IP Protocol Suite
426
9.6 DEBUGGING TOOLS We introduce two tools that use ICMP for debugging: ping and traceroute. The topics discussed in this section include: Ping Traceroute TCP/IP Protocol Suite
427
Example 2 We use the ping program to test the server fhda.edu. The result is shown below: $ ping fhda.edu PING fhda.edu ( ) 56 (84) bytes of data. 64 bytes from tiptoe.fhda.edu ( ): icmp_seq=0 ttl=62 time=1.91 ms 64 bytes from tiptoe.fhda.edu ( ): icmp_seq=1 ttl=62 time=2.04 ms 64 bytes from tiptoe.fhda.edu ( ): icmp_seq=2 ttl=62 time=1.90 ms 64 bytes from tiptoe.fhda.edu ( ): icmp_seq=3 ttl=62 time=1.97 ms 64 bytes from tiptoe.fhda.edu ( ): icmp_seq=4 ttl=62 time=1.93 ms See Next Slide TCP/IP Protocol Suite
428
Example 2 (Continued) 64 bytes from tiptoe.fhda.edu ( ): icmp_seq=5 ttl=62 time=2.00 ms 64 bytes from tiptoe.fhda.edu ( ): icmp_seq=6 ttl=62 time=1.94 ms 64 bytes from tiptoe.fhda.edu ( ): icmp_seq=7 ttl=62 time=1.94 ms 64 bytes from tiptoe.fhda.edu ( ): icmp_seq=8 ttl=62 time=1.97 ms 64 bytes from tiptoe.fhda.edu ( ): icmp_seq=9 ttl=62 time=1.89 ms 64 bytes from tiptoe.fhda.edu ( ): icmp_seq=10 ttl=62 time=1.98 ms --- fhda.edu ping statistics packets transmitted, 11 received, 0% packet loss, time 10103ms rtt min/avg/max = 1.899/1.955/2.041 ms TCP/IP Protocol Suite
429
Example 3 For the this example, we want to know if the adelphia.net mail server is alive and running. The result is shown below: $ ping mail.adelphia.net PING mail.adelphia.net ( ) 56(84) bytes of data. 64 bytes from mail.adelphia.net ( ): icmp_seq=0 ttl=48 time=85.4 ms 64 bytes from mail.adelphia.net ( ): icmp_seq=1 ttl=48 time=84.6 ms 64 bytes from mail.adelphia.net ( ): icmp_seq=2 ttl=48 time=84.9 ms 64 bytes from mail.adelphia.net ( ): icmp_seq=3 ttl=48 time=84.3 ms 64 bytes from mail.adelphia.net ( ): icmp_seq=4 ttl=48 time=84.5 ms See Next Slide TCP/IP Protocol Suite
430
Example 3 (Continued) 64 bytes from mail.adelphia.net ( ): icmp_seq=5 ttl=48 time=84.7 ms 64 bytes from mail.adelphia.net ( ): icmp_seq=6 ttl=48 time=84.6 ms 64 bytes from mail.adelphia.net ( ): icmp_seq=7 ttl=48 time=84.7 ms 64 bytes from mail.adelphia.net ( ): icmp_seq=8 ttl=48 time=84.4 ms 64 bytes from mail.adelphia.net ( ): icmp_seq=9 ttl=48 time=84.2 ms 64 bytes from mail.adelphia.net ( ): icmp_seq=10 ttl=48 time=84.9 ms 64 bytes from mail.adelphia.net ( ): icmp_seq=11 ttl=48 time=84.6 ms 64 bytes from mail.adelphia.net ( ): icmp_seq=12 ttl=48 time=84.5 ms --- mail.adelphia.net ping statistics --- 14 packets transmitted, 13 received, 7% packet loss, time 13129ms rtt min/avg/max/mdev = /84.694/85.469 TCP/IP Protocol Suite
431
Figure 9.20 The traceroute program operation
TCP/IP Protocol Suite
432
Example 4 We use the traceroute program to find the route from the computer voyager.deanza.edu to the server fhda.edu. The following shows the result: $ traceroute fhda.edu traceroute to fhda.edu ( ), 30 hops max, 38 byte packets 1 Dcore.fhda.edu ( ) ms ms ms 2 Dbackup.fhda.edu ( ) ms ms ms 3 tiptoe.fhda.edu ( ) ms ms ms See Next Slide TCP/IP Protocol Suite
433
Example 4 (Continued) The un-numbered line after the command shows that the destination is The TTL value is 30 hops. The packet contains 38 bytes: 20 bytes of IP header, 8 bytes of UDP header, and 10 bytes of application data. The application data is used by traceroute to keep track of the packets. The first line shows the first router visited. The router is named Dcore.fhda.edu with IP address The first round trip time was milliseconds, the second was milliseconds, and the third was milliseconds. The second line shows the second router visited. The router is named Dbackup.fhda.edu with IP address The three round trip times are also shown. The third line shows the destination host. We know that this is the destination host because there are no more lines. The destination host is the server fhda.edu, but it is named tiptoe. fhda.edu with the IP address The three round trip times are also shown. TCP/IP Protocol Suite
434
In this example, we trace a longer route, the route to xerox.com
$ traceroute xerox.com traceroute to xerox.com ( ), 30 hops max, 38 byte packets 1 Dcore.fhda.edu ( ) ms ms ms 2 Ddmz.fhda.edu ( ) ms ms ms ... 18 alpha.Xerox.COM ( ) ms ms ms Here there are 17 hops between source and destination. Note that some round trip times look unusual. It could be that a router is too busy to process the packet immediately. TCP/IP Protocol Suite
435
Example 6 An interesting point is that a host can send a traceroute packet to itself. This can be done by specifying the host as the destination. The packet goes to the loopback address as we expect. $ traceroute voyager.deanza.edu traceroute to voyager.deanza.edu ( ), 30 hops max, 38 byte packets 1 voyager ( ) ms ms ms TCP/IP Protocol Suite
436
Example 7 Finally, we use the traceroute program to find the route between fhda.edu and mhhe.com (McGraw-Hill server). We notice that we cannot find the whole route. When traceroute does not receive a response within 5 seconds, it prints an asterisk to signify a problem, and then tries the next hop.. $ traceroute mhhe.com traceroute to mhhe.com ( ), 30 hops max, 38 byte packets 1 Dcore.fhda.edu ( ) ms ms ms 2 Ddmz.fhda.edu ( ) ms ms ms 3 Cinic.fhda.edu ( ) ms ms ms * * * 17 * * * TCP/IP Protocol Suite
437
9.7 ICMP PACKAGE To give an idea of how ICMP can handle the sending and receiving of ICMP messages, we present our version of an ICMP package made of two modules: an input module and an output module. The topics discussed in this section include: Input Module Output Module TCP/IP Protocol Suite
438
Figure ICMP package TCP/IP Protocol Suite
439
User Datagram Protocol
Chapter 11 User Datagram Protocol Objectives Upon completion you will be able to: Be able to explain process-to-process communication Know the format of a UDP user datagram Be able to calculate a UDP checksum Understand the operation of UDP Know when it is appropriate to use UDP Understand the modules in a UDP package TCP/IP Protocol Suite
440
Figure 11.1 Position of UDP in the TCP/IP protocol suite
441
11.1 PROCESS-TO-PROCESS COMMUNICATION
Before we examine UDP, we must first understand host-to-host communication and process-to-process communication and the difference between them. The topics discussed in this section include: Port Numbers Socket Addresses TCP/IP Protocol Suite
442
Figure UDP versus IP TCP/IP Protocol Suite
443
Figure Port numbers request response TCP/IP Protocol Suite
444
Figure 11.4 IP addresses versus port numbers
TCP/IP Protocol Suite
445
Figure ICANN ranges ICANN: Internet Corporation for Assigned Names and Numbers TCP/IP Protocol Suite
446
The well-known port numbers are less than 1024.
Note: The well-known port numbers are less than 1024. TCP/IP Protocol Suite
447
Table 11.1 Well-known ports used with UDP
TCP/IP Protocol Suite
448
$ grep tftp /etc/services tftp 69/tcp tftp 69/udp
Example 1 In UNIX, the well-known ports are stored in a file called /etc/services. Each line in this file gives the name of the server and the well-known port number. We can use the grep utility to extract the line corresponding to the desired application. The following shows the port for TFTP. Note TFTP can use port 69 on either UDP or TCP. $ grep tftp /etc/services tftp 69/tcp tftp 69/udp See Next Slide TCP/IP Protocol Suite
449
Example 1 (Continued) SNMP uses two port numbers (161 and 162), each for a different purpose, as we will see in Chapter 21. $ grep snmp /etc/services snmp 161/tcp #Simple Net Mgmt Proto snmp 161/udp #Simple Net Mgmt Proto snmptrap 162/udp #Traps for SNMP TCP/IP Protocol Suite
450
Figure Socket address TCP/IP Protocol Suite
451
USER DATAGRAM UDP packets are called user datagrams and have a fixed-size header of 8 bytes. TCP/IP Protocol Suite
452
Figure 11.7 User datagram format
TCP/IP Protocol Suite
453
UDP length = IP length − IP header’s length
Note: UDP length = IP length − IP header’s length TCP/IP Protocol Suite
454
CHECKSUM UDP checksum calculation is different from the one for IP and ICMP. Here the checksum includes three sections: a pseudoheader, the UDP header, and the data coming from the application layer. The topics discussed in this section include: Checksum Calculation at Sender Checksum Calculation at Receiver Optional Use of the Checksum TCP/IP Protocol Suite
455
Figure 11.8 Pseudoheader for checksum calculation
TCP/IP Protocol Suite
456
Figure 11.9 Checksum calculation of a simple UDP user datagram
TCP/IP Protocol Suite
457
Optional Use of the Checksum
The checksum is optional. If not used, the field is filled with 0s. TCP/IP Protocol Suite
458
UDP OPERATION UDP uses concepts common to the transport layer. These concepts will be discussed here briefly, and then expanded in the next chapter on the TCP protocol. The topics discussed in this section include: Connectionless Services Flow and Error Control Encapsulation and Decapsulation Queuing Multiplexing and Demultiplexing TCP/IP Protocol Suite
459
Connectionless Services
UDP provides connectionless service. This means that each user datagram sent by UDP is an independent datagram. No connection establishment, no connection termination, each datagram can travel on a different path. TCP/IP Protocol Suite
460
Connectionless Services
We cannot send a stream of data to UDP and expect UDP to chop them into different related user datagrams. Instead each datagram must be small enough to fit into one user datagram. Only those processes sending short messages should use UDP. TCP/IP Protocol Suite
461
There is no flow control.
Flow and Error Control There is no flow control. There is no error control except for the checksum. TCP/IP Protocol Suite
462
Figure 11.10 Encapsulation and decapsulation
TCP/IP Protocol Suite
463
Figure Queues in UDP TCP/IP Protocol Suite
464
Figure 11.12 Multiplexing and demultiplexing
TCP/IP Protocol Suite
465
USE OF UDP We discuss some uses of the UDP protocol in this section. UDP is suitable for a process that requires simple request-response communication with little concern for flow and error control. UDP is a suitable transport protocol for multicasting. UDP is used for network management such as SNMP. UDP is used in routing protocols such as RIP. TCP/IP Protocol Suite
466
UDP PACKAGE To show how UDP handles the sending and receiving of UDP packets, we present a simple version of the UDP package. The UDP package involves five components: a control-block table, input queues, a control-block module, an input module, and an output module. The topics discussed in this section include: Control-Block Table Input Queues Control-Block Module Input Module Output Module TCP/IP Protocol Suite
467
Figure UDP design TCP/IP Protocol Suite
468
Table 11.2 The control-block table at the beginning of examples
TCP/IP Protocol Suite
469
Example 2 The first activity is the arrival of a user datagram with destination port number 52,012. The input module searches for this port number and finds it. Queue number 38 has been assigned to this port, which means that the port has been previously used. The input module sends the data to queue 38. The control-block table does not change. TCP/IP Protocol Suite
470
Example 3 After a few seconds, a process starts. It asks the operating system for a port number and is granted port number 52,014. Now the process sends its ID (4,978) and the port number to the control-block module to create an entry in the table. The module takes the first FREE entry and inserts the information received. The module does not allocate a queue at this moment because no user datagrams have arrived for this destination (see Table 11.3). See Next Slide TCP/IP Protocol Suite
471
Table 11.3 Control-block table after Example 3
TCP/IP Protocol Suite
472
Example 4 A user datagram now arrives for port 52,011. The input module checks the table and finds that no queue has been allocated for this destination since this is the first time a user datagram has arrived for this destination. The module creates a queue and gives it a number (43). See Table 11.4. See Next Slide TCP/IP Protocol Suite
473
Table 11.4 Control-block after Example 4
TCP/IP Protocol Suite
474
Example 5 After a few seconds, a user datagram arrives for port 52,222. The input module checks the table and cannot find an entry for this destination. The user datagram is dropped and a request is made to ICMP to send an “unreachable port” message to the source. TCP/IP Protocol Suite
475
Transmission Control Protocol
Chapter 12 Transmission Control Protocol Objectives Upon completion you will be able to: Be able to name and understand the services offered by TCP Understand TCP’s flow and error control and congestion control Be familiar with the fields in a TCP segment Understand the phases in a connection-oriented connection Understand the TCP transition state diagram Be able to name and understand the timers used in TCP Be familiar with the TCP options TCP/IP Protocol Suite
476
Figure 12.1 TCP/IP protocol suite
477
TCP SERVICES We explain the services offered by TCP to the processes at the application layer. The topics discussed in this section include: Process-to-Process Communication Stream Delivery Service Full-Duplex Communication Connection-Oriented Service Reliable Service TCP/IP Protocol Suite
478
Table 12.1 Well-known ports used by TCP
TCP/IP Protocol Suite
479
$ grep ftp /etc/services ftp-data 20/tcp ftp-control 21/tcp
Example 1 As we said in Chapter 11, in UNIX, the well-known ports are stored in a file called /etc/services. Each line in this file gives the name of the server and the well-known port number. We can use the grep utility to extract the line corresponding to the desired application. The following shows the ports for FTP. $ grep ftp /etc/services ftp-data 20/tcp ftp-control 21/tcp TCP/IP Protocol Suite
480
Stream delivery service
Figure Stream delivery Stream delivery service TCP/IP Protocol Suite
481
Figure 12.3 Sending and receiving buffers
TCP/IP Protocol Suite
482
Figure TCP segments TCP/IP Protocol Suite
483
TCP Services Process-to-Process Communication Stream Delivery Service
Full-Duplex Communication Connection-Oriented Service Establish a connection Data can be exchanged in both direction Close (terminate) the connection Reliable Service TCP/IP Protocol Suite
484
TCP FEATURES To provide the services mentioned in the previous section, TCP has several features that are briefly summarized in this section. The topics discussed in this section include: Numbering System Flow Control Error Control Congestion Control TCP/IP Protocol Suite
485
Note: The bytes of data being transferred in each connection are numbered by TCP. The numbering starts with a randomly generated number. TCP/IP Protocol Suite
486
Solution The following shows the sequence number for each segment:
Example 2 Suppose a TCP connection is transferring a file of 5000 bytes. The first byte is numbered What are the sequence numbers for each segment if data is sent in five segments, each carrying 1000 bytes? Solution The following shows the sequence number for each segment: Segment 1 ➡ Sequence Number: 10,001 (range: 10,001 to 11,000) Segment 2 ➡ Sequence Number: 11,001 (range: 11,001 to 12,000) Segment 3 ➡ Sequence Number: 12,001 (range: 12,001 to 13,000) Segment 4 ➡ Sequence Number: 13,001 (range: 13,001 to 14,000) Segment 5 ➡ Sequence Number: 14,001 (range: 14,001 to 15,000) TCP/IP Protocol Suite
487
Note: The value in the sequence number field of a segment defines the number of the first data byte contained in that segment. TCP/IP Protocol Suite
488
The acknowledgment number is cumulative.
Note: The value of the acknowledgment field in a segment defines the number of the next byte a party expects to receive. The acknowledgment number is cumulative. TCP/IP Protocol Suite
489
Flow Control TCP, unlike UDP, provides flow control.
The receiver of the data controls how much data are to be sent by the sender. TCP/IP Protocol Suite
490
Error Control To provide reliable service, TCP implements an error control mechanism. A segment is the unit of error detection. Error control in TCP is byte-oriented. TCP/IP Protocol Suite
491
Congestion Control TCP, unlike UDP, takes into account congestion in the network. The amount of data sent by a sender is not only controlled by the receiver (flow control), but is also determined by the level of congestion in the network. TCP/IP Protocol Suite
492
12.3 SEGMENT A packet in TCP is called a segment
The topics discussed in this section include: Format Encapsulation TCP/IP Protocol Suite
493
Figure 12.5 TCP segment format
TCP/IP Protocol Suite
494
Figure Control field TCP/IP Protocol Suite
495
I Table 12.2 Description of flags in the control field
TCP/IP Protocol Suite
496
Figure 12.7 Pseudoheader added to the TCP datagram
TCP/IP Protocol Suite
497
The inclusion of the checksum in TCP is mandatory.
Note: The inclusion of the checksum in TCP is mandatory. TCP/IP Protocol Suite
498
Figure 12.8 Encapsulation and decapsulation
TCP/IP Protocol Suite
499
A TCP CONNECTION TCP is connection-oriented. A connection-oriented transport protocol establishes a virtual path between the source and destination. All of the segments belonging to a message are then sent over this virtual path. A connection-oriented transmission requires three phases: connection establishment, data transfer, and connection termination. The topics discussed in this section include: Connection Establishment Data Transfer Connection Termination Connection Reset TCP/IP Protocol Suite
500
Figure 12.9 Connection establishment using three-way handshaking
TCP/IP Protocol Suite
501
A SYN segment cannot carry data, but it consumes one sequence number.
Note: A SYN segment cannot carry data, but it consumes one sequence number. TCP/IP Protocol Suite
502
Note: A SYN + ACK segment cannot carry data, but does consume one sequence number. TCP/IP Protocol Suite
503
An ACK segment, if carrying no data, consumes no sequence number.
Note: An ACK segment, if carrying no data, consumes no sequence number. TCP/IP Protocol Suite
504
Figure Data transfer TCP/IP Protocol Suite
505
Note: The FIN segment consumes one sequence number if it does not carry data. TCP/IP Protocol Suite
506
Figure 12.11 Connection termination using three-way handshaking
+1 TCP/IP Protocol Suite
507
Note: The FIN + ACK segment consumes one sequence number if it does not carry data. TCP/IP Protocol Suite
508
Figure Half-close TCP/IP Protocol Suite
509
12.5 STATE TRANSITION DIAGRAM
To keep track of all the different events happening during connection establishment, connection termination, and data transfer, the TCP software is implemented as a finite state machine. . The topics discussed in this section include: Scenarios TCP/IP Protocol Suite
510
Table States for TCP TCP/IP Protocol Suite
511
server client Figure 12.13 State transition diagram
+ + + + MSL: Maximum Segment Lifetime TCP/IP Protocol Suite
512
Figure 12.14 Common scenario
TCP/IP Protocol Suite
513
Figure 12.14 Common scenario
4-way handshake TCP/IP Protocol Suite
514
The common value for MSL is between 30 seconds and 1 minute.
Note: The common value for MSL is between 30 seconds and 1 minute. TCP/IP Protocol Suite
515
Figure 12.15 Three-way handshake
TCP/IP Protocol Suite
516
Figure 12.16 Simultaneous open
TCP/IP Protocol Suite
517
Figure 12.17 Simultaneous close
TCP/IP Protocol Suite
518
Figure 12.18 Denying a connection
TCP/IP Protocol Suite
519
Figure 12.19 Aborting a connection
TCP/IP Protocol Suite
520
FLOW CONTROL Flow control regulates the amount of data a source can send before receiving an acknowledgment from the destination. TCP defines a window that is imposed on the buffer of data delivered from the application program. The topics discussed in this section include: Sliding Window Protocol Silly Window Syndrome TCP/IP Protocol Suite
521
Figure Sliding window TCP/IP Protocol Suite
522
TCP’s sliding windows are byte oriented.
Note: A sliding window is used to make transmission more efficient as well as to control the flow of data so that the destination does not become overwhelmed with data. TCP’s sliding windows are byte oriented. TCP/IP Protocol Suite
523
Example 3 What is the value of the receiver window (rwnd) for host A if the receiver, host B, has a buffer size of 5,000 bytes and 1,000 bytes of received and unprocessed data? Solution The value of rwnd = 5,000 − 1,000 = 4,000. Host B can receive only 4,000 bytes of data before overflowing its buffer. Host B advertises this value in its next segment to A. TCP/IP Protocol Suite
524
Example 4 What is the size of the window for host A if the value of rwnd is 3,000 bytes and the value of cwnd is 3,500 bytes? Solution The size of the window is the smaller of rwnd and cwnd, which is 3,000 bytes. TCP/IP Protocol Suite
525
Example 5 Figure shows an unrealistic example of a sliding window. The sender has sent bytes up to 202. We assume that cwnd is 20 (in reality this value is thousands of bytes). The receiver has sent an acknowledgment number of 200 with an rwnd of 9 bytes (in reality this value is thousands of bytes). The size of the sender window is the minimum of rwnd and cwnd or 9 bytes. Bytes 200 to 202 are sent, but not acknowledged. Bytes 203 to 208 can be sent without worrying about acknowledgment. Bytes 209 and above cannot be sent. TCP/IP Protocol Suite
526
Figure Example 5 TCP/IP Protocol Suite
527
Example 6 In Figure the server receives a packet with an acknowledgment value of 202 and an rwnd of 9. The host has already sent bytes 203, 204, and 205. The value of cwnd is still 20. Show the new window. Solution Figure shows the new window. Note that this is a case in which the window closes from the left and opens from the right by an equal number of bytes; the size of the window has not been changed. The acknowledgment value, 202, declares that bytes 200 and 201 have been received and the sender needs not worry about them; the window can slide over them. TCP/IP Protocol Suite
528
Figure Example 6 TCP/IP Protocol Suite
529
Example 7 In Figure the sender receives a packet with an acknowledgment value of 206 and an rwnd of 12. The host has not sent any new bytes. The value of cwnd is still 20. Show the new window. Solution The value of rwnd is less than cwnd, so the size of the window is 12. Figure shows the new window. Note that the window has been opened from the right by 7 and closed from the left by 4; the size of the window has increased. TCP/IP Protocol Suite
530
Figure Example 7 TCP/IP Protocol Suite
531
Example 8 In Figure the host receives a packet with an acknowledgment value of 210 and an rwnd of 5. The host has sent bytes 206, 207, 208, and 209. The value of cwnd is still 20. Show the new window. Solution The value of rwnd is less than cwnd, so the size of the window is 5. Figure shows the situation. Note that this is a case not allowed by most implementations. Although the sender has not sent bytes 215 to 217, the receiver does not know this. TCP/IP Protocol Suite
532
Figure Example 8 TCP/IP Protocol Suite
533
Example 9 How can the receiver avoid shrinking the window in the previous example? Solution The receiver needs to keep track of the last acknowledgment number and the last rwnd. If we add the acknowledgment number to rwnd we get the byte number following the right wall. If we want to prevent the right wall from moving to the left (shrinking), we must always have the following relationship. new ack + new rwnd ≥ last ack + last rwnd or new rwnd ≥ (last ack + last rwnd) − new ack TCP/IP Protocol Suite
534
Note: To avoid shrinking the sender window, the receiver must wait until more space is available in its buffer. TCP/IP Protocol Suite
535
Note: Some points about TCP’s sliding windows:
❏ The size of the window is the lesser of rwnd and cwnd. ❏ The source does not have to send a full window’s worth of data. ❏ The window can be opened or closed by the receiver, but should not be shrunk. ❏ The destination can send an acknowledgment at any time as long as it does not result in a shrinking window. ❏ The receiver can temporarily shut down the window; the sender, however, can always send a segment of one byte after the window is shut down. (to prevent the zero window syndrome) TCP/IP Protocol Suite
536
Silly Window Syndrome If TCP sends segments containing only 1 byte of data, it means that a 41-byte datagram (20 bytes of TCP header and 20 bytes of IP header) transfers only 1 byte of data. The overhead is 41/1, which indicates that we are using the capacity of the network very inefficiently. This problem is called the silly window syndrome. TCP/IP Protocol Suite
537
Syndrome Created by the Sender
The sending TCP may create a silly window syndrome if it is serving an application that creates data slowly, for example,1 byte at a time. The solution is to prevent the sending TCP from sending the data byte by byte. The problem is how long should the sending TCP wait (for data from application)? TCP/IP Protocol Suite
538
Nagle’s Algorithm The sending TCP sends the first piece of data it receives from the sending application even if it is only 1 byte. Wait until either there are enough data from application or an ack from receiver comes back. TCP/IP Protocol Suite
539
Syndrome Created by the Receiver
The receiving TCP may create a silly window syndrome if it is serving an application that consumes data slowly, for example,1 byte at a time. Two solutions: Clark’s solution and delayed acknowledgement TCP/IP Protocol Suite
540
Clark’s Solution Send an acknowledgement as soon as the data arrives, but to announce a window size of zero until either there is enough space for a segment of maximum size or until the buffer is half empty TCP/IP Protocol Suite
541
Delayed Acknowledgement
Delay ack until there is enough space But may force the sender to retransmit if delayed too long Solution: the ack should not be delayed by more than 500 ms TCP/IP Protocol Suite
542
ERROR CONTROL TCP provides reliability using error control, which detects corrupted, lost, out-of-order, and duplicated segments. Error control in TCP is achieved through the use of the checksum, acknowledgment, and time-out. The topics discussed in this section include: Checksum Acknowledgment Acknowledgment Type Retransmission Out-of-Order Segments Some Scenarios TCP/IP Protocol Suite
543
Checksum (mandatory in TCP)
TCP/IP Protocol Suite
544
ACK segments do not consume sequence numbers and are not acknowledged.
Note: ACK segments do not consume sequence numbers and are not acknowledged. TCP/IP Protocol Suite
545
Generating Acknowledgements
Rule 1: When one end sends a data segment to the other end, it must include (piggyback) an ack Rule 2: Delay ack for at most 500 ms if there is only one segment to ack Rule 3: If there are two segments, ack immediately TCP/IP Protocol Suite
546
Generating Acknowledgements
Rule 4: Higher out of order sequence number segment received, ack immediately Rule 5: When a missing segment arrives, ack immediately Rule 6: If a duplicate segment arrives, ack immediately TCP/IP Protocol Suite
547
Acknowledgement Type Accumulative Acknowledgement: only advise the next byte to receive, out of order segments are not acknowledged Selective Acknowledgement (SACK): acknowledge the out of sequence (but in receiving window) segment (implemented using TCP option) TCP/IP Protocol Suite
548
Retransmission The source TCP starts one retransmission time-out (RTO) timer for each segment sent. If RTO expires, the segment is retransmitted. Pure ack segment is not retransmitted RTO is adjusted dynamically according to RTT( Round Trip Time) TCP/IP Protocol Suite
549
Retransmission Fast retransmission: retransmit the missing segments after three duplicate acks TCP/IP Protocol Suite
550
Note: In modern implementations, a retransmission occurs if the retransmission timer expires or three duplicate ACK segments have arrived. TCP/IP Protocol Suite
551
No retransmission timer is set for an ACK segment.
Note: No retransmission timer is set for an ACK segment. TCP/IP Protocol Suite
552
Note: Data may arrive out of order and be temporarily stored by the receiving TCP, but TCP guarantees that no out-of-order segment is delivered to the process. TCP/IP Protocol Suite
553
Figure 12.25 Normal operation
TCP/IP Protocol Suite
554
Figure Lost segment TCP/IP Protocol Suite
555
The receiver TCP delivers only ordered data to the process.
Note: The receiver TCP delivers only ordered data to the process. TCP/IP Protocol Suite
556
Figure 12.27 Fast retransmission
TCP/IP Protocol Suite
557
Figure 12.28 Lost acknowledgment
TCP/IP Protocol Suite
558
Figure 12.29 Lost acknowledgment corrected by resending a segment
TCP/IP Protocol Suite
559
Note: Lost acknowledgments may create deadlock if they are not properly handled. TCP/IP Protocol Suite
560
Deadlock Created by Lost Ack
Receiver first advises a window of 0. Later receiver advises a window size by sending an ack (because receiver has no data to send) The ack is lost. (ack is not acked or retransmitted) Sender waits for window advertisement. Receiver waits for data. (A deadlock) TCP/IP Protocol Suite
561
CONGESTION CONTROL Congestion control refers to the mechanisms and techniques to keep the load below the capacity. The topics discussed in this section include: Network Performance Congestion Control Mechanisms Congestion Control in TCP TCP/IP Protocol Suite
562
Figure Router queues TCP/IP Protocol Suite
563
Figure 12.31 Packet delay and network load
TCP/IP Protocol Suite
564
Figure 12.32 Throughput versus network load
TCP/IP Protocol Suite
565
Congestion Control Mechanism
Open-loop (prevent congestion) Retransmission policy: designed to optimize efficiency and at the same time prevent congestion Acknowledgement policy: do not acknowledge every packet received Discard policy: discard fault-tolerant packet first TCP/IP Protocol Suite
566
Congestion Control Mechanism
Closed-Loop (alleviate congestion after it happens) Back pressure: when a router is congested, it can inform the previous upstream router to reduce the rate Choke point: a choke packet is sent to the source to inform it of the congestion Implicit signaling: e.g., delay in ack Explicit signaling: set a bit in the packet to inform sender or receiver TCP/IP Protocol Suite
567
Congestion Control in TCP
Actual window size=minimum (rwnd,cwnd) Congestion policy slow start: exponential increase congestion avoidance: additive increase congestion detection: multiplicative decrease TCP/IP Protocol Suite
568
Figure 12.33 Slow start, exponential increase
TCP/IP Protocol Suite
569
Note: In the slow start algorithm, the size of the congestion window increases exponentially until it reaches a threshold. TCP/IP Protocol Suite
570
Congestion Avoidance When the size of the congestion window reaches the slow start threshold, the slow start phase stops and the congestion avoidance phase begins. In congestion avoidance, each time a whole window of segments is acknowledged, the size of the congestion window is increased by 1. TCP/IP Protocol Suite
571
Figure 12.34 Congestion avoidance, additive increase
TCP/IP Protocol Suite
572
Note: In the congestion avoidance algorithm the size of the congestion window increases additively until congestion is detected. TCP/IP Protocol Suite
573
Congestion Detection Congestion detection by RTO time-out
Set the threshold to half of the current window size Set cwnd to 1 Start the slow-start phase again TCP/IP Protocol Suite
574
Congestion Detection Congestion detection by three ACKs
Set the threshold to half of the current window size Set cwnd to the value of the threshold Start the congestion avoidance phase TCP/IP Protocol Suite
575
Note: Most implementations react differently to congestion detection:
❏ If detection is by time-out, a new slow start phase starts. ❏ If detection is by three ACKs, a new congestion avoidance phase starts. TCP/IP Protocol Suite
576
Figure 12.35 TCP congestion policy summary
TCP/IP Protocol Suite
577
Figure 12.36 Congestion example
TCP/IP Protocol Suite
578
TCP TIMERS To perform its operation smoothly, most TCP implementations use at least four timers. The topics discussed in this section include: Retransmission Timer Persistence Timer Keepalive Timer TIME-WAIT Timer TCP/IP Protocol Suite
579
Figure TCP timers TCP/IP Protocol Suite
580
Retransmission Timer When TCP sends a segment, it creates a retransmission timer for that particular segment. Two situations may occur: If an ACK is received before timer goes off, the timer is destroyed If the timer goes off before the ACK is received, the segment is retransmitted and the timer is reset TCP/IP Protocol Suite
581
Round Trip Time (RTT) Measured RTT (RTTM)
How long it takes to send a segment and receive an acknowledgement for it Remember that the segments and their acknowledgements do not have a one-to-one relationship, several segments may be acknowledged together TCP/IP Protocol Suite
582
Note: In TCP, there can be only be one RTT measurement in progress at any time. TCP/IP Protocol Suite
583
Round Trip Time (RTT) Smoothed RTT (RTTS)
The fluctuation in RTTM is too high Use weighted average instead The value of a is implementation-dependent, but it is normally set to 1/8. TCP/IP Protocol Suite
584
Round Trip Time (RTT) RTT Deviation (RTTD)
The value of b is implementation-dependent, but it is normally set to 1/4. TCP/IP Protocol Suite
585
Round Trip Time (RTT) Retransmission Timeout (RTO)
TCP/IP Protocol Suite
586
Example 10 Let us give a hypothetical example. Figure shows part of a connection. The figure shows the connection establishment and part of the data transfer phases. 1. When the SYN segment is sent, there is no value for RTTM , RTTS , or RTTD . The value of RTO is set to 6.00 seconds. 2. When the SYN+ACK segment arrives, RTTM is measured and is equal to 1.5 seconds. The next slide shows the values of these variables: RTTM = RTTS = 1.5 RTTD = 1.5 / 2 = RTO = = 4.5 TCP/IP Protocol Suite
587
Example 10 (continued) 3.When the first data segment is sent, a new RTT measurement starts. Note that the sender does not start an RTT measurement when it sends the ACK segment, because it does not consume a sequence number and there is no time-out. No RTT measurement starts for the second data segment because a measurement is already in progress. RTTM = RTTS = 7/8 (1.5) + 1/8 (2.5) = RTTD = 3/4 (0.75) + 1/4 |1.625 − 2.5| = RTO = (0.78) = 4.74 TCP/IP Protocol Suite
588
Figure Example 10 TCP/IP Protocol Suite
589
Note: Karn’s Algorithm: TCP does not consider the RTT of a retransmitted segment in its calculation of a new RTO. TCP/IP Protocol Suite
590
Exponential Backoff What is the value of RTO if a retransmission occurs? The value of RTO is doubled for each retransmission. TCP/IP Protocol Suite
591
Example 11 Figure is a continuation of the previous example. There is retransmission and Karn’s algorithm is applied. The first segment in the figure is sent, but lost. The RTO timer expires after 4.74 seconds. The segment is retransmitted and the timer is set to 9.48, twice the previous value of RTO. This time an ACK is received before the time-out. We wait until we send a new segment and receive the ACK for it before recalculating the RTO (Karn’s algorithm). TCP/IP Protocol Suite
592
Figure Example 11 Calculate this! TCP/IP Protocol Suite
593
Persistence Timer Deal with the zero-window-size advertisement
Receiver first advises a window of 0. Later receiver advises a window size by sending an ack (because receiver has no data to send) The ack is lost. (Remember that ack is not acked or retransmitted) Sender waits for window advertisement. Receiver waits for data. (A deadlock) TCP/IP Protocol Suite
594
Persistence Timer To correct this deadlock, when the sending TCP receives an acknowledgement with a window size of zero, it starts a persistence timer (=RTO at first). When the persistence timer goes off, the sending TCP sends a special segment call a probe. If no response, double the timer (max=60 s) and send probe again TCP/IP Protocol Suite
595
Keepalive Timer A keepalive timer is used in some implementations to prevent a long idle connection, for example, a client becomes silent Equip server with a keepalive timer (2 hours) After 2 hours’ silence, send a probe every 75 s After 10 probes, close the connection TCP/IP Protocol Suite
596
Time-Wait timer The time-wait timer (2 maximum segment lifetime) is used during connection termination TCP/IP Protocol Suite
597
OPTIONS The TCP header can have up to 40 bytes of optional information. Options convey additional information to the destination or align other options. TCP/IP Protocol Suite
598
Figure Options TCP/IP Protocol Suite
599
Figure 12.41 End-of-option option
TCP/IP Protocol Suite
600
EOP can be used only once.
Note: EOP can be used only once. TCP/IP Protocol Suite
601
Figure 12.42 No-operation option
TCP/IP Protocol Suite
602
NOP can be used more than once.
Note: NOP can be used more than once. TCP/IP Protocol Suite
603
Indicate the data only Max. 65535 bytes Default=536 bytes
Figure Maximum-segment-size option Indicate the data only Max bytes Default=536 bytes TCP/IP Protocol Suite
604
Note: The value of MSS is determined during connection establishment and does not change during the connection. TCP/IP Protocol Suite
605
Window Scale Factor The window size in TCP header is only 16 bits.
For a long fat pipe, bytes may not be sufficient. New window size=(window size in header) X 2(window scale factor) The largest value allowed by TCP is 14, which means the max. window size is 230 TCP/IP Protocol Suite
606
Figure 12.44 Window-scale-factor option
TCP/IP Protocol Suite
607
Note: The value of the window scale factor can be determined only during connection establishment; it does not change during the connection. TCP/IP Protocol Suite
608
Timestamp The end with the active open announces a timestamp in the connection request packet (SYN) If it receives a timestamp in the next segment (SYN+ACK) from the other end, it is allowed to use the timestamp. Two applications: measure RTT and prevent wrap-around sequence number TCP/IP Protocol Suite
609
Figure 12.45 Timestamp option
TCP/IP Protocol Suite
610
Note: One application of the timestamp option is the calculation of round trip time (RTT). TCP/IP Protocol Suite
611
Example 12 Figure shows an example that calculates the round-trip time for one end. Everything must be flipped if we want to calculate the RTT for the other end. The sender simply inserts the value of the clock (for example, the number of seconds past from midnight) in the timestamp field for the first and second segment. When an acknowledgment comes (the third segment), the value of the clock is checked and the value of the echo reply field is subtracted from the current time. RTT is 12 s in this scenario. TCP/IP Protocol Suite
612
Example 12 (Continued) The receiver’s function is more involved. It keeps track of the last acknowledgment (lastack) sent (12000). When the first segment arrives, it contains the bytes to The first byte is the same as the value of lastack. It then copies the timestamp value (4720) into the tsrecent (Timestamp recent) variable. The value of lastack is still (no new acknowledgment has been sent). When the second segment arrives, since none of the byte numbers in this segment include the value of lastack, the value of the timestamp field is ignored. When the receiver decides to send an accumulative acknowledgment with acknowledgment 12200, it changes the value of lastack to and inserts the value of tsrecent in the echo reply field. TCP/IP Protocol Suite
613
Example 12 (Continued) The value of tsrecent will not change until it is replaced by a new segment that carries byte (next segment). Note that as the example shows, the RTT calculated is the time difference between sending the first segment and receiving the third segment. This is actually the meaning of RTT: the time difference between a packet sent and the acknowledgment received. The third segment carries the acknowledgment for the first and second segments. TCP/IP Protocol Suite
614
Figure Example 12 TCP/IP Protocol Suite
615
PAWS: Protection Against Wrapped Sequence numbers
Increase the size of sequence number involves increasing the size of the window as well as the format of the segment. The easiest solution is to include the timestamp in the sequence number. Actual sequence number=timestamp+original sequence no. TCP/IP Protocol Suite
616
The timestamp option can also be used for PAWS.
Note: The timestamp option can also be used for PAWS. TCP/IP Protocol Suite
617
Figure SACK TCP/IP Protocol Suite
618
Example 13 Let us see how the SACK option is used to list out-of-order blocks. In Figure an end has received five segments of data. The first and second segments are in consecutive order. An accumulative acknowledgment can be sent to report the reception of these two segments. Segments 3, 4, and 5, however, are out of order with a gap between the second and third and a gap between the fourth and the fifth. An ACK and a SACK together can easily clear the situation for the sender. The value of ACK is2001, which means that the sender need not worry about bytes 1 to The SACK has two blocks. The first block announces that bytes 4001 to 6000 have arrived out of order. The second block shows that bytes 8001 to 9000 have also arrived out of order. This means that bytes 2001 to 4000 and bytes 6001 to 8000 are lost or discarded. The sender can resend only these bytes. TCP/IP Protocol Suite
619
Figure Example 13 TCP/IP Protocol Suite
620
Example 14 The example in Figure shows how a duplicate segment can be detected with a combination of ACK and SACK. In this case, we have some out-of-order segments (in one block) and one duplicate segment. To show both out-of-order and duplicate data, SACK uses the first block, in this case, to show the duplicate data and other blocks to show out-of-order data. Note that only the first block can be used for duplicate data. The natural question is how the sender, when it receives these ACK and SACK values knows that the first block is for duplicate data (compare this example with the previous example). The answer is that the bytes in the first block are already acknowledged in the ACK field; therefore, this block must be a duplicate. TCP/IP Protocol Suite
621
Figure Example 14 TCP/IP Protocol Suite
622
Example 15 The example in Figure shows what happens if one of the segments in the out-of-order section is also duplicated. In this example, one of the segments (4001:5000) is duplicated. The SACK option announces this duplicate data first and then the out-of-order block. This time, however, the duplicated block is not yet acknowledged by ACK, but because it is part of the out-of-order block (4001:5000 is part of 4001:6000), it is understood by the sender that it defines the duplicate data. TCP/IP Protocol Suite
623
Figure Example 15 TCP/IP Protocol Suite
624
TCP PACKAGE We present a simplified, bare-bones TCP package to simulate the heart of TCP. The package involves tables called transmission control blocks, a set of timers, and three software modules. The topics discussed in this section include: Transmission Control Blocks (TCBs) Timers Main Module Input Processing Module Output Processing Module TCP/IP Protocol Suite
625
Figure TCP package TCP/IP Protocol Suite
626
Figure TCBs Other TCP parameters TCP/IP Protocol Suite
627
Stream Control Transmission Protocol
Chapter 13 Stream Control Transmission Protocol Objectives Upon completion you will be able to: Be able to name and understand the services offered by SCTP Understand SCTP’s flow and error control and congestion control Be familiar with the fields in a SCTP segment Understand the phases in an SCTP association Understand the SCTP state transition diagram TCP/IP Protocol Suite
628
Figure 13.1 TCP/IP protocol suite
629
SCTP is a message-oriented, reliable protocol that combines the
Note: SCTP is a message-oriented, reliable protocol that combines the good features of UDP and TCP. TCP/IP Protocol Suite
630
SCTP SERVICES We explain the services offered by SCTP to the application layer processes. The topics discussed in this section include: Process-to-Process Communication Multiple Streams Multihoming Full-Duplex Communication Connection-Oriented Service Reliable Service TCP/IP Protocol Suite
631
Table 13.1 Some SCTP applications
TCP/IP Protocol Suite
632
Figure 13.2 Multiple-stream concept
TCP/IP Protocol Suite
633
An association in SCTP can involve multiple streams.
Note: An association in SCTP can involve multiple streams. TCP/IP Protocol Suite
634
Figure 13.3 Multihoming concept
TCP/IP Protocol Suite
635
SCTP association allows multiple IP addresses for each end.
Note: SCTP association allows multiple IP addresses for each end. TCP/IP Protocol Suite
636
SCTP FEATURES We discuss the general features of SCTP and then compare them with those of TCP. The topics discussed in this section include: Transmission Sequence Number (TSN) Stream Identifier (SI) Stream Sequence Number (SSN) Packets Acknowledgment Number Flow Control Error Control Congestion Control TCP/IP Protocol Suite
637
In SCTP, a data chunk is numbered using a TSN.
Note: In SCTP, a data chunk is numbered using a TSN. TCP/IP Protocol Suite
638
To distinguish between different streams, SCTP uses an SI.
Note: To distinguish between different streams, SCTP uses an SI. TCP/IP Protocol Suite
639
Note: To distinguish between different data chunks belonging to the same stream, SCTP uses SSNs. TCP/IP Protocol Suite
640
Figure 13.4 Comparison between a TCP segment and an SCTP packet
TCP/IP Protocol Suite
641
TCP has segments; SCTP has packets.
Note: TCP has segments; SCTP has packets. TCP/IP Protocol Suite
642
Note: In SCTP, control information and data information are carried in separate chunks. TCP/IP Protocol Suite
643
Figure 13.5 Packet, data chunks, and streams
TCP/IP Protocol Suite
644
Data chunks are identified by three identifiers: TSN, SI, and SSN.
Note: Data chunks are identified by three identifiers: TSN, SI, and SSN. TSN is a cumulative number identifying the association; SI defines the stream; SSN defines the chunk in a stream. TCP/IP Protocol Suite
645
Note: In SCTP, acknowledgment numbers are used to acknowledge only data chunks; control chunks are acknowledged by other control chunks if necessary. TCP/IP Protocol Suite
646
PACKET FORMAT We show the format of a packet and different types of chunks. An SCTP packet has a mandatory general header and a set of blocks called chunks. There are two types of chunks: control chunks and data chunks. The topics discussed in this section include: General Header Chunks TCP/IP Protocol Suite
647
Figure 13.6 SCTP packet format
TCP/IP Protocol Suite
648
In an SCTP packet, control chunks come before data chunks.
Note: In an SCTP packet, control chunks come before data chunks. TCP/IP Protocol Suite
649
Figure General header TCP/IP Protocol Suite
650
Figure 13.8 Common layout of a chunk
TCP/IP Protocol Suite
651
Chunks need to terminate on a 32-bit (4 byte) boundary.
Note: Chunks need to terminate on a 32-bit (4 byte) boundary. TCP/IP Protocol Suite
652
Table Chunks TCP/IP Protocol Suite
653
Note: The number of padding bytes are not included in the value of the length field. TCP/IP Protocol Suite
654
Figure DATA chunk TCP/IP Protocol Suite
655
Note: A DATA chunk cannot carry data belonging to more than one message, but a message can be split into several chunks The data field of the DATA chunk must carry at least one byte of data, which means the value of length field cannot be less than 17. TCP/IP Protocol Suite
656
Figure INIT chunk TCP/IP Protocol Suite
657
Format for variable length parameters
| Parameter Type | Parameter Length | \ \ / one or more Parameter Value / \ \ TCP/IP Protocol Suite
658
Parameter Type The Parameter Types are encoded such that the highest-order two bits specify the action that must be taken if the processing endpoint does not recognize the Parameter Type. 00 - Stop processing this SCTP packet and discard it, do not process any further chunks within it. 01 - Stop processing this SCTP packet and discard it, do not process any further chunks within it, and report the unrecognized parameter in an 'Unrecognized Parameter Type' (in either an ERROR or in the INIT ACK). 10 - Skip this parameter and continue processing. 11 - Skip this parameter and continue processing but report the unrecognized parameter in an 'Unrecognized Parameter Type' (in either an ERROR or in the INIT ACK). TCP/IP Protocol Suite
659
No other chunk can be carried in a packet that carries an INIT chunk.
Note: No other chunk can be carried in a packet that carries an INIT chunk. TCP/IP Protocol Suite
660
Figure INIT ACK chunk TCP/IP Protocol Suite
661
Note: No other chunk can be carried in a packet that carries an INIT ACK chunk. TCP/IP Protocol Suite
662
Figure 13.12 COOKIE ECHO chunk
TCP/IP Protocol Suite
663
Figure COOKIE ACK TCP/IP Protocol Suite
664
Figure SACK chunk TCP/IP Protocol Suite
665
Figure 13.15 HEARTBEAT and HEARTBEAT ACK chunks
TCP/IP Protocol Suite
666
Figure 13.16 SHUTDOWN, SHUTDOWN ACK, and SHUTDOWN COMPLETE chunks
The T bit is set to 0 if the sender had a TCB that it destroyed. If the sender did not have a TCB it should set this bit to 1. TCP/IP Protocol Suite
667
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure ERROR chunk | Cause Code | Cause Length | | Cause-specific Information | TCP/IP Protocol Suite
668
Table Errors TCP/IP Protocol Suite
669
Figure ABORT chunk T The T bit is set to 0 if the sender had a TCB that it destroyed. If the sender did not have a TCB it should set this bit to 1. TCP/IP Protocol Suite
670
AN SCTP ASSOCIATION SCTP, like TCP, is a connection-oriented protocol. However, a connection in SCTP is called an association to emphasize multihoming The topics discussed in this section include: Association Establishment Data Transfer Association Termination Association Abortion TCP/IP Protocol Suite
671
A connection in SCTP is called an association.
Note: A connection in SCTP is called an association. TCP/IP Protocol Suite
672
Figure 13.19 Four-way handshaking
TCP/IP Protocol Suite
673
A COOKIE ECHO or a COOKIE ACK chunk can carry DATA chunks.
Note: No other chunk is allowed in a packet carrying an INIT or INIT ACK chunk. A COOKIE ECHO or a COOKIE ACK chunk can carry DATA chunks. TCP/IP Protocol Suite
674
In SCTP, only DATA chunks consume TSNs;
Note: In SCTP, only DATA chunks consume TSNs; DATA chunks are the only chunks that are acknowledged. TCP/IP Protocol Suite
675
Figure 13.20 Simple data transfer
TCP/IP Protocol Suite
676
Note: The acknowledgment in SCTP defines the cumulative TSN, the TSN of the last DATA chunk received in order. TCP/IP Protocol Suite
677
Figure 13.21 Association termination
TCP/IP Protocol Suite
678
Figure 13.22 Association abortion
TCP/IP Protocol Suite
679
13.5 STATE TRANSITION DIAGRAM
To keep track of all the different events happening during association establishment, association termination, and data transfer, the SCTP software, like TCP, is implemented as a finite state machine. The topics discussed in this section include: Scenarios Simultaneous Close TCP/IP Protocol Suite
680
Figure 13.23 State transition diagram
TCP/IP Protocol Suite
681
Table States for SCTP TCP/IP Protocol Suite
682
Figure 13.24 A common scenario of states
TCP/IP Protocol Suite
683
Figure 13.25 Simultaneous open
TCP/IP Protocol Suite
684
Figure 13.26 Simultaneous close
TCP/IP Protocol Suite
685
FLOW CONTROL Flow control in SCTP is similar to that in TCP. In SCTP, we need to handle two units of data, the byte and the chunk. The topics discussed in this section include: Receiver Site Sender Site A Scenario TCP/IP Protocol Suite
686
Figure 13.27 Flow control, receiver site
TCP/IP Protocol Suite
687
Figure 13.28 Flow control, sender site
TCP/IP Protocol Suite
688
Figure 13.29 Flow control scenario
TCP/IP Protocol Suite
689
ERROR CONTROL SCTP uses a SACK chunk to report the state of the receiver buffer to the sender. Each implementation uses a different set of entities and timers for the receiver and sender sites. The topics discussed in this section include: Receiver Site Sender Site Sending Data Chunks Generating SACK Chunks TCP/IP Protocol Suite
690
Figure 13.30 Error control, receiver site
TCP/IP Protocol Suite
691
Figure 13.31 Error control, sender site
TCP/IP Protocol Suite
692
Figure 13.32 New state at the sender site after receiving a SACK chunk
TCP/IP Protocol Suite
693
CONGESTION CONTROL SCTP uses the same strategies for congestion control as TCP. SCTP uses slow start, congestion avoidance, and congestion detection phases. SCTP also uses fast retransmission and fast recovery. The topics discussed in this section include: Congestion Control and Multihoming Explicit Congestion Notification TCP/IP Protocol Suite
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.