RFC 3259 - Un bus de messages pour la coordination locale

From RFC.Wiki
Jump to: navigation, search

Groupe de travail du réseau

Demande de commentaires: 3259

Catégorie: Information

J. Ott TZI, Universitaet Bremen C. Perkins USC Information Sciences Institute D. Kutscher TZI, Universitaet Bremen Avril 2002

RFC 3259 - Un bus de messages pour la coordination locale

Statut de ce mémo 
Ce mémo fournit des informations à la communauté Internet. Cela fait

ne spécifie aucune norme Internet d'aucune sorte. La distribution de ce mémo est illimitée.

Copyright
Copyright (C) L'Internet Society (2002). Tous les droits sont réservés.
Abstrait 
Le bus de messages local (Mbus) est un protocole de coordination orienté message léger pour la communication de groupe entre les composants d'application. Le Mbus fournit une localisation automatique des pairs de communication, un adressage basé sur le sujet, un transfert de messages fiable et différents types de schémas de communication. Le protocole est superposé à la multidiffusion IP et est spécifié pour IPv4 et IPv6. L'étendue de multidiffusion IP est limitée à la multidiffusion lien-local. Ce document spécifie le protocole Mbus, c'est-à-dire la syntaxe des messages, les mécanismes d'adressage et de transport.


Contents


1. Introduction

La mise en œuvre de systèmes de conférence multimédia multipartite est un exemple où une infrastructure de coordination simple peut être utile: dans une variété de scénarios de conférence, un canal de communication local peut fournir un échange d'informations liées à la conférence entre des entités d'application co-localisées mais par ailleurs indépendantes, par exemple celles participer à des sessions de candidature appartenant à la même conférence. Dans les conférences faiblement couplées, un tel mécanisme permet la coordination des entités d'application, par exemple, pour mettre en œuvre la synchronisation entre les flux multimédias ou pour configurer des entités sans interaction de l'utilisateur. Il peut également être utilisé pour implémenter des conférences étroitement couplées permettant à un contrôleur de conférence d'appliquer un contrôle à l'échelle de la conférence dans un système d'extrémité.

Les systèmes de conférence tels que les téléphones IP peuvent également être considérés comme des composants d'un système distribué et peuvent ainsi être intégrés dans un groupe de modules d'application: par exemple, un appel de téléphonie IP effectué avec un téléphone IP autonome peut être étendu de manière dynamique à inclure des moteurs de médias pour d'autres types de médias en utilisant la fonction de coordination d'un mécanisme de coordination approprié. Différents composants de conférence individuels peuvent ainsi être combinés pour construire un système de conférence multimédia cohérent pour un utilisateur.

D'autres scénarios possibles incluent la coordination des composants d'application qui sont distribués sur différents hôtes dans un réseau, par exemple, ce que l'on appelle les appliances Internet.

1.1 Présentation du Mbus

La coordination locale des composants de l'application nécessite un certain nombre de modèles d'interaction différents: certains messages (tels que les informations sur les membres, les notifications de contrôle d'étage, la diffusion des changements d'état de la conférence, etc.) peuvent devoir être envoyés à toutes les entités d'application locales. Les messages peuvent également viser une certaine classe d'application (par exemple, tous les tableaux blancs ou tous les outils audio) ou un type d'agent (par exemple, toutes les interfaces utilisateur plutôt que tous les moteurs de médias). Ou il peut y avoir n'importe quel sous-groupe (spécifique à l'application ou au message) définissant les destinataires prévus, par exemple, des messages liés à la synchronisation des médias. Enfin, il peut y avoir des messages qui sont dirigés vers une seule entité: par exemple, des paramètres de configuration spécifiques qu'un contrôleur de conférence envoie à une entité d'application particulière, ou des échanges de requête-réponse entre tout serveur local et ses clients.

Le protocole Mbus tel que défini ici satisfait ces différents besoins de communication en définissant différents mécanismes de transport de messages (définis au paragraphe 6) et en fournissant un schéma d'adressage flexible (défini au paragraphe 4).

En outre, les messages Mbus échangés entre les entités d'application peuvent avoir des exigences de fiabilité différentes (qui sont généralement dérivées de leur sémantique). Certains messages auront un caractère plutôt transitoire véhiculant des informations d'état éphémère (qui sont rafraîchies / mises à jour périodiquement), telles que le niveau du compteur de volume d'une entité de récepteur audio à afficher par son agent d'interface utilisateur. Certains messages Mbus (tels que les requêtes de paramètres ou les requêtes adressées aux serveurs locaux) peuvent nécessiter une réponse du ou des homologues, fournissant ainsi un accusé de réception explicite au niveau sémantique au-dessus du Mbus. D'autres messages modifieront l'état de l'application ou de la conférence et il est donc essentiel qu'ils ne se perdent pas. Ce dernier type de message doit être délivré de manière fiable au destinataire, tandis que les messages du premier type ne nécessitent pas de mécanismes de fiabilité au niveau de la couche de transport Mbus. Pour les messages confirmés au niveau de la couche application, il est à la discrétion de l'application d'utiliser ou non un transport fiable en dessous.

Dans certains cas, les entités d'application voudront adapter le degré de fiabilité à leurs besoins, d'autres voudront s'appuyer sur le transport sous-jacent pour assurer la livraison des messages - et cela peut être différent pour chaque message Mbus. Le mécanisme de passage de message Mbus spécifié dans ce document offre un maximum de flexibilité en fournissant une transmission fiable obtenue grâce à des accusés de réception de la couche transport (dans le cas de communications point à point uniquement) ainsi qu'un passage de message non fiable (pour monodiffusion, multidiffusion locale et diffusion locale). Nous abordons ce sujet dans la section 4.

Enfin, les perturbations accidentelles ou malveillantes des communications Mbus par le biais de messages provenant d'applications d'autres utilisateurs doivent être évitées. Une réception accidentelle de messages Mbus d'autres utilisateurs peut se produire si deux utilisateurs partagent le même hôte pour utiliser les applications Mbus ou s'ils utilisent des applications Mbus qui sont réparties sur la même liaison réseau: dans les deux cas, l'adresse multicast Mbus utilisée et le port Le numéro peut être identique, ce qui entraîne la réception des messages Mbus de l'autre partie en plus de ceux de l'utilisateur. Des perturbations malveillantes peuvent se produire en raison de la multidiffusion d'applications (par exemple, à une portée globale) ou de la monodiffusion des messages Mbus. Pour éliminer la possibilité de traiter des messages Mbus indésirables, le protocole Mbus contient des résumés de messages pour l'authentification. En outre, le Mbus permet le cryptage pour assurer la confidentialité et permet ainsi d'utiliser le Mbus pour la distribution de clés locales et d'autres fonctions potentiellement sensibles à l'écoute clandestine. Ce document définit le cadre de configuration des applications Mbus en ce qui concerne les paramètres de sécurité dans la section 12.

1.2 Objectif de ce document

Trois composants constituent le bus de messages: les mécanismes de passage de messages de bas niveau, une syntaxe de commande et une hiérarchie de dénomination, et le schéma d'adressage.

Le but de ce document est de définir les mécanismes de protocole du mécanisme de passage de message Mbus de niveau inférieur qui est commun à toutes les implémentations Mbus. Cela comprend la spécification de

  • le format de message générique Mbus;
  • le concept d'adressage pour les entités d'application (notez que les schémas d'adressage concrets doivent être définis par des profils spécifiques à l'application);
  • les mécanismes de transport à utiliser pour acheminer des messages entre des entités d'application (colocalisées);
  • le concept de sécurité pour empêcher une utilisation abusive du bus de messages (comme prendre le contrôle de l'environnement de conférence d'un autre utilisateur);
  • les détails de la syntaxe du message Mbus; et
  • un ensemble de commandes obligatoires indépendantes de l'application qui sont utilisées pour amorcer des sessions Mbus.

1.3 Domaines d'application

Le protocole Mbus peut être déployé dans de nombreux domaines d'application différents, y compris mais sans s'y limiter:

Contrôle de conférence locale 
Dans la communauté Mbone, un modèle est apparu dans lequel un ensemble d'outils faiblement couplés est utilisé pour participer à une conférence. Un scénario typique est que les fonctionnalités audio, vidéo et d'espace de travail partagé sont fournies par trois outils distincts (bien que certains outils combinés existent). Cela correspond bien aux flux multimédias RTP [8] sous-jacents (ainsi qu'à d'autres), qui sont également transmis séparément. Compte tenu d'une telle architecture, il est utile de pouvoir effectuer une certaine coordination des différents outils multimédias. Par exemple, il peut être souhaitable de communiquer des informations de point de lecture entre des outils audio et vidéo, afin de mettre en œuvre la synchronisation labiale, d'arbitrer l'utilisation de ressources partagées (telles que des périphériques d'entrée), etc.
Un raffinement de cette architecture repose sur la présence d'un certain nombre de moteurs de médias qui exécutent des fonctions de protocole ainsi que la capture et la lecture de médias. De plus, il existe un (ou plusieurs) agents d'interface utilisateur (séparés) qui interagissent avec et contrôlent leur (s) moteur (s) multimédia. Une telle approche permet une flexibilité dans la conception et la mise en œuvre de l'interface utilisateur, mais nécessite évidemment certains moyens par lesquels les divers agents impliqués peuvent communiquer entre eux. Ceci est particulièrement souhaitable pour permettre une réponse cohérente aux actions liées à la conférence d'un utilisateur (comme rejoindre ou quitter une conférence).
Bien que la pratique actuelle dans la communauté Mbone consiste à travailler avec un modèle de contrôle de conférence faiblement couplé, des situations surviennent où cela n'est pas approprié et un protocole de contrôle de conférence à large zone plus étroitement couplé doit être utilisé. Dans de tels cas, il est hautement souhaitable de pouvoir réutiliser les outils existants (moteurs de médias) disponibles pour des conférences faiblement couplées et de les intégrer à un composant système mettant en œuvre le modèle de contrôle de conférence serré. Un moyen approprié pour réaliser cette intégration est un canal de communication qui permet à une entité de contrôle de conférence dédiée de contrôler "à distance" les moteurs multimédia en plus ou à la place de leurs interfaces utilisateur respectives.
Contrôle des groupes d'appareils dans un réseau

