Computer Networks (Graduate level)
description
Transcript of Computer Networks (Graduate level)
Univ. of Tehran Computer Network 1
Computer Computer NetworksNetworks
(Graduate level)
University of TehranDept. of EE and Computer Engineering
By:Dr. Nasser Yazdani
Lecture 11: MulticastingMulticasting
Univ. of Tehran Computer Network 2
Multicasting IP Multicast IGMP Multicast routing Assigned reading
[DC90] Multicast Routing in Datagram Internetworks and Extended LANs
Next Branch Multicast (NBM) routing protocol (2005)
Chapter 4, multicasting.
Univ. of Tehran Computer Network 3
OutlineOutline
Multicasting Why? Problems, initial solutions. Multicast routing Application level multicast.
Univ. of Tehran Computer Network 4
Why Multicast? Specify a set of receivers and only send
the data to them. Has a lot of applications:
Audio/video conferencing Distance lectures Internet TV Stock quotes and…
Can I just use broadcast?
Univ. of Tehran Computer Network 5
Does not scale Imagine trying to broadcast packets to
everyone on Internet! Wastes network resources
We are sending packets to people who will ignore them.
We clearly need something different…
Problems with broadcast
Univ. of Tehran Computer Network 6
Unicast Use unicast?
One sender, N receivers Sender sends N duplicated unicast
packets, one to each receiver.
S T1 T3 T4
R1
R2
T2
R4 R3Example: Multicast to Ri
by using unicast
Univ. of Tehran Computer Network 7
Problems? Links carry multiple copies of the same
packet. The link closest to the source flooded with
packets. Server needs to know the list of receivers to
send the packet to. How to handle receivers joining and leaving?
- How to define/manage groups? Wastes bandwidth Introduces complexity – now the source needs
to handle receiver crashes, link failures, etc… Source will be “flooded” with messages if a lot
of receivers join at once.
Ideas?
Univ. of Tehran Computer Network 8
More problem Imagine having an IP header of the form:
Any router along the way, forwards a packet if at least one of the destinations is downstream from it.
What if a group has 1000s of recipients? Routers will spend more time doing
forwarding lookup since they will need to search the forwarding table for each address.
R1R2R3R4……..Rn S
source destination
Univ. of Tehran Computer Network 9
IP Multicast Model Main idea Multicast groups Receivers can join or leave at any time. Any host can send to any group at any time –
open architecture The routers duplicate the packets instead of
the source. Routers will need to:
Keep state of groups are there waiting packets from me?
Participate in IGMP* Keep a separate routing table*
Multicast Address Ssource
destination
Univ. of Tehran Computer Network 10
Division of Responsibilities Host’s responsibility to register interest
with networks IGMP
Network’s responsibility to deliver packets to host
Multicast routing protocol Left unspecified:
Address assignment (random, MASC, etc.) Application-to-group mapping (session
directory, etc.)
Univ. of Tehran Computer Network 11
Multicast = Efficient Data Distribution
Src Src
Univ. of Tehran Computer Network 12
Multicast Address Allocation
Currently no standardized method for address allocation (even though an RFC exists about this)
There are a lot of proposed solutions to this Try searching for Multicast Address
Allocation on the net (MALLOC for short)
Univ. of Tehran Computer Network 13
Logical Naming Single name/address maps to
logically related set of destinations Destination set = multicast group
How to scale? Single name/address independent of
group growth or changes
Univ. of Tehran Computer Network 14
Multicast Groups Members are the intended receivers Senders may or may not be
members Hosts may belong to many groups Hosts may send to many groups Support dynamic creation of groups,
dynamic membership, dynamic sources
Univ. of Tehran Computer Network 15
Scope Groups can have different scope
LAN (local scope) Campus/admin scoping TTL scoping
Concept of scope important to multipoint protocols and applications
Univ. of Tehran Computer Network 16
Multicast Scope Control – Small TTLs
TTL expanding-ring search to reach or find a nearby subset of a group
s
1
2
3
Univ. of Tehran Computer Network 17
Multicast Scope Control – Large TTLs
Administrative TTL Boundaries to keep multicast traffic within an administrative domain, e.g., for privacy or resource reasons
An administrative domain
TTL threshold set oninterfaces to these links,greater than the diameterof the admin. domain
The rest of the Internet
Univ. of Tehran Computer Network 18
Multicast Scope Control Administratively-Scoped Addresses (RFC
1112 ) Uses address range 239.0.0.0 —
239.255.255.255 Supports overlapping (not just nested)
domains
An administrative domain
The rest of the Internet
address boundary set oninterfaces to these links
Univ. of Tehran Computer Network 19
Multicast Backbone (MBone)
An overlay network of IP multicast-capable routers
Host/router
MBone router
Physical linkTunnelPart of MBone
R R
R
H R
H
R
RH
Univ. of Tehran Computer Network 20
A method for sending multicast packets through multicast-ignorant routers
IP multicast packet is encapsulated in a unicast packet addressed to far end of tunnel:
Tunnel acts like a virtual point-to-point link Each end of tunnel is manually configured with
unicast address of the other end
MBone Tunnels
IP header,dest = unicast
IP header,dest = multicast
Transport headerand data…
Univ. of Tehran Computer Network 21
Link Layer Multicast On LANs
Exploits the fact that LAN is a broadcast medium.
Ethernet multicast addresses:
01:00:5e:00:00:00 – 01:00:5e:7f:ff:ff
How would an application join a group? Just tell link layer not to discard packets
targeted at the group of interest.
Univ. of Tehran Computer Network 22
Internet Multicast Group D addresses are used for multicast:
224.0.0.0 – 239.255.255.255
If you do an NSLOOKUP on these addresses you will see that they are registered as *.MCAST.NET
Set the highest 4 bits to 1110 use the remaining 28 Some well known addresses:
224.0.0.0 ~ 224.0.0.25 224.0.0.1 (ALL-SYSTEMS.MCAST.NET): all multicast hosts on
the subnet 224.0.0.2 (ALL-ROUTERS.MCAST.NET): all multicast routers on
the subnet Need a suite of protocols to take care of the various
aspects of Multicast (membership management, routing, etc..)
Univ. of Tehran Computer Network 23
Multicast Addressing multicast address a set of Internet hosts comprising a
multicast group. Senders : Dest. Address = multicast address IP multicast group Class D address Class D address : 1110 + 28 bit multicast group ID 224.0.0.0
to 239.255.255.255 0 1 2 3 ----------- 28 bits ---------- 1 1 1 0 Multicast Group ID 224.0.0.0 is reserved. 224.0.0.1 to 224.0.0.225 reserved for
permanent assignments to various uses, including routing protocols and other protocols that require a well-known permanent address.
Univ. of Tehran Computer Network 24
Multicast Addressing Some of the well-known groups include :
“all systems on this subnet” 224.0.0.1“all routers on this subnet” 224.0.0.2“all DVMRP routers” 224.0.0.4“all OSPF routers” 224.0.0.5“all OSPF designated routers”224.0.0.6“all RIP2 routers” 224.0.0.9“all PIM routers” 224.0.0.13“all CBT routers” 224.0.0.15
The remaining groups are either permanently assigned to various multicast applications or are available for dynamic assignment (239.0.0.0 to 239.255.255.255 for “Administratively scoped” applications)
Univ. of Tehran Computer Network 25
IP Multicast Protocol Suite A protocol that distributes
membership information – IGMP
A protocol that performs the routing – DVMRP, PIM-SM, PIM-DM, etc…
Protocols that deal with address allocation, reliability, congestion
Univ. of Tehran Computer Network 26
IP Multicast Architecture
Hosts
Routers
Service model
Host-to-router protocol(IGMP)
Multicast routing protocols(various)
Univ. of Tehran Computer Network 27
IP Multicast Service — Sending
Uses normal IP-Send operation, with an IP multicast address specified as the destination
Must provide sending application a way to: Specify outgoing network interface, if >1
available Specify IP time-to-live (TTL) on outgoing
packet Enable/disable loop-back if the sending host
is a member of the destination group on the outgoing interface
Univ. of Tehran Computer Network 28
IP Multicast Service — Receiving
Two new operations Join-IP-Multicast-Group(group-address,
interface) Leave-IP-Multicast-Group(group-
address, interface) Receive multicast packets for joined
groups via normal IP-Receive operation
Univ. of Tehran Computer Network 29
IGMPv2 Internet Group Management Protocol
RFC 2236 IGMP operates locally
between end hosts and their border router The goal is allowing the border router to learn what
groups are presented on the attached subnets.
S
R1
R2
A C
B
IGMPIGMP
<G1, G2, G3><G1, G2, G3>
<G1><G1>
<G1, G3><G1, G3>
Border RouterBorder Router<G1, G2, G3><G1, G2, G3>
<G1><G1>
<G1><G1>
Eth
ern
et/
Eth
ern
et/
Lan
Lan
IGMP Example
Univ. of Tehran Computer Network 30
IGMP protocol A soft-state protocol with 3 types of messages:
membership_query (MQ): sent by the router Determines the set of joined multicast groups on the LAN
membership_report (MR): sent by the hosts When a host joins a group or When a host responds to a MQ
Leave_group (LG): sent by the hosts When a host leaves a group
All of these messages are broadcasted over the LAN
router
host
timelineMR:join
MQ
MR
MQ
MR
LG:leave
Univ. of Tehran Computer Network 31
IGMP Protocol Border router does not need to know which
host(s) have joined a given multicast group. Only one host needs to report Why?
Potentially MR messages sent by the hosts could be problematic. How? Solution: Use feedback suppression
Each host waits randomly between 0 and max_resp_time
Send the report if no one else has sent in that period Leave Group message (LG) optional…
Why?
Univ. of Tehran Computer Network 32
Multicast Routing Basic objective – build distribution
tree for multicast packets Multicast service model makes it
hard Why? Anonymity Dynamic join/leave
Univ. of Tehran Computer Network 33
Routing Techniques Flood and prune
Begin by flooding traffic to entire network Prune branches with no receivers Examples: DVMRP, PIM-DM Unwanted state where there are no receivers
Link-state multicast protocols Routers advertise groups for which they have
receivers to entire network Compute trees on demand Example: MOSPF Unwanted state where there are no senders
Univ. of Tehran Computer Network 34
Routing Techniques Core based protocols
Specify “meeting place” aka core Sources send initial packets to core Receivers join group at core Requires mapping between multicast
group address and “meeting place” Examples: CBT, PIM-SM
Univ. of Tehran Computer Network 35
Shared vs. Source-based Trees
Source-based trees Separate shortest path tree for each
sender • DVMRP, MOSPF, PIM-DM, PIM-SM
Shared trees Single tree shared by all members Data flows on same tree regardless of
sender CBT, PIM-SM
Univ. of Tehran Computer Network 36
Source-based TreesRouter
Source
Receiver
S
R
R
R
R
R
S
S
Univ. of Tehran Computer Network 37
A Shared Tree
RP
Router
Source
Receiver
S
S
S
R
R
R
R
R
Univ. of Tehran Computer Network 38
Shared vs. Source-Based Trees
Source-based trees Shortest path trees – low delay, better load
distribution More state at routers (per-source state) Efficient for in dense-area multicast
Shared trees Higher delay (bounded by factor of 2), traffic
concentration Choice of core affects efficiency Per-group state at routers Efficient for sparse-area multicast
Univ. of Tehran Computer Network 39
DVMRP Builds a multicast routing table
By exchanging distance information amongst routers.
Gives consistent view of multicast tree among all routers
Stores ‘dependent routers’ info If there are multiple routers on the
same LAN lower IP address becomes the designated forwarder.
Univ. of Tehran Computer Network 40
DVMRP Multicast packets are forwarded based on
Reverse Path Forwarding. coming on the next slide!
Leaf routers check and send prune message when no group member on the network.
Upstream router prune the interface with no downstream router.
Graft message sent to create a new routing branch for late members.
Restart forwarding after a set prune lifetime (typical value 12 hours)
Univ. of Tehran Computer Network 41
Reverse Path Forwarding (RPF)
Procedure:1. A packet is received through interface I, from S
(source) to G (multicast group) - packet (S,G)2. A router looks into the routing table to find an
interface used to send packet to S, I (parent).3. If I != I (parent), I is a wrong interface to
receive (S,G).4. if I = I(parent), I is a correct interface to receive
(S, G). If the procedure succeeds, the datagram is
forwarded to all interfaces except I Otherwise, typically it is silently discarded. Packet is never forwarded back out I.
Univ. of Tehran Computer Network 42
Reverse Path Flooding (RPF)
A router forwards a broadcast packet originating at source S if and only if it arrives via the shortest path from the router back to S (i.e., the “reverse path”). Otherwise the packet will be discarded
The router forwards the packet out all incident links except the one on which the packet arrived.
Disadvantage :
Any single broadcast packet may be transmitted more than once across any link, up to the number of routers that share the link.
Univ. of Tehran Computer Network 43
Reverse Path Flooding (RPF)
RPF Check Fails!
Unicast Route TableUnicast Route Table
NetworkNetwork Interface Interface
151.10.0.0/16151.10.0.0/16 S1S1
198.14.32.0/24198.14.32.0/24 S0S0
204.1.16.0/24204.1.16.0/24 E0E0
A closer look: RPF Check FailsRPF Check Fails
Packet Arrived on Wrong Interface!
E0
S1
S0
S2
S1S1
Multicast Packet fromSource 151.10.3.21
XDiscard Packet!
Univ. of Tehran Computer Network 44
Reverse Path Flooding (RPF)
A closer look: RPF Check SucceedsRPF Check Succeeds
RPF Check Succeeds!
Unicast Route TableUnicast Route Table
NetworkNetwork Interface Interface
151.10.0.0/16151.10.0.0/16 S1S1
198.14.32.0/24198.14.32.0/24 S0S0
204.1.16.0/24204.1.16.0/24 E0E0
E0
S1
S0
S2
Multicast Packet fromSource 151.10.3.21
Packet Arrived on Correct Interface!S1S1
Forward out all outgoing interfaces.(i. e. down the distribution tree)
Univ. of Tehran Computer Network 45
Reverse Path Broadcasting (RPB)
Eliminates the duplicate broadcast packets generated by Reverse Path Forwarding
It is necessary for each router to identify which of its links are “child” links in the shortest reverse path tree rooted at any given source S.
When a broadcast packet originating at S arrives via the shortest path back to S, the router can forward it out only the child links for S.
Univ. of Tehran Computer Network 46
Truncated Reverse Path Broadcasting (TRPB)
The previous algorithms used broadcasting and so were wasting the bandwidth on the links that had no group members.
In TRPB only non-member leaf networks are deleted from each broadcast tree.
Leaf networks are the networks which have no downstream router.
So the leaf networks must be found out and it must be determined if there is any member on the leaf network or not then.
Univ. of Tehran Computer Network 47
Reverse Path Multicasting (RPM)
Provides on-demand pruning of shortest-path multicast trees. When a source first sends a multicast packet to a group, it
uses TRPB algorithm. When the packet reaches a router for whom all of the child
links are leaves and none of them have members of the destination group, a non-membership report (NMR) for that (source, group) pair is generated and sent back to the router that is one hop towards the source.
If the one-hop-back router receives NMRs from all of its child routers, and if its child links also have no members, it in turn sends an NMR back to its predecessor.
Subsequent multicast packets from the same source to the same group are blocked from traveling down the unnecessary branches by the NMRs sitting in intermediate routers.
A non-membership report includes an age field that is used to cancel the NMR effect after some time.
Univ. of Tehran Computer Network 48
Reverse Path Multicasting (RPM)
S
R
R R
R RR
G
G
G G
1. Send based on TRPB2. Send Prune message3. Prune the branches
Univ. of Tehran Computer Network 49
DVMRP in Action - 1
Source
Receiver 1
S
R1
DF
source tree
Forming a source tree
Univ. of Tehran Computer Network 50
DVMRP in Action - 2
Source
Receiver 1
S
R1
DF
source tree
datagram
Broadcast/flood
Univ. of Tehran Computer Network 51
DVMRP in Action - 3
Source
Receiver 1
S
R1
DF
source tree
datagram
IGMP DVMRP-Prune
prune
Univ. of Tehran Computer Network 52
DVMRP in Action - 4
Source
Receiver 1
S
R1
DF X
Y
source tree
datagram
X and Y are Pruned
Univ. of Tehran Computer Network 53
DVMRP in Action - 5
Source
Receiver 1
S
R1
DF X
Y
source tree
datagram
R2
Receiver 2
IGMP DVMRP-Graft
New Member
Univ. of Tehran Computer Network 54
DVMRP in Action - 6
Source
Receiver 1
S
R1
DF X
Y
source tree
datagram
R2
Receiver 2
New branch
Univ. of Tehran Computer Network 55
Possible Problems with IP Multicast
Doesn’t scale well with number of multicast groups Each router has to maintain state for every
“active” multicast group. Flooding in the beginning (bandwidth waste)
Open to DoS attacks by malicious senders. Multicast address assignment problems – how
to be globally consistent? Providing TCP-like reliability is hard Deployment problems as not all routers can
do multicast. Also, lack of business incentive as not clear how to make money on this.
Univ. of Tehran Computer Network 56
Another Approach to Multicast Routing
PIM – Protocol Independent Multicast Protocol Designed to provide scalable interdomain routing across
internet Can be independent of the underlying unicast routing protocol.
DVMRP dependent on the unicast routing protocol to find the multicast source.
Optimizes traffic depending on the density of receivers in the region.
Two main modes: Dense Mode –
Similar to DVMRP, works with flooding Builds source rooted distribution tree
Sparse Mode – Introduces Rendezvous Points – receivers “meet” new sources at the
RPs Builds a shared tree
Univ. of Tehran Computer Network 57
Shared Tree Example (PIM-SM)
S F1
F3
RP
F2 GR3
R5
R4
Sender registerswith RP
G sets up stateto RP
Univ. of Tehran Computer Network 58
Shared Tree Example (PIM-SM)
S F1
F3
RP
F2 GR3
R5
R4S -> RP unicast
RP -> G multicast
Univ. of Tehran Computer Network 59
IP Multicast Concepts
Host-to-router Protocol (IGMP): keep router up-to-date with group membership of
entire LAN
Multicast routing protocols (various): build distribution tree for multicast packets
senderreceivers
On-TreeLink
Branching router
On-Tree router
Designated Router
Univ. of Tehran Computer Network 60
SPT vs. Steiner Tree
R2
R5
R4
R1
S1
1
2
1
4
1
1
12
1
3
1
1
R3
R2
R5
R4
R1
S1
1
2
1
4
1
1
12
1
3
1
1
R3
SPT (Shortest Path Tree) Steiner
Router SourceReceiver
S
R
Univ. of Tehran Computer Network 61
Shared vs. Source-Based Trees
Router Source
Receiver
S
R
R
R
R
S
S
R
S
R
R
R
R
S
RP
Source-Based Tree Shared Tree
Univ. of Tehran Computer Network 62
Tree types Shortest Path Tree
Simplicity of construction method Distributed solutions High cost Source Based Tree
low delay, better load distribution, Per-source state at routers
Shared trees Higher delay, traffic concentration, Per-group state at routers
Steiner trees Lowest cost, highest delay NP-complete, Centralized solutions
Univ. of Tehran Computer Network 63
Basic Routing Techniques Flood & prune: DVMRP, PIM-DM
RSPT, Periodic Flooding, inter-domain routing difficulties,
Link-state multicast protocols: MOSPF SPT, High memory consumption, tree
calculation in every node. Core based protocols: CBT, PIM-SM
Comply well with the basic model, Sub-optimal tree, inter-domain routing difficulties, traffic concentration, sensitivity to core selection method, RSPT,
Univ. of Tehran Computer Network 64
Alternative Routing Techniques Explicit Multicast: Xcast, Bcast
Deployment, stateless, scalable, waste of data space, processing overhead, small groups only.
Application Level Multicast: ESM, NICE Deployment, stateless, no control burden on
network, scalable, overlay construction difficulties, stress, sub-optimal trees, stretch, high failure rate of host, cheating
Branching Point Based: NHBH , REUNITE, HBH SPT, low memory requirement, incremental
deployment, using unicast forwarding, high availability, Superfluous lookups.
Univ. of Tehran Computer Network 65
Two Main Problems of IP multicast State maintenance
Memory shortage when number of groups increase significantly
State invalidation due to routes changes
Need for complex inter-domain routing and management (PIM-SM/MSDP/MBGP)
Univ. of Tehran Computer Network 66
NBM
Univ. of Tehran Computer Network 67
Branching Point Idea Node types:
Member nodes Relay nodes Branching points
More than 80% of tree nodes are relay nodes.
H1S
R1
H2
R2 H4
R6 H3
r4
R4
R3
R5
r3
r5
r2
r1
R7
R9
R8
(a) Complete Tree
H1S
H2
H4
H3
r4
r3
r5
r2
r1
(b) Reduced Tree
Univ. of Tehran Computer Network 68
Problems with current methods Unnecessary lookups for unicast and
multicast packets
Does Hi has acorresponding entry in
the MFT?
Network Processor
ParserUnicast Forwarding Engine
Forward the packet to allHx in MFT based on
unicast forwarding table
Multicast Forwarding Engine
Forward the packetbased on unicastforwarding table
No
Yes
...
Univ. of Tehran Computer Network 69
Problems with current methods
REUNITE Asymmetries may result in creation of duplicate packets The departure of one receiver may change the route for others Route changes invalidate MCT Route change may disconnect a subset of receivers from the
tree even though all nodes and links work properly HBH
All relay nodes between every two adjacent BPs must keep MFT
Duplicate packets creation duo to asymmetries Route changes invalidate MCT
SEM The whole multicast tree must be constructed again if:
a new member joins the multicast session one of the existing members leaves the session
The number of receivers is inherently limited due to packet size limit
Univ. of Tehran Computer Network 70
NBM Principals
NBM main ideas: Build message contains IP addresses
of: the new receiver the next BP in the tree
Children of a failed BP detect failure of their parent and repair it locally by asking their grandpa to find a new parent for them.
Univ. of Tehran Computer Network 71
NBM Principals Seven Messages Type:
Join to announce receiver desire to join the tree
Leave to announce receiver desire to leave tree
Build to find associated BP of the new receiver
Replace To inform parent BP about creation of a new BP in the tree
Parent to inform a receiver or a BP about its parent and grandpa
Repair to locally repair the tree
Unlock To unlock parent BP
Univ. of Tehran Computer Network 72
Tree construction: r1 join
s
B2
rn2rn3 JoinBuildParentReplace
rn1
B1
rn4
r3
r1
r2
rn6
rn5
MFT
r1
Univ. of Tehran Computer Network 73
Tree construction: r2 join
s
B2
rn2rn3 JoinBuildParentReplace
rn1
B1
rn4
r3
r1
r2
rn6
rn5
MFT
r1 r2
MFT
r1 r2
B1
Univ. of Tehran Computer Network 74
Tree construction: r3 join
s
B2
rn2rn3JoinBuildParentReplace
rn1
B1
rn4
r3
r1
r2
rn6
rn5
MFT
MFT
r2 r1
B1
MFT
r2 r3
B2
Univ. of Tehran Computer Network 75
Tree Maintenance Each BP refresh its children periodically.
Refresh message contains IP address of grandpa Refresh rates of higher level BPs increase linearly
If a BP or a receiver misses three consecutive refresh (parent) messages: it sends a repair message toward the grandpa
Grandpa deal with repair requests in the same way as source do with receiver join messages: It sends a Build message toward the orphaned node or adds it to its MFT
Univ. of Tehran Computer Network 76
Tree Maintenance
s
B3
rn2rn3
RepiarBuildParentReplace
rn1
rn4
r3
r1
r2
B2
rn5
MFT
MFT
r1
B1
MFT
r2 r3
rn7r4
B2
B1
rn6rn9
rn8
B3
Univ. of Tehran Computer Network 77
Tree Maintenance
s
B3
rn2rn3
JoinBuildParentReplace
rn1
rn4
r3
r1
r2
B2
rn5
MFT
MFT
r1
B1
MFT
r2 r3
rn7r4
B3
B1
rn6rn9
rn8
MFT
B2 r4
rn6
Univ. of Tehran Computer Network 78
Height estimation Dependent Receivers (DR)
A BP can estimate DR of a branch by counting the number of Build messages passing through it.
Height of the branch (in reduced tree) is approximately logXDR.
Each branch has a different refresh rate Refresh period = MTI/logXDR
Higher level BPs refresh their children more frequently.
NMTI=NMEM*X2/(X-1)2
Univ. of Tehran Computer Network 79
Packet Forwarding in NBM
Node B received a packet with unicast destination H i
Is the Protocolfield = NBM_PROT ?
Network Processor
Parser
Unicast Forwarding Engine
Forward the packet toall Hx in MFT based on
unicast forwarding table
Multicast Forwarding Engine
B = Hi ?YesNo
Forward the packetbased on unicastforwarding table
No
Yes
Univ. of Tehran Computer Network 80
Simulation Setup
myns: large-scale simulations GT-ITM: graph generation
Transit-Stub model (10100 nodes) 10 transit domains Each transit domain has 10 nodes Each transit domain has 5 stub domains Each stub domain has 20 nodes
Average node degree: 3.5 50 simulation runs for each point
Univ. of Tehran Computer Network 81
Simulation Metrics Number of required table lookups
Multicast Forwarding Gain (MFG): the ratio between the number of required lookups in OBP and NBM
Overall Forwarding Gain (OFG): OFG takes unicast traffic into consideration as well
Number of required MFT entries SPT: NBP+NRN+NMEM RT: NBP+NMEM. MFT Reduction Gain (MRG): the ratio between SPT and
RT values. Tree availability
Tree Availability Gain (TAG): the ratio of non-leaf components of SPT to non-leaf components of RT or: NBP+NRN/NBP
Stress
Univ. of Tehran Computer Network 82
Table Lookups
100
1100
2100
3100
4100
101 303 505 707 909 1111 1313 1515Number of Receivers
Num
ber
of U
nica
st L
ooku
ps
NBMOBP
1.3
1.4
1.5
1.6
1.7
1.8
1.9
2
101 303 505 707 909 1111 1313 1515Number of Receivers
Mul
ticas
t For
war
ding
Gai
n
MFG OFG-70%OFG-80% OFG-90%
Univ. of Tehran Computer Network 83
Stress
1700
1800
1900
2000
2100
2200
2300
2400
0 2 4 6 8 10 12 14 16 18 20Link Stress (a)
Num
ber o
f Lin
ks
UnicastNBM 20%NBM 50%
2410
2430
2450
2470
2490
20 120 220 320 420 520 620 720 820 920 1020Link Stress (b)
Num
ber o
f Lin
ks
UnicastNBM 20%NBM 50%
Univ. of Tehran Computer Network 84
Tree Characteristics
0
300
600
900
1200
101 303 505 707 909 1111 1313 1515Number of Receivers
Cou
nt
MEM-20% BP-20% RN-20%MEM-50% BP-50% RN-50%MEM-100% BP-100% RN-100%
0.03
0.08
0.13
0.18
0.23
101 303 505 707 909 1111 1313 1515Number of Receivers
Rat
io o
f BP
s to
all
tree
nod
es
BP-Ratio-100%BP-Ratio-20%BP-Ratio-50%
Univ. of Tehran Computer Network 85
Branching Factor
0
2
4
6
8
101 303 505 707 909 1111 1313 1515Number of Receivers
Ave
rag
e B
ran
chin
g F
acto
r o
f B
Ps
X-20%X-50%X-100%
Univ. of Tehran Computer Network 86
TAG & MRG
1
6
11
16
21
101 303 505 707 909 1111 1313 1515Number of Receivers
Tree
Ava
ilabi
lty G
ain
TAG-100%TAG-20%TAG-50%TAG-HBH
1.4
1.8
2.2
2.6
3
3.4
101 303 505 707 909 1111 1313 1515Number of Receivers
MFT
Red
uctio
n G
ain
MRG-100%MRG-20%MRG-50%MRG-HBH
Univ. of Tehran Computer Network 87
Control Overhead
0
3000
6000
9000
12000
15000
101 303 505 707 909 1111 1313 1515Number of Receivers
Nu
mb
er o
f co
ntr
ol
mes
sag
es
Join BuildUnlock ReplaceParent
0
1000
2000
3000
4000
5000
6000
101 303 505 707 909 1111 1313 1515Number of Receivers
Nu
mbe
r o
f Par
ent m
essa
ges
Parent-Construction-3Parent-Maintenance-3Parent-Construction-2.3Parent-Maintenance-2.3
Univ. of Tehran Computer Network 88
Application Level Multicast Is what Netmeeting does based on IP multicast?
The idea is – don’t mess with IP, let the applications handle the multicast.
Used very widely today: Sources send packets to a central server which forwards them to
all receivers for the group
Efficient application layer multicast Apps self-organize into a multicast distribution structure Data replication and management only performed by group
members.
Univ. of Tehran Computer Network 89
Application Level Multicast Pros:
Easy to develop Pushes complexy towards the end systems No address assignment problems Can support a large number of groups
Cons Duplicate packets on the same link Higher delay due to distribution along longer
than optimal paths Longer reaction time to group joins Can potentially be complex
Univ. of Tehran Computer Network 90
Current Status IP Multicast
Many IETF groups work on various multicast related protocols. New routers have implementations of DVMRP Only a few ISPs have multicast feature turned on in the
routers.
MBone (Multicast backBone) A transient infrastructure before IP Multicast is fully deployed. A virtual network of multicast-capable islands connected by
tunnels (unicast encapsulated between islands) Runs DVMRP
Some enterprise networks have deployed multicast.
Univ. of Tehran Computer Network 91
Next-lecture: End to end Protocols
End to End issues UDP TCP
Different Version of TCP Assigned reading
Chapter 5 of the book