Internet Protocol Suite Instructor: Prof. Ruay-Shiung Chang Department of Computer Science and Information Engineering National Dong Hwa University, Hualien, TAIWAN

Textbook TCP/IP Protocol Suite, Third edition, McGraw-Hill By Behrouz A. Forouzan

References

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)

Any Questions?

Chapter 1 Introduction

CONTENTS A BRIEF HISTORY PROTOCOLS AND STANDARDS STANDARDS ORGANIZATIONS INTERNET STANDARDS INTERNET ADMINISTRATION

1.1 A BRIEF HISTORY

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.

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?

Figure 1-1 Internet today Network Access Points

Internet History Internet Society Webpage (http://www.isoc.org) Internet Society History Webpage (http://www.isoc.org/internet/history/) Computer History (http://www.computerhistory.org)

1.2 PROTOCOLS AND STANDARDS

Protocols Syntax Semantics Timing

Standards De facto: e.g., TCP/IP De jure: e.g., ISO OSI

1.3 STANDARDS ORGANIZATIONS

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)

Forums Regulatory Agencies Frame Relay Forum ATM Forum Federal Communications Commission (FCC) National Communications Commission (NCC)

The websites for the above organizations are given in Appendix G.

1.4 INTERNET STANDARDS

Maturity levels of an RFC Figure 1-2 Maturity levels of an RFC

Requirement levels of an RFC Figure 1-3 Requirement levels of an RFC

1.5 INTERNET ADMINISTRATION

Internet Administration Figure 1-4 Internet Administration Internet Architecture Board Internet Research Task Force Internet Engineering Task Force SG: Steering Group

Internet Numbers IP addresses Protocol numbers Domain names … IANA (Internet Assigned Numbers Authority) ICANN (Internet Corporation for Assigned Names and Numbers)

The OSI Model and TCP/IP Protocol Suite Chapter 2 The OSI Model and TCP/IP Protocol Suite

CONTENTS THE OSI MODEL LAYERS IN THE OSI MODEL TCP/IP PROTOCOL SUITE ADDRESSING TCP/IP VERSIONS

2.1 THE OSI MODEL

ISO is the organization. OSI is the model.

Figure 2-1 OSI Model

Figure 2-2 OSI layers

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 2. Trailers are usually added only at layer 2.

An exchange using the OSI model Figure 2-3 An exchange using the OSI model

2.2 LAYERS IN THE OSI MODEL

Figure 2-4 Physical Layer

Figure 2-5 Data Link Layer

Node-to-node delivery Figure 2-6 Node-to-node delivery

Figure 2-7 Network Layer

Figure 2-8 End-to-end delivery

Figure 2-9 Transport Layer

Reliable end-to-end delivery of a message Figure 2-10 Reliable end-to-end delivery of a message

Figure 2-11 Session Layer

Figure 2-12 Presentation Layer

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

Figure 2-14 Summary of layers

2.3 TCP/IP PROTOCOL SUITE

TCP/IP and OSI model Figure 2-15

2.4 ADDRESSING

Figure 2-16 Addresses in TCP/IP

Figure 2-17 Relation- ship of layers and addresses in TCP/IP

Figure 2.18 shows an example of physical addresses.

Figure 2-18 Physical addresses

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: 07-01-02-01-2C-4B A 6-byte (12 hexadecimal digits) physical address

Figure 2.19 shows an example of Internet addresses.

Figure 2-19 IP addresses Note the changes in physical address!!

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. 132.24.75.9

Figure 2.20 shows an example of transport layer communication.

Figure 2-20 Port addresses

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. 753 A 16-bit port address

2.5 TCP/IP VERSIONS

Versions: Version 4 (current): 32-bit IP address Version 5 Version 6 (in promotion): 128-bit IP address

IP Addresses: Classful Addressing Chapter 4 IP Addresses: Classful Addressing

CONTENTS INTRODUCTION CLASSFUL ADDRESSING OTHER ISSUES A SAMPLE INTERNET

4.1 INTRODUCTION

An IP address is a 32-bit address.

The IP addresses are unique. One IP address points to one computer. But a computer may have many IP addresses.

Address Space ………….. addr1 addr15 addr2 ………….. ………….. ………….. addr226

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 ………….. …………..

The address space of IPv4 is 232 or 4,294,967,296.

Binary Notation 01110101 10010101 00011101 11101010

Dotted-decimal notation Figure 4-1 Dotted-decimal notation

Hexadecimal Notation 0111 0101 1001 0101 0001 1101 1110 1010 75 95 1D EA 0x75951DEA

The binary, decimal, and hexadecimal number systems are reviewed in Appendix B.

Example 1 Change the following IP address from binary notation to dotted-decimal notation. 10000001 00001011 00001011 11101111 Solution 129.11.11.239

Example 2 Change the following IP address from dotted-decimal notation to binary notation. 111.56.45.78 Solution 01101111 00111000 00101101 01001110

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: 111.56.045.78 Solution There are no leading zeroes in dotted-decimal notation (045).

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: 75.45.301.14 Solution In dotted-decimal notation, each number is less than or equal to 255; 301 is outside this range.

Example 4 Change the following IP addresses from binary notation to hexadecimal notation. 10000001 00001011 00001011 11101111 Solution 0X810B0BEF or 810B0BEF16

4.2 CLASSFUL ADDRESSING

Occupation of the address space Figure 4-2 Occupation of the address space 231(50%) 230(25%) 229(12.5%) 228(6.25%)

In classful addressing, the address space is divided into five classes: A, B, C, D, and E.

Finding the class in binary notation Figure 4-3 Finding the class in binary notation

Finding the address class Figure 4-4 Finding the address class

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.

Find the class of the address: 00000001 00001011 00001011 11101111 Example 6 Find the class of the address: 00000001 00001011 00001011 11101111 Solution The first bit is 0. This is a class A address.

Find the class of the address: 11000001 10000011 00011011 11111111 Example 6 (Continued) Find the class of the address: 11000001 10000011 00011011 11111111 Solution The first 2 bits are 1; the third bit is 0. This is a class C address.

Finding the class in decimal notation Figure 4-5 Finding the class in decimal notation

Find the class of the address: 227.12.14.87 Example 7 Find the class of the address: 227.12.14.87 Solution The first byte is 227 (between 224 and 239); the class is D.

Find the class of the address: 193.14.56.22 Example 7 (Continued) Find the class of the address: 193.14.56.22 Solution The first byte is 193 (between 192 and 223); the class is C.

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 0.0.0.0 to 127.255.255.255. We notice that we are dealing with base 256 numbers here.

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 +  255  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.

Figure 4-6 Netid and hostid

Figure 4-7 Blocks in class A

Millions of class A addresses are wasted.

Figure 4-8 Blocks in class B

Many class B addresses are wasted.

Figure 4-9 Blocks in class C

The number of addresses in a class C block is smaller than the needs of most organizations.

Class D addresses are used for multicasting; there is only one block in this class.

Class E addresses are reserved for special purposes; most of the block is wasted.

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

In classful addressing, the network address (the first address in the block) is the one that is assigned to the organization.