Un groupe d'appareils connectés à un réseau local, par exemple des appareils ménagers dans un réseau domestique, nécessite un mécanisme de coordination local. Minimiser la configuration manuelle et la possibilité de déployer la communication de groupe sera également utile dans ce domaine d'application.

1.4 Terminologie des spécifications des exigences

Dans ce document, les mots clés «DOIT», «NE DOIT PAS», «OBLIGATOIRE», «DOIT», «NE DOIT PAS», «DEVRAIT», «NE DEVRAIT PAS», «RECOMMANDÉ», «PEUT» et «OPTIONNEL» doivent être interprétés comme décrit dans la RFC 2119 [1] et indiquer les niveaux d'exigence pour les implémentations Mbus conformes.

2. Règles de syntaxe formelle communes

Cette section contient les définitions des éléments de syntaxe ABNF [13] communs qui sont référencés ultérieurement par d'autres définitions dans ce document:

  base64 = base64_terminal / 
                    (1 * (4base64_CHAR) [base64_terminal]) 

  base64_char = UPALPHA / LOALPHA / DIGIT / "+" / "/" 
                    ;; Sensible aux majuscules et minuscules

  base64_terminal = (2base64_char "==") / (3base64_char "=") 

  UPALPHA =% x41-5A ;; Majuscules: AZ

  LOALPHA =% x61-7A ;; Minuscule: az

  ALPHA =% x41-5A /% x61-7A; AZ / az

  CHAR =% x01-7E 
                     ; tout caractère US-ASCII 7 bits,
                      exclure NUL et supprimer 

  OCTET =% x00-FF 
                     ; 8 bits de données

  CR =% x0D 
                     ; retour chariot

  CRLF = CR LF 
                     ; Nouvelle ligne standard Internet

  CHIFFRE =% x30-39 
                     ; 0-9

  DQUOTE =% x22 
                     ; " (Double citation)

  HTAB =% x09 
                     ; onglet horizontal

  LF =% x0A 
                     ; saut de ligne

  LWSP = * (WSP / CRLF WSP) 
                     ; espace blanc linéaire (dernière nouvelle ligne)

  SP =% x20 
                     ; espace

  WSP = SP / HTAB 
                      ; espace blanc

Tiré de RFC 2234 [13] et RFC 2554 [14].

3. Format du message

Un message Mbus comprend un en-tête et un corps. L'en-tête est utilisé pour indiquer comment et où un message doit être livré et le corps fournit des informations et des commandes à l'entité de destination. Les informations suivantes sont incluses dans l'en-tête:

Un champ ProtocolID fixe identifie la version du protocole de bus de messages utilisé. Le protocole défini dans ce document est "mbus / 1.0" (sensible à la casse). Un numéro de séquence (SeqNum) est contenu dans chaque message. Le premier message envoyé par une source DEVRAIT mettre SeqNum à zéro, et il DOIT incrémenter de un pour chaque message envoyé par cette source. Un numéro de séquence unique est utilisé pour tous les messages provenant d'une source, quels que soient les destinataires prévus et le mode de fiabilité sélectionné. La plage de valeurs d'un numéro de séquence est (0,4294967295). Une implémentation DOIT réinitialiser son numéro de séquence à 0 après avoir atteint 4294967295. Les implémentations DOIVENT prendre en compte le fait que le SeqNum d'autres entités peut être bouclé. Les SeqNums sont des nombres décimaux en représentation ASCII. Le champ TimeStamp est également contenu dans chaque message et DEVRAIT contenir un nombre décimal représentant l'heure de la construction du message en millisecondes depuis 00:00:00, UTC, 1er janvier 1970. Un champ MessageType indique le type de message envoyé. La valeur "R" indique que le message doit être transmis de manière fiable et DOIT être acquitté par le destinataire, "U" indique un message non fiable qui NE DOIT PAS être acquitté. Le champ SrcAddr identifie l'expéditeur d'un message. Cela DOIT être une adresse complète, avec tous les éléments d'adresse spécifiés. Le schéma d'adressage est décrit dans la section 4. Le champ DestAddr identifie le (s) destinataire (s) prévu (s) du message. Ce champ PEUT être joker en omettant des éléments d'adresse et donc adresser n'importe quel nombre (y compris zéro) d'entités d'application. Le schéma d'adressage est décrit dans la section 4. Le champ AckList comprend une liste de SeqNums pour lesquels ce message est un accusé de réception. Voir la section 7 pour plus de détails. L'en-tête est suivi du corps du message qui contient zéro ou plusieurs commandes à livrer à l'entité de destination. La syntaxe d'un message complet est donnée dans la section 5.

Si plusieurs commandes sont contenues dans la même charge utile de message Mbus, elles DOIVENT être livrées à l'application Mbus dans la même séquence dans laquelle elles apparaissent dans la charge utile de message.

4. Adressage

Chaque entité du message a une adresse Mbus unique qui est utilisée pour identifier l'entité. Les adresses Mbus sont des séquences d'éléments d'adresse qui sont des paires point / valeur. La balise et la valeur sont séparées par deux-points et les paires balise / valeur sont séparées par des espaces, comme ceci:

  (tag: valeur tag: valeur ...) 

La définition formelle de la syntaxe ABNF pour les adresses Mbus et leurs éléments est la suivante:

  mbus_address = "(" * WSP * 1address_list * WSP ")" 
  address_list = élément_adresse 
                  / address_element 1 * liste_adresses WSP 

  adresse_element = étiquette_adresse ":" valeur_adresse 

  adresse_tag = 1 * 32 (ALPHA) 

  valeur_adresse = 1 * 64 (% x21-27 /% x2A-7E) 
                    ; tout caractère US-ASCII 7 bits
                    ; exclure les espaces blancs, supprimer,
                    ; caractères de contrôle, "(" et ")"

Notez que cette définition et d'autres définitions ABNF dans ce document utilisent les symboles non terminaux définis dans la section 2.

Une adresse_tag DOIT être unique dans une adresse Mbus, c'est-à-dire qu'elle NE DOIT apparaître qu'une seule fois.

Chaque entité a une séquence fixe d'éléments d'adresse constituant son adresse et DOIT traiter uniquement les messages envoyés à des adresses qui correspondent à tous les éléments ou qui consistent en un sous-ensemble de ses propres éléments d'adresse. L'ordre des éléments d'adresse dans une séquence d'adresses n'est pas pertinent. Deux éléments d'adresse correspondent si leurs balises et leurs valeurs sont équivalentes. L'équivalence pour les chaînes d'élément d'adresse et de valeur d'adresse signifie que chaque octet d'une chaîne a la même valeur que l'octet correspondant de la deuxième chaîne. Par exemple, une entité avec une adresse de:

(conf: support de test: module audio: application moteur: id de rat: 4711-1@192.168.1.1) traitera les messages envoyés à

(média: module audio: moteur) et

(module: moteur) mais doit ignorer les messages envoyés à

(conf: support de test: module audio: application moteur: id de rat: 123-4@192.168.1.1 foo: bar) et

(toto: bar) Un message qui doit être traité par toutes les entités nécessite un ensemble vide d'éléments d'adresse.

4.1 Éléments d'adresse obligatoires

Chaque entité Mbus DOIT fournir un élément d'adresse obligatoire qui lui permet d'identifier l'entité. La balise d'élément est "id" et la valeur DOIT être composée des composants suivants:

L'adresse IP de l'interface utilisée pour envoyer des messages au Mbus. Pour IPv4, il s'agit de l'adresse en notation décimale à points. Pour IPv6, la partie interface-ID de l'adresse lien-local du nœud dans la représentation textuelle comme spécifié dans la RFC 2373 [3] DOIT être utilisée. Dans cette spécification, cette partie est appelée "host-ID". Un identifiant ("entity-ID") qui est unique dans la portée d'un seul host-ID. L'entité comprend deux parties. Pour les systèmes où le concept d'un ID de processus est applicable, il est RECOMMANDÉ que cet identificateur soit composé en utilisant un ID de processus et un désambiguateur par processus pour différentes entités Mbus d'un processus. Si un ID de processus n'est pas disponible, cette partie de l'ID d'entité peut être choisie au hasard (il est recommandé de choisir au moins un nombre aléatoire de 32 bits). Les deux nombres sont représentés sous forme textuelle décimale et DOIVENT être séparés par un caractère «-» (ASCII x2d). Notez que l'ID d'entité ne peut pas être le numéro de port du point d'extrémité utilisé pour envoyer des messages au Mbus car les mises en œuvre PEUVENT utiliser le numéro de port Mbus commun pour envoyer et recevoir du groupe de multidiffusion (comme spécifié au paragraphe 6).

La définition complète de la syntaxe de l'identificateur d'entité est la suivante:

 id-element = "id:" valeur-id 
 id-value = id-entité "@" id-hôte 
 id-entité = 1 * 10DIGIT "-" 1 * 5DIGIT 
 host-id = (adresse IPv4 / adresse IPv6) 

Veuillez vous référer à [3] pour les productions d'adresse IPv4 et d'adresse IPv6.

Un exemple d'élément id:

 identifiant: 4711-99@192.168.1.1 

5. Syntaxe du message

