Transcript ppt

Broadcast Internetworking
An architecture for bridging
multicast/broadcast-capable
networks
Yatin Chawathe
[email protected]
Mukund Seshadri
[email protected]
Jan 2002
Goal

Design an inter-domain multicast architecture
for the composition of different, non-interoperable multicast/broadcast
domains to provide an end-to-end multicast service.
Motivation


One-to-many or many-to-many (broadcast) applications are important
No universally deployed multicast protocol.


e.g. IP Multicast, SSM, Overlays, CDNs
Typical problems

Address-space scarcity (in IP Multicast)

Limited scalability


e.g. IP Multicast involves some form of flooding
Need for administrative boundaries.
Architecture
Source


Broadcast Network (BN) – any
multicast capable network/domain/CDN)
Broadcast Gateway (BG)
 Bridge between 2 BNs
 Pre-configured peering
relationship
 BGs run overlay multicaststyle algorithms.
 Analogous to BGP routers.


X
X
App-level, for protocolindependence
Leverage solutions for availability
and scalability
Less efficient link usage, and
more delay
Inefficient processing
Clients
BG
BN
Peering
Data
Naming

A session is associated with a unique Owner BN –



For shared tree protocols
Address space limited only by individual BNs’ naming protocols.
URL style-
bin://Owner_BN/native_session_name?pmtr=value...


native_session_name - specific to the owner BN
pmtr – metrics of interest (latency, bandwidth, etc.)
BIN Mediator
(an abstraction)
How does a client tell a BG that it wants to join a session?


A BG in a non-owner BN needs to be sent a JOIN message.
BNs are required to implement the BIN-Mediator, for sending JOINs for
sessions.



Modified clients which send JOIN to BGs
Static pre-configured JOIN at the BG
Routers or other BN-specific aggregators
Routing

Same principles as BGP



The metric for cost determines the routes chosen


Path – vector algorithm to propagate BG reachability info
Scope for forwarding policy hooks
e.g. latency, bandwidth, BN-hop-count
Session-agnostic, in order to avoid all BNs knowing about all
sessions.
Routing Implementation




TCP used for routing exchanges.
Incremental updates
Route changes are propagated immediately
BG peering within a BN is constrained: Set of internal peering
relationships should form a clique.
Distribution Trees
One tree per session, reverse shortest path-tree rooted at
owner BN.
BG tree state:(Session: Upstream node: list of downstream nodes)
Bidirectional



X


Non-optimal paths for sources not in owner BN
Avoids potentially large wide area latencies in sending data to the root.
Reduces 3rd party dependencies.
Source
P1
P1
P1 (S1:L:P2)
P2
C1 JOINs
P3
P2
P2
C2 JOINs
(S1:P1:L)
P3
(S1:L:P2)
C1
(S1:P1:L,P3)
P3
(S1:P2:P4)
JOIN
TRANSLATION
L
Local Multicast/Broadcast Interface
Client/BiN Mediator
(S1:P3:L)
C2
SROUTE
Source
-- Session specific cost in the owner BN.


All BGs in the owner BN know all
SROUTEs for owned sessions.
An SROUTE-Request to a BG in the
owner BN elicits an SROUTEResponse, containing all the
SROUTEs.


Downstream BG(s) compute best
target BG in the owner BN and send
JOINs towards that BG.


Downstream BGs can cache this value
to reduce SROUTE traffic.
JOINs contain SROUTEs received
earlier.
Increases initial setup latency, but
reduces propagation of session info to
disinterested BNs.
JOIN
SROUTE-Request
SROUTE-Response
REDIRECT
TRANSLATION
Data Paths

TRANSLATION messages carry
data path addresses per session



e.g. a transit SSM network might
require 2+ channels to be setup for
one session.
Label negotiation, for fast
forwarding.
P1
UDP:IP2,Port2
Local Broadcast Interface




Send and Receive multicast data
Allocate and reclaim local multicast
addresses
Subscribe to and unsubscribe from
local multicast sessions
Get SROUTE values.
(S1:L:P2)
UDP:IP1,Port1
P2 (S1:P1:L)
IPM:IPm1,Portm1
IPM:Null
C1
IPM:Null
P3
IPM:IPm1,Portm1
Local session names are in
TRANSLATION strings - interpreted
only by the Local Broadcast
Interface
JOIN
TRANSLATION
Preliminary Results




With Rate-limited Server--
Event driven, user-level
program
Best-effort forwarding
Deployed in 13-machine
testbed
Used simple HTTP-based
CDN (servers) in each BN
Future Work
With Rate-unlimited Server-

Performance improvement
(e.g. faster forwarding)
More Performance evaluation


Scalability in number of domains
– simulations?
Transport-layer modules
local recovery)
(e.g. SRM