Multicast: one sender to many receivers Multicast: one sender to many receivers Multicasting Multicasting Multicast: act of sending datagram to multiple receivers with single “transmit” operation � analogy: one teacher to many students By the end of this lecture, you should be able to…. Question: how to achieve multicast • Explain the necessity for multicasting • Explain how IGMP works Multicast via unicast • Explain the operation of different multicasting source sends N unicast algorithms such as RPF, Center-based Trees datagrams, one addressed to each of N receivers • Describe the difference between dense and sparse mode multicasting routers multicast receiver (red) forward unicast not a multicast receiver (red) datagrams 2 Multicast: one sender to many receivers Multicast: one sender to many receivers Multicast: one sender to many receivers Multicast: one sender to many receivers Multicast: act of sending datagram to multiple receivers with single Multicast: act of sending datagram to multiple receivers with single “transmit” operation “transmit” operation � analogy: one teacher to many students � analogy: one teacher to many students Question: how to achieve multicast Question: how to achieve multicast Network multicast Application-layer multicast Router actively participate in end systems involved in multicast multicast, making copies of packets as copy and forward unicast datagrams needed and forwarding towards among themselves multicast receivers Multicast routers (red) duplicate and forward multicast datagrams 3 4 1
Multicast groups Multicast groups Internet Multicast Service Model Internet Multicast Service Model 128.59.16.12 class D Internet addresses reserved for multicast: 128.119.40.186 multicast 128.34.108.63 group host group semantics: 226.17.30.197 o anyone can “join” (receive) multicast group 128.34.108.60 o anyone can send to multicast group o no network-layer identification to hosts of members multicast group concept: use of indirection needed: infrastructure to deliver mcast-addressed datagrams to all hosts that � hosts addresses IP datagram to multicast group have joined that multicast group � routers forward multicast datagrams to hosts that have “joined” that multicast group 5 6 Joining a mcast group: two- -step process step process Joining a mcast group: two IGMP: Internet Group Management Protocol IGMP: Internet Group Management Protocol host: sends IGMP report when application joins mcast group local: host informs local mcast router of desire to join group: IGMP (Internet � IP_ADD_MEMBERSHIP socket option Group Management Protocol) � host need not explicitly “unjoin” group when leaving wide area: local router interacts with other routers to receive mcast datagram flow router: sends IGMP query at regular intervals � many protocols (e.g., DVMRP, MOSPF, PIM) � host belonging to a mcast group must reply to query IGMP IGMP wide-area multicast routing query report IGMP 7 8 2
IGMP IGMP Multicast Routing: Problem Statement Multicast Routing: Problem Statement IGMP version 1 IGMP v2: additions include Goal: find a tree (or trees) connecting routers having local mcast router: Host Membership Query group-specific Query group members msg broadcast on LAN to all hosts Leave Group msg � tree: not all paths between routers used host: Host Membership Report � last host replying to Query can send � source-based: different tree from each sender to rcvrs msg to indicate group membership explicit Leave Group msg � shared-tree: same tree used by all group members � randomized delay before � router performs group-specific responding query to see if any hosts left in group � implicit leave via no reply to Query � RFC 2236 RFC 1112 IGMP v3: under development as Internet draft Shared tree Source-based trees 9 Shortest Path Tree Shortest Path Tree Approaches for building mcast trees Approaches for building mcast trees Approaches: mcast forwarding tree: tree of shortest path routes from source source-based tree: one tree per source to all receivers � shortest path trees � Dijkstra’s algorithm � reverse path forwarding S: source LEGEND group-shared tree: group uses one tree R1 2 � minimal spanning (Steiner) R4 router with attached 1 group member � center-based trees R2 5 router with no attached 3 4 R5 group member …we first look at basic approaches, then specific 6 link used for forwarding, R3 i protocols adopting these approaches i indicates order link R7 R6 added by algorithm 3
Reverse Path Forwarding Reverse Path Forwarding Reverse Path Forwarding: example Reverse Path Forwarding: example S: source LEGEND � rely on router’s knowledge of unicast R1 R4 router with attached shortest path from it to sender group member R2 � each router has simple forwarding behavior: router with no attached R5 group member if (mcast datagram received on incoming link on shortest path back R3 datagram will be to center) R7 forwarded R6 datagram will not be then flood datagram onto all outgoing links forwarded else ignore datagram • result is a source-specific reverse SPT – may be a bad choice with asymmetric links Reverse Path Forwarding: pruning Reverse Path Forwarding: pruning Shared- -Tree: Steiner Tree Tree: Steiner Tree Shared forwarding tree contains subtrees with no mcast group members Steiner Tree: minimum cost tree connecting all routers with � no need to forward datagrams down subtree attached group members � “prune” msgs sent upstream by router with no downstream group problem is NP-complete members excellent heuristics exists LEGEND not used in practice: S: source R1 � computational complexity router with attached R4 group member � information about entire network needed router with no attached R2 P � monolithic: rerun whenever a router needs to join/leave group member P R5 prune message links with multicast P R3 forwarding R7 R6 4
Center- -based trees based trees Center- -based trees: an example based trees: an example Center Center single delivery tree shared by all Suppose R6 chosen as center: one router identified as “center” of tree to join: LEGEND � edge router sends unicast join-msg addressed to center router R1 router with attached R4 � join-msg “processed” by intermediate routers and forwarded group member 3 towards center router with no attached R2 2 group member � join-msg either hits existing tree branch for this center, or arrives at 1 R5 center path order in which join messages generated R3 � path taken by join-msg becomes new branch of tree for this router 1 R7 R6 DVMRP: continued… DVMRP: continued… Internet Multicasting Routing: DVMRP Internet Multicasting Routing: DVMRP DVMRP: distance vector multicast routing protocol, RFC1075 soft state: DVMRP router periodically (1 min.) “forgets” flood and prune: reverse path forwarding, source-based tree branches are pruned: � RPF tree based on DVMRP’s own routing tables constructed by � mcast data again flows down unpruned branch communicating DVMRP routers � downstream router: reprune or else continue to receive data � no assumptions about underlying unicast routers can quickly regraft to tree � initial datagram to mcast group flooded everywhere via RPF � following IGMP join at leaf � routers not wanting group: send upstream prune msgs odds and ends � commonly implemented in commercial routers � Mbone routing done using DVMRP 5
Tunneling Tunneling PIM: Protocol Independent Multicast PIM: Protocol Independent Multicast Q: How to connect “islands” of multicast routers in a “sea” of not dependent on any specific underlying unicast routing algorithm (works unicast routers? with all) two different multicast distribution scenarios : Dense : Sparse: � group members � # networks with group logical topology physical topology densely packed, in members small wrt # “close” proximity. interconnected networks � mcast datagram encapsulated inside “normal” (non-multicast- � bandwidth more � group members “widely addressed) datagram plentiful dispersed” � normal IP datagram sent thru “tunnel” via regular IP unicast to receiving mcast router � bandwidth not plentiful � receiving mcast router unencapsulates to get mcast datagram PIM PIM- - Dense Mode Dense Mode Consequences of Sparse Consequences of Sparse- -Dense Dichotomy: Dense Dichotomy: Dense flood-and-prune RPF, similar to DVMRP but Sparse : group membership by routers assumed until routers explicitly prune no membership until routers explicitly � underlying unicast protocol provides RPF info data-driven construction on mcast tree join for incoming datagram (e.g., RPF) receiver- driven construction of mcast � less complicated (less efficient) downstream bandwidth and non-group-router tree (e.g., center-based) processing profligate flood than DVMRP reduces reliance on bandwidth and non-group-router processing conservative underlying routing algorithm � has protocol mechanism for router to detect it is a leaf-node router 6
Recommend
More recommend
