TSIN02 - Internetworking

© 2004 Image Coding Group, Linköpings Universitet

Lecture 3: MulticastLiterature:

� Forouzan: p. 100, Multicast Addresses + ch 10: IGMP� RFC2887: Reliable Multicast Design Space... (~17 pages) � RFC3170: IP Multicast Applications Challenges and Solutions (~23 pages)

� RFC2730, sections 1-2.3: MADCAP (~17 pages)� RFC2776, sections 1-4: MZAP (~9 pages)� RFC3376, sections 1,2, 4-6: IGMPv3, (~30 pages)� RFC2365: Administratively Scoped Multicast (~6 pages)(Multicast routing Forouzan ch. 15 not part of this lecture)

2

� 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

3

� 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

4

� 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)

5

� One-to-many:� Streaming TV/lectures/radio etc� Push media and announcements� Distributed requests (e.g., DB-queries)� Mass distribution of files

� Many-to-many� Multimedia conferencing� Synchronized resources� Concurrent processing

6

Major reasons why preferable over broadcast: Network may replicate packets and prune vast regions not interested in receiving packets

� Save network bandwidth� Save packet processing cycles.

Packet replication

Pruned areas

sender

7

TV over IP

Access network(turned off)

Per channel: � Potentially a very large group.� Just one sender.Operator in control. Works todayZaptime important!

8

Videoconferencing

� Every receiver also a sender.� Many WAN:s/operators involved. How to build the

tree over domain boundaries?� Inter domain multicast routing needed.

Scenario not yet globally deployable!

9

Multiuser Gaming

Server

Normally not a many-to-many application!� Tough upholding synchronism between clients � Sensitive to cheating if all clients have access to

the whole world state� Scales badly, The total amount of user input will at

some point surpass the data needed per user to render a scene.

10

...from an application’s point of view� Receivers form a group� Group identification scheme (scope?)� We want to form groups dynamically.

Need API for telling OS we’re interested in receiving/sending data for a group

� Security: Authentication, data integrity, privacy and anonymity.

� How to find information on existing groups? announcements, web-pages, predefined?

� Reliability

11

Two models:

1) ISM – Internet Standard Multicast� Many-to-many. Everyone (also non-group-

members) can send to a group (*,G)� A host need to communicate with gateway to start

receiving packets for group (*,G) (IGMP ver. 1 & 2)2) SSM – Source Specific Multicast

� Specific support for one-to-many. A group can be identified via the pair (S,G) where S is a sender’s host IP#.

� Communication with gateway via IGMP ver. 3 12

In IPv4 the “G” in the id is part of the normal host address space. The multicast “subnet” is :

224.0.0.0/4

I.e., Addresses 224.0.0.0 to 239.255.255.255

Some of these addresses are statically allocated by IANA and some ranges have predefined use.

13

224. 0. 0. 0 – 224. 0. 0.255 ������������ �����������

224. 0. 1. 0 – 224. 0. 1.255 ���������� �����������

224. 0. 2. 0 – 224. 0.255. 0 ����� ������

224. 1. 0. 0 – 224. 1.255.255 ���� �������� �����

224. 2. 0. 0 – 224. 2.255.255 �������������

224.252. 0. 0 – 224.255.255.255 ������������������

225. 0. 0. 0 – 231.255.255.255 ����!�"

232. 0. 0. 0 – 232.255.255.255 ������������#���� ������

233. 0. 0. 0 – 233.255.255.255 � ���������

234. 0. 0. 0 – 238.255.255.255 ����!�"

239. 0. 0. 0 – 239.255.255.255 �"$ �������!��%������"������

Excerpt from RFC 3171:

14

