may bea bad choice with asymmetric links R1 R2 R3 R4 R5 R6 R7 router with

May bea bad choice with asymmetric links r1 r2 r3 r4

This preview shows page 85 - 94 out of 115 pages.

may bea bad choice with asymmetric links R1 R2 R3 R4 R5 R6 R7 router with attached group member router with no attached group member datagram will be forwarded LEGEND S: source datagram will not be forwarded
Image of page 85
Reverse Path Forwarding: pruning forwarding tree contains subtrees with no mcast group members no need to forward datagrams down subtree “prune” msgs sent upstream by router with no downstream group members R1 R2 R3 R4 R5 R6 R7 router with attached group member router with no attached group member prunemessage LEGEND S: source links with multicast forwarding P P P
Image of page 86
Shared-Tree: Steiner Tree Steiner Tree: minimumcost treeconnecting all routers with attached group members problem is NP-complete excellent heuristics exists not used in practice: computational complexity information about entirenetwork needed monolithic: rerun whenever a router needs to join/leave
Image of page 87
Center-based trees singledelivery treeshared by all onerouter identified as “center” of tree to join: edgerouter sends unicast join-msg addressed to center router join-msg “processed” by intermediaterouters and forwarded towards center join-msg either hits existing treebranch for this center, or arrives at center path taken by join-msg becomes new branch of tree for this router
Image of page 88
Center-based trees: an example Suppose R6 chosen as center: R1 R2 R3 R4 R5 R6 R7 router with attached group member router with no attached group member path order in which join messages generated LEGEND 2 1 3 1
Image of page 89
Internet Multicasting Routing: DVMRP DVMRP: distancevector multicast routing protocol, RFC1075 flood and prune: reversepath forwarding, source-based tree RPF treebased 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 prunemsgs
Image of page 90
DVMRP: continued… soft state: DVMRP router periodically (1 min.) “forgets” branches arepruned: mcast data again flows down unpruned branch downstream router: repruneor elsecontinueto receive data routers can quickly regraft to tree following IGMP join at leaf odds and ends commonly implemented in commercial routers Mbonerouting done using DVMRP
Image of page 91
Tunneling Q: How to connect “islands” of multicast routers in a “sea” of unicast routers? mcast datagram encapsulated inside “normal” (non-multicast-addressed) datagram normal IP datagram sent thru “tunnel” via regular IP unicast to receiving mcast router receiving mcast router unencapsulates to get mcast datagram physical topology logical topology
Image of page 92
PIM: Protocol Independent Multicast not dependent on any specific underlying unicast routing algorithm (works with all) two different multicast distribution scenarios : Dense : group members densely packed, in “close” proximity.
Image of page 93
Image of page 94

You've reached the end of your free preview.

Want to read all 115 pages?

  • Fall '09
  • routing protocol, twork Laye

  • Left Quote Icon

    Student Picture

  • Left Quote Icon

    Student Picture

  • Left Quote Icon

    Student Picture