Subject: Application for Multicast Number

From: Vicky Fyrigou <[email-masked]>
Date: Mon, 31 Aug 1998 11:01:56 +0300

Hello all,

We would like to acquire a range of multicast addresses in order to
be able to use them for emission of real-audio and other multicast
applications to the MBONE.

We found a form for multicast number application at:

http://www.isi.edu/cgi-bin/iana/multicast.pl

Can you please advise on how we should fill in this form?
It seems that it is protocol oriented and we don't know
what we should reply in questions like:
"What message types are used ? What functions are performed by this protocol ? 
"
etc.

Thanks in advance,

Best Regards,

Vicky Fyrigou
FORTHnet S.A.

---

From: Mark Handley <[email-masked]>
Date: Mon, 31 Aug 1998 09:29:56 -0400

>applications to the MBONE.

These sort of applications are not ones that require statically
allocated addresses.  You might require a static well-known address
for particular protocol such as SAP or AAP, but A/V channels should
use dynamically allocated addresses.  There's simply no way IANA would
be able to cope with everyone in the world registering their own
static sessions.

The dynamic address allocation work in the IETF is not deployed yet,
but the existing session directories using SAP are currently serving
this purpose.

Thus you should probably use a session directory such as sdr, IP/TV or
MultiKit to choose your addresses and announce them to the session
announcement group, which will prevent other people dynamically
allocating the same addresses.  In addition it provides a way for
users to discover the existence of your sessions.

Cheers,
	Mark

---

From: Vicky Fyrigou <[email-masked]>
Date: Mon, 31 Aug 1998 17:50:28 +0300

Thanks for the quick reply.
What we really want to do is to be able to transmit multicast
information to MBONE, but to filter at the same time all the
dvmrp routes (we are kind of sensitive concerning our international
bandwidth).

We have a Real Audio Server that transmits multicast flow 
from radio stations and we would like to transmit it both
to our backbone and to MBONE. Whatsmore, we would like to 
be on total control of multicast channels on our backbone,
for access and security purposes. Therefore we need static 
allocation of multicast groups on our backbone.

Is there any solution proxy-like solution in order for us to have
static allocation of multicast channels in our backbone and 
dynamically to the rest of Mbone? 

Thanks again,

Best Regards,

Vicky Fyrigou
FORTHnet S.A.

---

From: Panos GEVROS <[email-masked]>
Date: Mon, 31 Aug 1998 17:01:12 +0200

|We have a Real Audio Server that transmits multicast flow 
 |from radio stations and we would like to transmit it both
 |to our backbone and to MBONE. Whatsmore, we would like to 
 |be on total control of multicast channels on our backbone,
 |for access and security purposes. Therefore we need static 
 |allocation of multicast groups on our backbone.
 |
 |Is there any solution proxy-like solution in order for us to have
 |static allocation of multicast channels in our backbone and 
 |dynamically to the rest of Mbone? 

consider using Administratively Scoped IP multicast (239. range of addresses)
and configure boundaries on all your border router tunnels to the Mbone
this will let you have the specific sessions confined within your region (and not propagated outside) 

for your intended audience; if the way to join the A/V channels on the Mbone is the session directory (sdr) you dont really care about the actual binding as long as the announcement is there and has an appropriate lifetime.
i dont know how "dynamic" (if at all) is the allocation of multicast addresses from sdr though.. 

Cheers,
Panos

---

From: Ignatios Souvatzis <[email-masked]>
Date: Mon, 31 Aug 1998 18:08:42 +0200

> dynamically to the rest of Mbone? 

I suggest that you allocate some unused, formally dynamic numbers, and
announce them semi-permanently using one of the announcemence tools.

This is how some other long-time channels work (e.g., Places Around
The World).

	-is

---

From: Mark Handley <[email-masked]>
Date: Mon, 31 Aug 1998 12:12:32 -0400

>i dont know how "dynamic" (if at all) is the allocation of multicast addresses

It's dynamic is the sense that sdr chooses an unused address from the
dynamic pool (224.2.X.Y) for you and you keep it only so long as you
have it announced in the session directory.

As opposed to the static case where you get one from IANA and a while
later you stop using it but the address is reserved forever.

By the end of this year we'll probably have a proper allocation
architecture starting to be used, but for now the session directory is
it.  You're unlikely to get a static address from IANA for an A/V
session because the guidelines are that these use dynamically
allocated addresses.

Cheers,
	Mark

---

From: Mark Handley <[email-masked]>
Date: Mon, 31 Aug 1998 12:15:06 -0400

>This is how some other long-time channels work (e.g., Places Around

Agreed, except for the word "formerly".  They're still dynamic because
whilst you keep them for as long as you use them, they return to the
pool when you stop announcing them.

Cheers,
	Mark

---

From: Ignatios Souvatzis <[email-masked]>
Date: Mon, 31 Aug 1998 18:59:31 +0200

> >I suggest that you allocate some unused, formally dynamic numbers, and
--------------------------------------------^^^^^^^^

> pool when you stop announcing them.

I double checked, and it still looks like "formally", not "formerly".

So, you're even more sleep deprived than me? ;-) 

Regards,
	-is

---

From: Mark Handley <[email-masked]>
Date: Mon, 31 Aug 1998 13:02:01 -0400

>> >I suggest that you allocate some unused, formally dynamic numbers, and

Unfortunately yes.  I'll go back to sleep now...

Mark

---

From: "Alan J. Flavell" <[email-masked]>
Date: Mon, 31 Aug 1998 18:03:38 +0100 (BST)

On Mon, 31 Aug 1998, Mark Handley wrote:

> >I suggest that you allocate some unused, formally dynamic numbers,

> Agreed, except for the word "formerly".  

With respect, those numbers are still formally dynamic, both formerly
and latterly ;-)

---

From: "Christopher J. Tengi" <[email-masked]>
Date: Mon, 31 Aug 1998 16:02:20 -0400

Mark,
    Do you have any idea as to whether the folks who write the code for the 
RealVideo server are looking into using the allocation architecture?  Right 
now, you have to plug a range of group addresses into the server 
configuration, and the server picks one as it needs it (telling the clients 
what it is when they try to open a connection to the server).  I suppose that 
we could announce a session or 2 (or 3 or 4...) with sdr and just point people 
to a web page for details if support doesn't end up in the RealVideo server.

					/Chris