Internet DRAFT - draft-singer-appsawg-mcast-url

draft-singer-appsawg-mcast-url







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]