Discovery protocol SSDP - universAAL/middleware GitHub Wiki

Table of Contents Protocol Introduction Discovering and peering SSDP message format SSDP discovery steps Advertisement Search Protocol adoption

UPnP (Universal Plug and Play) http://www.upnp.org/standardizeddcps/default.asp is a widely-accepted standard designed to enable the integration and interoperability of consumer electronics, intelligent appliances and mobile devices from many different vendors in the home environment. While UPnP focuses on the protocols aimed at letting devices interoperate (includes device and service discovery, for instance), the Digital Living Network Alliance (DLNA) standard http://www.dlna.org/en/industry/home/ defines guidelines for the standardization of the profiles and of the content offered by devices (including multimedia devices) of different manufacturers. Under this respect the two standards are complementary: UPnP offers management services and DLNA standardizes the profiles and content. UPnP offers services for the management of intelligent devices in the home environment, it is adopted by many (multimedia) devices already on the market, such as televisions, hi-fi, videocameras, etc., and it is the de-facto solution for infotainment, while DLNA defines, among other things, how the multimedia content should be offered. UPnP technology is an architecture for unmanaged peer- to-peer networks composed by intelligent devices (Routers, PCs, Videocamera, TV, etc.) in local network environments. The design goal of UPnP is to create a vendor independent (but vendor extendible), user friendly and robust standard. The UPnP forum defines a set of standard profiles describing different categories of devices. Up to now the forum identified, among others, the categories of Basic, Audio/Video (aimed at standardization of multimedia devices), Home Automation (for domotic applications), Remoting (for intelligent remote commands) etc. From a network point of view UPnP can be seen as a layer constructed over HTTP in a standard TCP/IP and UDP/IP network.

The UPnP Device Architecture (UDA) is designed to support zero-configuration, "invisible" networking and automatic discovery for several device categories from a wide range of vendors. UDA provides function able to:

1. dynamically join a device into the network,
2. obtain an IP
3. convey device capabilities
4. learn about the presence and capabilities of other devices
5. manage scenarios where devices can leave a network in a "invisible" way without loosing any unwanted state behind.

The technologies leveraged in the UPnP architecture include Internet protocols such as IP, TCP, UDP, HTTP, and XML. The adoption of internet protocols provides an efficient way to span several physical media by exploiting real world multiple-vendor interoperation, and enabling many home and office intranet interactions. The UDA provides a way to classify the UPnP devices:

• controlled device playing the role of server
• control-point device able to interact with controlled device.

The following steps define the main UPnP functionalities:

1. Addressing: every UPnP device needs a valid IP address in order to play the role of controlled device or control point. UPnP stack defines the mechanism to automatically acquire almost one valid IP address.
2. Discovery: existing UPnP devices can discover existing nodes through ad-hoc protocol in a dynamic way.
3. Description: every UPnP device is able to multicast the node description into the network in order to let existing UPnP devices to interact with the new device. The node description describes with an XML format device capabilities: vendor-specific manufacturer information ( e.g. the model name and number, the serial number, the manufacturer name, URLs to vendor-specific Web sites), any embedded devices or services (including the command and argument list to invoke the provided services), list of variables modeling the state of the node
4. Control: in order to remotely command a UPnP device, the UPnP stack defines an XML SOAP based message format containing command and parameter to perform specific actions
5. Eventing: UPnP provides a complete mechanism to be notifies as soon as specific events occur into the UPnP network. One or more UPnP devices offer a way to notify event listeners when a specific event fires.
6. Presentation: if a device provides an URL for presentation, control point can open the URL with a browser and navigate through the site in order to control or monitor the UPnP node state.

• quick protocol stack snippet by providing a concise description of every layer

In order to achieve the previous goal the UPnP Forum (the industry initiative promoting UPnP) defined the UPnP protocol stack depicted in figure 1, which provides features such as device and service discovery, device description, device control, eventing management, and presentation of the devices through user friendly interfaces (using HTML). UPnP exploits:

