lN-HOME NETWORKING
`Home Networking with
`Universal Plug and Play
`
`
`
`Brent A. Miller, IBM Corporation
`
`Toby Nixon, Microsoft Corporation
`
`Charlie Tai, Intel Corporation
`
`Mark D. Wood, Eastman Kodak Company
`
`ABSTRACT
`
`In this article we present an overview of the
`Universal Plug and Play (UPnP"‘) technology and
`the UPnP Forum, the multicompany organization
`that develops parts of the architecture. A technical
`description of the technology is presented, followed
`by three illustrative usage cases where it could be
`applied in home networking environments. Finally,
`the authors describe the benefits UPnP technology
`can provide in home networking and briefly discuss
`potential future work in this area.
`
`INTRODUCTION
`
`- The UPnP architecture leverages HTTP
`and other Internet technologies such as
`XML and SOAP.
`° UPnP technology enables vendor control
`over device user interface and interaction
`via a browser.
`' lt also enables conventional application pro-
`grammatic control.
`0 Vendors agree on UPnP control protocols
`on a per-device-class basis.
`- Vendors can unilaterally extend the basic
`control protocols as needed.
`UPnP architecture supports zero-configura-
`tion networking and automatic discovery of
`devices. Network infrastructure such as DHCP
`and DNS servers are optional; they may be used
`if available on the network but are not required.
`Furthermore, a device can leave a network
`smoothly and automatically without unwanted
`state information remaining behind. The UPnP
`architecture learns from the Internet’s success
`and heavily leverages its components, including
`1P, TCP. UDP, HTTP, SOAP,‘and XML.
`
`THE UPNP FORUM
`
`All sorts of devices — PCS, mobile phones, cam-
`eras, handheld computers, and so on — are
`increasingly connecting to networks, and they
`are using a multitude of connectivity methods to
`do so. This trend increases the need for self-con-
`figuring networks that allow devices to easily and
`automatically join and leave networks, and learn
`about other connected devices. Home networks,
`automotive networks, and similar environments
`demand new technologies that can automate
`device and service discovery and control, obviat-
`Universal Plug and Play is not only a technology,
`ing the need to administer these networks.
`it is also a cross-industry initiative. The UPnP
`The Universal Plug and Play (UPnP) architec-
`Forum is the embodiment of that initiative, and
`ture enables pervasive peer-to-peer network con-
`its primary mission is to develop device control
`nectivity of PCs of all form factors, intelligent
`protocols (DCPS) that describe standard methods
`appliances, and wireless devices. It is a distribut-
`for device interaction. For more information
`ed, open networking architecture that leverages
`about the UPnP Forum, see [1].
`TCP/IP and Web technologies to enable seamless
`Formed in 1999, the Forum now has more
`proximity networking in addition to control and
`than 350 member companies from many indus-
`data transfer among networked devices in the
`tries, including consumer electronics, home
`home, office, and everywhere in between. Figure
`automation and security, computers and periph-
`1 depicts an example UPnP networking topology,
`erals, networking, appliances, semiconductors,
`illustrating multiple device types and multiple
`and others.‘ General membership requires com-
`connectivity methods.
`What is universal about the UPnP architecture?
`pletion of a membership agreement2 but is free
`0 It uses common protocols rather than ven-
`of charge. Forum members receive a license to
`the intellectual property necessary to implement
`dor-specific device drivers.
`2 See
`0 It is independent of the underlying physical
`the UPnP specifications and may participate in
`http://www.upnp.org/mom
`media and transports.
`the development of those specifications.
`beIship.hIm for UPnP
`Working committees produce the DCPs. In
`' UPnP devices can be implemented using
`Forum membership infor-
`2001, working committees were developing
`any programming language, and on any
`mation.
`DCPS for audio-visual devices, home automation
`operating system.
`
`¢:':".'::.—_:."-_-":_"_ :-:3
`
`UPnP is a trademark of
`the UPnP lmplementers
`Corporation.
`
`’ A complete current
`membership list is avail-
`able at
`htlp://www.upnp.0rg/[om
`m/menibersthtm
`
`104
`
`0163-6804/0|/$1011) © 2001 IEEE
`
`IEEE_ Communications Magazine - December 2001
`
`Netflix, Inc- Exhibit 1011
`
`

