Philippe Dax
Pièce C218
dax@inf.enst.fr

Memoire CASI: MALLOC

Description

Aujourd'hui, le seul moyen valable et cohérent pour une application utilisant l'IP Multicast, d'obtenir une adresse de groupe, parmi les 450 millions disponibles, est d'utiliser l'annonceur de sessions sdr sur le réseau iMBone (Multicast Bone). Cet annonceur choisit une adresse aléatoirement dans des plages d'adresses réservées aux différents médias (audio, vidéo, tableau partagé, ...) et ceci pour un scope (ttl) donné: site, pays, continent, monde. Cette adresse est alors diffusée par le protocole SAP (Session Announcement Protocol) à tous les sdr dans le même scope, ainsi que la description de la session formatée selon SDP (Session Description Protocol). Cette annonce permet donc à n'importe qui de joindre l'application visible dans le scope donné.

Cependant, avec l'arrivée de nouvelles applications qui utilisent plusieurs canaux multicast (DIS, jeux distribués, hiérarchie de flots,...), il est nécessaire d'obtenir dynamiquement des adresses multicast temporaires sans faire appel à sdr qui l'afficherait à tord au milieux des annonces générales.

C'est pour cette raison qu'un groupe de travail de l'IETF (Internet Engineering Task Force) dénommé MALLOC s'est créé pour résoudre ce problème.

Le travail demandé dans ce mémoire consiste en une étude bibliographique suivie d'un développement.

La première phase, éventuellement précédée d'un état de l'Art, sera orientée bibliographie autour de l'architecture des protocoles.
Elle consiste à étudier les différents protocoles qui sont proposés dans le groupe MALLOC, à savoir: MADCAP (Multicast Address Dynamic Client Allocation Protocol) inspiré de DHCP entre l'application cliente et un serveur MAAS (Multicast Address Allocation Server), AAP (Address Allocation Protocol) inspiré de SAP entre les serveurs MAAS et MASC (Multicast Address Set Claim) entre les serveurs MAAS et les serveurs MASC.

La seconde phase constite à implémenter un petit serveur MAAS, selon l'API proposée dans un draft, de façon à gérer les requêtes unicast MADCAP des applications clientes et gérer les échanges AAP d'informations entre plusieurs serveurs MAAS, sans se préoccuper des serveurs MASC pour le moment, à moins que... :-)