Catégorie : Information

Spécification du protocole d’accès à un hôte (HAP) - Version 2

Statut du présent mémoire

Le présent mémoire décrit le protocole d’accès à un hôte mis en œuvre dans le réseau terrestre à haut débit (TWBNET, Terrestrial Wideband Network). Il rend obsolète la plus grande partie de la RFC 907, mais pas toute. Le présent mémoire donne des informations pour la communauté de l’Internet. Il ne spécifie pas une norme de l’Internet. La distribution du présent mémoire n’est soumise à aucune restriction.

Préface

Le présent mémoire spécifie le protocole d’accès à un hôte (HAP, Host Access Protocol). HAP est un protocole d’accès de couche réseau (couche 3 inférieure de l’OSI) qui a d’abord été mis en œuvre il y a une dizaine d’années pour le réseau de paquets haut débit par satellite (WBNET, Wideband Packet Satellite Network) financé par le DARPA/DCA, le précurseur du réseau terrestre haut débit (TWBNET, Terrestrial Wideband Network). La présente version de la spécification rend obsolètes les références [1] et [2] en plus de la plus grande partie de la RFC 907.

HAP est un protocole en développement, qui sera révisé lorsque de nouvelles capacités seront ajoutées et que les dispositifs non utilisés seront éliminés ou révisés. Une des raisons de la révision actuelle de HAP est que, à la différence du canal satellite du WBNET d’origine, les liaisons de fibre optique T1 de TWBNET ne sont pas un support de diffusion. Cela a rendu urgentes certaines modifications au protocole pour permettre une plus grande efficacité dans un réseau à topologie mêlée. Une autre cause de révision est le besoin de rendre HAP capable de prendre en charge divers protocole de la couche 3 supérieure de l’OSI, comme le DECNET Phase V, ST, et CLNP, sur lesquels seul le protocole Internet (IP) était utilisé auparavant. L’appendice B décrit comment est réalisée la rétro-compatibilité avec l’ancienne version de HAP qui ne prend en charge que IP. Une troisième cause du changement du protocole est le désir de simplifier l’interaction entre les agents de protocole ST2 (RFC 1190) et le TWBNET. Cela a principalement affecté la façon certains erreurs d’établissement sont traitées. Il est prévu que ces changements soient rétro-compatibles. L’Appendice A décrit les deux capacités qui pourraient être ajoutées à l’avenir à HAP.

Une des améliorations du protocole, les "flux de groupes", décrite dans la référence [2] a été éliminée. Il n’y a pas d’applications connues qui utilisent le dispositif. Comme décrit à l’Appendice A, un nouveau mécanisme, appelé "flux partagés", capable de fournir des capacités équivalentes, sera mis en œuvre en cas de besoin. Les changements à [2] qui ont été retenus incluent divers messages de commande d’interrogation/réponse qui permettent à un hôte de déterminer de quelles ressources il dispose (surtout utile pour le nettoyage après un réamorçage ou une défaillance de l’hôte).

Le présent document suppose que le lecteur est familier de la terminologie d’inter réseautage du DoD.

Table des matières

1 Introduction
2 Généralités
3 Messages de datagramme
4 Messages de flux
5 Messages de contrôle de flux
6 L’agent de service
6.1 Messages d’établissement de flux
6.2 Messages d’établissement de groupe
6.3 Notifications
6.4 Accusés de réception d’établissement
6.5 Messages de demande/réponse d’information
7. Surveillance de la liaison d’accès de l’hôte
8. Initialisation
9. Contrôle de bouclage
10. Autres messages de commande
11. Appendice A – Extensions futures
12. Appendice B -- Rétro compatibilité
13. Appendice C – Numéros alloués aux identifiants de protocole HAP
Références

1 Introduction

Le protocole d’accès à un hôte (HAP) est un protocole de couche réseau (comme X.25). ("Couche réseau" signifie ici la couche 3 inférieure de l’ISO, la couche de protocole en dessous de la couche de protocole Internet (IP) du DoD [3] et au-dessus de tout protocole de couche de liaison.) HAP définit les différents types de messages de commande d’hôte à réseau et de messages de commande d’hôte à hôte qui peuvent être échangés sur la liaison d’accès connectant un hôte et le nœud du réseau de commutation de paquets. Le protocole établit les formats de ces messages, et décrit les procédures pour déterminer quand chaque type de message devrait être transmis et ce que signifie sa réception.

HAP a été mis en œuvre dans le réseau étendu appelé réseau terrestre haut débit (TWBNET, Terrestrial Wideband Network) [5] et dans les routeurs et autres hôtes qui se connectent au TWBNET. Les nœuds de commutation de paquets qui composent le TWBNET sont appelés commutateurs de paquets haut débit WPS, Wideband Packet Switches).

Les deux précurseurs de HAP, le protocole d’hôte/SATNET [6], utilisé dans le réseau atlantique de paquets par satellites (SATNET) et dans le réseau de terminaux d’accès mobiles (MATNET, Mobile Access Terminal Network [7]), et HAP, utilisé dans le réseau haut débit par satellite (WBNET, Wideband Satellite Network ) [8] original, était au départ conçus pour fournir un accès efficace au seul canal satellite que chaque réseau utilisait pour connecter tous les sites. Les concepteurs du protocole HAP ont reflété quelques unes des particularités de l’environnement de canal satellite unique dans le protocole HAP lui-même. Le réseau terrestre haut débit (TWBNET) actuel utilises des connexions en fibre optique de débit T1 entre les sites. les réseaux futurs et TWBNET peuvent utiliser une combinaison de connexions terrestres et de connexions par satellite, et peuvent en utiliser plus d’une. Le protocole HAP a été modifié pour s’accommoder de ces extensions.

La section 2 présente une vue générale de HAP. Les détails des formats et des procédures d’échange des messages HAP figurent dans les sections 3 à 10. Des explications complémentaires sur certains des sujets traités dans cette spécification HAP se trouvent dans la référence [1].

Tout protocole utilisé pour fournir des échanges de messages suffisamment fiables sur la liaison hôte-WPS est supposé transparent au protocole défini dans le présent document. Des exemples de tels protocoles de niveau liaison sont les protocoles ARPANET 1822 d’hôte local et distant [9], le protocole VDH ARPANET [9], et HDLC.

2 Généralités

HAP peut être caractérisé comme un protocole bilatéral, non fiable, avec un mécanisme facultatif de contrôle des flux. Les messages HAP s’écoulent simultanément dans les deux directions entre le WPS et l’hôte. La transmission est non fiable en ce sens que le protocole ne fournit aucune garantie de livraison en séquence sans erreur. Si la livraison sans erreur sur la liaison d’accès de l’hôte est exigée, elle doit être fournie par le protocole de couche liaison au dessous de HAP. (L’utilisation de protocoles de couche liaison à cette fin sort du domaine d’application du présent document.) Le mécanisme de commande des flux de HAP fonctionne de façon indépendante dans chaque direction, mais le choix d’activer le contrôle des flux o pas s’applique aux deux directions à la fois.

HAP prend en charge la communication d’hôte à hôte dans deux modes correspondant aux deux types de messages de données de HAP, les messages de datagrammes et les messages de flux. Chaque type de message peut avoir jusqu’à 2048 octets. Le service de transmission de base dans le réseau est le service de datagrammes. Les datagrammes sont de longueur variable, sans séquence, indépendants, et la livraison n’est pas garantie. L’en-tête HAP de chaque datagramme détermine le traitement du message.

Sur la base de ce service de datagramme est construit un service de "flux". Le service de flux fournit des garanties de bande passante réseau, mais exige des opérations explicites d’établissement et de retrait pour allouer et retirer les ressources du réseau. Le trafic de flux est le mieux adapté au trafic sur support continu, mais peut aussi être utilisé pour obtenir le délai réseau le plus court possible. Les flux d’hôtes sont établis par un échange de message d’établissement entre l’hôte et le réseau avant le commencement du flux de données. Bien que les flux d’hôte établis puissent voir leurs caractéristiques modifiées par des messages d’établissement ultérieurs alors qu’ils sont en cours d’utilisation, les propriétés fixes d’allocation des flux par rapport aux datagrammes imposent des exigences assez strictes sur la source du trafic qui utilise le flux. Les arrivées de trafic de flux doivent correspondre aux allocations de flux à la fois en temps inter-arrivées et en taille de message si on veut obtenir une efficacité raisonnable. Les caractéristiques et l’utilisation des datagrammes et des flux sont décrites en détail aux Sections 3 et 4 du présent document.

Dans le réseau, aussi bien les transmissions de datagrammes et de flux utilisent l’adressage logique. Chaque hôte du réseau se voit allouer une adresse logique permanente de 16 bits qui est indépendante de l’accès physique sur le WPS auquel il est rattaché. Ces adresses logiques de16 bits sont présentes dans tous les messages de données d’hôte à WPS et de WPS à hôte.

HAP prend en charge l’adressage en diffusion groupée des "groupes". L’adressage en diffusion groupée est fourni principalement pour prendre en charge la livraison multi-destination exigée pour les applications de conférences. Les adresses de groupes sont créées et supprimées de façon dynamique par l’utilisation de messages d’établissement échangés entre un hôte et le WPS. L’ensemble des membres d’un groupe peut être tout sous-ensemble arbitraire des hôtes du réseau. Un message adressé à une adresse de groupe est délivrée à tous les hôtes qui sont membres de ce groupe, à l’exception de l’envoyeur. Une fois qu’une adresse de diffusion groupée a été créée, tout hôte membre peut utiliser cette adresse, et pas seulement le créateur.

Bien que HAP ne garantisse pas la livraison sans erreur, le contrôle d’erreur est un aspect important de la conception du protocole. Le contrôle d’erreur de HAP est concerné à la fois par les transferts locaux entre un hôte et son WPS local et par les transferts à travers le réseau vers la ou les destinations. Le WPS offre aux utilisateurs un choix d’options de protection contre les erreurs du réseau fondé sur la capacité du réseau à envoyer de messages de façon sélective sur son support de transmission à différents taux de correction d’erreurs directe (FEC, forward error correction). Ces options de FEC sont appelés des niveaux de fiabilité. Quatre niveaux de fiabilité (faible, moyen-faible, moyen-fort, et fort) sont disponibles. Le taux d’erreur précis fourni par chaque niveau de fiabilité n’est pas spécifié.

Divers mécanismes de somme de contrôle et de CRC sont utilisés dans le réseau pour fournir une capacité de détection d’erreurs. Un hôte a une opportunité, lorsqu’il envoie un message, d’indiquer si le message devrait être délivré à sa destination ou éliminé si une erreur de données est détectée par le réseau. Chaque message reçu du réseau par un hôte a un fanion qui indique si une erreur a été détectée ou non dans ce message particulier. Un hôte peut décider message par message si il veut ou non accepter ou éliminer les transmissions qui contiennent des erreurs de données.

Pour la connexion d’un hôte et du WPS à proximité, les taux d’erreur dus au bruit externe ou à des défaillances matérielles sur le circuit d’accès peuvent être raisonnablement espérées bien inférieures aux taux d’erreur des meilleurs circuits de réseaux interurbains. Et donc dans ce cas, il y a peu à gagner à utiliser la détection d’erreurs et la retransmission sur le circuit d’accès. Il est cependant fourni une somme de contrôle d’en-tête de 16 bits pour s’assurer que les WPS n’agissent pas sur des informations de commande incorrectes. Pour des distances relativement longues ou des connexions bruyantes, les retransmissions peuvent être nécessaires sur le circuit d’accès pour optimiser les performances aussi bien pour le trafic à faible qu’à haute fiabilité. Il est prévu que les procédures de contrôle d’erreur de la couche de liaison (comme HDLC avec retransmission) soient utilisées à cette fin, mais l’utilisation d’un protocole de couche de liaison fiable est en dehors du domaine d’application du présent document.

Chaque message de datagramme soumis au WPS par un hôte est marqué comme étant dans une des trois classes de priorité, de la priorité 2 (la plus élevée) à la priorité 0 (la plus basse). La classe de priorité est utilisée par le WPS pour arbitrer les conflits lorsque les ressources réseau sont rares (par exemple, la bande passante de la liaison). C’est à dire que si le réseau ne peut pas livrer tous les messages offerts, les messages de priorité élevée seront livrés de préférence aux messages de priorité faible. Les niveaux de priorité affectent l’ordre d’accès à la bande passante inter-site et l’ordre de livraison des messages au WPS de destination.

Chaque message de flux a aussi trois classes de priorité, de la priorité 2 (la plus élevée) à la priorité 0 (la plus faible). De plus, les flux eux-mêmes ont trois classes de préséance, de la préséance 2 (la plus élevée) à la préséance 0. Un flux de préséance plus élevée peut préempter un flux de préséance inférieure au moment de l’établissement. La priorité de message de flux fournit un mécanisme pour qu’un hôte à faible bande passante reçoive un flux de forte bande passante et élimine de façon sélective les messages marqués comme moins importants par l’envoyeur. La priorité de message de flux n’affecte pas l’ordre de livraison des messages de flux entre la source et la destination.