The class is A because the first byte is between Example 9 Given the network address 17.0.0.0, 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 17.0.0.0 to 17.255.255.255.

The class is B because the first byte is between Example 10 Given the network address 132.21.0.0, 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 132.21. The addresses range from 132.21.0.0 to 132.21.255.255.

The class is C because the first byte is between Example 11 Given the network address 220.34.76.0, 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 220.34.76. The addresses range from 220.34.76.0 to 220.34.76.255.

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.

Figure 4-10 Masking concept

Figure 4-11 AND operation

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.

Mask in dotted-decimal Default Masks Class Mask in Binary Mask in dotted-decimal A 11111111 0…0 255.0.0.0 B 11111111 11111111 0…0 255.255.0.0 C 1…1 00000000 255.255.255.0

The default mask is 255.0.0.0, which means Example 12 Given the address 23.56.7.91 and the default class A mask, find the beginning address (network address). Solution The default mask is 255.0.0.0, which means that only the first byte is preserved and the other 3 bytes are set to 0s. The network address is 23.0.0.0.

The default mask is 255.255.0.0, which means Example 13 Given the address 132.6.17.85 and the default class B mask, find the beginning address (network address). Solution The default mask is 255.255.0.0, which means that the first 2 bytes are preserved and the other 2 bytes are set to 0s. The network address is 132.6.0.0.

which means that the first 3 bytes are Example 14 Given the address 201.180.56.5 and the class C default mask, find the beginning address (network address). Solution The default mask is 255.255.255.0, which means that the first 3 bytes are preserved and the last byte is set to 0. The network address is 201.180.56.0.

We must not apply the default mask of one class to an address belonging to another class.

CIDR (Classless Inter-Domain Routing) Notation 18.46.74.10/8 141.24.74.69/16 200.14.70.22/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.

4.13 OTHER ISSUES

Figure 4-12 Multihomed devices

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

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

Figure 4-13 Network addresses

Example of direct broadcast address Figure 4-14 Example of direct broadcast address

Example of limited broadcast address Figure 4-15 Example of limited broadcast address

Example of this host on this address Figure 4-16 Example of this host on this address

Example of specific host on this network Figure 4-17 Example of specific host on this network

Example of loopback address Figure 4-18 Example of loopback address

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 172.16 to 172.31 16 C 192.168.0 to 192.168.255 256

Unicast, Multicast, and Broadcast Addresses Unicast communication is one-to-one. Multicast communication is one-to-many. Broadcast communication is one-to-all.

Multicast delivery will be discussed in depth in Chapter 15.

4.4 A SAMPLE INTERNET WITH CLASSFUL ADDRESSES

Figure 4-19 Sample internet

4.4 SUBNETTING

IP addresses are designed with two levels of hierarchy.

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.208.10.11?)

A network with three levels of hierarchy (subnetted) Figure 4.21 A network with three levels of hierarchy (subnetted)

Addresses in a network with and without subnetting Figure 4.22 Addresses in a network with and without subnetting

Hierarchy concept in a telephone number Figure 4.23 Hierarchy concept in a telephone number

Default mask and subnet mask Figure 4.24 Default mask and subnet mask

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.

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.

Example 15 What is the subnetwork address if the destination address is 200.45.34.56 and the subnet mask is 255.255.240.0?

The subnetwork address is 200.45.32.0. Solution 11001000 00101101 00100010 00111000 11111111 11111111 11110000 00000000 11001000 00101101 00100000 00000000 The subnetwork address is 200.45.32.0.

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.

What is the subnetwork address if the destination address is 19.30.80.5 and the mask is 255.255.192.0?

Comparison of a default mask and Figure 4.25 Comparison of a default mask and a subnet mask

The number of subnets must be a power of 2.

The number of 1s in the default mask is 24 (class C). A company is granted the site address 201.70.64.0 (class C). The company needs six subnets. Design the subnets. Solution The number of 1s in the default mask is 24 (class C).

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 (32 - 27). The mask is

The number of subnets is 8. Solution (Continued) 11111111 11111111 11111111 11100000 or 255.255.255.224 The number of subnets is 8. The number of addresses in each subnet is 25 (5 is the number of 0s) or 32.

The number of 1s in the default mask is 16 (class B). A company is granted the site address 181.56.0.0 (class B). The company needs 1000 subnets. Design the subnets. Solution The number of 1s in the default mask is 16 (class B).

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 (16 + 10). The total number of 0s is 6 (32 - 26).

The number of subnets is 1024. Solution (Continued) The mask is 11111111 11111111 11111111 11000000 or 255.255.255.192. The number of subnets is 1024. The number of addresses in each subnet is 26 (6 is the number of 0s) or 64.

Variable-length subnetting Without counting the all 0’s and all 1’s hosts

SUPERNETTING

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

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.

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? 198.47.32.0 198.47.33.0 198.47.34.0 198.47.32.0 198.47.42.0 198.47.52.0 198.47.62.0 198.47.31.0 198.47.32.0 198.47.33.0 198.47.34.0 198.47.32.0 198.47.33.0 198.47.34.0 198.47.35.0

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.

In subnetting, we need the first address of the subnet and the subnet mask to define the range of addresses.

In supernetting, we need the first address of the supernet and the supernet mask to define the range of addresses.

Comparison of subnet, default, Figure 4.27 Comparison of subnet, default, and supernet masks

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 11111111 11111111 11110000 00000000 or 255.255.240.0

A supernet has a first address of 205. 16. 32 A supernet has a first address of 205.16.32.0 and a supernet mask of 255.255.248.0. A router receives three packets with the following destination addresses: 205.16.37.44 205.16.42.56 205.17.33.76 Which packet belongs to the supernet?

Solution We apply the supernet mask to see if we can find the beginning address. 205.16.37.44 AND 255.255.248.0  205.16.32.0 205.16.42.56 AND 255.255.248.0  205.16.40.0 205.17.33.76 AND 255.255.248.0  205.17.32.0 Only the first address belongs to this supernet.

A supernet has a first address of 205. 16. 32 A supernet has a first address of 205.16.32.0 and a supernet mask of 255.255.248.0. 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 205.16.32.0 to 205.16.39.0. The first address is 205.16.32.0. The last address is 205.16.39.255.

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

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

Figure 5.1 Variable-length blocks TCP/IP Protocol Suite

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

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

Example 1 Which of the following can be the beginning address of a block that contains 16 addresses? a. 205.16.37.32 b.190.16.42.44 c. 17.17.33.80 d.123.45.24.52 Solution Only two are eligible (a and c). The address 205.16.37.32 is eligible because 32 is divisible by 16. The address 17.17.33.80 is eligible because 80 is divisible by 16. TCP/IP Protocol Suite

Example 2 Which of the following can be the beginning address of a block that contains 256 addresses? a.205.16.37.32 b.190.16.42.0 c.17.17.32.0 d.123.45.24.52 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

Example 3 Which of the following can be the beginning address of a block that contains 1024 addresses? a. 205.16.37.32 b.190.16.42.0 c. 17.17.32.0 d.123.45.24.52 Solution In this case, we need to check two bytes because 1024 = 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

