For those of you who would like to know more about Multicasting then here
is the MBONE faq file. It has got lots of hints on how to get started
and where to pick up free software for video conferencing, and tells you
how to tune in to broadcasts on the net... experimental stuff, but very
interesting.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% CLIP %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Frequently Asked Questions (FAQ) on the Multicast Backbone (MBONE)
------------------------------------------------------------------
Steve Casner, casner at isi.edu, 16-Jan-93
*** This file is venera.isi.edu:mbone/faq.txt ***
*** Corrections and Additions Requested ***
* What is the MBONE?
The MBONE is an outgrowth of the first two IETF "audiocast"
experiments in which live audio and video were multicast from the
IETF meeting site to destinations around the world. The idea is
to construct a semi-permanent IP multicast testbed to carry the
IETF transmissions and support continued experimentation between
meetings. This is a cooperative, volunteer effort.
The MBONE is a virtual network. It is layered on top of portions
of the physical Internet to support routing of IP multicast
packets since that function has not yet been integrated into many
production routers. The network is composed of islands that can
directly support IP multicast, such as multicast LANs like
Ethernet, linked by virtual point-to-point links called "tunnels".
The tunnel endpoints are typically workstation-class machines
having operating system support for IP multicast and running the
"mrouted" multicast routing daemon.
* How do IP multicast tunnels work?
IP multicast packets are encapsulated for transmission through
tunnels, so that they look like normal unicast datagrams to
intervening routers and subnets. Currently, the encapsulation
takes the form of source routing. The multicast router modifies
the packet by appending an IP Loose Source Route option to the
packet's IP header. The multicast destination address is moved
into the source route, and the unicast address of the router at
the far end of the tunnel is placed in the IP Destination Address
field. Thus, normal unicast routing carries the packet to the
other end of the tunnel where the multicast router restores the
original multicast destination address and deletes the source
route before forwarding the packet.
The presence of the IP LSR option may cause modern router hardware
to divert the tunnel packets through a slower software processing
path, causing poor performance. Therefore, the tunneling
mechanism will soon be changed to use true IP encapsulation in
which an additional IP header is prepended with the source and
destination addresses of the endpoints of the tunnel, then
stripped at the other end. For backward compatibility, both
methods of tunnel encapsulation could coexist on separate tunnels.
* What is the topology of the MBONE?
We anticipate that within a continent, the MBONE topology will be
a combination of mesh and star: the backbone and regional (or
mid-level) networks will be linked by a mesh of tunnels among
mrouted machines located primarily at interconnection points of
the backbones and regionals. Some redundant tunnels may be
configured with higher metrics for robustness. Then each regional
network will have a star hierarchy hanging off its node of the
mesh to fan out and connect to all the customer networks that want
to participate.
Between continents there will probably be only one or two tunnels,
preferably terminating at the closest point on the MBONE mesh. In
the US, this may be on the Ethernets at the two FIXes (Federal
Internet eXchanges) in California and Maryland. But since the
FIXes are fairly busy, it will be important to minimize the number
of tunnels that cross them. This may be accomplished using IP
multicast directly (rather than tunnels) to connect several
multicast routers on the FIX Ethernet.
* How is the MBONE topology going to be set up and coordinated?
The primary reason we set up the MBONE e-mail lists (see below)
was to coordinate the top levels of the topology (the mesh of
links among the backbones and regionals). This must be a
cooperative project combining knowledge distributed among the
participants, somewhat like Usenet. The goal is to avoid loading
any one individual with the responsibility of designing and
managing the whole topology, though perhaps it will be necessary
to periodically review the topology to see if corrections are
required.
The intent is that when a new regional network wants to join in,
they will make a request on the appropriate MBONE list, then the
participants at "close" nodes will answer and cooperate in setting
up the ends of the appropriate tunnels. To keep fanout down,
sometimes this will mean breaking an existing tunnel to inserting
a new node, so three sites will have to work together to set up
the tunnels.
To know which nodes are "close" will require knowledge of both the
MBONE logical map and the underlying physical network topology,
for example, the physical T3 NSFnet backbone topology map combined
with the network providers' own knowledge of their local topology.
Within a regional network, the network's own staff can
independently manage the tunnel fanout hierarchy in conjunction
with end-user participants. New end-user networks should contact
the network provider directly, rather than the MBONE list, to get
connected.
* What is the anticipated traffic level?
The traffic anticipated during IETF multicasts is 100-300Kb/s, so
500Kb/s seems like a reasonable design bandwidth. Between IETF
meetings, most of the time there will probably be no audio or
video traffic, though some of the background session/control
traffic may be present. A guess at the peak level of experimental
use might be 5 simultaneous voice conversations (64Kb/s each).
Clearly, with enough simultaneous conversations, we could exceed
any bandwidth number, but 500Kb/s seems reasonable for planning.
Note that the design bandwidth must be multiplied by the number of
tunnels passing over any given link since each tunnel carries a
separate copy of each packet. This is why the fanout of each
mrouted node should be no more than 5-10 and the topology should
be designed so that at most 1 or 2 tunnels flow over any T1 line.
While most MBONE nodes should connect with lines of at least T1
speed, it will be possible to carry restricted traffic over slower
speed lines. Each tunnel has an associated threshold against
which the packet's IP time-to-live (TTL) value is compared. By
convention in the IETF multicasts, higher bandwidth sources such
as video transmit with a smaller TTL so they can be blocked while
lower bandwidth sources such as compressed audio are allowed
through.
* Why should I (a network provider) participate?
To allow your customers to participate in IETF audiocasts and
other experiments in packet audio/video, and to gain experience
with IP multicasting for a relatively low cost.
* What technical facilities and equipment are required for a network
provider to join the MBONE?
Each network-provider participant in the MBONE provides one or
more IP multicast routers to connect with tunnels to other
participants and to customers. The multicast routers are
typically separate from a network's production routers since most
production routers don't yet support IP multicast. Most sites use
workstations running the mrouted program, but the experimental
MOSPF software for Proteon routers is an alternative (see MOSPF
question below).
It is best if the workstations can be dedicated to the multicast
routing function to avoid interference from other activities and
so there will be no qualms about installing kernel patches or new
code releases on short notice. Since most MBONE nodes other than
endpoints will have at least three tunnels, and each tunnel
carries a separate (unicast) copy of each packet, it is also
useful, though not required, to have multiple network interfaces
on the workstation so it can be installed parallel to the unicast
router for those sites with configurations like this:
+----------+
| Backbone |
| Node |
+----------+
|
------------------------------------------ External DMZ Ethernet
| |
+----------+ +----------+
| Router | | mrouted |
+----------+ +----------+
| |
------------------------------------------ Internal DMZ Ethernet
(The "DMZ" Ethernets borrow that military term to describe their
role as interface points between networks and machines controlled
by different entities.) This configuration allows the mrouted
machine to connect with tun
