Broadcast%20Internetworking

1
Broadcast Internetworking

• An architecture for bridging multicast/broadcast-c
  apable networks

Yatin Chawathe yatin_at_research.att.com
Mukund Seshadri mukunds_at_cs.berkeley.edu
Jan 2002
2
Motivation
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.

• 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.

3
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 multicast-style algorithms.
• Analogous to BGP routers.
• App-level, for protocol-independence
• Leverage solutions for availability and
  scalability
• Less efficient link usage, and more delay
• Inefficient processing

Clients
BG
BN
Peering
Data
4
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

5
Routing

• Same principles as BGP
• Path vector algorithm to propagate BG
  reachability info
• Scope for forwarding policy hooks
• The metric for cost determines the routes chosen
• 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.

6
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
• 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
(S1LP2)
P2
P2
C1 JOINs
(S1P1L,P3)
C2 JOINs
P3
P3
(S1P2P4)
(S1P3L)
L Local Multicast/Broadcast Interface
C2
Client/BiN Mediator
7
SROUTE-- Session specific cost in the owner BN.
Source

• All BGs in the owner BN know all SROUTEs for
  owned sessions.
• An SROUTE-Request to a BG in the owner BN elicits
  an SROUTE-Response, containing all the SROUTEs.
• Downstream BGs can cache this value to reduce
  SROUTE traffic.
• Downstream BG(s) compute best target BG in the
  owner BN and send JOINs towards that BG.
• 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
8
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.
• 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.
• Local session names are in TRANSLATION strings -
  interpreted only by the Local Broadcast Interface

(S1LP2)
P1
UDPIP2,Port2
UDPIP1,Port1
(S1P1L)
P2
IPMIPm1,Portm1
IPMNull
C1
IPMNull
P3
IPMIPm1,Portm1
9
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 (e.g. SRM local recovery)