Les messages de datagramme et de flux qui sont présentés au WPS par un hôte peuvent n’être pas acceptés pour un certain nombre de raisons : une priorité trop faible, une destination morte, l’absence de mémoires tampon dans le WPS de source, etc. L’hôte rencontre une situation similaire pour ce qui concerne le traitement des messages provenant du WPS. Pour permettre ai receveur d’un message d’informer l’envoyeur de la disposition locale de son message est mis en œuvre un mécanisme d’acceptation/refus (A/R). Le mécanisme est la manifestation externe de l’algorithme de contrôle des flux internes et d’encombrement du WPS (ou de l’hôte). Si les A/R sont activés, une acceptation ou un refus explicite ou implicite de chaque message est retourné à l’hôte par le WPS (et réciproquement). Cela permet à l’hôte (ou au WPS) de réessayer à sa discrétion les messages refusés et peut fournir des informations utiles pour optimiser l’envoi des messages ultérieurs lorsque la raison des refus est aussi fournie. Le mécanisme A/R peut être désactivé pour fournir une interface de "pure élimination". Le choix de l’hôte d’utiliser ou non le mécanisme d’A/R ne limite pas sa capacité à envoyer et recevoir des messages à tous les autres hôtes.

Bien que le mécanisme A/R permette le contrôle des transferts de messages individuels, il ne facilite pas la régulation des flux de priorité. Une telle régulation est traitée en passant des informations d’état facultatives (GOPRI) à travers l’interface hôte-WPS qui indiquent quelles priorités sont actuellement acceptées. Aussi longtemps que ces informations, relatives aux changements d’états de priorité, sont passées fréquemment, l’envoyeur peut éviter de générer des messages qui sont sûrs d’être refusés.

HAP définit à la fois des messages de données (messages de datagrammes et messages de flux) et des messages de commande de liaison. Les messages de données sont utilisés pour envoyer des informations entre les hôtes sur le réseau. Les messages de commande de liaison sont échangés entre un hôte et le WPS pour gérer la liaison d’accès local.

L’allocation des ressources du réseau, telles que les flux et les groupes, est accomplie via un échange de messages de datagrammes, appelés Établissement (Setup), entre l’hôte utilisateur et un agent au sein de WPS appelé "Agent de service." Les Setup sont utilisés pour réserver, allouer, modifier, libérer, et désallouer des ressources réseau. Chaque ressource allouée a un identifiant unique qui, lorsqu’il est placé dans un champ approprié d’un en-tête de message, permet que ce message utilise la ressource. Par exemple, après un échange de Setup pour créer une adresse de groupe, un message peut être envoyé au groupe en plaçant l’adresse du groupe dans le champ destination de ce message. L’agent de service permet aussi à un hôte de s’enquérir des ressources qu’il possède.

Chaque message HAP consiste en un nombre entier de mots de 16 bits (c’est-à-dire un nombre pair d’octets). Le premier des mots du message contient toujours des informations de contrôle et est appelé l’en-tête de message. Le premier mot de l’en-tête de message identifie le type du message qui suit. Le second mot de l’en-tête de message est une somme de contrôle qui couvre toutes les informations d’en-tête. Tout message qui reçoit une somme de contrôle d’en-tête qui ne correspond pas à la somme de contrôle calculée sur les informations d’en-tête reçues doit être éliminé. Le format du reste de l’en-tête dépend du type de message spécifique.

Les formats et l’utilisation des types de message individuel sont détaillés dans les sections suivantes. Une description de format commun est utilisée à cette fin. Les mots d’un message sont numérotés en partant de zéro (c’est-à-dire que zéro est le premier mot d’un en-tête de message). Les bits au sein d’un mot sont numérotés à partir de zéro (celui de plus fort poids) à quinze (celui de moindre poids). la notation utilisée pour identifier une localisation de champ particulière est :

<MOTn°>{-<MOTn°>} [ <BITn°>{-<BITn°>} ] <description>

où les éléments facultatifs entre {} sont utilisés pour spécifier la limite supérieure (incluse) d’une gamme. Le lecteur devrait se référer à ces identifiants de champs pou connaître les spécifications précises de la taille des champs. Les champs qui sont communs à plusieurs types de message sont définis dans la première section qui les utilise. Seul le nom du champ apparaîtra normalement dans les descriptions des sections ultérieures.

Les protocoles de niveau liaison utilisés pour la prise en charge de HAP peuvent différer selon l’ordre dans lequel ils transmettent les bits qui constituent les messages HAP. Les mots du message sont transmis du mot 0 au mot N.

3 Messages de datagramme

Les datagrammes sont un des deux types de message fournis par HAP, comme décrit dans la précédente section. Parce que les ressources réseau ne sont pas réservée s à l’avance pour le trafic de datagrammes, la livraison du trafic de datagrammes est soumise à de plus longs délais de livraison et à une plus grande variance des délais que le trafic de flux, et est soumis aux contrôles de flux et d’encombrement.

La priorité des datagrammes détermine quels paquets sont délivrés ou éliminés lorsque les ressources réseau ne permettent pas le traitement de tous le trafic présenté. Il est prévu que les messages de datagrammes soient utilisés pour prendre en charge la majorité du trafic d’ordinateur à ordinateur et de terminal à ordinateur qui est par nature en salves.

Le format des messages de datagrammes et l’objet de chaque champ de commande d’en-tête est décrit à la Figure 1.

Figure 1 ; Message de datagramme

0[0] Classe de message . Ce bit identifie le message comme message de données ou message de contrôle.

0 = Message de données
1 = Message de contrôle

0[1] Indicateur de bouclage. Ce bit permet à l’envoyeur d’un message de déterminer si ses propres messages sont en boucle. L’hôte et le WPS utilisent chacun des réglages différents de ce bit pour leurs transmissions. Si un message arrive avec le bit de bouclage égal à sa valeur de sortie, le message est alors en boucle.

0 = Envoyé par l’hôte
1 = Envoyé par WPS

0[2-3] Priorité. Dans les messages de WPS à hôte, ce champ donne des informations concernant la plus faible priorité actuellement acceptée par le WPS. L’hôte peut facultativement choisir de fournir des informations de priorité similaires au WPS.

0 = Priorité faible
1 = Priorité moyenne
2 = Priorité élevée
3 = (Réservé.)

0[4-6] Réservé. Doit être à zéro.

0[7] Réservé. Doit être à zéro. Anciennement utilisé pour les besoins de diagnostic de WPS.

0[8-15] Numéro de message. Ce champ contient l’identification du message utilisé par le mécanisme d’acceptation/refus (A/R) (lorsqu’il est activé). Si le numéro de message est zéro, A/R est désactivé pour ce message spécifique. Voir à la Section 5 une description détaillée du mécanisme A/R.

1[0-15] Somme de contrôle d’en-tête. La somme de contrôle est le complément à 2 de la somme des compléments à deux des mots 0 à 6 (à l’exclusion du mot de somme de contrôle lui-même).

2[0-15] A/R porté. Ce champ peut contenir un mot d’acceptation/refus fournissant un état d’A/R sur le trafic qui s’écoule dans la direction opposée. Son inclusion peut éliminer le besoin d’un message de contrôle d’A/R séparé (voir la Section 5). Une valeur de zéro pour ce mot est utilisée pour indiquer qu’aucune information d’A/R porté n’est présente.

3[0] Type de message de données. Ce bit identifie si le message est un message de datagramme ou un message de flux.

0 = Message de datagramme
1 = Message de flux

3[1] Fanion IL. Obsolète. Doit être à zéro. (Voir l’appendice B.)

3[2] Fanion éliminer. Ce fanion permet à un hôte de source de donner des instructions au réseau (y compris l’hôte de destination) sur que faire du message quand des erreurs de données sont détectées (en supposant que la somme de contrôle d’en-tête est correcte).

0 = Éliminer le message si des erreurs de données sont détectées.
1 = Ne pas éliminer le message si des erreurs de données sont détectées.

La valeur de ce fanion, réglée par l’hôte de source, est passée à l’hôte de destination.

3[3] Fanion d’erreurs de données. Ce fanion est utilisé en conjonction avec le fanion éliminer pour indiquer à l’hôte de destination si des erreurs de données ont été détectées dans le message avant la transmission sur la liaison d’accès WPS à hôte de la destination. Il n’est utilisé que si le fanion élimination = 1. Il devrait être réglé à zéro par l’hôte de source.

0 = Pas d’erreur de données détectée
1 = Des erreurs de données sont détectées

3[4-5] Priorité. L’hôte de source utilise ce champ pour spécifier la priorité avec laquelle le message devrait être traité au sein du réseau.

0 = Priorité faible
1 = Priorité moyenne
2 = Priorité haute
3 = (Réservé.)

La priorité de chaque message est passée à l’hôte de destination par le WPS de destination.

3[6-7] Désignateur de durée de vie. L’hôte de source utilise ce champ pour spécifier la durée maximum pendant laquelle l’existence d’un message devrait être admise au sein du réseau avant d’être supprimé. Le temps écoulé commence lorsque le message a été reçu par le WPS de l’hôte de source (ou est envoyé par un agent du WPS) est il est vérifié pour la dernière fois lorsque le message est mis en file d’attente pour sa transmission sur l’interface entrée/sortie vers l’hôte de destination. Si un message est en diffusion groupée, chaque copie est traitée séparément.

0 = 1 seconde
1 = 2 secondes
2 = 5 secondes
3 = 10 secondes

3[8-9] Fiabilité. L’hôte de source utilise ce champ pour spécifier les exigences de base de taux d’erreurs binaires pour la portion données de ce message. Le WPS de source utilise ce champ pour déterminer les paramètres de transmission du circuit de jonction et de niveau de correction d’erreur directe requis pour fournir ce taux d’erreurs binaires.

0 = Fiabilité basse
1 = Fiabilité moyenne basse
2 = Fiabilité moyenne haute
3 = Haute fiabilité

3[10-15] Longueur de fiabilité. L’hôte de source utilise ce champ pour spécifier une portion de données d’utilisateur qui devrait être transmise au plus haut niveau de fiabilité (le plus faible taux d’erreurs binaires). Les mots de l’en-tête du message HAP et les premiers octets 2*<Longueur de fiabilité> des données d’utilisateur seront tous deux transmis à la plus haute fiabilité alors que le reste des données d’utilisateur sera transmis au niveau de fiabilité qui est spécifié dans le champ 3[8- 9] Le mécanisme Longueur de fiabilité donne à l’usager la capacité de transmettre des informations d’en-tête privées (par exemple, des en-têtes IP et TCP) à un niveau de fiabilité plus élevé que le reste des données.

4[0-15] Adresse de l’hôte de destination. Ce champ contient l’adresse réseau logique de l’hôte de destination.

5[0-15] Adresse de l’hôte de source. Ce champ contient l’adresse réseau logique de l’hôte de source.

6[0-15] Identifiant de protocole. Ce champ spécifie le protocole du prochain niveau supérieur. Les identifiants de protocole sont alloués administrativement, excepté 0 qui est réservé, et ne font pas partie de la présente spécification. Voir la référence [10].

7-N Données. Ce champ contient jusqu’à 16 384 bits (2 048 octets) de données d’utilisateur, et doit être un nombre pair d’octets.

4 Messages de flux

Les messages de flux sont le second type de message fournis par HAP, comme décrit à la Section 2. Les flux fournissent une bande passante garantie entre la source et la ou les destinations, et fournissent le délai de livraison et la variance de délai minimum disponibles dans le réseau. Les flux conviennent pour le trafic volatile, tels que la parole, et pour la prise en charge d’applications à facteur d’utilisation élevé qui exigent des garanties de débit.

Les flux doivent être créé s avant que les messages de flux puissent s’écouler d’hôte à hôte. Le protocole pour accomplir la création des flux est décrit au paragraphe 6.1. Une fois établi, un flux se voit attribuer des ressources réseau spécifiques, telles que la bande passante. Au sein des limites de son allocation de flux, un hôte a une souplesse considérable dans la façon d’utiliser le flux. Bien que la durée de vie, la fiabilité et la longueur de fiabilité de chaque message de flux soir fixée au moment de l’établissement du flux, l’adresse logique de destination peut varier d’un message de flux à l’autre.

Un hôte peut donc multiplexer divers flux logiques en un seul flux, tant que le flux a été établi pour atteindre tous les hôtes de destination. Le format des messages de flux est décrit à la Figure 2.

Figure 2 : Message de flux

0[0] Classe de message = 0 (Message de données).

0[1] Indicateur de bouclage.

0[2-3] Priorité.

0[4-7] Réservé.

0[8-15] Numéro de message. Ce champ sert au même objet que le champ numéro de message dans le message de datagramme. De plus, une seule séquence de numéro de message est utilisée à la fois pour les messages de datagrammes et de flux (voir la Section 5).

1[0-15] Somme de contrôle d’en-tête. (Voir la description sous le message de datagramme.)

2[0-15] A/R porté.

3[0] Type de message de données = 1 (flux).

3[1] Fanion IL. Obsolète. Doit être à zéro.

3[2] Fanion éliminer.

3[3] Fanion d’erreur de données.

3[4-5] Priorité de message de flux. Noter que tous les messages de flux ont priorité sur tout message de datagramme. La priorité n’affectera pas l’ordre de livraison des messages de flux.

0 = Priorité faible
1 = Priorité moyenne
2 = Priorité élevée
3 = Réservé

