Testing Networked Connected Device Protocol Efficiency - PowerPoint Presentation

Slide1

Testing Networked Connected Device Protocol Efficiency

Peter Shier

Microsoft CorporationSlide2

Goals for the Project

Raise your awareness of network connected devices and how they work

Learn the discovery protocols

Learn what affects protocol efficiency

Design tests for one aspect of efficiency and implement for each protocol

Analyze results and compare across protocols

Suggest possible improvements to protocols and/or implementationsSlide3

What is a Device?

A user-perceived physical package that exposes one or more logical functions

Categorized by relationship to the host computer:

System, Peripheral, Peer, Cloud

Device Attributes:

Function: Storage, audio, video, input, network, etc.

Packaging: single or multi-function

Connectivity:

Wired or wireless

Single or multi-transport

Single or

multi-hosted (connect to multiple simultaneous hosts)

Power Management: self or bus-powered

Exclusive or shared

Fixed or portable

Virtual or physicalSlide4

NCDs in the Market Today

Printers

Scanners

Fax

Storage

Media players/servers/hubs

TV

BluRay

players

Phones

,

point-of-sale

Internet gateways

Modems

Sensors/actuators

Home/commercial/industrial automation

Energy management

Security cameras

Projectors

Security systems

Game consoles

Health care

Attributes:

Peripheral/peer/cloud, Ethernet/

WiFi

, single/multi-transport, single/multi-hosted, self/bus-powered, exclusive/shared, fixed/portable, physical/virtualSlide5

Projected Growth (Consumer)

Annual Sales/Net Additions: Connect Consumer Electronics (units in millions)

Source: Parks Associates, 2009Slide6

NCD Protocols

What

is an NCD protocol?

Discovery, control, events

Security,

remoting

, power management, device management,

QoS

Device Profiles

Principal protocols for NCDs today:

Bonjour

Universal Plug and Play (UPnP)

Device Profile for Web Services (DPWS)Slide7

BonjourSlide8

What is Bonjour?

Apple’s trade name for

Zeroconf

discovery protocol.

Originally called Rendezvous but later changed due to trademark conflict

Invented by Stuart Cheshire of Apple

Defines:

IP and host name configuration without infrastructure assistance

Service discovery

Service browsing

Does not define:

S

ervice description

Service access protocols

Security, management, low power, etc.

Typically used on private subnets but can be used on the Internet and enterprise networks

Licensed by Apple for free with a partial open source implementation.

Built into OS X, available for Windows 2K/XP/Vista (separately or with iTunes), and there is an established open source implementation (

Avahi

).

Used by OS X for printer and file server discovery,

i

Tunes (shared music),

iPhoto

(shared photos),

iChat

, and by many 3

rd

party apps for local discovery (e.g.

Tivo

desktop uses it to find DVRs).

Used by

iPhone

and iPod Touch Remote app for iTunes library discovery

Safari has a Bonjour folder under Bookmarks

Supported by some NAS drives for discoverySlide9

IP Addressing

Uses

RFC 3927

for auto-

config

of IP addresses (169.254.n.n) if no DHCP server is available.

Host chooses a random 169.254.n.n address and then sends out an Address Resolution Protocol (ARP) packet to check if another host is using it.

If yes, then it chooses another and tries again.

Host repeats this until a free address is foundSlide10

Domain Name System (DNS)

DNS is a database that returns

tuples

called “resource records” keyed by domain names e.g. IP address for

www.microsoft.com

Tuple

contains domain name, time-to-live, class, type, value

Class is almost always internet (IN)

Examples of Type:

A: IPv4 address

AAAA: IPv6 address

MX: mail exchange – email address for domain name

NS: name server – name server for the domain

CNAME: canonical name – enables aliasing well known names with internal names. Lookup continues using this name.

PTR: pointer – can be used to redirect to another name (or anything else) e.g. for reverse IP lookups

HINFO: host info – OS used by host

TXT: free form text

LOC: geographical location of associated with domain name

SOA: start of authority – authoritative info about a DNS zone – primary name server, email of domain admin, domain serial number

SRV: a service locationSlide11

Multicast DNS

On local subnet uses DNS commands with multicast for naming and discovery.

Uses a pseudo top-level domain “

.local”

