AW: Reserved addresses in the SSM range

[Hummel Heinrich <Heinrich.Hummel@icn.siemens.de>]

If there is so much trouble with the multicast address space, why is everyone happy with this awful limitation?
Why can't every unicast address S assign as many multicast-IDs (MC-IDs)  by itself as to host as many TV-like webpages as it may create?
Each pair (S,MC-ID) will unambiguously identify the respective delivery tree!
The SSM-WG is a standardization body and can therefore define what is necessary to go with such a change.
It shouldn't be a big task to define the "destination" in the IP-header : dest. addr=S, option field =MC-ID, type=SSM.
It wouldn't be a big task either to adjust IGMP. And in the internet: there is no big difference if you identify the delivery tree
by (S, MC-ID) rather than by (S,G).

For more, see draft-hummel-ssm-00.txt

Heinrich



> -----Urspr> üngliche Nachricht-----
> Von:	Stephen Sprunk [SMTP:ssprunk@cisco.com]
> Gesendet am:	Montag, 7. August 2000 20:00
> An:	Doron Rajwan
> Cc:	ssm-interest@external.cisco.com
> Betreff:	Re: Reserved addresses in the SSM range
> 
> 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.