Summary of IP Multicast

CPSC 601.43
Course Director: Dr. Anirban
Mahanti

Student : Liqi Shi
Outline
1. Introduction to Multicast
2. Multicast Group and Service Model
3. Multicast Routing
4. Deployment Issues of Multicast
5. EXPRESS
6. References

1 Introduction to Multicast
1.1 Why Multicast /Multicast Applications
1.2 Broadcast/Unicast/Multicast

1.1 Why Multicast /Multicast
Applications
Same data sent to multiple receivers
To use the bandwidth efficiently
Reduce routing processing
Sender doesnt get receivers address
1.1 Why Multicast /Multicast
Applications
Video/audio conference
IP TV, Video on Demand
Advertisement, Stock, Distance learning
Synchronizing of distributed database,
websites
1.1 Why Multicast /Multicast
Applications
ConferenceXP: An Example of Multicast
application

Video Conference
Distance Learning
1.2 Broadcast/Unicast/Multicast
Broadcast: One sender, all the others as
receivers
Unicast: One sender and one receiver
Multicast: One sender (potentially many
senders), many receivers
You can take broadcast and unicast as two
special types of multicast
1.2 Broadcast/Unicast/Multicast
UNICAST
With 4 receivers,
sender must
replicate the
stream 4
times
1.2 Broadcast/Unicast/Multicast


MULTICAST
Source transmits
one stream of data
for n receivers
Replication
happens inside
routers and
switches
WAN links only
need one copy of
the data, not n
copies.
2 Multicast Group and Service Model
Each multicast group is identified by a class D IP
address
Members of the group could be anywhere in the
Internet
Members can join and leave the group and indicate
this to the routers
Senders and receivers are distinct: i.e., a sender
need not be a member, but receivers should be
Routers listen to all multicast addresses and use
multicast routing protocols to manage groups (IGMP)

2 Multicast Group and Service Model
Multicast Address
IP reserved class D addresses for multicast
224.0.0.0~239.255.255.255
Base address: 224.0.0.0 is reserved
224.0.0.1~224.0.0.255 are devoted to multicast routing
and group maintenance protocols
Multicast addresses can only be used as destination
No ICMP error messages can be generated for multicast
datagram



2 Multicast Group and Service Model
Mapping IP Multicast to Ethernet Multicast: Place the lower
23 bits of the IP multicast address into the lower 23 bits of
special Ethernet multicast address 01.00.5E.00.00.00. 32
multicast groups may be mapped into the same address.
Probability is small, but receivers should check the datagram
3 Multicast Routing
3.1 Transmission and Delivery of Multicast Datagram
3.2 Internet Group Management Protocol (IGMP)
3.3 Multicast Forwarding Algorithms
Flooding
Spanning Trees
Reverse Path Broadcasting (RPB)
Truncated Reverse Path Broadcasting (TRPB)
Reverse Path Multicasting (RPM)
Core Based Trees (CBT)
3.4 Multicast Protocols
Distance Vector Multicast Routing Protocol (DVMRP)
Multicast OSPF (MOSPF)
Protocol-Independent Multicast (PIM)
BGMP and MASC


3.1 Transmission and Delivery of Multicast
Datagram
Local subnetwork transmission
The source station simply addresses the IP packet to the multicast group, the
network interface card maps the Class D address to the corresponding
Ethernet multicast address, and the frame is sent. Receivers that wish to
capture the frame notify their IP layer that they want to receive datagrams
addressed to the group
Transmission throughout the Internet
Routers are required to implement a multicast routing protocol that permits the
construction of multicast delivery trees and supports multicast data packet
forwarding. In addition, each router needs to implement a group membership
protocol (IGMP) that allows it to learn about the existence of group members on
its directly attached subnetwork

3.2 Internet Group Management
Protocol (IGMP)
Introduction
IGMP runs between hosts and the
nearest multicast routers. A local
host can use it to inform the router
which multicast group it wants to be
added in, while the multicast routers
can use it to poll the LAN
periodically, thus determine if
known group members are still
active
IGMP message format

