All things related to multicast

[Marshall Eubanks <>]

Hello;

On Jun 27, 2008, at 10:28 AM, Bill Owens wrote:

> On Fri, Jun 27, 2008 at 03:14:02PM +0100, Tim Chown wrote:
> > On Thu, Jun 19, 2008 at 09:51:13AM -0400, Bill Owens wrote:
> >
> > > Since this has become a recurring problem I'm going to approach it  
> > > through education; telling people not to leave a SAP listener  
> > > running on their desktop, and getting them to disable sap listen  
> > > on their routers. Hopefully that will be enough. But I wonder  
> > > whether it is time to start down the road towards deprecation. . .
> >
> > ... which leads to the question of a viable alternative.
> >
> > I'm hoping to have a project student working on the general area next
> > semester.   I'd be interested in references to projects that are
> > monitoring existing SAP traffic, with a view to redistributing the
> > information via other means (perhaps RSS-a-like).   In our case, we
> > would include IPv6 SAP also.
>
> I vaguely recall such things being discussed several times, but I've  
> always paid them little attention because SAP:
> - already works
> - is built into every important client and server application
> - isn't all that useful anyway
>
> To date, any replacement service would have the first two points as  
> hurdles, and the third point as its only way to gain an advantage.  
> Now we can add the threat of SAP storms to the list, but those only  
> affect the network operators, not the end users (at least, not  
> directly).
>
> I suspect that there are some hidden hurdles to acceptance of a new  
> solution as well. SAP was designed back in the golden days when  
> everybody trusted each other and we were all friends - not like  
> today :) Any replacement would be held to a higher standard for  
> resistance against spoofing, DoS attacks (to the service as well as  
> to the participants), protocol extensibility, internationalization,  
> etc. And whatever buzzword compliance you decide on, somebody will  
> prefer a different buzzword. At any rate, good luck and godspeed ;)
>
> Of course, SAP would go away if we could ever kick our addiction to  
> ASM. And I don't really think that it has any future at all in v6,  
> except perhaps as a local-area service (ie. within the reach of a  
> single PIM domain). Perhaps that's the way to push forward - we need  
> something for the inevitable future when we're all running SSM/ 
> embedded-RP v6 multicast.

A SAP for SSM was always resisted in the IETF but I personally think  
that it would be a good thing. Here is how I envisioned it :

Set up a SSM group address for SAPSSM, say G-SAP. There is a well  
known channel (i.e, a specific S-SAP), so that anyone can listen to (S- 
SAP, G-SAP). The S-SAP could maybe be anycast in some fashion,  so  
that there
is not a reliance on one specific machine.

Now, if I want to add material into SAPSSM, I start sending out SAP  
announcements on (S-ME, G-SAP). Note that this is a different channel,  
and listeners to (S-SAP, G-SAP) will not get this.

So, I have to register somehow with the SAPSSM servers, who would then  
listen to my SAP announcements and reflect them to (S-SAP, G-SAP).  
This registration would presumably be unicast, and there would have to  
be some sort of trust aspect to this. (I.e., as Bill points out, S-SAP  
should not accept everything from S-ME without some checking of S-ME.)

This could be done, and I personally think it would be useful to have.

Regards
Marshall



> Bill.