RFC(F) 3259

From RFC.Wiki
Jump to: navigation, search
Groupe de travail du réseau J. Ott
Appel à observations: 3259 TZI, Universitaet Bremen
Catégorie: Informatif C. Perkins
                                      Institut des sciences de l'information de l'USC
                                                             D. Kutscher
                                                TZI, Universitaet Brême
                                                              Avril 2002

                  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. Distribution de ceci
   le mémo est illimité.

Copyright

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

Abstrait

   Le bus de messages local (Mbus) est un message léger orienté
   protocole de coordination pour la communication de groupe entre les applications
   Composants. Le Mbus fournit une localisation automatique de la communication
   pairs, adressage par sujet, transfert fiable des messages et
   différents types de schémas de communication. Le protocole est posé sur
   haut de la multidiffusion IP et est spécifié pour IPv4 et IPv6. L'IP
   la portée de la multidiffusion est limitée à la multidiffusion lien-local. Ce document
   spécifie le protocole Mbus, c'est-à-dire la syntaxe du message, l'adressage et
   mécanismes de transport.

Table des matières

   1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
   1.1 Présentation du Mbus. . . . . . . . . . . . . . . . . . . . . . . 3
   1.2 Objectif de ce document. . . . . . . . . . . . . . . . . . 5
   1.3 Domaines d'application. . . . . . . . . . . . . . . . . . . . 5
   1.4 Terminologie pour les spécifications des exigences. . . . . . . . . 6
   2. Règles de syntaxe formelle communes. . . . . . . . . . . . . . . . . 6
   3. Format du message. . . . . . . . . . . . . . . . . . . . . . . sept
   4. Adressage. . . . . . . . . . . . . . . . . . . . . . . . . 9
   4.1 Éléments d'adresse obligatoires. . . . . . . . . . . . . . . . . dix
   5. Syntaxe du message. . . . . . . . . . . . . . . . . . . . . . . 11
   5.1 Codage des messages. . . . . . . . . . . . . . . . . . . . . . 11
   5.2 En-tête de message. . . . . . . . . . . . . . . . . . . . . . . 11
   5.3 Syntaxe de commande. . . . . . . . . . . . . . . . . . . . . . . 12

   6. Transport. . . . . . . . . . . . . . . . . . . . . . . . . 13
   6.1 Multidiffusion / diffusion locale. . . . . . . . . . . . . . . . . 14
   6.1.1 Groupes de multidiffusion Mbus pour IPv4. . . . . . . . . . . . . . . 15
   6.1.2 Groupes multicast Mbus pour IPv6. . . . . . . . . . . . . . . 15
   6.1.3 Utilisation de la diffusion. . . . . . . . . . . . . . . . . . . . . . 16
   6.1.4 Numéro de port Mbus UDP. . . . . . . . . . . . . . . . . . . . 16
   6.2 Unicast dirigé. . . . . . . . . . . . . . . . . . . . . . 16
   7. Fiabilité. . . . . . . . . . . . . . . . . . . . . . . . 18
   8. Connaissance des autres entités. . . . . . . . . . . . . . . . 20
   8.1 Intervalle de transmission des messages Hello. . . . . . . . . . . . 21
   8.1.1 Calcul de l'intervalle des messages Hello. . . . . . . . 22
   8.1.2 Initialisation des valeurs. . . . . . . . . . . . . . . . . . 23
   8.1.3 Ajustement de l'intervalle de message Hello lorsque le nombre de
         Les entités augmentent. . . . . . . . . . . . . . . . . . . . . 23
   8.1.4 Ajustement de l'intervalle de message Hello lorsque le nombre de
         Les entités diminuent. . . . . . . . . . . . . . . . . . . . . 23
   8.1.5 Expiration des minuteries Hello. . . . . . . . . . . . . . . . . 23
   8.2 Calcul du délai d'expiration des entités Mbus. . . . . . . . . 24
   9. Messages. . . . . . . . . . . . . . . . . . . . . . . . . . 24
   9.1 mbus.hello. . . . . . . . . . . . . . . . . . . . . . . . . 24
   9.2 mbus.bye. . . . . . . . . . . . . . . . . . . . . . . . . . 25
   9.3 mbus.ping. . . . . . . . . . . . . . . . . . . . . . . . . 25
   9,4 mbus.quit. . . . . . . . . . . . . . . . . . . . . . . . . 26
   9,5 mbus. En attente. . . . . . . . . . . . . . . . . . . . . . . . 26
   9,6 mbus.go. . . . . . . . . . . . . . . . . . . . . . . . . . 27
   10. Constantes. . . . . . . . . . . . . . . . . . . . . . . . . 27
   11. Sécurité Mbus. . . . . . . . . . . . . . . . . . . . . . . 28
   11.1 Modèle de sécurité. . . . . . . . . . . . . . . . . . . . . . . 28
   11.2 Chiffrement. . . . . . . . . . . . . . . . . . . . . . . . . 28
   11.3 Authentification des messages. . . . . . . . . . . . . . . . . . . 29
   11.4 Procédures pour les expéditeurs et les destinataires. . . . . . . . . . . . 30
   12. Configuration Mbus. . . . . . . . . . . . . . . . . . . . . 31
   12.1 Stockage de paramètres basé sur un fichier. . . . . . . . . . . . . . . . 33
   12.2 Stockage des paramètres basé sur le registre. . . . . . . . . . . . . . 34
   13. Considérations de sécurité. . . . . . . . . . . . . . . . . . 34
   14. Considérations IANA. . . . . . . . . . . . . . . . . . . . 35
   15. Références. . . . . . . . . . . . . . . . . . . . . . . . . 35
   A. À propos des références. . . . . . . . . . . . . . . . . . . . . . 37
   B. Limitations et travaux futurs. . . . . . . . . . . . . . . . 37
   Adresses des auteurs. . . . . . . . . . . . . . . . . . . . . . . . 38
   Déclaration de copyright complète. . . . . . . . . . . . . . . . . . . . . 39

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 les
   entités d'application localisées mais par ailleurs indépendantes, par exemple
   ceux qui participent à des sessions de candidature appartenant au même
   conférence. Dans les conférences faiblement couplées, un tel mécanisme permet
   pour la coordination des entités d'application, par exemple pour mettre en œuvre
   synchronisation entre les flux multimédias ou pour configurer des entités
   sans interaction de l'utilisateur. Il peut également être utilisé pour mettre en œuvre étroitement
   conférences couplées permettant à un contrôleur de conférence d'appliquer
   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
   composants d'un système distribué et peut ainsi être intégré dans un
   groupe de modules d'application: par exemple, un appel de téléphonie IP
   est effectuée avec un téléphone IP autonome peut être dynamiquement
   étendu pour inclure des moteurs de médias pour d'autres types de médias utilisant le
   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 de l'application
   composants distribués sur différents hôtes d'un réseau, pour
   exemple, ce que l'on appelle les appareils Internet.

