[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Reacting to previous messages
after the inter-continental time difference ... and thus a late re-action
(incredible what happens in the other side of the atlantic while I am sleeping
;-) ... and what happens here while you also drowse away.
Well, (at least!) here goes my re-action although I do not know to which messag
e
I am re-acting to.
The addition of the core/source address to the group address seems to me one of
the nicest ideas to tackle the problem of multicast address scarceness and thus
the idea of having a WG joining efforts to see it implemented re-assures me tha
t
some people believe in "simple solutions to big problems".
The idea of a new protocol to compete with PIM-SM is for me not so clear,
though. This is partially, because I am doing at present a survey on multicast
routing protocols and the list of protocols to be surveyed has been increasing
day by day. Thus, I think that another protocol, for the sake of a competing
protocol, be it SM or Express will just create a feeling of
"yet-another-protocol" for people who are eager to see whether this thing calle
d
Multicast strives or not... and none of the present proposals convinced me for
the inter-domain routing case.
On the other hand, it is also not clear for me whether a protocol like PIM-SM
(adding 4 bytes worth of address or not) can be a compelling protocol for all
types of applications. It looks more to me that PIM-SM is a hybrid of all the
new (and GOOD) ideas that have come out lately like:
1: the shared tree for group membership management;
2: the bidirectional trees for sources that are also members;
3: the soft state with RPF check forwarding for flexible adaptability to routin
g
changes;
etc, etc
... and I would not be surprised if in the future the glue of the extra 4 bytes
will be another addendum...
However, if you want to implement PIM-SM good luck! take some holiday first and
save your breath: it is not an easy task! And why should multicast routing
require such a complexity anyway?
As far as multicast applications is concerned, I have been longing to see
"interactive" applications considered seriously as multicast applications rathe
r
than passive "push" applications like Internet TV that might generate a lot of
revenue but that give me the feeling of "I have better things to do then stay
home and watch TV". The argument that such applications are not there yet is no
t
valid, in my opinion. Virtual reality based entertainemt and educative
applications can become a reality as soon as network engineers can come up with
a network that enables these applications to "navigate" well!
Interactive applications do not require such a complex protocol like PIM-SM. A
single, bidirectional shared tree protocol scales well, is simple to implement
and easy to maintain. Feel worried about traffic concentration? create another
group and another shared tree. It might be even better for the sake of traffic
engineering, since with a new core, the data might be using different links tha
n
the original one.
I am going a bit away from the main issue here which was the need to create a
new WG. Moreover, the charter of the new WG as defined by Cheng-Yin Lee did not
mention anything about a new protocol, if I got it right. However, I could not
help myself to express that if a new protocol could be designed having in mind
a
clearly defined application domain (and I have to give my credits to
Hoolbrook&Cheriton for Express in what concerns Internet TV) that would seem
advantageous for the multicast routing challenge. Interactive applications
(where most sources are receivers and there can be many) is probably an
inspiring domain both from a technical and business point of view (after all
deep inside of every computer user there is always a "games-freak" teenager ;-)
Maria
> ubject:
> Re: Work Proposal
> Date:
> Wed, 19 May 1999 12:08:43 -0400
> From:
> Cheng-Yin Lee <leecy@nortelnetworks.com>
> To:
> "sm-interest@cs.ucl.ac.uk" <sm-interest@cs.ucl.ac.uk>
>
>
>
>
> Jon suggested timescales as well, so here is a strawman proposal
>
> The primary goal of the group is to develop specifications that will ease
> the scaling (in the longer term) of current multicast routing protocols
> targeted for these type of applications:
> * Internet wide information distribution (eg 'webcast', content
> subscription/distribution)
> * Internet wide interactive information exchange (eg
> conferencing/discussion, games).
>
> The approach taken will allow the root (source or core) of the multicast
> distribution tree to allocate logical addresses that can be used to
> address multicast groups. Since address management is local to the root, it
> will not require Internet wide coordination and will also facilitate
> applications to use the address space in a creative and application
> specific manner (eg content filtering/naming, layered data) where
> applicable.
>
> The scope of work is as follows:
>
> * extend the current multicast API to use this new addressing
> - the group multicast address will consist of both the root (source or
> core) of the multicast tree and a
> multicast address.
>
> * extend the current multicast data forwarding to forward based on
> <root, multicast address>.
> The address encoding should allow :
> - routers which do not understand this new addressing to forward packets
> non natively (unicast)
> - current hardware to forward packet with this new addressing when the
> root is the source of the multicast group in the initial implementation
> and deployment,
> - for hardware to be upgraded to forward packet with the core as root.
>
> * changes to control messages will be defined generically in TLV format.
> The group will coordinate with the respective WGs for these to be
> implemented in PIM/CBT/BGMP.
>
> * migration/interoperability issues related to the above
>
> Goals and Milestones:
>
> Jul 99 Charter WG and specify goals and deliverables
> Oct 99 Issue first Internet-Draft on extensions to IP multicast
> Dec 99 Achieve concensus on the extensions
> Mar 00 Issue detailed specifications on host and router extensions
> Nov 00 Submit specifications to IESG as proposed standards
>
> Reference:
> * "Multicast Requirements for the Definition of New IP Multicast
> Services"
> Christophe Diot, Bryan Lyles, Sprint ATL
> Brian Neil Levine, Consultant, Sprint ATL
> Ramanan Shanmugam, Amir Tabdili, Hassan Kassem, Sprintlink
>
>