Re: Reserved addresses in the SSM range

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

Thus spake "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?

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.

> Heinrich

S

     |          |         Stephen Sprunk, K5SSS, CCIE #3723
    :|:        :|:        Network Design Consultant, GSE
   :|||:      :|||:       14875 Landmark Blvd #400; Dallas, TX
.:|||||||:..:|||||||:.    Email: ssprunk@cisco.com