`
`
`
`Remote
`control
`
`
`
`Wireless access
`poi,“
`
`C
`
`amera
`
`Cable modem
`
`“EWired LAN
`
`E 1
`
`394
`
`AC power
`
`Lighting
`
`Appliance
`
`.
`
`i
`
`I |
`
`|
`
`]
`
`UPnP vendor defined
`
`UPnP Forum working committee defined
`
`UPnP device architecture defined
`
`
`
`Figure 2. The UPnP protocol stack.
`
`If no DHCP server responds, the device uses
`automatic IP addressing [5]. lt randomly chooses
`an address in the 169.254/16 range, and tests it
`using an Address Resolution Protocol [6] probe
`to determine if it is already in use. If so, another
`address is chosen and tested until an unused
`address is found. It then periodically checks for
`the existence of a DHCP server; if a server
`responds, the device uses the assigned address,
`and stops using the address selected by Auto-IP
`after a period of parallel use to complete inter-
`actions in progress.
`In addition to numeric IP addresses, names can
`be used to access devices if they are identified in a
`Domain Name Service (DNS) server [7, 8]. Device
`names could be registered manually, dynamically
`according to [9], or by the DHCP server.
`DISCOVERY
`
`
`
`I Figure 1.An example UPnP topology.
`
`and security equipment, appliances, printers,
`cameras and other imaging devices, and Internet
`gateways. The steering committee governs the
`overall business of the Forum, establishing work-
`ing committees, ratifying DCPs, and guiding the
`Forum in general. Steering committee members
`are elected by the Forum’s members}
`For UPnP v. 1, the Forum has completed or
`will complete dozens of DCPs for various classes
`of UPnP devices. As DCPs are ratified, they are
`published on the Forum’s Web site at
`http://www.upnp.org.
`
`TECHNICAL DESCRIPTION
`OVERVIEW
`
`The UPnP Device Architecture [2] defines the
`protocols for communication between UPnP
`control points and devices. These protocols are
`illustrated in Fig. 2,
`taken from [3], and
`described further in following sections. The
`architecture specifies six phases of interaction:
`0 Addressing, by which devices obtain an IP
`address
`
`- Discovery, by which control points become
`aware of the existence of devices
`° Description, by which control points learn
`details about devices and their services
`- Control, in which control points invokc ser-
`vice actions
`0 Eventing, by which devices notify control
`points of changes in state
`- Presentation, by which devices can present
`Web pages to control points allowing for
`status and control interactions
`
`ADDRESSING
`
`3 The Stectirtg Committee
`consists ofup to 20 mem-
`Every UPnP device incorporates a Dynamic
`ber companies. A com-
`Host Configuration Protocol [4] client and
`plete list of current
`searches for a DHCP server when initially con-
`Devices advertise their services to control points
`Steering Committee mem-
`nected to the network. A device first requests an
`on the network using the UPnP discovery proto-
`bers can be found at
`IP address via DHCP. If a response is received
`col, which is based on the Simple Service Dis-
`/mp://www.upnp.org/fbru
`before a prescribed timeout, the device uses the
`covery Protocol [10]. Control points also may
`m/memberstatemenmthtm
`use SSDP to search for devices of interest on the
`dynamically assigned address.
`
`
`IEEE Communications Magazine - December 2001
`
`105
`
`Netflix, Inc- Exhibit 1011
`
`

`
` :-T
`
`Cmf? " *7
`
`Formed in 1999,
`
`the Forum now
`
`has more than
`
`350 member
`
`companies from
`
`many industries,
`
`including
`consumer
`
`electronics, home
`automation
`
`and security,
`
`computers and
`
`peripherals,
`
`networking,
`
`appliances,
`
`semiconductors,
`and others.
`
`or state. When a control point retrieves a device’s
`description, these added features are exposed to
`the control point for control and eventing.
`Retrieving a UPnP device description is sim-
`ple: the control point issues a GET request on
`the URL in the discovery message, and the
`device returns the device description in the body
`of an HTTP response [14]. Retrieving a UPnP
`service description is a similar process that uses
`a URL within the device description.
`
`CONTROL
`
`Having obtained knowledge of a device and its
`services, a control point can ask those services to
`invoke actions. Invoking actions is a form of
`remote procedure call; a control point sends the
`action to the device's service, and when the
`action has completed (or failed), the service
`returns any results or errors.
`Actions are invoked by sending a message to
`the control URL for the service. Control mes-
`sages are expressed in XML using the Simple
`Object Access Protocol [15] and sent via HTTP
`requests; results and errors are received via
`HTTP responses. The effects of the action, if
`any, are modeled by changes in the variables
`that describe the runtime state of the service and
`may be reflected in event messages.
`
`EVENTING
`
`network. The fundamental exchange in both
`cases is a discovery message containing a few
`specific attributes of the device or one of its ser-
`vices: its type, a unique identifier, and a pointer
`to more detailed information.
`Devices multicast, using a well-known address
`and port, several NOTIFY messages advertising
`the availability of embedded devices and services
`[1 1]. Control points monitor this standard multi-
`cast address for notifications that new capabili-
`ties are available.
`Advertisement messages indicate the lifetime
`of the advertisement. If a device remains avail-
`able, it retransmits its advertisements well before
`the lifetime expiration. If a device or service
`becomes unavailable and an orderly shutdown is
`possible, previous advertisements are cancelled by
`sending cancellation messages; otherwise, adver-
`tisements eventually expire on their own. The life-
`time for advertisements is selected to balance the
`need to minimize network traffic with the desire
`to maximize the currency of device status.
`Control points may search for devices or ser-
`vices of interest by multicasting an SSDP M-
`SEARCH message. Responses from devices
`contain information essentially identical to adver-
`tisement messagcs, but responses to search requests
`are unicast directly to the requesting control point.
`The time to live (TTL) field in the IP header
`of multicast discovery messages is set to a small
`value to reduce propagation of UPnP messages .
`beyond the boundaries of the local network,
`hence limiting the scope of advertisement.
`
`DESCRlP110N
`
`After a control point has discovered a device, it
`uses a URL contained in the discovery message
`to request a UPnP description from the device.
`The description includes a device description and
`one or more service descriptions.
`The device description includes vendor-spe-
`cific information such as the model name and
`number, serial number, and manufacturer name.
`For each service included in the device, the
`device description lists the service type, name,
`and URLs for the service description, control,
`and eventing. A device description may include
`descriptions of embedded devices and a URL to
`access a presentation page.
`A service description includes a list of actions
`the service responds to, arguments for each
`action, and a list of state variables. The variables
`model the state of the service at runtime and are
`described in terms of their data type, range, and
`event characteristics.
`
`A UPnP service description includes a list of
`actions to which the service responds and a list
`of variables that model the state of the service at
`runtime. The service publishes updates, in the
`form of event messages, when these variables
`change and a control point may subscribe to
`receive this information.
`To subscribe to event notification, a control
`point sends a subscription message to the sub-
`scription URL specified in the device description
`and provides a delivery URL to which event
`notifications should be sent. The subscription
`message is a request to receive all event mes-
`sages; no mechanism is provided to subscribe to
`a subset of cvcnted state variables. All sub-
`scribed control points receive all event messages
`regardless of why the state variable changed.
`If the subscription is accepted, the device
`responds with a unique identifier for the sub-
`scription and the duration of the subscription.
`The device then sends an initial event message
`to the control point that includes the names and
`current values for all evented variables.
`When an evented state variable changes, the
`service notifies subscribed control points by send-
`ing event messages. These messages are GENA
`UPnP descriptions use XML syntax and are
`NOTIFY messages, sent using HTTP, that con-
`based on a standard UPnP device template or ser-
`tain within their body an XML structure that
`vice template [12]. Device and service templates
`specifies the names of one or more state variables
`are produced by the UPnP Forum and derived
`and the new values of those variables. Event mes-
`from the UPnP template language. The template
`sages are sent as soon as possible after the state
`language itself is written in XML syntax and is
`changes so that control points receive accurate
`derived from an XML schema language [13].
`and timely information about the service, allowing
`Because the template language, templates, and
`them to display a responsive user interface. Con-
`descriptions are all machine-readable, automat-
`ed tools can be used to ensure that the latter
`trol points acknowledge receipt of event messages
`by responding with an HTTP OK message. Event
`two have all required elements, are correctly
`notifications contain sequence numbers to allow
`nested, and have values of the correct data types.
`UPnP vendors can differentiate their devices
`detection of lost or out-of-order messages.
`Some state variable values might change too
`by extending services, embedding other devices,
`rapidly for eventing to be useful. Event notifica-
`and including additional UPnP services, actions,
`
`106
`
`IEEE Communications Magazine 0 December 2001
`
`Netflixiie Exhibit 1011
`
`

`
`
`
`Unlike the UPnP
`
`device and service
`
`descriptions, the
`contents of a
`
`presentation page
`
`are completely
`
`specified by the
`UPnP vendor. A
`
`presentation page
`need not be
`
`present, but if
`
`present it must
`
`be an HTML page
`and should be
`
`written in HTML
`
`version 3.0
`
`or later.
`
`tions for such state variables may be filtered;
`devices send notifications only when the degree
`of change exceeds a limit or a specified amount
`of time has elapsed since the last notification.
`The parameters for these filters are specified in
`the service description.
`To keep a subscription active. the control
`point sends a message to renew the subscription
`before it expires. The renewal message is sent to
`the same URL as the subscription message, and
`specifies the subscription identifier received
`when the subscription was accepted. The
`response for a renewal message is the same as
`one for a subscription message, updating the
`lifetime of the subscription. Should a subscrip-
`tion expire, the device stops sending event mes-
`sages to that control point; any attempt to renew
`the expired subscription is rejected.
`When a control point no longer needs event
`notifications from a particular service, it cancels
`its subscription by sending an appropriate mes-
`sage to the subscription URL.
`PRESENTATION
`
`In addition to the functional interface provided
`by control and eventing, devices may also pro-
`vide a presentation URL for a “Web” interface,
`accessible from a standard Web browser. If such
`a URL is provided in the device description, the
`control point can use an HTTP GET request to
`retrieve an HTML page from this URL, load the
`page into a browser. and allow a user to control
`the device and view device status. The degree to
`which control and status monitoring can be
`accomplished depends on the specific capabili-
`ties of the presentation page and device.
`Unlike the UPnP device and service descrip-
`tions, the contents of a presentation page are
`completely specified by the UPnP vendor. A
`presentation page need not be present, but if
`present it must be an HTML page and should be
`written in HTML v. 3.0 or later. The architec-
`ture does not define further requirements for
`presentation pages, but certain design character-
`istics are recommended.
`
`USAGE SCENARIOS
`
`Forum is actively defining DCPs for more than a
`dozen devices, enabling several popular usage
`cases. Here we describe some usage cases that are
`likely to benefit from the use of UPnP technology.
`
`USAGE CASE 1: UPNP lunznnsr GATEWAYS
`
`With the proliferation of multiple-PC house-
`holds and the wide deployment of broadband
`services, Internet gateways are becoming popular
`as consumers seek to share their high-speed
`Internet connection among multiple devices.
`Internet gateways typically employ Network
`Address Translation (NAT) function to allow mul-
`tiple home PCs and other Internet devices to share
`the external IP address that is assigned by the
`Internet service provider. The UPnP Internet gate-
`way can help to solve a problem that often con-
`fronts home and small business users: peer-to-pccr
`applications such as videoconferencing, IP telepho-
`ny, and online gaming don’t work with NAT
`because devices that share a single IP address can-
`not be identified uniquely over the Internet.
`Consider a hypothetical user, Paula, who ini-
`tially has a PC in the den with a 56K modem con-
`nection to the Internet. Paula recently purchased
`a second PC to browse the Web and run other
`Internet applications while she is in the kitchen.
`She installs a wireless home network and an
`Internet gateway to allow both PCs to share a
`new asynchronous digital subscriber line (ADSL)
`broadband connection. Paula discovers that the
`online gaming and peer-to-peer applications that
`worked well with only one PC no longer work.
`Even after calling the technical support hotline,
`Paula, like most consumers, still could not figure
`out how to manually set up the gateway’s port
`mapping table to make the non-UPnP gateway
`work as she would like. When Paula learns that
`her online gaming and peer-to-peer applications
`already have UPnP capability, she installs a new
`UPnP Internet gateway and her applications run
`as expected, without any configuration.
`UPnP technology automates the processes of
`discovering the Internet gateway and configuring
`the port mapping function that maps applications
`running in the home to unique external port num-
`bers that are visible to external peers. A UPnP
`Internet gateway can also generate event notifica-
`tions when the conncction speed changes or a
`connection is lost. Applications might take advan-
`tage of this information and adjust themselves
`accordingly. The UPnP architecture allows con-
`trol points to work seamlessly with Internet gate-
`ways without user intervcntion. Hence, Paula
`can enjoy Internet browsing and online gaming
`with friends and get the most out of her home
`network and high-speed Internet connection.
`
`Consumers are interested in the usage cases
`enabled by the UPnP architecture. As home net-
`works become more widespread, consumers
`increasingly will appreciate the value of sharing
`and accessing many devices via a home network.
`UPnP technology permits devices to be used
`anywhere within a home network. With the
`advent of low-cost wireless communication meth-
`ods such as IEEE" 802.11 and Bluetooth"‘
`technologies, the network’s reach might extend
`to the entire house and yard. Devices can be
`located where it is most convenient and con-
`Another device approaching final standardiza-
`tion in the UPnP Forum is the printer. The stan-
`trolled from any UPnP control point, including
`PCs, Internet appliances, and mobile devices.
`dard UPnP printer definition enables a control
`Ease of use is critical to the success of the
`point to print to any UPnP printer without prior
`home network. Home networking is intended to
`configuration. Traditionally, a user wishing to
`IEEE and IEEE 802 and
`make life easier for consumers, enabling them to
`share a printer among different PCs needs to
`its derivatives are regis-
`share resources and access devices from any loca-
`install the appropriate printer driver on each PC.
`tered trademarks of the
`tion. These benefits are realized only if devices are
`If a printer is a network printer, prior knowledge
`Institute for Electrical and
`easy to use; the success of home networking could
`of either the printer or a print server’s identity is
`Electronics Engineers,
`be severely limited if device and network configu-
`required. UPnP technology automates the dis-
`Inc.
`ration is required. To foster ease of use, the UPnl’
`covery and configuration processes.
`
`
`USAGE CASE 2: THE PRINTER
`
`
`
`Blueroorh Lt a trademark
`of the Bluetoath Special
`Interest Group, Inc.
`
`IEEE Communications Magazine 0 December 2001
`
`107
`
`Netflix, Inc- Exhibit 1011
`
`

`
`
`
`
`
`C_“‘—“""“““|_..__ ._ __.._
`
`To enable
`
`complete
`
`interoperability,
`
`agreement on
`data formats is
`
`required for
`devices such as
`
`printers. The
`UPnP architecture
`
`does not
`
`prescribe a spe-
`cific data transfer
`
`format; however,
`
`the UPnP printer
`
`working
`committee has
`
`standardized
`
`basic formats to
`ensure
`
`interoperability.
`
`108
`
`For example, suppose Paula has a printer
`attached to her wireless network. She comes
`home from work one day and turns on the televi-
`sion to watch the news. During a commercial, she
`wishes to print an e-mail from her PDA. UPnP
`technology enables Paula’s PDA to discover the
`available printers in the home. Paula selects one
`and prints her document. The UPnP architecture
`provides a standard control protocol for interact-
`ing with the printer and alerts her to abnormal
`conditions such as paper jams. If Paula’s home
`network consisted of a mixture of wired and wire-
`less networks, UPnP technology would allow her
`PDA to find the printer regardless of the physical
`network to which it is attached.
`To enable complete interoperability, agree-
`ment on data formats is required for devices
`such as printers. The UPnP architecture does
`not prescribe a specific data transfer format;
`however, the UPnP printer working committee
`has standardized basic formats to ensure inter-
`operability. All UPnP printers must support an
`XHMTL-based page description language and
`JPEG-encoded images. Other document and
`image formats may be supported at the manu-
`facturer’s discretion.
`
`USAGE CASE 3: MUL11MEDlA APPLICATIONS
`
`An exciting range of multimedia applications for
`consumer electronic devices, PCs, and even some
`mobile devices could be enabled by specifications
`being cooperatively developed by the UPnP
`Forum’s audio, audio-visual, camera, and electron-
`ic picture frame working committees. The goal is
`to enable users to store, play, and view audio and
`video content across this range of device classes.
`Consider again our hypothetical uscr Paula,
`and suppose that she purchases a UPnP camera
`with a networked docking station. When Paula
`returns home from her son Ben’s soccer match
`and docks the camera, her PC-based image man-
`agcmcnt application notes that the camera is now
`available on the network. The application queries
`the camera, finds new content, and automatically
`retrieves the new soccer match pictures. Later
`that night, when Paula checks her e-mail, she
`already has at her fingertips the favorite photos
`of the day. which she then e-mails to Ben's grand-
`father. She also programs hcr electronic picture
`frame to include one particular favorite in its
`repeating slidcshow for the next week.
`While checking her c-mail, Paula learns that
`a new recording by her favorite artist is avail-
`able. Paula visits the recording label’s Web site,
`purchases a copy of one of the songs, and initi-
`ates a download of the song to her new audio
`player in the family room. Later that night Paula
`decides to listen to the song on her home enter-
`tainment system. Using her remote control, she
`selects the new recording from her audio player
`and plays it on her stereo.
`Several key factors empower these usage
`cases and many others. Beyond the basic discov-
`ery, descriptive and control capabilities provided
`by the UPnP architecture, work is in progress to
`define a standard model for a multimedia stor-
`age service, leveraging emerging XML-based
`frameworks such as MPEG-21. Moreover. by
`developing common mechanisms to establish
`and manage data transfer, different multimedia
`
`devices could intcroperate. In addition to sup-
`porting [P-based protocols such as HTTP and
`RTSP, working committees are defining support
`for non-IP-based mechanisms such as IEEE
`1394 and direct analog connections. Although
`control information by necessity uses an IP-
`based network, data transfer need not do so.
`Note that some devices could act as both
`UPnP controlled devices that implement one or
`more UPnP DCPs, and UPnP control points. For
`example, a digital camcorder might control other
`UPnP devices. Vendors are free to implement
`whatever control functionality is appropriate; a
`camcorder might allow a user to send video
`directly from the camcorder to a picture frame or
`digital television. A camcorder also might allow
`the user to print still snapshots on a printer.
`Although UPnP control points can discover any
`UPnP device, they can only interact with or con-
`trol those devices or services for which they have
`prior knowledge of the interaction model.
`
`UPNP TECHNOLOGY BENEFITS FOR
`
`HOME NET\NORK|NG
`STANDARDS-BASED
`
`Universal Plug and Play builds on existing proto-
`cols and technology (including IP, TCP, UDP,
`HTTP, H'l‘M L, SOAP, and XML) whenever
`practical. The Internet provides highly proven,
`well understood, and open networking technolo-
`gy that is easy to use. IP internetworking is well
`suited for UPnP because it has provcn its ability
`to span different physical media, enable real-
`world multivendor interoperation, and achieve
`synergy with the Internet and many home and
`office intranets. Mixed-media multivendor net-
`works are likely to become common in the
`future, and the UPnP architecture has been
`designed explicitly for these environments.
`
`UNIVERSALITY
`
`By leveraging Internet protocols, UPnP technol-
`ogy is ideally suited for cross-device cross-net-
`work deployment.
`It can work with any
`underlying networking technology that supports
`IP traffic, but it does not require all devices to
`include an ll’ stack. Cost, technology, or legacy
`might prccludc IP traffic for some media and
`devices. By using UPnP protocol bridges, devices
`that communicate with non-IP protocols can
`participate in UPnP networks.
`Furthennore, the UPnP architecture is based
`on the notion of sending only data, not exe-
`cutable code, between control points and devices.
`Data is transmitted in a platform-independent
`manner, allowing vendors to select the most
`appropriate operating system and language for
`device and control point implementation.
`Although the UPnP architecture provides a
`mechanism for universal control, it does not stip-
`ulate universality of data transfer. Instead, com-
`mon data formats within certain domains and
`usage cases may be agreed on, such as the previ-
`ously described example of XHTML and JPEG
`formats for UPnP printers. In some scenarios, the
`control point and controlled device might use
`UPnP control protocols at runtimc to negotiate
`mutually supported formats for data transfer.
`
`IEEE Communications Magazine 0 December 2001
`
`Netflix, Inc.
`
`l Exhibit 1011
`
`

`
`
`
`FUTURE WORK
`
`UPnP version 1 is well on its way toward com-
`pletion, with version 1 of the Device Architec-
`ture publicly available and DCPS for many device
`classes approaching finality. Several potential
`areas of future work are discussed next.
`UPnP v. 1 does not directly specify any coun-
`termeasures for security threats, but instead
`leverages security features found in the stan-
`dards-based protocols on which the UPnP archi-
`tecture is built. Among these are network
`isolation (firewalls), medium access control layer
`encryption, and physical access control. Because
`these measures alone are not sufficient to
`address all scenarios, a security working commit-
`tee has been formed within the Forum to inves-
`tigatc potential future security enhancements.
`To help foster interworking with other tech-
`nologies, the UPnP Forum surveys other stan-
`dards—based initiatives with potential synergy. For
`example, the Forum is investigating possible
`future exploitation of common elements of the
`UPnP architecture and Web services,‘ which today
`share some protocols. Another example is work
`underway within the Bluetooth Special Interest
`Group5 to develop a UPnP Bluetooth profile. Of
`course, because the UPnP architecture is based on
`IP, future use of IPv6° must be considered.
`Although the version 1 DCPs address many
`device classes, numerous other devices types
`could be candidates for future DCPs. The UPnP
`Forum actively solicits new members with exper-
`tise in devices that could benefit from UPnP tech-
`nology and welcomes proposals for new DCPs.
`
`SUMMARY
`
`REFERENCES
`[1] Universal Plug and Play Forum, About the Universal
`Plug and Play Forum, 1999, http://www.upnp.org/
`forum/defaulnhtm
`[2] Microsoft Corp., Universal Plug and Play Device Archi-
`tecture, v. 1.0, lune 2000, http:/lwww.upnp.org/
`download/UPnPDA1o_2o00o613.htm
`(31 Universal Plug and Play Forum, Understanding Universal
`Plug and Play, 2000, httpi/www.upnpbrgldownloadl
`UPNP_UnderstandingUPNP.doc
`[4] Drorns. "Dynamic Host Configuration Protocol," IETF
`RFC 2131, 1997, httpv/www.ietf.org/rfc/rfc2l31.txt
`[5] “Automatically Choosing an IP Address in an Ad-Hoc
`IPv4 Network," IETF draft, httpJ/search.iett'.orgfinternet-
`drafts/draft-ietf-dhc-ipvdsautoconfig-D5.txt
`[61 Plummet, “An Ethernet Address Resolution Protocol."
`IETF RFC 826, 1982. httpfl/wwwjetl.org/rfr/rfc0826.txt?
`nurnber=826
`I7] Moclrapetris, Internet Engineering Task Force RFC ‘I034.
`Domain Names - Concepts and Facilities, 1987,
`http://www.ietf.org/rfc/rfcl 034.txt
`[8] Mockapetris, Internet Engineering Task Force RFC I035.
`Domain Names - Implementation and Specification.
`1987. httpi/lNvvw.ietf.org/rf<lrfcl035.‘bn
`[9] Vixie et al., lnternet Engineering Task Force RFC 2136,
`Dynamic Updates in the Domain Name System, 1997,
`|'Ittp'l/www.ietf.org/rfclrfczl 36.txt
`[10] Goland er al., Internet Engineering Task Force draft,
`Simple Service Discovery Protocol, 2000; http://www.
`upnp.org/download/draft_cai_ssdp_v1_O3.txt
`[1 1] Cohen, Aggarwal. and Golan. General Event Notifica-
`tion Architecture, IETF draft, 2000, http://www.upnp.
`org/draft—cohen-gena-client-01 .ott
`[12] W3C, "Extensible Markup Language." http://www.w3.
`orglXML
`[131 Layman er al.. "W3C Note XML-Data," 1998.
`http‘.//www.w3.org/Tl?/1 998/NOTE-XML-data; Frankston
`and Thompson,
`"XML—Data Reduced," 1998.
`httpz//www.ltg.ed.ac.uk/--htlXMLData-Reducedltfm
`[14] Fielding et al., "HTTP: Hypertext Transfer Protocol 1.1,"
`IETF RFC 2616, 1999, http://www.ietf.orglrfc/rfc26l6.txt
`[15] W3C tech. rep., "Simple Object Access Protocol v.
`1.2," 2001, http://www.w3.ol'gfl'RJ'S0apl2
`
`Universal Plug
`
`and Play builds
`
`upon existing
`
`protocols and
`
`technology
`
`(including lP, TCP,
`
`UDP, HTTP,
`
`HTML, SOAP, and
`
`XML) whenever
`
`practical. The
`
`Internet provides
`
`highly proven,
`well understood
`
`and open
`
`networking
`
`technology that is
`
`easy to use.
`
`ADDITIONAL READlNGS
`[1] W3C, Hypertext Markup Language. http1/www.w3.org/
`Markup
`
`In this article we introduced Universal Plug and
`Play, an architecture for easy and robust connec-
`BIOGRAPHIES
`tivity of many sorts of devices in homes, offices,
`and elsewhere. The UPnP Forum is a multicom-
`BRENT A. MILLER (bamiller@us.ibm.corn) is a senior software
`engineer in IBM's Software Solutions Division in Research
`pany organization that develops the UPnP DCPs.
`Triangle Park. North Carolina. He has been involved with
`The theory of operation for UPnP technology is
`UPnP technology for two years, serving as lBM's original
`based on the UPnP Device Architecture v. 1.0.
`representative to the UPnP Forum Steering Committee. He
`is co-author of the book Bluetooth Revealed (Prentice-Hall.
`Important aspects of the architecture are addressing,
`2000). He holds a 8.5. in computer and information sci-
`discovery, description, control, eventing, and presen-
`ence from the Ohio State University.
`tation. Together these elements enable seamless net-
`Toav NIXON (SM,
`'99] (tnixon@microsoft.com) is architect
`working of multiple classes of devices, such as
`for UPnP in the Windows Networking group at Microsoft,
`printers, Internet gateways, and multimedia devices
`and chairs the UPnP Forum Technical Committee. with
`Universal Plug and Play offers advantages for
`Microsoft since 1993. he has worked in many industry and
`standards organizations, chaired U.S. and ITU committees
`home networking applications, including:
`on modem