IP Multicasting Olof Hagsand KTHNOC/NADA · Prime architect: Steve Deering Group addresses (class...

IP Multicasting

Olof Hagsand KTHNOC/NADA

2D1490 p4 2007

Literature

● Handouts about delivery trees● RFC 4601 Section 3 (you may need some definitions from

Section 2)

IP Multicast applications

● Unicast is point-to-point● But many applications relays the same information to many.● Examples:

– Radio – TV – Conferencing– Distribution of control information– Distributed games

● But in fact, few use native multicasting today, except for control and IPTV

Deployment● Multicast Routing is in general not deployed in current networks● However multicast control is widely used● Some sites (eg ”stadsnät”) have deployed local multicast delivery

– IPTV distribution may be the killer application● IP Multicast is slowly gaining acceptance

Tunneling● All routers need not be multicast enabled - does this mean that

we cannot reach all hosts that want to join a multicast group on the Internet?– No, because we can use tunneling over non-multicast enabled sub-nets– VPN and Ipv6 also often works like this

● This is the way the MBONE – the Multicast BackBONE is constructed– Islands of multicast enabled routers interconnected by tunnels

Non-multicast enabled network

Multicast enabled routers

IP Multicast Summary

● Prime architect: Steve Deering● Group addresses (class D)● Exploits multicast-capable networking hardware if available● Best-effort delivery semantics (unreliable)● Receiver-based multicast:

– Senders send to any group– Receivers join groups

● Dynamic group membership– Hosts leave and join groups dynamically

● Notation:– (S, G) – specific sender S to group G– (*, G) – all senders to group G

Reliable multicast● There is no “multicast-TCP”. Why?● Problem: how to deal with all acknowledgments

– TCP-like ACKs would cause “ACK-implosions”● Ideas:

– Acknowledgment aggregation points - keep copies of data for retransmission cases

– Use NACKs (Negative acknowledgements)– Send redundant information so that lost information can be

recomputed from the information received, i.e. use forward error correcting codes (FEC)

● There is no general-purpose reliable multicast protocol for the Internet– Only application-specific

IP Multicast Architecture

3. Host-to router protocol

2. Link-level Multicast

4. Intra-domain Multicast Routing

1. Multicast in hosts

5. Inter-domain Multicast Routing

IP Multicast Addresses● IP-multicast addresses, class D addresses (binary prefix: 1110)

224.0.0.0 - 239.255.255.255 ● 28 bit multicast group id● Selected addresses reserved by IANA for special purposes:

GLOP addressing233/8

All Routers on this subnet224.0.0.2All Systems on this subnet224.0.0.1

DVMRP Routers224.0.0.4RIP Routers224.0.0.9

Source-specific multicast232/8

Local Network Control Block (dont forward)224.0.0.0 – 224.0.0.255

DescriptionAddress

GLOP Addressing

● Can be a problem with dynamic multicast address allocation.

● You can register with IANA but most applications use dynamic multicast address allocation

● With GLOP, you can map directly between AS and multicast addresses with prefix 233/8

● Every AS can use 256 such addresses as it likes.● Example: AS 5662 (hex: 0x161e - 22.30) can use multicast

addresses 233.22.30.0 - 233.22.30.255

233 22 30 *

22 30 AS number

Multicast address

Source-specific multicast● Regular IP multicast model (Any-source multicast)

– A receiver R joins a group G (*, G)– R receives all traffic destined to G– Senders unknown a priori -> The routing protocol must detect

senders● Source-specific multicast

– A receiver R joins a group G for sender S only– R receives traffic only from S destined to G– The routing protocol need not detect sender

● SSM uses multicast addresses with prefix 232/8● Requires changes to socket API● IGMPv3● But detection of senders not necessary

Multicast in hosts

● Send is easy – just use a class D address as destination

● Receive is more complicated● Processes create sockets and bind to port● Process calls setsockopt(s, IP_PROTO,

IP_ADD_MEMBERSHIP)– Joins multicast group

● IP-stack sends IGMP report on network● More than one process may join same

group– Can use different (UDP) ports

● But only one IGMP report is sent● When last process leaves

IGMP leave is sent

Process1

Socket

Kernel

Userspace

Process2

UDPIP

Link

Network

Link-level/Hardware Multicast

● Ethernet - good example of hardware multicast– Most Ethernet NICs support multicast

● Ethernet multicast addresses:

– The low order bit of the high order byte is 1:

*1:**:**:**:**:**● Many NICs on the same network may listen to the same

Ethernet multicast address.● Other Link-level layers may not support multicast, being

NBMA (Non-Broadcast Multiple Access)– eg ATM, FR, X25

Mapping IP Multicast to Ethernet

● To use HW multicast on a LAN, the IP multicast address is translated to an Ethernet multicast address.

● The 23 low order bits of the IP multicast address placed in the 23 low order bits of the Ethernet IP multicast address: 01:00:5E:00:00:00

● Example, IP multicast address 227.141.54.33 (0xE38D3621):0xD3621 into 01:00:5E:00:00:00 --> 01:00:5E:0D:36:21

● IP to Ethernet multicast address mapping is not unique! – 32:1 overlap

– IP may receive multicast despite the lack of receiving process

– IP-layer must be able to do filtering (based on IP multicast address)

01 00 5E 0D 36 21

= 227.141.54.33E3 8D 36 21

Host to router: IGMP / MLD● Group membership communication between hosts and multicast routers

– Not for routing of multicast packets● IGMP enables routers to maintain group members to each router interface

– Without IGMP, routers would have to broadcast all multicast packets● Internet Group Management Protocol

– version 1 – RFC 1112 (Historic)● Query from router and response from host

– version 2 – RFC 2236 (most common today)● Leave group by host

– version 3 – RFC 3376 (coming up)● Source filtering

● In IPv6, the control protocol is called MLD– Multicast Listener Discovery Protocol

Position of IGMP in TCP/IP

● Part of the network layer– Encapsulated in IP (like ICMP)

● IGMP messages always addressed to a multicast address – often all systems (224.0.0.1), all routers (224.0.0.2)– or to a specific multicast group

L3: NetworkIP

ICMP IGMP

ARP

IGMPv2 Messages

● General membership query– Sent regularly by routers to query all membership

● Specific membership query – Sent by routers to query specific group membership

● Membership report– Sent by hosts to report joined groups

● Leave group – Sent by hosts to leave groups

Host Behaviour

● A process joins a multicast group on a given interface● Host sends IGMP report to group address when first process joins a group.

– Host keeps a table of all groups which have a reference count > 0● Host sends IGMP leave to 224.0.0.2 when last process leaves group

– In IGMPv1 hosts did not send explicit leaves● Router sends IGMP queries to 224.0.0.1 at regular intervals.

– general query: group = 0.0.0.0– specific group query: group = multicast address of the group

● Host responds to IGMP query by sending IGMP report to group address– Hosts snoop for other hosts’ reports– Set random timer Suppress if other host on same segment sends it

IGMP Example (1)

Host H1 joins group G(H2 had joined earlier)

Membership report -> G

General query -> 224.0.0.1

R1 sends general query to all systems on this network.R1 sends this ~60s (tunable)

H1

H1

H2

H2

R1

R1

IGMP Example (2)

H1 and H2 sets random timer before they reply.H2's timer sets of first.H1 sees H2's report and cancels its timer. R1 now knows that there is at least one member of G on the network.


leave -> 224.0.0.2

H1 leaves group G. Sends a leave message to all routers on this network.

H1

H1

H2

H2

R1

R1

IGMP Example (3)

R1 knows that one member has left, but needs to know if there are any others, so sends a specific group query to group.

Specific query -> G

H1

H1

H2

H2

R1

R1

If H2 remains in G, it sends a membership report.If not, R1 sends query again, and then notes that there are no members of G on this network.


Querier Election● If there are many routers, who sends the queries?● Initially both send general queries● The one with the lowest IP address is elected the IGMP

Querier

H1

H2

R1

R2


.1

.2x

IGMP v3

● Allows selection of senders – not only groups– Enables: Source specific multicast

● A host can join a group and specific sender:– (S, G) not only (*, G)

● IGMP v3 is not commonly deployed.

IGMP snooping

● IGMP is an L3 protocol. Switches are L2.● When a multicast L2 message comes in to a switch, it does not

know where the members are -> must flood on all ports.● For large bridged networks, this may waste a lot of bandwidth,

especially for high bw applications (eg IPTV)● Bridges may therefore listen to IGMP messages, and prune/graft

traffic based on this.● This is called IGMP snooping● Bridge needs to listen to queries, joins, and leaves.

– Override the membership report suppression– Detects routers

● Many modern bridges have this capability

IGMP learning bridge

CPU

Mac-address ports2

3

1 4

0

Regular learning bridges have a learning table where the source address of a frame is used to determine to which ports to send frames.

The switch has a CPU that runs learning and spanning tree (port 0).

A 1

A

IGMP Snooping example(1)

CPU

Mac-address ports2

3

1 4

0

But no senders have multicast addresses!

Without IGMP, the switch cannot know where the listeners are: the switch must flood multicast to all ports.

Groupmember

Sender

Not groupmember

2Mbps TV


With IGMP snooping: Let CPU intercept all multicast traffic.

CPU can detect IGMP membership reports and add ports where listeners are to learning table (including the IGMP querier and CPU)

CPU

Mac-address ports2

3

1 4

0

Report G Mac(G) 0, 2, 4

Groupmember

Sender

Not groupmember


Now multicast only reaches members that have joined.

Note:

Router (IGMP querier) needs to receive all multicast. Therefore the switch CPU must listen to IGMP queries too.

CPU

Mac-address ports2

3

1 4

0

2Mbps TV

Mac(G) 0, 2, 4

Groupmember

Sender

Not groupmember


But switch CPU may be overwhelmed by multicast traffic. Therefore, CPU should listen to multicast IGMP only -> equip ports with hw that can filter IGMP.

Now, only IGMP multicast reaches CPU. All data traffic directly on ports.

CPU

Mac-address ports2

3

1 4

0

Mac(G) IGMP 0Mac(G) DATA 2, 4

Report G

Query


All multicast data traffic directly on ports without interception by CPU.

CPU

Mac-address ports2

3

1 4

0

2Mbps TV


Multicast Router

● Listens to all multicast traffic and forwards if necessary.● Multicast router listens to all multicast addresses.

– Ethernet: 223 link layer multicast addresses– Listens promiscuously to all LAN multicast traffic

● Communicates with directly connected hosts via IGMP● Communicates with other multicast routers with multicast routing

protocols

IGMP MulticastRouting

Multicast in routers● Packets are replicated to many

output ports● Forwarding used to be done in slowpath –

in the main CPU● Modern routers can do forwarding in the

linecards or in hardware● Replication can be made in:

– incoming linecards, – backplane– outgoing linecards

● Routes computed by main CPU by multicast routing protocol are installed in the linecard FIB

● Route lookup in two steps:– RPF, – multicast forwarding

Network

LC 1 LC 2 LC 3

Backplane

CPU

Step 1: Reverse Path Forwarding (RPF)

shortestpath

packet forwarded

not shortestpath

packet is dropped

● Basic forwarding principle in multicast● Forward datagram only if it arrives on interface used to send

unicast to source– Send out on all other interfaces: Flooding!

● Make a lookup of souce adress– Either build your own table (eg DVMRP)– Or use unicast routing table (eg PIM)

Step 2: Multicast Forwarding

A

B

C

Sender, group interface list*, 231.2.3.4 A, B, C10.0.0.1, 231.2.3.4 A10.0.2.1, 231.2.3.4 C*, 229.5.6.7 B, C

● Keep a table with (S,G) entries and an interface forwarding list● This is the delivery tree built by the multicast routing protocol● Data driven (push): Entries are created when data is sent● Demand-driven (pull): Entries appear when receivers join.

Multicast Routing● A packet received on a router is forwarded on many interfaces● The network replicates the packets – not the hosts● All routing protocols aim at building delivery trees through a network● Mostly multicast routing is more concerned where packets come from

instead of where they are going

Delivery Trees● Group Shared Trees: (*, G)

– Same delivery tree for all senders– Router state: O(G) – But suboptimal paths and delays– Unidirectional or Bidirectional

● Source Based Trees: (S, G)– Different delivery tree for each sender– Router state: O(S*G), – Optimal paths and delay.

● Data-driven / Push – Trees built when data packets are sent

● Demand-driven / Pull– Build when members join

Group Shared Trees

Rendezvouspoint

Sender

Receiver

Sender

Receiver

Receiver

● Build one common tree per group (*, G)– Bidirectional – data flows up and down the tree– Unidirectional – data flows only downwards in the tree - must first be

sent to rendez-vous point (in the figure)

Source Based Trees

Sender

Receiver

Sender

Receiver

Receiver

● Build shortest path trees, one per sender and group● (S,G)

Designated Router● Many multicast routers on one link. IGMP elects one Querier● But multicast protocol also elects a Designated Router on

each shared segment.● DR handles multicast routing on behalf of the link, and

forwards data.● (Note IGMP Querier and DR may be different)

DR

Delivery tree

Protocol classification● Dense-mode protocols

– Intended for domains with high receiver density– Push, Source trees– Examples: PIM-DM, DVMRP

● Sparse-mode protocols– Intended for domains with small receiver density– Pull, shared trees (not always,..)– Examples: PIM-SM, CBT

● Link-state protocols– Source trees– Examples: MOSPF

DVMRP

● Distance-Vector Multicast Routing Protocol– Based on unicast distance vector (eg RIP)

● DVMRP is data-driven/push and uses source-based trees● DVMRP builds Truncated Broadcast Trees

– Reverse Path Broadcasting– Builds routing tables with source networks– Uses poison reverse to detect down-link routers

● DVMRP floods trees with data● Then prunes and grafts tree depending on receiver dynamics.

Example: Building truncated broadcast trees (1)

N

R1 R2

S1E0 E0 E1

● Assume sender S1 on network N● Two routers R1 and R2 with tables as shown● R1 sends DVMRP Router Report message on 224.0.0.4 to

neighbors (every ~60s)

N 1 E1 1


N

R1 R2

S1 E0 E0 E1

● R2 adds 1 to metric and add in its table● Next report sent, it adds 32 (poison reverse) for routes it learned

on that interface● Now R1 knows it is upstreams for sources from N, ● And adds E0 in its delivery tree for N

N 2 E0N 1 E1

Delivery tree

34


N

R1 R2S1

E0 E0

● Both R3 and R4 announces N on shared network M● The one with lowest metric (R3) is elected as designated router

for forwarding multicast from N on network M● R4 truncates the delivery tree.

N 2 E0N 1 E1

S0 S0

E0 E0

N 3 S0N 2 S0

M

R3R4

34

1

2 3

341 352

E1


N

R1 R2S1

E0 E0

● Multicast traffic from S1 will flow according to the final delivery tree below.

● The tree is a shortest path tree – a source-based tree.

S0 S0

E0 E0 M

R3R4

E1

S0

Multicast forwarding: flooding When multicast data arrives from sender S1 to a group G,

– An RPF check is made using the DVMRP table● Packets arriving on wrong interface are discarded

– An (S, G) entry is created in the router (data-driven) with the outgoing interface list according to the truncated broadcast tree.

– Packets are flooded according to the (S, G) entry● Example: (S,G): E0, S0

N

R1S1

E0 E1

S0

DVMRP pruning● But suppose there are no receivers on a segment

– Router knows this because of IGMP join/leaves● Router sends DVMRP Prunes upwards in the tree● Interface removed from (S,G) entry

– If (S,G) entry empty, send prune message upwards in tree

RPM Pruning Example

N

R1 R2S1

E0 E0

S0 S0

E0 E0 M

R3R4

E1

S0

prune tree: no members

X

propagate pruning msgs up shortest path tree

X

X

DVMRP grafting● Suppose a new receiver joins a group

– Router knows this because of IGMP join● Router sends DVMRP Graft upwards in the tree● Interface added to (S,G) entry upstreams

– If new (S,G) entry, send graft messages upwards in tree● Truncated broadcast trees + pruning + grafting is sometimes called:

– Reverse path multicasting.

Link-State Multicast: MOSPF● Add multicast to a given link-state routing protocol● Extend LSAs with group-membership LSA (type 6)

– Only containing members of a group● Uses the link-state database in OSPF to build delivery trees

– Every router knows the topology of the complete network– Least-cost source-based trees using metrics– One tree for all (S,G) pairs with S as source

● The delivery trees are optimal, since we use Dijkstra● Expensive to keep all this information

– Cache active (S,G) pairs – MOSPF is Data-driven/push: computes Dijkstra when datagram arrives

● If OSPF is used for unicast routing, it is easy to extend it for multicast routing as well

RT1N1

RT2N2

3

3

N3

RT4

1RT3

N4

2

RT5

RT66

N12

N13

N14

N15

8

88

6

RT9N11

RT12

N10

3

10

N9

H12

1RT11 N8

RT10

Ib

7

Ia

3

N6

1

RT8

0

4

N7

RT7

92

0

0

5

00

0

MOSPF example: optimal source-based tree

0

0

source

Group members

Core Based Tree - CBT

● CBT - Core Based Trees● Group shared multicast trees – (*, G)● Demand-driven

– Routers send join messages when hosts join groups● Divide the internet into regions where each region has a core

router● When a host joins a multicast group the nearest multicast router

attaches to the forwarding tree by sending a join request towards its core router

● Senders sends multicast datagrams to core router encapsulated in unicast datagrams – unidirectional shared trees

Protocol Independent Multicasting - PIM

● PIM relies on any unicast routing tables for its RPF check– Does not build its own tables (as DVMRP)

● Split into two protocols for different uses– PIM-DM – PIM Dense mode– PIM-SM – PIM Sparse mode

PIM – Dense Mode● PIM - Dense Mode

– Flooding-and-prune strategy – similar to DVMRP– Ca 3-minute cycle

● Uses unicast routing tables for RPF– No separate multicast routing protocol

● Builds only source-based trees● PIM Hello messages – to detect neighbor PIM routers● PIM Prune messages

– Like DVMRP, but prunes also used instead of poison reverse in DVMRP

● PIM Assert messages– To elect one single forwarder on a shared link

● PIM Graft – just like DVMRP

PIM-DM example

N

R1 R2S1

E0

S0

E0

PruneR3R4

E1

S0

Assert

PIM-SM● Explicit join model● Both shared and source-based trees.

– Source-base tree switchover● Source registration● Rendez-vous point (RP) discovery

PIM-SM shared tree joins: RPT● Explicit joins – traffic only reaches the part of the network

where there is traffic● Joins travel up to rendez-vous point to join the shared tree

– (*, G) join– Sent periodically

● Install a new (*,G) entry for every new interface that the join is received on

● This shared tree is called RPT: RP Tree

PIM-SM join example (1)

IGMP join

(*, G) Join

Receiver 1

Sender


(*, G) Join

Receiver 1

Receiver 2

IGMP join

Sender

Registering sources – PIM Register● PIM-SM trees are unidirectional, sender's DR must send to

RP to distribute traffic. – All routers must know the Group-to-RP mapping

● Sender's DR sends PIM Register messages towards the RP– Multicast data is encapsulated within the unicast Register

message● The RP then joins the source tree!

– Sends a (S,G) Join towards the source● When the native multicast packets arrive at RP:

– Encapsulated data is discarded● PIM register-stop is sent to sender DR

PIM-SM source registring (1)

NewSender S

● PIM-register sent to RP from source● Data is encapsulated in unicast Register messages to RP,

then natively in (S,*) tree

1. Register


NewSender S

● RP joins (S,G) tree (hop-by-hop)● Data is sent natively from S along (S,G) tree to RP and via

Register messages

2. (S, G) Join

2. (S, G) Join


NewSender S

● RP sends Register-Stop to make sender stop encapsulating data.

● Data is now sent natively from S along (S,G) tree to RP.

3. Register-Stop

PIM-SM shortest path trees● For performance reasons, PIM-SM tries to build source-

trees (SPT) after the shared tree join– Most vendors: try to build source tree directly

● As soon as a receiving router (a DR) gets its first multicast data packet from a new source S, it sends an (S, G) Join upwards towards the source.

● To prune the (*,G) tree, it sends a (S,G,rpt) RP-prune at the same time (to avoid duplicates).– The RP-prune is a special kind of prune– The router may still be interested in other (*,G) traffic.

● Finally, the source may be pruned from the shared tree.

PIM-SM Shortest path tree(1)

(S, G) Join

Receiver

Receiver

Sender S

● Receiver DRs sends (S,G) Join towards source joining the (S,G) tree.


Receiver

Receiver

(S, G) RP-PruneSender S

● Traffic starts flowing down SPT also● Receiver DR:s send (S,G,rpt) Prune towards RP to leave

RPT tree and avoid duplicates


Receiver

Receiver

Sender S

● Traffic flows down (S,G) tree only● Note traffic still flows to RP (for new receivers joining RPT)

Source-specific joins

● If a router receives an IGMP v3 source-specific join● The router can skip the RPT join and go directly to the SPT

join!

PIM Hello protocol

PIM has a Hello protocolPIM Hellos are sent on 224.0.0.13 to shared media in order to

– Form neighbor adjacencies– Select DR on a shared media (for handling hosts on a

network)– Options negotiation.

PIM Assert

● On a transit link (shared media) one router must be the upstream router for a tree

● Routers may have inconsistent unicast routing tables causing different routers to believe different routers are upstream

● This would cause the tree to have several upstream routers -> duplicares.

● PIM Assert messages are sent to vote for one single forwarder per tree for the shared media.

● All routers on that shared link use the winner to send joins to.

PIM Rendez-vous points● The placement of the RP can be important, since all (at least

initial) traffic need to pass the RP.● Group-to-RP mapping

– Same RP for all groups– Different RP's for different groups

● Manual configuration● CISCO Auto-RP

– Uses multicast to distribute Group-to-RP information: RP-Discovery (224.0.1.40)

● IETF Bootstrap router mechanism– A Bootstrap router (BSR) floods messages using hop-by-hop

flooding containing a candidate RP-set– Hashing used to select given RP

● Anycast-RP– Use anycast address to identify RP

PIM Bootstrap router mechanism (1)

Candidate-RPadvertisements are unicast to the BSR

Bootstrap router

A

B

C

D

E


BSR messages containing the RP-candidate list is broadcast

A

B

C

D

E

[B, E] [B, E]

[B, E]

[B, E]

[B, E]


B and E are RPs for different groups - depending on the hash algorithm

A

B

C

D

E

RP for 239.0.0.0 – 239.0.0.3, 239.0.0.8 - 239.0.0.11,....

RP for 239.0.0.4 - 239.0.0.7,...

MSDP – Multicast Source Discovery Protocol

● Discovering sources is a major problem in PIM, especially in the inter-domain routing case:– One AS manages an independent RP for that domain – following the

autonomous systems architecture– But what if there are senders in other domains?

● MSDP operation:– The RPs in different domains communicate with each other on a

peer-to-peer basis– The RP keeps track of all senders in one domain and sends MSDP

Source Active (SA) messages to the RPs in the other domains– If an RP has receivers in a group G, and discovers a sender S in

another domain, it performs a (S,G) Join towards S.– SA messages are reliably flooded to all RP peers

● Concern for scalability

MSDP Example(1)

● Assume a group G and a sender S in AS3 and receiver R in AS5● S starts sending to G and registers with RP3 in AS3 and R has joined the

shared tree in AS5● RP3 floods Source Active messages for S

AS1

AS5

AS2

AS3AS4

R

S RP3

RP1 RP2

RP4

RP5

SA(S,G)SA(S,G)SA(S,G)

SA(S,G) SA(S,G)

SA(S,G)

MSDP Example(2)

● RP5 receives the SA (S,G), and since it has receivers in its domain,● It joins the source-specific tree (S,G)

AS1

AS5

AS2

AS3AS4

R

S RP3

RP1 RP2

RP4

RP5Join(S,G)Join(S,G)

Join(S,G)Data

Anycast-RP and MSDP

● In anycast-RP the RP is an anycast address which is used by many routers.– Every RP serves a part of the network.

● But the RP:s need to synchronize their state to detect all senders/receivers.

● Anycast-RP:s synchronizes their state with MSDP – also within a domain.

MBGP

● Multiprotocol BGP (Multicast BGP)● MSDP and PIM uses regular unicast routing to make RPF● But sometimes, one may wish to traffic engineer the multicast

traffic, without affecting normal unicast traffic● Advertise new attributes:

– MP_REACH_NLRI/ MP_UNREACH_NLRI● Makes it possible to advertise different paths for unicast and

multicast traffic flow between AS:s

MBGP Example

● AS3 announces prefix S/24 to AS2 for unicast, but to AS4 for multicast● Now, unicast traffic to S flows a different way than multicast traffic from S

AS1

AS5

AS2

AS3AS4

R

S/24 RP3

RP1 RP2

RP4

RP5

Announce S(unicast)

Unicast to S

Multicast from S

Announce S(multicast)

Summary: Multicast routing

● Multicast routing uses network resources more efficiently than unicast emulation

● Shared-trees versus Source-trees● Push/Pull● Sparse-mode versus dense-mode● Multicast routing protocols

– DVMRP, MOSPF, CBT, PIM-DM, PIM-SM, MSDP, MBGP