Subject: allocation of multicast addresses

From: Victor Reijs <[email-masked]>
Date: Thu, 04 Jun 1998 15:38:16 +0200

Hello all of you,

I am on search on advice on the allocation of multicast address for a
high end conferencing system made in the Netherlands (Mesh:
www.mesh.nl). It is now performing very well on ATM but we are looking
how to implement it over IP. For this we would like to use IP multicast
and thus we need to decide on the multicast addresses to be allocated.
We of course don't want to disturbe existing allocation shemes and
furthermore we want to be a little future proof. Because there is not
yet a standard for this (although they are working/thinking on it), we
would like to have some advice from you. 
We have studied the link:
http://www.isi.edu/in-notes/iana/assignments/multicast-addresses
and now we have a few ideas:
A) get our own space from IANA.
Is that the correct and feasable way to do it?

B) there is now already implemented in the software the following scheme
(only used in local area IP multicast!):
224+<station ID|modulus 15>.<last three digits of the station's normal
IP address> <random portnummer greater than 6400>
This would be the easiest (is already implmented), but is this not too
scary on the real IP multicast network?

C) use the assigned group in the above URL:
224.2.0.0-224.2.127.253  Multimedia Conference Calls         [SC3]
Or do we misinterpretate the aim of this group?
If we are going to use this, we are thinking of the following scheme:
224.2.<station ID|modulus 128>,<datatype> <random portnumber greater
than 6400>

D) any other scheme?

Please provide input what we should choose?

Thanks for your ideas and all the best,

Victor

---

From: Mark Handley <[email-masked]>
Date: Thu, 04 Jun 1998 12:27:36 -0400

>Is that the correct and feasable way to do it?

This is useful only if you hope to have one (or a very small number)
of conferences, and isn't useful if you want to take advantage of
admin scoping.

>scary on the real IP multicast network?

Yes.  You will clash with other users.

>224.2.<station ID|modulus 128>,<datatype> <random portnumber greater

These are the addresses currently allocated by sdr.  If you use these
addresses please use sdr or one of its clones.  If you don't, you'll
cause address clashes.

>D) any other scheme?

Use a dynamic address allocated using the MALLOC architecture.  
See
  http://north.east.isi.edu/malloc/
or
  "MASC/BGMP Architecture for Inter-Domain Multicast Routing"
  http://netweb.usc.edu/estrin/papers/masc-bgmp-arch.ps>
for more details.
       
This isn't finished yet, but we hope to start testing AAP this
summer/fall, and MASC a little later.  Sdr will migrate to using AAP
late this year.

If you absolutely need addresses right now, get some from sdr and
announce their usage using sdr.  

Cheers,
	Mark

---

From: Manolo Sola <[email-masked]>
Date: Fri, 05 Jun 1998 09:13:39 +0900

Victor,

> >D) any other scheme?

There is a proposal based on Static Multicast and PIM-SM/{CBT/OCBT}
to be presented at INET'98. Please, for details see bellow. Comments are also
welcome.

http://www.ietf.org/internet-drafts/draft-ohta-static-multicast-00.txt
http://web.jet.es/sola/inet98.html

I will try to summarize through a simple example:

If you are delegated the set of unicast IP addresses X.Y.Z.0/24, you will
also be
delegated the multicast IP addresses M.X.Y.Z, with M=224,...,239.  You can
use
or subdelegate multicast IP addresses in the same way you do with unicast
addresses.
The multicast IP address of your multicast group is looked up through DNS,
for example:
BBC.COM    IN    A    225.120.1.2
The available set of RPs/Cores to connect is also looked up through DNS:
BBC.COM   IN   RVP   england.bbc.com.
          IN   RVP   scotland.bbc.com.
Receivers/senders look up DNS for BBC.COM and then join/send to the nearest
RP or
Core. An Inter-RP/Core protocol is used to forward multicast traffic among
RPs/Cores, this protocol can be as simple as tunneling. We think that only a
few
RPs/Cores will be needed.

-- Manolo