SIP

1



Le protocole SIP et la gestion des sources dynamiques dans une session de groupe



Présenté par :



Mathieu Sengelé



Lieu du stage : Laboratoire LSIIT Université Louis Pasteur Pôle API, Bd Sébastien Brant 67400 ILLKIRCH



Stage de DEA d’informatique Sous la direction de Jean-Jacques Pansiot Professeur Mickaël Hoerdt Doctorant



2



Remerciements

Je tiens tout d’abord à remercier l’ensemble des membres de l’équipe Réseaux et Protocoles du LSIIT pour m’avoir accueilli au sein de leur équipe ainsi que pour leur sympathie. Je remercie plus particulièrement Jean-Jacques Pansiot et Mickaël Hoerdt pour leurs réponses à mes questions ainsi que pour leurs réunions toujours constructives. Ils ont su guider mon travail tout au long de ce stage. Je tiens également à remercier mes amis de la promo de DEA sans qui cette année ne se serait pas déroulée dans la même ambiance. Je les remercie également pour le "traditionnel" moment de défoulement sur le terrain de basket après le repas. Enfin, je remercie toutes les personnes qui m’ont soutenu durant ce stage ainsi que celles qui m’ont aidé pour la relecture et la correction de ce mémoire.



3



4



Table des matières

1 2 Introduction Les modèles de communication de groupe 2.1 Avantage du multicast . . . . . . . . . . . . . . . . . . . . . 2.2 Typologie des applications de groupe . . . . . . . . . . . . . 2.2.1 Ouverture et fermeture de groupe : . . . . . . . . . . 2.2.2 Portée d’une application : . . . . . . . . . . . . . . 2.2.3 Trois catégories générales d’applications de groupe : 2.3 Any Source Multicast (ASM) . . . . . . . . . . . . . . . . . 2.3.1 Définition . . . . . . . . . . . . . . . . . . . . . . . 2.3.2 Avantages . . . . . . . . . . . . . . . . . . . . . . . 2.3.3 Inconvénients . . . . . . . . . . . . . . . . . . . . . 2.4 Single Source Multicast (SSM) . . . . . . . . . . . . . . . . 2.4.1 Définition . . . . . . . . . . . . . . . . . . . . . . . 2.4.2 Avantages . . . . . . . . . . . . . . . . . . . . . . . 2.4.3 Inconvénients . . . . . . . . . . . . . . . . . . . . . 2.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 11 13 13 14 14 15 15 16 16 16 17 18 18 19 19 20 21 21 21 22 23 23 25 25 25 26 26 27 28



. . . . . . . . . . . . . .



. . . . . . . . . . . . . .



. . . . . . . . . . . . . .



. . . . . . . . . . . . . .



. . . . . . . . . . . . . .



. . . . . . . . . . . . . .



. . . . . . . . . . . . . .



. . . . . . . . . . . . . .



. . . . . . . . . . . . . .



. . . . . . . . . . . . . .



3



SSM et le multi source dynamique 3.1 Modification de RTP/RTCP . . . . . . . . . . . . . . . . . . . 3.1.1 Principe . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.2 Mécanismes . . . . . . . . . . . . . . . . . . . . . . . 3.1.3 Problèmes . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Single Source Multicast Source Discovery Protocol (SSMSDP) 3.3 Autres propositions . . . . . . . . . . . . . . . . . . . . . . . 3.3.1 Annuaire de sessions multicast . . . . . . . . . . . . . 3.3.1.1 Principe : . . . . . . . . . . . . . . . . . . . 3.3.1.2 Problèmes : . . . . . . . . . . . . . . . . . 3.3.2 Utilisation de proxies SSM . . . . . . . . . . . . . . . 3.3.3 Protocole de routage . . . . . . . . . . . . . . . . . . 3.4 Problèmes et limites . . . . . . . . . . . . . . . . . . . . . . . 5



. . . . . . . . . . . .



. . . . . . . . . . . .



. . . . . . . . . . . .



. . . . . . . . . . . .



. . . . . . . . . . . .



. . . . . . . . . . . .



. . . . . . . . . . . .



. . . . . . . . . . . .



. . . . . . . . . . . .



6 4



TABLE DES MATIÈRES

Session Initiation Protocol (SIP) 4.1 Présentation . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.1 Sémantique . . . . . . . . . . . . . . . . . . . . . . . 4.1.2 Mécanismes . . . . . . . . . . . . . . . . . . . . . . . 4.1.3 Domaine d’application . . . . . . . . . . . . . . . . . 4.2 Utilisation de SIP dans des conférences . . . . . . . . . . . . 4.3 Intérêt dans le cadre de la signalisation d’une session multicast 29 29 29 31 34 35 36 39 39 39 40 40 40 42 43 43 44 45 46 47 47 47 48 49 51 53



. . . . . .



. . . . . .



. . . . . .



. . . . . .



. . . . . .



. . . . . .



. . . . . .



. . . . . .



. . . . . .



5



SIP et le multi source dynamique 5.1 Architecture et mécanismes nécessaires . . . . . . . . . . . . . 5.1.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . 5.1.2 Mécanismes . . . . . . . . . . . . . . . . . . . . . . . . 5.1.2.1 Interactions : . . . . . . . . . . . . . . . . . . 5.1.2.2 Détection de sources annoncées inutilement : . 5.1.2.3 Gestion d’une politique de session : . . . . . . 5.2 Discussion sur l’utilisation de SIP . . . . . . . . . . . . . . . . 5.2.1 Interactions Source - Contrôleur . . . . . . . . . . . . . 5.2.2 Interactions Contrôleur - Membres du canal de contrôle . 5.2.3 Mécanismes supplémentaires . . . . . . . . . . . . . . . 5.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . .



. . . . . . . . . . .



. . . . . . . . . . .



. . . . . . . . . . .



. . . . . . . . . . .



. . . . . . . . . . .



. . . . . . . . . . .



. . . . . . . . . . .



. . . . . . . . . . .



6



Proposition 6.1 Mécanismes de résolution de l’URI . . . . . . . . . . . . . . . . . 6.1.1 Déclaration d’une source . . . . . . . . . . . . . . . . . . . 6.1.2 Adhésion au groupe . . . . . . . . . . . . . . . . . . . . . 6.2 Mécanisme de mise en place dynamique de contrôleurs secondaires 6.3 Méthode Hybride (SIP-SSMSDP) . . . . . . . . . . . . . . . . . . Perspectives et conclusion



. . . . .



. . . . .



. . . . .



. . . . .



. . . . .



. . . . .



7



Table des figures

1.1 2.1 2.2 2.3 2.4 3.1 3.2 4.1 4.2 4.3 4.4 5.1 5.2 6.1 6.2 6.3 6.4 Pile de protocoles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Comparatif distribution Unicast et Multicast Illustration d’une application de type M to 1 Architecture ASM . . . . . . . . . . . . . . Architecture SSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 14 16 17 18 22 24 30 32 34 36 42 43 47 49 50 52



Architecture "Session Relaying" . . . . . . . . . . . . . . . . . . . . . . . . . Architecture "Sender Advertisement" . . . . . . . . . . . . . . . . . . . . . . Structure d’un Agent SIP (UA) . . . . . Illustration d’une session SIP . . . . . . Fonctionnement d’un REGISTRAR SIP Architecture pour les conférences SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .



Mécanisme de requête probabiliste . . . . . . . . . . . . . . . . . . . . . . . . Interactions entre source et contrôleur . . . . . . . . . . . . . . . . . . . . . . Adhésion d’une source au groupe . . . . . . . . . . . . Adhésion d’un membre au groupe . . . . . . . . . . . Mécanisme de mise en place de contrôleurs secondaires Architecture générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .



7



8



TABLE DES FIGURES



Liste des tableaux

4.1 4.2 Les différents types de requêtes SIP . . . . . . . . . . . . . . . . . . . . . . . Les classes de réponses SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 31



9



10



LISTE DES TABLEAUX



Chapitre 1



Introduction

Le multicast est un service réseau permettant la diffusion de messages vers un nombre élevé de récepteurs et cela sans surcoût en bande passante pour l’émetteur. Le réseau et les protocoles de routage se chargent de faire parvenir les messages à l’ensemble des récepteurs et ce de façon transparente pour l’émetteur. Ce service est, de par l’intégration du multicast dans les nouveaux routeurs, de plus en plus répandu dans l’Internet. L’enjeu majeur pour l’explosion de ce service à grande échelle est la mise en place d’un protocole de signalisation nécessaire à la gestion du multicast à l’échelle d’Internet. Ce protocole doit permettre à un nombre illimité de récepteurs de recevoir les données d’une ou plusieurs source(s) et cela sans aucune restriction au niveau de la localisation dans le réseau. Pour cela, nous avons au cours de ce stage de DEA étudié la signalisation utilisée pour la gestion de sessions de groupe. La Figure 1.1 représente les différentes couches auxquelles nous nous sommes intéressé.



F IG . 1.1 – Pile de protocoles Nous allons dans le Chapitre 2 détailler les différents modèles de groupes existants. Le modèle SSM qui est considéré par la communauté scientifique comme une solution applicable à 11



12



CHAPITRE 1. INTRODUCTION



l’échelle d’Internet, ne supporte cependant qu’une seule source. La définition de nouveaux mécanismes et protocoles de signalisation est donc nécessaire si l’on souhaite utiliser le modèle SSM dans le cadre d’une communication de groupe avec des sources multiples. Une étude des propositions existantes permettant d’utiliser SSM avec plusieurs sources est effectuée dans le Chapitre 3. Dans le Chapitre 4, nous nous intéressons au protocole de signalisation SIP qui est largement utilisé dans les applications de type téléphonie. Nous allons ensuite dans le Chapitre 5 étudier s’il est possible de tirer avantage des mécanismes dont le protocole SIP dispose dans le cadre d’une application de groupe. Enfin, dans le Chapitre 6 nous présenterons notre proposition qui permet la gestion d’une session de groupe avec des sources multiples. Cette proposition apporte un mécanisme permettant de définir plusieurs contrôleurs de groupe multicast de façon dynamique et cela, grâce à l’utilisation du degré d’indirection supplémentaire que le protocole SIP apporte.



Chapitre 2



Les modèles de communication de groupe

2.1 Avantage du multicast

Le multicast est un service réseau offrant la possibilité d’envoyer un message vers un nombre illimité de récepteurs potentiels. Au contraire de l’unicast où l’envoi d’un même message d’une source vers N récepteurs nécessiterait N connexions TCP et demanderait à ce que la source émette N fois les données, le multicast permet à la source de n’envoyer qu’une seule fois le flux de données et c’est le protocole multicast sous-jacent qui va gérer la duplication et distribution des paquets à l’ensemble des membres de la session multicast. La source n’émettant qu’une seule fois les données, ce service permet une économie importante de bande passante et il ne demande pas à la source d’avoir connaissance de l’ensemble des récepteurs des données qu’elle envoie. La Figure 2.1 illustre parfaitement cette économie de bande passante que le service multicast apporte. Dans cet exemple, la source émet des données vers trois récepteurs (A, B et C). En unicast la source doit émettre trois fois les mêmes données alors qu’en multicast la source n’émet qu’une seule fois ses données et c’est le support réseaux ainsi que le protocole de routage qui vont distribuer les données à l’ensemble des membres du groupe multicast. Un groupe multicast est constitué de N sources, M récepteurs et possède un identifiant de groupe devant être connu par un hôte souhaitant émettre des données vers ce groupe ou en recevoir. Le choix du protocole de transport utilisé dans un groupe multicast doit se faire en fonction des services désirés et du type de données à transmettre. Le multicast est parfaitement adapté pour toutes les applications nécessitant une communication de groupe comme par exemple une visioconférence, un streaming audio ou vidéo sur Internet, les jeux en réseaux,les mises à jours du portage d’une distribution linux vers l’ensemble de ses "mirrors" etc ...



