Multicasting
Short recap of the basics No single link should contain multiple copies of H R same packet. R R H R H Multicast R packets H R H Extra packets with replicated unicast Extra packet No unwanted with broadcast packets should be received.
Near-term vs Long-term
The Standard IP Multicast Model 1. A source can send multicast packets at any time, with no need to register or to schedule transmission. 2. Based on UDP. 3. Sources need only to know a multicast address and not who is in the group. 4. Sources need not be a part of the group itself. 5. Arbitrary number of sources. 6. Members can join or leave a multicast group at will. 7. No synchronization og registration with a centralized management group. Model does not discuss routing, security, QoS, or address allocation.
MBone - A virtual network on top of IP - Connectivity over IP-encapsulated tunnels. - Reverse-Path Forwarding Tree - DVMRP
Distance vector multicast routing protocol (DVMRP) Each node would have its own routing table. Loop avoidance with reverse shortest path tree. Created using flooding and later also pruning. Rooted at the source (Illustration of a regular DVRP table)
Flooding Hosts Multicast routers Other routers
Flooding
Flooding
Flooding
Flooding
Flooding
Destination interface Reverse-Path Forwarding A - B 1 C 2 (Note: This is a simplified routing table.) C 2 A 4 1 B B
Destination interface Reverse-Path Forwarding A - B 1 C 2 (Note: This is a simplified routing table.) C 2 A 4 1 B B
Destination interface Reverse-Path Forwarding A - B 1 C 4 (Note: This is a simplified routing table.) C 2 A 4 1 B B
Destination interface Reverse-Path Forwarding A - B 1 C 4 (Note: This is a simplified routing table.) C 2 A 4 1 B Not the same interface, so it won’t forward the message.
More Reverse-path forwarding C A B
More Reverse-path forwarding C A B
More Reverse-path forwarding C A B
More Reverse-path forwarding C A RPF makes B sure these links are not used for multicast traffic. Done through prune messages.
More Reverse-path forwarding C A B RPF makes sure these links are not used for multicast traffic
More Reverse-path forwarding C A B Sends prune message towards source if all interfaces except source has received prune message
Reaching the leaf node(s) Checks to see if it knows of any group members in the subnet. C A B
Reaching the leaf node(s) If any member is a part of the group, the leaf router will forward the packet on the subnet. C A B
Reaching the leaf node(s) If there are no members in of the group in the subnet it will send back a prune message. C A B
Pruning It will be forwarded further back towards the source. C A B
This router will also send out Pruning a prune message as it has no other links than the one towards source. C A B
Pruning C A B Receives prune
Pruning C A B
Pruning Each router need to remember which interface is not a part of the tree. C A B
The reverse shortest path tree C A
Protocol Independent Multicast (PIM) Uses whatever unicast routing table to perform RPF checks. Sparse mode: PIM-SM Dense mode: PIM-DM
Dense mode Lots of unnecessary In short: packets if low density - We flood the network and branches that has no members are eliminated. - Does this regularly to create the reverse-path forwarding tree. - This is how is finds new members. Works best with high density of members.
Sparse mode - Works better for low density of members. - Explicit join messages. - A single core as a meeting place for sources and receivers. Rendezvous Point (RP) - A group can only have a single RP. - Creates a Rendezvous-point tree - Protocol Independent Multicast (PIM-SM)
PIM Multicast trees RP A Needs an RP. B This will be the root. Note that the RP does not have to be the source.
PIM Multicast trees If B wants to join the group it sends a join message towards the RP. RP A B
PIM Multicast trees Gets forwarded to the RP. RP A B
PIM Multicast trees But how does it know who is RP? RP A B
As in DM the routers still needs to remember which interfaces is PIM Multicast trees a part of the tree. RP A B
PIM Multicast trees This only tells RP that B is a receiver. So what about the sources? RP A B
PIM Multicast trees Source sends a unicast encapsulated multicast message to the RP. RP A B
PIM Multicast trees RP A If the RP knows B about this group it strips off the unicast header and forwards the multicast message down the tree
PIM Multicast trees RP A If RP doesn’t B have forwarding state for the group it sends back a register-stop message.
PIM Multicast trees RP A If RP doesn’t B have forwarding state for the group it sends back a register-stop message.
PIM Multicast trees RP A If RP doesn’t B have forwarding state for the group it sends back a register-stop message.
PIM Multicast trees RP A If RP doesn’t B have forwarding state for the group it sends back a register-stop message.
PIM Multicast trees RP A If RP doesn’t B have forwarding state for the group it sends back a register-stop message.
In short Dense mode: Sparse mode: - - Best when high density of members Best when low density of members - Broadcast-and-prune protocol - Join protocol - Source is always root - Rendezvous Point (RP) - More distributed traffic. - Single point of failure and lots of traffic
Native multicast in MBone
Issues with MBone - Scalability: Flat networks: Must keep track of state information. - Manageability: - No central management. How to manage this? - Can’t configure better routes. - Interdomain policy management
Intradomain Multicast - Emerge due to the need to provide scalable hierarchical, internet-wide multicast. - Extension of the interdomain unicast route exchange protocol BGP to make multicast routing hierarchical.
Multicast with BGP - Hierarchical - Supports interdomain routing. - Simply a matter of choosing the best External link. - MBGP - Something is still missing: - Doesn’t provide multicast tree construction functions. What is the format of the join message? When should it be sent?
MSDP - Uses PIM-SM - How to inform an RP in one domain that there are sources In other domains. - (in practice) One RP per domain - MSDP works by having representatives in each domain.
MSDP operations 1. New source. Register with RP. 2. MSDP sends SA til connected peers. 3. Message flooding. 4. Group state-check within each domain. If state exist -> RP sends PIM join to source 5. If data is contained in the message, the RP will forward it on the multicast tree. 6. Step 3-5 will repeat until all MSDP peers have received the SA message and all group members are receiving data from the source.
Long-term proposals
Border Gateway Multicast Protocol (BGMP) - Bidirectional shared trees between domains using a single root. - BGMP needs to decide in which particular domain to root the shared tree. - Uses a strict address allocation scheme. Each domain should have specific set of address. Solving dependency problems between domains. - GLOP and MASC Example of dependency problems
Root Address Multicast Architecture A response to the complexity of MBGP/PIM-SM/MSDS and BGMP. The other ones misses security, billing , and management. A need for fundamental changes. Tries to avoid the complexity of core placement: Two primary protocols: Express Multicast and Single Multicast.
Commodity Internet - Measuring success. - At the time of publishment studies had only dealt with MBone. - Bring MBone to the new infrastructure. Solution: make the MBone its own AS
Internet2 deployment - Multicast “the right way” - Internet2 Multicast Working Group has set some ground rules: - Must be native - Must be sparse mode - No tunnels allowed - All routers must support interdomain multicast routing.
Conclusion
Multicasting: Top, middle, bottom Multicasting at different layers
Multicasting ➔ Sending the same data to multiple recipients in a group.
Multicasting ➔ Sending the same data to multiple recipients in a group.
At different levels L7: Application Application multicast ● L6: Presentation Overlay multicast ● L5: Session L4: Transport IP multicast ● L3: Network L2: Link L1: Physical
Metrics used Tree quality ● Multicast tree cost ○ End to end delay ○ Control overhead ● Number of control messages ○
Application multicast Two categories: ● Unstructured (NARADA) ○ Periodically exchange membership & routing info ■ Build a mesh on E2E measurements ■ Build delivery tree on top, based on distance ■ Structured (NICE) ○ Recursively arrange members into hierarchy ■
Recommend
More recommend
