L'invention concerne le domaine des télécommunications, en particulier le contrôle de l'accès à des flux IP Multicast.

Dans la technique de diffusion IP Multicast, les paquets IP Multicast sont diffusés en utilisant une adresse IP destinataire particulière, dite adresse Multicast.

Un flux Multicast est caractérisé par son adresse source S et par son adresse de groupe G, chaque flux Multicast pouvant donc être représenté par un couple (S, G) unique. Deux flux Multicast distincts peuvent ainsi avoir la même adresse source S ou la même adresse de groupe G.

La particularité des flux IP Multicast porte essentiellement sur le fait que les données support de ces flux sont transmises à l'équipement terminal demandeur, par exemple un décodeur audio-visuel, sur requête de ce dernier transmise sur le réseau IP.

La demande de réception, ou d'arrêt de réception d'un flux Multicast s'effectue selon le protocole IGMP, pour Internet Group Management Protocol en anglais, défini à l'IETF par les recommandations RFC 1112, RFC 2236 et RFC 3376 ou selon le protocole MLD, pour Multicast Listener Discovery en anglais, défini par les recommandations RFC 2710, RFC 3810.

Sur réception d'un message de requête de réception, message du type

"Membership report", précisant l'adresse source de diffusion souhaitée, le premier équipement de télécommunication du réseau EP capable d'interpréter ce message de requête transmet le flux de données Multicast correspondant sur le lieu d'où provient ce message de requête.

Un message de requête de diffusion de flux Multicast peut également se rapporter à un ensemble de sources pour un groupe G donné, le flux Multicast étant alors désigné (*,G) et correspondant alors à une somme des flux émis par les différentes sources vers ce même groupe.

Dans le contexte de la diffusion de flux Multicast et de la présente demande, on désigne par équipement de collecte l'équipement réseau prenant en charge le message de requête IGMP/MLD d'un utilisateur, afin d'envoyer à ce dernier le flux de données Multicast correspondant. A l'heure actuelle, les protocoles de transmission de message de requête de diffusion Multicast, de type IGMP, ne définissent pas de méthode d'authentification ni d'autorisation d'un utilisateur demandeur à solliciter la transmission d'un flux Multicast en réseau.

Des tentatives dans ce but ont été proposées auprès de I ¹ IETF suggérant de modifier les messages de requête précités dans le but d'acheminer des informations d'authentification vers une plateforme d'authentification/autorisation. La réussite de l'authentification et de l'autorisation permet la prise en compte du message de requête de l'utilisateur demandeur par l'équipement de collecte.

La proposition précitée, finalement non avenue, pose les problèmes suivants :

- impact majeur sur les protocoles de gestion de flux Multicast existants, en raison de l'ajout de couches d'authentification sur les équipements d'accès au réseau et sur l'équipement terminal de l'utilisateur ;

- nécessité d'un accès à une plate-forme d'autorisation à chaque message de requête de flux Multicast transmis par un utilisateur, processus qui peut augmenter le temps de réception du flux Multicast de façon sensible dans le cas de diffusion Multicast de programmes TV sur ligne haut débit de type ADSL par exemple.

Une autre approche d'autorisation a en outre été proposée. Selon cette dernière, dans le but de déterminer le droit d'un utilisateur à demander la diffusion d'un flux Multicast déterminé, le terminal de l'utilisateur demandeur sollicite cette autorisation auprès d'une plateforme d'autorisation spécifique connectée au réseau IP. Sur réception de la demande d'autorisation, la plateforme d'autorisation retourne une acceptation ou un rejet de l'autorisation, selon les droits à recevoir le flux Multicast demandé dont dispose l'utilisateur. Sur réception de l'autorisation acceptée, le terminal de l'utilisateur émet alors à destination du réseau un message de requête de

diffusion Multicast, du type requête IGMP, afin de recevoir le flux Multicast correspondant.

Cette dernière solution présente les inconvénients suivants :

- nécessité d'un accès à une plateforme d'autorisation à chaque message de requête de diffusion des flux Multicast, ce qui, comme dans le cas de la proposition précédente, peut augmenter le temps de réception du flux Multicast de façon sensible dans le cas de diffusion Multicast de programme TV sur ligne haut débit de type ADSL ;

- problème de sécurité dans le cas où le terminal de l'utilisateur est modifié pour envoyer un message de requête de diffusion Multicast de type IGMP vers le réseau IP sans demande préalable des droits à la plateforme d'autorisation.

La présente invention a pour objet de remédier à l'ensemble des inconvénients des propositions de l'art antérieur, par la mise en œuvre d'un procédé et d'un système local de contrôle d'accès à des flux IP Multicast. En particulier, ce but est atteint en développant au niveau de tout équipement de collecte une fonction locale spécifique d'acceptation ou de refus des messages de requête de diffusion IP Multicast.

