In einer eMail vom 27.11.2009 19:28:17 Westeuropäische Normalzeit schreibt [email protected]:
> In einer eMail vom 26.11.2009 02:35:49 Westeuropäische Normalzeit > schreibt [email protected]: > Did anyone indicate if multicast was a fundamental requirement or > fundamental component? > > Dino > > > Multicast: It strikes me that multicast has never been a topic for > RRG discussion, although it is mainly a routing issue. I would like to know if the RRG is going to recommend an architecture that explicitly says it won't include multicast, or it will implicitly include it but lack any reference to how it will scale. But I do think "multicast" is "routing". Totally in sync. > State-less multicast would be a valuable topic, I thought 3 years > ago when I tried to launch a respective EU-ICT project which was > rated to be "very poor" (not only simple "poor" as was NIRA). > > However, state-less multicast can be done by changing the multicast > philosophy. Multicast must adjust, and not the routing architecture. > Will say, it can be accomplished with the current BGP as well. > Nevertheless, the combination "state-less multicast + location-based > routing" might be even more beneficial. E.g. inspire future research > work as to minimize the hereby accepted disadvantages/costs. What the RRG could recommend is that we don't support a native multicast architecture in the core but the edges could run multicast as defined today but the edges would perform "replicated unicast". Yes, replicated unicast ! My idea was: building a cascade tree of unicasts for sake of multicasting towards millions of receivers in a most economical way: To catch the basic idea: the sender sends the data to 10 receivers (or their proxies), which in return send them to 10 further receivers etc. Given that each party gets the same list of participants it will be able to identify its 10 successors based on its own position inside this list. Furthermore: the degree 10 might not be sufficient if there are only m branching-capable nodes while n>>m receivers are to be serviced.So I was able to compute the adequate "degree of cascading" and also to compute the adequate positions of the branching-capable nodes inside this list of participants. Effectively, there is only unicast between any two branching capable nodes, and let's say 90 % of the receivers are stupid ones being leaves of the cascade tree. Disadvantage: via the same physical link several copies of the same packet might be forwarded. Advantage: states are required just at a minority of branching-nodes.Combined with location-aware routing the disadvantage might be reduced eventually upon further study. I provide references to a "replicated unicast" at the network layer as well as attaching doing core based native replication as in LISP- Multicast. Dino I will read the sent draft in the coming days. Heiner
_______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
