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