Internet DRAFT - draft-fan-core-coap-via-option

draft-fan-core-coap-via-option






CoRE                                                              X. Fan
Internet-Draft                                                       ZTE
Intended status: Standards Track                       December 18, 2012
Expires: June 21, 2013


                       CoAP Via Option Extension
                   draft-fan-core-coap-via-option-00

Abstract

   This document adds an extension option to the Constrained Application
   Protocol (CoAP): Via. The Via option is used to indicate the proxies
   between the coap client and the coap server.

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 June 21, 2013.

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





Fan                       Expires June 21, 2013                 [Page 1]

Internet-Draft          CoAP Via Option Extension          December 2012


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Motivation . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Option Definition  . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Example  . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  7
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 10
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11





































Fan                       Expires June 21, 2013                 [Page 2]

Internet-Draft          CoAP Via Option Extension          December 2012


1.  Introduction

   This document adds a new option to the Constrained Application
   Protocol : Via. The via option is used to indicate the proxies
   between the coap client and the coap server.

1.1.  Motivation

   A proxy is a CoAP endpoint that can be tasked by CoAP clients to
   perform requests on their behalf.  Proxy is helpful to reduce
   response time, network bandwidth consumption and energy consumption.

   There may be zero or more proxies between two endpoints, when an
   endpoint receives a coap message, it needs to know the proxies which
   have forwarded this message.  So this document is intended to define
   a new option which can be used to track the message and avoid forward
   loops.

1.2.  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].

   The terms Proxy, Coap Client and Coap Server as specified in the
   terminology section of [I-D.ietf-core-coap].

























Fan                       Expires June 21, 2013                 [Page 3]

Internet-Draft          CoAP Via Option Extension          December 2012


2.  Option Definition

       +--------+---+---+---+---+------+--------+--------+--------+
       |   No   | C | U | N | R | Name |Format  | Length | Default|
       +--------+---+---+---+---+------+--------+--------+--------+
       |  TBD   |   |   |   | X |  via | string | 1-255  | (none) |
       +--------+---+---+---+---+------+--------+--------+--------+

   The Via option is "elective" and "safe" . when a proxy doesn't
   recognise this option, it can ignore this option.

   The value of this option is a string which MUST be globally unique,
   e.g., IP address, domain name or any other identifiers of the proxy
   endpoint.

   The via option can occur more than once.

   When a proxy endpoint receives a coap message with via options, the
   proxy MUST first check the via options value, if the via option
   configured in the proxy endpoint is equal to one of the via options
   in the coap message, there occurs a forward loop , the proxy MUST
   drop this coap message.

   When a proxy endpoint forwards a coap message, it can add a new via
   option into the message at the end of the existing via options.

   The via option can be used in the request message and/or the response
   messages.  It is recommended that the proxy can be configured to add
   this option into request and/or response message.






















Fan                       Expires June 21, 2013                 [Page 4]

Internet-Draft          CoAP Via Option Extension          December 2012


3.  Example

   In the example below, there are two proxies between client and
   server: proxy1 and proxy2 ,the via option are configured with value
   "proxy1@test.com" and "proxy2@test.com".


         Client              Proxy1              Proxy2         Server
         |                   |                   |                   |
         | no via  option    |                   |                   |
         +------------------>|                   |                   |
         | REQUEST(1)        |                   |                   |
         |                   |via:proxy1@test.com|                   |
         |                   +------------------>|                   |
         |                   |  REQUEST(2)       |                   |
         |                   |                   |via:proxy1@test.com|
         |                   |                   |via:proxy2@test.com|
         |                   |                   +------------------>|
         |                   |                   |    REQUEST(3)     |
         |                   |                   |                   |
         |                   |                   |   no via option   |
         |                   |                   |<------------------+
         |                   |                   |     RESPONSE(4)   |
         |                   |via:proxy2@test.com|                   |
         |                   |<------------------+                   |
         |                   |      RESPONSE(5)  |                   |
         |via:proxy2@test.com|                   |                   |
         |via:proxy1@test.com|                   |                   |
         |<------------------+                   |                   |
         |   RESPONSE(6)     |                   |                   |
         |                   |                   |                   |


   (1)Client sends a request message with no via option;

   (2)Proxy1 adds a via option into the request message, the option
   value is "proxy1@test.com";

   (3)Proxy2 adds a via option into the request message following
   proxy1, the value is "proxy2@test.com",then the request message has
   two via options.

   (4)Server responses this request with no via option;

   (5)Proxy2 adds a via option into the response message, the option
   value is "proxy2@test.com";

   (6)Proxy1 add a via option into the response message following



Fan                       Expires June 21, 2013                 [Page 5]

Internet-Draft          CoAP Via Option Extension          December 2012


   proxy2, the value is "proxy1@test.com",then the response message has
   two via options.

















































Fan                       Expires June 21, 2013                 [Page 6]

Internet-Draft          CoAP Via Option Extension          December 2012


4.  IANA Considerations

   The IANA is requested to add the following option number entries:

           +--------+----------+------------ +
           | Number | Name     | Reference   |
           +--------+----------+-------------+
           |  TBD   | Via      | RFCXXXX     |
           +--------+--------- +-------------+










































Fan                       Expires June 21, 2013                 [Page 7]

Internet-Draft          CoAP Via Option Extension          December 2012


5.  Security Considerations

   However, once there were too many proxies between client and server,
   and all the proxies are enabled to add this via option, so that it
   will make the length of the message so long , and correspondingly
   increase energy consumption or network consumption.













































Fan                       Expires June 21, 2013                 [Page 8]

Internet-Draft          CoAP Via Option Extension          December 2012


6.  Acknowledgements

   TBD
















































Fan                       Expires June 21, 2013                 [Page 9]

Internet-Draft          CoAP Via Option Extension          December 2012


7.  References

7.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-12 (work in progress), October 2012.

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

7.2.  Informative References

   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              June 2002.

   [I-D.shelby-core-coap-req]
              Shelby, Z., Stuber, M., Sturek, D., Frank, B., and R.
              Kelsey, "CoAP Requirements and Features",
              draft-shelby-core-coap-req-02 (work in progress),
              October 2010.























Fan                       Expires June 21, 2013                [Page 10]

Internet-Draft          CoAP Via Option Extension          December 2012


Author's Address

   Xianyou Fan
   ZTE Corporation
   Xing Guang Rd, Yu Bei Districtt
   Chongqing, Chongqing  401121
   P. R. China

   Phone: +86-23-67887556
   Email: fan.xianyou@zte.com.cn









































Fan                       Expires June 21, 2013                [Page 11]