Subject: RE: mboned: Source discovery draft for SSM

From: <[email-masked]>
Date: Fri, 13 Aug 2004 13:07:14 +0300

> -----Original Message-----
> From: Stig Venaas [mailto:[email-masked]]
>
> Very nice draft. I think some solution like this is needed. A very
> similar approach is suggested in the expired draft
> draft-hoerdt-mboned-multisource-ssm-00.txt

Yes, its quite similar to solution showed in that draft. The biggest differences seem to be the TCP and MSDP usage, also the logical multicast group shared by the sources differs.

> 
> One advantage with your approach is that you're using TCP for the SAs
> I think. The only small issue I see, is that it would require some
> additional host infrastructure. Since it's using a privileged port,
> you will some daemon that listens to this port and somehow notify
> clients. I guess one could also consider kernel support, but I'm not
> sure I like that. It would make it easy to join automatically as you
> suggest which might be an interesting way of emulating SSM for old ASM
> applications though.

No need to go to kernel level, but a general source discovery library would be nice to have (implementation under construction).

> 
> I believe a host should be able to join two completely different
> sessions (S,G) and (S',G) where the group is the same. That should
> work fine though as long as the receiver checks the source address
> in the IP header of the UDP MSDP SAs it receives. Else it wouldn't
> know if an SA for a source belonged to (S,G) or (S',G) and hence it
> wouldn't know which application/socket should join the new source.

It's possible to have two different sessions with the same group address, although then the logical multicast group concept is not valid anymore. Then you also lose the ability to leave all sources with simple IGMP/MLD Leave (*,G) message (which isn't a big thing, but...). In IPv6 there shouldn't be any need to have same group address for two different sessions, in IPv4 there might be some need, do you have some requirement behind your proposal? It's similar to ASM in that context that the group address define the multicast session (at least in network level, where UDP port numbers are not considered).

Anyway, thanks for the constructive input. Hopefully there will be some more discussion about the validity of the main proposal and different options that are available for the solution (UDP vs. TCP for SA announcement, logical multicast group vs. several sessions using same group address, IPSec need, etc.).

- Rami 

_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/

---

From: Stig Venaas <[email-masked]>
Date: Fri, 13 Aug 2004 12:46:25 +0200

> > From: Stig Venaas [mailto:[email-masked]]
[...]
> No need to go to kernel level, but a general source discovery library would be nice to have (implementation under construction).

Yes, no need for kernel support, but you will at least need something
that has root privileges to listen to that port and communicate with
applications. An application library is useful, but you shouldn't
require applications to have root privileges. This of course depends
a bit on operating systems etc and is an implementation detail. I think
this issue need to be considered though.

> It's possible to have two different sessions with the same group address, although then the logical multicast group concept is not valid anymore. Then you also lose the ability to leave all sources…

I guess I agree. There is a tiny risk though that two independent
sessions use the same group, so I think it's good to handle that case
if you can. It's not a big concern, but I think it's worth having in
mind. You may want to check the IP header source address of the UDP SA
packets anyway to be sure they came from the controller. Else you're
vulnerable to DoS attacks.

> Anyway, thanks for the constructive input. Hopefully there will be some more discussion about the validity of the main proposal and different options that are available for the solution (UDP vs. TC…

Yep (:

Another thing that perhaps should be considered, is whether you can
have a controller that is not itself a data source for the virtual
group. That is, only announcing sources, not sending any other data.
I see at least some possible uses for that. But I think that is doable
with your approach.

I think the main problem with approaches like yours (and that other
draft) compared to ASM, is that you require someone to "own" the
session. That is, you need to pick one source to be responsible for
the control function, and you have a problem if that one source
becomes unreachable, crashes or simply wants to leave. This might be
problematic if you have long lasting sessions with no-one in particular
being the owner. You have some of the same issues with Embedded-RP too.
I think that is hard to overcome, and it's perhaps an acceptable
limitation.

I've been mulling a bit over possible solutions to this. What I have in
mind is designating another source as a backup controller, so that if
the controller goes away, the sources know they should establish MSDP
peerings with another particular source, and the receivers are ready to
accept the UDP SAs. One could even consider solutions where any source
can be a controller, so that as long as you have sources you also have
at least one controller... If the protocol had supported a way for a
source to say whether it's willing to be a backup controller, and
perhaps some priority value... One problem is of course session
announcements. People need somehow to know what the current controller
channel is to join the session. Well, this is just some idle
speculations, I'm not sure whether it's worth considering.

Stig