Internet DRAFT - draft-birkholz-yang-push-coap-problemstatement
draft-birkholz-yang-push-coap-problemstatement
SACM Working Group H. Birkholz
Internet-Draft Fraunhofer SIT
Intended status: Informational T. Zhou
Expires: April 21, 2018 Huawei
X. Liu
Jabil
E. Voit
Cisco Systems
October 18, 2017
YANG Push Operations for CoMI
draft-birkholz-yang-push-coap-problemstatement-00
Abstract
This document provides a problem statement, derives an initial gap
analysis and illustrates a first set of solution approaches in regard
to augmenting YANG data stores based on the CoAP Management Interface
with YANG Push capabilities. A binary transfer mechanism for YANG
Subscribed Notifications addresses both the requirements of
constrained-node networks and the need for semantic interoperability
via self-descriptiveness of the corresponding data in motion.
Status of This Memo
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 https://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 April 21, 2018.
Copyright Notice
Copyright (c) 2017 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
Birkholz, et al. Expires April 21, 2018 [Page 1]
Internet-Draft CoMI Push October 2017
(https://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.
Table of Contents
1. Context of the Problem . . . . . . . . . . . . . . . . . . . 2
1.1. Binary YANG transfer protocol . . . . . . . . . . . . . . 3
1.2. Device-Type Scope . . . . . . . . . . . . . . . . . . . . 3
1.3. Subscriptions via CoAP . . . . . . . . . . . . . . . . . 3
1.4. Configured Subscriptions and Call-Home . . . . . . . . . 4
1.5. Bootstrapping of Drop-Shipped Pledges . . . . . . . . . . 4
2. Summary of the Problem Statement . . . . . . . . . . . . . . 5
3. Potential Approaches and Solutions . . . . . . . . . . . . . 6
3.1. YANG subscription variants . . . . . . . . . . . . . . . 6
3.2. YANG Push via CoAP . . . . . . . . . . . . . . . . . . . 6
3.3. Dynamic Subscriptions . . . . . . . . . . . . . . . . . . 7
3.3.1. YANG Push via GET . . . . . . . . . . . . . . . . . . 7
3.3.2. YANG Push via FETCH . . . . . . . . . . . . . . . . . 7
3.4. Configured Subscriptions . . . . . . . . . . . . . . . . 7
3.4.1. Retaining the Content of a GET Operation as
Configuration . . . . . . . . . . . . . . . . . . . . 7
3.4.2. Call Home via CoAP . . . . . . . . . . . . . . . . . 8
3.4.3. Dynamic Home Discovery . . . . . . . . . . . . . . . 8
4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 8
8. Normative References . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Context of the Problem
A binary transfer capability for YANG Subscribed Notifications
[I-D.ietf-netconf-subscribed-notifications] based on YANG Push
[I-D.ietf-netconf-yang-push] can be realized by using existing RFC
and I-D work as building blocks. This section is intended to provide
a corresponding overview of the existing ecosystem in order to
identify gaps and therefore provide a problem statement.
Birkholz, et al. Expires April 21, 2018 [Page 2]
Internet-Draft CoMI Push October 2017
1.1. Binary YANG transfer protocol
The CoAP Management Interface I-D (CoMI [I-D.ietf-core-comi]) defines
operations for a YANG data store based on the Constrained Application
Protocol (CoAP [RFC7252]). CoAP uses a request/response interaction
model that is based on HTTP (similar to RESTCONF [RFC8040]) and
allows for multiple transports, including UDP or TCP (see
[I-D.ietf-core-coap-tcp-tls]). The Concise Binary Object
Representation (CBOR [RFC7049]) is used for the serialization of data
in motion in respect to CoAP operations and the data modeled with
YANG [I-D.ietf-core-yang-cbor].
1.2. Device-Type Scope
[I-D.ietf-core-comi] states that CoAP "is designed for Machine to
Machine (M2M) applications such as smart energy, smart city and
building control. Constrained devices need to be managed in an
automatic fashion to handle the large quantities of devices that are
expected in future installations. Messages between devices need to
be as small and infrequent as possible. The implementation
complexity and runtime resources need to be as small as possible."
In addition, [I-D.ietf-core-comi] highlights that "CoMI and RESTCONF
are intended to work in a stateless client-server fashion. They use
a single round-trip to complete a single editing transaction, where
NETCONF needs up to 10 round trips. To promote small messages, CoMI
uses a YANG to CBOR mapping [I-D.ietf-core-yang-cbor] and numeric
identifiers [I-D.ietf-core-sid] to minimize CBOR payloads and URI
length."
In essence, via CoMI, a small sensor can emit a set of measurements
as binary encoded YANG notifications, which would only add a minimal
overhead to the data in motion, but would increase interoperability
significantly due to the powerful and widely used semantics enabled
by YANG (in contrast to a set of raw values that always require
additional context information and imperative guidance to be managed
and post-processed appropriately).
1.3. Subscriptions via CoAP
The CoAP pub/sub I-D defines a CoAP Subscribe operation
[I-D.ietf-core-coap-pubsub] that is based on observing resources via
the Observe option for the GET operation as defined in [RFC7641].
The CoAP pub/sub draft is intended to provide the capabilities and
characteristics of MQTT via a CoAP based protocol. The only other
CoAP operation that supports the Observe option is the FETCH
operation defined in [RFC8132].
Birkholz, et al. Expires April 21, 2018 [Page 3]
Internet-Draft CoMI Push October 2017
The Observe option creates a small corresponding state on the server
side that eliminates the need for continuous polling of a resource
via subsequent requests. Instead, subsequent responses including
both the Observe option and using the token of the request that
initiated the observation are returned when the observed resource
changes. A subscription (i.e. the observe state retained on the
server) can be discarded by the client by sending a correspond CoAP
GET with Observe using an Observe parameter of 1 or simply by
"forgeting" the observation and return a CoAP Reset after receiving a
notification in the context of the subscription. A subscription can
also be discarded by the server by sending a corresponding response
that does not contain an Observe option.
The subscription used in CoAP pub/sub are used to subscribe to a
topic provided by a CoAP broker REST API. YANG Push
[I-D.ietf-netconf-yang-push] and corresponding YANG Subscribed
Notifications are used to subscribe to data node updates provided by
a YANG management interface. YANG subscriptions can include a filter
expression (either a subtree expression or an XPATH expression). The
encoding rules of XPATH expressions in CBOR are covered by
[I-D.ietf-core-yang-cbor].
1.4. Configured Subscriptions and Call-Home
Configured subscriptions are basically static configuration that
creates subscription state on the YANG data store when it is started
and persists between boot-cycles without the need of a client to
create that subscription state. In consequence, a configured
subscription can result in unsolicited pushed notifications in
respect to a YANG client.
A popular variant of the configured subscription as defined in
[I-D.ietf-netconf-yang-push] is the Call Home procedure defined in
[RFC8071]. In this approach, a Transport Layer application
association with the YANG client is initiated by the YANG data store.
After this "initial phase, in which the YANG server is acting like a
client", the existing Transport Layer connection (or session, in case
of, for example, TLS) is then used to the YANG client to initiate a
subscription (i.e. the YANG client is initiating a dynamic
subscription based on a pre-configured request retained and issued by
the YANG data store).
1.5. Bootstrapping of Drop-Shipped Pledges
[I-D.ietf-anima-bootstrapping-keyinfra] highlights that effectively
"to literally 'pull yourself up by the bootstraps' is an impossible
action. Similarly, the secure establishment of a key infrastructure
without external help is also an impossibility."
Birkholz, et al. Expires April 21, 2018 [Page 4]
Internet-Draft CoMI Push October 2017
According to [I-D.ietf-anima-bootstrapping-keyinfra] the
bootstrapping approach Call-Home has problems and limitations, which
(amongst others) the draft itself is trying to address:
o the pledge requires realtime connectivity to the vendor service
o the domain identity is exposed to the vendor service (this is a
privacy concern)
o the vendor is responsible for making the authorization decisions
(this is a liability concern)
A Pledge in the context of [I-D.ietf-anima-bootstrapping-keyinfra] is
"the prospective device, which has an identity installed by a third-
party (e.g., vendor, manufacturer or integrator)."
A Pledge can be "drop-shipped", which refers to "the physical
distribution of equipment containing the 'factory default'
configuration to a final destination. In zero-touch scenarios there
is no staging or pre-configuration during drop-ship."
In the scope of Call-Home as a part of YANG Push, either the factory
default configuration of a drop-shipped Pledge that is a YANG data
store would require to include the "home to Call Home" configuration
or it has to be configured locally.
[I-D.ietf-netconf-zerotouch] is intended to provide more flexibility
to the Call-Home procedure already - by allowing to stage connection
attempts to a locally administered network and if that fails fall
back to connecting to a remotely administered network. Alas,
[I-D.ietf-netconf-zerotouch] is either prone to the same limitations
as cited above or requires local configuration in order to find the
home to Call-Home.
The "Join Registrar" defined by
[I-D.ietf-anima-bootstrapping-keyinfra] mitigates the cited problems
and limitation by introducing "a representative of the domain that is
configured, perhaps autonomically, to decide whether a new device is
allowed to join the domain. The administrator of the domain
interfaces with a Join Registrar (and Coordinator) to control this
process. Typically a Join Registrar is "inside" its domain."
2. Summary of the Problem Statement
Currently, the following gaps are identified:
o no CoAP Subscribe procedure for dynamic YANG subscriptions is
standardized that is able to convey a filter expression and
Birkholz, et al. Expires April 21, 2018 [Page 5]
Internet-Draft CoMI Push October 2017
potentially other metadata required in the context of a YANG
Subscribed Notifications application association. Analogously,
new payload types (e.g. a FETCH payload media-type) have to be
defined.
o no CoAP Call Home feature is standardized to support a popular
variant of configured YANG subscriptions.
o no general Call Home mechanism is standardized that enables the
discovery of "a home to Call Home" or that would be able to deal
with "changing homes" in a dynamic but secure manner.
In addition to the identified gaps, the semantics of metadata - if
there are any - that have to be conveyed to or from a YANG data store
in order to subscribe to a (filtered) YANG module or data node are
not identified.
The problem statement could be summarized as follows:
"There is no complete solution based on CoAP to enable a freshly
unpacked YANG data store ("drop-shipped pledge", e.g. the cliche
light bulb) to discover an appropriate home it can than Call-Home to
in a secure and trusted manner in order to push (un-)solicited
subscribed notifications."
3. Potential Approaches and Solutions
There are multiple approaches that could lead to viable solutions
that address the identified gaps. The following sections illustrate
the general solution context and some of the most promising
approaches.
3.1. YANG subscription variants
A YANG Push update subscription service both provides support for
dynamic subscription (i.e. subscription state created by a client
request, allowing for solicited push notifications in the context of
an up-time cycle of the server) and configured subscription (i.e.
subscription configuration retained on the server, allowing for
unsolicited push notifications across up-time cycles of the server).
3.2. YANG Push via CoAP
The two CoAP operations that enable a subscription mechanism are GET
and FETCH (i.e. by supporting the Observe option). Both operations
are viable candidates for creating a CoAP-based YANG Push mechanism
for CoMI.
Birkholz, et al. Expires April 21, 2018 [Page 6]
Internet-Draft CoMI Push October 2017
3.3. Dynamic Subscriptions
Using CoAP, the client issuing the initial subscription request
creates the subscription state. Examples are the GET or FETCH
operation including an Observe option using an Observe parameter of 0
(zero).
3.3.1. YANG Push via GET
This usage scenario requires two consecutive operations. It is not
possible to transfer a filter expression included in a GET operation.
In consequence, a POST operation on a collection resource has to be
conducted in order to convey a filter expression to the YANG data
store, allowing it to return an URI that contains the data node
information filtered in respect to the posted filter expression
(encoded in CBOR).
This variant allows for multiple clients to observe a specific
filtered data node without conducting a POST operation, if the
corresponding URI is made known to other clients that did not conduct
the POST operation or, for example, is canonically linked to/
derivable from a filter expression.
3.3.2. YANG Push via FETCH
This usage scenario requires only one operation. A FETCH operation
can include a body that is capable to contain a filter expression and
potentially other metadata that might be required to establish a
suitable subscription state on the YANG data store.
It might be possible that this variant could introduce a slight delay
in respect to response time if providing a filtered resource requires
a lot of computation time on a constrained device. I.e. the resource
cannot be prepared "beforehand".
3.4. Configured Subscriptions
Using CoAP, the server retains configuration that creates
subscription state when the YANG data store is started. The client
has to have or gain knowledge of the CoAP tokens that are included in
the responses created in the context of the subscription state create
from server configuration.
3.4.1. Retaining the Content of a GET Operation as Configuration
This usage scenario "mimics" the receiving of a subscription request
by storing the corresponding information that are relevant for
creating a subscription state as configuration on the YANG data
Birkholz, et al. Expires April 21, 2018 [Page 7]
Internet-Draft CoMI Push October 2017
store. I.e. the configuration would be including the YANG client IP
address and the CoAP token to be used in the responses that convey
the subscribed notifications.
This variant requires that the client also knows or gains knowledge
of the corresponding CoAP token in order to not discard the incoming
responses.
3.4.2. Call Home via CoAP
This usage scenario defines the Call Home procedure standardized in
[RFC8071] as an additional capability of CoAP. DTLS or TLS state is
initiated by the YANG data store and triggers a dynamic subscription
procedure of the YANG client using the session initiated by the YANG
data store.
3.4.3. Dynamic Home Discovery
This usage scenario is based on the Bootstrapping Remote Secure Key
Infrastructures I-D [I-D.ietf-anima-bootstrapping-keyinfra] and EST
over secure CoAP I-D [I-D.vanderstok-ace-coap-est] and requires the
standardization of a general use of Join Registrars in the context of
YANG data stores that support YANG Push via static subscriptions.
4. IANA considerations
This document includes no requests to IANA, but solutions drafts
incubated via this document might.
5. Security Considerations
This document includes no security considerations, but solution
drafts incubated via this document will.
6. Acknowledgements
Carsten Bormann, Klaus Hartke, Michel Veillette
7. Change Log
First version -00
8. Normative References
Birkholz, et al. Expires April 21, 2018 [Page 8]
Internet-Draft CoMI Push October 2017
[I-D.ietf-anima-bootstrapping-keyinfra]
Pritikin, M., Richardson, M., Behringer, M., Bjarnason,
S., and K. Watsen, "Bootstrapping Remote Secure Key
Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping-
keyinfra-08 (work in progress), October 2017.
[I-D.ietf-core-coap-pubsub]
Koster, M., Keranen, A., and J. Jimenez, "Publish-
Subscribe Broker for the Constrained Application Protocol
(CoAP)", draft-ietf-core-coap-pubsub-02 (work in
progress), July 2017.
[I-D.ietf-core-coap-tcp-tls]
Bormann, C., Lemay, S., Tschofenig, H., Hartke, K.,
Silverajan, B., and B. Raymor, "CoAP (Constrained
Application Protocol) over TCP, TLS, and WebSockets",
draft-ietf-core-coap-tcp-tls-09 (work in progress), May
2017.
[I-D.ietf-core-comi]
Veillette, M., Stok, P., Pelov, A., and A. Bierman, "CoAP
Management Interface", draft-ietf-core-comi-01 (work in
progress), July 2017.
[I-D.ietf-core-sid]
Veillette, M., Pelov, A., Turner, R., Minaburo, A., and A.
Somaraju, "YANG Schema Item iDentifier (SID)", draft-ietf-
core-sid-01 (work in progress), May 2017.
[I-D.ietf-core-yang-cbor]
Veillette, M., Pelov, A., Somaraju, A., Turner, R., and A.
Minaburo, "CBOR Encoding of Data Modeled with YANG",
draft-ietf-core-yang-cbor-05 (work in progress), August
2017.
[I-D.ietf-netconf-subscribed-notifications]
Voit, E., Clemm, A., Prieto, A., Nilsen-Nygaard, E., and
A. Tripathy, "Custom Subscription to Event Notifications",
draft-ietf-netconf-subscribed-notifications-05 (work in
progress), October 2017.
[I-D.ietf-netconf-yang-push]
Clemm, A., Voit, E., Prieto, A., Tripathy, A., Nilsen-
Nygaard, E., Bierman, A., and B. Lengyel, "Subscribing to
YANG datastore push updates", draft-ietf-netconf-yang-
push-10 (work in progress), October 2017.
Birkholz, et al. Expires April 21, 2018 [Page 9]
Internet-Draft CoMI Push October 2017
[I-D.ietf-netconf-zerotouch]
Watsen, K., Abrahamsson, M., and I. Farrer, "Zero Touch
Provisioning for NETCONF or RESTCONF based Management",
draft-ietf-netconf-zerotouch-17 (work in progress),
September 2017.
[I-D.vanderstok-ace-coap-est]
Kumar, S., Stok, P., Kampanakis, P., Furuhed, M., and S.
Raza, "EST over secure CoAP (EST-coaps)", draft-
vanderstok-ace-coap-est-02 (work in progress), June 2017.
[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
October 2013, <https://www.rfc-editor.org/info/rfc7049>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014,
<https://www.rfc-editor.org/info/rfc7252>.
[RFC7641] Hartke, K., "Observing Resources in the Constrained
Application Protocol (CoAP)", RFC 7641,
DOI 10.17487/RFC7641, September 2015,
<https://www.rfc-editor.org/info/rfc7641>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>.
[RFC8071] Watsen, K., "NETCONF Call Home and RESTCONF Call Home",
RFC 8071, DOI 10.17487/RFC8071, February 2017,
<https://www.rfc-editor.org/info/rfc8071>.
[RFC8132] van der Stok, P., Bormann, C., and A. Sehgal, "PATCH and
FETCH Methods for the Constrained Application Protocol
(CoAP)", RFC 8132, DOI 10.17487/RFC8132, April 2017,
<https://www.rfc-editor.org/info/rfc8132>.
Authors' Addresses
Henk Birkholz
Fraunhofer SIT
Rheinstrasse 75
Darmstadt 64295
Germany
Email: henk.birkholz@sit.fraunhofer.de
Birkholz, et al. Expires April 21, 2018 [Page 10]
Internet-Draft CoMI Push October 2017
Tianran Zhou
Huawei
156 Beiqing Rd.
Beijing, Haidian District
China
Email: zhoutianran@huawei.com
Xufeng Liu
Jabil
8281 Greensboro Drive, Suite 200
McLean VA 22102
USA
Email: Xufeng_Liu@jabil.com
Eric Voit
Cisco Systems
Email: evoit@cisco.com
Birkholz, et al. Expires April 21, 2018 [Page 11]
