Universal Plug and Play (UPnP)

(1)

Universal Plug and Play (UPnP)

(*) Cours réalisé grâce aux documents de : Didiez Donsez, Stéphane Lavirotte,

Jean-Yves Tigli

Mail: Stephane.Lavirotte@unice.fr Web: http://stephane.lavirotte.com/

Université de Nice - Sophia Antipolis

Présentation: Stéphane Lavirotte Auteurs: … et al*

(2)

Pour un bon départ

Introduction

(3)

Motivations

 Fournir une infrastructure « invisible » (auto-adaptable) pour le Small Office Homme Office (SOHO)

 Réseau

– Dynamique et éphémère – Sans administration

 Nœuds

– Auto-configurables – Auto-descriptifs

(4)

Contraintes imposées de mise en œuvre

 Limitation à de l’envoi de données sur le réseau

– Pas d’exécutables circulant sur le réseau – Minimiser les versions

– Minimiser les aspects sécurité

 Conserver le code de l’application « privé »

– Etre agnostique par rapport au réseau, à l’OS, au langage de programmation

– Mise à jour de l’implémentation sans affecter l’interopérabilité

 Augmenter les performances

 Augmenter les possibilités

 Etre d’accord sur le format et le sens des données

– Choix de protocoles éprouvés (W3C, IETF)

– Définition des Dispositifs et Services par un Forum

(5)

Introduction

 Le forum UPnP™

– une initiative industrielle

– Conçue pour permettre la connectivité simple et robuste entre dispositifs de différents fournisseurs

 L'architecture d'UPnP permet la découverte puis le contrôle de dispositifs sur un réseau, indépendant

– Des OS

– Des langages de programmation, – Des réseaux physiques et locaux.

 La technologie d'UPnP s’appuie pour cela sur des

normes existantes IP, UDP et TCP, HTTP, XML et SOAP

 http://www.upnp.org/

(6)

Architecture UPnP

 Control Point (Point de Contrôle)

– Agit sur les équipements (le client)

 Device (Dispositif, équipements)

– Fournit des services (le serveur)

 Un dispositif peut contenir les deux

Network

Network1 Internet

^NAT

Network2

Bridge NAT

Control Point

Device2

Service Service

Device1

Service

Control Point Device3

Service

(7)

Schémas de Principe

UPnP: Comment ça marche ?

(8)

Terminologie UPnP

1. Un point de contrôle et des dispositifs obtiennent une adresse

2. Un point de contrôle trouve les dispositifs intéressants 3. Un point de contrôle découvre les capacités du dispositif 4. Un point de contrôle déclenche une action du dispositif 5. Un point de contrôle écoute les changement d’état des

dispositifs

6. Un point de contrôle commande les dispositifs ou visualise les changements d’état par l’interface HTML du dispositif

1. Adressage

2. Découverte

3. Description

6. Présentation 5. Evènements

4. Contrôle

(9)

Sous-Système UPnP côté Dispositif

Network

Device

Description

Events generated by the device

Events notification Eventing

Event subscription Control

Control Request Action Request

Control Response

Action Response

Device Advertisements over SSDP channel

Discovery

Discovery Search Addressing

DHCP Auto-IP

(10)

Sous-Système UPnP côté Point de Contrôle

Control

Control Request

Eventing

Event

subscription Events notification

Control Response Discovery

Search Discovery Response Discovery

Presentation Control point user

Network Addressing

DHCP Auto-IP

(11)

Overview of the Intel

^®

Tools for UPnP Technologies

 Ylian Saint-Hilaire

– Senior Architect

Présentation d’

(12)

Détail des piles et protocoles utilisés et mis en œuvre par UPnP

Piles et Protocoles UPnP

(13)

Piles et protocoles UPnP

 La suite de protocoles HTTP/TCP/IP fournissent la connectivité de base de réseau pour UPnP.

 Chaque phase UPnP est reliée à des protocoles de réseau plus ou moins standards.

Description XML

Contrôle SOAP