Type 0x11 0x11 0x16 0x17 0x12
Group
Addre
ss
unuse
d
used used used used
Meani
ng
Gener
al
memb
ership
query
Specifi
c
memb
ership
query
Memb
ership
report
Leave
group
Memb
ership
report
(V1)
0 8 16 32
3.2 Internet Group Management
Protocol (IGMP)
IGMP versions
RFC1112, IGMP version 1
<draft-ietf-idmr-igmp-v2-01.txt>, IGMP version2
defines a procedure for the election of the multicast querier for each
LAN
defines a new type of Query message-the Group-Specific Query
message
defines a Leave Group message
<draft-cain-igmp-00. txt>, IGMP version 3
introduces support for Group-Source Report messages so that a host
can elect to receive traffic from specific sources of a multicast group
support for Leave Group messages first introduced in IGMP Version 2
has been enhanced to support Group-Source Leave messages. This
feature allows a host to leave an entire group or to specify the specific
IP address(es) of the (source, group) pair(s) that it wishes to leave
3.2 Internet Group Management
Protocol (IGMP)
How it works
One host joins a group
Newly joined host in a group sends IGMP message to group multicast
address declaring membership.
Local multicast router receives the message and establishes
necessary routing path
Group membership report
Router sends Host Membership Query to 224.0.0.1 (all multicast hosts
on a subnet)
Host responds with Host Membership report for each group to which it
belongs (sent to group address)
other hosts in the same group suppress reports
Router periodically broadcasts query to detect if groups have gone
away

3.2 Internet Group Management
Protocol (IGMP)
Each host
responds to the
query with a
random delay. If
one report is
received at the
router, the other
reports will be
suppressed
3.3 Multicast Forwarding Algorithms
Introduction: IGMP is responsible for delivering packets from a
local router to directly attached subnetwork. To forwarding
multicast packets across internet, we should use multicast
protocols. Several algorithms may be used by the protocols.

3.3.1 Flooding
3.3.2 Spanning Trees
3.3.3 Reverse Path Broadcasting (RPB)
3.3.4 Truncated Reverse Path Broadcasting (TRPB)
3.3.5 Reverse Path Multicasting (RPM)
3.3.6 Core Based Trees (CBT)

3.3.1 Flooding
When a router receives a packet, the router will determine
whether its the first time it receives the packet. If so, the packet
will be delivered to all interfaces except the one on which it
arrived, otherwise the packet will be discarded.
No routing tables needed
Inefficient use of bandwidth

SRC Non-red streams will be
discarded according to
flooding algorithm
3.3.2 Spanning Tree
Only one active path connects any two of routers
The multicast packets will not loop and reach all routers
May not provide the most efficient path between the source
subnetwork and group members


3.3.3 Reverse Path Broadcasting (RPB)
A local router only accepts
packets from the nearest
source (parent), otherwise the
packets are discarded
Accepted packets will be
forwarded to all interfaces
except the source
it does not take into account
multicast group membership
when building the distribution
tree, so packets may be
forwarded to non-membership
subnetwork

3.3.4 Truncated Reverse Path
Broadcasting (TRPB)
Its an enhancement of RPB
With the help of IGMP,
multicast routers determine the
group membership on each leaf
subnetwork, thus avoiding
forwarding packets to non-
members
Eliminates unnecessary traffic
on leaf subnetworks , but does
not consider group
memberships when building the
branches of the distribution tree

Source,
G1
G1
G2
G3
Truncated
3.3.5 Reverse Path Multicasting (RPM)
RPM creates a delivery tree that spans only
Subnetworks with group members, and
Routers along the shortest path to subnetworks with group
members
First packet will be sent to all interfaces except the source. If
none of the subnetworks connected to the leaf router have
group members, the leaf router may transmit a "prune"
message on its parent link informing the upstream router not to
forward packets in this group to the leaf
In RPM, first packet still needs to be forwarded throughout the
network.
Each router has to maintain state information for all groups. It
will be impossible as the number of groups and sources
increases.

3.3.5 Reverse Path Multicasting (RPM)
Source,
G
G
G
First packet of G
G Member subnetwork
Non-member
subnetwork
Prune message
3.3.6 Core Based Trees (CBT)
There is a backbone for CBT. It includes both
core and non-core routers.





3.3.6 Core Based Trees (CBT)
If a host wants to join one group, it has to send a unicast join
request message to the core. The nearest router in the
backbone will respond with ACK and the intermediate routers
will record the routing information, thus a delivery tree for a
group is established
Compared to previous algorithms, CBT can use bandwidth and
router resources more efficiently
CBT may result in traffic concentration and bottlenecks near
core routers since traffic from all sources traverses the same
set of links as it approaches the core
A single shared tree may create trees not as optimal as source-
trees
3.4 Multicast Protocols
3.4.1 Distance Vector Multicast Routing Protocol
(DVMRP)
3.4.2 Multicast OSPF (MOSPF)
3.4.3 Protocol-Independent Multicast (PIM)
3.4.4 BGMP and MASC