1.1 Présentation du Mbus

   La coordination locale des composants de l'application nécessite un certain nombre de
   différents modèles d'interaction: certains messages (comme l'appartenance
   informations, notifications de contrôle d'étage, diffusion de la conférence
   changements d'état, etc.) peuvent devoir être envoyés à toutes les applications locales
   entités. Les messages peuvent également être ciblés sur une certaine application
   classe (par exemple, tous les tableaux blancs ou tous les outils audio) ou type d'agent (par exemple,
   toutes les interfaces utilisateur plutôt que tous les moteurs multimédias). Ou il peut y avoir
   tout sous-groupe (spécifique à l'application ou au message) définissant le
   destinataires prévus, par exemple, les messages liés à la synchronisation des médias.
   Enfin, il peut y avoir des messages destinés à une seule entité:
   par exemple, des paramètres de configuration spécifiques qu'une conférence
   le contrôleur envoie à une entité d'application particulière, ou une requête
   échanges de réponses 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 transports de messages
   mécanismes (définis dans la section 6) et en fournissant un
   schéma d'adressage (défini dans la section 4).

   En outre, les messages Mbus échangés entre les entités d'application peuvent
   ont des exigences de fiabilité différentes (qui sont généralement dérivées
   de leur sémantique). Certains messages auront une
   caractère véhiculant des informations d'état éphémère (qui est
   rafraîchi / mis à jour périodiquement), comme le niveau de l'indicateur de volume d'un
   entité de réception audio à afficher par son agent d'interface utilisateur.
   Certains messages Mbus (tels que les requêtes de paramètres ou les requêtes
   serveurs locaux) peuvent exiger une réponse du ou des homologues,
   fournir une reconnaissance explicite au niveau sémantique en plus de
   le Mbus. D'autres messages modifieront l'application ou la conférence
   état et il est donc essentiel qu’ils ne se perdent pas. Le dernier
   le type de message doit être transmis de manière fiable au destinataire,
   alors que les messages du premier type ne nécessitent pas de fiabilité
   mécanismes au niveau de la couche de transport Mbus. Pour les messages confirmés à
   la couche d'application, c'est à la discrétion de l'application
   s'il faut ou non utiliser 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
   transport sous-jacent pour assurer la livraison des messages - et ce
   peut être différent pour chaque message Mbus. Le message Mbus passant
   mécanisme spécifié dans ce document fournit un maximum de
   flexibilité en fournissant une transmission fiable grâce à
   accusés de réception de la couche de transport (en cas de point à point
   communications uniquement) ainsi que la transmission de messages non fiables (pour
   monodiffusion, multidiffusion locale et diffusion locale). Nous abordons cela
   sujet de la section 4.

   Enfin, perturbation accidentelle ou malveillante des communications Mbus
   via les messages provenant d'applications d'autres utilisateurs doivent
   être prévenu. Réception accidentelle de messages Mbus d'autres utilisateurs
   peut se produire si deux utilisateurs partagent le même hôte pour utiliser Mbus
   applications ou s'ils utilisent des applications Mbus qui sont dispersées
   sur la même liaison réseau: dans les deux cas, la multidiffusion Mbus utilisée
   l'adresse et le numéro de port peuvent être identiques conduisant à la réception de
   les messages Mbus de l'autre partie en plus des propres messages de l'utilisateur.
   Des perturbations malveillantes peuvent survenir en raison de la multidiffusion d'applications
   (par exemple, à une portée globale) ou unicast des messages Mbus. Éliminer
   la possibilité de traiter les messages Mbus indésirables, le Mbus
   protocole contient des résumés de messages pour l'authentification. En outre,
   le Mbus permet le cryptage pour assurer la confidentialité et ainsi permettre
   utilisation du Mbus pour la distribution locale des clés et d'autres fonctions
   potentiellement sensible aux écoutes clandestines. Ce document définit le
   cadre de configuration des applications Mbus en matière de sécurité
   paramètres de la section 12.

