Video Conferencing & Collaborative SW...slick stuff!

Rob Harper harper at convex.csc.FI
Mon Mar 8 07:48:05 EST 1993

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

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 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

    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

* 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

* 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

More information about the Bio-soft mailing list

Send comments to us at biosci-help [At] net.bio.net