224.0.0.0 Base Address (Reserved) [RFC1112,JBP]224.0.0.1 All Systems on this Subnet [RFC1112,JBP]224.0.0.2 All Routers on this Subnet [JBP]224.0.0.3 Unassigned [JBP]224.0.0.4 DVMRP Routers [RFC1075,JBP]224.0.0.5 OSPFIGP OSPFIGP All Routers [RFC2328,JXM1]224.0.0.6 OSPFIGP OSPFIGP Designated Routers [RFC2328,JXM1]224.0.0.7 ST Routers [RFC1190,KS14]224.0.0.8 ST Hosts [RFC1190,KS14]224.0.0.9 RIP2 Routers [RFC1723,GSM11]224.0.0.10 IGRP Routers [Farinacci]224.0.0.11 Mobile-Agents [Bill Simpson]224.0.0.12 DHCP Server / Relay Agent [RFC1884]224.0.0.13 All PIM Routers [Farinacci]224.0.0.14 RSVP-ENCAPSULATION [Braden]224.0.0.15 all-cbt-routers [Ballardie]224.0.0.16 designated-sbm [Baker]224.0.0.17 all-sbms [Baker]224.0.0.18 VRRP [Hinden]224.0.0.19 IPAllL1ISs [Przygienda]224.0.0.20 IPAllL2ISs [Przygienda]224.0.0.21 IPAllIntermediate Systems [Przygienda]224.0.0.22 IGMP [Deering]224.0.0.23 GLOBECAST-ID [Scannell]. . .

15

224.0.1.0 VMTP Managers Group [RFC1045,DRC3]224.0.1.1 NTP Network Time Protocol [RFC1119,DLM1]224.0.1.2 SGI-Dogfight [AXC]224.0.1.3 Rwhod [SXD]224.0.1.4 VNP [DRC3] 224.0.1.5 Artificial Horizons – Aviator [BXF]224.0.1.6 NSS - Name Service Server [BXS2]224.0.1.7 AUDIONEWS - Audio News Multicast [MXF2]224.0.1.8 SUN NIS+ Information Service [CXM3]224.0.1.9 MTP Multicast Transport Protocol [SXA]224.0.1.10 IETF-1-LOW-AUDIO [SC3]224.0.1.11 IETF-1-AUDIO [SC3]224.0.1.12 IETF-1-VIDEO [SC3]224.0.1.13 IETF-2-LOW-AUDIO [SC3]224.0.1.14 IETF-2-AUDIO [SC3]224.0.1.15 IETF-2-VIDEO [SC3]224.0.1.16 MUSIC-SERVICE [Guido van Rossum]224.0.1.17 SEANET-TELEMETRY [Andrew Maffei]224.0.1.18 SEANET-IMAGE [Andrew Maffei]224.0.1.19 MLOADD [Braden]224.0.1.20 any private experiment [JBP]224.0.1.21 DVMRP on MOSPF [John Moy]. . .

16

For sending a datagram to a multicast group we use normal UDP where the destination address is set to the multicast address.

ver

8 bits 8 bits

DS

.

.

.

8 bits 8 bits

hlen Total Length

Identifaction (16bits) Frag. offsetflags

TTL Protocol (17) Header checksum

Source IP address

Destination IP address

Source port address Destination port address

UDP total length UDP Checksum

Data

multicastaddressgoes here!

UDP encapsulation in IP datagram

17

� Just for group membership communication between a host and a router

� Has nothing to do with multicast routing� Keeps an updated list of active group listeners for each

connected LAN.� Simplistic network layer service. No address management,

no session management, no reliable data delivery, no security support, no synchronism

IP

ICMPIGMP

ARP RARP

18

������������ ����������� �������������� ������������������������������ �������������������������������������������

��������������

19

Type Maximumresponse time checksum

Group Address

8 bits 8 bits 16 bits

Message types:� Membership query (0x11)

sent by router on 224.0.0.1. If Group Address field is 0.0.0.0 we have a general query. Otherwise we have a special query.

� Membership Report (0x16)sent by host when first time joining or when router queries. Sent to the group in question.

� Leave Report (0x17)sent by host when leaving a group. (Not in IGMP ver. 1). Sent to the group “all routers”.

20

Host / Router communication

Host RouterJoin multicast group (*,G) Membership report sent

on groupaddr G. Router allocates table space and sets a timer to y secs. (default)

And again...

General membership query sent to 224.0.0.1

Membership report sent on groupaddr G.

Wait a random amount of time

