idnits 2.17.1 draft-singer-appsawg-mcast-url-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 16, 2014) is 3473 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) ** Downref: Normative reference to an Experimental RFC: RFC 6968 ** Obsolete normative reference: RFC 4395 (Obsoleted by RFC 7595) -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Singer 3 Internet-Draft Apple, Inc. 4 Intended status: Standards Track A. Begen 5 Expires: April 19, 2015 Cisco 6 October 16, 2014 8 URLs and HTTP Response Forms for Multicast 9 draft-singer-appsawg-mcast-url-00 11 Abstract 13 This document motivates the need for defining a URL for multicast 14 delivery and provides a proposal for this purpose. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on April 19, 2015. 33 Copyright Notice 35 Copyright (c) 2014 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. Glossary of Terms . . . . . . . . . . . . . . . . . . . . . . 4 51 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 4. Required Information . . . . . . . . . . . . . . . . . . . . 4 53 5. Suggested URL Form . . . . . . . . . . . . . . . . . . . . . 5 54 5.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 5 55 5.2. Information on FLUTE (RFC 6726) . . . . . . . . . . . . . 5 56 5.3. URL Form Requirements . . . . . . . . . . . . . . . . . . 6 57 5.4. Base URL Form . . . . . . . . . . . . . . . . . . . . . . 6 58 6. FCAST Metainformation field . . . . . . . . . . . . . . . . . 8 59 7. HTTP Status Codes and Their Applicability to FCAST . . . . . 8 60 7.1. Useful . . . . . . . . . . . . . . . . . . . . . . . . . 8 61 7.2. Unlikely but Possible . . . . . . . . . . . . . . . . . . 9 62 7.3. Probably Inapplicable . . . . . . . . . . . . . . . . . . 9 63 8. Operation of the URL Handler . . . . . . . . . . . . . . . . 10 64 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 65 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 66 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 67 11.1. Normative References . . . . . . . . . . . . . . . . . . 11 68 11.2. Informative References . . . . . . . . . . . . . . . . . 11 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 71 1. Introduction 73 Various multicast file-delivery protocols are defined by the IETF and 74 3GPP (notably File Delivery over Unidirectional Transport (FLUTE) and 75 FCAST). However, they are hard to adopt into other services, partly 76 because they do not follow conventions on how these transports are 77 addressed and what information they deliver. Notably: 79 1. Much of the Web (Internet) assumes that if a file can be used, it 80 can be referred to by a URL that contains enough information to 81 start to try retrieving it. This is not true for files available 82 over multicast. 84 2. When a URL form is used, it can be annotated with the information 85 on what it refers to (e.g., a MIME type, a codecs parameter for 86 that MIME type, and so on). If we have no URL, we cannot 87 annotate it. 89 3. HTTP header responses are widely used to signal the 90 unavailability of an expected resource (404) or that a resource 91 has moved (re-direct), or that there are other choices to 92 retrieve the indicated resource, or to deliver portions of a 93 resource (byte-ranges). Though FCAST uses the metainformation 94 format of HTTP, it misses the status line, so neither 95 unavailability nor re-direct can be signaled. You cannot re- 96 direct from multicast to HTTP, for example. 98 4. 'Soft' information such as multicast group addresses, transport 99 session identifiers, and so on, are hard-coded into the 100 descriptions (e.g., Session Description Protocol (SDP) files 101 [RFC4566]). In general, the Web/Internet avoids hard-coding such 102 values, preferring to use lookup (e.g., DNS for addresses); 103 lookups can be re-factored as boundaries are crossed. 105 Traditionally multicasts have been addressed by requiring the client 106 to acquire some pre-knowledge (e.g., an SDP file) by some means out 107 of band. Thus, we require that every protocol that might use 108 multicast be adapted. This is error-prone, limiting, and time- 109 consuming. Instead, if an operating system can have a URL handler 110 for multicast URLs that deliver file objects, with an interface that 111 'emulates' the interface to HTTP, many (not all) things would 'just 112 work'. Perhaps the most notable is that we might re-direct from HTTP 113 to multicast when the server detects that there is a better way to 114 get the resource (perhaps, at this time and for this client). 116 The places where URLs occur, and where it would be advantageous to be 117 able to state "this file is available on multicast", are legion. 118 Obvious examples include anything linked into HTML (a Web page or 119 email), especially media (video, audio, images); in HTTP itself where 120 re-direction supplies a URL, and HTTP adaptive streaming systems 121 where many clients could be fetching the same set of content 122 segments. For many of these, operating system support with the same 123 API as HTTP would suffice. Even in the HTTP adaptive streaming case, 124 where it is true that the streaming engine needs to know it is using 125 multicast (as this would make substantial changes to bandwidth 126 estimation, etc.), simplifying the markup and the protocol 127 identification to a URL is a plus. FCAST is closer to HTTP operation 128 than FLUTE; files 'just arrive' and there is no concept of the 'set' 129 as represented by the file delivery table in FLUTE. We therefore 130 focus on FCAST in this document. 132 2. Glossary of Terms 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 136 "OPTIONAL" in this document are to be interpreted as described in 137 [RFC2119]. 139 3. Use Cases 141 Here are two example use cases. 143 1. The classic stadium. A sports franchise wants everyone in the 144 stadium to be able to watch a few selected camera streams. They 145 multicast the streams over a tuned WiFi system. 147 2. A network operator (either Internet service or 3G/4G) wants to 148 enable people to see a video mosaic of the top channels, and 149 click through to get to a channel fast. 151 The simple solutions are: 153 1. Provide a QR code that embeds a multicast URL linking to the 154 manifest file for the video content at the entrance, in printed 155 material, on posters, etc. When people tune to that multicast 156 URL with their phones, they get the manifest, and it refers to 157 streams that are also multicast. The act of tuning into the 158 session starts the client caching everything that arrives. 160 2. The mosaic is a multicast URL, and the segments of each program 161 are also multicast but with short cache-times, and using the same 162 URL label as the unicast address (i.e. ,an HTTP URL). When the 163 user clicks on a program, they fetch the manifest (or perhaps the 164 manifests are also multicast and pre-filled into the cache) and 165 they already have the current segment cached, so startup is 166 effectively instant. As they proceed, there is a good chance the 167 multicast has delivered every segment they need, just in time. 169 4. Required Information 171 Currently, tune-in to a multicast involves getting hold of a 'head' 172 file that gives a variety of information. The possible information 173 can be roughly separated into different classes: 175 1. Information about alternatives that could be supplied as part of 176 the higher-level protocol (e.g., different representations in 177 HTTP adaptive streaming and HTML5 source elements) 179 2. Information (IP addresses and the like) that is needed to 180 'bootstrap' the multicast reception 182 3. Information about where/how the reception is possible (e.g., 183 protocol parameters, time-ranges, and so on) 185 4. Information that could be acquired later, in-band, such as 186 feedback addresses, the availability of alternatives and unicast 187 repair servers, and so on (or indeed, a fuller description of the 188 multicast itself) 190 For the sake of simplicity, we propose that we only include (2) and 191 (3) in the URL form. 193 Ideally, there is something about the multicast itself that allows 194 the client system to assess fairly rapidly whether it is working (the 195 multicast join succeeded, packets are arriving, etc.) and if that 196 fails, the URL handler can give a suitable error indication (maybe an 197 existing one, maybe new). 199 5. Suggested URL Form 201 5.1. Introduction 203 Both FLUTE and FCAST rely on Asynchronous Layered Coding (ALC) 204 [RFC5775] / Layered Coding Transport (LCT) [RFC5651], which in turn 205 has the concept of channels to handle congestion and rate control. 206 We presume the existence of a base channel and indicate how to 207 acquire that. 209 In an FCAST session, files are identified by URI labels. We suggest 210 that we identify a reserved URN form to indicate 'this is a complete 211 SDP file describing all the sessions'. This allows bootstrapping 212 from the base channel to all of the channels in a session. 214 FLUTE [RFC6726] is specific about the parameters needed to acquire an 215 ALC/LCT session, and since FCAST [RFC6968] also relies on ALC/LCT, 216 the same analysis applies. 218 5.2. Information on FLUTE (RFC 6726) 220 To start receiving a file delivery session, the receiver needs to 221 know transport parameters associated with the session. Interpreting 222 these parameters and starting the reception therefore represents the 223 entry point from which thereafter the receiver operation falls into 224 the scope of this specification. According to [RFC5775], the 225 transport parameters of an ALC/LCT session that the receiver needs to 226 know are: 228 o The source IP address. 230 o The number of channels in the session. 232 o The destination IP address and port number for each channel in the 233 session. 235 o The transport session identifier (TSI) of the session. 237 o An indication that the session is a FLUTE session. The need to 238 demultiplex objects upon reception is implicit in any use of 239 FLUTE, and this fulfills the ALC requirement of an indication of 240 whether or not a session carries packets for more than one object 241 (all FLUTE sessions carry packets for more than one object). 243 5.3. URL Form Requirements 245 We have at least the following requirements: 247 o The URLs must be valid according to the RFCs and recent work at 248 the W3C 250 o The absolute form must exist (obviously) 252 o Relative URLs must also work 254 o We should avoid the fragment (#) and query suffices (?) even 255 though, in the latter case, there is no server that the URL is 256 sent to. 258 o We should permit the URL to self-declare its validity period (and 259 thus enable rapid time-outs when it is requested outside this 260 period) 262 o Ideally, we also allow it to indicate its 'geographic' (operator 263 network) availability scope 265 5.4. Base URL Form 267 This suggests a URL form in three parts: 269 o A prefix giving the URL scheme and basic parameters 271 o A mid-part giving the temporal and geographic scope 273 o A suffix that is the label of the desired file 275 Where the prefix is roughly like 276 fcast://destination:port/source:TSI 278 with 280 destination: An explicit multicast address (x.y.z.w) or (better) a 281 name that resolves to one (or more) IP multicast address(es) for 282 the base channel. 284 port: Port number for the base channel. 286 source: An explicit IP address (x.y.z.w) or (better) a name that 287 resolves to the source address. 289 TSI: The transport session identifier for the session. 291 The mid-part has optional terms that are each formatted as / 292 key:value. The keys and their values are: 294 start: the absolute start-time of availability 296 end: likewise, the end time 298 network: an identification of the network(s) on which the 299 multicast is made available (for the indicated time-span, if any) 301 The start and end times are each optional and if present are 302 expressed exactly as in SDP, i.e. as the decimal representation of 303 Network Time Protocol (NTP) time values in seconds since 1900. If 304 the URL agent determines it is operating outside this time range, a 305 suitable error SHOULD be returned immediately. If either the start 306 or end time are absent, then the multicast starts (or stops) at an 307 indefinite time. 309 The network attribute takes a list of domain names, joined by the 310 plus sign; if the URL handler is confident that the machine is not on 311 any of the networks, a suitable error SHOULD be returned immediately, 312 as it knows the multicast reception will not succeed. 314 The suffix starts with the special key /label: and is followed by the 315 label of the desired file. (We retain at least the forward slashes 316 in the path in the clear so that relative URLs work, but perhaps some 317 characters and maybe some instances of slash should be escaped.) 319 Example: 321 fcast://232.0.0.1:5620/broadcast.example.com:527353/start:35776638264 322 /network:media.example.com/label:http://news.example.com/stuff.mp4 323 given such a URL, the terminal can (try to) tune into the FCAST 324 session, and retrieve the indicated file. 326 6. FCAST Metainformation field 328 In FCAST the metainformation field carries anything that an HTTP 329 metainformation field can carry, but not the status line. This means 330 it is not possible to indicate "this file might be expected here, but 331 it is not here any more" (404) or "this file has moved" (301 or 307) 332 or even that there are multiple choices on where to get this resource 333 (300 'choices'). The most useful, perhaps, is the ability to 334 indicate "you might have expected to get this over this multicast, 335 but it's not here, but over there (re-direct)" perhaps even re- 336 directing back to HTTP, or to another multicast session. 338 We therefore suggest we define a new form of the FCAST 339 metainformation that also includes a status line formatted exactly as 340 the HTTP status line, but with the HTTP-version replaced by FCAST- 341 version: 343 Status-Line = FCAST-Version SP Status-Code SP Reason-Phrase CRLF 345 7. HTTP Status Codes and Their Applicability to FCAST 347 Here are the status codes available in HTTP 1.1, and a brief 348 statement of whether they could be applicable to FCAST: 350 7.1. Useful 352 o 200 OK: Usual status code when the object is supplied, or when 353 just the metainformation is supplied 355 o 203 Non-Authoritative Information 357 o 206 Partial Content: Useful to indicate that byte-ranges of the 358 resource are supplied separately 360 o 300 Multiple Choices: Useful to indicate that there are also other 361 places to get the content 363 o 301 Moved Permanently: The resource might be expected here, but 364 has moved (re-direct) 366 o 302 Found 368 o 303 See Other 369 o 307 Temporary Redirect: The resource might be expected here, but 370 has moved (re-direct) 372 o 404 Not Found: The resource might be expected here, but it is no 373 longer available 375 o 410 Gone 377 7.2. Unlikely but Possible 379 o 100 Continue: Unlikely to be of use 381 o 101 Switching Protocols: Maybe useful 383 o 502 Bad Gateway: The multicast was being fed by a gateway that 384 failed 386 o 503 Service Unavailable 388 7.3. Probably Inapplicable 390 o 201 Created 392 o 202 Accepted 394 o 204 No Content 396 o 205 Reset Content 398 o 304 Not Modified 400 o 305 Use Proxy 402 o 400 Bad Request 404 o 401 Unauthorized 406 o 402 Payment Required 408 o 403 Forbidden 410 o 405 Method Not Allowed 412 o 406 Not Acceptable 414 o 407 Proxy Authentication Required 416 o 408 Request Time-out 417 o 409 Conflict 419 o 411 Length Required 421 o 412 Precondition Failed 423 o 413 Request Entity Too Large 425 o 414 Request-URI Too Large 427 o 415 Unsupported Media Type 429 o 416 Requested range not satisfiable 431 o 417 Expectation Failed 433 o 500 Internal Server Error 435 o 501 Not Implemented 437 o 504 Gateway Time-out 439 o 505 HTTP Version not supported 441 8. Operation of the URL Handler 443 When the client-side URL handler gets the first URL for a given 444 session, it would 'tune in that session' and (with luck) start 445 receiving files and metainformation. On the receipt of 'special 446 files' (e.g., an SDP) it can expand its knowledge of the session. 447 Other files not corresponding to the immediate request in hand should 448 be cached, observing the cache control headers. When the indicated 449 file (or at least the requested byte-range of the indicated file) is 450 available, it is returned. If a 404, 410, or 3xx response is 451 received for the indicated file, then an appropriate error is 452 returned, as indeed it is if the URL specifies that the multicast is 453 only available over a given time range, and the request is not or 454 cannot be satisfied in that time range. 456 9. Security Considerations 458 TBC. 460 10. IANA Considerations 462 This section contains the registration information for the "fcast" 463 URI scheme (in accordance with Section 5.4 of [RFC4395]). 465 Editor's note: The registration template will be provided in a later 466 revision. 468 11. References 470 11.1. Normative References 472 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 473 Requirement Levels", BCP 14, RFC 2119, March 1997. 475 [RFC6968] Roca, V. and B. Adamson, "FCAST: Object Delivery for the 476 Asynchronous Layered Coding (ALC) and NACK-Oriented 477 Reliable Multicast (NORM) Protocols", RFC 6968, July 2013. 479 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 480 Registration Procedures for New URI Schemes", BCP 35, RFC 481 4395, February 2006. 483 11.2. Informative References 485 [RFC5775] Luby, M., Watson, M., and L. Vicisano, "Asynchronous 486 Layered Coding (ALC) Protocol Instantiation", RFC 5775, 487 April 2010. 489 [RFC5651] Luby, M., Watson, M., and L. Vicisano, "Layered Coding 490 Transport (LCT) Building Block", RFC 5651, October 2009. 492 [RFC6726] Paila, T., Walsh, R., Luby, M., Roca, V., and R. Lehtonen, 493 "FLUTE - File Delivery over Unidirectional Transport", RFC 494 6726, November 2012. 496 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 497 Description Protocol", RFC 4566, July 2006. 499 Authors' Addresses 501 Dave Singer 502 Apple, Inc. 503 1 Infinite Loop 504 Cupertino 95014 505 USA 507 EMail: singer@apple.com 508 Ali Begen 509 Cisco 510 181 Bay Street 511 Toronto, ON M5J 2T3 512 Canada 514 EMail: abegen@cisco.com