Ip multicast overview, Satellite classroom example – ADTRAN Stub Routing User Manual

Page 2

Advertising
background image

IP Multicast Overview

IP Multicast Stub Routing in AOS

2

Copyright © 2005 ADTRAN, Inc.

61200890L1-29.3A

IP Multicast Overview

IP multicast has many applications, ranging from video and/or audio program delivery, music-on-hold for
an IP PBX, conferencing applications, and delivery of software updates, data, or other information to
multiple sites and/or devices. This document uses simple example applications to illustrate the various
components of IP multicast.

Satellite Classroom Example

The following example describes a one-to-many application and compares operation in a non-multicast
network to operation in a multicast network. This example is illustrated in Figure 1 on page 3.

A university has opened satellite classrooms in several towns across a large rural portion of the country,
providing local residents access to live classes. Satellite offices connect to the university backbone and
include a small LAN at each location. Students participate in classes using computers connected to the
satellite classroom LAN. Headsets are used since each student may be attending a different class. Classes
are conducted at scheduled times from the central university campus, and the live audio and video streams
are made available via the media server. To join a class, the student logs into a computer at the satellite
classroom and selects a URL, opening a media player and pointing it to the appropriate content on the
media server. The media server configures the media player for the content's stream format (CODECs,
etc.), preparing it to receive and play the selected content.

Satellite Classroom Application on a Non-Multicast Network

Referring to Figure 1 on page 3,

PC1

,

PC2

,

PC4

, and

PC6

have subscribed to the same classroom

broadcast. Since the network is not multicast-enabled, the

Media Server

must send a separate copy of the

content to the IP address of each PC. In this case, there are four copies of the content traversing the
network in four streams. The link from the

Media Server

to the

University Backbone

is a potential

bottleneck. In this backbone layout, the backbone path serving satellite sites 1 and 2 (

Satellite

Router 1/Satellite Router 2

) is another potential bottleneck. Notice that

PC1

and

PC2

are on the same

broadcast domain. Even though they are subscribed to the exact same content, that stream is transmitted
twice and consumes twice the bandwidth on that segment. This solution does not scale.

Advertising