Host chooses a name (e.g.

MyMachine.local

) and queries network for presence. If no response then claims name otherwise tries alternate (

e.g

MyMachine2.local)

After claiming name host multicasts unsolicited DNS response with its resource records to announce its presence. Will also announce its departure.

Query types for discovery:

One shot, one

unicast answer (e.g. browse for

http://somename.local

)

One shot, multiple unicast answers for limited time (e.g. snapshot view of available printers)

Continuous, multiple multicast answers (e.g. keep a list of printers up to date). Other clients can update their caches too.

Repurposes an effectively unused bit to choose unicast/multicast

reponsesSlide12

Browsing

Hosts announce and respond to queries for services (not devices).

DNS-based service discovery (DNS-SD) defined by Internet Draft (

http://files.dns-sd.org/draft-cheshire-dnsext-dns-sd.txt

).

Services use a structured namespace to indicate the service type and protocol e.g. _

ipp._tcp.microsoft.com

means that MS exposes a service using the Internet Printing Protocol over TCP.

Multiple service instances on the same host use prefixes to differentiate e.g. windows._ipp._tcp.microsoft.com and xbox._ipp._tcp.microsoft.com.

Protocol names are registered with standard body. Listed at

http://www.dns-sd.org/ServiceTypes.html

.

DNS defines SRV record for service discovery. Contains host name and port number.

DNS-SD adds use of

PTR records for enumerating service instances (e.g. multiple printers within the same domain)

TXT records with content structured as key/value pairs for service properties (e.g. “PAPERSIZE=A4”)

User sends DNS query for PTR records of service instances and then queries SRV/TXT pairs for instance(s) of interest.

User-visible service instance name is also primary identifier of the service i.e. there is no concept of separate computer-readable guaranteed unique name and user-readable friendly names.

Inventors claim this is better to avoid possibility that identical friendly names do not represent different services.

Usage of very friendly names is encouraged e.g. “_

ipp._tcp.Building

10, Mail Room 1355.microsoft.com”Slide13

Beyond the Subnet

DNS-SD can also work with

unicast

DNS in an infrastructure network.

Assumes that DNS admin is willing to add DNS-SD records

Recommended for things like finding key web pages (e.g. where is the new employee info page?)

Defines concept of domain enumeration

Uses default DNS search domain from DHCP and sends it PTR queries for a series of special names that a DNS admin can set up to answer these questions:

What are the interesting domains to browse for services? (

b._dns-sd._udp

)

From that list what is the recommended default domain? (

db._dns-sd._udp

)

What are the recommended domains for advertising services? (

r._dns-sd._udp

)

Assumes that dynamic DNS update is possible (RFC 2136)

Bonjour defines a “DNS update lease” command for when a server’s IP address changes or a server leaves the network (RFC 2671)

From that list what it the recommended default? (

dr._dns-sd._udp

)

For legacy clients that don’t specify domains for browsing, which domains should be browsed in addition to

.local

? (

lb._dns-sd._udp

)

Defines concept of DNS long-lived queries

Requests notification from DNS if a record changes or is deleted.

Used to avoid polling DNS for changes (that arrive for free in multicast DNS)

Apple uses all of the above for Back-to-my-Mac and now for remote access to router-attached storage (Airport and Time Capsule).

They implement the needed DNS services in their cloud (

MobileMe

) and establish an IPv6

Teredo

connection using IPSEC. Users enter

creds

directly into router

config

UI.Slide14

Universal Plug and Play (UPnP)Slide15

What is UPnP?

Universal Plug and Play

Architecture that defines how devices and clients find each other and interact over an IP network.

Has nothing to do with PNP in Windows though it did originate at Microsoft.

Defined by a series of published standards from an industry group called the UPnP Forum.

Also parallel org UPnP Implementers Corp. that does device compliance certification.

Base standard: UPnP Device Architecture (UDA)

Version 1.0 and 1.1.

Windows supports v1.0.

v1.1. published in late 2008.

Many device profiles built on top of UDA:

A/V, print, scan, IGD, home auto, telephony, content-sync, remote UI

A device profile is called a “Device Control Protocol” (DCP) in UPnP

Adjunct specs for optional device-agnostic features:

Remote access, power management, security,

QoS

, device management

UPnP is targeted at the consumer market on the home network.

The UPnP forum is largely controlled by consumer electronics companies at this point and includes all major players except Apple.

