Re: Reserved addresses in the SSM range

["Stephen Sprunk" <ssprunk@cisco.com>]

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: ssprunk@cisco.com




----- Original Message -----
From: "Doron Rajwan" <Doron@bandwiz.com>
To: <ssm-interest@external.cisco.com>
Sent: Friday, August 04, 2000 21:27
Subject: Reserved addresses in the SSM range


>
> 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.