13



14



CHAPITRE 2. LES MODÈLES DE COMMUNICATION DE GROUPE



F IG . 2.1 – Comparatif distribution Unicast et Multicast Deux modèles de communications de groupes ont été définis par la communauté de recherche et sont détaillés par la suite.



2.2 Typologie des applications de groupe

Avant de voir les deux modèles de communication de groupe, il est important de mettre en avant la diversité des applications de groupe. Les applications de groupe peuvent se différencier par exemple en terme de taille, dynamicité et portée de l’application. Le choix d’une architecture ou d’un protocole de signalisation plutôt qu’un autre doit donc se baser sur l’application visée et pas uniquement sur une représentation du problème au niveau de la couche réseaux. Il est donc nécessaire de définir certains critères de comparaison et d’effectuer une classification des types d’applications de groupe.



2.2.1 Ouverture et fermeture de groupe :

Dans un groupe ouvert, une source peut envoyer des données sans avoir besoin d’y adhérer au préalable. Cela permet donc à une source de commencer à émettre de façon plus rapide (disparition du temps de latence dû à l’adhésion au groupe avant d’émettre) mais une telle ouverture pose de façon évidente des problèmes de sécurité pour le groupe. Par opposition au groupe ouvert, dans un groupe fermé il est nécessaire d’adhérer au groupe avant de pouvoir y émettre des données. Cette approche induit un temps de latence avant l’émis-



2.2. TYPOLOGIE DES APPLICATIONS DE GROUPE



15



sion des données (temps nécessaire à l’adhésion au groupe) mais rajoute un degré de sécurité pour le groupe. Il est en effet possible dans un groupe fermé de refuser qu’une source donnée émette vers le groupe ; chose impossible dans un groupe ouvert. Le choix entre l’utilisation d’un groupe ouvert ou fermé peut donc simplement se faire en se basant sur des critères de degré de confiance du réseau visé et de degré de confidentialité des informations échangées. Par exemple utiliser un groupe ouvert pour une application interne au réseau d’une entreprise et un groupe fermé pour une application fonctionnant à l’échelle d’Internet.



2.2.2 Portée d’une application :

Un autre critère important dans le choix d’une architecture et d’un protocole de signalisation optimal est la portée de l’application considérée. La portée d’une application multicast représente son "rayon d’action". Cette portée peut être assez facilement définie en jouant sur le nombre de sauts qu’un paquet IP a le droit d’effectuer, plus ce nombre de sauts est petit et plus l’application à un domaine d’action restreint. On peut très bien imaginer utiliser des protocoles spécifiques pour des applications ayant une portée très limitée (protocoles plus "simples" mais plus coûteux qui ne sont donc pas applicables à grande échelle).



2.2.3 Trois catégories générales d’applications de groupe :

La taille du groupe ainsi que la dynamicité et le nombre de sources sont des critères permettant de distinguer plusieurs catégories générales d’applications de groupe. Trois catégories ont été définies dans [20] – One to Many (1 to M) : une unique source émet des données vers deux ou plusieurs récepteurs. Les streaming audio ou vidéo sont des applications de type One to Many. – Many to Many (M to M) : plusieurs sources émettent et reçoivent des données d’un même groupe multicast. Les applications de type vidéoconférence sont un exemple d’application de type Many to Many. – Many to One (M to 1) : des applications de type Many to One ont de nombreuses sources et un seul (ou un nombre faible) récepteur. Ces d’applications se basent généralement sur un système de requêtes/réponses. La figure 2.2 montre un exemple possible d’une application de ce type. Ces applications sont peu extensibles de par les messages multiples en destination d’un seul récepteur, ce récepteur étant un goulet d’étranglement. Le choix du protocole de signalisation et de l’architecture à utiliser doit donc se faire en fonction de l’ensemble des critères applicatifs décrits ci-dessus.



16



CHAPITRE 2. LES MODÈLES DE COMMUNICATION DE GROUPE



F IG . 2.2 – Illustration d’une application de type M to 1



2.3 Any Source Multicast (ASM)

2.3.1 Définition

Dans le modèle Any Source Multicast (ASM) [9] défini par Deering, chaque groupe est identifié par une adresse logique multicast G 1 . Ce modèle construit un arbre partagé et chaque membre du groupe peut potentiellement émettre des données vers l’ensemble des membres du groupe multicast G. Dans ce modèle, une source ne doit pas forcément être membre d’un groupe pour lui envoyer des données, on parle de groupe ouvert ("open group"). Pour adhérer à un groupe il est uniquement nécessaire d’en connaître l’adresse multicast G. L’architecture de ce modèle est représentée dans la Figure 2.3



2.3.2 Avantages

– dynamicité : de nouveaux membres peuvent joindre le groupe sans avoir à connaître d’autres membres de ce même groupe, seule la connaissance de l’adresse multicast du groupe est nécessaire. – "open group" : n’importe qui peut envoyer des données à un groupe, il n’est pas obligatoire d’en être membre. – aucune restriction topologique : les membres du groupe peuvent être situés n’importe où et un paquet envoyé vers un groupe G sera acheminé à tous les membres de ce groupe peu importe leur localisation. – différents types de groupes : les groupes multicast peuvent être temporaires ou bien permanents, une visioconférence par exemple utilisera une adresse de groupe multicast

1



classe d’adresse D : IP de 224.0.0.0 à 239.255.255.255



2.3. ANY SOURCE MULTICAST (ASM)



17



F IG . 2.3 – Architecture ASM temporaire car celle-ci ne durera pas très longtemps. Au contraire, une chaîne de télévision proposant un flux multicast sur Internet obtiendra une adresse de groupe permanente. – taille illimitée : d’un point de vue réseau il n’existe aucune restriction sur le nombre de récepteurs d’un groupe multicast, cependant cette extensibilité varie fortement suivant l’architecture ASM utilisée en pratique.



2.3.3 Inconvénients

Cependant l’implémentation de ce modèle à l’échelle d’Internet pose certains problèmes. L’un d’eux étant d’allouer de façon unique une adresse de groupe multicast. Le fait d’attribuer la même adresse multicast G à deux groupes G1 et G2 reviendrait à fusionner ces deux groupes. Ainsi, tous les messages à destination de G1 ou G2 seront reçus par tous les membres du groupe multicast G (donc par ceux de G1 et G2). Ce modèle comporte également certaines limites selon l’architecture utilisée pour sa mise en œuvre, par exemple une architecture de type PIM-DM n’est pas extensible de part le fait qu’elle utilise un mécanisme de type "flood and prune" tandis que les architectures basées sur un "core" comme PIM-SM ou CBT sont très sensibles aux pannes de ce "core". Le fait que ce modèle soit basé sur un groupe ouvert où tout le monde peut envoyer des données vers l’ensemble des membres du groupe sans avoir à être membre du groupe, pose des problèmes évidents de sécurité. On imagine aisément l’ampleur que peut avoir une simple attaque de type "Denial Of Service" vers un groupe multicast. Suivant les types d’architectures, il est possible d’utiliser les capacités de filtrage d’IGMPv3 [5] afin d’augmenter la sécurité. Pour obtenir une certaine sécurité il faudrait utiliser IGMPv3 en mode "INCLUDE" (c’est à dire



18



CHAPITRE 2. LES MODÈLES DE COMMUNICATION DE GROUPE



n’accepter que les messages en provenance d’adresses connues) ce qui reviendrait à "fermer" le groupe multicast ; ce qui va à l’encontre du modèle ASM tel qu’il a été décrit par Deering. Le modèle de Deering étant par définition basé sur un groupe ouvert, il faut donc mettre en œuvre des mécanismes permettant la découverte automatique des sources. Ces mécanismes sont assez complexes à appliquer à l’échelle d’Internet (en inter-domaine essentiellement).



2.4 Single Source Multicast (SSM)

2.4.1 Définition

Dans sa thèse [12], Hugh Holbrook définit le modèle SSM (Single Source Multicast). Dans ce protocole, un canal multicast est constitué d’une source, de N récepteurs et est identifié par le couple (S,G). Un arbre par source ayant comme racine la source du canal est construit. Les données circulent dans ce canal de manière UNIDIRECTIONNELLE de la source vers les récepteurs. S et G représentent respectivement l’IP de la source et l’adresse multicast du canal. Pour adhérer à un canal il suffit donc d’envoyer un message IGMPv3 "subscribe(S,G)" et un message "unsubscribe(S,G)" pour le quitter. Dans ce modèle, chaque récepteur adhère uniquement au canal dont il souhaite recevoir des données. La Figure 2.4 représente l’architecture du modèle SSM.



F IG . 2.4 – Architecture SSM



2.4. SINGLE SOURCE MULTICAST (SSM)



19



2.4.2 Avantages

Le modèle SSM élimine une partie des inconvénients du modèle ASM. Le fait d’utiliser le couple (S,G) pour représenter un canal SSM garantit de façon implicite l’unicité de l’identification du canal. En effet, S étant l’adresse IP de la source émettant sur le canal, plusieurs canaux SSM ayant même adresse multicast (G) seront différenciés par l’adresse IP de leur source (S). Dans le modèle SSM il est donc inutile de mettre en œuvre des mécanismes garantissant l’unicité d’un canal. Par opposition au modèle ASM qui se veut "open group", une seule source est autorisée à émettre sur un canal SSM ce qui garantit un niveau de sécurité bien plus important. De plus, la nécessité de connaître l’adresse multicast et l’adresse IP de la source avant d’adhérer à un canal implique une certaine sécurité et liberté de choix pour chaque hôte. Contrairement au modèle ASM où tous les membres d’un groupe reçoivent systématiquement tous les messages à destination du groupe, dans le modèle SSM chaque hôte doit explicitement adhérer au canal de chaque source dont il souhaite recevoir des données, ce qui permet à chaque hôte d’appliquer sa propre politique d’adhésion au canal.



2.4.3 Inconvénients

La nécessité de devoir connaître l’adresse IP source rend cependant ce modèle "statique" et peu approprié à une communication de type "many-to-many" avec sources dynamiques. Il est donc nécessaire de définir des mécanismes permettant de découvrir dynamiquement de nouvelles sources afin de pouvoir utiliser SSM dans des applications comportant plusieurs sources. Pour cela deux mécanismes (et une version hybride des deux) ont été définis par Holbrook : – Session Relaying : dans ce mécanisme, un des membres du canal multicast est le "session relay". Dès qu’un membre du canal souhaite émettre, il envoie un message unicast vers le "session relay" qui se chargera de diffuser ce message en multicast vers tous les membres du groupe. – Sender Advertisement : dans cette approche, un membre souhaitant émettre, envoie un message au "session coordinator" pour signaler son intention. Ce message sera relayé par le "session coordinator" à l’ensemble des membres du canal de contrôle qui vont, ou non, adhérer à ce nouveau canal. Il y a donc un canal SSM pour chaque source, ce qui fait qu’un récepteur reçoit uniquement des messages des canaux multicast auxquels il a adhéré. Ce mécanisme propose donc une meilleure gestion de la bande passante que le "session relaying" mais il génère une multiplication du nombre de canaux SSM (et donc d’état à maintenir dans les routeurs). Cette méthode comporte un temps de latence ("startup delay") avant qu’un canal soit effectivement actif. Cette latence est due au temps nécessaire



20



CHAPITRE 2. LES MODÈLES DE COMMUNICATION DE GROUPE

à la transmission des différents messages avant que les membres adhèrent au nouveau canal SSM. L’utilisation de cette méthode ne semble donc pas très appropriée pour des canaux ayant une durée de vie très courte. Un autre problème rencontré est l’annonce des sessions existantes aux membres du canal arrivés tardivement (élément essentiel si l’on veut tenir compte de la dynamicité des sources).



