Algor lgorit ithms hms and and Prot otocols ocols for or IP - PDF document

CMPE 252A: Computer Networks Set 10: Algor lgorit ithms hms and and Prot otocols ocols for or IP Mult ulticas icasting ing 1 Multicasting  Uses:  Multimedia “ broadcast ” : IP radio, webcasts  Teleconferencing: multiparty videoconferencing with (Mbone, CUSeeMe)  Database replication  Distributed computing: immediate updates to all members  Real-time workgroups: multimedia collaboration  System management: concerted file updates to group of hosts  Stock ticker: low-bandwidth quotes to millions of hosts (cf. Pointcast)  Single LAN segment:  straightforward (IEEE 802 includes provision for MAC- layer multicast addresses) 2 Multicasting  Purpose: Support one-to-many and many-to-many communication needed for many applications across LANs and WANs.  Problem: To minimize the communication and processing overhead entailed in disseminating the same data packets to a group of receivers.  Goal: Identify the receiver set in a convenient way and distribute packets to the set efficiently.  Approach:  Disseminate packets over a tree spanning all the intended receivers.  Identify the receivers with a group identifier or the set of receiver identifiers. 3 1

IP Multicast Architecture  Based on Steve Deering ’ s original proposal (SIGCOMM 88 Proceedings; his PhD thesis)  The architecture expands LAN multicasting to the Internet.  It consists of three basic components:  Group addressing based on globally unique identifiers (IP multicast addresses)  Separation of senders and receivers with anonymous receiver affiliation  A tree-based routing and group structure  Advantages: Efficiency of packet forwarding and simplicity  Disadvantages: Scalability, difficult to adapt to group dynamics, limited services 4 IP Multicast Idea Addresses used:  224.0.0.0 through 239.255.255.255 (the former Class D addresses in IPv4) Abstraction:   multicast address associated with multicast group  host joins / leaves group and receives address dynamically  sender host sends packets to multicast group (one or more destinations) not individuals!  routers deliver to all hosts that joined group address To avoid unnecessary duplication of  packets, routers must route packets using source and destination addresses, and an efficient routing structure must be built! 5 IP Internet Multicasting R R R R G R R R R R R R R R R G G 6 2

Internet Group Management Protocol (IGMP) RFC 1112 - used by hosts and routers to exchange multicast group  membership information over LAN Multicast routers use IGMP in conjunction with a multicast routing protocol,  to support IP multicasting across the Internet. Takes advantage of broadcast nature of LAN to updates - IGMP v1 - 3  Two kinds of packets: query / response  7 Constructing The Multicast Routing Structure  If routers know the topology of the network, they can compute a multicast routing tree locally.  If routers maintain only distance or path information to destinations, multicast routing tree must be computed in a distributed manner.  Internet multicast routing protocols are based on reverse path forwarding. 8 Link-State Multicast  Goal: route packets to all hosts that joined multicast group address  Each host on a LAN periodically announces the groups to which it belongs (IGMP).  Each router uses link-state flooding to distribute  cost of links to neighbors  multicast addresses it wants to receive (hosts joined group)  Each router computes  regular unicast routing (Dijkstra's algorithm to compute shortest- path spanning tree for each source/group pair)  spanning tree for M nodes joining to each active multicast address  Augment link-state update messages to include set of groups that have members on a particular LAN.  Each router caches tree for currently active source/group pairs.  Possible algorithm:  find node with smallest host address among M  use Dijkstra to build tree, rooted at that host reaching all M nodes 9 3

Limitations of Link-State Multicasting  Routers need to maintain too much state for each multicast group.  Routers need to send many more link-state updates.  Routers need to compute a multicast routing tree for each source of a group in the worst case, in order to decide when to forward packets. 10 Multicast Extensions to Open Shortest Path First (MOSPF)  RFC-1583: OSPFv2 - Interior Gateway Protocol (IGP) specifically designed to distribute unicast topology information among routers belonging to a single Autonomous System  RFC-1584: MOSPF routers maintain a current image of the network topology through the unicast OSPF link-state routing protocol  Extends OSPF by providing the ability to route multicast IP traffic  Extension is backward compatible so that routers running MOSPF will interoperate with non-multicast OSPF routers when forwarding unicast IP data traffic. 11 Distributed Approaches for Building Multicast Trees Approaches:  Source-based tree: One tree per source  shortest path trees  reverse path forwarding  Group-shared tree: Entire group uses one tree  Minimal spanning (Steiner)  Center-based trees 12 4

Shortest Path Tree  Multicast forwarding tree: tree of shortest path routes from source to all receivers  Dijkstra ’ s algorithm S: source LEGEND R1 2 R4 router with attached 1 group member R2 router with no attached 3 4 R5 group member link used for forwarding, R3 i i indicates order link R7 R6 added by algorithm 13 Reverse Path Forwarding q Rely on router ’ s knowledge of unicast shortest path from it to sender q Each router has simple forwarding behavior: if (mcast datagram received on incoming link on shortest path back to “ center ” ) then flood datagram onto all outgoing links else ignore datagram 14 Reverse Path Forwarding: Example S: source LEGEND R1 R4 router with attached group member R2 router with no attached R5 group member R3 datagram is forwarded R7 R6 datagram should not be forwarded • Additional signaling is needed to attain the desired tree. • Use information about distance to source to avoid forwarding to equidistant neighbors (R2 and R4, R3 and R6) 15 5

Reverse Path Forwarding: Pruning  “Prune” messages sent to upstream neighbors other than parent (eliminate chords).  Forwarding tree contains subtrees with no mcast group members  No need to forward datagrams down “receiver empty” subtree.  “ prune ” msgs sent upstream by router with no downstream group members LEGEND S: source R1 router with attached R4 group member router with no attached R2 P group member P R5 P prune message P links with multicast R3 forwarding R7 R6 16 Distance-Vector Multicast Routing Protocol (DVMRP)  Implemented by the mrouted program.  Specified in RFC-1075.  Implemented version differs in packet format, different tunnel format, additional packet types.  Maintains routing knowledge via a distance- vector routing protocol:  Much like RIP, described in RFC-1058  Routers maintain hop count to all possible multicast sources. 17 DVMRP  DVMRP: distance vector multicast routing protocol, RFC1075  flood and prune: reverse path forwarding, source-based tree  RPF tree based on DVMRP ’ s own routing tables constructed by communicating DVMRP routers  no assumptions about underlying unicast  initial datagram to mcast group flooded everywhere via RPF  routers not wanting group: send upstream prune msgs 18 6

DVMRP: continued…  soft state: DVMRP router periodically (1 min.) “ forgets ” branches are pruned:  mcast data again flows down un-pruned branch  downstream router: re-prune or else continue to receive data  routers can quickly regraft to tree  following IGMP join at leaf  odds and ends  Mbone routing was done using DVMRP  Replaced by PIM 19 Tunneling How do we connect “ islands ” of multicast routers in a “ sea ” of unicast routers? logical topology physical topology q mcast datagram encapsulated inside “ normal ” (non-multicast-addressed) datagram q normal IP datagram sent thru “ tunnel ” via regular IP unicast to receiving mcast router q receiving mcast router unencapsulates to get mcast datagram 20 Problems with Basic Approach  Flooding the Internet to establish a multicast routing tree is not an option!  This is the key reason why multicasting (based on DVMRP) cannot be deployed on a large scale.  The problem stems from the lack of addressing information in an IP multicast address!  Where is a multicast group on the Internet?  The solution to this problem is to use special nodes as the “ address ” of a group 21 7