Evènement GENA

Présentation HTML Découverte

SSDP Adressage

DHCP / Auto IP

HTTP TCP UDP

HTTPU/MU

UPnP Device Architecture UPnP Forum Working Commitee

UPnP Vendor

(14)

Adressage

 Points de contrôle et dispositifs recherche une adresse

– Utilisation d’un serveur DHCP – Sinon, utilisation de Auto-IP

 Qu’est ce que c’est que Auto-IP ?

– IETF Draft Automatically Choosing an IP Address in an Ad-Hoc IPv4 Network

 Quelles sont les étapes de Auto-IP ?

– Prendre une adresse dans l’intervalle 169.254/16 – Vérification de la non utilisation de l’adresse

– Recherche périodique d’un serveur DHCP

(15)

Découverte

 Le Point de Contrôle

– recherche les dispositifs

intéressants

 0 récupère l’adresse

 1 découvre le dispositif

– Avertit / Trouve les dispositifs typés

(services)

 Garantie de capacités minimales

– Simple

 Le Dispositif

– Avertit quand il rejoint le réseau

– Rafraîchit

l’avertissement (lease) – Annule

l’avertissement quant il se retire

 Le Point de contrôle recherche au besoin

– Le dispositif répond – Le Point de Contrôle

filtre

(16)

Découverte: Pile du protocole

IP UDP

UPnP Device Architecture Defined UPnP Forum Working Commitee Defined

UPnP Vendor Defined

HTTPMU

(multicast) GENA SSDP HTTPU

(Unicast) SSDP

(17)

Découverte: SSDP

 Qu’est ce que c’est SSDP

– IETF Draft Simple Service Discovery Protocol (expiré) – Proposé par Microsoft et Hewlett-Packard

– Il peut être utilisé par des dispositifs démarrant pour notifier aux autres leur présence.

– Il peut être employé par des points de contrôle essayant de trouver un service (demande une recherche pour un service )

 SSDP est employé au-dessus de HTTPMU et HTTPU

– Basé sur UDP

– Annonces/requêtes sont faits multicast sur HTTPMU – Réponses sont faits au-dessus de HTTPU

– Adresse multicast: 239.255.255.250 – Port: 1900

(18)

HTTPMU

 HTTPMU

– a été inventé pour soutenir UPnP

– n'est pas une recommandation du W3C

– utilise la syntaxe HTTP tout en en changeant la sémantique

 Ainsi une requête comme GET http://localhost/index.html ne peut pas être interprétée comme une requête d'un document

– utilise les requêtes standards de HTTP: GET, POST, HEAD, … – permet l’utilisation de nouveaux types de requêtes: NOTIFY – fonctionne sur UDP (multicast)

 envoi de datagrammes messages d’un seul bloc

 possibilité d’envoi des datagrammes à un "groupe"

 les contenus du datagramme sont des requêtes HTTP

– aucune réponse à ces requêtes multicast puisque le message peut être reçu par plusieurs clients

(19)

HTTPU

 HTTPU

– a été inventé pour UPnP

– n’est pas une recommandation du W3C

– envoie un seul datagramme en UDP à un destinataire – le destinataire peut envoyer une réponse en retour à

l’émetteur à l’adresse et au port d’émission du datagramme.

(20)

Annonce SSDP (Notify)

 Multicast sur HTTPMU

 Qui ? Un dispositif pour s’annoncer

 Quand ? Ajout, arrêt ou rafraîchissement (lease) (NTS)

 Comment ?

– USN: chaque dispositif a un UUID de sorte d’être identifié même en cas de changement d’adresse IP

 Les notifications sont atomiques et envoyées périodiquement

 Pas de réponse à une annonce

NOTIFY * HTTP/1.1

HOST: 239.255.255.250:1900

CACHE-CONTROL: max-age = seconds until advertisement expires LOCATION: URL for UPnP description for root device

NT:search target NTS: ssdp:alive

USN :advertisement UUID

(21)