Dans ces deux approches, les "session relay" ou "session coordinator" peuvent refuser de relayer les données de sources non autorisées, ce qui apporte une certaine sécurité. Cependant les "session relay" et "session coordinator" sont les points sensibles de ces approches (pannes, attaques). SSM semble convenir parfaitement à une diffusion d’une source vers un nombre très important de récepteurs, tout en garantissant de façon implicite un niveau de sécurité beaucoup plus important qu’avec le modèle ASM. Dès lors que l’on veut utiliser SSM pour faire du multicast avec N sources dynamiques et N récepteurs dynamiques, le problème de l’absence de mécanisme de découverte des sources existantes se pose. Pour répondre à ce manque, plusieurs mécanismes ont été proposés et sont détaillés par la suite.



2.5 Conclusion

Ces deux modèles de communication de groupe possèdent leurs avantages et leurs inconvénients. Le modèle définit par Holbrook est considéré comme une solution pour un déploiement du multicast à grande échelle (Internet par exemple). Il manque cependant un mécanisme de découverte dynamique des sources afin que SSM puisse être utilisé dans les applications multicast à sources multiples. La communauté scientifique a donc cherché à mettre en œuvre les mécanismes proposés par Holbrook dans sa thèse afin d’apporter à SSM un mécanisme de découverte et d’annonce dynamique des sources. Dans la section 3.1 nous allons voir une solution basée sur le mécanisme de Session Relaying puis dans le paragraphe 3.2 nous verrons une solution utilisant le mécanisme de Sender Advertisement. D’autres solutions basées sur une nouvelle architecture ou bien encore sur un nouveau protocole de routage seront également détaillées dans la partie 3.3.



Chapitre 3



SSM et le multi source dynamique

3.1 Modification de RTP/RTCP

3.1.1 Principe

RTP est un Protocole de transfert de données en temps réel qui fonctionne au dessus d’UDP. Ce protocole numérote les paquets ce qui permet par exemple de reconstituer l’ordre d’envoi des paquets si ceux-ci arrivent avec un déséquencement. Ce protocole dispose également d’un mécanisme de contrôle appelé RTCP. Le principe de ce mécanisme de contrôle, est l’envoi périodique de paquets de contrôle de l’ensemble des participants d’une session ; dans le contexte d’une session multicast ces rapports permettent donc : – d’avoir un retour sur la qualité de service : la source peut connaître la qualité de réception de l’ensemble des membres de cette session. – de détecter et localiser les éventuelles congestions : ce qui peut par exemple permettre à la source d’une session multicast d’adapter le flux de ses données en fonction des éventuelles congestions. Cependant, la périodicité de l’envoi des rapports induit un temps de latence avant la détection des congestions. – de maintenir une liste de l’ensemble des participants de la session : tout membre de la session envoyant des messages de contrôle vers la source, celle-ci peut aisément connaître le nombre de membres de la session par exemple. Il faut définir la fréquence d’envoi des rapports RTCP afin que le protocole puisse être extensible à grande échelle. Typiquement la fréquence de ces rapports diminue avec l’augmentation du nombre de membres de la session. Dans leur article [7], Chesterfield et Schooler proposent de modifier RTP/RTCP [29] afin de 21



22



CHAPITRE 3. SSM ET LE MULTI SOURCE DYNAMIQUE



l’adapter à un environnement SSM.



F IG . 3.1 – Architecture "Session Relaying" La Figure 3.1 illustre l’architecture utilisée. Dans cette architecture, la source du canal SSM est le "session relay". Si un membre du canal SSM souhaite émettre des données vers l’ensemble des membres du groupe, il envoie ses données en unicast au session relay qui va les diffuser en multicast dans le canal SSM.



3.1.2 Mécanismes

Chesterfield et Schooler proposent donc de modifier ces mécanismes afin de les adapter à un environnement SSM. Le modèle SSM construit un arbre par source ayant comme racine la source du canal multicast et les données circulent de manière unidirectionnelle de la racine vers les feuilles dans cet arbre. Pour envoyer un message à tous les membres d’un canal SSM il suffit donc d’envoyer ce message en unicast à la source qui va le propager en multicast à l’ensemble des membres du groupe. De cette façon, tout membre d’un canal SSM reçoit des informations de l’ensemble des autres membres de ce même canal. Il faut cependant définir une méthode afin que la source relaye les messages de l’ensemble des membres du canal de façon optimale, sans générer de surconsommation de bande passante. Deux mécanismes son proposés par Chesterfield et Schooler : – "reflection" : la source envoie en multicast tous les rapports qu’elle reçoit. Cette méthode basique pose un problème évident de surconsommation de bande passante pour un canal ayant beaucoup de membres. – "summarisation" : la source fait un "résumé" de l’ensemble des rapports de tous les membres puis le diffuse en multicast sur le canal. Cette méthode est beaucoup plus économe en terme de bande passante mais elle pose tout de même certains problèmes comme



3.2. SINGLE SOURCE MULTICAST SOURCE DISCOVERY PROTOCOL (SSMSDP)

par exemple la nécessité de synchroniser les rapports des membres.



23



Une analyse des coûts en messages ainsi qu’un comparatif des deux mécanismes sont effectués dans [6]. Ces mécanismes permettent donc à l’ensemble des membres d’un canal multicast de recevoir des informations en provenance de tous les membres de ce même canal. Ces informations peuvent par exemple servir à un membre pour signaler aux autres qu’il va émettre des données. Cela permet donc d’utiliser SSM dans le cadre d’une communication avec plusieurs sources dynamiques.



3.1.3 Problèmes

Cette solution semble tout de même assez limitative tant sur le plan des applications concernées que sur le plan de l’extensibilité. En effet, ce mécanisme ne fonctionnant que dans les applications multicast supportant le protocole RTP/RTCP, cela revient à se limiter à un type d’applications données ce qui est assez restrictif. Le fait que tous les messages (la signalisation et les données) passent par la source pour ensuite être relayés, nécessite que la source soit robuste et qu’elle ait une bande passante importante. Cela induit forcément des limites assez fortes d’extensibilité car la quantité de messages à relayer augmente avec le nombre de sources. Ce mécanisme induit également un temps de latence avant d’obtenir des informations des autres membres du canal, cette latence est due à la périodicité des rapports.



3.2 Single Source Multicast Source Discovery Protocol (SSMSDP)

Dans cette approche, un protocole [4] est défini et implémenté [11], ce protocole permet la découverte de sources pour les applications à sources multiples en se basant sur le modèle SSM. Les interactions nécessaires à la découverte et l’annonce de nouvelles sources sont également décrites. L’architecture utilisée est représentée dans la Figure 3.2. Un canal de contrôle est utilisé pour annoncer les sources actives. La source de ce canal de contrôle est appelée contrôleur. Ce contrôleur reçoit des messages d’annonce de différentes sources et les propage en multicast dans le canal de contrôle tout en maintenant à jour une table contenant l’ensemble des sources qu’il connaît. Chaque source émet des données sur son propre canal SSM, les informations nécessaires à l’adhésion à ces canaux sont diffusées par le contrôleur dans le canal de contrôle.



24



CHAPITRE 3. SSM ET LE MULTI SOURCE DYNAMIQUE



Les membres du canal de contrôle obtiennent donc une liste des sources actives et les données nécessaires afin de pouvoir adhérer aux canaux SSM.



F IG . 3.2 – Architecture "Sender Advertisement" Les messages utilisés sont : – ON(SRC,M) : ce message est envoyé par une source au contrôleur pour signaler son existence et le contrôleur se charge de propager ce message aux membres du canal de contrôle qui vont adhérer au canal s’ils le souhaitent (JOIN(SRC,M)). Ce message est envoyé de façon périodique par chaque source au contrôleur qui maintient à jour un timer pour chaque message ON. Si le timer arrive à expiration le contrôleur considère que la source n’émet plus de données. – OFF((S,G),(SRC,M)) : avec ce message une source SRC signale au contrôleur S qu’elle va cesser d’émettre des données, ce message est envoyé à tous les membres du canal de contrôle (S,G) afin de signaler l’arrêt du canal (SRC,M). – IN F OREQ : ce message peut être envoyé par un membre du canal de contrôle au contrôleur afin d’obtenir la liste de toutes les sources actives connues. Le contrôleur va renvoyer cette liste dans un message IN F ORESP . Cela permet à un nouveau membre du canal de contrôle de connaître rapidement toutes les sources sans avoir à attendre le prochain envoi périodique des messages ON. En plus des messages utilisés pour la découverte et la détection de la disparition de sources, ce protocole propose également certains messages optionnels de contrôle de sources. Le contrôleur peut placer différents "flags" dans la table qu’il maintient à jour pour chaque source. Ces flags sont par exemple : – KICKED : lorsque le contrôleur reçoit un message ON d’une source qui est marquée



3.3. AUTRES PROPOSITIONS



25



KICKED dans sa table, celui-ci ne propage pas le message vers les membres du canal de contrôle. Le contrôleur peut passer une source en statut KICKED, pour cela il n’a qu’à placer le flag KICKED dans sa table et propager un message KICK à l’ensemble des membres du canal de contrôle signalant que la source est indésirable. Inversement, retirer le statut KICKED d’une source revient simplement à retirer le flag dans la table du contrôleur et propager un message ON sur le canal pour annoncer la source aux membres du canal de contrôle. – MUTED : ce mécanisme est moins violent que le KICK car dans ce cas, le contrôleur envoie simplement un message MUTE à la source ne devant plus émettre de données. Cette source en recevant ce message cesse d’émettre jusqu’à réception d’un message UNMUTE. Des timers associés à ces messages sont déclenchés par la source et le contrôleur pour maintenir leur validité. Ce protocole propose donc une solution au problème de découverte de sources dans un réseau SSM en se basant sur le mécanisme de Sender Advertisement proposé par Holbrook dans sa thèse [12]. Une nouvelle signalisation est définie afin de gérer les différentes interactions entre sources, contrôleur et membres du canal de contrôle. L’utilisation des mécanismes KICK et MUTE permet également de mettre en œuvre une politique d’annonce des sources et de signaler à l’ensemble des membres du canal de contrôle qu’une source est devenue indésirable. L’architecture basée sur le mécanisme de Sender Advertisement est cependant fortement vulnérable aux pannes du contrôleur (tout comme le mécanisme de Session Relayiong est sensible aux pannes du "session relay"). On voit aisément que tout le mécanisme d’annonce des sessions multicast s’écroule en cas de défaillance du contrôleur. Des mécanismes beaucoup plus tolérants aux pannes ont donc vu le jour. Dans la section 3.3.1 nous verrons une proposition se basant sur la mise en place d’une hiérarchie de serveurs définissant un annuaire de sessions multicast (idée fortement similaire au mécanisme de DNS) puis dans le paragraphe 3.3.3 une proposition intégrant le support des sources multiples SSM au niveau de la couche réseau sera présentée.



3.3 Autres propositions

3.3.1 Annuaire de sessions multicast

3.3.1.1 Principe :



Dans [3], une nouvelle architecture afin de pouvoir annoncer des canaux SSM en inter domaine est décrite (une idée similaire est proposée dans [25]). Une hiérarchie de "Channel Reflector" est définie et permet de mettre en œuvre un système d’annuaire de sessions multicast à l’échelle d’Internet



26



CHAPITRE 3. SSM ET LE MULTI SOURCE DYNAMIQUE