Adoption today is largely in IGDs but A/V is growing via DLNA.Slide16

UPnP Protocol StackSlide17

UPnP Device Architecture

Defines devices and control points:

Control point: what we think of as the client application that discovers and consumes the services of a device.

Device: logically partitioned into a set of services (e.g. print, scan, fax). Exposes a detailed description of the services it offers to potential clients.

Devices can also contain other devices. The outermost device is called the root device.

Both devices and control points can be implemented on any hardware that can host them e.g. a PC can be a device, a control point, or both.

Devices advertise their presence when they join a subnet by multicasting a message containing a URL to more detailed information about the device.

Clients can listen for advertisements or initiate searches to which devices may respond.

Clients read an XML doc from the device that describes its services in complete detail and how to access them.

A service is defined as a set of state variables, actions, and events

Analogous to an OOP object that exposes properties, methods, and events

Clients invoke actions and access state variables using SOAP messages.

Devices can optionally fire events to indicate changes in state variables.

Clients can optionally sink these events.

Devices can optionally expose a presentation interface (i.e. web page).Slide18

Discovery: The SSDP Protocol

UPnP defines its own discovery mechanism:

Simple Service Discovery Protocol

When a device connects to the network it

must

multicast announcements of its presence, its nested devices, and its services.

Uses a series of HTTP headers multicast via UDP to a well-known address (239.255.255.250:1900).

Device profiles may add their own specific headers.

Headers include unique device ID, counters to indicate device reboot, device description change, cache hints, port for unicast search (directed discovery)

Announcements have an expiration time. Devices must resend announcements after expiration.

A control point may multicast a search message scoped by device type and service type. Devices that match the search criteria

must

respond.

A control point may also do directed discovery by

unicast

search message to a particular device if it knows the IP address. The device

must

respond if it matches the search criteria.

When a device is leaving the network it

should

multicast announcements that its root device, nested device, and services will no longer be available.

Discovery multicasts are sent with TTL=1 in IP packet to avoid routing out of the subnet.Slide19

Description

XML doc containing:

Description of root and nested devices:

make, model, serial number, manufacturer, URL to web site for more info

Device type: some are standard, others vendor-defined.

UDN: unique device name. UUID that remains stable for the device instance (across reboots and IP address changes). Matches the NT header in discovery message.

Reference to services within device description:

Service type, name, URLs for service description, control, & events.

Presentation URL (e.g. router web-based

config

UI)

Service description:

Actions with arguments and return values

State variables with data type, data range, and event characteristics

CP retrieves description docs with HTTP/TCP using GET.Slide20

<

root

xmlns

="urn:schemas-upnp-org:device-1-0"

configId

="

configuration number">

<

specVersion

>

<major>1</major> <

minor>1</minor>

</

specVersion

>

<

device>

<

deviceType

>

urn:schemas-upnp-org:device:

deviceType:v

</

deviceType

>

<

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

>

<

UDN>

uuid:

UUID

</UDN>

<

UPC>

Universal Product Code</UPC>

<

iconList

>

<

icon>

<

mimetype

>image/

format</

mimetype

>

<

width>

horizontal pixels</width>

<

height>

vertical pixels</height>

<

depth>

color depth</depth>

<

url

>

URL to icon</

url

>

</

icon>

</

iconList

>

<

serviceList

>

<

service>

<

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>

</

serviceList

>

<

deviceList

>

<!--

Description of embedded devices go here ->

</

deviceList

>

<

presentationURL

>

URL for presentation</

presentationURL

>

</

device>

</

root>Slide21

<

scpd

configId

="configuration number">

<

specVersion

>

<major>1</major>

<minor>1</minor>

</

specVersion

>

<

actionList

>

<action>

<name>

actionName

</name>

<

argumentList

>

<argument>

<name>argumentNameIn1</name>

<direction>in</direction>

<

relatedStateVariable

>

stateVariableName

</

relatedStateVariable

>

</argument>

<argument>

<name>argumentNameOut1</name>

<direction>out</direction>

<

retval

/>

<

relatedStateVariable

>

stateVariableName

</

relatedStateVariable

>

</argument>

<argument>

<name>argumentNameOut2</name>

<direction>out</direction>

<

relatedStateVariable

>

stateVariableName

</