3[6-15] Identifiant de flux. Le WPS utilise ce champ pour identifier les ressources réseau préallouées (allocations de bande passante, file d’attentes, mémoires tampon, etc.) à utiliser pour la livraison du message. Les flux et leurs numéros d’identification (identifiants de flux) sont établis par une demande Create Stream explicite (voir le paragraphe 6.1).

4[0-15] Adresse d’hôte de destination.

5[0-15] Adresse d’hôte de source.

6[0-15] Identifiant de protocole.

7-N Données. Ce champ contient jusqu’à 16 384 bits (2 048 octets) de données d’utilisateur, et doit être un nombre pair d’octets.

5 Messages de contrôle de flux

Le WPS prend en charge un mécanisme d’acceptation/refus (A/R) dans chaque direction sur la liaison d’accès de l’hôte. Le mécanisme A/R est activé pour la liaison lorsque l’hôte établit un bit dans le message de contrôle Restart Complete (redémarrage achevé) (voir à la Section 8). Chaque message de datagramme et de flux contient un numéro de message à 8 bits utilisé pour identifier le message pour les besoins du contrôle de flux. Lorsque le mécanisme A/R est activé, le numéro de message est incrémenté modulo 256 dans les messages successifs, en sautant le numéro de message zéro (zéro indique que A/R est désactivé pour ce message). Jusqu’à 127 messages peuvent être en cours (attendant l’acceptation ou le refus) dans chaque direction. Si le receveur d’un message est incapable d’accepter le message, un indication de refus contenant le numéro de message du message refusé et la raison du refus est retourné. L’indication de refus peut être portée sur les messages de données dans la direction opposée sur la liaison ou peut être envoyée dans un message de contrôle distinct en l’absence de trafic de données dans le sens inverse.

Les indications d’acceptation sont retournées d’une façon similaire, soit portées sur des messages de données soit dans un message de contrôle distinct. Une acceptation est retournée par le receveur pour indiquer que le message identifié a été reçu de la liaison d’accès de l’hôte et n’a pas été refusé. Les indications d’acceptation retournées par le WPS ne sont pas un accusé de réception de bout en bout et n’impliquent pas de garantie de livraison à l’hôte ou aux hôtes de destination, ou même une assurance que le message ne sera pas éliminé intentionnellement par le réseau. Ils sont envoyés principalement pour faciliter la gestion des mémoires tampon de l’hôte.

Pour réduire le nombre de messages A/R échangés, une seule indication A/R peut être retournée pour plusieurs (en petit nombre) messages non acquittés précédemment. L’acceptation explicite du numéro de message N implique une acceptation implicite des messages en cours avec les numéros N-1, N-2, etc., conformément à la définition de l’acceptation mentionnée ci-dessus. Une interprétation analogue du refus de numéro de message permet au receveur d’un groupe de messages de les rejeter en groupe lorsque ils sont tous refusés pour la même raison. Par mesure de plus grande efficacité, HAP permet l’agrégation de tout mélange d’indications A/R en un seul message de contrôle A/R. Un tel message peut être utilisé, par exemple, pour rejeter un groupe de messages où le code de refus est différent pour chacun.

Dans certaines circonstances la redondance associée au traitement des messages A/R peut se révéler dissuasive. Pour ces cas, il est possible de désactiver le mécanisme A/R et de faire fonctionner l’interface HAP en mode d’élimination pure. La capacité à effectuer cela liaison par liaison a déjà été notée (voir les Sections 2 et 8). De plus, les messages avec le numéro de séquence zéro sont pris pour des messages pour lesquels le mécanisme A/R est désactivé de façon sélective. Pour permettre un retour d’informations critiques, même lorsque le fonctionnement est en mode élimination, HAP définit un message de contrôle "Réponse non numérotée". Les informations de contrôle de flux, et les autres informations qui ne peuvent pas être envoyées comme une indication A/R, sont envoyées dans un message de contrôle Réponse non numérotée. Le format de ce type de message est illustré à la Figure 5.

Le format donné à la Figure 3 est utilisé à la fois pour les indications A/R qui sont portées par les messages de données (mot 2), et pour les informations d’A/R agrégées dans les messages A/R de contrôle. Le format des messages A/R de contrôle est donné à la Figure 4.

Figure 3 : Mot d’acceptation/refus

[0] Type d’acceptation/refus. Ce champ identifie si les informations d’A/R sont d’acceptation ou de refus.

0 = Acceptation
1 = Refus

[1-7] Code de refus. Lorsque le type d’acceptation/refus = 1, ce champ donne le code du refus.

0 = Priorité non acceptée
1 = Encombrement du WPS de source
2 = Encombrement du WPS de destination
3 = Hôte de destination mort
4 = WPS de destination mort
5 = Adresse d’hôte de destination illégale
6 = Accès non admis à l’hôte de destination
7 = Adresse d’hôte de source illégale
8 = Message perdu dans la liaison d’accès
9 = Identifiant de flux invalide
10 = Hôte de source illégal pour l’identifiant de flux
11 = Message trop long
12 = Message de flux trop tôt
13 = Type de message de contrôle illégal
14 = Code de refus illégale dans A/R
15 = La boucle ne peut être mise en œuvre
16 = Encombrement de l’hôte de destination
17 = Livraison refusée
18 = Nombre impair de longueur de paquet (non admis)
19 = Valeur de durée de vie de flux invalide
20 = La "longueur de fiabilité" excède la longueur du message

[8-15] A/R Numéro de message. Ce champ contient le numéro du message auquel se réfère cette acceptation/refus. Il s’applique aussi à tous les messages en instance avec des numéros antérieurs. Noter que ce champ ne peut jamais être zéro car un numéro de message de zéro implique que le mécanisme A/R est désactivé.

Figure 4 : Message d’acceptation/refus

0[0] Classe de message = 1 (Message de contrôle).

0[1] Indicateur de bouclage.

0[2-3] Priorité de passage.

0[4-7] Réservé.

0[8-11] Longueur de message. Ce champ contient la longueur totale de ce message en mots (N+1).

0[12-15] Type de message de contrôle = 1 (acceptation/refus).

1[0-15] Somme de contrôle d’en-tête. La somme de contrôle est le complément à 2 de la somme des compléments à 2 des mots 0 à N (à l’exclusion du mot de somme de contrôle lui-même).

2[0-15] Mot d’acceptation/refus.

3-N Mots supplémentaires d’acceptation/refus (facultatif).

Figure 5 : Réponse non numérotée

0[0] Classe de message = 1 (Message de contrôle).

0[1] Indicateur de bouclage.

0[2-3] Priorité de passage.

0[4-7] Réservé.

0[8-11] Code de réponse.

3 = Destination injoignable
5 = Adresse d’hôte de destination illégale
7 = Adresse d’hôte de source illégale
9 = Identifiant de flux non existant
10 = Identifiant de flux illégal
13 = Violation du protocole
15 = La boucle ne peut être mise en œuvre

0[12-15] Type de message de contrôle = 5 (Réponse non numérotée).

1[0-15] Somme de contrôle d’en-tête. La somme de contrôle est le complément à 2 de la somme des compléments à 2 des mots 0 à 3 (à l’exclusion du mot de somme de contrôle lui-même).

2[0-15] Informations de réponse. Si le code de réponse est :

3 : Adresse d’hôte de destination
5 : Adresse d’hôte de destination
7 : Adresse d’hôte de source
9 : Identifiant de flux (justifié à droite)
10 : Identifiant de flux (justifié à droite)
13 : Mot 0 du message en cause
15 : Mot 0 du message Demande de bouclage

3[0-15] Informations de réponse. Si le code de réponse est :

3, 5, 7, ou 9 : Indéfini
10 : Adresse d’hôte de source
13 : Mot 3 du message en cause, ou 0 si il n’y a pas de mot 3
15 : Mot 2 du message Demande de bouclage

6 L’agent de service

L’allocation des ressources réseau, telles que les flux et les groupes, est accomplie via un échange de messages de datagramme, appelé messages d’établissement, entre l’hôte utilisateur et l’agent de service (adresse réseau zéro). Les opérations d’établissement incluent la réservation, l’allocation, la modification, la libération, et la désallocation des ressources. L’agent de service provoque le traitement de l’action demandée et sert d’intermédiaire entre l’utilisateur et le reste du réseau. Dans le processus de mise en œuvre de l’action demandée, diverses bases de données du réseau sont mises à jour pour refléter l’état actuel de la ressource en cause. L’agent de service permet aussi à un hôte d’enquêter sur les ressources dont il dispose en se servant des messages Demande d’informations et Réponse d’informations.

Une interaction d’établissement initiée par un hôte implique un triple échange dans lequel : (1) l’hôte demandeur envoie un Demande d’établissement à l’agent de service, (2) l’agent de service retourne un Réponse d’établissement à l’hôte demandeur, et (3) l’hôte demandeur retourne un Accusé de réception d’établissement à l’agent de service. Cette procédure est utilisée pour assurer une transmission fiable des demandes et réponses d’établissement. Afin de permettre que soit en cours plus d’un message Demande d’établissement provenant d’un hôte, il est alloué à chaque demande un Identifiant de demande univoque. La réponse qui y est associée et l’accusé de réception qui suit sont identifiés par l’identifiant de demande qu’ils contiennent. L’hôte demandeur devrait recevoir une réponse à une demande d’établissement dans les trois secondes. Le délai réel va dépendre de la nature de la demande et de la topologie du réseau. Pour les réseaux simples, le délai va souvent être inférieur à une seconde. L’hôte demandeur devrait répondre à une Réponse par un Accusé de réception d’établissement en moins d’une seconde.

Les échanges d’établissement initiés par l’agent de service impliquent un échange double où : (1) l’agent de service envoie une Notification aux hôtes affectés, et (2) les hôtes retournent un Accusé de réception d’établissement à l’agent de service. Les notifications sont utilisées pour informer un hôte des changements d’état d’une ressource réseau. Afin de permettre que soit en cours plus d’une notification, il est alloué à chacune un identifiant de notification univoque. L’accusé de réception d’établissement retourné par l’hôte notifié à l’agent de service doit contenir l’identifiant de notification. L’hôte devrait répondre en moins d’une seconde.

Une interrogation pour information est initiée par un hôte et implique un échange dans lequel : (1) l’hôte envoie un message Demande d’informations à l’agent de service, et (2) l’agent de service renvoie un message Réponse d’information. Il n’y a pas de mécanisme d’accusé de réception, car cette demande ne change aucune allocation de ressource. De plus, s’il y a une erreur dans la demande, une seule réponse sera envoyée par le WPS, et le WPS ne fera aucun effort pour vérifier ou retransmettre des réponses perdues. Il est de la responsabilité de l’hôte d’attendre un certain temps et de déterminer alors qu’une demande d’informations sans réponse a été perdue de la retransmettre. (Le temps nécessaire pour répondre à une telle demande est normalement très inférieur à une seconde.) Le WPS va retourner l’identifiant de message de la demande d’informations dans le message de réponse d’informations.

Le format général de tous les messages d’agent de service est :

<en-tête de message de datagramme> <en-tête d’agent de service> <corps de message>

Le champ Identifiant de protocole dans l’en-tête de message de datagramme doit être HAP_PROTO_SETUP (1) (voir à l’Appendice C) pour les messages envoyés à l’agent de service et sera HAP_PROTO_SETUP dans les messages reçus de l’agent de service. L’agent de service ne reconnaît pas ou ne prend pas en charge l’utilisation d’autres protocoles de niveau supérieur (par exemple, IP), dans les messages d’établissement, et éliminera les messages contenant des tels en-têtes.

Les illustrations de formats de message ci-dessous montrent seulement l’en-tête d’agent de service et le corps de message et n’incluent pas l’en-tête de message de datagramme. Pour rappeler que l’en-tête de datagramme n’est pas inclus, les décalages de mots son préfixés d’un "S".

Le format de l’en-tête d’agent de service est illustré à la Figure 6. Le corps de message va dépendre du type de message. Les messages Demande de flux et Réponse de flux sont décrits au paragraphe Section 6.1. Les messages Demande de groupe et Réponse de groupe sont décrits au paragraphe 6.2. Le format des notifications est décrit au paragraphe 6.3, et celui des accusés de réception d’établissement est décrit au paragraphe 6.4. Les messages Demande et Réponse d’informations sont décrits au paragraphe 6.5.

Figure 6 : En-tête d’agent de service

S0[0-7] Type de message. Ce champ détermine le type de message.

0 = Accusé de réception d’établissement
1 = Demande d’établissement
2 = Réponse d’établissement
3 = Notification
4 = Demande d‘informations
5 = Réponse d’informations

S0[8-15] Code.

Pour les demandes d’établissement, ce champ identifie le type de demande.

1 = Créer une adresse de groupe (diffusion groupée)
2 = Supprimer une adresse de groupe
3 = Joindre à un groupe
4 = Quitter un groupe
5 = Créer un flux
6 = Supprimer un flux
7 = Changer un flux
8 = Créer un flux partagé
9 = Supprimer tous les flux possédés par cet hôte
10 = Ajouter un membre au groupe
11 = Retirer un membre du groupe

Pour les Réponses d’établissement, ce champ donne le code de réponse. Certains des codes de réponse peuvent être retournés à toute demande d’établissement et d’autres sont spécifiques de la demande.

