[Live-devel] Multicast streams, SSM and Bidir

[John M. Zwiebel]

This is 2 cents from a router vendor...
It has nothing to do with streaming other than how those streams
are delivered via multicast.  You should care if you are developing
on an OS that does not support IGMPv3 or if you are planning on
doing IPv6 streaming.

If you are doing multicast, over the past 10 years we've moved away
from dense-mode to sparse-mode and 3 years ago, we recognized that
ASM (any source multicast) which can roughly be thought of as the
same thing as PIM-SM (sparse mode) was just not going to work in
high-end routers because of the huge resource requirements to handle
all the data-driven events.  (Actually, for at least 9 years every
IETF has bemoaned the fact that there is no RTS/CTS mechanism for
alerting the network that a multicast stream is about to be sent.)

RFC1112 suggests that the network "just handle it" when it sees a
multicast packet.  In turn this means that source discovery has had
to be accomplished in the network, which is what the PIM register
mechanism is all about.  I'm starting a Don Quixote campaign to tell 
you,
the users, that even though ASM works and appears to work well, if
we really want to achieve a multicast deployment where we can handle
100,000+ routes (sources) of HDTV quality streams, no router vendor
is going to be able to support this without throwing lots of expensive
processing power into their systems (For example Juniper currently
requires an extra PIC, or line card, to specifically handle PIM source
registration -- Note that this card is also used for other things
so I'm not trying to say that the PIC itself is a bad thing, just
that ASM requires this card and so ASM is a "bad thing".)

To reach its full potential Multicast must remove the data-driven
events from the protocols and must determine ways of nailing up
routes -before- the source starts sending any data.  (The alternative
will be to require sources to send a series of "preamble" packets that
install the routes before the "real" data is sent.  I should note that
if we are talking about a video stream, the loss of 5 seconds at the
start of the stream may not matter, but I'm not in a position to
judge that loss.  I am sure that it will matter for other applications
meaning multicast protocols will dump ASM so you need to be aware of
the alternatives.)

There are two alternatives to ASM: SSM and Bidir.  Both of these use
the basics of the current PIM-SM protocol and make subtle, fairly
easy to implement, changes to the protocol.

SSM, source specific multicast (sometimes referred to as single-source
multicast) can be realized by making changes only on the last-hop router
and the receiving host.  Many streaming applications I'm aware of 
already
download sdp files to the application which specifies both the source 
and
the multicast group that the source is going to send to.  This source
group combination or (S,G) is referred to as a channel.  The beauty of 
SSM
is that source discovery is removed from the network and put into a 
service
that can be easily defined by the application developer.  Now all that 
remains
is for the receiver to signal the router the channel desired.

Unfortunately, this signal is accomplished through IGMPv3.  Although 
every
major router vendor has implemented IGMPv3, there are many OSs which do 
not
support it.  (MacOS, for example, perhaps because the FreeBSD community 
has been
unable to get past their nicene squabbles about which implementation is 
better or
maybe its because the folks who put a lot of effort into IGMPv3 haven't 
seen
it take off.)  Windows does support IGMPv3. Linux sometimes supports 
IGMPv3.

Once the receiver has passed the channel request to the last-hop 
router, a
PIM JOIN message is sent on the shortest-path tree and nailed up -- 
before any
packets are sourced.  This is the same data path that ASM would have 
built, but
it is without having to deliver data to the PIM-RP for source 
discovery, without
having to establish a shared-tree, without having to switch from the 
shared-tree
to the shortest-path, without the routers having to deal with data 
driven events.

You, as an application developer, get a data path up more quickly and 
reliably.
Your network provider doesn't have to worry about data traveling around 
places
it doesn't need to go.  Your customer has a happy experience.  You get 
to have
the network replicate the data rather than having to have a huge server 
farm
to unicast to every customer that wants a tcp connection.  Its a huge 
win
all around.

Bidir, or Bi-directional PIM, builds shared-trees rather than shortest 
path trees.
This deployment requires upgrading the OS in all the routers so they 
support
PIM-DF (designated forwarder) election.  DF election is fairly simple 
to implement
and the three major router vendors have had it available for a while 
now.  Bidir
does not require any changes in the host receiver.  I can not imagine 
Bidir being
used for a streaming media application, therefore I will not bore you 
with too
many details.  However, if you have a many to many application -- 
perhaps distance-
learning -- Bidir may be the way to go.  Again, like SSM, the routes 
can be
nailed up -before- any data is sent.  Unlike ASM the Bidir RP does not 
do
anything except provide a point in the "internet space" that is the 
root of the
distribution tree.  Data travels up and down that tree.  There is no 
reason
that the Bidir RP couldn't be your application running on a primary 
server
somewhere.  (However, if you go this way, then some way of 
communicating this to
the network will have to be developed.  Router folks are probably going 
to leave
this up to the application folks since we don't know the direction your 
app
is going to take.  Although IPv6 has a proposal called "embed-RP" which 
may make
this useful.)

So, after all of this, what do you guys need to know.
   -- ASM is not going to scale to really huge numbers of sources or 
large BW, you need
	to move to SSM and/or Bidir
   -- SSM requires IGMPv3, you need to be pressuring your OS vendor for 
it
   -- Source discovery needs some kind of a standard directory.  Getting 
the sdp
	file off of a web page seems "good enough" to me, but I've heard lots 
of
	complaints especially from those who have been using ASM for a while.
   -- Think of opening up a channel rather than joining a group.  Design 
your app
	so you can "channel surf".
   -- Layer2 switches are going to be a problem.  I should have 
mentioned them.

Layer2 switches.  Bridges are dumb.  They only use the MAC address.  
Multicast
destinations are never sources so they can't figure out which port the 
multicast
packet is suppose to be sent out of so they send it out all ports.  
This is good
in that all the systems connected to the switch see the mpackets.  This 
is bad
in that all the systems connected to the switch see the mpackets.  Some 
switches
limit the ports the mpackets are forwarded out of by doing IGMP 
snooping.  Sadly
this is just limited to the destination or group address.  There is no 
such thing
as IGMPv3 snooping.  There are lots of protocols which are suppose to 
limit the
ports out which the mpackets are forwarded.  But they don't do a very 
good job
of it.  The only layer2 solution is called GARP.  It is roughly IGMP at 
layer 2.
Any system connected to the switch is suppose to send a GARP message 
instructing
the switch to forward multicast packets for a specific multicast MAC 
address to
this port.  Some router vendors have implemented this.  I do not know 
of any
host Operating Systems which have.

So, until there is a solution, make sure your switch will forward the 
mpackets.
And demand your switch vendor provide you with a solution.

Thanks for taking the time to read this.

John Zwiebel