Internet DRAFT - draft-liu-iot-arch
draft-liu-iot-arch
Internet Engineering Task Force Y. Liu
Internet-Draft Y. Song
Intended status: Experimental H. Yu
Expires: 12 November 2023 Guangzhou Genlian
11 May 2023
The Architecture for Internet of Things Network
draft-liu-iot-arch-02
Abstract
In this document, it identifies gateways for field-bus networks, data
storages for archiving and developing data sharing platform, and
application units to be important system components for developing
digital communities: i.e., building-scale and city-wide ubiquitous
facility networking infrastructure. The standard defines a data
exchange protocol that generalizes and interconnects these components
(gateways, storages, application units) over the IPv6-based networks.
This enables integration of multiple facilities, data storages,
application services such as central management, energy saving,
environmental monitoring and alarm notification systems.
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 12 November 2023.
Copyright Notice
Copyright (c) 2023 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 (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Liu, et al. Expires 12 November 2023 [Page 1]
Internet-Draft The Architecture for Internet of Things May 2023
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 Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Conventions . . . . . . . . . . . . . . . . . 3
3. System Architecture . . . . . . . . . . . . . . . . . . . . . 4
3.1. Gateway . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Storage . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.3. Application . . . . . . . . . . . . . . . . . . . . . . . 4
3.4. Registry . . . . . . . . . . . . . . . . . . . . . . . . 4
3.5. Concerns of the network design . . . . . . . . . . . . . 5
4. System Model . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Point . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 6
5.2. Definition . . . . . . . . . . . . . . . . . . . . . . . 6
5.3. URI-based identification . . . . . . . . . . . . . . . . 7
5.4. PointSet . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Common communication protocol . . . . . . . . . . . . . . . . 7
6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.2. Component-to-component communication protocol . . . . . . 8
6.2.1. Types of component-to-component communication
protocol . . . . . . . . . . . . . . . . . . . . . . 8
6.2.2. FETCH protocol . . . . . . . . . . . . . . . . . . . 8
6.2.3. WRITE protocol . . . . . . . . . . . . . . . . . . . 8
6.2.4. TRAP protocol . . . . . . . . . . . . . . . . . . . . 8
6.3. Component-to-registry communication protocol . . . . . . 9
6.3.1. Type of component-to-registry communication
protocol . . . . . . . . . . . . . . . . . . . . . . 9
6.3.2. REGISTRATION protocol . . . . . . . . . . . . . . . . 9
6.3.3. LOOKUP protocol . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
10. Normative References . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
Liu, et al. Expires 12 November 2023 [Page 2]
Internet-Draft The Architecture for Internet of Things May 2023
1. Introduction
This document identifies gateways for field-bus networks, data
storages for archiving and developing data sharing platform, and
application units such as for providing user interfaces of analysis
and knowing the environmental information to be important system
components for developing digital communities: i.e., building-scale
and city-wide ubiquitous facility networking infrastructure. The
standard defines a data exchange protocol that generalizes and
interconnects these components (gateways, storages, application
units) over the IPv6-based networks. This opens the application
interface to handle the statuses of multi-vendor facilities on a
generalized digital infrastructure. The standard assumes distributed
operation of the infrastructure by multiple service providers and
integrators, and defines a component management protocol that
autonomously interoperates such distributed infrastructure. Security
requirements are taken into consideration in this standard to ensure
the integrity and confidentiality of data.
2. Terminology and Conventions
access control: The means to allow authorized entry and usage of
resources.
actuator: A transducer that accepts a data sample or samples and
converts them into physical action.
eXtensible Markup Language (XML) namespace: A method for
distinguishing XML elements and attributes that may have the same
name but different meanings. A URL is used as a prefix to a "local
name." This combination ensures the uniqueness of the element or
attribute name. The URL is used only as a way to create a unique
prefix and does not have to resolve to a real page on the Internet.
A transducer that converts a physical, biological, or chemical
parameter into a digital signal.
universally unique identifier (UUID): An identifier that has a unique
value within some defined universe. In this standard, the query-
expression and lookup-expression of transport data structure has a
UUID unless otherwise stated.
Liu, et al. Expires 12 November 2023 [Page 3]
Internet-Draft The Architecture for Internet of Things May 2023
3. System Architecture
This protocol specification applies to a TCP/IP-based facility
networking architecture. One of the main goals of this specification
is to enable interoperability among facility networking components.
Thus, GW, Storage and APP, what we call "Component" in this document,
have the same generalized communication interface. Registry has
different communication interface with these components. A Component
works as a part of data- plane, and a Registry works as a part of
control- plane.
In the networking environment, Registry works as a broker of
Components. It manages meta information e.g., the role of each
component and the semantics of Point ID, in order to bind components
appropriately and autonomously. We here describe them in more detail
and show how they collaborate with each other.
3.1. Gateway
Gateway component has physical sensors and actuators. It generalizes
the data model and the access method for those devices, encapsulating
each physical (field-bus) data model and access method. It acts on
its actuator according to the written value from a component (e.g.,
APP), and it provides physical sensor readings for other components
(e.g., Storage and APP).
3.2. Storage
Storage component archives the history of data sequences. The
written values from other components should be permanently stored in
the backend disks. It provides the archived values to the components
that have requested them.
3.3. Application
APP component provides some particular works on sensor readings and
actuator commands. It can have user interface to display the latest
environmental state. It can also allow a user to input some
schedules of actuator settings, and it can as well analyze some
sensor data in realtime and provide the result as a virtual device.
3.4. Registry
The Registry works as a broker of GW, Storage, and APPs. The main
role of registry is to bind those components appropriately and
autonomously. It is separated from the data-plane. It does not work
on sensor readings or actuator settings directly. It should allow
system operation without Registry.
Liu, et al. Expires 12 November 2023 [Page 4]
Internet-Draft The Architecture for Internet of Things May 2023
3.5. Concerns of the network design
All components can behave both as the TCP (IETF RFC 793) initiator
and receiver at once. It implies the components should be put on a
flat network. A flat network means there are no middle boxes which
could disturb bi-directional communications such as NAT routers and
firewalls.
To avoid the issue, we strongly recommend building IPv6 (IETF RFC
2460) network. There could be other solutions than IPv6 such as http
proxy based or NAT traversal solutions. However, they would depend
on the requirements of the network configuration. This specification
does not reject such solutions, but they are required to make
interoperable with other systems and not to disturb the
specification.
4. System Model
Component is the basic unit for all the GWs, Storages, and APPs. The
interface of Component provides data and query method. GW, Storage,
and APP are the inherited classes of Component. Thus, they have the
same interface (i.e., data and query method), and they communicate
with each other using the same protocol. Here, Query is a method for
retrieving data (including event-based data transfer) from Component;
Data is a method for pushing data into Component.
Registry works as a broker of Components with another type of
interface (i.e., registration and lookup method). The interface of
Registry provides registration and lookup method. Here,
o Registration is a method for registering the role of components and
semantics of Points.
o Lookup is a method for finding appropriate components and Points.
Typical implementations for GWs, Storages, APPs and Registry would
be:
GW implementations encapsulate field-buses and provide INPUT/OUTPUT
access for physical devices (by query and data method).
Storage implementations archive the history of data posted by data
method, and provide the historical data by query method.
APP implementations provide other functionalities. For example, they
can have user interface. Data processing component must be also
categorized to an APP implementation.
Liu, et al. Expires 12 November 2023 [Page 5]
Internet-Draft The Architecture for Internet of Things May 2023
Registry implementations manage the relationships between Point ID
and components, provide registration of the role of components and
semantic of Points by registration method, and provide inquiry of
appropriate components and Points by lookup method.
This generalization enables open development of facility networking
components (i.e., GWs, Storages and APPs) by any vendors. And we
would deploy facility networking systems for customer buildings
without customized programming, by binding these developed
components.
The role of Registry is to increase the autonomousness of component-
to-component collaboration. It allows autonomous collaboration of
components, by sharing the information of component roles in an
operational domain (in fact, not only in an operational domain but
also with other external domains).
5. Point
5.1. Introduction
This section introduces the concept of Point. A Point shall have an
URI-based globally unique identifier. It identifies a dataflow that
exchanges data (i.e., sensor readings, actuator commands and meta-
control signals) among components.
5.2. Definition
A Point is an elemental message channel for a specific data sequence
among Components. A sequence of sensor readings, actuator commands
and others (e.g., virtualized sensor readings, meta-control signals)
shall be bound to a Point. We denote a message in a Point (whether
it is coming from a sensor or it is outgoing to an actuator) by
value. Any object type is allowed for values in a Point.
Delivery of values among components shall be made by invoking other
components' interface. The provided methods are:
Query: to read objects from specified Points
Data: to write objects into specified Points
By using these methods, a component can get data of the specified
Points from another component, and it can also transfer data to
another component with specification of the Points.
Liu, et al. Expires 12 November 2023 [Page 6]
Internet-Draft The Architecture for Internet of Things May 2023
5.3. URI-based identification
A Point is associated to a globally unique data sequence. The data
shall have been generated from a specific sensor or to a specific
actuator in the world. Thus, in order to identify the data sequence
globally, each Point should have a globally unique identifier. Note
that for private operation, it does not necessarily need to be
globally unique. However, it is not recommended.
In the network, every Point shall have a URI for its identifier.
Practically, we will first assign IDs for physical sensors and
actuators, and then we will use the IDs for the Point IDs. This
operation goes well with the traditional facility networking
operation.
Taking URI for identifiers enables global access (if the Point is
public) to the Point. Let X(=http://gw.foo.org/sensor1) be a Point
ID.
If components do not know the registry server that manages the Point
ID (X), they should try to access X directly. Then, the URI can
redirect to the registry server. If components already know the
registry server for X, Point ID may not need to be reachable.
However, in order to obtain operational consistency, the host of the
URI should be the host name of the GW (because physical sensors and
actuators are attached to the GW). Thus, typical URI format should
be:
point ID = "http://(GW host name)/(any format to identify the Point
in the GW)"
5.4. PointSet
This specification also defines PointSet to enable hierarchical
management of Points. A PointSet aggregates multiple Points and
multiple PointSets. This definition allows the conventional
operation of grouping of Points hierarchically. However, PointSet
feature is optional. All the components should allow operation
without pointSet.
6. Common communication protocol
Liu, et al. Expires 12 November 2023 [Page 7]
Internet-Draft The Architecture for Internet of Things May 2023
6.1. General
This specification defines two types of communication protocols for
components and registry, including the component-to-component
communication protocol and component-to-registry communication
protocol. The protocol message for component-to-component and
component-to-registry communication is intended to use Simple Object
Access Protocol (SOAP Version 1.2 Part 1: Messaging Framework").
6.2. Component-to-component communication protocol
6.2.1. Types of component-to-component communication protocol
This section specifies and describes the following three types of
sub-protocols for component-to-component communication. Note that
instances of components are GWs, Storages, and APPs. As for the
accessing methods to a registry.
FETCH protocol -- for data retrieval from a remote component.
WRITE protocol -- for data transfer to a remote component.
TRAP protocol -- for event query registration and event data
transfer.
6.2.2. FETCH protocol
FETCH is a protocol for data retrieval from a remote component. We
here denote the component that inquires data from the remote
component by 'Requester', and the component that replies with the
data by 'Provider'.
6.2.3. WRITE protocol
WRITE is a protocol for data transfer to a remote component. We
denote the component that submits data to the remote component by
Requester, and the component that receives the data by Target.
6.2.4. TRAP protocol
TRAP is a protocol for event query registration and event data
transfer. We here give names for components in the following manner.
Requester -- the component that sets event-based query to Provider.
Provider -- the component that transmits data when it has received
query-matching updates.
Liu, et al. Expires 12 November 2023 [Page 8]
Internet-Draft The Architecture for Internet of Things May 2023
Callback (Data) -- the components that receives data from the
Provider.
Callback (Control) -- the components that receives control signals
from the Provider.
This subsection provides the definition of collaboration among these
components. Though the roles are explicitly categorized in general,
in most of the practical systems, Callback (Data), Callback (Control)
and Requester will be the same component.
6.3. Component-to-registry communication protocol
6.3.1. Type of component-to-registry communication protocol
This section specifies the following two types of sub-protocols for
component-to-registry communication.
REGISTRATION Protocol -- for registration of the role of components
and semantics of Points.
LOOKUP Protocol -- for searching appropriate components and Points.
6.3.2. REGISTRATION protocol
REGISTRATION is a protocol which enables a component to register the
role of components and semantics of Points. We denote the component
that submits registration request to its Registry by "Registrant".
6.3.3. LOOKUP protocol
LOOKUP is a protocol for a component to search appropriate access
components (for component-to-component communication), and to search
Points by semantic-query. We here denote the component that searches
appropriate components and Points from its Registry by 'Requester'.
7. Security Considerations
This protocol is basically open. It assumes multi-domain operation
and public access from other domain's system components. In this
context, security requirements to the system would be listed as
follows:
o To avoid unintended data disclosure to the public.
o To avoid unauthorized access to writable resources.
o Availability and confidentiality of remote communication host.
Liu, et al. Expires 12 November 2023 [Page 9]
Internet-Draft The Architecture for Internet of Things May 2023
o Integrity and confidentiality of data.
o To avoid unintended access or operational conflicts.
To get confidentiality of remote communication host, we would be able
to take VPN, SSL, SSH and other related technologies. HTTPS, or SIP
and its security extension would help in getting integrity and
confidentiality of data.
Access control and access confliction management shall be other
important but different types of security issues that should be
discussed independently. Generally, access control is used to allow
only specific users to access both readable and writable resources,
which would certainly help to avoid unauthorized access from or
unintended data disclosure to the public (sometimes anonymous) users.
In order to manage this, the system would need to introduce the
concept of users to identify who is accessing the resources. We
assume URI-based identification for user authentication just as Point
ID takes URI for its identifier. Authentication of these users and
components (probably by taking advantage of the existing
authentication platforms) would certainly need to be considered.
8. IANA Considerations
This document does not include an IANA request.
9. Acknowledgements
Funding for the RFC Editor function is currently provided by
PetroChina Huabei Oilfield Company and BII Group.
10. Normative References
Authors' Addresses
Yan Liu
Guangzhou Genlian
Xiangjiang International Technology Innovation Center, 41 Jinlong Road, Nansha District, Guangzhou
Guangzhou
China
Email: yliu@cfiec.net
Yang Song
Guangzhou Genlian
Xiangjiang International Technology Innovation Center, 41 Jinlong Road, Nansha District, Guangzhou
Guangzhou
China
Liu, et al. Expires 12 November 2023 [Page 10]
Internet-Draft The Architecture for Internet of Things May 2023
Email: ysong@biigroup.cn
Haisheng Yu
Guangzhou Genlian
Xiangjiang International Technology Innovation Center, 41 Jinlong Road, Nansha District, Guangzhou
Guangzhou
China
Email: hsyu@cfiec.net
Liu, et al. Expires 12 November 2023 [Page 11]