Un autre objet de la présente invention est, en outre, la mise en œuvre d'un procédé et d'équipements de contrôle d'accès à des flux IP Multicast grâce auxquels les protocoles de transmission de message de requête de diffusion IP Multicast IGMP ou MLD sont inchangés, ce qui permet de garantir une totale compatibilité du procédé et du système objets de l'invention avec les matériels terminaux utilisateur existants.

Un autre objet de la présente invention est, en outre, la mise en œuvre d'un procédé et d'un système local de contrôle d'accès à des flux IP Multicast dans lesquels le volume des échanges protocolaires avec une entité d'autorisation, chargée d'accepter ou de refuser l'autorisation d'accès demandée, est réduit de manière significative.

Le procédé de contrôle d'accès à un flux IP Multicast demandé par le terminal utilisateur à un équipement de collecte de messages de requête de diffusion

- A -

de flux IP Multicast connecté au réseau IP, objet de la présente invention, est remarquable en ce que, suite à la connexion de ce terminal utilisateur à cet équipement de collecte, celui-ci consiste au moins à transmettre de cet équipement de collecte vers un serveur de contrôle d'accès, connecté au réseau IP, un message de demande d'autorisation d'accès. Suite à une authentifîcation et/ou une identification et à une vérification réussies des droits d'accès dont dispose le terminal utilisateur par ce serveur de contrôle d'accès, il consiste à transmettre de ce serveur de contrôle d'accès vers cet équipement de collecte un message d'acceptation d'autorisation d'accès comportant au moins un filtre Multicast. Sinon, suite à un échec d'authentification et/ou d'identification et de vérification réussies des droits d'accès dont dispose ce terminal utilisateur par le serveur de contrôle d'accès, il consiste à transmettre de ce serveur de contrôle d'accès vers cet équipement de collecte un message de refus d'autorisation d'accès pour inhiber la connexion du terminal utilisateur. Le procédé de contrôle d'accès à un flux IP Multicast objet de la présente invention trouve application au contrôle et à la gestion de la diffusion des flux Multicast sur réseau IP, réseau local d'entreprise et/ou réseau Internet, et à la distribution des applications et/ou services tels que applications multimédia du type ligne TV sur ADSL véhiculé(e)s par les flux IP Multicast précités. Le procédé objet de l'invention sera mieux compris, ainsi que les équipements permettant la mise en œuvre de ce dernier, à la lecture de la description et à l'observation des dessins ci-après dans lesquels :

- la figure 1 représente, à titre purement illustratif, un diagramme spatio-temporel des étapes essentielles de mise en œuvre du procédé objet de la présente invention,

- la figure 2a représente, à titre purement illustratif, une variante de mise en œuvre du procédé objet de l'invention lors d'une phase de changement d'autorisation d'accès proposée pour un terminal utilisateur spécifique,

- la figure 2b représente, à titre purement illustratif, une variante de mise en œuvre du procédé objet de l'invention lors d'une phase de renouvellement d'autorisation d'accès proposée pour un terminal utilisateur spécifique,

- la figure 3 a représente, à titre purement illustratif, la structure d'un filtre Multicast permettant la mise en œuvre du procédé objet de la présente invention,

- la figure 3b représente, à titre purement illustratif, une architecture spécifique de mémorisation de filtres Multicast permettant la mise en œuvre du procédé objet de la présente invention, - la figure 4a représente, à titre illustratif, un serveur de contrôle d'accès, conforme à l'objet de la présente invention,

- la figure 4b représente, à titre illustratif, un équipement de collecte conforme à l'objet de la présente invention.

Une description plus détaillée du procédé de contrôle d'accès à un flux IP Multicast demandé, par un terminal utilisateur, à un équipement de collecte connecté au réseau IP sera maintenant donnée en liaison avec la figure 1 et les figures suivantes.

D'une manière générale, on considère un terminal utilisateur UT non représenté au dessin de la figure 1, connecté à un réseau IP. Le terminal utilisateur précité peut procéder à la transmission vers l'équipement de collecte CE d'un message de requête de connexion et de diffusion de flux IP Multicast de manière totalement classique.

Le message de requête de diffusion de flux IP Multicast correspond par exemple à un message de requête transmis conformément au protocole IGMP ou au protocole MLD tel que mentionné précédemment dans la description.

En référence à la figure 1, le procédé objet de la présente invention consiste au moins à transmettre de l'équipement de collecte CE vers un serveur de contrôle d'accès ACS, connecté au réseau IP, un message de demande d'autorisation d'accès noté AAD sur la figure précitée.

Sur la même figure on a noté 1 une étape de préparation du message de demande d'autorisation d'accès de données AAD et 2 l'opération proprement dite de transmission du message AAD précité vers le serveur de contrôle d'accès ACS.