0 = Groupe ou flux créé
1 = Groupe ou flux supprimé
2 = Hôte ajouté au groupe
3 = Hôte supprimé du groupe
4 = Flux changé
5 = (Réservé)
6 = Type de demande invalide ou non pris en charge
7 = (Réservé)
8 = Problème réseau
9 = Mauvaise clé de groupe
10 = Identifiant d’adresse/flux de groupe non existant
11 = Non membre du groupe/non créateur de flux
12 = Préséance de flux non acceptée
13 = (Réservé)
14 = (Réservé)
15 = (Réservé)
16 = Incapable d’ajouter tous les nouveaux hôtes
17 = Ressources réseau insuffisantes
18 = Bande passante demandée trop grande
19 = (Réservé)
20 = (Réservé)
21 = Maximum de messages par intervalle trop faible
22 = Réponse perdue par le réseau
23 = Valeur illégale de priorité ou préséance
24 = Adresse fournie invalide

Pour Notification, ce champ contient le type de notification. (Voir au paragraphe 6.3.)

Pour Accusé de réception d’établissement, ce champ contient le type d’accusé de réception. (Voir au paragraphe 6.4.)

Pour Demande d’information, ce champ contient le type de demande. (Voir au paragraphe 6.5.)

Pour Réponse d’information, ce champ contient le type de réponse. (Voir au paragraphe 6.5.)

S1[0-15] Somme de contrôle. La somme de contrôle est le complément à 2 de la somme des compléments à 2 des mots dans l’en-tête d’agent de service (à l’exclusion du mot de somme de contrôle lui-même) et le corps de message. Les messages reçus avec une mauvaise somme de contrôle doivent être éliminés.

S2[0-15] Identifiant de message. Ce champ est alloué par l’hôte pour identifier de façon univoque les demandes en cours (identifiant de demande) et pas l’agent de service pour identifier de façon univoque les notifications en cours (identifiant de notification).

6.1 Messages d’établissement de flux

Les flux donnent le moyen de réserver des ressources réseau pour délivrer du trafic à un débit maximum spécifié à une liste de destinataires désignés. Le trafic envoyé via un flux a priorité sur tout trafic hors flux, et sa livraison est faite dans le délai minimum de bout en bout possible. Les hôtes utilisent les flux pour prendre en charge des applications qui ont des charges de trafic prévisibles (tels que la voix par paquet ou la vidéo ou d’autres trafic à support continu) ou qui exigent un délai de transmission minimum et la plus faible variance de délai. Les flux sont normalement utilisés pour des flux de trafic de durée modérée à longue, où le coût d’un établissement de flux est acceptable.

Les flux doivent être établis avant que les messages de données de flux puissent s’écouler. Les messages d’établissement de flux, dont chacun a une demande et une réponse, sont Créer le flux, Supprimer le flux, Changer le flux, et Supprimer tous les flux. (La demande Créer un flux partagé est une addition future prévue au protocole.) L’utilisation de ces messages est illustrée dans le scénario des échanges entre un hôte et l’agent de service montré à la Figure 7 où l’hôte établit un flux, envoie des données, modifie les caractéristiques du flux, envoie d’autres données, et finalement ferme le flux. Non illustré, mais implicites dans ce scénario, sont les indications facultatives d’A/R associées à chaque message d’établissement de flux.

Figure 7 : Exemple de flux

Les flux ont huit propriétés caractéristiques qui sont sélectionnées au moment de l’établissement. Ces propriétés sont : (1) les mots de données par intervalle de temps, (2) l’intervalle de temps, (3) la fiabilité, (4) la longueur de fiabilité, (5) la préséance, (6) le nombre maximum de messages par intervalle, (7) la liste des receveurs, et (8) l’ensemble des autres flux avec lesquels de flux partage les ressources. Pour établir un flux, l’hôte envoie le message Créer une demande de flux (Figure 8) à l’agent de service. Après que le réseau a traité la demande de création de flux, l’agent de service va répondre par un message Réponse de création de flux (Figure 9). Si le code de réponse dans la Réponse de création de flux indique que le flux a bien été créé, l’hôte peut procéder à l’émission des flux de messages de données après avoir envoyé un accusé de réception de réponse.

Durant la durée de vie d’un flux, l’hôte qui l’a créé peut décider que certaines de ses propriétés caractéristiques devraient être modifiées. Toutes les propriétés sauf une peuvent être modifiées en utilisant le message Changer la demande de flux (Figure 10). La seule propriété qui ne peut pas être changée est si le flux veut ou non partager ses ressources avec d’autres flux. Après que le réseau a traité la demande de changement de flux, l’agent de service va répondre en envoyant une Réponse de changement de flux (Figure 11) à l’hôte. Un hôte qui demande une allocation de canal réduite devrait diminuer immédiatement son débit d’émission sans attendre la réception de la Réponse de changement de flux. Un hôte qui demande une augmentation d’allocation ne devrait pas commencer à émettre selon le nouvel ensemble de paramètres sans avoir d’abord reçu un code de réponse indiquant que le changement demandé a pris effet.

Lorsque l’hôte n’a plus besoin du flux qu’il a créé, il devrait d’abord arrêter d’envoyer du trafic via le flux et ensuite envoyer à l’agent de service un message Demande de suppression de flux (Figure 12). Après que le réseau a traité la demande de suppression de flux, l’agent de service va répondre en envoyant une réponse de suppression de flux (Figure 13) à l’hôte.

Si l’hôte s’est planté ou a redémarré, il peut ne plus savoir quels flux il possède. L’hôte peut utiliser une Demande d’informations (voir au paragraphe 6.5) pour déterminer quels flux il possède, ou l’hôte peut utiliser Demande de suppression de tous les flux (Figure 14) pour éliminer toutes les ressources de flux qu’il pourrait posséder. Le format de Réponse de suppression de tous les flux est donné à la Figure 15.

Noter que les flux, comme toutes les autres ressources allouées par l’agent de service,peuvent être réclamés par le réseau s’il sont inutilisés. Normalement, si aucune trafic n’est envoyé à un flux dans un intervalle de 6 minutes, et si le propriétaire du flux est mort ou injoignable, le flux peut être supprimé.

Figure 8 : Demande de création de flux

S0[0-7] Type d’établissement = 1 (Demande).

S0[8-15] Type de demande = 5 (Créer un flux).

S1[0-15] Somme de contrôle d’établissement. (Voir la description de l’en-tête d’établissement.)

S2[0-15] Identifiant de demande.

S3[0-3] Maximum de messages par intervalle (1 à 15). Ce champ spécifie le nombre maximum de messages de flux que l’hôte va délivrer au WPS dans tout intervalle de flux.

S3[4-5] Préséance. Ce champ spécifie la préséance du flux. Lorsqu’il y a des ressources réseau insuffisantes pour prendre en charge tous les flux demandés, les demandes pour les flux de préséance supérieure vont préempter les flux existants de préséance inférieure et les demandes pour des flux avec une préséance insuffisante seront rejetés. La préséance moyenne est recommandée comme choix par défaut.

0 = Préséance basse
1 = Préséance moyenne
2 = Préséance élevée

S3[6-7] Intervalle. Ce champ spécifie l’intervalle, en multiples de 21,22 millisecondes. (Pour la rétro compatibilité seulement. Les nouvelles applications devraient utiliser 3. L’utilisation de ce champ pour spécifier un intervalle est en cours de suppression.)

0 = 21,22 millisecondes
1 = 42,44 millisecondes
2 = 84,88 millisecondes
3 = utilise l’intervalle du mot S5

S3[8-9] Fiabilité. Ce champ spécifie l’exigence de base de débit d’erreur binaire pour la portion données de tous les messages du flux. Le débit d’erreur exact obtenu par chaque choix n’est pas spécifié.

0 = Fiabilité faible
1 = Fiabilité moyenne basse
2 = Fiabilité moyenne haute
3 = Haute fiabilité

S3[10-15] Longueur de fiabilité. Ce champ spécifie combien de mots au delà de l’en-tête du message de flux devraient être transmis à la fiabilité maximum pour tous les messages dans le flux de l’hôte.

S4[0-15] Mots de données par intervalle. Ce champ spécifie le nombre maximum de mots de 16 bits des données de ce flux que le réseau a besoin de transporter durant chaque intervalle, sans compter les mots de l’en-tête de message de flux HAP. Les données de flux peuvent être portées dans autant de messages (jusqu’à MAX MES) dans chaque intervalle que le choisit l’hôte.

S5[0-15] Intervalle (en unités de 125 microsecondes). Ce champ spécifie l’intervalle de temps auquel les données de <mots de données par intervalle> dans les messages <max mes> seront envoyées. Pour la rétro-compatibilité, un intervalle de 0 choisit un intervalle de 169,76 millisecondes. Ce champ est ignoré sauf si le champ INT est 3.

S6[0-7] Réservé. Doit être à zéro.

S6[8-15] Longueur de liste d’adresses de destination. Ce champ spécifie le nombre d’entrées dans le champ Liste d’adresses de destination. Les valeurs permises sont 1 à 8.

S7-SN Liste d’adresses de destination. Cette liste doit spécifier, au moins indirectement, tous les receveurs prévus de ce trafic de flux. Au moins une adresse de destination doit être fournie. Toute adresse réseau valide, y compris en particulier les adresses de groupe, peuvent être utilisées (excepté l’adresse de l’agent de service, 0). Les messages envoyés dans le flux ne se limitent pas à l’utilisation des adresses HAP sur la liste. Par exemple, si la liste consiste seulement en l’adresse de groupe G, et si l’hôte A est un membre de G, un message de flux peut être envoyé à A, qui n’est pas sur la liste.

Attention : L’adhésion à un groupe n’est évaluée qu’à l’établissement. Les changements des membres d’un groupe ne causent pas la modification du flux.

Attention : La création d’un flux implique l’allocation de ressources réseau spécifiques le long de routes spécifiques pour la livraison de ce trafic. Un message de flux envoyé à des hôtes autres que ceux spécifiés via Setup sera probablement non livrable. Un message de flux à une adresse d’un groupe qui a acquis de nouveaux membres depuis le dernier établissement du flux peut être non livrable aux nouveaux membres.

Figure 9 : Réponse de création de flux

S0[0-7] Type d’établissement = 2 (Réponse).

S0[8-15] Code de réponse. Toute réponse autre que "Flux créé" signifie que le flux n’a pas été créé.

0 = Flux créé
8 = Problème réseau
12 = Préséance de flux non acceptée
17 = Ressources réseau insuffisantes
18 = Bande passante demandée trop grande
21 = Max. messages par intervalle trop petit
22 = Réponse perdue dans le réseau
23 = Valeur de préséance illégale
24 = Adresse de destination invalide dans la liste

S1[0-15] Somme de contrôle d’établissement. (Voir la description d’en-tête d’établissement.)

S2[0-15] Identifiant de demande.

S3[0-5] Réservé. Doit être à zéro.

S3[6-15] ID de flux. Ce champ contient un identifiant de flux alloué par le réseau. Il doit être inclus dans tous les messages de données du flux envoyés par l’hôte pour permettre au WPS d’associer le message aux caractéristiques de flux mémorisées et aux ressources réservées pour ce trafic du flux.

S4[0-5] Réservé. Doit être à zéro.

S4[6-15] Longueur de la liste d’adresses. Nombre des entrées dans le champ Liste d’adresses.

S5-SN Liste d’adresses. Il contient les adresses de destination provenant de la demande Création de flux qui étaient invalides ou injoignables. Les destinations injoignables font l’objet d’une liste comme un groupe où tous les membres du groupe sont injoignables, ou individuellement autrement ; c’est-à-dire, les adresses du groupe sont développées et les membres injoignables sont inclus dans la liste. La liste des destinations injoignables sera tronquée, si nécessaire, pour limiter cette réponse à un seul message HAP de longueur maximum.

Figure 10 : Demande de changement de flux

S0[0-7] Type d’établissement = 1 (Demande).

S0[8-15] Type de demande = 7 (Changer le flux).

S1[0-15] Somme de contrôle d’établissement. (Voir la description de l’en-tête d’établissement.)

S2[0-15] Identifiant de demande.

S3[0-5] Réservé. Doit être à zéro.

S3[6-15] ID de flux.

S4[0-3] Nouveau maximum de messages par intervalle.

S4[4-5] Nouvelle préséance.

S4[6-7] Nouveau choix d’intervalle.

S4[8-9] Nouvelle fiabilité.

S4[10-15] Nouvelle longueur de fiabilité.

S5[0-15] Nouveau mots de données par intervalle.

S6[0-15] Nouvel intervalle (ignoré sauf pour INT = 3).

S7[0-7] Réservé. Doit être à zéro.

S7[8-15] Longueur de liste d’adresses de destination. Ce champ spécifie le nombre d’entrées dans la nouvelle Liste d’adresses de destination. Les valeurs admises sont 0 à 8. Utiliser zéro (qui indique qu’il n’y a pas d’adresse dans la liste) pour éviter de changer la liste des hôtes receveurs.

S8-SN Nouvelle liste d’adresses de destination. Nouvelle liste, complète, des hôtes receveurs. La qualité de membre des adresses de groupe est évaluée au moment de l’exécution de l’établissement. Les changements ultérieurs des membres du groupe ne causent pas de modification du flux. Noter que l’utilisation de la même liste d’adresses de destination dans la demande de changement de flux que celle utilisée dans la demande de création de flux peut aboutir à un changement de la liste des hôtes receveurs si les membres du groupe ont changé.