Recherche SSDP (Search)

 Multicast

 Qui ? Un point de contrôle qui a manqué les annonces

 Quand ? Recherche de dispositif ou de service

 Comment ?

 La recherche est assez simple: le service demandé

correspond-il au type de service ou pas? Si oui il y aura une réponse par HHTPU, sinon pas.

M-SEARCH * HTTP/1.1

HOST: 239.255.255.250:1900 MAN: "ssdp:discover"

MX: seconds to delay response ST: search target

(22)

Réponse SSDP

 Unicast

 Qui ? Un dispositif

 Quand ? Si ST correspond à NT

 Comment ?

 Envoyé pour chaque NT qui correspond

 Matching très simple

HTTP/1.1 200 OK

CACHE-CONTROL: max-age = seconds until advertisement expires LOCATION: URL for UPnP description for root device

ST: search target

USN: advertisement UUID

(23)

Description

 Le point de contrôle apprend les capacités des dispositifs

– 0 récupère l’adresse – 1 découvre le

dispositif

 URL pour la description du dispositif

– 2 récupère la description

 URL pour la description du (des) service(s)

 Pile du protocole

IP TCP

UPnP Vendor

HTTP

(24)

Description: Dispositif et Service

 Description du Dispositif

– Type

– Description Physique – Description Logique

 Pour chaque Service

– Type

– URL pour la description

– URL pour le contrôle – URL pour les

évènements

– Interface utilisateur

 Icones

 URL de présentation

 Services

– Unité fonctionnelles du dispositif

 Description du Service

– Actions

– Variables d’état

 Tout est spécifié en

XML

(25)

Modèle de Données (Simplifié)

Fichier device.xml

Fichiers scpd.xml

(26)

Fichier device.xml

<?xml version="1.0"?>

<rootxmlns="urn:schemas-upnp-org:device-1-0">

<URLBase>base URL for all relative URLs</URLBase>

<friendlyName>short user-friendly title</friendlyName>

<manufacturer>manufacturer name</manufacturer>

<manufacturerURL>URL to manufacturer site</manufacturerURL>

<modelDescription>long user-friendly title</modelDescription>

<modelName>model name</modelName>

<modelNumber>model number</modelNumber>

<modelURL>URL to model site</modelURL>

<serialNumber>manufacturer's serial number</serialNumber>

<UPC>Universal Product Code</UPC>

<deviceType>urn:schemas-upnp-org:device:deviceType</deviceType>

<serviceType>urn:schemas-upnp-org:service:serviceType:v</serviceType>

<serviceId>urn:upnp-org:serviceId:serviceID</serviceId>

<SCPDURL>URL to service description</SCPDURL>

<controlURL>URL for control</controlURL>

<eventSubURL>URL for eventing</eventSubURL>

</service>

Declarations for other services (if any) go here

</serviceList>

<deviceList>Description of embedded devices (if any) go here</deviceList>

<icon>

<mimetype>image/format</mimetype>

<width>horizontal pixels</width>

<height>vertical pixels</height>

<depth>color depth</depth>

</icon>

XML to declare other icons, if any, go here

</iconList>

<presentationURL>URL for presentation</presentationURL>

</device>

Description Physique

Description Autre

Description Logique

(27)

<deviceType>urn:schemas-upnp-org:device:deviceType:v</deviceType>

</service>

</serviceList>

<icon>

</icon>

</iconList>

</device>

</specVersion>

</root>

Description: Dispositif (Physique)

(28)

Description: Dispositif (Logique)

<deviceType>urn:schemas-upnp-org:device:deviceType :v</deviceType>

</service>

</serviceList>

<icon>

</icon>

</iconList>

</device>

</specVersion>

(29)

<deviceType>urn:schemas-upnp-org:device:deviceType:v</deviceType>

</service>

</serviceList>

<icon>

</icon>

</iconList>

</device>

</specVersion>

</root>

Description: Dispositif (autre)

(30)

Fichier scpd.xml

<scpdxmlns="urn:schemas-upnp-org:service-1-0">