3.4.1 Distance Vector Multicast Routing
Protocol (DVMRP)
Source-based trees, data-driven (broadcast-and-prune), implicit
join, dense mode protocol
RPM algorithm
Derived from Routing Information Protocol (RIP)
RIP forwards the unicast packets based on the next-hop towards a
destination
DVMRP constructs delivery trees based on shortest previous-hop
back to the source
DVMRP forwarding table: built from DVMRPs own routing table,
received prune messages
TTL and admin scoping available; physical or tunnel interfaces
possible

3.4.1 Distance Vector Multicast Routing
Protocol (DVMRP)
If router C can receive datagrams from both A and B, then it
will receive from A if As metric to the source is smaller than
Bs or if they are equal, A has the smaller IP address on its
downstream interface
3.4.1 Distance Vector Multicast Routing
Protocol (DVMRP)
Separate processes (and updates) for unicast and multicast
routing
Limitations:
distance-vector => slow to adapt to topology changes;
Must store source-specific sate even when not on tree => scaling
problems

B A
Source
3.4.2 Multicast OSPF (MOSPF)
OSPF provides each router with the topology of the
Internet or its OSPF area
MOSPF uses OSPFs topology database to calculate
forwarding tree.
Broadcasting data for a group is demand-driven, that
means it happens only when a host joins or leaves a
group. Compared to data-driven protocols, the cost
is that routing information should be propagated,
because all routers in an area must maintain
membership about every group
3.4.3 Protocol-Independent Multicast
(PIM)
PIM has two variants: Dense mode (DM) and sparse
mode (SM)
DM builds source-based trees in a data-driven (broadcast-and-
prune), implicit join manner
SM allows shared tree and uses explicit join.
PIM-DM
it employs the Reverse Path Multicasting (RPM) algorithm
PIM-DM relies on the presence of an existing unicast routing
protocol to adapt to topology changes, but it is independent of the
mechanisms of the specific unicast routing protocol, while DVMRP
has its own routing table
PIM-DM simply forwards multicast traffic on all downstream
interfaces until explicit prune messages are received
3.4.3 Protocol-Independent Multicast
(PIM)
PIM-SM
Routers with directly attached or downstream members are
required to join a sparse-mode distribution tree by
transmitting explicit join messages
PIM-SM is similar to the Core-Based Tree (CBT) approach in
that it employs the concept of a rendezvous point (RP)
where receivers "meet" sources


Join a PIM-SM
distribution
tree
3.4.3 Protocol-Independent Multicast
(PIM)
PIM-SM (cont.)
When a host first transmits a multicast packet to a group, its
DR encapsulates the multicast packet in a PIM-SM-Register
packet and unicasts it to the primary RP. The RP responds
PIM-Join message. All routers between source and RP
maintain the route so that subsequent unencapsulated
multicast packets could be forwarded to the RP
3.4.3 Protocol-Independent Multicast
(PIM)
PIM-SM (cont.)
PIM-SM allows receivers to either continue to receive
multicast traffic over the RP-shared tree or over a source-
rooted shortest-path tree that a receiver subsequently creates.
The shortest-path tree allows a group member to reduce the
delay between itself and a particular source
3.4.4 BGMP and MASC
BGMP (Border Gateway Multicast Protocol )
BGMP builds shared tree of domains for a group
So we can use a rendezvous mechanism at the domain level
Shared tree is bidirectional
Root of shared tree of domains is at root domain
Runs in routers that border a multicast routing domain
Runs over TCP
Joins and prunes travel across domains
Can build unidirectional source trees

3.4.4 BGMP and MASC
unidirectional
source
tree
3.4.4 BGMP and MASC
MASC (Multicast Address Set Claim )
Group prefixes are temporarily leased to domains
Allocated by ISP who in turn received them from its
upstream provider
Claims for group allocation resolve collisions
Group allocations are advertised across domains
Group prefix allocations are not assigned to domainsthey
are leased
Applications must know that group addresses may go away
RFC 2909