relatedStateVariable

>

</argument>

</

argumentList

>

</action>

</

actionList

>

<

serviceStateTable

>

<

stateVariable

sendEvents

="yes"|"no" multicast="yes"|"no">

<name>

variableName

</name>

<

dataType

>basic data type</

dataType

>

<

defaultValue

>default value</

defaultValue

>

<

allowedValueRange

>

<minimum>minimum value</minimum>

<maximum>maximum value</maximum>

<step>increment value</step>

</

allowedValueRange

>

</

stateVariable

>

<

stateVariable

sendEvents

="yes"|"no" multicast="yes"|"no">

<name>

variableName

</name>

<

dataType

type="dt1:variable data type">string</

dataType

>

<

defaultValue

>default value</

defaultValue

>

<

allowedValueList

>

<

allowedValue

>enumerated value</

allowedValue

>

</

allowedValueList

>

</

stateVariable

>

<

stateVariable

sendEvents

="yes"|"no" multicast="yes"|"no">

<name>

variableName

</name>

<

dataType

type="dt2:vendor data type">string</

dataType

>

<

defaultValue

>default value</

defaultValue

>

</

stateVariable

>

</

serviceStateTable

>

</

scpd

>Slide22

Control: Invoking an Action

POST

path control URL HTTP/1.0

HOST:

hostname:portNumber

CONTENT-LENGTH:

bytes in body

CONTENT-TYPE: text/xml;

charset

="utf-8"

USER-AGENT:

OS/version UPnP/1.1 product/version

SOAPACTION: "

urn:

schemas-upnp-org:service:

serviceType:v#actionName

"

<?xml version="1.0"?>

<

s:Envelope

xmlns:s

="http://schemas.xmlsoap.org/soap/envelope/"

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

<

s:Body>

<

u:actionName

xmlns:u

="

urn:

schemas-upnp-org:service:serviceType:v

">

<

argumentName

>in

arg

value</

argumentName

>

</

u:actionName>

</

s:Body>

</

s:Envelope>Slide23

Action Response

HTTP/1.0 200 OK

CONTENT-TYPE: text/xml;

charset

="utf-8"

DATE:

when response was generated

SERVER:

OS/version UPnP/1.1 product/version

CONTENT-LENGTH:

bytes in body

<?xml version="1.0"?>

<

s:Envelope

xmlns:

s

="http://schemas.xmlsoap.org/soap/envelope/"

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

<

s:Body>

<

u:actionNameResponse

xmlns:u

=

"

urn:

schemas-upnp-org:service:serviceType:v

">

<

argumentName

>out

arg

value</

argumentName

>

</

u:actionNameResponse>

</

s:Body>

</

s:Envelope>Slide24

Events

Protocol: General Event Notification Architecture (GENA)

Control points can subscribe to events on state variables.

Events can be unicast or multicast (new in UPnP 1.1)

Multicast events allow devices to monitor state changes in other devices without implementing a control point.

Control point sends a subscription message to service for events on a variable for a specified period of time.

Message includes callback URL where CP will receive events

Service responds with a subscription ID and then fires an initial event so CP can get current state of variable.

Event message contains an integer key that increments with each event message.

Single event message may contain multiple variables.

CP can send subscription renewal message with ID.

CP sends subscription cancellation message with ID when events are no longer needed.Slide25

Devices Profile for

Web Services (DPWS)Slide26

What is DPWS?

Architecture that defines how devices and clients find each other and interact over an IP network.

Defined by a published standard that is largely based on other web services (WS) standards:

Web Services Description Language (WSDL)

XML Schema

SOAP 1.2 over HTTP and UDP

WS-Addressing

WS-

MetadataExchange

WS-Transfer

WS-Policy

WS-Security

WS-Discovery

WS-

Eventing

Essentially – a standard that describes how devices should use other WS standards

Device profiles built on DPWS:

Print, scan, network projector, home automation, industrial control/automation, Windows

SideShow

, RFID, health, point-of-sale

Adjunct specs for optional device-agnostic features:

Discovery proxy

DPWS is targeted at both consumer and enterprise marketsSlide27

DPWS Architecture

Defines devices and clients:

Device: a network-attached component that exposes one or more services.

Devices advertise their presence when they join a subnet by multicasting a message containing a URL to more detailed information about the device.