1.2 Objectif de ce document

   Trois composants constituent le bus de messages: le message de bas niveau
   des mécanismes de passage, 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 de
   le mécanisme de passage des messages Mbus de niveau inférieur qui est commun à tous
   Implémentations Mbus. Cela comprend la spécification de

   o le format de message générique Mbus;

   o le concept d'adressage pour les entités applicatives (notez que
      des schémas d'adressage concrets doivent être définis par application
      profils spécifiques);

   o les mécanismes de transport à employer pour acheminer les messages
      entre des entités d'application (colocalisées);

   o le concept de sécurité pour éviter une mauvaise utilisation du bus de messages (comme
      prendre le contrôle de l'environnement de conférence d'un autre utilisateur);

   o les détails de la syntaxe du message Mbus; et

   o 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 nombreuses applications différentes
   domaines, y compris mais sans s'y limiter:

   Contrôle de conférence locale: dans la communauté Mbone, un modèle est apparu
      par lequel un ensemble d'outils faiblement couplés est utilisé pour participer à
      une conférence. Un scénario typique est que l'audio, la vidéo et le partage
      la fonctionnalité d'espace de travail est fournie par trois outils distincts
      (bien que certains outils combinés existent). Cela correspond bien à la
      sous-jacent RTP [8] (ainsi que d'autres) flux multimédias, qui sont
      également transmis séparément. Compte tenu d'une telle architecture, il est
      utile pour être en mesure d'effectuer une certaine coordination des différents
      outils médiatiques. Par exemple, il peut être souhaitable de communiquer
      informations de point de lecture entre les outils audio et vidéo, dans l'ordre
      pour implémenter la synchronisation labiale, pour arbitrer l'utilisation du partage
      ressources (telles que les périphériques d'entrée), etc.

      Un raffinement de cette architecture repose sur la présence d'un
      nombre de moteurs multimédias qui exécutent également des fonctions de protocole
      comme capture et lecture de médias. De plus, un (ou plusieurs)

      Il existe des agents d'interface utilisateur (séparés) qui interagissent avec et
      contrôler leur (s) moteur (s) média. Une telle approche permet
      flexibilité dans la conception et la mise en œuvre de l'interface utilisateur, mais
      nécessite évidemment des moyens par lesquels les différents agents impliqués
      peuvent communiquer entre eux. Ceci est particulièrement souhaitable
      pour permettre une réponse cohérente à la conférence d'un utilisateur
      actions (comme rejoindre ou quitter une conférence).

      Bien que la pratique actuelle dans la communauté Mbone soit de travailler avec un
      modèle de contrôle de conférence faiblement couplé, des situations surviennent où
      ce n'est pas approprié et une zone étendue plus étroitement couplée
      le protocole de contrôle de conférence doit être utilisé. Dans de tels cas, il
      est hautement souhaitable pour pouvoir réutiliser les outils existants (médias
      moteurs) disponibles pour des conférences faiblement couplées et intégrer
      avec un composant système mettant en œuvre la conférence serrée
      modèle de contrôle. Un moyen approprié pour réaliser cette intégration
      est un canal de communication qui permet une conférence dédiée
      entité de contrôle pour contrôler "à distance" les moteurs de médias en plus
      vers ou à la place de leurs interfaces utilisateur respectives.

   Contrôle des groupes d'appareils dans un réseau: groupe d'appareils
      connecté à un réseau local, par exemple, des appareils ménagers dans une maison
      réseau, nécessitent un mécanisme de coordination local. Minimiser
      configuration manuelle et la possibilité de déployer le groupe
      la communication 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", "REQUIS",
   "DOIT", "NE DOIT PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDÉ", "PEUT",
   et "FACULTATIF" 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] courants
   qui sont référencées 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. le
   les informations suivantes sont incluses dans l'en-tête:

      Un champ ProtocolID fixe identifie la version du bus de messages
      protocole 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. UNE
      un numéro de séquence unique est utilisé pour tous les messages d'une source,
      quels que soient les destinataires visés et le mode de fiabilité
      choisi. La plage de valeurs d'un numéro de séquence est (0,4294967295).
      Une mise en œuvre DOIT réinitialiser son numéro de séquence à 0 après
      atteignant 4294967295. Les implémentations DOIVENT prendre en compte 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
      contiennent un nombre décimal représentant l'heure du message
      construction en millisecondes depuis 00:00:00, UTC, 1er janvier 1970.

      Un champ MessageType indique le type de message envoyé. le
      la valeur "R" indique que le message doit être transmis de manière fiable
      et DOIT être reconnu 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
      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 l'adresse
      éléments et donc adresser n'importe quel nombre (y compris zéro) de
      entités d'application. Le schéma d'adressage est décrit dans
      Section 4.

      Le champ AckList comprend une liste de SeqNums pour lesquels
      le 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
   plus de commandes à livrer à l'entité de destination. La syntaxe
   pour un message complet est donné dans la section 5.

   Si plusieurs commandes sont contenues dans le même message Mbus
   charge utile, ils DOIVENT être livrés à l'application Mbus dans le
   même ordre dans lequel ils apparaissent dans la charge utile du message.

4. Adressage

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

      (tag: valeur tag: valeur ...)

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

      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 le
   symboles non terminaux définis dans la section 2.

   Une adresse_tag DOIT être unique dans une adresse Mbus, c'est-à-dire qu'elle DOIT
   se produire 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
   correspond à tous les éléments ou consiste en un sous-ensemble de sa propre adresse
   éléments. L'ordre des éléments d'adresse dans une séquence d'adresses est
   non pertinent. Deux éléments d'adresse correspondent si leurs balises et
   leurs valeurs sont équivalentes. Équivalence pour l'élément d'adresse et
   chaîne de valeur d'adresse signifie que chaque octet d'une chaîne a le
   même valeur que l'octet correspondant dans la deuxième chaîne. Pour
   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
   toto: bar)

   et

   (toto: bar)

   Un message qui doit être traité par toutes les entités nécessite un
   ensemble 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 le
   La valeur DOIT être composée des éléments suivants:

   o L'adresse IP de l'interface utilisée pour l'envoi des messages
      au Mbus. Pour IPv4, il s'agit de l'adresse en décimal pointé
      notation. Pour IPv6, la partie interface-ID du lien local du nœud
      adresse dans la représentation textuelle comme spécifié dans la RFC 2373 [3]
      Doit être utilisé.

      Dans cette spécification, cette partie est appelée "host-ID".

   o Un identifiant («entity-ID») qui est unique dans le cadre d'un
      ID d'hôte unique. L'entité comprend deux parties. Pour les systèmes
      lorsque le concept d'identifiant de processus est applicable, il est RECOMMANDÉ
      que cet identifiant soit composé en utilisant un process-ID et un per-
      désambiguïsateur de 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 choisi au hasard (il est recommandé qu'au moins 32 bits
      nombre aléatoire est choisi). Les deux nombres sont représentés en décimal
      forme textuelle et DOIT être séparé par un caractère «-» (ASCII x2d).

   Notez que l'ID d'entité ne peut pas être le numéro de port du point de terminaison
   utilisé pour envoyer des messages au Mbus car les implémentations PEUVENT utiliser
   le numéro de port Mbus commun pour l'envoi et la réception du
   groupe de multidiffusion (comme spécifié dans la section 6).

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

      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 nous
   ASCII est un sous-ensemble de UTF-8 et ne nécessite aucun codage supplémentaire, et
   qu'un message encodé avec UTF-8 ne contiendra pas zéro octet.

   Chaque message PEUT être crypté en utilisant un algorithme de clé secrète comme
   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 suivi par 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). Ici
   sont 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 dans
   Section 5.3.