Figure 11 : Réponse de changement de flux

S0[0-7] Type d’établissement = 2 (Réponse).

S0[8-15] Code de réponse. Le nombre entre parenthèses indique la phase de traitement au moment de l’erreur (voir le paragraphe marqué Attention ci-dessous). Les erreurs de la phase zéro et de la phase une laissent le flux inchangé ; les erreurs des dernières phases peuvent laisser le flux partiellement modifié.

4 = Flux changé
8 = (1) Problème réseau
10 = (0) Identifiant de flux non existant
11 = (0) Pas de création de flux
12 = (0) Préséance de flux non acceptée
16 = (3) Incapable d’ajouter les nouveaux receveurs
17 = (2) Ressources réseau insuffisantes
18 = (2) Bande passante demandée trop grande
21 = (0) Maximum de messages par intervalle trop petit
22 = (2) Réponse perdue dans le réseau
23 = (0) Valeur de préséance illégale
24 = (0) Adresse de destination invalide dans la liste

S1[0-15] Somme de contrôle d’établissement. (Voir la description d’en-tête d’établissement.)

S2[0-15] Identifiant de demande.

S3[0-5] Réservé. Doit être à zéro.

S3[6-15] Longueur de liste d’adresse. Ce champ spécifie le nombre d’adresses dans la liste d’adresses.

S4-SN Liste d’adresses. Elle contient les adresses de destination provenant de la demande Changement de flux qui étaient invalides (erreurs de phase 0) ou injoignables (erreurs de phase 3). Les destinations injoignables sont énumérées comme un groupe si chaque membre du groupe était injoignable, ou individuellement autrement ; c’est-à-dire que les adresses du groupe sont développées et les membre injoignables sont inclus dans la liste. La liste des destinations injoignables sera tronquée, si nécessaire, pour limiter cette réponse à un seul message HAP de longueur maximum.

Attention : la réponse de changement de flux va indiquer un échec si un aspect du changement demandé ne s’est pas produit. Cependant, le flux peut avoir été partiellement modifié. Le traitement est effectué selon les trois phases suivantes :

0 : vérifier q’il y a des demandes invalides ;

1 : éliminer les anciens receveurs qui ne sont plus dans la dernière liste ;

2 : augmenter ou diminuer l’allocation de bande passante du flux (les diminutions réussissent normalement) ;

3 : étendre le flux à tout nouveau receveur.

Si la phase 2 échoue, la phase 3 n’est pas effectuée, le code de réponse va indiquer une erreur et les paramètres du flux seront inchangés. Si la phase 3 échoue, la liste d’adresses contiendra les destinations que le flux n’a pas atteint, s’il en est, provenant de la dernière lister. La phase 1 n’échoue que si le flux a été suspendu (voir à Notifications) ou si le WPS rencontre des problèmes de connexité avec le réseau.

Figure 12 : Demande de suppression de flux

S0[0-7] Type d’établissement= 1 (Demande).

S0[8-15] Type de demande = 6 (Supprimer le flux).

S1[0-15] Somme de contrôle d’établissement. (Voir la description de l’en-tête d’établissement.)

S2[0-15] Identifiant de demande.

S3[0-5] Réservé. Doit être à zéro.

S3[6-15] Identifiant de flux.

Figure 13 : Réponse de suppression de flux

S0[0-7] Type d’établissement = 2 (Réponse).

S0[8-15] Code de réponse. Si la demande était valide, l’agent de service aura marqué le flux pour suppression même si les ressources du flux n’ont pas encore été supprimées.

1 = Flux supprimé
10 = Identifiant de flux non existant
11 = Pas de création de flux

S1[0-15] Somme de contrôle d’établissement. (Voir la description d’en-tête d’établissement.)

S2[0-15] Identifiant de demande.

Figure 14 : Demande de supprimer tous les flux

S0[0-7] Type d’établissement = 1 (Demande).

S0[8-15] Type de demande = 9 (Supprimer tous les flux).

S1[0-15] Somme de contrôle d’établissement. (Voir la description d’en-tête d’établissement.)

S2[0-15] Identifiant de demande.

Figure 15 : Réponse à supprimer tous les flux

S0[0-7] Type d’établissement = 2 (Réponse).

S0[8-15] Code de réponse. L’agent de service aura marqué tous les flux de l’hôte à supprimer, même si les ressources du flux n’ont pas encore été supprimées.

1 = Flux supprimés

S1[0-15] Somme de contrôle d’établissement. (Voir la description d’en-tête d’établissement.)

S2[0-15] Identifiant de demande.

6.2 Messages d’établissement de groupe

L’adressage de groupe (diffusion groupée) permet à un hôte d’envoyer le même message à N hôtes différents sans avoir à envoyer N copies du message. Le réseau duplique le message autant que de besoin. En plus de la réduction de la charge pour l’hôte d’origine, la diffusion groupée réduit la charge du réseau parce que le réseau n’a plus à transporter les duplicata le long des portions communes des chemins entre la source et les destinations. La diffusion groupée est particulièrement recommandée pour les conférences multi sites et les simulations réparties.

Les adresses de groupe sont créées et supprimées de façon dynamique via les messages d’établissement échangés entre les hôtes et l’agent de service. Les membres d’un groupe peuvent être tout sous-ensemble arbitraire des hôtes du réseau. Un message de datagramme ou un message de flux adressé à un groupe est délivré à tous les hôtes qui sont membres de ce groupe (exception : les messages de flux envoyés à une adresse de groupe qui inclut des hôtes dont le flux n’est pas établi). Les messages d’établissement de groupe, dont chacun a une Demande et une réponse, sont Créer le groupe, Supprimer le groupe, Joindre le groupe, Quitter le groupe, Ajouter un membre au groupe, et Retirer un membre du groupe.

La Figure 16 montre une utilisation normale des messages d’établissement de groupe. La figure illustre un scénario d’échanges entre trois hôtes et l’agent de service. Dans le scénario, un hôte, l’hôte A, crée un groupe auquel se joignent les hôtes B et C. Les hôtes échangent alors des messages de données en utilisant l’adresse de groupe. Noter que les messages en diffusion groupée ne sont pas retourné à leur origine. Les hôtes A et C quittent alors le groupe, et l’hôte B décide de supprimer le groupe. Comme dans le scénario du paragraphe 6.1, les indications d’A/R ont été omises pour simplifier.

Une partie de la procédure de création de groupe implique que l’agent de service retourne à l’hôte créateur une clé de 48 bits avec l’adresse de groupe de 16 bits. L’hôte créateur doit passer la clé avec l’adresse de groupe aux autres hôtes qui veulent se joindre au groupe. Ces autres hôtes doivent fournir la clé avec l’adresse de groupe dans leurs demandes Joindre le groupe. La clé est utilisée par le réseau pour authentifier ces opérations et minimiser par là la probabilité que des hôtes non désirés deviennent délibérément ou par inadvertance membres du groupe. La procédure utilisée par un hôte pour distribuer l’adresse du groupe et la clé sort du domaine d’application de HAP.

Dans la figure ci-dessous, pour simplifier, l’agent de service réseau est décrit comme une seule entité.

Figure 16 : Exemple de groupe

Une autre méthode pour ajouter et retrancher des membres d’un groupe est d’utiliser Ajouter un membre du groupe et Retirer un membre du groupe. Ces demandes d’établissement permettent aux hôtes qui sont déjà membres du groupe d’ajouter ou de supprimer d’autres hôtes.

Les demandes d’établissement Joindre le groupe, Quitter le groupe, Ajouter un membre du groupe, Retirer un membre du groupe, et Supprimer le groupe sont authentifiées en utilisant la clé de 48 bits. Quitter le groupe et Retirer un membre du groupe vont retirer un hôte de la liste des membres du groupe mais ne vont pas altérer l’existence du groupe. Supprimer le groupe efface toute connaissance du groupe dans le réseau. HAP permet à tout hôte qui détient la clé appropriée de supprimer le groupe à tout moment. Et donc, les adresses de groupe peuvent être supprimées même si l’hôte qui est à l’origine de la création du groupe a quitté le groupe ou s’est planté. De plus, des groupes peuvent exister pour lesquels il n’y a actuellement pas de membre parce que chaque membre a exécuté un Quitter alors qu’aucun n’a exécuté un Supprime. Il est de la responsabilité des hôtes de coordonner et gérer l’utilisation des adresses de groupe.

Noter que les adresses de groupe, comme toutes les autres ressources allouées par le réseau, peuvent être réclamées par le réseau si elles sont trop longtemps inutilisées. Actuellement, si aucun trafic n’est envoyé à l’adresse de groupe dans un intervalle de 6 minutes, le réseau peut supprimer le groupe et notifier à tous les membres que le groupe n’existe plus.

La demande Création de groupe (Figure 17) est utilisée pour établir une adresse de diffusion groupée. Après que le réseau a traité la demande Création de groupe, l’agent de service va répondre en envoyant la réponse de Création de groupe (Figure 18) à l’hôte.

Un hôte peut devenir membre d’un groupe une fois qu’il connaît l’adresse de groupe et la clé de 48 bits, en envoyant à l’agent de service le message de demande Joindre le groupe (Figure 19). L’agent de service va répondre à la demande Joindre le groupe par une réponse à Joindre le groupe (Figure 20). L’hôte qui a créé un groupe devient automatiquement membre de ce groupe sans qu’il soit besoin d’une demande explicite Joindre le groupe.

Un hôte membre peut ajouter un autre hôte au groupe en envoyant à l’agent de service le message Ajouter un membre au groupe (Figure 21). L’agent de service va répondre par une réponse à Ajouter un membre au groupe (Figure 22).

À tout moment après être devenu membre d’un groupe, un hôte peut choisir d’abandonner le groupe. Pour ce faire, l’hôte envoie à l’agent de service une demande Quitter le groupe (Figure 23). L’agent de service va répondre par une réponse à Quitter le groupe (Figure 24).

Un hôte membre peut expulser un autre membre du groupe en envoyant à l’agent de service le message de demande Retirer un membre du groupe (Figure 25). L’agent de service va répondre par une réponse à Retirer un membre du groupe (Figure 26).

Un hôte peut supprimer un groupe existant via une demande Supprimer le groupe (Figure 27). L’agent de service va répondre par une réponse à Supprimer le groupe (Figure 28). L’agent de service va aussi envoyer aux autres membres du groupe, s’il en est, une notification de la suppression du groupe (voir au paragraphe 6.3).

Figure 17 : Demande de création de groupe

S0[0-7] Type d’établissement = 1 (Demande).

S0[8-15] Type de demande = 1 (Créer le groupe).

S1[0-15] Somme de contrôle d’établissement. (Voir la description de l’en-tête d’établissement.)

S2[0-15] Identifiant de demande.

Figure 18 : Réponse de Création de groupe

S0[0-7] Type d’établissement = 2 (Réponse).

S0[8-15] Code de réponse.

0 = Groupe créé
8 = Problème réseau
17 = Ressources réseau insuffisantes
22 = Réponse perdue dans le réseau

S1[0-15] Somme de contrôle d’établissement. (Voir la description de l’en-tête d’établissement.)

S2[0-15] Identifiant de demande.

S3[0-15] Adresse de groupe. Ce champ contient l’adresse de diffusion groupée de 16 bits que tout membre du groupe peut utiliser pour joindre les autres membres du groupe. Les adresses de diffusion groupée sont allouées de façon dynamique par le réseau.

S4-S6 Clé. Ce champ contient une clé de 48 bits allouée par le réseau; qui est associée à l’adresse de groupe. Elle doit être fournie pour les demandes ultérieures Joindre le groupe, Quitter le groupe, Ajouter un membre du groupe, Retirer un membre du groupe, et Supprimer le groupe, qui font référence à l’adresse du groupe.

Figure 19 : Demande de Joindre le groupe

S0[0-7] Type d’établissement = 1 (Demande).

S0[8-15] Type de demande = 3 (Joindre le groupe).

S1[0-15] Somme de contrôle d’établissement. (Voir la description de l’en-tête d’établissement.)

S2[0-15] Identifiant de demande.

S3[0-15] Adresse de groupe. C’est le groupe auquel l’hôte souhaite se joindre. Ayant réussi à se joindre au groupe, l’hôte peut envoyer des messages au groupe et va recevoir des messages envoyés au groupe quand ces messages ont une priorité de MGP ou supérieure.

S4-S6 Clé. C’est la clé associée à l’adresse du groupe.

S7[0-13] Réservé. Doit être à zéro.

S7[14-15] Priorité minimum du message de groupe. L’hôte ne va pas recevoir de messages envoyés au groupe qui ont une priorité de message inférieure à MGP. Il faut envoyer un autre message de demande Joindre le groupe pour changer la priorité minimum.

Figure 20 : Réponse à Joindre le groupe

S0[0-7] Type d’établissement = 2 (Réponse).

S0[8-15] Code de réponse.

2 = Hôte ajouté au groupe
9 = Mauvaise clé
10 = Adresse de groupe non existante
17 = Ressources réseau insuffisantes

S1[0-15] Somme de contrôle d’établissement. (Voir la description de l’en-tête d’établissement.)