Leave group (*,G)Leave group message sent on 224.0.0.2

Several group-specific membership queries sent on 2 group IP address

A general membership query is routinely sent every 125s (default)

Wait a random amount of time

Router must check if there are more hosts in group. Sends 2 (default)group specific membership queries with 1s. (default) apart.

21

What if a “join group” message gets lost?� Join Group messages should be sent at least twice

In certain applications a quick tear-down of a group feed is highly prioritized.� IGMP ver. 2 introduced “leave group”. When router sees

this it sends a group specific membership query a couple of times to give other group members the chance to reestablish the groups existance.

What if there are thousands of members in a group and a router sends a query message?� Hosts must delay a random amount of time to see if

another host answers.22

Non-Member

DelayingMember Idle Member

Each host has one of three states with respect to any multicast address

Leave Group� send leave if flag set

Report Received� stop timer� clear flag

Timer Expired� send report� set flag

Query Received� start timer

Join Group� send report� set flag� start timer

Leave Group� stop timer� send leave if flag set

Query Received� restart timer if maximum response time < current timer

The flag indicates if host is the the last one sending the membership report.

23

Layer-2 networks can be very large with many nodes. How does multicast work on e.g., Ethernet?

Ethernet uses MAC-addressing (6 bytes):

00000001 00000000 01011110 0yyyyyyy yyyyyyyy yyyyyyy

� 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 where left part = 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.

24

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

ieeexplore.ieee.org

25

Adds a new message type� 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]

.

.

.

26

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.

27

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 region127 world

I.e., routers was instructed to drop multicast packets depending on the TTL value.

28

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/14and 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.

29

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.

30

In this example scopes Z2 and Z4 may use the same address range, but Z1 and Z3 need to use different ranges (and not the same as Z2/Z4).

L5

L1 L2 L3

L4

Z1Z2

Z3

Z1: top level scopeLi : local scopesZ2 – Z4: sub-scopes

Z4

L6

31

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.

32

“I have developed this new fancy multi-party multimedia application. How do I get suitable multicast addresses dynamically?”Answer: RFC2730

Multicast Address Dynamic Client Allocation Protocol

Given a scope we can contact a MADCAP server and lease an address for a given time. Leases may be renewed and can be actively released.

If we don’t know server’s host address we can issue a DISCOVER message over the scope’s relative multicast address no 1.

33

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”

� MZAP can detect misconfigurations.� In practice this information is usually pooled at the MADCAP server, and

hosts can request the information from there. 34

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.)

Still an active research topic!Three main solutions:

1) NACK-based: Receivers requestsretransmission whena packet seems missing

2) ACK-based: Every packet is acknowledged byevery receiver. Sender resends on time-out

3) FEC-based: Redundancy is added in the form of a of aforward-error (or rather erasure)-correcting code.

See RFC2887 for a nice introduction!

35

Receivers send 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

36

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.

37

y1 � y2 � y3 � y5 = 0

y2 � y3 � y4 � y6 = 0y1 � y3 � y4 � y7 = 0

In 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) code.

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)

38

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 Ai: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

B3C3

A1 B1

D5

D1

A5

C2

A3D3

A2 B2

C5

D2

B5 D6 A6 C6 B6 D7 A7 C7 B7

C1

B4C4

A1 B1 D1 C2

A4D4

A2 B2 D2 C1

B3C3

A1 B1 D1 C2

A3D3

A2 B2 D2Layer 3:

Layer 2:

Layer 1:

time

39

There 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� Uses FEC� Is an experimental RFC (3940)

40

From RFC3269: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 seem all expired by now...

41

idmr - Inter-Domain Multicast Routing� IGMP ver. 2, 3� Various multicast routing protocols

mboned – MBONE Deployment� Zone Announcement Protocol (ZAP)

malloc – Multicast-Address Allocation� Multicast Address Dynamic Client Allocation Protocol

(MADCAP)

rmt - Reliable Multicast Transport� Draft for NACK-based protocol: NORM� Experimental layered protocol: ALC

42

Multicast can help in scaling up one-to-many and many-to-many applications.

Multicast addresses are 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.