Chapter 10 Figure 10.1 Position of IGMP in the network layer Objectives Upon completion you will be able to: Know the purpose of IGMP Know the types of IGMP messages Understand how a member joins a group and leaves a group Understand membership monitoring Understand how an IGMP message is encapsulated Understand the interactions of the modules of an IGMP package TCP/IP ProtocolSuite 1 TCP/IP ProtocolSuite 2 Unicast Traffic Unicast Traffic Unicast applications send one copy of each packet to every client unicast address TCP/IP ProtocolSuite 3 TCP/IP ProtocolSuite 4
Unicast Traffic Broadcast Traffic Hosts not using a multimedia application must still process the broadcast traffic TCP/IP ProtocolSuite 5 TCP/IP ProtocolSuite 6 Multicast Traffic \IP Multicast Characteristics A multicast server sends out a single data stream to multiple clients using a special multicast address. TCP/IP ProtocolSuite 7 Transmits to a host group Delivers with best effort reliability Supports dynamic membership Supports diverse numbers and locations Supports membership in more than one group TCP/IP ProtocolSuite 8
IP Multicast Group Membership Group Membership Multicast uses query and report messages to establish and maintain group membership TCP/IP ProtocolSuite 9 TCP/IP ProtocolSuite 10 IGMP: Internet Group Management Protocol IGMPv1 How hosts tell routers about group membership Routers solicit group membership from directly connected hosts RFC 1112 specifies first version of IGMP RFC 2236 specifies version 2 of IGMP RFC 3376 specifies version 3 of IGMP Supported on UNIX systems, PCs, and MACs IGMP messages not forwarded by routers IGMP is a group management protocol. It helps a multicast router create and update a list of loyal members related to each router interface. RFC 1112 Host extensions for IP Multicasting Membership Queries Querier sends IGMP query messages to 224.0.0.1 with ttl = 1, determining what group addresses have members on that subnet One router on LAN is designated/elected to send queries, but all routers listen to the replies/reports Query interval 60 120 seconds Membership Reports IGMP report sent by one host suppresses sending by others; sending based on random timer per group Restrict to one report per group per LAN Unsolicited reports sent by host, when it first joins the group TCP/IP ProtocolSuite 11 TCP/IP ProtocolSuite 12
IGMPv1 Packet Format IGMPv1 Joining a Group Joining member sends report to 224.1.1.1 immediately upon joining TCP/IP ProtocolSuite 13 TCP/IP ProtocolSuite 14 IGMPv1 General Queries IGMPv1 Maintaining a Group H1 224.1.1.1 H2 224.1.1.1 H3 H1 H2 H3 Report #2 Suppressed #3 IGMPv1 General Query to 224.0.0.1 Multicast Router The router periodically sends general queries to 224.0.0.1 to determine memberships IGMPv1 Query to 224.0.0.1 #1 Router sends periodic queries #1 #2 One member per group per subnet report #3 Other members suppress reports TCP/IP ProtocolSuite 15 TCP/IP ProtocolSuite 16
IGMPv1 Leaving a Group IGMPv2 Router sends periodic queries Hosts silently leave group Router continues sending periodic queries No reports for group received by router Group times out TCP/IP ProtocolSuite 17 RFC 2236 Leave Group message Host sends leave message if it leaves the group and is the last member (reduces leave latency in comparison to v1); sent to 224.0.0.2 (all routers) Group-specific query After Host sends Leave Group message, Router sends Groupspecific queries to make sure there are no members present before stopping to forward data for the group for that subnet TCP/IP ProtocolSuite 18 IGMPv2 IGMPv2 Joining a Group Querier election mechanism On multiaccess networks, an IGMP Querier router is elected based on lowest IP address. Only the Querier router sends Querys. Query-Interval Response Time General Queries specify Max. Response Time which inform hosts of the maximum time within which a host must respond to General Query. (Improves burstiness of the responses.) Backward compatible with IGMPv1 172.16.41.1 172.16.41.2 172.16.41.3 H1 224.1.1.1 Report RTR141 172.16.41.141 Joining member sends report to 224.1.1.1 immediately upon joining (same as IGMPv1) H2 H3 TCP/IP ProtocolSuite 19 TCP/IP ProtocolSuite 20
Figure 10.5 Membership report IGMPv2 Querier Election 172.16.41.1 172.16.41.2 172.16.41.3 H1 H2 H3 In IGMP, a membership report is sent twice, one after the other. If first one is lost or damage, the second one replaces it. Query IGMP Non-Querier 172.16.41.143 IGMPv2 Query IGMP Querier 172.16.41.141 TCP/IP ProtocolSuite 21 Intially all routers send out a query Router with lowest IP address elected querier Other routers become non-queriers TCP/IP ProtocolSuite 22 IGMPv2 Maintaining a Group Figure 10.7 General query message 172.16.41.1 172.16.41.2 172.16.41.3 H1 224.1.1.1 H2 224.1.1.1 H3 Report Suppressed Query IGMPv2 172.16.41.141 Router sends periodic queries One member per group per subnet report (delayed response : 1 10 s) Other members suppress reports The general query message does not define a particular group. TCP/IP ProtocolSuite 23 TCP/IP ProtocolSuite 24
IGMPv2 Leaving a Group IGMPv2 Leaving a Group (Cont.) 172.16.41.1 172.16.41.2 172.16.41.3 H1 224.1.1.1 H2 224.1.1.1 H3 172.16.41.1 172.16.41.2 172.16.41.3 H1 H2 224.1.1.1 H3 #1 Leave to 224.0.0.2 #3 Report to 224.1.1.1 #1 Leave to 224.0.0.2 RTR141 172.16.41.141 Group Specific Query to 224.1.1.1 #2 RTR141 172.16.41.141 Group-specific Query to 224.1.1.1 #2 #1 H2 leaves group; sends leave message Router sends group-specific query A remaining member host sends report; group remains active #2 #3 TCP/IP ProtocolSuite 25 Last host leaves group; sends Leave message #1 Router sends group-specific query; #2 no report is received, group times out TCP/IP ProtocolSuite 26 Figure 10.6 Leave report Figure 10.2 IGMP message types TCP/IP ProtocolSuite 27 TCP/IP ProtocolSuite 28
IGMPv2 Packet Format Table 10.1 IGMP type field Multiple message types Max. Resp. Time Max. time before sending a responding report in 1/10 secs (default = 10 secs) Group Address: Multicast group address (0.0.0.0 for general queries) TCP/IP ProtocolSuite 29 TCP/IP ProtocolSuite 30 Example 1 Imagine there are three hosts in a network as shown in Figure 10.8. A query message was received at time 0; the random delay time (in tenths of seconds) for each group is shown next to the group address. Show the sequence of report messages. Example 1 (Continued) Solution The events occur in this sequence: a. Time 12: The timer for 228.42.0.0 in host A expires and a membership report is sent, which is received by the router and every host including host B which cancels its timer for 228.42.0.0. b. Time 30: The timer for 225.14.0.0 in host A expires and a membership report is sent, which is received by the router and every host including host C which cancels its timer for 225.14.0.0. c. Time 50: The timer for 238.71.0.0 in host B expires and a membership report is sent, which is received by the router and every host. d. Time 70: The timer for 230.43.0.0 in host C expires and a membership report is sent, which is received by the router and every host including host A which cancels its timerfor 230.43.0.0. TCP/IP ProtocolSuite 31 TCP/IP ProtocolSuite 32
10.4 ENCAPSULATION Figure 10.9 Encapsulation of IGMP packet The IGMP message is encapsulated in an IP datagram, which is itself encapsulated in a frame. The topics discussed in this section include: IP Layer Data Link Layer Netstat Utility TCP/IP ProtocolSuite 33 TCP/IP ProtocolSuite 34 Multicast IP Address Structure Note: The IP packet that carries an IGMP packet has a value of 2 in its protocol field. The IP packet that carries an IGMP packet has a value of 1 in its TTL field. A Class D address consists of 1110 as the high-order bits in the first octet, followed by a 28-bit group address. Class D addresses range from 224.0.0.0 through 239.255.255.255. The high-order bits in the first octet identify this 224-base address. TCP/IP ProtocolSuite 35 TCP/IP ProtocolSuite 36
Figure 10.10 Mapping class D to Ethernet physical address Table 10.2 Destination IP addresses TCP/IP ProtocolSuite 37 TCP/IP ProtocolSuite 38 Figure 10.10 Mapping class D to Ethernet physical address : Example 1 Figure 10.10 Mapping class D to Ethernet physical address : Example 2 TCP/IP ProtocolSuite 39 TCP/IP ProtocolSuite 40
Example 2 Note: An Ethernet multicast physical address is in the range 01:00:5E:00:00:00 to 01:00:5E:7F:FF:FF. Change the multicast IP address 230.43.14.7 to an Ethernet multicast physical Solution We can do this in two steps: a. We write the rightmost 23 bits of the IP address in hexadecimal. This can be done by changing the rightmost 3 bytes to hexadecimal and then subtracting 8 from the leftmost digit if it is greater than or equal to 8. In our example, the result is 2B:0E:07. b. We add the result of part a to the starting Ethernet multicast address, which is (01:00:5E:00:00:00). The result is 01:00:5E:2B:0E:07 TCP/IP ProtocolSuite 41 TCP/IP ProtocolSuite 42 Example 3 Multicast Tunneling Change the multicast IP address 238.212.24.9 to an Ethernet multicast address. Solution a. The right-most three bytes in hexadecimal are D4:18:09. We need to subtract 8 from the leftmost digit, resulting in 54:18:09.. b. We add the result of part a to the Ethernet multicast starting address. The result is 01:00:5E:54:18:09 Problem Not all routers are multicast capable Want to connect domains with non-multicast routers between them Solution Encapsulate multicast packets in unicast packet Tunnel multicast traffic across non-multicast routers Internet MBONE Multicast capable virtual subnet of Internet Native multicast regions connection with tunnels TCP/IP ProtocolSuite 43 TCP/IP ProtocolSuite 44
Figure 10.11 Tunneling Figure 10.11 Tunneling Multicast Router 1 encapsulates multicast packets for groups that have receivers outside of network 1. It encapsulates them as unicast IPin-IP packets. Multicast Router 1 UR1 Encapsulated Data Packet Unicast Routers UR2 Multicast Router 2 Multicast Router 2 decapsulates IPin-IP packets. It then forwards them using Reverse Path Multicast. Sender 1 Network 1 Receiver Network 2 TCP/IP ProtocolSuite 45 Mbone (1994) TCP/IP ProtocolSuite 46 Mbone (1996) Experimental Multicast Backbone on the Internet Based on the virtual connection between multicast routers TCP/IP ProtocolSuite 47 TCP/IP ProtocolSuite 48
Example 4 Example 4 We use netstat with three options, -n, -r, and -a. The -n option gives the numeric versions of IP addresses, the -r option gives the routing table, and the -a option gives all addresses (unicast and multicast). Note that we show only the fields relative to our discussion. $ netstat -nra Kernel IP routing table Destination Gateway Mask Flags Iface 153.18.16.0 0.0.0.0 255.255.240.0 U eth0 169.254.0.0 0.0.0.0 255.255.0.0 U eth0 127.0.0.0 0.0.0.0 255.0.0.0 U lo 224.0.0.0 0.0.0.0 224.0.0.0 U eth0 0.0.0.0 153.18.31.254 0.0.0.0 UG eth0 Result of route print in Windows XP. Any packet with a multicast address from 224.0.0.0 to 239.255.255.255 is masked and delivered to the Ethernet interface. TCP/IP ProtocolSuite 49 TCP/IP ProtocolSuite 50 10.5 IGMP PACKAGE Figure 10.12 IGMP package We can show how IGMP can handle the sending and receiving of IGMP packets through our simplified version of an IGMP package. In our design an IGMP package involves a group table, a set of timers, and four software modules. The topics discussed in this section include: Group Table Timers Group-Joining Module Group-Leaving Module Input Module Output Module TCP/IP ProtocolSuite 51 TCP/IP ProtocolSuite 52
Figure 10.13 Group table Chapter 11 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 ProtocolSuite 53 TCP/IP ProtocolSuite 54 Figure 11.1 Position of UDP in the TCP/IP protocol suite User Datagram Protocol UDP is supports unreliable transmissions of datagrams UDP merely extends the host-to-to-host delivery service of IP datagram to an application-to-application service The only thing that UDP adds is multiplexing and demultiplexing Applications Applications UDP UDP IP IP IP IP IP TCP/IP ProtocolSuite 55 TCP/IP ProtocolSuite 56
11.1 PROCESS-TO-PROCESS COMMUNICATION Before we examine UDP, we must first understand host-to to-host communication and process-to to-process communication and the difference between them. Figure 11.2 UDP versus IP The topics discussed in this section include: Port Numbers Socket Addresses TCP/IP ProtocolSuite 57 TCP/IP ProtocolSuite 58 Figure 11.3 Port numbers Figure 11.4 IP addresses versus port numbers TCP/IP ProtocolSuite 59 TCP/IP ProtocolSuite 60
Figure 11.5 ICANN ranges Table 11.1 Well-known ports used with UDP The well-known port numbers are less than 1024. TCP/IP ProtocolSuite 61 TCP/IP ProtocolSuite 62 Example 1 Example 1 (Continued) 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 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 See Next Slide TCP/IP ProtocolSuite 63 TCP/IP ProtocolSuite 64
Figure 11.6 Socket address 11.2 USER DATAGRAM UDP packets are called user datagrams and have a fixed-size header of 8 bytes. TCP/IP ProtocolSuite 65 TCP/IP ProtocolSuite 66 Figure 11.7 User datagram format 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: UDP length = IP length IP header s length Checksum Calculation at Sender Checksum Calculation at Receiver Optional Use of the Checksum TCP/IP ProtocolSuite 67 TCP/IP ProtocolSuite 68
Figure 11.8 Pseudoheader for checksum calculation Figure 11.9 Checksum calculation of a simple UDP user datagram TCP/IP ProtocolSuite 69 TCP/IP ProtocolSuite 70 11.4 UDP OPERATION Figure 11.10 Encapsulation and decapsulation 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 ProtocolSuite 71 TCP/IP ProtocolSuite 72
Figure 11.11 Queues in UDP Figure 11.12 Multiplexing and demultiplexing TCP/IP ProtocolSuite 73 TCP/IP ProtocolSuite 74 11.5 USE OF UDP We discuss some uses of the UDP protocol in this section. 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 ProtocolSuite 75 TCP/IP ProtocolSuite 76
Figure 11.13 UDP design Table 11.2 The control-block table at the beginning of examples TCP/IP ProtocolSuite 77 TCP/IP ProtocolSuite 78 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. 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). Table 11.3 Control-block table after Example 3 TCP/IP ProtocolSuite 79 TCP/IP ProtocolSuite 80
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. Table 11.4 Control-block after Example 4 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 ProtocolSuite 81 TCP/IP ProtocolSuite 82