Leur architecture est basée sur une hiérarchie de CRs dépendant d’un CR primaire ayant connaissance de l’ensemble des CRs à l’échelle d’Internet ; les autres CR ont simplement une connaissance locale des canaux SSM existants. Les informations sur de nouveaux canaux SSM sont donc propagées dans cette architecture de CR (propagation hop-by-hop entre les CRs, le multicast n’est pas utilisé pour cela). La hiérarchie utilisée permet également de définir une portée pour chaque canal SSM (i.e. un domaine au-delà duquel l’annonce ne sera pas diffusée au CR suivant) ce qui permet d’éviter d’annoncer des canaux SSM à l’échelle d’Internet alors que l’on sait pertinemment que ces canaux seront restreints à des domaines bien précis (des vidéo conférences internes à une société par exemple). L’avantage d’un tel système est qu’il est transparent aux utilisateurs finaux et qu’il ne demande pas de changement de protocole. Un utilisateur final n’a qu’à contacter le CR de son domaine afin de connaître l’ensemble des canaux multicast existants sur son domaine. L’autre avantage de ce système est qu’il apporte un rayon de portée pour chaque canal SSM.



3.3.1.2



Problèmes :



Ce nouveau système d’annuaire de sessions soulève de nombreuses interrogations en ce qui concerne : – la cohérence : on imagine très bien la difficulté et le coût en bande passante que la synchronisation entre les différents CR peut potentiellement demander si l’on souhaite maintenir une cohérence des annonces à l’échelle d’Internet – le déploiement : le déploiement d’un tel système demande également certains efforts car chaque AS (Autonomous System) ou domaine doit mettre en place son propre CR. – la tolérance aux pannes : le CR primaire doit être robuste et on peut se demander comment le système réagirait en cas de panne d’un CR. – la sécurité : on peut très bien imaginer qu’un faux CR puisse potentiellement inonder tout ce système de fausses annonces de canaux SSM. Il faut donc également mettre en œuvre des mécanismes d’authentification des CRs.



3.3.2 Utilisation de proxies SSM

Dans [31], Zappala et Fabbri proposent d’utiliser des proxies SSM afin de gérer les applications comportant des sources multiples. Dans leur approche, le créateur d’un groupe SSM (donc la source) peut autoriser certains autres nœuds à jouer le rôle de proxy pour le groupe. Un groupe SSM est donc identifié par



3.3. AUTRES PROPOSITIONS



27



(S1,G1) et une liste de proxy (P1, P2 etc... avec P1=S1 étant le canal principal). Avec ce système, un groupe SSM est constitué de plusieurs canaux SSM, un canal principal ayant comme racine la source du groupe SSM puis un sous canal SSM pour chaque proxy ayant autorité sur le groupe. La source et les proxies s’échangent des données via des canaux SSM (un pour chaque proxy et un pour la source) puis ces données sont ensuite diffusées en multicast par chaque proxy aux membres de leurs propres canaux SSM (de même pour la source qui diffuse les données sur son canal principal). Le canal principal permet aux récepteurs ne supportant pas les proxies d’adhérer de façon "classique" au canal SSM principal. Adhérer à un groupe revient dans ce cas à adhérer au canal SSM ayant pour racine le créateur du groupe ou à l’un des canaux ayant pour racine un proxy autoritaire pour le groupe. L’avantage est que chaque nouveau membre peut choisir à quel canal il va adhérer, il peut donc par exemple choisir le proxy "le plus proche" (choisi en fonction du temps de réponse au ping par exemple) plutôt qu’adhérer systématiquement à la source du canal SSM qui peut être très éloignée. De façon similaire, émettre des données revient à les envoyer au proxy choisit qui les diffusera à l’ensemble des autres proxies qui vont par la suite les diffuser à l’ensemble des membres de leurs canaux SSM respectifs. Cette approche se révèle plutôt efficace lorsque les proxies sont bien choisis et bien situés par rapport aux membres du canal SSM. L’utilisation de proxies ne va rien apporter s’ils sont trop peu nombreux et "éloignés" de l’ensemble des membres du canal . Le choix du nombre de proxies à utiliser ainsi que leur localisation reste un problème assez complexe à solutionner, d’autant plus, que les groupes multicast sont par définition dynamiques, ce qui implique que le nombre de proxies doit également l’être au cours de la session. On peut également se demander si un tel mécanisme ne va pas augmenter de façon importante le nombre de canaux SSM.



3.3.3 Protocole de routage

Dans [26], il est proposé d’intégrer le support de sources multiples dans SSM directement au niveau de la couche réseau. Placer le support de sources multiples au niveau de la couche réseau rend ceci totalement transparent aux couches supérieures et donc utilisable quelle que soit l’application et le protocole de signalisation. L’idée est de mettre en place un mécanisme permettant au propriétaire du canal SSM (la source) d’autoriser de nouvelles sources à émettre dans le canal. Le propriétaire du canal propage alors un message qui va modifier les entrées dans les routeurs, ce qui va permettre à la nouvelle source d’émettre dans le canal. L’arbre unidirectionnel "classique" SSM devient en quelque sorte un arbre bidirectionnel pour les sources autorisées.



28



CHAPITRE 3. SSM ET LE MULTI SOURCE DYNAMIQUE



Cette idée semble être une solution élégante au problème du support de sources multiples dans une session SSM où toute la charge est laissée à la couche réseau. Cependant, cette solution nécessite des efforts de déploiement car il faudrait que l’ensemble des routeurs d’Internet supporte ce nouveau protocole. Même si les résultats expérimentaux montrent qu’en agrégeant les états les tables de routage n’augmentent pas de façon linéaire avec l’augmentation du nombre de sources. On peut tout de même se demander si cette approche ne risque pas de surcharger les tables de routages des routeurs d’Internet si cette extension SSM est déployée.



3.4 Problèmes et limites

De nombreuses solutions ont été proposées afin d’intégrer à SSM un mécanisme de découverte et d’annonce dynamique de sources. Ces solutions possèdent cependant toutes certaines limites et soulèvent certains problèmes quant à leurs déploiements éventuels. Ainsi, la modification de RTP/RTCP détaillée dans le paragraphe 3.1 soulève le problème de la robustesse du canal de retour et de la source. Cela pose un problème d’extensibilité étant donné que le trafic va augmenter avec le nombre de sources. Les solutions basées sur la mise en place d’une nouvelle architecture ou encore sur la modification des protocoles de routage présentées dans la section 3.3 nécessiteraient d’importants efforts de déploiement. La solution présentée dans le paragraphe 3.2 ne connaît pas ces deux problèmes d’extensibilité ou de déploiement mais toute l’architecture utilisée repose essentiellement sur un contrôleur, ce qui la rend très vulnérable et dépendante aux pannes de ce contrôleur. Il semble donc intéressant de mettre en œuvre un mécanisme permettant par exemple de définir des contrôleurs secondaires et ce de façon dynamique. Pour cela, nous allons dans un premier temps présenter de façon détaillée le protocole SIP [24] dans le Chapitre 4 pour ensuite montrer dans le Chapitre 6 ce que SIP apporte à l’annonce de sources dynamiques dans une session de groupe basée sur le modèle SSM.



Chapitre 4



Session Initiation Protocol (SIP)

4.1 Présentation

Le protocole SIP [24] est un protocole largement utilisé, essentiellement pour des applications de type téléphonie sur IP. Il fournit les mécanismes nécessaires à l’ouverture et à la fermeture d’une session.



4.1.1 Sémantique

Avant d’étudier de façon plus détaillée le fonctionnement de ce protocole, il est nécessaire d’expliquer la terminologie qui sera utilisée par la suite ainsi que présenter le type de requêtes et leurs significations. – Session : une session multimédia est constituée d’un ensemble d’émetteurs et de récepteurs multimédia avec des données circulant des émetteurs vers les récepteurs. – User Agent Client (UAC) : entité générant puis envoyant des requêtes. Ce rôle est ponctuel et dure uniquement le temps d’une transaction SIP (i.e : si une application génère une requête SIP, celle-ci va agir comme un UAC durant cette transaction). – User Agent Server (UAS) : entité générant des réponses aux requêtes SIP. Ces réponses peuvent être une acceptation, un refus ou bien une redirection de la requête reçue. De façon analogue à un UAC, le rôle d’UAS dure uniquement le temps d’une transaction SIP. – User Agent (UA) : entité pouvant agir à la fois comme UAC et UAS, c’est l’application et la transaction SIP qui décident si un UA doit agir comme UAS ou UAC. Un tel UA est constitué d’un module SIP interagissant avec une application. La Figure 4.1 illustre la structure d’un UA. La gestion des interactions entre l’application et le module SIP dépend de l’implémentation de l’UA. Cette spécificité explique la diversité et le nombre d’UA différents existants.



29



30



CHAPITRE 4. SESSION INITIATION PROTOCOL (SIP)

– URI (Uniform Resource Identifier) : les URI sont utilisés pour identifier les UA, leur format est similaire à une adresse e-mail (Ex: sip:clarinet@u-strasbg.fr). – Registrar : un Registrar est un serveur acceptant les requêtes REGISTER et mémorisant les informations reçues pour le domaine qu’il gère. Ce mécanisme permet de gérer la mobilité des UA et de rediriger les requêtes vers la nouvelle localisation. Le Registrar fait correspondre adresses IP et URI pour l’ensemble des URI du domaine sur lequel il a autorité. – Proxy, Proxy Server : un proxy est une entité intermédiaire agissant à la fois comme UAC et UAS afin de faire des requêtes à la place d’autres UAC. Son rôle est de s’assurer qu’une requête est envoyée à une autre entité plus "proche" du destinataire de la requête. Une requête se propage donc de Proxy en Proxy jusqu’à atteindre sa destination. Un proxy interprète et modifie si nécessaire certaines parties spécifiques de la requête avant de la faire suivre.



F IG . 4.1 – Structure d’un Agent SIP (UA) Le Tableau 4.1 détaille les différents types de requêtes SIP.



Requête INVITE OPTIONS BYE CANCEL ACK REGISTER



Description invitation de l’appelé dans une session requête afin de découvrir les capacités du récepteur (i.e : les options qu’il supporte) terminaison d’un appel requête d’abandon d’une requête d’invitation incomplète acquittement d’une réponse enregistre la localisation courante d’un utilisateur TAB . 4.1 – Les différents types de requêtes SIP



4.1. PRÉSENTATION



31



En réponse à une requête un UAS renvoie un code d’état afin de signaler de quelle façon la requête a été traitée. Ces codes sont découpés en 6 catégories qui sont décrites dans le Tableau 4.2 Code d’état 1xx 2xx 3xx 4xx 5xx 6xx Description information concernant le statut de l’appel réussite redirection vers un autre serveur erreur côté client erreur côté serveur échec global Exemple 180 RINGING 200 OK 301 MOVED TEMPORARILY 401 UNAUTHORISED 500 INTERNAL SERVER ERROR 606 NOT ACCEPTABLE



TAB . 4.2 – Les classes de réponses SIP



4.1.2 Mécanismes