Figure 5.2 Format of classless addressing address TCP/IP Protocol Suite

Table 5.1 Prefix lengths TCP/IP Protocol Suite

Classful addressing is a special case of classless addressing. Note: Classful addressing is a special case of classless addressing. TCP/IP Protocol Suite

Example 4 What is the first address in the block if one of the addresses is 167.199.170.82/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: 10100111 11000111 10101010 01010010 Keep the left 27 bits: 10100111 11000111 10101010 01000000 Result in CIDR notation: 167.199.170.64/27 TCP/IP Protocol Suite

Example 5 What is the first address in the block if one of the addresses is 140.120.84.24/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 140.120.80.0/20. See Next Slide TCP/IP Protocol Suite

Figure 5.3 Example 5 TCP/IP Protocol Suite

Example 6 Find the first address in the block if one of the addresses is 140.120.84.24/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 140.120.80.0/20. See Next Slide TCP/IP Protocol Suite

Figure 5.4 Example 6 TCP/IP Protocol Suite

Example 7 Find the number of addresses in the block if one of the addresses is 140.120.84.24/20. Solution The prefix length is 20. The number of addresses in the block is 232−20 or 212 or 4096. Note that this is a large block with 4096 addresses. TCP/IP Protocol Suite

Example 8 Using the first method, find the last address in the block if one of the addresses is 140.120.84.24/20. Solution We found in the previous examples that the first address is 140.120.80.0/20 and the number of addresses is 4096. To find the last address, we need to add 4095 (4096 − 1) to the first address. See Next Slide TCP/IP Protocol Suite

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 15.255. We then add the first address to this number (in base 255) to obtain the last address as shown below: 140 . 120 . 80 . 0 15 . 255 ------------------------- 140 . 120 . 95 . 255 The last address is 140.120.95.255/20. TCP/IP Protocol Suite

Example 9 Using the second method, find the last address in the block if one of the addresses is 140.120.84.24/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 00000000 00000000 00001111 11111111 or 0.0.15.255. We add the mask complement to the beginning address to find the last address. See Next Slide TCP/IP Protocol Suite

Example 9 (Continued) We add the mask complement to the beginning address to find the last address. 140 . 120 . 80 . 0 0 . 0 . 15 . 255 ---------------------------- 140 . 120 . 95 . 255 The last address is 140.120.95.255/20. TCP/IP Protocol Suite

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 190.87.140.202/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

The leftmost 5 numbers are ➡ 128 + 64 + 0 + 0 + 8 Example 10 (Continued) 202 ➡ 128 + 64 + 0 + 0 + 8 + 0 + 2 + 0 The leftmost 5 numbers are ➡ 128 + 64 + 0 + 0 + 8 The first address is 190.87.140.200/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 0.0.0.7. If we add this to the first address, we get 190.87.140.207/29. In other words, the first address is 190.87.140.200/29, the last address is 190.87.140.207/29. There are only 8 addresses in this block. TCP/IP Protocol Suite

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

Figure 5.5 Example 11 TCP/IP Protocol Suite

Note: In classless addressing, the last address in the block does not necessarily end in 255. TCP/IP Protocol Suite

Note: In CIDR notation, the block granted is defined by the first address and the prefix length. TCP/IP Protocol Suite

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

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

Example 12 An organization is granted the block 130.34.12.64/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

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

Figure 5.6 Example 13 TCP/IP Protocol Suite

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 130.34.12.64/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 130.34.12.79/28. See Next Slide TCP/IP Protocol Suite

Example 13 (Continued) 2.The first address in the second subnet is 130.34.12.80/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, 130.34.12.95/28. 3. Similarly, we find the first address of the third subnet to be 130.34.12.96/28 and the last to be 130.34.12.111/28. 4. Similarly, we find the first address of the fourth subnet to be 130.34.12.112/28 and the last to be 130.34.12.127/28. TCP/IP Protocol Suite

See Next Slide For One Solution Example 14 An organization is granted a block of addresses with the beginning address 14.24.74.0/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

Figure 5.7 Example 14 TCP/IP Protocol Suite

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

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

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 70.12.100.128/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

Figure 5.8 Example 15 TCP/IP Protocol Suite

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 70.12.100.128/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 70.12.100.128/27 to 70.12.100.159/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

See Next Slide Example 15 (Continued) b. The West office uses the network address 70.12.100.160/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 70.12.100.160/28 to 70.12.100.175/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

Example 15 (Continued) c. The East office uses the network address 70.12.100.176/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 70.12.100.176/28 to 70.12.100.191/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

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

Example 16 An ISP is granted a block of addresses starting with 190.100.0.0/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 128 addresses c. The third group has 128 customers; each needs 64 addresses. See Next Slide TCP/IP Protocol Suite

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

Figure 5.9 Example 16 TCP/IP Protocol Suite

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 190.100.0.0/24 190.100.0.255/24 2nd Customer 190.100.1.0/24 190.100.1.255/24 . . . 64th Customer 190.100.63.0/24 190.100.63.255/24 Total = 64 × 256 = 16,384 See Next Slide TCP/IP Protocol Suite

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 190.100.64.0/25 190.100.64.127/25 2nd Customer 190.100.64.128/25 190.100.64.255/25 · · · 128th Customer 190.100.127.128/25 190.100.127.255/25 Total = 128 × 128 = 16,384 See Next Slide TCP/IP Protocol Suite

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 190.100.128.0/26 190.100.128.63/26 2nd Customer 190.100.128.64/26 190.100.128.127/26 · · · 128th Customer 190.100.159.192/26 190.100.159.255/26 Total = 128 × 64 = 8,192 See Next Slide TCP/IP Protocol Suite

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

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

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

IP is a connectionless protocol. Note: IP is a connectionless protocol. TCP/IP Protocol Suite

Figure 6.1 Direct delivery TCP/IP Protocol Suite

Figure 6.2 Indirect delivery TCP/IP Protocol Suite

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

Figure 6.3 Next-hop method TCP/IP Protocol Suite

Routing table too large Figure 6.4 Network-specific method Routing table too large TCP/IP Protocol Suite

Figure 6.5 Host-specific routing TCP/IP Protocol Suite

Figure 6.6 Default routing TCP/IP Protocol Suite

Figure 6.7 Simplified forwarding module in classful address without subnetting TCP/IP Protocol Suite

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

Figure 6.8 Configuration for routing, Example 1 TCP/IP Protocol Suite

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

Figure 6.9 Tables for Example 1 TCP/IP Protocol Suite

Example 2 Router R1 in Figure 6.8 receives a packet with destination address 192.16.7.14. Show how the packet is forwarded. Solution The destination address in binary is 11000000 00010000 00000111 00001110. A copy of the address is shifted 28 bits to the right. The result is 00000000 00000000 00000000 00001100 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 192.16.7.0. The table for Class C is searched. The network address is found in the first row. The next-hop address 111.15.17.32. and the interface m0 are passed to ARP. TCP/IP Protocol Suite