L'étape 2 précitée est alors suivie d'une étape 3 exécutée au niveau du serveur de contrôle d'accès ACS consistant en une authentification et/ou une identification du terminal utilisateur et en une vérification des droits d'accès dont dispose le terminal utilisateur UT. Cette étape notée 3 est exécutée par le serveur de contrôle d'accès ACS et représentée par la relation symbolique = vraie

On indique que les critères et les processus de mise en œuvre d'authentification et de vérification des droits d'accès peuvent être des critères et des processus classiques lesquels, pour cette raison, ne seront pas décrits en détail.

Sur authentification et/ou identification et vérification réussies des droits d'accès à l'étape 3,1e procédé consiste alors à transmettre en une étape 4 du serveur de contrôle d'accès ACS vers l'équipement de collecte CE, un message d'acceptation d'autorisation d'accès AAA. Le message précité comprend au moins un filtre Multicast.

L'étape 4 précitée est alors suivie d'une étape 5 exécutée au niveau de l'équipement de collecte CE laquelle consiste à permettre la connexion du terminal utilisateur UT à l'équipement de collecte CE, ainsi qu'à installer dans ce dernier le ou les filtres Multicast transportés lors de l'étape 4.

Au contraire, suite à un échec d'authentification et/ou d'identification du terminal utilisateur et de vérification réussies des droits d'accès dont dispose le terminal utilisateur UT, cette étape étant représentée par l'étape 3' de la figure 1 au niveau du serveur d'authentification ACS et symbolisé par la relation

/^V(AAR) = faux

V_A,

Ie procédé objet de l'invention est poursuivi par une étape 4' consistant à transmettre, du serveur de contrôle d'accès ACS vers l'équipement de collecte CE, un message de refus d'autorisation d'accès AAR. Le message transmis à l'étape 4' précité permet alors d'inhiber en une étape 5' exécutée au niveau de l'équipement de collecte CE la connexion du terminal utilisateur à ce dernier.

Toutefois, et selon un mode de mise en œuvre préférentiel non limitatif du procédé objet de la présente invention, le message d'acceptation d'autorisation d'accès AAA comporte avantageusement au moins un ensemble de filtres Multicast, lesquels sont bien entendu destinés à conduire le contrôle d'accès proprement dit suite à la réception du message AAA après l'étape 4 de transmission de ce dernier par l'équipement de collecte CE.

En particulier, selon un aspect remarquable du procédé objet de la présente invention, chaque filtre Multicast comporte au moins une valeur de type de filtre par autorisation ou refus de transmission d'un message de requête de diffusion IP Multicast, cette requête de diffusion Multicast étant définie par exemple par le couple d'adresse S, G de la source S de la diffusion Multicast et du groupe G considéré.

Ainsi que représenté sur la figure 1 précitée, pour exécuter l'étape 4 de transmission du message d'autorisation d'acceptation d'accès AAA accompagnée de l'ensemble des filtres notés (MFj) f , j désignant une référence de filtre MF par exemple, l'on procède à l'étape 3 de la figure 1 à une récupération des droits utilisateur sur le flux Multicast pour traduire en termes d'un ensemble de filtres IP Multicast l'ensemble des droits précités.

Dans ce but, outre un champ comportant une valeur de type de filtre par autorisation ou refus de transmission d'un message de requête de diffusion IP Multicast, chaque filtre peut comporter avantageusement au moins l'adresse IP(S) de la source de diffusion du flux IP Multicast, l'adresse IP(G) du groupe Multicast destinataire de la diffusion Multicast, une valeur fonctionnelle de mise à jour par adjonction, ou suppression d'un filtre IP Multicast existant, dont le rôle sera décrit ultérieurement dans la description, et un numéro d'identification de filtre IP

Multicast, ce numéro d'identification de filtre étant lié à l'indice j précédemment mentionné.

En conséquence, sur la figure 1, le message d'acceptation d'autorisation d'accès est représenté par la relation AAA(MR) ₁ ¹ * .

Le procédé objet de la présente invention tel que décrit en liaison avec la figure 1 peut avantageusement être mis en œuvre grâce à la famille des protocoles de transmission de messages de type AAA pour Authentication Authorization, Accounting en anglais, le serveur de contrôle d'accès ACS étant, dans cette hypothèse, un serveur de même type serveur AAA mettant plus particulièrement en œuvre le protocole dit protocole RADIUS.

Le procédé objet de la présente invention peut également être mis en œuvre grâce au protocole DIAMETER et, dans cette hypothèse, l'échange de messages entre l'équipement de collecte CE et, le serveur de contrôle d'accès ACS est effectué selon ce protocole, le serveur de contrôle d'accès précité étant lui-même un serveur de type serveur AAA mettant plus particulièrement en œuvre le protocole DIAMETER.