<name>actionName</name>

<name>formalParameterName</name>

<direction>inxorout</direction>

<relatedStateVariable>stateVariableName</relatedStateVariable>

</argument>

Declarations for other arguments (if any) go here

</argumentList>

</action>

Declarations for other actions (if any) go here

</actionList>

<name>variableName</name>

<dataType>variable datatype</dataType>

<defaultValue>default value</defaultValue>

<minimum>minimum value</minimum>

<maximum>maximum value</maximum>

<step>increment value</step>

</allowedValueRange>

</stateVariable>

<dataType>variable data type</dataType>

<allowedValue>some value</allowedValue>

</allowedValueList>

</stateVariable>

Declarations for other state variables (if any) go here

</serviceStateTable>

Description actions

Description variables

(31)

Description: Service (actions)

<direction>in xor out</direction>

</argument>

</argumentList>

</action>

</actionList>

</stateVariable>

</allowedValueList>

</stateVariable>

(32)

Description: Services (Variables)

<direction>inxorout</direction>

</argument>

</argumentList>

</action>

</actionList>

</stateVariable>

</allowedValueList>

</stateVariable>

</specVersion>

(33)

Contrôle

 Côté Point de Contrôle

– Chercher l’URL pour la commande

– Construit des requêtes (RPC calls) en utilisant SOAP

– Envoie les requêtes par HTTP

– Attend les réponses SOAP du dispositif.

 Côté Dispositif

– Parse la requête SOAP – Effectue l'action requise

et renvoie les réponses dans des messages

SOAP

 Pile du protocole

IP TCP

UPnP Vendor

HTTP SOAP

(34)

Contrôle: SOAP

 Qu’est ce que SOAP ?

– IETF Draft Simple Object Access Protocol

– Protocol basé sur XML pour l’échange d’information dans un environnement décentralisé et distribué

 Enveloppe: défini un cadre pour décrire ce qui est dans le message et comment l’utiliser

 Convention: représente l’appel distant de méthodes et les réponses

(35)

Contrôle: Requête SOAP

 Qui ? Le Point de Contrôle

 Quand ? Pour déclencher une action d’un dispositif

POST path of control URL HTTP/1.1

HOST: host of control URL:port of control URL CONTENT-TYPE: text/xml; charset="utf-8"

SOAPACTION: "urn:schemas-upnp-org:service:serviceType:v#actionName"

<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"

s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">

<s:Body>

</s:Body>

</s:Envelope>

<u:actionName xmlns:u="urn:schemas-upnp-org:service:serviceType:v">

<argumentName>in arg value</argumentName>

other in args and their values (if any) go here

</u:actionName>

(36)

Contrôle: Réponse Action

 Qui ? Le dispositif

 Quand ? Quand l’action est effectuée

HTTP/1.1 200 OK

CONTENT-TYPE: text/xml; charset="utf-8"

<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"

s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">

<s:Body>

</s:Body>

</s:Envelope>

<u:actionNameResponse

xmlns:u="urn:schemas-upnp-org:service:serviceType:v">

<argumentName>out arg value</argumentName>

other out args and their values (if any) go here

</u:actionNameResponse>

(37)

Evénement

 Le dispositif

– publie une liste

d’événements auxquels les points de contrôle

peuvent s’abonner et sur lesquels ils peuvent

obtenir des notifications

 Les points de contrôles

– souscrivent auprès d’un dispositif pour un

événement publié

 Les événements sont

notifiés par les dispositifs à travers TCP aux points de contrôle abonnés.

 Pile du protocole

IP TCP

UPnP Vendor

HTTP GENA

(38)

Evènement: GENA

 Qu’est ce que GENA ?

– IETF Draft General Event Notification Architecture

– Envoi et reçoit des notifications par HTTP au dessus de TCP/IP

 Souscription (abonnement) aux notification

 Désabonnement

 Notification

– Disponibilité des dispositifs

– Changement des valeurs de variables d’état

