Subject: mboned: Interest in working on multicast address rendezvous?

From: Pekka Savola <[email-masked]>
Date: Thu, 27 Jan 2005 19:22:29 +0200 (EET)

Hello folks,

From time to time, there has been more or less vigorous discussion in so called 
"multicast address rendezvous", i.e., how does a multicast application (like 
one that has a static IANA assignment today) pick the address for creating a 
new session, and how do the other instances of the same application find that 
IP address.

This was discussed as part of IMDOC at IETF59 though I don't think there was 
much result from that (the last item on agenda):
  http://www.ietf.org/proceedings/04mar/172.htm

This is also mentioned in section 4 (which might be going away as it's a bit 
out of scope) of:
  draft-savola-mboned-addrarch-00.txt section 4.

What I'd like is to have a couple of people (myself included if needed :) to 
sit down, and try to write an I-D on the subject, exploring the problem, 
perhaps introducing some requirements, and maybe even look at the solution 
space for a bit.

Anyone interested?  I'd prefer to be only a contributor myself, as I have a bit 
too many drafts out already, so if you'd like to actively drive the effort, 
this is the chance of the lifetime.. ;-)

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/

---

From: Beau Williamson <[email-masked]>
Date: Thu, 27 Jan 2005 13:47:24 -0600

Pekka,

I've had some discussions about this with Dave Thaler in the past.  There 
was some work done in the past on SADP (Session Address Discovery Protocol) 
that I thought was in the general direction of what was needed although 
maybe it needs some tweaking.

My idea was that we need to better establish at least two well known scopes 
for the smallest and largest scope WITHIN a PIM Domain (such as an 
Enterprise).  You would then assign an SADP Scope Relative address that 
could be used by an application to discover what multicast address was 
being used for it's application.  The key is that you don't want to depend 
on a given SADP Server architecture having to exist prior to this 
working.  Instead, you want the application developers to be free to write 
code so that their SERVERS listend to this scope relative address and then 
responded ONLY to SADP Requests for their application.  The goal is to let 
the application writers deploy their applications in networks that have a 
minimum infrastructure.

Hopefully some of the above makes sense.

Beau Williamson
P.S.  I can contribute to this but don't have the cycles to write an ID.
At 1/27/2005 11:22 AM, Pekka Savola wrote:
>Hello folks,
>
> From time to time, there has been more or less vigorous discussion in so 
> called "multicast address rendezvous", i.e., how does a multicast 
> application (like one that has a static IANA assignment today) pick the 
> address for creating a new session, and how do the other instances of the 
> same application find that IP address.
>
>This was discussed as part of IMDOC at IETF59 though I don't think there 
>was much result from that (the last item on agenda):
>This is also mentioned in section 4 (which might be going away as it's a 
>bit out of scope) of:
>What I'd like is to have a couple of people (myself included if needed :) 
>to sit down, and try to write an I-D on the subject, exploring the 
>problem, perhaps introducing some requirements, and maybe even look at the 
>solution space for a bit.
>
>Anyone interested?  I'd prefer to be only a contributor myself, as I have 
>a bit too many drafts out already, so if you'd like to actively drive the 
>effort, this is the chance of the lifetime.. ;-)
>
>--

---

From: "Marshall Eubanks" <[email-masked]>
Date: Thu, 27 Jan 2005 20:46:57 -0500

On Thu, 27 Jan 2005 19:22:29 +0200 (EET)
> this is the chance of the lifetime.. ;-)

I am interested. Let me see if I can recap what I understand of the current issues

Orignally, there was SDR, which basically had "global" address assignment using a
distributed database (i.e., every sdr user knew about every addressed being used, at least 
inside the same scope). SDR also does source announcement and session description (i.e., it provided
enough information to join a group). SDR "doesn't scale" and is pretty ASM centric and is
effectively dead now.

Then there was an effort around MADCAP/MALLOC/MASC and BGMP, which is widely regarded as having
failed, and was certainly never driven to deployment, and 
GLOP, which has been very successful.  Now there is also SSM, which
in theory does not require any address allocation (although I will be willing to bet that if
NASDAQ and other financial users moves to a IPv4 SSM solution, they will want some sort of address
allocations to avoid Ethernet MAC collisions).

Of course, the lack of multicast deployment and GLOP and SSM have taken the some' wind out of the
sails of any sort of dynamic address allocation.

So, the questions I would have are

- is this address allocation only, or does it include any sort of source announcement ? If so, will
the source announcement include sufficient information to join the group, and will this be
restricted to SDP files, or will it support other source description types ?

- is there going to be some sort of distributed database of multicast address usage, a
central server type solution, or a human allocation as is done by ARIN and the other RIR's ?
If the distributed database solution is picked, will multicast be used to populate it, or will this
be done out of band, say using DNS ?

- Will SSM be supported ? If so, how will SSM support a distributed database, or will this be
allowed to drive the architecture ?

- Will this service be available to anyone, or will there be restrictions ? If so, how ?
Will this be done automatically to the service (in the way that DNS is limited or BGP are limited by
peering arrangements), or will there be some sort of authorization on top of that ?

Well, that's probably enough for now. Question, comments and rotten tomatoes are all welcomed as
always.

Regards
Marshall Eubanks

(Note
that ARIN 2002-3 was on my part originally an attempt to extend the GLOP idea to unicast addresses,
and this was accepted by ARIN, albeit with some changes.)

---

From: Pekka Savola <[email-masked]>
Date: Fri, 28 Jan 2005 14:13:49 +0200 (EET)

Hi,

A few initial stabs to your questions, and a quick take on what a 
mechanism could look like (but probably eventually won't).

> restricted to SDP files, or will it support other source description types ?

Not SAP-like broadcast announcement itself, but IMHO there should be 
sufficient information for the late-comers to join the session. 
Whether SDP descriptions should provide sufficient capability is an 
open question, and whether it should be possible to use the service 
without having to do SDP at all if the application is suitably simple.

> be done out of band, say using DNS ?

DNS is a candidate at least as a means of redirection (e.g., as a way 
to refer to an SDP file for more details, if just giving the group IP 
address (ASM-only, beware) is not enough).

The database may also be something that is only locally deployed 
accessible, e.g., a local MADCAP server with tweaks.

> allowed to drive the architecture ?

A good question.  SSM does not have the same "IANA assignment" 
problem, but could clearly benefit of this as well in making it easier 
to discovery SSM (S,G) pairs instead of ASM.

> peering arrangements), or will there be some sort of authorization on top of that ?

Again, good questions.  There are some concerns to relating to privacy 
if a globally accessible database is used (i.e., can anyone look up 
whether site X is using app Y, and which node(s) are using it at site 
X).

....

First, we have to consider the requirements:
  1) smaller-than-global scoped applications should require no 
configuration at the site, to make it attractive to the app 
developers;
  2) globally scoped applications may require administrative control.

To satisfy goal 1), we'll have to take shortcuts.  I.e., deploy some
form of scope-relative SADP addresses that an application can use
without any server to announce its presence for others interested in
that application.

To satisfy goal 2), there has to be configuration of some 
infrastructure.  One could consider a means of discovery of 
GLOP/Embedded-RP "restricted-global SADP" address, but the issue is 
that an orgnization might not want to tell of all of its 
restricted-global sessions to all of its business partners.

Is that a showstopper for this kind of "semi-global SADP"?  If so that 
would imply that we'd have to be content with a means to discover a 
MADCAP server or figuring out another means to resolve the address 
conflicts which does not require "semi-global" propagation of 
information of the existing sessions.