Multicast
For one-to-many use, but not used by many
Eirik Rodvang Tveterås
Endre Kure
11.03.16
11 March 2016 |
1
Background of presenters
Eirik Rodvang Tveterås

Bachelor: Design, Use and Interaction at
UIO

Master: Programming and networks at
UIO

Currently writing master thesis at
Simula
Endre Kure

Master (M.Sc.) in Industrial Economics
and Technology Management at NTNU
 Specialization in Networks and
Financial Engineering

Currently PhD Candidate at IFI/Simula
 Working on TIDENET-project
(Theoretical and Data-driven
Approaches for Energy-efficient
Networks)
11 March 2016 |
2
The presentation based two articles in the curriculum of INF 5050
Articles from the INF 5050 presented

“The Evolution of Multicast: From the MBone to Interdomain Multicast to Internet2
Deployment", K.C. Almeroth, IEEE Network, January/February 2000

"A comparative study of multicast protocols: top, bottom, or in the middle?" L. Lao, J.H. Cui, M.
Gerla, and D. Maggiorini. UCLA 2005
Each slide is marked accordingly with source in foot note
11 March 2016 |
3
Agenda
Historic perspective on multicast
Layer dependent deployment
Types of IP multicast
Future perspective
11 March 2016 |
4
Multicast increases communication performance through the
use of “three principles”
Multicast basics

One-to-many or many-to-many
communication

Indirect communication through
groups

Increased performance with
reduced costs

Introduced as IP multicast service
(MBone)
Founding principles
1 IP-style semantics


Source can send packets without
preregistration
Packets sent with UDP
2 Open groups


Source only need multicast address, and
no group knowledge, to send
Possible with multiple sources per
group
3 Dynamic groups


Group members can join or leave a
multicast group at will
No synchronization or negation with a
centralized group mgmt. entity
Source: “The Evolution of Multicast: From the MBone to Interdomain Multicast to Internet2 Deployment", K.C. Almeroth,
IEEE Network, January/February 2000
11 March 2016 |
5
Multicast Backbone (MBone) first implementation of multicast in IP Internet
MBone basics

IP multicast service

Experimental backbone for
carrying IP multicast traffic on the
Internet

Deployed as a flat virtual network

Intradomain multicast through
point-to-point tunnels
Deployment of MBone
Multicast
island
Source: “The Evolution of Multicast: From the MBone to Interdomain Multicast to Internet2 Deployment", K.C. Almeroth,
IEEE Network, January/February 2000
Unicast
tunnel
11 March 2016 |
6
Agenda
Historic perspective on multicast
Layer dependent deployment
Types of IP multicast
Future perspective
11 March 2016 |
7
Multicast efficiency increase and control overhead decrease with nearness to
router, but with higher deployment cost
Types of multicast
(e.g protocol)
Efficiency
Control
overhead
Ease of
deployment
Multicast tree description
Router
Leaf node
Application
layer
Multicast
(NARADA/
NICE)
Low
High
High
Proxy node
Network link
Multicast tree
Multicast forward tables
kept by leaf nodes
Overlay
multicast
(Pure Overlay
Multicast –
POM)
Medium
Medium
Medium
Multicast forward tables
kept by special
deployed backbone
proxy overlay (deployed
by ISP)
IP multicast
(PIM-SM)
High
Low
Low
Multicast forward tables
kept by routers
Source: "A comparative study of multicast protocols: top, bottom, or in the middle?" L. Lao, J.H. Cui, M. Gerla, and D. Maggiorini. UCLA 2005
11 March 2016 |
8
Simulations show IP multicast with lowest control overhead and
tree cost
Evaluation of simulation
Multicast tree quality

Metrics
Results of
simulation
(intradomain)
Control overhead
Bandwidth: Number of physical links in
the multicast tree (tree cost)
End-to-end delay: Number of hops
between a source and a receiver

Number of control messages1)
incurring during a 1000 second
simulation

Application:
 Highest tree cost
 Delay increase with group size


Overlay:
 Tree cost increases more then IP for
larger groups
 Delay slightly higher the IP
Application:
 Overhead drastically increase with
group size
 Lower that overlay for smaller
groups

Overlay:
 Backbone overlay messages
independent of group size
 Cluster messages increase with
group size

IP:


IP:


Lowest tree cost
Same delay as unicast

Lowest control overhead
Note: 1) Includes tree set-up, refresh and tear-down messages as well as overlay link measurements
Source: "A comparative study of multicast protocols: top, bottom, or in the middle?" L. Lao, J.H. Cui, M. Gerla, and D. Maggiorini. UCLA 2005
11 March 2016 |
9
Overlay multicast promising competitor
to IP multicast (benchmark)
Main findings from simulation
1. IP and Overlay multicast have
better trade-offs between tree
cost and end-to-end delay
2. For single groups; Overlay has
higher control overhead than IP
and Application, but this
drastically decrease with multiple
groups
3. Overlay performance significantly
affected by proxy structure
Conclusion of paper
1 Overlay on par with IP

Overlay multicast could achieve
comparable performance to IP multicast
2 Group size matters

Compared with Application layer
multicast, Overlay multicast is a good
choice for large number of groups
3 Time dependent deployment


Application multicast is suitable for
immediate deployment
Overlay multicast could serve as a longterm solution, but need more research
Source: "A comparative study of multicast protocols: top, bottom, or in the middle?" L. Lao, J.H. Cui, M. Gerla, and D. Maggiorini. UCLA 2005
11 March 2016 | 10
Agenda
Historic perspective on multicast
Layer dependent deployment
Types of IP multicast
Future perspective
11 March 2016 | 11
IP multicast divided into 2 categories with different challenges;
intradomain multicast most researched
IP multicast
Intradomain
Main
challenge

Scalability

Manageability (Virtual topology
mgmt.)
Interdomain

Manageability (AS cooperation)
Source: “The Evolution of Multicast: From the MBone to Interdomain Multicast to Internet2 Deployment", K.C. Almeroth,
IEEE Network, January/February 2000
11 March 2016 | 12
Time domain and graph features categorize the various protocols into 4
subgroups of multicasting
IP multicast
Intradomain
Main
challenge

Scalability

Manageability (Virtual topology
mgmt.)
Dense trees
Interdomain

Sparse trees
Manageability (AS cooperation)
Near-term
Long-term
 Near-term solution focus on

Nodes in tree
protocols enabling interdomain
multicasting
Long-term solution focus on
experimental protocols to enhance
established solutions
Nodes not in tree
Source: “The Evolution of Multicast: From the MBone to Interdomain Multicast to Internet2 Deployment", K.C. Almeroth,
IEEE Network, January/February 2000
11 March 2016 | 13
Node density determines protocol efficiency
Dense Trees
Sparse trees

“Broadcast-and-prune” approach

“Explicit join” approach

Reverse shortest path tree rooted
at source

Reverse shortest path or shared
trees

Designed for intradomain
multicast

Core node called a Rendezvous
Point (RP)

Some dense tree protocols are:
 DVMRP
 MOSPF
 PIM-DM

Some sparse tree protocols are:
 PIM-SM
 CBT
Source: “The Evolution of Multicast: From the MBone to Interdomain Multicast to Internet2 Deployment", K.C. Almeroth,
IEEE Network, January/February 2000
11 March 2016 | 14
Agenda
Historic perspective on multicast
Layer dependent deployment
Types of IP multicast
Intradomain multicast
Interdomain multicast
Future perspective
11 March 2016 | 15
DVMRP example of protocol with “broadcastand-prune” approach that hallmarks dense mode protocols
Main features
Protocol
mode
Tree type
Main steps
Dense mode Sparse mode

Shortest path

Shared
Other


Periodically IGMP is used to discover
group members
State information kept in router for each
source
Differences to similar protocols


PIM-DM
 Assumes unicast routing table available
 Packets are forwarded to all outgoing
interface (except pruned devices)
MOSPF
 Membership is shared and flooded
 Data is only sent on request
