idnits 2.17.1 draft-pelov-core-cosol-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 17, 2016) is 2991 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'No-Responce' is mentioned on line 600, but not defined == Unused Reference: 'I-D.ietf-core-observe' is defined on line 696, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-marin-ace-wg-coap-eap-01 == Outdated reference: A later version (-01) exists of draft-pelov-yang-lora-00 == Outdated reference: A later version (-17) exists of draft-tcs-coap-no-response-option-13 == Outdated reference: A later version (-02) exists of draft-veillette-core-cool-00 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force A. Pelov, Ed. 3 Internet-Draft Acklio 4 Intended status: Informational L. Toutain, Ed. 5 Expires: August 20, 2016 Institut MINES-TELECOM ; TELECOM Bretagne 6 Y. Delibie, Ed. 7 Kerlink 8 February 17, 2016 10 Constrained Signaling Over LP-WAN 11 draft-pelov-core-cosol-01 13 Abstract 15 This document presents a new type of long-range, low-rate radio 16 technologies and an extensible mechanism to operate these networks 17 based on CoAP. The emerging Low-Power Wide-Area Networks (LP-WAN) 18 present a particular set of constraints, which places them at the 19 intersection of infrastructure networks, ultra-dense networks, delay- 20 tolerant networks and low-power and lossy networks. The main 21 objectives of LP-WAN signaling is to minimize the number of exchanged 22 messages, minimize the size of each message in a secure and 23 extensible manner, all with keeping the fundamental principle of 24 technology-independence (L2-independence). This document describes 25 the use of the Constrained Application Protocol (CoAP) as the main 26 signaling protocol for LP-WAN, over which minimal messages are 27 exchanged allowing the full operation of the network, such as 28 authentication, authorization, and management. The use of CoAP 29 signaling provides a generic mechanism that can be applied to 30 different LP-WAN technologies. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on August 20, 2016. 49 Copyright Notice 51 Copyright (c) 2016 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 68 2. LP-WAN Technologies . . . . . . . . . . . . . . . . . . . . . 5 69 2.1. Radio technologies . . . . . . . . . . . . . . . . . . . 5 70 2.2. Physical Layer Characteristics . . . . . . . . . . . . . 5 71 2.2.1. Ultra Narrowband LP-WAN radios . . . . . . . . . . . 6 72 2.2.2. Spread-spectrum LP-WAN radios . . . . . . . . . . . . 6 73 2.3. MAC Layer Characteristics . . . . . . . . . . . . . . . . 6 74 3. CoSOL Architecture . . . . . . . . . . . . . . . . . . . . . 7 75 3.1. General LP-WAN architecture . . . . . . . . . . . . . . . 7 76 3.2. Node-F lifecycle . . . . . . . . . . . . . . . . . . . . 8 77 3.3. CoAP as Signaling Protocol for LP-WANs . . . . . . . . . 10 78 3.3.1. Semi-Association . . . . . . . . . . . . . . . . . . 10 79 3.3.2. Network Discovery . . . . . . . . . . . . . . . . . . 11 80 3.3.3. Association . . . . . . . . . . . . . . . . . . . . . 13 81 3.3.4. Authentication . . . . . . . . . . . . . . . . . . . 13 82 3.3.5. Operation . . . . . . . . . . . . . . . . . . . . . . 14 83 3.3.6. Dissociation . . . . . . . . . . . . . . . . . . . . 15 84 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 85 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 86 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 87 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 88 7.1. Normative References . . . . . . . . . . . . . . . . . . 16 89 7.2. Informative References . . . . . . . . . . . . . . . . . 17 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 92 1. Introduction 94 The goal of this document is to provide the necessary mechanisms to 95 operate a Low-Power Wide-Area Network (LP-WAN) by using IETF CoAP 96 [RFC7252] as a core signaling protocol. 98 Long-range, low-rate radio technologies have emerged in the past 99 several years, and are the base for building LP-WANs. LP-WANs 100 generally have the following characteristics: 102 o Work in narrow, license-free (ISM) bands with good propagation 103 properties (< 1GHz) 105 o Low- to very-low throughput (1-200 kbps) 107 o Low-power operation (25 mW in Europe) 109 o Long-range communication capabilities (up to 30 km with line-of- 110 sight, several km in urban environment) 112 o Strong channel access restrictions (1% to 10% duty cycling) 114 o Infrastructure-based 116 o Star topology 118 LP-WANs are built on radio communication technologies, which use 119 advanced signal processing techniques and combination of appropriate 120 modulation and coding approaches to provide the aforementioned radio 121 characteristics. 123 The absence of license fees and the far-reaching connectivity allow 124 for an extremely competitive pricing of LP-WANs compared to other 125 networking technologies, e.g. cellular or mesh. LP-WANs are 126 sometimes referred to as LPWA or LR-WAN (Low-Rate WAN). Even though 127 LP-WANs are extremely limited in terms of network performance, they 128 are enough for a wide class of applications, among which [LTN001]: 130 o Metering (water, gas, electricity) 132 o Infrastructure networks (water, gas, electricity, roads, 133 pipelines, drains) 135 o Environment/Smart City (waste management, air pollution monitoring 136 and alerting, acoustic noise monitoring, public lighting 137 management, parking management, self service bike rental, digital 138 board monitoring, water pipe leakage monitoring) 140 o Environment/Country side (soil quality, livestock surveillance, 141 cattle and pet monitoring, climate, irrigation) 143 o Remote monitoring (house, building) 145 o Industrial (water tank, asset tracking) 146 o Automotive (vehicle tracking, impact detection, pay as you drive, 147 assistance request, ...) 149 o Logistics (goods tracking, conservation monitoring) 151 o Healthcare (patient monitoring, home medical equipment usage) 153 o House appliances (pet tracking, white goods, personal asset) 155 o Truck (tyre monitoring) 157 o Identification (authentication) 159 The IEEE is studying LP-WANs, but limited to the case of low-energy 160 critical infrastructure monitoring (LECIM), under the group IEEE 161 802.15.4k [IEEE.802-15.4k]. 163 The combination of the above characteristics and the envisioned 164 applications define a new class of networks with the following unique 165 constraints: 167 o Potentially extremely high density (expected of up to 10k-100k+ 168 end-devices managed by a single radio antena) 170 o Coexistence of delay-tolerant and critical applications (metering 171 and alarms) 173 o Low-power, low-throughput, lossy connectivity (use of ISM bands) 175 o Limited payload (100 bytes max, typically less than 50 bytes, 12 176 bytes for UNB) 178 CoAP is a client-server protocol specialized for constrained networks 179 and devices. CoAP is highly optimized, extensible, standard 180 protocol, which in conjunction with the Concise Binary Object 181 Representation (CBOR) is the ideal candidate for the signaling 182 protocol of the control plane of an LP-WAN. 184 It can be used during all stages of the lifecycle of the network, 185 e.g. discovery, authentication, operation. Furthermore, this can be 186 achieved by following RESTful management paradigm, by using a 187 particular resource tree definition or adopting COOL 188 [I-D.veillette-core-cool]. 190 1.1. Requirements Language 192 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 193 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 194 document are to be interpreted as described in RFC 2119 [RFC2119]. 196 2. LP-WAN Technologies 198 2.1. Radio technologies 200 There are two classes of LP-WAN radio technologies, using different 201 radio modulation approaches: 203 o Ultra Narrow Band (UNB) 205 o Spread-spectrum (SS) 207 An example of UNB is the technology developed and promoted by SigFox 208 [SigFox]. Semtech LoRa [LoRa] uses a direct-sequence spread-spectrum 209 with orthogonal codes (OSSS). 211 Both approaches have their advantages and will coexist in the future, 212 as there are currently several operators, which deploy the two types 213 in the same areas. 215 2.2. Physical Layer Characteristics 217 At the physical layer, the important part is the possibility to 218 reconstruct the signal at long distances. The used ISM bands are 219 defined around the world (e.g. 868 MHz in Europe and 900 MHz in USA) 220 and require a 1% (or 10%) duty cycling, or alternatively - advanced 221 detection and channel reallocation techniques. In reality, all 222 deployed networks use the duty cycling limitation, with the following 223 distinction. There is one 100kHz band in which 10% duty cycling is 224 allowed, with a slightly more emission power. The rest of the bands 225 are limited at 1% duty cycling and very restricted power of emission 226 (e.g. 25 mW in Europe). 228 UNB LP-WANs make the distinction between Uplink and Downlink, first 229 depending on the modulation, and second with the 10% duty-cycling 230 channel been used for the Downlink. OSSS LP-WANs make no such 231 distinction, although for the operation of a network, an operator can 232 chose to use the same Uplink/Downlink channel separation. 234 Note that the 1% or 10% duty-cycle limitation counts for all trafic 235 originating from an electronic equipment, e.g. an antena managing 236 100k objects must obey the same limitation as an end-device, with all 237 frames emitted from the antena (data, acknowledgements) counting 238 towards its quota. 240 2.2.1. Ultra Narrowband LP-WAN radios 242 Ultra Narrowband (UNB) technologies generally possess the following 243 physical layer characteristics [LTN003]: 245 o Uplink: 247 * channelization mask 100kHz (600 kHz USA) 249 * baud rate 100 bauds (600 bauds USA) 251 * modulation BPSK 253 o Downlink: 255 * channelization mask: dynamic selection 257 * down link baud rate: 600 baud 259 * modulation scheme: GFSK 261 * downlink transmission power: 500 mW, 10% duty cycle 263 2.2.2. Spread-spectrum LP-WAN radios 265 OSSS technologies possess the following physical layer 266 characteristics [LTN003]: 268 o channelization mask: from 8 kHz to 500 kHz (depending on spreading 269 factor) 271 o chip rate: 8 kcps up to 500 kcps 273 o data rate: 30-50 000 bps 275 o modulation scheme: equivalent to DSSS with orthogonal signaling 277 No particular distinction is made between the Uplink and the 278 Downlink. 280 2.3. MAC Layer Characteristics 282 Several proprietary MAC frame formats exist for UNB and OSSS. 283 However, they are designed to operate the network in a centralized, 284 highly-vertically-integrated fashion. The only standard MAC frame 285 format is the IEEE 802.15.4k, which is based on the well-known IEEE 286 802.15.4 with the addition of a fragmentation sub-layer. 288 The channel access method is based on ALOHA, although it is up to the 289 network operator to chose if an appropriate end-node polling should 290 be implemented. 292 3. CoSOL Architecture 294 3.1. General LP-WAN architecture 296 We can identify three types of entities in a typical LP-WAN. These 297 are: 299 o Node-F: far-reachable node, e.g. the end-point, object, device. 301 o Node-R: radio relay, bridging the LP-WAN radio technology to a 302 different medium (often a LAN or cellular WAN). 304 o Node-G: gateway node, interconnection between the radio-relay node 305 and the Internet. 307 +--------+ +--------+ +--------+ 308 | Node-F | <-- LP-WAN radio --> | Node-R | <-- IP --> | Node-G | 309 +--------+ +--------+ +--------+ 311 General architecture of an LP-WAN. LP-WAN radio technology is used 312 only between the Node-F and the Node-R. 314 Figure 1 316 Of these, only Node-F and Node-R communicate through an LP-WAN radio 317 technology. However, due to the extreme constraints of these 318 technologies, they are always behind a gateway (Node-G). Note, that 319 the Node-R and Node-G can be collocated, e.g. on a single hardware 320 equipment. 322 The Node-G is connected to the Internet and is assumed to have 323 sufficient computational resources to store a context for each of the 324 Node-Fs. The strong limitation here is the radio link. 326 In an actual deployment, a (limited) set of Node-Rs cover a large 327 area with a potentially very-high number of Node-Fs. A single Node-G 328 is capable of controlling all Node-Rs. 330 o 331 o o 332 o (((*)))-------\ 333 o o | 334 o o | 335 o (((*)))---------------+------Node-G 336 o o | 337 o o | 338 o (((*)))-------------------+ 339 o | 340 o o o o | 341 o (((*)))-----------/ 342 o o 343 o o 345 o = Node-F 346 (((*))) = Node-R 348 An example coverage of an area with several Node-Rs. Note that a 349 single Node-F may be covered by several Node-Rs. 351 Figure 2 353 3.2. Node-F lifecycle 355 Similar to other wireless infrastructure-based technologies, a Node-F 356 can go through several stages: 358 o Semi-Association 360 o Network Discovery 362 o Association 364 o Authentication 366 o Dissociation 368 The Node-F state machine is then the following: 370 +------------------------------------------------------+ 371 | | 372 V | 373 Semi-associated | 374 | | 375 V | 376 Disconnected <-> Network discovery -> Associated -> Authenticated 377 ^ | | 378 | | | 379 +------------------------------------------------------+ 381 Node-F connectivity state machine. 383 Figure 3 385 The Node-F can be in Semi-Associated mode. Upon start, and depending 386 on the application, a Node-F can use a state of uni-directional 387 communication, where it is considered semi-associated to the network. 388 In that state, the Node-F broadcasts frames, handled by the Node-G, 389 but the network cannot join the Node-F on a regular basis. This is a 390 degraded LP-WAN operating mode and if caution is not used, can lead 391 to significant scalability and evolvability issues. 393 The Network Discovery can be reactive or proactive. The former is 394 based on detecting beacon frames sent periodically by the network 395 (e.g. Node-G). The latter is implemented by the Node-F broadcasting 396 probe request frames, to which all appropriate Node-Gs must respond. 398 Once a network has been discovered, the Node-F can associate to the 399 network. The association creates the necessary (minimal) context on 400 the Node-G, which initiates the authentication of the Node-F 402 The authentication is initiated by the Node-G, which should allow for 403 the necessary AAA exchanges to take place. If the authentication is 404 successful, the Node-F enters the Authenticated state. In this stage 405 there is bi-directional communication between the Node-F and the 406 Node-G. If the authentication is not successful, the Node-F enters 407 Disconnected state. Once in Authenticated state, the Node-F can 408 downgrade its connectivity to Semi-Associated mode. 410 The management of the node in Authenticated state is performed with 411 COOL [I-D.veillette-core-cool]. As an example, managing the 412 parameters of a Semtech LoRa device can be achieved through the use 413 of the YANG module defined in [I-D.pelov-yang-lora] 415 Finally, the Node-F may decide to dissociate from the network by 416 sending an explicit request. Upon dissociation the Node-G may 417 release all contexts related to the Node-F and re-association 418 requires going through the authentication stage again. Node mobility 419 is achieved by explicitly dissociating from the old Node-G and then 420 authenticating to the new Node-G. Implicit dissociation is also 421 possible upon the expiration of predefined timers, or in case of 422 mobility optimization. 424 3.3. CoAP as Signaling Protocol for LP-WANs 426 Use as CoAP for signaling is implemented as follows. The MAC, 427 network and/or transport layers MUST provide a mechanism to 428 differentiate user data from signaling data frames (e.g. by using 429 separate MAC addresses, IP addresses and/or UDP-ports). Both the 430 Node-G and the Node-F are running CoAP servers for implementing the 431 control plane. Frames exchanged over the LP-WAN radio interface and 432 marked as "signaling data" are handled by the corresponding control 433 plane CoAP servers. 435 The Node-G runs a (virtual) CoAP server for each Node-F. This server 436 is identified with a DNS name, e.g. "node123.home.node- 437 g.example.com", which can be used explicitly in the CoAP messages via 438 the Proxy-Uri option if needed. 440 Note, that the Node-R acts only as a transceiver and as such is 441 transparent from protocol point of view. As such, the following 442 management scheme applies: 444 +--------+ +--------+ 445 | Node-F | <-- LP-WAN constraints --> | Node-G | 446 +--------+ +--------+ 448 Node-F connectivity from protocol point of view. 450 Figure 4 452 3.3.1. Semi-Association 454 When in a semi-associated state, a Node-F broadcasts its messages 455 without performing network discovery, or association. If the Node-F 456 is under the coverage of a Node-G, the Node-G will receive the 457 broadcast, and forward the user data. The frames SHOULD be signed, 458 so that they could be authenticated by the network. Layer 2 459 acknowledgements MUST be used, and in some cases piggybacking on them 460 can provoke the Node-F to associate to the network. 462 The broadcast messages MUST include the necessary information to join 463 the user data destination, and enough information for the Node-G to 464 authenticate the message sender. This can be achieved through a 465 Confirmable CoAP message, where the user data are POSTed to a well- 466 known resource defined on the Node-G. DTLS with integrity check can 467 be used, with long-lived keys negotiated by the Node-F and the 468 network. Alternatively, COSE objects may provide the necessary 469 mechanisms. 471 Even though an application can be implemented by using only simplex 472 association capabilities, there are non-negligible negative 473 consequences related to scalability and evolvability in this case. 474 For example, a Node-F which periodically broadcasts information will 475 occupy the spectrum, even if there is no operator willing to accept 476 its trafic. In addition, no channel access management can be 477 applied. 479 Node-F Node-G 480 | | 481 | | 482 +--------->| Header: POST 483 | POST | Uri-Host: "destination.example.com" 484 | | Uri-Path: "temp" 485 | | 486 | | 487 |<---------+ Header: 2.01 Created 488 | 2.01 | 489 | | 490 | | 492 Sending a message in a semi-associated state. 494 Figure 5 496 3.3.2. Network Discovery 498 A network can be discovered by a Node-F reactively or proactively. 500 Reactive network discovery is based on the detection of periodic 501 beacons emitted by the Node-G. The beacons are implemented with CoAP 502 messages with the No-Response option 503 [I-D.tcs-coap-no-response-option]. The Node-G POSTs its information 504 to a well-known resource, e.g. "/network/node-G/" or a resource alias 505 "/g". Alternatively, this could be achieved by POST-ting to a COOL 506 container (e.g. POST /cool with data node ID = 1 for example). 508 Node-F Node-G 509 | | 510 | | 511 |<---------+ Header: POST 512 | POST /g | Uri-Path: "g" 513 | | [No-Responce] 514 | | 515 | | 517 Reactive network discovery. The Node-G sends periodically beacon 518 messages, containing information pertinent to this network. 520 Figure 6 522 The CoAP POST request is processed at the Node-F. A resource is 523 created locally, with the representation, which provides the 524 appropriate network parameters, e.g. network ID, Node-G ID, and other 525 radio-related parameters, such as channel, beacon frequency and so 526 forth. This information allows the Node-F to begin the 527 authentication phase. 529 A Node-F may chose to proactively probe for the existence of network 530 coverage. In that case, it sends a Confirmable CoAP GET request to 531 obtain the information from a well-known resource, normally published 532 by the beacon messages, e.g. "/network/node-G/" or a resource alias 533 "/g" or COOL data node ID ("/cool" data node ID = 2 for example). 535 Node-F Node-G 536 | | 537 | | 538 +--------->| Header: GET 539 | GET /g | Uri-Path: "g" 540 | | Accept: application/cbor 541 | | 542 | | 543 |<---------+ Header: 2.05 Content 544 | 2.05 | Payload: ... 545 | | 547 Proactive network discovery. The Node-F request the information of 548 all surrounding Node-Gs. 550 Figure 7 552 Once the network is discovered, the Node-F has all necessary 553 information to start the authentication phase. 555 3.3.3. Association 557 Before being able to communicate, the Node-F must associate to the 558 network, and then eventually authenticate. The association phase 559 signals to the Node-G that there is a new device willing to 560 communicate with the network. This association SHOULD provide enough 561 information to allow the Node-G to start the authentication process. 562 For example, it may provide the AAA server, which could authenticate 563 the Node-F, or its EAP-Identity. Note, that the Node-F may elect to 564 mark the association message with the No-response option 565 [I-D.tcs-coap-no-response-option], waiting for the subsequent 566 authentication request from the Node-G. 568 Node-F Node-G 569 | | 570 | | 571 +--------->| Header: POST 572 | POST /n | Uri-Path: "n" 573 | | Payload: ... 574 | | 575 |<---------+ Header: 2.01 Created 576 | 2.01 | Location-Path: "/n/n705" 577 | | 579 Node-F associates to a network, by creating a corresponding resource 580 element on the Node-G. 582 Figure 8 584 3.3.4. Authentication 586 The EAP-over-CoAP [I-D.marin-ace-wg-coap-eap] specifies an approach 587 to encapsulating EAP messages over CoAP. This allows to authenticate 588 a Node-F, which wishes to join an LP-WAN, and negotiate the L2 589 encryption keys, and DTLS keying material. 591 As the Node-F has already associated to the Node-G, it is the Node-G 592 that initiates the authentification request, by going directly to 593 Step 1) of the EAP-over-CoAP specification. 595 Node-F Node-G 596 | | 597 | | 598 1) |<-----------+ Header: POST 599 | POST /auth | Uri-Path: "auth" 600 | | [No-Responce] 601 | | 602 | | 603 2) +----------->| Header: 2.01 Created 604 | ACK /auth | Location-Path: "/auth/5" 605 | | 606 | | 607 | | 608 3) |<-----------+ Header: PUT 609 | PUT /auth/5| Uri-Path: "auth/5" 610 | | Payload: EAP-PSK MSG 1 611 | | 612 | | 613 4) +----------->| Header: 2.04 Changed 614 | ACK /auth/5| Payload: EAP-PSK MSG 2 615 | | 616 ...... 618 Node-F and Node-G perform mutual authentication following EAP-over- 619 CoAP. 621 Figure 9 623 Upon the end of the authentication phase, a Master Shared Key (MSK) 624 is known by the Node-F and the Node-G, and is used to generate DTLS 625 encryption or integrity keys. Further communications should be 626 encrypted/signed with the freshly derived keys. 628 3.3.5. Operation 630 Once the Node-F is authenticated to the network, it can send user 631 data via the Node-G to any other end-point on the Internet. 633 During the operation of the Node-F, the network may need to change 634 one or more parameters concerning the LP-WAN radio parameters of the 635 Node-F. These changes may even concern parameters related to the 636 Node-F itself (such as sleep cycles), its network parameters (e.g. 637 IP addresses), and so forth. This is achieved through the use of 638 COOL [I-D.veillette-core-cool]. The appropriate YANG modules must be 639 present on the Node-F (e.g. a Semtech LoRa Node-F should implement 640 the [I-D.pelov-yang-lora] module). 642 Node-F Node-G 643 | | 644 | | 645 |<-----------+ Header: PUT 646 | PUT /cool | Uri-Path: "cool" 647 | | Payload: {5:10,6:2} 648 | | 649 | | 650 +----------->| Header: 2.04 Changed 651 | 2.04 | 652 | | 654 Example, in which the Node-G changes the Spreading Factor (e.g. COOL 655 data node ID = 5) to 10, and the Channel (e.g. COOL data node ID = 656 6) to 2. Note, that the payload is encoded in CBOR. 658 Figure 10 660 3.3.6. Dissociation 662 If the Node-F wishes to deregister from the network, it could do so 663 by deleting the context created upon association: 665 Node-F Node-G 666 | | 667 | | 668 +--------------->| Header: POST 669 | DELETE /n/n705 | Uri-Path: "n/n705" 670 | | 671 | | 672 |<---------------+ Header: 2.02 Deleted 673 | 2.02 | 674 | | 676 Node-F dissociates from the network by deleting its associated 677 resources. 679 Figure 11 681 4. Acknowledgements 683 5. IANA Considerations 685 This memo includes no request to IANA. 687 6. Security Considerations 689 All drafts are required to have a security considerations section. 690 See RFC 3552 [RFC3552] for a guide. 692 7. References 694 7.1. Normative References 696 [I-D.ietf-core-observe] 697 Hartke, K., "Observing Resources in CoAP", draft-ietf- 698 core-observe-16 (work in progress), December 2014. 700 [I-D.marin-ace-wg-coap-eap] 701 Garcia, D., "EAP-based Authentication Service for CoAP", 702 draft-marin-ace-wg-coap-eap-01 (work in progress), October 703 2014. 705 [I-D.pelov-yang-lora] 706 Pelov, A., Toutain, L., Delibie, Y., and A. Minaburo, 707 "YANG module for LoRa Networks", draft-pelov-yang-lora-00 708 (work in progress), December 2015. 710 [I-D.tcs-coap-no-response-option] 711 Bhattacharyya, A., Bandyopadhyay, S., Pal, A., and T. 712 Bose, "CoAP option for no server-response", draft-tcs- 713 coap-no-response-option-13 (work in progress), November 714 2015. 716 [I-D.veillette-core-cool] 717 Veillette, M. and A. Pelov, "Constrained Objects 718 Language", draft-veillette-core-cool-00 (work in 719 progress), November 2015. 721 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 722 Requirement Levels", BCP 14, RFC 2119, 723 DOI 10.17487/RFC2119, March 1997, 724 . 726 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 727 Application Protocol (CoAP)", RFC 7252, 728 DOI 10.17487/RFC7252, June 2014, 729 . 731 7.2. Informative References 733 [IEEE.802-15.4k] 734 Institute of Electrical and Electronics Engineers, "Low- 735 Rate Wireless Personal Area Networks (LR-WPANs) - 736 Amendment 5: Physical Layer Specifications for Low Energy, 737 Critical Infrastructure Monitoring Networks., IEEE 738 802.15.4k", IEEE Standard 802.15.4, 2013. 740 [LoRa] Semtech, "https://web.archive.org/web/20150510011904/ 741 https://www.semtech.com/wireless-rf/lora.html", May 2015. 743 [LTN001] European Telecommunications Standards Institute, "Low 744 Throughput Networks (LTN); Use Cases for Low Throughput 745 Networks, ETSI GS LTN 001", IEEE ETSI GS LTN 001, 2014. 747 [LTN003] European Telecommunications Standards Institute, "Low 748 Throughput Networks (LTN); Protocols and Interfaces, ETSI 749 GS LTN 003", IEEE ETSI GS LTN 003, 2014. 751 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 752 Text on Security Considerations", BCP 72, RFC 3552, 753 DOI 10.17487/RFC3552, July 2003, 754 . 756 [SigFox] SigFox, "https://web.archive.org/web/20150628225901/ 757 http://www.sigfox.com/en/#!/technology", June 2015. 759 Authors' Addresses 761 Alexander Pelov (editor) 762 Acklio 763 2bis rue de la Chataigneraie 764 Cesson-Sevigne, Bretagne 35510 765 FR 767 Email: a@ackl.io 769 Laurent Toutain (editor) 770 Institut MINES-TELECOM ; TELECOM Bretagne 771 2 rue de la Chataigneraie 772 Cesson-Sevigne, Bretagne 35510 773 FR 775 Email: laurent.toutain@telecom-bretagne.eu 776 Yannick Delibie (editor) 777 Kerlink 778 1 rue Jacqueline Auriol 779 Thorigne-Fouillard, Bretagne 35235 780 FR 782 Email: yannick.delibie@kerlink.fr