Subject: Reserved addresses in the SSM range

From: Doron Rajwan <[email-masked]>
Date: Sat, 5 Aug 2000 04:27:11 +0200

Regarding Hugh question about reserving addresses in the SSM address space,
I would suggest to reserve at least 255 addresses, or even more.

First, we have nothing to loose. 

Second, we all know that UDP and TCP reserved ports is proven to be helpful.

Third, especially if my suggestion about "Multicast on-demand" will be
accepted, a multicast server will have the ability to know if it has at
least one connected client to any given multicast address. In this case, we
can think of the following services, each given in a different, predefined,
multicast address:

1. Time service. The server's local time and time zone every second.
   Support packet-loss rate detection.
   Support "ping" for multicast.
   I suggest address 232.0.0.1 for this one.

2. CA service. Send certification about the server every 5 seconds.

3. Quote of the day service. Actually, quote of the minute.

4. Directory service. Send some information regarding the current server.
   Probably the most important service.

5. ...

Doron.

---

From: "Stephen Sprunk" <[email-masked]>
Date: Mon, 7 Aug 2000 12:59:49 -0500

232.0/16 would be my choice for a reserved block.  My reasoning:

o  Use of 232.0.0/24 may disrupt essential services on 224.0.0/24.
o  Most users/admins are already wary of addresses with zeroes.
o  SSM addresses are reusable since they are source-specific, so there
is little danger of reserving too much space (1/256th in my case).

Is there any interest in "default" group addresses based on port
numbers?  For instance, if I somehow know my NTP server's address but
not the group number, then I could try 232.x.0.123:123, and then switch
to unicast if that fails.

In regard to sender notification of receiver presence, shouldn't that be
handled at the transport or application layer?  For example, we could
modify RTCP such that responses to RTP streams sent to an SSM address
would be directed to the sender instead of the group.

S

     |          |         Stephen Sprunk, K5SSS, CCIE #3723
    :|:        :|:        Network Design Consultant, GSE
   :|||:      :|||:       14875 Landmark Blvd #400; Dallas, TX
.:|||||||:..:|||||||:.    Email: [email-masked]

---

From: "Dr. Carsten Bormann" <[email-masked]>
Date: Mon, 7 Aug 2000 21:24:50 +0200

> For example, we could

Just remember that the RTCP receiver reporting algorithms depend on seeing
every other report to gauge the group size and adjust the reporting
bandwidth appropriately (see section 6.2 of RFC1889 or, better,
draft-ietf-avt-rtp-new-08.txt).
RTCP currently has no way to reflect this information back from the sender
(which is the only one who will have it if RTCP is unicast).
For NORM (NAK oriented reliable multicast, rmt working group), we will
probably put a sender-based group size estimation scheme into the protocol
to make this work.

Gruesse, Carsten

---

From: Colin Perkins <[email-masked]>
Date: Mon, 07 Aug 2000 16:02:44 -0400

>probably put a sender-based group size estimation scheme into the protocol

We did figure out a way of making this work during a side discussion at the
Oslo IETF, but I don't think it ever got written down..  Maybe it's time to
resurrect those ideas?

Colin