SIP peut fonctionner au dessus de TCP ou d’UDP. Afin de palier aux pertes éventuelles de messages possibles si UDP est utilisé SIP doit donc avoir ses propres mécanismes de retransmissions. Les requêtes émises par les UAC sont donc retransmises périodiquement jusqu’à réception d’une réponse de l’UAS. Plus spécifiquement pour les requêtes de type INVITE, l’UAC réémet la requête au bout d’une durée initiale de T1 secondes qui double à chaque réémission. L’UAC cesse de réémettre s’il reçoit une réponse de l’UAS ou s’il a réémit le paquet 7 fois. Un mécanisme similaire est utilisé par l’UAS. Pour initier une session SIP, l’UA doit simplement connaître l’adresse URI de l’UA qu’il désire contacter. Un message INVITE est envoyé en direction de cette URI et sera relayé par un ou plusieurs proxies en direction de l’UA correspondant à l’URI du destinataire. La Figure 4.2 illustre l’initialisation et la fermeture d’une session SIP entre deux UA. Description des différentes étapes représentées dans la Figure 4.2 : 1. L’UA identifié par l’URI sip:pascal@u-strasbg.fr souhaite contacter l’UA d’URI sip:mathieu@ustrasbg.fr. Pour cela il envoie une requête de type INVITE à destination de cette URI. 2. Le proxy du domaine u-strasbg.fr fait suivre la requête INVITE et le signale à l’UA de l’appelant en lui retournant le code d’état 100 TRYING. 3. L’UA de l’appelé a reçu le message mais la communication n’est pas encore acceptée (dans le contexte d’une application téléphonique on se retrouve dans la situation où le téléphone sonne et où l’on attend que la personne décroche). L’UA de l’appelé signale cela en renvoyant le code d’état 180 RINGING au proxy qui va l’envoyer à l’UA de l’appelant. 4. L’UA de l’appelé accepte la communication et retourne le code d’état 200 OK au proxy qui le relaye à l’UA de l’appelant.



32



CHAPITRE 4. SESSION INITIATION PROTOCOL (SIP)



F IG . 4.2 – Illustration d’une session SIP 5. L’UA de l’appelant envoie un message d’acquittement. A partir de ce moment, la connexion entre les deux UA est initialisée et plus aucun message ne passe par le proxy. 6. Les deux UA peuvent s’envoyer des données via la connexion qui a été décrite dans le message INVITE (i.e: UDP ou TCP par exemple). Cette connexion utilisée pour l’échange de données est totalement indépendante de la connexion utilisée pour la signalisation SIP. 7. Ici, un des UAs souhaite clore la connexion, il envoie donc un message BYE. 8. Le message BYE est acquitté via un code d’état 200 OK. La connexion entre les deux UA est rompue. Pour communiquer, les UA s’échangent des messages SIP codés en mode texte (UTF8) ayant une sémantique similaire à celle des messages du protocole HTTP. L’exemple ci-dessous illustre une entête SIP. INVITE sip:mathieu@u-strasbg.fr SIP/2.0 Via: SIP/2.0/UDP pc5.u-strasbg.fr ;branch=z9h4K76shds Max-Forwards: 70 To: Mathieu From: Pascal ;tag=1928301774 Call-ID: a844c7670@pc5.u-strasbg.fr CSeq: 314159 INVITE Contact: Content-Type: application/sdp Content-Length: 142



4.1. PRÉSENTATION



33



Descriptif des différents champs de l’entête SIP : – La première ligne contient le type de message (ici il s’agit d’un message INVITE) – Via : ce champ représente le chemin parcouru par la requête, lors de l’envoie de la requête il contient initialement l’URI de l’émetteur de cette requête. Ensuite, à chaque fois qu’un UA fait suivre la requête celui-ci rajoute sa propre URI dans ce champ. – Max-Forwards : nombre maximum de sauts – To : URI du destinataire du message – From : URI de l’expéditeur du message – Call-ID : identifiant unique représentant la session SIP – Cseq : contient un entier et un nom de méthode, l’entier est généré aléatoirement une première fois puis est ensuite incrémenté à chaque nouveau message. – Contact : contient une ou plusieurs URI représentant une route directe pour contacter l’UA de l’expéditeur (ici l’UA de Pascal) – Content-Type : description du corps du message – Content-Length : taille en octet du corps du message – branch,tag : utilisés pour des raisons d’identification SIP permet donc aisément d’initier une communication entre deux UA. Pour cela, il suffit qu’un UA émette un message SIP INVITE qui sera relayé avant d’atteindre l’UA destinataire qui pourra accepter ou non cette communication. La seule information nécessaire afin de pouvoir contacter un UA est de connaître son URI. Des serveurs appelés REGISTRAR sont utilisés pour maintenir la cohérence entre URI et localisation dans le réseau. Ce mécanisme permet également de gérer la mobilité des UA et de garantir une continuité de service lorsque l’UA se déplace. Un UA ayant changé de localisation dans le réseau (nouvelle adresse IP, nouveau domaine) peut signaler à son REGISTRAR sa nouvelle position via un message REGISTER. La Figure 4.3 illustre le fonctionnement d’un REGISTRAR et montre comment une requête SIP se propage jusqu’à l’UA souhaité. Description des mécanismes représentés dans la Figure 4.3 : 1. L’UA ayant pour URI sip:mathieu@u-strasbg.fr contacte le REGISTRAR autoritaire sur son domaine (u-strasbg.fr) pour lui communiquer sa nouvelle localisation via un message REGISTER. Dans cet exemple, l’UA en question se voit attribuer l’adresse dhcp-pc34.ustrasbg.fr. 2. Le REGISTRAR enregistre la nouvelle adresse correspondant à l’URI sip:mathieu@ustrasbg.fr dans son Location Service (le Location Service est un système d’annuaire associant une adresse à une URI). 3. Ici, l’UA cherche à contacter l’URI sip:mathieu@u-strasbg.fr, cet UA envoie donc une requête SIP qui sera reçue par un des proxies SIP autoritaires sur le domaine. 4. Le proxy interroge le Location Service afin d’obtenir l’adresse associée à l’URI. 5. Le proxy reçoit l’adresse associée à l’URI.



34



CHAPITRE 4. SESSION INITIATION PROTOCOL (SIP)



F IG . 4.3 – Fonctionnement d’un REGISTRAR SIP 6. Le proxy redirige la requête initiale vers l’UA destination et ce de façon totalement transparente pour l’UA source. L’exemple de la Figure 4.3 se place dans le contexte d’une requête SIP intra-domaine mais le mécanisme illustré fonctionne également en inter-domaine En inter-domaine, la requête se propage de proxy en proxy jusqu’à atteindre le domaine destination. Les REGISTRAR rendent donc l’établissement d’une connexion entre deux UA possible et ce sans aucune contrainte de localisation.



4.1.3 Domaine d’application

Le protocole SIP est largement utilisé pour établir des connexions point à point dans des applications de type téléphonie sur IP. Un UA est constitué d’un module SIP et d’une application (cf. paragraphe 4.1.1). La diversité et le nombre de modules SIP existants (Vovida, osip, eXosip, sipXtackLib etc...) ainsi que le comportement spécifique de chaque UA (dû à la façon dont sont gérées les interactions entre le module SIP et l’application) expliquent pourquoi il existe autant d’UA et d’extensions SIP différents. Chaque UA possède ses propres comportements et est donc généralement spécifique à une application donnée. SIP ne se limite cependant pas à des communications point à point entre uniquement deux UA. En effet, SIP est également utilisé lors de communications multiples appelées conférences. Nous allons dans la section 4.2 présenter l’architecture et les mécanismes utilisés lorsque l’on se trouve dans le contexte d’une communication de groupe ("conférence" en terminologie SIP) pour ensuite décrire dans le paragraphe 4.3 ce que l’utilisation de SIP peut apporter dans le



4.2. UTILISATION DE SIP DANS DES CONFÉRENCES

cadre de la signalisation d’une session multicast.



35



4.2 Utilisation de SIP dans des conférences

Avant d’étudier comment le protocole SIP est utilisé dans une communication de groupe il est nécessaire d’expliciter certains termes et de situer clairement dans quel contexte ses communications de groupe se placent. – Conférence : dans SIP, une conférence est une instance d’une conversation multi-partie – Conférence faiblement couplée : une conférence faiblement couplée est une conférence sans aucun mécanisme de coordination entre les participants. Ce type de conférence utilise fréquemment le multicast pour la diffusion des adhésions à la conférence. – Conférence fortement couplée : une conférence fortement couplée est une conférence dans laquelle un unique UA (appelé focus) maintient un dialogue avec chaque participant et dirige la conférence. Ce focus est identifié par une URI spécifique appelée conference URI. Les propositions existantes décrivant les mécanismes à mettre en œuvre lorsque l’on utilise SIP dans une session de groupe, se placent toujours dans le cadre de conférences fortement couplées. Ce contexte est bien entendu totalement opposé à celui de la découverte et l’annonce de sources dans une session de groupe basée sur le modèle SSM. Il est cependant intéressant d’expliquer les mécanismes utilisés dans des conférences fortement couplées pour ensuite essayer de voir si de tels mécanismes peuvent être appliqués à des conférences faiblement couplées. Dans [17] Miladinovic et Stadler proposent une extension de SIP afin de pouvoir l’utiliser dans des conférences. Leur extension n’est cependant utilisable que dans des groupes fermés, cela suppose que chaque membre du groupe ait connaissance de tous les autres membres de ce même groupe. Deux modèles sont proposés dans cet article. Le premier consiste à utiliser un serveur jouant en quelque sorte le rôle de pont entre tous les participants, dans le second tous les participants sont reliés entre eux (full-mesh conference). Cette approche connaît des limites d’extensibilité, les résultats expérimentaux montrent une forte augmentation du trafic avec l’augmentation du nombre de participants. Dans [14] et [22] une architecture et les mécanismes SIP nécessaires à la réalisation d’une communication entre plusieurs UA sont présentés. L’architecture se base sur un UA central appelé "focus" qui est connecté à l’ensemble des participants de la conférence et qui est responsable de maintenir une signalisation SIP avec chaque participant de la conférence et de s’assurer que chaque participant obtienne les informations qui composent la conférence. Une telle conférence SIP est identifiée par l’URI du "focus".



36



CHAPITRE 4. SESSION INITIATION PROTOCOL (SIP)



Le "focus" peut également implémenter une politique de conférence (notion purement applicative), c’est à dire qu’il possède un ensemble de règles pouvant par exemple servir à refuser les messages en provenance de certains UA ou encore à déterminer vers quels UAs il faut propager les messages en provenance d’un UA spécifique. Une fois les règles définies, le "focus" commande un "mixer"1 qui va générer les données de sortie et les distribuer aux participants (ou à d’autres "mixers"). Pour cela, le "mixer" maintient une connexion RTP avec les participants de la conférence.



F IG . 4.4 – Architecture pour les conférences SIP La Figue 4.4 représente les interconnexions entre le "focus", "mixer" et les UA. Des architectures plus complexes avec plusieurs mixers par exemple sont bien entendu possibles. Ces architectures reposent sur un modèle "multi unicast" qui par définition est difficilement applicable avec un grand nombre de participants. Le draft [22] n’évoque que très brièvement la possibilité d’utiliser un modèle de communication multicast et explique simplement qu’il est possible d’utiliser un canal multicast sous-jacent pour la distribution des données. Cependant aucune architecture ou mécanisme ne sont décrits afin de pouvoir utiliser SIP dans un modèle multicast.



4.3 Intérêt dans le cadre de la signalisation d’une session multicast

Les mécanismes décrits dans la section 4.2 ne tirent aucunement partie des avantages que le multicast possède. La distribution des données entre l’ensemble des membres d’une conférence repose sur des communications multi unicast. Le fait d’utiliser de multiples connexions unicast pour gérer une session de groupe rend les mécanismes décrits dans le paragraphe 4.2 inapplimixer : entité recevant des données en entrée, les traitant en fonction des instructions reçues par le "focus" puis générant des données en sortie.

1



4.3. INTÉRÊT DANS LE CADRE DE LA SIGNALISATION D’UNE SESSION MULTICAST37