(39)

Evènement: Abonnement

 Qui ? Le Point de Contrôle

 Quand ? Avant de recevoir tout évènement

 Comment ?

SUBSCRIBE publisher path HTTP/1.1 HOST: publisher host:publisher port CALLBACK: <delivery URL>

NT: upnp:event

TIMEOUT: Second-requested subscription duration

(40)

Evènement: Réponse Abonnement

 Qui ? Le Dispositif

 Quand ? Acceptation de l’abonnement

 Comment ?

HTTP/1.1 200 OK

SID: uuid:subscription-UUID

TIMEOUT: Second-actual subscription duration

(41)

Evènement: Notification

 Qui ? Le Dispositif

 Quand ? A chaque changement de variables d’état

NOTIFY delivery path HTTP/1.1 HOST: delivery host:delivery port CONTENT-TYPE: text/xml

NT: upnp:event

NTS: upnp:propchange SID: uuid:subscription-UUID SEQ: event key

<e:propertyset xmlns:e="urn:schemas-upnp-org:event-1-0">

<e:property>

<variableName>new value</variableName>

</e:property>

Other variable names and values (if any) go here

</e:propertyset>

(42)

Présentation

 Le point de contrôle apprend les capacités des dispositifs

– 0 récupère l’adresse – 1 découvre le

dispositif

– 2 récupère la description

 URL pour la description de la présentation

– 5 charge la page de présentation

 Pile du protocole

IP TCP

UPnP Device Architecture UPnP Vendor

HTTP

(43)

Synthèse sur UPnP

Evènements Contrôle

Recherche et Découverte

IP

UPnP Device Architecture Defined UPnP Forum Working Commitee Defined

UPnP Vendor Defined

UDP TCP

HTTPMU (multicast)

SSDP

GENA HTTPU

(Unicast) SSDP SOAP HTTP GENA

HTTP

(44)

Full Tutorial of the

Intel

^®

Authoring Tools for UPnP Technologies

 Ylian Saint-Hilaire

Une aide à la

mise en œuvre d’

(45)

Typage

 24 types primitifs

– Boolean

– ui1, ui2, i1, i2, i4, int, ui4

– r4, float, r8, number, fixed.14.4 – char, string

– uri, uuid

– time, time.tz, date, dateTime, dateTime.tz – bin.base64, bin.hex

 Variables d’état

– Type primitif

– Évènementiel ou pas

 Paramètre (in / out) d’une action

– Type relatif à une variable d’état

– Remarque: Déclaration de variable d’état fictive A_ARG_TYPE_X pour les paramètres des actions

(46)

Erreurs UPnP

 Peut être retourné quand une action est invoquée

– INVALID_ACTION – (401) No such action could be found.

– INVALID_ARGS – (402) Invalid argument.

– INVALID_SEQUENCE_NUMBER – (403) Out of synchronization.

– INVALID_VARIABLE – (404) State variable not found.

– DEVICE_INTERNAL_ERROR – (501) Internal error.

 Catégories

– Common Action Errors [600-699], defined by the UPnP Forum Technical Committee.

– Action Specific Errors [700-799] defined by the UPnP Forum Working Committee.

– Non-Standard Action Specific Errors [800-899] defined by vendors.

(47)

Des produits intégrant UPnP

 Logiciel

 Matériel (1051 dispositifs certifiés au 29/10/2012)

(48)

Overview of Intel

^®

AV Tools for UPnP Technologies

 Ylian Saint-Hilaire

Démonstration

(49)

(50)

DLNA

 Digital Living Network Alliance (DLNA)

– Proposé par Sony en juin 2003

– Historiquement: Digital Home Working Group (DHWG) – Devenu DLNA 1 an plus tard

– Organisation collaborative de plus de 250 sociétés

 Standard pour l’interopérabilité permettant

– La lecture, le partage et le contrôle d’appareils multimédia

 Acteurs:

– Digital Media Server (DMS): fournisseur de contenus

