Overview of Multicast Architectures Future directions 25111999 Laurentiu

Overview of Multicast Architectures Future directions 25/11/1999 Laurentiu Barza

Definition of multicast Multicast: Multicast is the act of sending a message to multiple receivers using a single local “transmit” operation

The place of multicast among the data distribution mechanisms Unicast Broadcast Multicast Send to one Send to some Send to All

Multicast routing problem: Problem: Given a source and a set of destinations, Route same packet to at least (or exactly) this set of destinations A B C Source D E

Internet multicast routing Group membership: IGMP Route etablishment: DVMRP, MOSPF, PIM, CBT Group addresing: MADCAP / AAP / MASC, GLOP Inter-domain routing: BGMP, Express, RAMA

Internet Group Membership Protocol It is used by end-system to declare membership in particular multicast group to nearest router(s) IGMPv 1: Timed-out Leave IGMPv 2: Fast (Explicit Leave) IGMPv 3: Per-Source Join

Multicast routing protocols Source - based Tree Protocols: - DVMRP - MOSPF - PIM-DM Shared -Tree Protocols - CBT - PIM-SM

Source based tree B A Source C D E

Dense mode multicast routing protocols Dense mode protocols assume that almost all the hosts in a domain wants to participate in the multicast group. They are « flood and prune » protocols: - data from the sender « floods » across the network from a sender to all possible receivers - subnets with no receivers then send a prune message upstream to prevent unnecessary traffic arriving Thus all routers that are not on the delivery tree need to hold «prune state» to prevent the traffic from flowing where is not wanted.

Shared tree core B A Source C D E Core-based tree

Sparse mode PIM • Instead of flooding and pruning to directly build a shortest path tree, Sparse-mode PIM initially builds a shared tree. • The shared tree is build by sending join messages towards a Rendezvous Point (RP). • Once data is flowing, the shared tree can be converted to a shortest path tree if required.

Problems of Shared-tree based protocols (PIM-SM): Finding the rendezvous point: - by router configuration - using a « bootstrap mechanism » : hashing into a set of candidate RPs The number of RPs scales linearly with the size of domain, so PIM cannot scale globally. Traffic concentration in core routers. Single points of failure. Deployment problem: ISP doesn ’t want to depend on an RP in another ISP for multicast service between its own customers.

« Glop bits » for Static Address Allocation Addresses 233. 0. 0. 0 to 233. 255 have been asigned for static allocation. Every domain gets 256 addresses for their own use allocated by embedding the Autonomous System number as the middle 16 bits of the multicast architecture. Static allocation of entre space would result in poor utilization and ineffective reuse of addresses as it has with IPv 4 unicast addresses. However, allocating a subset of addresses this way solves the current problem.

Dynamic Address Allocation There exist an hierarchical address allocation scheme: • inter-domain: MASC • allocate ranges of addresses to domain • intra-domain: AAP • allocate individual addresses from ranges • client-server: MADCAP • simple request/response protocol

Multicast Source Discovery Protocol - MSDP RP 2 RP 1 MSDP R 1 domain 1 R 2 R 3 R 4 S domain 2 MSDP is a glue between RPs from different domains.

The immediate future • PIM-SM / MSDP become widesperad • Some ISP restrict who can send, from security considerations ( until it will appear IGMPv 3) • GLOP for static allocation

Inter-domain multicast routing In the near term, we won’t have a true inter-domain multicast routing protocol to be deployed. We we do get one deployed, what will it look like ? Three proposals: • BGMP + GRIB • Express • Root-addressed Multicast (or Simple Multicast)

BGMP • A protocol for inter-domain multicast routing • Partition Class D address space • Default Bidirectional Shared Tree for inter-domain routing • Receiver domains can utilize choice of protocol • Discussed in the IETF idmr wg

Express • Express is a one-to-many multicast architecture. • A source must join a channel (i. e. source address+group address) to receive data from the source. • Address allocation is local to a source, there is no need of complicated protocols. • Deployment is very easy (IGMPv 3+PIM-SM), and there are big-money customers interested in for such service. • Receivers must find out who the sources are through some other mechanism (doesn ’t solve the binding/rendezvous problem).

Simple Multicast / RAMA • RAMA is a multicast architecture similar to CBT, where to address a group we use a pair: ( core address, group address ). • Address allocation is local to a core. • Receivers must find out the core address through whatever mecanism they use to find the group address. • Hosts need changing to allow them to inform their local routers what the core address is.

Problems in deploying current architecture The current architecture lacks simple and scalable mechanisms for supporting: • Acces controls. Including group creation and membership. • Security. For protection against attacks to the routing and data integrity of multicast datagrams. • Address allocation. • Network management. Such tools are not developed at this stage.

Requirements in deploying of multicast ISP requirements: - easy to deploy, - control and manage, - to scale well with the growing Internet ISP customers expect: - to be the sole owners of multicast address (even temporary), - to have security guarantees, - to be able to correct network problems quickly