5.1 Codage des messages

Tous les messages DOIVENT utiliser le codage de caractères UTF-8. Notez que l'US ASCII est un sous-ensemble de UTF-8 et ne nécessite aucun codage supplémentaire, et qu'un message codé avec UTF-8 ne contiendra pas zéro octet.

Chaque message PEUT être chiffré en utilisant un algorithme de clé secrète tel que défini dans la section 11.

5.2 En-tête de message

Les champs de l'en-tête sont séparés par des espaces blancs et suivis de CRLF. Le format de l'en-tête est le suivant:

msg_header = "mbus / 1.0" 1 * WSP SeqNum 1 * WSP TimeStamp 1 * WSP

            MessageType 1 * WSP SrcAddr 1 * WSP DestAddr 1 * WSP AckList 

Les champs d'en-tête sont expliqués dans le format du message (section 3). Voici les définitions de syntaxe ABNF pour les champs d'en-tête:

 SeqNum = 1 * 10DIGIT; plage numérique 0 - 2 ^ 32-1
 Horodatage = 1 * 13DIGIT 
 MessageType = "R" / "U" 
 ScrAddr = mbus_address 
 DestAddr = mbus_address 


 AckList = "(" * WSP * 1 (1 * DIGIT * (1 * WSP 1 * 10DIGIT)) * WSP ")" 
 Voir la section 4 pour une définition de "mbus_address". 

La définition de la syntaxe d'un message complet est la suivante:

 mbus_message = msg_header * 1 (CRLF msg_payload) 
 msg_payload = mbus_command * (CRLF mbus_command) 

La définition des règles de production pour une commande Mbus est donnée au paragraphe 5.3.

5.3 Syntaxe des commandes

L'en-tête est suivi de zéro, une ou plusieurs commandes à livrer aux entités Mbus indiquées par le champ DestAddr. Chaque commande se compose d'un nom de commande qui est suivi d'une liste de zéro ou de plusieurs paramètres et se termine par une nouvelle ligne.

 commande (paramètre paramètre ...) 

Syntaxiquement, le nom de la commande DOIT être un «symbole» tel que défini dans le tableau suivant. Les paramètres PEUVENT être n'importe quel type de données tiré du tableau suivant:

 val = Entier / Flottant / Chaîne / Liste / 
                   Symbole / Données 
 Entier = * 1 "-" 1 * DIGIT 
 Float = * 1 "-" 1 * DIGIT "." 1 * CHIFFRE
 Chaîne = DQUOTE * CHAR DQUOTE 
                   ; voir ci-dessous pour les caractères d'échappement
 Liste = "(" * WSP * 1 (val * (1 * WSP val)) * WSP ")" 
 Symbole = ALPHA * (ALPHA / DIGIT / "_" / "-" / 
                   ".") 
 Données = "<" * base64 ">" 

Les valeurs booléennes sont codées sous la forme d'un entier, la valeur zéro représentant false et la valeur non nulle représentant true.

Les paramètres de chaîne de la charge utile DOIVENT être placés entre guillemets doubles ("). Dans les chaînes, le caractère d'échappement est la barre oblique inverse (\) et les séquences d'échappement suivantes sont définies:

 + ---------------- + ----------- + 
 | Séquence d'échappement | Signification |
 + ---------------- + ----------- + 
 | \\ | \ |
 | \ "|" |
 | \ n | newline |
 + ---------------- + ----------- + 

Les paramètres de liste n'ont pas besoin d'être des listes homogènes, c'est-à-dire qu'ils peuvent contenir des paramètres de types différents.

Les données opaques sont représentées sous forme de chaînes de caractères codées en Base64 (voir RFC 1521 [7]) entourées de "<" et ">"

La définition de la syntaxe ABNF pour les commandes Mbus est la suivante:

 mbus_command = nom_commande arglist 
 command_name = Symbole 
 arglist = Liste 
 

Les noms de commande DEVRAIENT être construits de manière hiérarchique pour regrouper les commandes liées conceptuellement sous une hiérarchie commune. Le délimiteur entre les noms dans la hiérarchie DOIT être "." (point). Les profils d'application NE DOIVENT PAS définir des commandes commençant par "mbus.".

Le schéma d'adressage Mbus défini dans la section 4 permet de spécifier des adresses incomplètes en omettant certains éléments d'une liste d'éléments d'adresse, ce qui permet aux entités d'envoyer des commandes à un groupe d'entités Mbus. Par conséquent, tous les noms de commandes DEVRAIENT être sans ambiguïté d'une manière qu'il soit possible de les interpréter ou de les ignorer sans tenir compte de l'adresse du message.

Un ensemble de commandes au sein d'une certaine hiérarchie qui DOIT être compris par chaque entité est défini au paragraphe 9.

6. Transport

Tous les messages sont transmis sous forme de messages UDP, avec deux alternatives possibles:

1. Multidiffusion / diffusion locale Cette classe de transport DOIT être utilisée pour tous les messages qui ne sont pas envoyés à une adresse cible pleinement qualifiée. Il PEUT également être utilisé pour les messages envoyés à une adresse cible pleinement qualifiée. Il DOIT être fourni par des implémentations conformes. Voir la section 6.1 pour plus de détails. 2. Monodiffusion dirigée Cette classe de transport PEUT être utilisée pour les messages qui sont envoyés à une adresse de destination pleinement qualifiée. Il est OPTIONNEL et ne doit pas être fourni par des implémentations conformes. Une adresse cible pleinement qualifiée est une adresse Mbus d'une entité Mbus existante dans une session Mbus. Une implémentation peut identifier une adresse Mbus comme étant pleinement qualifiée en conservant une liste d'entités connues dans une session Mbus. Chaque entité connue possède sa propre adresse Mbus unique et pleinement qualifiée.

Les messages sont transmis dans des datagrammes UDP, une taille de message maximale de 64 Ko NE DOIT PAS être dépassée. Il est RECOMMANDÉ que les applications utilisant une étendue non locale d'hôte ne dépassent pas une taille de message du MTU de liaison.

Notez que «unicast», «multicast» et «broadcast» signifient respectivement IP Unicast, IP Multicast et IP Broadcast. Il est possible d'envoyer un message Mbus adressé à une seule entité à l'aide de la multidiffusion IP.

Cette spécification traite à la fois de Mbus sur UDP / IPv4 et de Mbus sur UDP / IPv6.

6.1 Multidiffusion / diffusion locale

En général, le Mbus utilise la multidiffusion avec une portée limitée pour le transport des messages. Deux étendues de multidiffusion Mbus différentes sont définies, chacune pouvant être configurée pour être utilisée avec une session Mbus:

1. local hôte

2. lien local

Les participants d'une session Mbus doivent connaître à l'avance l'adresse multicast - elle ne peut pas être négociée pendant la session car elle est déjà nécessaire pour la communication initiale entre les entités Mbus pendant la phase d'amorçage. Il ne peut pas non plus être alloué avant une session Mbus car il n'y aurait aucun mécanisme pour annoncer l'adresse allouée à toutes les entités Mbus potentielles. Par conséquent, l'adresse multicast doit être attribuée de manière statique. Ce document définit l'utilisation d'adresses attribuées statiquement et fournit également une spécification de la façon dont une session Mbus peut être configurée pour utiliser des adresses non standard et non attribuées (voir la section 12).

Les sections suivantes spécifient l'utilisation des adresses multicast pour IPv4 et IPv6.

6.1.1 Groupes multicast Mbus pour IPv4

Pour IPv4, une adresse multicast relative à la portée attribuée statiquement, telle que définie par la RFC 2365 [11], est utilisée. Le décalage de l'adresse relative de portée pour Mbus est 8 (MBUS, voir http://www.iana.org/assignments/multicast-addresses [19]).

Différentes portées sont définies par la RFC 2365 [11]. La portée locale IPv4 (239.255.0.0/16) est la portée minimale englobante pour la multidiffusion à portée administrative (telle que définie par la RFC 2365 [11]) et non plus divisible - son étendue exacte dépend du site.

Pour la portée locale IPv4, en appliquant les règles de la RFC 2365 [11] et en utilisant le décalage attribué de 8, l'adresse de multidiffusion Mbus est donc 239.255.255.247.

Pour IPv4, les différentes portées Mbus définies (hôte-local et lien-local) doivent être réalisées comme suit:

multidiffusion hôte-local Sauf configuration contraire, l'adresse Mbus relative à la portée attribuée dans la portée locale (239.255.255.247 à partir de la RFC 2365 [11]) DOIT être utilisée. Les datagrammes Mbus UDP DEVRAIENT être envoyés avec un TTL de 0. multidiffusion lien-local Sauf configuration contraire, l'adresse Mbus relative à la portée attribuée dans la portée locale (239.255.255.247 à partir de la RFC 2365 [11]) DOIT être utilisée. Les datagrammes Mbus UDP DEVRAIENT être envoyés avec un TTL de 1.

6.1.2 Groupes multicast Mbus pour IPv6

IPv6 a différentes plages d'adresses pour différentes portées de multidiffusion et distingue les portées de nœud local et de lien local, qui sont implémentées comme un ensemble de préfixes d'adresse pour les différentes plages d'adresses ( RFC 2373 [3]). Le préfixe lien-local est FF02, le préfixe local nœud est FF01. Une adresse multicast attribuée en permanence sera utilisée pour la communication multicast Mbus, c'est-à-dire une adresse indépendante de la valeur de portée et qui peut être utilisée pour toutes les portées. Les implémentations pour IPv6 DOIVENT utiliser l'adresse indépendante de la portée et le préfixe approprié pour la portée sélectionnée. Pour la communication Mbus hôte-local, le préfixe de portée IPv6 nœud-local DOIT être utilisé, pour la communication Mbus lien-local, le préfixe de portée lien-local IPv6 DOIT être utilisé.

L'adresse multicast IPv6 permanente pour Mbus / Ipv6 est FF0X: 0: 0: 0: 0: 0: 0: 300.

FF0X: 0: 0: 0: 0: 0: 0: 300 DEVRAIT être utilisé pour Mbus / IPv6 où le X dans FF0X indique que la portée n'est pas fixe car il s'agit d'une adresse à portée totale. Cela signifie que, pour la portée locale du nœud, FF01: 0: 0: 0: 0: 0: 0: 300 DEVRAIT être utilisé et pour la portée lien-local FF02: 0: 0: 0: 0: 0: 0: 300 DEVRAIT être utilisé. Voir RFC 2375 [4] pour les attributions d'adresses de multidiffusion IPv6.

Si un système d'application unique est distribué sur plusieurs hôtes colocalisés, la portée locale de liaison DEVRAIT être utilisée pour la multidiffusion de messages Mbus qui ont potentiellement des destinataires sur les autres hôtes. Le protocole Mbus n'est pas destiné (et donc délibérément pas conçu) pour la communication entre des hôtes qui ne sont pas sur la même liaison. Voir la section 12 pour les spécifications des mécanismes de configuration Mbus.

6.1.3 Utilisation de la diffusion

Dans les situations où la multidiffusion n'est pas disponible, la diffusion PEUT être utilisée à la place. Dans ces cas, une adresse de diffusion IP pour le réseau connecté DEVRAIT être utilisée pour l'envoi. L'adresse de diffusion locale du nœud pour IPv6 est FF01: 0: 0: 0: 0: 0: 0: 1, l'adresse de diffusion lien-local pour IPv6 est FF02: 0: 0: 0: 0: 0: 0: 1. Pour IPv4, l'adresse de diffusion générique (pour la diffusion lien-local) est 255.255.255.255. Il est RECOMMANDÉ que les implémentations IPv4 utilisent l'adresse de diffusion générique et un TTL de zéro pour la diffusion locale de l'hôte.

La diffusion NE DOIT PAS être utilisée dans des situations où la multidiffusion est disponible et prise en charge par tous les systèmes participant à une session Mbus.

Voir la section 12 pour configurer l'utilisation de la diffusion.

6.1.4 Numéro de port Mbus UDP

Le numéro de port Mbus UDP enregistré est 47000.

6.2 Monodiffusion dirigée

La monodiffusion dirigée (via UDP) vers le port d'une application spécifique est une classe de transport alternative à la multidiffusion. La monodiffusion dirigée est une optimisation OPTIONNELLE et PEUT être utilisée par les implémentations Mbus pour délivrer des messages adressés à une seule entité d'application uniquement - l'adresse dont l'implémentation Mbus a déjà appris d'autres échanges de messages. Notez que le champ DestAddr de ces messages DOIT néanmoins être rempli correctement. Chaque entité Mbus DEVRAIT utiliser une seule adresse d'extrémité unique pour envoyer des messages au groupe de multidiffusion Mbus ou à des entités de réception individuelles. Une adresse de point de terminaison unique est un tuple composé de l'adresse IP de l'entité et d'un numéro de port source UDP, où le numéro de port est différent du numéro de port Mbus standard.

Les messages DOIVENT être envoyés uniquement par monodiffusion si l'adresse cible Mbus est unique et si l'entité d'envoi peut vérifier que l'entité réceptrice utilise une adresse de point d'extrémité unique. Ce dernier peut être vérifié en considérant le dernier message reçu de cette entité.

Notez que plusieurs entités Mbus, par exemple au sein du même processus, peuvent partager une adresse de transport commune; dans ce cas, le contenu du champ d'adresse de destination est utilisé pour envoyer davantage le message. Compte tenu de la définition de «l'adresse de point d'extrémité unique» ci-dessus, l'utilisation d'une adresse de point d'extrémité partagée et d'un répartiteur permet toujours à d'autres entités Mbus d'envoyer des messages en monodiffusion à l'une des entités qui partagent l'adresse de point d'extrémité. Cela peut donc être considéré comme un détail de mise en œuvre. Les messages avec une liste d'adresses cible vide DOIVENT toujours être envoyés à toutes les entités Mbus (via multicast si disponible).

L'algorithme suivant peut être utilisé par l'envoi d'entités pour déterminer si une adresse Mbus est unique compte tenu de l'ensemble actuel d'entités Mbus:

    soit ta = l'adresse cible; 
    parcourir l'ensemble de tous 
    adresses Mbus actuellement connues { 
       soit ti = l'adresse à chaque itération; 
       compter les adresses pour lesquelles 
       le prédicat isSubsetOf (ta, ti) donne vrai; 
    } 

Si le nombre d'adresses correspondantes est exactement 1, l'adresse est unique. L'algorithme suivant peut être utilisé pour le prédicat isSubsetOf, qui vérifie si le deuxième message correspond au premier selon les règles spécifiées dans la section 4. (Une correspondance signifie qu'une entité réceptrice qui utilise la deuxième adresse Mbus doit également traiter les messages reçus avec le première adresse comme adresse cible.)

    isSubsetOf (addr a1, a2) renvoie true, ssi 
       chaque élément d'adresse de a1 est contenu 
       dans la liste des éléments d'adresse d'a2. 