– Digital Media Player (DMP): trouve et joue des contenus

– Digital Media Renderer (DMR): décode et joue des contenus – Digital Media Controller (DMC): parcours des contenus

– Digital Media Printer (DMPr): imprime des contenus

(51)

Technologies utilisées par DLNA

 S’appuie sur des standards du modèle OSI:

1. Physique: xBase-T, Câble coaxial, Wireless 2. Liaison: Ethernet, MoCa, Wi-Fi

3. Réseau: IP, DHCP 4. Transport: TCP, UDP 5. Session:

6. Présentation:

7. Application: HTTP, UPnP (découverte et contrôle), UPnP A/V (gestion des media)

– Mais aussi DTCP-IP (DRM)

– Et de nombreux format de media: JPEG, MPEG2, PNG, GIF, TIFF, MP3, WMA9, AC-3, MPEG1, MPEG4, WMV9, …

(52)

Et la suite d’UPnP…

Conclusion

(53)

Avantages d’UPnP

 UPnP

– Envoi juste des données

– Conserve les implémentations privées

– Accord sur le contenu et le format des données

 UPnP est:

– Basé sur des protocoles Web

– Piloté par un Forum pour les types de dispositifs et services – Indépendant du réseau physique, de l’OS, des API

– Utilisé pour la découverte, la description, le control et la gestion par évènements

 Un standard de fait:

– Mis en œuvre dans des produits industriels matériels et logiciels

(54)

Fédérer les Protocoles Existants

 Tous les équipements ne sont pas UPnP

– Protocoles domestiques alternatifs

 X10, Z-Wave, KNX (Konnex, EHS/EIB/Bâtibus), OneWire, Propriétaire (alarme, volets roulants, ...)

– Chaque réseau crée un « micro-monde »

 Comment relier ces « micro-mondes » via UPnP ?

– Notion de pont (ou gateway) UPnP

Gateway X10 - UPnP

Gateway FireWire - UPnP

Gateway ZigBee - UPnP

(55)

Limitations et Perspectives

 UPnP pas adapté pour les petits dispositifs

– Nécessité d’embarquer

 la gestion des protocoles réseaux IP / TCP / UDP

 Un serveur HTTP

 Un parseur de document XML

– Nécessite donc des capacités de stockage et de calcul non négligeables

 Pointeur sur d’autres approches plus légères

– SCP: Simple Control Protocol

– http://www.microsoft.com/Presspass/press/2000/jun00/scppr.

mspx

(56)

Faiblesses d’UPnP et Perspectives

 UPnP utilise SSDP

– par-dessus UDP (HTTPU et HTTPMU pour l'unicast et le multicast)

– cette spécification n’est pas standardisée – la version draft a expiré en 2000

 UPnP n'intègre aucun protocole d'authentification.

 UPnP est une pile imposante pour des dispositifs légers

 UPnP v2 ou DPWS

– Mêmes objectifs qu’UPnP

– Corrige les défaut d’UPnP mais sans être backward compatible (d’où le changement de nom)

– Complètement compatible avec les standards du Web

(57)

Alternatives et Compléments

 Alternatives

– JINI

– SLP (Service Location Protocol)

– DNS-SD (Apple’ Rendez Vous, Bonjour)

 Compléments

– DLNA (Digital Living Network Alliance) – EchoNet (Japon)

– IGRS Intelligent Grouping and Resource Sharing (Chine) – Mix de UPnP et DPWS

– Digital Home Working Group (DHWG) – DPWS (Device Profile for Web Services)

(58)

Références

 Universal Plug and Play forum

– http://www.upnp.org/

 UPnP architecture

– http://www.upnp.org/resources/documents.asp

 UPnP SDK for Linux

– http://pupnp.sourceforge.net/

 Simple Object Access Protocol

– http://www.w3.org/TR/SOAP/

 IETF draft on ‘Multicast and Unicast UDP HTTP Messages’

– http://www.ics.uci.edu/pub/ietf/http/draft-goland-http-udp- 01.txt