IP Multicast applications
Unicast is point-to-point But many applications relays the same information to
many. Examples:
– Distribution of control information
– Distributed games But in fact, few use native multicasting today, except
control and IPTV
IP Multicast Summary
– Senders send to any group
– Receivers join groups
Notation:
– (*, G) – all senders to group G
Reliable multicast
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 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:
Scope restricted to one site239.253.0.0/16
Global Scope224.0.1.0 – 238.255.255.255
All Routers on this subnet224.0.0.2 All Systems on this subnet224.0.0.1
DVMRP Routers224.0.0.4 RIP Routers224.0.0.9
Limited Scope239.0.0.0-239.255.255.255
224.0.0.0 – 224.0.0.255 DescriptionAddress
Multicast in hosts Send is easy – just use a class D
address as destination
Process calls setsockopt(s, IP_PROTO, IP_ADD_MEMBERSHIP)
– Joins multicast group
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
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. – How is this done?
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)
Host to router: IGMP
– 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
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
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
Dynamics of IGMP Messages
Membership report Sent to M
join multicast group M
Membership reports (M, N,...)
Random timer
Periodic ~60s
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)
This may allow for pruning of certain senders 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 Many modern bridges have this capability
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
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,
– outgoing linecards
Routes computed by main CPU by multicast routing protocol are installed in the linecard FIB
Network
Backplane
CPU
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
– Router state: O(G)
– Unidirectional or Bidirectional
– Different delivery tree for each sender
– Router state: O(S*G),
– Optimal paths and delay.
Demand-driven / Pull
– 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
(S,G)
– Push, Source trees
– Examples: PIM-DM, DVMRP
– Pull, shared trees (not always,..)
– Examples: PIM-SM, CBT
Basic forwarding principle in multicast forwarding Forward a multicast datagram only if it arrives on the
interface used to send unicast to the source – Send out on all other interfaces – Flooding!
Make a lookup of the source address in the FIB!
shortest path
packet forwarded
DVMRP builds Truncated Broadcast Trees
– Reverse Path Broadcasting (Forouzan)
– Using poison reverse (infinity is 32 in DVMRP)
DVMRP floods trees with data
Then prunes and grafts tree depending on receiver dymanics.
Example: Building truncated broadcast trees (1)
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
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
N
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
M
N
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
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
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
X Parent router
X
X
– 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
Forouzan calls truncated broadcast trees + pruning + grafting for reverse path multicasting.
Link-State Multicast: MOSPF Add multicast to a given link-state routing protocol
– MOSPF
Uses the multiprotocol facility in OSPF to carry multicast information
Extend LSAs with group-membership LSA
– 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
Expensive to keep all this information
– Cache active (S,G) pairs
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-SM shared tree joins
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 Install a new (*,G) entry for every new interface that
the join is received on
PIM-SM join example (1)
PIM-SM shortest path trees
For performance reasons, PIM-SM tries to build source-trees after the shared tree join
– Most vendors: try to build source tree directly
As soon as a receiving router gets its first multicast data packet from a new source S, it sends an (S, G) Join upwards towards the source.
PIM-SM join example (2)
Sender S
Registering sources
PIM-SM trees are unidirectional, senders must send to RP to distribute traffic.
– All routers must know the Group-to-RP mapping Upstreams routers sends PIM Register messages
towards the RP
The RP then joins the source tree!
– Sends a (S,G) Join towards the source
PIM-SM source registring
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
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
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
– 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
Requires changes to socket API
IGMPv3
But detection of senders not necessary
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
Multicast Routing is in general not deployed in current networks
Some sites (eg ”stadsnät”) have deployed local multicast delivery – IPTV distribution may be the killer application
IP Multicast is slowly gaining acceptance
Summary: IP Multicast
Multicast routing uses network resources more efficiently than unicast emulation
IP multicast is receiver-based and uses best effort delivery
Multicast architecture
– Host behaviour
– Link-level multicast