Un élément d'adresse a1 est contenu dans une liste d'éléments d'adresse si la liste contient un élément égal à a1. Un élément d'adresse est considéré comme égal à un autre élément d'adresse s'il a les mêmes valeurs pour les deux champs d'élément d'adresse (balise et valeur).

7. Fiabilité

Alors que la plupart des messages sont censés être envoyés en utilisant un transport non fiable, il peut être nécessaire de livrer certains messages de manière fiable. La fiabilité peut être sélectionnée sur une base par message au moyen du champ MessageType. La livraison fiable est prise en charge pour les messages avec un seul destinataire; c'est-à-dire à une adresse Mbus pleinement qualifiée. Une entité ne peut donc envoyer des messages fiables qu'à des adresses connues, c'est-à-dire qu'elle ne peut envoyer des messages fiables qu'aux entités qui ont annoncé leur existence sur le Mbus (par exemple, au moyen des messages mbus.hello () tels que définis au paragraphe 9.1). Une entité émettrice NE DOIT PAS envoyer un message de manière fiable si l'adresse cible n'est pas unique. (Voir la section 6 pour la spécification d'un algorithme pour déterminer si une adresse est unique.

L'interdiction de la livraison fiable des messages pour les messages envoyés à plusieurs destinations est motivée par la simplicité de la mise en œuvre ainsi que du protocole. L'effet souhaité peut être obtenu au niveau de la couche application en envoyant des messages fiables individuels à chaque adresse de destination pleinement qualifiée, si les informations d'appartenance à la session Mbus sont disponibles.

Chaque message est étiqueté avec un numéro de séquence de message. Si le MessageType est "R", l'expéditeur attend un accusé de réception du destinataire dans un court laps de temps. Si l'accusé de réception n'est pas reçu dans cet intervalle, l'expéditeur DOIT retransmettre le message (avec le même numéro de séquence de message), augmenter le délai d'expiration et redémarrer le temporisateur. Les messages DOIVENT être retransmis un petit nombre de fois (voir ci-dessous) avant que la transmission ou le destinataire ne soit considéré comme ayant échoué. Si le message n'est pas remis avec succès, l'application d'envoi est notifiée. Dans ce cas, il appartient à l'application de déterminer les actions spécifiques (le cas échéant) à entreprendre.

Les messages fiables DOIVENT être acquittés en ajoutant leur SeqNum au champ AckList d'un message envoyé à l'expéditeur du message fiable. Ce message DOIT être envoyé à une adresse cible Mbus pleinement qualifiée. Plusieurs accusés de réception PEUVENT être envoyés dans un seul message. Les mises en œuvre PEUVENT soit superposer l'AckList sur un autre message envoyé à la même destination, soit PEUVENT envoyer un message d'accusé de réception dédié, sans commandes dans la partie de la charge utile du message.

Les procédures précises sont les suivantes:

Expéditeur Un expéditeur A d'un message fiable M au récepteur B DOIT transmettre le message soit via IP-multicast ou via IP-unicast, conserver une copie de M, initialiser un compteur de retransmission N à '1' et démarrer un temporisateur de retransmission T (initialisé à T_r). Si un accusé de réception est reçu de B, le temporisateur T DOIT être annulé et la copie de M est rejetée. Si T expire, le message DOIT être retransmis, le compteur N DOIT être incrémenté de un, et le temporisateur DOIT être redémarré (mis à N * T_r). Si N dépasse le seuil de retransmission N_r, la transmission est supposée avoir échoué, d'autres tentatives de retransmission NE DOIVENT PAS être entreprises, la copie de DOIT être rejetée et l'application d'envoi DEVRAIT être notifiée. Receveur Un récepteur B d'un message fiable provenant d'un expéditeur A DOIT accuser réception du message dans un laps de temps T_c <T_r. Cela PEUT être fait au moyen d'un message d'accusé de réception dédié ou en superposant l'accusé de réception sur un autre message adressé uniquement à A. Optimisation du récepteur Dans une mise en œuvre simple, B peut choisir d'envoyer immédiatement un message d'accusé de réception dédié. Cependant, pour plus d'efficacité, il pourrait ajouter le SeqNum du message reçu à une liste d'accusés de réception propre à l'expéditeur; si le SeqNum ajouté est le premier accusé de réception de la liste, B DEVRAIT démarrer un temporisateur d'accusé de réception TA (initialisé à T_c). Lorsque le temporisateur expire, B DEVRAIT créer un message d'accusé de réception dédié et l'envoyer à A. Si B doit transmettre un autre message Mbus adressé uniquement à A, il devrait ajouter les accusés de réception à ce message et annuler TA. Dans les deux cas, B doit stocker une copie de la liste d'accusé de réception en tant qu'entrée unique dans la liste de copie par expéditeur, conserver cette entrée pendant une période T_k et vider la liste d'accusé de réception. Constantes et algorithmes Les constantes et algorithmes suivants DEVRAIENT être utilisés par les implémentations:

 T_r = 100 ms 
 N_r = 3 
 T_c = 70 ms 
 T_k = ((N_r) * (N_r + 1) / 2) * T_r 