3.4.4 BGMP and MASC
4 Deployment Issues of Multicast
Current architecture deters the commercial deployment of
multicast.
Router mitigation: Older hardware doesnt support multicast. If
software upgrade is not applicable, the routers are forced into
early retirement
Domain independent: For sparse mode multicast, its better to use
CBT or PIM-SM. However, many problems are present when
RPs/core and sources are in different domains
Traffic sources in other domains may require traffic controls, such as
rate or congestion control
ISP has little control over receivers who receive messages from an
RP in another domain
ISP refuses to be a core if it has no receives or sources
Advertisement of the addresses of the RP/core is not very easy
4 Deployment Issues of Multicast
Current architecture deters the commercial
deployment of multicast (cont.)
Group management: Current service model does
not consider group management, including
receiver/transmitter authorization, group creation,
billing, etc. Dangers:
Flooding attack
Collision of sessions
Unauthorized reception
Changing the content of a session


4 Deployment Issues of Multicast
Current architecture deters the commercial deployment of multicast (cont.)
Multicast security:
Authentication, authorization, encryption and data integrity
Current IP multicast service and architecture do not mandate any authentication
Encryption is appropriate mechanism to preserve data privacy at application level
Secure Multicast services are network level solutions to ensure that multicast tree
construction and delivery services are restricted to authenticated and authorized hosts
(i.e. KHIP)
MSEC - Multicast Security (MSEC@IETF)
Drafts:
The Group Domain of Interpretation (draft-ietf-msec-gdoi-06.txt)
Group Key Management Architecture (draft-ietf-msec-gkmarch-03.txt)
GSAKMP Light (draft-ietf-msec-gsakmp-light-sec-01.txt)
MIKEY: Multimedia Internet KEYing (draft-ietf-msec-mikey-04.txt)
HMAC-authenticated Diffie-Hellman for MIKEY (draft-ietf-msec-mikey-
dhhmac-00.txt)
RFCs:
<none>

4 Deployment Issues of Multicast
Current architecture deters the commercial deployment of multicast
(cont.)
Address allocation: When multicast service is popular, address allocation
will be a big problem. Currently there are four alternatives for address
allocation.
MAAA: It is very complicated, consisting of three protocols which connect hosts,
domains, address allocation servers. The allocation of addresses between
domains is handled by Multicast Address Set Claim (MASC). Multicast Address
Dynamic Client Allocation Protocol (MADCAP) is used by host to request
address from server. The servers inform each other of claimed address blocks by
Address Allocation Protocol (AAP). However, MAAA never considers whether
address resource is enough
Static allocation and assignment (GLOP): Restrict addresses available to
domains by AS numbers
EXPRESS model: Uses per source and channel (S,E) structure, so each source
can have 16 million channels
IPv6 addressing: IPv6 provides sufficient addresses
4 Deployment Issues of Multicast
Some alternate service models
EXPRESS
Application level multicast: Application level
multicast has the potential to address most
problems associated with IP multicast, since its
based on unicast. However, Application level
multicast can not perform as well as IP multicast.
The reason is that some redundant traffic on
physical links is unavoidable
5 EXPRESS (Explicitly Requested
Single Source Multicast)
5.1 EXPRESS channel model and
advantages
5.2 EXPRESS count management protocol
(ECMP)
5.3 Multi-source applications
5.4 Cost of EXPRESS and conclusion
5.1 EXPRESS channel model and
advantages
1. Channel Model
The channel model is identified by (S,E), where S is the
single source and E is a channel destination address
Only source S can send datagrams to (S,E)
If a subscriber host wants to receive data from S, it should
explicitly specify both S and E in its request
Compared to group model, (S,E) and (S,E) are unrelated.
That means a subscriber to (S,E) wont receive data from
(S,E)
Class D address (232.*.*.*) are assigned for experimental
use by EXPRESS

5.1 EXPRESS channel model and
advantages
Channel Model Group Model
5.1 EXPRESS channel model and
advantages
2. EXPRESS Service Interface Extensions
Source Host
count = CountQuery (channel, countId, timeout) is used to
collect count information for the channel
channelKey (channel, K(S,E)) is used to inform the network
that the channel is authenticated
Subscriber Host
result = newSubscription (channel, [K(S,E)]) is used to
participate in a channel
result = deleteSubscription (channel) is used to unsubscribe
form a channel
count (channel, countId, count) is used to reply to CountQuery
5.1 EXPRESS channel model and
advantages
3 Advantages
EXPRESS provides 2 channels per source.
Channels neednt be treated as scarce resource
The source has exclusive access to a channel
A subscriber can only get data from the
designated source
Single source and knowledge of subscriber
numbers enables ISP easy in charging