S2[0-15] Identifiant de demande.

Figure 21 : Demande Ajouter un membre du groupe

S0[0-7] Type d’établissement = 1 (Demande).

S0[8-15] Type de demande = 3 (Joindre le groupe).

S1[0-15] Somme de contrôle d’établissement. (Voir la description de l’en-tête d’établissement.)

S2[0-15] Identifiant de demande.

S3[0-15] Adresse du groupe. C’est le groupe auquel l’hôte va se joindre. Ayant réussi à se joindre au groupé, l’hôte peut envoyer des messages au groupe et va recevoir des messages envoyés au group par d’autres hôtes (la priorité minimum initiale de message sera 0).

S4-S6 Clé. C’est la clé associée à l’adresse du groupe.

S7[0-15] Adresse de l’hôte. L’adresse réseau de l’hôte à ajouter au groupe.

Figure 22 : Réponse d’ajout de membre du groupe

S0[0-7] Type d’établissement = 2 (Réponse).

S0[8-15] Code de réponse.

2 = Hôte ajouté au groupe (ou était déjà membre)
9 = Mauvaise clé
10 = Adresse de groupe non existante
11 = Le demandeur n’est pas membre du groupe
17 = Ressources réseau insuffisantes
22 = Réponse perdue dans le réseau
24 = Adresse d’hôte invalide

S1[0-15] Somme de contrôle d’établissement. (Voir la description de l’en-tête d’établissement.)

S2[0-15] Identifiant de demande.

Figure 23 : Demande Quitter le groupe

S0[0-7] Type d’établissement = 1 (Demande).

S0[8-15] Type de demande = 4 (Quitter le groupe).

S1[0-15] Somme de contrôle d’établissement. (Voir la description de l’en-tête d’établissement.)

S2[0-15] Identifiant de demande.

S3[0-15] Adresse de groupe. C’est le groupe dont l’hôte souhaite cesser d’être membre. Ayant quitté le groupe, l’hôte va cesser de recevoir les messages envoyés au groupe et ne sera plus capable d’en envoyer au groupe.

S4-S6 Clé. C’est la clé associée à l’adresse de groupe.

Figure 24 : Réponse à Quitter le groupe

S0[0-7] Type d’établissement = 2 (Réponse).

S0[8-15] Code de réponse.

3 = Hôte supprimé du groupe
9 = Mauvaise clé
10 = Adresse de groupe invalide
11 = Non membre du groupe
17 = Ressources réseau insuffisantes

S1[0-15] Somme de contrôle d’établissement. (Voir la description de l’en-tête d’établissement.)

S2[0-15] Identifiant de demande.

Figure 25 : Demande de Retirer un membre du groupe

S0[0-7] Type d’établissement = 1 (Demande).

S0[8-15] Type de demande = 4 (Quitter le groupe).

S1[0-15] Somme de contrôle d’établissement. (Voir la description de l’en-tête d’établissement.)

S2[0-15] Identifiant de demande.

S3[0-15] Adresse de groupe. C’est le groupe dont l’hôte devrait être retiré. Après avoir quitté le groupe, cet hôte va cesser de recevoir les messages envoyés au groupe et sera incapable d’en envoyer au groupe.

S4-S6 Clé. C’est la clé associée à l’adresse de groupe.

S7[0-15] Adresse de l’hôte. Adresse réseau de l’hôte à retirer du groupe.

Figure 26 : Réponse à retirer le membre du groupe

S0[0-7] Type d’établissement = 2 (Réponse).

S0[8-15] Code de réponse.

3 = Hôte supprimé du groupe (ou n’était pas membre)
9 = Mauvaise clé
10 = Adresse de groupe invalide
11 = Demandeur non membre du groupe
17 = Ressources réseau insuffisantes
22 = Réponse perdue dans le réseau
24 = Adresse d’hôte invalide

S1[0-15] Somme de contrôle d’établissement. (Voir la description de l’en-tête d’établissement.)

S2[0-15] Identifiant de demande.

Figure 27 : Demande Supprimer le groupe

S0[0-7] Type d’établissement = 1 (Demande).

S0[8-15] Type de demande = 2 (Supprimer le groupe).

S1[0-15] Somme de contrôle d’établissement. (Voir la description de l’en-tête d’établissement.)

S2[0-15] Identifiant de demande.

S3[0-15] Adresse de groupe. C’est l’adresse de diffusion groupée à supprimer. Si le groupe est supprimé, les autres membres restants du groupe, s’il en est, auront notification de la suppression du groupe.

S4-S6 Clé.

Figure 28 : Réponse à Supprimer le groupe

S0[0-7] Type d’établissement = 2 (Réponse).

S0[8-15] Code de réponse.

1 = Groupe supprimé
8 = Problème réseau
9 = Mauvaise clé
10 = Adresse de groupe invalide
17 = Ressources réseau insuffisantes
22 = Réponse perdue dans le réseau

S1[0-15] Somme de contrôle d’établissement. (Voir la description de l’en-tête d’établissement.)

S2[0-15] Identifiant de demande.

6.3 Notifications

Les notifications sont des échanges d’établissement initiés par le WPS pour informer un hôte des changements de l’état d’une ressource réseau. Le format des messages Notification est indiqué à la Figure 29.

Figure 29 : Message de notification

S0[0-7] Type de message = 3 (Notification).

S0[8-15] Code. Il indique ce que la Notification signifie.

0 = Flux suspendu
1 = Flux repris
2 = Flux supprimé
3 = Groupe supprimé par un hôte
4 = Groupe supprimé par le réseau
5 = Tous les flux sont supprimés
6 = Tous les groupes sont supprimés
7 = Groupe changé par l’hôte
8 = Groupe changé par le réseau

S1[0-15] Somme de contrôle. (Voir la description de l’en-tête d’agent de service.)

S2[0-15] Identifiant de notification.

S3[0-15] Informations de notification.

Pour les types de notification 0, 1, et 2, Informations de notification contient ce qui suit :

Pour les types de notification 3, 4, 7, et 8, Informations de notification contient ce qui suit :

Pour les types de notification 5 et 6, qui se réfèrent à tous les flux ou groupes, Informations de notification est zéro.

6.4 Accusés de réception d’établissement

L’hôte doit accuser réception des Réponses et Notifications d’établissement provenant de l’agent de service, comme décrit plus haut. Le format du message d’Accusé de réception d’établissement est indiqué à la Figure 30.

Figure 30 : Accusé de réception d’établissement

S0[0-7] Type de message = 0 (Accusé de réception).

S0[8-15] Code. Ce champ indique le type d’accusé de réception.

0 = Accusé de réception de réponse

1 = Accusé de réception de notification

S1[0-15] Somme de contrôle. (Voir la description d’en-tête d’agent de service.)

S2[0-15] Identifiant de message. C’est un Identifiant de demande ou un Identifiant de notification.

6.5 Messages de demande/réponse d’information

L’hôte peut obtenir des informations sur l’état du WPS et sur les ressources que le WPS a actuellement allouées pour l’hôte en envoyant un message Demande d’informations à l’agent de service. La réponse d’informations qui est retournée permettra à l’hôte de déterminer 1) quelles ressources le WPS a allouées à l’hôte et 2) l’état actuel du réseau, et éventuellement, certains paramètres du réseau. Cela permet à l’hôte de se dispenser d’essayer d’utiliser des ressources dont il n’a plus la disposition, et de récupérer des informations qu’il peut avoir perdu sur ses ressources réseau. Cette communication informe aussi l’hôte sur l’état du réseau de façon qu’il puisse prendre des décisions en matière de priorités et d’acheminement.

Chaque message Demande d’informations (Figure 31) et Réponse d’informations (Figure 32) traite d’un seul type de ressource à la fois. L’en-tête du message Réponse d’informations contient le nombre d’entrées au sein du message, le nombre de mots de 16 bits dans chaque entrée, et une instance de la structure d’informations appropriée pour chaque ressource que décrit le message de Réponse d’informations. Ces structures d’informations sont décrites aux Figures 33 et 34.

De futures versions du protocole HAP pourront permettre des interrogations sur la connexité du réseau, sur le délai estimé pour une adresse de destination spécifique dans des conditions spécifiées, etc. C’est une section du protocole qui va vraisemblablement s’étendre à l’avenir. Les extensions sont prévues pour être rétro compatibles à condition que les développeurs ne codent pas dans le matériel la taille des entrées d’informations retournées.

Figure 31 : Message Demande d’informations

S0[0-7] Type de message = 4 (Demande d’informations).

S0[8-15] Code. Ce champ identifie le Type de Demande d’informations.

1 = Flux possédés par l’hôte

2 = Groupes auxquels l’hôte appartient

S1[0-15] Somme de contrôle. (Voir la description d’en-tête d’agent de service.)

S2[0-15] Identifiant de message. Ce champ est alloué par l’hôte pour identifier de façon univoque les demandes en cours (Identifiant de demande). Cet ID est copié dans le message Réponse d’informations par l’agent de service.

Figure 32 : Message réponse d’informations

S0[0-7] Type de message = 5 (Réponse d’informations).

S0[8-15] Code. Ce champ identifie le type de réponse d’informations.

1 = Flux possédés par l’hôte

2 = Groupes auxquels appartient l’hôte

3 = Erreur dans le message Demande d’informations

4 = Problème réseau

5 = Accès interdit

S1[0-15] Somme de contrôle. (Voir la description d’en-tête d’agent de service.)

S2[0-15] Identifiant de message. Ce champ est alloué par l’hôte pour identifier de façon univoque les demandes en cours (Identifiant de demande). Cet ID est copié dans le message Réponse d’informations par l’agent de service.

S3[0-7] Nombre d’entrées incluses dans le message Réponse d’informations.

S3[8-15] Nombre de mots de 16 bits par entrée.

S4-SN Zéro, une ou plusieurs instances de la structure des informations de flux ou des informations de groupe.

Figure 33 : Informations de flux

Figure 34 : Informations de groupe

7. Surveillance de la liaison d’accès de l’hôte

Lorsque la liaison d’accès fonctionne, les statistiques sur la charge de trafic et le taux d’erreurs sont entretenues par l’hôte et le WPS. Une fois par seconde, l’hôte et le WPS échangent ces informations via les messages d’état (Figure 35). Cet échange périodique de messages d’état permet aux deux extrémités de la liaison de surveiller les flux dans les deux directions. Le WPS fait aussi rapport de ces statistiques de surveillance au centre des opérations du réseau (NOC, Network Operations Center). Si l’hôte ou le WPS échoue à recevoir des messages d’état pendant dix secondes, la liaison sera redémarrée (voir au paragraphe 8).

La procédure de redémarrage de liaison initialise tous les comptes et statistiques internes du WPS pour cette liaison à zéro. Lors du traitement des messages de données et de contrôle, les comptes sont mis à jour pour refléter le nombre total de messages envoyés, de messages reçus correctement, et de messages reçus avec différentes classes d’erreurs depuis le dernier redémarrage de la liaison. Chaque fois qu’arrive un message d’état, une photographie des comptes du WPS local est prise. Les compte de réception local, en conjonction avec un compte d’envoi contenu dans le message d’état reçu, permet le calcul des statistiques de trafic dans l’intervalle d’une seconde de la mise à jour, en supposant que l’ensemble des compte au moment du précédent rapport de surveillance a été sauvegardé. En incluant dans le message d’état envoyé (dans la direction opposée) le compte de réception et le compte d’envoi reçu qui a été utilisé avec eux, l’extrémité émettrice de la liaison d’accès ainsi que l’extrémité réceptrice peuvent déterminer les performances de la liaison de l’envoyeur au receveur.

Figure 35 : Message d’état

0[0] Classe de message = 1 (Message de contrôle).

0[1] Indicateur de bouclage.

0[2-3] Priorité de passage.

0[4-11] Réservé. Doit être à zéro.

0[12-15] Type de message de contrôle = 0 (État).

1[0-15] Somme de contrôle d’en-tête. La somme de contrôle est le complément à 2 de la somme des compléments à 2 des mots 0 à 10 (à l’exclusion du mot de somme de contrôle lui-même).

2[0-15] Plus récent A/R envoyé. Ce champ est un duplicata du plus récent mot d’acceptation/refus. Il est inclus dans le message d’état périodique en cas de perte des précédentes transmissions contenant les informations d’A/R.

3[0-15] Capacité du flux. Lorsqu’il est envoyé par le WPS, ce champ indique quelle capacité de flux est inutilisée, en unités de bits de données par milliseconde. Il n’est pas garanti qu’une demande pour un flux de cette taille réussisse. Comme la capacité disponible dépend directement de divers paramètres qui peuvent être choisis par l’utilisateur, la valeur de ce champ est la capacité maximum qui pourrait être atteinte si les flux existants étaient développées à fiabilité faible. Ce champ n’est pas significatif dans les messages envoyés de l’hôte au WPS et doivent être réglés à zéro.

4[0-15] Horodatage. Ce champ indique l’heure à laquelle le message d’état a été généré. Lorsqu’il est envoyé par un WPS, l’heure est en unités de secondes depuis le dernier redémarrage de la liaison. L’hôte devrait aussi horodater ses messages en unités de secondes.