8. Connaissance des autres entités

Avant que les entités Mbus puissent communiquer entre elles, elles doivent s'informer mutuellement de leur existence. Après cette procédure de bootstrap, chaque entité Mbus passe par toutes les autres entités écoutant le même Mbus et connaît le nouveau venu et le nouveau venu a pris connaissance de toutes les autres entités. En outre, les entités doivent être en mesure de remarquer l'échec (ou la sortie) d'autres entités.

Toute entité Mbus DOIT annoncer sa présence (sur le Mbus) après le démarrage. Cela doit être fait à plusieurs reprises tout au long de sa durée de vie pour résoudre les problèmes de séquence de démarrage: les entités doivent toujours prendre conscience des autres entités indépendamment de l'ordre de démarrage.

Chaque entité Mbus DOIT maintenir le nombre de membres de session Mbus et mettre à jour en permanence ce nombre en fonction de tout changement observé. Les mécanismes de la façon dont l'existence et la sortie d'autres entités (section 9.1) et mbus.bye (section 9.2). Chaque implémentation de protocole Mbus DOIT envoyer périodiquement des messages mbus.hello qui sont utilisés par d'autres entités pour surveiller l'existence de cette entité. Si une entité n'a pas reçu de messages mbus.hello pendant un certain temps (voir la section 8.2) d'une entité, l'entité respective est considérée comme ayant quitté le Mbus et DOIT être exclue de l'ensemble des entités actuellement connues. A la réception d'un message mbus.bye, l'entité respective est considérée comme ayant également quitté le Mbus et DOIT être immédiatement exclue de l'ensemble des entités actuellement connues.

Chaque entité Mbus DOIT envoyer des messages Hello au Mbus après le démarrage. Après la transmission du message bonjour, il DOIT démarrer une minuterie après l'expiration de laquelle le prochain message bonjour doit être transmis. La transmission des messages Hello NE DOIT PAS être arrêtée à moins que l'entité ne se détache du Mbus. L'intervalle d'envoi des messages Hello dépend du nombre actuel d'entités dans un groupe Mbus et peut donc changer de manière dynamique afin d'éviter la congestion due à de nombreuses entités envoyant des messages Hello à un débit constant élevé.

Le paragraphe 8.1 spécifie le calcul des intervalles de message bonjour qui DOIVENT être utilisés par les implémentations de protocole. En utilisant les valeurs calculées pour obtenir le minuteur de message Hello actuel, le délai d'expiration des messages Hello reçus est calculé dans la section 8.2. La section 9 spécifie le synopsis des commandes pour les messages Mbus correspondants.

8.1 Intervalle de transmission des messages Hello

Étant donné que le nombre d'entités dans une session Mbus peut varier, il faut prendre soin de permettre au protocole Mbus de s'adapter automatiquement à une large gamme de tailles de groupe. Le débit moyen auquel les messages Hello sont reçus augmenterait linéairement jusqu'au nombre d'entités dans une session si l'intervalle d'envoi était défini sur une valeur fixe. Avec un intervalle de 1 seconde, cela signifierait qu'une entité prenant part à une session Mbus avec n entités recevrait n messages Hello par seconde. En supposant que toutes les entités résidaient sur un hôte, cela conduirait à n * n messages qui doivent être traités par seconde - ce qui n'est évidemment pas une solution viable pour les grands groupes. Il est donc nécessaire de déployer des intervalles de messages Hello adaptés dynamiquement, en tenant compte de nombres d'entités variables. Dans ce qui suit,

L'algorithme présente les caractéristiques suivantes:

Le nombre de messages Hello qui sont reçus par une seule entité dans une certaine unité de temps reste approximativement constant à mesure que le nombre d'entités change. L'intervalle effectif qui est utilisé par une entité Mbus spécifique est randomisé afin d'éviter la synchronisation involontaire des messages Hello dans une session Mbus. Le premier message d'accueil d'une entité est également retardé d'une certaine durée aléatoire. Un mécanisme de reconsidération du temporisateur est déployé afin d'adapter l'intervalle de manière plus appropriée dans les situations où un changement rapide du nombre d'entités est observé. Ceci est utile lorsqu'une entité rejoint une session Mbus et apprend toujours l'existence d'autres entités ou lorsqu'un plus grand nombre d'entités quitte le Mbus en même temps. 8.1.1 Calcul de l'intervalle des messages Hello Les noms de variables suivants sont utilisés dans le calcul spécifié ci-dessous (toutes les valeurs de temps en millisecondes):

hello_p: La dernière fois qu'un message Hello a été envoyé par une entité Mbus. hello_now: l'heure actuelle hello_d: l'intervalle calculé déterministe entre les messages hello. hello_e: L'intervalle effectif (aléatoire) entre les messages Hello. hello_n: l'heure de la prochaine transmission programmée d'un message Hello. entity_p: Le nombre d'entités au moment où hello_n a été recalculé pour la dernière fois. entités: le nombre d'entités actuellement connues. L'intervalle entre les messages Hello DOIT être calculé comme suit:

Le nombre d'entités actuellement connues est multiplié par c_hello_factor, ce qui donne l'intervalle entre les messages Hello en millisecondes. Il s'agit de l'intervalle calculé déterministe, noté hello_d. La valeur minimale de hello_d est c_hello_min, ce qui donne

 hello_d = max (c_hello_min, c_hello_factor * entités * 1ms). 

La section 8 fournit une spécification sur la façon d'obtenir le nombre d'entités actuellement connues. La section 10 fournit des valeurs pour les constantes c_hello_factor et c_hello_min.

L'intervalle effectif hello_e qui doit être utilisé par des entités individuelles est calculé en multipliant hello_d par un nombre choisi au hasard entre c_hello_dither_min et c_hello_dither_max comme suit:

  bonjour_e = c_hello_dither_min + 
            RND * (c_hello_dither_max - c_hello_dither_min) 

RND étant une fonction aléatoire qui produit une distribution égale entre 0 et 1. Voir également la section 10.

hello_n, l'heure du prochain message bonjour en millisecondes est définie sur hello_e + hello_now.

8.1.2 Initialisation des valeurs

Lors de la participation à une session Mbus, une implémentation de protocole définit hello_p = 0, hello_now = 0 et entity = 1, entity_p = 1 (l'entité Mbus elle-même) puis calcule l'heure du prochain message Hello comme spécifié dans la section 8.1.1. Le prochain message Hello est prévu pour la transmission à hello_n.

8.1.3 Ajustement de l'intervalle de message Hello lorsque le nombre d'entités augmente

Lorsque l'existence d'une nouvelle entité est observée par une implémentation de protocole, le nombre d'entités actuellement connues est mis à jour. Aucune autre action concernant le calcul de l'intervalle des messages Hello n'est requise. Le réexamen de l'intervalle de temporisation a lieu lorsque le temporisateur actuel pour le prochain message bonjour expire (voir la section 8.1.5).

8.1.4 Ajustement de l'intervalle de message Hello lorsque le nombre d'entités diminue

En réalisant qu'une entité a quitté le Mbus, le nombre d'entités actuellement connues est mis à jour et l'algorithme suivant doit être utilisé pour reconsidérer l'intervalle de temporisation pour les messages Hello:

1. La valeur de hello_n est mise à jour en définissant hello_n = hello_now + (entités / entités_p) * (hello_n - hello_now) 2. La valeur de hello_p est mise à jour en définissant hello_p = hello_now - (entités / entités_p) * (hello_now - hello_p) 3. La minuterie actuellement active pour les prochains messages Hello est annulée et une nouvelle minuterie est lancée pour hello_n. 4. entity_p est défini sur entités.

8.1.5 Expiration des minuteries Hello

Lorsque le temporisateur de message hello expire, l'implémentation du protocole DOIT effectuer les opérations suivantes:

L'intervalle hello hello_e est calculé comme spécifié dans la section 8.1.1. 1. SI hello_e + hello_p <= hello_now ALORS un message bonjour est transmis. hello_p est défini sur hello_now, hello_e est à nouveau calculé comme spécifié dans la section 8.1.1 et hello_n est défini sur hello_e + hello_now. 2. ELSE SI hello_e + hello_p> hello_now ALORS hello_n est défini sur hello_e + hello_p. Un nouveau minuteur pour le prochain message Hello commence à expirer à hello_n. Aucun message bonjour n'est transmis. entity_p est défini sur entités. 8.2 Calcul du délai d'expiration pour les entités Mbus Chaque fois qu'une entité Mbus n'a pas entendu pendant un laps de temps de c_hello_dead * (hello_d * c_hello_dither_max) millisecondes d'une autre entité Mbus, elle peut considérer que cette entité a échoué (ou a quitté silencieusement). Le nombre d'entités actuellement connues DOIT être mis à jour en conséquence. Voir la section 8.1.4 pour plus de détails. Notez qu'aucune action supplémentaire n'est nécessaire à partir de cette observation.

La section 8.1.1 spécifie comment obtenir hello_d. La section 10 définit les valeurs des constantes c_hello_dead et c_hello_dither_max.

9. Messages

Cette section définit certains messages de base indépendants de l'application qui DOIVENT être compris par toutes les implémentations; ces messages sont nécessaires au bon fonctionnement du Mbus. Cette spécification ne contient pas de messages spécifiques à l'application. Ceux-ci doivent être définis en dehors de la spécification de base du protocole Mbus dans des profils Mbus séparés.

9.1 mbus.hello

 Syntaxe: 
 mbus.hello () 
 Paramètres: - aucun - 

Les messages mbus.hello DOIVENT être envoyés de manière non fiable à toutes les entités Mbus.

Chaque entité Mbus apprend d'autres entités Mbus en observant leurs messages mbus.hello et en suivant l'adresse d'expéditeur de chaque message et peut ainsi calculer le nombre actuel d'entités.

Les messages mbus.hello DOIVENT être envoyés périodiquement à des intervalles calculés dynamiquement comme spécifié au paragraphe 8.

Au démarrage, le premier message mbus.hello DOIT être envoyé après un délai hello_delay, où hello_delay est un nombre choisi au hasard entre 0 et c_hello_min (voir la section 10).

9.2 mbus.bye

 Syntaxe: mbus.bye () 
 Paramètres: - aucun - 

Une entité Mbus qui est sur le point de se terminer (ou "se détacher" du Mbus) DEVRAIT l'annoncer en transmettant un message mbus.bye. Le message mbus.bye DOIT être envoyé de manière non fiable à toutes les entités.

9,3 mbus.ping

 Syntaxe: mbus.ping () 
 Paramètres: - aucun - 

mbus.ping peut être utilisé pour solliciter d'autres entités pour signaler leur existence en répondant par un message mbus.hello. Chaque implémentation de protocole DOIT comprendre mbus.ping et répondre avec un message mbus.hello. Le message de réponse bonjour DOIT être retardé de hello_delay millisecondes, où hello_delay est un nombre choisi au hasard entre 0 et c_hello_min (voir la section 10). Plusieurs messages mbus.ping PEUVENT recevoir une réponse par un seul mbus.hello: si un ou plusieurs autres messages mbus.ping sont reçus pendant que l'entité attend les unités de temps hello_delay avant de transmettre le message mbus.hello, aucun message mbus.hello supplémentaire ne doit être programmé pour ces messages mbus.ping supplémentaires.

Comme spécifié au paragraphe 9.1, les messages hello DOIVENT être envoyés de manière non fiable à toutes les entités Mbus. C'est également le cas pour les réponses aux messages ping. Une entité qui répond à mbus.ping avec mbus.hello DEVRAIT arrêter les minuteries en attente pour les messages hello après avoir envoyé le message hello et programmer un nouvel événement de minuterie pour le message hello suivant. (Notez qu'en utilisant les variables et les algorithmes de la section 8.1.1, cela peut être réalisé en définissant hello_p sur hello_now.)