1. Source broadcasts data packet on local
network. Attached routers forwards it on
all outgoing interfaces
2. Each router performs a reversed path
forwarding (RPF) check. Router checks
incoming packet is on its outgoing
interface for the source address
1. If yes, packet is forwarded on all
outgoing interfaces
2. If no, packet is dropped
3. Leaf router checks if it has knowledge of
any group members (with IGMP)
1. If members, the packet is forwarded
2. No members, “prune”-message is sent
back to source on RPF interface
4. All “prune”-packets forwarded to source.
Each router in path updates its state.
Router sends “prune”-message if it
receives “prune”-messages on all incoming
non-RPF interfaces
Source: “The Evolution of Multicast: From the MBone to Interdomain Multicast to Internet2 Deployment", K.C. Almeroth, IEEE Network, January/February 2000
Notes: DVMRP = Distance Vector Multicast Routing Protiocol, IGMP = Internet Group Management Protocol, OMSPF = Multicast Open Shortest Path First,
PIM-DM = Protocol Independent Multicast Dense mode
11 March 2016 | 16
DVMRP – Animation 1
Main features
Router
Source
Multicast
packet
Prune
packet
Leaf (nonmulticast)
Main steps
Leaf
(multicast)
1. Source broadcasts data packet on local
network. Attached routers forwards it on
all outgoing interfaces
2. Each router performs a reversed path
forwarding (RPF) check. Router checks
incoming packet is on its outgoing
interface for the source address
1. If yes, packet is forwarded on all
outgoing interfaces
2. If no, packet is dropped
3. Leaf router checks if it has knowledge of
any group members (with IGMP)
1. If members, the packet is forwarded
2. No members, “prune”-message is sent
back to source on RPF interface
4. All “prune”-packets forwarded to source.
Each router in path updates its state.
Router sends “prune”-message if it
receives “prune”-messages on all incoming
non-RPF interfaces
Source: “The Evolution of Multicast: From the MBone to Interdomain Multicast to Internet2 Deployment", K.C. Almeroth,
IEEE Network, January/February 2000
11 March 2016 | 17
DVMRP – Animation 2
Main features
Router
Source
Multicast
packet
Prune
packet
Leaf (nonmulticast)
Main steps
Leaf
(multicast)
1. Source broadcasts data packet on local
network. Attached routers forwards it on
all outgoing interfaces
2. Each router performs a reversed path
forwarding (RPF) check. Router checks
incoming packet is on its outgoing
interface for the source address
1. If yes, packet is forwarded on all
outgoing interfaces
2. If no, packet is dropped
3. Leaf router checks if it has knowledge of
any group members (with IGMP)
1. If members, the packet is forwarded
2. No members, “prune”-message is sent
back to source on RPF interface
4. All “prune”-packets forwarded to source.
Each router in path updates its state.
Router sends “prune”-message if it
receives “prune”-messages on all incoming
non-RPF interfaces
Source: “The Evolution of Multicast: From the MBone to Interdomain Multicast to Internet2 Deployment", K.C. Almeroth,
IEEE Network, January/February 2000
11 March 2016 | 18
DVMRP – Animation 2.1
Main features
Router
Source
Multicast
packet
Prune
packet
Leaf (nonmulticast)
Main steps
Leaf
(multicast)
1. Source broadcasts data packet on local
network. Attached routers forwards it on
all outgoing interfaces
2. Each router performs a reversed path
forwarding (RPF) check. Router checks
incoming packet is on its outgoing
interface for the source address
1. If yes, packet is forwarded on all
outgoing interfaces
2. If no, packet is dropped
3. Leaf router checks if it has knowledge of
any group members (with IGMP)
1. If members, the packet is forwarded
2. No members, “prune”-message is sent
back to source on RPF interface
4. All “prune”-packets forwarded to source.
Each router in path updates its state.
Router sends “prune”-message if it
receives “prune”-messages on all incoming
non-RPF interfaces
Source: “The Evolution of Multicast: From the MBone to Interdomain Multicast to Internet2 Deployment", K.C. Almeroth,
IEEE Network, January/February 2000
11 March 2016 | 19
DVMRP – Animation 2.2
Main features
Router
Source
Multicast
packet
Prune
packet
Leaf (nonmulticast)
Main steps
Leaf
(multicast)
1. Source broadcasts data packet on local
network. Attached routers forwards it on
all outgoing interfaces
2. Each router performs a reversed path
forwarding (RPF) check. Router checks
incoming packet is on its outgoing
interface for the source address
1. If yes, packet is forwarded on all
outgoing interfaces
2. If no, packet is dropped
3. Leaf router checks if it has knowledge of
any group members (with IGMP)
1. If members, the packet is forwarded
2. No members, “prune”-message is sent
back to source on RPF interface
4. All “prune”-packets forwarded to source.
Each router in path updates its state.
Router sends “prune”-message if it
receives “prune”-messages on all incoming
non-RPF interfaces
Source: “The Evolution of Multicast: From the MBone to Interdomain Multicast to Internet2 Deployment", K.C. Almeroth,
IEEE Network, January/February 2000
11 March 2016 | 20
DVMRP – Animation 3
Main features
Router
Source
Multicast
packet
Prune
packet
Leaf (nonmulticast)
IGMP
IGMP
IGMP
Main steps
Leaf
(multicast)
1. Source broadcasts data packet on local
network. Attached routers forwards it on
all outgoing interfaces
2. Each router performs a reversed path
forwarding (RPF) check. Router checks
incoming packet is on its outgoing
interface for the source address
1. If yes, packet is forwarded on all
outgoing interfaces
2. If no, packet is dropped
3. Leaf router checks if it has knowledge of
any group members (with IGMP)
1. If members, the packet is forwarded
2. No members, “prune”-message is sent
back to source on RPF interface
4. All “prune”-packets forwarded to source.
Each router in path updates its state.
Router sends “prune”-message if it
receives “prune”-messages on all incoming
non-RPF interfaces
Source: “The Evolution of Multicast: From the MBone to Interdomain Multicast to Internet2 Deployment", K.C. Almeroth,
IEEE Network, January/February 2000
11 March 2016 | 21
DVMRP – Animation 3.1
Main features
Router
Source
Multicast
packet
Prune
packet
Leaf (nonmulticast)
Main steps
Leaf
(multicast)
1. Source broadcasts data packet on local
network. Attached routers forwards it on
all outgoing interfaces
2. Each router performs a reversed path
forwarding (RPF) check. Router checks
incoming packet is on its outgoing
interface for the source address
1. If yes, packet is forwarded on all
outgoing interfaces
2. If no, packet is dropped
3. Leaf router checks if it has knowledge of
any group members (with IGMP)
1. If members, the packet is forwarded
2. No members, “prune”-message is sent
back to source on RPF interface
4. All “prune”-packets forwarded to source.
Each router in path updates its state.
Router sends “prune”-message if it
receives “prune”-messages on all incoming
non-RPF interfaces
Source: “The Evolution of Multicast: From the MBone to Interdomain Multicast to Internet2 Deployment", K.C. Almeroth,
IEEE Network, January/February 2000
11 March 2016 | 22
DVMRP – Animation 3.2
Main features
Router
Source
Multicast
packet
Prune
packet
Leaf (nonmulticast)
I
I
Main steps
Leaf
(multicast)
1. Source broadcasts data packet on local
network. Attached routers forwards it on
all outgoing interfaces
2. Each router performs a reversed path
forwarding (RPF) check. Router checks
incoming packet is on its outgoing
interface for the source address
1. If yes, packet is forwarded on all
outgoing interfaces
2. If no, packet is dropped
3. Leaf router checks if it has knowledge of
any group members (with IGMP)
1. If members, the packet is forwarded
2. No members, “prune”-message is sent
back to source on RPF interface
4. All “prune”-packets forwarded to source.
Each router in path updates its state.
Router sends “prune”-message if it
receives “prune”-messages on all incoming
non-RPF interfaces
Source: “The Evolution of Multicast: From the MBone to Interdomain Multicast to Internet2 Deployment", K.C. Almeroth,
IEEE Network, January/February 2000
11 March 2016 | 23
DVMRP – Animation 4
Main features
Router
Source
Multicast
packet
Prune
packet
I’
Leaf (nonmulticast)
Main steps
Leaf
(multicast)
1. Source broadcasts data packet on local
network. Attached routers forwards it on
all outgoing interfaces
2. Each router performs a reversed path
forwarding (RPF) check. Router checks
incoming packet is on its outgoing
interface for the source address
1. If yes, packet is forwarded on all
outgoing interfaces
2. If no, packet is dropped
3. Leaf router checks if it has knowledge of
any group members (with IGMP)
1. If members, the packet is forwarded
2. No members, “prune”-message is sent
back to source on RPF interface
4. All “prune”-packets forwarded to source.
Each router in path updates its state.
Router sends “prune”-message if it
receives “prune”-messages on all incoming
non-RPF interfaces
Source: “The Evolution of Multicast: From the MBone to Interdomain Multicast to Internet2 Deployment", K.C. Almeroth,
IEEE Network, January/February 2000
11 March 2016 | 24
DVMRP – Final multicast tree
Main features
Router
Source
Leaf
(multicast)
Main steps
Multicast
tree
1. Source broadcasts data packet on local
network. Attached routers forwards it on
all outgoing interfaces
2. Each router performs a reversed path
forwarding (RPF) check. Router checks
incoming packet is on its outgoing
interface for the source address
1. If yes, packet is forwarded on all
outgoing interfaces
2. If no, packet is dropped
3. Leaf router checks if it has knowledge of
any group members (with IGMP)
1. If members, the packet is forwarded
2. No members, “prune”-message is sent
back to source on RPF interface
4. All “prune”-packets forwarded to source.
Each router in path updates its state.
Router sends “prune”-message if it
receives “prune”-messages on all incoming
non-RPF interfaces
Source: “The Evolution of Multicast: From the MBone to Interdomain Multicast to Internet2 Deployment", K.C. Almeroth,
IEEE Network, January/February 2000
11 March 2016 | 25
PIM-SM (PIM-sparse mode) use “explicit join” approach to
build the multicast tree
Main features
Protocol
mode
Tree type
Dense mode Sparse mode