24
5.2 EXPRESS count management
protocol (ECMP)
ECMP maintains the distribution tree and supports
source-directed counting and voting
Routing aspect of ECMP is simple because explicit
source specification allows reverse path forwarding
(RPF)
ECMP consists of three messages:
CountQuery(channel, countId, timeout)
Count(channel, CountId, K(S,E))
CountResponse(channel, CountId, status)
5.2 EXPRESS count management
protocol (ECMP)
Generic Counting Operation
CountQuery can start at source or any router on the channel
distribution tree. A sub-range of CountIds are defined for local use.
The query is sent from source to the first hop router, specifying a
channel, countId and timeout
Receiving router minus timeout value by the measured round-trip
time to its upstream router, and send the query to each
downstream router
An end-station host responds to CountQuery with Count message
The value in the Count response is recorded locally. Once Counts
are received from all neighbors or timeout, the counts are summed
and the total is sent upstream in a Count reply
5.2 EXPRESS count management
protocol (ECMP)
Distribution Tree Maintenance
subscriberId is a reserved countId used to report number of
subscribers in a subtree
A newSubscription causes an unsolicited subscriberId Count
message to be propagated to the channel source, just as a host
joins to the core in CBT
A host unsubscribes by sending zero Count message
For authenticated subscription, the upstream router uses
CoutResponse to deny or validate the user. A valid key is cached
in the local router
Core routers are connected by TCP, using Count message to
maintain the connection
Edge routers are connected by UDP. Upstream routers have to
send CountQuery periodically to maintain the tree, like IGMP
5.2 EXPRESS count management
protocol (ECMP)
5.2 EXPRESS count management
protocol (ECMP)
Neighbor discovery uses neighbors countId, and for
a local LAN, all channels countId is used by
CountQuery, as IGMP general query
Packet forwarding is like conventional multicast. A
router looks up (S,E) after receiving an EXPRESS
packet
Authentication is used based on trust of routers. To
get more security, end-to-end encryption can be
used
Due to single source, ECMP is easy to manage and
implement
5.3 Multi-source applications
Multi-source applications can be built on EXPRESS
channels either by using multiple channels, one per
source, or by allowing multiple sources to share a
channel using higher-level relaying. The later one is
specially used for almost single source
Almost single source can have several sources, but
one of them is the main source
Session relay approach uses an SR host to relay
packets. The main resource can reside on it.
Packets are transferred from source station to SR
host by unicast
5.3 Multi-source applications
5.3 Multi-source applications
Advantages of session relay
The application can select the SR placement, thus reduce
communication
Backup SRs can be used for fault-tolerance
The SR can provide extra application-specific functionality beyond
simply relaying data, as it can add sequence numbers to relayed
packets
Can be used by ISP to provide session relay service. Standard
relaying and accessing protocol is needed
Session relay is like CBT but the later one has no application
level control
Relaying time is not significant in wide area applications
5.4 Cost of EXPRESS
The key cost of EXPRESS
Cost of router FIB memory for channels (12 bytes
for each entry)
Cost of management-level router state (16 bytes
for each count activity)
Cost of maintaining this state (the cost growing
linearly with the number of channels)
The incremental costs of EXPRESS can be
neglected compared to economic effects
5.4 Cost of EXPRESS
Counting: to get an average number of customers in
a long period by polling doesnt affect systems
performance
Proactive Counting: Receivers and routers
proactively send Count upstream without requiring a
CountQuery solicitation.
Get more accurate estimation of user number, consume
more bandwidth
The convergence time of the algorithm grows approximately
linearly with the depth of the tree, while the depth of a tree
grows logarithmically with the group size


6 References
Douglas E. Comer, Internetworking with TCP/IP vol1, Principles,
Protocols, and Architectures, 4
th
edition Pages:319-350
Chuck Semeria and Tom Maufer, Introduction to IP Multicast Routing
L. Sahasrabuddhe and B. Mukherjee, Multicast Routing Algorithms
and Protocols: A Tutorial, IEEE Network, Vol. 14, No. 1,
January/February 2000
H. Holbrook and D. Cheriton, IP Multicast Channels: Express Support
for Large-scale Single-source Applications, Proc. of ACM SIGCOMM
Conference 1999
C. Diot, D. Levine, B. Lyles, H. Kassem, and D. Balensiefen,
Deployment Issues for the IP Multicast Service and Architecture, IEEE
Network, Vol. 14, No. 1, January/February 2000
http://www.nleymann.de/ip-multicast/mcLinksMain.htm