Subject: multicast-transition

From: Dirk Ooms <[email-masked]>
Date: Mon, 05 Feb 2001 11:19:20 +0100

Hi all,

I was wondering whether anyone ever considered to apply techniques,
similar to the ones defined in ngtrans for ipv6, to ip multicast.  At
the moment one needs to configure static tunnels to connect to the MBone
over a non-multicast network.  Wouldn't it be good to investigate how
senders and/or receivers can hook up automatically to the MBone (without
the requirement of somebody in the MBone configuring a tunnel to your
network).

So, the concept of tunnel brokers might be useful: potential senders or
receivers can request a tunnel to a tunnel broker.  This requires some
boxes at the border of the MBone that are willing to
encapsulate/decapsulate, possibly take the role of DR (maybe one can
find broadcasters that want to sponsor such boxes).

Automatic tunneling might be another mechanism helping the deployment of
multicast.  In SSM, one could consider mechanisms as the following one
(I know it impacts the current model, but I think it's also pretty cool,
so maybe someone else might come up with variants that diminish the
impact):

At the SSM meeting in Pittsburg Doron Rajwan presented the idea to
extend IGMP to enable SSM-senders to check whether there are any
receivers for their data.  As an alternative one could consider to
terminate the PIM messages on the senders themselves (this would be a
scaled down PIM-stub with very limited functionality).  Once this
principle of terminating PIM at the SSM-sender would be accepted, one
can easily create automatic tunnels: again a number of special boxes are
placed at the border of the MBone, which will inject a default route
into the Mbone (the MRIBs will have a default route).  So (S,G) PIM
Joins with an S that is not part of the multicast topology will follow
the default route and will end up in this special border box.  The box
consults its RIB and tunnels the PIM Join to the sender S.  By looking
at the source of the outer IP header the sender knows where it has to
tunnel its multicast data to.

The above mechanism would allow that anyone can send to the MBone by
just downloading an application (no need to have a multicast router or
to configure a tunnel).  In ISM it was required that a sender sends its
data to the DR of the sender to be able to be discovered by the
receivers (via flooding or via an RP), but in SSM this is not necessary
anymore since out-of-band signaling is used.

In ngtrans there is another group of mechanisms beside tunneling, which
are the translators.  This could be another topic to investigate: how
can a unicast-only host hook up to a multicast distribution via a
special translator box.

Any comment?

dirk

-- 
Dirk Ooms                       mailto:[email-masked]
                                tel:+32 3 2404732
Network Strategy Group (NSG)    http://www.rc.bel.alcatel.be/nsg
Alcatel                         http://www.alcatel.com

---

From: Jon Crowcroft <[email-masked]>
Date: Mon, 05 Feb 2001 13:01:39 +0000

dirk
 
1/ you may need to consider load balancing the tunnel brokers - this can
be complex

2/ you will need to consider policy at the tunnel brokers
(the same reason an ISP might not want multicast is why they wont be
too fond of peope running tunnel brokers in the next door isp...

3/ see REUNITE (recursive unicast multicast ) from CMU as an approach
to some of this...

otherwise, i think it might be a nice idea...

 cheers

   jon

---

From: "Tony Ballardie" <[email-masked]>
Date: Mon, 5 Feb 2001 16:29:09 -0000

Dirk,

 > Wouldn't it be good to investigate how

I gave a short talk at mboned and ssm in San Diego about
auto-tunnelling. It's a definite must, and real soon, if inter-domain
IP multicast isn't going to completely wither. Although my proposal 
was only strawman-like, the concept at least was almost unanimously 
acknowledged as being needed. I proposed extending IGMP to 
additionally have receivers issue a special join to an anycast address
which would create a tunnel between the receiver and closest multicast
router.

Whatever the mechanism, it has to be simple and not involve
*any* 3rd party config, or ideally - user config. Of course, this
implies host mods, but IGMP is evolving anyway, so it would
be a good time (and chance) to integrate this. 

I think this capability is urgent for receivers, but less so for
senders. "Broadcasters" should be - and probably are - prepared
to go to greater lengths to ensure their content gets out there.

I plan to write a draft but haven't had time yet, and I had a
couple of offers to co-author, which might mean it gets done
a bit quicker :-)

cheers

Tony

---

From: Luis Costa <[email-masked]>
Date: Tue, 6 Feb 2001 15:40:43 +0100 (MET)

> 3/ see REUNITE (recursive unicast multicast ) from CMU as an approach

We are currently working on an evolution of REUNITE's idea, named HBH,
that extends the ability to support unicast clouds, especially for asymmetric 
networks. We presented a poster at NGC'2000, you can also take a look at
the technical report at 

http://www-rp.lip6.fr/publications/files/costa/hbh.ps.gz

Comments are welcome!

Luis

=======================================================================
Luis Henrique MACIEL KOSMALSKI COSTA		     [email-masked]
D.Sc. Student

Laboratoire d'Informatique de Paris VI 	             LIP6-UPMC - France
Grupo de Teleinformatica e Automacao            GTA-COPPE/UFRJ - Brasil
WWW - http://www-rp.lip6.fr/~costa
Tel. +33 1 44 27 87 72 

Research Interests: QoS-based Routing and Multimedia Applications.
=======================================================================

---

From: Dirk Ooms <[email-masked]>
Date: Thu, 08 Feb 2001 12:26:03 +0100

As people start drafting 'multicast-transition' schemes, I would like to
stress that it would be nice that the IGMP extensions at both ends of
the 'multicast path' would be the same, so that in the case of the
absence of a multicast network inbetween source and receiver it works
transparantly.

         +-       -+
+---+    |  +---+  |    +---+      +---+     +---+     +---+
|src|----|--|ucr|--|----|mcr|------|mcr|-----|ucr|-----|rcv|
+---+    |  +---+  |    +---+      +---+     +---+     +---+
         +-       -+

      Doron's IGMP++         MBone        Tony's IGMP++
  <---------------------><----------><------------------->

dirk

---

From: Dirk Ooms <[email-masked]>
Date: Thu, 08 Feb 2001 15:02:48 +0100

Or even more general: IGMP could also be used between two non-connected
multicast islands.