5[0-15] Sent By Us (envoyés par nous). Compte des messages envoyés par nous depuis le dernier redémarrage de la liaison (celui-ci non inclus).

6[0-15] Sent To Us (envoyés à nous). Compte des messages qui nous ont été envoyés depuis le dernier redémarrage de la liaison. C’est le compte depuis le mot 5 du dernier message d’état reçu.

7[0-15] Reçus, sans erreur. C’est le compte des messages reçus sans erreur (depuis le dernier redémarrage de la liaison) au moment de la réception du dernier message d’état.

8[0-15] Reçus avec erreurs. C’est le compte des messages reçus avec des erreurs (depuis le dernier redémarrage de la liaison) au moment de la réception du dernier message d’état.

9[0-15] Mauvaise somme de contrôle d’en-tête. C’est le compte des messages reçus avec une mauvaise somme de contrôle d’en-tête (depuis le dernier redémarrage de la liaison) au moment de la réception du dernier message d’état.

10[0-15] Indication d’erreur du matériel. C’est le compte des messages reçus avec une indication d’erreur de CRC du matériel ou d’erreur d’interface matérielle (depuis le dernier redémarrage de la liaison) au moment de la réception du dernier message d’état.

8. Initialisation

Le protocole d’accès aux hôtes utilise un certain nombre de variables d’état qui doivent être initialisées pour un fonctionnement approprié. Ces variables sont associées aux numéros de messages envoyés et reçus utilisés par le mécanisme d’acceptation/refus et les statistiques entretenus pour la prise en charge de la surveillance de la liaison. L’initialisation de la liaison devrait être effectuée lorsqu’une machine est initialement mise sous tension, lorsqu’elle effectue un redémarrage système, lorsque l’état ON (voir ci-dessous) arrive en fin de temporisation, lorsqu’une condition de bouclage arrive en fin de temporisation (voir au paragraphe 9), ou chaque fois que la liaison passe d’un état de non-fonctionnement à un état de fonctionnement.

L’initialisation est accomplie par l’échange des messages Demande de redémarrage (RR, Restart Request) et Redémarrage achevé (RC, Restart Complete) entre un hôte et un WPS. L’une ou l’autre (ou les deux) extrémité peut envoyer un RR initial,et les deux extrémités doivent avoir envoyé et reçu un message RC afin de déclarer la liaison établie. Parce que le message RC est une réponse (à un RR ou un RC), la réception d’un message RC par les deux extrémités garantit que la liaison physique fonctionne dans les deux directions. Le diagramme d’état d’initialisation qui doit être mis en œuvre par le WPS et l’hôte est montré à la Figure 36. Cinq états sont identifiés dans le diagramme d’état :

OFF On y entre à la reconnaissance d’une exigence de redémarrage. L’interface de l’hôte ou du WPS peut reconnaître cette exigence elle-même ou être forcée au redémarrage à réception d’un message RR provenant de l’autre extrémité alors qu’elle est dans l’état ON.

INIT Les variables d’état locales ont été initialisée mais aucun message RC n’a encore été envoyé ou reçu. Si la réception d’un RR a initialisé le redémarrage, ou si un RR a été reçu depuis le début du redémarrage, envoyer un RC (facultatif, il réduit le temps de redémarrage). Autrement, envoyer un RR pour alerter l’autre extrémité du redémarrage.

RR-SNT Un demande de réinitialisation (RR) a été envoyée à l’autre extrémité, mais aucun message RR ou RC n’a été reçu.

RC-SNT Un RC a été envoyé à l’autre extrémité en réponse à un RR. L’interface attend de recevoir un RC.

ON Des messages RC ont été envoyés et reçus. Les compteurs locaux ont été mis à zéro. Les messages de données et de contrôle peuvent maintenant être échangés entre le WPS et l’hôte.

Tous les états ont une temporisation de 10 secondes (non illustrée) qui retourne le protocole à l’état OFF. L’occurrence de tout événement autre que ceux indiqués dans le diagramme est ignorée.

Figure 36 : Diagramme d’état de redémarrage de liaison HAP

Le message de contrôle Demande de redémarrage (Figure 37) est envoyé par un hôte ou un WPS lorsqu’il souhaite redémarrer une liaison. La Demande de redémarrage cause la remise à zéro de toutes les statistiques de surveillance rapportées dans le message d’état et l’arrêt de tout trafic sur la liaison dans les deux directions. Le message Redémarrage achevé (Figure 38) est envoyé en réponse à la réception d’une Demande de redémarrage ou d’un Redémarrage achevé pour terminer l’initialisation de la liaison. Redémarrage achevé porte un champ utilisé par l’hôte pour activer ou désactiver le mécanisme d’acceptation/refus pour la ligne qu’on redémarre (voir la Section 5). Après le traitement du Redémarrage achevé, le trafic peut s’écouler sur la liaison.

L’allocation et l’état des ressources réseau (flux et groupes) sont séparés de l’état de la ou des liaisons d’accès de l’hôte au WPS. Le message Demande d’informations (voir au paragraphe 6.5) peut être utilisé par un hôte pour déterminer les ressources dont il dispose. Si le bit "SL" est mis dans le message Redémarrage achevé provenant du WPS, et si l’hôte pense que des ressources lui sont allouées, l’hôte est vivement encouragé à utiliser une Demande d’informations pour vérifier qu’il dispose toujours de ces ressources.

Figure 37 : Demande de redémarrage

0[0] Type de message = 1 (Message de contrôle).
0[1] Indicateur de bouclage.
0[2-4] Réservé. Doit être à zéro.
0[5-7] Numéro de version HAP. Utiliser 1. Le zéro invoque le code de rétro compatibilité (voir l’Appendice B).
0[8-11] Réservé. Doit être à zéro.
0[12-15] Type de message de contrôle = 3 (Demande de redémarrage).
1[0-15] Somme de contrôle d’en-tête. La somme de contrôle est le complément à 2 de la somme des compléments à 2 des mots 0 à 3 (à l’exclusion du mot de somme de contrôle lui-même).
2[0-15] Adresse de l’hôte. Le WPS insère l’adresse principale de réseau de l’hôte. L’hôte peut insérer une de ses adresses réseau dans ce champ (les hôtes peuvent avoir plus d’une adresse logique par accès physique). Le WPS n’établira la liaison HAP que si l’adresse de l’hôte est valide pour l’accès utilisé.
3[0-15] Numéro de liaison. Ce champ contient l'identification de l’envoyeur de la liaison physique utilisée. Ces informations sont utilisées pour identifier la liaison lors de rapports d’erreurs au centre des opérations du réseau (NOC).

Figure 38 : Redémarrage achevé

0[0] Type de message = 1 (Message de contrôle).
0[1 Indicateur de bouclage.
0[2-4] Réservé. Doit être à zéro.
0[5-7] Numéro de version HAP. Utiliser 1. Le zéro invoque le code de rétro compatibilité (voir l’Appendice B).
0[8-9] Réservé. Doit être à zéro.
0[10] Alerte de perte de service (booléen) (seulement du WPS à l’hôte ; l’hôte doit envoyer zéro). Si le WPS a des raisons de croire que les ressources allouées à l’hôte pourraient ne pas correspondre à ce que l’hôte croit lui être alloué, SL est mis à un.
Si SL est à un, un hôte qui croit qu’il a des ressources est vivement encouragé à utiliser une Demande d’informations pour vérifier que les ressources lui sont toujours allouées. SL sera à un la première fois qu’une liaison est activée après le redémarrage d’un WPS, et peut être mis à un dans d’autres cas.
0[11] Contrôle d’acceptation/refus. Ce bit est utilisé par l’hôte pour activer ou désactiver le mécanisme d’acceptation/refus pour tout le trafic de la liaison.

0 = Désactiver l’acceptation/refus
1 = Activer l’acceptation/refus

0[12-15] Type de message de contrôle= 4 (Redémarrage achevé).
1[0-15] Somme de contrôle d’en-tête. Couvre les mots 0 à 3.
2[0-15] Adresse de l’hôte.
3[0-15] Numéro de liaison.

9. Contrôle de bouclage

Le protocole d’accès à un hôte fournit un message de contrôle Demande de bouclage (Loopback Request) qui peut être utilisé par un WPS ou un hôte pour demander le bouclage à distance de ses messages HAP. De telles demandes sont généralement le résultat d’une intervention de l’opérateur pour les besoins du diagnostic des fautes du système. Pour la clarté de l’exposé qui suit, l’unité (WPS ou hôte) qui demande le bouclage à distance est appelée "émetteur" et l’unité qui met en œuvre (ou rejette) le bouclage est appelée "receveur".

Lorsque la liaison d’accès de l’hôte est mise en boucle à distance, tous les messages HAP seront retournés, non modifiés, sur la liaison d’accès par le receveur. (Les messages qui sont trop longs pour être des messages HAP valides peuvent être éliminés plutôt que retournés.) Le receveur n’enverra aucun de ses propres messages à l’émetteur pendant qu’il met en œuvre la boucle. Les messages générés par le WPS sont distingués des messages générés par l’hôte au moyen de l’indicateur de bouclage qui est dans tout en-tête de message HAP.

Deux types de bouclage à distance peuvent être demandés : le bouclage au matériel d’interface du receveur et le bouclage au logiciel d’entrée/sortie du receveur. HAP ne spécifie pas la façon dont le receveur devrait mettre en œuvre ces boucles ; de plus, certains receveurs peuvent utiliser des matériels d’interface qui sont incapables de faire le bouclage des messages de l’émetteur , ne permettant au receveur de fournir que des boucles logiques. Un receveur peut n’être pas capable d’interpréter les messages de l’émetteur alors qu’il les renvoie en boucle. Cependant, si une telle interprétation est possible, le receveur n’agira sur aucun message de l’émetteur autre que les messages de contrôle de demande de réinitialisation de la liaison WPS-hôte (Demande de redémarrage, RR) ; voir la Section 8.)

Lorsqu’un receveur génère une condition de bouclage en réponse à une demande de bouclage, il fait une promesse implicite de maintenir la condition pour la durée spécifiée dans le message Demande de bouclage. Cependant, si une condition imprévue telle qu’un redémarrage système survient chez l’émetteur ou le receveur, l’unité affectée essayera de réinitialiser la liaison WPS-hôte en envoyant un message RR à l’autre unité. Si le message RR est reconnu par l’autre unité, une séquence d’initialisation de liaison peut être achevée. Cela va restaurer la liaison dans une condition de non bouclage même si la durée de boucle spécifiée n’est pas encore arrivée à expiration. Si un receveur ne peut interpréter les messages RR de l’émetteur, et en l’absence d’une intervention de l’opérateur chez le receveur, la boucle restera en place pour sa durée.

HAP ne spécifie pas les caractéristiques de conditions de bouclage qui pourraient être mises en œuvre localement par une unité donnée. Un exemple d’une telle condition serait celle obtenue lorsqu’un WPS commande à son interface d’hôte de renvoyer en boucle ses propres messages. Si de telles conditions de boucle locales causent aussi la réflexion des messages reçus de l’unité distante, l’unité distante va détecter la condition via l’en-tête HAP Indicateur de bouclage.

Une séquence spécifique doit être suivie pour l’établissement d’un bouclage à distance. Elle commence après l’initialisation de la liaison HAP et la prise de décision de faire une demande de bouclage à distance. L’émetteur envoie alors un message Demande de bouclage (Figure 39) au receveur et attend (1) l’expiration d’une temporisation de 10 s, ou (2) un message de réponse non numéroté "La boucle ne peut être mise en œuvre" provenant du receveur, ou (3) un de ses propres messages reflété. Si l’événement (1) ou (2) survient, la demande a échoué et l’émetteur peut, à son choix, réessayer un nouveau message Demande de bouclage. Si l’événement (3) survient, la condition de boucle à distance a été établie. Tout en attendant un de ces événements, les messages provenant du receveur sont traités normalement. Noter que les messages RR qui arrivent du receveur durant ce temps vont mettre un terme à la demande de bouclage.

Lorsqu’un receveur obtient un message Demande de bouclage, il met en œuvre la boucle demandée pour la durée demandée, ou retourne une réponse "La boucle ne peut être mise en œuvre" sans changer l’état de la liaison. Cette dernière réponse serait retournée, par exemple, si un receveur est incapable de mettre en œuvre un bouclage matériel demandé. Un receveur devrait prendre l’initiative d’une réinitialisation de la liaison avec un ou des messages RR chaque fois qu’une condition de bouclage arrive en fin de temporisation.

Une asymétrie est exigée dans la séquence ci-dessus pour résoudre le cas (peu probable) où le WPS et l’hôte demandent tous deux en même temps la mise en boucle. Si un WPS reçoit d’un hôte un message Demande de bouclage alors qu’il est lui-même en attente d’un événement de type (1) à (3), il va retourner à l’hôte une réponse "La boucle ne peut être mise en œuvre" et va continuer d’attendre. Cependant, un hôte dans la situation inverse va interrompre la demande de bouclage et agira sur la demande de boucle du WPS.

Figure 39 : Demande de bouclage

0[0] Type de message = 1 (Message de commande).
0[1] Indicateur de bouclage.
0[2-3] Priorité de passage.
0[4-7] Réservé. Doit être à zéro.
0[8-11] Type de boucle. Ce champ indique le type de boucle demandé comme suit :