cables à grande échelle. Le protocole SIP permet d’initialiser des connexions point à point et ce sans aucune restriction au niveau de la localisation des UA. Le degré d’indirection dû à l’utilisation d’URI pour identifier un UA apporte une gestion de la mobilité des UA. Il est donc intéressant de voir s’il est possible de tirer avantage de l’ensemble des mécanismes que SIP propose si l’on se place dans le contexte d’annonce de sources dynamiques dans une session de groupe. Dans la section 5.1 nous allons décrire l’architecture sur laquelle nous nous baserons, puis nous définirons les mécanismes que nous souhaitons pouvoir utiliser pour ensuite dans la partie 5.2 étudier ce que l’utilisation de SIP apporte comme fonctionnalités et s’il est judicieux de l’utiliser dans le cadre d’une session de groupe.



38



CHAPITRE 4. SESSION INITIATION PROTOCOL (SIP)



Chapitre 5



SIP et le multi source dynamique

5.1 Architecture et mécanismes nécessaires

Avant de pouvoir étudier le comportement et l’apport du protocole SIP dans le cadre de la gestion d’une session de groupe, il est nécessaire de définir dans quel type d’architecture on se place et de détailler les mécanismes et les fonctionnalités qu’une telle architecture doit posséder.



5.1.1 Architecture

Afin de pouvoir gérer une session de groupe, il est nécessaire de mettre en place une architecture qui soit la moins restrictive et la plus extensible possible. Une architecture pouvant supporter un très grand nombre de membres et ne connaissant aucune restriction sur la localisation des membres doit donc être choisie. C’est pour cela qu’une architecture de type Sender Advertisement va être utilisée. Cette architecture est représentée dans la Figure 3.2 et son fonctionnement est détaillé dans les sections 2.4 et 3.2. Cette architecture est extensible à très grande échelle, aussi bien en terme de nombre de récepteurs qu’en terme de nombre de sources. Le fait d’utiliser un canal multicast pour annoncer les sources actives permet en effet au contrôleur de pouvoir effectuer ses annonces quel que soit le nombre de membres du canal de contrôle. Une architecture de type Session Relay est moins extensible car l’ensemble des messages de contrôle et les données passent par la source (voir paragraphe 3.1). Les sources s’annonçant périodiquement au contrôleur on peut supposer que cette architecture peut supporter un très grand nombre de sources sans pour autant que le contrôleur soit submergé sous les messages d’annonce des différentes sources actives. On peut imaginer faire varier cette période avec le nombre de sources que le contrôleur doit annoncer. L’architecture de Sender Advertisement est très sensible aux pannes du contrôleur. En effet tout le système d’annonce de sources stoppe si le contrôleur ne fonctionne plus correctement. 39



40



CHAPITRE 5. SIP ET LE MULTI SOURCE DYNAMIQUE



Il existe également un temps de latence avant qu’un nouveau membre du canal de contrôle apprenne l’existence des sources. Cette latence est due à la périodicité des annonces du contrôleur (Note: le protocole décrit dans la partie 3.2 met en œuvre un mécanisme supprimant cette latence).



5.1.2 Mécanismes

5.1.2.1 Interactions :



– Sources - Contrôleur : Les sources émettent des messages vers le contrôleur afin qu’il apprenne leurs existences. A réception d’un message d’annonce d’une source, le contrôleur rajoute cette source dans la table contenant les sources à annoncer. Un timer est associé à chaque entrée dans cette table. Lorsque ce timer arrive à expiration le contrôleur supprime la source de sa table et cesse de l’annoncer. Les messages envoyés par les sources vers le contrôleur sont donc périodiques et le contrôleur relance le timer à chaque message d’une source. – Contrôleur - Membres du canal de contrôle : Le contrôleur annonce périodiquement les sources qu’il connaît dans le canal de contrôle. A réception des messages du contrôleur chaque membre peut décider d’adhérer ou non aux canaux SSM annoncés. Les données sont diffusées en multicast dans le canal de contrôle et le contrôleur n’a aucune connaissance du nombre de membres de son canal de contrôle et il ne reçoit aucun message de ceux-ci. – Membres du canal de contrôle - Sources : Les sources émettent des données en multicast sur leur canal SSM. Les membres du canal de contrôle adhèrent aux canaux SSM des sources dont ils souhaitent recevoir le contenu.



5.1.2.2



Détection de sources annoncées inutilement :



L’absence de retour au niveau du contrôleur fait qu’il annonce une liste de sources qui se sont déclarées à lui, mais il ne sait absolument pas si ces sources ont des abonnés parmis les membres du canal de contrôle. La seule condition pour que le contrôleur cesse d’annoncer une source est que celle-ci cesse d’émettre (arrêt explicite suite à un message de la source ou bien arrêt implicite par expiration du timer). Le contrôleur annonce donc potentiellement des sources "inutiles" car aucun membre du canal de contrôle ne souhaite s’abonner à celles-ci. Il semble donc intéressant d’utiliser un mécanisme permettant au contrôleur de détecter les sources qu’il annonce mais qui n’ont pas d’abonné pour ensuite décider de cesser de les annoncer ou bien encore d’augmenter la période d’annonce. On peut donc imaginer que le contrôleur utilise un système de requêtes avec réponses probabilistes afin d’interroger les membres du canal de contrôle et de déterminer si une source à



5.1. ARCHITECTURE ET MÉCANISMES NÉCESSAIRES



41



des membres dans le canal de contrôle. Le contrôleur émet donc un message ECHO(S,G,P). Le couple (S,G) représente l’adresse IP de la source et l’adresse multicast du canal SSM et P représente la probabilité de réponse à la requête. Le contrôleur émet la requête et la propage en multicast dans son canal de contrôle, puis les membres du canal de contrôle lui répondent en unicast. La probabilité P est mise en place afin d’éviter que le contrôleur soit submergé de réponses. Cette probabilité est donc initialement très faible, de cette façon même si un très grand nombre de membres du canal de contrôle sont abonnés au canal (S,G) seul un faible nombre de réponses seront émises vers le contrôleur. Le pseudo code ci-dessous décrit le comportement du contrôleur et des membres du canal de contrôle et le fonctionnement de ce mécanisme de requêtes probabilistes. Ce mécanisme est également illustré dans la Figure 5.1.



Contrôleur: - émet message ECHO(S,G,P) - en l’absence de réponses - réémission avec augmentation de la probabilité P - après plusieurs réémissions sans réponses - on cesse d’annoncer (S,G) ou - on augmente la période d’annonce de (S,G) Membres du canal de contrôle: à réception d’un message ECHO(S,G,P) - si abonné au canal (S,G) - tirer B entre [0,1] - si B < P - envoyer ECHO_REPLY(S,G) au contrôleur - sinon - ne rien faire - sinon - ne rien faire



Un tel mécanisme doit cependant être utilisé avec précaution par le contrôleur. Le risque est de cesser d’annoncer une source dans le canal de contrôle. Il faut donc que le contrôleur utilise ce mécanisme en tenant compte de la dynamicité des sources et du type d’application. On peut par exemple imaginer que le contrôleur utilise un système de timer pour déclencher ce type de requêtes. Il annonce initialement les sources toutes les 5 secondes et effectue une requête de type ECHO(S,G,P) toutes les 30 minutes puis double la période d’annonce d’une source n’ayant aucun membre dans le canal de contrôle. Ces valeurs sont simplement données pour l’exemple



42



CHAPITRE 5. SIP ET LE MULTI SOURCE DYNAMIQUE



F IG . 5.1 – Mécanisme de requête probabiliste et elles n’ont aucune valeur théorique. L’étude de la variation et de la dynamicité des sources dans des simulations pourrait être une méthode afin de fixer ces valeurs de façon adéquate.



5.1.2.3



Gestion d’une politique de session :



Le contrôleur ne dispose d’aucun moyen pour détecter le contenu de ce qu’une source qu’il annonce, diffuse sur son propre canal multicast. Cela signifie qu’un contrôleur annonce potentiellement des sources émettant des données dangereuses. Une source mal intentionnée peut par exemple s’annoncer au contrôleur qui, ne disposant d’aucun mécanisme pour le détecter va donc diffuser les informations concernant cette source sur son canal de contrôle et de cette façon annoncer une source potentiellement dangereuse. De façon similaire, une source étant annoncée par le contrôleur peut changer de comportement au cours du temps. Cette source peut par exemple se retrouver compromise suite à un virus qui va chercher à se propager via le canal multicast de l’hôte infecté. Il est donc nécessaire de mettre en œuvre des moyens permettant au contrôleur de bannir une source. Une première possibilité est de faire adhérer le contrôleur à chaque canal multicast des sources qu’il annonce. De cette façon, il va recevoir les flux de l’ensemble des sources et pourra rapidement détecter les sources mal intentionnées et cesser de les annoncer. Cette solution implique une forte charge supplémentaire au niveau du contrôleur augmentant avec le nombre de sources à annoncer. Un tel mécanisme n’est donc applicable que dans une session de groupe de taille relativement réduite (i.e: peu de sources). La seconde approche consiste à laisser la détection des sources indésirables à la charge des membres du canal de contrôle et de mettre en place un mécanisme leur permettant de le signaler au contrôleur. C’est un tel mécanisme qui est mis en place dans le protocole décrit dans la section 3.2 avec l’utilisation de messages KICK pouvant être envoyés au contrôleur. Un membre



5.2. DISCUSSION SUR L’UTILISATION DE SIP



43



du canal de contrôle qui considère qu’une source dont il reçoit des données est indésirable, va le signaler au contrôleur qui cessera d’annoncer cette source. Il est bien évident qu’il faut sécuriser ce mécanisme en authentifiant les membres du canal de contrôle afin de garantir que cette décision est fondée. Ces mécanismes d’authentification et de sécurité ne seront pas détaillés car ils ne font pas l’objet de ce mémoire de DEA.



5.2 Discussion sur l’utilisation de SIP

Maintenant que l’architecture utilisée et les mécanismes sont clairement définis il est important de voir si l’utilisation de SIP comme protocole de signalisation se justifie et si elle apporte des fonctionnalités supplémentaires. Dans ce contexte, un groupe multicast est identifié par l’URI du contrôleur qui va annoncer l’ensemble des sources qu’il connaît.



5.2.1 Interactions Source - Contrôleur

Le mécanisme essentiel à mettre en place entre les différentes sources et le contrôleur est la détection rapide de la disparition d’une source. La partie où la source s’annonce au contrôleur est en effet assez aisée à mettre en œuvre et ce, quel que soit le protocole de signalisation utilisé ; seule le type de message change quand on passe d’un protocole à un autre. Dans SSMSDP (détaillé dans le paragraphe 3.2) la détection de la disparition d’une source se fait par un système de timers et de messages émis périodiquement par les sources. Un tel mécanisme induit une certaine latence avant de détecter qu’une source n’existe plus et la réactivité du contrôleur dépend de la période d’émission des messages de la source. Nous allons donc voir ce que les mécanismes dont le protocole SIP dispose apportent à ce problème de détection de disparition de sources.



F IG . 5.2 – Interactions entre source et contrôleur



44



CHAPITRE 5. SIP ET LE MULTI SOURCE DYNAMIQUE