Shortest path
Other



Rendezvous point (RP)
Protocol independent
Explicit join
Similar protocols

CBT
Main steps
Shared

1. RP must be configured. Different
groups can have different routers
for RP, but a single group can only
have one. Bootstrap protocol to
discover all RP routers in the
network
2. Receivers send explicit join
messages to the RP. Forwarding
state is created in each router along
the path from the receiver to the RP
3. Each source sends multicast data
packets to the RP. When a RP
receives a package it can:
1. Packet can be stripped and sent
to the shared tree
2. RP sends a register-stop message
to the other RP
4. RP establishes multicast forwarding
state between itself and the source
Source: “The Evolution of Multicast: From the MBone to Interdomain Multicast to Internet2 Deployment", K.C. Almeroth,
IEEE Network, January/February 2000
11 March 2016 | 26
Animation 1
Main steps
Main features
Router
Multicast
packet
Source
Leaf (nonmulticast)
Rendezvous Point (RP)
Leaf
(multicast)
1. RP must be configured. Different
groups can have different routers
for RP, but a single group can only
have one. Bootstrap protocol to
discover all RP routers in the
network
2. Receivers send explicit join
messages to the RP. Forwarding
state is created in each router along
the path from the receiver to the RP
3. Each source sends multicast data
packets to the RP. When a RP
receives a package it can:
1. Packet can be stripped and sent
to the shared tree
2. RP sends a register-stop message
to the other RP
4. RP establishes multicast forwarding
state between itself and the source
Source: “The Evolution of Multicast: From the MBone to Interdomain Multicast to Internet2 Deployment", K.C. Almeroth,
IEEE Network, January/February 2000
11 March 2016 | 27
Animation 2
Main steps
Main features
Router
Multicast
packet
Source
Leaf (nonmulticast)
Rendezvous Point (RP)
Leaf
(multicast)
1. RP must be configured. Different
groups can have different routers
for RP, but a single group can only
have one. Bootstrap protocol to
discover all RP routers in the
network
2. Receivers send explicit join
messages to the RP. Forwarding
state is created in each router along
the path from the receiver to the RP
3. Each source sends multicast data
packets to the RP. When a RP
receives a package it can:
1. Packet can be stripped and sent
to the shared tree
2. RP sends a register-stop message
to the other RP
4. RP establishes multicast forwarding
state between itself and the source
Source: “The Evolution of Multicast: From the MBone to Interdomain Multicast to Internet2 Deployment", K.C. Almeroth,
IEEE Network, January/February 2000
11 March 2016 | 28
Animation 3
Main steps
Main features
Router
Multicast
packet
Source
Leaf (nonmulticast)
Rendezvous Point (RP)
Leaf
(multicast)
1. RP must be configured. Different
groups can have different routers
for RP, but a single group can only
have one. Bootstrap protocol to
discover all RP routers in the
network
2. Receivers send explicit join
messages to the RP. Forwarding
state is created in each router along
the path from the receiver to the RP
3. Each source sends multicast data
packets to the RP. When a RP
receives a package it can:
1. Packet can be stripped and sent
to the shared tree
2. RP sends a register-stop message
to the other RP
4. RP establishes multicast forwarding
state between itself and the source
Source: “The Evolution of Multicast: From the MBone to Interdomain Multicast to Internet2 Deployment", K.C. Almeroth,
IEEE Network, January/February 2000
11 March 2016 | 29
Animation 4
Main steps
Main features
Router
Multicast
packet
Source
Leaf (nonmulticast)
Rendezvous Point (RP)
Leaf
(multicast)
1. RP must be configured. Different
groups can have different routers
for RP, but a single group can only
have one. Bootstrap protocol to
discover all RP routers in the
network
2. Receivers send explicit join
messages to the RP. Forwarding
state is created in each router along
the path from the receiver to the RP
3. Each source sends multicast data
packets to the RP. When a RP
receives a package it can:
1. Packet can be stripped and sent
to the shared tree
2. RP sends a register-stop message
to the other RP
4. RP establishes multicast forwarding
state between itself and the source
Source: “The Evolution of Multicast: From the MBone to Interdomain Multicast to Internet2 Deployment", K.C. Almeroth,
IEEE Network, January/February 2000
11 March 2016 | 30
Agenda
Historic perspective on multicast
Layer dependent deployment
Types of IP multicast
Intradomain multicast
Interdomain multicast
Future perspective
11 March 2016 | 31
MBones with limited usage, current best solution is
a family of protocols (PIM-SM/MBGP/MSDP)
MBone today

