Network Working Group D. Singer
Internet-Draft Apple, Inc.
Intended status: Standards Track A. Begen
Expires: April 19, 2015 Cisco
October 16, 2014
URLs and HTTP Response Forms for Multicast
draft-singer-appsawg-mcast-url-00
Abstract
This document motivates the need for defining a URL for multicast
delivery and provides a proposal for this purpose.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 19, 2015.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
Singer & Begen Expires April 19, 2015 [Page 1]
Internet-Draft Multicast URLs October 2014
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Glossary of Terms . . . . . . . . . . . . . . . . . . . . . . 4
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Required Information . . . . . . . . . . . . . . . . . . . . 4
5. Suggested URL Form . . . . . . . . . . . . . . . . . . . . . 5
5.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 5
5.2. Information on FLUTE (RFC 6726) . . . . . . . . . . . . . 5
5.3. URL Form Requirements . . . . . . . . . . . . . . . . . . 6
5.4. Base URL Form . . . . . . . . . . . . . . . . . . . . . . 6
6. FCAST Metainformation field . . . . . . . . . . . . . . . . . 8
7. HTTP Status Codes and Their Applicability to FCAST . . . . . 8
7.1. Useful . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.2. Unlikely but Possible . . . . . . . . . . . . . . . . . . 9
7.3. Probably Inapplicable . . . . . . . . . . . . . . . . . . 9
8. Operation of the URL Handler . . . . . . . . . . . . . . . . 10
9. Security Considerations . . . . . . . . . . . . . . . . . . . 10
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
11.1. Normative References . . . . . . . . . . . . . . . . . . 11
11.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
Various multicast file-delivery protocols are defined by the IETF and
3GPP (notably File Delivery over Unidirectional Transport (FLUTE) and
FCAST). However, they are hard to adopt into other services, partly
because they do not follow conventions on how these transports are
addressed and what information they deliver. Notably:
1. Much of the Web (Internet) assumes that if a file can be used, it
can be referred to by a URL that contains enough information to
start to try retrieving it. This is not true for files available
over multicast.
2. When a URL form is used, it can be annotated with the information
on what it refers to (e.g., a MIME type, a codecs parameter for
that MIME type, and so on). If we have no URL, we cannot
annotate it.
Singer & Begen Expires April 19, 2015 [Page 2]
Internet-Draft Multicast URLs October 2014
3. HTTP header responses are widely used to signal the
unavailability of an expected resource (404) or that a resource
has moved (re-direct), or that there are other choices to
retrieve the indicated resource, or to deliver portions of a
resource (byte-ranges). Though FCAST uses the metainformation
format of HTTP, it misses the status line, so neither
unavailability nor re-direct can be signaled. You cannot re-
direct from multicast to HTTP, for example.
4. 'Soft' information such as multicast group addresses, transport
session identifiers, and so on, are hard-coded into the
descriptions (e.g., Session Description Protocol (SDP) files
[RFC4566]). In general, the Web/Internet avoids hard-coding such
values, preferring to use lookup (e.g., DNS for addresses);
lookups can be re-factored as boundaries are crossed.
Traditionally multicasts have been addressed by requiring the client
to acquire some pre-knowledge (e.g., an SDP file) by some means out
of band. Thus, we require that every protocol that might use
multicast be adapted. This is error-prone, limiting, and time-
consuming. Instead, if an operating system can have a URL handler
for multicast URLs that deliver file objects, with an interface that
'emulates' the interface to HTTP, many (not all) things would 'just
work'. Perhaps the most notable is that we might re-direct from HTTP
to multicast when the server detects that there is a better way to
get the resource (perhaps, at this time and for this client).
The places where URLs occur, and where it would be advantageous to be
able to state "this file is available on multicast", are legion.
Obvious examples include anything linked into HTML (a Web page or
email), especially media (video, audio, images); in HTTP itself where
re-direction supplies a URL, and HTTP adaptive streaming systems
where many clients could be fetching the same set of content
segments. For many of these, operating system support with the same
API as HTTP would suffice. Even in the HTTP adaptive streaming case,
where it is true that the streaming engine needs to know it is using
multicast (as this would make substantial changes to bandwidth
estimation, etc.), simplifying the markup and the protocol
identification to a URL is a plus. FCAST is closer to HTTP operation
than FLUTE; files 'just arrive' and there is no concept of the 'set'
as represented by the file delivery table in FLUTE. We therefore
focus on FCAST in this document.
Singer & Begen Expires April 19, 2015 [Page 3]
Internet-Draft Multicast URLs October 2014
2. Glossary of Terms
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
[RFC2119].
3. Use Cases
Here are two example use cases.
1. The classic stadium. A sports franchise wants everyone in the
stadium to be able to watch a few selected camera streams. They
multicast the streams over a tuned WiFi system.
2. A network operator (either Internet service or 3G/4G) wants to
enable people to see a video mosaic of the top channels, and
click through to get to a channel fast.
The simple solutions are:
1. Provide a QR code that embeds a multicast URL linking to the
manifest file for the video content at the entrance, in printed
material, on posters, etc. When people tune to that multicast
URL with their phones, they get the manifest, and it refers to
streams that are also multicast. The act of tuning into the
session starts the client caching everything that arrives.
2. The mosaic is a multicast URL, and the segments of each program
are also multicast but with short cache-times, and using the same
URL label as the unicast address (i.e. ,an HTTP URL). When the
user clicks on a program, they fetch the manifest (or perhaps the
manifests are also multicast and pre-filled into the cache) and
they already have the current segment cached, so startup is
effectively instant. As they proceed, there is a good chance the
multicast has delivered every segment they need, just in time.
4. Required Information
Currently, tune-in to a multicast involves getting hold of a 'head'
file that gives a variety of information. The possible information
can be roughly separated into different classes:
1. Information about alternatives that could be supplied as part of
the higher-level protocol (e.g., different representations in
HTTP adaptive streaming and HTML5 source elements)
Singer & Begen Expires April 19, 2015 [Page 4]
Internet-Draft Multicast URLs October 2014
2. Information (IP addresses and the like) that is needed to
'bootstrap' the multicast reception
3. Information about where/how the reception is possible (e.g.,
protocol parameters, time-ranges, and so on)
4. Information that could be acquired later, in-band, such as
feedback addresses, the availability of alternatives and unicast
repair servers, and so on (or indeed, a fuller description of the
multicast itself)
For the sake of simplicity, we propose that we only include (2) and
(3) in the URL form.
Ideally, there is something about the multicast itself that allows
the client system to assess fairly rapidly whether it is working (the
multicast join succeeded, packets are arriving, etc.) and if that
fails, the URL handler can give a suitable error indication (maybe an
existing one, maybe new).
5. Suggested URL Form
5.1. Introduction
Both FLUTE and FCAST rely on Asynchronous Layered Coding (ALC)
[RFC5775] / Layered Coding Transport (LCT) [RFC5651], which in turn
has the concept of channels to handle congestion and rate control.
We presume the existence of a base channel and indicate how to
acquire that.
In an FCAST session, files are identified by URI labels. We suggest
that we identify a reserved URN form to indicate 'this is a complete
SDP file describing all the sessions'. This allows bootstrapping
from the base channel to all of the channels in a session.
FLUTE [RFC6726] is specific about the parameters needed to acquire an
ALC/LCT session, and since FCAST [RFC6968] also relies on ALC/LCT,
the same analysis applies.
5.2. Information on FLUTE (RFC 6726)
To start receiving a file delivery session, the receiver needs to
know transport parameters associated with the session. Interpreting
these parameters and starting the reception therefore represents the
entry point from which thereafter the receiver operation falls into
the scope of this specification. According to [RFC5775], the
transport parameters of an ALC/LCT session that the receiver needs to
know are:
Singer & Begen Expires April 19, 2015 [Page 5]
Internet-Draft Multicast URLs October 2014
o The source IP address.
o The number of channels in the session.
o The destination IP address and port number for each channel in the
session.
o The transport session identifier (TSI) of the session.
o An indication that the session is a FLUTE session. The need to
demultiplex objects upon reception is implicit in any use of
FLUTE, and this fulfills the ALC requirement of an indication of
whether or not a session carries packets for more than one object
(all FLUTE sessions carry packets for more than one object).
5.3. URL Form Requirements
We have at least the following requirements:
o The URLs must be valid according to the RFCs and recent work at
the W3C
o The absolute form must exist (obviously)
o Relative URLs must also work
o We should avoid the fragment (#) and query suffices (?) even
though, in the latter case, there is no server that the URL is
sent to.
o We should permit the URL to self-declare its validity period (and
thus enable rapid time-outs when it is requested outside this
period)
o Ideally, we also allow it to indicate its 'geographic' (operator
network) availability scope
5.4. Base URL Form
This suggests a URL form in three parts:
o A prefix giving the URL scheme and basic parameters
o A mid-part giving the temporal and geographic scope
o A suffix that is the label of the desired file
Where the prefix is roughly like
Singer & Begen Expires April 19, 2015 [Page 6]
Internet-Draft Multicast URLs October 2014
fcast://destination:port/source:TSI
with
destination: An explicit multicast address (x.y.z.w) or (better) a
name that resolves to one (or more) IP multicast address(es) for
the base channel.
port: Port number for the base channel.
source: An explicit IP address (x.y.z.w) or (better) a name that
resolves to the source address.
TSI: The transport session identifier for the session.
The mid-part has optional terms that are each formatted as /
key:value. The keys and their values are:
start: the absolute start-time of availability
end: likewise, the end time
network: an identification of the network(s) on which the
multicast is made available (for the indicated time-span, if any)
The start and end times are each optional and if present are
expressed exactly as in SDP, i.e. as the decimal representation of
Network Time Protocol (NTP) time values in seconds since 1900. If
the URL agent determines it is operating outside this time range, a
suitable error SHOULD be returned immediately. If either the start
or end time are absent, then the multicast starts (or stops) at an
indefinite time.
The network attribute takes a list of domain names, joined by the
plus sign; if the URL handler is confident that the machine is not on
any of the networks, a suitable error SHOULD be returned immediately,
as it knows the multicast reception will not succeed.
The suffix starts with the special key /label: and is followed by the
label of the desired file. (We retain at least the forward slashes
in the path in the clear so that relative URLs work, but perhaps some
characters and maybe some instances of slash should be escaped.)
Example:
fcast://232.0.0.1:5620/broadcast.example.com:527353/start:35776638264
/network:media.example.com/label:http://news.example.com/stuff.mp4
Singer & Begen Expires April 19, 2015 [Page 7]
Internet-Draft Multicast URLs October 2014
given such a URL, the terminal can (try to) tune into the FCAST
session, and retrieve the indicated file.
6. FCAST Metainformation field
In FCAST the metainformation field carries anything that an HTTP
metainformation field can carry, but not the status line. This means
it is not possible to indicate "this file might be expected here, but
it is not here any more" (404) or "this file has moved" (301 or 307)
or even that there are multiple choices on where to get this resource
(300 'choices'). The most useful, perhaps, is the ability to
indicate "you might have expected to get this over this multicast,
but it's not here, but over there (re-direct)" perhaps even re-
directing back to HTTP, or to another multicast session.
We therefore suggest we define a new form of the FCAST
metainformation that also includes a status line formatted exactly as
the HTTP status line, but with the HTTP-version replaced by FCAST-
version:
Status-Line = FCAST-Version SP Status-Code SP Reason-Phrase CRLF
7. HTTP Status Codes and Their Applicability to FCAST
Here are the status codes available in HTTP 1.1, and a brief
statement of whether they could be applicable to FCAST:
7.1. Useful
o 200 OK: Usual status code when the object is supplied, or when
just the metainformation is supplied
o 203 Non-Authoritative Information
o 206 Partial Content: Useful to indicate that byte-ranges of the
resource are supplied separately
o 300 Multiple Choices: Useful to indicate that there are also other
places to get the content
o 301 Moved Permanently: The resource might be expected here, but
has moved (re-direct)
o 302 Found
o 303 See Other
Singer & Begen Expires April 19, 2015 [Page 8]
Internet-Draft Multicast URLs October 2014
o 307 Temporary Redirect: The resource might be expected here, but
has moved (re-direct)
o 404 Not Found: The resource might be expected here, but it is no
longer available
o 410 Gone
7.2. Unlikely but Possible
o 100 Continue: Unlikely to be of use
o 101 Switching Protocols: Maybe useful
o 502 Bad Gateway: The multicast was being fed by a gateway that
failed
o 503 Service Unavailable
7.3. Probably Inapplicable
o 201 Created
o 202 Accepted
o 204 No Content
o 205 Reset Content
o 304 Not Modified
o 305 Use Proxy
o 400 Bad Request
o 401 Unauthorized
o 402 Payment Required
o 403 Forbidden
o 405 Method Not Allowed
o 406 Not Acceptable
o 407 Proxy Authentication Required
o 408 Request Time-out
Singer & Begen Expires April 19, 2015 [Page 9]
Internet-Draft Multicast URLs October 2014
o 409 Conflict
o 411 Length Required
o 412 Precondition Failed
o 413 Request Entity Too Large
o 414 Request-URI Too Large
o 415 Unsupported Media Type
o 416 Requested range not satisfiable
o 417 Expectation Failed
o 500 Internal Server Error
o 501 Not Implemented
o 504 Gateway Time-out
o 505 HTTP Version not supported
8. Operation of the URL Handler
When the client-side URL handler gets the first URL for a given
session, it would 'tune in that session' and (with luck) start
receiving files and metainformation. On the receipt of 'special
files' (e.g., an SDP) it can expand its knowledge of the session.
Other files not corresponding to the immediate request in hand should
be cached, observing the cache control headers. When the indicated
file (or at least the requested byte-range of the indicated file) is
available, it is returned. If a 404, 410, or 3xx response is
received for the indicated file, then an appropriate error is
returned, as indeed it is if the URL specifies that the multicast is
only available over a given time range, and the request is not or
cannot be satisfied in that time range.
9. Security Considerations
TBC.
Singer & Begen Expires April 19, 2015 [Page 10]
Internet-Draft Multicast URLs October 2014
10. IANA Considerations
This section contains the registration information for the "fcast"
URI scheme (in accordance with Section 5.4 of [RFC4395]).
Editor's note: The registration template will be provided in a later
revision.
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC6968] Roca, V. and B. Adamson, "FCAST: Object Delivery for the
Asynchronous Layered Coding (ALC) and NACK-Oriented
Reliable Multicast (NORM) Protocols", RFC 6968, July 2013.
[RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
Registration Procedures for New URI Schemes", BCP 35, RFC
4395, February 2006.
11.2. Informative References
[RFC5775] Luby, M., Watson, M., and L. Vicisano, "Asynchronous
Layered Coding (ALC) Protocol Instantiation", RFC 5775,
April 2010.
[RFC5651] Luby, M., Watson, M., and L. Vicisano, "Layered Coding
Transport (LCT) Building Block", RFC 5651, October 2009.
[RFC6726] Paila, T., Walsh, R., Luby, M., Roca, V., and R. Lehtonen,
"FLUTE - File Delivery over Unidirectional Transport", RFC
6726, November 2012.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
Authors' Addresses
Dave Singer
Apple, Inc.
1 Infinite Loop
Cupertino 95014
USA
EMail: singer@apple.com
Singer & Begen Expires April 19, 2015 [Page 11]
Internet-Draft Multicast URLs October 2014
Ali Begen
Cisco
181 Bay Street
Toronto, ON M5J 2T3
Canada
EMail: abegen@cisco.com
Singer & Begen Expires April 19, 2015 [Page 12]