A Python UPnP Media Server
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

1045 lines
45 KiB

  1. Internet Engineering Task Force Yaron Y. Goland
  2. INTERNET DRAFT Ting Cai
  3. Paul Leach
  4. Ye Gu
  5. Microsoft Corporation
  6. Shivaun Albright
  7. Hewlett-Packard Company
  8. October 28, 1999
  9. Expires April 2000
  10. Simple Service Discovery Protocol/1.0
  11. Operating without an Arbiter
  12. <draft-cai-ssdp-v1-03.txt>
  13. Status of this Memo
  14. This document is an Internet-Draft and is in full conformance with
  15. all provisions of Section 10 of RFC2026.
  16. Internet-Drafts are working documents of the Internet Engineering
  17. Task Force (IETF), its areas, and its working groups. Note that
  18. other groups may also distribute working documents as Internet-
  19. Drafts.
  20. Internet-Drafts are draft documents valid for a maximum of six
  21. months and may be updated, replaced, or obsoleted by other documents
  22. at any time. It is inappropriate to use Internet- Drafts as
  23. reference material or to cite them other than as "work in progress."
  24. The list of current Internet-Drafts can be accessed at
  25. http://www.ietf.org/ietf/1id-abstracts.txt
  26. The list of Internet-Draft Shadow Directories can be accessed at
  27. http://www.ietf.org/shadow.html.
  28. Please send comments to the SSDP mailing list. Subscription
  29. information for the SSDP mailing list is available at
  30. http://www.upnp.org/resources/ssdpmail.htm.
  31. Abstract
  32. The Simple Service Discovery Protocol (SSDP) provides a mechanism
  33. where by network clients, with little or no static configuration,
  34. can discover network services. SSDP accomplishes this by providing
  35. for multicast discovery support as well as server based notification
  36. and discovery routing.
  37. Table of Contents
  38. Status of this Memo................................................1
  39. Abstract...........................................................1
  40. Goland et al. [Page 1]
  41. INTERNET-DRAFT SSDP/V1 October 28, 1999
  42. Table of Contents..................................................1
  43. 1. Changes Since 02.............................................3
  44. 2. Introduction.................................................3
  45. 2.1. Problem Statement.........................................3
  46. 2.2. Proposed Solution.........................................4
  47. 2.2.1. Message Flow on the SSDP Multicast Channel...........4
  48. 2.2.2. SSDP Discovery Information Caching Model.............4
  49. 2.3. Design Rationale..........................................5
  50. 2.3.1. Message Flow on the SSDP Multicast Channel...........5
  51. 2.3.2. SSDP Discovery Information Caching Model.............7
  52. 3. Terminology..................................................8
  53. 4. SSDP Discovery Requests......................................8
  54. 4.1. Problem Statement.........................................8
  55. 4.2. Proposed Solution.........................................8
  56. 4.3. Design Rationale.........................................10
  57. 4.3.1. Why is the ST header so limited? Why doesn't it support
  58. at least and/or/not? Why not name/value pair searching?.....10
  59. 4.3.2. If we are using the SEARCH method why aren't you using
  60. the DASL search syntax?.....................................10
  61. 4.3.3. Why can we only specify one search type in the ST
  62. header of a ssdp:discover request?..........................10
  63. 4.3.4. Why do we only provide support for multicast UDP, not
  64. TCP, ssdp:discover requests?................................10
  65. 4.3.5. Why do we require that responses without caching
  66. information not be cached at all?...........................11
  67. 5. SSDP Presence Announcements.................................11
  68. 5.1. Problem Statement........................................11
  69. 5.2. Proposed Solution........................................11
  70. 5.2.1. ssdp:alive..........................................11
  71. 5.2.2. ssdp:byebye.........................................12
  72. 5.3. Design Rationale.........................................13
  73. 5.3.1. Why are we using GENA NOTIFY requests?..............13
  74. 5.3.2. Why is there no response to the ssdp:alive/ssdp:byebye
  75. requests sent to the SSDP multicast channel/port?...........13
  76. 5.3.3. Could NTS values other than ssdp:alive/ssdp:byebye be
  77. sent to the SSDP multicast channel/port?....................13
  78. 5.3.4. Why do we include the NT header on ssdp:byebye
  79. requests?...................................................13
  80. 5.3.5. Shouldn't the NT and NTS values be switched?........13
  81. 6. SSDP Auto-Shut-Off Algorithm................................13
  82. 6.1. Problem Statement........................................13
  83. 6.2. Proposed Solution........................................13
  84. 6.3. Design Rationale.........................................14
  85. 6.3.1. Why do we need an auto-shut-off algorithm?..........14
  86. 6.3.2. Why not just require everyone to support directories
  87. and thus get around the scaling issue?......................15
  88. 7. ssdp:all....................................................15
  89. 7.1. Problem Statement........................................15
  90. 7.2. Proposed Solution........................................15
  91. 7.3. Design Rationale.........................................16
  92. 7.3.1. Why would anyone want to enumerate all services?....16
  93. 8. SSDP Reserved Multicast Channel.............................16
  94. Goland et al. [Page 2]
  95. INTERNET-DRAFT SSDP/V1 October 28, 1999
  96. 8.1. Problem Statement........................................16
  97. 8.2. Proposed Solution........................................16
  98. 8.3. Design Rationale.........................................16
  99. 8.3.1. Why didn't SSDP just get a static local administrative
  100. scope address rather than a relative address?...............16
  101. 8.3.2. Why does SSDP need to use a port other than 80?.....16
  102. 9. HTTP Headers................................................17
  103. 9.1. USN Header...............................................17
  104. 9.2. ST Header................................................17
  105. 10. Security Considerations.....................................17
  106. 11. IANA Considerations.........................................17
  107. 12. Appendix - Constants........................................17
  108. 13. Acknowledgements............................................17
  109. 14. References..................................................17
  110. 15. Author's Addresses..........................................18
  111. 1. Changes Since 02
  112. The entire specification has been extensively re-written. As such
  113. the reader is advised to re-read the entire specification rather
  114. than to just look for particular changes.
  115. Removed the arbiter and related functionality.
  116. Spec used to contain both ssdp:discover and ssdp:discovery, settled
  117. on ssdp:discover.
  118. Changed SSDP multicast message examples to use the reserved relative
  119. multicast address "5" provided by IANA. In the local administrative
  120. scope, the only scope currently used by SSDP, this address
  121. translates to 239.255.255.250.
  122. An application has been made for a reserved port for SSDP but no
  123. response from IANA has been received.
  124. 2. Introduction
  125. [Ed. Note: In my experience, one of the best ways to enable a
  126. specification to be quickly and successfully developed is to provide
  127. a problem statement, a proposed solution and a design rationale. I
  128. came across this three-part design structure when Larry Masinter
  129. proposed it to the WebDAV WG. To that end, I have divided this spec
  130. in a similar manner. Once the specification is sufficiently mature,
  131. the problem statement and design rationale sections will be placed
  132. in a separate document and the proposed solutions will be presented
  133. for standardization.]
  134. This document assumes the reader is very familiar with [RFC2616],
  135. [HTTPUDP], [GENA], [MAN] and [RFC2365].
  136. 2.1. Problem Statement
  137. Goland et al. [Page 3]
  138. INTERNET-DRAFT SSDP/V1 October 28, 1999
  139. A mechanism is needed to allow HTTP clients and HTTP resources to
  140. discover each other in local area networks. That is, a HTTP client
  141. may need a particular service that may be provided by one or more
  142. HTTP resources. The client needs a mechanism to find out which HTTP
  143. resources provide the service the client desires.
  144. For the purposes of this specification the previously mentioned HTTP
  145. client will be referred to as a SSDP client. The previous mentioned
  146. HTTP resource will be referred to as a SSDP service.
  147. In the simplest case this discovery mechanism needs to work without
  148. any configuration, management or administration. For example, if a
  149. user sets up a home network or a small company sets up a local area
  150. network they must not be required to configure SSDP before SSDP can
  151. be used to help them discover SSDP services in the form of Printers,
  152. Scanners, Fax Machines, etc.
  153. It is a non-goal for SSDP to provide for multicast scope bridging or
  154. for advanced query facilities.
  155. 2.2. Proposed Solution
  156. 2.2.1. Message Flow on the SSDP Multicast Channel
  157. The following is an overview of the messages used to implement SSDP.
  158. SSDP clients discover SSDP services using the reserved local
  159. administrative scope multicast address 239.255.255.250 over the SSDP
  160. port [NOT YET ALLOCATED BY IANA].
  161. For brevity's sake the SSDP reserved local administrative scope
  162. multicast address and port will be referred to as the SSDP multicast
  163. channel/Port.
  164. Discovery occurs when a SSDP client multicasts a HTTP UDP discovery
  165. request to the SSDP multicast channel/Port. SSDP services listen to
  166. the SSDP multicast channel/Port in order to hear such discovery
  167. requests. If a SSDP service hears a HTTP UDP discovery request that
  168. matches the service it offers then it will respond using a unicast
  169. HTTP UDP response.
  170. SSDP services may send HTTP UDP notification announcements to the
  171. SSDP multicast channel/port to announce their presence.
  172. Hence two types of SSDP requests will be sent across the SSDP
  173. multicast channel/port. The first are discovery requests, a SSDP
  174. client looking for SSDP services. The second are presence
  175. announcements, a SSDP service announcing its presence.
  176. 2.2.2. SSDP Discovery Information Caching Model
  177. Goland et al. [Page 4]
  178. INTERNET-DRAFT SSDP/V1 October 28, 1999
  179. The following provides an overview of the data provided in a SSDP
  180. system.
  181. Services are identified by a unique pairing of a service type URI
  182. and a Unique Service Name (USN) URI.
  183. Service types identify a type of service, such as a refrigerator,
  184. clock/radio, what have you. The exact meaning of a service type is
  185. outside the scope of this specification. For the purposes of this
  186. specification, a service type is an opaque identifier that
  187. identifies a particular type of service.
  188. A USN is a URI that uniquely identifies a particular instance of a
  189. service. USNs are used to differentiate between two services with
  190. the same service type.
  191. In addition to providing both a service type and a USN, discovery
  192. results and presence announcements also provide expiration and
  193. location information.
  194. Location information identifies how one should contact a particular
  195. service. One or more location URIs may be included in a discovery
  196. response or a presence announcement.
  197. Expiration information identifies how long a SSDP client should keep
  198. information about the service in its cache. Once the entry has
  199. expired it is to be removed from the SSDP client's cache.
  200. Thus a SSDP client service cache might look like:
  201. USN URI | Service Type URI | Expiration | Location
  202. -----------------|------------------|------------|------------------
  203. upnp:uuid:k91... | upnp:clockradio | 3 days | http://foo.com/cr
  204. -----------------|------------------|------------|------------------
  205. uuid:x7z... | ms:wince | 1 week | http://msce/win
  206. -----------------|------------------|------------|------------------
  207. In the previous example both USN URIs are actually UUIDs such as
  208. upnp:uuid:k91d4fae-7dec-11d0-a765-00a0c91c6bf6.
  209. If an announcement or discovery response is received that has a USN
  210. that matches an entry already in the cache then the information in
  211. the cache is to be completely replaced with the information in the
  212. announcement or discovery response.
  213. 2.3. Design Rationale
  214. [Ed. Note: In my own experience one of the most powerful ways to
  215. explain design rationale is in a question/answer form. Therefore I
  216. have used that format here.]
  217. 2.3.1. Message Flow on the SSDP Multicast Channel
  218. Goland et al. [Page 5]
  219. INTERNET-DRAFT SSDP/V1 October 28, 1999
  220. Please see section 8.3 for more design rationale behind our use of
  221. multicasting.
  222. 2.3.1.1. Why use multicast for communication?
  223. We needed a solution for communication that would work even if there
  224. was no one around to configure things. The easiest solution would
  225. have been to build a discovery server, but who would set the server
  226. up? Who would maintain it? We needed a solution that could work even
  227. if no one had any idea what discovery was. By using multicasting we
  228. have the equivalent of a "party channel." Everyone can just grab the
  229. channel and scream out what they need and everyone else will hear.
  230. This means no configuration worries. Of course it brings up other
  231. problems which are addressed throughout this specification.
  232. 2.3.1.2. Why use a local administrative scope multicast address?
  233. Multicasting comes in many scopes, from link local all the way to
  234. "the entire Internet." Our goal is to provide for discovery for
  235. local area networks not for the entire Internet. LANs often are
  236. bridged/routed so a link local multicast scope was too restrictive.
  237. The next level up was a local administrative scope. The idea being
  238. that your administrator decides how many machines should be grouped
  239. together and considered a "unit". This seemed the ideal scope to use
  240. for a local discovery protocol.
  241. 2.3.1.3. Why does SSDP support both service discovery requests as well
  242. as service presence announcements?
  243. Some discovery protocols only support discovery requests, that is,
  244. the client must send out a request in order to find out who is
  245. around. The downside to such solutions is that they tend to be very
  246. expensive on the wire. For example, we want to display to our user
  247. all the VCRs in her house. So we send out a discovery request.
  248. However our user has just purchased a new VCR and, after starting
  249. our program, plugged it in. The only way we would find out about the
  250. new VCR and be able to display it on our user's screen is by
  251. constantly sending out discovery requests. Now imagine every client
  252. in the network having to send out a torrent of discovery requests
  253. for service they care about in order to make sure they don't miss a
  254. new service coming on-line.
  255. Other systems use the opposite extreme, they only support
  256. announcements. Therefore, when our user opens the VCR display window
  257. we would just sit and listen for announcements. In such systems all
  258. the services have to send out a constant stream of announcements in
  259. order to make sure that no one misses them. Users aren't the most
  260. patient people in the world so each service will probably need to
  261. announce itself at least every few seconds. This constant stream of
  262. traffic does horrible things to network efficient, especially for
  263. shared connections like Ethernets.
  264. Goland et al. [Page 6]
  265. INTERNET-DRAFT SSDP/V1 October 28, 1999
  266. SSDP decided to adopt a hybrid approach and do both discovery and
  267. announcements. This can be incredibly efficient. When a service
  268. first comes on-line it will send out an announcement so that
  269. everyone knows it is there. At that point it shouldn't ever need to
  270. send out another announcement unless it is going off-line, has
  271. changed state or its cache entry is about to expire. Any clients who
  272. come on-line after the service came on-line will discover the
  273. desired service by sending out a discovery request. The client
  274. should never need to repeat the discovery request because any
  275. services that subsequently come on-line will announce themselves.
  276. The end result is that no one needs to send out steady streams of
  277. messages. The entire system is event driven, only when things change
  278. will messages need to be sent out. The cost, however, is that the
  279. protocol is more complex. We felt this was a price worth paying as
  280. it meant that SSDP could be used successfully in fairly large
  281. networks.
  282. 2.3.1.4. Doesn't the caching information turn SSDP back into a
  283. "announcement driven" protocol?
  284. Discovery protocols that only support announcements generally have
  285. to require services to send announcements every few seconds.
  286. Otherwise users screens will take too long to update with
  287. information about which services are available.
  288. SSDP, on the other hand, allows the service to inform clients how
  289. long they should assume the service is around. Thus a service can
  290. set a service interval to seconds, minutes, days, weeks, months or
  291. even years.
  292. Clients do not have to wait around for cache update messages because
  293. they can perform discovery.
  294. 2.3.2. SSDP Discovery Information Caching Model
  295. 2.3.2.1. Why do we need USNs, isn't the location good enough?
  296. When a service announces itself it usually includes a location
  297. identifying where it may be found. However that location can and
  298. will change over time. For example, a user may decide to change the
  299. DNS name assigned to that device. Were we to depend on locations,
  300. not USNs, when the service's location was changed we would think we
  301. were seeing a brand new service. This would be very disruptive to
  302. the user's experience. Imagine, for example, that the user has set
  303. up a PC program that programs their VCR based on schedules pulled
  304. off the Internet. If the user decides to change the VCR's name from
  305. the factory default to something friendly then a location based
  306. system would loose track of the VCR it is supposed to be programming
  307. because the name has changed. By using unique Ids instead we are
  308. able to track the VCR regardless of the name change. So the user can
  309. Goland et al. [Page 7]
  310. INTERNET-DRAFT SSDP/V1 October 28, 1999
  311. change the VCR's name at will and the VCR programming application
  312. will still be able to program the correct VCR.
  313. 2.3.2.2. Why are USNs URIs and why are they required to be unique
  314. across the entire URI namespace for all time?
  315. In general making a name universally unique turns out to usually be
  316. a very good idea. Mechanisms such as UUIDs allow universally unique
  317. names to be cheaply created in a decentralized manner. In this case
  318. making USNs globally unique is very useful because services may be
  319. constantly moved around, if they are to be successfully tracked they
  320. need an identifier that isn't going to change and isn't going to get
  321. confused with any other service.
  322. URIs were chosen because they have become the de facto managed
  323. namespace for use on the Internet. Anytime someone wants to name
  324. something it is easy to just use a URI.
  325. 3. Terminology
  326. SSDP Client - A HTTP client that makes use of a service.
  327. SSDP Service - A HTTP resource that provides a service used by SSDP
  328. clients.
  329. Service Type - A URI that identifies the type or function of a
  330. particular service.
  331. Unique Service Name (USN) - A URI that is guaranteed to be unique
  332. across the entire URI namespace for all time. It is used to uniquely
  333. identify a particular service in order to allow services with
  334. identical service type URIs to to be differentiated.
  335. In addition, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
  336. "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
  337. "OPTIONAL" in this document are to be interpreted as described in
  338. RFC 2119 [RFC2119].
  339. 4. SSDP Discovery Requests
  340. 4.1. Problem Statement
  341. A mechanism is needed for SSDP clients to find desired SSDP
  342. services.
  343. 4.2. Proposed Solution
  344. The SEARCH method, introduced by [DASL], is extended using the [MAN]
  345. mechanism to provide for SSDP discovery.
  346. The SSDP SEARCH extension is identified by the URI ssdp:discover.
  347. Goland et al. [Page 8]
  348. INTERNET-DRAFT SSDP/V1 October 28, 1999
  349. For brevity's sake a HTTP SEARCH method enhanced with the
  350. ssdp:discover functionality will be referred to as a ssdp:discover
  351. request.
  352. ssdp:discover requests MUST contain a ST header. ssdp:discover
  353. requests MAY contain a body but the body MAY be ignored if not
  354. understood by the HTTP service.
  355. The ST header contains a single URI. SSDP clients may use the ST
  356. header to specify the service type they want to discover.
  357. This specification only specifies the use of ssdp:discover requests
  358. over HTTP Multicast UDP although it is expected that future
  359. specifications will expand the definition to handle ssdp:discover
  360. requests sent over HTTP TCP.
  361. ssdp:discover requests sent to the SSDP multicast channel/port MUST
  362. have a request-URI of "*". Note that future specifications may allow
  363. for other request-URIs to be used so implementations based on this
  364. specification MUST be ready to ignore ssdp:discover requests on the
  365. SSDP multicast channel/port with a request-URI other than "*".
  366. Only SSDP services that have a service type that matches the value
  367. in the ST header MAY respond to a ssdp:discover request on the SSDP
  368. multicast channel/port.
  369. Responses to ssdp:discover requests sent over the SSDP multicast
  370. channel/port are to be sent to the IP address/port the ssdp:discover
  371. request came from.
  372. A response to a ssdp:discover request SHOULD include the service's
  373. location expressed through the Location and/or AL header. A
  374. successful response to a ssdp:discover request MUST also include the
  375. ST and USN headers.
  376. Response to ssdp:discover requests SHOULD contain a cache-control:
  377. max-age or Expires header. If both are present then they are to be
  378. processed in the order specified by HTTP/1.1, that is, the cache-
  379. control header takes precedence of the Expires header. If neither
  380. the cache-control nor the Expires header is provided on the response
  381. to a ssdp:discover request then the information contained in that
  382. response MUST NOT be cached by SSDP clients.
  383. 4.2.1.1. Example
  384. M-SEARCH * HTTP/1.1
  385. S: uuid:ijklmnop-7dec-11d0-a765-00a0c91e6bf6
  386. Host: 239.255.255.250:reservedSSDPport
  387. Man: "ssdp:discover"
  388. ST: ge:fridge
  389. MX: 3
  390. Goland et al. [Page 9]
  391. INTERNET-DRAFT SSDP/V1 October 28, 1999
  392. HTTP/1.1 200 OK
  393. S: uuid:ijklmnop-7dec-11d0-a765-00a0c91e6bf6
  394. Ext:
  395. Cache-Control: no-cache="Ext", max-age = 5000
  396. ST: ge:fridge
  397. USN: uuid:abcdefgh-7dec-11d0-a765-00a0c91e6bf6
  398. AL: <blender:ixl><http://foo/bar>
  399. 4.3. Design Rationale
  400. 4.3.1. Why is the ST header so limited? Why doesn't it support at
  401. least and/or/not? Why not name/value pair searching?
  402. Deciding the "appropriate" level of search capability is a hopeless
  403. task. So we decided to pare things back to the absolute minimum, a
  404. single opaque token, and see what happens. The result so far has
  405. been a very nice, simple, easy to implement, easy to use discovery
  406. system. There are lots of great features it doesn't provide but most
  407. of them, such as advanced queries and scoping, require a search
  408. engine and a directory. This level of capability is beyond many
  409. simple devices, exactly the sort of folks we are targeting with
  410. SSDP. Besides, search functionality seems to be an all or nothing
  411. type of situation. Either you need a brain dead simple search
  412. mechanism or you need a full fledged near SQL class search system.
  413. Instead of making SSDP the worst of both worlds we decided to just
  414. focus on the dirt simple search problem and leave the more advanced
  415. stuff to the directory folk.
  416. 4.3.2. If we are using the SEARCH method why aren't you using the
  417. DASL search syntax?
  418. We couldn't come up with a good reason to force our toaster ovens to
  419. learn XML. The features the full-fledged DASL search syntax provides
  420. are truly awesome and thus way beyond our simple scenarios. We fully
  421. expect that DASL will be the preferred solution for advanced search
  422. scenarios, but that isn't what this draft is about.
  423. 4.3.3. Why can we only specify one search type in the ST header of a
  424. ssdp:discover request?
  425. We wanted to start as simple as possible and be forced, kicking and
  426. screaming, into adding additional complexity. The simplest solution
  427. was to only allow a single value in the ST header. We were also
  428. concerned that if we allowed multiple values into the ST headers
  429. somebody would try to throw in and/or/not functionality. Given the
  430. minimal byte savings of allowing multiple values into the ST header
  431. it seems better to just leave the protocol simpler.
  432. 4.3.4. Why do we only provide support for multicast UDP, not TCP,
  433. ssdp:discover requests?
  434. Goland et al. [Page 10]
  435. INTERNET-DRAFT SSDP/V1 October 28, 1999
  436. We only define what we need to make the discovery protocol work and
  437. we don't need TCP to make the discovery protocol work. Besides to
  438. make TCP discovery really work you need to be able to handle
  439. compound responses which means you need a compound response format
  440. which is probably XML and that is more than we wanted to handle.
  441. Eventually we expect that you will be able to go up to the SSDP port
  442. on a server using a HTTP TCP request and discover what service, if
  443. any, lives there. But that will be described in a future
  444. specification.
  445. 4.3.5. Why do we require that responses without caching information
  446. not be cached at all?
  447. Because that was a lot easier thing to do then trying to explain the
  448. various heuristics one could use to deal with services who don't
  449. provide caching information.
  450. 5. SSDP Presence Announcements
  451. 5.1. Problem Statement
  452. A mechanism is needed for SSDP services to be able to let interested
  453. SSDP clients know of their presence.
  454. A mechanism is needed to allow SSDP services to update expiration
  455. information in cache entries regarding them.
  456. A mechanism is needed to allow SSDP services to notify interested
  457. SSDP clients when their location changes.
  458. A mechanism is needed to allow SSDP services to inform interested
  459. SSDP clients that they are going to de-activate themselves.
  460. 5.2. Proposed Solution
  461. 5.2.1. ssdp:alive
  462. SSDP services may declare their presence on the network by sending a
  463. [GENA] NOTIFY method using the NTS value ssdp:alive to the SSDP
  464. multicast channel/port.
  465. For brevity's sake HTTP NOTIFY methods with the NTS value ssdp:alive
  466. will be referred to as ssdp:alive requests.
  467. When a ssdp:alive request is received whose USN matches the USN of
  468. an entry already in the SSDP client's cache then all information
  469. regarding that USN is to be replaced with the information on the
  470. ssdp:alive request. Hence ssdp:alive requests can be used to update
  471. location information and prevent cache entries from expiring.
  472. Goland et al. [Page 11]
  473. INTERNET-DRAFT SSDP/V1 October 28, 1999
  474. The value of NT on a ssdp:alive request MUST be set to the service's
  475. service type. ssdp:alive requests MUST contain a USN header set to
  476. the SSDP service's USN.
  477. ssdp:alive requests SHOULD contain a Location and/or AL header. If
  478. there is no DNS support available on the local network then at least
  479. one location SHOULD be provided using an IP address of the SSDP
  480. service.
  481. ssdp:alive requests SHOULD contain a cache-control: max-age or
  482. Expires header. If both are present then they are to be processed in
  483. the order specified by HTTP/1.1, that is, the cache-control header
  484. takes precedence of the Expires header. If neither the cache-control
  485. nor the Expires header is provided the information in the ssdp:alive
  486. request MUST NOT be cached by SSDP clients.
  487. There is no response to a ssdp:alive sent to the SSDP multicast
  488. channel/port.
  489. 5.2.1.1. Example
  490. NOTIFY * HTTP/1.1
  491. Host: 239.255.255.250:reservedSSDPport
  492. NT: blenderassociation:blender
  493. NTS: ssdp:alive
  494. USN: someunique:idscheme3
  495. AL: <blender:ixl><http://foo/bar>
  496. Cache-Control: max-age = 7393
  497. 5.2.2. ssdp:byebye
  498. SSDP services may declare their intention to cease operating by
  499. sending a [GENA] NOTIFY method using the NTS value ssdp:byebye to
  500. the SSDP multicast channel/port.
  501. For brevity's sake HTTP NOTIFY methods with the NTS value
  502. ssdp:byebye will be referred to as ssdp:byebye requests.
  503. The value of NT on a ssdp:byebye request MUST be set to the
  504. service's service type. ssdp:byebye requests MUST contain a USN
  505. header set to the SSDP service's USN.
  506. There is no response to a ssdp:byebye sent to the SSDP multicast
  507. channel/port.
  508. When a ssdp:byebye request is received all cached information
  509. regarding that USN SHOULD be removed.
  510. 5.2.2.1. Example
  511. NOTIFY * HTTP/1.1
  512. Host: 239.255.255.250:reservedSSDPport
  513. Goland et al. [Page 12]
  514. INTERNET-DRAFT SSDP/V1 October 28, 1999
  515. NT: someunique:idscheme3
  516. NTS: ssdp:byebye
  517. USN: someunique:idscheme3
  518. 5.3. Design Rationale
  519. 5.3.1. Why are we using GENA NOTIFY requests?
  520. We needed to use some notification format and GENA seemed as good as
  521. any. Moving forward, GENA gives us a framework to do notification
  522. subscriptions which will be necessary if SSDP services are to be
  523. able to provide status updates across the wilds of the Internet
  524. without depending on the largely non-existent Internet multicast
  525. infrastructure.
  526. 5.3.2. Why is there no response to the ssdp:alive/ssdp:byebye
  527. requests sent to the SSDP multicast channel/port?
  528. What response would be sent? There isn't much of a point of having
  529. the SSDP clients send response saying "we received your
  530. notification" since there may be a lot of them.
  531. 5.3.3. Could NTS values other than ssdp:alive/ssdp:byebye be sent to
  532. the SSDP multicast channel/port?
  533. Yes.
  534. 5.3.4. Why do we include the NT header on ssdp:byebye requests?
  535. Technically it isn't necessary since the only useful information is
  536. the USN. But we want to stick with the GENA format that requires a
  537. NT header. In truth the requirement of including the NT header is a
  538. consequence of the next issue.
  539. 5.3.5. Shouldn't the NT and NTS values be switched?
  540. Yes, they should. Commands such as ssdp:alive and ssdp:byebye should
  541. be NT values and the service type, where necessary, should be the
  542. NTS. The current mix-up is a consequence of a previous design where
  543. the NT header was used in a manner much like we use the USN today.
  544. This really needs to change.
  545. 6. SSDP Auto-Shut-Off Algorithm
  546. 6.1. Problem Statement
  547. A mechanism is needed to ensure that SSDP does not cause such a high
  548. level of traffic that it overwhelms the network it is running on.
  549. 6.2. Proposed Solution
  550. Goland et al. [Page 13]
  551. INTERNET-DRAFT SSDP/V1 October 28, 1999
  552. [Ed. Note: We have a proposed solution but it is still a bit rough,
  553. so we will be publishing to the SSDP mailing list for further
  554. discussion before including it in the draft.]
  555. 6.3. Design Rationale
  556. 6.3.1. Why do we need an auto-shut-off algorithm?
  557. The general algorithm for figuring out how much bandwidth SSDP uses
  558. over a fixed period of time based on the number of ssdp:discover
  559. requests is :
  560. DR = Total number of SSDP clients making ssdp:discover requests over
  561. the time period in question.
  562. RS = Total number of services that will respond to the ssdp:discover
  563. requests over the time period in question.
  564. AM = Average size of the ssdp:discover requests/responses.
  565. TP = Time period in question.
  566. ((DR*3 + DR*9*RS)*AM)/TP
  567. The 3 is the number of times the ssdp:discover request will be
  568. repeated.
  569. The 9 is the number of times the unicast responses to the
  570. ssdp:discover requests will be sent out assuming the worst case in
  571. which all 3 original requests are received.
  572. So let's look at a real world worst-case scenario. Some companies,
  573. in order to enable multicast based services such as voice or video
  574. streaming to be easily configured set their local administrative
  575. multicast scope to encompass their entire company. This means one
  576. gets networks with 100,000 machines in a single administrative
  577. multicast scope. Now imagine that there is a power outage and all
  578. the machines are coming back up at the same time. Further imagine
  579. that they all want to refresh their printer location caches so they
  580. all send out ssdp:discover requests. Let us finally imagine that
  581. there are roughly 5000 printers in this network. To simplify the
  582. math we will assume that the ssdp:discover requests are evenly
  583. distributed over the 30 seconds.
  584. DR = 100,000 requesting clients
  585. RS = 5000 services
  586. AM = 512 bytes
  587. TP = 30 seconds
  588. ((100000*3+100000*9*5000)*512)/30 = 76805120000 bytes/s =
  589. 585976.5625 Megabits per second
  590. This is what one would call an awful number.
  591. Goland et al. [Page 14]
  592. INTERNET-DRAFT SSDP/V1 October 28, 1999
  593. In a more reasonably sized network SSDP is able to handle this worst
  594. case scenario much better. For example, let's look at a network with
  595. 1000 clients and 50 printers.
  596. DR = 1000 requesting clients
  597. RS = 50 services
  598. AM = 512 bytes
  599. TP = 30 seconds
  600. ((1000*3+1000*9*50)*512)/30 = 7731200 bytes/s = 59 Mbps
  601. Now this looks like an awful amount but remember that that this is
  602. the total data rate needed for 30 seconds. This means that the total
  603. amount of information SSDP needs to send out to survive a reboot is
  604. 59*30 = 1770 Mb. Therefore a 10 Mbps network, assuming an effective
  605. data rate 5 Mbps under constant load that means it will take 1770/5
  606. = 354 seconds = 6 minutes for the network to settle down.
  607. That isn't bad considering that this is an absolute worst case in a
  608. network with 1000 clients and 50 services all of whom want to talk
  609. to each other at the exact same instant.
  610. In either case, there are obvious worst-case scenarios and we need
  611. to avoid network storms, therefore we need a way for SSDP to de-
  612. activate before it causes a network storms.
  613. 6.3.2. Why not just require everyone to support directories and thus
  614. get around the scaling issue?
  615. Many manufacturers stick every protocol they can think of in their
  616. clients and services. So if your network administrator happened to
  617. buy some clients and servers that supported SSDP but didn't know
  618. they supported SSDP then you can imagine the problems. Therefore
  619. even if we required directory support there are still many cases
  620. where SSDP clients and services may inadvertently end up in a
  621. network without anyone knowing it and cause problems.
  622. 7. ssdp:all
  623. 7.1. Problem Statement
  624. A mechanism is needed to enable a client to enumerate all the
  625. services available on a particular SSDP multicast channel/port.
  626. 7.2. Proposed Solution
  627. All SSDP services MUST respond to SEARCH requests over the SSDP
  628. multicast channel/port with the ST value of ssdp:all by responding
  629. as if the ST value had been their service type.
  630. For brevity's sake a SEARCH request with a ST of ssdp:all will be
  631. referred to as a ssdp:all request.
  632. Goland et al. [Page 15]
  633. INTERNET-DRAFT SSDP/V1 October 28, 1999
  634. 7.3. Design Rationale
  635. 7.3.1. Why would anyone want to enumerate all services?
  636. This feature is mostly for network analysis tools. It also will
  637. prove very useful in the feature when directories become SSDP aware.
  638. They will be able to discover all services, record information about
  639. them and make that information available outside the local
  640. administrative multicast scope.
  641. 8. SSDP Reserved Multicast Channel
  642. 8.1. Problem Statement
  643. SSDP needs a local administrative multicast channel that will be
  644. guaranteed to only be used by SSDP compliant clients and services.
  645. 8.2. Proposed Solution
  646. IANA has reserved the relative multicast address "5" for the
  647. exclusive use of SSDP. In the local administrative scope used by
  648. this version of SSDP the relative address translates to
  649. 239.255.255.250.
  650. An application has been put in for a SSDP reserved port but IANA has
  651. not yet responded.
  652. 8.3. Design Rationale
  653. 8.3.1. Why didn't SSDP just get a static local administrative scope
  654. address rather than a relative address?
  655. We got a relative address because we expect that SSDP may be used to
  656. discover basic system services such as directories. In that case if
  657. you can't find a directory in your local scope you may want to try a
  658. wider multicast scope. This is exactly the sort of functionality
  659. enabled by MALLOC (http://www.ietf.org/html.charters/malloc-
  660. charter.html). MALLOC allows one to enumerate all the multicast
  661. scopes that are supported on the network. The SSDP client can then
  662. try progressively larger scopes to find the service they are seeing.
  663. However this progressively wider discovery only works if SSDP uses a
  664. relative address.
  665. 8.3.2. Why does SSDP need to use a port other than 80?
  666. There is a bug in the Berkley Sockets design that was inherited by
  667. WinSock as well. The bug is as follows: One can not grab a
  668. particular port on a particular multicast address without owning the
  669. same port on the local unicast address.
  670. Goland et al. [Page 16]
  671. INTERNET-DRAFT SSDP/V1 October 28, 1999
  672. The result is that if we used port 80 on the SSDP multicast scope
  673. then we would require that the SSDP software also grab port 80 for
  674. the local machine. This would mean that SSDP could only be
  675. implemented on machines which either didn't have HTTP servers or
  676. whose HTTP servers had been enhanced to support SSDP.
  677. We felt this was a unnecessary restriction. Therefore we are
  678. choosing to use a port other than 80 on the SSDP multicast channel.
  679. 9. HTTP Headers
  680. 9.1. USN Header
  681. USN = "USN" ":" AbsoluteURI; defined in section 3.2.1 of [RFC2616]
  682. 9.2. ST Header
  683. ST = "ST" ":" AbsoluteURI
  684. 10. Security Considerations
  685. TBD.
  686. 11. IANA Considerations
  687. To ensure correct interoperation based on this specification, IANA
  688. must reserve the URI namespace starting with "ssdp:" for use by this
  689. specification, its revisions, and related SSDP specifications.
  690. IANA has reserved the relative multicast address "5" for exclusive
  691. use by SSDP. An application has been made for a registered port.
  692. 12. Appendix - Constants
  693. MAX_UNIQUE - 50 - Maximum number of unique IP address/port pairs
  694. that may be sent over UDP before tripping the auto-shut-off
  695. algorithm.
  696. MAX_COUNT - 30 seconds - When the "go quiet" process is begun a
  697. message is sent out that is delayed a random interval between 0 to
  698. MAX_COUNT seconds.
  699. 13. Acknowledgements
  700. This document is the result of enormous effort by a large number of
  701. people including but not limited to:
  702. Alan Boshier, Babak Jahromi, Brandon Watson, Craig White, Dave
  703. Thaler, Holly Knight, Michel Guittet, Mike Zintel, Munil Shah, Paul
  704. Moore, Peter Ford, Pradeep Bahl, and Todd Fisher.
  705. 14. References
  706. Goland et al. [Page 17]
  707. INTERNET-DRAFT SSDP/V1 October 28, 1999
  708. [HTTPUDP] Y. Y. Goland. Multicast and Unicast UDP HTTP Requests.
  709. Internet Draft - a work in progress, draft-goland-http-udp-00.txt.
  710. [GENA] J. Cohen, S. Aggarwal, Y. Y. Goland. General Event
  711. Notification Architecture Base: Client to Arbiter. Internet Draft -
  712. a work in progress, draft-cohen-gena-client-00.txt.
  713. [MAN] H. Nielsen, P. Leach, S. Lawrence. Mandatory Extensions in
  714. HTTP. Internet Draft - a work in progress, draft-frystyk-http-
  715. extensions-03.txt.
  716. [RFC2119] S. Bradner. Key words for use in RFCs to Indicate
  717. Requirement Levels. RFC 2119, March 1997.
  718. [RFC2365] D. Meyer. Administratively Scoped IP Multicast. RFC
  719. 2365, July 1998.
  720. [RFC2396] T. Berners-Lee, R. Fielding and L. Masinter. Uniform
  721. Resource Identifiers (URI): Generic Syntax. RFC 2396, August 1998.
  722. [RFC2518] Y. Goland, E. Whitehead, A. Faizi, S. Carter, and D.
  723. Jensen. HTTP Extensions for Distributed Authoring – WEBDAV. RFC
  724. 2518, February 1999.
  725. [RFC2616] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, L.
  726. Masinter, P. Leach and T. Berners-Lee. Hypertext Transfer Protocol -
  727. HTTP/1.1. RFC 2616, November 1998.
  728. [DASL] S. Reddy, D. Lowry, S. Reddy, R. Henderson, J. Davis, A.
  729. Babich. DAV Searching & Locating. a work in progress - draft-ietf-
  730. dasl-protocol-00.txt.
  731. 15. Author's Addresses
  732. Yaron Y. Goland, Ting Cai, Paul Leach, Ye Gu
  733. Microsoft Corporation
  734. One Microsoft Way
  735. Redmond, WA 98052
  736. Email: {yarong, tingcai, paulle, yegu}@microsoft.com
  737. Shivaun Albright
  738. Hewlett-Packard Company
  739. Roseville, CA
  740. Email: SHIVAUN_ALBRIGHT@HP-Roseville-om2.om.hp.com
  741. This document will expire in April 2000.
  742. Goland et al. [Page 18]