7.4.9
The MBone—The Multicast Backbone
While all these industries are
making great—and highly publicized—plans for future (inter)national digital
video on demand, the Internet community has been quietly implementing its own
digital multimedia system, MBone (Multicast Backbone). In this section we will
give a brief overview of what it is and how it works.
MBone can be thought of as Internet
television. Unlike video on demand, where the emphasis is on calling up and
viewing precompressed movies stored on a server, MBone is used for broadcasting
live video in digital form all over the world via the Internet. It has been
operational since early 1992. Many scientific conferences, especially IETF
meetings, have been broadcast, as well as newsworthy scientific events, such as
space shuttle launches. A Rolling Stones concert was once broadcast over MBone
as were portions of the Cannes Film Festival. Whether this qualifies as a
newsworthy scientific event is arguable.
Technically, MBone is a virtual
overlay network on top of the Internet. It consists of multicast-capable
islands connected by tunnels, as shown in Fig. 7-81. In this figure, MBone consists of six
islands, A through F, connected by seven tunnels. Each island (typically a LAN
or group of interconnected LANs) supports hardware multicast to its hosts. The
tunnels propagate MBone packets between the islands. Some day in the future,
when all the routers are capable of handling multicast traffic directly, this
superstructure will no longer be needed, but for the moment, it does the job.
Each island contains one or more
special routers called mrouters (multicast routers). Some of these are actually
normal routers, but most are just UNIX workstations running special user-level
software (but as the root). The mrouters are logically connected by tunnels.
MBone packets are encapsulated within IP packets and sent as regular unicast
packets to the destination mrouter's IP address.
Tunnels are configured manually.
Usually, a tunnel runs above a path for which a physical connection exists, but
this is not a requirement. If, by accident, the physical path underlying a
tunnel goes down, the mrouters using the tunnel will not even notice it, since
the Internet will automatically reroute all the IP traffic between them via
other lines.
When a new island appears and wishes
to join MBone, such as G in Fig. 7-81, its administrator sends a message
announcing its existence to the MBone mailing list. The administrators of
nearby sites then contact him to arrange to set up tunnels. Sometimes existing
tunnels are reshuffled to take advantage of the new island to optimize the
topology. After all, tunnels have no physical existence. They are defined by
tables in the mrouters and can be added, deleted, or moved simply by changing
these tables. Typically, each country on MBone has a backbone, with regional
islands attached to it. Normally, MBone is configured with one or two tunnels
crossing the Atlantic and Pacific oceans, making MBone global in scale.
Thus, at any instant, MBone consists
of a specific topology consisting of islands and tunnels, independent of the
number of multicast addresses currently in use and who is listening to them or
watching them. This situation is very similar to a normal (physical) subnet, so
the normal routing algorithms apply to it. Consequently, MBone initially used a
routing algorithm, DVMRP (Distance Vector Multicast Routing Protocol) based on
the Bellman-Ford distance vector algorithm. For example, in Fig. 7-81, island C can route to A either via B
or via E (or conceivably via D). It makes its choice by taking the values those
nodes give it about their respective distances to A and then adding its
distance to them. In this way, every island determines the best route to every
other island. The routes are not actually used in this way, however, as we will
see shortly.
Now let us consider how multicasting
actually happens. To multicast an audio or video program, a source must first
acquire a class D multicast address, which acts like a station frequency or
channel number. Class D addresses are reserved by a program that looks in a
database for free multicast addresses. Many multicasts may be going on at once,
and a host can ''tune'' to the one it is interested in by listening to the
appropriate multicast address.
Periodically, each mrouter sends out
an IGMP broadcast packet limited to its island asking who is interested in
which channel. Hosts wishing to (continue to) receive one or more channels send
another IGMP packet back in response. These responses are staggered in time, to
avoid overloading the local LAN. Each mrouter keeps a table of which channels
it must put out onto its LAN, to avoid wasting bandwidth by multicasting
channels that nobody wants.
Multicasts propagate through MBone
as follows. When an audio or video source generates a new packet, it multicasts
it to its local island, using the hardware multicast facility. This packet is
picked up by the local mrouter, which then copies it into all the tunnels to
which it is connected.
Each mrouter getting such a packet
via a tunnel then checks to see if the packet came along the best route, that
is, the route that its table says to use to reach the source (as if it were a
destination). If the packet came along the best route, the mrouter copies the
packet to all its other tunnels. If the packet arrived via a suboptimal route,
it is discarded. Thus, for example, in Fig. 7-81, if C's tables tell it to use B to get
to A, then when a multicast packet from A reaches C via B, the packet is copied
to D and E. However, when a multicast packet from A reaches C via E (not the
best path), it is simply discarded..
In addition to using reverse path
forwarding to prevent flooding the Internet, the IP Time to live field is also
used to limit the scope of multicasting. Each packet starts out with some value
(determined by the source). Each tunnel is assigned a weight. A packet is
passed through a tunnel only if it has enough weight. Otherwise it is
discarded. For example, transoceanic tunnels are normally configured with a
weight of 128, so packets can be limited to the continent of origin by being
given an initial Time to live of 127 or less. After passing through a tunnel,
the Time to live field is decremented by the tunnel's weight.
While the MBone routing algorithm
works, much research has been devoted to improving it. One proposal keeps the
idea of distance vector routing, but makes the algorithm hierarchical by
grouping MBone sites into regions and first routing to them (Thyagarajan and
Deering, 1995).
Another proposal is to use a
modified form of link state routing instead of distance vector routing. In
particular, an IETF working group modified OSPF to make it suitable for
multicasting within a single autonomous system. The resulting multicast OSPF is
called MOSPF (Moy, 1994). What the modifications do is have the full map built
by MOSPF keep track of multicast islands and tunnels, in addition to the usual
routing information. Armed with the complete topology, it is straightforward to
compute the best path from every island to every other island using the
tunnels. Dijkstra's algorithm can be used, for example.
A second area of research is
inter-AS routing. Here an algorithm called PIM (Protocol Independent Multicast)
was developed by another IETF working group. PIM comes in two versions,
depending on whether the islands are dense (almost everyone wants to watch) or
sparse (almost nobody wants to watch). Both versions use the standard unicast
routing tables, instead of creating an overlay topology as DVMRP and MOSPF do.
In PIM-DM (dense mode), the idea is
to prune useless paths. Pruning works as follows. When a multicast packet
arrives via the ''wrong'' tunnel, a prune packet is sent back through the
tunnel telling the sender to stop sending it packets from the source in
question. When a packet arrives via the ''right'' tunnel, it is copied to all
the other tunnels that have not previously pruned themselves. If all the other
tunnels have pruned themselves and there is no interest in the channel within
the local island, the mrouter sends a prune message back through the ''right''
channel. In this way, the multicast adapts automatically and only goes where it
is wanted.
PIM-SM (spare mode), described in
RFC 2362, works differently. The idea here is to prevent saturating the
Internet because three people in Berkeley want to hold a conference call over a
class D address. PIM-SM works by setting up rendezvous points. Each of the
sources in a PIM-SM multicast group send their packets to the rendezvous
points. Any site interested in joining up asks one of the rendezvous points to
set up a tunnel to it. In this way, all PIM-SM traffic is transported by
unicast instead of by multicast. PIM-SM is becoming more popular, and the MBone
is migrating toward its use. As PIM-SM becomes more widely used, MOSPF is
gradually disappearing. On the other hand, the MBone itself seems to be
somewhat stagnant and will probably never catch on in a big way.
Nevertheless,
networked multimedia is still an exciting and rapidly moving field, even if the
MBone does not become a huge success. New technologies and applications are
announced daily. Increasingly, multicasting and quality of service are coming
together, as discussed in (Striegel and Manimaran, 2002). Another hot topic is
wireless multicast (Gossain et al., 2002). The whole area of multicasting and
everything related to it are likely to remain important for years to come.
No comments:
Post a Comment
silahkan membaca dan berkomentar