Arhitecturi pentru retele
si servicii (ARS)
Managementul serviciilor si retelelor (MSR)
Octavian Catrina 2
Data delivered to a group of receivers. Typical examples:
(N : M)
What applications use multicast? What are the requirements
and design challenges of multicast communications?
What multicast support does IP provide (network layer)?
After an overview of multicast applications, we'll focus on IP
multicast: service model, addressing, group management, and
S= Sender; R=Receiver
Octavian Catrina 3
Multicast applications (examples)
One-to-many Real-time audio-video distribution:
lectures, presentations, meetings,
movies, etc. Internet TV. Time
sensitive. High bandwidth.
Push media: news headlines,
stock quotes, weather updates,
sports scores. Low bandwidth.
File distribution: Web content
replication (mirror sites, content
network), software distribution.
Bulk transfer. Reliable delivery.
Announcements: alarms, service
advertisements, network time, etc.
Low bandwidth. Short delay.
Many-to-many Multimedia conferencing: multiple
synchronized video/audio streams,
whiteboard, etc. Time sensitive.
High bandwidth, but typically only
one sender active at a time.
Distance learning: presentation
from lecturer to students, questions
from students to everybody.
Synchronized replicated resources,
e.g., distributed databases. Time
Multi-player games: Possibly high
bandwidth, all senders active in
parallel. Time sensitive.
Octavian Catrina 4
Multicast requirements (1)
Efficient and scalable delivery
Multi-unicast repeats each data item.
Wastes sender and network resources.
Cannot scale up for many receivers
and/or large amounts of data.
Timely and synchronized delivery
Multi-unicast uses sequential transmission.
Results in long, variable delay for large
groups and/or for large amounts of data.
In particular, critical issue for real-time
communications (e.g., videoconferencing).
We need a different delivery paradigm.
Octavian Catrina 5
Multi-unicast vs. Multicast tree
Multi-unicast delivery 1:N transmission handled as N
Inefficient, slow, for N1: multiple
packet copies per link (up to N).
Multicast tree delivery Transmission follows the edges of
a tree, rooted at the sender, and
reaching all the receivers.
A single packet copy per link.
4 3 2
Multicast tree delivery
4 3 2
Octavian Catrina 6
Multicast requirements (2)
Group membership changes dynamically.
We need join and leave mechanisms (latency may be critical).
For many applications, a sender must be able to send without
knowing the group members or having to join (e.g., scalability).
A receiver might need to select the senders it receives from.
Multicast group identification
Applications need special identifiers for multicast groups.
(Could they use lists of host IP addresses or DNS names?)
Groups have limited lifetime.
We need mechanisms for dynamic allocation of unique
multicast group identifiers (addresses).
Octavian Catrina 7
Multicast requirements (3)
Receivers must learn when a multicast session starts and
which is the group id (such that they can "tune in").
We need session description & announcement mechanisms.
Applications need a certain level of reliable data delivery.
Some tolerate limited data loss. Others do not tolerate any loss
(e.g., all data to all group members - hard problem).
We need mechanisms that can provide the desired reliability.
Receivers within a group may have very different capabilities
and network connectivity: processing and memory resources,
network bandwidth and delay, etc.
We need special delivery mechanisms.
Octavian Catrina 8
Requirements: Some conclusions
Multi-unicast delivery is not suitable
Multi-unicast does not scale up for large groups and/or large
amounts of data: it becomes either very inefficient, or does not
fulfill the application requirements.
We need new mechanisms and protocols,
specially designed for multicast.
Specific functional requirements
Specific multicast functions, which are not needed for unicast:
group management, heterogeneous receivers.
General functions, which are also needed for unicast, but
become much more complex for multicast: addressing, routing,
reliable delivery, flow & congestion control.
Octavian Catrina 9
Which layers should handle multicast?
Data link layer
Efficient delivery within a multi-access network.
Multicast extensions for LAN and WAN protocols.
Multicast routing for efficient & timely delivery.
IP multicast extensions. Multicast routing protocols.
End-to-end error control, flow control, and congestion control
over unreliable IP multicast.
Multicast transport protocols.
Application layer multicast
Overlay network created at application layer using existing
unicast transport protocols. Easier deployment, less efficient.
Still an open research topic.
Octavian Catrina 10
IP multicast model (1)
"Transmission of an IP datagram to a group of hosts"
Extension of the IP unicast datagram service.
IP multicast model specification: RFC 1112, 1989.
Unique (destination) address for a group of hosts.
Different datagram delivery semantics A distinct range of
addresses is reserved in the IP address space.
Who receives? Explicit receiver join
IP delivers datagrams with a destination address G only to
applications that have explicitly notified IP that they are
members of group G (i.e., requested to join group G).
Who sends? Any host can send to any group
Multicast senders need not be members of the groups they
Octavian Catrina 11
IP multicast model (2)
No restrictions for group size and member location
Groups can be of any size.
Group members can be located anywhere in an internetwork.
Dynamic group membership
Receivers can join and leave a group at will.
The IP network must adapt the multicast tree accordingly.
Senders need not know the identity of the receivers.
Receivers need not know each-other.
Analogy: A multicast address is like a radio frequency, on which
anyone can transmit, and anyone can tune in.
Best-effort datagram delivery
No guarantees that: (1) all datagrams are delivered (2) to all
group members (3) in the order they have been transmitted.
Octavian Catrina 12
IP multicast model: brief analysis
Simple, convenient service interface. Same send/receive ops
as for unicast, plus join/leave ops.
Anybody can send/listen to a group. Security, billing?
Extension to reliable multicast service? Difficult problem.
IP network viewpoint
Scales up well with the group size.
Single destination address, no need to monitor membership.
Does not scale up with the number of groups. Conflicts with
the original IP model (per session state in routers).
Routers must discover the existence/location of receivers and
senders. They must maintain dynamic multicast tree state per-
group and even per-source&group.
Dynamic multicast address allocation. How to avoid allocation
conflicts (globally)? Very difficult problem.
Octavian Catrina 13
IPv4 multicast addresses
IPv4 multicast addresses
IP multicast in LANs
Relies on the MAC layer's native multicast.
Mapping of IP multicast addresses to MAC
31 28 27 0
1110 multicast address
Class Address range
D 126.96.36.199 to
1 1 1 0 28 bits (228 addresses)
IPv4 multicast address
Ethernet multicast address
0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 1 0 1 1 1 1 0 0 23 bits