Subject: AW: 232-Addresses not only for current SSM model

From: Hummel Heinrich <[email-masked]>
Date: Thu, 3 May 2001 16:24:50 +0200

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" <[email-masked]>
> > 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: [email-masked]
>

---

From: "Stephen Sprunk" <[email-masked]>
Date: Thu, 3 May 2001 11:39:58 -0500

> expressed two major concerns:

Reading your draft (now expired) shows that sections 1 and 2 specify the
SSM delivery model and IGMPv3.  Section 3 rehashes the debate between
MOSPF/DVMRP and PIM.

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

The SSM delivery model specified by using 232/8 addresses does NOT
require PIM or any other specific mrouting protocol, as you imply it
does above.  If you wish to develop a ring-based or minimal tree
mrouting protocol that provides the SSM delivery model, that is
certainly possible.

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

The ASM delivery model is not source-specific.

> 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

The problem with trying to optimize for these specific technologies is
that layer 3 can't see them.

> IMHO: Path protection makes a lot of sense if any path failure
> affected thousands/millions of receivers (--> big multicast
> applications such as internet-TV).

Unicast path protection has the exact same issue; any given link failing
in the Internet may affect millions of users.

> Building a bi-directional ring (or tree of rings) may allow that each
> designated receiver node gets the data twice via two different pathes.

Any such technology can be implemented below layer 3 if desired to
prevent a link from failing in the first place (from layer 3's
perspective).  Carriers have shown a strong adversity to this approach
in the past, so making it mandatory at a higher layer is unlikely to be
popular.

> 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 utilization is impressive yes, but the protocol complexity required
to achieve it is unwieldy, not to mention the additional latency
introduced by minimal trees over shortest-path trees.

> Heinrich

S