|
- Internet Engineering Task Force Yaron Y. Goland
- INTERNET DRAFT Ting Cai
- Paul Leach
- Ye Gu
- Microsoft Corporation
- Shivaun Albright
- Hewlett-Packard Company
- October 28, 1999
- Expires April 2000
-
-
-
- Simple Service Discovery Protocol/1.0
- Operating without an Arbiter
- <draft-cai-ssdp-v1-03.txt>
-
-
-
- Status of this Memo
-
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC2026.
-
- 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.
-
- Please send comments to the SSDP mailing list. Subscription
- information for the SSDP mailing list is available at
- http://www.upnp.org/resources/ssdpmail.htm.
-
- 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.
-
- Table of Contents
-
- Status of this Memo................................................1
- Abstract...........................................................1
-
-
- Goland et al. [Page 1]
- INTERNET-DRAFT SSDP/V1 October 28, 1999
-
-
- Table of Contents..................................................1
- 1. Changes Since 02.............................................3
- 2. Introduction.................................................3
- 2.1. Problem Statement.........................................3
- 2.2. Proposed Solution.........................................4
- 2.2.1. Message Flow on the SSDP Multicast Channel...........4
- 2.2.2. SSDP Discovery Information Caching Model.............4
- 2.3. Design Rationale..........................................5
- 2.3.1. Message Flow on the SSDP Multicast Channel...........5
- 2.3.2. SSDP Discovery Information Caching Model.............7
- 3. Terminology..................................................8
- 4. SSDP Discovery Requests......................................8
- 4.1. Problem Statement.........................................8
- 4.2. Proposed Solution.........................................8
- 4.3. Design Rationale.........................................10
- 4.3.1. Why is the ST header so limited? Why doesn't it support
- at least and/or/not? Why not name/value pair searching?.....10
- 4.3.2. If we are using the SEARCH method why aren't you using
- the DASL search syntax?.....................................10
- 4.3.3. Why can we only specify one search type in the ST
- header of a ssdp:discover request?..........................10
- 4.3.4. Why do we only provide support for multicast UDP, not
- TCP, ssdp:discover requests?................................10
- 4.3.5. Why do we require that responses without caching
- information not be cached at all?...........................11
- 5. SSDP Presence Announcements.................................11
- 5.1. Problem Statement........................................11
- 5.2. Proposed Solution........................................11
- 5.2.1. ssdp:alive..........................................11
- 5.2.2. ssdp:byebye.........................................12
- 5.3. Design Rationale.........................................13
- 5.3.1. Why are we using GENA NOTIFY requests?..............13
- 5.3.2. Why is there no response to the ssdp:alive/ssdp:byebye
- requests sent to the SSDP multicast channel/port?...........13
- 5.3.3. Could NTS values other than ssdp:alive/ssdp:byebye be
- sent to the SSDP multicast channel/port?....................13
- 5.3.4. Why do we include the NT header on ssdp:byebye
- requests?...................................................13
- 5.3.5. Shouldn't the NT and NTS values be switched?........13
- 6. SSDP Auto-Shut-Off Algorithm................................13
- 6.1. Problem Statement........................................13
- 6.2. Proposed Solution........................................13
- 6.3. Design Rationale.........................................14
- 6.3.1. Why do we need an auto-shut-off algorithm?..........14
- 6.3.2. Why not just require everyone to support directories
- and thus get around the scaling issue?......................15
- 7. ssdp:all....................................................15
- 7.1. Problem Statement........................................15
- 7.2. Proposed Solution........................................15
- 7.3. Design Rationale.........................................16
- 7.3.1. Why would anyone want to enumerate all services?....16
- 8. SSDP Reserved Multicast Channel.............................16
-
-
- Goland et al. [Page 2]
- INTERNET-DRAFT SSDP/V1 October 28, 1999
-
-
- 8.1. Problem Statement........................................16
- 8.2. Proposed Solution........................................16
- 8.3. Design Rationale.........................................16
- 8.3.1. Why didn't SSDP just get a static local administrative
- scope address rather than a relative address?...............16
- 8.3.2. Why does SSDP need to use a port other than 80?.....16
- 9. HTTP Headers................................................17
- 9.1. USN Header...............................................17
- 9.2. ST Header................................................17
- 10. Security Considerations.....................................17
- 11. IANA Considerations.........................................17
- 12. Appendix - Constants........................................17
- 13. Acknowledgements............................................17
- 14. References..................................................17
- 15. Author's Addresses..........................................18
-
- 1. Changes Since 02
-
- The entire specification has been extensively re-written. As such
- the reader is advised to re-read the entire specification rather
- than to just look for particular changes.
-
- Removed the arbiter and related functionality.
-
- Spec used to contain both ssdp:discover and ssdp:discovery, settled
- on ssdp:discover.
-
- Changed SSDP multicast message examples to use the reserved relative
- multicast address "5" provided by IANA. In the local administrative
- scope, the only scope currently used by SSDP, this address
- translates to 239.255.255.250.
-
- An application has been made for a reserved port for SSDP but no
- response from IANA has been received.
-
- 2. Introduction
-
- [Ed. Note: In my experience, one of the best ways to enable a
- specification to be quickly and successfully developed is to provide
- a problem statement, a proposed solution and a design rationale. I
- came across this three-part design structure when Larry Masinter
- proposed it to the WebDAV WG. To that end, I have divided this spec
- in a similar manner. Once the specification is sufficiently mature,
- the problem statement and design rationale sections will be placed
- in a separate document and the proposed solutions will be presented
- for standardization.]
-
- This document assumes the reader is very familiar with [RFC2616],
- [HTTPUDP], [GENA], [MAN] and [RFC2365].
-
- 2.1. Problem Statement
-
-
-
- Goland et al. [Page 3]
- INTERNET-DRAFT SSDP/V1 October 28, 1999
-
-
- A mechanism is needed to allow HTTP clients and HTTP resources to
- discover each other in local area networks. That is, a HTTP client
- may need a particular service that may be provided by one or more
- HTTP resources. The client needs a mechanism to find out which HTTP
- resources provide the service the client desires.
-
- For the purposes of this specification the previously mentioned HTTP
- client will be referred to as a SSDP client. The previous mentioned
- HTTP resource will be referred to as a SSDP service.
-
- In the simplest case this discovery mechanism needs to work without
- any configuration, management or administration. For example, if a
- user sets up a home network or a small company sets up a local area
- network they must not be required to configure SSDP before SSDP can
- be used to help them discover SSDP services in the form of Printers,
- Scanners, Fax Machines, etc.
-
- It is a non-goal for SSDP to provide for multicast scope bridging or
- for advanced query facilities.
-
- 2.2. Proposed Solution
-
- 2.2.1. Message Flow on the SSDP Multicast Channel
-
- The following is an overview of the messages used to implement SSDP.
-
- SSDP clients discover SSDP services using the reserved local
- administrative scope multicast address 239.255.255.250 over the SSDP
- port [NOT YET ALLOCATED BY IANA].
-
- For brevity's sake the SSDP reserved local administrative scope
- multicast address and port will be referred to as the SSDP multicast
- channel/Port.
-
- Discovery occurs when a SSDP client multicasts a HTTP UDP discovery
- request to the SSDP multicast channel/Port. SSDP services listen to
- the SSDP multicast channel/Port in order to hear such discovery
- requests. If a SSDP service hears a HTTP UDP discovery request that
- matches the service it offers then it will respond using a unicast
- HTTP UDP response.
-
- SSDP services may send HTTP UDP notification announcements to the
- SSDP multicast channel/port to announce their presence.
-
- Hence two types of SSDP requests will be sent across the SSDP
- multicast channel/port. The first are discovery requests, a SSDP
- client looking for SSDP services. The second are presence
- announcements, a SSDP service announcing its presence.
-
- 2.2.2. SSDP Discovery Information Caching Model
-
-
-
-
- Goland et al. [Page 4]
- INTERNET-DRAFT SSDP/V1 October 28, 1999
-
-
- The following provides an overview of the data provided in a SSDP
- system.
-
- Services are identified by a unique pairing of a service type URI
- and a Unique Service Name (USN) URI.
-
- Service types identify a type of service, such as a refrigerator,
- clock/radio, what have you. The exact meaning of a service type is
- outside the scope of this specification. For the purposes of this
- specification, a service type is an opaque identifier that
- identifies a particular type of service.
-
- A USN is a URI that uniquely identifies a particular instance of a
- service. USNs are used to differentiate between two services with
- the same service type.
-
- In addition to providing both a service type and a USN, discovery
- results and presence announcements also provide expiration and
- location information.
-
- Location information identifies how one should contact a particular
- service. One or more location URIs may be included in a discovery
- response or a presence announcement.
-
- Expiration information identifies how long a SSDP client should keep
- information about the service in its cache. Once the entry has
- expired it is to be removed from the SSDP client's cache.
-
- Thus a SSDP client service cache might look like:
-
- USN URI | Service Type URI | Expiration | Location
- -----------------|------------------|------------|------------------
- upnp:uuid:k91... | upnp:clockradio | 3 days | http://foo.com/cr
- -----------------|------------------|------------|------------------
- uuid:x7z... | ms:wince | 1 week | http://msce/win
- -----------------|------------------|------------|------------------
-
- In the previous example both USN URIs are actually UUIDs such as
- upnp:uuid:k91d4fae-7dec-11d0-a765-00a0c91c6bf6.
-
- If an announcement or discovery response is received that has a USN
- that matches an entry already in the cache then the information in
- the cache is to be completely replaced with the information in the
- announcement or discovery response.
-
- 2.3. Design Rationale
-
- [Ed. Note: In my own experience one of the most powerful ways to
- explain design rationale is in a question/answer form. Therefore I
- have used that format here.]
-
- 2.3.1. Message Flow on the SSDP Multicast Channel
-
-
- Goland et al. [Page 5]
- INTERNET-DRAFT SSDP/V1 October 28, 1999
-
-
-
- Please see section 8.3 for more design rationale behind our use of
- multicasting.
-
- 2.3.1.1. Why use multicast for communication?
-
- We needed a solution for communication that would work even if there
- was no one around to configure things. The easiest solution would
- have been to build a discovery server, but who would set the server
- up? Who would maintain it? We needed a solution that could work even
- if no one had any idea what discovery was. By using multicasting we
- have the equivalent of a "party channel." Everyone can just grab the
- channel and scream out what they need and everyone else will hear.
- This means no configuration worries. Of course it brings up other
- problems which are addressed throughout this specification.
-
- 2.3.1.2. Why use a local administrative scope multicast address?
-
- Multicasting comes in many scopes, from link local all the way to
- "the entire Internet." Our goal is to provide for discovery for
- local area networks not for the entire Internet. LANs often are
- bridged/routed so a link local multicast scope was too restrictive.
- The next level up was a local administrative scope. The idea being
- that your administrator decides how many machines should be grouped
- together and considered a "unit". This seemed the ideal scope to use
- for a local discovery protocol.
-
- 2.3.1.3. Why does SSDP support both service discovery requests as well
- as service presence announcements?
-
- Some discovery protocols only support discovery requests, that is,
- the client must send out a request in order to find out who is
- around. The downside to such solutions is that they tend to be very
- expensive on the wire. For example, we want to display to our user
- all the VCRs in her house. So we send out a discovery request.
- However our user has just purchased a new VCR and, after starting
- our program, plugged it in. The only way we would find out about the
- new VCR and be able to display it on our user's screen is by
- constantly sending out discovery requests. Now imagine every client
- in the network having to send out a torrent of discovery requests
- for service they care about in order to make sure they don't miss a
- new service coming on-line.
-
- Other systems use the opposite extreme, they only support
- announcements. Therefore, when our user opens the VCR display window
- we would just sit and listen for announcements. In such systems all
- the services have to send out a constant stream of announcements in
- order to make sure that no one misses them. Users aren't the most
- patient people in the world so each service will probably need to
- announce itself at least every few seconds. This constant stream of
- traffic does horrible things to network efficient, especially for
- shared connections like Ethernets.
-
-
- Goland et al. [Page 6]
- INTERNET-DRAFT SSDP/V1 October 28, 1999
-
-
-
- SSDP decided to adopt a hybrid approach and do both discovery and
- announcements. This can be incredibly efficient. When a service
- first comes on-line it will send out an announcement so that
- everyone knows it is there. At that point it shouldn't ever need to
- send out another announcement unless it is going off-line, has
- changed state or its cache entry is about to expire. Any clients who
- come on-line after the service came on-line will discover the
- desired service by sending out a discovery request. The client
- should never need to repeat the discovery request because any
- services that subsequently come on-line will announce themselves.
- The end result is that no one needs to send out steady streams of
- messages. The entire system is event driven, only when things change
- will messages need to be sent out. The cost, however, is that the
- protocol is more complex. We felt this was a price worth paying as
- it meant that SSDP could be used successfully in fairly large
- networks.
-
- 2.3.1.4. Doesn't the caching information turn SSDP back into a
- "announcement driven" protocol?
-
- Discovery protocols that only support announcements generally have
- to require services to send announcements every few seconds.
- Otherwise users screens will take too long to update with
- information about which services are available.
-
- SSDP, on the other hand, allows the service to inform clients how
- long they should assume the service is around. Thus a service can
- set a service interval to seconds, minutes, days, weeks, months or
- even years.
-
- Clients do not have to wait around for cache update messages because
- they can perform discovery.
-
- 2.3.2. SSDP Discovery Information Caching Model
-
- 2.3.2.1. Why do we need USNs, isn't the location good enough?
-
- When a service announces itself it usually includes a location
- identifying where it may be found. However that location can and
- will change over time. For example, a user may decide to change the
- DNS name assigned to that device. Were we to depend on locations,
- not USNs, when the service's location was changed we would think we
- were seeing a brand new service. This would be very disruptive to
- the user's experience. Imagine, for example, that the user has set
- up a PC program that programs their VCR based on schedules pulled
- off the Internet. If the user decides to change the VCR's name from
- the factory default to something friendly then a location based
- system would loose track of the VCR it is supposed to be programming
- because the name has changed. By using unique Ids instead we are
- able to track the VCR regardless of the name change. So the user can
-
-
-
- Goland et al. [Page 7]
- INTERNET-DRAFT SSDP/V1 October 28, 1999
-
-
- change the VCR's name at will and the VCR programming application
- will still be able to program the correct VCR.
-
- 2.3.2.2. Why are USNs URIs and why are they required to be unique
- across the entire URI namespace for all time?
-
- In general making a name universally unique turns out to usually be
- a very good idea. Mechanisms such as UUIDs allow universally unique
- names to be cheaply created in a decentralized manner. In this case
- making USNs globally unique is very useful because services may be
- constantly moved around, if they are to be successfully tracked they
- need an identifier that isn't going to change and isn't going to get
- confused with any other service.
-
- URIs were chosen because they have become the de facto managed
- namespace for use on the Internet. Anytime someone wants to name
- something it is easy to just use a URI.
-
- 3. Terminology
-
- SSDP Client - A HTTP client that makes use of a service.
-
- SSDP Service - A HTTP resource that provides a service used by SSDP
- clients.
-
-
- Service Type - A URI that identifies the type or function of a
- particular service.
-
- Unique Service Name (USN) - A URI that is guaranteed to be unique
- across the entire URI namespace for all time. It is used to uniquely
- identify a particular service in order to allow services with
- identical service type URIs to 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].
-
- 4. SSDP Discovery Requests
-
- 4.1. Problem Statement
-
- A mechanism is needed for SSDP clients to find desired SSDP
- services.
-
- 4.2. Proposed Solution
-
- The SEARCH method, introduced by [DASL], is extended using the [MAN]
- mechanism to provide for SSDP discovery.
-
- The SSDP SEARCH extension is identified by the URI ssdp:discover.
-
-
- Goland et al. [Page 8]
- INTERNET-DRAFT SSDP/V1 October 28, 1999
-
-
-
- For brevity's sake a HTTP SEARCH method enhanced with the
- ssdp:discover functionality will be referred to as a ssdp:discover
- request.
-
- ssdp:discover requests MUST contain a ST header. ssdp:discover
- requests MAY contain a body but the body MAY be ignored if not
- understood by the HTTP service.
-
- The ST header contains a single URI. SSDP clients may use the ST
- header to specify the service type they want to discover.
-
- This specification only specifies the use of ssdp:discover requests
- over HTTP Multicast UDP although it is expected that future
- specifications will expand the definition to handle ssdp:discover
- requests sent over HTTP TCP.
-
- ssdp:discover requests sent to the SSDP multicast channel/port MUST
- have a request-URI of "*". Note that future specifications may allow
- for other request-URIs to be used so implementations based on this
- specification MUST be ready to ignore ssdp:discover requests on the
- SSDP multicast channel/port with a request-URI other than "*".
-
- Only SSDP services that have a service type that matches the value
- in the ST header MAY respond to a ssdp:discover request on the SSDP
- multicast channel/port.
-
- Responses to ssdp:discover requests sent over the SSDP multicast
- channel/port are to be sent to the IP address/port the ssdp:discover
- request came from.
-
- A response to a ssdp:discover request SHOULD include the service's
- location expressed through the Location and/or AL header. A
- successful response to a ssdp:discover request MUST also include the
- ST and USN headers.
-
- Response to ssdp:discover requests SHOULD contain a cache-control:
- max-age or Expires header. If both are present then they are to be
- processed in the order specified by HTTP/1.1, that is, the cache-
- control header takes precedence of the Expires header. If neither
- the cache-control nor the Expires header is provided on the response
- to a ssdp:discover request then the information contained in that
- response MUST NOT be cached by SSDP clients.
-
- 4.2.1.1. Example
-
- M-SEARCH * HTTP/1.1
- S: uuid:ijklmnop-7dec-11d0-a765-00a0c91e6bf6
- Host: 239.255.255.250:reservedSSDPport
- Man: "ssdp:discover"
- ST: ge:fridge
- MX: 3
-
-
- Goland et al. [Page 9]
- INTERNET-DRAFT SSDP/V1 October 28, 1999
-
-
-
- HTTP/1.1 200 OK
- S: uuid:ijklmnop-7dec-11d0-a765-00a0c91e6bf6
- Ext:
- Cache-Control: no-cache="Ext", max-age = 5000
- ST: ge:fridge
- USN: uuid:abcdefgh-7dec-11d0-a765-00a0c91e6bf6
- AL: <blender:ixl><http://foo/bar>
-
- 4.3. Design Rationale
-
- 4.3.1. Why is the ST header so limited? Why doesn't it support at
- least and/or/not? Why not name/value pair searching?
-
- Deciding the "appropriate" level of search capability is a hopeless
- task. So we decided to pare things back to the absolute minimum, a
- single opaque token, and see what happens. The result so far has
- been a very nice, simple, easy to implement, easy to use discovery
- system. There are lots of great features it doesn't provide but most
- of them, such as advanced queries and scoping, require a search
- engine and a directory. This level of capability is beyond many
- simple devices, exactly the sort of folks we are targeting with
- SSDP. Besides, search functionality seems to be an all or nothing
- type of situation. Either you need a brain dead simple search
- mechanism or you need a full fledged near SQL class search system.
- Instead of making SSDP the worst of both worlds we decided to just
- focus on the dirt simple search problem and leave the more advanced
- stuff to the directory folk.
-
- 4.3.2. If we are using the SEARCH method why aren't you using the
- DASL search syntax?
-
- We couldn't come up with a good reason to force our toaster ovens to
- learn XML. The features the full-fledged DASL search syntax provides
- are truly awesome and thus way beyond our simple scenarios. We fully
- expect that DASL will be the preferred solution for advanced search
- scenarios, but that isn't what this draft is about.
-
- 4.3.3. Why can we only specify one search type in the ST header of a
- ssdp:discover request?
-
- We wanted to start as simple as possible and be forced, kicking and
- screaming, into adding additional complexity. The simplest solution
- was to only allow a single value in the ST header. We were also
- concerned that if we allowed multiple values into the ST headers
- somebody would try to throw in and/or/not functionality. Given the
- minimal byte savings of allowing multiple values into the ST header
- it seems better to just leave the protocol simpler.
-
- 4.3.4. Why do we only provide support for multicast UDP, not TCP,
- ssdp:discover requests?
-
-
-
- Goland et al. [Page 10]
- INTERNET-DRAFT SSDP/V1 October 28, 1999
-
-
- We only define what we need to make the discovery protocol work and
- we don't need TCP to make the discovery protocol work. Besides to
- make TCP discovery really work you need to be able to handle
- compound responses which means you need a compound response format
- which is probably XML and that is more than we wanted to handle.
- Eventually we expect that you will be able to go up to the SSDP port
- on a server using a HTTP TCP request and discover what service, if
- any, lives there. But that will be described in a future
- specification.
-
- 4.3.5. Why do we require that responses without caching information
- not be cached at all?
-
- Because that was a lot easier thing to do then trying to explain the
- various heuristics one could use to deal with services who don't
- provide caching information.
-
- 5. SSDP Presence Announcements
-
- 5.1. Problem Statement
-
- A mechanism is needed for SSDP services to be able to let interested
- SSDP clients know of their presence.
-
- A mechanism is needed to allow SSDP services to update expiration
- information in cache entries regarding them.
-
- A mechanism is needed to allow SSDP services to notify interested
- SSDP clients when their location changes.
-
- A mechanism is needed to allow SSDP services to inform interested
- SSDP clients that they are going to de-activate themselves.
-
- 5.2. Proposed Solution
-
- 5.2.1. ssdp:alive
-
- SSDP services may declare their presence on the network by sending a
- [GENA] NOTIFY method using the NTS value ssdp:alive to the SSDP
- multicast channel/port.
-
- For brevity's sake HTTP NOTIFY methods with the NTS value ssdp:alive
- will be referred to as ssdp:alive requests.
-
- When a ssdp:alive request is received whose USN matches the USN of
- an entry already in the SSDP client's cache then all information
- regarding that USN is to be replaced with the information on the
- ssdp:alive request. Hence ssdp:alive requests can be used to update
- location information and prevent cache entries from expiring.
-
-
-
-
-
- Goland et al. [Page 11]
- INTERNET-DRAFT SSDP/V1 October 28, 1999
-
-
- The value of NT on a ssdp:alive request MUST be set to the service's
- service type. ssdp:alive requests MUST contain a USN header set to
- the SSDP service's USN.
-
- ssdp:alive requests 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 of the SSDP
- service.
-
- ssdp:alive requests SHOULD contain a cache-control: max-age or
- Expires header. If both are present then they are to be processed in
- the order specified by HTTP/1.1, that is, the cache-control header
- takes precedence of the Expires header. If neither the cache-control
- nor the Expires header is provided the information in the ssdp:alive
- request MUST NOT be cached by SSDP clients.
-
- There is no response to a ssdp:alive sent to the SSDP multicast
- channel/port.
-
- 5.2.1.1. Example
-
- NOTIFY * HTTP/1.1
- Host: 239.255.255.250:reservedSSDPport
- NT: blenderassociation:blender
- NTS: ssdp:alive
- USN: someunique:idscheme3
- AL: <blender:ixl><http://foo/bar>
- Cache-Control: max-age = 7393
-
- 5.2.2. ssdp:byebye
-
- SSDP services may declare their intention to cease operating by
- sending a [GENA] NOTIFY method using the NTS value ssdp:byebye to
- the SSDP multicast channel/port.
-
- For brevity's sake HTTP NOTIFY methods with the NTS value
- ssdp:byebye will be referred to as ssdp:byebye requests.
-
- The value of NT on a ssdp:byebye request MUST be set to the
- service's service type. ssdp:byebye requests MUST contain a USN
- header set to the SSDP service's USN.
-
- There is no response to a ssdp:byebye sent to the SSDP multicast
- channel/port.
-
- When a ssdp:byebye request is received all cached information
- regarding that USN SHOULD be removed.
-
- 5.2.2.1. Example
-
- NOTIFY * HTTP/1.1
- Host: 239.255.255.250:reservedSSDPport
-
-
- Goland et al. [Page 12]
- INTERNET-DRAFT SSDP/V1 October 28, 1999
-
-
- NT: someunique:idscheme3
- NTS: ssdp:byebye
- USN: someunique:idscheme3
-
- 5.3. Design Rationale
-
- 5.3.1. Why are we using GENA NOTIFY requests?
-
- We needed to use some notification format and GENA seemed as good as
- any. Moving forward, GENA gives us a framework to do notification
- subscriptions which will be necessary if SSDP services are to be
- able to provide status updates across the wilds of the Internet
- without depending on the largely non-existent Internet multicast
- infrastructure.
-
-
- 5.3.2. Why is there no response to the ssdp:alive/ssdp:byebye
- requests sent to the SSDP multicast channel/port?
-
- What response would be sent? There isn't much of a point of having
- the SSDP clients send response saying "we received your
- notification" since there may be a lot of them.
-
- 5.3.3. Could NTS values other than ssdp:alive/ssdp:byebye be sent to
- the SSDP multicast channel/port?
-
- Yes.
-
- 5.3.4. Why do we include the NT header on ssdp:byebye requests?
-
- Technically it isn't necessary since the only useful information is
- the USN. But we want to stick with the GENA format that requires a
- NT header. In truth the requirement of including the NT header is a
- consequence of the next issue.
-
- 5.3.5. Shouldn't the NT and NTS values be switched?
-
- Yes, they should. Commands such as ssdp:alive and ssdp:byebye should
- be NT values and the service type, where necessary, should be the
- NTS. The current mix-up is a consequence of a previous design where
- the NT header was used in a manner much like we use the USN today.
- This really needs to change.
-
- 6. SSDP Auto-Shut-Off Algorithm
-
- 6.1. Problem Statement
-
- A mechanism is needed to ensure that SSDP does not cause such a high
- level of traffic that it overwhelms the network it is running on.
-
- 6.2. Proposed Solution
-
-
-
- Goland et al. [Page 13]
- INTERNET-DRAFT SSDP/V1 October 28, 1999
-
-
- [Ed. Note: We have a proposed solution but it is still a bit rough,
- so we will be publishing to the SSDP mailing list for further
- discussion before including it in the draft.]
-
- 6.3. Design Rationale
-
- 6.3.1. Why do we need an auto-shut-off algorithm?
-
- The general algorithm for figuring out how much bandwidth SSDP uses
- over a fixed period of time based on the number of ssdp:discover
- requests is :
-
- DR = Total number of SSDP clients making ssdp:discover requests over
- the time period in question.
- RS = Total number of services that will respond to the ssdp:discover
- requests over the time period in question.
- AM = Average size of the ssdp:discover requests/responses.
- TP = Time period in question.
-
- ((DR*3 + DR*9*RS)*AM)/TP
-
- The 3 is the number of times the ssdp:discover request will be
- repeated.
- The 9 is the number of times the unicast responses to the
- ssdp:discover requests will be sent out assuming the worst case in
- which all 3 original requests are received.
-
- So let's look at a real world worst-case scenario. Some companies,
- in order to enable multicast based services such as voice or video
- streaming to be easily configured set their local administrative
- multicast scope to encompass their entire company. This means one
- gets networks with 100,000 machines in a single administrative
- multicast scope. Now imagine that there is a power outage and all
- the machines are coming back up at the same time. Further imagine
- that they all want to refresh their printer location caches so they
- all send out ssdp:discover requests. Let us finally imagine that
- there are roughly 5000 printers in this network. To simplify the
- math we will assume that the ssdp:discover requests are evenly
- distributed over the 30 seconds.
-
- DR = 100,000 requesting clients
- RS = 5000 services
- AM = 512 bytes
- TP = 30 seconds
-
- ((100000*3+100000*9*5000)*512)/30 = 76805120000 bytes/s =
- 585976.5625 Megabits per second
-
- This is what one would call an awful number.
-
-
-
-
-
- Goland et al. [Page 14]
- INTERNET-DRAFT SSDP/V1 October 28, 1999
-
-
- In a more reasonably sized network SSDP is able to handle this worst
- case scenario much better. For example, let's look at a network with
- 1000 clients and 50 printers.
-
- DR = 1000 requesting clients
- RS = 50 services
- AM = 512 bytes
- TP = 30 seconds
-
- ((1000*3+1000*9*50)*512)/30 = 7731200 bytes/s = 59 Mbps
-
- Now this looks like an awful amount but remember that that this is
- the total data rate needed for 30 seconds. This means that the total
- amount of information SSDP needs to send out to survive a reboot is
- 59*30 = 1770 Mb. Therefore a 10 Mbps network, assuming an effective
- data rate 5 Mbps under constant load that means it will take 1770/5
- = 354 seconds = 6 minutes for the network to settle down.
-
- That isn't bad considering that this is an absolute worst case in a
- network with 1000 clients and 50 services all of whom want to talk
- to each other at the exact same instant.
-
- In either case, there are obvious worst-case scenarios and we need
- to avoid network storms, therefore we need a way for SSDP to de-
- activate before it causes a network storms.
-
- 6.3.2. Why not just require everyone to support directories and thus
- get around the scaling issue?
-
- Many manufacturers stick every protocol they can think of in their
- clients and services. So if your network administrator happened to
- buy some clients and servers that supported SSDP but didn't know
- they supported SSDP then you can imagine the problems. Therefore
- even if we required directory support there are still many cases
- where SSDP clients and services may inadvertently end up in a
- network without anyone knowing it and cause problems.
-
- 7. ssdp:all
-
- 7.1. Problem Statement
-
- A mechanism is needed to enable a client to enumerate all the
- services available on a particular SSDP multicast channel/port.
-
- 7.2. Proposed Solution
-
- All SSDP services MUST respond to SEARCH requests over the SSDP
- multicast channel/port with the ST value of ssdp:all by responding
- as if the ST value had been their service type.
-
- For brevity's sake a SEARCH request with a ST of ssdp:all will be
- referred to as a ssdp:all request.
-
-
- Goland et al. [Page 15]
- INTERNET-DRAFT SSDP/V1 October 28, 1999
-
-
-
- 7.3. Design Rationale
-
- 7.3.1. Why would anyone want to enumerate all services?
-
- This feature is mostly for network analysis tools. It also will
- prove very useful in the feature when directories become SSDP aware.
- They will be able to discover all services, record information about
- them and make that information available outside the local
- administrative multicast scope.
-
- 8. SSDP Reserved Multicast Channel
-
- 8.1. Problem Statement
-
- SSDP needs a local administrative multicast channel that will be
- guaranteed to only be used by SSDP compliant clients and services.
-
- 8.2. Proposed Solution
-
- IANA has reserved the relative multicast address "5" for the
- exclusive use of SSDP. In the local administrative scope used by
- this version of SSDP the relative address translates to
- 239.255.255.250.
-
- An application has been put in for a SSDP reserved port but IANA has
- not yet responded.
-
- 8.3. Design Rationale
-
- 8.3.1. Why didn't SSDP just get a static local administrative scope
- address rather than a relative address?
-
- We got a relative address because we expect that SSDP may be used to
- discover basic system services such as directories. In that case if
- you can't find a directory in your local scope you may want to try a
- wider multicast scope. This is exactly the sort of functionality
- enabled by MALLOC (http://www.ietf.org/html.charters/malloc-
- charter.html). MALLOC allows one to enumerate all the multicast
- scopes that are supported on the network. The SSDP client can then
- try progressively larger scopes to find the service they are seeing.
- However this progressively wider discovery only works if SSDP uses a
- relative address.
-
- 8.3.2. Why does SSDP need to use a port other than 80?
-
- There is a bug in the Berkley Sockets design that was inherited by
- WinSock as well. The bug is as follows: One can not grab a
- particular port on a particular multicast address without owning the
- same port on the local unicast address.
-
-
-
-
- Goland et al. [Page 16]
- INTERNET-DRAFT SSDP/V1 October 28, 1999
-
-
- The result is that if we used port 80 on the SSDP multicast scope
- then we would require that the SSDP software also grab port 80 for
- the local machine. This would mean that SSDP could only be
- implemented on machines which either didn't have HTTP servers or
- whose HTTP servers had been enhanced to support SSDP.
-
- We felt this was a unnecessary restriction. Therefore we are
- choosing to use a port other than 80 on the SSDP multicast channel.
-
- 9. HTTP Headers
-
- 9.1. USN Header
-
- USN = "USN" ":" AbsoluteURI; defined in section 3.2.1 of [RFC2616]
-
- 9.2. ST Header
-
- ST = "ST" ":" AbsoluteURI
-
- 10. Security Considerations
-
- TBD.
-
- 11. 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.
-
- IANA has reserved the relative multicast address "5" for exclusive
- use by SSDP. An application has been made for a registered port.
-
- 12. Appendix - Constants
-
- MAX_UNIQUE - 50 - Maximum number of unique IP address/port pairs
- that may be sent over UDP before tripping the auto-shut-off
- algorithm.
-
- MAX_COUNT - 30 seconds - When the "go quiet" process is begun a
- message is sent out that is delayed a random interval between 0 to
- MAX_COUNT seconds.
-
- 13. Acknowledgements
-
- This document is the result of enormous effort by a large number of
- people including but not limited to:
- Alan Boshier, Babak Jahromi, Brandon Watson, Craig White, Dave
- Thaler, Holly Knight, Michel Guittet, Mike Zintel, Munil Shah, Paul
- Moore, Peter Ford, Pradeep Bahl, and Todd Fisher.
-
- 14. References
-
-
-
- Goland et al. [Page 17]
- INTERNET-DRAFT SSDP/V1 October 28, 1999
-
-
- [HTTPUDP] Y. Y. Goland. Multicast and Unicast UDP HTTP Requests.
- Internet Draft - a work in progress, draft-goland-http-udp-00.txt.
-
- [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-
- extensions-03.txt.
-
- [RFC2119] S. Bradner. Key words for use in RFCs to Indicate
- Requirement Levels. RFC 2119, March 1997.
-
- [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.
-
- [RFC2518] Y. Goland, E. Whitehead, A. Faizi, S. Carter, and D.
- Jensen. HTTP Extensions for Distributed Authoring – WEBDAV. RFC
- 2518, February 1999.
-
- [RFC2616] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, L.
- Masinter, P. Leach and T. Berners-Lee. Hypertext Transfer Protocol -
- HTTP/1.1. RFC 2616, November 1998.
-
- [DASL] S. Reddy, D. Lowry, S. Reddy, R. Henderson, J. Davis, A.
- Babich. DAV Searching & Locating. a work in progress - draft-ietf-
- dasl-protocol-00.txt.
-
- 15. Author's Addresses
-
- Yaron Y. Goland, Ting Cai, Paul Leach, Ye Gu
- Microsoft Corporation
- One Microsoft Way
- Redmond, WA 98052
-
- Email: {yarong, tingcai, paulle, yegu}@microsoft.com
-
- Shivaun Albright
- Hewlett-Packard Company
- Roseville, CA
-
- Email: SHIVAUN_ALBRIGHT@HP-Roseville-om2.om.hp.com
-
- This document will expire in April 2000.
-
-
-
-
-
- Goland et al. [Page 18]
-
|