Le procédé objet de la présente invention tel que décrit en liaison avec la figure 1 peut être mis en œuvre en particulier lors d'une demande de connexion d'un terminal utilisateur UT ou en tout cas pour toute demande de connexion d'un terminal utilisateur à un équipement de collecte.

Le procédé objet de la présente invention permet également de mettre en œuvre différentes variantes particulières lesquelles permettent en fait d'exécuter des opérations, telles que le changement d'autorisation d'accès, alors que les droits par exemple de l'utilisateur sont toujours valides mais que ces droits demandent un changement en vue d'une modification de promotion d'accès ou autre par exemple, respectivement lors d'un renouvellement des droits d'un utilisateur déterminé, les droits précités étant alors considérés comme toujours valables mais impérativement renouvelables. Le changement ou le renouvellement d'autorisation d'accès sont exécutés par une opération réalisée sous l'autorité du seul serveur de contrôle d'accès ACS.

Une variante de réalisation de mise en œuvre du procédé objet de la présente invention dans une application à un changement d'autorisation d'accès sera maintenant donnée en liaison avec la figure 2a. On conçoit en particulier que dans cette situation le renouvellement est également mis en œuvre sous l'autorité du seul serveur de contrôle d'accès ACS dans les conditions ci-après.

Suite à la transmission du message d'acceptation d'autorisation, telle que décrite précédemment en figure 1, le terminal utilisateur considéré étant connecté, le procédé objet de l'invention dans la variante selon la figure 2a consiste par exemple, sous le contrôle du serveur de contrôle d'accès ACS à transmettre du serveur de contrôle d'accès précité vers l'équipement de collecte CE un message de changement d'autorisation d'accès noté AC.

De préférence, ainsi que représenté en figure 2a, le message de changement d'autorisation d'accès précité comporte la transmission de filtres Multicast permettant d'exécuter ce changement auprès de l'équipement de collecte CE. A la figure 2a, l'étape de transmission précitée du message de changement d'autorisation est notée 2a.

Elle est suivie d'une étape 3 a, exécutée au niveau de l'équipement de collecte CE, laquelle consiste à vérifier le changement d'autorisation proposé et à accepter et exécuter le changement d'accès précité sous l'autorité de l'équipent de collecte CE. L'étape 3 a est alors suivie d'une étape 4a consistant à transmettre de l'équipement de collecte CE vers le serveur de contrôle d'accès ACS un message de notification d'acceptation et d'exécution du changement d'autorisation d'accès par l'équipement de collecte, ce message étant noté :

NOT(AC). Sinon, sur rejet et absence d'exécution du changement d'autorisation d'accès au niveau de l'équipement de collecte CE, cette étape de rejet étant notée 3a' sur la figure 2a, le procédé de changement d'autorisation d'accès objet de l'invention, tel que représenté en figure 2a, consiste à transmettre de l'équipement de collecte CE vers le serveur de contrôle d'accès ACS un message de refus et de non exécution du

changement d'autorisation d'accès par l'équipement de collecte. Sur la figure 2a, le message de refus et de non exécution du changement d'autorisation d'accès est noté

NOT(AC) .

L'étape 4a' précitée peut alors être suivie au niveau du serveur de contrôle d'accès ACS d'une étape 5a' laquelle consiste à boucler le processus d'autorisation d'accès.

On comprend, en particulier, que dans le cadre du changement d'autorisation d'accès illustrée en figure 2a, le message de changement d'autorisation d'accès permet de transporter un ou plusieurs filtres IP Multicast dont la valeur fonctionnelle est une valeur fonctionnelle de mise à jour par adjonction ou suppression d'un filtre IP

Multicast existant.

Une description plus détaillée d'une variante de mise en œuvre du procédé objet de l'invention dans le cas d'un renouvellement d'une autorisation d'accès pour un utilisateur déterminé sera maintenant donnée en liaison avec la figure 2b. Le procédé objet de l'invention-- tel que décrit en liaison avec la figure 2b, dans le cas d'un renouvellement d'une autorisation d'accès, ou en tout cas de la transmission d'une nouvelle autorisation d'accès, peut être mis en œuvre tant que le terminal utilisateur UT considéré est connecté au réseau IP, à l'initiative du serveur de contrôle d'accès ACS. En référence à la figure 2b et sous le contrôle du serveur de contrôle d'accès

ACS, le procédé objet de l'invention consiste alors en une étape Ib consistant pour le serveur de contrôle d'accès ACS à prendre une décision de nouvelle autorisation d'accès pour l'utilisateur UT considéré et à établir de nouveaux droits utilisateur sur le flux Multicast, ces nouveaux droits pouvant alors être traduits en termes de filtres Multicast, ainsi que décrit précédemment dans la description.