Example 3 Router R1 in Figure 6.8 receives a packet with destination address 167.24.160.5. Show how the packet is forwarded. Solution The destination address in binary is 10100111 00011000 10100000 00000101. A copy of the address is shifted 28 bits to the right. The result is 00000000 00000000 00000000 00001010 or 10. The class is B. The network address can be found by masking off 16 bits of the destination address, the result is 167.24.0.0. 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 111.30.31.18 and the interface number m0 are passed to ARP. TCP/IP Protocol Suite

Figure 6.10 Simplified forwarding module in classful address with subnetting TCP/IP Protocol Suite

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

Example 4 (Continued) Note several points. First, the site address is 145.14.0.0/16 (a class B address). Every packet with destination address in the range 145.14.0.0 to 145.14.255.255 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

Figure 6.11 Configuration for Example 4 TCP/IP Protocol Suite

Example 5 The router in Figure 6.11 receives a packet with destination address 145.14.32.78. Show how the packet is forwarded. Solution The mask is /18. After applying the mask, the subnet address is 145.14.0.0. The packet is delivered to ARP with the next-hop address 145.14.32.78 and the outgoing interface m0. TCP/IP Protocol Suite

Example 6 A host in network 145.14.0.0 in Figure 6.11 has a packet to send to the host with address 7.22.67.91. Show how the packet is routed. Solution The router receives the packet and applies the mask (/18). The network address is 7.22.64.0. 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

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

Figure 6.12 Simplified forwarding module in classless address TCP/IP Protocol Suite

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

Figure 6.13 Configuration for Example 7 TCP/IP Protocol Suite

Table 6.1 Routing table for router R1 in Figure 6.13 TCP/IP Protocol Suite

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 180.70.65.140. Solution The router performs the following steps: 1. The first mask (/26) is applied to the destination address. The result is 180.70.65.128, which does not match the corresponding network address. See Next Slide TCP/IP Protocol Suite

Example 8 (Continued) 2. The second mask (/25) is applied to the destination address. The result is 180.70.65.128, 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

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 201.4.22.35. Solution The router performs the following steps: See Next Slide TCP/IP Protocol Suite

Example 9 (Continued) 1. The first mask (/26) is applied to the destination address. The result is 201.4.22.0, which does not match the corresponding network address (row 1). 2. The second mask (/25) is applied to the destination address. The result is 201.4.22.0, which does not match the corresponding network address (row 2). 3. The third mask (/24) is applied to the destination address. The result is 201.4.22.0, 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

Example 10 Show the forwarding process if a packet arrives at R1 in Figure 6.13 with the destination address 18.24.32.78. 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 180.70.65.200 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

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

Table 6.2 Routing table for Example 11 TCP/IP Protocol Suite

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

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 130.4.8.0 is directly connected to router R2 or through a point-to-point network (WAN) and another router. We do not know if network140.6.12.64 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

Figure 6.14 Guessed topology for Example 6 TCP/IP Protocol Suite

Figure 6.15 Address aggregation TCP/IP Protocol Suite

Figure 6.16 Longest mask matching TCP/IP Protocol Suite

Example 12 As an example of hierarchical routing, let us consider Figure 6.17. A regional ISP is granted 16384 addresses starting from 120.14.64.0. 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

Figure 6.17 Hierarchical routing with ISPs TCP/IP Protocol Suite

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

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 120.14.64.0 to 120.14.127.255 to the regional ISP. The regional ISP sends every packet with destination address 120.14.64.0 to 120.14.79.255 to Local ISP1. Local ISP1 sends every packet with destination address 120.14.64.0 to 120.14.64.3 to H001. TCP/IP Protocol Suite

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

Figure 6.18 Common fields in a routing table TCP/IP Protocol Suite

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

$ netstat -rn Kernel IP routing table Example 13 (continued) $ netstat -rn Kernel IP routing table Destination Gateway Mask Flags Iface 153.18.16.0 0.0.0.0 255.255.240.0 U eth0 127.0.0.0 0.0.0.0 255.0.0.0 U lo 0.0.0.0 153.18.31. 254 0.0.0.0 UG eth0. See Next Slide TCP/IP Protocol Suite

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:153.18.17.11 Bcast:153.18.31.255 Mask:255.255.240.0 .... 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

Figure 6.19 Configuration of the server for Example 13 TCP/IP Protocol Suite

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

Figure 6.20 Router components TCP/IP Protocol Suite

Figure 6.21 Input port TCP/IP Protocol Suite

Figure 6.22 Output port TCP/IP Protocol Suite

Figure 6.23 Crossbar switch TCP/IP Protocol Suite

Figure 6.24 A banyan switch TCP/IP Protocol Suite

(1->6) and (5->7) will conflict with each other. Figure 6.25 Examples of routing in a banyan switch (1->6) and (5->7) will conflict with each other. TCP/IP Protocol Suite

Prevent blocking in banyan switch Figure 6.26 Batcher-banyan switch sorter 6 7 6 6 7 7 Prevent blocking in banyan switch TCP/IP Protocol Suite

