Internet DRAFT - draft-sunde-netinf-protocol-bluetooth
draft-sunde-netinf-protocol-bluetooth
Network Working Group L. Sunde
Internet-Draft Uppsala University
Intended status: Standards Track July 03, 2013
Expires: January 04, 2014
The NetInf Bluetooth Convergence Layer
draft-sunde-netinf-protocol-bluetooth-00
Abstract
This document defines a Network of Information (NetInf) convergence
layer intended to be used over some Bluetooth protocol providing
reliable transmission. A convergence layer handles the transport of
NetInf requests and responses. In this convergence layer the common
NetInf messages are defined using JavaScript Object Notation (JSON)
and Named Data Object (NDO) octet parts, both using length prefixes.
While the convergence layer is intended to be used over Bluetooth,
any underlying protocol providing reliable transmission could
potentially be used.
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 January 04, 2014.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
Sunde Expires January 04, 2014 [Page 1]
Internet-Draft NetInf Bluetooth CL July 2013
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Bluetooth Convergence Layer Specification . . . . . . . . . . 2
2.1. PUBLISH . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. PUBLISH-RESP . . . . . . . . . . . . . . . . . . . . . . 4
2.3. GET . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.4. GET-RESP . . . . . . . . . . . . . . . . . . . . . . . . 5
2.5. SEARCH . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.6. SEARCH-RESP . . . . . . . . . . . . . . . . . . . . . . . 6
3. Security Considerations . . . . . . . . . . . . . . . . . . . 7
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Normative References . . . . . . . . . . . . . . . . . . 7
5.2. Informative References . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
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 RFC 2119 [RFC2119].
2. Bluetooth Convergence Layer Specification
This section specifies a NetInf Convergence Layer
[I-D.kutscher-icnrg-netinf-proto] intended to be used over Bluetooth.
The protocol does not provide reliable transmission. This is assumed
to be provided by the underlying Bluetooth protocol, e.g. radio
frequency communication (RFCOMM). The Bluetooth convergence layer
(BCL) could potentially also be used on top of non-Bluetooth
protocols providing the required features (e.g. TCP).
The BCL does not provide any means of discovering or selecting which
devices to route to. This problem must be handled by the
implementation. A Bluetooth connection needs to be established
between the sender and the receiver. This connection MAY use RFCOMM
[RFCOMM]. It MAY be established using the service discovery protocol
[SDAP] with the Universally Unique IDentifier [RFC4122]
111a8500-6ae2-11e2-bcfd-0800200c9a66.
Sunde Expires January 04, 2014 [Page 2]
Internet-Draft NetInf Bluetooth CL July 2013
The response to a request SHOULD be sent back using the same
connection (if two-way communication is supported) but an
implementation MUST NOT assume that this always is the case.
The protocol is built around sending UTF-8 [RFC3629] encoded JSON and
NDO octets through a stream providing reliable transmission. All
JSON and octet parts MUST be prefixed with their length in bytes.
The length prefix MUST be a 32-bit signed integer encoded in two's
complement using big endian network byte order.
The ni URI scheme [RFC6920] MUST be supported. Other URI schemes MAY
be supported.
The following names are defined for JSON name/value pairs:
------------------------------------------------------------------
Name | Value | Comments
------------------------------------------------------------------
type | string | Message type. MUST be "publish",
| | "publish-response", "get", "get-response",
| | "search" or "search-response".
------------------------------------------------------------------
msgid | string | Message identifier.
------------------------------------------------------------------
uri | string | NDO URI.
------------------------------------------------------------------
hoplimit | number | Number of times to forward this message.
| | Assumed to be 0 if not present.
------------------------------------------------------------------
locators | [string] | Locators to the NDO.
------------------------------------------------------------------
ext | object | Metadata and future extensions. Metadata
| | MUST be an object under the "meta" key if
| | present. E.g. "ext":{"meta":{...}}
------------------------------------------------------------------
octets | true/false | Flag indicating if this JSON is directly
| | followed by the NDO octets (including the
| | length prefix). Assumed to be false if
| | not present.
------------------------------------------------------------------
status | number | Code indicating the status of a response.
------------------------------------------------------------------
tokens | [string] | Tokens used in a SEARCH. MUST contain at
| | least one token.
------------------------------------------------------------------
results | [object] | The results of a search. See Section 2.6.
------------------------------------------------------------------
Sunde Expires January 04, 2014 [Page 3]
Internet-Draft NetInf Bluetooth CL July 2013
Figure 1: Bluetooth CL JSON
2.1. PUBLISH
A PUBLISH MUST start with a JSON part (including the associated
length prefix). The JSON part MUST include the following name/value
pairs:
o type
o msgid
o uri
Where "type" MUST be "publish" and "uri" MUST be the URI of the NDO
being published.
The JSON part MAY also include:
o hoplimit
o locators
o ext
o octets
If "octets" is present and true, the JSON part MUST be followed by
the octets of the NDO (including the associated length prefix). If
"octets" is not present or false, the JSON part MUST NOT be followed
by the octets.
2.2. PUBLISH-RESP
A PUBLISH-RESP MUST consist of a single JSON part. The JSON part
MUST include the following name/value pairs:
o type
o status
o msgid
Where "type" MUST be "publish-response".
2.3. GET
Sunde Expires January 04, 2014 [Page 4]
Internet-Draft NetInf Bluetooth CL July 2013
A GET MUST consist of a single JSON part. The JSON part MUST include
the following name/value pairs:
o type
o msgid
o uri
Where "type" MUST be "get".
The JSON part MAY also include:
o hoplimit
2.4. GET-RESP
A GET-RESP MUST start with a JSON part. The JSON part MUST include
the following name/value pairs:
o type
o status
o msgid
o uri
Where "type" MUST be "get-response" and "uri" MUST be the URI
requested NDO.
The JSON part MAY also include:
o locators
o octets
If "octets" is present and true, the JSON part MUST be followed by
the octets of the requested NDO. If "octets" is not present or
false, the JSON part MUST NOT be followed by the octets.
2.5. SEARCH
A SEARCH MUST consist of a single JSON part. The JSON part MUST
include the following name/value pairs:
o type
Sunde Expires January 04, 2014 [Page 5]
Internet-Draft NetInf Bluetooth CL July 2013
o msgid
o tokens
Where "type" MUST be "search".
The JSON part MAY also include:
o hoplimit
2.6. SEARCH-RESP
A SEARCH-RESP MUST consist of a single JSON part. The JSON part MUST
include the following name/value pairs:
o type
o status
o msgid
o results
Where "type" MUST be "search-response".
Each object in the "results" array represents an NDO considered to
match the tokens included in the corresponding SEARCH. If no
matching NDOs were found "results" might be empty. The following
name/value pairs are defined for the search result objects:
------------------------------------------------------------------
Name | Value | Comments
------------------------------------------------------------------
ni | string | The ni URI of the matching NDO.
| | MUST be included.
------------------------------------------------------------------
metadata | object | Metadata belonging to the matching NDO.
| | MAY be included.
------------------------------------------------------------------
Figure 2: Search result JSON
Sunde Expires January 04, 2014 [Page 6]
Internet-Draft NetInf Bluetooth CL July 2013
3. Security Considerations
As mentioned in [I-D.kutscher-icnrg-netinf-proto] requesters SHOULD
attempt to limit the amount of personally identifying information for
privacy reasons. Care should be taken when generating SEARCH tokens
and when responding to a SEARCH.
Validation of name-data integrity is important. Consider a scenario
where the connected Bluetooth devices are a number of smart phones
that happen to be in close proximity. The other devices can not be
trusted to send the correct data and might even try to send malicious
data.
In the smart phone case battery life is also something to take into
consideration. By requesting data over and over again a requester
could intentionally drain the battery of the responder.
4. IANA Considerations
This document has no actions for IANA.
5. References
5.1. Normative References
[I-D.kutscher-icnrg-netinf-proto]
Kutscher, D., Farrell, S., and E. Davies, "The NetInf
Protocol", draft-kutscher-icnrg-netinf-proto-01 (work in
progress), February 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B.,
Keranen, A., and P. Hallam-Baker, "Naming Things with
Hashes", RFC 6920, April 2013.
5.2. Informative References
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
Unique IDentifier (UUID) URN Namespace", RFC 4122, July
2005.
[RFCOMM] Bluetooth Special Interest Group , "RFCOMM with TS 07.10
Serial Port Emulation", November 2012.
Sunde Expires January 04, 2014 [Page 7]
Internet-Draft NetInf Bluetooth CL July 2013
[SDAP] Bluetooth Special Interest Group , "Service Discovery
Application Profile", February 2001.
Author's Address
Linus Sunde
Uppsala University
Uppsala
Sweden
Email: Linus.Sunde.9273@student.uu.se
Sunde Expires January 04, 2014 [Page 8]
