| Internet Engineering Task Force | A. Pelov, Ed. |
| Internet-Draft | Acklio |
| Intended status: Informational | L. Toutain, Ed. |
| Expires: August 20, 2016 | Institut MINES-TELECOM ; TELECOM Bretagne |
| Y. Delibie, Ed. | |
| Kerlink | |
| February 17, 2016 |
Constrained Signaling Over LP-WAN
draft-pelov-core-cosol-01
This document presents a new type of long-range, low-rate radio technologies and an extensible mechanism to operate these networks based on CoAP. The emerging Low-Power Wide-Area Networks (LP-WAN) present a particular set of constraints, which places them at the intersection of infrastructure networks, ultra-dense networks, delay-tolerant networks and low-power and lossy networks. The main objectives of LP-WAN signaling is to minimize the number of exchanged messages, minimize the size of each message in a secure and extensible manner, all with keeping the fundamental principle of technology-independence (L2-independence). This document describes the use of the Constrained Application Protocol (CoAP) as the main signaling protocol for LP-WAN, over which minimal messages are exchanged allowing the full operation of the network, such as authentication, authorization, and management. The use of CoAP signaling provides a generic mechanism that can be applied to different LP-WAN technologies.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 20, 2016.
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
The goal of this document is to provide the necessary mechanisms to operate a Low-Power Wide-Area Network (LP-WAN) by using IETF CoAP [RFC7252] as a core signaling protocol.
Long-range, low-rate radio technologies have emerged in the past several years, and are the base for building LP-WANs. LP-WANs generally have the following characteristics:
LP-WANs are built on radio communication technologies, which use advanced signal processing techniques and combination of appropriate modulation and coding approaches to provide the aforementioned radio characteristics.
The absence of license fees and the far-reaching connectivity allow for an extremely competitive pricing of LP-WANs compared to other networking technologies, e.g. cellular or mesh. LP-WANs are sometimes referred to as LPWA or LR-WAN (Low-Rate WAN). Even though LP-WANs are extremely limited in terms of network performance, they are enough for a wide class of applications, among which [LTN001]:
The IEEE is studying LP-WANs, but limited to the case of low-energy critical infrastructure monitoring (LECIM), under the group IEEE 802.15.4k [IEEE.802-15.4k].
The combination of the above characteristics and the envisioned applications define a new class of networks with the following unique constraints:
CoAP is a client-server protocol specialized for constrained networks and devices. CoAP is highly optimized, extensible, standard protocol, which in conjunction with the Concise Binary Object Representation (CBOR) is the ideal candidate for the signaling protocol of the control plane of an LP-WAN.
It can be used during all stages of the lifecycle of the network, e.g. discovery, authentication, operation. Furthermore, this can be achieved by following RESTful management paradigm, by using a particular resource tree definition or adopting COOL [I-D.veillette-core-cool].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
There are two classes of LP-WAN radio technologies, using different radio modulation approaches:
An example of UNB is the technology developed and promoted by SigFox [SigFox]. Semtech LoRa [LoRa] uses a direct-sequence spread-spectrum with orthogonal codes (OSSS).
Both approaches have their advantages and will coexist in the future, as there are currently several operators, which deploy the two types in the same areas.
At the physical layer, the important part is the possibility to reconstruct the signal at long distances. The used ISM bands are defined around the world (e.g. 868 MHz in Europe and 900 MHz in USA) and require a 1% (or 10%) duty cycling, or alternatively - advanced detection and channel reallocation techniques. In reality, all deployed networks use the duty cycling limitation, with the following distinction. There is one 100kHz band in which 10% duty cycling is allowed, with a slightly more emission power. The rest of the bands are limited at 1% duty cycling and very restricted power of emission (e.g. 25 mW in Europe).
UNB LP-WANs make the distinction between Uplink and Downlink, first depending on the modulation, and second with the 10% duty-cycling channel been used for the Downlink. OSSS LP-WANs make no such distinction, although for the operation of a network, an operator can chose to use the same Uplink/Downlink channel separation.
Note that the 1% or 10% duty-cycle limitation counts for all trafic originating from an electronic equipment, e.g. an antena managing 100k objects must obey the same limitation as an end-device, with all frames emitted from the antena (data, acknowledgements) counting towards its quota.
Ultra Narrowband (UNB) technologies generally possess the following physical layer characteristics [LTN003]:
OSSS technologies possess the following physical layer characteristics [LTN003]:
No particular distinction is made between the Uplink and the Downlink.
Several proprietary MAC frame formats exist for UNB and OSSS. However, they are designed to operate the network in a centralized, highly-vertically-integrated fashion. The only standard MAC frame format is the IEEE 802.15.4k, which is based on the well-known IEEE 802.15.4 with the addition of a fragmentation sub-layer.
The channel access method is based on ALOHA, although it is up to the network operator to chose if an appropriate end-node polling should be implemented.
We can identify three types of entities in a typical LP-WAN. These are:
+--------+ +--------+ +--------+
| Node-F | <-- LP-WAN radio --> | Node-R | <-- IP --> | Node-G |
+--------+ +--------+ +--------+
General architecture of an LP-WAN. LP-WAN radio technology is used only between the Node-F and the Node-R.
Figure 1
Of these, only Node-F and Node-R communicate through an LP-WAN radio technology. However, due to the extreme constraints of these technologies, they are always behind a gateway (Node-G). Note, that the Node-R and Node-G can be collocated, e.g. on a single hardware equipment.
The Node-G is connected to the Internet and is assumed to have sufficient computational resources to store a context for each of the Node-Fs. The strong limitation here is the radio link.
In an actual deployment, a (limited) set of Node-Rs cover a large area with a potentially very-high number of Node-Fs. A single Node-G is capable of controlling all Node-Rs.
o
o o
o (((*)))-------\
o o |
o o |
o (((*)))---------------+------Node-G
o o |
o o |
o (((*)))-------------------+
o |
o o o o |
o (((*)))-----------/
o o
o o
o = Node-F
(((*))) = Node-R
An example coverage of an area with several Node-Rs. Note that a single Node-F may be covered by several Node-Rs.
Figure 2
Similar to other wireless infrastructure-based technologies, a Node-F can go through several stages:
The Node-F state machine is then the following:
+------------------------------------------------------+
| |
V |
Semi-associated |
| |
V |
Disconnected <-> Network discovery -> Associated -> Authenticated
^ | |
| | |
+------------------------------------------------------+
Node-F connectivity state machine.
Figure 3
The Node-F can be in Semi-Associated mode. Upon start, and depending on the application, a Node-F can use a state of uni-directional communication, where it is considered semi-associated to the network. In that state, the Node-F broadcasts frames, handled by the Node-G, but the network cannot join the Node-F on a regular basis. This is a degraded LP-WAN operating mode and if caution is not used, can lead to significant scalability and evolvability issues.
The Network Discovery can be reactive or proactive. The former is based on detecting beacon frames sent periodically by the network (e.g. Node-G). The latter is implemented by the Node-F broadcasting probe request frames, to which all appropriate Node-Gs must respond.
Once a network has been discovered, the Node-F can associate to the network. The association creates the necessary (minimal) context on the Node-G, which initiates the authentication of the Node-F
The authentication is initiated by the Node-G, which should allow for the necessary AAA exchanges to take place. If the authentication is successful, the Node-F enters the Authenticated state. In this stage there is bi-directional communication between the Node-F and the Node-G. If the authentication is not successful, the Node-F enters Disconnected state. Once in Authenticated state, the Node-F can downgrade its connectivity to Semi-Associated mode.
The management of the node in Authenticated state is performed with COOL [I-D.veillette-core-cool]. As an example, managing the parameters of a Semtech LoRa device can be achieved through the use of the YANG module defined in [I-D.pelov-yang-lora]
Finally, the Node-F may decide to dissociate from the network by sending an explicit request. Upon dissociation the Node-G may release all contexts related to the Node-F and re-association requires going through the authentication stage again. Node mobility is achieved by explicitly dissociating from the old Node-G and then authenticating to the new Node-G. Implicit dissociation is also possible upon the expiration of predefined timers, or in case of mobility optimization.
Use as CoAP for signaling is implemented as follows. The MAC, network and/or transport layers MUST provide a mechanism to differentiate user data from signaling data frames (e.g. by using separate MAC addresses, IP addresses and/or UDP-ports). Both the Node-G and the Node-F are running CoAP servers for implementing the control plane. Frames exchanged over the LP-WAN radio interface and marked as "signaling data" are handled by the corresponding control plane CoAP servers.
The Node-G runs a (virtual) CoAP server for each Node-F. This server is identified with a DNS name, e.g. "node123.home.node-g.example.com", which can be used explicitly in the CoAP messages via the Proxy-Uri option if needed.
Note, that the Node-R acts only as a transceiver and as such is transparent from protocol point of view. As such, the following management scheme applies:
+--------+ +--------+
| Node-F | <-- LP-WAN constraints --> | Node-G |
+--------+ +--------+
Node-F connectivity from protocol point of view.
Figure 4
When in a semi-associated state, a Node-F broadcasts its messages without performing network discovery, or association. If the Node-F is under the coverage of a Node-G, the Node-G will receive the broadcast, and forward the user data. The frames SHOULD be signed, so that they could be authenticated by the network. Layer 2 acknowledgements MUST be used, and in some cases piggybacking on them can provoke the Node-F to associate to the network.
The broadcast messages MUST include the necessary information to join the user data destination, and enough information for the Node-G to authenticate the message sender. This can be achieved through a Confirmable CoAP message, where the user data are POSTed to a well-known resource defined on the Node-G. DTLS with integrity check can be used, with long-lived keys negotiated by the Node-F and the network. Alternatively, COSE objects may provide the necessary mechanisms.
Even though an application can be implemented by using only simplex association capabilities, there are non-negligible negative consequences related to scalability and evolvability in this case. For example, a Node-F which periodically broadcasts information will occupy the spectrum, even if there is no operator willing to accept its trafic. In addition, no channel access management can be applied.
Node-F Node-G
| |
| |
+--------->| Header: POST
| POST | Uri-Host: "destination.example.com"
| | Uri-Path: "temp"
| |
| |
|<---------+ Header: 2.01 Created
| 2.01 |
| |
| |
Sending a message in a semi-associated state.
Figure 5
A network can be discovered by a Node-F reactively or proactively.
Reactive network discovery is based on the detection of periodic beacons emitted by the Node-G. The beacons are implemented with CoAP messages with the No-Response option [I-D.tcs-coap-no-response-option]. The Node-G POSTs its information to a well-known resource, e.g. "/network/node-G/" or a resource alias "/g". Alternatively, this could be achieved by POST-ting to a COOL container (e.g. POST /cool with data node ID = 1 for example).
Node-F Node-G
| |
| |
|<---------+ Header: POST
| POST /g | Uri-Path: "g"
| | [No-Responce]
| |
| |
Reactive network discovery. The Node-G sends periodically beacon messages, containing information pertinent to this network.
Figure 6
The CoAP POST request is processed at the Node-F. A resource is created locally, with the representation, which provides the appropriate network parameters, e.g. network ID, Node-G ID, and other radio-related parameters, such as channel, beacon frequency and so forth. This information allows the Node-F to begin the authentication phase.
A Node-F may chose to proactively probe for the existence of network coverage. In that case, it sends a Confirmable CoAP GET request to obtain the information from a well-known resource, normally published by the beacon messages, e.g. "/network/node-G/" or a resource alias "/g" or COOL data node ID ("/cool" data node ID = 2 for example).
Node-F Node-G
| |
| |
+--------->| Header: GET
| GET /g | Uri-Path: "g"
| | Accept: application/cbor
| |
| |
|<---------+ Header: 2.05 Content
| 2.05 | Payload: ...
| |
Proactive network discovery. The Node-F request the information of all surrounding Node-Gs.
Figure 7
Once the network is discovered, the Node-F has all necessary information to start the authentication phase.
Before being able to communicate, the Node-F must associate to the network, and then eventually authenticate. The association phase signals to the Node-G that there is a new device willing to communicate with the network. This association SHOULD provide enough information to allow the Node-G to start the authentication process. For example, it may provide the AAA server, which could authenticate the Node-F, or its EAP-Identity. Note, that the Node-F may elect to mark the association message with the No-response option [I-D.tcs-coap-no-response-option], waiting for the subsequent authentication request from the Node-G.
Node-F Node-G
| |
| |
+--------->| Header: POST
| POST /n | Uri-Path: "n"
| | Payload: ...
| |
|<---------+ Header: 2.01 Created
| 2.01 | Location-Path: "/n/n705"
| |
Node-F associates to a network, by creating a corresponding resource element on the Node-G.
Figure 8
The EAP-over-CoAP [I-D.marin-ace-wg-coap-eap] specifies an approach to encapsulating EAP messages over CoAP. This allows to authenticate a Node-F, which wishes to join an LP-WAN, and negotiate the L2 encryption keys, and DTLS keying material.
As the Node-F has already associated to the Node-G, it is the Node-G that initiates the authentification request, by going directly to Step 1) of the EAP-over-CoAP specification.
Node-F Node-G
| |
| |
1) |<-----------+ Header: POST
| POST /auth | Uri-Path: "auth"
| | [No-Responce]
| |
| |
2) +----------->| Header: 2.01 Created
| ACK /auth | Location-Path: "/auth/5"
| |
| |
| |
3) |<-----------+ Header: PUT
| PUT /auth/5| Uri-Path: "auth/5"
| | Payload: EAP-PSK MSG 1
| |
| |
4) +----------->| Header: 2.04 Changed
| ACK /auth/5| Payload: EAP-PSK MSG 2
| |
......
Node-F and Node-G perform mutual authentication following EAP-over-CoAP.
Figure 9
Upon the end of the authentication phase, a Master Shared Key (MSK) is known by the Node-F and the Node-G, and is used to generate DTLS encryption or integrity keys. Further communications should be encrypted/signed with the freshly derived keys.
Once the Node-F is authenticated to the network, it can send user data via the Node-G to any other end-point on the Internet.
During the operation of the Node-F, the network may need to change one or more parameters concerning the LP-WAN radio parameters of the Node-F. These changes may even concern parameters related to the Node-F itself (such as sleep cycles), its network parameters (e.g. IP addresses), and so forth. This is achieved through the use of COOL [I-D.veillette-core-cool]. The appropriate YANG modules must be present on the Node-F (e.g. a Semtech LoRa Node-F should implement the [I-D.pelov-yang-lora] module).
Node-F Node-G
| |
| |
|<-----------+ Header: PUT
| PUT /cool | Uri-Path: "cool"
| | Payload: {5:10,6:2}
| |
| |
+----------->| Header: 2.04 Changed
| 2.04 |
| |
Example, in which the Node-G changes the Spreading Factor (e.g. COOL data node ID = 5) to 10, and the Channel (e.g. COOL data node ID = 6) to 2. Note, that the payload is encoded in CBOR.
Figure 10
If the Node-F wishes to deregister from the network, it could do so by deleting the context created upon association:
Node-F Node-G
| |
| |
+--------------->| Header: POST
| DELETE /n/n705 | Uri-Path: "n/n705"
| |
| |
|<---------------+ Header: 2.02 Deleted
| 2.02 |
| |
Node-F dissociates from the network by deleting its associated resources.
Figure 11
This memo includes no request to IANA.
All drafts are required to have a security considerations section. See RFC 3552 [RFC3552] for a guide.
| [I-D.ietf-core-observe] | Hartke, K., "Observing Resources in CoAP", Internet-Draft draft-ietf-core-observe-16, December 2014. |
| [I-D.marin-ace-wg-coap-eap] | Garcia, D., "EAP-based Authentication Service for CoAP", Internet-Draft draft-marin-ace-wg-coap-eap-01, October 2014. |
| [I-D.pelov-yang-lora] | Pelov, A., Toutain, L., Delibie, Y. and A. Minaburo, "YANG module for LoRa Networks", Internet-Draft draft-pelov-yang-lora-00, December 2015. |
| [I-D.tcs-coap-no-response-option] | Bhattacharyya, A., Bandyopadhyay, S., Pal, A. and T. Bose, "CoAP option for no server-response", Internet-Draft draft-tcs-coap-no-response-option-13, November 2015. |
| [I-D.veillette-core-cool] | Veillette, M. and A. Pelov, "Constrained Objects Language", Internet-Draft draft-veillette-core-cool-00, November 2015. |
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [RFC7252] | Shelby, Z., Hartke, K. and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014. |
| [IEEE.802-15.4k] | Institute of Electrical and Electronics Engineers, "Low-Rate Wireless Personal Area Networks (LR-WPANs) - Amendment 5: Physical Layer Specifications for Low Energy, Critical Infrastructure Monitoring Networks., IEEE 802.15.4k", IEEE Standard 802.15.4, 2013. |
| [LoRa] | Semtech, "https://web.archive.org/web/20150510011904/https://www.semtech.com/wireless-rf/lora.html", May 2015. |
| [LTN001] | European Telecommunications Standards Institute, "Low Throughput Networks (LTN); Use Cases for Low Throughput Networks, ETSI GS LTN 001", IEEE ETSI GS LTN 001, 2014. |
| [LTN003] | European Telecommunications Standards Institute, "Low Throughput Networks (LTN); Protocols and Interfaces, ETSI GS LTN 003", IEEE ETSI GS LTN 003, 2014. |
| [RFC3552] | Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, DOI 10.17487/RFC3552, July 2003. |
| [SigFox] | SigFox, "https://web.archive.org/web/20150628225901/http://www.sigfox.com/en/#!/technology", June 2015. |