Still used to some degree

MBone as its own Autonomous
System (AS) placed at NASA


Goal is to move sites on the MBone
to native multicast
Remove old MBone tunnels
Replacement

Transition from Mbones flat
topology to a true Interdomain
infrastructure

Multicast-friendly Internet
exchange (MIX) at NASA

Interdomain multicast now
possible

PIM-SM/MBGP/MSDP is currently
the best solution
Source: The Evolution of Multicast: From the MBone to Interdomain Multicast to Internet2 Deployment", K.C. Almeroth, IEEE
Network, January/February 2000
11 March 2016 | 32
MSDP solves problems with interdomain RP discovery
Main features
1. New sources register with the domain`s
RP
Leaf node
Rendezvous
Point
Routers
2. MSDP detect new sources and sends SA
message to all peers
3. MSDP peers that receives SA performs RPF
checks to prevent looping of SA message
4. Within a domain, the RP checks if it has
state for group members and sends PIM
join message to the source
AS 2
AS 1
5. If message contains data, the RP forwards
the message to the multicast tree
AS 3
6. Steps 3-5 are repeated until all MSDP peers
have received the SA message and all
group members are receiving data from
the source
Source: “The Evolution of Multicast: From the MBone to Interdomain Multicast to Internet2 Deployment", K.C. Almeroth,
IEEE Network, January/February 2000
Note: MSDP = Multicast Source Discovery pProtocol
11 March 2016 | 33
Long-term multicast aims at improving
current solution with experimental protocols
Long-term
Standard IP
Separate solution
Protocols
BGMP, MASC, GLOP
RAMA protocols: Express multicast,
Simple multicast
Goals
Proposals to solve the problem with
address allocation
Proposals to change the standard
multicast model to simplify the
problem
Future long-term solutions are based more on political
founding than scientific advances
Source: “The Evolution of Multicast: From the MBone to Interdomain Multicast to Internet2 Deployment", K.C. Almeroth,
IEEE Network, January/February 2000
11 March 2016 | 34
Agenda
Historic perspective on multicast
Layer dependent deployment
Types of IP multicast
Future perspective
11 March 2016 | 35
Interdomain multicast with high importance as number of AS
and share/rate of IP Video traffic are increasing
Number of AS
Traffic by Application category
Number of ASN registered by year
RIPE
ARIN
APNIC
LACNIC
Number of Exabyte per month by year, forecast 15’-19
Internet video
Web/Data
AFRINCI
IP VoD
Gaming
File sharing
CAGR 14’-19’
80000
23%
200
Forecast
60000
35%
15%
1%
14%
150
CAGR 05’-15’
12%
40000
20000
33%
50
0
0
2014
2015
2016
2017
2018
IP Video
100
2019
Interdomain multicast will dominate the future
Sources: afrinic.net, apnic.net, arin.net, lacnic.net, ripe.net. All sources updated as of 01.03.2016, Cisco “ The Zettabyte Era:
Trends and Analysis, May 2015
Note: ASN = Autonomous System Number, CAGR = Compounded Annual Growth
11 March 2016 | 36
Questions?
11 March 2016 | 37