Source: http://lowpan.ru/
Timestamp: 2017-10-22 07:54:57
Document Index: 168997483

Matched Legal Cases: ['art 2', 'art 2', 'art 2', 'art 2', 'art 3', 'art 3', 'art 4', 'art 5', 'art 5', 'art 5', 'art 5', 'ART 3', 'art 5', 'ART 2', 'art"\n46', 'art 1']

Home - LoWPAN
The Internet of Thinks Messaging Protocol is open Internet protocol for inter thinks messaging. ITMP consist of three important components: discovering, remote procedure calling, messaging (pub-sub), in comparing with competitors ITMP is compact, simple, extensible, robust protocol.
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this specification are to be interpreted as described in IETF
ITMP defines a wire level protocol. ITMP does not define a wire-level distinction between "clients" and "servers", the protocol is symmetric. It is expected and encouraged that implementations of ITMP will have different capabilities.
A conformant implementation MAY perform protocol negotiation, and then parse, process, and produce frames in accordance with the format and semantics.
Part 2 defines the peer-to-peer transport protocol which operates over TCP and UDP or Serial Line. Every conformant implementation of TMP over TCP MUST implement Part 2. Part 2 admits behaviors that might not be appropriate for every implementation. For example a “client library” might not allow for its communication partner to spontaneously attempt to initiate a connection and request messages. Where an implementation does not allow for a behavior the implementation MUST respond according to the rules defined within Part 2 of the specification.
Part 3 of this document defines the ITMP Messaging Layer. Every conformant implementation which processes messages MUST implement this part of the specification. Some implementations might not process messages (for example, an implementation acting as a “router” which looks only at the routing information carried by the ITMP Transport layer). Such implementations do not actively implement Part 3, but MUST NOT act in ways which violate the rules of this part of the specification. The Messaging layer admits behaviors that might not be appropriate for all implementations (and within an implementation all behaviors might not be available for all configurations). Where a behavior is not admitted, the implementation MUST respond according to the rules defined within this specification.
It is RECOMMENDED that implementations designed to act as messaging intermediaries support the ability to act as a transactional resource. It is RECOMMENDED that implementations or re-usable libraries provide Application Programming Interfaces to enable them to act as transactional controllers. Where a behavior is not admitted, the rules defined in part 4 regarding responses to non-admitted behaviors MUST be followed.
Part 5 defines Security Layers to provide an authenticated and/or encrypted transport. Implementations SHOULD allow the configuration of appropriate levels of security for the domain in which they are to be deployed. Conformant implementations acting in the TCP server role are strongly RECOMMENDED to implement Part 5: section 5.2 (or Part 5: 5.2.1 Alternative Establishment). Implementations acting in the TCP server role are strongly RECOMMENDED to implement Part 5: section 5.3 and to support commonly used SASL mechanisms. In particular such implementations SHOULD support the PLAIN [RFC4616] and SCRAM-SHA1 [RFC5802] mechanisms. Conformant implementations acting in the TCP client role SHOULD be capable of being configured to connect to an implementation in the TCP server role that is following the recommendations above.
The ITMP based mostly on JSON format and CBOR encoding and type system followed by those definition for interoperable data representation. ITMP values can be annotated with CBOR extension.
The ITMP type system defines a standard set of primitive types for representing both common scalar values and common collections. The scalar types include booleans, integer numbers, floating point numbers, strings and binary data. The collection types include arrays(polymorphic), and maps.
An ITMP uses JSON strings or CBOR binary encoded messages.
An ITMP network consists of nodes connected via links. Nodes act as agents and can realize one or more roles. Actor is a node that implements RPC functions. Publisher is a node that produces events. Subscriber is a node that can receive events messages and react for its in some manner. Broker is a node that act as Subscriber for all Connected Publishers act as Publisher for Subscribers and connect one another.
2.1.2 Protocol Frames
The protocol consists of messages of frames all of them has same structure.
[<message type>,<id>,<name>,<parameters>,<options>]
where <message type> - integer number from 0 - 23 described int table 2.1
<id> - integer number initially chosen randomly and then increments any time new message sending. It prevent of messages doubles and allow correlate answer to question.
<name> - string denotes procedure to call or event name to emit or subscribe
<parameters> - array of function or event parameters or map of named values instead of position dependent values stored in array, can be committed if empty
<options> - map of named values extend parameters of calling method, can be committed if empty
0 [CONNECT,0,"ITMP10"] opened connection and make version negotiation
1 [CONNECTED,0,"ITMP10"] confirm connection and start communication
2 [ABORT,0,"",[503,"time out"]] terminate connection
3 [DISCONNECT,0,"",[503,"time out"]]
4 [GETDESCR,id,"name"] 6 - get description
5 [DESCR,id,"name",["name&int"]] 7 - description response
6 [DESCRERR,id,"name",[404,"not found"]] 8 - get - description error
8 [CALL,id,"name",[1,2]] 9 - call
9 [CALLCANCEL,id,"name"] 10 call cancel
10 [CALLRESP,id,"name",["ok","result"]] 11 - call response
12 [PROGRESS,id,"name",[2,"almost done"]] 12 call in progress
13 [CALLERR,id,"name",[503,"time out"]] 13 - call error
16 [EVENT,id,"alarm",[32,"12:33"]] 14 - event
17 [EVENT_WITH_ACK,id,"alarm",[32,"12:33"]] 15 - event with acknowledge awaiting
18 [EVENTACK,id,"alarm"] 15 - event acknowledged
19 [EVENTNAK,id,"alarm",[500,"server busy"]] 16 - event not acknowledged
20 [SUBSCRIBE,id,"alarm"] 17 - subscribe
21 [UNSUBSCRIB,id,"alarm"] 20 - unsibscribe
22 [CONFIRMED,id,"alarm",[503,"no memory"]] 18 - subscription confirmed19 - subscription not confirmed
23 [NOT CONFIRMED,id,"*",[503,"no memory"]]
23 [KEEP_ALIVE,id,""] 23 - keep alive
Prior to sending any frames on a connection, each peer MAY start by sending a protocol header that indicates the protocol version used on the connection. In total this is an CONNECT message:
JSON: [CONNECT, 0, "ITMP10"]
CBOR: 83 00 00 66 49 54 4d 50 31 30 // 10 bytes
The ITMP peer which acted in the role of the TCP client (i.e. the peer that actively opened the connection) MUST immediately send its outgoing protocol header on establishment of the TCP connection. The ITMP peer which acted in the role of the TCP server MAY elect to wait until receiving the incoming protocol header before sending its own outgoing protocol header. This permits a multi protocol server implementation to choose the correct protocol version to fit each client.
Two ITMP peers agree on a protocol version as follows (where the words “client” and “server” refer to the roles being played by the peers at the TCP connection level):
 When the client opens a new socket connection to a server, it MUST send a protocol header with the client’s preferred protocol version.
 If the requested protocol version is supported, the server MUST send its own protocol header with the requested version to the socket, and then proceed according to the protocol definition.
 If the requested protocol version is not supported, the server MUST send a protocol header with a supported protocol version and then close the socket.
 When choosing a protocol version to respond with, the server SHOULD choose the highest supported version that is less than or equal to the requested version. If no such version exists, the server SHOULD
respond with the highest supported version.
PART 3. Messaging
3.1.1. CONNECT
Sent by a Client to initiate opening of a ITMP session to a Router attaching to a Realm.
[CONNECT, Realm|uri, Options|dict]
3.1.2. CONNECTED
Sent by a Server to accept a Client. The ITMP session is now open.
[CONNECTED, Session|id, Options|dict]
3.1.3. ABORT
Sent by a Peer*to abort the opening of a ITMP session. No response is expected.
[ABORT, Reason|uri, Options|dict]
3.1.4. DISCONNECT
Sent by a Peer to close a previously opened ITMP session. Must be echo'ed by the receiving Peer.
[DISCONNECT, Reason|uri, Options|dict]
6.4.1.5. ERROR
Error reply sent by a Peer as an error response to different kinds of
[ERROR, REQUEST.Type|int, REQUEST.Request|id, Details|dict,
Error|uri]
Error|uri, Arguments|list]
Error|uri, Arguments|list, ArgumentsKw|dict]
Note that if the server only supports a single protocol version, it is consistent with the above rules for the server to send its protocol header prior to receiving anything from the client and to subsequently close the socket if the client’s protocol header does not match the server’s.
3.2.1. GETDESCR
Sent by a Client to get information about method, event or whole node.
[GETDESCR, id|int, name|uri, Options|dict]
3.2.2. DESCR
Sent by a Node to inform about event or function.
[DESCR, id|int, name|uri, [description|string] Options|dict]
<field description> ::= <name><description><signature>
<name> ::= string
<signature> ::= <interface> | <func> | <event> | <container>
<interface> ::= ’:’ [ <interface name> [ , <interface name> ] ]
<interface name> ::= string
<container> ::= ’*’ [ <interface name> [ , <interface name> ] ]
<func> ::= ’&’ <return type list> [ ‘(‘ <argument type list> ’)’ ]
<event> ::= ’!’ <type list>
<return type list> ::= <type list>
<argument type list> ::= <type list>
<type list> ::= [ <type> [ , <type> ] ]
<type> ::= <simple type> | '['<type list>']' | '{' <prop name> [ '?' ] : <type> [ , <prop name> : <type> ] '}'
<simple type> ::= <type char> [<description>]
<description>::='’' [<name>] [<version>] [<UniqueId>] [<units>] [<variants>] [<manufacturer>] '’'
<version>::=’%’ string
<UniqueId>::=’#’ string
<units> ::= '$' string
<variants> ::= '<' <value> [ , <value> ] '>'
<manufacturer> ::= '@' string
<type char> ::= i | s | b | f | B | N | Q | I | U | X | T | F | D | S
simple type JSON and CBOR encoded
s UTF-8 string
fixed types JSON BASE64 string or CBOR byte array encoded as sequence (for small controllers without complex encoders)
B 8-bit unsigned integer (byte)
Q 16-bit unsigned integer
I 32-bit signed integer
U 32-bit unsigned integer
X 64-bit signed integer
T 64-bit unsigned integer
F single-precision floating point (IEEE 754)
D double-precision floating point (IEEE 754)
S UTF-8 string with length prefix
any sequence of primitive typed values encoded as byte array or base64 encoded string for json
3.4 Subscribe
3.4 Publish
Please note that the above examples use the literal notation defined in RFC 2234 [RFC2234] for non alphanumeric
The protocol id is not a part of the protocol version and thus the rule above regarding the highest supported
version does not apply. A client might request use of a protocol id that is unacceptable to a server - for example,
it might request a raw AMQP connection when the server is configured to require a TLS or SASL security layer
(See Part 5: section 5.1). In this case, the server MUST send a protocol header with an acceptable protocol id
(and version) and then close the socket. It MAY choose any protocol id.
Frames are divided into three distinct areas: a fixed width frame header, a variable width extended header, and a
variable width frame body.
amqp-core-complete-v1.0-os
Standards Track Work Product Copyright
c OASIS Open 2012. All Rights Reserved.
PART 2. TRANSPORT 2.3 Framing
8 bytes *variable* *variable*
frame header The frame header is a fixed size (8 byte) structure that precedes each frame. The frame
header includes mandatory information necessary to parse the rest of the frame including
size and type information.
extended header The extended header is a variable width area preceding the frame body. This is an extension
point defined for future expansion. The treatment of this area depends on the frame type.
frame body The frame body is a variable width sequence of bytes the format of which depends on the
Основная функция протокола обмен сообщениями для реализации передачи уведомлений, а также удаленного вызова функций.
Небольшие накладные расходы на передачу сообщений позволяют реализовать протокол на небольших контроллерах
1.1 Формат сообщения
Сообщение представляет собой пакет состоящий из заголовка, опций, адреса и данных
[message_type,id,name,data,options]
message type one of
CHALLENGE: 4,
AUTHENTICATE: 5,
0 - connect
4 - disconnect
5 - disconnected
6 - get description
7 - description response
8 - get - description error
10 call cancel
11 - call response
12 call in progress
13 - call error
14 - event
15 - event acknowledged
16 - event not acknowledged
17 - subscribe
18 - subscription confirmed
19 - subscription not confirmed
20 - unsibscribe
21 - unsubscripted
22 - not unsubscripted
23 - keep alive
id is number (unsigned id) it should start from any value (random) and should increment every time (it can be used to control double sending and lost packets)
name is string name (could be integer value for simplest implementations) of calling function emitted event and so on
data is array or map of arguments for calling function return value for returning and so on, data can be omitted if there is no options in message
options is map of additional values specific for that method, options can be omitted if there is empty map
JSON encoding, then transport is string based it is variant
CBOR encoding, then transport is binary based
Hello world message encoding
[7,14756,"","Hello world"]
message "hello world" even without topic
84 - array of 4 items
07 - integer value - 7
19 39 a4 integer value 14756
60 - empty string
6B 48 65 6c 6c 6f 20 77 6f 72 6c 64 - string "Hello world"
call the method relay.on without parameters
[4,4365,"relay.on"]
83 - array of 3 items
04 - integer value - 4
19 11 0d integer value 4365
68 72 65 6c 61 79 2e 6f 6e - string "relay.on"
call e method
[5,4365,"relay.on"] or even [5,4365] // if function relay.on has no return value (void in c language)
[5,4365,"relay.on",true] or even [5,4365,null,true] // if function relay.on has boolean return value type
[6,4365,"relay.on",[4,"arguments omitted"]] or even [6,4365,null,[4,"arguments omitted"]] // if function relay.on can not be called because arguments should be passed
Заголовок занимает один байт
MTH - Method
00 = LCP (link control protocol)
01 = desc (announce when NON) empty url-get dev desc
10 = call (inform when NON)
11 = publ (NON or CON publication)
0 = NON non confirmable message
1 = CON confirmable request
2 = ACK normal response
3 = ERR error response
00 – no address present (point to point)
01 – Master to slave (slave address presented)
10 – slave to Master (slave address presented)
11 – desination and source address presented
0 = no message id or in options
1 = message id is 1 bytes length
2 = message id is 2 bytes length
3 = message id is 4 bytes length
Метод определяет сообщение и смысл следующих бит.
LCP – сообщение относится к протоколу управления соединением (смотри соответствующий раздел).
Call – (аналог GET в REST идеологии) сообщение ITMP обеспечивающее удаленный вызов процедуры подписку на событие или список членов для индексатора или объекта
Desc – сообщение ITMP обеспечивающее получение информации об указанном URL
Publ – сообщение ITMP обеспечивающее возможность сообщить об асинхронном событии (от клиента к получателю, указывается урл события)
NON – сообщение не требует подтверждения принимающей стороной
CON – сообщение требует подтверждения (или ответа с соответствующими данными)
ACK – сообщение ответ на CON сообщение - успех
ERR – сообщение ответ на CON сообщение - неуспех
длина идентификатора сообщения указана в заголовке
длина url может быть от 0 до 127 байт и указывается в одном байте
Данные в сообщении зависят от url для которого выполняется запрос и продолжаются до конца пакета.
1.2.1 Сообщение Call
В сообщении указывается URL требуемого действия, в payload параметры, для контроля повторной отправки и сопоставления запроса и ответа каждое сообщение помечается MessageID который увеличивается после отправки каждого сообщения.
Если при запросе биты T установлены в NON не предполагает ответ, если в запросе биты T установлены в CON – запрос подразумевает получение ответа (ACK или ERR) с тем- же url и MessageID что и в запросе
при ответе устанавливаются биты T равными ACK или ERR в зависимости от успешности выполнения запрашиваемого действия
1.2.2 Сообщение Desc (Description)
В сообщении указывается URL для которого требуется получить описание, payload должен быть пустым, для контроля повторной отправки и сопоставления запроса и ответа каждое сообщение помечается MessageID который увеличивается после отправки каждого сообщения.
Биты T установлены в CON – запрос подразумевает получение ответа (ACK или ERR) с тем- же url и MessageID что и в запросе
1.2.3 Сообщение Publ (Publish)
В сообщении указывается URL возникновения события, payload содержит информацию о событии, для контроля повторной отправки и сопоставления запроса и ответа каждое сообщение помечается MessageID который увеличивается после отправки каждого сообщения.
Если необходимо получить подтверждение сообщения T устанавливается в CON иначе NON. при необходимости получить подверждение ожидается ответ (ACK или ERR) с тем- же url и MessageID что и в запросе. оба ответа говорят о корректном получении сообщения и повторные отправки прекращаются.
1.2.4 Сообщения об ошибках
сообщение об ошибке содержит первым байтом код ошибки далее необязательное текстовое описание ошибки
+------+------------------------------+---------+
| Code | Description | encoded |
| 1.02 | Processing | 12 |
| 4.00 | Bad Request | 40 |
| 4.01 | Unauthorized | 41 |
| 4.02 | Bad Option | 42 |
| 4.03 | Forbidden | 43 |
| 4.04 | Not Found | 44 |
| 4.05 | Method Not Allowed | 45 |
| 4.06 | Not Acceptable | 46 |
| 4.12 | Precondition Failed | 4B |
| 4.13 | Request Entity Too Large | 4C |
| 4.15 | Unsupported Content-Format | 4F |
| 5.00 | Internal Server Error | 50 |
| 5.01 | Not Implemented | 51 |
| 5.02 | Bad Gateway | 52 |
| 5.03 | Service Unavailable | 53 |
| 5.04 | Gateway Timeout | 54 |
| 5.05 | Proxying Not Supported | 55 |
| 5.06 | call exception | 56 |
Если сервер не может немедленно ответить на запрос клиента (особенно в ситуации когда мастер-клиент управляет порядком запросов по шине к нескольким серверам) он может ответить сообщением Processing (12), тогда клиент должен через указанную задержку послать повторный запрос с тем же ID и получить задержанный ответ сервера.
1.3 Схема описания данных
при выполнении запроса get возвращается описание поля без указания имени (имя есть в поле url), при запросе call для получения списка полей отдается массив (вначале указывается количество полей, а затем сами поля) строк с описанием полей объекта.
<field description>::=<name><description><signature>
<name>::=string
<signature>::=<interface>|<func>|<event>|<container>
<interface>::=’:’[<interface name>[,<interface name>]]
<container>::=’*’[<interface name>[,<interface name>]]
<func>::=’&’<ret type list>[‘(‘<argument type list>’)’]
<event>::=’!’<type list>
<interface name>::=string
<ret type list>::=<type list>
<argument type list>::=<type list>
<type list>::=[<type>[,<type>]]
<type>::=<simple type>|a<simple type>
<simple type>::=<type char>[<description>]
<description>::='{'[<name>][<version>][<UniqueId>] [<units>][<variants>][<manufacturer>]'}'
<version>::=’%’string
<UniqueId>::=’#’string
<units>::='$'string
<variants>::='['<value>[,<value>]']'
<manufacturer>::='@'string
<type char>::=b|n|q|i|u|x|t|N|Q|I|U|X|T|f|d|s
N 16-bit packed signed integer
Q 16-bit packed unsigned integer
I 32-bit packed signed integer
U 32-bit packed unsigned integer
X 64-bit packed signed integer
T 64-bit packed unsigned integer
NSC duino{#1.0}:motor
addr&b
setpwm&b{status}(n{value[0..1024]})
DESCR "" responce
F01.100:apollo,upd{#1.0}
CALL "" responce
upd&(b)
frd&(i)
pwr&(b)
stat&b{status byte}
dev*fgdev
DESCR "dev" response
dev{extrenal bus devices}*fgdev
CALL "dev" response
num&b{devs number}
add&(s{element name})
del&(s{element name})
list&as{array of item names}
*fgdev
CALL "dev/*" response
act{execute action}&b{status byte}(b{action to execute[0=none,1=reset]})
DESCR "dev/num" response
{number of external devices connected}&b{devices number}
DESCR "dev/5" response
Интерфейс содержит сигнатуры методов, свойств, событий
функция это необходимое действие со списком параметров и списков возвращаемых значений описывается как
Свойство это объединение двух методов – чтения и записи, причем типы для чтения и записи совпадают, если в запросе присутствует поле данных то это операция записи а затем чтения в противном случае это операция чтения (когда поле данных в запросе пустое), при необходимости реализовать свойство, доступное только для записи, нужно определить функцию без возвращаемого параметра
Событие это извещение клиента об изменении состояния агента, событие сопровождается сопутствующими данными
Коллекция, именованный набор элементов имеющих общие интерфейсы
коллекция может поддерживать получение количества, списка элементов, а также операции по добавлению/удалению элементов. Эти операции должны быть сообщены по запросу Call для коллекции ели получение списка элементов в запросе CALL для коллекции не реализовано, последним элементом перечня методов должен быть метод * без имени подразумевающий что в коллекции есть элементы но их список недоступен (даже если на момент запроса количество элементов 0)
1.4 Примеры сообщений
Each device describing as object consist of variables, functions and events. Each variable, function and event has a type (for functions input and output, for events output), name, id, and tagged annotations
Get Device object Description
51 get description
00 message id=0
00 get device description (no resource name)
encoded answer (32 bytes)
61 descripttion answer
00 description of device empty uri
1C description length
4d 4f 54 38 32 33 MOT823.112rack:mot{#1.0@NSC}
2e 31 31 32 72 61
63 6b 3a 6d 6f 74
7b 23 31 2e 30 40
4e 53 43 7d
Get field list
91 call emty url command
01 message id=1
00 root with empty uri
08 02 6c 57 01 57 url list = ["lW","W","3","4",
01 33 01 34 01 35 "5","6","7","info"]
01 36 01 37 04 69
6e 66 6f
Get field description
91 get description command
02 message id=2
02 6c 57 uri = "lW"
answer encoded
A1 get description answer
26 62 7b 6c 65 76 “&b{level of Water$%[0..100]}”
65 6c 20 6f 66 20 function return one byte
57 61 74 65 72 24 that means water level in
25 5b 30 2e 2e 31 percents (from 0 to 100)
30 30 5d 7d
Get field description (4 bytes)
03 message id=3
01 57 uri = "W"
answer encoded (40 bytes)
A1 get descripttion answer
1d description length
7b 73 74 61 72 74 “{start watering}&
20 77 61 74 65 72 (b{time$ms})”
69 6e 67 7d 26 28
62 7b 74 69 6d 65
24 6d 73 7d 29
possible error answer encoded
B1 get descripttion err answer
44 url not found
D2 publish CON
00 00 message id=0 (two bytes)
08 31 32 2f 73 74
61 72 74 URL: "12/start"
46 7b event data
E2 publish ACK
Several routing protocol have been proposed by the 6LoWPAN community such as LOAD,[8] DYMO-LOW,[9] HI-LOW.[10] However, only two routing protocols are currently legitimate for large-scale deployments: LOADng [11] standardized by the ITU [4] under the recommendation ITU-T G.9903 and RPL [12] standardized by the IETF ROLL working group.[13]
In 6LoWPAN: The Embedded Internet (Wiley, 2009), Shelby and Bormann redefine the 6LoWPAN acronym as "IPv6 over lowpower wireless area networks," arguing that "Personal" is no longer relevant to the technology.
http://datatracker.ietf.org/wg/6lowpan/
Mulligan, Geoff, "The 6LoWPAN architecture", EmNets '07: Proceedings of the 4th workshop on Embedded networked sensors, ACM, 2007
Zach Shelby and Carsten Bormann, "6LoWPAN: The wireless embedded Internet - Part 1: Why 6LoWPAN?" EE Times, May 23, 2011
"Thread Wireless Networking Protocol Now Available". threadgroup.org. Thread Group. Retrieved 25 October 2015.
Higginbotham, Stacey. "This week's podcast unravels the secrets of Thread and HomeKit". gigaom.com. gigaom. Retrieved 30 January 2015.
Sullivan, Mark. "Nest, Samsung, ARM and others launch 'Thread' home automation network protocol". http://venturebeat.com. venture beat. Retrieved 30 January 2015.
http://tools.ietf.org/html/draft-daniel-6lowpan-security-analysis-05