L'étape Ib précitée est alors suivie d'une étape 2b consistant à transmettre, du serveur de contrôle d'accès vers l'équipement de collecte CE, un message de renouvellement d'autorisation d'accès, lequel est noté AR sur la figure 2b précitée.

L'étape 2b est alors suivie d'une étape 3b exécutée par l'équipement de collecte CE laquelle consiste par exemple à prendre en compte la demande de renouvellement transmise par le serveur de contrôle d'accès ACS.

L'étape 3b est alors suivie d'une étape 4b consistant à transmettre, de l'équipement de collecte CE vers le serveur de contrôle d'accès ACS, un message de notification de prise en compte de la demande de renouvellement par l'équipement de collecte précitée.

L'étape 4b est alors suivie d'une étape 5b exécutée au niveau du serveur de contrôle d'accès ACS cette étape consistant à archiver la prise en compte de la demande de renouvellement d'autorisation d'accès pour l'utilisateur UT.

L'équipement de collecte CE procède à une étape 6b, étape analogue à l'étape 1 de la figure 1, par exemple, puis à une transmission, à l'étape 7b, d'une demande d'autorisation d'accès par un message AAD, lequel est pris en compte à l'étape 8b par le serveur de contrôle d'accès ACS. Ce dernier ayant mémorisé et archivé la notification de prise en compte transmise à l'étape 4b de réautorisation d'accès et de l'archivage de cette demande à l'étape 5b, procède, à une étape 8b, à une vérification des droits d'accès pour le terminal utilisateur UT et à l'envoi de nouveaux droits ou d'une d'autorisation d'accès renouvelée par l'envoi à l'étape 9b d'un message d'acceptation d'autorisation d'accès, comportant également une pluralité de filtres Multicast MF _j correspondant bien entendu aux nouveaux droits Multicast dans le cadre du renouvellement de l'autorisation.

L'étape 9b est alors suivie d'une étape 10b exécutée au niveau de l'équipement de collecte CE, cette étape étant bien entendu semblable à l'étape 5 de la figure 1 par exemple.

Dans le cas où, ainsi que représenté en figure 2b, la vérification des droits par le serveur de contrôle d'accès ACS ne peut être effectuée à l'étape 8b', cette dernière étape est alors suivie d'une étape 9b' de transmission d'un message de refus d'autorisation d'accès AAR comparable à l'étape 4' de la figure 1.

L'étape 9b' est suivie d'une étape 10b' exécutée par l'équipement de collecte CE prenant en compte le rejet de l'autorisation d'accès de manière semblable à l'étape 5' de la figure 1, sans pour autant inhiber la connexion du terminal utilisateur UT à l'équipement de collecte CE. Enfin, d'une manière générale, on indique que toute demande d'autorisation ou de réautorisation d'accès transmise de l'équipement de collecte CE vers le serveur de contrôle d'accès ACS est suivie d'une étape de vérification des droits d'accès du terminal utilisateur demandeur exécuté par le serveur de contrôle d'accès ACS précité. Une description plus détaillée des filtres IP Multicast et de leur expression dans les messages d'acceptation d'autorisation d'accès AAA précité sera maintenant donnée en liaison avec la figure 3a et la figure 3b.

Sur la figure 3 a on a représenté en fait la structure d'un filtre IP Multicast permettant la mise en œuvre du procédé objet de la présente invention. IJn tel filtre, en particulier lorsque ce dernier est incorporé dans un message d'acceptation d'autorisation d'accès, comprend avantageusement, ainsi que représenté en figure 3 a, une valeur de type de filtre par autorisation ou refus de transmission d'un message de requête de diffusion IP Multicast défini par un couple d'adresses. Sur la figure 3a, la valeur de type est désignée Ty et est réputée prendre deux valeurs arbitraires 0 ou 1 lors de l'autorisation respectivement du refus de transmission d'un message de requête de diffusion EP Multicast.

Le filtre D? Multicast comporte également, ainsi que représenté sur la figure précitée, l'adresse IP(S) de la source de diffusion du flux D? Multicast, l'adresse IP(G) du groupe Multicast destiné à recevoir la diffusion Multicast considérée depuis la source d'adresse S et une valeur fonctionnelle notée FV de mise à jour par adjonction, ou suppression d'un filtre IP Multicast existant. Sur la figure 3 a, la valeur fonctionnelle FV est réputée pouvoir prendre 2 valeurs distinctes arbitraires 0, 1 chaque valeur correspondant à la fonction d'ajout ou de suppression d'un filtre IP Multicast existant. En ce qui concerne la valeur 0, représentant par exemple la fonction d'adjonction, cette dernière peut correspondre à un remplacement, dans un