mbus.ping permet à une nouvelle entité de rechercher rapidement d'autres entités sans avoir à attendre les messages Hello individuels réguliers. En spécifiant une adresse cible, la nouvelle entité peut restreindre la sollicitation de messages Hello à un sous-ensemble d'entités qui l'intéresse.

9,4 mbus.quit

 Syntaxe: 
 mbus.quit () 
 Paramètres: - aucun - 

Le message mbus.quit est utilisé pour demander à d'autres entités de se terminer (et de se détacher du Mbus). Que cette demande soit honorée par les entités réceptrices ou non est spécifique à l'application et n'est pas définie dans ce document.

Le message mbus.quit peut être multidiffusé ou envoyé de manière fiable par monodiffusion à une seule entité Mbus ou à un groupe d'entités.

9,5 mbus en attente

 Syntaxe: 
 mbus.waiting (condition) 
 Paramètres: 
    condition de symbole 

Le paramètre condition est utilisé pour indiquer que l'entité qui transmet ce message attend qu'un événement particulier se produise. Une entité Mbus DEVRAIT être capable d'indiquer qu'elle attend qu'un certain événement se produise (similaire à une opération P () sur un sémaphore mais sans créer un état externe ailleurs). En conjonction avec cela, une entité Mbus DEVRAIT être capable d'indiquer à une autre entité que cette condition est maintenant satisfaite (similaire à l'opération V () d'un sémaphore).

Le message mbus.waiting PEUT être diffusé à toutes les entités Mbus, PEUT être multidiffusé vers un sous-groupe arbitraire, ou PEUT être monodiffusé vers un homologue particulier. La transmission du message mbus.waiting DOIT être non fiable et DOIT donc être répétée à un intervalle défini par l'application (jusqu'à ce que la condition soit satisfaite).

Si une application veut indiquer qu'elle attend que plusieurs conditions soient remplies, plusieurs messages mbus.waiting sont envoyés (éventuellement inclus dans la même charge utile Mbus). Notez que les messages mbus.hello et mbus.waiting peuvent également être transmis dans une seule charge utile Mbus.

9,6 mbus.go

 Syntaxe: 
 mbus.go (condition) 
 Paramètres: 
    condition de symbole 
    Ce paramètre spécifie la condition remplie. 

Le message mbus.go est envoyé par une entité Mbus pour "débloquer" une autre entité Mbus - qui a indiqué qu'elle attend qu'une certaine condition soit remplie. Une seule condition peut être spécifiée par message mbus.go. Si plusieurs conditions sont satisfaites simultanément, plusieurs messages mbus.go PEUVENT être combinés en une seule charge utile Mbus.

Le message mbus.go DOIT être envoyé de manière fiable par monodiffusion à l'entité Mbus à débloquer.

10. Constantes

Les valeurs suivantes pour les temporisateurs et les compteurs mentionnés dans ce document DEVRAIENT être utilisées par les implémentations:

 + ------------------- + ------------------------ + ---- ---------- + 
 | Minuterie / Compteur | Valeur | Unité |
 + ------------------- + ------------------------ + ---- ---------- + 
 | c_hello_factor | 200 | - |
 | c_hello_min | 1000 | millisecondes |
 | c_hello_dither_min | 0,9 | - |
 | c_hello_dither_max | 1.1 | - |
 | c_hello_dead | 5 | - |
 + ------------------- + ------------------------ + ---- ---------- + 
    T_r = 100 ms 
    N_r = 3 
    T_c = 70 ms 
    T_k = ((N_r) * (N_r + 1) / 2) * T_r 

11. Sécurité Mbus

11.1 Modèle de sécurité

Afin d'éviter toute perturbation accidentelle ou malveillante des communications Mbus via des messages provenant d'applications provenant d'autres utilisateurs, l'authentification des messages est déployée (section 11.3). Pour chaque message, un résumé DOIT être calculé sur la base de la valeur d'une valeur de clé secrète partagée. Les destinataires de messages DOIVENT vérifier si l'expéditeur appartient au même domaine de sécurité Mbus en recalculant le résumé et en le comparant à la valeur reçue. Les messages DOIVENT être traités ultérieurement uniquement si les deux valeurs sont égales. Afin de permettre différentes sessions Mbus simultanées à une portée donnée et de compenser les implémentations défectueuses de la multidiffusion locale hôte, l'authentification de message DOIT être fournie par des implémentations conformes.

La confidentialité du transport des messages Mbus peut être obtenue en utilisant éventuellement des méthodes de cryptage symétriques (section 11.2). Chaque message PEUT être chiffré en utilisant une clé secrète partagée supplémentaire et un algorithme de chiffrement symétrique. Le cryptage est OPTIONNEL pour les applications, c'est-à-dire qu'il est autorisé à configurer un domaine Mbus pour ne pas utiliser le cryptage. Mais les implémentations conformes DOIVENT fournir la possibilité d'utiliser le cryptage des messages (voir ci-dessous).

L'authentification et le chiffrement des messages peuvent être paramétrés: les algorithmes à appliquer, les clés à utiliser, etc. Ces paramètres et d'autres sont définis dans un objet de configuration Mbus accessible par toutes les entités Mbus participant à une session Mbus. Afin de réaliser l'interopérabilité, les implémentations conformes DEVRAIENT utiliser les valeurs fournies par une telle configuration Mbus. La section 12 définit les paramètres obligatoires et facultatifs ainsi que les procédures de stockage pour différentes plates-formes. Seulement dans les cas où aucune des options mentionnées au paragraphe 12 n'est applicable, des méthodes alternatives de configuration des entités de protocole Mbus PEUVENT être déployées.

Les algorithmes et procédures d'application des techniques de chiffrement et d'authentification sont spécifiés dans les sections suivantes.

11.2 Chiffrement

Le cryptage des messages est OPTIONNEL, ce qui signifie qu'un Mbus PEUT être configuré pour ne pas utiliser le cryptage.

Les implémentations peuvent choisir entre différents algorithmes de chiffrement. Chaque implémentation conforme DOIT fournir l'algorithme AES [18]. De plus, les algorithmes suivants DEVRAIENT être pris en charge: DES [16], 3DES (triple DES) [16] et IDEA [20].

Pour les algorithmes exigeant que les données en / décryptage soient complétées à certaines limites, des octets avec une valeur de 0 DEVRAIENT être utilisés pour les caractères de remplissage.

La longueur des clés de chiffrement est déterminée par l'algorithme de chiffrement actuellement utilisé. Cela signifie que la clé de chiffrement configurée NE DOIT PAS être plus courte que la longueur de clé native pour l'algorithme actuellement configuré.

Les mises en œuvre DES DOIVENT utiliser le mode DES Cipher Block Chaining (CBC). Les clés DES (56 bits) DOIVENT être codées en 8 octets comme décrit dans la RFC 1423 [12], ce qui donne 12 caractères codés en Base64. IDEA utilise des clés de 128 bits (24 caractères encodés en Base64). AES peut utiliser des clés 128 bits, 192 bits ou 256 bits. Pour le cryptage Mbus utilisant AES, seules des clés de 128 bits (24 caractères codés en Base64) DOIVENT être utilisées.

