Arbitrage de protocoles de transport

Une fois que la connexion de monodiffusion initiale fiable a été établie, le service MCS procède à l'établissement de sa propre connexion. Après l'initialisation du service MCS, l'information suivante est transmise au protocole MAP: domaine auquel la connexion est liée; version de protocole utilisée par le service MCS sur la connexion; et nombre de priorités et de niveaux de fiabilité utilisés dans le domaine (information fournie au protocole MAP lorsque les paramètres de domaine sont initialement fixés). Une fois que le protocole MAP dispose de cette information, il peut procéder à l'arbitrage des protocoles de transport.

Le nœud appelant produira une unité MAPArbitrateProtocolsRequest contenant la liste des

moins inclure le protocole monodiffusion fiable utilisé pour créer la connexion existante. La prise en charge des autres protocoles de transport est facultative. Après avoir comparé cette liste à ses propres capacités, le nœud appelé répondra par une unité MAPArbitrateProtocolsConfirm indiquant quels protocoles doivent être utilisés.

Si aucun protocole non fiable n'est sélectionné, les données non fiables sont envoyées à l'aide des protocoles fiables (dans le cas de la monodiffusion, les données non fiables sont envoyées par les mêmes connexions que les données fiables). Si le service MCS a indiqué qu'il n'y aura aucune donnée non fiable dans le domaine, il est inutile d'inclure des protocoles non fiables dans l'une ou l'autre des unités MAPPDU d'arbitrage. Si aucun protocole multidiffusion n'est sélectionné, toutes les données sont envoyées par monodiffusion (entre ces deux nœuds).

La confirmation inclura toujours exactement un protocole monodiffusion fiable. Elle comprendra facultativement un protocole monodiffusion non fiable. Dans le cas de la multidiffusion, elle comprendra tous les protocoles que les deux nœuds se sont entendus pour utiliser (il peut en exister plus d'un pour chaque niveau de fiabilité).

Pour ce qui est du protocole monodiffusion fiable, les nœuds arbitrent également le nombre de connexions de transport qui constituent la connexion MAP en question. S'il existe plus d'une connexion de transport, les données unidiffusées se répartissent entre elles selon leur priorité. Il est parfaitement correct que des connexions MAP différentes soient formées de connexions de transport en nombres différents, même à l'intérieur d'un îlot multidiffusion particulier. Les sous-paragraphes suivants donnent des détails sur le processus de création de connexions de transport additionnelles.

Les unités MAPPDU d'arbitrage contiennent aussi un identificateur de référence de domaine.

L'émetteur recourt ensuite à cette valeur pour indiquer à quel domaine une unité MAPPDU est associée, lorsque le domaine ne peut pas se déduire implicitement. Plus précisément, cette valeur est utilisée pour créer des connexions de monodiffusion fiables additionnelles et pour transmettre des données non fiables.

Un nœud quelconque peut imposer un nouvel arbitrage des protocoles de transport avec un nœud voisin, simplement par l'émission d'une unité MAPArbitrateProtocolsRequest. Afin d'éviter la perte de connexions, il est toutefois nécessaire que le protocole monodiffusion fiable sélectionné précédemment soit disponible dans le menu de protocole. Si le nouvel arbitrage entraîne la modification des protocoles monodiffusion, la transition doit s'effectuer immédiatement (des détails sur ce processus se trouvent dans un sous-paragraphe subséquent). Les modifications apportées à l'ensemble des protocoles multidiffusion n'ont aucun effet direct sur les groupes multidiffusion existants. Ces modifications se reflètent seulement dans les attributions de groupe subséquentes (des détails sur ce processus se trouvent dans le sous-paragraphe sur l'attribution et la distribution des groupes multidiffusion; voir A.8.3).

Il est possible que des nœuds adjacents subissent une "collision d'arbitrage". Cela se produit lorsque les deux nœuds émettent une unité MAPArbitrateProtocolsRequest en même temps. Cette situation peut se détecter aux deux nœuds, car ils recevront tous deux une demande d'arbitrage alors qu'ils attendaient une confirmation. Dans ce cas, il n'est pas tenu compte de la demande provenant du nœud de niveau inférieur (et le nœud inférieur arrête d'attendre une confirmation). La demande provenant du nœud de niveau supérieur est traitée normalement.

La Figure A.8-3 illustre le processus d'arbitrage lorsque le nœud 2 appelle le nœud 1.

T1600730-97

MAPArbitrateProtocolsRequest MapArbitrateProtocolsConfirm

nœud 1 nœud 2

Figure A.8-3/T.125 – Synchronisation des processus MAPPDU d'arbitrage

A.8.2.1 Création de connexions de monodiffusion fiables additionnelles

Comme il a été mentionné plus haut, les nœuds arbitrent aussi le nombre de connexions de monodiffusion fiables qui constitueront une connexion MAP particulière. S'ils décident d'en utiliser plus d'une, il est alors nécessaire de créer les connexions additionnelles. Le présent sous-paragraphe utilise le terme connexion pour désigner une connexion de monodiffusion fiable.

Ce processus est lancé par le nœud appelant, qui appelle le protocole monodiffusion fiable sélectionné afin de créer le nombre approprié de connexions additionnelles. A mesure que les connexions deviennent prêtes à utiliser, le nœud appelant transmet sur chacune une unité MAPConnectRequest. Cette unité MAPPDU contient les champs suivants:

• le numéro de version du protocole est le même que celui déjà sélectionné pour la connexion initiale;

• le point MAPSAP est le même que celui utilisé pour créer la connexion initiale;

• l'identificateur de référence de domaine est celui qui était envoyé dans l'unité MAPArbitrateProtocolsRequest sur la connexion initiale;

• les valeurs de priorités faible et élevée indiqueront la gamme de priorités qui sera envoyée sur cette connexion (les priorités requises, spécifiées par le service MCS, sont typiquement réparties uniformément entre les connexions disponibles).

Le nœud appelé doit accepter chacune des connexions additionnelles en émettant une unité MAPConnectConfirm sur chacune. Cette unité MAPPDU contiendra une copie exacte des deux premiers champs de la demande ci-dessus.

Le refus d'une des connexions additionnelles représente une erreur de protocole. Si l'un des deux nœuds ne peut pas créer le nombre de connexions adopté, toutes les connexions correspondant à la connexion MAP en question doivent être coupées, ce qui coupe le nœud inférieur du domaine.

Il est important que toutes les priorités requises mappent une connexion une fois ce processus terminé. A mesure que chaque connexion additionnelle est mise en service, elle est mappée avec une gamme de priorités. Toutes les priorités requises qui ne sont pas explicitement mappées avec une connexion additionnelle sont traitées par la connexion initiale. Les priorités qui demeurent doivent être contiguës à la priorité zéro (qui est déjà mappée avec la connexion initiale).

A.8.2.2 Changement de connexions de monodiffusion fiables

Après un nouvel arbitrage de protocoles, il peut être nécessaire que deux nœuds passent dynamiquement à un ensemble différent de connexions de monodiffusion fiables. Cela se produit dans l'une ou l'autre des conditions suivantes: les nœuds ont choisi de passer à un protocole monodiffusion fiable différent; les nœuds ont choisi d'utiliser un nombre différent de connexions de transport; les nœuds ont choisi de changer la taille maximale de l'information utile des connexions de monodiffusion fiable (ce qui ne peut pas s'effectuer lorsque des groupes multidiffusion sont encore actifs); ou les nœuds ont échangé de nouvelles données de configuration applicables au protocole

monodiffusion fiable. A noter qu’une transition dynamique ne peut pas se produire tant que la configuration de l'ensemble précédent de connexions de monodiffusion fiable n'est pas terminée.

Afin de passer dynamiquement à un ensemble différent de connexions, il est nécessaire d'exécuter les étapes suivantes:

1) l'initiateur de l'arbitrage doit créer le nombre adopté de nouvelles connexions au nœud éloigné en utilisant le protocole sélectionné. Ce nœud est alors appelé "nœud appelant";

2) le nœud appelant émettra une unité MAPConnectRequest sur chaque nouvelle connexion, à mesure qu'elle devient prête. Cette unité MAPPDU contient les champs suivants:

• le numéro de version du protocole est le même que celui déjà sélectionné pour les connexions précédentes;

• le point MAPSAP est le même que celui utilisé pour créer les connexions précédentes;

• l'identificateur de référence de domaine est celui qui était envoyé dans l'unité MAPArbitrateProtocolsRequest sur la connexion initiale précédente;

• les valeurs de priorités faible et élevée indiqueront la gamme de priorités qui sera envoyée sur cette connexion (les priorités requises, spécifiées par le service MCS, sont typiquement réparties uniformément entre les connexions disponibles);

3) le nœud appelé répondra en envoyant une unité MAPConnectConfirm sur chaque nouvelle connexion une fois que la demande aura été reçue. Le numéro de version du protocole et le point MAPSAP sont les mêmes que dans la demande;

4) à la réception de chaque confirmation, le nœud appelant suit les nouvelles connexions qui sont prêtes à utiliser. En comparant la gamme de priorités des connexions précédentes avec la gamme de priorités des nouvelles connexions confirmées, le nœud appelant peut déterminer à quel moment une connexion précédente peut être coupée (étant donné que toutes ses priorités sont couvertes par les nouvelles connexions). Lorsque cela se produit, le nœud appelant envoie une unité MAPDisconnectRequest à la connexion précédente. A ce moment, le nœud appelant commence à envoyer tout le trafic de monodiffusion fiable dans la gamme de priorités de la connexion précédente sur les nouvelles connexions appropriées;

5) dès la réception d'une demande de déconnexion, le nœud appelé envoie une unité MAPDisconnectConfirm sur la connexion précédente. Le nœud appelé commence alors à envoyer du trafic de monodiffusion fiable dans la gamme de priorités de la connexion précédente sur les nouvelles connexions appropriées. Le nœud appelé doit également assurer le suivi des connexions précédentes qui ont été coupées. En comparant la gamme de priorités des nouvelles connexions avec la gamme de priorités des connexions précédentes, le nœud appelé peut déterminer à quel moment le traitement des données reçues d'une nouvelle connexion peut commencer sans problème (cela se produit lorsque toutes les connexions précédentes qui acheminaient des données dans la gamme de priorités de la nouvelle connexion ont été coupées);

6) lorsque le nœud appelant reçoit une confirmation de déconnexion, on peut supposer que toutes les données en instance de la connexion précédente ont été vidées et que la connexion peut être coupée. En comparant la gamme de priorités des nouvelles connexions avec la gamme de priorités des connexions précédentes, le nœud appelant peut déterminer à quel moment le traitement des données reçues d'une nouvelle connexion peut commencer sans problème (cela se produit lorsque toutes les connexions précédentes qui acheminaient des données dans la gamme de priorités de la nouvelle connexion ont été coupées).