Internet DRAFT - draft-loreto-core-coap-streaming

draft-loreto-core-coap-streaming






core                                                           S. Loreto
Internet-Draft                                                   O. Novo
Intended status: Standards Track                                Ericsson
Expires: September 28, 2012                               March 27, 2012


                             CoAP Streaming
                  draft-loreto-core-coap-streaming-00

Abstract

   This specification defines a simple mechanism for streaming media
   data from a server to a client in a constrained network over CoAP.
   The mechanism take advantage of the observer design pattern described
   in CoAP, extending it, to support streaming media transfer between
   nodes.

Note

   Discussion and suggestions for improvement are requested, and should
   be sent to core@ietf.org.

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 September 28, 2012.

Copyright Notice

   Copyright (c) 2012 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



Loreto & Novo          Expires September 28, 2012               [Page 1]

Internet-Draft               CoAP Streaming                   March 2012


   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

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  COAP Streaming Extension  . . . . . . . . . . . . . . . . . . . 3
     2.1.  Definition  . . . . . . . . . . . . . . . . . . . . . . . . 3
     2.2.  CoAP Streaming negotiation  . . . . . . . . . . . . . . . . 6
   3.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 8
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 8
     6.1.  Normative References  . . . . . . . . . . . . . . . . . . . 8
     6.2.  Informative References  . . . . . . . . . . . . . . . . . . 8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 9






























Loreto & Novo          Expires September 28, 2012               [Page 2]

Internet-Draft               CoAP Streaming                   March 2012


1.  Introduction

   The Constrained Application Protocol (CoAP)[I-D.ietf-core-coap] is a
   specialized web transfer protocol used with constrained networks and
   nodes for machine-to-machine applications.

   CoAP has a number of extensions.  One of its extensions is the
   "Observing Resource in CoAP" draft [I-D.ietf-core-observe].  The
   "Observing Resource in CoAP" draft defines a mechanism to push
   resource representations from servers to interested clients.

   However, the CoAP specification or any of its extensions do not
   define any mechanism to transfer media information between the nodes.
   If a node in a constrained network wants to transfer some streaming
   media information with any other node, it does not have any specific
   mechanism to do so.

   The main purpose of this document is to extend the "Observing
   Resource in CoAP" draft [I-D.ietf-core-observe] to support streaming
   media transfer between the nodes.

   In addition, this specification adds a new option Streaming to the
   Constrained Application Protocol (CoAP).  The main purpose of this
   option is to indicate when a message will break into chunks of known
   size.

1.1.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].


2.  COAP Streaming Extension

2.1.  Definition

   The CoAP Streaming mechanism extends the "Observing Resource in CoAP"
   draft [I-D.ietf-core-observe].  The basic life cycle of an
   application using CoAP streaming is as follows:

   o  The client registers itself with a resource by performing a GET
      request that includes an Observe Option.  The registration process
      is defined in the "Observing Resource in CoAP" draft
      [I-D.ietf-core-observe].






Loreto & Novo          Expires September 28, 2012               [Page 3]

Internet-Draft               CoAP Streaming                   March 2012


   o  If the observation relationship is established between the server
      and the client, the server sends a CoAP streaming response to the
      client, including the Observe Option, whenever some new media
      chuck is available.


   A CoAP streaming response includes the following options:

   o  The Observe and Token defined in the "Observing Resource in CoAP"
      draft [I-D.ietf-core-observe].

   o  A New Option header called 'streaming' that indicates the message
      will break into chunks of known size.

   o  End of File (EOF) that indicates the end of the transmission of
      the media.  This value will help to differentiate between a
      connection terminated by a fault and one that is correctly
      terminated.

   The following example includes a media chunk in the observation
   message:

                   2.05 Content
                   Observe: 12
                   Token: 0x4a
                   Streaming: chunked
                   Payload:
                     This is the data in the first chunk

                        Figure 1: Transfer response

   The CoAP streaming mechanism is based on the capability of the server
   to send several pieces of information in different responses.

   Figure 2 illustrates the media communication between client and
   server.















Loreto & Novo          Expires September 28, 2012               [Page 4]

Internet-Draft               CoAP Streaming                   March 2012


           Client                   Server
             |                        |
             |                        |
             |                        |
             |GET /videocamera        |
             | Observe: 0             |
             | Token: 0x4a            |
             |----------------------->|
             |                        |
             |                        |
             |2.05 Content            |
             | Observe: 1             |
             | Token: 0x4a            |
             | Streaming: chunked     |
             | Content-Type: 0        |
             | Payload:               |
             |       First chuck      |
             |<-----------------------|
             |                        |
             |                        |
             |2.05 Content            |
             | Observe: 2             |
             | Token: 0x4a            |
             | Streaming: chunked     |
             | Content-Type: 0        |
             | Payload:               |
             |       Second chuck     |
             |<-----------------------|
             |                        |
             |                        |
             |                        |
             |                        |

               Figure 2: Observing a Media Resource in COAP

   A notification containing a chunk can be confirmable or non-
   confirmable (i.e. sent in a confirmable or non-confirmable message).
   However, all the notifications using the mechanism defined in this
   draft MUST use non-confirmable messages.

   The server MUST set the value of the Observe Option in each
   notification to the 16 least-significant bits of a strictly
   increasing sequence number that MUST contain no gap.  If there is no
   gap in the Observe Option between two sequence notification a client
   is receiving, no chunk has been lost or delayed by the network.

   Note that, differently from what specified in Section 4.4 of
   [I-D.ietf-core-observe], a server can send more than one notification



