Brevet FR3157043A1 — publié le 20250620

Procédé de détermination d’un ensemble de flux multicast auxquels un terminal récepteur est habilité à accéder. L’invention se rapporte à un procédé de détermination d’un ensemble de flux multicast auxquels un terminal récepteur est habilité à accéder, parmi une pluralité de flux diffusés par un service de contenus sur un réseau de communication. Un tel procédé comprend, au niveau d’un routeur : - la réception (RCP), en provenance dudit terminal, d’un message de signalisation comprenant une clé de résolution, dite alias (AL) ; - la mise en œuvre d’une procédure de résolution (RES) dudit alias, comprenant l’obtention d’une information (IH) parmi : -- une information représentative d’une habilitation dudit terminal à accéder à au moins un flux multicast de ladite pluralité de flux, comprenant au moins une adresse d’au moins un groupe multicast de diffusion dudit au moins un flux multicast ; ou -- une information représentative d’une absence d’habilitation dudit terminal à accéder à l’un quelconque desdits flux multicast de ladite pluralité de flux. Figure d’abrégé : Figure 1 Procédé de détermination d’un ensemble de flux multicast auxquels un terminal récepteur est habilité à accéder. Le domaine de l’invention est celui des communications au sein d’au moins un réseau de communication, et notamment celui des services IP à valeur ajoutée. Plus précisément, l’invention se rapporte à la mise en œuvre de services de diffusion de contenus exploitant un mode de transmission multicast dans un réseau de communication. Art antérieur La diffusion d’un même contenu à de multiples utilisateurs est un service couramment proposé et mis en œuvre via les réseaux de communication actuels, par exemple dans le cadre de la retransmission d’évènements culturels ou sportifs (retransmission d’un concert dans un métavers, retransmission d’un match de football en direct, etc.). Sur le plan technique, l’ingénierie de tels services de diffusion repose généralement sur un mode de transmission dit « multicast ». Ce mode est en effet particulièrement adapté aux schémas de communication de groupes, tels que la diffusion de contenus à destination de plusieurs utilisateurs (récepteurs), ou encore la mise en œuvre de services de type visioconférence entre plusieurs utilisateurs où chaque participant est à tour de rôle source ou récepteur. Dans les réseaux IP (« Internet Protocol »), le mode de transmission multicast repose sur le calcul, l’établissement et la maintenance d’arbres de distribution par un protocole de routage dynamique, tel que le protocole PIM (« Protocol Independent Multicast », RFC7761). Un objectif principal de la mise en œuvre de tels arbres de diffusion est d’optimiser les ressources d’un réseau selon un mode de réplication déterministe des données. Les réseaux de communication, notamment les réseaux mobiles de cinquième génération (5G), offrent par ailleurs la possibilité aux opérateurs qui les exploitent de gérer des habilitations (aussi appelées contrôle d’accès) relatives à l’acheminement du trafic sur le réseau. De telles habilitations reposent typiquement sur l’application de règles de classification de trafic, généralement appliquées par un point d’accès au réseau. Un tel point d’accès est un nœud situé en périphérie du réseau, par exemple déployé en frontal des accès clients ou bien utilisé pour connecter un réseau à d’autres réseaux voisins. Par exemple, ce point d’accès peut être situé à l’interface de raccordement d’une passerelle (par exemple une passerelle paquet, ou « Packet Gateway » en anglais, pour les générations les plus récentes – 4G, 5G – des réseaux mobiles) qui permet d’accéder au réseau Internet. Un tel point d’accès peut également se situer à l’interface de raccordement d’un terminal mobile (ou « User Equipment » ou UE en anglais) au réseau d’accès radio (ou « Radio Access Network » ou RAN en anglais), de façon notamment à optimiser l’usage des ressources radio en fonction du profil du trafic qu’elle est susceptible d’acheminer. Dans ce contexte, la politique d’acheminement de contenus diffusés en multicast sur un réseau de communication, repose notamment sur l’habilitation des terminaux récepteurs à accéder auxdits contenus. Par exemple, si le réseau de communication met en œuvre des tranches réseau, il doit pouvoir déterminer les capacités d’accès des récepteurs à l’une ou l’autre des tranches, en fonction par exemple de la nature du service de diffusion auquel un récepteur a souscrit. De telles considérations permettent d’ajuster dynamiquement avec un niveau de granularité adéquat (récepteur, contenu) les règles de classification de trafic qui régissent l’accès ou non des récepteurs à l’une ou l’autre de ces tranches, et in fine, auxdits contenus. Or, la mise en œuvre et la maintenance (par ex. en cas de modifications des droits d’accès d’un terminal ou un utilisateur) de telles règles de classification implique actuellement des configurations complexes du réseau, avec un risque substantiel d’erreurs lors des opérations de configuration en question. Il existe donc un besoin pour une technique permettant de simplifier la gestion des habilitations d’accès de terminaux récepteurs à des contenus multicast diffusés au sein d’un réseau de communication, et plus particulièrement l’obtention de telles informations d’habilitation par le réseau. La présente invention propose une solution visant à remédier à certains inconvénients de l’art antérieur. Selon un aspect, la présente invention se rapporte en effet à un procédé de détermination d’un ensemble de flux multicast auxquels un terminal récepteur est habilité à accéder, parmi une pluralité de flux multicast diffusés par un service de contenus sur un réseau de communication. Selon le principe général de l’invention proposée, un tel procédé comprend, au niveau d’un équipement routeur dudit réseau de communication : - la réception, en provenance dudit terminal récepteur, d’un premier message de signalisation comprenant une clé de résolution, dite alias, utilisable par ledit équipement routeur pour déterminer ledit ensemble ; - la mise en œuvre d’une procédure de résolution dudit alias, comprenant l’obtention, en fonction dudit alias, d’une information parmi (i) une information représentative d’une habilitation dudit terminal récepteur à accéder à au moins un flux multicast de ladite pluralité de flux multicast, comprenant au moins une adresse de groupe multicast, dite adresse multicast autorisée, d’au moins un groupe multicast associé à la diffusion dudit au moins un flux multicast ; ou (ii) une information représentative d’une absence d’habilitation dudit terminal récepteur à accéder à l’un quelconque desdits flux multicast de ladite pluralité de flux multicast. De cette manière, le réseau de communication dispose de moyens permettant d’identifier rapidement et simplement si un terminal récepteur est habilité ou non à accéder à tout ou partie des flux multicast diffusé par un service de contenus, et est ainsi par exemple apte à mettre en œuvre des traitements différenciés, par exemple appliquer des règles de classification, en fonction de ces informations. Dans un mode de réalisation particulier, ladite procédure de résolution est mise en œuvre intégralement au sein dudit équipement routeur. De cette manière, la résolution d’un alias peut être mise en œuvre localement, et donc plus rapidement, sans intervention d’un équipement tiers. Dans un autre mode de réalisation particulier, ladite procédure de résolution est mise en œuvre conjointement avec un équipement tiers, ladite obtention comprenant : - l’émission, à destination dudit équipement tiers, d’une requête de résolution dudit alias, comprenant ledit alias. - la réception, en provenance dudit équipement tiers, de ladite information représentative d’une habilitation ou d’une absence d’habilitation. Selon une caractéristique particulière, ledit équipement tiers appartient au groupe comprenant : - un équipement de contrôle dudit réseau de communication ; - un serveur de système de nom de domaine (DNS) au sein dudit réseau de communication ; - un équipement associé audit service de contenus. De cette manière, il n’est pas nécessaire de propager les informations permettant la résolution d’un alias, c’est-à-dire les informations de correspondances entre des alias et des adresses multicast autorisées associées, à un grand nombre d’équipements routeur d’un réseau de communication : les équipements routeur peuvent ainsi se reposer sur des équipements tiers mieux adaptés ou mieux optimisés pour de telles opérations de résolution. Dans un mode de réalisation particulier, ledit alias a le format d’un nom de domaine, comprenant un ou plusieurs niveaux hiérarchisés. De cette manière, les équipements tiers sollicités pour les opérations de résolution d’alias peuvent notamment prendre la former d’équipements existants déjà déployés sur le réseau de communication et spécialisés à cette fin, tels que des serveurs de système de nom de domaine par exemple. Selon une caractéristique particulière, un ou plusieurs niveaux hiérarchiquement supérieurs desdits niveaux hiérarchisés dudit alias, formant un sous-alias dit alias parent dudit alias, identifient de manière unique ledit service de contenus. De cette manière, le service de contenus peut être identifié directement à partir de l’alias. Dans un mode de réalisation particulier, ledit alias parent est utilisé pour identifier ledit service de contenus auquel transmettre une requête de résolution dudit alias, lorsque ladite procédure de résolution est configurée pour être mise en œuvre conjointement avec un équipement associé audit service de contenus. De cette manière, le réseau de communication est notamment en mesure d’acheminer vers le serveur autoritaire de l’alias parent toute requête de résolution concernant des alias fils. Dans un mode de réalisation particulier, ladite procédure de résolution dudit alias comprend une étape de recherche dudit alias au sein d’une liste d’alias marqués comme ayant déjà fait l’objet d’une résolution, et, en cas de présence dudit alias dans ladite liste, la délivrance d’une information représentative d’une absence d’habilitation dudit terminal récepteur à accéder à l’un quelconque desdits flux multicast de ladite pluralité de flux multicast. De cette manière, la présente technique permet de mettre en place des restrictions d’accès à certains flux multicast, lorsqu’il est détecté qu’un même alias est potentiellement partagé entre plusieurs terminaux récepteurs. Dans un mode de réalisation particulier, ladite réception dudit message de signalisation fait suite à l’émission d’un premier message de demande de signalisation émis par ledit équipement routeur à destination d’un ensemble de terminaux récepteurs connectés audit réseau de communication. De cette manière, on utilise de manière transparente et astucieuse ce qui peut être comparé à des mécanismes d’échanges de signalisation multicast classiques pour obtenir de la part des terminaux récepteurs connectés au réseau de communication les alias utilisables pour identifier les flux multicast auxquels ces terminaux sont habilités à accéder. Selon une caractéristique particulière, ledit premier message de demande de signalisation comprend au moins un identifiant dudit service de contenus. De cette manière, seuls les terminaux récepteurs qui souscrivent à un service de contenus particuliers peuvent être ciblés dans le cadre de la demande de signalisation. Selon une caractéristique particulière, ladite procédure de résolution est mise en œuvre au sein d’un équipement sélectionné en fonction dudit identifiant dudit service de contenus. De cette manière, l’équipement en charge de procéder à la résolution d’un alias est identifié facilement, en fonction du service de contenus considéré. Dans un mode de réalisation particulier, ledit procédé de détermination comprend, en outre, lorsque la procédure de résolution dudit alias délivre une information représentative d’une habilitation dudit terminal récepteur à accéder à au moins un flux multicast de ladite pluralité de flux multicast : - l’émission, à destination dudit terminal récepteur, d’un deuxième message de demande de signalisation comprenant ladite au moins une adresse multicast autorisée ; - la réception, en provenance dudit terminal récepteur, d’un deuxième message de signalisation représentatif d’une demande de souscription dudit terminal récepteur à au moins un groupe multicast associé au moins une de ladite au moins une adresse multicast autorisée. De cette manière, après obtention des flux multicast auxquels un terminal récepteur est habilité à accéder par le réseau de communication, des échanges de signalisation plus classiques peuvent être mis en œuvre afin de permettre au terminal récepteur d’indiquer les flux multicast auxquels il souhaite souscrire, et d’enclencher ainsi le processus permettant audit terminal récepteur de recevoir les flux sélectionnés. Selon une caractéristique particulière, lesdits messages de demande de signalisation et de signalisation sont des messages respectivement de type « Query » et « Report » selon un protocole de signalisation IGMP adapté ou un protocole de signalisation MLD adapté. De cette manière, l’implémentation de la présente technique dans l’écosystème existant est simplifiée, dans la mesure où est assurée une certaine compatibilité avec les protocoles de signalisation multicast IGMP et MLD largement utilisés pour la mise en place de services de diffusion multicast dans un réseau IP. Selon une caractéristique particulière, ledit réseau de communication met en œuvre des tranches réseau, et ladite réception du deuxième message de signalisation permet la mise en œuvre d’un traitement différencié en fonction d’au moins un identifiant de tranche encodé dans une adresse multicast et/ou compris dans un champ de données libre dudit deuxième message de signalisation. De cette manière, la présente technique permet notamment l’application facilitée de règles de classification au sein du réseau de communication. Selon un autre aspect, l’invention se rapporte à un procédé de souscription d’un terminal récepteur à au moins un groupe multicast associé à la diffusion d’un flux multicast au sein d’un réseau de communication, ledit procédé étant mis en œuvre par ledit terminal récepteur et comprenant : - la réception, en provenance d’un équipement routeur dudit réseau de communication, d’un premier message de demande de signalisation, comprenant au moins un identifiant d’un service de contenus ; - la transmission, à destination dudit équipement routeur, d’un premier message de signalisation, comprenant au moins une clé de résolution, dite alias, sélectionnée par ledit terminal récepteur en fonction dudit identifiant de service de contenus ; - la réception, en provenance dudit équipement routeur, d’un deuxième message de demande de signalisation, comprenant au moins une adresse multicast, dite adresse multicast autorisée, d’au moins un groupe multicast associé à la diffusion par ledit service de contenus d’au moins un flux multicast que ledit terminal récepteur est habilité à accéder ; - la transmission, à destination dudit équipement routeur, d’un deuxième message de signalisation représentatif d’une demande de souscription dudit terminal à au moins un groupe multicast associé au moins une de ladite au moins une adresse multicast autorisée. Selon un autre aspect, l’invention concerne un équipement routeur pour la détermination d’un ensemble de flux multicast auxquels un terminal récepteur est habilité à accéder, parmi une pluralité de flux multicast diffusés par un service de contenus via un réseau de communication, ledit équipement routeur comprenant au moins un processeur configuré pour : - recevoir, en provenance dudit terminal récepteur, d’un premier message de signalisation comprenant une clé de résolution, dite alias, utilisable par ledit équipement routeur pour déterminer ledit ensemble ; - mettre en œuvre d’une procédure de résolution dudit alias, comprenant l’obtention, en fonction dudit alias, d’une information parmi : -- une information représentative d’une habilitation dudit terminal récepteur à accéder à au moins un flux multicast de ladite pluralité de flux multicast, comprenant au moins une adresse multicast, dite adresse multicast autorisée, d’au moins un groupe multicast associé à la diffusion dudit au moins un flux multicast ; ou -- une information représentative d’une absence d’habilitation dudit terminal récepteur à accéder à l’un quelconque desdits flux multicast de ladite pluralité de flux multicast. Un tel équipement routeur pourra bien sûr présenter les différentes caractéristiques relatives au procédé de détermination selon l’invention, qui peuvent être combinées ou considérées isolément. Ainsi, les caractéristiques et avantages de cette équipement sont les mêmes que ceux du procédé de détermination et ne sont pas détaillés plus amplement. Selon un autre aspect, l’invention concerne un terminal récepteur apte à souscrire à un à au moins un groupe multicast associé à la diffusion d’un flux multicast au sein d’un réseau de communication, ledit terminal récepteur comprenant au moins un processeur configuré pour : - recevoir, en provenance d’un équipement routeur dudit réseau de communication, un premier message de demande de signalisation, comprenant au moins un identifiant de service de contenus ; - transmettre, à destination dudit équipement routeur, un premier message de signalisation, comprenant au moins une clé de résolution, dite alias, sélectionnée par ledit terminal récepteur en fonction dudit identifiant de service de contenus ; - recevoir, en provenance dudit équipement routeur, un deuxième message de demande de signalisation, comprenant au moins une adresse de groupe multicast, dite adresse multicast autorisée, d’au moins un groupe multicast associé à la diffusion par ledit service de contenus d’au moins un flux multicast que ledit terminal récepteur est habilité à accéder - transmettre, à destination dudit équipement routeur, un deuxième message de signalisation représentatif d’une demande de souscription dudit terminal à au moins un groupe multicast associé au moins une de ladite au moins une adresse multicast autorisée. Un tel terminal pourra bien sûr présenter les différentes caractéristiques relatives au procédé de souscription selon l’invention, qui peuvent être combinées ou considérées isolément. Ainsi, les caractéristiques et avantages de ce terminal sont les mêmes que ceux du procédé de souscription et ne sont pas détaillés plus amplement. Selon un autre aspect, l’invention proposée se rapporte également à un produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur, comprenant des instructions de code de programme pour l’exécution d'au moins un des procédés tels que décrits précédemment dans l’un quelconque de ses modes de réalisation, lorsque ce procédé est exécuté sur un ordinateur. L’invention proposée vise également un support d’enregistrement lisible par un ordinateur sur lequel est enregistré un programme d’ordinateur comprenant des instructions de code de programme pour l’exécution des étapes des procédés tel que décrits précédemment, dans l’un quelconque de leurs modes de réalisation. Un tel support d'enregistrement peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une clé USB ou un disque dur. D'autre part, un tel support d'enregistrement peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens, de sorte que le programme d’ordinateur qu’il contient est exécutable à distance. Le programme selon l'invention peut être en particulier téléchargé sur un réseau, par exemple le réseau Internet. Les différents modes de réalisation mentionnés ci-dessus sont combinables entre eux pour la mise en œuvre de l'invention. Figures D’autres caractéristiques et avantages de l’invention apparaîtront plus clairement à la lecture de la description suivante d’un mode de réalisation particulier, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels : FIG. 1 présente de manière schématique les différentes étapes d’un procédé de détermination d’un ensemble de flux multicast auxquels un terminal récepteur est habilité à accéder, dans un mode de réalisation particulier de l’invention proposée ; FIG. 2 présente un diagramme de séquence illustrant les échanges de messages de signalisation entre un réseau de communication et un terminal récepteur, dans un mode de réalisation particulier de la technique proposée ; FIG. 3 illustre un exemple de formalisme d’un message de signalisation IGMP adapté de type « Query », dans un mode de réalisation particulier de l’invention proposée ; FIG. 4 illustre un exemple de formalisme d’un message de signalisation IGMP adapté de type « Report », dans un mode de réalisation particulier de l’invention proposée ; FIG. 5 illustre un exemple de mécanisme de souscription d’une source à un service de gestion simplifiée des habilitations d’accès à des flux multicast, dans un mode de réalisation particulier de l’invention proposée ; FIG. 6 présente de manière schématique les différentes étapes d’un procédé de souscription d’un terminal récepteur à un groupe multicast associé à la diffusion d’un flux multicast au sein d’un réseau de communication, dans un mode de réalisation particulier de l’invention proposée ; FIG. 7 décrit une architecture simplifiée d’un équipement routeur pour la mise en œuvre de l’invention proposée. Description détaillée de l’invention 1. Principe général – procédé mis en œuvre côté réseau L’invention décrite ci-après permet de remédier à certains des inconvénients précités. La technique proposée permet en effet de gérer de manière simplifiée la vérification des habilitations d’un terminal, dit terminal récepteur, à accéder à des contenus multicast au sein d’un réseau de communication. À cet effet, selon le principe général de l’invention et comme détaillé par la suite, il est notamment proposé diverses adaptations des protocoles de souscription d’un terminal récepteur à un groupe multicast, comprenant notamment la mise en œuvre de mécanismes permettant la découverte et la détermination, par le réseau, de flux multicast auquel un équipement est habilité à accéder. L’invention est baptisée AMUSE (pour « Alias-based Multicast Service Enhanced », en anglais). Selon un premier aspect, la présente invention se rapporte à un procédé d’identification d’un ensemble de flux multicast auxquels un terminal récepteur est habilité à accéder, parmi une pluralité de flux multicast diffusés par un service de contenus (typiquement un service de diffusion de contenus) via un réseau de communication. Un tel ensemble peut éventuellement être vide, s’il est déterminé à l’issue du procédé que le terminal récepteur en question n’est habilité à accéder à aucun des flux multicast diffusés par le service de contenus. Le service de contenus comprend un ou plusieurs serveurs de contenus délivrant des flux multicast, et éventuellement des équipements complémentaires sollicités pour assurer d’autres fonctions associées au service de diffusion (serveur de résolution dédié, serveur d’application pour la mise en œuvre de phases de négociation avec le réseau par exemple pour souscrire à un service de gestion simplifiée des habilitations selon la présente technique, etc.), comme présenté ultérieurement. Le procédé selon la présente technique, illustré par la FIG. 1 , est mis en œuvre par un équipement de type routeur (plus simplement appelé routeur par la suite) du réseau de communication, typiquement situé à la périphérie du réseau (et qui peut être qualifié à ce titre de routeur d’accès, ou de bordure). Dans une étape 11, un tel routeur reçoit selon une procédure de réception dite RCP, en provenance d’un terminal récepteur connecté au réseau, un message de signalisation comprenant au moins une clé de résolution, également appelée alias AL dans le cadre du présent document. Comme détaillé par la suite, un tel alias AL, qui prend typiquement la forme d’une donnée textuelle, est une information utilisable par le routeur pour déterminer les flux multicast auxquels le terminal récepteur est éventuellement autorisé à accéder. Selon une caractéristique particulière, le message de signalisation reçu par le routeur fait suite à un message de demande de signalisation préalablement émis par le routeur à destination d’un ensemble de terminaux récepteurs connectés au réseau de communication et susceptibles d’être candidats à la réception de flux multicast. Dans un mode de réalisation particulier, un tel message de demande de signalisation comprend par exemple un identifiant de service de contenus (un ou plusieurs serveurs de contenus pouvant agir en tant que source de diffusion pour un même contenu) apte à diffuser des flux multicast sur le réseau de communication, sur la base duquel le terminal récepteur peut choisir l’alias à transmettre au réseau, lorsqu’un tel terminal stocke plusieurs alias (par exemple différents alias en lien avec différents services auxquels il a souscrit et fournis par les différents fournisseurs de contenus . Dans une étape 12, l’alias AL reçu par le routeur en étape 11 fait l’objet d’une procédure de résolution RES réalisée ou à tout le moins initialisée par le routeur. Plus particulièrement, cet alias est utilisé par le routeur comme clé de résolution pour obtenir le cas échéant, au sein d’une structure de données dite d’habilitation, un ensemble d’adresses de groupes multicast auquel le terminal récepteur a le droit d’accéder. En d'autres termes, une telle structure de données d’habilitation (par exemple une base de données) comprend des entrées associant des alias à une ou plusieurs adresses de groupe multicast. D’autres informations complémentaires peuvent également être associées à un alias dans la structure de données d’habilitation, telles que par exemple un identifiant de service associé à l’alias, une durée de validité de l’alias, une information représentative d’une validité courante de l’alias, etc. Si l’alias présenté par un terminal récepteur en étape 11 est présent dans la structure de données d’habilitation et est associé à des adresses de groupes multicast pour un service donné, alors le terminal récepteur est a priori habilité à accéder aux flux multicast associés à ces adresses de groupes multicast (sous réserve que d’éventuelles conditions supplémentaires d’accès aux flux multicast correspondants, par exemple un contrôle de l’absence d’utilisations multiples d’un même d’alias par des terminaux récepteurs différents comme présenté ultérieurement dans le document, soient également vérifiées). Si en revanche l’alias présenté par un terminal récepteur en étape 11 n’est pas présent pour ce service dans la structure de données d’habilitation, ou qu’il est présent mais qu’il n’est associé à aucune adresse de groupe multicast ou bien qu’il est associé à un autre service, alors le terminal récepteur n’est habilité à accéder à aucun flux multicast sur la base de l’alias présenté. La procédure de résolution de l’alias délivre à l’issue de l’étape 12 une information IH, représentative d’une habilitation ou d’une absence d’habilitation du terminal récepteur à accéder à tout ou partie des flux multicast diffusés par une source de contenus. Selon différents modes de réalisation décrits ci-après, la procédure de résolution de l’alias peut être mise en œuvre intégralement au sein du routeur, ou conjointement avec un équipement tiers. Dans un premier mode de réalisation particulier, la résolution de l’alias est effectuée localement, c’est-à-dire intégralement par le routeur qui a reçu l’alias en provenance du terminal récepteur. Dans un tel mode de réalisation, la structure de données d’habilitation (ou à tout le moins une copie d’une telle structure de données) est disponible en local, au sein même du routeur. La résolution est alors immédiate et ne requiert pas de délai de résolution supplémentaire. Dans d’autres modes de réalisation particuliers, la résolution de l’alias est mise en œuvre conjointement avec un équipement tiers, différent de l’équipement routeur qui a reçu l’alias en provenance du terminal récepteur. Dans un tel mode de réalisation, la structure de données d’habilitation n’est généralement pas disponible au sein du routeur même, aussi celui-ci sollicite-t-il un équipement tiers ayant accès à cette structure de données. À cette fin, le routeur émet à destination de l’équipement tiers, une requête de résolution comprenant l’alias obtenu en étape 11, et il reçoit en retour une information d’habilitation en provenance de l’équipement tiers, une fois que celui-ci a effectué la résolution de l’alias via une consultation de la structure de données d’habilitation. L’équipement tiers peut par exemple être un équipement de contrôle du réseau de communication (plus simplement appelé contrôleur réseau dans la suite du présent document). Dans certains modes de réalisation, notamment en lien avec un format particulier d’alias détaillé par la suite, l’équipement tiers peut également être un serveur de système de nom de domaine (ou serveurs DNS, « Domain Name System » en anglais), ou encore service de contenus, un équipement associé au service de contenus (par exemple un service de contenus associé à ce service, ou un serveur de résolution dédié et déployé pour ce service) qui fournit les flux multicast pour lesquels on souhaite vérifier les éventuelles habilitations d’un terminal récepteur. Comme détaillé par la suite, le routeur a préalablement été configuré, par exemple durant une phase de souscription au service de gestion simplifiée des habilitations, avec le mode de résolution à mettre en œuvre (résolution locale ou via un équipement tiers, et en lien avec quel équipement tiers le cas échéant). Lorsque le routeur est configuré pour solliciter un équipement tiers pour la résolution d’alias, les paramètres de configuration fournis à ce routeur comprennent les informations nécessaires permettant au routeur de contacter cet équipement tiers, éventuellement assorties d’informations permettant de procéder à une authentification mutuelle avec un tel équipement tiers. Un ou plusieurs équipements tiers peuvent être configurés au sein d’un même routeur. De plus, des équipements dédiés ou distincts par service peuvent être fournis à un routeur. Dans ce cas, le routeur sélectionne l’équipement tiers à contacter en fonction du service cible. Dans tous les cas, à l’issue de la procédure de résolution de l’alias par le routeur, qu’elle ait été mise en œuvre intégralement par le routeur ou conjointement avec un équipement tiers, le routeur obtient une information d’habilitation, qui peut être : - une information représentative d’une habilitation du terminal récepteur à accéder à au moins un flux multicast diffusé par le service de contenus via le réseau de communication, auquel cas l’information d’habilitation reçue comprend la ou les adresses de groupes multicast associées à la diffusion du ou des flux multicast que le terminal récepteur est habilité à recevoir (de telles adresses de groupes multicast sont alors qualifiées d’adresses de groupes multicast autorisées) ; - une information représentative d’une absence d’habilitation du terminal récepteur à accéder à l’un quelconque des flux multicast diffusés par le service de contenus sur le réseau de communication. Dans un mode de réalisation particulier, lorsque l’information obtenue par le routeur à l’issue de l’étape 12 est représentative d’une habilitation du terminal récepteur à accéder à au moins un flux multicast diffusé par le service de contenus via le réseau de communication, et que le routeur a donc à ce stade connaissance d’au moins une adresse de groupes multicast associée audit flux, et éventuellement, des adresses unicast des sources impliquées dans la diffusion d’un contenu demandé, de nouveaux messages de signalisation sont échangés entre le routeur (c-à-d. le réseau) et le terminal récepteur afin de permettre au terminal récepteur de rejoindre l’un de ces groupes. Un tel échange repose par exemple sur des protocoles de signalisation conçus à cette fin, éventuellement adaptés dans le contexte de la présente technique, tel que par exemple le protocole IGMP (« Internet Group Management Protocol », RFC3376) dans le contexte d’un environnement IPv4, ou le protocole MLD (« Multicast Listener Discovery », RFC3810) dans le contexte d’un environnement IPv6. On rappelle que ces protocoles de signalisation existants reposent sur des principes de fonctionnement similaires : un équipement requérant du réseau de communication, typiquement un routeur, émet à fréquence régulière des messages de type « Query » (c’est à dire de type « Requête », en français) à destination des récepteurs connectés au réseau (via une adresse multicast disponible à cet effet, par exemple l’adresse 224.0.0.1 dans le cas d’une signalisation IGMP), lesquels récepteurs peuvent former en réponse des messages de type « Report » (c’est à dire de type « Rapport », en français) pour souscrire à tel ou tel groupe listé dans le message « Query », et indiquer ainsi qu’ils souhaitent recevoir le flux multicast associé à ce groupe. Un message de type « Report » renseigne de façon explicite les informations de joignabilité du récepteur (typiquement une adresse IP) ainsi que la ou les adresse(s) de groupe multicast à laquelle le récepteur souhaite accéder. L’utilisation des messages conventionnels IGMP/MLD tels que précédemment décrits ne permet cependant pas de mettre en œuvre la présente technique, du moins pas sans adaptation, ne serait-ce que parce que des échanges de messages supplémentaires pour l’obtention et la résolution de l’alias, non prévus dans ces protocoles, sont requis. De telles opérations peuvent être effectuées au moyen de messages dédiés. Cependant, pour des besoins de simplification d’intégration dans l’écosystème existant, dans un exemple d’implémentation décrit ci-après en lien avec la FIG. 2 , il est proposé dans un mode de réalisation particulier une mise en œuvre reposant sur des ajustements et des extensions aux messages IGMP/MLD existants. Plus particulièrement, dans une étape 21, un équipement requérant du réseau de communication, typiquement un routeur R, émet à fréquence régulière des messages qui peuvent être assimilés à des messages de type « Query » à destination des récepteurs connectés au réseau (via une adresse de groupe multicast disponible à cet effet, par exemple l’adresse 224.0.0.1 dans le cas d’une signalisation IGMP). Comme un message « Query » classique, un tel message constitue un premier message de demande de signalisation. Toutefois, à la différence d’un message « Query » conventionnel, il n’identifie aucun groupe multicast, et ne comprend donc aucune adresse de groupe multicast explicite. Un exemple de premier message de demande de signalisation dans une mode de réalisation de la présente technique est illustré par la FIG. 3 . Selon une caractéristique particulière, un tel message peut éventuellement comprendre un identifiant de service. En réponse à ce premier message de demande de signalisation, un terminal récepteur TR transmet à l’équipement requérant R, dans une étape 22, un message qui peut être assimilé à un premier message de signalisation de type « Report ». Ce message renseigne de façon explicite les informations de joignabilité du terminal récepteur TR (typiquement une adresse IP). Il comprend en outre au moins un alias, éventuellement sélectionné par le terminal récepteur TR en fonction de l’identifiant de service, lorsqu’un tel identifiant est compris dans le message de demande de signalisation préalablement reçu. Un tel message de signalisation n’est bien entendu transmis que si au moins un alias est associé au terminal récepteur (et, de surcroît, le cas échéant, au service cible identifié dans le message de demande de signalisation). À réception du message de signalisation comprenant au moins un alias, l’équipement requérant R procède dans une étape 23 à la résolution de cet alias, selon les modalités déjà décrites précédemment (par exemple localement ou via un équipement tiers, en fonction de la configuration préalablement établie du routeur R). Le cas échéant, à l’issue de cette procédure de résolution de l’alias, l’équipement requérant dispose d’au moins une adresse de groupe multicast d’au moins un groupe multicast associé à l’alias obtenu en étape 22. Dans une étape 24, l’équipement requérant R émet alors à destination du terminal récepteur un deuxième message de demande de signalisation, qui peut également être comparé à un message de type « Query » classique, en ce sens qu’il contient une liste d’adresses de groupes multicast auquel le terminal récepteur peut souscrire. Toutefois, ce message se distingue d’un message « Query » classique en ce qu’il est adapté de manière à cibler un terminal récepteur particulier (le terminal récepteur qui a répondu en étape 22 au premier message de demande de signalisation), et en ce qu’il comprend uniquement les adresses des groupes multicast auxquels ce terminal récepteur est habilité à accéder, obtenues en étape 23. Ces adresses de groupes multicast sont éventuellement assorties de l’alias correspondant tel que véhiculé dans ce deuxième message de demande de signalisation. En réponse à ce deuxième message de demande de signalisation, le terminal récepteur TR transmet à l’équipement requérant R, dans une étape 25, un message qui peut être comparé à un message de type « Report » classique. Ce message comprend les adresses des groupes multicast auquel le terminal récepteur TR souhaite souscrire, parmi ceux listés dans le deuxième message de demande de signalisation. Un exemple d’un tel message de signalisation dans une mode de réalisation de la présente technique est illustré par la FIG. 4 . À noter que dans le cas d’une utilisation d’un réseau de communication mettant en œuvre des tranches réseau, un tel message peut être envoyé à l’issue d’une phase de raccordement du terminal récepteur à une tranche réseau. Par exemple, le terminal extrait un identifiant de la tranche encodée dans une adresse de groupe multicast reçue dans le deuxième message de demande de signalisation émis en étape 24 après résolution de l’alias. Plusieurs cas de figures peuvent alors se présenter. Si le raccordement à la tranche identifiée est déjà effectif, le terminal récepteur ajoute l’adresse de groupe multicast correspondante à la liste des adresses à envoyer dans le message « Report » émis en étape 25. Si le raccordement à la tranche identifiée n’est pas encore effectif, et en l’absence d’instructions contraires obtenues par le terminal récepteur, celui-ci se connecte à la tranche en question et, une fois la connexion établie, il ajoute l’adresse de groupe multicast correspondante à la liste des adresses à envoyer dans le message « Report » émis en étape 25. Le terminal récepteur est alors apte à recevoir le flux multicast acheminé le long d’un arbre de distribution ad hoc déployé dans la tranche à laquelle il s’est connecté. Dans le cas d’une impossibilité à établir une connexion à la tranche identifiée, le terminal récepteur exclut l’adresse de groupe multicast correspondante de la liste des adresses multicast à envoyer dans le message dans le message « Report » émis en étape 25. Ainsi le terminal récepteur n’a la possibilité d’avoir accès qu’aux flux multicast auxquels il est habilité à accéder, les adresses des groupes multicast auxquels il n’a pas le droit de souscrire ne lui étant jamais communiquées. On s’intéresse maintenant à un mode de réalisation de la présente technique, dans lequel l’alias présente un formalisme particulier. Plus particulièrement, dans ce mode de réalisation particulier, l’alias est construit sur un format similaire à un nom de domaine (voir par exemple RFC 1035), comprenant un ou plusieurs niveaux hiérarchisés. Il est ainsi par exemple formé d’un « label » ou d’une concaténation de plusieurs labels séparés par un même séparateur (typiquement le caractère point « . ») et ordonnés selon une structure hiérarchique prédéfinie. Un alias peut par exemple avoir un format du type « alias-petit-fils >. alias-fils >. alias-parent > » (selon un exemple à trois niveaux hiérarchiques, donné à titre purement illustratif et non limitatif). Un tel format d’alias est intéressant à plusieurs titres. En premier lieu, il permet d’utiliser de manière astucieuse des serveurs du système de nom de domaine (ou serveurs DNS, « Domain Name System » en anglais) pour procéder à la résolution des alias. En d'autres termes, on exploite la capacité de ces serveurs à retourner des adresses IP en fonction d’un nom de domaine, mais pour un usage différent de l’usage courant consistant à déterminer une adresse IP d’un serveur à contacter à partir d’un nom de domaine par exemple compris dans une URL (localisateur universel de ressource, ou « Uniform Resource Locator » en anglais). Ainsi, dans le cadre de la présente technique, ces serveurs DNS sont utilisés comme équipements tiers à contacter par un routeur pour la résolution d’alias formatés comme des noms de domaines, et retournent sur la base de ces alias les adresses de groupes multicast identifiant des flux multicast auxquels des terminaux récepteurs sont habilités à accéder. De plus, l’utilisation d’une telle structure permet aussi de présenter l’alias dans les certificats de sécurité associés à un terminal récepteur. On s’appuie ainsi sur une architecture et des mécanismes déjà existants et optimisés pour la résolution des alias, ce qui permet de simplifier la mise en œuvre de la présente technique et de réaliser des économies en termes de coûts et de temps de développement et/ou de déploiement par exemple. En deuxième lieu, la structure hiérarchisée d’un alias au format d’un nom de domaine peut être exploitée pour donner encore plus de flexibilité au mécanisme de résolution d’alias selon la présente technique. Par exemple, dans un mode de réalisation particulier, un ou plusieurs niveaux hiérarchiquement supérieurs de l’alias, formant un sous-alias dit alias parent au sein de l’alias, peuvent être utilisés pour identifier de manière unique un service de contenus. Une telle caractéristique permet par exemple à un routeur configuré pour solliciter des résolutions d’alias auprès d’un équipement tiers (par exemple un serveur exploité par un fournisseur du service de contenus, un serveur de résolution dédié d’un fournisseur du service de contenus, un serveur impliqué dans la fourniture du service de contenus) d’identifier, sur la base de l’alias parent, à quel équipement (par exemple exploité par un fournisseur de service de contenus) il doit effectivement transmettre sa requête de résolution. Ainsi, un tel routeur saura par exemple qu’il doit solliciter : - le service de contenus sc1 s’il reçoit un alias « encodage3.contenu1.sc1 » ou « contenu14.sc1 » (car l’alias parent commun à ces alias est « sc1 » ) ; - le service de contenus sc2 s’il reçoit un alias contenu1.sc2 ou sc2 (car l’alias parent commun à ces alias est « sc2 » ) ; - le service de contenus sc3 s’il reçoit un alias « contenu1.sc3 « ou « encodage2.contenu2.sc3 » ou « recepteur44.sc3 » (car l’alias parent commun à ces alias est « sc3 » ) ; - etc. Les exemples précédents sont bien entendus donnés à titre purement illustratif et non limitatif. Pour les besoins de ces échanges à des fins de résolution, le routeur peut notamment disposer et maintenir une table d’adressage mettant en correspondance des alias parents et des adresses IP permettant de contacter des serveurs de contenus associés. 2. Souscription au service On présente, en relation avec la FIG. 5 , une phase de souscription au service de gestion des habilitations d’accès à des flux multicast selon la technique proposée, mise en œuvre en amont des opérations de signalisation précédemment présentées par lesquelles un terminal récepteur manifeste son intention de rejoindre un groupe multicast. Cette phase de souscription est mise en œuvre par un équipement d’un service de contenus (dit source) SRC qui a la capacité de les diffuser selon le mode de transmission multicast via le réseau de communication. Une telle source peut par exemple être un serveur de contenus du service de contenus, un serveur de résolution associé à ce service, ou encore un équipement dédié à ce service. Dans un mode de réalisation particulier, la capacité du réseau à prendre en charge une gestion des habilitations d’accès à des flux multicast selon la présente invention est par exemple exposée par le réseau au moyen d’une interface de programmation d'application (« Application Programming Interface » en anglais, ou API) dédiée. Selon une caractéristique particulière, un protocole de négociation dynamique tel que le protocole CPNP (« Connectivity Provisioning Negotiation Protocol », RFC8921) est utilisé pour exposer une telle interface, le réseau hébergeant un serveur CPNP tandis que qu’un équipement du service de contenus (typiquement un serveur d’application) embarque un client CPNP. Cet exemple est toutefois non limitatif, et d’autres protocoles tel que par exemple le protocole RESTCONF (RFC8040) peuvent également être utilisés pour exposer cette API. Le service de contenus SRC souhaitant souscrire au service de gestion des habilitations d’accès transmet, au moyen de l’API dédiée précédemment décrite, une demande de souscription SBSC, comprenant au moins un identifiant de source, par exemple une adresse IP (éventuellement associée à un numéro de port) à laquelle le service de contenus SRC apte à diffuser des contenus multicast peut être contacté, ou encore un identifiant extrait d’un certificat présenté ce service de contenus dans une demande d’établissement d’une association de sécurité (TLS (« Transport Layer Security », en anglais), DTLS (« Datagram Transport Layer Security », en anglais), etc.). Selon une caractéristique particulière, la demande de souscription SBSC comprend également des données relatives à des alias déjà générés, ou que le service de contenus est configuré pour générer de tels alias dans le cadre de la présente technique. Ainsi, à titre d’exemple et selon une caractéristique particulière, les messages échangés avec le réseau dans le cadre d’une demande de souscription comprennent au moins un alias générique, correspondant à un alias parent tel que précédemment présenté (par exemple « sc1 ») associé au service de contenus SRC. Dans le cadre du mécanisme du souscription, il est demandé au réseau d’associer cet alias parent et/ou des noms de domaine fils de cet alias parent (typiquement, pour reprendre l’exemple précédent, tout nom de domaine au format « *.sc1 » , par ex. « contenu7.sc1 » , « encodage1.contenu3.sc1 » , « recepteur45.sc1 ») à une ou plusieurs adresses de groupe multicast utilisées par le réseau pour la diffusion d’un contenu selon le mode de transmission multicast, en fonction des habilitations souhaitées. L’alias parent permet aussi d’identifier le serveur tiers à utiliser pour la résolution de l’alias. Par exemple, lors de la résolution, le réseau de communication est en mesure d’acheminer vers le serveur autoritaire de l’alias parent toute requête de résolution concernant des alias fils. Pour ce faire, un équipement routeur n’a besoin de maintenir localement que l’identité d’un serveur associé à un alias parent, et n’a pas besoin de maintenir des entrées spécifiques par alias fils. Selon une caractéristique particulière, la demande de souscription SBSC comprend également des données relatives à un mode de résolution souhaité des alias. Un paramètre « ALIAS_RESOLUTION_MODE » peut par exemple être utilisé à cet effet. Ainsi, à titre illustratif : - si « ALIAS_RESOLUTIONS_MODE == LOCAL », alors c’est le routeur qui reçoit l’alias qui se charge lui-même de la résolution ; - si « ALIAS_RESOLUTIONS_MODE == DNS », alors le système de nom de domaine DNS est utilisé pour la résolution d’un alias ; - si « ALIAS_RESOLUTION_MODE == SC », alors toutes les requêtes de résolution d’un alias fils d’un alias parent doivent être relayées au service de contenus SRC. Dans ce dernier cas, de manière optionnelle, un paramètre « ALIAS_RESOLVER » peut également être communiqué au réseau le cas échéant, pour indiquer l’adresse ou les adresses IP d’équipements complémentaires (typiquement des serveurs de résolution) associés au service de contenus, lorsque ce dernier n’effectue pas lui-même la résolution. Pour compléter le processus de souscription au procédé de gestion des habilitations d’accès à des flux multicast, plusieurs itérations d’échanges d’informations entre le service de contenus à l’origine de la demande de ladite souscription et le réseau peuvent s’avérer nécessaires. En réponse à la demande de souscription audit procédé, une fois l’ensemble des échanges finalisés, un élément du réseau, tel qu’un contrôleur réseau, envoie au service de contenus un message ACK_SBSC confirmant la bonne souscription au procédé de gestion des habilitations d’accès à des flux multicast. 3. Diversité des alias - communication des alias au terminal récepteur On s’intéresse maintenant au processus de génération des alias, et à leur communication au terminal récepteur. Comme présenté précédemment, un alias est une clé de résolution qui peut être utilisée pour identifier, dans une structure de données dite d’habilitation, des adresses de groupes multicast auquel un dispositif qui a connaissance de l’alias – typiquement un terminal récepteur – est habilité à accéder. Dans le cadre de la présente technique, il convient de noter que les alias peuvent être associés à différentes entités, selon l’objectif visé. Par exemple, en fonction de l’utilisation souhaitée, il est possible d’avoir différents types d’alias, tels que : - des alias associés à des terminaux récepteurs : l’alias est alors par exemple utilisé pour récupérer une pluralité d’adresses de groupes multicast permettant d’accéder à un ensemble de contenus – typiquement un catalogue de contenus proposé par un fournisseur de contenus – auquel le terminal récepteur détenteur de l’alias est habilité à accéder ; - des alias associés à un ou plusieurs contenus : l’alias est alors par exemple utilisé pour récupérer une pluralité d’adresses de groupes multicast associées à un même contenu disponible dans plusieurs encodages (SD, HD, 4K, etc.) auquel le terminal récepteur détenteur de l’alias est habilité à accéder ; - des alias associés à un contenu dans un encodage particulier : l’alias est alors par exemple utilisé pour récupérer une adresse de groupe multicast associée à un contenu dans un encodage donné auquel le terminal récepteur détenteur de l’alias est habilité à accéder ; - dans le cas d’un réseau de communication mettant en œuvre des tranches réseau, des alias associés à une tranche réseau utilisée pour recevoir un contenu multicast : l’alias est alors par exemple utilisé pour récupérer une adresse de groupe multicast associée à un contenu auquel le terminal récepteur détenteur de l’alias est habilité à accéder, assortie d’une information supplémentaire (par exemple encodée dans l’adresse multicast) relative à une tranche réseau à utiliser pour recevoir le contenu en question ; - des alias associés à des classes de service utilisées dans le réseau de communication pour recevoir un contenu multicast ; - etc. En d'autres termes, les alias ne sont pas nécessairement tous associés à un même type d’information, mais ont tous en commun la capacité de permettre à un terminal récepteur en particulier d’identifier une ou plusieurs adresses de groupes multicast (c-à-d. associées à un ou plusieurs contenus multicast) auquel un terminal récepteur est habilité à accéder. Les alias peuvent être mis à disposition d’un terminal récepteur de plusieurs manières. Dans un mode de réalisation particulier, un alias est transmis par un service de contenus qui l’a généré à un terminal récepteur via une transmission chiffrée établie sur un réseau de communication. Il peut par exemple être obtenu par le terminal récepteur au moyen d’une application dédiée installée sur ce terminal récepteur, ou par une connexion à un serveur dédié par l’intermédiaire d’un navigateur ou tout autre applicatif installé sur ce terminal. Dans un autre mode de réalisation, un alias peut être affiché sur une page HTTP dédiée accessible à un utilisateur après authentification, afin d’être saisi directement par l’utilisateur dans une application dédiée du terminal récepteur. Dans d’autres modes de réalisation particuliers, un alias (notamment un alias associé à un terminal récepteur) peut avoir été stocké dans une mémoire du terminal récepteur dès la fabrication de ce terminal tel qu’un décodeur TV ou une Set-Top Box (STB), le cas échéant, ou à tout le moins avant sa commercialisation. Dans un mode de réalisation particulier, la génération des alias par un service de contenus est réalisée de sorte à garantir une unicité d’alias par récepteur susceptible d’être habilité à accéder à tout ou partie des contenus diffusés. En d'autres termes, le service de contenus génère un alias unique par récepteur. Un tel mode est avantageux en ce qu’il permet d’une part de simplifier les opérations d’autorisation d’accès à un contenu d’un service de contenus, et d’autre part de faciliter la mise en place de règles de classification de trafic en périphérie du réseau et d’éviter le partage d’un même identifiant entre plusieurs terminaux. Ainsi, la détection de doublons d’alias lors de la procédure de résolution peut être considérée comme une anomalie dans un mode de réalisation particulier de la technique proposée. L’habilitation à accéder à des flux multicast peut alors n’être par exemple délivrée qu’à un seul terminal récepteur parmi ceux qui présentent un même alias (par exemple au terminal récepteur qui présente l’alias pour la première fois). Alternativement, le service de diffusion de contenus peut par exemple être refusé à tous les terminaux récepteurs qui présente un même alias, sans distinction, et l’accès aux flux multicast est alors refusé à l’ensemble desdits terminaux. Selon une caractéristique particulière, afin de mettre en œuvre les restrictions relatives à des doublons d’alias précédemment évoquées, la procédure de résolution d’un alias comprend une étape de recherche dudit alias au sein d’une liste d’alias marqués comme ayant déjà fait l’objet d’une résolution, et, en cas de présence dudit alias dans ladite liste, la délivrance d’une information représentative d’une absence d’habilitation du terminal récepteur ayant présenté l’alias à accéder à l’un quelconque des flux multicast diffusés par le service de contenus auquel est associé l’alias. Selon le mode de réalisation implémenté, l’unicité de l’alias peut être mise en œuvre au niveau d’un service de contenus considéré (l’alias est alors unique par service, mais un même alias est susceptible d’être utilisé en lien avec plusieurs services fournisseur de contenus distincts), ou être universelle (un alias est alors supposé globalement unique, y compris dans un contexte où les terminaux récepteurs sont habilités à accéder à des contenus diffusés par des fournisseurs de contenus distincts). Il convient de noter que dans le cadre de la présente technique, les adresses de groupes multicast associées à un alias peuvent dans certains cas évoluer en fonction de divers paramètres. Par exemple, lorsque le réseau de communication met en œuvre des tranches réseau, et que les adresses de groupes multicast sont construites de manière à encoder en leur sein des tranches réseau particulières à utiliser pour l’acheminement du trafic (une adresse de groupe multicast étant alors de fait associée à une tranche réseau), il peut s’avérer intéressant dans certaines situations – par exemple en fonction de données représentatives d’un état courant du réseau de communication, reçues en provenance de divers dispositifs de contrôle déployés au sein du réseau – de modifier la ou les adresses de groupes multicast associées à un alias de manière à permettre un basculement du trafic sur une autre tranche réseau que celle associée à l’adresse ou aux adresses de groupe multicast initialement associée(s) à l’alias dans la structure de données d’habilitation. Les données représentatives d’un état courant du réseau de communication comprennent par exemple des données indiquant l’indisponibilité ou la congestion de certaines tranches, des temps de latence trop longs mesurés sur certaines tranches, des temps de transit unidirectionnel trop importants, des taux de perte de données trop élevés, etc., qui constituent autant d’indicateurs de nature à encourager une redirection du trafic multicast d’une tranche vers une autre (notamment si ces indicateurs se dégradent au fil du temps ). Ainsi, selon les résultats de la résolution d’un alias et des conditions d’acheminement de trafic au sein des différentes tranches, une redirection du trafic vers une autre tranche réseau peut être automatiquement mise en œuvre. Une telle redirection peut être réalisée à l’initiative du réseau de communication (typiquement par un contrôleur en charge de l’allocation et de la gestion des ressources du réseau, ou encore par un équipement routeur sur la base d’informations transmises par le contrôleur afin de lui permettre de sélectionner la tranche vers laquelle diriger le trafic multicast). De manière alternative, la redirection du trafic multicast peut aussi être réalisée à l’initiative du service de contenus. Dans ce cas, un serveur associé à ce service informe le réseau (par exemple via une API) d’une nouvelle adresse de groupe multicast à utiliser pour un alias donné. Un contrôleur réseau peut alors identifier les entités (équipements routeurs et terminaux récepteurs) impliqués dans la souscription au groupe multicast correspondant et dans l’acheminement du trafic multicast correspondant, et informer ces entités de la modification de l’adresse de groupe multicast. Dans ce cadre, un message de signalisation de type « Query » comprenant la nouvelle adresse de groupe est envoyé par les routeurs requérants (soit les routeurs qui embarquent la fonction d’IGMP Querier ou de MLD Querier) aux terminaux récepteurs concernés. À réception de ce message, les terminaux récepteurs en question répondent aux équipements requérants par un message de type « Report », selon les modalités précédemment décrites en relation avec la FIG. 2 , lorsqu’ils souhaitent continuer à recevoir le contenu correspondant. Il convient de noter qu’en cas de décision d’une redirection de trafic, des mécanismes complémentaires selon un protocole de routage dynamique sont également mis en œuvre, afin de permettre le raccordement du terminal récepteur à un arbre de distribution ad hoc. 4. Procédé mis en œuvre côté terminal Selon un autre aspect, l’invention se rapporte également à un procédé de souscription d’un terminal récepteur à au moins un groupe multicast associé à la diffusion d’un flux multicast au sein d’un réseau de communication mettant en œuvre des tranches réseau. Un tel procédé, illustré par la FIG. 6 dans un mode de réalisation particulier, est mis en œuvre par un terminal récepteur connecté au réseau de communication. Dans une étape 61, le terminal récepteur reçoit un premier message de demande de signalisation en provenance du réseau, typiquement d’un équipement routeur. Comme décrit précédemment en relation avec le procédé mis en œuvre côté réseau, un tel message peut par exemple prendre la forme d’un message de signalisation de type « Query » (c-à-d. de type « Requête », en français) adapté pour les besoins de la présente technique. Ce premier message de demande de signalisation comprend, dans un mode de réalisation particulier, un identifiant de service (ici, service de diffusion de contenus). À réception de ce message, et éventuellement sur la base de l’identifiant de service qui y est inclus, le terminal récepteur détermine, par exemple au sein d’une structure de données stockée dans une mémoire de ce terminal, au moins un alias destiné à être utilisé comme clé de résolution par le réseau pour déterminer si le terminal récepteur est habilité ou non à accéder à des flux multicast associés audit identifiant de service, et le cas échéant, les groupes multicast auquel le terminal récepteur est habilité à accéder. Dans une étape 62, en réponse au premier message de demande de signalisation, le terminal récepteur transmet à l’équipement routeur un premier message de signalisation, comprenant ledit alias. Comme décrit précédemment en relation avec le procédé mis en œuvre par le réseau, un tel message peut par exemple prendre la forme d’un message de signalisation de type « Report » (c-à-d. de type « Rapport », en français) adapté pour les besoins de la présente technique Dans une étape 63, le terminal récepteur reçoit un deuxième message de demande de signalisation en provenance du réseau de communication, après que ce dernier ait procédé à la résolution de l’alias. Ce deuxième message de demande de signalisation, qui peut également par exemple prendre la forme d’un message de signalisation de type « Query » (c-à-d. de type « Requête », en français) adapté pour les besoins de la présente technique, comprend au moins une adresse de groupe multicast, dite adresse multicast autorisée, identifiant au moins un groupe multicast associé à la diffusion par un service de contenus (et le cas échéant, le service de diffusion de contenus identifié par l’identifiant reçu en étape 61) d’au moins un flux multicast auquel le terminal récepteur est habilité à accéder. Dans une étape 64, en réponse au deuxième message de demande de signalisation, le terminal récepteur transmet à l’équipement routeur un deuxième message de signalisation représentatif d’une demande de souscription du terminal récepteur à au moins un groupe multicast associé à au moins une de ladite au moins une adresse de groupe multicast autorisée. 5. Dispositifs On présente finalement, en relation avec la FIG. 7 les structures simplifiées d’une entité, par exemple un équipement routeur d’un réseau de communication ou un terminal récepteur, selon au moins un mode de réalisation décrit ci-dessus. Comme illustré par la FIG. 7 , une telle entité comprend au moins une mémoire 71 comprenant une mémoire tampon, au moins une unité de traitement 72, équipée par exemple d’une machine de calcul programmable ou d’une machine de calcul dédiée, par exemple un processeur P, et pilotée par le programme d’ordinateur 73, mettant en œuvre des étapes d’au moins un procédé selon au moins un mode de réalisation de l’invention. A l’initialisation, les instructions de code du programme d’ordinateur 73 sont par exemple chargées dans une mémoire RAM avant d’être exécutées par le processeur de l’unité de traitement 72. Si l’entité est un équipement routeur du réseau de communication, le processeur de l’unité de traitement 72 met en œuvre des étapes du procédé de détermination d’un ensemble de flux multicast auxquels un terminal récepteur est habilité à accéder parmi une pluralité de flux multicast diffusés par un service de contenus via le réseau de communication, tel que décrit précédemment, selon les instructions du programme d’ordinateur 73, pour : - recevoir, en provenance dudit terminal récepteur, d’un premier message de signalisation comprenant une clé de résolution, dite alias, utilisable par ledit équipement routeur pour déterminer ledit ensemble ; - mettre en œuvre d’une procédure de résolution dudit alias, comprenant l’obtention, en fonction dudit alias, d’une information parmi : (i) une information représentative d’une habilitation dudit terminal récepteur à accéder à au moins un flux multicast de ladite pluralité de flux multicast, comprenant au moins une adresse de groupe multicast, dite adresse multicast autorisée, d’au moins un groupe multicast associé à la diffusion dudit au moins un flux multicast ; ou (ii) une information représentative d’une absence d’habilitation dudit terminal récepteur à accéder à l’un quelconque (ou à au moins un) desdits flux multicast de ladite pluralité de flux multicast. Si l’entité est un terminal récepteur souhaitant recevoir un flux multicast, le processeur de l’unité de traitement 72 met en œuvre des étapes du procédé de souscription à un groupe multicast décrit précédemment, selon les instructions du programme d’ordinateur 73, pour : - recevoir, en provenance d’un équipement routeur dudit réseau de communication, un premier message de demande de signalisation, comprenant au moins un identifiant de service de contenus ; - transmettre, à destination dudit équipement routeur, un premier message de signalisation, comprenant au moins une clé de résolution, dite alias, sélectionnée par ledit terminal récepteur en fonction dudit identifiant de service de contenus ; - recevoir, en provenance dudit équipement routeur, un deuxième message de demande de signalisation, comprenant au moins une adresse de groupe multicast, dite adresse multicast autorisée, d’au moins un groupe multicast associé à la diffusion par ledit service de contenus d’au moins un flux multicast que ledit terminal récepteur est habilité à accéder - transmettre, à destination dudit équipement routeur, un deuxième message de signalisation représentatif d’une demande de souscription dudit terminal à au moins un groupe multicast associé au moins une de ladite au moins une adresse multicast autorisée. Procédé de détermination d’un ensemble de flux multicast auxquels un terminal récepteur est habilité à accéder, parmi une pluralité de flux multicast diffusés par un service de contenus via un réseau de communication, ledit procédé étant caractérisé en ce qu'il comprend, au niveau d’un équipement routeur dudit réseau de communication : - la réception (RCP), en provenance dudit terminal récepteur, d’un premier message de signalisation comprenant une clé de résolution, dite alias (AL), utilisable par ledit équipement routeur pour déterminer ledit ensemble ; - la mise en œuvre d’une procédure de résolution (RES) dudit alias, comprenant l’obtention, en fonction dudit alias, d’une information (IH) parmi : -- une information représentative d’une habilitation dudit terminal récepteur à accéder à au moins un flux multicast de ladite pluralité de flux multicast, comprenant au moins une adresse de groupe multicast, dite adresse multicast autorisée, d’au moins un groupe multicast associé à la diffusion dudit au moins un flux multicast ; ou -- une information représentative d’une absence d’habilitation dudit terminal récepteur à accéder à l’un quelconque desdits flux multicast de ladite pluralité de flux multicast. Procédé selon la revendication 1, caractérisé en ce que ladite procédure de résolution est mise en œuvre intégralement au sein dudit équipement routeur. Procédé selon la revendication 1, caractérisé en ce que ladite procédure de résolution est mise en œuvre conjointement avec un équipement tiers, ladite obtention comprenant : - l’émission, à destination dudit équipement tiers, d’une requête de résolution dudit alias, comprenant ledit alias. - la réception, en provenance dudit équipement tiers, de ladite information représentative d’une habilitation ou d’une absence d’habilitation. Procédé selon la revendication 3, caractérisé en ce que ledit équipement tiers appartient au groupe comprenant : - un équipement de contrôle dudit réseau de communication ; - un serveur de système de nom de domaine (DNS) au sein dudit réseau de communication ; - un équipement associé audit service de contenus. Procédé selon la revendication 4, caractérisé en ce que ledit alias a le format d’un nom de domaine, comprenant un ou plusieurs niveaux hiérarchisés. Procédé selon la revendication 5, caractérisé en ce qu’un ou plusieurs niveaux hiérarchiquement supérieurs desdits niveaux hiérarchisés dudit alias, formant un sous-alias dit alias parent dudit alias, identifient de manière unique ledit service de contenus. Procédé selon la revendication 6, caractérisé en ce que ledit alias parent est utilisé pour identifier ledit service de contenus auquel transmettre une requête de résolution dudit alias, lorsque ladite procédure de résolution est configurée pour être mise en œuvre conjointement avec un équipement associé audit service de contenus. Procédé selon la revendication 1, caractérisé en ce que ladite procédure de résolution dudit alias comprend une étape de recherche dudit alias au sein d’une liste d’alias marqués comme ayant déjà fait l’objet d’une résolution, et, en cas de présence dudit alias dans ladite liste, la délivrance d’une information représentative d’une absence d’habilitation dudit terminal récepteur à accéder à l’un quelconque desdits flux multicast de ladite pluralité de flux multicast. Procédé selon la revendication 1, caractérisé en ce que ladite réception dudit message de signalisation fait suite à l’émission d’un premier message de demande de signalisation émis par ledit équipement routeur à destination d’un ensemble de terminaux récepteurs connectés audit réseau de communication. Procédé selon la revendication 9, caractérisé en ce que ledit premier message de demande de signalisation comprend au moins un identifiant dudit service de contenus. Procédé selon la revendication 10, caractérisé en ce que ladite procédure de résolution est mise en œuvre au sein d’un équipement sélectionné en fonction dudit identifiant dudit service de contenus. Procédé selon la revendication 1, caractérisé en ce qu’il comprend en outre, lorsque la procédure de résolution dudit alias délivre une information représentative d’une habilitation dudit terminal récepteur à accéder à au moins un flux multicast de ladite pluralité de flux multicast : - l’émission, à destination dudit terminal récepteur, d’un deuxième message de demande de signalisation comprenant ladite au moins une adresse multicast autorisée ; - la réception, en provenance dudit terminal récepteur, d’un deuxième message de signalisation représentatif d’une demande de souscription dudit terminal récepteur à au moins un groupe multicast associé au moins une de ladite au moins une adresse multicast autorisée. Procédé selon la revendication 12, caractérisé en ce que lesdits messages de demande de signalisation et de signalisation sont des messages respectivement de type « Query » et « Report » selon un protocole de signalisation IGMP adapté ou un protocole de signalisation MLD adapté. Procédé selon la revendication 12, caractérisé en ce que ledit réseau de communication met en œuvre des tranches réseau, et en ce que ladite réception du deuxième message de signalisation permet la mise en œuvre d’un traitement différencié en fonction d’au moins un identifiant de tranche encodé dans une adresse multicast et/ou compris dans un champ de données libre dudit deuxième message de signalisation. Procédé de souscription d’un terminal récepteur à au moins un groupe multicast associé à la diffusion d’un flux multicast au sein d’un réseau de communication, ledit procédé étant caractérisé en ce qu'il comprend, par ledit terminal récepteur : - la réception (61), en provenance d’un équipement routeur dudit réseau de communication, d’un premier message de demande de signalisation, comprenant au moins un identifiant d’un service de contenus ; - la transmission (62), à destination dudit équipement routeur, d’un premier message de signalisation, comprenant au moins une clé de résolution, dite alias, sélectionnée par ledit terminal récepteur en fonction dudit identifiant de service de contenus ; - la réception (63), en provenance dudit équipement routeur, d’un deuxième message de demande de signalisation, comprenant au moins une adresse multicast, dite adresse multicast autorisée, d’au moins un groupe multicast associé à la diffusion par ledit service de contenus d’au moins un flux multicast que ledit terminal récepteur est habilité à accéder ; - la transmission (64), à destination dudit équipement routeur, d’un deuxième message de signalisation représentatif d’une demande de souscription dudit terminal à au moins un groupe multicast associé au moins une de ladite au moins une adresse multicast autorisée. Équipement routeur pour la détermination d’un ensemble de flux multicast auxquels un terminal récepteur est habilité à accéder, parmi une pluralité de flux multicast diffusés par un service de contenus via un réseau de communication, ledit équipement routeur comprenant au moins un processeur configuré pour : - recevoir, en provenance dudit terminal récepteur, d’un premier message de signalisation comprenant une clé de résolution, dite alias, utilisable par ledit équipement routeur pour déterminer ledit ensemble ; - mettre en œuvre d’une procédure de résolution dudit alias, comprenant l’obtention, en fonction dudit alias, d’une information parmi : -- une information représentative d’une habilitation dudit terminal récepteur à accéder à au moins un flux multicast de ladite pluralité de flux multicast, comprenant au moins une adresse multicast, dite adresse multicast autorisée, d’au moins un groupe multicast associé à la diffusion dudit au moins un flux multicast ; ou -- une information représentative d’une absence d’habilitation dudit terminal récepteur à accéder à l’un quelconque desdits flux multicast de ladite pluralité de flux multicast. Terminal récepteur apte à souscrire à un à au moins un groupe multicast associé à la diffusion d’un flux multicast au sein d’un réseau de communication, ledit terminal récepteur comprenant au moins un processeur configuré pour : - recevoir, en provenance d’un équipement routeur dudit réseau de communication, un premier message de demande de signalisation, comprenant au moins un identifiant de service de contenus ; - transmettre, à destination dudit équipement routeur, un premier message de signalisation, comprenant au moins une clé de résolution, dite alias, sélectionnée par ledit terminal récepteur en fonction dudit identifiant de service de contenus ; - recevoir, en provenance dudit équipement routeur, un deuxième message de demande de signalisation, comprenant au moins une adresse de groupe multicast, dite adresse multicast autorisée, d’au moins un groupe multicast associé à la diffusion par ledit service de contenus d’au moins un flux multicast que ledit terminal récepteur est habilité à accéder - transmettre, à destination dudit équipement routeur, un deuxième message de signalisation représentatif d’une demande de souscription dudit terminal à au moins un groupe multicast associé au moins une de ladite au moins une adresse multicast autorisée. Produit programme d’ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur, caractérisé en ce qu’il comprend des instructions de code de programme pour l’exécution d'un procédé selon l'une quelconque des revendications 1 à 14, lorsqu’il est exécuté par un ordinateur.