5.3 Syntaxe des commandes

   L'en-tête est suivi de zéro, une ou plusieurs commandes à
   livré aux entités Mbus indiquées par le champ DestAddr. Chaque
   commande se compose d'un nom de commande suivi d'une liste de
   zéro, ou 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 forme d'entier, avec la valeur zéro
   représentant faux et non nul représentant vrai.

   Les paramètres de chaîne dans la charge utile DOIVENT être inclus dans les 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 à être des listes homogènes, c'est-à-dire qu'ils peuvent
   contiennent des paramètres de différents types.

   Les données opaques sont représentées comme encodées en Base64 (voir RFC 1521 [7])
   chaînes de caractères 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 commandes DEVRAIENT être construits hiérarchiquement pour regrouper
   commandes liées conceptuellement sous une hiérarchie commune. le
   le délimiteur entre les noms de 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
   adresses incomplètes en omettant certains éléments d'une adresse
   liste d'éléments, permettant aux entités d'envoyer des commandes à un groupe de Mbus
   entités. Par conséquent, tous les noms de commande DEVRAIENT être sans ambiguïté dans un
   façon dont il est possible de les interpréter ou de les ignorer sans
   compte tenu de l'adresse du message.

   Un ensemble de commandes dans une certaine hiérarchie qui DOIT être compris
   par chaque entité est définie à la section 9.

6. Transport

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

   1. Multidiffusion / diffusion locale:
      Cette classe de transport DOIT être utilisée pour tous les messages qui ne sont pas
      envoyé à une adresse cible pleinement qualifiée. Il PEUT également être utilisé pour
      messages envoyés à une adresse cible pleinement qualifiée. Il
      DOIT être fourni par des implémentations conformes. Voir section 6.1
      pour plus de détails.

   2. Unicast dirigé:
      Cette classe de transport PEUT être utilisée pour les messages qui sont envoyés à un
      adresse de destination pleinement qualifiée. Il est OPTIONNEL et ne
      doivent être fournis par des implémentations conformes.

   Une adresse cible pleinement qualifiée est une adresse Mbus d'un
   Entité Mbus dans une session Mbus. Une implémentation peut identifier un
   Adresse Mbus pleinement qualifiée en conservant une liste des
   entités dans une session Mbus. Chaque entité connue a son 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 DOIVENT PAS être dépassés. Il est RECOMMANDÉ que les applications
   en utilisant une portée non locale de l'hôte, ne dépassez pas une taille de message du lien
   MTU.

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

   Cette spécification traite à la fois Mbus sur UDP / IPv4 et 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 message
   transport. Deux étendues de multidiffusion Mbus différentes sont définies, soit
   dont peuvent être configurés pour être utilisés avec une session Mbus:

   1. local hôte

   2. lien local

   Les participants à une session Mbus doivent connaître l'adresse multicast dans
   avance - il ne peut pas être négocié pendant la session car il 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 attribué avant
   une session Mbus car il n'y aurait pas de mécanisme pour annoncer le
   adresse allouée à toutes les entités Mbus potentielles. Par conséquent, la
   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 un

   spécification de la façon dont une session Mbus peut être configurée pour utiliser des
   adresses standard non attribuées (voir section 12).

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

6.1.1 Groupes multicast Mbus pour IPv4

   Pour IPv4, une adresse de multidiffusion relative à l'étendue attribuée statiquement comme
   défini par RFC 2365 [11] est utilisé. Le décalage pour la portée relative
   l'adresse 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]. L'étendue locale d'IPv4
   (239.255.0.0/16) est la portée minimale englobante pour administrativement
   multidiffusion étendue (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, appliquer les règles de la RFC 2365 [11] et
   en utilisant le décalage assigné de 8, l'adresse de multidiffusion Mbus est
   donc 239.255.255.247.

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

   Multidiffusion hôte-local: sauf configuration contraire, le
      adresse Mbus relative à l'étendue dans l'étendue locale (239.255.255.247 comme
      de la RFC 2365 [11]) DOIT être utilisé. Les datagrammes Mbus UDP DEVRAIENT être envoyés
      avec un TTL de 0.

   multicast link-local: sauf configuration contraire, le
      adresse Mbus relative à l'étendue dans l'étendue locale (239.255.255.247 comme
      de la RFC 2365 [11]) DOIT être utilisé. 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 étendues de multidiffusion et
   distingue les étendues de nœud local et de lien local, qui sont implémentées
   comme un ensemble de préfixes d'adresses pour les différentes plages d'adresses (RFC
   2373 [3]). Le préfixe lien-local est FF02, le préfixe nœud-local est
   FF01. Une adresse multicast attribuée en permanence sera utilisée pour Mbus
   communication multicast, c'est-à-dire une adresse indépendante du
   scope et qui peut être utilisé pour toutes les étendues. Implémentations pour
   IPv6 DOIT utiliser l'adresse indépendante de la portée et l'adresse appropriée
   préfixe pour l'étendue sélectionnée. Pour la communication Mbus hôte-local,
   Le préfixe de portée IPv6 nœud-local DOIT être utilisé, pour le Mbus lien-local
   communication 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 portée tout
   adresse. Cela signifie, 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 seul système d'application est réparti sur plusieurs co-
   hôtes localisés, la portée locale de liaison DEVRAIT être utilisée pour la multidiffusion Mbus
   messages qui ont potentiellement des destinataires sur les autres hôtes. le
   Le protocole Mbus n'est pas prévu (et donc délibérément pas conçu)
   pour la communication entre hôtes non sur le même lien. Voir 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
   au lieu. Dans ces cas, une adresse de diffusion IP pour le
   le réseau DEVRAIT être utilisé 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. C'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 les situations où la multidiffusion est disponible
   et pris 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

   Unicast dirigé (via UDP) vers le port d'une application spécifique est
   une classe de transport alternative à la multidiffusion. Unicast dirigé est un
   Optimisation OPTIONNELLE et PEUT être utilisée par les implémentations Mbus pour
   remise de messages adressés à une seule entité d'application uniquement -
   l'adresse dont l'implémentation Mbus a appris d'autres
   échanges de messages avant. Notez que le champ DestAddr d'un tel
   les messages DOIVENT néanmoins être remplis correctement. Chaque entité Mbus
   DEVRAIT utiliser une seule adresse d'extrémité unique pour envoyer des messages à
   le groupe de multidiffusion Mbus ou vers des entités de réception individuelles. UNE

   l'adresse de point de terminaison unique est un tuple constitué de l'adresse IP de l'entité
   adresse et 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 en monodiffusion si l'adresse cible Mbus est
   unique et si l'entité expéditrice peut vérifier que l'entité réceptrice
   utilise une adresse de point de terminaison unique. Ce dernier peut être vérifié par
   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 de
      le champ d'adresse de destination est utilisé pour envoyer plus loin le
      message. Compte tenu de la définition ci-dessus de l'expression "adresse de point de terminaison unique",
      l'utilisation d'une adresse de point de terminaison partagée et d'un répartiteur permet toujours
      d'autres entités Mbus pour envoyer des messages unicast à l'un des
      entités qui partagent l'adresse du point de terminaison. Donc cela peut ê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 à tous
   Entités Mbus (via multicast si disponible).

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

         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
      d'abord 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 la première adresse comme un
      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. Une adresse
      élément 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 la valeur).