Loreto & Novo          Expires September 28, 2012               [Page 5]

Internet-Draft               CoAP Streaming                   March 2012


   per second per client, token and resource.  The server can then
   happen to reuse the same option value with the same client, token and
   resource within approximately 2**16 seconds (roughly 18.2 hours).

   Since CoAP runs over UDP, chunks (i.e. notifications) can arrive to
   the client in a different order than they were sent or a chunk can be
   lost.  The ordering of the chunks is determined by the Observe option
   that, in this case, can be seen as similar to the "sequence number"
   of the RTP [RFC3550].  It is left to the application to choose the
   appropriate action, if any, when it detects that a chunk is missing.

   A notification containing a chunk is made up of the bytes after the
   options, if any; its maximum length SHOULD be 1280 bytes.

   The chunks are encoded as "text/plain; charset=utf-8" setting the
   Content-Type option to 0.  How the media is translated to text format
   is out of the scope of this document.

2.2.  CoAP Streaming negotiation

   Figure 3 illustrates a client discovering the different codecs a
   resource (i.e. videocamera) on a server supports, using the Core
   Resource Discovery mechanism [I-D.ietf-core-link-format].

   The client then chooses a proper code to observe selecting the right
   URI.

























Loreto & Novo          Expires September 28, 2012               [Page 6]

Internet-Draft               CoAP Streaming                   March 2012


          Client                                Server
             |                                     |
             |                                     |
             |                                     |
             | GET /.well-known/core?rt=videocamera|
             |------------------------------------>|
             |                                     |
             |                                     |
             |2.05 Content                         |
             | <videocamera/MPEG>;rt="videocamera" |
             | <videocamera/AVI>;rt="videocamera"  |
             |<------------------------------------|
             |                                     |
             |                                     |
             |GET /videocamera/MPEG                |
             | Observe: 0                          |
             | Token: 0x4a                         |
             |------------------------------------>|
             |                                     |
             |                                     |
             |2.05 Content                         |
             | Observe: 1                          |
             | Token: 0x4a                         |
             | Streaming: chunked                  |
             | Content-Type: 0                     |
             | Payload:                            |
             |       First chuck                   |
             |<------------------------------------|
             |                                     |
             |                                     |
             |2.05 Content                         |
             | Observe: 2                          |
             | Token: 0x4a                         |
             | Streaming: chunked                  |
             | Content-Type: 0                     |
             | Payload:                            |
             |       Second chuck                  |
             |<------------------------------------|
             |                                     |


                        Figure 3: Media negotiation


3.  Security Considerations

   This presents no security considerations beyond those in section 8 of
   the Observing Resources in CoAP specification [I-D.ietf-core-observe]



Loreto & Novo          Expires September 28, 2012               [Page 7]

Internet-Draft               CoAP Streaming                   March 2012


   .


4.  IANA Considerations

   The IANA is requested to add the following "CoAP Option Numbers"
   entry as per Section 11.2 of [I-D.ietf-core-coap].

                   +--------+------------------+----------------+
                   | Number | Name             | Reference      |
                   +--------+------------------+----------------+
                   |  23    |     Streaming    | Section 2      |
                   +--------+------------------+----------------+


5.  Acknowledgements

   The authors of this draft would like to thank Heidi-Maria Rissanen.


6.  References

6.1.  Normative References

   [I-D.ietf-core-coap]
              Shelby, Z., Hartke, K., Bormann, C., and B. Frank,
              "Constrained Application Protocol (CoAP)",
              draft-ietf-core-coap-09 (work in progress), March 2012.

   [I-D.ietf-core-observe]
              Hartke, K., "Observing Resources in CoAP",
              draft-ietf-core-observe-05 (work in progress), March 2012.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, July 2003.

6.2.  Informative References

   [I-D.ietf-core-link-format]
              Shelby, Z., "CoRE Link Format",
              draft-ietf-core-link-format-11 (work in progress),
              January 2012.





Loreto & Novo          Expires September 28, 2012               [Page 8]

Internet-Draft               CoAP Streaming                   March 2012


Authors' Addresses

   Salvatore Loreto
   Ericsson
   Hirsalantie 11
   Jorvas 02420
   Finland

   Email: salvatore.loreto@ericsson.com


   Oscar Novo
   Ericsson
   Hirsalantie 11
   Jorvas 02420
   Finland

   Email: oscar.novo@ericsson.com

































Loreto & Novo          Expires September 28, 2012               [Page 9]