AW: 232-Addresses not only for current SSM model

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

	About my  motivations regarding this issue:
	In the past (see Pittsburgh-draft draft-hummel-ssm-00.txt) I expressed two major concerns:
	#1: to have a global (i.e. not source specific) multicast address G
	#2: to build/extend the delivery tree reversely.
	The 232-Address overcomes concern #1 perfectly. But can it be used also by future multicast models
	which do not use the current JOIN message? In case this is assured: great. In case this is assured even without
	the need for subranges of the 232-address space: even better.

	In Minneapolis I learnt that there will be no further SSM session. While this is ok with regard to the SSM model, it 
	won't be the end of working on multicast. At the same time, I think, no one will ever come up with a multicast model
	which uses a non-source specific multicast address G. Do you agree?

	Am I looking to develop a different protocol ?
	Well, I would like to, though I must admit I am neither THE expert on classical multicast nor on the new technologies which should be
	integrated /utilized like Optical networking, path protection, OAM.

	IMHO: Path protection makes a lot of sense if any path failure affected thousands/millions of receivers (--> big multicast applications such as internet-TV).
	Building a bi-directional ring (or tree of rings) may allow that each designated receiver node gets the data twice via two different pathes.
	In case any link breaks, it will receive the data at least once. 
	Some costs are involved: double bandwidth, some more links

	I did some simulations: in a network of 300 nodes and 550 links I computed the  delivery channel from 1 root node to 99 leaf nodes. 
	a) a Dijkstra-Shortest path tree took 204 links, 
	b) a ring took 213 links,
	c) a minimal-sized tree took 160 links.

	These figures show: The ring was not too bad compared with the Dijkstra-Shortest path tree (which is  state of the art in all existing multicast models).
	The minimal-sized tree is pretty impressive. 

	Different potential concepts: The delivery tree shall be a
	a)   minimal tree
	b)   ring
	c) ring with attached trees (its a ring of RPs :-) )
	d) tree of rings

	Enough work for the next ten years. 

	Regards,
	Heinrich


> Thus spake "Hummel Heinrich" <Heinrich.Hummel@icn.siemens.de>
> > My point is another one or maybe I should ask this question:
> > When a node in the middle of the network receives a particular
> > "multicast" message, how can he recognize which  evtly. present
> > (S,G) -multicast channel is meant in case there are multiples of
> > (S,G)-models, and not just SSM ?
> 
> A node in the middle of the network forwards a packet based on the (S,G)
> state already stored in that node; this behavior is independent of how
> exactly that (S,G) state is created (eg. DVMRP, MOSPF, PIM).
> 
> Using 232/8 addresses declares that the sender(s) and recipient(s) want
> the SSM delivery model (versus the default ISM).  It does not mandate
> the use of PIM; PIM just happens to be the only protocol (AFAIK) that
> offers SSM delivery so far.
> 
> I can't tell from your first message if you're looking to develop a
> different delivery model than either ISM or SSM, or if you're looking to
> develop a different protocol to provide ISM and/or SSM delivery.
> 
> 
>      |          |         Stephen Sprunk, K5SSS, CCIE #3723
>     :|:        :|:        Network Design Consultant, ANS
>    :|||:      :|||:       RCDN2 in Richardson, TX
> .:|||||||:..:|||||||:.    Email: ssprunk@cisco.com
>