1 / 55

0940_03F8_c1 NW97_US_106

Multicast Issues for Gigapop Operators David Meyer Gigapop Operators II Workshop 26 June 1998. 0940_03F8_c1 NW97_US_106. Agenda. Introduction First Some Basic Technology Basic Host Model Basic Router Model Data Distribution Concepts

Download Presentation

0940_03F8_c1 NW97_US_106

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Multicast Issues for Gigapop Operators David MeyerGigapop Operators II Workshop 26 June 1998 0940_03F8_c1 NW97_US_106

  2. Agenda • Introduction • First Some Basic Technology • Basic Host Model • Basic Router Model • Data Distribution Concepts • What Are the Deployment Obstacles • What Are the Non-technical Issues • What Are the Technical Scaling Issues

  3. Agenda (Cont.) • Potential Solutions (Cisco Specific) • Multi-level RP, Anycast Clusters, MSDP • Using Directory Services • Industry Solutions • BGMP and MASC • Possible Deployment Scenarios • References

  4. Introduction—Level Set • This presentation focuses on large-scale multicast routing for Gigapops and their customers • Note that the problem is essentially the same as the inter-domain multicast routing problem • The problems/solutions presented are related to inter-enterprise or Gigapop deployment of IP multicast • The current set of deployed technology is sufficient for enterprise environments

  5. Introduction—Why Would You Want to Deploy IP Multicast? • You don’t want the same data traversing your links many times— bandwidth saver • You want to join and leave groups dynamically without notifying all data sources—pay-per-view

  6. Introduction—Why Would You Want to Deploy IP Multicast? • You want to discover a resource but don’t know who is providing it or if you did, don’t want to configure it— expanding ring search • Reduce startup latency for subscribers

  7. Introduction—Why Would a Gigapop Want to Deploy IP Multicast? • All of the previous, plus revenue potential for deploying IP multicast • Initial applications • Radio station transmissions • Real-time stock quote service • Future applications • Distance learning • Entertainment

  8. Basic Host Model • Strive to make the host model simple • When sourcing data, just send the data • Map network layer address to link layer address • Routers will figure out where receivers are and are not • When receiving data, need to perform two actions • Tell routers what group you’re interested in (via IGMP) • Tell your LAN controller to receive for link-layer mapped address

  9. Basic Host Model • Hosts can be receivers and not send to the group • Hosts can send but not be receivers of the group • Or they can be both

  10. Basic Host Model • There are some protocol and architectural issues • Multiple IP group addresses map into a single link-layer address • You need IP-level filtering • Hosts join groups, which means they receive traffic from all sources sending to the group • Wouldn’t it be better if hosts could say what sources they were willing to receive from

  11. Basic Host Model • There are some protocol and architectural issues (continued) • You can access control sources but you can’t access control receivers in a scalable way

  12. Basic Router Model • Since hosts can send any time to any group, routers must be prepared to receive on all link-layer group addresses • And know when to forward or drop packets

  13. Basic Router Model • What does a router keep track of? • interfaces leading to receivers • sources when utilizing source distribution trees • prune state depending on the multicast routing protocol (e.g. Dense Mode)

  14. Data Distribution Concepts • Routers maintain state to deliver data down a distribution tree • Source trees • Router keeps (S,G) state so packets can flow from the source to all receivers • Trades off low delay from source against router state

  15. Data Distribution Concepts • Shared trees • Router keeps (*,G) state so packets flow from the root of the tree to all receivers • Trades off higher delay from source against less router state

  16. Data Distribution Concepts • How is the tree built? • On demand, in response to data arrival • Dense-mode protocols (PIM-DM and DVMRP) • MOSPF • Explicit control • Sparse-mode protocols (PIM-SM and CBT)

  17. Data Distribution Concepts • Building distribution trees requires knowledge of where members are • flood data to find out where members are not(Dense-mode protocols) • flood group membership information (MOSPF), and build tree as data arrives • send explicit joins and keep join state (Sparse-mode protocols)

  18. Data Distribution Concepts • Construction of source trees requires knowledge of source locations • In dense-mode protocols you learn them when data arrives (at each depth of the tree) • Same with MOSPF • In sparse-mode protocols you learn them when data arrives on the shared tree (in leaf routers only) • Ignore since routing based on direction from RP • Pay attention if moving to source tree

  19. Data Distribution Concepts • To build a shared tree you need to know where the core (RP) is • Can be learned dynamically in the routing protocol (Auto-RP, PIMv2) • Can be configured in the routers • Could use a directory service

  20. Data Distribution Concepts • Source trees make sense for • Broadcast radio transmissions • Expanding ring search • Generic few-sources-to-many-receiver applications • High-rate, low-delay application requirements • Per source policy from a service provider’s point of view • Per source access control

  21. Data Distribution Concepts • Shared trees make sense for • Many low-rate sources • Applications that don’t require low delay • Consistent policy and access control across most participants in a group • When most of the source trees overlap topologically with the shared tree

  22. Deployment Obstacles—Non-Technical Issues • How to bill for the service • Is the service what runs on top of multicast? • Or is it the transport itself? • Do you bill based on sender or receiver, or both? • How to control access • Should sources be rate-controlled (unlike unicast routing) • Should receivers be able to receive at a specific rate only?

  23. Deployment Obstacles—Non-Technical Issues • How to make your peers fan-out instead of you (reduce the replication factor in you own network) • Closest exit versus latest entrance—all a wash • How to avoid multicast from opening a lot of security holes • Network-wide denial of service attacks • Eaves-dropping simpler since receivers are unknown

  24. Deployment Obstacles—Technical Issues • Source tree state will become a problem as IP multicast gains popularity • When policy and access control per source will be the rule rather than the exception • Group state will become a problem as IP multicast gains popularity • 10,000 three member groups across the Internet

  25. Deployment Obstacles— Technical Issues • Hopefully we can upper bound the state in routers based on their switching capacity

  26. Deployment Obstacles— Technical Issues • Gigapop customers are telling us they don’t want to depend on another customer’s (or gigapop) RP • Do we connect shared trees together? • Do we have a single shared tree across domains? • Do we use source trees only for inter-domain groups?

  27. Deployment Obstacles— Technical Issues • Customers are telling us that the unicast and multicast topologies won’t be congruent across domains • Due to physical/topological constraints • Due to policy constraints • We need a inter-domain routing protocol that distinguishes unicast versus multicast policy

  28. How to Control Multicast Routing Table State in the Network? • Fundamental problem of learning group membership Flood and Prune DVMRP PIM-DM Broadcast Membership MOSPF DWRs Rendezvous Mechanism PIM-SM BGMP

  29. Rendezvous Mechanism • Why not use sparse-mode PIM? • Where to put the root of the shared tree (the RP) • Third-party RP problem • If you did use sparse-mode PIM • Group-to-RP mappings would have to be distributed throughout the Internet

  30. Rendezvous Mechanism • Lets try using sparse-mode PIM for inter-domain multicast • Look at four possibilities • Multi-level RP • Anycast clusters • MSDP • Use directory services

  31. Connect Shared Trees Together—Multi-Level RP • Idea is to have a hierarchy of shared trees • Level-0 RPs are inside of domains • They propagate joins from routers to a Level-1 RP that may be in another domain • All level-0 shared trees get connected together via a Level-1 RP • If multiple Level-1 RPs, iterate up to Level-2 RPs

  32. Connect Shared Trees Together—Multi-Level RP • Problems • Requires PIM protocol changes • If you don’t locate the Level-0 RP at the border, intermediate PIM routers think there may be two RPs for the group • Still has the third-party problem, there is ultimately one node at the root of the hierarchy • Data has to flow all the way to the highest-level RP

  33. Connect Shared Trees Together—Anycast Clusters • Share the burden of being an RP among service providers • Each RP in each domain is a border router • Build RP clusters at interconnect points (or dense-mode clouds) • Group allocation is per cluster and not per-user or per-domain

  34. Connect Shared Trees Together—Anycast Clusters • Closest border router in cluster is used as the RP • Routers in a domain will use the domain’s RP • Provided you have an RP for that group range at an interconnect point • If not, you use the closest RP at the interconnect point (could be RP in another domain)

  35. Connect Domains Together—MSDP • If you can’t connect shared trees together easily, then don’t • Multicast Source Discovery Protocol • Different paradigm • Rather than getting trees connected, get sources known to all trees • Sounds non-scalable, but the trick is in the implementation

  36. Connect Domains Together—MSDP • An RP in a domain has a MSDP peering session with an RP in another domain • Runs over TCP • Source-Active (SA) messages are sent to describe active sending sources in a domain • Logical topology is built for the sole purpose to distribute SA messages

  37. Connect Domains Together—MSDP • How it works • Source goes active in PIM-SM domain • It’s packets get PIM registered to domain’s RP • RP sends SA message to it’s MSDP peers • Other MSDP peers forward to their peers away from the originating RP • If a peer in another domain has receivers for the group the source is sending to, it joins the source (Flood-and-Join model)

  38. Connect Domains Together—MSDP • There is no shared tree across domains • Therefore each domain can depend solely on it’s own RP (no third-party problem) • SA state is not stored at each MSDP peer • You could encapsulate data in SA messages for low-rate bursty sources • You could have SA caching peers to speed up join latency

  39. Use Directory Services • You can use directory services to: • Enable a single shared tree across domains • Enable use of source tree only and avoid using a single shared tree across domains

  40. Use Directory Services • How it works with a single shared tree across domains • Put RP in client’s domain • Optimal placement of the RP if the domain had a multicast source or receiver active • Policy for RP is consistent with policy for domain’s unicast prefixes • Use directory to find RP address for a given group

  41. Use Directory Services • For example • Receiver host sends IGMP report for 224.1.1.1 • First-hop router performs DNS name resolution on • 1.1.1.224.pim.mcast.net • An A record is returned with the IP address of RP • First-hop router sends PIM join message towards RP

  42. Use Directory Services • All routers get consistent RP addresses via DNS • When dynamic DNS is widely deployed it will be easier to change A records • In the mean time, use loopback addresses on routers and move them around in your domain

  43. Use Directory Services • When domain group allocation exists, a domain can be authoritative for a DNS zone • 1.224.pim.mcast.net • 128/17.1.224.pim.mcast.net

  44. Use Directory Services • Another approach—avoid using shared trees all together • Build PIM-SM source trees across domains • Put multiple A records in DNS to describe sources for the group 1.0.2.224.sources.pim.mcast.net IN CNAME dmm-home IN CNAME dino-home dmm-home IN A 171.69.58.81 dino-home IN A 171.69.127.178

  45. Standards Solutions • Ultimate scalability of both routing and group allocation can be achieved using BGMP/MASC • Use BGP4+ (MBGP) to deal with non-congruency issues

  46. Border Gateway Multicast Protocol (BGMP) • Use a PIM-like protocol that runs between domains (BGP equivalent for multicast) • The protocol builds a shared tree of domains for a group • So we can use a rendezvous mechanism at the domain level • Shared tree is bi-directional • Root of shared tree of domains is at root domain

  47. Border Gateway Multicast Protocol (BGMP) • Runs in routers that border a multicast routing domain • Runs over TCP like BGP • Joins and prunes travel at domain hops • Can build unidirectional source trees • MIGP tells the borders about group membership

  48. Multicast Address Set Claim (MASC) • How does one determine the root domain for a given group? • Group prefixes are temporarily leased to domains • They are allocated out of a service provider’s allocation which in turn get from upstream provider

  49. Multicast Address Set Claim (MASC) • Claims for group allocation resolve collisions • Group allocations are advertised across domains • Lots of machinery for aggregating group allocations

  50. Multicast Address Set Claim (MASC) • Tradeoff between aggregation and anticipated demand for group addresses • Group prefix allocations are not assigned to domains—they are leased • Application must be written to know that group addresses may go away • Work in progress

More Related