Clients can listen for advertisements or initiate searches to which devices may respond.

Device advertise a logical address that can be converted to a physical address.

The logical address is unique across reboots of the device.

Clients read an XML doc from the device that describes its services in complete detail and how to access them.

A service is defined as a set of operations and events

Analogous to an OOP object that exposes methods and events

Clients invoke commands using SOAP messages.

Devices can optionally fire events to indicate changes in state.

Clients can optionally sink these events.Slide28

Discovery: WS-Discovery Protocol

DPWS uses the existing web services discovery protocol: WS-Discovery

When a device connects to the network it multicasts a single announcement of its presence with its identity – an “endpoint reference” (

Hello

)

.

An interested client multicasts a message expressing interest (

Resolve)

The device

unicasts

a response with its transport address (

ResolveMatch

)

The client uses the address to get device metadata (SOAP/HTTP)

A client may multicast a search message targeted by “type” and “scope” (e.g. type=“printer” and scope=“color”) (

Probe

).

Devices that match the search send a

unicast

response (

ProbeMatch

).

A client may also do directed discovery by

unicast

search message if it knows the device’s endpoint reference or transport address.

When a device is leaving the network it multicasts a single announcement (

Bye

)Slide29
Slide30

Device Description

An XML doc retrieved by the client using SOAP/HTTP containing the following sections:

ThisModel

: characteristics common to all instances of the device:

manufacturer name &

url

model number &

url

presentation

url

(e.g. router’s browser-based

config

UI)

ThisDevice

: characteristics specific to an instance of the device:

friendly name

firmware version

serial number

Relationship

: defines the relationship between the hosting device and its hosted services

Host

: identity, endpoint reference, and data types defined by a device

Hosted

: identity, endpoint reference, and data types for a serviceSlide31

Service Description

Uses Web Services Description Language (WSDL): an XML schema for describing a web service.

May be returned as part of the device description or as a separate description from the service.

May define data types

Key concepts:

Port Type

: the interface contract on a service

Operation

: a method or event exposed by the interface contract

Message

: the input or output parameters of an operation

May define bindings between an operation and the protocol used to invoke it (in addition to SOAP/HTTP)Slide32

Control

Service actions are invoked using SOAP/HTTP.Slide33

Events

Events are simply control operations in reverse (from service to client)

The service must manage subscriptions

Subscription message includes:

Address to deliver events (via SOAP/HTTP)

Desired duration of subscription

Optional filter section containing list of events of interest

Other messages:

Renew

Unsubscribe

Subscription End: sent from service to terminate a subscription unexpectedlySlide34

Protocol Efficiency

Text vs. binary

Chattiness – how often do messages flow? Implementation-specific?

Network

bandwidth

usage – how much stuff is in those messages?

Main CPU usage - vs. NIC processor

Power usage – e.g. heartbeat message forcing higher power states more often

Multicasting

usage – prohibitive on

WiFi

Implementation complexity – states/transitions, msg. fields/meanings

Testability – possible to test all states and transitions?

Certification – how hard to pass? Relates

to testability.

Implementation

costs

– RAM/flash needs, offloading

Interoperability – optional features, spec clarity (e.g. should vs. must)

Application complexity – how do all of the above affect client apps?

Application error-proneness – how hard is it to write a client?Slide35

Top 10 Reasons for Protocol Efficiency

?Slide36

Top 10 Reasons for Protocol Efficiency

Cost

Cost

Cost

Cost

Cost

Cost

Cost

Cost

Cost

CostSlide37

Designing Tests

Tests should focus on a single aspect of efficiency

Break down your chosen aspect into components e.g. power usage during unsolicited announcements

Consider network environment

Consider number of clients and devices

Get repeatable results

Try multiple stacks if you can – results may varySlide38

Processing Results

Estimate results before running tests based on what you have learned of the protocols

Create comparison table with raw results across protocols

Interpret the numbers:

Why did they perform that way?

Were your estimates correct?

If not, what did you miss?

Which protocol is the most efficient?

Could the protocols be redesigned to be more efficient while achieving the same design goals?

Make recommendations for protocol implementers to improve efficiency on their platformSlide39

Milestones

M1: Learn the protocols

M2: Compile and run the sample code

M3: Design and run tests

M4: Interpret resultsSlide40

Questions?