Date post: | 07-Apr-2018 |
Category: |
Documents |
Upload: | phat-nguyen |
View: | 215 times |
Download: | 0 times |
of 51
8/4/2019 3.Multicast2pp
1/51
1
Multicast
Outline
Introduction
Network layer Multicast
Transport layer Multicast
Perspectives
8/4/2019 3.Multicast2pp
2/51
2
Outline
Introduction Definition
Notion of group
Problem
Network layer Multicast
Transport layer Multicast Perspectives
What Is Multicast?
Efficient communication means 1-to-N
multicast vs. unicast and broadcast
unicast: a single source to a single destination
multicast: a single source to a subset of destinations
broadcast: a single source to all destinations
unicast(1-to-1)
multicast(1-to-N)
broadcast(1-to-all)
8/4/2019 3.Multicast2pp
3/51
3
What Is Multicast?
Communication 1 to N
Bandwidth-saving technology which reducestraffic by delivering a unique information flowto several receivers simultaneously
Multicast examples The networks material layer supports multicast
efficiently Example: Ethernet allows a packet to be received by
many hosts
Several protocols and different service models Examples: IETF multicast IP, ATM Multipoint
Unicast
R
sender Problem
Sending the same data
towards severalreceivers in unicast is
not efficient
Example
Popular Web sitesbecome serious
bottlenecks
8/4/2019 3.Multicast2pp
4/51
4
Multicast
R
sender Efficient distribution 1to many
Applications For Multicast
Reliability
Response time
100%
200 ms 2 s 20 s
Real-timeinteractive
Multimediadistribution
distributionof documents
conference Dlay -order
of 100 ms tolerance of
a certainloss rate
Continuousflows, real-time,not interactive,unidirectional
Softwaredistribution
100% reliability Few temporal
constraints
8/4/2019 3.Multicast2pp
5/51
5
Why Multicast? (1/3)
distribution using TCP/IP
Results Several copies of the same packet
several buffers
several connections
R3
R4R2
R1
S
D1
D2
D3
D4
D5
Why Multicast? (2/3)
distribution using multicast
Results A single copy of each packet
A single buffer
A single multicast connection
R3
R4R2
R1
S
D1
D2D3
D4
D5
8/4/2019 3.Multicast2pp
6/51
6
Why Multicast? (3/3)
Uses bandwidth efficiently
Prevents network congestion
minimises servers load
Provides information to more userssimultaneously
Reaches many people at the same time
etc.
Introduction To IP Multicast
Efficient 1-to-several distribution
Data Distribution with a tree
Packets cross networks links only once
Adressing independent of localization
One IP address per multicast group
Receiver-oriented service model
Applications can subscribe and quit multicast groups
Senders dont know who listens
Similar to the television model
Different from telephone or ATM networks
8/4/2019 3.Multicast2pp
7/51
7
IP Multicast
Service All senders send towards the same group
simultaneously
Receivers subscribe to any group
Routers find receivers
Unreliable delivery
Reserved IP addresses 224.0.0.0 to 239.255.255.255 reserved for
multicast
Static addresse for usual services (e.g. sessionadvertisement protocol)
Notion of Multicast Group
How can we identify a Mcast packets receivers?
unicast: one IP destination address
Here, all destination addresses???
abstraction: multicast group
Links together a set of senders and receivers Exists independently of senders and receivers
senders receiversMulticast
group
Each receiver receivespacket sfrom eachsender
8/4/2019 3.Multicast2pp
8/51
8
IP Multicast Addresses (1/2)
multicast group: class D address0
10
110
1110
rseau
station
adresse multicast
A
B
C
D
rseau
rseau
station
station
11100000 00000000 00000000 00000000
11101111 11111111 11111111 11111111
...de 224.0.0.0
239.255.255.255.
.
.
224.0.0.0 : unused
224.0.0.1 : represents the set of the considered subnetworksstations
There is no address for the set of all machines on the Internet
IP Multicast Addresses (2/2)
Group addressingS
D
S
DD
D
D
Receivers subscribe to thegroup address 224.1.2.3
@ IP source 224.1.2.3 donnes Mcaster
adresse de
destination
en-tte IP
Address indirection
Each host has its own IP @, independent of the group @
Problems distinction Discover the set of usual Mcast groups Express the wish to receive a groups packets Discover the set of a groups receivers Deliver data to each member of the group
8/4/2019 3.Multicast2pp
9/51
9
Multicast Problems
Questions... When and how does a group begin and end?
When and how is the group address chosen?
How do new stations join a group?
Are there any conditions to belong to a group?
How do routers interoperate to deliver packets?
Choices... A receiver should be able to join or leave a group during a
transmission
A receiver should be able to join or leave a group without signaling itexplicitly to senders
Statements... Receiver hosts are often connected to local networks...
Introduction
Network layer Multicast multicast on LANs
IGMP protocol
Service model
Multicast routing algorithms
Multicast routing protocols
Transport layer Multicast
Perspectives
Outline
8/4/2019 3.Multicast2pp
10/51
10
Multicast on a LAN (1/3)
What currently exists (Ethernet example)
Ethernet relies on a broadcast medium
each station has a network card with a specific
hardware @
There is a broacast address (FF.FF.FF.FF.FF.FF)
What can we do to reach only a subset of
stations? ex: H1 wants to send a Mcast packet to H2 and
H4 who are on the same network as H1
Two possibilities...
Multicast on a LAN (2/3) network multicast using link broadcast
network multicast using link multicast
Ethernet
IPH1
Ethernet
IPH2
Ethernet
IPH3
Ethernet
IPH4
...
Ethernet
IPH1
Ethernet
IPH2
Ethernet
IPH3
Ethernet
IPH4
...
@ de H1 FF.FF.FF.FF.FF.FF IP multicast Packet
@ de H1 @ MAC multicast IP multicast Packet
@src @dst
8/4/2019 3.Multicast2pp
11/51
11
Multicast on a LAN (3/3)
Translation of IP multicast addresses into Ethernet @
Ethernet multicast addresses format
de 01:00:5e:00:00:00
01:00:5e:7f:ff:ff.
.
.
0000 0001 0000 0000 0101 1110 0111 1111 1111 1111 1111 1111
0000 0001 0000 0000 0101 1110 0000 0000 0000 0000 0000 0000
Translation mechanism
0000 0001 0000 0000 0101 1110 0
1110 xxxx x
23 derniers bits
We know how to Mcast an IP packet on a broadcast LAN!
IP Multicast Architecture Components
hosts
routers
Service model
Host-router Protocol
(IGMP)
multicastrouting protocols (several)
8/4/2019 3.Multicast2pp
12/51
12
Protocol Involved in Hosts
IP Service Interface
Link-Layer Service Interface
Upper-Layer Protocol Modules
IP Module
Link-Layer Modules(e.g., Ethernet)
IP to link-layer addressmapping (e.g., ARP)
ICMP IGMP
What Is IGMP? How can a router determine if its LAN has receivers for
a given Mcast group?
Internet Group Management Protocol
Allows a host to indicate its local router if he wants to join agroup
Used in broadcast LANs
...
HR
R
R
H
HH
H
H.
.
.
.
.
.
Multicast routinglong distance
IGMP
IGMPIGMPIGMP
8/4/2019 3.Multicast2pp
13/51
13
IGMP Version 1 (1/1) RFC 1112 (Aug.89)
query/report messages exchange
R
S1
HH
Long distancemulticast routing
S2
H
H
HH
H
query(quelquun intress par un groupe?)
report (225.5.5.5) report (224.9.9.9)
@ IP source 224.9.9.9 donnes
en-tte IP
@ destination
IGMP Version 1 (2/2) Risk of congestion
Answers spreading based on timers
R
H H
request sent
timer armed
answer sent answer reception,timer disarmed
query
report
timer armed
H
Traffic reduction on the LAN if no member
Possible delay (qq s.) before receiving data
8/4/2019 3.Multicast2pp
14/51
14
IGMP Version 2 (1/2)
RFC 2236 (Nov.97)
A receiver explicitly informs its router when itleaves a group
3 types of messages
Message typemembership_query
gnralspcifique
membership_report
leave_group
Sent by
routerrouter
hosthost
goal
Ask groups to which hosts have subscribedAsk if a given group has members on a LAN
indicate that a host wants to join (or has joined) a groupIndicate that a host leaves a given group
Answers spreading with 0 timer MaxRespTime
IGMP Example (1)
Network 1
Host 1 starts sending packets No IGMP packet sent
Packets stay on network 1
router sends a IGMP Membership Queryperiodically
Network 2Router
1
2 4
3
dinh ky
8/4/2019 3.Multicast2pp
15/51
15
IGMP Example (2)
Network 1
Host 3joins the conference
He sends a IGMP Membership Report message
router starts to forward packets on the network 2
Host 3 leaves the conference
He sends a IGMP Leave Group message
Sent only if he was the last host to send a IGMPMembership Report message
Network 2Router
1
2 4
33
Membership Report
33
Leave Group
IGMP Version 2 (2/2)
R
S1
HH
routage multicastgrande distance
S2
H
H
HH
H
query
(quelquun intress par un groupe?)
leave_group (225.5.5.5) report (224.9.9.9)
@ IP source 224.9.9.9 donnes
@ destination
en-tte IP
Message format
type MaxRespTime Checksum
Multicast Group Address
Reduction of Leaves latency
8/4/2019 3.Multicast2pp
16/51
16
IGMP Version 3A receiver can select the sources he wants to hear
(or not)
R
S1
HH
routage multicastgrande distance
S2
H
H
HH
H
query(quelquun intress par un groupe?)
report
(224.9.9.9,
source=S2)
@ IP source 224.9.9.9 donnes
@ destination
en-tte IP
report
(225.5.5.5,
sourceS3)
S3
Internet Group Management Protocol (IGMP)
Protocol to manage the membership to a group
IP hosts report their Mcast groups membership to theirneighbor routers
Messages in IGMPv2 (RFC 2236)
Membership Query (from routers)
Membership Report (from hosts)
Leave Group (from hosts)
Advertise-listen protocol with suppression
Hosts answer only if no other host answered
Soft State protocol
8/4/2019 3.Multicast2pp
17/51
17
IP Multicast Architecture Components
hosts
routers
Service Model
Host-router protocol(IGMP)
Multicast routing protocols(several)
Multicast Service Model
Based on S. Deerings work
Transmission features IP multicast: transmission of an IP packet to a group of hosts
identified by a single destination address
best efforttransmission
Group features Dynamic membership
No restriction on localization and members #
One host may be member of several groups simultaneously
A host does not need to be member of a group to be a source
Permanent/temporary group
The Joinoperation is receiver-driven
8/4/2019 3.Multicast2pp
18/51
18
Senders do not control who joins the group
No control on who sends to the group
Packets coming from different sources may be interlaced
2 different groups may choose the same @
Role of local Mcast routers co-resident or separated from traditional routers
A local router who receives a Mcast packet from one of itshosts, with a TTL>1, forwards it to all subnetworksconnecting receiver memberstant le paquet en local
Multicast Service Model
RFC 1112 specifies necessary host extensions tosupport
3 conformity levels 0: host does not support Mcast 1: host can send packets to a group 2: host supports multicast for sending and receiving
Host IP implementation model
module IP
module LAN(Ethernet)
traduction d@(ARP)
interface de service
LAN
ICMP
interface de service IP
IGMP
modules de protocoles de niveau sup.
Multicast Service Model
tron lan vao nhau
8/4/2019 3.Multicast2pp
19/51
19
Extensions for Mcast sending IP service interface
use SendIP
dest@ = group@
The upper level must be able to specify a TTL
IP Module if IP-dest is on the same local network
or if IP-dest is a group @
then send packet locally to IP-dest
else send packet locally to GatewayTo (IP-dest)
LAN service interface LAN Module
Mcast IP@ / Mcast MAC@ translation mechanism
Multicast Service Model
Extensions for Mcast reception
IP service interface use ReceiveIP
add JoinHostGroup (group-address, interface)
add LeaveHostGroup (group-address, interface)
IP module
Maintain list of groups of which the host is member for each interface(updates with Join and Leave)
integration of IGMP and subscription to 224.0.0.1
LAN service interface add JoinLocalGroup (group-address)
add LeaveLocalGroup (group-address)
LAN module Filtering mechanisms by the card (recommended)
Multicast Service Model
8/4/2019 3.Multicast2pp
20/51
20
IP Multicast Service Model
(RFC-1112)
Each group is identified by a unique IPaddress
Groups can be of any size
Group members may be anywhere on theInternet
Group members may join or leave a groupas they wish
Sources dont need to be members
Service Model
Group membership not explicitly known
Analogy:
Each multicast address is like a radio frequencywhich anyone may send to and that anyone may
listen to
8/4/2019 3.Multicast2pp
21/51
21
IP Multicast Architecture Components
hosts
routers
Service Model
Host-router protocol(IGMP)
Multicast routing protocols(several)
Multicast Routing
The multicast service model makes thelocalization of receivers difficult
Anonymity
Join/leave dynamically
Current options (not very efficient)
Flood the network with packets
Tell routers all possible groups and receivers so
that they may create routes (trees)
8/4/2019 3.Multicast2pp
22/51
22
First Routing Techniques
Flooding and pruning Start with flooding all the network with traffic
Prune branches with no receiver
"unwanted"state where there is no receiver
Link state multicast protocols
Routers advertise groups for which they havereceivers in the whole network
Trees computation on demand
unwanted"state where there is no source
Rendez-Vous Options
Broadcast first packets from each source towards the
whole network: non members prune
Examples: DVMRP, PIM-DM
Broadcast group membership advertisements from
each receiver to the whole network Example: MOSPF
Specify a meeting place" where sources send the
first packets and where receivers subscribe; thisrequires a mapping between the multicast group
address and the rendez-vous point
Examples: CBT, PIM-SM
8/4/2019 3.Multicast2pp
23/51
23
Shared (group) vs Source-based Trees
Source-based trees
Different shortest path tree for each source
Shared (group) trees
Unique tree shared by all members
Data pass through the same tree whatever the
source is
Multicast Trees Taxonomy
Multicast routing can build different types ofdistribution trees
Separate tree whose root is each data source
(DVMRP, MOSPF, PIM-DM, PIM-SM) Shared tree whose root is the groups core /
rendez-vous point (CBT, PIM-SM)
8/4/2019 3.Multicast2pp
24/51
24
Shared Tree Example
RP
Source-Based Tree Examples
8/4/2019 3.Multicast2pp
25/51
25
Shared Trees v.s. Source-Based Trees
Source-based trees
Shortest path trees low delay, better load
balancing
More states in routers (1 state/source)
Efficient for multicast in high-density spaces
Shared trees
Higher delay, traffic concentration 1 state/group in routers
Efficient for multicast in low-density spaces
Protocols Taxonomy
DVMRP source-based trees
MOSPF source-based trees
PIM shared and source-based trees
8/4/2019 3.Multicast2pp
26/51
26
Multicast Routing Algorithms
Goal: compute a tree of links connecting allrouters belonging to the group
3 families
Shortest Path Tree algorithms
Minimum Cost Tree algorithms
Constrained Tree algorithms
SPT Algorithms (1/2)
Goal: compute a tree With S = source
Which covers all receivers Di of the group
So that the distance between S and Diis minimum
Basic algorithms Bellmann-Ford: distance vectors
Dijkstra: link state
1 tree / source
8/4/2019 3.Multicast2pp
27/51
27
SPT Algotrithms (2/2)
S
R1
R3
R5
R6
R9
R11
R2
R8
D1
D2
D3 R4
D4 R7
R10 D6
D7
D5
S
R1
R3
R5
R6
R9
R11
R2
R8
D1
D2
D3 R4
D4 R7
R10 D6
D7
D5
Topology example Tree obtained with avector distance algorithm
MCT Algorithms (1/2)
Goal: minimize the trees total cost
2 families
Minimum Spanning Tree algorithms
constraint: the tree must contain no node which is not amember of the group
Ex: Prims algorithm
les algorithmes Minimum Steiner Tree
la contrainte est leve
problme NP-complet
ils supposent de connatre toutes les liaisons du rseau
ils sont monolithiques
ils nexploitent pas les informations dj disponibles deroutage unicast
8/4/2019 3.Multicast2pp
28/51
28
MCT Algorithms (2/2)SR1
R3
R5
R6
R9
R11
R2
R8
D1
D2
D3 R4
D4 R7
R10 D6
D7
D5
Tree obtained with adistance vector algorithm
S
R1
R3
R5
R6
R9
R11
R2D1
D2
D3
D4
R10 D6
D7
D5
Steiners tree
rq: dist(S, D6) = 5 rq: dist(S, D6) = 7
CT Algorithms
Goal: minimize simultaneously dist(S, Di) etand trees total cost
Principle Associate 2 metrics to each link (distance/delay
and cost)
Look for the minimum cost tree such that
dist(S, Di)
8/4/2019 3.Multicast2pp
29/51
29
What Do We Call IP Multicast ?
Mechanism used in the Internet to build anefficientand loop-freemulticast routingalgorithm
IGMP + Mcast routing protocol
RPF (1/2)
Reverse Path Forwarding (Source-based Routing)
One of the first used techniques
Goal: build a tree with root S which minimizes dist(S, Di)
Principle: use flooding with
If a packet is received by the interface used par router to reach Sthen the packet is forwarded to the other interfaceselse the packet is discarded
Simple mechanism Used information is the same as unicast routing
Ri doesnt need to know spanning trees
No particular mechanism to stop flooding
8/4/2019 3.Multicast2pp
30/51
8/4/2019 3.Multicast2pp
31/51
31
Truncated Broadcasting (1/2)
Goal: reduce traffic on LANs leaves
Idea: use membership information providedby IGMP to determine whether a packetshould be Mcasted on a leaf LAN or not
Kind of leaves pruning
No traffic reduction in the center of the network
Truncated Broadcasting (2/2)
F
R2
H4
H5
F
H2
H3R3
H6
H7R4
H8
R5
H12
H13R9H14
H15R8
R6H9
R7H10
H11
R12
H16
H17
H18
R13
H19
F
H20 H21
R11
H22
F
H23 H24
R10
H25 H26
H1 R1F F
F
F
FF
F
F FF
F
FF
FF
F
F
F
8/4/2019 3.Multicast2pp
32/51
8/4/2019 3.Multicast2pp
33/51
8/4/2019 3.Multicast2pp
34/51
34
DVMRP (5/6)Tree after
graftD
R2
H4
H5
D
H2
H3R3
H6
H7R4
H8R5
H12
H13R9H14
H15R8
R6H9
R7
H10
H11
R12
H16
H17
H18
R13
H19
D
H20 H21
R11
H22
D
H23 H24
R10
H25 H26
H1 R1D
D
D
DD
D
DD
DVMRP (6/6)
Problems common to distance vectorprotocols
Peridodical flooding process for each source
Memorization of prune (Source, Group)
records
8/4/2019 3.Multicast2pp
35/51
35
MOSPF
RFC 1584 (March 94)
Multicast Open Shortest Path First
Principle
Operates in an AS which uses OSPF for unicastrouting
extends OSPF by adding membership informationto link state information broadcast by OSPF
problem: scalability(network size)
Memorization of one record per group and pernetwork link
One tree/source
Multicast OSPF (MOSPF)
OSPF extension (Open Shortest-Path First,intra-domain link state unicast routingprotocol)
Each router indicates groups for which it hasdirectly connected members
8/4/2019 3.Multicast2pp
36/51
36
MOSPF
Link state advertisements are completed bythe addresses of multicast groups to whichlocal members have subscribed
The link state routing algorithm isaugmented to compute the shortest path
distribution tree between any source andany set of destinations
S1
R1
R2
X
Y
Z
Link state: each router floods with link state advertisement
Multicast: membership information added to link state info
Each router computes the multicast tree for each active source and
creates an entry with the list of exit interfaces
8/4/2019 3.Multicast2pp
37/51
37
S1
R1
R2
X
Y
Z has the networks map, including members below X and Y
Z computes the shortest path tree from S1 to X and YZ creates a multicast entry with an exit interface
W, Q and R each create a multicast entry
Z
W
Q
R
R1
R2
X
Y
Z
W
Q
R
S1
The link state advertisement with the new topology can require
a new computation of the tree and of the tables entries
8/4/2019 3.Multicast2pp
38/51
38
R1
R2
X
Y
Z
W
Q
R
S1
T
R3
The link state advertisement (T) with a new membership advertisement
(R3) may require the incremental computation and the additionof an interface to the list of exit interfaces (Z)
Impact on the Route Computation
Source-based multicast trees cannot all bepre-computed
On demand computation when the first packetfrom a source S to a group G arrives
Packet forwarding on exit interfaces whichcorrespond to the local portion of the tree
8/4/2019 3.Multicast2pp
39/51
39
CBT (1/3)
RFC 2189 et 2201 (Sept.97)
Core Based Tree (Group-shared Tree)
Goal: avoid DVMRP and MOSPF drawbacks
Scalable: one single tree for the group
Efficiency (avoid floodings): explicit Join and Leave
messages
Principle: build a bidirectional shared tree, with a
unique core
CBT (2/3)
Trees construction
A local router which has a new member for a group sends ajoin-request message to the core in unicast
The core or the first router on the path which alreadybelongs to the tree answers with a join-ack
Each router which saw the join-request markes the if onwhich it received it
Trees maintenance Each router periodically sends echo-request to its
upstream router
The upstream router answers with echo-reply
If a downstream router does not receive any answer after Ntrials, it prunes its subtree by sending a flush-tree
message
8/4/2019 3.Multicast2pp
40/51
40
CBT (3/3) R1 sends a join (G) to the core R2 marks the R2-R1 if to forward
packets in the future
R3 marks the R3-R2 if
the core marks the core-R3 if
when R4 joins G, its joinstops at R2
R2 marks the R2-R4 if
to send a packet to G, S sends it inunicast to the core which forwards it
R1
S
R2 R3
R4
cur
Advantages No flooding (vs. DVMRP)
A host may join/leave a group without delay (vs. DVMRP)
One record/group with exit interfaces (vs. DVMRP)
No explicit tree computation (vs. MOSPF)
Drawbacks Problems of reliability, robustness and congestion for the core
The tree is not optimal for all sources
PIM (1/3)
RFC 2362 (June 98)
Protocol Independent Multicast
Idea: explicit distinction between 2 distributionscenarios
Dense mode
Members are geographically concentrate in a zone
Idea: RPF with flood-and-prune, similar DVMRP
seems reasonable
8/4/2019 3.Multicast2pp
41/51
41
PIM (2/3)
Sparse mode
Members are geographically scattered
Goal: a router shouldnt have to work, unless it joins a tree
Principle: center-basedapproach, similar to CBT
Excepted: No acknowledgement in response to join
the join is sent periodically to refresh the tree
The RDV point informs an active source that it should stopsending when there is router left in the tree
Changing mode is possible: from shared tree to source-based tree
RDV points periodically send downstream to indicate theiractivity
PIM (3/3)
Changing mode allows to unload the core
In case of failure, hosts which have changed mode keepreceiving
PIM doesnt tell how a router determines a groups rendez-vous point
PIM doesnt tell how to determine whether a group issparse or dense
R1 knows that its SP to S passes through its R1-R4 if or, R1 receives Mcast packets on its R1-R2 if
R1 sends a join to R4
R1 then sends a prune to the core
the core stops Mcast forwarding on core-R2
and R2-R1D
S
R1 R2
R3
cur
R4
Path with CBT
Pathwith PIM
8/4/2019 3.Multicast2pp
42/51
42
Mbone (1/3)
Problem To bring Mcast to play on the Internet, all routers must have Mcast
functions and local routers must support IGMP
Most Internet routers dont support Mcast !!!
Idea Build Mcast-capable subnetworks on the edges of the Internet
Interconnect them through tunnels, tunnels ends are stations withmrouted and an OSs support for Mcast
Multicast Backbone of the Internet
Virtual overlay network, transient solution First tunnel in 88 between BBN and Stanford
Thousands of subnetworks today
Used to broadcast IETF sessions or IEEE/ACM conferences
Mbone (2/3)
Principle: tunneling Encapsulation of Mcast packets transmitted on the Mbone in
traditional IP packets
The receiving end of the tunnel detects that it has a IP packetencapsulated in a IP packet (protocol=4)
after decapsulation, it forwards the Mcast packet
Either locally on its subnetwork, if it has members Or to the next Mcast router, after re-encapsulation
M1 M2
R1 R2
tunnel
Real path
encapsulation decapsulation
@ M1
unicast
@ M2
unicast
@ M1
unicast224.5.5.5 data
Original Mcast packetUnicast IP header
8/4/2019 3.Multicast2pp
43/51
43
Mbone (3/3)
Traffic Conferences typically generate 100-300 kbits/s (limited to
500 kbit/s)
No policy mechanism but user deontology
Applications Session directories (sd, sdr)
audio conferences (vat , nevot , rat)
Video conferences (nv , ivs , vic , nevit)
whiteboard (wb)
Text editor (nte)
Interactive distributed games (MiMaze)
Outline
Introduction
Network Layer Multicast
Transport Layer Multicast Reliability
SRM
RMTP
Perspectives
8/4/2019 3.Multicast2pp
44/51
44
Reliablity Can we extend the approach used in unicast (ACK)?
Each destination must send an ACK for each (group of) message(s)
a msg is retransmitted until reception of an acknowledgement fromeach destination
Network congestion
Source implosion
Idea: use NAK The control goes from source to receivers
The source transmits without caring about ACK
Receivers detect losses thanks to sequence Ns holes
Man protocols have been proposed
Atomicity: either 0 or all recievers have received the message
Termination: the result of a transmission is known in a finitetime
SRM, RMTP, RAMP, RMP, etc.
SRM (1/2)
Scalable Reliable Multicast Offers a reliable transmission, no sequence, scalable (because
receiver-based+ local retransmission)
2 components
One component independent from the application: offers mechanisms to
ask for and recuperate missing data segments
One component dependent on the application: responsible forsequencing and segments naming so that they may be identifieduniquely by the whole group
Idea: a missing segment is not necessarilyretransmitted by the source When a loss is detected, the retransmission request is multicasted
The closest receiver from the requestor multicasts the retransmission
8/4/2019 3.Multicast2pp
45/51
45
SRM (2/2)
S1/D1
S2/D2
S3/D3
D4D5
D7D6
new msgsretransm. Req.retransmissions
Goal: minimize traffic One single member asks for the
retransmission
One single member retransmits themissing segment
Principle Requests sending: slotting+ damping
Request Timer
Retransmissions sending
Repair Timer
Difficulty Timers dimensioning
RTT estimation for each pair (Di,Dj)
hyp : D5, D6 and D7have a missing msg
RMTP Reliable Multicast Transport Protocol
Offers a reliable point-to-multipoint transmission with maintanedsequence
Ideas notion of hierarchy
Reduce source implosion
Reduce response time
notion of local retransmission
principle Receivers are clustered in
local regions
There is one DR (DesignatedReceiver) per region, incharge of status msgaggregation
Status msg
S
DR1
D
DR2
D D
DR3
D D DDR4
D D
Difficulty: Build the logical tree
8/4/2019 3.Multicast2pp
46/51
46
Outline
Introduction
Network layer multicast
Transport layer multicast
Research perspectives Network layer
Transport layer Application layer
Network Layer Perspectives
Adressing and routing withina group
Multicast routing in a mobile network
Multicast routing with QoS
S
R1
R2 R3
R4
D1
D2
R5D DD
D D D DD
S
R1
R2 R3
R4
D2
R5D D
D D D D1D
multicast on a subtree reachcast
8/4/2019 3.Multicast2pp
47/51
47
Transport Layer Perspectives
Flow / Congestion control
Reliability (assisted by routers)
Group members auto-configuration
Application Layer Perspectives
Multicast addresses allocation
Shared objects naming
8/4/2019 3.Multicast2pp
48/51
48
Multicast IP in the Real World
Commercial Motivation
Problem Internet traffic grows by 100% each year
Routers technology improves by 70% each year
Rapid enough routers are very expensive
ISPs must find a way of reducing traffic
Multicast could be used for the Web: distribute data from popular sited to caches on
the Internet
Send Multicast audio/video flows
Software distribution
8/4/2019 3.Multicast2pp
49/51
49
ISPs Problems
Multicast leads to a high networks utilization
One source can produce a high load on the network
Experimental multicast applications require relatively muchbandwith: audio and video
No flow control in most multicast applications
Multicast breaks the Telco/ISP billing model
Currently, both sender and receiver pay for BW
Multicast allows the source to buy less BW and reach as many
receivers The load on the ISPs network in not proportional to the sources
rate
Multicasts Economics
One packet sent to several receivers
source+ benefits from the load reduction on the network
compared to unicast+ lower cost for network connectivity
Network service provider- One sent packet may cause a higher load than a
unicast packet n
+ reduces the global traffic on the network
Receiver= same number of received packets as in unicast
8/4/2019 3.Multicast2pp
50/51
50
Multicast Issues Multicast is not mature
protocols and applications not mature
Tools are difficlut to use, debugging is difficult
Routing protocols leave many unsolved questions
Interoperability flooding and pruning / explicit subscribttion
Routing instability
The multicast development focused on academic problems,not on commercial issues
Multicast breaks the telco/ISP billing model
Routing has not considered policies
PIM, DVMRP, CBT do not consider ISP policies issues
BGMP considers them a little bit, but it is currently being developed
Current Multicast Solution For ISPs
Restriction of multicast data sources
Charge source for multicast traffic distribution
Static agreements
Dont transmit multicast traffic Some ISP propose multicast traffic to their users
(e.g. UUNET UUCast)
ISPs start to negociate agreements betweenpeers
chin chan, ky cang
8/4/2019 3.Multicast2pp
51/51
Bibliography
[RFC 1112] S. Deering, Host Extensionsfor IP Multicasting, August 1989.
[RFC 1075] D. Waitzman, S. Deering, C. Partridge, Distance Vector Multicast Routing Protocol,November 1988.
[RFC 1584] J. Moy, Multicast Extensions to OSPF, March 1994.
[RFC 2189] A. Ballardie, Core Base Trees (CBT Version 2) Multicast Routing: ProtocolSpecification, September 1997.
[RFC 2201] A. Ballardie, Core Base Trees (CBT Version 2) Multicast Architecture, September1997.
[RFC 2236] R. Fenner, Internet Group Management Protocol, Version 2, November 1997.
[RFC 2362] D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering, M. Handley, V. Jacobson, C.Liu, P. Sharma, L. Wei, Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol
Specification, June 1998.
C. Diot, W. Dabbous, J. Crowcroft, Multipoint Communication: A Survey of Protocols, Functionsand Mechanisms, IEEE JSAC, Vol.15, N3, April 1997.
S. Floyd, V. Jacobson, S. McCanne, C.G. Liu, L. Zhang, A Reliable Multicast Framework for Light-
weight Sessions and Applications Level Framing, Proc. of ACM SIGCOMM95, October 1995. S. Paul, K.K. Sabnani, J.C. Lin, S. Bhattacharyya, Reliable Multicast Transport Protocol (RMTP),
IEEE JSAC, Vol.15, N3, April 1997.
S. Paul, Multicasting on the Internet and its Applications, Kluwer Academic Publishers, 1998.
http://www.mbone.com