0 = Indéfini
1 = Boucle à l’interface (boucle matérielle)
2 = Boucle au pilote (boucle logicielle)
3-15 = Indéfini

0[12-15] Type de message de contrôle= 8 (Demande de bouclage)
1[0-15] Somme de contrôle d’en-tête. La somme de contrôle est le complément à 2 de la somme des compléments à 2 des mots 0 à 2 (à l’exclusion du mot de somme de contrôle lui-même).
2[0-15] Durée de boucle. L’émetteur du message Demande de bouclage utilise ce champ pour spécifier le nombre de secondes pendant lequel la boucle doit être maintenue par le receveur.

10. Autres messages de commande

Avant qu’un WPS ou un hôte désactive volontairement une liaison WPS-hôte, il devrait envoyer au moins un message de contrôle Liaison en cours de fermeture (Figure 40) sur cette liaison. HAP ne définit pas la ou les actions qui devraient être entreprises par un WPS ou un hôte lorsqu’un tel message est reçu ; informer le centre des opérations du réseau (NOC) et/ou les utilisateurs du réseau de l’évènement qui va se produire est une de ces actions normales. Noter que chaque message Liaison en cours de fermeture n’appartient qu’à la liaison WPS-hôte sur laquelle il est envoyé ; si un hôte et un WPS sont connectés par plusieurs liaisons, ces liaison peuvent être désactivées de façon sélective.

Un message de contrôle Pas d’opération (NOP, No Operation) (Figure 41) peut être envoyé à tout moment par un WPS ou un hôte. Un message NOP contient jusqu’à 32 mots de données arbitraires qui sont indéfinies pour HAP. Les messages NOP peuvent être exigés dans certains cas pour libérer l’état du matériel de la liaison WPS-hôte.

Figure 40 : Liaison en cours de fermeture

0[0] Type de message = 1 (Message de contrôle).
0[1] Indicateur de bouclage.
0[2-3] Priorité de passage.
0[4-7] Réservé. Doit être à zéro.
0[8-11] Raison. Ce champ est utilisé par le WPS ou l’hôte pour indiquer comme suit la raison de la désactivation de cette liaison WPS-hôte :

0 = Annuler la notification précédente, ne va pas fermer
1 = Raison non spécifiée
2 = Gestion des performance planifiée
3 = Entretien matériel planifié
4 = Entretien logiciel planifié
5 = Redémarrage d’urgence
6 = Coupure de courant
7 = Coupure logicielle
8 = Défaillance du matériel
9 = Non planifiée
10 = Dernier avertissement : Le WPS ou l’hôte désactivera la liaison dans 10 secondes
11-15 = Indéfini

0[12-15] Type de message de contrôle = 7 (Liaison en cours de fermeture).
1[0-15] Somme de contrôle d’en-tête. La somme de contrôle est le complément à 2 de la somme des compléments à 2 des mots 0 à 3 (à l’exclusion du mot de somme de contrôle lui-même).
2[0-15] Temps restant avant désactivation. Ce champ spécifie la durée restante avant que le WPS ou l’hôte désactive la liaison (en minutes). Une entrée de zéro indique qu’il reste moins d’une minute.
3[0-15] Durée de désactivation. Ce champ spécifie la durée pendant laquelle la liaison WPS-hôte sera désactivée (en minutes). Une entrée de zéro indique que la durée de désactivation sera de moins d’une minute. Une entrée de -1 (tous les bits mis à 1) indique une durée de désactivation indéfinie.

Figure 41 : NO OPERATION (NOP)

0[0] Type de message = 1 (Control Message).
0[1] Indicateur de bouclage.
0[2-6] Réservé. Doit être à zéro.
0[7-11] Longueur. Nombre de mots de données arbitraires.
0[12-15] Type de message de contrôle = 6 (NOP).
1[0-15] Somme de contrôle d’en-tête. La somme de contrôle est le complément à 2 de la somme des compléments à 2 des mots 0 à N (à l’exclusion du mot de somme de contrôle lui-même).
2-N Données arbitraires. On peut envoyer jusqu’à 32 mots de données. Les données ne sont pas définies par HAP.

11. Appendice A – Extensions futures

Les extensions à HAP décrites ci-dessous sont incluses pour élargir le contexte de la compréhension des capacités actuelles de HAP, ainsi que pour suggérer comment HAP pourra être amélioré à l’avenir pour fournir une meilleure prise en charge des conférences multi-sites. Ces capacités ne sont pas prises en charge par TWBNET.

Une modification à prendre en considération est l’addition d’une ressource de "conférence", qui possèderait un certain nombre de flux et de groupes et améliorerait la capacité du réseau à satisfaire les besoins des utilisateurs de conférences. Une seule demande de modification de la "conférence", comme l’ajout d’un nouveau membre, résulterait en la modification de tous les flux dans la conférence pour inclure le nouveau membre, en la modification de l’adresse de groupe principale de la conférence pour ajouter le nouveau membre, etc., en une seule opération du réseau. Non seulement une telle capacité simplifierait la gestion des ressources de la conférence pour les hôtes, mais réduirait aussi le nombre des opérations d’établissement du réseau, permettrait plus de décisions presque "atomiques" sur la question de savoir si une modification de conférence particulière est possible, et réduirait le problème de la récupération si la modification n’est pas possible.

Un autre changement à prendre en considération est l’addition de flux "partagés". Cette capacité permettrait aux hôtes de partager une seule allocation de bande passante du réseau (et d’autres ressources) partout où les flux partagent un chemin de communication commun. Les hôtes qui utilisent un flux partagé doivent vouloir restreindre leur débit total de transmission au débit de la bande passante partagée. Les conférences multi-site pourraient utiliser une telle capacité pour éviter d’allouer toute la bande passante pour les données vocales de tous les membres de la conférence. Au lieu de cela, la bande passante pour, disons, quatre voix actives à la fois, pourrait être allouée et partagée, et les messages vocaux ne seraient perdus que lorsque plus de quatre personnes essayent de parler à la fois.

La demande Créer un flux partagé utiliserait un code de demande différent de celui de la demande Créer un flux, et le message d’établissement contiendrait vraisemblablement au moins un champ supplémentaire pour identifier l’ensemble de flux partagés. Les demandes Changement de flux et Suppression de flux pourraient être utilisée à la fois pour les flux partagés et non partagés.

12. Appendice B -- Rétro compatibilité

Le WPS va prendre en charge l’utilisation par les hôtes de HAP version 0 jusqu’à ce que les hôtes aient adopté la version 1. Le WPS détermine quelle version de HAP utilise l’hôte en examinant les messages de contrôle Demande de redémarrage et/ou Redémarrage achevé envoyés par l’hôte au WPS. Si l’hôte initie un redémarrage et envoie alors à la fois une Demande de redémarrage et un Redémarrage achevé, et si les numéros de version HAP dans les deux messages diffèrent, le numéro de version dans le Redémarrage achevé prévaudra. Le WPS établira toujours le numéro de version à 1. Si l’hôte envoie 0 dans le champ numéro de version, le mode de compatibilité de la version 0 sera invoqué.

La version 0 de HAP ne contenait pas le champ Identifiant de protocole dans les en-têtes de message de datagramme et de flux. À la place était utilisé le bit IL dans le mot de type de service pour indiquer la présence ou l’absence d’un en-tête de protocole Internet (IP) (tout numéro de version) à la suite de l’en-tête HAP. Voici la description d’origine de ce bit :

3[1] Fanion Internet/Local. Ce fanion est établi par un hôte de source pour spécifier à un hôte de destination si la portion données du message contient un en-tête de protocole Internet (IP) [3]. Ce champ est passé de façon transparente par les WPS de source et de destination pour le trafic entre les hôtes du réseau. Ce champ est examiné par les agents de WPS afin de prendre en charge le fonctionnement Internet.

0 = Internet

1 = Local

Algorithmes de conversion

Les messages de contrôle de liaison (par exemple, Demande de redémarrage) n’exigent pas de conversion. Les messages de datagramme et de flux envoyés par ou à un hôte qui a HAP version 0 seront convertis par le WPS. C’est probablement à cause de la conversion de message que le débit maximum des hôtes qui utilisent HAP version 0 sera quelque peu inférieur à celui des hôtes qui utilisent HAP version 1.

HAP version 0 utilisait le bit IL dans le mot HAP Type de service pour indiquer la présence ou l’absence d’un en-tête IP. La version 1 utilise le champ Identifiant de protocole. Pour convertir les messages d’hôte à WPS, le bit IL sera éliminé, et le champ Identifiant de protocole sera inséré, avec la valeur indiquée :

Pour convertir les messages de WPS à hôte, le champ Identifiant de protocole sera supprimé, et le bit IL sera établi par :

IL = (protocol_id était HAP_PROTO_IP) ? 0 : 1;

HAP_PROTO_IP (voir l’Appendice C) sera utilisé pour IP "versions" 3 (protocole GG), 4 (IP), et 5 (ST).

Les champs d’en-tête de message de datagramme TTL et PRI ont été intervertis dans HAP version 0 par rapport à la version 1. Le code de conversion échange les contenus de ces deux champs pour les hôtes qui ont la version 0.

Le champ d’en-tête de message de flux TTL dans HAP version 0 a été remplacé par le champ PRE dans la version 1. Comme la seule valeur permise dans TTL était 1, et que c’est une valeur valide de PRE, aucune conversion n’est nécessaire.

Dans HAP version 0, les messages entre un hôte et l’agent de service pouvaient contenir des en-têtes de protocole Internet. Aucun hôte n’utilise cette capacité, aussi aucune disposition ne sera prise pour accommoder les en-têtes IP dans les Établissement entre les hôtes et l’agent de service.

Dans la version 0, le message de contrôle Demande de redémarrage contenait un champ "raison du redémarrage". Ce champ était ignoré dans toutes les mises en œuvre en cours et il a été éliminé dans la version 1.

Les mises en œuvre en cours s’attendent à ce que le WPS insère un "compte d’incarnation" dans les bits 5 à 10 du premier mot des messages Demande de redémarrage et Redémarrage achevé. Cette fonctionnalité a été remplacée par le bit "SL" dans le message Redémarrage achevé de la version 1. Le code de compatibilité sera ajouté si nécessaire, mais on s’attend à ce que personne n’en ait besoin.

13. Appendice C – Numéros alloués aux identifiants de protocole HAP

La présente section énumère les valeurs du champ Identifiant de protocole. Cette partie de la spécification sera obsolète quand sera publiée une version de la RFC Numéros alloués contenant les numéros d’identifiants de protocole HAP.

HAP adopte les numéros Ether-type dans la gamme 1500-65535. Les identifiants de protocole 256 à 511 identifient les protocoles ISO. Zéro indique l’absence d’en-tête de protocole de niveau supérieur. Les autres identifiants de protocole sont réservé pour une allocation ultérieure.

Figure 42 : Numéros d’identifiant du protocole HAP

Références

1. G. Falk, S. Groff, R. Koolish et W. Milliken, "PSAT Technical Report", Rapport technique BBN n° 4469, Chapitre 4, mai 1981.

2. Rees, T., éditeur, "A Host Access Protocol Specification", BBN Laboratories, Inc., May 1987. (Révision de la RFC 907 qui a été distribuée à la communauté des utilisateurs DARPA et WBNET mais non resoumise comme RFC.)

3. J. Postel, éditeur, "Protocole Internet – Spécification du protocole du programme DARPA Internet", RFC 791, USC/Information Sciences Institute, septembre 1981.

4. C. Topolcic, éditeur, "Protocole expérimental de flux Internet, version 2 (ST-II)", RFC 1190, Bolt Beranek and Newman, Inc., octobre 1990.

5. W. Edmond, K. Seo, M. Leib et C. Topolcic, "The DARPA Wideband Network Dual Bus Protocol", Proceedings of ACM SIGCOMM '90, pages 79-89, 24-27 septembre 1990.

6. "Host/SATNET Protocol", Internet Engineering Note (IEN) 192, juillet 1981.

7. L. Evenchik, D. McNeill, R. Bressler, A. Owen, R. Rice jr., G. Trout, C. Pavey, D. Damer, F. Deckelman et T. Hughes, "MATNET, An Experimental Navy Shipboard Satellite Communications Network", Proceedings of INFOCOM '82, pages 3-11, 30 mars – 1 er avril 1982.

8. G. Falk, J. Groff, W. Milliken, M. Nodine, S. Blumenthal et W. Edmond, "Integration of Voice and Data in the Wideband Packet Satellite Network", IEEE Journal on Selected Areas in Communications, Vol. SAC-1, n° 6, décembre 1983.

9. "Interface Message Processor: Specifications for the Interconnection of a Host and an IMP", Raport technique BBN n° 1822, octobre 1980.

10. J. Reynolds et J. Postel, "Numéros alloués", RFC 1060, USC/Information Sciences Institute, mars 1990. (Rendue obsolète par la RFC 3232, les numéros alloués sont accessibles à www.iana.org).

Considérations pour la sécurité

Les questions de sécurité ne sont pas abordées dans le présent document.

Adresse de l’auteur

Winston Edmond
Bolt Beranek and Newman, Inc.
Network Technologies Department
10 Moulton Street
Cambridge, Massachusetts 02138
Téléphone : (617) 873-3000
mél : wbe@bbn.com