11.3 Authentification des messages

Pour l'authentification des messages, des codes d'authentification de message hachés (HMAC) comme décrit dans la RFC 2104 [5] sont déployés. En général, les implémentations peuvent choisir entre un certain nombre d'algorithmes de résumé. Pour l'authentification Mbus, l'algorithme HMAC DOIT être appliqué de la manière suivante:

La valeur de hachage clé est calculée à l'aide de l'algorithme HMAC spécifié dans la RFC 2104 [5]. L'algorithme de hachage spécifique et la clé de hachage secrète DOIVENT être obtenus à partir de la configuration Mbus (voir la section 12). Les valeurs de hachage clés (voir RFC 2104 [5]) DOIVENT être tronquées à 96 bits (12 octets). Par la suite, les 12 octets résultants DOIVENT être codés en Base64, résultant en 16 caractères codés en Base64 (voir la RFC 1521 [7]). Soit MD5 [15], soit SHA-1 [17] DEVRAIT être utilisé pour les codes d'authentification de message (MAC). Une implémentation PEUT fournir MD5, alors que SHA-1 DOIT être implémenté.

La longueur des clés de hachage est déterminée par l'algorithme de hachage sélectionné. Cela signifie que la clé de hachage configurée NE DOIT PAS être plus courte que la longueur de clé native pour l'algorithme actuellement configuré.

Les algorithmes qui DOIVENT être fournis par les implémentations sont AES et SHA-1.

Voir la section 12 pour une spécification des notations pour les chaînes Base64.

Un expéditeur DOIT appliquer les opérations suivantes à un message qui doit être envoyé:

1. Si le cryptage est activé, le message DOIT être crypté à l'aide de l'algorithme configuré et de la clé de cryptage configurée. Le remplissage (ajout de caractères supplémentaires) pour les chiffrements par blocs DOIT être appliqué comme spécifié au paragraphe 11.2. Si le cryptage n'est pas activé, le message reste inchangé. 2. Par la suite, un code d'authentification de message (MAC) pour le message (crypté) DOIT être calculé en utilisant l'algorithme HMAC configuré et la clé de hachage configurée. 3. Le MAC DOIT alors être converti en codage Base64, ce qui donne 16 caractères Base64 comme spécifié au paragraphe 11.3. 4. Enfin, l'expéditeur DOIT construire le message final en plaçant le message (chiffré) après le MAC codé en base64 et un CRLF. La définition ABNF du message final est la suivante: final_msg = MsgDigest CRLF encr_msg MsgDigest = base64 encr_msg = * OCTET Un récepteur DOIT appliquer les opérations suivantes à un message qu'il a reçu:

1. Séparez le MAC encodé en base64 du message (crypté) et décodez le MAC. 2. Recalculez le MAC du message à l'aide de l'algorithme HMAC configuré et de la clé de hachage configurée. 3. Comparez le MAC d'origine avec le MAC recalculé. S'ils diffèrent, le message DOIT être rejeté sans autre traitement. 4. Si le cryptage est activé, le message DOIT être décrypté en utilisant l'algorithme configuré et la clé de cryptage configurée. Les octets de fin avec une valeur de 0 DOIVENT être supprimés. Si le message ne commence pas par la chaîne "mbus /", le message DOIT être rejeté sans autre traitement. 12. Configuration Mbus Une implémentation DOIT être configurable par les paramètres suivants:

Version de configuration Le numéro de version de l'entité de configuration donnée. Les numéros de version permettent aux implémentations de vérifier si elles peuvent traiter les entrées d'une entité de configuration donnée. Les numéros de version sont des valeurs entières. Le numéro de version de la version spécifiée ici est 1. Clé de cryptage La clé secrète utilisée pour le chiffrement des messages. Touche dièse La clé de hachage utilisée pour l'authentification des messages. Portée L'étendue de multidiffusion à utiliser pour les messages envoyés. Les paramètres ci-dessus sont obligatoires et DOIVENT être présents dans chaque entité de configuration Mbus.

Les paramètres suivants sont facultatifs. Quand ils sont présents, ils DOIVENT être honorés. Lorsqu'elles ne sont pas présentes, les implémentations DEVRAIENT revenir aux valeurs par défaut prédéfinies (telles que définies dans Transport (Section 6)):

Adresse Adresse de multidiffusion non standard à utiliser pour le transport des messages. Utilisation de la diffusion Il peut être spécifié si la diffusion doit être utilisée. Si la diffusion a été configurée, les implémentations DEVRAIENT utiliser l'adresse de diffusion du réseau (comme spécifié au paragraphe 6.1.3) au lieu de l'adresse de multidiffusion standard. Numéro de port Numéro de port UDP non standard à utiliser pour le transport des messages. Deux fonctions distinctes pour le stockage des paramètres sont envisagées: pour les systèmes de type Unix, un fichier de configuration par utilisateur DEVRAIT être utilisé et pour les systèmes Windows-95/98 / NT / 2000 / XP, un ensemble d'entrées de registre est défini qui DEVRAIT être utilisé. Pour les autres systèmes, il est RECOMMANDÉ d'utiliser le mécanisme de configuration basé sur les fichiers.

La syntaxe des valeurs des entrées de paramètres respectives reste la même pour les deux fonctions de configuration. Ce qui suit définit un ensemble de productions ABNF (voir RFC 2234 [13]) qui sont ultérieurement réutilisées pour les définitions de la syntaxe du fichier de configuration et des entrées de registre:

algo-id = "NOENCR" / "AES" / "DES" / "3DES" / "IDEA" /

                       «HMAC-MD5-96» / «HMAC-SHA1-96» 

scope = "HOSTLOCAL" / "LINKLOCAL"

clé = base64

numéro_version = 1 * 10DIGIT

key_value = "(" algo-id "," key ")"

adresse = adresse IPv4 / adresse IPv6 / "DIFFUSION"

port = 1 * 5DIGIT; valeurs de 0 à 65535 Compte tenu de la définition ci-dessus, une entrée de clé DOIT être spécifiée en utilisant cette notation:

 "(" algo-id "," base64string ")" 

algo-id est l'une des chaînes de caractères spécifiées ci-dessus. Pour algo-id == "NOENCR", les autres champs sont ignorés. Cependant, les virgules de délimitation DOIVENT toujours être présentes.

Une chaîne Base64 se compose des caractères définis dans le jeu de caractères Base64 (voir RFC 1521 [7]), y compris tous les caractères de remplissage possibles, c'est-à-dire que la longueur d'une chaîne Base64 est toujours un multiple de 4.

Le paramètre scope est utilisé pour configurer une étendue IP-Multicast et peut être défini sur "HOSTLOCAL" ou "LINKLOCAL". Les mises en œuvre DEVRAIENT choisir un

valeur de ce paramètre et construire une adresse IP effective en tenant compte des spécifications du paragraphe 6.1.

L'utilisation de la diffusion est configurée en fournissant la valeur "BROADCAST" pour le champ d'adresse. Si la diffusion a été configurée, les mises en œuvre DEVRAIENT utiliser l'adresse de diffusion réseau pour la version IP utilisée au lieu de l'adresse de multidiffusion standard.

Le paramètre numéro_version spécifie un numéro de version pour l'entité de configuration utilisée.

12.1 Stockage des paramètres basé sur un fichier

Le nom de fichier d'un fichier de configuration Mbus est ".mbus" dans le répertoire personnel de l'utilisateur. Si une variable d'environnement appelée MBUS est définie, les implémentations DEVRAIENT interpréter la valeur de cette variable comme un nom de fichier pleinement qualifié qui doit être utilisé pour le fichier de configuration. Les implémentations DOIVENT garantir que ce fichier dispose des autorisations de fichier appropriées qui empêchent les autres utilisateurs de le lire ou de l'écrire. Le fichier DOIT exister avant qu'une conférence ne soit lancée. Son contenu DOIT être encodé en UTF-8 et DOIT se conformer à la définition de syntaxe suivante:

 mbus-file = mbus-topic LF * (entrée LF) 
 mbus-topic = "[MBUS]" 
 entrée = 1 * (version_info / hashkey_info 
                        / encryptionkey_info / scope_info 
                        / info_port / info_adresse) 
 version_info = "CONFIG_VERSION =" numéro_version 
 hashkey_info = "HASHKEY =" valeur_clé 
 encrkey_info = "ENCRYPTIONKEY =" key_value 
 scope_info = "SCOPE =" portée 
 port_info = "PORT =" port 
 address_info = "ADDRESS =" adresse 

Les entrées suivantes sont définies: CONFIG_VERSION, HASHKEY, ENCRYPTIONKEY, SCOPE, PORT, ADDRESS.

Les entrées CONFIG_VERSION, HASHKEY et ENCRYPTIONKEY sont obligatoires, elles DOIVENT être présentes dans chaque fichier de configuration Mbus. L'ordre des entrées n'est pas significatif.

Un exemple de fichier de configuration Mbus:

 [MBUS] 
 CONFIG_VERSION = 1 
 HASHKEY = (HMAC-MD5-96, MTIzMTU2MTg5MTEy) 
 ENCRYPTIONKEY = (DES, MTIzMTU2MQ ==) 
 PORTÉE = HOSTLOCAL 
 ADRESSE = 224.255.222.239 
 PORT = 47000 

12.2 Stockage des paramètres basé sur le registre

