View
8
Download
0
Category
Preview:
Citation preview
TSIN02 - Internetworking
© 2004 Image Coding Group, Linköpings Universitet
Lecture 3: Multicast
Literature:Fouruzan: p. 108- Multicast Addresses
Fouruzan: ch 10: IGMP
RFC3170: IP Multicast Applications Challenges and Solutions
RFC1112, RFC2236, RFC3376 (IGMP ver. 1,2,3)
(Multicast routing Fouruzan: p. 409- not part of this lecture)
TSIN02 - Internetworking
2
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 emergingtechniques
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 exclusivelyto 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 unknownIP#/MAC. (E.g., DHCP, (R)ARP, SLP)
Sending small pieces of information which arefundamental to most hosts. (E.g., NTP, routinginfo)
TSIN02 - Internetworking
5
Communication Forms cont.
One-to-many:
Streaming TV/lectures/radio etcPush media and announcementsDistributed requests (e.g., DB-queries)Mass distribution of filesMany-to-many
Multimedia conferencing
Synchronized resources
Concurrent processing
TSIN02 - Internetworking
6
Major reasons why preferable over broadcast:Network may replicate packets and prune vastregions not interested in receiving packets
Save network bandwidth
Save packet processing cycles.
Communication Forms cont.
Packet replication
Pruned areas
sender
TSIN02 - Internetworking
7
Application Example #1
TV over IP
Access network
(turned off)
Per channel:Potentially a very large group.Just one sender.
Operator in control. Works todayZaptime important!
TSIN02 - Internetworking
8
Application Example #2
Videoconferencing
Every receiver also a sender.Many WAN:s/operators involved. How to buildthe tree over domain boundaries?Inter domain multicast routing needed.
Scenario not yet globally deployable!
TSIN02 - Internetworking
9
Application Example #3
Multiuser Gaming
Server
Normally not a many-to-many application!Tough upholding synchronism between clientsSensitive to cheating if all clients have access tothe whole world stateScales badly, The total amount of user input willat some point surpass the data needed per userto render a scene.Though shared audio etc could benefit
TSIN02 - Internetworking
10
Application Needs
...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 inreceiving/sending data for a group
Security: Authentication, data integrity, privacyand anonymity.
How to find information on existing groups?announcements, web-pages, predefined?
Reliability
TSIN02 - Internetworking
11
IP Multicast architecture
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 tostart receiving packets for group (*,G) (IGMPver. 1 & 2)
2) SSM – Source Specific Multicast
Specific support for one-to-many. A group canbe identified via the pair (S,G) where S is asender’s host IP#.
Communication with gateway via IGMP ver. 3
TSIN02 - Internetworking
12
IPv4 Multicast Addressing
In IPv4 the “G” in the id is part of the normal hostaddress 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 byIANA and some ranges have predefined use.
TSIN02 - Internetworking
13
IPv4 Multicast Addressing cont.
224. 0. 0. 0 – 224. 0. 0.255224. 0. 1. 0 – 224. 0. 1.255224. 0. 2. 0 – 224. 0.255. 0224. 1. 0. 0 – 224. 1.255.255224. 2. 0. 0 – 224. 2. 0.255224. 3. 0. 0 – 231.255.255.255232. 0. 0. 0 – 232.255.255.255233. 0. 0. 0 – 233.255.255.255234. 0. 0. 0 – 238.255.255.255239. 0. 0. 0 – 239.255.255.255
Excerpt from draft-ietf-mboned-rfc3171bis-01.txt: (expires July2004)
TSIN02 - Internetworking
14
Local Network Control Block224.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]. . .
TSIN02 - Internetworking
15
Internetwork Control Block224.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]. . .
TSIN02 - Internetworking
16
Sending an multicast datagram
For sending a datagram to a multicast group we usenormal UDP where the destination address is set tothe 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
TSIN02 - Internetworking
17
IGMP – Internet Group Management Protocol
Just for group membership communication between ahost and a router
Has nothing to do with multicast routing
Keeps an updated list of active group listeners foreach connected LAN.
Simplistic network layer service. No addressmanagement, no session management, no reliabledata delivery, no security support, no synchronism
IP
ICMPIGMP
ARP RARP
TSIN02 - Internetworking
18
IGMP – Message format (IGMP v. 2)
Type Maximumresponse time checksum
Group Address
8 bits 8 bits 16 bits
Message types:
Membership query (0x11)sent by router on 224.0.0.0. If Group Address field is0.0.0.0 we have a general query. Otherwise we have aspecial query.
Membership Report (0x16)sent by host when first time joining or when routerqueries.
Leave Report (0x17)sent by host when leaving a group. (Not in IGMP ver. 1)
TSIN02 - Internetworking
19
IGMP – Communication Example
Host / Router communication
Host RouterJoin multicast group (*,G)
Membership report senton groupaddr G. Router allocates table space and
sets a timer to y secs. (default)And again...
General membershipquery sent to 224.0.0.1
Membership report senton groupaddr G.
Wait a randomamount of time
Leave group (*,G)Leave group messagesent on 224.0.0.2
Several group-specificmembership queries sent on224.0.0.1
A general membership query isroutinely sent every 125s (default)
Wait a randomamount of time
Router must check if there aremore hosts in group. Sends 2(default)G-S membership queries with 1s.(default) apart.
TSIN02 - Internetworking
20
IGMP – Pitfalls taken care of
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 feedis highly prioritized.
IGMP ver. 2 introduced “leave group”. When routersees this it sends a group specific membership querya couple of times to give other group members thechance to reestablish the groups existance.
What if there are thousands of members in a group anda router sends a query message?
Hosts must delay a random amount of time to see ifanother host answers.
TSIN02 - Internetworking
21
IGMP – Host state diagram
Non-Member
DelayingMember Idle Member
Each host hasone of threestates withrespect to anymulticastaddress
Leave Groupsend leave if flag set
Report Receivedstop timerclear flag
Timer Expiredsend reportset flag
Query Receivedstart timer
Join Groupsend reportset flagstart timer
Leave Groupstop timersend leave
if flag set
Query Receivedrestart timer ifmaximum
responsetime < current
timer
The flag indicates if host isthe the last one sendingthe membership report.
TSIN02 - Internetworking
22
Link-level Multicast
Layer-2 networks can be very large with manynodes. How does multicast work on e.g., Ethernet?
Ethernet uses MAC-addressing (6 bytes):
xxxxxxx1 xxxxxxxx xxxxxxxx xyyyyyyy 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 MACaddresses wherex = 0000000(1)00000000010111100 andy = 23 low-order bits of the IPv4 multicast address
Hence frames may arrive at an interface which thehost is not really interested in.
TSIN02 - Internetworking
23
Link-layer Multicast cont.
How does a typical Ethernet-network handle thoseframes?
Dumb switches broadcast all multicast frames!
More advanced switches may use a technique called“IGMP snooping” to filter out group join and leavemessages.
Hosts and switches which are VLAN enabled mayuse the GRMP (GARP Multicast RegistrationProtocol) defined in IEEE 802.1Q.
NOTE: We have free access to all IEEE standards within theUniversity domain! Download from
ieeexplore.ieee.org
TSIN02 - Internetworking
24
IGMP ver. 3 (RFC3376)
Adds a new message type
Version 3 Membership Report (0x22)sent by host when joining one or more source specificmulticast 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 fromthe interface’s multicast filter. Also the membership query messageformat has been updated to include a specific source list.
TSIN02 - Internetworking
26
More on Multicast Addresses
Multicast addresses are not that many. Some of themwe 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 packetsdepending on the TTL value.
TSIN02 - Internetworking
27
Administrative Scoping
TTL-scoping is not the preferred way while itcomplicates dynamic address allocation and is notsuited for intersected scopes etc.
The range 239.0.0.0/8 is reserved for so calledAdministrative scopes. Routers decide based on thegroup 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 areto be used. A large organization might further wantto divide this address space into ranges used byvarious sub-scopes.
TSIN02 - Internetworking
28
Scope restrictions
Administrative scopes has some natural restrictions
Must be connected. I.e., there must exist a routebetween any two hosts part of a scope.
Must be convex. I.e., the route between any twohosts must not cross the scope boundary.
Two intersecting scopes should have disjunctaddress ranges in case a route within one scopegoes 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 thesame address range, but Z1 and Z3 need to usedifferent 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 thelast 256 addresses are assigned by IANA. E.g., forthe IPv4 local scope we will have:
Local Session Announcements will hence always use239.255.255.255. MADCAP 239.255.255.254 etc.
TSIN02 - Internetworking
31
Multicast addresses on-demand
“I have developed this new fancy multi-partymultimedia application. How to get suitable multicastaddresses dynamically?”
Answer: RFC2730
Multicast Address Dynamic Client Allocation Protocol
Given a scope we can contact a MADCAP serverand lease an address for a given time. Leases maybe renewed and can be actively released.
If we don’t know server’s host address we can issuea DISCOVER message over the scope’s relativemulticast address no 1.
TSIN02 - Internetworking
32
Scope Discovery
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 arouter is called ZBR (Zone Boundary Router).
For every scope the ZBR is a border for it regularly transmits ZoneAnnouncement Messages (ZAMs) to the local scope MZAP multicastaddress (239.255.255.252). These messages are then flooded to alllocal scopes within the announced scope.
Announcements contain a Zone ID and address range, but also astring description of the zone. Example: “Department of ElectricalEngineering” “liu.se”
MZAP can detect misconfigurations.
TSIN02 - Internetworking
33
Reliable Multicast (RM)
How to use the best-effort network-layer multicast todistribute data reliably? (I.e., everything arrivessooner or later in the correct order at all receivers.)
Still an active research topic!
Three main solutions:
1) NACK-based: Receivers requests retransmission 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!
TSIN02 - Internetworking
34
RM – NACK Based Approach
Receivers sends back a NACK when a packetdoesn’t arrive in time.
Problem: NACK-implosion at sender.
Solution 1: Don’t send a NACK immediately, but waita random amount to see (in the data stream) if anyother 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 inTCP. For this to scale the receivers need to form an“ACK-tree” in which the ACK:s are aggregated (justas in the NACK-case described earlier)
The ACK-tree could be the same as the multicasttree. This however needs new functionality inrouters
Receivers dynamically form a tree separate fromthe multicast tree and send ACK:s to their parentsonly. Parents might even react to late ACK:s andresend 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 bitsof data. Any received k bits will enable us to recover the k bits oforiginal data. Example using a Hamming (7,4)
110 100 000 001Incoming Data Block:
Construct three parity blocks according to: ( = xor)p
1= x
1x
2x
3
p2= x
2x
3x
4
p3= x
1x
3x
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 theknown received bits (yi). For very large codes (large n) weneed some algebraic structure enabling fast reconstruction.
Hamming (7,4) is usually usedas an example of an block-codecapable of correcting one error(position unknown)
TSIN02 - Internetworking
37
RM – Layered Coding
Multicasting in general has a problem with congestioncontrol. What should sender do (or even know) when abranch suffers from overload?
Apart from various upstream solutions we could useseveral multicast streams, layers, and let receivers joindepending on traffic situation
Layering can be combined with FEC. In the example above any two Ai:swith different index need to be received to reconstruct A. We see that areceiver listening to all layers might have all data (A,B,C,D) at timeinstant (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 avoidcongestion (Receiver joins the suitable ones)
Uses FEC-techniques
RFC is experimental
NACK-oriented reliable multicast (NORM)
Uses random back-off for NACK (truncated exponentialdistribution
Uses FEC
Is just a draft (expires May 2004)
TSIN02 - Internetworking
39
RM – The Ultimate Solution?From RFC3269:
Reliable Multicast Transport (RMT) protocols can beconstructed in a variety of ways, some of which willwork better for certain situations than others. It isbelieved that the requirements space for reliablemulticast transport is sufficiently diverse that no oneprotocol can meet all the requirements [RFC2887,(Sally Floyd et al)].
The working group RMT did some work on Generic RouterAssist (GRA) where small packet handling programs withaccess to buffers etc could be inserted into routers byapplications. In this way a generic solution could be had for allfuture multicast scenarios. GRA only made an appearance assome Internet-Drafts which seems all expired by now...
TSIN02 - Internetworking
40
IETF Working Groups
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 AllocationProtocol (MADCAP)
rmt - Reliable Multicast Transport
Draft for NACK-based protocol: NORM
Experimental layered protocol: ALC
TSIN02 - Internetworking
41
SummaryMulticast can help in scaling up one-to-many and many-to-many applications.
Multicast addresses is part of the normal host addressspace. A group is either identified with a multicast addressor a multicast address plus source address(source-specific multicasting)
Hosts use IGMP to communicate with router to join andleave groups.
Multicast addresses may live in a scope. Scopes mayintersect and nest. Protocols for leasing multicastaddresses exist.
Using multicast for reliable file transfer can be done, butthere is no full IETF standard yet.
Recommended