Multicasting A message can be unicast, multicast, or broadcast

Embed Size (px)

Citation preview

  • Slide 1
  • Multicasting A message can be unicast, multicast, or broadcast.
  • Slide 2
  • Unicasting In unicasting, the router forwards the received packet through only one of its interfaces.
  • Slide 3
  • Multicasting
  • Slide 4
  • In multicasting, the router may forward the received packet through several of its interfaces. In multicasting communications there is one source and a group of destinations In broadcasting there is one source but all of other hosts are the destinations
  • Slide 5
  • Multicasting and multiple unicasting Multicasting starts with one single packet from the source that is duplicated by the router The destination address in each packet is the same for all duplicates In multiple unicasting several packets starts from the source. Destination address will be different in each packet There may be multiple copies traveling between two routers---E.g. Email There will be a delay between packets in MU
  • Slide 6
  • Multicasting versus multiple unicasting
  • Slide 7
  • Multicast Applications Multicasting has many applications today such as access to distributed databases information dissemination teleconferencing distance learning
  • Slide 8
  • Multicast Routing In multicast routing, each involved router needs to construct a shortest path tree for each group When a router receives a multicast packet it forwards to different networks Two types Source based tree Group shared tree
  • Slide 9
  • Source Based Tree In the source-based tree approach, each router needs to have one shortest path tree for each group. If the number of groups is m, each router needs to have m shortest path trees, one for each group
  • Slide 10
  • Source-based tree approach
  • Slide 11
  • Group Shared Tree In the group-shared tree approach, only the core router, which has a shortest path tree for each group, is involved in multicasting. Instead of each router having m shortest path tree, only one designated router called the centre core or rendezvous router, takes the responsibility of distributing multicast traffic
  • Slide 12
  • Group-shared tree approach
  • Slide 13
  • Taxonomy of common multicast protocols
  • Slide 14
  • Mulitcast link state routing Multicast link state routing uses the source- based tree approach. Information about a group comes from IGMP
  • Slide 15
  • Multicast Open Shortest Path First (MOSPF) Multicast Open Shortest Path First protocol is an extension of OSPF protocol that uses multicast link state routing to create source based tree.
  • Slide 16
  • Multicast distance vector routing Multicast distance vector routing uses source based tree But router never makes the routing table When a router receives a multicast packet it forwards the packet as though it is consulting a routing table.
  • Slide 17
  • Flooding A router receives a packet and without even looking at the destination group address, send it out from every interface except the one from which it was received.
  • Slide 18
  • Reverse path forwarding(RPF) In RPF a router forwards only the copy that has traveled the shortest path from the source to the router. No loops But duplicate copies may receive
  • Slide 19
  • RPF
  • Slide 20
  • Figure 15.9 Problem with RPF
  • Slide 21
  • Reverse Path Broadcasting(RPB)
  • Slide 22
  • Figure 15.10 RPF versus RPB
  • Slide 23
  • Reverse path multicating(RPM) RPM adds pruning and grafting to RPB to create a multicast shortest path tree that supports dynamic membership changes
  • Slide 24
  • RPF, RPB, and RPM
  • Slide 25
  • Distance Vector Multicast Routing Protocol (DVMRP) Is an implementation of multicast distance vector routing. It is a source based routing protocol
  • Slide 26
  • CBT The Core-Based Tree (CBT) protocol is a group-shared protocol that uses a core as the root of the tree. The autonomous system is divided into regions and a core (center router or rendezvous router) is chosen for each region.
  • Slide 27
  • Every router is informed of the unicast address of the selected rendezvous router Each router then sends a unicast join message Intermediate router extracts information such as unicast address of sender and interfaces through which it has passed When all message received a tree is formed at rendezvous router
  • Slide 28
  • Group-shared tree with rendezvous router
  • Slide 29
  • Sending a multicast packet to the rendezvous router
  • Slide 30
  • In CBT, the source sends the multicast packet (encapsulated in a unicast packet) to the core router. The core router decapsulates the packet and forwards it to all interested interfaces
  • Slide 31
  • If router wants to leave the group it sends a leave message to upstream router. Difference between DVMRP 1) tree is first made and then pruned but in CBT initial no tree, joining gradually makes the tree 2) made from the root up but CBT formed from the leaves down
  • Slide 32
  • 32 PIM Protocol Independent Multicast (PIM) is the name given to two independent multicast routing protocols: Protocol Independent Multicast, Dense Mode (PIM-DM) and Protocol Independent Multicast, Sparse Mode (PIM-SM).
  • Slide 33
  • 33 PIM-DM is used in a dense multicast environment, such as a LAN.
  • Slide 34
  • 34 PIM-DM uses RPF and pruning/grafting strategies to handle multicasting. Like DVMRP,However, it is independent from the underlying unicast protocol.
  • Slide 35
  • 35 PIM-SM is used in a sparse multicast environment such as a WAN.
  • Slide 36
  • 36 PIM-SM is similar to CBT but uses a simpler procedure. Does not require acknowledgement Creates backup set of rendezvous point for each region to cover RP failures Can switch from group shared tree to source based tree
  • Slide 37
  • Host Configuration: BOOTP and DHCP
  • Slide 38
  • BOOTP The Bootstrap Protocol (BOOTP) is a client/server protocol that configures a diskless computer or a computer that is booted for the first time. BOOTP provides the IP address, subnet mask, the address of a default router, and the address of a name server. Configuration file
  • Slide 39
  • RARP provides only IP address Both client and server should be on same network
  • Slide 40
  • Operations BOOTP server issues a passive open command on UDP port number 67 and waits for client A BOOTP client issues an active open command on port number 68 This message is encapsulated in UDP datagram and in turn encapsulated in IP datagram IP addresses of client and server will be all zeros and all ones Server responds
  • Slide 41
  • Client and server on the same network
  • Slide 42
  • Client and server on two different networks
  • Slide 43
  • Use of UDP ports
  • Slide 44
  • Using TFTP In the reply message server defines the path name of a file in which the client can find complete booting information. Client then uses TFTP to obtain the rest of information
  • Slide 45
  • Error Control BOOTP requires UDP uses the checksum BOOTP client uses timers and a retransmission policy if it does not receive the BOOTP reply to a request. Timers will be set randomly
  • Slide 46
  • BOOTP packet format
  • Slide 47
  • Operation Code: 8 bit: 1 request 2 reply Hardware type: type of physical network for Ethernet value is 1 Hardware Length: 8 bit: length of physical address Hop count: 8bit Specifies max no of hops a packet can travel Transaction ID: 4 byte: integer Number of seconds: 16 bit: elapsed since the client started to boot Client IP address : 4 byte Your IP address : 4 byte
  • Slide 48
  • Server IP address : 4 byte Gateway IP address: 4 byte: IP address of router Client hardware address: Physical address of client Server name: optional 64 byte : contains domain name of the server Bootfile name: optional 128 byte: full path name of the bootfile Options: 64 byte: only in reply it is used server uses a number called magic cookie in the format of IP address with the value: 99.130.83.99
  • Slide 49
  • Option format
  • Slide 50
  • Options for BOOTP
  • Slide 51
  • DHCP In BOOTP binding is predetermined The Dynamic Host Configuration Protocol (DHCP) provides static and dynamic address allocation that can be manual or automatic
  • Slide 52
  • Static Address allocation Backward compatible with BOOTP A DHCP server has a database that statically binds physical address to IP address
  • Slide 53
  • Dynamic Address Allocation Use a second database- pool of IP addresses When a DHCP client requests First check the static database If not, the DHCP server selects a temporary IP address from the pool of available(unused) and assigns an IP address for a negotiable period of time.
  • Slide 54
  • Manual and automatic configuration Mapping the IP address to physical address configuration In BOOTP it is manual In DHCP it has both manual and automatic Static addresses are created manually Dynamic addresses are created automatically
  • Slide 55
  • Packet Format
  • Slide 56
  • DHCP packet
  • Slide 57
  • Flag 1 bit flag to let the client specify a forced broadcast reply from the server
  • Slide 58
  • Options Tag 53
  • Slide 59
  • Options Other option include 51 :Lease time 58 : Renewal (T1) time value 59 : Rebinding (T2) time value
  • Slide 60
  • Transition States DHCP client transitions from one state to another depending on the message it receives or sends
  • Slide 61
  • DHCP transition diagram
  • Slide 62
  • Initializing state When the DHCP client first starts, it is in the initializing state. Client broadcast the DHCPDISCOVER message Using port 67
  • Slide 63
  • Selecting State After sending DHCPDISCOVER message client goes to selecting state Servers respond with DHCPOFFER Offers IP address, Lease time Default lease time is 1hour Client select the offer of one server and send DHCPREQUEST message Client goes to requesting state
  • Slide 64
  • Requesting State The client remains in the requesting state until it receives a DHCPACK message from the server which creates a binding between the client physical address and its IP address. After the receipt of DHCPACK client goes to bound state
  • Slide 65
  • Bound State Client uses the IP address until the lease expires When 50% of the lease period is reached, client sends another DHCPREQUEST to ask for renewal. Then goes to renewal state
  • Slide 66
  • Renewal state Client remains in the renewal state until one of two events happens 1) It can receive a DHCPACK, which renews the lease agreement Client reset the timer goes back to bound state
  • Slide 67
  • 2) No DHCPACK is received and 87.5 % of the lease time expires, the client goes to rebinding state
  • Slide 68
  • Rebinding state The client remains in rebinding state until of three events happens 1) Client receives a DHCPNACK 2) The lease time expires 3) DHCPACK In the first two it goes to initializing state and try to get another IP address In the third it goes to bound state
  • Slide 69
  • Exchanging messages