De nombreux protocoles d'administration existent : Broadband Forum TR-69 [TR6904], OMA DM [OMAD05], SNMP [SNMP02], DMTF WS-Management [WSMa06], IETF Netconf [Netc06], OASIS MUWS [MUWS05], JCP JMX [JMX02]. Les trois premiers sont probablement les plus importants sur le marché du réseau domestique. Le quatrième est intéressant pour son alignement sur la technologie des Web Services et sa complémentarité avec l'ensemble protocolaire DPWS [DPWS06].
3.2.1 Spécifications du Broadband Forum : TR-069, TR-106, etc.
Le Broadband Forum (ex-DSL Forum, www.broadband-forum.org) est une organisation fondée en 1994 et qui compte plus de 200 membres aujourd'hui. Depuis lors, de nombreuses spécifications se sont répandues, non seulement sur le marché des réseaux et équipements DSL mais aussi sur d'autres types de technologies réseau. Si son succès repose aujourd'hui principalement sur la gestion des passerelles Internet domestiques, ses spécifications touchent la gestion de nombreux équipements du réseau domestiques (Set-Top-Box, applications VoIP, etc.).
Le protocole d'administration qui se répand aujourd'hui est le protocole TR-069 (Technical Report 069) [TR6904] appelé CPE WAN Management Protocol (CWMP, cf. Figure 33). Ce protocole, associé notamment au TR-106, normalise un modèle de données générique et des opérations sur ce modèle de données. Il adresse les fonctions principales de l'administration d'équipements (cf. section 3.1.1) en restreignant la gestion du cycle de vie logiciel à celle du micrologiciel et en ouvrant la supervision à la gestion des fichiers de journalisation.
Figure 33 Architecture d'administration de bout en bout du Broadband Forum – www.broadband-forum.org
Les interactions sont définies entre un serveur d'administration distant nommé ACS (Auto-Configuration Server) et l'équipement administré nommé CPE (Customer Premises Equipment). Généralement, le CPE initie la connexion avec l'ACS. L'ACS ne peut initier la connexion que lorsque le CPE possède une adresse visible, ce qui est rarement le cas pour les équipements du réseau domestiques où les adresses ne sont visibles que localement. Les exceptions étant la passerelle Internet et les équipements d'un réseau IPv6. Les connexions permettent l'inventaire des équipements à administrer. Un modèle de données est défini afin de décrire ces équipements. Les connexions périodiques et événementielles entre le CPE et l'ACS permettent les envois d'opérations vers le CPE et la notification de l'ACS d'événements s'effectuant sur le CPE. La sécurité est restreinte à l'authentification d'un unique ACS et du cryptage éventuel des données échangées. L'ACS étant unique pour un CPE, l'aspect transactionnel d'isolation n'est l'objet d'aucune spécification. En revanche, l'atomicité des opérations effectuées est l'objet de la spécification de session entre ACS et CPE.
Le modèle de données suit une approche générique. Chaque équipement est décrit selon un modèle de paires noms-valeurs (cf. le contenu de la réponse décrite dans la Figure 30). La hiérarchie du modèle se vérifie dans la hiérarchie des noms. Chaque paramètre a pour nom la concaténation d'un chemin énumérant les parents jusqu'au paramètre-feuille, le séparateur étant le '.'. Par exemple, le paramètre dont la valeur est le nombre d'octets envoyés depuis le dernier redémarrage de la passerelle Internet a pour nom "InternetGatewayDevice.LAN.Stats.TotalBytesSent".
Les opérations sur ce modèle de données sont :
• GetParameterValues : obtenir les valeurs de paramètres. Le nommage des éléments est toujours absolu (chemins définis à partir de la racine de l'arbre de données). Aucun opérateur de sélection n'est défini en supplément de ce nommage simple.
• SetParameterValues : modifier les valeurs de paramètres.
• GetParameterAttributes : obtenir les attributs de paramètres. Les attributs principaux des paramètres sont le mode lecture seule ou écriture et le mode de notification de changements).
• SetParameterAttributes : modifier les attributs de paramètres.
• AddObject : ajouter un objet (sous-arbre) dans une table multi-objets.
• DeleteObject : supprimer un objet.
• Download : télécharger un fichier.
• Reboot : redémarrer l'équipement.
Les événements sont remontés selon deux opérations de notification
• Inform : notifier d'un changement de paramètre.
• TransferComplete : informer de l'achèvement d'un transfert.
Le succès des protocoles du Broadband Forum s'expliquent par la simplicité du modèle de données et du protocole TR-069 et évidemment par l'effort uni de lobbying des opérateurs auprès de leurs fournisseurs et partenaires au sein de l'importante organisation du Broadband Forum. Un des défauts de cet ensemble protocolaire est la non-adoption de celui-ci par les fabricants d'équipements domestiques autres que ceux délivrés dans les services des opérateurs (passerelle, Set-Top-Box). Les équipements multimédia et domotique demeurent administrés par d'autres protocoles ou sont exempts de protocoles d'administration. La création du Comité de Travail UPnP Execution Platform résulte en partie de ce manque. L'autre raison est la non-adéquation des protocoles existants tels que ceux du Broadband Forum à une administration des équipements par les équipements du réseau domestique eux-mêmes (applications de self-care).
3.2.2 OMA DM et SCOMO
OMA DM (Device Management) [OMAD05] et SCOMO (Software COmponent Management Object) [SCOM08] sont des spécifications de l'OMA (Open Mobile Alliance), un organisme fondé en Juin 2002 et comptant aujourd'hui plus de 200 membres. L'OMA normalise les protocoles et modèles de données utiles sur le marché du téléphone mobile.
L'OMA DM est un ensemble protocolaire qui permet la configuration, le diagnostic et la supervision de performances d'équipements embarqués. SCOMO ajoute à cet ensemble la gestion du cycle de vie des applications sur ces équipements. Tandis que l'OMA DM normalise un modèle de données générique et les opérations de manipulations de celui-ci, SCOMO normalise des modèles de module logiciel, leurs diagrammes d'états et les opérations de gestion associées.
De manière similaire au protocole TR-069, seul l'équipement administré initie les connexions avec le serveur. Un équipement peut être administré par plusieurs serveurs appelés RM (Remote Manager). Les opérations spécifiées sur le modèle de données permettent le contrôle synchrone des équipements et la notification des serveurs. OMA DM définit le moyen d'authentifier ces RMs, de leur affecter des droits dans des Listes de Contrôle d'Accès (Access Control Lists) et de garantir l'intégrité des messages. Les messages "Atomic" et "Sequence" sont définis afin de définir des séquences d'opérations atomiques et isolées.
Le modèle de données suit une approche générique. Chaque équipement est décrit selon un arbre de données retranscrit dans un modèle générique proche du systèmes de paires nom-valeur de TR-069. Un nœud possède une valeur qui peut être obtenue (Get), remplacée (Replace), ou exécuté (Exec) suivant la sémantique du nœud et des droits associés aux serveurs.
Les opérations sur ce modèle de données sont :
• Get : obtenir la valeur d'un nœud de l'arbre de données (feuille ou sous-arbre).
• Replace : remplacer la valeur d'un nœud de l'arbre.
• Add : ajouter un nœud à l'arbre.
• Delete : supprimer un nœud de l'arbre.
• Exec : exécuter la valeur d'un nœud de l'arbre
• Copy : copier ou déplace un nœud de l'arbre.
• Atomic : spécifier le caractère atomique de l'exécution des opérations subordonnées à cette commande.
• Sequence : spécifier un ordre à l'exécution des opérations subordonnées. Les événements sont remontés selon l'opération de notification suivante :
• Alert
Le protocole OMA DM est en passe d'être progressivement déployé sur les équipements mobiles. L'effort uni des opérateurs et des fabricants de téléphones portables assure le succès de la spécification. Toutefois, sa provenance d'un protocole plus complexe, SyncML DM, et la relative complexité apparente des messages de configuration n'en font pas une spécification claire. SCOMO est intéressant dans le cadre des travaux du Comité UPnP Device Management car il résulte d'une démarche similaire de représenter un modèle général de modules logiciels qui s'adapterait à la plupart des modèles définis par les technologies de plateformes existantes. Comme le modèle SCOMO peut être comparé à ces modèles existants, SCOMO est décrit avec détails dans la partie intitulée Plateformes d'exécution (cf. section 3.3.5).
3.2.3 SNMP
SNMP (Simple Network Management Protocol) [SNMP02] est une spécification de l'IETF (Internet Engineering Task Force). Cette spécification apparut dans sa première version en 1988. Par la suite, deux autres versions vinrent l'améliorer. Aujourd'hui, de nombreux équipements sont administrables selon ce protocole, notamment les équipements de routages réseau et quelques équipements domestiques de type passerelle Internet et Set-Top-Box.
Les 3 versions de SNMP permettent la configuration, le diagnostic et la supervision de performances des équipements. Il n'adresse pas la gestion de cycle de vie logiciel. SNMP normalise un modèle de données de type générique et un ensemble réduit d'opérations pour la manipulation de celui-ci.
SNMP définit un modèle de description simple d'équipements, des opérations et des événements liés à sa manipulation. La version 3 de SNMP spécifie les aspects d'authentification et d'intégrité des messages. Le protocole permet l'administration d'un équipement par plusieurs administrateurs. En particulier, il définit l'atomicité de l'opération de modification de plusieurs paramètres (Set) et, de plus, un mécanisme de 2 phase commit pour la configuration de plusieurs équipements dans une seule session atomique. En revanche, le protocole n'indique pas la manière de découvrir les équipements décrits selon ce protocole.
Le modèle de données suit une approche générique similaire à celle du protocole TR-069 (cf. section 3.2.1). Chaque équipement est décrit selon un modèle arborescent tabulaire.
• Get : obtenir la valeur d'un paramètre.
• GetNext : obtenir la valeur du paramètre suivant dans un tableau de paramètres.
• GetBulk : obtenir la valeur de plusieurs paramètres dans un tableau.
• Set : modifier la valeur d'un ou plusieurs paramètres.
Les événements sont remontés selon l'opération de notification suivante :
• Trap : remonter une alerte à un administrateur.
De par sa simplicité et son ancienneté, ce protocole est encore utilisé aujourd'hui sur de nombreux appareils. Toutefois, le consensus grandissant autour de TR-069 sur le réseau domestique et d'OMA DM sur le réseau mobile font décliner son importance sur ces environnements.
3.2.4 DMTF WS-Management
WS-Management est un protocole récent qui repose sur de nombreux protocoles de la technologie Web Services. De façon a priori étonnante, ce protocole aligné sur les Web Services n'est spécifié ni par le W3C ni par OASIS. Le DMTF (Distributed Management Task Force) a pris l'initiative de cette spécification afin de consolider la promotion de ces nombreux modèles de données objets dont la traduction en tant que spécifications XML est disponible : CIM (Common Information Model), CDM (Common Diagnostics Model), SMBIOS (System Management BIOS), DASH (Desktop and mobile Architecture for System Hardware), etc.
Ce protocole permet la configuration, le diagnostic et la supervision de performance d'équipements embarqués. Il n'adresse pas la gestion de cycle de vie logiciel. De même que les autres protocoles décrits, WS-Management spécifie un ensemble réduit d'opérations pour la manipulation d'un modèle données.
WS-Management est associé à WS-Eventing pour la souscription et la résiliation de souscription à des événements, et à WS-Security et WS-Trust pour l'authentification et la garantie de l'intégrité des échanges. Il peut être associé à DPWS (cf. section 1.1.3) pour la découverte d'équipements. Rien n'est explicitement spécifié pour l'atomicité et l'isolation des opérations de modifications de l'arbre de données de l'équipement mais la spécification pourrait être associée à WS-AtomicTransaction pour la gestion des aspects transactionnels des échanges (Atomicité, Cohérence, Isolation, Durabilité). WS-AtomicTransaction définit en particulier un protocole "2 phase commit".
Le modèle de données des équipements doit seulement suivre le modèle XML général afin de pouvoir être administrés. L'approche est donc relativement spécifique aux équipements ("device-specific"). Peu de protocoles suivent cette approche (Netconf est un autre exemple) car la spécification et l'implémentation des opérations est plus complexe en raison de la généralité du modèle.
Les opérations sur ce modèle de données sont :
• Get : obtenir la valeur d'un paramètre ou d'un sous-arbre. La sélection du paramètre ou du nœud suit la spécification XPath, qui permet la définition d'un ensemble riche de filtres sur des données XML. La méthode peut aussi être utilisée pour obtenir la liste des espaces de noms XML (namespaces) supportés par l'équipement.
• Put : modifier la valeur d'un paramètre ou d'un sous-arbre.
• Create : créer une instance d'un objet dans une séquence d'objets.
• Enumerate, Pull, Release : respectivement initier, continuer, annuler une énumération d'instances d'une séquence d'objets.
WS-Management est encore peu utilisé. Comme DPWS, ce protocole est déjà implémenté dans le serveur d'exploitation Microsoft Vista. La généralité du protocole, son alignement sur la technologie des Web Services et le succès des technologies XML sont ses atouts techniques. La puissance de vente de Microsoft étaie l'importance à venir de ce protocole sur le marché du réseau domestique et de l'entreprise.