filtre Multicast donné installé, des valeurs d'adresse de source S et/ou de groupe G, ainsi que des valeurs de type Ty.

Enfin, chaque filtre Multicast comprend un numéro d'identification de filtre IP Multicast noté en en-tête par exemple, IDMF.

L'ensemble des messages précités permet ainsi de véhiculer une pluralité de filtres Multicast, lesquels bien entendu, représentent l'ensemble des droits d'accès Multicast de chaque terminal utilisateur considéré UT.

En particulier, les échanges de messages précités peuvent être exécutés au moyen de la famille des protocoles AAA, tels que les protocoles RADIUS et DIAMETER précédemment mentionnés dans la description suivant le tableau 1 ci- après.

Tableau 1 : Application aux protocoles RADIUS et DIAMETER

En référence au tableau précité, le transport des filtres Multicast s'effectue alors par le moyen d'un attribut dédié à affecter par les entités assurant le contrôle d'accès et en particulier par le serveur de contrôle d'accès ACS. Cet attribut peut être exécuté par un attribut de type VSA pour Vendor

Spécifie Attribute.

Dans le tableau précité :

- la première colonne désigne les messages AAA c'est-à-dire les messages transmis et précédemment décrits avec les figures 1, 2a, 2b, - la deuxième colonne désigne un mode d'implémentation des messages précités dans le cadre du protocole RADIUS selon la recommandation RFC 2865 et RFC 3576 de l'IETF pour Internet Engineering Task Force ;

- la troisième colonne désigne un mode d'implémentation des messages précités selon le protocole DIAMETER RFC 3588 + NASREQ. NASREQ est une proposition référencée actuellement draft-ietf-aaa-diameter-nasreq- 17.txt, proposition ayant pour vocation à évoluer comme RFC.

Dans les colonnes précitées du tableau, les mentions «n italique des deuxième et troisième colonnes font référence à la désignation officielle selon les recommandations correspondantes pour les protocoles RADIUS respectivement DIAMETER.

On notera en particulier que, le changement d'autorisation tel que décrit en liaison avec la figure 2a, par exemple, est exclusivement mis en œuvre grâce au

protocole RADIUS car le protocole DIAMETER ne permet pas, à l'heure actuelle, l'utilisation de messages spécifiques pour ce type d'opération.

Le nombre de filtres Multicast envoyés par message dépend de la taille maximale du message autorisé par le protocole considéré. Il dépend également de la taille maximale qu'autorise le protocole pour le transport d'un attribut. Il est possible d'envoyer plusieurs fois le même attribut dans le même message. Le système de numérotation des filtres Multicast, c'est-à-dire l'attribution du numéro d'identification IDMF permet également de mettre en place les filtres précités en répétant plusieurs fois les échanges décrits précédemment. Le format des filtres Multicast envoyés peut être optimisé par exemple en effectuant des regroupements du type :

- regroupement des filtres dont le type de filtre est le même, permission respectivement refus, selon l'opération à réaliser ajouter ou supprimer ;

- regroupement des opérations ajout ou suppression ; - regroupement des sources devant être filtrées pour un groupe d'utilisateurs donnés ;

- regroupement des groupes devant être filtrés pour une source donnée. Sur réception du message d'acceptation d'autorisation d'accès, le message

AAA des figures 1, 2b, et du message AC de la figure 2a en particulier du message précité comportant les filtres Multicast pour le terminal utilisateur considéré UT, l'équipement de collecte CE procède alors aux opérations suivantes :

- détermination du contexte propre à la gestion de la connexion utilisateur concerné pour l'installation des filtres, une telle opération ainsi que représenté en figure 3b peut consister à discriminer un identifiant d'utilisateur noté UID ₁ à UIDj sur la figure 3 et les informations de contexte correspondantes ;

- extraction proprement dite des filtres reçus par le protocole de type protocole AAA, cette extraction consistant en une lecture des différents champs de chaque filtre tel que représenté en figure 3 a,

- évaluation du contenu du filtre Multicast candidat à l'installation.

Dans cette opération, les filtres reçus pour une opération de suppression permettent alors la suppression des filtres existants sur la base, par exemple, du numéro de filtre, c'est-à-dire du numéro IDMF correspondant, les filtres étant, par exemple, mémorisés avec leur contexte utilisateur et leur identifiant de filtre IDMF désigné MF ₁₁ à MFMI respectivement MFn à MFNI sur la figure 3b. Les filtres peuvent également être supprimés sur la base du triplet S, G, type, c'est-à-dire la variable Ty. Dans le cas où il existe une incohérence entre le triplet S, G, Ty et le numéro du filtre, alors aucun filtre pouvant correspondre n'est supprimé. En l'absence d'incohérence, bien entendu, le filtre Multicast candidat à la suppression est alors supprimé.

