Subject: mboned: IPv6 multicast DAD

From: Stig Venaas <[email-masked]>
Date: Mon, 2 Aug 2004 21:29:13 +0200

I think it might be better to discuss details related to this in this
wg only.

The idea with multicast DAD, would be to determine if the same
multicast group (or last 32 bits) is used by someone else on the link.
There are applications where there might be both multiple receivers and
sources on the same link though.

I think DAD makes sense for sources. I'm thinking of some solution where
an application makes a system call to register as a source, and specifies
group address (or leaves it blank) and whether it needs to be a unique
source. The call should fail if the specified group have other sources on
the link and it wanted to be unique. If address is not specified, the
kernel could pick some random group (or maybe some other algorithm) and
check if it's unique. Right now I don't want to think about how the
protocol should be for doing the actual DAD.

If such a system call were created, it could allow for some great
simplifications to PIM-SM or maybe Bi-dir with embedded-RP, since you
do signalling prior to sending data.

What do you think, is it worth pursuing something like this?

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

---

From: Jean-Jacques Pansiot <[email-masked]>
Date: Tue, 03 Aug 2004 10:51:05 +0200

>an application makes a system call to register as a source, and specifies
One problem is that in some existing applications (eg vic), you start as 
a receiver (and must specify the
group address) and later on become a source.
What has been missing with IP multicast is the notion of "creating " a 
group. The group "creator" needs not
to be a source. I would rather have a tool  :
register-multicast-address( G, duration) or
register-multicast-address(*, type/scope, duration)  /* automatically 
generate an address of the given type/scope */
(obviously this utility could be included directly into some applications).
As said in a previous mail, this could be useful also for SSM ( dont 
rely on the user to guess
an unused SSM group ID).

>do signalling prior to sending data.
That would be very helpful,  but I think it is another function : source 
register

>What do you think, is it worth pursuing something like this?
I think that this type of mechanism is really needed to deploy multicast

Jean-Jacques

---

From: Pekka Savola <[email-masked]>
Date: Tue, 3 Aug 2004 17:34:31 +0300 (EEST)

> register-multicast-address(*, type/scope, duration)  /* automatically 

It is worth noting, that "duration" is a tricky concept.  You assume 
that the application knows how long the session is going to run.  Does 
it ask the user to supply his estimate?   What if that estimate does 
not hold?  What if the application is non-interactive?

With IPv6 (at least), we really aren't concerned about the duration,
as there is no multicast address shortage.  The app could just use it
as long as it wishes.  At the very least, the duration should be be
optional ("0" for infinite or "for now"?).

(However, I'm slightly concerned about designing nice APIs.. because
we often seem to discuss them, but nothing gets done because the IETF
typically doesn't do them.)

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings