idnits 2.17.1 draft-pelov-core-cosol-00.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 (July 4, 2015) is 3191 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'No-Responce' is mentioned on line 594, but not defined == Outdated reference: A later version (-17) exists of draft-tcs-coap-no-response-option-11 == Outdated reference: A later version (-11) exists of draft-vanderstok-core-comi-06 Summary: 0 errors (**), 0 flaws (~~), 4 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: January 5, 2016 Telecom Bretagne 6 Y. Delibie, Ed. 7 Kerlink 8 July 4, 2015 10 Constrained Signaling Over LR-WAN 11 draft-pelov-core-cosol-00 13 Abstract 15 This document presents a new type of far-reaching, low-rate radio 16 technologies and an extensible mechanism to operate these networks 17 based on CoAP. The emerging Wide Area Networks based on them - Low- 18 Rate WAN (LR-WAN) preset a particular set of constraints, which 19 places them at the intersection of infrastructure networks, ultra- 20 dense networks, delay-tolerant networks and low-power and lossy 21 networks. The main objectives of LR-WAN signaling is to minimize the 22 number of exchanged messages, minimize the size of each message in a 23 secure and extensible manner. This document describes the use of the 24 Constrained Application Protocol (CoAP) as the main signaling 25 protocol for LR-WANs, over which minimal messages are exchanged 26 allowing the full operation of the network, such as authentication, 27 authorization, and management. The use of CoAP signaling provides a 28 generic mechanism that can be applied to different LR-WAN 29 technologies. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on January 5, 2016. 48 Copyright Notice 50 Copyright (c) 2015 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 67 2. LR-WAN Technologies . . . . . . . . . . . . . . . . . . . . . 5 68 2.1. FARE technologies . . . . . . . . . . . . . . . . . . . . 5 69 2.2. Physical Layer Characteristics . . . . . . . . . . . . . 5 70 2.2.1. Ultra Narrowband FARE radios . . . . . . . . . . . . 6 71 2.2.2. Spread-spectrum FARE radios . . . . . . . . . . . . . 6 72 2.3. MAC Layer Characteristics . . . . . . . . . . . . . . . . 6 73 3. CoSOL Architecture . . . . . . . . . . . . . . . . . . . . . 7 74 3.1. General LR-WAN architecture . . . . . . . . . . . . . . . 7 75 3.2. Node-F lifecycle . . . . . . . . . . . . . . . . . . . . 8 76 3.3. CoAP as Signaling Protocol for LR-WANs . . . . . . . . . 10 77 3.3.1. Semi-Association . . . . . . . . . . . . . . . . . . 10 78 3.3.2. Network Discovery . . . . . . . . . . . . . . . . . . 11 79 3.3.3. Association . . . . . . . . . . . . . . . . . . . . . 12 80 3.3.4. Authentication . . . . . . . . . . . . . . . . . . . 13 81 3.3.5. Dissociation . . . . . . . . . . . . . . . . . . . . 14 82 3.4. Shared resource tree . . . . . . . . . . . . . . . . . . 15 83 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 84 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 85 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 86 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 87 7.1. Normative References . . . . . . . . . . . . . . . . . . 17 88 7.2. Informative References . . . . . . . . . . . . . . . . . 17 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 91 1. Introduction 93 The goal of this document is to provide the necessary mechanisms to 94 operate a Low-Rate Wide-Area Network (LR-WAN) by using IETF CoAP 95 [RFC7252] as a core signaling protocol. 97 Far-Reaching, low-rate communication technologies (FARE) have emerged 98 in the past several years, and are the base for building Low-Rate 99 Wide-Area Networks (LR-WAN). LR-WANs have the following 100 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 Far-Reaching 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 LR-WANs are built on Far-Reaching Radio communication technologies 119 (FARE), which use advanced signal processing techniques and 120 combination of appropriate modulation and coding approaches to 121 provide the aforementioned radio characteristics. 123 The absence of license fees and the Far-Reaching connectivity allow 124 for an extremely competitive pricing of LR-WANs compared to other 125 networking technologies, e.g. cellular or mesh. LR-WANs are 126 sometimes referred to as LPWAN (Low-Power WAN), e.g. by Semtech 127 [LoRa]. Even though LR-WANs are extremely limited in terms of 128 network performance, they are enough for a wide class of 129 applications, among which [LTN001]: 131 o Metering (water, gas, electricity) 133 o Infrastructure networks (water, gas, electricity, roads, 134 pipelines, drains) 136 o Environment/Smart City (waste management, air pollution monitoring 137 and alerting, acoustic noise monitoring, public lighting 138 management, parking management, self service bike rental, digital 139 board monitoring, water pipe leakage monitoring) 141 o Environment/Country side (soil quality, livestock surveillance, 142 cattle and pet monitoring, climate, irrigation) 144 o Remote monitoring (house, building) 145 o Industrial (water tank, asset tracking) 147 o Automotive (vehicle tracking, impact detection, pay as you drive, 148 assistance request, ...) 150 o Logistics (goods tracking, conservation monitoring) 152 o Healthcare (patient monitoring, home medical equipment usage) 154 o House appliances (pet tracking, white goods, personal asset) 156 o Truck (tyre monitoring) 158 o Identification (authentication) 160 The IEEE is studying LR-WANs, but limited to the case of low-energy 161 critical infrastructure monitoring (LECIM), under the group IEEE 162 802.15.4k [IEEE.802-15.4k]. 164 The combination of the above characteristics and the envisioned 165 applications define a new class of networks with the following unique 166 constraints: 168 o Potentially extremely high density (expected of up to 10k-100k+ 169 end-devices managed by a single radio antena) 171 o Coexistence of delay-tolerant and critical applications (metering 172 and alarms) 174 o Low-power, low-throughput, lossy connectivity (use of ISM bands) 176 o Limited payload (100 bytes max, typically less than 50 bytes, 12 177 bytes for UNB) 179 CoAP is a client-server protocol specialized for constrained networks 180 and devices. CoAP is highly optimized, extensible, standard 181 protocol, which in conjunction with the Concise Binary Object 182 Representation (CBOR) is the ideal candidate for the signaling 183 protocol of the control plane of an LR-WAN. 185 It can be used during all stages of the lifecycle of the network, 186 e.g. discovery, authentication, operation. Furthermore, this can be 187 achieved by following RESTful management paradigm, by using a 188 particular resource tree definition or adopting CoMI 189 [I-D.vanderstok-core-comi]. 191 1.1. Requirements Language 193 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 194 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 195 document are to be interpreted as described in RFC 2119 [RFC2119]. 197 2. LR-WAN Technologies 199 2.1. FARE technologies 201 There are two classes of Far-Reaching radio Technologies, using 202 different radio modulation approaches: 204 o Ultra Narrow Band (UNB) 206 o Spread-spectrum (SS) 208 An example of UNB is the technology developed and promoted by SigFox 209 [SigFox]. Semtech LoRa [LoRa] uses a direct-sequence spread-spectrum 210 with orthogonal codes (OSSS). 212 Both approaches have their advantages and will coexist in the future, 213 as there are currently several operators, which deploy the two types 214 in the same areas. 216 2.2. Physical Layer Characteristics 218 At the physical layer, the important part is the possibility to 219 reconstruct the signal at long distances. The used ISM bands are 220 defined around the world (e.g. 868 MHz in Europe and 900 MHz in USA) 221 and require a 1% (or 10%) duty cycling, or alternatively - advanced 222 detection and channel reallocation techniques. In reality, all 223 deployed networks use the duty cycling limitation, with the following 224 distinction. There is one 100kHz band in which 10% duty cycling is 225 allowed, with a slightly more emission power. The rest of the bands 226 are limited at 1% duty cycling and very restricted power of emission 227 (e.g. 25 mW in Europe). 229 UNB LR-WANs make the distinction between Uplink and Downlink, first 230 depending on the modulation, and second with the 10% duty-cycling 231 channel been used for the Downlink. OSSS LR-WANs make no such 232 distinction, although for the operation of a network, an operator can 233 chose to use the same Uplink/Downlink channel separation. 235 Note that the 1% or 10% duty-cycle limitation counts for all trafic 236 originating from an electronic equipment, e.g. an antena managing 237 100k objects must obey the same limitation as an end-device, with all 238 frames emitted from the antena (data, acknowledgements) counting 239 towards its quota. 241 2.2.1. Ultra Narrowband FARE radios 243 Ultra Narrowband (UNB) technologies generally possess the following 244 physical layer characteristics [LTN003]: 246 o Uplink: 248 * channelization mask 100kHz (600 kHz USA) 250 * baud rate 100 bauds (600 bauds USA) 252 * modulation BPSK 254 o Downlink: 256 * channelization mask: dynamic selection 258 * down link baud rate: 600 baud 260 * modulation scheme: GFSK 262 * downlink transmission power: 500 mW, 10% duty cycle 264 2.2.2. Spread-spectrum FARE radios 266 OSSS technologies possess the following physical layer 267 characteristics [LTN003]: 269 o channelization mask: from 8 kHz to 500 kHz (depending on spreading 270 factor) 272 o chip rate: 8 kcps up to 500 kcps 274 o data rate: 30-50 000 bps 276 o modulation scheme: equivalent to DSSS with orthogonal signaling 278 No particular distinction is made between the Uplink and the 279 Downlink. 281 2.3. MAC Layer Characteristics 283 Several proprietary MAC frame formats exist for UNB and OSSS. 284 However, they are designed to operate the network in a centralized, 285 highly-vertically-integrated fashion. The only standard MAC frame 286 format is the IEEE 802.15.4k, which is based on the well-known IEEE 287 802.15.4 with the addition of a fragmentation sub-layer. 289 The channel access method is based on ALOHA, although it is up to the 290 network operator to chose if an appropriate Node-F polling should be 291 implemented. 293 3. CoSOL Architecture 295 3.1. General LR-WAN architecture 297 We can identify three types of entities in a typical LR-WAN. These 298 are: 300 o Node-F: far-reachable node, e.g. the end-point, object, device 302 o Node-R: radio relay, bridging the Far-Reaching radio technology to 303 a different medium (often a LAN or cellular WAN) 305 o Node-G: gateway node, interconnection between the radio-relay node 306 and the Internet 308 +--------+ +--------+ +--------+ 309 | Node-F | <-- FARE --> | Node-R | <-- IP --> | Node-G | 310 +--------+ +--------+ +--------+ 312 General architecture of an LR-WAN. FARE radio technology is used 313 only between the Node-F and the Node-R. 315 Figure 1 317 Of these, only Node-F and Node-R communicate through a FARE 318 technology. However, due to the extreme constraints of these 319 technologies, they are always behind a gateway (Node-G). Note, that 320 the Node-R and Node-G can be collocated, e.g. on a single hardware 321 equipment. 323 The Node-G is connected to the Internet and is assumed to have 324 sufficient computational resources to store a context for each of the 325 Node-Fs. The strong limitation here is the radio link. 327 In an actual deployment, a (limited) set of Node-Rs cover a large 328 area with a potentially very-high number of Node-Fs. A single Node-G 329 is capable of controlling all Node-Rs. 331 o 332 o o 333 o (((*)))-------\ 334 o o | 335 o o | 336 o (((*)))---------------+------Node-G 337 o o | 338 o o | 339 o (((*)))-------------------+ 340 o | 341 o o o o | 342 o (((*)))-----------/ 343 o o 344 o o 346 o = Node-F 347 (((*))) = Node-R 349 An example coverage of an area with several Node-Rs. Note that a 350 single Node-F may be covered by several Node-Rs. 352 Figure 2 354 3.2. Node-F lifecycle 356 Similar to other wireless infrastructure-based technologies, a Node-F 357 can go through several stages: 359 o Semi-Association 361 o Network Discovery 363 o Authentication 365 o Association 367 o Dissociation 369 The Node-F state machine is then the following: 371 +-----------------------------------------------------+ 372 | | 373 V | 374 Semi-associated ----------+ | 375 | ^ | | 376 | | | | 377 V | V | 378 Disconnected -> Network discovery -> Associated -> Authenticated 379 ^ | 380 | | 381 +-----------------------------------------------------+ 383 Node-F connectivity state machine. 385 Figure 3 387 The Node-F can be in Semi-Associated mode. Upon start, and depending 388 on the application, a Node-F can use a state of uni-directional 389 communication, where it is considered semi-associated to the network. 390 In that state, the Node-F broadcasts frames, handled by the Node-G, 391 but the network cannot join the Node-F on a regular basis. This is a 392 degraded LR-WAN operating mode and if caution is not used, can lead 393 to significant scalability and evolvability issues. 395 The Network Discovery can be reactive or proactive. The former is 396 based on detecting beacon frames sent periodically by the network 397 (e.g. Node-G). The latter is implemented by the Node-F broadcasting 398 probe request frames, to which all appropriate Node-Gs must respond. 400 Once a network has been discovered, the Node-F and the Node-G can 401 perform mutual authentication. 403 Upon authentication, the Node-G configures the necessary network 404 parameters of the Node-F, which is henceforth associated to the 405 network. The association request may be explicit or implicit, in 406 which case after successful authentication the Node-F enters 407 automatically the associated state. In this stage there is bi- 408 directional communication between the Node-F and the Node-G. 410 Finally, the Node-F may decide to dissociate from the network by 411 sending an explicit request. Upon dissociation the Node-G may 412 release all contexts related to the Node-F and re-association 413 requires going through the authentication stage again. Node mobility 414 is achieved by explicitly dissociating from the old Node-G and then 415 authenticating to the new Node-G. Implicit dissociation is also 416 possible upon the expiration of predefined timers, or in case of 417 mobility optimization. 419 3.3. CoAP as Signaling Protocol for LR-WANs 421 Use as CoAP for signaling is implemented as follows. The MAC, 422 network and/or transport layers MUST provide a mechanism to 423 differentiate user data from signaling data frames (e.g. by using 424 separate MAC addresses, IP addresses and/or UDP-ports). Both the 425 Node-G and the Node-F are running CoAP servers for implementing the 426 control plane. Frames exchanged over the FARE radio interface and 427 marked as "signaling data" are handled by the corresponding control 428 plane CoAP servers. CoAP requests are thus used to keep a shared 429 vision of the network and the node between the two. This is realized 430 by a virtual, shared resource-tree as described in Section 3.4. 432 The Node-G runs a (virtual) CoAP server for each Node-F. This server 433 is identified with a DNS name, e.g. "node123.home.node- 434 g.example.com", which can be used explicitly in the CoAP messages via 435 the Proxy-Uri option if needed. 437 Note, that the Node-R acts only as a transceiver and as such is 438 transparent from protocol point of view. As such, the following 439 management scheme applies: 441 +--------+ +--------+ 442 | Node-F | <-- LR-WAN constraints --> | Node-G | 443 +--------+ +--------+ 445 Node-F connectivity state machine. 447 Figure 4 449 3.3.1. Semi-Association 451 When in a semi-associated state, a Node-F broadcasts its messages 452 without performing network discovery, or association. If the Node-F 453 is under the coverage of a Node-G, the Node-G will receive the 454 broadcast, and forward the user data. The frames SHOULD be signed, 455 so that they could be authenticated by the network. Layer 2 456 acknowledgements MUST be used, and in some cases piggybacking on them 457 can provoke the Node-F to associate to the network. 459 The broadcast messages MUST include the necessary information to join 460 the user data destination, and enough information for the Node-G to 461 authenticate the message sender. This can be achieved through a 462 Confirmable CoAP message, where the user data are POSTed to a well- 463 known resource defined on the Node-G. DTLS with integrity check can 464 be used, with long-lived keys negotiated by the Node-F and the 465 network. 467 Even though an application can be implemented by using only simplex 468 association capabilities, there are huge negative consequences 469 related to scalability and evolvability in this case. For example, a 470 Node-F which periodically broadcasts information will occupy the 471 spectrum, even if there is no operator willing to accept its trafic. 472 In addition, no channel access management can be applied. 474 Node-F Node-G 475 | | 476 | | 477 +--------->| Header: POST 478 | POST | Uri-Host: "destination.example.com" 479 | | Uri-Path: "temp" 480 | | 481 | | 482 |<---------+ Header: 2.01 Created 483 | 2.01 | 484 | | 485 | | 487 Sending a message in a semi-associated state. 489 Figure 5 491 3.3.2. Network Discovery 493 A network can be discovered by a Node-F reactively or proactively. 495 Reactive network discovery is based on the detection of periodic 496 beacons emitted by the Node-G. The beacons are implemented with CoAP 497 messages with the No-Response option 498 [I-D.tcs-coap-no-response-option]. The Node-G POSTs its information 499 to a well-known resource, e.g. "/network/node-G/" or a resource alias 500 "/g" or CoMI YANG hash ID "/mg/GgQ". 502 Node-F Node-G 503 | | 504 | | 505 |<---------+ Header: POST 506 | POST /g | Uri-Path: "g" 507 | | [No-Responce] 508 | | 509 | | 511 Reactive network discovery. The Node-G sends periodically beacon 512 messages, containing information pertinent to this network. 514 Figure 6 516 The CoAP POST request is processed at the Node-F. A resource is 517 created locally, with the representation, which provides the 518 appropriate network parameters, e.g. network ID, Node-G ID, and other 519 radio-related parameters, such as channel, beacon frequency and so 520 forth. This information allows the Node-F to begin the 521 authentication phase. 523 A Node-F may chose to proactively probe for the existence of network 524 coverage. In that case, it sends a Confirmable CoAP GET request to 525 obtain the information from a well-known resource, normally published 526 by the beacon messages, e.g. "/network/node-G/" or a resource alias 527 "/g" or CoMI YANG hash ID "/mg/GgQ". 529 Node-F Node-G 530 | | 531 | | 532 +--------->| Header: GET 533 | GET /g | Uri-Path: "g" 534 | | Accept: application/cbor 535 | | 536 | | 537 |<---------+ Header: 2.05 Content 538 | 2.05 | Payload: ... 539 | | 541 Proactive network discovery. The Node-F request the information of 542 all surrounding Node-Gs. 544 Figure 7 546 Once the network is discovered, the Node-F has all necessary 547 information to start the authentication phase. 549 3.3.3. Association 551 Before being able to communicate, the Node-F must associate to the 552 network, and then eventually authenticate. The association phase 553 signals to the Node-G that there is a new device willing to 554 communicate with the network. This association SHOULD provide enough 555 information to allow the Node-G to start the authentication process. 556 For example, it may provide the AAA server, which could authenticate 557 the Node-F, or its EAP-Identity. Note, that the Node-F may elect to 558 mark the association message with the No-response option 559 [I-D.tcs-coap-no-response-option], waiting for the subsequent 560 authentication request from the Node-G. 562 Node-F Node-G 563 | | 564 | | 565 +--------->| Header: POST 566 | POST /n | Uri-Path: "n" 567 | | Payload: ... 568 | | 569 |<---------+ Header: 2.01 Created 570 | 2.01 | Location-Path: "/n/n705" 571 | | 573 Node-F associates to a network, by creating a corresponding resource 574 element on the Node-G. 576 Figure 8 578 3.3.4. Authentication 580 The EAP-over-CoAP [I-D.garcia-core-security] specifies an approach 581 to encapsulating EAP messages over CoAP. This allows to authenticate 582 a Node-F, which wishes to join an LR-WAN, and negotiate the L2 583 encryption keys, and DTLS keying material. 585 As the Node-F has already associated to the Node-G, it is the Node-G 586 that initiates the authentification request, by going directly to 587 Step 1) of the EAP-over-CoAP specification. 589 Node-F Node-G 590 | | 591 | | 592 1) |<-----------+ Header: POST 593 | POST /auth | Uri-Path: "auth" 594 | | [No-Responce] 595 | | 596 | | 597 2) +----------->| Header: 2.01 Created 598 | ACK /auth | Location-Path: "/auth/5" 599 | | 600 | | 601 | | 602 3) |<-----------+ Header: PUT 603 | PUT /auth/5| Uri-Path: "auth/5" 604 | | Payload: EAP-PSK MSG 1 605 | | 606 | | 607 4) +----------->| Header: 2.04 Changed 608 | ACK /auth/5| Payload: EAP-PSK MSG 2 609 | | 610 ...... 612 Node-F and Node-G perform mutual authentication following EAP-over- 613 CoAP. 615 Figure 9 617 Upon the end of the authentication phase, a Master Shared Key (MSK) 618 is known by the Node-F and the Node-G, and is used to generate DTLS 619 encryption or integrity keys. Further communications should be 620 encrypted/signed with the freshly derived keys. 622 3.3.5. Dissociation 624 If the Node-F wishes to deregister from the network, it could do so 625 by deleting the context created upon association: 627 Node-F Node-G 628 | | 629 | | 630 +--------------->| Header: POST 631 | DELETE /n/n705 | Uri-Path: "n/n705" 632 | | 633 | | 634 |<---------------+ Header: 2.02 Deleted 635 | 2.02 | 636 | | 638 Node-F dissociates from the network by deleting its associated 639 resources. 641 Figure 10 643 3.4. Shared resource tree 645 The Node-F and Node-G have to use any opportunity to save trafic. 646 This can be handled by having a shared context on both devices, which 647 is updated in an asynchronous fashion. In a RESTful approach, the 648 shared context is a resource tree, synchronized with CoAP messages. 649 Note, that this only concerns the control plane, responsible for 650 managing the devices. The data plane is independent and can use any 651 communication pattern, which fits the radio limitations. 653 The shared resource tree can be structured freely, but will generally 654 include the radio parameters of the Node-F and Node-G, their 655 identities, authentication results, encryption/integrity preferences 656 and parameters, compression methods, etc. It will can also include 657 trafic shaping settings, restrictions, counters, and so forth. The 658 resource tree can follow a structure defined with YANG. 660 For example, for a typical OSSS installation, the following 661 parameters should be specified: 663 o Node-R beacon channels 665 o Node-F response channel 667 o Node-F response spreading factor 669 o Node-F response coding rate 671 o Node-F fall-back (default) channel 673 o Node-F fall-back (default) spreading factor 674 o Node-F fall-back (default) coding rate 676 o ... 678 Upon authentication, the two nodes establish an authenticated 679 connection. Each of the resources can then be accessed in read-only, 680 read-write, or write-only mode. Access is performed with CoAPs GET, 681 PUT, POST and DELETE methods. 683 The most frequently accessed resource tree elements should have short 684 aliases, in order to have short URIs. If the management server is 685 independent from the application servers, using a single- or double- 686 character abbreviation under the root tree is recommended. 687 Alternatively, the use of CoMI [I-D.vanderstok-core-comi] is 688 recommended if YANG representation is available. 690 For example: 692 /radio/interace/lora/lora1/spreading_factor -> /sf 693 /radio/interace/lora/lora1/coding_rate -> /cr 695 +--------+ +--------+ 696 | Node-F | <------------------------> | Node-G | 697 +--------+ +--------+ 698 | shared | | shared | 699 | context| | context| 700 | | | | 701 | /sf | | /sf | 702 | /cr | | /cr | 703 | /auth | | /auth | 704 | /mac16 | | /mac16 | 705 | /mac64 | | /mac64 | 706 | | | | 707 | /mg | | /mg | 708 | ... | | ... | 709 +--------+ +--------+ 711 Node-F and Node-G have a shared context. Upon modification (e.g. the 712 operator changes the spreading factor /sf of the Node-F at the Node- 713 G), the Node-G will update the value on the Node-F with a CoaP PUT or 714 a CoAP GET OBSERVE [I-D.ietf-core-observe] message. 716 Figure 11 718 4. Acknowledgements 720 5. IANA Considerations 722 This memo includes no request to IANA. 724 6. Security Considerations 726 All drafts are required to have a security considerations section. 727 See RFC 3552 [RFC3552] for a guide. 729 7. References 731 7.1. Normative References 733 [I-D.garcia-core-security] 734 Garcia-Morchon, O., Kumar, S., Keoh, S., Hummen, R., and 735 R. Struik, "Security Considerations in the IP-based 736 Internet of Things", draft-garcia-core-security-06 (work 737 in progress), September 2013. 739 [I-D.ietf-core-observe] 740 Hartke, K., "Observing Resources in CoAP", draft-ietf- 741 core-observe-16 (work in progress), December 2014. 743 [I-D.tcs-coap-no-response-option] 744 Bhattacharyya, A., Bandyopadhyay, S., and A. Pal, "CoAP 745 option for no server-response", draft-tcs-coap-no- 746 response-option-11 (work in progress), June 2015. 748 [I-D.vanderstok-core-comi] 749 Stok, P., Greevenbosch, B., Bierman, A., Schoenwaelder, 750 J., and A. Sehgal, "CoAP Management Interface", draft- 751 vanderstok-core-comi-06 (work in progress), February 2015. 753 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 754 Requirement Levels", BCP 14, RFC 2119, March 1997. 756 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 757 Application Protocol (CoAP)", RFC 7252, June 2014. 759 7.2. Informative References 761 [IEEE.802-15.4k] 762 Institute of Electrical and Electronics Engineers, "Low- 763 Rate Wireless Personal Area Networks (LR-WPANs) - 764 Amendment 5: Physical Layer Specifications for Low Energy, 765 Critical Infrastructure Monitoring Networks., IEEE 766 802.15.4k", IEEE Standard 802.15.4, 2013. 768 [LoRa] Semtech, "https://web.archive.org/web/20150510011904/ 769 https://www.semtech.com/wireless-rf/lora.html", May 2015. 771 [LTN001] European Telecommunications Standards Institute, "Low 772 Throughput Networks (LTN); Use Cases for Low Throughput 773 Networks, ETSI GS LTN 001", IEEE ETSI GS LTN 001, 2014. 775 [LTN003] European Telecommunications Standards Institute, "Low 776 Throughput Networks (LTN); Protocols and Interfaces, ETSI 777 GS LTN 003", IEEE ETSI GS LTN 003, 2014. 779 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 780 Text on Security Considerations", BCP 72, RFC 3552, July 781 2003. 783 [SigFox] SigFox, "https://web.archive.org/web/20150628225901/ 784 http://www.sigfox.com/en/#!/technology", June 2015. 786 Authors' Addresses 788 Alexander Pelov (editor) 789 Acklio 790 2 Rue de la Chataigneraie 791 Cesson-Sevigne, Bretagne 35510 792 FR 794 Phone: +33299127004 795 Email: a@ackl.io 797 Laurent Toutain (editor) 798 Telecom Bretagne 799 2 Rue de la Chataigneraie 800 Cesson-Sevigne, Bretagne 35510 801 FR 803 Phone: +33299127026 804 Email: laurent.toutain@telecom-bretagne.eu 805 Yannick Delibie (editor) 806 Kerlink 807 1 rue Jacqueline Auriol 808 Thorigne-Fouillard, Bretagne 35235 809 FR 811 Phone: +33299122900 812 Email: yannick.delibie@kerlink.fr