Les filtres reçus pour une opération d'adjonction sont installés à la place indiquée par exemple par le numéro de filtre, ou selon une relation biunivoque, à une adresse mémoire de l'équipement de collecte CE.

Lorsque par exemple, le numéro de filtre n'est pas indiqué, l'équipement de collecte CE peut alors installer le filtre à la suite de la liste des filtres propres au contexte utilisateur dans l'ordre d'évaluation des filtres reçus et en affectant un numéro interne supérieur au numéro existant pour le contexte.

Si au contraire, le numéro de filtre spécifié fait référence à un filtre différent déjà en place, le nouveau filtre est implanté à la place de ce dernier. En référence à la figure 3b, on indique que chaque filtre MF ₁₁ à MFMI OU

MFH à MF _NÏ est stocké en conservant les champs suivants :

- le numéro d'ordre du filtre dans la liste des filtres Multicast présents dans le contexte utilisateur, c'est-à-dire le numéro d'identification IDMF ;

- l'adresse IP source adresse IP(S) du filtre Multicast considéré ou la désignation de toutes les adresses de source possibles ("*" ou encore représentables comme l'adresse IP 0.0.0.0) ;

- l'adresse IP du groupe Multicast G considérée ou la désignation de toutes les adresses de groupe possibles ("*" ou encore représentables comme l'adresse IP 0.0.0.0) ;

- le type de filtre, c'est-à-dire permission ou refus par la variable Ty permettant de déterminer l'interprétation qui doit être faite du filtre lors de l'évaluation d'une requête.

Ainsi, les informations stockées par l'équipement de collecte CE sont équivalentes à celles transportées par les messages d'acceptation d'autorisation d'accès AAA, bien que le format de stockage puisse apparaître différent du format de transport.

Seule l'information relative à l'opération d'ajout ou de suppression réalisée par l'équipement de collecte CE peut être supprimée, les filtres successifs étant stockés et mémorisés au niveau de l'équipement de collecte CE ainsi que représenté en figure 3b.

En ce qui concerne l'évaluation d'un message de requête de diffusion de flux IP Multicast par l'équipement de collecte CE, requête IGMP ou MLD, cette évaluation peut être effectuée de la manière suivante : - détermination de la provenance de la requête permettant de retrouver le contexte de l'utilisateur concerné et découpage de la requête en demande de flux individuels : si la requête de demande de réception des flux Sl, S2, S3, Gl, c'est-à- dire des flux diffusés par les sources Sl, S2, S3 pour le groupe Gl, les requêtes obtenues par distribution des sources sur le groupe, c'est-à-dire les requêtes SlGl, S2G1, S3G1 sont évaluées de façon séparée ;

- avant la prise en compte des numéros d'ordre des filtres, les requêtes sont évaluées en premier face au filtre suivant : a) interdiction globale d'une source quels que soient les groupes, soit

(S,*) ; b) interdiction globale d'un groupe quelles que soient les sources, soit (*, G).

- la requête est évaluée face à chaque filtre dans l'ordre donné par les numéros de filtre jusqu'à ce que la description du flux Multicast de la requête corresponde au filtre considéré ;

- la première action, permission ou refus, termine l'évaluation de la requête dans la liste des filtres ;

- en cas de non correspondance de la requête au filtre du contexte utilisateur, la requête est refusée par défaut. En particulier on peut considérer cependant que l'absence de filtre pour un utilisateur signifie l'absence de volonté de tout filtrage auquel cas toute requête est acceptée ;

- pour accepter par défaut une requête en fin d'évaluation il faut la présence d'un filtre de type permission avec S et/ou G valorisé à 0.0.0.0 et dont le numéro d'ordre place le filtre en fin de liste d'évaluation ; - si la requête est acceptée, alors la commande de flux Multicast est poursuivie de façon transparente au processus de contrôle et d'autorisation. Si la requête est refusée, aucune action n'est engagée pour une commande de flux Multicast correspondant à la requête refusée.

Une description plus détaillée d'un serveur de contrôle d'accès à flux Multicast conforme à l'objet de la présente invention sera maintenant donnée en liaison avec la figure 4a.

En référence à la figure précitée, on indique que, outre une unité centrale de traitement CPU, une unité de mémoire de travail RAM et une unité d'entrée-sortie I/O permettant la connexion du serveur du contrôle d'accès ACS au réseau Internet ainsi que représenté en figure 4a, celui-ci comporte au moins un module générateur de messages d'autorisation d'accès, les messages AAA de la figure 1 et 2b et AC de la figure 2a, ce module générateur étant noté MA ₁ sur la figure 4a. En particulier le module générateur peut consister en un module de programme MA ₁ , lequel est mémorisé dans le serveur de contrôle d'accès ACS et dans la zone de mémoire de programme PROG _A de ce dernier. On comprend bien sûr que les messages d'acceptation comportent au moins un filtre Multicast tel que décrit en liaison avec la figure 3 a et comportent, en particulier, au moins une valeur de type de filtre par autorisation ou refus de transmission d'un message de requête de diffusion IP Multicast défini par un couple d'adresses. Bien entendu, le serveur de contrôle d'accès ACS objet de l'invention comprend également d'autres modules générateurs de

