[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01
Distributed Systems Group S. Qanbari
Internet-Draft S. Mahdizadeh
S. Dustdar
Intended status: Informational TU Wien
Expires: March 2016 N. Behinaein
R. Rahimzadeh
BIHE
September 20, 2015
Diameter of Things (DoT): A Protocol for Real-time
Telemetry of IoT Applications
draft-tuwien-dsg-diameterofthings-01
Abstract
The Diameter of Things (DoT) protocol is intended to provide a real-
time metering framework for IoT applications in resource-constraint
gateways. Respecting resource capacity constraints on edge devices
establishes a firm requirement for a lightweight protocol in support
of fine-grained telemetry of IoT deployment units. Such metering
capability is needed when lack of resources among competing
applications dictates our schedule and credit allocation. In response
to these findings, the authors offer the DoT protocol that can be
incorporated to implement real-time metering of IoT services for
prepaid subscribers as well as Pay-per-use economic models. The DoT
employs mechanisms to handle the composite application resource usage
units consumed/charged against a single user balance. Such charging
methods come in two models of time-based and event-based patterns. The
former is used for scenarios where the charged units are continuously
consumed while the latter is typically used when units are implicit
invocation events. The DoT-enabled platform performs a chained
metering transaction on a graph of dependent IoT microservices,
collects the emitted usage data, then generates billable artifacts
from the chain of metering tokens. Finally it permits micropayments to
take place in parallel.
Qanbari, et al. Expires March 20, 2016 [Page 1]
Internet-Draft Diameter of Things (DoT) September 2015
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. This document may not be modified,
and derivative works of it may not be created, and it may not be
published except as an Internet-Draft.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on March 20, 2016.
Copyright Notice
Copyright (c) 2015 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.
Qanbari, et al. Expires March 20, 2016 [Page 2]
Internet-Draft Diameter of Things (DoT) September 2015
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Quest for Metering . . . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. Conventions used in this document . . . . . . . . . . . . . . 6
3. Architecture Models . . . . . . . . . . . . . . . . . . . . . 7
4. DoT Metering Token Messages . . . . . . . . . . . . . . . . . 8
5. DoT-based IoT Application Overview . . . . . . . . . . . . . 10
5.1. DoT-based Application Topology . . . . . . . . . . . . . 10
5.2. DoT-based Metering Plan . . . . . . . . . . . . . . . . . 12
6. DoT Interrogations . . . . . . . . . . . . . . . . . . . . . 12
6.1. Initial Identification (II) . . . . . . . . . . . . . . . 17
6.2. Request Realization (RR). . . . . . . . . . . . . . . . . 18
6.3. Telemetry Transmission (TT) . . . . . . . . . . . . . . . 18
6.4. Value Verification (VV) . . . . . . . . . . . . . . . . . 21
7. DoT Messages . . . . . . . . . . . . . . . . . . . . . . . . . 22
8. DoT Application State Machine . . . . . . . . . . . . . . . . 25
9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 35
10. Security Considerations . . . . . . . . . . . . . . . . . . 35
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 35
12. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 36
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 36
13.1. Normative References . . . . . . . . . . . . . . . . . . 36
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37
1. Introduction
Utility computing\cite{Buyya:2009:CCE:1528937.1529211} is an evolving
facet of ubiquitous computing that aims to converge with emerging
Internet of Things (IoT) infrastructure and applications for sensor-
equipped edge devices. The agility and flexibility to quickly
provision IoT services on such gateways requires an awareness of how
underlying resources are being utilized as metered services. Such
awareness mechanisms enable IoT platforms to adjusts the resource
leveling to not exceed the elasticity constraints such that stringent
QoS is achievable.
Respecting resource elasticity requirements on edge devices
establishes a firm requirement of a lightweight protocol with
support of fine-grained telemetry for IoT deployment units. Such
metering capability is needed when lack of resources among competing
applications dictates our schedule and credit allocation. In
response to these findings, the authors offer a DoT protocol that
can be incorporated to implement real-time AAA of IoT services for
prepaid subscribers to make and enforce trade-off decisions.
Qanbari, et al. Expires March 20, 2016 [Page 3]
Internet-Draft Diameter of Things (DoT) September 2015
Based on this protocol, IoT infrastructure providers are able to
collect the emitted usage data, then generate billable artifacts
from a chain of metering transaction tokens. Finally it permits
micro-payments to take place in parallel. This document specifies a
DoT application that can be used to implement real-time telemetry
for a variety of IoT applications.
1.1. Quest for Metering
The quest for telemetry of the client's IoT application resource
usage becomes more challenging when the job is deployed and
processed in a constrained environment. Such applications collect
data via sensors and control actuators for more utilization in home
automation, industrial control systems, smart cities and other IoT
deployments. In this context, telemetry enables a Pay-per-use or
utility-based pricing model through metered data to achieve more
financial transparency for resource-constrained applications.
Metering measures rates of resource utilization via metrics, such as
number of application invocations, data storage or memory usage
consumed by the IoT service subscribers. Metrics are statistical
units that indicate how consumption is measured and priced.
Furthermore, metering is the process of measuring and recording the
usage of an entire IoT application topology, individual parts of the
topology, or specific services, tasks and resources. From the
provider view, the metering mechanisms for service usage differ
widely, due to their offerings which are influenced by their IoT
business models. Such mechanisms range from usage over time,
invocation-basis to subscription models. Thus, IoT application
providers are encouraged to offer reasonable pricing models to
monetize the corresponding metering model.
To fulfill such requirements, we have incorporated and extended the
Diameter base protocol defined in [RFC6733] to an IoT domain. There
are several established Diameter base protocol applications like
Mobile IPv4 [RFC4004], Diameter Credit-Control [RFC4006] and Session
Initiation Protocol (SIP) [RFC4740] applications. However, none of
them completely conforms to the IoT application metering models.
The current accounting models specified in the Diameter base are not
sufficient for real-time resource usage control, where credit
allocation is to be determined prior to and after the service
invocation. In this sense, the existing Diameter base applications
do not provide dynamic metering policy enforcement in resource and
credit allocations for prepaid IoT users. Diameter extensibility
Qanbari, et al. Expires March 20, 2016 [Page 4]
Internet-Draft Diameter of Things (DoT) September 2015
allows us to define any protocol above the Diameter base protocol.
Along with this idea, in order to support real-time metering, credit
control and resource allocation, we have extended the Diameter to
Diameter of Things (DoT) protocol by adding four new types of
servers in the AAA infrastructure: DoT provisioning server, DoT
resource control server, DoT metering server and DoT payment server.
Further details regarding the aforementioned entities will be
discussed in a later section of DoT architecture models. In summary,
our main focus is the specification of an extended Diameter base
protocol to an IoT application domain. This contributes to
fully implementing a real-time policy-based telemetry and resource
control for a variety of IoT applications.
1.2. Terminology
AAA
Authentication, Authorization, and Accounting for a specific IoT
application
AA answer
AA answer generically refers to a service specific authorization and
authentication answer. AA answer commands are defined in service
specific authorization applications, e.g., [NASREQ] and [DIAMMIP].
AA request
AA request generically refers to a service specific authorization and
authentication request. AA request commands are defined in service
specific authorization applications e.g., [NASREQ] and [DIAMMIP].
Diameter of Things (DoT)
DoT implements a mechanism to provision IoT deployment units, control
resource elasticity, meter usage, and charge the user credit for the
rendered IoT applications.
IoT Microservice
A fine-grained atomic task performed by an IoT service on a device.
IoT Application Topology
It contains the composition of hybrid collaborating IoT
microservices to meet the user's request. The topology is packages
with the elasticity requirements and constraints (hardware or
software resources) which will dictate our schedule and credit
allocation within the runtime environment.
Qanbari, et al. Expires March 20, 2016 [Page 5]
Internet-Draft Diameter of Things (DoT) September 2015
Metering Server
A DoT metering server performs real-time metering and rating of
IoT applications deployment.
Provisioning Server
Provisioning server refers to initial configuration, deployment
and management of IoT applications for subscribers. It also deals
with ensuring the underlying IoT device layer is available to serve.
Payment Server
The micropayment transaction charges subscribers upon relatively
small amounts for a unit of resource usage. It basically transfers
a certain amount of trade in the payWord. In the Pay Word scheme a
payment order consists of two parts, a digitally signed payment
authority and a separate payment token which determines the amount.
A chained hash function, is used to authenticate the token. The
server then calculates a chain of payment tokens (or paychain).
Payments are made by revealing successive paychain tokens.
Rating
The process of giving price to an IoT application usage events.
This applies to service usage as well as underlying resource usage.
Resource-control Server
Resource control server implements a mechanism that interacts in
real-time with a resource and credit allocation to an account as
well as the IoT application. It controls the charges related to
the specific IoT application usage.
One-cycle event
It indicates a single-request-response message exchange pattern
which one specific service is invoked by one consumer at a time
while no session state is maintained. One message is exchanged in
each direction between a Requesting DoT Node and a Responding
DoT Node.
2. Conventions used in this document
In examples, "C:" and "S:" indicate lines sent by the client and
server respectively.
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].
Qanbari, et al. Expires March 20, 2016 [Page 6]
Internet-Draft Diameter of Things (DoT) September 2015
In this document, these words will appear with that interpretation
only when in ALL CAPS. Lower case uses of these words are not to be
interpreted as carrying RFC-2119 significance.
In this document, the characters ">>" preceding an indented line(s)
indicates a compliance requirement statement using the key words
listed above. This convention aids reviewers in quickly identifying
or finding the explicit compliance requirements of this RFC.
3. Architecture Models
Figure 1 illustrates a schematic view on collaborating components of
DoT architecture. It contains of a DoT client, Provisioning server,
Resource control server, Metering server, and a Payment server.
+------+ +----------+ AAA & +------------+
| End |<-->| DoT | DoT | AAA |
| User | | Client |<-------->| Server |
+------+ +----------+ Protocol +------------+
^ ^
DoT | DoT |
Protocol| Protocol|
| |
v v
+------------+ DoT +----------+ DoT +---------+
|Provisioning| Protocol | Resource | Protocol | Payment |
| Server |<-------->| Control |<-------->| Server |
| | | Server | | |
+------------+ +----------+ +---------+
| ^
| | DoT
| | Protocol
| v
| Dot +------------+
| Protocol | Metering |
--------------->| Server |
+------------+
Figure 1: Typical Diameter of Things (DoT) application architecture
As the end user defines and composes an IoT application, the request
is forwarded to the DoT client. The DoT client submits the composed
application to the DoT infrastructure which determines possible
charges, verifies user accounts, controls the resource allocation to
the application, meters the usage, and finally generates a bill and
deducts the corresponding credit from the end user's account balance.
Qanbari, et al. Expires March 20, 2016 [Page 7]
Internet-Draft Diameter of Things (DoT) September 2015
DoT client contacts the AAA server with AAA protocol to authenticate
and authorize the end user. When the end user submits the IoT
application topology graph, the DoT client contacts the provisioning
server to submit an application topology. Afterwards, the
provisioning server contacts the resource control server with
information of required resource units. The resource control server
reserves resources that need to be
allocated to the service.
Finally the DoT client receives the grant resource message and
informs the end user that the request has been granted. Next, the
IoT application is deployed and instantiated, then the submitted
topology is registered to metering server for telemetry and credit
control purposes.
The metering server is responsible to perform the metering
transactions according to the submitted topology and meter the
services by calling metering task of each service in the chain.
Metering transactions will remain running until the termination
request is sent from DoT client to the provisioning server.
After receiving termination request, the resource control server
releases the resources and sends the billable artifacts related to
the user usage to the payment server. The payment server, then,
invokes the payment transaction and deducts credit from the end
user's account and refunds unused reserved credit to the user's
account.
4. DoT Metering Token Messages
In DoT application architecture, metered values are transfered via
tokens. This section defines DoT token message attributes that MUST be
supported by all DoT implementations that conform to this
specification. The CBOR [RFC7049] message format is considered for
the metering tokens transmission since it can decrease payload sizes
compared to other data formats.
Qanbari, et al. Expires March 20, 2016 [Page 8]
Internet-Draft Diameter of Things (DoT) September 2015
------------------------------------
| Metering Token Message Format |
| Header |
| Token ID (OctedString) |
| App Identifier (Unsigned32) |
----------------------- | Origin Session ID (OctedString) |
| | | Token Timestamp (Time) |
| IoT App | | Polict ID (Unsigned8) |
| | | Metric ID Array (Collection) |
|-----------------------| | Body |
| DoT | | Service Usage [key,values] |
| | | Resource Usage Array [key,values]|
| +++++++++--------------------------------------------
| + Token +-------
| +++++++++ | |
| | | Encode/Decode
|-----------------------| | Metering Token
| | |
| CoAP | Default Size= 1 KB
| | |
| ++++++++++++++++++++ | |
| +Payload Data Model+ | |
| + CBOR +-------
| ++++++++++++++++++++ |
| |
|-----------------------|
| |
| UDP |
| |
-----------------------
<DoT-Token-Message> ::= < Token-Id >
{ App-Identifier }
{ Origin-Session-Id }
{ Token-Timestamp }
{ Policy-Id }
{ Metric-Id-Array }
{ Service-Usage }
{ Resource-Usage-Array}
Figure 2: Diameter of Things (DoT) Metering Token Structure
5. DoT-based IoT Application Overview
The DoT application defined in this specification implements flexible
metering policy as well as the definition and constraints of the
application topology.
Qanbari, et al. Expires March 20, 2016 [Page 9]
Internet-Draft Diameter of Things (DoT) September 2015
5.1. DoT-based Application Topology
The main responsibility of the provisioning server is the actual
provision of the requested IoT application package. It contains the
composition of collaborating IoT microservices to meet the user's
request.
Each IoT microservice is predefined with a detailed specification
such as its ID, constraints and various usage patterns and policies.
For instance, as defined in List 1. they can be advertised with
diverse pricing models due to the event-based or time-based patterns
for specific subscribers. The IoT microservices elasticity
requirements and constraints (hardware or software resources) are
also defined in the topology which will dictate our schedule within
the runtime environment. The end user's request can be received in
the form of a JSON object. It contains user information as well as
the user requirements in terms of IoT composite application topology
and its specification, to realize the intended behavior. After
receiving the request, a provisioning server generates a dependency
graph of the application topology complying with its specification.
{ "microserviceID":"01",
"microserviceName":"getTemperature",
"uri":"getTemperature.py",
"execute":"python getTemperature.py",
"constraints":{"runtime": "python 2.7","memory": "..."}
"policies":[{"policyID":"PL_01_01",
"cost":"$2/week",
"desc":"session mode - $2 per week"},
{"policyID":"PL_01_02",
"cost":"0.01cent/invoke",
"desc":"event mode - 0.01cent per invoke"},
{"policyID":"PL_01_03",
"cost":"$1",
"desc":"subscription fee"},
], }
List 1. Sample IoT microservice elasticity requirement definition
The Dependency graph displays dependencies between different
microservices which are requested to be in topology. In the
DoT protocol, this dependency graph is used in forming the
transaction model for metering the IoT deployment unit.
Qanbari, et al. Expires March 20, 2016 [Page 10]
Internet-Draft Diameter of Things (DoT) September 2015
The dependency graph is a directional graph where each node of the
graph represents an available microservice in the service package
registry. Similarly, each edge of the graph shows dependencies
between two microservices (two nodes). The edge has a direction that
shows the execution order of microservices involved in this edge.
The sample of dependency graph in the form of incidence matrix is
shown in the Figure 3.
Display (Humidity & Temperature)
------
| |
| S_03 |
| |
------
^ ^
getHumidity | | getTemperature
------ | | ------
| | | | | |
| S_02 |---------- -----------| S_01 |
| | E_02 E_01 | |
------ (=PL_02_01) (=PL_01_02) ------
E_01 E_02
-------------------------------
S_03 | (PL_01_02) (PL_02_01) |
| |
| |
S_02 | 0 -(PL_02_01) |
| |
| |
S_01 | -(PL_01_02) 0 |
--------------------------------
Figure 3: Typical DoT Application Topology and its Incident Matrix
Additionally, each edge has a label which shows the policy to be in
effect for this connection. The Resource control server realizes
such metering policies using a predefined incident matrix. This
incident matrix represents the metering policies for our directed
acyclic graph (DAG) of IoT services. The metering policy incident
matrix P_t is a n*m matrix of [P_ij] policies, where n is the
number of nodes (vertices) and m is number of lines (Edges). In the
Qanbari, et al. Expires March 20, 2016 [Page 11]
Internet-Draft Diameter of Things (DoT) September 2015
cell of N_i and V_j, the P_ij indicates the rate of call per granted
unit (time & events). It enables each service to invoke its neighbor
with the attached policy. Therefore, when a client sends a request
containing a tailored IoT application topology, the Resource control
server is able to rate the request based on the enforced metering
policies of time (duration) and event-based usage patterns.
5.2. DoT-based Metering Plan
The metering plans define the allocation mechanism for granting the
required resource units to an IoT application/constituent
microservices. It is an indication that the following assumptions
underlying our IoT telemetry solution has been considered for the
proper positioning of DoT protocol. The IoT applications are
advertised with an associated charging plans. In case of cloud-based
model, there can be a subscription fee for such pay-per-use plans.
The cost of obtaining such plans is known as the plan's "premium"
which is the price that is calculated and offered in the subscription
phase by the provider. The estimation of the plan's premium is out
of the scope of the DoT protocol. The plan indicates the composed
services pricing schema and comes in two models of predefined as well
as customized. The plan will be built to be consistent with the
composed application topology in the rate setting.
The subscribed metering plan indicates: (i) the price of granted
units for every IoT application constituent microservice.
For instance, 5 hours for Humidity sensor and 10 invocations for
Chiller On/Off actuator. (ii) the resource Used Unit Update (U3)
frequency for all associated units which are defined in the
provider's plan. (iii) the manual/automatic payment configuration.
So that the provider can handle the payment transactions
automatically while informing the user. (iv) container instance fee,
which is the fee that user pays for underlying resource usage.
Instance usage can be time based or underlying resource-usage based
which is defined by the provider's policy. (v) finally, subscription
time for pay-per-use model and subscription fee for prepaid model.
6. DoT Interrogations
For a Hybrid DoT, four main interrogations are performed for a
well-functioning protocol. The first interrogation is called Initial
Identification (II) which basically deals with clients'
identification, for instance the user authentication and
authorization processes. The second interrogation is Request
Qanbari, et al. Expires March 20, 2016 [Page 12]
Internet-Draft Diameter of Things (DoT) September 2015
Realization (RR) that aims to provision the clients' IoT applications
as well as scheduling their resource allocation upon agreed terms
and subscribed plan. The third interrogation is called Telemetry
Transmission (TT) that deals with metering the running services as
well as the granted units usage data transmission for charging
purposes. The final interrogation, entitled Value Verification (VV),
ensures value generation and delivery to the interested stakeholders.
The hybrid metering is carried out in main DoT sessions which hold
globally unique and constant Session-IDs. The whole DoT-based
metering life-cycle including the II, RR, TT, and VV interrogations
in prepaid model and pay-per-use model are presented in Figure 4 and
Figure 5 respectively.
End DoT AAA Provision Resource Metering BitCoin
User Client Server Server Control Server Server Server
| | | | | | |
| | | | | | |
|Auth Req | AAA | | | | |
|---------->| request | | | | |
|Credential |--------->| | | | |
|authorized |<---------| | | | |
|<----------|AAA answer| | | | |
| | | | | | |
|IoT App & | | | | | |
|Plan | | | | | |
|submition | | | negotiate| | | |
|---------->|Provision IoT App &| to | | |
| |subscription plan | allocate | | |
| |------------------>| resources | | |
| | | |----------->| Resource | |
| | | | |--scheduling| |
| | | | | | | |
| | | | |<- | |
| | | | |-- Reserve | |
| | | | | | resource| |
| | | | |<- & lock | |
| | | | Granted | credit | |
| | | | resource | | |
|Request | Resource Granted |<-----------| | |
|authorized |<------------------| | | |
|<----------| | | | | |
Qanbari, et al. Expires March 20, 2016 [Page 13]
Internet-Draft Diameter of Things (DoT) September 2015
| | | | | | |
| Start | | | | | |
| service | | | | | |
|---------->| Deploy service | | | |
| |------------------>| Meter IoT app | |
| | | |------------------------>| |
| | | | |Ask for | |
| | | | |granted | |
| | | | |units + plan| |
| | | | |<-----------| |
| | | | | | |
| | | | |Granted | |
| | | | |units + plan| |
| | | | |----------->| |
| | | | | |-- |
| : : : : : | |
| : : : : :<- metering|
| | | | | |transaction|
| | | | | | |
| | | | | |--Summarize|
| | | | | | | usage |
| | | | | |<- |
| | | | |Send | |
| | | | |usage update| |
| | | | |<-----------| |
| | | | | | |
| | | | |-- Charge | |
| | | | | | credit | |
| | | | |<- | |
| | | |Credit |-- Check | |
| | | |update | | credit | |
| | Credit update |notification|<- threshold| |
| | required |<-----------| | |
|Notify user|<------------------| | | |
|<----------| | | | | |
| | | | |-- Update | |
| | | | | | & lock | |
| | | | |<- credit | |
| : : : : : |
|Service : : : : : |
|termination| | | | | |
|---------->| Render service | Release | | |
| |------------------>| resource & | Measure | |
| | | |----------->| usage quota| |
| | | | bill |----------->| |
Qanbari, et al. Expires March 20, 2016 [Page 14]
Internet-Draft Diameter of Things (DoT) September 2015
| | | | | |-- |
| | | | | | | |
| | | |Metering |Quota value |<- Commit &|
| | | |acknowledge |<-----------| aggregate|
| | | |<-----------| | |
| | | | | | |
| | | | Terminate metering | |
| | | |------------------------>| |
| | | | | | |
| | | | | Send for payment |
| | | | |----------------------->|
| | | | | Payment --|
| | | | | transaction| |
| | User | | | | ->|
| | logoff | | |<-----------------------|
| |--------->| | | Update client credit |
| | End user | | | | |
| |<---------| | | | |
| | Session | | | | |
Figure 4. The sequence of DoT interrogations in prepaid model
to enable hybrid metering
End DoT AAA Provision Resource Metering BitCoin
User Client Server Server Control Server Server Server
| | | | | | |
| | | | | | |
|Auth Req | AAA | | | | |
|---------->| request | | | | |
|Credential |--------->| | | | |
|authorized |<---------| | | | |
|<----------|AAA answer| | | | |
| | | | | | |
|IoT App & | | | | | |
|Plan | | | | | |
|submition | | | negotiate| | | |
|---------->|Provision IoT App &| to | | |
| |subscription plan | allocate | | |
| |------------------>| resources | | |
| | | |----------->| Resource | |
| | | | |--scheduling| |
| | | | | | | |
| | | | |<- | |
Qanbari, et al. Expires March 20, 2016 [Page 15]
Internet-Draft Diameter of Things (DoT) September 2015
| | | | |-- Reserve | |
| | | | | | resource| |
| | | | Granted |<- | |
| | | | resource | | |
|Request | Resource Granted |<-----------| | |
|authorized |<------------------| | | |
|<----------| | | | | |
| Start | | | | | |
| service | | | | | |
|---------->| Deploy service | | | |
| |------------------>| Meter IoT app | |
| | | |------------------------>| |
| | | | |Ask for | |
| | | | |granted | |
| | | | |units + plan| |
| | | | |<-----------| |
| | | | | | |
| | | | |Granted | |
| | | | |units + plan| |
| | | | |----------->| |
| | | | | |-- |
| : : : : : | |
| : : : : :<- metering|
| | | | | |transaction|
| | | | | | |
| | | | | |--Summarize|
| | | | | | | usage |
| | | | | |<- |
| | | | |Send | |
| | | | |usage update| |
| | | | |<-----------| |
| | | | | | |
| | | | |Validate | |
| | | | |Subscription| |
| | | | |-- | |
| | | | | | | |
| |Renew subscription |Renew |<- | |
| |required |<-----------| | |
|Notify user|<------------------|subscription| | |
|<----------| | |request | | |
| | | | |-- Check | |
| | | | | | payment | |
| | | | |<- interval| |
Qanbari, et al. Expires March 20, 2016 [Page 16]
Internet-Draft Diameter of Things (DoT) September 2015
| | | | | | |
| | | | | Send for payment |
| | | | |----------------------->|
| | | | | Payment --|
| | | | | transaction| |
| | | | | | ->|
| | | | |<-----------------------|
| | | | | Payment confirmation |
| : : : : : |
|Service : : : : : |
|termination| | | | | |
|---------->| Render service | Release | | |
| |------------------>| resource & | Measure | |
| | | |----------->| usage quota| |
| | | | bill |----------->| |
| | | | | |-- |
| | | | | | | |
| | | |Metering |Quota value |<- Commit &|
| | | |acknowledge |<-----------| aggregate|
| | | |<-----------| | |
| | | | | | |
| | | | Terminate metering | |
| | | |------------------------>| |
| | | | | | |
| | | | | Send for payment |
| | | | |----------------------->|
| | | | | Payment --|
| | | | | transaction| |
| | User | | | | ->|
| | logoff | | |<-----------------------|
| |--------->| | | Update client credit |
| | End user | | | | |
| |<---------| | | | |
| | Session | | | | |
Figure 4. The sequence of DoT interrogations in pay-per-use model
to enable hybrid metering
6.1. Initial Identification
The end user subscribes the application as well as the chosen plan
to the DoT client. The DoT client submits the IoT deployment units
to the Provisioning server to ask for the required resource units
it needs to run. In this case, the Provisioning server queries for
resources (including underlying resources and credit allocation)
from Resource control server. The Resource control server is
Qanbari, et al. Expires March 20, 2016 [Page 17]
Internet-Draft Diameter of Things (DoT) September 2015
responsible for the device resource reservation. It also keeps
track of user credit fluctuations.
In this phase, the end user requirements are modeled into an
application topology using a directed acyclic graph. This graph can
connect various IoT microservices available in diverse usage units.
The deployment of such hybrid applications will result in one global
constant Session-ID followed by related sub-session-IDs as well as
transaction-IDs. Note that the IoT application might send a
(re)authorization request to the AAA server to establish or maintain
a valid DoT session. However, this process does not influence the
credit allocation that is streaming between the DoT client and
provisioning server, as it has already been authorized for the
whole transaction before.
6.2. Request Realization (RR)
The Resource control server analyzes the IoT service and allocates
resources to the requested service. It also considers the
subscription time/fee in order to notify user when this value elapses.
When the new usage update arrives at the Resource control server, it
charges the credit based on the usage summary received from the
Metering server. It also validates subscription by checking the
status of credit (as in prepaid model) or elapsed time
(in pay-per-use model) against a certain threshold. Upon reaching
the threshold, the Resource control server sends an update
notification request to the user. DoT protocol makes it possible to
define a default action for this purpose. This default action can be
to perform update automatically or to ask user to take the desired
action.
6.3. Telemetry Transmission (TT)
As soon as the end user sends the Start service request to the DoT
client, the DoT Client asks the Provisioning server to initiate the
service and start monitoring and metering processes. In this regard,
the Provisioning server submits the IoT application to the Metering
server and asks to establish a metering mechanism for the newly
opened session.
As soon as an IoT application is deployed, metering server monitors
the real usage of each service element including service usage and
resource usage at a certain frequency rate called Unit Usage Update
(U3). The U3 frequency determines the rate of sending updates
regarding unit usage of each service. It is independent of the type
Qanbari, et al. Expires March 20, 2016 [Page 18]
Internet-Draft Diameter of Things (DoT) September 2015
of service. For example, the U3 set to 25%, implies that for a
time-based microservice with granted units of 100 minutes, the usage
update should be provided every $25$ minutes; and for an event-based
microservice with granted units of 100 invocations, the usage update
will be sent after every 25 invocations.
To make it more clear, after identification of an IoT application to
the Metering server, the Metering server sends a request to the
Resource control server asking for the amount of granted units which
are reserved for all microservices involved in the application as
well as the plan, which includes the U3 value for each microsevice
as defined by the provider. The U3 values are then provided to the
Metering agents, as the metering server starts the metering
transaction.
During deployment of an IoT application, each Metering agent meters
the actual resource and service usage of its associated/assigned
microservice. If the actual service usage value reaches an integer
multiples of U3, the Metering agent will send a notification message
to the Metering server. The Metering server then uses these feedbacks
to gain a realistic perception of the usage of each microservice and
to charge the user credit accordingly. Next, if the application
usage of a microservice reaches the threshold value, the Metering
Server informs the Resource control server issuing a resource-update
request for the service. For instance, when the actual usage of a
certain microservice reaches a certain threshold, e.g. more than 70%,
metering server informs the resource control server. This contributes
to a continuous and consistent service delivery. The detailed flow of
TT phase is presented in Figure 6.
Provision Resource Payment Metering Metering Agent
Server Control Server Server Cohort
| Server | | (Raspbery Node)
| | | | |
| | | | |
| Meter IoT App | | Request to |
|---------------------------------------->| meter + send |
| | | | U3 freq. |
| | | |-------------->|
| | | | |-- Wake up
| | | | | | metering
| | | | |<- agent
| | | | |
| | | | |-- Create
| | | | | | token
| | | | |<-
Qanbari, et al. Expires March 20, 2016 [Page 19]
Internet-Draft Diameter of Things (DoT) September 2015
| | | | |
| | | | |-- Meter
| | | | | | IoT app &
| | | | |<- resource
| | | | | usage
| | | | |--
| | | | | | Write
| | | |Send token at |<- token
| | | |U3 intervals |
| | | |<--------------|
| : : : |
| : : : |
|Release | | | |
|resource | Measure | | |
|---------->| usage quota| | |
| |---------------------------->|Request to |
| | | ----|commit( meter |
| | | | |& commit token)|
| | | | |-------------->|
| | | | | Publish vote |
| | | Commit | | (yes/no) |
| | | Request| |<--------------|
| | | Phase | | Vote from |
| | | | | agent A |
| | | | |<----------* |
| | | | | Vote from |
| | | | | agent B |
| | | --| |<----------* |
| | | | ---| |
| | | 2PC| | |
| | | | ---| |
| | | --| | Commit/Retry |
| | | | |-------------->|
| | | | | Token from |
| | | Commit | | agent A |
| | | Phase | |<----------* |
| | | | | Token from |
| | | | | agent B |
| | | | |<----------* |
| | | ---| |
| | | |-- Commit |
| | | | | metering |
| | | |<- transaction|
| | | | |
| | | |-- Summarize |
| | | | | & aggregate|
| | | |<- tokens |
Qanbari, et al. Expires March 20, 2016 [Page 20]
Internet-Draft Diameter of Things (DoT) September 2015
| | Aggregated usage value | |
| |<----------------------------| |
| | | | |
| | Send | | |
| | for payment| | |
| |----------->| | |
| | | | |
| | |-- Start | |
| | Update | | payment | |
| | client |<- transaction | |
| | credit | | |
| |<-----------| | |
| | | | |
Figure 6. DoT Hybrid Metering - 2PC transaction model
In the DoT credit allocation model, the provisioning server asks
the resource control server to reserve resources and to lock a
suitable amount of the user's credit. Then it returns the
corresponding amount of credit resources in the form of service
specific usage units (e.g., number of invocations, duration) to
be metered. The granted and allocated unit type(s) should not be
changed during an ongoing DoT session.
6.4. Value Verification (VV)
When the end user terminates the service session, the DoT client
MUST send a final service rendering request to the Provisioning
server. The Provisioning server should ask the Resource Control
server to release all the allocated resources to the IoT application
and perform payment transaction. As such, the Resource control
server deallocates the granted resources and asks the Metering
server to commit the measured metering tokens and report the quota
value to it. Then the Resource Control server sends the billable
artifacts to the Payment Server to charge the client account
respectively. Finally the Payment server sends the updated client
credit to the Resource Control. Meanwhile DoT Client drops the user
session throughout AAA server.
Upon each deduction from user credit, the DoT protocol verifies the
credit value. As soon as the credit value drops below a certain
threshold, it informs the user to perform credit update automatically
or to take the desired action manually.
Qanbari, et al. Expires March 20, 2016 [Page 21]
Internet-Draft Diameter of Things (DoT) September 2015
7. DoT Messages
The DoT messages contain commands and Attribute Value Pairs (AVP) to
enable metering and payment transactions for DoT-based applications.
The messaging structure should be supported by all the collaborating
peers in the domain architecture.
The following command codes are defined in DoT application:
Abbr Command Name Sender Receiver
------------------------------------------------------------------------
PATR Provision-Application-Topology DoT client Provisioning
-Request server
PATA Provision-Application-Topology Provisioning DoT client
-Answer server
ARAR App-Resource-Allocation-Request Provisioning Resource
server Control
server
ARAA App-Resource-Allocation-Answer Resource Provisioning
Control server
server
SIAR Start-IoT-App-Request DoT client Provisioning
server
SIAA Start-IoT-App-Answer Provisioning DoT client
server
TIAR Terminate-IoT-App-Request DoT client Provisioning
server
CUSR Close-User-Session-Request DoT client AAA server
ARRR App-Resource-Release-Request Provisioning Resource
server Control
server
TIAA Terminate-IoT-App-Answer Provisioning DoT client
server
CUSA Close-User-Session-Answer AAA server DoT client
Qanbari, et al. Expires March 20, 2016 [Page 22]
Internet-Draft Diameter of Things (DoT) September 2015
ARRA App-Resource-Release-Answer Resource Provisioning
Control server
server
SBPR Start-Bill-Payment-Request Resource Payment
Control server
server
SBPA Start-Bill-Payment-Answer Payment Resource
server Control
Server
CAMR Commit-App-Metering-Request Resource Metering
Control server
server
CAMA Commit-App-Metering-Answer Metering Resource
server Control
Server
SAMR Start-App-Metering-Request Provisioning Metering
server server
SAMA Start-App-Metering-Answer Metering Provisioning
server server
UACR Update-Allocation-Confirmation Resource Rrovisioning
-Request control server
server
NUAR Notify-User-Allocation-Request Provisioning DoT client
server
UACA Update-Allocation-Confirmation Provisioning Resource
-Answer server Control
Server
NUAA Notify-User-Allocation-Answer DoT client Provisioning
server
GASR Get-App-Specification-Request Metering Resource
server control
server
GASA Get-App-Specification-Answer resource Metering
control server
server
Qanbari, et al. Expires March 20, 2016 [Page 23]
Internet-Draft Diameter of Things (DoT) September 2015
PUUR Publish-Usage-Update-Request Metering resource
server control
server
PUUA Publish-Usage-Update-Answer resource Metering
control server
server
TAMR Terminate-App-Metering-Request Provisioning Metering
server server
TAMA Terminate-App-Metering-Answer Metering Provisioning
server server
Four main commands are explained here in more details.
7.1. Provision-Application-Topology-Request/Answer
The PATR command is a message between DoT client and Provisioning
server. Via this command, the DoT client submits the IoT App
(defined by the Client) to the Provisioning server and inquiry
resources needed for the application delivery in II or RR
interrogations. Following the request, the PATA response with an
acknowledgment of resources reserved for the client's IoT App
request. For instance, the PATR message format is:
[<Session-Id>, <Client-Id>, <Request-action>, <Dest-Realm>,
<User-Name>, <IoT-App-Id>, <AVPs>]. In return, the PATA response
will contain the <Granted-Service-Units> attribute in addition to
the original request.
7.2. App-Resource-Allocation-Request/Answer
The ARAR command indicates the operation communicated between the
Provisioning and Resource control server. This command aims to
reserve resources including underlying resources as well as credit
allocation for the provisioned application.
7.3. Commit-App-Metering-Request/Answer
The CAMR command is used in RR interrogation. As soon as the
Provisioning server receives Terminate-IoT-App-Request command, it
sends a Commit-App-Metering-Request command message to the Metering
server asking resource usage quota measurement for a specific user.
Qanbari, et al. Expires March 20, 2016 [Page 24]
Internet-Draft Diameter of Things (DoT) September 2015
Another use case is to ask for resource usage during service
delivery. In return, the Commit-App-Metering-Answer command is used
to report the measured quota value for the requested user and the
metered IoT application.
7.4. Start-Bill-Payment-Request/Answer
The Start-Bill-Payment-Request command which should be invoked in VV
interrogation, is used between the Resource control server and the
Payment server to establish a payment mechanism and initiate a fund
transfer. In response to the request, the Start-Bill-Payment-Answer
command contains the state of payment transaction and the updated
user credit information.
8. DoT Application State Machine
This section defines the DoT application protocol state machines.
There are five different state machines for each entity in DoT
protocol. The first state machine describes the states of DoT client.
The second one describes the Provisioning server state machine. The
third one is the state machine of Resource control server. The
fourth and fifth state machines describe the Metering server and
Payment server accordingly.
In DoT client state machine, the states PendingI, PendingP, PendingD,
PendingT stand for pending states to wait for an answer to an
already sent request related to Initial, Provisioning, Deployment,
Termination requests.
In Provisioning server state machine, the states PendingR and
PendingM stands for states of waiting for an answer from the
Resource control server and the Metering server respectively.
In Resource control server state machine, the states PendingPY and
PendingPM correspond to the state of waiting for the payment and
metering answer.
In Metering server state machine, the states PendingG and PendingUU
stand for pending states for Granted unit and Usage Update information
The event 'Tw expired, Failure to send, temporary error' in the state
machines indicates the situation where there is a problem in network,
preventing one entity to communicate with the desired entity, or the
cases where the destination entity is too busy and cannot handle
the request at that time.
Qanbari, et al. Expires March 20, 2016 [Page 25]
Internet-Draft Diameter of Things (DoT) September 2015
Dot client
State Event Action New State
-----------------------------------------------------------------------
Idle AA request received Send AA request to PendingI
from end user AA server, start Tw
pendingI Successful AA answer Submit application PendingP
received topology as well as
the plan to
Provisioning
sever (PATR),
restart Tw
pendingI Tw expired, Retry sending AA PendingI
Failure to send, request to AA server,
temporary error restart Tw
PendingP Answer received from Submit request to PendingD
Provisioning server start the IoT
(PATA) application to
Provisioning server
(SIAR),restart Tw
PendingP Answer received from Fix the problem and PendingD
Provisioning server send the request
(PATA) with again, restart Tw
result code != SUCCESS
PendingD Answer received from Stop Tw, Open
Provisioning server Inform end user that
(SIAA) service & monitoring
have beed started
PendingD Answer received from Fix the problem and PendingD
Provisioning server send the request
(SIAA) with again, restart Tw
result code != SUCCESS
PendingD Tw expired, Retry sending pendingD
Failure to send, Provisioning request
temporary error to Provisioning
server (SIAR),
restart Tw
Qanbari, et al. Expires March 20, 2016 [Page 26]
Internet-Draft Diameter of Things (DoT) September 2015
Open Update notification Inform user about the Open
received from update, send answer
Provisioning server back to Provisioning
(NUAR) with server (NUAA)
USER_INPUT equal to False
Open User confirmation request Send update Open
recieved for the updating confirmation request
credit from Provisioning to user
server (NUAR) with
USER_INPUT equal to True
Open User confirmation Send answer back to Open
request recieved (NUAR) Provisioning server
but not successfully (NUAA) with
processed result code !=SUCCESS
Open User confirmed the Send update Open
update confirmation
answer (NUAA) with
status=CONFIRM to
Provisioning server
Open User rejected the Send update Open
update confirmation answer
(NUAA) with
status=REJECT to
Provisioning server
Open User sends termination Send termination PendingT
request request to
Provisioning server
(TIAR), start Tw
PendingT Answer received from Inform user about Idle
Provisioning server termination, stop Tw
(TIAA)
PendingT Answer received from Fix the problem and PendingT
Provisioning server send the request
(TIAA) with again, restart Tw
result != SUCCESS
PendingT Tw expired, Retry sending PendingT
Failure to send, termination request
temporary error to Provisioning server
(TIAR), restart Tw
Qanbari, et al. Expires March 20, 2016 [Page 27]
Internet-Draft Diameter of Things (DoT) September 2015
Provisioning server
State Event Action New State
-----------------------------------------------------------------------
Idle Request to provision Send the resource PendingR
application topology from allocation request
DoT client (PATR) received to resource control
and successfully processed server (ARAR),
Start Tw
Idle Request to provision Send the provision Idle
application topology from topology answer to
DoT client (PATR) received DoT client (PATA)
but not successfully with
processed Result-Code!=SUCCESS
PendingR Answer of resource Send the provision Idle
allocation from resource topology answer to
control server (ARAA) DoT client (PATA),
received Stop Tw
PendingR Answer of resource Fix the problem and PendingR
allocation from resource send the resource
control server (ARAA) allocation request to
received with resource control
result code!=SUCCESS server (ARAR) again,
Restart Tw
PendingR Tw expired, Restart Tw, PendingR
Failure to send, Retry sending the
temporary error resource allocation
request to resource
control server (ARAR)
Idle Request to start the IoT Send the start PendingM
application from DoT metering request to
client (SIAR) received metering server(SAMR),
and successfully processed Start Tw
Idle Request to start the IoT Send the start app Idle
application from DoT answer to DoT client
client(SIAR) received (SIAA) with
but not successfully Result-Code!= SUCCESS
processed
Qanbari, et al. Expires March 20, 2016 [Page 28]
Internet-Draft Diameter of Things (DoT) September 2015
PendingM Answer of starting IoT Send the start app Open
application from metering answer to DoT client
server (SAMA) received (SIAA), Stop Tw
PendingM Answer of starting IoT Fix the problem and PendingM
application from metering send the start metering
server (SAMA) received request to metering
with result code!=SUCCESS server (SAMR) again,
Restart Tw
PendingM Tw expired, Restart Tw, PendingM
Failure to send, Retry sending the
temporary error start metering request
to metering server
(SAMR) again
Open Request to notify user Send the allocation Open
about updating resource notification to DoT
allocation from resource client (NUAR)
control server (UACR)
received and successfully
processed
Open Request to terminate IoT Send the resource PendingR
application from DoT release request to
client (TIAR) received resource control
and successfully server (ARRR),
processed Start Tw
Open Request to terminate Send the terminate Open
IoT application from DoT app answer to DoT
client (TIAR) received client (TIAA) with
but not successfully Result-Code!= SUCCESS
processed
PendingR Answer of confirming the Send the terminate PendingM
release of allocated metering request to
resources from resource metering server (TAMR),
control server (ARRA) Start Tw
received
PendingR Answer of confirming Fix the problem and PendingR
the release of allocated send the resource
resources from resource release request to
control server (ARRA) resource control
received with server (ARRR) again,
result code!=SUCCESS Restart Tw
Qanbari, et al. Expires March 20, 2016 [Page 29]
Internet-Draft Diameter of Things (DoT) September 2015
PendingR Tw expired, Restart Tw, PendingR
Failure to send, Retry sending a
temporary error Request to release
the allocated
resources to resource
control server (ARRR)
PendingM Answer of confirming Send the terminate Idle
metering termination from app answer to DoT
metering server (TAMA) client (TIAA),
received Stop Tw
PendingM Answer of confirming Fix the problem and PendingM
metering termination send the terminate
from metering server metering request to
(TAMA) received with metering server (TAMR)
result code!=SUCCESS again, Restart Tw
PendingM Tw expired, Terminate the Idle
Failure to send, service,
temporary error Send the terminate
app answer to DoT
client (TIAA)
Resource control server
State Event Action New State
-----------------------------------------------------------------------
Idle Request to reserve Perform resource Open
resources from scheduling, reserve
provisioning server(ARAR) resources (based on
received and successfully plan) , lock the
processed credit, send the
resources allocation
acknowledgement
answer to provisioning
server (ARAA)
Idle Request to reserve send the resources Idle
resources from allocation answer
provisioning server(ARAR) to provisioning
received but not server (ARAA) with
successfully processed Result-Code!= SUCCESS
Qanbari, et al. Expires March 20, 2016 [Page 30]
Internet-Draft Diameter of Things (DoT) September 2015
Open Request to retrieve the Send the answer Open
Specification information containing granted
from metering server unis and plan to
(GASR) received and metering server(GASA)
successfully processed
Open Request to retrieve the Send the getting Open
Specification information specification answer
from metering server to metering server
(GASR) received but not (GASA) with
successfully processed Result-Code!= SUCCESS
Open Request to publish usage Charge credit Open
update from metering according the last
server (PUUR) received sent usage, Send
and successfully the acknowledge
processed answer to metering
server (PUUA)
Open Request to publish usage Send the usage Open
update from metering update answer to
server (PUUR) received metering server
but not successfully (PUUA) with
processed Result-Code!=SUCCESS
Open Credit threshold is met Update and lock Open
credit, Send update
notification to
provisioning server
(UACR)
Open Request to release the Release the allocated PendingM
allocated resources from resources, Send the
provisioning server(ARRR) commit request to
received and metering server
successfully processed (CAMR), Start Tw
Open Request to release the Send the resource Open
allocated resources release answer to
from provisioning server provisioning server
(ARRR) received but not (ARRA) with
successfully processed Result-Code!= SUCCESS
Qanbari, et al. Expires March 20, 2016 [Page 31]
Internet-Draft Diameter of Things (DoT) September 2015
PendingM Answer of commiting Send the resource PendingPY
metering containing the release answer to
quota values from provisioning server
metering server (CAMA) (ARRA), Send a request
received to payment server to
charge the client
based on billable
artifact (SBPR),
Restart Tw
PendingM Answer of commiting Fix the problem and PendingM
metering from metering send the commit
server (CAMA) received request to metering
with server(CAMR) again,
result code!=SUCCESS Restart Tw
PendingM Tw expired, Retry sending the PendingM
Failure to send, commit metering
temporary error request to metering
server(CAMR),
Restart Tw
PendingPY Answer of billing StopTw Idle
payment from payment
server (SBPA)
received
PendingPY Answer of billing Fix the problem and PendingPY
payment from payment send a payment
server (SBPA) received request to payment
with server (SBPR) again,
result code!=SUCCESS Restart Tw
PendingPY Tw expired, Retry sending a PendingPY
Failure to send, payment request
temporary error to payment
server (SBPR),
Restart Tw
Qanbari, et al. Expires March 20, 2016 [Page 32]
Internet-Draft Diameter of Things (DoT) September 2015
Metering server
State Event Action New State
-----------------------------------------------------------------------
Idle Request to start Send answer to the PendingG
metering received Provisioning server
from Provisioning (SAMA), send request
server (SAMR) to Resource ctrl
server asking for
granted Units and
plan (GASR),start Tw
Idle Request to start Send answer to the Idle
metering received (SAMR) Provisioning server
but not successfully (SAMA) with
processed result code!=SUCCESS
PendingG Answer received from Send service Open
Resource ctrl server specific and U3
including granted units to each metering
and plan (GASA) agent, start metering
transaction,
stop Tw
PendingG Answer received from Fix the problem PendingG
Resource ctrl server andsend the request
with result code!=SUCCESS again, restart Tw
PendingG Tw expired, Retry sending PendingG
Failure to send, request(GASR) again,
temporary error restart Tw
Open Unit usage update Summarize the usage PendingUU
message recieved from a and send it to
metering agent Resource ctrl
server (PUUR),
start Tw
PendingUU Answer received from Stop Tw Open
Resource ctrl server
PendingUU Tw expired, Retry sending PendingUU
Failure to send, request(PUUR)
temporary error again, restart Tw
Qanbari, et al. Expires March 20, 2016 [Page 33]
Internet-Draft Diameter of Things (DoT) September 2015
PendingUU Answer received from Fix the problem PendingUU
Resource ctrl server with and send the
result code !=SUCCESS request again,
restart Tw
Open Request to commit the Aggregate tokens Open
measured metering tokens and send the answer
and report the quota back to Resource
value received from ctrl server (CAMA)
Resource ctrl.
server (CAMR)
Open CAMR request recieved Send the answer Open
but not successfully back to Resource ctrl
processed server (CAMA) with
result code !=SUCCESS
Open Request to terminate Terminate metering, Idle
metering received from send Answer back to
Provisioning server Provisioning
(TAMR) server (TAMA)
Payment server
State Event Action New State
-----------------------------------------------------------------------
Idle Request to charge the Generate a bill by Idle
client based on billable Invoking the payment
artifact from resource transaction, Deduct
control server (SBPR) credit from the end
received and successfully user's account and
processed refund unused
reserved credit to
user's account, Send
start bill payment
answer to resource
control server(SBPA)
Idle Request to charge the Send start bill
client based on billable payment answer
artifact from resource to resource control
control server (SBPR) server(SBPA) with
received but not Result-Code!= SUCCESS Idle
successfully processed
Qanbari, et al. Expires March 20, 2016 [Page 34]
Internet-Draft Diameter of Things (DoT) September 2015
9. Formal Syntax
The following syntax specification uses the JavaScript Object
Notation (JSON) Data Interchange Format as described in RFC-7159
[RFC7159].
List 2 presents the sample dependency graph together with its
metering policies in the form of a JSON object.
{
"graphLabel":"home_temp_hum_display",
"nodes":[{ "id":"S_01",
"name":"getTemperature",
"type":"node",},
{ "id":"S_02",
"name":"getHumidity"
"type":"node",},
{ "id":"S_03",
"name":"Display",
"type":"node",}],
"edges":[{"id":"E_01",
"directed":"True",
"source":"S_01",
"destination":"S_03",
"label":"PL_01_02"},
{"id":"E_02",
"directed":"True",
"source":"S_02",
"destination":"S_03",
"label":"PL_02_01"
}]
}
List 2. Sample IoT microservice elasticity requirement definition
10. Security Considerations
This document has not conducted its security analysis, yet.
11. IANA Considerations
This draft does not specify its IANA considerations, yet.
Qanbari, et al. Expires March 20, 2016 [Page 35]
Internet-Draft Diameter of Things (DoT) September 2015
12. Conclusions
In this draft, the authors offer a protocol entitled "Diameter of
Things (DoT)" that realizes the telemetry mechanisms to the Internet
of Things (IoT) domain. The TU Wien DSG will provide further
improvements and implementations to the DoT protocol respectively.
13. References
13.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Crocker, D. and Overell, P.(Editors), "Augmented BNF for
Syntax Specifications: ABNF", RFC 2234, Internet Mail
Consortium and Demon Internet Ltd., November 1997.
[NASREQ] Calhoun, P., Zorn, G., Spence, D., and D. Mitton,
"Diameter Network Access Server Application", RFC 4005,
August 2005.
[RFC6733] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC4004] Calhoun, P., Johansson, T., Perkins, C., Hiller, T.,and
P. McCann, "Diameter Mobile IPv4 Application", RFC 4004,
August 2005.
[RFC4006] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and
J. Loughney, "Diameter Credit-Control Application", RFC
4006, August 2005.
[RFC4740] Garcia-Martin, M., "Diameter Session Initiation Protocol (
SIP) Application", RFC 4740, April 2006.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Qanbari, et al. Expires March 20, 2016 [Page 36]
Internet-Draft Diameter of Things (DoT) September 2015
[RFC2234] Paul Hoffman, "The JavaScript Object Notation (JSON)
Data Interchange Format", RFC 7159, Internet Engineering
Task Force (IETF), March 2014.
[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", RFC 7049, October 2013.
13.2. Informative References
[DIAMMIP] Calhoun, P., Johansson, T., Perkins, C., Hiller, T., and
P. McCann, "Diameter Mobile IPv4 Application", RFC 4004,
August 2005.
14. Acknowledgments
We truly appreciate and commend the insight provided by Diameter
implementors who have motivated us to incorporate the Diameter
mechanisms in IoT domain. The result is an extension to Diameter
base protocol in which its specifications are proposed in this
document.
This document was prepared using 2-Word-v2.0.template.dot.
Authors' Addresses
Soheil Qanbari
Distributed Systems Group
Technical University of Vienna (TUWien)
Argentinierstrasse 8 / 184-1
1040 Vienna
Austria
Phone: +43-1-58801-18402
EMail: soheil@dsg.tuwien.ac.at
Qanbari, et al. Expires March 20, 2016 [Page 37]
Internet-Draft Diameter of Things (DoT) September 2015
Soheil Qanbari
Distributed Systems Group
Technical University of Vienna (TUWien)
Argentinierstrasse 8 / 184-1
1040 Vienna
Austria
Phone: +43-1-58801-18402
EMail: soheil@dsg.tuwien.ac.at
Samira Mahdizadeh
Distributed Systems Group
Technical University of Vienna (TUWien)
Argentinierstrasse 8 / 184-1
1040 Vienna
Austria
Phone: +43-1-58801-18402
EMail: e1329639@student.tuwien.ac.at
Schahram Dustdar
Distributed Systems Group
Technical University of Vienna (TUWien)
Argentinierstrasse 8 / 184-1
1040 Vienna
Austria
Phone: +43-1-58801-18414
EMail: dustdar@dsg.tuwien.ac.at
Negar Behinaein
Computer Science Group
Baha'i Institute for Higher Education (BIHE)
Tehran/Iran
Email: negar.behinaein@bihe.org
Rabee Rahimzadeh
Computer Science Group
Baha'i Institute for Higher Education (BIHE)
Tehran/Iran
EMail: rabee.rahimzadeh@bihe.org
Qanbari, et al. Expires March 20, 2016 [Page 38]
Internet-Draft Diameter of Things (DoT) September 2015
Html markup produced by rfcmarkup 1.122, available from
https://tools.ietf.org/tools/rfcmarkup/