[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03

Internet Engineering Task Force                        Yaron Y. Goland
INTERNET DRAFT                                                Ting Cai
                                                            Paul Leach
                                                                 Ye Gu
                                                 Microsoft Corporation
                                                      Shivaun Albright
                                               Hewlett-Packard Company
                                                         June 21, 1999
                                                 Expires December 1999



                 Simple Service Discovery Protocol/1.0
                       <draft-cai-ssdp-v1-02.txt>



Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   This document is an Internet-Draft. Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time.  It is inappropriate to use Internet- Drafts as
   reference material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Abstract

   The Simple Service Discovery Protocol (SSDP) provides a mechanism
   where by network clients, with little or no static configuration,
   can discover network services. SSDP accomplishes this by providing
   for multicast discovery support as well as server based notification
   and discovery routing.

1.   Introduction

   With the growing number of small peer-to-peer TCP/IP networks, such
   as home or small office networks, users need a way to discover
   resources in a network easily, quickly, dynamically, and without any
   a priori knowledge.  This document provides a discovery protocol
   that meets this user requirement.




Goland et al.                                                 [Page 1]


INTERNET-DRAFT                 SSDP/V2                  June 21, 1999


   The proposed protocol is called the Simple Service Discovery
   Protocol (SSDP).

   SSDP provides support for services declaring their presence.

   SSDP provides support for those seeking services to search for the
   desired services.

   SSDP provides support for subscription arbiters as defined in [GENA]
   with limited SEARCH method support so allow clients to discover
   services and receive service notifications.

2.   Terminology

   Client - A HTTP resource that makes use of a service.

   Service - A HTTP resource that provides a service used by clients.

   SSDP Proxy - A SSDP service that routes notifications from services
   to clients, maintains a store reflecting the current state of
   services in the system and allows clients to search that store in
   order to ascertain information about the current state of the
   system.

   Service Type - A URI that identifies the nature of a service.
   Service types can be very broad, for example, all SSDP compliant
   services to very narrow, a particular batch of a particular model of
   a particular product that comes in green. Service type URIs are
   treated as opaque identifiers by the SSDP protocol.

   Unique Service Name (USN) - An identifier that is unique across all
   services for all time. It is used to uniquely identify a particular
   service in order to allow services of identical service type to be
   differentiated.

   In addition, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
   "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   RFC 2119 [RFC2119].

3.   SSDP Resources

3.1. Services

3.1.1.    Overview

   A non-SSDP proxy aware service is a very simple resource. When it
   wakes up it sends a httpmu ssdp:alive NOTIFY message to the SSDP
   reserved multicast channel and then it waits.

   If it should receive a httpmu ssdp:discover SEARCH request over the
   SSDP reserved multicast channel then it will check the ST header. If


Goland et al.                                                 [Page 2]


INTERNET-DRAFT                 SSDP/V2                  June 21, 1999


   the value in the ST header matches its service type then it will
   send a httpmu response to the requestor.

   If it should receive a httpmu ssdp:notproxyaware SEARCH request over
   the SSDP reserved multicast channel then it will send a httpmu
   response. The response is the exact same response it would have sent
   for a matching ssdp:discover SEARCH request.

   If the service sends out caching information, which it should, then
   it will also send out a ssdp:alive NOTIFY request to the SSDP
   reserved multicast channel before the expiration given in its
   previous SEARCH responses and NOTIFY requests.

   Finally, if the service is able, it will send out a ssdp:byebye
   NOTIFY request to the SSDP reserved multicast channel before it goes
   off-line.

3.1.2.    Requirements

   SSDP compliant services MUST have a USN and a service type URI.

   SSDP compliant services SHOULD monitor the SSDP reserved multicast
   channel for SEARCH requests.

   SSDP compliant services that monitor the SSDP reserved multicast
   channel MUST support ssdp:discovery and ssdp:notproxyaware SEARCH
   request extensions sent over the SSDP reserved multicast channel.

   SSDP compliant services SHOULD send out a ssdp:alive NOTIFY method
   when they first join a new network.

   SSDP services MUST NOT send out more than MAXNOTE NOTIFY requests a
   minute to the SSDP reserved multicast channel.

   [Ed. Note: The number 5 is totally arbitrary. But we need a very
   hard limitation to keep the channel from getting overloaded. Anyone
   who needs more than 5 notify requests a minute needs to be a proxy
   aware service.]

3.2. Proxy Aware Services

3.2.1.    Overview

   A proxy aware service meets all the requirements for a non-proxy
   aware service plus requires support for http in addition to httpmu,
   is required to perform proxy detection, and support
   ssdp:proxyawareservices SEARCHs.

   See section .4.1 for information on proxy discovery.

   If proxy detection fails then the SSDP aware services will act like
   a non-proxy aware service until it hears a ssdp:alive NOTIFY request


Goland et al.                                                 [Page 3]


INTERNET-DRAFT                 SSDP/V2                  June 21, 1999


   from a proxy over the SSDP reserved multicast channel. In which case
   it will act as specified below.

   If there is a SSDP proxy in the network then the service will send
   it a ssdp:alive NOTIFY request to provide the SSDP proxy with
   information about itself.

   Any further NOTIFY methods the service has to send out will be sent
   directly to the SSDP proxy using http.

   The service will continue to monitor the SSDP reserved multicast
   channel in order to hear the proxy's regular announcements that it
   is still functional. The server may optionally answer any SEARCH
   requests it receives over the SSDP reserved multicast channel.

   If the proxy should fail to send out its regularly ssdp:alive NOTIFY
   request then the service will automatically fall back to using the
   SSDP reserved multicast channel.

3.2.2.    Requirements

   Services which intend to send out a significant number of
   notifications MUST support SSDP proxies as specified in section .0 as
   well as all rules for non-proxy aware SSDP services.

   A proxy aware service MUST follow all the rules for a non-proxy
   aware service with the exception that they MUST support
   ssdp:proxyawareservice SEARCH requests over the SSDP reserved
   multicast channel rather than ssdp:notproxyaware SEARCH requests.

   If a SSDP proxy is discovered then the service MUST send all NOTIFY
   requests to the SSDP proxy using http. When a proxy is available the
   service MAY continue to answer ssdp:discover requests sent over the
   SSDP reserved multicast channel and MUST continue to answer
   ssdp:proxyawareservice SEARCH requests sent over the SSDP reserved
   multicast channel.

3.3. Clients

3.3.1.    Overview

   Upon waking up a client's first task is likely to be initializing
   its cache in order to track services it is interested in.

   The first step in initializing the cache is to find out if there is
   a proxy. Therefore the client will perform proxy discovery as
   specified in section .4.1.

   The next step is to send out ssdp:discovery SEARCH requests for each
   of the service types the client is interested in. If there is a
   proxy then the client will use http to send the requests to the



Goland et al.                                                 [Page 4]


INTERNET-DRAFT                 SSDP/V2                  June 21, 1999


   proxy. If there is no proxy then the client will use httpmu to send
   the requests to the SSDP reserved multicast channel.

   Each response that has caching information, such as an expires
   header or a cache-control: max-age will be put into the client's
   cache.

   The client will expect that services that sent out caching
   information will send out ssdp:alive NOTIFY requests before the
   cached information is set to expire. ssdp:alive NOTIFY requests
   contain the same information as ssdp:discover SEARCH responses.
   Therefore the client can use the ssdp:alive NOTIFY requests to keep
   the cache up to date.

   If there is a proxy then the client will get its notify requests
   through the proxy. That is, the proxy will open a http connection to
   the client and send it notifications. In order to let the proxy know
   what notifications it is interested in the client will use the
   [GENA] SUBSCRIBE method setting the NT header value equal to the
   service types the client is interested in. The client will record
   the timeout value returned in the SUBSCRIBE response so that it can
   make sure to re-subscribe before its subscription expires.

   When using a proxy the client will monitor the SSDP reserved
   multicast channel in order to hear the SSDP proxy's ssdp:alive
   NOTIFY requests. The client will ignore any other NOTIFY requests it
   hears over the SSDP reserved multicast channel when it is using a
   proxy.

   If there isn't a proxy then the client will listen to the SSDP
   reserved multicast channel in order to hear notifications from any
   services that it may be interested in.

   Proxy or not, the client can keep the cache up to date just by
   initializing it with ssdp:discovery SEARCH requests and then
   receiving appropriate ssdp:alive NOTIFY requests.

   If the proxy should fail then the client will switch over to the
   SSDP reserved multicast channel until it hears a ssdp:alive NOTIFY
   request from a proxy. At that point it will repeat the cycle of
   subscribing to the proxy.

3.3.2.    Requirements

   Clients MUST provide for SSDP proxy support as specified in section .
   4.1.

   If a SSDP proxy is present then the client SHOULD use the SUBSCRIBE
   method as defined in [GENA] to subscribe to the proxy for all
   service types the client wishes to receive notifications for. The NT
   header of the SUBSCRIBE method is to be set to the service types the
   client is interested in.


Goland et al.                                                 [Page 5]


INTERNET-DRAFT                 SSDP/V2                  June 21, 1999



   If a SSDP proxy is present then the client SHOULD send all
   ssdp:discover, ssdp:notproxyaware and ssdp:proxyawareservice SEARCH
   requests to the proxy using http rather than to the SSDP reserved
   multicast channel using httpmu.

   When a client is using a SSDP proxy it SHOULD NOT listen to any
   NOTIFY requests it receives over the SSDP reserved multicast channel
   other than those sent by the SSDP proxy. This prohibition is meant
   to allow the proxy to tailor the information a client receives based
   on the client's particular needs.

3.3.3.    SUBSCRIBE example

   SUBSCRIBE dude HTTP/1.1
   Host: iamthedude:203
   NT: <upnp:toaster>
   Callback: <http://blah/bar:923>
   Scope: <http://iamthedude/dude:203>
   Timeout: Infinite

   HTTP/1.1 200 O.K.
   Subscription-ID: uuid:kj9d4fae-7dec-11d0-a765-00a0c91e6bf6
   Timeout: Second-604800

3.4. ssdp:aproxy Service

3.4.1.    Overview

   When a SSDP proxy first wakes up or if it has lost a proxy election
   then it is an un-elected proxy of service type ssdp:aproxy.

   The ssdp:aproxy service's first action will be to perform a proxy
   election. If the ssdp:aproxy service doesn't win the proxy election
   then it will remain a ssdp:aproxy.

   Other than performing proxy election a ssdp:aproxy is just like any
   other proxy aware service, including the need to send out a
   ssdp:alive NOTIFY request when it wakes up and answering
   ssdp:discover and ssdp:proxyawareservices SEARCH requests.

3.4.2.    Requirements

   SSDP proxies are SSDP services of type ssdp:aproxy and MUST comply
   with all requirements for SSDP proxy aware services.

   All SSDP proxies MUST support the proxy election algorithm as
   specified in .4.3.






Goland et al.                                                 [Page 6]


INTERNET-DRAFT                 SSDP/V2                  June 21, 1999


3.5. ssdp:proxy Service

3.5.1.    Overview

   If a ssdp:aproxy wins the proxy election then it still remains a
   ssdp:aproxy service. However it also takes on a new service type,
   ssdp:proxy.

   The main job of a ssdp:proxy service is to cache information
   regarding the state of services in its assigned network. It does
   this by sending out a ssdp:notproxyaware SEARCH request in order to
   obtain information about all the non-proxy aware services. Then it
   sends out a ssdp:alive NOTIFY request of notification type
   ssdp:proxy. This will cause all the SSDP proxy aware services to
   automatically send NOTIFY requests to the proxy informing the proxy
   of their state.

   Services that are not proxy aware will continue to send NOTIFY
   requests to the SSDP reserved multicast channel. The ssdp:proxy is
   responsible for listening to those NOTIFY requests and recording the
   information as specified in section .4.2.

   Services which are SSDP proxy aware will start to send all of their
   NOTIFY requests directly to the proxy using http. As with services
   that aren't SSDP proxy aware, the ssdp:proxy will be responsible for
   recording the information the NOTIFY requests provide.

   In addition to caching NOTIFY information the ssdp:proxy is also a
   subscription arbiter, as defined in [GENA]. This means that the
   ssdp:proxy will accept SUBSCRIBE requests from clients and will
   route NOTIFY requests that it receives accordingly. When the proxy
   announces itself with a ssdp:alive request all clients on the
   network will automatically send their SUBSCRIBE requests to the
   proxy.

   The ssdp:proxy provides very basic SEARCH services, specifically it
   supports ssdp:discover, ssdp:notproxyaware and
   ssdp:proxyawareservice over http. Unlike a normal service the proxy
   is able to answer these SEARCH requests with information for
   services other than itself. This information is taken from the cache
   it built up from the NOTIFY requests it has received. By mapping the
   notification type of the NOTIFY request to service types the
   ssdp:proxy is able to answer SEARCH requests for particular service
   types. Unlike SEARCH requests over the SSDP multicast channel, which
   only have one answer, the ssdp:proxy will often need to return
   multiple responses to a single search request. As such some sort of
   compound format is needed. The property search result format first
   specified in [WEBDAV] and later adopted for SEARCH use in [DASL] is
   used for this purpose.





Goland et al.                                                 [Page 7]


INTERNET-DRAFT                 SSDP/V2                  June 21, 1999


3.5.2.    Requirements

   A ssdp:proxy service MUST also be a ssdp:aproxy service and follow
   all the requirements for ssdp:aproxy services.

   If the ssdp:aproxy service wins the proxy election then it MUST take
   on the service type ssdp:proxy and all the requirements thereof as
   specified in this document.

   ssdp:proxy services are proxy aware services and MUST follow all the
   requirements thereof. Note, however, that a ssdp:proxy does not have
   to send out a proxy discovery request because the ssdp:proxy knows
   through out of band means who the proxy is, i.e. itself.

   Upon becoming a ssdp:proxy service type the ssdp:proxy MUST perform
   a ssdp:notproxyaware SEARCH on the SSDP reserved multicast channel
   as well as announce itself through a ssdp:alive NOTIFY request on
   the SSDP reserved multicast channel.

   All ssdp:alive NOTIFY requests of service type ssdp:proxy MUST
   include a cache-control: max-age directive and a Location and/or AL
   header with at least one http URL.

   ssdp:proxy services MUST NOT provide answers to SEARCH requests
   received through the SSDP reserved multicast channel with
   information about any service but themselves.

   All ssdp:proxy services MUST comply with all requirements for
   subscription arbiters as defined in [GENA].

   ssdp:proxy services MUST record all service information gained from
   NOTIFY requests. If the ssdp:proxy does not have sufficient
   resources to support the current load of services then it MUST send
   out a ssdp:byebye announcement and cease to act as a ssdp:proxy. Any
   SEARCH requests of type ssdp:discover, ssdp:notproxyaware or
   ssdp:proxyawareservice which are sent to the location in the
   ssdp:alive NOTIFY request MUST be answered based on the complete
   dataset collected from the NOTIFY requests in addition to any extra
   service information the ssdp:proxy may have available.

   ssdp:proxy services MUST be able to map the value in the NT header
   on a SUBSCRIBE request to the ST header value in both ssdp:discover
   SEARCH and ssdp:alive/ssdp:byebye NOTIFY requests.

4.   SSDP Algorithms

4.1. SSDP Proxy Support

   Resources that support SSDP proxies MAY be configured using some
   unspecified mechanism with the address of the SSDP proxy they are to
   use. Resources that support SSDP proxies SHOULD be configured to



Goland et al.                                                 [Page 8]


INTERNET-DRAFT                 SSDP/V2                  June 21, 1999


   perform SSDP proxy discovery if the SSDP proxy they are configured
   to use is not available.

   If a resource that supports SSDP proxies has not been configured
   with a SSDP proxy to support then it MUST perform discovery on
   service type ssdp:proxy in order to determine if a SSDP proxy is
   available.

   Resources that support SSDP proxies MAY begin to make requests
   directly to the reserved multicast channel after the first SSDP
   proxy discovery request has failed without completing the full UDP
   HTTP request cycle. This is often necessary because SSDP proxy
   discovery can take some time and users are notoriously impatient.

   Any time a SSDP proxy supporting resource receives a notification
   that a SSDP proxy is available the resource MUST switch over to
   using the SSDP proxy.

   Resources that support SSDP proxies MUST monitor the reserved
   multicast channel in order to listen for the SSDP proxy's
   notifications. Resources that support SSDP proxies MUST support both
   ssdp:alive and ssdp:byebye notification subtypes when sent by SSDP
   proxies. Resources that support SSDP proxies MAY ignore any other
   notification subtypes sent by the SSDP proxy.

   If the time between required ssdp:alive notifications should pass
   without receiving a notification then the resource MUST assume that
   the proxy is dead and begin using the SSDP reserved multicast
   channel.

   Once a proxy has been declared dead the resource MUST assume that
   the proxy has lost all subscription information for the resource. So
   if the proxy comes back to life the resource will still have to
   resubscribe.

   The ssdp:alive notifications sent out by the SSDP proxy will include
   all the addresses that the SSDP proxy can be accessed through. If
   the current address the SSDP proxy supporting resource is using
   doesn't match any of the listed addresses then the resource MUST
   change to one of the listed addresses. So long as the USN in the
   ssdp:alive notification is the same as the USN of the SSDP proxy the
   resource is currently using there is no need to resubscribe.

   If the USN of a ssdp:alive NOTIFY request from a ssdp:proxy service
   is not the same as the USN of the ssdp:proxy the resource is
   currently using then the resource MUST assume that the new proxy has
   no knowledge of their subscriptions, notifications, etc.







Goland et al.                                                 [Page 9]


INTERNET-DRAFT                 SSDP/V2                  June 21, 1999


4.2. Notification Caching

   ssdp:alive NOTIFY requests contain at minimum a NT header, a NTS
   header, a USN header, a Location and/or AL header and potentially a
   HTTP cache control directive such as expires or cache-control: max-
   age.

   The NTS header, set to ssdp:alive, lets the receiver know that this
   is a notification from a SSDP service.

   The NT header specifies the type of service.

   The USN header specifies the USN for the service.

   The Location and/or AL header specifies locations at which the
   service can be found.

   Using the NT, USN and Location/AL values it is possible to create a
   cache entry for the service keyed to its USN. The entry will
   automatically be purged when the HTTP caching directive directs. If
   no cache lifetime information is provided then the NOTIFY
   information is to be discarded. Note, however, the ssdp:proxy
   services will still be required to route the NOTIFY method as
   specified for a subscription arbiter by [GENA].

   Services keep caches which contain information about them up to date
   by regularly sending out ssdp:alive NOTIFY requests before the
   expiration of their previous ssdp:alive NOTIFY request.

   Many services are best served by having extremely long expiration
   periods. For example, a printer or scanner that is unlikely to be
   moved very often will probably want to have an expiration period of
   a week or more.

4.3. Proxy Election

4.3.1.    Proxy Election Algorithm

   The proxy election algorithm is based on the use of the proxy number
   to determine which ssdp:aproxy should be the ssdp:proxy for the
   local network. Proxy numbers are decimal numbers between 0.0 and 1.
   The number 1 MUST NOT be configured by default into any device. It
   is reserved for use by administrators to force a particular
   ssdp:aproxy to always win election.

   In the case of a tie the USN will break the tie. USNs are compared
   by treating them as strings of bytes and comparing each byte in
   network byte order. The first USN that has a larger byte value than
   the other wins the comparison.

   Proxy elections are carried out by sending out a SSDPC httpmu method
   to the SSDP reserved multicast channel. As soon as the method is


Goland et al.                                                [Page 10]


INTERNET-DRAFT                 SSDP/V2                  June 21, 1999


   sent a timer is set to PROXYWAIT seconds. If no counter challenge is
   made before the timer expires then the challenger has won and MUST
   send out a ssdp:alive NOTIFY request declaring themselves ssdp:proxy
   with all the responsibilities that entails.

   If a SSDPC request is received over the SSDP reserved multicast
   channel before the time expires then the timer must be reset.

   When a SSDPC request is received the receiver MUST compare the PN
   value in the SSDPC request to its own. If the PN in the request is
   higher then the receiver has lost the challenge. If the PN in the
   request is lower then the receiver's then the receiver MUST send out
   another challenge. The reason being that the only way that a
   challenge with a lower PN could have been received is if there is
   another challenge underway which could indicate network connectivity
   problems. To be the safe side another set of challenges are issued.
   Note that the re-broadcast could cause a cascade of new challenges
   in the worst case. Finally, if the two PNs are equal then the USNs
   are to be compared. If the challenger's USN is larger as previously
   defined then the receiver has lost the challenge. If the USN is
   smaller then the challenge should be repeated for the same reasons
   as previously stated. If the two USNs are the same panic is probably
   called for, as this should be statistically impossible.

   On the off chance that the previous was somehow comprehensible the
   following pseudo-code is offered to completely confuse the reader
   and hopefully directly contradict the previous text.

   Challenge(PN, USN) {
      If (Challenge is not already underway)
         Send a SSDPC method with PN & USN headers;
      Proxy = Self;
      Set Timer to ProxyWait Seconds;
      While (Timer Isn't Up & Not Received a Message) {
         If Received ssdp:alive NOTIFY from ssdp:aproxy {
            If (Message.PN > PN) Proxy = Message;
            If (Message.PN == PN) {
               If (Message.USN > USN) {
                  Send a SSDPC method with PN & USN headers;
                  Proxy = Message;
               }
               ElseIf (Message.USN < USN)
                  Send a SSDPC method with PN & USN headers;
               ElseIf (Message.USN == USN) PANIC;
            }
            If (message.PN < PN)
               Send a SSDPC method with PN & USN headers;
            Set Timer to ProxyWait Seconds;
            Continue;
         }
         If (Time is Up) {
            If (Proxy == Self) Declare Self Proxy;


Goland et al.                                                [Page 11]


INTERNET-DRAFT                 SSDP/V2                  June 21, 1999


            Exit;
         }
      }
   }

4.3.2.    When Proxy Elections Occur

   When a ssdp:aproxy service first connects to a new network, since it
   is by definition a proxy aware service, it will perform proxy
   discovery. If no response is received within the retry/time out
   interval defined by [HTTPUDP] then the ssdp:aproxy MUST issue a
   challenge.

   Anytime a ssdp:aproxy receives a ssdp:alive NOTIFY request from a
   ssdp:proxy with a PN/USN lower than its own, a challenge MUST be
   issued.

   Anytime a ssdp:proxy receives a ssdp:alive NOTIFY request from
   another ssdp:proxy, indicating a network communication failure or a
   buggy proxy, regardless of the PN/USN pair the receiving ssdp:proxy
   MUST issue a challenge. This will hopefully allow buggy proxies to
   recover and/or increase the chance of communicating over the
   apparent network problem.

   Anytime a ssdp:aproxy service, remember that ssdp:proxy services are
   also ssdp:aproxy, receives a SSDPC request then the ssdp:aproxy MUST
   enter challenge mode if it isn't already in it.

   ssdp:proxy resources who loose an election MUST NOT issue a
   ssdp:byebye NOTIFY request. This will cause needless proxy detection
   requests by proxy aware services and clients. The proxy election
   winner will issue a ssdp:alive NOTIFY request that will cause all of
   the loosing proxy's clients and services to switch over.

5.   SSDPC httpmu Method

   The SSDPC httpmu method is sent to the SSDP reserved multicast
   channel and MUST have two headers, PN and USN. There is no response
   to the SSDPC method.

5.1. Example

   SSDPC * HTTP/1.1
   Host: SSDPreservedmulticastchannel
   PN: 0.001
   USN: someunique:idscheme3








Goland et al.                                                [Page 12]


INTERNET-DRAFT                 SSDP/V2                  June 21, 1999


6.   SSDP SEARCH Extensions

6.1. ssdp:discover SEARCH Extension

   The purpose of the ssdp:discover SEARCH method is to find out about
   services available on a network.

   The ssdp:discover SEARCH method is a SEARCH method which has been
   extended using the mechanism defined in [MAN].

   The ssdp:discover SEARCH methods MUST have a ST header. They MAY
   have a body but the body MAY be ignored if not understood.

6.1.1.    ssdp:discover over httpmu

   Only services whose service type matches the value in the ST header
   of a ssdp:discover SEARCH method MAY respond to a ssdp:discover
   SEARCH method received of httpmu. All other resources MUST NOT
   respond.

   Services MUST only respond for themselves to ssdp:discover SEARCH
   methods received over httpmu.

   The response to a ssdp:discover SEARCH method received over the SSDP
   reserved multicast channel is to be sent to the IP address and port
   of the requestor. The response MUST include a ST header set to the
   same service type as the request and a USN header containing the
   service's USN. The response SHOULD include a Location and/or AL
   header.

6.1.1.1.  Example

   M-SEARCH * HTTP/1.1
   Host: reservedSSDPmulticastaddress
   Man: ssdp:discovery
   ST: ge:fridge
   MM: 0
   MX: 3

   HTTP/1.1 200 OK
   ST: upnp:blender
   USN: uuid:abcdefgh-7dec-11d0-a765-00a0c91e6bf6
   AL: <blender:ixl><http://foo/bar>

6.1.2.    ssdp:discover over http

   Services MAY respond for other services to ssdp:discover SEARCH
   methods received over http. For example, this is how ssdp:proxies
   behave.





Goland et al.                                                [Page 13]


INTERNET-DRAFT                 SSDP/V2                  June 21, 1999


   The response to the ssdp:discover SEARCH method when sent over http
   MUST comply with the response to the SEARCH method as specified in
   [DASL].

   The location provided for each service response MUST be the
   service's USN. Each response MUST include the servicetype property
   and SHOULD include the location property.

   Support for ssdp:discover does not imply nor require support for
   [WEBDAV] or [DASL].

   Implementer's Note: DASL supports a very extensible response format
   so it would be expected that additional responses of different types
   might be mixed in with the service responses. As such it is
   important to check the servicetype property for each response to
   ensure that it is the service type that was requested.

6.1.2.1.  Example

   M-SEARCH /I/AM HTTP/1.1
   Host: http://the/proxy
   Man: ssdp:discovery
   ST: upnp:blender

   HTTP/1.1 207 Multi-Status
   Content-Type: text/xml
   Content-Length: xxx

   <?xml version="1.0"?>
   <D:multistatus xmlns:D="DAV:" xmlns:S="ssdp:">
      <D:response>
         <D:href>uuid:kj9d4fae-7dec-11d0-a765-00a0c91e6bf6</D:href>
         <D:propstat>
            <D:prop>
               <S:location><D:href>http://foo/bar</D:href></S:location>
               <S:servicetype>
                  <D:href>upnp:blender</D:href>
               </S:servicetype>
            </D:prop>
         </D:propstat>
      </D:response>
      <D:response>
         <D:href>uuid:abcdefgh-7dec-11d0-a765-00a0c91e6bf6</D:href>
         <D:propstat>
            <D:prop>
               <S:location>
                  <D:href>blender:ixl</D:href>
                  <D:href>http://foo/bar</D:href>
               </S:location>
               <S:servicetype>
                  <D:href>ge:fridge</D:href>
               </S:servicetype>


Goland et al.                                                [Page 14]


INTERNET-DRAFT                 SSDP/V2                  June 21, 1999


            </D:prop>
         </D:propstat>
      </D:response>
   </D:multistatus>

6.2. ssdp:notproxyaware SEARCH Extension

   The ssdp:notproxyaware SEARCH acts in the same manner as
   ssdp:discover except that the ST header is not submitted and only
   non-proxy aware SSDP services match the query.

6.3. ssdp:proxyawareservices SEARCH Extension

   [Ed. Note: This was originally introduced for use with the proxy
   free shut off algorithm which has since been taken out of the spec
   and moved to the appendix. Its use is still mandated as I suspect it
   is still useful. If this suspicion turns out to be erroneous then it
   will be removed.]

   The ssdp:proxyawareservices SEARCH acts in the same manner as
   ssdp:discover except that the ST header is not submitted and only
   proxy aware SSDP services match the query.

7.   GENA Notification Subtypes

7.1.1.    ssdp:alive

   ssdp:alive notification subtype MUST NOT be used for notifications
   from non-SSDP compliant services.

   The NT header of a ssdp:alive NOTIFY method MUST be set to the
   service type of the SSDP compliant service sending the request.

   ssdp:alive notifications MUST include a USN header set to the value
   of the service's USN.

   ssdp:alive notifications SHOULD contain a Location and/or AL header.
   If there is no DNS support available on the local network then at
   least one location SHOULD be provided using an IP address for the
   host.

   ssdp:alive notifications SHOULD contain a cache-control: max-age
   directive. Please refer to section .4.2 for details on caching
   ssdp:alive notifications based on cache directives.

   ssdp:alive notifications sent by ssdp:proxy services MUST include
   the PN header.







Goland et al.                                                [Page 15]


INTERNET-DRAFT                 SSDP/V2                  June 21, 1999


7.1.1.1.  Example

   NOTIFY * HTTP/1.1
   Host: reservedSSDPmulticastaddress
   NT: blenderassociation:blender
   NTS: ssdp:alive
   USN: someunique:idscheme3
   AL: <blender:ixl><http://foo/bar>
   Cache-Control: max-age = 7393

   This is a notification sent to the reserved SSDP multicast channel
   announcing that a service of service type blenderassociation:blender
   is alive and available for use at the locations blender:ixl and
   http://foo/bar. Because the NOTIFY request was sent using httpmu
   there is no response.

7.1.2.    ssdp:byebye

   ssdp:byebye notifications allow arbitrary services to inform clients
   that the service is about to go off-line. Clients and SSDP Proxies
   SHOULD remove the service's entry from their cache upon receiving a
   ssdp:byebye notification.

   ssdp:byebye notifications MUST set the NT header to their service
   type and MUST include a USN header.

7.1.2.1.  Example

   NOTIFY /proxy/location HTTP/1.1
   Host: ssdpproxy
   NT: blenderassociation:blender
   NTS: ssdp:byebye
   USN: someunique:idscheme3

   HTTP/1.1 200 O.K.

   In this case the blender is SSDP proxy aware and has switched over
   to using a SSDP proxy. Because the message was sent using http there
   is a response.

8.   SSDP properties

   The following properties are returned in SSDP enhance SEARCH
   responses sent across http.

8.1. servicetype Property

   Name: servicetype
   Namespace: SSDP:
   Purpose: Specifies the service type of the associated service.

   <!ELEMENT servicetype href>


Goland et al.                                                [Page 16]


INTERNET-DRAFT                 SSDP/V2                  June 21, 1999



   The HREF XML element is defined in [WEBDAV].

8.2. location Property

   Name: location
   Namespace: SSDP:
   Purpose: Specifies the location(s) at which the service can be
   contacted.

   <!ELEMENT location (href)*>

9.   HTTP Headers

9.1. USN Header

   USN = "USN" ":" AbsoluteURI; defined in section 3.2.1 of [RFC2068]

   Contains a USN.

9.2. ST Header

   ST = "ST" ":" AbsoluteURI

   Contains a service type.

9.3. PN Header

   PN = "PN" ":" ("1" | "0." 1*digit)

   Contains a proxy number.

10.  SSDP Reserved Multicast Channel

   The SSDP reserved multicast channel will be a locally scoped
   multicast address as defined in [RFC2365]. The actual address will
   be issued by IANA.

11.  Security Considerations

   TBD.

12.  IANA Considerations

   To ensure correct interoperation based on this specification, IANA
   must reserve the URI namespace starting with "ssdp:" for use by this
   specification, its revisions, and related SSDP specifications.







Goland et al.                                                [Page 17]


INTERNET-DRAFT                 SSDP/V2                  June 21, 1999


13.  Appendix - Constants

   MAXPROX - Maximum number of SSDP proxy aware services allowed on a
   proxy free network before SSDP services must be disabled.

   PROXYWAIT - Number of seconds to wait before assuming one has won a
   challenge.

14.  Appendix - Proxy Free Shut Off

   [Ed. Note: This is a really wacky algorithm that doesn't even work
   all that well that was introduced to deal with concerns about
   overload from SSDP proxy aware services on large networks with no
   SSDP proxy support. I have removed it from the spec until we have a
   better idea of the need for this algorithm. To make it really work
   we would have to change it to have one of the services be elected as
   a "shut off leader" who would then answer search requests for the
   number of services on the network. This is just ugly. Let's hope we
   don't need it.]

   In certain circumstances a large number of SSDP proxy aware services
   may be present on a network. However the network itself was never
   meant to run SSDP.

   For example, an administrator may purchase a large number of
   printers that support many different access mechanisms including
   SSDP. The administrator never intended for the printers to use SSDP
   and certainly doesn't want to be bothered with have to explicitly
   configure them to not use SSDP.

   In such a case the desired behavior is for the SSDP proxy aware
   services to de-active their SSDP support rather than flood the
   network with large numbers of notifications.

   The issue is of less relevance to non-SSDP proxy aware services as
   these services are required to produce very few notifications and so
   do not pose much of a threat to the network.

   In order to detect when this situation has come to pass SSDP proxy
   aware services that perform proxy discovery but fail to find a proxy
   MUST perform a SEARCH for resources of type ssdp:proxyawareservice.
   If the speed of the network divided by the number of responses
   exceeds MAXPROX then the service MUST enter the wait state. In the
   wait state the service MUST disable all SSDP functionality except
   listening for a ssdp:alive notification from a SSDP proxy and
   answering ssdp:proxyawareservice SEARCH requests sent across the
   SSDP reserved multicast channel.

   If there is a SSDP proxy but it subsequently dies without
   replacement then services SHOULD wait for the amount of time
   specified in the cache-control: max-age directive before assuming



Goland et al.                                                [Page 18]


INTERNET-DRAFT                 SSDP/V2                  June 21, 1999


   that no proxy is coming back and executing the proxy free shut off
   algorithm from the beginning.

   [Ed. Note: There is a built in assumption here that non-proxy aware
   services will have such a low rate of NOTIFY activity that it would
   be almost impossible to put enough of them on a single local
   multicast loop to cause a traffic overload. Such assumptions are
   what administrative nightmares are made of so we may want to also
   put in detection of non-proxy aware services and assign them an even
   higher threshold, but a threshold none the less, to determine cut
   off. The other possibility is to have a bandwidth based cut off, but
   this requires knowing what the bandwidth of the underlying link is.]

15.  Acknowledgements

   This document is the result of enormous effort by a large number of
   people including but not limited to: Munil Shah, Holly Knight, Peter
   Ford, Mike Zintel, Pradeep Bahl, Paul Moore, Babak Jahromi, Brandon
   Watson, Michel Guittet, Todd Fisher, and Craig White.

16.  References

   [GENA] J. Cohen, S. Aggarwal, Y. Y. Goland. General Event
   Notification Architecture Base: Client to Arbiter. Internet Draft -
   a work in progress, draft-cohen-gena-client-00.txt.

   [MAN] H. Nielsen, P. Leach, S. Lawrence. Mandatory Extensions in
   HTTP. Internet Draft - a work in progress, draft-frystyk-http-
   mandatory-00.txt.

   [HTTPUDP] Y. Y. Goland. Multicast and Unicast UDP HTTP Requests.
   Internet Draft - a work in progress, draft-goland-http-udp-00.txt.

   [RFC2365] D. Meyer.  Administratively Scoped IP Multicast.  RFC
   2365, July 1998.

   [RFC2396] T. Berners-Lee, R. Fielding and L. Masinter.  Uniform
   Resource Identifiers (URI): Generic Syntax.  RFC 2396, August 1998.

   [RFC2119] S. Bradner. Key words for use in RFCs to Indicate
   Requirement Levels.  RFC 2119, March 1997.

   [RFC2068] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, and T.
   Berners-Lee. Hypertext Transfer Protocol -- HTTP/1.1.  RFC 2068,
   January 1997.

   [RFC2518] Y. Goland, E. Whitehead, A. Faizi, S. Carter, and D.
   Jensen. HTTP Extensions for Distributed Authoring รป WEBDAV. RFC
   2518, February 1999.



Goland et al.                                                [Page 19]


INTERNET-DRAFT                 SSDP/V2                  June 21, 1999


17.  Author's Addresses

      Yaron Y. Goland, Ting Cai, Paul Leach, Ye Gu
      Microsoft Corporation
      One Microsoft Way
      Redmond, WA 98052

      Email: {yarong, tingcai, paulle}@microsoft.com

      Shivaun Albright
      Hewlett-Packard Company
      Roseville, CA

      Email: SHIVAUN_ALBRIGHT@HP-Roseville-om2.om.hp.com

      This document will expire in December 1999.






































Goland et al.                                                [Page 20]


Html markup produced by rfcmarkup 1.126, available from https://tools.ietf.org/tools/rfcmarkup/