message notés MAx et correspondant, par l'appel en mémoire de travail RAM par la CPU, à la mise en œuvre du procédé tel que décrit en liaison avec les figures 1 et 2a, 2b.

Une description plus détaillée d'un équipement de collecte CE d'un message de requête de diffusion IP Multicast conforme à l'objet de la présente invention sera également décrit en liaison avec la figure 4b.

En référence à cette figure, outre une unité centrale de traitement CPU, une mémoire de travail, RAM et des organes d'entrée-sortie I/O permettant la connexion de cet équipement de collecte CE au réseau Internet, celui-ci comporte au moins un module générateur d'un message de demande d'autorisation d'accès, c'est-à-dire du message AAD de la figure 1, 2a ou 2b. Ce module générateur peut correspondre par exemple, à un module de programme MC ₁ mémorisé dans une zone de mémoire de programme PROGc de l'équipement de collecte CE et appelé par l'unité centrale dans la mémoire de travail de ce dernier pour exécution correspondante. De même, l'équipement de collecte CE comporte un module de mémorisation de messages d'acceptation d'autorisation d'accès, module noté MC ₂ sur la figure 4b, c'est-à-dire des messages AAA ainsi que des filtres Multicast contenus dans ces derniers. Il comporte également un module MC ₃ d'installation des filtres Multicast précités ainsi que décrits précédemment dans la description. Les modules MC ₂ et MC ₃ correspondent également à des modules de programme mémorisés dans la mémoire de programme PROGc de l'équipement de collecte CE. Pour exécution, ces derniers sont appelés par la CPU dans la mémoire de travail RAM et exécution correspondante conformément au procédé décrit précédemment dans la description en liaison avec les figures 1, 2a, 2b. D'autres modules fonctionnels notés MC _x peuvent être prévus dans la zone de mémoire de programme précitée. En particulier, un module MC ₄ est prévu pour exécuter l'analyse des requêtes de diffusion IP Multicast vis-à-vis des filtres Multicast installés.

En ce qui concerne le module d'installation MC ₃ , celui-ci, pour chaque filtre Multicast reçu, exécute les opérations consistant à discriminer, à partir du message de requête de diffusion IP Multicast, les références du terminal utilisateur demandeur, à

extraire du message d'acceptation d'autorisation de diffusion IP Multicast chaque filtre Multicast, évaluer le contenu du filtre Multicast candidat à l'installation ainsi que décrit précédemment dans la description, et, sur évaluation de Ia valeur fonctionnelle de suppression, supprimer le filtre Multicast existant correspondant, puis installer le filtre Multicast candidat à installation. Sinon sur évaluation de la valeur fonctionnelle d'adjonction ou de mise à jour du filtre candidat à installation, installer le filtre Multicast candidat à installation, ainsi que décrit précédemment dans la description.

L'invention couvre en outre un programme d'ordinateur enregistré sur un support de mémorisation comportant une suite d'instructions pour exécution par un ordinateur ou un dispositif dédié, tel qu'un serveur de contrôle d'accès à un flux EP Multicast précédemment décrit en liaison avec la figure 4a. Il est remarquable en ce que, lors de cette exécution, cette suite d'instructions permet la mise en œuvre des étapes d'authentification et/ou d'identification et de vérification des droits d'accès d'un terminal utilisateur et de transmission de ce serveur de contrôle d'accès vers un équipement de collecte d'un message d'acceptation ou de refus d'acceptation d'accès du procédé de contrôle d'accès à un flux IP Multicast demandé par ce terminal utilisateur, précédemment décrit en liaison avec les figures 1, 2a, 2b, 3a et 3b.

L'invention couvre enfin un programme d'ordinateur enregistré sur un support de mémorisation comportant une suite d'instructions pour exécution par un ordinateur ou un dispositif dédié, tel qu'un équipement de collecte d'un message de requête de diffusion IP Multicast émis par un terminal utilisateur, précédemment décrit en liaison avec la figure 4b. Il est remarquable en ce que, lors de cette exécution, cette suite d'instructions permet la mise en œuvre de l'étape de transmission, de cet équipement de collecte vers un serveur de contrôle d'accès, d'un message de demande d'autorisation d'accès du procédé de contrôle d'accès à un flux IP Multicast demandé par ce terminal utilisateur, précédemment décrit en liaison avec les figures 1, 2a, 2b, 3 a et 3 b.