La Figure 5.2 schématise les interactions entre l’UA d’une source et celui du contrôleur. L’UA de la source connaît uniquement l’URI identifiant le groupe multicast. Pour s’annoncer à ce groupe, l’UA de la source peut envoyer un message SIP INVITE à destination de cette URI. Ce message SIP va donc passer par un ou plusieurs proxies et va finalement arriver à destination de l’UA du contrôleur après que le REGISTRAR ait fait la correspondance entre l’URI et la localisation du contrôleur (le fonctionnement du REGISTRAR est détaillé dans la section 4.1.2). Les communications entre les modules SIP des deux UA (i.e: toute la signalisation SIP) peuvent se faire via TCP ou UDP. Lorsqu’on utilise TCP, une connexion TCP réservée à la signalisation SIP est établie entre les deux UA. Une première idée a été de voir s’il est possible d’utiliser cette connexion TCP comme moyen de détection de la disparition d’une source. Une rupture de cette connexion TCP propre à la signalisation signifierait que la source n’est plus présente. Cette solution s’avère en réalité difficilement applicable car il n’existe aucun standard définissant le comportement des UA lorsque TCP est utilisé pour la signalisation. Cela veut donc dire que la connexion peut être arbitrairement fermée par un des UA sans pour autant que le second UA ne puisse en déduire quoi que ce soit. Si de nouveaux messages SIP doivent être échangés entre les deux UA la connexion TCP est alors ré-ouverte. La gestion de cette connexion TCP est donc propre à chaque UA et est définie lors de leurs implémentations. L’utilisation d’un tel mécanisme imposerait donc une restriction au niveau du comportement des UA. On peut également se demander comment le contrôleur réagirait devant un nombre potentiellement élevé de connexions TCP à maintenir avec l’ensemble des sources. C’est pour ces raisons que cette idée a été écartée. Le protocole SIP n’apporte donc aucun mécanisme supplémentaire à ceux existants et l’utilisation de timers et de messages émis périodiquement par les sources semble donc être la seule méthode applicable pour détecter la disparition d’une source (comportement identique à SSMSDP).



5.2.2 Interactions Contrôleur - Membres du canal de contrôle

Pour les interactions entre les membres du canal de contrôle et le contrôleur, l’usage du protocole SIP se restreint à faire une simple correspondance entre l’URI du groupe multicast et les informations nécessaires afin de pouvoir adhérer au groupe (i.e: le couple (S,G)). Le protocole SIP ne dispose cependant pas d’un tel mécanisme. Le seul moyen pour apprendre les informations concernant le contrôleur serait par exemple, d’émettre un message INVITE qui sera relayé jusqu’au contrôleur. De cette façon, l’UA souhaitant adhérer au groupe va apprendre l’IP du contrôleur lorsque celui-ci répondra à ses messages. Ce mécanisme en dehors du fait qu’il va submerger le contrôleur de messages INVITE n’a pas de sens réel.



5.2. DISCUSSION SUR L’UTILISATION DE SIP



45



L’utilisation de messages INVITE entre les sources et le contrôleur est justifiée car les sources initialisent une connexion point à point avec le contrôleur dans le but de diffuser les informations concernant leurs canaux SSM respectifs ainsi qu’envoyer périodiquement des messages de contrôle. Entre le contrôleur et les membres du canal de contrôle, utiliser un message INVITE reviendrait à initier une connexion point à point entre deux UA dans le but d’apprendre les informations nécessaires afin de pouvoir adhérer à un groupe multicast. Il est donc nécessaire de mettre en place un mécanisme permettant à un UA de pouvoir faire la correspondance entre l’URI et l’adresse réelle du contrôleur. Dans [8] et [23], une extension SIP est décrite. Cette extension repose sur une nouvelle entité appelée "Presence Agent" qui permet une gestion des changements d’états. Ce mécanisme met en place un "Presence Server" qui peut interagir avec la base de données d’un REGISTRAR et qui permet d’effectuer une résolution de l’URI. Un UA souhaitant obtenir des informations concernant un groupe multicast envoie donc un message SUBSCRIBE pour l’URI du groupe multicast. Ce message SUBSCRIBE va arriver au Presence Server qui va répondre à l’UA par un message NOTIFY contenant les informations associées à l’URI. Un des champs du message SUBSCRIBE spécifie la durée pendant laquelle l’UA est "abonné" au Presence Server et tant que cette période n’est pas écoulée, le Presence Server notifiera l’UA de TOUT changement concernant l’URI. On peut donc imaginer utiliser une communication SIP "classique" entre les sources et le contrôleur et un mécanisme basé sur un Presence Server afin que les UA souhaitant adhérer au canal de contrôle obtiennent les informations associées à l’URI du groupe multicast.



5.2.3 Mécanismes supplémentaires

Le mécanisme de détection de source sans abonné présenté en section 5.1.2 est purement applicatif et totalement indépendant du protocole utilisé. Dans [22], une extension de SIP permettant de gérer une politique de conférence est décrite. Dans cette approche, un serveur est mis en place et il définit la politique de la conférence. L’ensemble des clients peut interagir avec ce serveur et modifier la politique de la conférence. On peut donc imaginer utiliser un tel mécanisme afin que les membres du canal de contrôle puissent intervenir sur la politique du groupe multicast et par exemple supprimer une source indésirable. Utiliser un tel mécanisme impliquerait de mettre en place une entité supplémentaire (le serveur chargé de gérer la politique du groupe) ainsi que définir les interactions entre le contrôleur et cette nouvelle entité. Le coût de la mise en place de ce système s’avère donc relativement important surtout si on le compare avec la solution proposée par SSMSDP qui se base sur de simples messages de type KICK ou BAN. De plus, l’utilisation de SIP pour la gestion de la politique du groupe n’apporte pas de fonctionnalités supplémentaires justifiant ces coûts.



46



CHAPITRE 5. SIP ET LE MULTI SOURCE DYNAMIQUE



5.3 Conclusion

Le protocole SIP fournit les mécanismes nécessaires à la gestion des sources dynamiques dans une session de groupe. En effet, les sources peuvent s’annoncer au contrôleur via un message INVITE et les UA souhaitant adhérer au canal de contrôle peuvent obtenir les informations nécessaires à l’adhésion au groupe en effectuant une requête SUBSCRIBE. Cependant le type de messages ainsi que l’architecture utilisés sont fortement similaires à ceux utilisé dans SSMSDP. Le fait d’utiliser le protocole SIP n’apporte pas de nouveaux mécanismes plus efficaces solutionnant le problème de la détection de panne d’une source par exemple. Le réel intérêt d’utiliser le protocole SIP pour la gestion d’une session de groupe repose dans le degré d’indirection qu’apporte l’utilisation d’une URI comme descripteur du groupe multicast. Une utilisation astucieuse des différentes entités SIP et de la gestion de l’URI peut permettre de mettre en place un système de contrôleurs secondaires évoluant de façon dynamique au cours de la vie du groupe. Ce mécanisme solutionne donc le problème de vulnérabilité aux pannes du contrôleur que connaît l’architecture Sender advertisement. Les mécanismes permettant l’utilisation dynamique de contrôleurs secondaires ainsi qu’un descriptif de notre proposition seront détaillés dans le Chapitre 6.



Chapitre 6



Proposition

6.1 Mécanismes de résolution de l’URI

6.1.1 Déclaration d’une source

Une source souhaitant que le contrôleur annonce son existence dans son canal de contrôle doit donc disposer d’un mécanisme afin de contacter le contrôleur. Pour cela, la source émet un message INVITE en destination de l’URI du groupe multicast. Le déroulement d’un tel mécanisme est représenté dans la Figure 6.1.



F IG . 6.1 – Adhésion d’une source au groupe Voici un descriptif des différentes actions représentées dans la Figure 6.1 : 47



48



CHAPITRE 6. PROPOSITION

1. Initialement, le contrôleur émet un message REGISTER en destination du REGISTRAR afin d’associer sa localisation courante à l’URI identifiant le groupe multicast. 2. L’UA de la source émet un message SIP INVITE à destination de l’URI représentant le groupe multicast. 3. Ce message INVITE va se propager de proxy en proxy pour finalement atteindre le proxy du domaine de l’URI. Ce proxy va obtenir la localisation de l’UA associé à l’URI en consultant le Location Server. 4. Après avoir déterminé la localisation du destinataire du message INVITE, le proxy va faire suivre le message INVITE vers son destinataire. 5. Le contrôleur reçoit un message INVITE, il en déduit qu’il doit annoncer une nouvelle source. Il met donc les informations associées à cette source dans son cache et il l’annonce en multicast dans son canal de contrôle. Le contrôleur peut également refuser le message si la source est indésirable (dans ce cas, le contrôleur n’annonce pas la source dans son canal de contrôle et émet un message signalant ce refus dans l’étape 6). 6. Le contrôleur émet un message pour signaler à la source qu’il a bien reçu et accepté son message d’invitation. C’est uniquement à réception de ce message que la source apprend l’identité du contrôleur (i.e: son adresse IP).



Un tel mécanisme permet donc à une source de contacter le contrôleur afin qu’il apprenne l’existence de la source et qu’il émette les informations relatives à la source sur son canal de contrôle. SIP ne permet cependant pas au contrôleur de détecter rapidement la panne d’une source, la mise en place de messages de contrôles périodiques émis par les sources est donc nécessaire.



6.1.2 Adhésion au groupe

Un UA désirant adhérer au groupe afin de recevoir les annonces du contrôleur doit également disposer d’un mécanisme lui permettant d’obtenir les informations nécessaires à l’adhésion au groupe à partir de l’URI du groupe. Pour les raisons détaillées en section 5.2, il n’est pas approprié d’envoyer un message INVITE comme le fait une source. La Figure 6.2 illustre par quels mécanismes un UA communique avec le Presence Server afin d’obtenir les informations nécessaires à l’adhésion au groupe. Descriptif des différents mécanismes représentés dans la Figure 6.2 : 1. Initialement, le contrôleur émet un message REGISTER en destination du REGISTRAR afin d’associer sa localisation courante à l’URI identifiant le groupe multicast. 2. L’UA souhaitant adhérer au groupe multicast a besoin d’obtenir le couple (S,G) identifiant le groupe. Il doit donc faire la correspondance entre l’URI identifiant le groupe et le couple (S,G). Pour cela, il envoie un message SUBSCRIBE qui va atteindre le Presence Server autoritaire pour le domaine.



6.2. MÉCANISME DE MISE EN PLACE DYNAMIQUE DE CONTRÔLEURS SECONDAIRES49



F IG . 6.2 – Adhésion d’un membre au groupe 3. A réception du message SUBSCRIBE, le Presence Server va interroger le Location Server pour obtenir les informations associées à l’URI. Ces messages SUBSCRIBE ont une durée de validité, cela veut dire que tant qu’une souscription d’un UA pour une URI donnée est valide, le Presence Server va notifier l’UA de TOUT changement des données associées à l’URI. 4. Le Presence Server renvoi à l’UA les informations correspondant à l’URI via un message NOTIFY. A réception de ce message, l’UA apprend les informations nécessaires à l’adhésion au groupe. Une fois que l’UA a obtenu le couple (S,G), il émet un message IGMPV3 SUBSCRIBE(S,G) afin d’adhérer au groupe multicast et d’obtenir les annonces effectuées par le contrôleur.



6.2 Mécanisme de mise en place dynamique de contrôleurs secondaires

Tous les participants au groupe multicast obtiennent donc le descriptif du groupe multicast à partir de l’URI identifiant le groupe. Une utilisation astucieuse du degré d’indirection supplémentaire qu’apporte l’usage d’une URI permet de modifier les informations associées à l’URI et cela de façon dynamique au cours de la vie du groupe. Le fait de pouvoir modifier ces informations rend possible la mise en place de contrôleurs secondaires au cours du déroulement de la vie du groupe.



50



CHAPITRE 6. PROPOSITION



Dans notre proposition, un groupe multicast est identifié par une URI et au moins deux contrôleurs sont initialement associés à cette URI. La Figure 6.3 illustre le fonctionnement de notre proposition et montre de quelle façon nous avons utilisé le protocole SIP.