Pour les systèmes dépourvus du concept de répertoire personnel d'un utilisateur comme emplacement pour les fichiers de configuration, la base de données suggérée pour les paramètres de configuration (par exemple, le registre Windows9x, Windows NT, Windows 2000, Windows XP) DEVRAIT être utilisée. La hiérarchie des entrées de registre associées à Mbus est la suivante:

 HKEY_CURRENT_USER \ Software \ Mbus 

Les entrées de cette section hiérarchique sont:

 + --------------- + -------- + ---------------- + 
 | Nom | Type | Production ABNF |
 + --------------- + -------- + ---------------- | 
 | CONFIG_VERSION | DWORD | numéro_version |
 | HASHKEY | String | key_value |
 | ENCRYPTIONKEY | String | key_value |
 | PORTÉE | String | portée |
 | ADRESSE | String | adresse |
 | PORT | DWORD | port |
 + --------------- + -------- + ---------------- + 

La même syntaxe pour les valeurs de clé que pour la fonction de configuration basée sur fichier DOIT être utilisée.

13. Considérations relatives à la sécurité

Les mécanismes de sécurité Mbus sont spécifiés dans la section 11.1.

Il convient de noter que la spécification de transport Mbus définit un ensemble d'algorithmes de base obligatoire qui doivent être pris en charge par les implémentations. Cet ensemble de base est destiné à fournir une sécurité raisonnable en imposant des algorithmes et des longueurs de clé qui sont considérés comme suffisamment forts cryptographiquement au moment de la rédaction.

Cependant, pour permettre une efficacité, il est permis d'utiliser des algorithmes cryptographiquement plus faibles, par exemple HMAC-MD5 au lieu de HMAC-SHA1. De plus, le cryptage peut être complètement désactivé si la confidentialité est fournie par d'autres moyens ou n'est pas considérée comme importante pour une certaine application.

Les utilisateurs du Mbus doivent donc connaître la configuration de sécurité sélectionnée et vérifier si elle répond aux exigences de sécurité pour une application donnée. Puisque chaque mise en œuvre DOIT fournir l'algorithme cryptographiquement fort, il devrait toujours être possible de configurer un Mbus de manière à garantir une communication sécurisée avec authentification et confidentialité.

En aucun cas, les développeurs d'applications doivent être conscients des implémentations IP incorrectes qui ne sont pas conformes à la RFC 1122 [2] et envoyer des datagrammes avec des valeurs TTL de zéro, ce qui entraîne l'envoi de messages Mbus à la liaison réseau locale bien qu'un utilisateur puisse avoir sélectionné l'hôte portée locale dans la configuration Mbus. Lors de l'utilisation de la multidiffusion à portée administrative, les utilisateurs ne peuvent pas toujours supposer la présence de routeurs de frontière correctement configurés. Dans ces cas, l'utilisation du cryptage DEVRAIT être envisagée si la confidentialité est souhaitée.

14. Considérations IANA

L'IANA a attribué une adresse multicast relative à la portée avec un décalage de 8 pour Mbus / IPv4. L'adresse de multidiffusion permanente IPv6 est FF0X: 0: 0: 0: 0: 0: 0: 300.

Le numéro de port Mbus UDP enregistré est 47000.

15. Références

[1] Bradner, S., "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, RFC 2119 , mars 1997.

[2] Braden, R., «Requirements for Internet Hosts - Communication Layers», STD 3, RFC 1122 , octobre 1989.

[3] Hinden, R. et S. Deering, "IP Version 6 Addressing Architecture", RFC 2373 , juillet 1998.

[4] Hinden, R. et S. Deering, "IPv6 Multicast Address Assignments", RFC 2375 , juillet 1998.

[5] Krawczyk, H., Bellare, M. et R. Canetti, «HMAC: Keyed-Hashing for Message Authentication», RFC 2104 , février 1997.

[6] Resnick, P., éditeur, "Internet Message Format", RFC 2822 , avril 2001.

[7] Borenstein, N. et N. Freed, "MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC 1521 , septembre 1993.

[8] Schulzrinne, H., Casner, S., Frederick, R. et V. Jacobsen, «RTP: A Transport Protocol for Real-Time Applications», RFC 1889 , janvier 1996.

[9] Handley, M., Schulzrinne, H., Schooler, E. et J. Rosenberg, «SIP: Session Initiation Protocol», RFC 2543 , mars 1999.

[10] Handley, M. et V. Jacobsen, "SDP: Session Description Protocol", RFC 2327 , avril 1998.

[11] Meyer, D., "Administrativement Scoped IP Multicast", BCP 23, RFC 2365 , juillet 1998.

[12] Balenson, D., "Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers", RFC 1423 , février 1993.

[13] Crocker, D. et P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234 , novembre 1997.

[14] Myers, J., "SMTP Service Extension for Authentication", RFC 2554 , mars 1999.

[15] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321 , avril 1992.

[16] DÉPARTEMENT DU COMMERCE DES ÉTATS-UNIS / Institut national des normes et de la technologie, «Data Encryption Standard (DES)», FIPS PUB 46-3, catégorie Sécurité informatique, sous-catégorie Cryptographie, octobre 1999.

[17] US DEPARTMENT OF COMMERCE / National Institute of Standards and Technology, "Secure Hash Standard", FIPS PUB 180-1, avril 1995.

[18] Daemen, JD et VR Rijmen, «Proposition AES: Rijndael», mars 1999.

[19] IANA, «Internet Multicast Addresses», URL http://www.iana.org/assignments/multicast-addresses , mai 2001.

[20] Schneier, B., "Applied Cryptography", édition 2, éditeur John Wiley & Sons, Inc., statut: non normatif, 1996.


Annexe A. À propos des références

Veuillez noter que la liste de références contient des références normatives et non normatives. Chaque référence non normative est marquée comme "statut: non normatif". Toutes les références non marquées sont normatives.

Annexe B. Limitations et travaux futurs

Le Mbus est un mécanisme de coordination locale léger et délibérément non conçu pour une coordination de plus grande portée. Il est censé être utilisé sur un seul nœud ou - tout au plus - sur une seule liaison réseau.

Par conséquent, le protocole Mbus ne contient pas les fonctionnalités qui seraient nécessaires pour le qualifier pour une utilisation sur Internet mondial:

Il n'existe aucun mécanisme permettant de contrôler la congestion. La question du contrôle de la congestion est un problème général pour les protocoles de multidiffusion. Le Mbus permet des messages non acquittés qui sont envoyés de manière non fiable, par exemple sous forme de notifications d'événements, d'une entité à une autre. Étant donné que les accusés de réception négatifs ne sont pas définis, il n'y a aucun moyen pour l'expéditeur de se rendre compte qu'il inonde une autre entité ou qu'il encombre un segment de réseau à faible bande passante.

Le mécanisme de fiabilité, c'est-à-dire les temporisateurs de retransmission, sont conçus pour fournir un transport de messages efficace et réactif sur les liaisons locales, mais ne sont pas adaptés pour faire face à des retards plus importants qui pourraient être introduits à partir des files d'attente de routeur, etc.

Certaines expériences sont actuellement en cours pour tester l'applicabilité des ponts entre différents domaines Mbus distribués sans changer la sémantique de base du protocole. Puisque l'utilisation de tels ponts doit être orthogonale aux définitions de base du protocole Mbus et que ces expériences sont toujours en cours de travail, il n'est pas fait mention de ce concept dans cette spécification.

Adresses des auteurs

Joerg Ott

TZI, Universitaet Brême Bibliothekstr. 1 Brême 28359 Allemagne Téléphone: + 49.421.201-7028 Télécopieur: + 49.421.218-7000 COURRIEL: jo@tzi.uni-bremen.de Colin Perkins

Institut des sciences de l'information de l'USC 3811 N. Fairfax Drive # 200 Arlington VA 22203 Etats-Unis COURRIEL: csp@isi.edu Dirk Kutscher

TZI, Universitaet Brême Bibliothekstr. 1 Brême 28359 Allemagne Téléphone: + 49.421.218-7595 Télécopieur: + 49.421.218-7000 COURRIEL: dku@tzi.uni-bremen.de

Déclaration de droit d'auteur complète

Copyright (C) L'Internet Society (2002). Tous les droits sont réservés.

Ce document et ses traductions peuvent être copiés et fournis à des tiers, et les travaux dérivés qui le commentent, l'expliquent ou aident à sa mise en œuvre peuvent être préparés, copiés, publiés et distribués, en tout ou en partie, sans restriction d'aucune sorte. , à condition que l'avis de droit d'auteur ci-dessus et ce paragraphe soient inclus sur toutes ces copies et œuvres dérivées. Cependant, ce document lui-même ne peut être modifié d'aucune manière, par exemple en supprimant l'avis de droit d'auteur ou les références à l'Internet Society ou à d'autres organisations Internet, sauf si nécessaire dans le but de développer des normes Internet, auquel cas les procédures relatives aux droits d'auteur définies dans le processus des normes Internet doit être suivi ou, au besoin, le traduire dans des langues autres que l'anglais.

Les autorisations limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par l'Internet Society ou ses successeurs ou ayants droit.

Ce document et les informations qu'il contient sont fournis sur une base «TELS QUELS» et LA SOCIÉTÉ INTERNET ET LE GROUPE DE TRAVAIL D'INGÉNIERIE INTERNET DÉCLINE TOUTE GARANTIE, EXPRESSE OU IMPLICITE, Y COMPRIS, MAIS SANS S'Y LIMITER, UNE GARANTIE QUE L'UTILISATION DES INFORMATIONS CI-DESSUS NE SERA PAS INFRACTION À TOUT DROIT OU À TOUTE GARANTIE IMPLICITE DE QUALITÉ MARCHANDE OU D'ADÉQUATION À UN USAGE PARTICULIER.

Reconnaissance

Le financement de la fonction RFC Editor est actuellement assuré par l'Internet Society.