7. Fiabilité

   Alors que la plupart des messages devraient être envoyés en utilisant un
   transport, 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 seulement; c'est-à-dire à une adresse Mbus pleinement qualifiée. Un
   l'entité ne peut donc envoyer des messages fiables qu'à des adresses connues, c'est-à-dire
   il ne peut envoyer des messages fiables qu'aux entités qui ont annoncé
   leur existence sur le Mbus (par exemple, au moyen de messages mbus.hello ()
   tel que défini dans la section 9.1). Une entité expéditrice NE DOIT PAS envoyer de message
   de manière fiable si l'adresse cible n'est pas unique. (Voir la section 6 pour le
   spécification d'un algorithme pour déterminer si une adresse est
   unique.) Une entité réceptrice DOIT uniquement traiter et accuser réception d'un
   message fiable si l'adresse de destination correspond exactement à la sienne
   adresse source (l'adresse de destination NE DOIT PAS être un sous-ensemble du
   adresse source).

   Interdiction de la livraison fiable des messages pour les messages envoyés à plusieurs
   destinations est également motivée par la simplicité de la mise en œuvre
   comme protocole. L'effet souhaité peut être obtenu au
   couche applicative en envoyant des messages individuels fiables à chacun
   adresse de destination pleinement qualifiée, si les informations d'adhésion
   pour la session Mbus est disponible.

   Chaque message est étiqueté avec un numéro de séquence de message. Si la
   MessageType est "R", l'expéditeur attend un accusé de réception du
   destinataire dans un court laps de temps. Si l'acquittement 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), augmentez
   timeout et redémarrez le minuteur. Les messages DOIVENT être retransmis un
   un petit nombre de fois (voir ci-dessous) avant la transmission ou le
   le destinataire est considéré comme ayant échoué. Si le message n'est pas
   livré 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) à prendre.

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

   Les procédures précises sont les suivantes:

   Expéditeur: l'expéditeur A d'un message fiable M adressé au récepteur B DOIT
      transmettre le message 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
      un accusé de réception est reçu de B, le temporisateur T DOIT être annulé et
      la copie de M est supprimée. Si T expire, le message DOIT être
      retransmis, le compteur N DOIT être incrémenté de un, et le
      le temporisateur DOIT être redémarré (réglé sur 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 la demande d'envoi
      DEVRAIT être notifié.

   Récepteur: Un récepteur B d'un message fiable d'un expéditeur A DOIT
      acquitter la réception du message dans un délai T_c <
      T_r. Cela PEUT être fait au moyen d'un accusé de réception dédié
      message ou en superposant l'accusé de réception sur un autre message
      adressée uniquement à A.

   Optimisation du récepteur: dans une implémentation simple, B peut choisir de
      envoyer immédiatement un message d'accusé de réception dédié. Cependant, pour
      efficacité, il pourrait ajouter le SeqNum du message reçu à un
      liste des accusés de réception spécifiques à l'expéditeur; si le SeqNum ajouté est
      le premier accusé de réception de la liste, B DEVRAIT commencer un
      temporisateur d'acquittement TA (initialisé à T_c). Lorsque la minuterie
      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é
      seulement à A, il devrait reprendre les accusés de réception sur ce
      message et annuler TA. Dans les deux cas, B devrait conserver une copie de
      la liste des accusés de réception en une seule entrée dans la copie par expéditeur
      list, conservez cette entrée pendant une période T_k, et videz le
      liste de remerciements. Au cas où l'un des messages conservés dans une entrée
      de la liste de copies est à nouveau reçue de A, l'ensemble
      la liste d'acquittement stockée dans cette entrée est programmée pour (re)
      transmission suivant les règles ci-dessus.

   Constantes et algorithmes: les constantes et algorithmes suivants
      DEVRAIT être utilisé 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
   découvrir mutuellement leur existence. Après ce bootstrap
   procédure que chaque entité Mbus passe par toutes les autres entités
   écouter le même Mbus savoir sur le nouveau venu et le nouveau venu
   a découvert toutes les autres entités. De plus, les entités ont besoin
   pour pouvoir remarquer l'échec (ou la sortie) d'autres entités.

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

   Chaque entité Mbus DOIT maintenir le nombre de membres de session Mbus et
   actualisez en permanence ce nombre en fonction des changements observés.
   Les mécanismes de la façon dont l'existence et la sortie d'autres entités
   peuvent être détectés sont des messages Mbus dédiés pour la reconnaissance des entités:
   mbus.hello (section 9.1) et mbus.bye (section 9.2). Chaque Mbus
   la mise en œuvre du protocole DOIT envoyer périodiquement des messages mbus.hello
   qui sont utilisées par d'autres entités pour surveiller l'existence de ce
   entité. Si une entité n'a pas reçu de messages mbus.hello pour un
   une certaine heure (voir la section 8.2) d'une entité, l'entité respective
   est considéré comme ayant quitté le Mbus et DOIT être exclu de l'ensemble
   d'entités actuellement connues. À la réception d'un mbus.bye
   message que l'entité respective est considérée comme ayant quitté le Mbus
   bien et DOIT être exclu de l'ensemble des entités actuellement connues
   immédiatement.

   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 Hello doit être transmis.
   La transmission des messages Hello NE DOIT PAS être arrêtée à moins que l'entité
   se détache du Mbus. L'intervalle d'envoi des messages d'accueil est
   dépend du nombre actuel d'entités dans un groupe Mbus et peut
   évoluent ainsi dynamiquement afin d'éviter les encombrements dus à de nombreux
   entités envoyant des messages de bonjour à un taux élevé constant.

   La section 8.1 spécifie le calcul des intervalles de message Hello qui
   DOIT être utilisé par les implémentations de protocole. En utilisant les valeurs qui sont
   calculé pour obtenir le minuteur de message Hello actuel, le délai
   pour les messages Hello reçus est calculé dans la section 8.2. Section 9
   spécifie le synopsis de commande pour les messages Mbus correspondants.

8.1 Intervalle de transmission des messages Hello

   Comme le nombre d'entités dans une session Mbus peut varier, il faut
   être pris pour permettre au protocole Mbus de se mettre à l'échelle automatiquement sur une
   large gamme de tailles de groupe. Le taux moyen auquel les messages Hello
   sont reçues augmenterait linéairement jusqu'au nombre d'entités dans un
   session si l'intervalle d'envoi a été défini sur une valeur fixe. Étant donné un
   intervalle de 1 seconde, cela signifierait qu'une entité participant à une
   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 est
   évidemment pas une solution viable pour les grands groupes. Il est donc
   nécessaire pour déployer des intervalles de messages Hello adaptés dynamiquement,
   en tenant compte d'un nombre variable d'entités. Dans ce qui suit,
   nous spécifions un algorithme qui DOIT être utilisé par les implémenteurs pour
   calculer l'intervalle pour les messages bonjour en tenant compte des
   nombre d'entités Mbus.

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

   o Le nombre de messages Hello reçus par une seule entité
      dans une certaine unité de temps reste approximativement constante car le
      le nombre d'entités change.

   o L'intervalle effectif utilisé par une entité Mbus spécifique est
      randomisé afin d'éviter la synchronisation involontaire de
      Bonjour les messages dans une session Mbus. Le premier bonjour message de
      une entité est également retardée d'un certain laps de temps aléatoire.

   o Un mécanisme de reconsidération de la minuterie est déployé afin d'adapter
      l'intervalle plus approprié dans les situations où un changement rapide
      du nombre d'entités est observé. Ceci est utile lorsqu'un
      l'entité rejoint une session Mbus et est toujours en train d'apprendre
      l'existence d'autres entités ou lorsqu'un plus grand nombre d'entités
      quitte immédiatement le Mbus.

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 un Mbus
      entité.

   hello_now: l'heure actuelle

   hello_d: l'intervalle calculé déterministe entre bonjour
      messages.

   hello_e: L'intervalle effectif (aléatoire) entre les messages Hello.

   hello_n: L'heure de la prochaine transmission programmée d'un bonjour
      message.

   entity_p: Le nombre d'entités au moment où hello_n a été la dernière
      recalculé.

   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 dans
   millisecondes. C'est l'intervalle calculé déterministe, noté
   Allô 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 spécifie comment obtenir le nombre de
   entités actuellement connues. La section 10 fournit des valeurs pour
   constantes c_hello_factor et c_hello_min.

   L'intervalle effectif hello_e qui doit être utilisé par l'individu
   entités est calculée en multipliant hello_d par un
   nombre 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 donne une distribution uniforme
   entre 0 et 1. Voir également la section 10.

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

8.1.2 Initialisation des valeurs

   Lors de la participation à une session Mbus, une implémentation de protocole
   hello_p = 0, hello_now = 0 et entités = 1, entity_p = 1 (l'entité Mbus
   lui-même), puis calcule l'heure du prochain message bonjour comme
   spécifié à la section 8.1.1. Le prochain message de bienvenue est prévu pour
   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 un protocole
   mise en œuvre le nombre d'entités actuellement connues est mis à jour. Non
   action complémentaire concernant le calcul du message Hello
   l'intervalle est requis. La reconsidération de l'intervalle du timer
   a lieu lorsque le minuteur actuel du prochain message bonjour expire
   (voir 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 de
   les entités actuellement connues sont mises à jour et l'algorithme suivant
   doit être utilisé pour reconsidérer l'intervalle du minuteur 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) * (bonjour_now - bonjour_p)

   3. Le minuteur actuellement actif pour les prochains messages Hello est
      annulé et un nouveau minuteur démarre pour hello_n.

   4. entity_p est défini sur entités.

8.1.5 Expiration des minuteries Hello

   Lorsque le minuteur 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
         calculé à nouveau comme spécifié dans la section 8.1.1 et hello_n est
         mis à hello_e + hello_now.

      2. ELSE SI hello_e + hello_p> hello_now ALORS hello_n est défini sur
         bonjour_e + bonjour_p. Un nouveau minuteur pour le prochain message bonjour est
         a commencé à 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 une période de
   c_hello_dead * (hello_d * c_hello_dither_max) millisecondes d'un autre
   Entité Mbus, il peut considérer que cette entité a échoué (ou avoir 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 que non
   la nécessité de toute action supplémentaire en est nécessairement implicite
   observation.

   La section 8.1.1 spécifie comment obtenir hello_d. L'article 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
   DOIT être compris par toutes les implémentations; ces messages sont
   nécessaire au bon fonctionnement du Mbus. Cette spécification fait
   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 Mbus séparé
   profils.

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 découvre d'autres entités Mbus en observant leur
   mbus.hello messages et suivi de l'adresse de l'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 de manière dynamique
   intervalles calculés comme spécifié dans la section 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 section 10).

9.2 mbus.bye

      Syntaxe: mbus.bye ()

      Paramètres: - aucun -

   Une entité Mbus sur le point de se terminer (ou de "se détacher" du Mbus)
   DEVRAIT l'annoncer en transmettant un message mbus.bye. le
   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 protocole
   l'implémentation DOIT comprendre mbus.ping et répondre avec un mbus.hello
   message. 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 section 10). Plusieurs messages mbus.ping PEUVENT être
   répondu par un seul mbus.hello: si un ou plusieurs autres mbus.ping
   les messages sont reçus pendant que l'entité attend hello_delay time
   unités avant de transmettre le message mbus.hello, pas de mbus.hello supplémentaire
   message doit être programmé pour ces messages mbus.ping supplémentaires.

   Comme spécifié dans la section 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 au ping
   messages. Une entité qui répond à mbus.ping avec mbus.hello DEVRAIT
   arrêter tous les minuteurs en attente pour les messages de bonjour après l'envoi du
   Bonjour message et programmez un nouvel événement de minuterie pour le bonjour suivant
   message. (Notez qu'en utilisant les variables et les algorithmes de
   Section 8.1.1 ceci 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 d'accueil individuels réguliers. Par
   spécifiant une adresse cible, la nouvelle entité peut restreindre
   sollicitation de messages bonjour à un sous-ensemble d'entités dont il s'agit
   intéressé par.

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
   eux-mêmes (et se détacher du Mbus). Si cette demande est
   honoré par les entités destinataires ou non est spécifique à l'application et
   non défini dans ce document.

   Le message mbus.quit peut être multicast ou envoyé de manière fiable via unicast
   à 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 de condition est utilisé pour indiquer que l'entité
         la transmission de ce message attend un événement particulier pour
         se produire.

   Une entité Mbus DEVRAIT être en mesure d'indiquer qu'elle attend un
   certain événement se produit (similaire à une opération P () sur un sémaphore
   mais sans créer d’état extérieur ailleurs). En conjonction
   avec cela, une entité Mbus DEVRAIT être capable d'indiquer à un autre
   entité que cette condition est maintenant satisfaite (similaire à un sémaphore
   Opération V ()).

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

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

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 en "débloquer" une autre
   Entité Mbus - qui a indiqué qu'elle attend un certain
   condition à remplir. Une seule condition peut être spécifiée par
   Message mbus.go. Si plusieurs conditions sont remplies simultanément
   plusieurs messages mbus.go PEUVENT être combinés dans une seule charge utile Mbus.

   Le message mbus.go DOIT être envoyé de manière fiable via unicast au Mbus
   entité à débloquer.

10. Constantes

   Les valeurs suivantes pour les minuteries et les compteurs mentionnés dans ce
   le document DEVRAIT être utilisé 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 de Mbus
   communications via des messages provenant d'applications d'autres
   utilisateurs, l'authentification des messages est déployée (section 11.3). Pour chaque
   message, un condensé DOIT être calculé en fonction de la valeur d'un
   valeur de clé secrète. Les destinataires des 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 uniquement
   traité davantage si les deux valeurs sont égales. Afin de permettre
   différentes sessions Mbus simultanées à un périmètre donné et à
   compenser les implémentations défectueuses de la multidiffusion locale hôte, message
   l'authentification DOIT être fournie par des implémentations conformes.

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

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

   Les algorithmes et procédures d'application du cryptage et
   les techniques d'authentification sont spécifiées 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 à certains
   les octets de limites avec une valeur de 0 DEVRAIENT être utilisés pour le remplissage
   personnages.

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

   Les implémentations DES DOIVENT utiliser le chaînage de blocs de chiffrement DES (CBC)
   mode. Les clés DES (56 bits) DOIVENT être codées sur 8 octets comme décrit dans
   RFC 1423 [12], résultant en 12 caractères codés en Base64. IDEA utilise
   Clés 128 bits (24 caractères codés en base64). AES peut utiliser soit
   Clés 128 bits, 192 bits ou 256 bits. Pour le cryptage Mbus utilisant AES uniquement
   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, les codes d'authentification des messages 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é dans le
   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 le
      la clé de hachage secrète DOIT être obtenue à partir de la configuration Mbus (voir
      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 RFC 1521 [7]).

   Soit MD5 [15] ou SHA-1 [17] DEVRAIT être utilisé pour le message
   codes d'authentification (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 le hachage sélectionné
   algorithme. 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é.

11.4 Procédures pour les expéditeurs et les destinataires

   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 du
      l'algorithme configuré et la clé de chiffrement configurée. Rembourrage
      (ajout de caractères supplémentaires) pour les chiffrements par blocs DOIVENT être appliqués comme
      spécifié dans la section 11.2. Si le cryptage n'est pas activé, le
      le message reste inchangé.

   2. Ensuite, un code d'authentification de message (MAC) pour le
      (crypté) le message DOIT être calculé en utilisant le HMAC configuré
      algorithme et la clé de hachage configurée.

   3. Le MAC DOIT ensuite être converti en codage Base64, ce qui entraîne 16
      Caractères Base64 comme spécifié dans la Section 11.3.

   4. Enfin, l'expéditeur DOIT construire le message final en plaçant
      le message (crypté) après le MAC encodé 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écoder le MAC.

   2. Recalculez le MAC du message à l'aide du HMAC configuré.
      algorithme et 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é à l'aide du
      l'algorithme configuré et la clé de chiffrement configurée. Trailing
      les octets avec une valeur de 0 DOIVENT être supprimés. Si le message ne

      commencez par la chaîne "mbus /" le message DOIT être ignoré
      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. Version
         les nombres permettent aux implémentations de vérifier si elles peuvent traiter
         entrées d'une entité de configuration donnée. Les numéros de version sont
         valeurs entières. Le numéro de version de la version spécifiée
         voici 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 Mbus
   entité de configuration.

   Les paramètres suivants sont facultatifs. Quand ils sont présents, ils
   DOIT être honoré. 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

         L'adresse de multidiffusion non standard à utiliser pour le message
         transport.

      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 le
         adresse de diffusion du réseau (comme spécifié dans la section 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 installations distinctes pour le stockage des paramètres sont envisagées:
   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 que DEVRAIT être utilisé. Pour les autres systèmes, il est RECOMMANDÉ
   que le mécanisme de configuration basé sur les fichiers est utilisé.

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

   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. Les virgules de délimitation
   DOIT toujours être présent cependant.

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

   Le paramètre scope est utilisé pour configurer une étendue IP-Multicast et
   peut être réglé sur "HOSTLOCAL" ou "LINKLOCAL". Implémentations
   DEVRAIT choisir une étendue IP-Multicast appropriée en fonction du

   valeur de ce paramètre et construire une adresse IP efficace
   compte tenu des spécifications de la section 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 implémentations DEVRAIENT utiliser l'adresse de diffusion du réseau pour le
   Version IP au lieu de l'adresse de multidiffusion standard.

   Le paramètre numéro_version spécifie un numéro de version pour le
   entité de configuration.

12.1 Stockage des paramètres basé sur un fichier

   Le nom de fichier d'un fichier de configuration Mbus est ".mbus" dans le fichier de l'utilisateur
   répertoire personnel. 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 complet à utiliser pour la configuration
   fichier. Les implémentations DOIVENT s'assurer que ce fichier a
   autorisations de fichier qui empêchent d'autres utilisateurs de le lire ou de l'écrire. le
   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,
   ils DOIVENT être présents dans chaque fichier de configuration Mbus. L'ordre de
   les entrées ne sont pas significatives.

   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 qui n'ont pas le concept de répertoire personnel d'un utilisateur en tant que lieu
   pour les fichiers de configuration la base de données suggérée pour la configuration
   paramètres (par exemple, Windows9x, Windows NT, Windows 2000, Windows XP
   registre) DEVRAIT être utilisé. La hiérarchie du registre lié à Mbus
   entrées est comme suit:

      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 configuration basée sur un fichier
   l'installation 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
   implémentations. Cet ensemble de base est destiné à fournir des
   sécurité en imposant des algorithmes et des longueurs de clé qui sont pris en compte
   être suffisamment fort cryptographiquement au moment de la rédaction.

   Cependant, afin de permettre l'efficacité, il est permis d'utiliser
   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 assurée par d'autres moyens ou n'est pas considérée comme importante pour un
   certaine application.

   Les utilisateurs du Mbus doivent donc être conscients de la sécurité sélectionnée
   configuration et doit vérifier si elle répond aux exigences de sécurité pour un
   application donnée. Puisque chaque implémentation DOIT fournir le
   algorithme cryptographiquement fort, il devrait toujours être possible de
   configurer un Mbus de manière à sécuriser la communication avec
   l'authentification et la confidentialité sont assurées.

   En aucun cas, les développeurs d'applications doivent être conscients des adresses IP incorrectes
   implémentations qui ne sont pas conformes à la RFC 1122 [2] et envoient
   datagrammes avec des valeurs TTL de zéro, ce qui entraîne l'envoi de messages Mbus à
   le lien réseau local bien qu'un utilisateur ait pu sélectionner l'hôte local
   portée dans la configuration Mbus. Lors de l'utilisation à portée administrative
   multidiffusion, les utilisateurs ne peuvent pas toujours supposer la présence de
   routeurs périphériques configurés. Dans ces cas, l'utilisation du cryptage
   DEVRAIT être considéré si la confidentialité est souhaitée.

14. Considérations IANA

   L'IANA a attribué une adresse multicast relative à la portée avec un
   offset de 8 pour Mbus / IPv4. L'adresse multicast 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 l'exigence
         Niveaux », BCP 14, RFC 2119, mars 1997.

   [2] Braden, R., «Conditions requises pour les hôtes Internet - 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, "Adresse de multidiffusion IPv6
         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) Première partie: mécanismes de spécification et de description
         the Format of Internet Message Bodies ", RFC 1521, septembre
         1993.

   [8] Schulzrinne, H., Casner, S., Frederick, R. et V. Jacobsen,
         "RTP: un protocole de transport pour les applications en temps réel", 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., "Multidiffusion IP à portée administrative", BCP 23, RFC
         2365, juillet 1998.

   [12] Balenson, D., "Amélioration de la confidentialité pour Internet Electronic
         Courrier: partie III: algorithmes, modes et identifiants ", RFC 1423,
         Février 1993.

   [13] Crocker, D. et P. Overell, "BNF augmenté pour la syntaxe
         Spécifications: ABNF ", RFC 2234, novembre 1997.

   [14] Myers, J., "Extension de service SMTP pour l'authentification", RFC
         2554, mars 1999.

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

   [16] US DEPARTMENT OF COMMERCE / National Institute of Standards et
         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 et
         Technology, «Secure Hash Standard», FIPS PUB 180-1, avril 1995.

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

   [19] IANA, "Adresses de multidiffusion Internet", URL
         http://www.iana.org/assignments/multicast-addresses, mai 2001.

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

Annexe A. À propos des références

   Veuillez noter que la liste des références contient à la fois normative et
   références 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 pas conçu pour une coordination de plus grande envergure. Il est
   devrait être utilisé sur un seul nœud ou - tout au plus - sur un seul
   lien réseau.

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

      Il n'existe aucun mécanisme permettant de contrôler la congestion. Le problème
      du contrôle de la congestion est un problème général pour la multidiffusion
      protocoles. Le Mbus autorise les messages non acquittés
      envoyés de manière non fiable, par exemple sous forme de notifications d'événements, à partir d'un
      entité à une autre. Puisque les accusés de réception négatifs ne sont pas
      défini il n'y a aucun moyen pour l'expéditeur de réaliser qu'il est
      inonder une autre entité ou encombrer un réseau à faible bande passante
      segment.

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

   Certaines expériences sont actuellement en cours pour tester l'applicabilité de
   ponts entre différents domaines Mbus distribués sans changement
   la sémantique de base du protocole. Puisque l'utilisation de tels ponts devrait
   être orthogonale aux définitions de base du protocole Mbus et puisque celles-ci
   des expériences sont toujours en cours, il n'est pas question de cela
   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 à
   d'autres, et des œuvres dérivées qui le commentent ou l'expliquent autrement
   ou aider à sa mise en œuvre peut être préparé, copié, publié
   et distribué, en tout ou en partie, sans restriction d'aucune
   genre, à 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
   le 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 aux fins de
   élaborer des normes Internet, auquel cas les procédures
   les droits d'auteur définis dans le processus des normes Internet doivent être
   suivi, ou au besoin pour le traduire dans des langues autres que
   Anglais.

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

   Ce document et les informations qu'il contient sont fournis sur un
   Base "TEL QUEL" et LA SOCIÉTÉ INTERNET ET L'INGÉNIERIE INTERNET
   TASK FORCE DÉCLINE TOUTE GARANTIE, EXPRESSE OU IMPLICITE, Y COMPRIS
   MAIS SANS S'Y LIMITER UNE GARANTIE QUE L'UTILISATION DES INFORMATIONS
   LES PRÉSENTES NE VIOLENT AUCUN DROIT NI AUCUNE GARANTIE IMPLICITE DE
   QUALITÉ MARCHANDE OU ADÉQUATION À UN USAGE PARTICULIER.

Reconnaissance

   Le financement de la fonction RFC Editor est actuellement assuré par le
   Société Internet.