Servizio Comunitario di Informazione in materia di Ricerca e Sviluppo - CORDIS

FP5

6NET Sintesi della relazione

Project ID: IST-2001-32603
Finanziato nell'ambito di: FP5-IST
Paese: France

Examination of the issue of IPv6 interdomain multicast and source discovery for multisource SSM applications

The SSM architecture is now well understood. PIM-SM for SSM and IPv6 is available on most routers as is MLDv2. On the client side, MLDv2 is still lacking on Windows OS, but should be available with the next (Longhorn) version. In the core of the network, SSM is much simpler to operate than ASM since it needs no RP and no additional protocol such as MSDP. Moreover these ASM mechanisms can be the target of DDoS attacks, whereas SSM seems more robust. By design there is no need for complex address allocations mechanisms since an SSM address must be unique for a given source only. Similarly it is easy to do source control since only one source may send in a channel.

For multiparty applications, there is a need to use either session relay where all sources send to an applicative relay that forwards data in an SSM channel, or to have some intra session source announcement. We have shown that with tools such as ssmsdp, it is possible to keep the same source discovery service at the application level, while using SSM only in the network. Moreover, this can be done with a very minor modification to existing ASM applications. New functionalities
could easily be introduced in the controller (floor control).

One potential problem with this proposition is scalability in terms of sessions or sources. We have seen that this is not a problem, at least for sessions with a few hundred sources. One problem sometimes mentioned is the number of states that have to be maintained in routers if each source has its own tree. However this is not very different from ASM, since a source tree is usually constructed for each active source.

Another potential problem with SSM only is service discovery (or session announcement) using multicast, such as session announcements with sdr/SAP since this makes use of an ASM group that has no clear owner (hence no controller). Propositions such as sas can be used in this case. This should probably be extended to a hierarchical version for scalability reasons. In any case different tools are probably needed for different types of applications (TV channels, network games, videoconferencing).

On the host side, MLDv2 is not yet widely available (Linux or BSD with Kame patch), it is still missing for Windows and MacOS, but should be available in the Longhorn release of Windows. As far as applications are concerned, we have seen that ASM applications can be easily ported to SSM: relatively straightforward for single source applications, quite easy for multiparty applications when using ssmsdp. Reliable multicast can make use of a unidirectional channel when using FEC, as with
Flute.

Concerning flow and congestion control, solutions are available with layering and mechanisms such as FLID. They can be used both for video transmission and for reliable transfer. Some improvements are probably needed to guarantee a faster convergence and an improved fairness between flows. However a good TCP friendliness seems to be achieved, at least for connections with small RTTs. Eventually, all SSM applications (except very low bandwidth ones) should have this type of congestion control.

On the other hand there is still a lack in management tools for multicast in general and particularly for SSM over IPv6 in an inter-domain context. Tools such as ssmping or beacons are a first answer to check connectivity but they are not sufficient to locate connectivity problems precisely. Tools such as mtrace6 (mtrace is available for IPv4) or tracetree would be useful. Also Mibs allowing to remotely monitor an IPv6 multicast network are needed.

In conclusion we can say that SSM over IPv6 seems a very attractive solution for multicast, particularly at the inter-domain level. Almost all building blocks are there, waiting for some popular applications.

Contatto

Jean-Jacques PANSIOT, (Head of Unit)
Tel.: +33-3-90244563
Fax: +33-3-90244455
E-mail