CoAP option for no server-response
draft-tcs-coap-no-response-option-04

The information below is for an old version of the document
Document Type Active Internet-Draft (individual)
Last updated 2013-10-09
Stream (None)
Intended RFC status (None)
Formats plain text pdf html bibtex
IETF conflict review conflict-review-tcs-coap-no-response-option
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
CoRE                                                   A. Bhattacharyya
Internet Draft                                         S. Bandyopadhyay
Intended status: Standards track                                 A. Pal
Expires: April 2014                      Tata Consultancy Services Ltd.
                                                       October 9, 2013

                    CoAP option for no server-response
                   draft-tcs-coap-no-response-option-04

   Abstract

   There can be typical M2M scenarios where responses from the data
   sink to the data source against request/ notification from the
   source might be considered redundant. This kind of open-loop
   exchange (with no reverse path from the sink to the source) may be
   desired while updating resources in constrained systems looking for
   maximized throughput with minimized resource consumption. CoAP
   already provides a non-confirmable (NON) mode of exchange where The
   receiving end-point does not respond with ACK. However, the
   receiving end-point responds the sender with a status code
   indicating "the result of the attempt to understand and satisfy the
   request".

   This draft introduces a header option: 'No-Response' to suppress
   responses from the receiver and discusses exemplary use cases which
   motivated this proposition based on real experience. This option
   also provides granularity by allowing suppression of a typical class
   or a combination of classes of responses. This option may be
   effective for both unicast and multicast scenarios.

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), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   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."

Bhattacharyya, et al.   Expires April 9, 2014                 [Page 1]
 Internet-Draft  draft-tcs-coap-no-response-option-04      October 2013

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on April 9, 2014.

Copyright Notice

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

   1. Introduction ................................................ 3
      1.1. Granular suppression of responses ...................... 3
      1.2. Terminology ............................................ 4
   2. Potential benefits .......................................... 4
   3. Exemplary application scenarios ............................. 4
      3.1. Frequent update of geo-location from vehicles to backend
      (Category 1) ................................................ 5
         3.1.1. Benefits using No-Response ........................ 5
      3.2. Multicasting traffic congestion information to PDAs/ smart-
      phones (Category 2) ......................................... 6
         3.2.1. Using granular response suppression ............... 6

Bhattacharyya, et al.   Expires April 9, 2014                 [Page 2]
 Internet-Draft  draft-tcs-coap-no-response-option-04      October 2013

         3.2.2. Benefits using No-Response ........................ 6
   4. Option Definition ........................................... 6
      4.1. Achieving granular suppression ......................... 8
   5. Example ..................................................... 9
      5.1. Request/response Scenario .............................. 9
Show full document text