F IG . 6.3 – Mécanisme de mise en place de contrôleurs secondaires Détail des différents mécanismes représentés sur la Figure 6.3 : 1. Envoi d’un message SUBSCRIBE 2. Réponse du Presence Server via un message NOTIFY. Dans cet exemple le groupe représenté par l’URI a initialement un contrôleur principal et un contrôleur secondaire. Le message NOTIFY contient donc les adresses de ces contrôleurs ainsi que l’adresse du groupe (C1,C2,G dans notre exemple, les deux canaux de contrôle sont donc (C1,G) et (C2,G)). 3. L’UA reçoit le message NOTIFY et adhère donc au groupe (C1,G) et commence à recevoir les annonces du contrôleur. NOTE: déroulement similaire pour une SOURCE, le proxy va récupérer les informations (ici C1,C2,G) puis relayer le message. La source apprendra donc également l’existence des deux contrôleurs. 4. Au cours de la vie du groupe, le contrôleur principal tombe en panne. Tous les membres du groupe (sources et adhérents au canal de contrôle) ont connaissance du contrôleur secondaire, ils détectent rapidement une panne du contrôleur principal et basculent donc sur le contrôleur secondaire.



6.3. MÉTHODE HYBRIDE (SIP-SSMSDP)

5. Le contrôleur secondaire prend le relais et assure la pérennité de la vie du groupe.



51



6. En détectant que la panne du contrôleur principal dure, le contrôleur secondaire décide qu’il est nécessaire de mettre en place un nouveau contrôleur de secours (C3 dans cet exemple). C2 envoie donc un message REGISTER(C3) afin d’associer C3 à l’URI du groupe. 7. Les données sont mises à jour au niveau du REGISTRAR 8. Les données étant à jour au niveau du REGISTRAR, toute nouvelle requête obtiendra les bonnes informations concernant le groupe multicast. L’ensemble des sources ainsi que les membres du canal de contrôle étant déjà abonnés au groupe avant qu’une modification des contrôleurs secondaires ne ce soit effectuée ne connaissent pas l’adresse du nouveau contrôleur de secours. Le contrôleur diffuse donc un message dans son canal pour signaler les modifications des adresses des contrôleurs et envoie également ce même message en unicast aux sources afin que l’ensemble des membres du groupe soient informés de l’existence d’un nouveau contrôleur de secours. La mise en place d’un tel mécanisme basé sur l’utilisation du degré d’indirection qu’une URI SIP apporte pour définir le groupe multicast, permet donc de fournir une solution au problème de vulnérabilité aux pannes du contrôleur dues à l’utilisation d’une architecture de type Sender Advertisement.



6.3 Méthode Hybride (SIP-SSMSDP)

Pour les raisons décrites dans le paragraphe 5.2, utiliser SIP pour l’ensemble des mécanismes nécessaires au bon déroulement de la vie du groupe multicast n’est pas recommandé. Il est bien entendu possible de reproduire tous les mécanismes nécessaires au groupe avec le protocole SIP, cependant le fait d’utiliser SIP plutôt que SSMSDP n’apporte aucune fonctionnalité supplémentaire justifiant un tel choix. L’usage du protocole SIP comme protocole de signalisation dans une session de groupe permet grâce au degré d’indirection que l’URI apporte, une gestion dynamique des informations décrivant le groupe. Ainsi, un groupe multicast n’est plus identifié de façon statique par le couple (S,G) mais par une adresse URI. Cette adresse URI décrit de façon statique un groupe multicast mais les informations associées à cette URI peuvent être modifiées de façon dynamique en cas de panne du contrôleur par exemple. On peut considérer le fait d’utiliser l’indirection qu’une URI SIP apporte comme une extension de SSMSDP qui permet d’apporter une solution au problème de sensibilité aux pannes du contrôleur que l’architecture de Sender Advertisement connaît. Il est donc nécessaire de décrire le fonctionnement global de notre système et déterminer dans quelles parties on utilise SIP.



52



CHAPITRE 6. PROPOSITION



F IG . 6.4 – Architecture générale La Figure 6.4 représente le mécanisme global. Elle illustre dans quelles parties la signalisation et les mécanismes propres au protocole SIP sont utilisés. Le protocole SIP est donc utilisé pour : – déclarer une source (mécanisme détaillé dans la section 6.1.1) – adhérer au groupe (mécanisme détaillé dans la section 6.1.2) – modifier les données associées à l’URI (mécanisme détaillé dans la section 6.2) Une fois que SIP a permis d’obtenir les informations associées à l’URI identifiant le groupe, le protocole SIP n’est plus utilisé et les mécanismes "classiques" de SSMSDP sont utilisés. La source émet donc des messages ON périodiques vers le contrôleur qui va annoncer cette source dans son canal multicast tant qu’il reçoit les messages ON. Le contrôleur utilise un cache avec un timer pour chaque entrée dans ce cache, la réception d’un message ON d’une source relance le timer associé à cette source. Une gestion de la politique du groupe peut également être mise en place grâce aux messages KICK et BAN dont SSMSDP dispose. Cette méthode hybride consiste donc simplement à utiliser initialement SIP comme "résolveur d’URI" pour ensuite utiliser SSMSDP. On peut donc considérer que cette proposition décrit une extension possible de SSMSDP.



Chapitre 7



Perspectives et conclusion

Nous avons, au cours de ce stage de DEA, étudié la signalisation nécessaire à la gestion d’une session multicast. Pour cela, nous avons tout d’abord étudié le fonctionnement de différents modèles de communication de groupe, pour ensuite nous placer dans le contexte du modèle SSM qui est considéré comme le modèle qui va permettre l’explosion du multicast à grande échelle sur Internet. Nous avons cherché à déterminer quel pouvait être l’apport du protocole SIP à la gestion d’une session de groupe. Pour cela, nous avons dans un premier temps effectué une observation détaillée des différentes propositions existantes ; puis dans un deuxième temps, nous avons étudié en détail la sémantique et le fonctionnement du protocole SIP. Par ces observations, nous avons montré que l’utilisation du protocole SIP pour la gestion d’une session de groupe ne se justifiait pas. En effet, l’utilisation du protocole SIP nécessiterait d’importantes modifications dans le comportement des UA. L’usage d’une URI SIP comme identificateur d’un groupe multicast apporte cependant un niveau d’indirection permettant de solutionner le problème de vulnérabilité aux pannes du contrôleur propre à l’architecture de type Sender Advertisement. Nous avons décrit les mécanismes ainsi que l’architecture nécessaire à cette mise en place de contrôleurs de secours. Notre proposition peut être considérée comme une extension de SSMSDP permettant grâce à SIP d’associer plusieurs contrôleurs à un groupe multicast et de faire évoluer ces contrôleurs de façon dynamique au cours de la vie du groupe. Cette proposition est pour le moment purement théorique, afin d’étudier son comportement ainsi que les coûts qu’une telle proposition induit, les perspectives de développement futur sont : – simulation : confronter notre proposition à une série de simulations afin d’observer les coûts en temps et quantité de messages que l’utilisation de SIP et d’une URI pour identifier un groupe multicast induit. – implémentation : développer l’extension de SSMSDP et l’expérimenter. 53



54



CHAPITRE 7. PERSPECTIVES ET CONCLUSION



Bibliographie

[1] K. C. Almeroth, S. Bhattacharyya, and C. Diot. Challenges of Integrating ASM and SSM IP Multicast Protocol Architectures. Lecture Notes in Computer Science, 2170:343–??, 2001. [2] Hitoshi Asaeda. Protocol Analysis of Any-Source Multicast and Source-Specific Multicast. Rapport de recherche de l’INRIA, January 2004. [3] Hitoshi Asaeda and Vicent Roca. Consideration of Multicast Channel Announcement Architecture. Rapport de recherche de l’INRIA, March 2003. [4] F. Beck, M. Hoerdt, and J-J Pansiot. Source Discovery Protocol in SSM Networks : draftbeck-mboned-ssm-source-discovery-protocol-03.txt, June 2003. [5] B. Cain, S. Deering, B. Fenner, I. Kouvelas, and A. Thyagarajan. RFC 3376 - Internet Group Management Protocol, Version 3, October 2002. [6] Julian Chesterfield and Eve M. Schooler. A Comparison of RTCP standard and Summarised Feedback Models. Memo, AT&T Labs-Research, Menlo Park, CA, March 2002. [7] Julian Chesterfield and Eve M. Schooler. An Extensible RTCP Control Framework for Large Multimedia Distributions. IEEE Symposium on Network Computers and Applications (NCA-03), April 2003. [8] M. Day, J. Rosenberg, and H. Sugano. RFC 2778 - A Model for Presence and Instant Messaging, February 2000. [9] Stephen Deering. Multicast routing in a datagram internetwork. PhD thesis, Standford University, December 1991. [10] M. Handley and V. Jackobson. RFC 2327 - SDP : Session Description Protocol, April 1998. [11] M. Hoerdt, F. Beck, and J-J Pansiot. Multi-source communications over SSM networks : draft-hoerdt-mboned-multisource-ssm-02.txt, June 2003. [12] Hugh Holbrook. A channel model for multicast. PhD thesis, Standford University, August 2001. [13] R. Lehtonen, J. Soini, J. Majalainen, H. Vatiainen, and M. Tammi. MCOP operation for first hop routers - draft-lehtonen-mboned-mcop-operation-01.txt, December 2003. [14] R. Mahy, B. Campbell, R. Sparks, J. Rosenberg, D. Petrie, and A. Johnston. A Call Control and Multi-party usage framework for the Session Initiation Protocol : draft-ietf-sipping-ccframework-03.txt, October 2003. 55



56



BIBLIOGRAPHIE



[15] Steven R McCanne. Scalable Multimedia Communication with Internet Multicast, Lightweight Sessions, and the MBone. Technical Report CSD-98-1002, University of California, Berkeley, August 1998. [16] I. Miladinovic and J. Stadler. A simulation study of multi-recipient messages in the Session Initiation Protocol. IEEE International Conference on Communication Systems (ICCS), November 2002. [17] I. Miladinovic and J. Stadler. Multiparty Conference Signalling using the Session Initiation Protocol (SIP). International Network Conference 2002 (INC2002), July 2002. [18] I. Miladinovic and J. Stadler. Optimization of Signaling Traffic in Centralized Conferences using SIP. WSEAS ICOMIV Conference, September 2002. [19] I. Miladinovic and J. Stadler. Multi-Recipient Requests in the Session Initiation Protocol. IASTED International Conference AI PDCN, February 2003. [20] B. Quinn and K. Almeroth. RFC 3170 - IP Multicast Applications : Challenges and Solutions, September 2001. [21] A. B. Roach. RFC 3265 - Session Initiation Protocol (SIP)-Specific Event Notification, June 2002. [22] J. Rosenberg. A Framework for Conferencing with the Session Initiation Protocol : draftietf-sipping-conferencing-framework-01.txt, October 2003. [23] J. Rosenberg. A Presence Event Package for the Session Initiation Protocol (SIP) : draftietf-simple-presence-10.txt, January 2003. [24] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, and E. Schooler. RFC 3261 - SIP : Session Initiation Protocol, June 2002. [25] K. Sarac and P. Namburi. Multicast Session Announcements on top of SSM. International Conference in Communications (ICC), June 2004. [26] K. Sarac, P. Namburi, and K. Almeroth. SSM Extensions : Network Layer Support for Multiple Senders in SSM. International Conference on Computer Communications and Networks (ICCCN), October 2003. [27] P. Savola. PIM-SM Multicast Routing Security Issues and Enhancements : draft-savolamboned-mroutesec-00.txt, January 2004. [28] P. Savola and B. Haberman. Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address : draft-ietf-mboned-embeddedrp-02.txt, March 2004. [29] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson. RFC 3550 - RTP : A Transport Protocol for Real-Time Applications, July 2003. [30] A. Swan and L. Rowe. The Case for a Multicast Session Layer. Berkeley Multimedia Research Center, TR 2003-168, July 2003. [31] Daniel Zappala and Aaron Fabbri. Using SSM Proxies to Provide Efficient MultipleSource Multicast Delivery. IEEE Globecom, Sixth Global Internet Symposium, November 2001.