Politecnico di Milano Advanced Network Technologies Laboratory. Application Layer Protocols for the IoT

Size: px

Start display at page:

Download "Politecnico di Milano Advanced Network Technologies Laboratory. Application Layer Protocols for the IoT"

Kristin Phelps
6 years ago
Views:

1 Politecnico di Milano Advanced Network Technologies Laboratory Application Layer Protocols for the IoT 1

2 Politecnico di Milano Advanced Network Technologies Laboratory COnstrained Application Protocol (COAP) 2

3 Background o GOAL: to enable web-based services in constrained wireless networks n 8 bit micro-controllers n limited memory n low-power networks o Problem: WEB solution are hardly applicable o Solution: re-design web-based services for constrained networks -> COAP 3

4 How Does the Web Work? o Resources in the Web are: n managed by servers n identified by URIs n accessed synchronously by clients through request/response paradigms o In a word, Representational State Transfer (REST) 4

5 URL Resolution 5

6 The CoAP Architecture 6

7 CoAP At a Glance o Embedded web transfer protocol (coap://) o Asynchronous transaction model o UDP binding with reliability and multicast support o GET, POST, PUT, DELETE methods o URI support o 4 byte header o Subset of MIME types and HTTP response codes o Built-in discovery o Optional observation and block transfer 7

8 COAP Messaging Basics o o Transport: n (mainly) UDP binding Message Exchange between Endpoints n n n n Messages with 4 bytes header (shared by request and responses) containing a message ID (16 bits) Reliable exchange through Confirmable Messages which must be acknowledged (through ACK or Reset Messages). Simple Stop-and-Wait retransmission with exponential backoff. Unreliable exchange through Non-Confirmable Message Duplicate detection for both confirmable and non-confirmable messages (through message ID) 8

9 COAP Messaging Message ID 9

10 COAP Message Semantics o REST Request/Response piggybacked on CoAP Messages o Method, Response Code and Options (URI, content-type etc.) 10

11 COAP Request/Response Examples Message ID Token 11

12 COAP: Separate Response 12

13 COAP: Non-confirmable Request 13

14 Message Header (4 bytes) Ver T TKL Code Message ID Token (if any, TKL bytes) Options (if any) Payload (if any) Ver - Version (1) T Message Type (Confirmable, Non-Confirmable, Acknowledgement, Reset) TKL- Token Length, if any, the number of Token bytes after this header Code - Request Method (1-10) or Response Code (40-255) Message ID 16-bit identifier for matching responses Token Optional response matching token 14

15 Option Format Option Delta Option Length 1 byte \ \ / Option Delta / 0-2 bytes \ (extended) \ \ \ / Option Length / 0-2 bytes \ (extended) \ \ \ / / \ \ / Option Value / 0 or more bytes \ \ / / \ \ Option Delta - Difference between this option type and the previous Length - Length of the option value Value - The value of Length bytes immediately follows Length 15

16 Base Specification Options No. C U N R Name Format Length Default x x If-Match opaque 0-8 (none) 3 x x - Uri-Host string (see below) 4 x ETag opaque 1-8 (none) 5 x If-None-Match empty 0 (none) 7 x x - Uri-Port uint 0-2 (see below) 8 x Location-Path string (none) 11 x x - x Uri-Path string (none) 12 Content-Format uint 0-2 (none) 14 x - Max-Age uint x x - x Uri-Query string (none) 16 Accept uint 0-2 (none) 20 x Location-Query string (none) 35 x x - Proxy-Uri string (none) 39 x x - Proxy-Scheme string (none) C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable 16

17 Dealing with Packet Loss o Stop and Wait approach o Repeat a request after a time-out in case ACK (or RST) is not coming back 17

18 Back-Off Details o Initial time-out set to: n Rand [ACK_TIMEOUT, ACK_TIMEOUT * ACK_RANDOM_FACTOR] ([2s, 3s]) o When time-out expires and the transmission counter is less than MAX_RETRANSMIT (4) n n n retransmit Increase transmission counter double the time-out value o The procedure is repeated until n n n n A ACK is received A RST message is received the transmission counter exceeds MAX_RETRANSMIT the total attempt duration exceeds MAX_TRANSMIT_WAIT (93s) 18

19 Proxyng and caching 19

20 COAP Observation o PROBLEM: n REST paradigm is often PULL type, that is, data is obtained by issuing an explicit request n Information/data in WSN is often periodic/triggered (e.g., get me a temperature sample every 2 seconds or get me a warning if temperature goes below 5 C) o SOLUTION: use Observation on COAP resources 20

21 Observation See draft-ietf-core-observe 21

22 COAP Block Transfer o PROBLEM: avoid segmentation in the lower layers (IPv6) o SOLUTION: COAP Block Transfer Mode n brings up fragmentation at the application layer 22

23 Block transfer o Block2 Option added to messages n nr=incremental block number within original data n m=more blocks flag n sz=block size 23

24 Discovery & Semantics o Resource Discovery n GOAL: Discovering the links hosted by CoAP (or HTTP) servers GET /.well-known/core?optional_query_string n Returns a link-header style format o URL, relation, type, interface, content-type etc. 24

25 CoRE Resource Discovery </dev/bat>;obs;if="";rt="ipso:dev-bat";ct="0", </dev/mdl>;if="";rt="ipso:dev-mdl";ct="0", </dev/mfg>;if="";rt="ipso:dev-mfg";ct="0, </pwr/0/rel>;obs;if="";rt="ipso:pwr-rel";ct="0", </pwr/0/w>;obs;if="";rt="ipso:pwr-w";ct="0", </sen/temp>;obs;if="";rt="ucum:cel";ct="0" 25

26 Getting Started with CoAP o o o Open source implementations: n Java CoAP Library Californium n C CoAP Library Erbium n n n n libcoap C Library jcoap Java Library OpenCoAP C Library TinyOS and Contiki include CoAP support Firefox has a CoAP plugin called Copper Wireshark has CoAP plugin 26

27 Politecnico di Milano Advanced Network Technologies Laboratory The Message Queuing Telemetry Transport () Invented in 1999 (IBM proprietary standard) Released in 2010 Official OASIS standard since 2014 Current version

28 in short is a Client Server publish/subscribe messaging transport protocol. o More features: n Simple to implement (especially at the sensor side) n QoS Support n Lightweight and bandwidth efficient n Data agnostic n Session awareness 28

29 Communication Pattern o Publish/Subscribe paradigm n Clients don t know each other n One-to-Many paradigm n Every client publishes & subscribes n PUSH information paradigm compared to PULL s one in COAP Subscribe:? C Laptop Publish: 30 C Publish: 30 C Subscribe:? C Senosr node Publish: 30 C Mobile device 29

30 Components o Publish/Subscribe paradigm n Clients don t know each other n One-to-Many paradigm n Every client publishes & subscribes n PUSH information paradigm compared to PULL s one in COAP Senosr node Client Publish: 30 C Publish: 30 C Broker Subscribe:? C Subscribe:? C Publish: 30 C Laptop Client Mobile device Client 30

31 Topics deib/antlab/room5/temperature Topic level Topic separator o Wildcards allowed only when subscribing deib/antlab/ + /temperature Single level Wildcard Plus sign can be used in multiple levels 31

32 Multi-level Wildcards deib/antlab/room5/ # Multi-level Wildcard (can be used only at the end) 32

33 Connections TCP o Each client opens one connection to the Broker o Push capabilities o Works even through firewalls IP 33

34 Open Connections Client CONNECT CONNACK Broker o CONNECT message fields: n clientid clientmatteo n cleansession true n username (opt) matteo n password (opt) 1234 n lastwilltopic (opt) matteo/temp n lastwillqos (opt) 1 n lastwillmessage (opt) something wrong n keepalive 30 34

35 Open Connections Client CONNECT CONNACK Broker o CONNACK message fields: n sessionpresent true n returncode 0-4 0: everything ok 1: unacceptable version 2: id rejected 3: server unavailable 4: bad username and pwd 5: unauthorized 35

36 Publishing Client Client PUBLISH Broker PUBLISH Client o PUBLISH message fields n packeid 2 n topicname matteo/temp n QoS 1 n retainflag false n Payload temperature:30 n dupflag false Client 36

37 QoS 0: at most once o Best effort transfer (same reliability provided by the underlying trasport protocol) Client PUBLISH QoS=0 Broker 37

38 QoS 1: at least once o The client stores the message and keeps retransmitting it until it is acknowledged by the broker (message can be received multiple times) PUBLISH QoS=1 Client PUBACK Broker o PUBACK message fields: n packetid 2 38

39 QoS 2: exactly once PUBLISH QoS=1 Client PUBREC PUBREL PUBCOMP Broker o o o o PUBREC, PUBREL, PUBCOMP message fields: n PacketId 2 PUBLISH broker: process the packet accordingly, send PUBREC message back, store locally packetid to avoid duplicate processing PUBREC client: discard the initial packet and send PUBREL PUBREL client: clear any current state and send PUBCOMP 39

40 Subscribing SUBSCRIBE Client SUBACK Broker o SUBSCRIBE message fields: n packetid 2 n QoS1 0 n Topic1 matteo/temp/1 n QoS2 1 n Topic2 kitchen/temp/2 n one QoS/topic couple for each subscription o SUBACK message fields: n packetid 2 n returncode 1 2 n returncode 2 0 one returncode for each topic in the subscription 40

41 Unsubscribing UNSUBSCRIBE Client UNSUBACK Broker o UNSUBSCRIBE message fields: n packetid 2 n Topic1 matteo/temp/1 n Topic2 kitchen/temp/2 n o UNSUBACK messagefields: n packetid 2 one returncode for each topic in the subscription 41

42 Persistent Sessions o o o In default operation mode when the client disconnects, all the client-related status at the broker is flushed (list of subscription, QoS pending messages, etc.) In persistent sessions both client and broker maintain a session: n Broker: n o o o o o Client o o Existence of a session, even if there are no subscriptions All subscriptions All messages in QoS 1 or 2 flow, which are not confirmed by the client All new QoS 1 or 2 messages, which the client missed while it was offlne All received QoS 2 messages, which are not yet confirmed to the client All messages in a QoS 1 or 2 flow, which are not confirmed by the broker All received QoS 2 messages, which are not yet confirmed to the broker That means even if the client is offline all the above will be stored by the broker and are available right after the client reconnects. 42

43 Retained Messges o Problem: publishing and subscribing are asynchronous processes o A client subscribing to a topic pattern may not get any message on that topic until some other client publishes on it o Retaind messages are PUBLISH messages with the retainedflag set to one o The broker stores locally the retained message and send it to any other client which subscribes to a topic pattern matching that of the retained message 43

44 Last Will Message o The Last Will and Testament (LWT) notifies other clients about an hard disconnec by a specific client o Each client can specify its last will message when connecting to a broker o The broker will store the message until it detects client hard disconnection o The broker sends the message to all subscribed clients on the specific topic o The stored LWT message will be discarded if a client disconnects gracefully by sending a DISCONNECT message. 44

45 LWT Set Up Client CONNECT CONNACK Broker o CONNECT message fields: n clientid clientmatteo n cleansession true n username (opt) matteo n password (opt) 1234 n lastwilltopic (opt) matteo/temp n lastwillqos (opt) 1 n lastwillmessage (opt) something wrong n keepalive 30 45

46 LWT Message is sent when.. o An I/O error or network failure is detected by the server. o The client fails to communicate within the Keep Alive time. o The client closes the network connection without sending a DISCONNECT packet first. o The server closes the network connection because of a protocol error. 46

47 Keepalive o It is responsability of the client to keep the connection active o Upon expiration of the keepalive, if no other interaction has happened with broker, the client pings the broker which pings it back Client PINGREQ PINGRESP Broker o PINGREQ and PINGRESP messages have null payload 47

48 -SN o Main differences n Extended architecture with Gateways and Forwarders n New gateway discovery procedures (and messages) n Some messages are more compressed n Extended keepalive procedures to support sleeping clients 48

49 Getting started o Brokers list n Mosquitto n HiveMQ o and NodeRed. Let s use it 49

Politecnico di Milano Advanced Network Technologies Laboratory. Constrained Application Protocol (CoAP)

Politecnico di Milano Advanced Network Technologies Laboratory Constrained Application Protocol (CoAP) 1 Background o GOAL: to enable web- based services in constrained wireless networks n 8 bit micro-