1. full featured TCP/IP: required by all the phase of the protocol;
2. standard HTTP over TCP client & server: required by Control and Event phases;
3. non-standard HTTP over UDP with unicast and multicast communication: required by Discovery phase;
4. GENA required by the Eventing management;
5. SSDP required by the Discovery services;
6. SOAP required by the Control services.

UPnP stack used by Discover and Control phase are depicted in figure 2 . It also should be observed that UPnP focuses only on management aspects of the cooperation among devices, but it does not impose constraints on how the actual transfer of content should happen, which is thus left to the application layers (out of band communication). In many cases the applications rely on the lower layers of the protocol stack for this purpose (typically TCP/IP).

• Define existing device constraints for protocol adoption: general purpose device vs specific one. This section aims at quickly mark those protocols designed for unrealistic AAL Node

From the previous description it is clear that UPnP is not a lightweight protocol, however there exist implementations even for embedded systems with (moderately) limited resources such as hand-held devices.

SSDP protocol answers to the Discovery challenge in UPnP networks. As reported by figure 1, SSDP builds the UPnP stack and uses part of the header field format of HTTP 1.1 (RFC 2616), however it uses UDP instead of TCP as adopted in HTTP 1.1. As soon as a device joins the network, the UPnP discovery protocol announces for the available device services to the network control points, moreover SSDP provides to network control point the ability to search for specific devices into network. SSDP does not rely on third-party server such as DHCP or DNS in order to perform discovery tasks, instead it adopts discovery messages containing specific device information able to let existing UPnP devices be aware of new available services.

All SSDP messages must be formatted in according to RFC 2616 (section 4.1) and a common layout is made of the following parts:

• start-line: every SSDP message contains exactly one of the following start-line:

    NOTIFY * HTTP/1.1\r\n 
    M-SEARCH * HTTP/1.1\r\n 
    HTTP/1.1 200 OK\r\n 

• list of message header fields: every header must be formatted in according to RFC 2616 (section 4.2), the common header layout adheres to the following convention:

    <filed-name>":"<filed-value>

UPnP vendors can define their own custom headers in accordance to the following convention:

    <field-name“.”domain-name>":"<filed-value>

SSDP messages should not contain the body part, these messages can be discarder from UPnP devices.

SSDP exploits two basic steps during device discovery task: Advertisement and Search. The rest of this paragraph will introduce both of the steps.

The advertisement step starts as soon as a device joins the network by sending several multicasting discovery messages to the standard address and port 239.255.255.250:1900. These messages let control-point devices be aware of all the network device capabilities: root devices, embedded devices and services. Every message ships with a duration attribute, this prevent control-device to accept obsolete messages. A device can choose between three different advertisement messages:

• Device available (ssdp:alive message): the device advertises control-points about the available capabilities by sending several multicast messages:

1. three discovery messages for the root device
2. two discovery messages for each embedded device
3. one message for each service type in each device

• Device unavailable (ssdp:byebye message): the device prepares leaving the network, all the provided root devices, any embedded devices and any services become unavailable. For every previously sent ssdp:alive message, one ssdp:byebye multicast message must be sent.
• Device update (ssdp:update message): the device announces control-point about newly added root devices, embedded devices and embedded services. The device can exploits ssdp:update as soon as it acquires a new ip address.

SSDP provides to control-point device mechanisms to search for a specific device into the whole UPnP network. Control-point devices can multicast SSDP search messages by specifying the interests for the search. Available devices matching the search interests can respond by sending SSDP response messages. The search steps exploits two SSDP message types: request and response.

• Search request: M-SEARCH

Control-point devices can send a M-SEARCH message in order to perform the search step by sending multicast messages or unicast messages, in the latter case control-poin knows the device address. It is important to notice that control-point devices have to send multiple M-SEARCH messages in order to prevent unreliable UDP protocol nature.

• Search response

Device responding to the M-SEARCH sends a unicast UDP response to the source IP address and port that sent the request to the multicast address.

• Define well-know limitations and possible draw-backs in protocol adoption

Exist several UPnP stack implementations, the available development kits differ from programming language adoption. The following list aims at remark the java programming kit:

1. CyberGarage http://www.cybergarage.org/twiki/bin/view/Main/UPnPFramework
2. Cling http://teleal.org/projects/cling