(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

Figure 7.1 ARP and RARP TCP/IP Protocol Suite

Figure 7.2 Position of ARP and RARP in TCP/IP protocol suite

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

Figure 7.3 ARP operation TCP/IP Protocol Suite

Figure 7.4 ARP packet TCP/IP Protocol Suite

Figure 7.5 Encapsulation of ARP packet TCP/IP Protocol Suite

Figure 7.6 Four cases using ARP TCP/IP Protocol Suite

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

Example 1 A host with IP address 130.23.43.20 and physical address B2:34:55:10:22:10 has a packet to send to another host with IP address 130.23.43.25 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

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

Figure 7.7 Example 1 TCP/IP Protocol Suite

Figure 7.8 Proxy ARP TCP/IP Protocol Suite

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

Figure 7.9 ARP components TCP/IP Protocol Suite

Table 7.1 Original cache table used for examples TCP/IP Protocol Suite

Example 2 The ARP output module receives an IP datagram (from the IP layer) with the destination address 114.5.7.89. 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 457342ACAE32, and sends the packet and the address to the data link layer for transmission. The cache table remains the same. TCP/IP Protocol Suite

Example 3 Twenty seconds later, the ARP output module receives an IP datagram (from the IP layer) with the destination address 116.1.7.22. 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

Table 7.2 Updated cache table for Example 3 TCP/IP Protocol Suite

Example 4 Fifteen seconds later, the ARP input module receives an ARP packet with target protocol (IP) address 188.11.8.71. 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 (E34573242ACA) 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

Table 7.3 Updated cache table for Example 4 TCP/IP Protocol Suite

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

Table 7.4 Updated cache table for Example 5 TCP/IP Protocol Suite

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

The RARP request packets are broadcast; Note: The RARP request packets are broadcast; the RARP reply packets are unicast. TCP/IP Protocol Suite

Figure 7.10 RARP operation TCP/IP Protocol Suite

Figure 7.11 RARP packet TCP/IP Protocol Suite

Figure 7.12 Encapsulation of RARP packet TCP/IP Protocol Suite

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

Figure 8.1 Position of IP in TCP/IP protocol suite

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

Figure 8.2 IP datagram TCP/IP Protocol Suite

Figure 8.3 Service type or differentiated services TCP/IP Protocol Suite

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

Table 8.1 Types of service TCP/IP Protocol Suite

Table 8.2 Default types of service TCP/IP Protocol Suite

Table 8.3 Values for codepoints TCP/IP Protocol Suite

Supplementary Material Quality of Service TCP/IP Protocol Suite

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

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

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

Principles for QOS Guarantees Simple model for sharing and congestion studies (“dumbbell topology”): TCP/IP Protocol Suite

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

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

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

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

Summary TCP/IP Protocol Suite

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

Figure 8.2 IP datagram TCP/IP Protocol Suite

Note: The total length field defines the total length of the datagram including the header. TCP/IP Protocol Suite

Figure 8.4 Encapsulation of a small datagram in an Ethernet frame TCP/IP Protocol Suite

Figure 8.5 Multiplexing TCP/IP Protocol Suite

Table 8.4 Protocols TCP/IP Protocol Suite

Example 1 An IP packet has arrived with the first 8 bits as shown: 01000010 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

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

Example 3 In an IP packet, the value of HLEN is 516 and the value of the total length field is 002816 . 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

Example 4 An IP packet has arrived with the first few hexadecimal digits as shown below: 45000028000100000102 . . . 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

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

Figure 8.6 MTU TCP/IP Protocol Suite

Table 8.5 MTUs for some networks TCP/IP Protocol Suite

Figure 8.7 Flags field TCP/IP Protocol Suite

Figure 8.8 Fragmentation example TCP/IP Protocol Suite

Figure 8.9 Detailed fragmentation example TCP/IP Protocol Suite

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

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

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

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

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

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

Figure 8.10 Option format TCP/IP Protocol Suite

Figure 8.11 Categories of options TCP/IP Protocol Suite

Figure 8.12 No operation option TCP/IP Protocol Suite

Figure 8.13 End of option option TCP/IP Protocol Suite

Figure 8.14 Record route option TCP/IP Protocol Suite

Figure 8.15 Record route concept TCP/IP Protocol Suite

Figure 8.16 Strict source route option TCP/IP Protocol Suite

Figure 8.17 Strict source route concept TCP/IP Protocol Suite

Figure 8.18 Loose source route option Can visit other routers besides those listed. TCP/IP Protocol Suite

Figure 8.19 Timestamp option TCP/IP Protocol Suite

Figure 8.20 Use of flag in timestamp TCP/IP Protocol Suite

Figure 8.21 Timestamp concept TCP/IP Protocol Suite

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 00000001; not copied. b. End of option: Code is 00000000; not copied. c. Record route: Code is 00000111; not copied. d. Strict source route: Code is 10001001; copied. e. Loose source route: Code is 10000011; copied. f. Timestamp: Code is 01000100; not copied. TCP/IP Protocol Suite

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 00000001; datagram control. b. End of option: Code is 00000000; datagram control. c. Record route: Code is 00000111; datagram control. d. Strict source route: Code is 10001001; datagram control. e. Loose source route: Code is 10000011; datagram control. f. Time stamp: Code is 01000100; debugging and management control. TCP/IP Protocol Suite

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 153.18.8.1. $ ping fhda.edu PING fhda.edu (153.18.8.1) 56(84) bytes of data. 64 bytes from tiptoe.fhda.edu (153.18.8.1): .... The result shows the IP address of the host and the number of bytes used. TCP/IP Protocol Suite

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 (153.18.8.1) 56(124) bytes of data. 64 bytes from tiptoe.fhda.edu (153.18.8.1): icmp_seq=0 ttl=62 time=2.70 ms RR: voyager.deanza.fhda.edu (153.18.17.11) Dcore_G0_3-69.fhda.edu (153.18.251.3) Dbackup_V13.fhda.edu (153.18.191.249) tiptoe.fhda.edu (153.18.8.1) Dbackup_V62.fhda.edu (153.18.251.34) Dcore_G0_1-6.fhda.edu (153.18.31.254) voyager.deanza.fhda.edu (153.18.17.11) The result shows the interfaces and IP addresses. TCP/IP Protocol Suite

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 (153.18.8.1), 30 hops max, 38 byte packets 1 Dcore_G0_1-6.fhda.edu (153.18.31.254) 0.972 ms 0.902 ms 0.881 ms 2 Dbackup_V69.fhda.edu (153.18.251.4) 2.113 ms 1.996 ms 2.059 ms 3 tiptoe.fhda.edu (153.18.8.1) 1.791 ms 1.741 ms 1.751 ms The result shows the three routers visited. TCP/IP Protocol Suite

$ 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 153.18.251.4. $ traceroute -g 153.18.251.4 fhda.edu. traceroute to fhda.edu (153.18.8.1), 30 hops max, 46 byte packets 1 Dcore_G0_1-6.fhda.edu (153.18.31.254) 0.976 ms 0.906 ms 0.889 ms 2 Dbackup_V69.fhda.edu (153.18.251.4) 2.168 ms 2.148 ms 2.037 ms TCP/IP Protocol Suite

$ 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 153.18.251.4, not any other one. $ traceroute -G 153.18.251.4 fhda.edu. traceroute to fhda.edu (153.18.8.1), 30 hops max, 46 byte packets 1 Dbackup_V69.fhda.edu (153.18.251.4) 2.168 ms 2.148 ms 2.037 ms TCP/IP Protocol Suite

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

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

Figure 8.22 Checksum concept TCP/IP Protocol Suite

Figure 8.23 Checksum in one’s complement arithmetic TCP/IP Protocol Suite

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

Figure 8.24 Example of checksum calculation in binary TCP/IP Protocol Suite

IP Checksum Calculation TCP/IP Protocol Suite

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

Figure 8.25 Example of checksum calculation in hexadecimal TCP/IP Protocol Suite TCP/IP Protocol Suite 372

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

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

Figure 8.26 IP components TCP/IP Protocol Suite

Figure 8.27 MTU table TCP/IP Protocol Suite

Figure 8.28 Reassembly table TCP/IP Protocol Suite

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

Figure 9.1 Position of ICMP in the network layer TCP/IP Protocol Suite

Figure 9.2 ICMP encapsulation TCP/IP Protocol Suite

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

Figure 9.3 ICMP messages TCP/IP Protocol Suite

Table 9.1 ICMP messages TCP/IP Protocol Suite

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

Figure 9.4 General format of ICMP messages TCP/IP Protocol Suite

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

ICMP always reports error messages to the original source. Note: ICMP always reports error messages to the original source. TCP/IP Protocol Suite

Figure 9.5 Error-reporting messages TCP/IP Protocol Suite

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 127.0.0.0 or 0.0.0.0. TCP/IP Protocol Suite

Figure 9.6 Contents of data field for the error messages TCP/IP Protocol Suite

Figure 9.7 Destination-unreachable format TCP/IP Protocol Suite

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

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

Note: A router cannot detect all problems that prevent the delivery of a packet. TCP/IP Protocol Suite

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

Figure 9.8 Source-quench format TCP/IP Protocol Suite

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

Note: One source-quench message is sent for each datagram that is discarded due to congestion. TCP/IP Protocol Suite

Figure 9.9 Time-exceeded message format TCP/IP Protocol Suite

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

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

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

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

Note: A parameter-problem message can be created by a router or the destination host. TCP/IP Protocol Suite

0 = Redirect datagrams for the Network. Figure 9.12 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

Figure 9.11 Redirection concept TCP/IP Protocol Suite

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

Note: A redirection message is sent from a router to a host on the same local network. TCP/IP Protocol Suite

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

Figure 9.13 Query messages TCP/IP Protocol Suite

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

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

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

Figure 9.14 Echo-request and echo-reply messages TCP/IP Protocol Suite

Figure 9.15 Timestamp-request and timestamp-reply message format Milliseconds from midnight in Universal Time TCP/IP Protocol Suite

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

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

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

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

Figure 9.16 Mask-request and mask-reply message format TCP/IP Protocol Suite

Figure 9.17 Router-solicitation message format TCP/IP Protocol Suite

=0 default router Figure 9.18 Router-advertisement message format TCP/IP Protocol Suite

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

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

Figure 9.19 Example of checksum calculation TCP/IP Protocol Suite

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

Example 2 We use the ping program to test the server fhda.edu. The result is shown below: $ ping fhda.edu PING fhda.edu (153.18.8.1) 56 (84) bytes of data. 64 bytes from tiptoe.fhda.edu (153.18.8.1): icmp_seq=0 ttl=62 time=1.91 ms 64 bytes from tiptoe.fhda.edu (153.18.8.1): icmp_seq=1 ttl=62 time=2.04 ms 64 bytes from tiptoe.fhda.edu (153.18.8.1): icmp_seq=2 ttl=62 time=1.90 ms 64 bytes from tiptoe.fhda.edu (153.18.8.1): icmp_seq=3 ttl=62 time=1.97 ms 64 bytes from tiptoe.fhda.edu (153.18.8.1): icmp_seq=4 ttl=62 time=1.93 ms See Next Slide TCP/IP Protocol Suite

Example 2 (Continued) 64 bytes from tiptoe.fhda.edu (153.18.8.1): icmp_seq=5 ttl=62 time=2.00 ms 64 bytes from tiptoe.fhda.edu (153.18.8.1): icmp_seq=6 ttl=62 time=1.94 ms 64 bytes from tiptoe.fhda.edu (153.18.8.1): icmp_seq=7 ttl=62 time=1.94 ms 64 bytes from tiptoe.fhda.edu (153.18.8.1): icmp_seq=8 ttl=62 time=1.97 ms 64 bytes from tiptoe.fhda.edu (153.18.8.1): icmp_seq=9 ttl=62 time=1.89 ms 64 bytes from tiptoe.fhda.edu (153.18.8.1): icmp_seq=10 ttl=62 time=1.98 ms --- fhda.edu ping statistics --- 11 packets transmitted, 11 received, 0% packet loss, time 10103ms rtt min/avg/max = 1.899/1.955/2.041 ms TCP/IP Protocol Suite

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 (68.168.78.100) 56(84) bytes of data. 64 bytes from mail.adelphia.net (68.168.78.100): icmp_seq=0 ttl=48 time=85.4 ms 64 bytes from mail.adelphia.net (68.168.78.100): icmp_seq=1 ttl=48 time=84.6 ms 64 bytes from mail.adelphia.net (68.168.78.100): icmp_seq=2 ttl=48 time=84.9 ms 64 bytes from mail.adelphia.net (68.168.78.100): icmp_seq=3 ttl=48 time=84.3 ms 64 bytes from mail.adelphia.net (68.168.78.100): icmp_seq=4 ttl=48 time=84.5 ms See Next Slide TCP/IP Protocol Suite

Example 3 (Continued) 64 bytes from mail.adelphia.net (68.168.78.100): icmp_seq=5 ttl=48 time=84.7 ms 64 bytes from mail.adelphia.net (68.168.78.100): icmp_seq=6 ttl=48 time=84.6 ms 64 bytes from mail.adelphia.net (68.168.78.100): icmp_seq=7 ttl=48 time=84.7 ms 64 bytes from mail.adelphia.net (68.168.78.100): icmp_seq=8 ttl=48 time=84.4 ms 64 bytes from mail.adelphia.net (68.168.78.100): icmp_seq=9 ttl=48 time=84.2 ms 64 bytes from mail.adelphia.net (68.168.78.100): icmp_seq=10 ttl=48 time=84.9 ms 64 bytes from mail.adelphia.net (68.168.78.100): icmp_seq=11 ttl=48 time=84.6 ms 64 bytes from mail.adelphia.net (68.168.78.100): 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.207/84.694/85.469 TCP/IP Protocol Suite

Figure 9.20 The traceroute program operation TCP/IP Protocol Suite

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 (153.18.8.1), 30 hops max, 38 byte packets 1 Dcore.fhda.edu (153.18.31.254) 0.995 ms 0.899 ms 0.878 ms 2 Dbackup.fhda.edu (153.18.251.4) 1.039 ms 1.064 ms 1.083 ms 3 tiptoe.fhda.edu (153.18.8.1) 1.797 ms 1.642 ms 1.757 ms See Next Slide TCP/IP Protocol Suite

Example 4 (Continued) The un-numbered line after the command shows that the destination is 153.18.8.1. 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 153.18.31.254. The first round trip time was 0.995 milliseconds, the second was 0.899 milliseconds, and the third was 0.878 milliseconds. The second line shows the second router visited. The router is named Dbackup.fhda.edu with IP address 153.18.251.4. 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 153.18.8.1. The three round trip times are also shown. TCP/IP Protocol Suite

In this example, we trace a longer route, the route to xerox.com $ traceroute xerox.com traceroute to xerox.com (13.1.64.93), 30 hops max, 38 byte packets 1 Dcore.fhda.edu (153.18.31.254) 0.622 ms 0.891 ms 0.875 ms 2 Ddmz.fhda.edu (153.18.251.40) 2.132 ms 2.266 ms 2.094 ms ... 18 alpha.Xerox.COM (13.1.64.93) 11.172 ms 11.048 ms 10.922 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

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 (127.0.0.1), 30 hops max, 38 byte packets 1 voyager (127.0.0.1) 0.178 ms 0.086 ms 0.055 ms TCP/IP Protocol Suite

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 (198.45.24.104), 30 hops max, 38 byte packets 1 Dcore.fhda.edu (153.18.31.254) 1.025 ms 0.892 ms 0.880 ms 2 Ddmz.fhda.edu (153.18.251.40) 2.141 ms 2.159 ms 2.103 ms 3 Cinic.fhda.edu (153.18.253.126) 2.159 ms 2.050 ms 1.992 ms ... 16 * * * 17 * * * ............... TCP/IP Protocol Suite

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

Figure 9.21 ICMP package TCP/IP Protocol Suite

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

Figure 11.1 Position of UDP in the TCP/IP protocol suite

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

Figure 11.2 UDP versus IP TCP/IP Protocol Suite

Figure 11.3 Port numbers request response TCP/IP Protocol Suite

Figure 11.4 IP addresses versus port numbers TCP/IP Protocol Suite

Figure 11.5 ICANN ranges ICANN: Internet Corporation for Assigned Names and Numbers TCP/IP Protocol Suite

The well-known port numbers are less than 1024. Note: The well-known port numbers are less than 1024. TCP/IP Protocol Suite

Table 11.1 Well-known ports used with UDP TCP/IP Protocol Suite

$ 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

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

Figure 11.6 Socket address TCP/IP Protocol Suite

11.2 USER DATAGRAM UDP packets are called user datagrams and have a fixed-size header of 8 bytes. TCP/IP Protocol Suite

Figure 11.7 User datagram format TCP/IP Protocol Suite

UDP length = IP length − IP header’s length Note: UDP length = IP length − IP header’s length TCP/IP Protocol Suite

11.3 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

Figure 11.8 Pseudoheader for checksum calculation TCP/IP Protocol Suite

Figure 11.9 Checksum calculation of a simple UDP user datagram TCP/IP Protocol Suite

Optional Use of the Checksum The checksum is optional. If not used, the field is filled with 0s. TCP/IP Protocol Suite

11.4 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

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

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

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

Figure 11.10 Encapsulation and decapsulation TCP/IP Protocol Suite

Figure 11.11 Queues in UDP TCP/IP Protocol Suite

Figure 11.12 Multiplexing and demultiplexing TCP/IP Protocol Suite

11.5 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

11.6 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

Figure 11.13 UDP design TCP/IP Protocol Suite

Table 11.2 The control-block table at the beginning of examples TCP/IP Protocol Suite

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

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

Table 11.3 Control-block table after Example 3 TCP/IP Protocol Suite

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

Table 11.4 Control-block after Example 4 TCP/IP Protocol Suite

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

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

Figure 12.1 TCP/IP protocol suite

12.1 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

Table 12.1 Well-known ports used by TCP TCP/IP Protocol Suite

$ 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

Stream delivery service Figure 12.2 Stream delivery Stream delivery service TCP/IP Protocol Suite

Figure 12.3 Sending and receiving buffers TCP/IP Protocol Suite

Figure 12.4 TCP segments TCP/IP Protocol Suite

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

12.2 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

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

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 10001. 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

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

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

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

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

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

12.3 SEGMENT A packet in TCP is called a segment The topics discussed in this section include: Format Encapsulation TCP/IP Protocol Suite

Figure 12.5 TCP segment format TCP/IP Protocol Suite

Figure 12.6 Control field TCP/IP Protocol Suite

I Table 12.2 Description of flags in the control field TCP/IP Protocol Suite

Figure 12.7 Pseudoheader added to the TCP datagram TCP/IP Protocol Suite

The inclusion of the checksum in TCP is mandatory. Note: The inclusion of the checksum in TCP is mandatory. TCP/IP Protocol Suite

Figure 12.8 Encapsulation and decapsulation TCP/IP Protocol Suite

12.4 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

Figure 12.9 Connection establishment using three-way handshaking TCP/IP Protocol Suite

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

Note: A SYN + ACK segment cannot carry data, but does consume one sequence number. TCP/IP Protocol Suite

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

Figure 12.10 Data transfer TCP/IP Protocol Suite

Note: The FIN segment consumes one sequence number if it does not carry data. TCP/IP Protocol Suite

Figure 12.11 Connection termination using three-way handshaking +1 TCP/IP Protocol Suite

Note: The FIN + ACK segment consumes one sequence number if it does not carry data. TCP/IP Protocol Suite

Figure 12.12 Half-close TCP/IP Protocol Suite

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

Table 12.3 States for TCP TCP/IP Protocol Suite

server client Figure 12.13 State transition diagram + + + + MSL: Maximum Segment Lifetime TCP/IP Protocol Suite

Figure 12.14 Common scenario TCP/IP Protocol Suite

Figure 12.14 Common scenario 4-way handshake TCP/IP Protocol Suite

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

Figure 12.15 Three-way handshake TCP/IP Protocol Suite

Figure 12.16 Simultaneous open TCP/IP Protocol Suite

Figure 12.17 Simultaneous close TCP/IP Protocol Suite

Figure 12.18 Denying a connection TCP/IP Protocol Suite

Figure 12.19 Aborting a connection TCP/IP Protocol Suite

12.6 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

Figure 12.20 Sliding window TCP/IP Protocol Suite

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

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

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

Example 5 Figure 12.21 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

Figure 12.21 Example 5 TCP/IP Protocol Suite

Example 6 In Figure 12.21 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 12.22 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

Figure 12.22 Example 6 TCP/IP Protocol Suite

Example 7 In Figure 12.22 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 12.23 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

Figure 12.23 Example 7 TCP/IP Protocol Suite

Example 8 In Figure 12.23 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 12.24 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

Figure 12.24 Example 8 TCP/IP Protocol Suite

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

Note: To avoid shrinking the sender window, the receiver must wait until more space is available in its buffer. TCP/IP Protocol Suite

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

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

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

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

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

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

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

12.7 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

Checksum (mandatory in TCP) TCP/IP Protocol Suite

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

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

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

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

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

Retransmission Fast retransmission: retransmit the missing segments after three duplicate acks TCP/IP Protocol Suite

Note: In modern implementations, a retransmission occurs if the retransmission timer expires or three duplicate ACK segments have arrived. TCP/IP Protocol Suite

No retransmission timer is set for an ACK segment. Note: No retransmission timer is set for an ACK segment. TCP/IP Protocol Suite

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

Figure 12.25 Normal operation TCP/IP Protocol Suite

Figure 12.26 Lost segment TCP/IP Protocol Suite

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

Figure 12.27 Fast retransmission TCP/IP Protocol Suite

Figure 12.28 Lost acknowledgment TCP/IP Protocol Suite

Figure 12.29 Lost acknowledgment corrected by resending a segment TCP/IP Protocol Suite

Note: Lost acknowledgments may create deadlock if they are not properly handled. TCP/IP Protocol Suite

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

12.8 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

Figure 12.30 Router queues TCP/IP Protocol Suite

Figure 12.31 Packet delay and network load TCP/IP Protocol Suite

Figure 12.32 Throughput versus network load TCP/IP Protocol Suite

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

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

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

Figure 12.33 Slow start, exponential increase TCP/IP Protocol Suite

Note: In the slow start algorithm, the size of the congestion window increases exponentially until it reaches a threshold. TCP/IP Protocol Suite

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

Figure 12.34 Congestion avoidance, additive increase TCP/IP Protocol Suite

Note: In the congestion avoidance algorithm the size of the congestion window increases additively until congestion is detected. TCP/IP Protocol Suite

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

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

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

Figure 12.35 TCP congestion policy summary TCP/IP Protocol Suite

Figure 12.36 Congestion example TCP/IP Protocol Suite

12.9 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

Figure 12.37 TCP timers TCP/IP Protocol Suite

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

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

Note: In TCP, there can be only be one RTT measurement in progress at any time. TCP/IP Protocol Suite

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

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

Round Trip Time (RTT) Retransmission Timeout (RTO) TCP/IP Protocol Suite

Example 10 Let us give a hypothetical example. Figure 12.38 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 = 1.5 RTTS = 1.5 RTTD = 1.5 / 2 = 0.75 RTO = 1.5 + 4 . 0.75 = 4.5 TCP/IP Protocol Suite

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 = 2.5 RTTS = 7/8 (1.5) + 1/8 (2.5) = 1.625 RTTD = 3/4 (0.75) + 1/4 |1.625 − 2.5| = 0.78 RTO = 1.625 + 4 (0.78) = 4.74 TCP/IP Protocol Suite

Figure 12.38 Example 10 TCP/IP Protocol Suite

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

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

Example 11 Figure 12.39 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

Figure 12.39 Example 11 Calculate this! TCP/IP Protocol Suite

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

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

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

Time-Wait timer The time-wait timer (2 maximum segment lifetime) is used during connection termination TCP/IP Protocol Suite

12.10 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

Figure 12.40 Options TCP/IP Protocol Suite

Figure 12.41 End-of-option option TCP/IP Protocol Suite

EOP can be used only once. Note: EOP can be used only once. TCP/IP Protocol Suite

Figure 12.42 No-operation option TCP/IP Protocol Suite

NOP can be used more than once. Note: NOP can be used more than once. TCP/IP Protocol Suite

Indicate the data only Max. 65535 bytes Default=536 bytes Figure 12.43 Maximum-segment-size option Indicate the data only Max. 65535 bytes Default=536 bytes TCP/IP Protocol Suite

Note: The value of MSS is determined during connection establishment and does not change during the connection. TCP/IP Protocol Suite

Window Scale Factor The window size in TCP header is only 16 bits. For a long fat pipe, 65535 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

Figure 12.44 Window-scale-factor option TCP/IP Protocol Suite

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

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

Figure 12.45 Timestamp option TCP/IP Protocol Suite

Note: One application of the timestamp option is the calculation of round trip time (RTT). TCP/IP Protocol Suite

Example 12 Figure 12.46 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

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 12000 to 12099. 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 12000 (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 12200 and inserts the value of tsrecent in the echo reply field. TCP/IP Protocol Suite

Example 12 (Continued) The value of tsrecent will not change until it is replaced by a new segment that carries byte 12200 (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

Figure 12.46 Example 12 TCP/IP Protocol Suite

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

The timestamp option can also be used for PAWS. Note: The timestamp option can also be used for PAWS. TCP/IP Protocol Suite

Figure 12.47 SACK TCP/IP Protocol Suite

Example 13 Let us see how the SACK option is used to list out-of-order blocks. In Figure 12.48 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 2000. 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

Figure 12.48 Example 13 TCP/IP Protocol Suite

Example 14 The example in Figure 12.49 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

Figure 12.49 Example 14 TCP/IP Protocol Suite

Example 15 The example in Figure 12.50 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

Figure 12.50 Example 15 TCP/IP Protocol Suite

12.11 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

Figure 12.51 TCP package TCP/IP Protocol Suite

Figure 12.52 TCBs Other TCP parameters TCP/IP Protocol Suite

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

Figure 13.1 TCP/IP protocol suite

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

13.1 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

Table 13.1 Some SCTP applications TCP/IP Protocol Suite

Figure 13.2 Multiple-stream concept TCP/IP Protocol Suite

An association in SCTP can involve multiple streams. Note: An association in SCTP can involve multiple streams. TCP/IP Protocol Suite

Figure 13.3 Multihoming concept TCP/IP Protocol Suite

SCTP association allows multiple IP addresses for each end. Note: SCTP association allows multiple IP addresses for each end. TCP/IP Protocol Suite

13.2 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

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

To distinguish between different streams, SCTP uses an SI. Note: To distinguish between different streams, SCTP uses an SI. TCP/IP Protocol Suite

Note: To distinguish between different data chunks belonging to the same stream, SCTP uses SSNs. TCP/IP Protocol Suite

Figure 13.4 Comparison between a TCP segment and an SCTP packet TCP/IP Protocol Suite

TCP has segments; SCTP has packets. Note: TCP has segments; SCTP has packets. TCP/IP Protocol Suite

Note: In SCTP, control information and data information are carried in separate chunks. TCP/IP Protocol Suite

Figure 13.5 Packet, data chunks, and streams TCP/IP Protocol Suite

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

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

13.3 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

Figure 13.6 SCTP packet format TCP/IP Protocol Suite

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

Figure 13.7 General header TCP/IP Protocol Suite

Figure 13.8 Common layout of a chunk TCP/IP Protocol Suite

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

Table 13.2 Chunks TCP/IP Protocol Suite

Note: The number of padding bytes are not included in the value of the length field. TCP/IP Protocol Suite

Figure 13.9 DATA chunk TCP/IP Protocol Suite

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

Figure 13.10 INIT chunk TCP/IP Protocol Suite

Format for variable length parameters 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Parameter Type | Parameter Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -+ \ \ / one or more Parameter Value / \ \ TCP/IP Protocol Suite

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

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

Figure 13.11 INIT ACK chunk TCP/IP Protocol Suite

Note: No other chunk can be carried in a packet that carries an INIT ACK chunk. TCP/IP Protocol Suite

Figure 13.12 COOKIE ECHO chunk TCP/IP Protocol Suite

Figure 13.13 COOKIE ACK TCP/IP Protocol Suite

Figure 13.14 SACK chunk TCP/IP Protocol Suite

Figure 13.15 HEARTBEAT and HEARTBEAT ACK chunks TCP/IP Protocol Suite

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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 13.17 ERROR chunk 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code | Cause Length | | Cause-specific Information | TCP/IP Protocol Suite

Table 13.3 Errors TCP/IP Protocol Suite

Figure 13.18 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

13.4 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

A connection in SCTP is called an association. Note: A connection in SCTP is called an association. TCP/IP Protocol Suite

Figure 13.19 Four-way handshaking TCP/IP Protocol Suite

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

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

Figure 13.20 Simple data transfer TCP/IP Protocol Suite

Note: The acknowledgment in SCTP defines the cumulative TSN, the TSN of the last DATA chunk received in order. TCP/IP Protocol Suite

Figure 13.21 Association termination TCP/IP Protocol Suite

Figure 13.22 Association abortion TCP/IP Protocol Suite

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

Figure 13.23 State transition diagram TCP/IP Protocol Suite

Table 13.4 States for SCTP TCP/IP Protocol Suite

Figure 13.24 A common scenario of states TCP/IP Protocol Suite

Figure 13.25 Simultaneous open TCP/IP Protocol Suite

Figure 13.26 Simultaneous close TCP/IP Protocol Suite

13.6 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

Figure 13.27 Flow control, receiver site TCP/IP Protocol Suite

Figure 13.28 Flow control, sender site TCP/IP Protocol Suite

Figure 13.29 Flow control scenario TCP/IP Protocol Suite

13.7 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

Figure 13.30 Error control, receiver site TCP/IP Protocol Suite

Figure 13.31 Error control, sender site TCP/IP Protocol Suite

Figure 13.32 New state at the sender site after receiving a SACK chunk TCP/IP Protocol Suite

13.8 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