
Framework for a Global Hierarchical Multicast
This page is not yet complete.
Table of Contents
Multicast Data Distribution
- Shortest path trees and Center-based trees
- Shortest perform better
- Center-based has lower overhead
Some of the solutions that have been proposed:
- MOSPF,DVMRP
- Because of broadcast, then are not really suitable for global use.
- PIM and CBT don't do that.
Scope Control
- Scoping is presently done with ttl. The growth of the Internet
- is making ttl's mostly useless.
- here is a need for scoped groups.
Center Location
- A Solution is required.
- Studies show intelligent location beneficial.
- Present Solutions are currently ad hoc.
- initial sender
- administratively selected
Addressing Issues
- Flat Address Space -- No way to filter
- Proposed use of address ranges
- Name/Address Resolution
- There is no "DNS" for multicast --?
- Currently, SD is used.
- Aggregation
- Multicast addresses inherently aggregated
Interoperability
- Complex issue for present protocols
- Need well defined boundaries for a heterogeneous environment
A Proposal -- A Cluster-based Hierarchical Architecture for Multicast
(CHARM)
- Put clusters together concentrically.
Assumptions
- Underlying Unicast Routing based on domains and border routers
- A Level Registrar
- a hierarchical version of sd
- Multicast border routers
Logical Hierarchy
- The physical paths don't have to follow the hierarchy.
Level "N"
- This means that it is some group (which is may be contained in other
groups).
Registrar
- Provides information about MBRs to group members
Control Tree
- Built as a shared tree between MBRs to share cluster related information
Inter-cluster Lists
- Shortest path trees constructed between MBRs at the level of the group
- Designated MBRs are chosen for a cluster on a per source cluster basis
Group Creation
- Group Registration -- via the registrar
- Source Based Trees -- All Local Receivers and partipants in MBRs of
this cluster
Joining the group
- Receiver gets list of MBRs from registrar
- Receivers join towards the closest MBR
- MBRs with receivers joined to them join the DMBRs
The Total Data Delivery Path
- Worst case penalties
- receiving cluster worst case penalty
- the diameter of the receiving cluster
- sending cluster worst case penalty
- the diameter of the receiving cluster
- and the diameter of the sending cluster
A Simulation was done using a 128 node network with 16 senders and 16
receivers.
Number of hops were counted, but there were no other costs considered.
There appears to be no relationship between the diameter of the clusters
versus the diameter of the entire network.
As the network becomes more clustered, the choice of the "center"
is less critical and the path length penalty is reduced.
Primary Benefit of this approach
- Scope Control
- Center Location
- Aggregation at the Group Level
- Interoperability (because of well defined boundaries)
Also, there is a well identified trade-off between scope control and path
length.
Conclusion
- All benefits of the hierarchy at low cost.
- Further improvements can be made.
- reducing the sending cluster penalty
- Reducing the receiving cluster penalty
- if a congruent unicast hierarchy is present
Questions
Has the MBONE community been approached about this? There is a draft
available. The folks doing MBONE engineering have commented on it, but it
is unlikely that the entire MBONE will be re-engineered to match this model,
but it seems likely that some ideas will be considered as
this moves forward.
How does the election process work when DMBR's change? The Control
Tree handles this. However, it appears that this does not change frequently.
The details on this are in the draft.
What about commercial applications? There have been several discussions
about it. It appears to be an important issue. The fact that this architecture
has well defined boundaries and this seems to lend itself to doing some
kind of accounting/charging for service.
Copyright © 1996 Stan Barber. Reproduction with attribution
granted.
Academ Consulting Services
P.O. Box 300481
Houston, Texas 77230-0481
Comments via email to www@academ.com