All things related to multicast

[Tom Pusateri <>]

In message 
<>
 you write:
>On Wed, Jul 09, 2003 at 02:52:46PM -0700, Joel Jaeggli wrote:
>> On Wed, 9 Jul 2003, Lorenzo Vicisano wrote:
>> 
>> > On Wed, Jul 09, 2003 at 02:17:38PM -0700, Joel Jaeggli wrote:
>> > > 
>> > > It was never clear to me why a host to router signaling mechanism had 
>> > > to be different from the router to router signaling mechanism.
>> > 
>> > one reason is because a host just needs to signal that is wants to
>> > receive multicast on a link, while a router cooperates with other
>> > routers to forward multicast in some optimized way. Hence the
>> > statement "I want to receive from this link" is typically not
>> > sufficient.
>> 
>> so why can't I just send an s,g join towards s using pim instead of nicely 
>> using igmp to get my first hop router to do it for me?
>
>because you, the host, would have to have routing information to find
>out who the 1st hop towards the source is... you would also have to
>take part to the PIM routing protocol to find out who's responsible to
>forward in your lan for that source.
>
>       Lorenzo

More than that, routers are particular about the state they keep and
who they exchange routing information with. Running PIM on the hosts
is a fast way to get PIM turned off on the routers.


I won't be at the BOF so here are some suggestions I would like to see
come out of this work:

1. I don't think we should throw out the idea of a new signaling protocol
   too quickly. If we can reuse someone else's packet formats, then
   great but the characteristics of the signaling should be decided first
   and then we can determine if an existing protocol will fit our needs.

   The characteristics I would like to see are:

   a. Host application can send join requests without any special
      privileges on the largest variety of operating systems. This
      speeds deployment and puts users in control without having to
      get approval from Administrators. This dictates that the
      protocol be UDP or TCP based.

   b. A server or router listening to these join requests should not
      have to guess what type of join this is. The server may be doing
      encapsulation or it may be doing header rewriting (translating
      from multicast to unicast). It needs to know how many "users" it
      can handle and know if resources become limited that it can drop
      these hosts instead of dropping something like real multicast
      PIM neighbor adjacencies which will affect many "users".

      A way to clearly distinguish this application is essential if
      you want router/switch vendors to be willing to replicate or
      accept tunnel requests at the edge of your network.

2. Don't make encapsulation a requirement.

   This complicates the host implementation requiring it to decapsulate.
   While this may be one way to get the multicast to the hosts,
   simply having servers sit at the edge of a network and replicating
   a multicast stream to a bunch of hosts by replacing the multicast
   destination address with the hosts unicast address eliminates
   much complication from the host application. It simply sees a
   regular UDP unicast stream coming in.

3. The address the join is sent to should be specified the same way
   as the group and the source address is learned. This will likely be
   in the SDP description. The join address may in fact be the source,
   or it may be an anycast address or some other invention. But we're
   free to try different approaches and we don't lock ourselves in.

4. The join should use the router alert option in the IP header.
   This will allow routers along the path from the receiver to
   the source to process the unicast join or send it to a server
   it knows about.

Lets nail down some more requirements of the signaling protocol
and then decide if we need to invent something new or we can
reuse some existing mechanism.

Thanks,
Tom