This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Lecture 3: MulticastGoals:● Understand the abstract idea with multicast and its benefits● Get some insight into some applications using multicast.● Understand the IETF multicast architecture
– Multicast addressing
– Multicasting on a LAN: the IGMP protocol
– IGMP evolution
– Layer-2 relation● Gain some understanding regarding some emerging
techniques– Address allocation
– Reliable multicast
TSIN02 - Internetworking
3
Lecture 3: MulticastOutline:
● Applications (one-to-many, many-to-many)
● Multicast architecture
– Multicast addressing
– LAN mechanisms (IGMP v. 2)
– Support in layer 2 (IGMP snooping)
– IGMP ver. 3● Emerging techniques
– Address allocation (Which addresses can I use?)
– Reliable multicast
TSIN02 - Internetworking
4
Communication Forms● One-to-one:
In most applications the peer sends data exclusively to the receiver. Examples: Web-traffic, Video-on-demand etc.
● One-to-all:
– What is all? (ans: the local network)– Requesting a service from a host with unknown
IP#/MAC. (E.g., DHCP, (R)ARP, SLP)– Sending small pieces of information which are
fundamental to most hosts. (E.g., NTP, routing info)
TSIN02 - Internetworking
5
Communication Forms cont.
● One-to-many:
– Streaming TV/lectures/radio etc– Push media and announcements– Distributed requests (e.g., DB-queries)– Mass distribution of files
● All addresses with the low-order bit in the high-order byte set is an Ethernet multicast address
● IP-multicast addresses is mapped onto MAC addresses wherex = 0000000(1)00000000010111100 andy = 23 low-order bits of the IPv4 multicast address
● Hence frames may arrive at an interface which the host is not really interested in.
TSIN02 - Internetworking
23
Link-layer Multicast cont.
How does a typical Ethernet-network handle those frames?● Dumb switches broadcast all multicast frames!● More advanced switches may use a technique called
“IGMP snooping” to filter out group join and leave messages.
● Hosts and switches which are VLAN enabled may use the GRMP (GARP Multicast Registration Protocol) defined in IEEE 802.1Q.
NOTE: We have free access to all IEEE standards within the University domain! Download from
– Version 3 Membership Report (0x22)sent by host when joining one or more source specific multicast groups
Type = 0x22 Reserved checksum
Reserved
8 bits 8 bits 16 bits
Number of Group Records [M]
Group Record [1]
Group Record [2]
Group Record [M]
.
.
.
TSIN02 - Internetworking
25
IGMP ver. 3 cont.
Record Type Aux Data Len Number of Sources (N)
Multicast Address
8 bits 8 bits 16 bits
Source Address [1]Source Address [2]
.
.Source Address [N]
Auxillary Data (may not currently be used)
Group Record Internal Format:
Where Record Type tells if the (S,G) pairs are included or excluded from the interface’s multicast filter. Also the membership query message format has been updated to include a specific source list.
TSIN02 - Internetworking
26
More on Multicast Addresses
Multicast addresses are not that many. Some of them we want to use locally.
The early experimental Mbone (Multimedia backbone) used TTL-scoping: (the time-to-live field in IP header)
1 local (traverses no router)
2 – 31 site (never leaves institution or university)
63 region
127 world
I.e., routers was instructed to drop multicast packets depending on the TTL value.
TSIN02 - Internetworking
27
Administrative Scoping
TTL-scoping is not the preferred way while it complicates dynamic address allocation and is not suited for intersected scopes etc.
The range 239.0.0.0/8 is reserved for so called Administrative scopes. Routers decide based on the group address whether to forward packets. Organizations etc. might use the reserved subrange
Organization local scope: 239.192.0.0/14
and decide for themselves how these addresses are to be used. A large organization might further want to divide this address space into ranges used by various sub-scopes.
TSIN02 - Internetworking
28
Scope restrictions
Administrative scopes has some natural restrictions● Must be connected. I.e., there must exist a route
between any two hosts part of a scope.● Must be convex. I.e., the route between any two
hosts must not cross the scope boundary.● Two intersecting scopes should have disjunct
address ranges in case a route within one scope goes through the other.
● Any scope boundary is also a boundary for alocal scope using the range 239.255.0.0/16.
TSIN02 - Internetworking
29
In this example scopes Z2 and Z4 might use the same address range, but Z1 and Z3 need to use different ranges (and not the same as Z2/Z4).
Adminstrative Scope Example
L5
L1 L2 L3
L4
Z1Z2
Z3
Z1: top level scopeLi : local scopesZ
2 – Z
4: sub-scopes
Z4
L6
TSIN02 - Internetworking
30
Scoping and Relative Addresses
Given an administrative scope’s address range the last 256 addresses are assigned by IANA. E.g., for the IPv4 local scope we will have:
0 SAP Session Announcement Protocol 1 MADCAP Protocol 2 SLPv2 Discovery 3 MZAP 4 Multicast Discovery of DNS Services 5 SSDP 6 DHCP v4 7 AAP 8 MBUS 9-252 Reserved - To be assigned by the IANA 253 Reserved 254-255 Reserved - To be assigned by the IANA
Local Session Announcements will hence always use 239.255.255.255. MADCAP 239.255.255.254 etc.
TSIN02 - Internetworking
31
Multicast addresses on-demand
“I have developed this new fancy multi-party multimedia application. How to get suitable multicast addresses dynamically?”
How can we find out which scopes are available?Answer: RFC2776
Multicast-Scope Zone Announcement Protocol (MZAP):
● Routers on the border of a scope (=zone) runs the protocol. Such a router is called ZBR (Zone Boundary Router).
● For every scope the ZBR is a border for it regularly transmits Zone Announcement Messages (ZAMs) to the local scope MZAP multicast address (239.255.255.252). These messages are then flooded to all local scopes within the announced scope.
● Announcements contain a Zone ID and address range, but also a string description of the zone. Example: “Department of Electrical Engineering” “liu.se”
How to use the best-effort network-layer multicast to distribute data reliably? (I.e., everything arrives sooner or later in the correct order at all receivers.)
Receivers sends back a NACK when a packet doesn’t arrive in time.
Problem: NACK-implosion at sender.
Solution 1: Don’t send a NACK immediately, but wait a random amount to see (in the data stream) if any other receiver has initiated a retransmission
Solution 2: Build in NACK aggregation in routers.NACK(3)
NACK(3)
NACK(4)
NACK(3)
NACK(3)NACK(3-4)
Packet 4lost here
Datasender
Packet 3lost here
TSIN02 - Internetworking
35
RM – ACK Based Approach
Every receiver acknowledges received content as in TCP. For this to scale the receivers need to form an “ACK-tree” in which the ACK:s are aggregated (just as in the NACK-case described earlier)● The ACK-tree could be the same as the multicast
tree. This however needs new functionality in routers
● Receivers dynamically form a tree separate from the multicast tree and send ACK:s to their parents only. Parents might even react to late ACK:s and resend data to children themselves.
TSIN02 - Internetworking
36
y1 ⊗ y2 ⊗ y3 ⊗ y5 = 0
y2 ⊗ y3 ⊗ y4 ⊗ y6 = 0
y1 ⊗ y3 ⊗ y4 ⊗ y7 = 0
RM – FEC Based ApproachIn general we can add redundancy to k bits of data obtaining n bits of data. Any received k bits will enable us to recover the k bits of original data. Example using a Hamming (7,4)
110 100 000 001Incoming Data Block:
Construct three parity blocks according to: (⊗ = xor) p
1 = x
1 ⊗ x
2 ⊗ x
3
p2 = x
2 ⊗ x
3 ⊗ x
4
p3 = x
1 ⊗ x
3 ⊗ x
4
110 100 000 001 010 101 111Outgoing:
We can now afford to loose any three of the above blocks! Solve the parity relation to the right after putting in the known received bits (yi). For very large codes (large n) we need some algebraic structure enabling fast reconstruction.
Hamming (7,4) is usually used as an example of an block-code capable of correcting one error (position unknown)
TSIN02 - Internetworking
37
RM – Layered Coding
Multicasting in general has a problem with congestion control. What should sender do (or even know) when a branch suffers from overload?
Apart from various upstream solutions we could use several multicast streams, layers, and let receivers join depending on traffic situation
Layering can be combined with FEC. In the example above any two A i:s with different index need to be received to reconstruct A. We see that a receiver listening to all layers might have all data (A,B,C,D) at time instant (1) while a layer 1 and 2 receiver will have to wait till (2)
(1) (2)
C1
B3
C3
A1 B1
D5
D1
A5
C2
A3
D3
A2 B2
C5
D2
B5 D6 A6 C6 B6 D7 A7 C7 B7
C1
B4
C4
A1 B1 D1 C2
A4
D4
A2 B2 D2 C1
B3
C3
A1 B1 D1 C2
A3
D3
A2 B2 D2Layer 3:
Layer 2:
Layer 1:
time
TSIN02 - Internetworking
38
RM – The rmt Working GroupThere is a working group Reliable Multicast Transport(rmt) which are developing protocols:
● Asynchronous Layered Coding (ALC)
– Several multicast streams in different rates to avoid congestion (Receiver joins the suitable ones)
– Uses FEC-techniques
– RFC is experimental● NACK-oriented reliable multicast (NORM)
– Uses random back-off for NACK (truncated exponential distribution
Reliable Multicast Transport (RMT) protocols can be constructed in a variety of ways, some of which will work better for certain situations than others. It is believed that the requirements space for reliable multicast transport is sufficiently diverse that no one protocol can meet all the requirements [RFC2887, (Sally Floyd et al)].
The working group RMT did some work on Generic Router Assist (GRA) where small packet handling programs with access to buffers etc could be inserted into routers by applications. In this way a generic solution could be had for all future multicast scenarios. GRA only made an appearance as some Internet-Drafts which seems all expired by now...
SummaryMulticast can help in scaling up one-to-many and many-to-many applications.
Multicast addresses is part of the normal host address space. A group is either identified with a multicast address or a multicast address plus source address(source-specific multicasting)
Hosts use IGMP to communicate with router to join and leave groups.
Multicast addresses may live in a scope. Scopes may intersect and nest. Protocols for leasing multicast addresses exist.
Using multicast for reliable file transfer can be done, but there is no full IETF standard yet.