Subject: AW: Reserved addresses in the SSM range

From: Hummel Heinrich <[email-masked]>
Date: Tue, 8 Aug 2000 08:26:12 +0200

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:[email-masked]]
> Gesendet am:	Montag, 7. August 2000 20:00
> An:	Doron Rajwan
> Cc:	[email-masked]
> 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: [email-masked]
> 
> 
> 
> 
> ----- Original Message -----
> From: "Doron Rajwan" <[email-masked]>
> To: <[email-masked]>
> 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.

---

From: "Stephen Sprunk" <[email-masked]>
Date: Tue, 8 Aug 2000 02:52:20 -0500

Thus spake "Hummel Heinrich" <[email-masked]>
> If there is so much trouble with the multicast address space, why is
> everyone happy with this awful limitation?

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

I think you're in violent agreement with the SSM work already
established.  The addresses allocated for SSM use will function in the
exact same way as the MC-ID you describe above, except with backwards
compatibility to the existing IP header format and address space.

Allowing a 32-bit address space for SSM groups may have some utility,
however this would inherently require modification to the IP header,
handling mechanisms, etc.  The current SSM allocation of 232/8 from the
Class D address space provides 24 bits of group identification, which is
arguably far in excess of what any given host can be expected to make
use of.

The discussion at hand is how many and which addresses should be
reserved, as you pointed out is necessary in the first paragraph of
section 2.1 in your draft.

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

The majority of concerns you raise are addressed by IGMPv3 and PIM-SSM,
or other various mechanisms (eg. RSVP).

Others, such as admission control, can be easily solved by application
mechanisms.

Some, such as fewest-links distribution trees are admittedly not handled
by PIM's tree-building model, but the complexity involved in creating a
system to handle such trees isn't generally worth the negligible or
minimal gain over a shortest-path tree.

S