Distributed Systems Group S. Qanbari Internet-Draft S. Dustdar Intended status: Informational TU Wien Expires: January 2016 N. Behinaein R. Rahimzadeh BIHE July 8, 2015 Diameter of Things (DoT): A Protocol for real-time Telemetry of IoT Applications draft-tuwien-dsg-diameterofthings-00 Abstract The Diameter of Things (DoT) protocol is intended to provide a realtime telemetry framework for IoT applications in resource-constraint gateways. Such metering capability is needed when lack of resources among competing applications dictates our schedule and credit allocation. The DoT protocol can be incorporated to implement real-time AAA of IoT services for prepaid subscribers. The DoT employs mechanisms to meter the IoT composite application units used/charged over a client credit. Such metering methods come in two models of session-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. 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." Qanbari, et al. Expires January 8, 2016 [Page 1] Internet-Draft Diameter of Things (DoT) July 2015 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 October 8, 2010. 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 January 8, 2016 [Page 2] Internet-Draft Diameter of Things (DoT) July 2015 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Quest for Metering . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions used in this document . . . . . . . . . . . . . . 5 3. Architecture Models . . . . . . . . . . . . . . . . . . . . . 6 4. DoT Metering Token Messages . . . . . . . . . . . . . . . . . 7 5. DoT-based IoT Application Overview . . . . . . . . . . . . . 8 5.1. DoT-based Metering Policy . . . . . . . . . . . . . . . . 8 5.2. DoT-based Application Topology. . . . . . . . . . . . . . 9 6. Hybrid DoT Metering (session & event-based) . . . . . . . . . 11 6.1. Initial Identification . . . . . . . . . . . . . . . . . 13 6.2. Request Realization (RR). . . . . . . . . . . . . . . . . 15 6.3. Value Verification (VV) . . . . . . . . . . . . . . . . . 17 7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 17 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 10. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 18 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 11.1. Normative References . . . . . . . . . . . . . . . . . . 18 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 1. Introduction Utility computing is an evolving facet of elastic computing that aims to converging with emerging Internet of Things (IoT) infrastructures and applications into the 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 enables 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 an 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 January 8, 2016 [Page 3] Internet-Draft Diameter of Things (DoT) July 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 sensor, controls actuators for more utilizations 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 models through metered data to achieve more financial transparency for resource-constraint applications. Metering measures rates of resource utilization via metrics, such as number of application invocations, data storage or memory usage, consumed by the cloud 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 that are influenced by their IoT business models. Such mechanisms range from usage over time, volume-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, it is necessary to facilitate a resource usage metering server between Resource-control server and the Payment server. This document specifies a Diameter of Things (DoT) application that can be used to implement real-time metering and charging mechanisms for a variety of IoT applications. The scope of this specification is the IoT application and resource usage metering. IoT application authorization and authentication is inherited from the Diameter base protocol and is out of the scope. Qanbari, et al. Expires January 8, 2016 [Page 4] Internet-Draft Diameter of Things (DoT) July 2015 1.2. Terminology AAA Authentication, Authorization, and Accounting to a specific IoT application 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. Metering Server A DoT metering server performs real-time metering and rating of IoT applications deployment. Rating The process of giving price to the application usage events. IoT Microservice A fine-grained task performed by an IoT service on a device. 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]. 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. Qanbari, et al. Expires January 8, 2016 [Page 5] Internet-Draft Diameter of Things (DoT) July 2015 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 | Protocol| | 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 client requests and composes a IoT application, the request is forwarded to the DoT client. The DoT client submits the composed application, determines possible charges, verifies user account, controls the resource allocation to the application, meters the usage, and finally, generates a bill and deducts the corresponding credit from the client's account balance. 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 a application topology. Afterwards, the provisioning server contacts the resource control server with information of required resource units. The resource control server determines potential charge and reserves resources should be allocated to the service. According to application's elasticity requirements, it verifies whether the user's credit is enough to Qanbari, et al. Expires January 8, 2016 [Page 6] Internet-Draft Diameter of Things (DoT) July 2015 cover the cost of the deployed application or not. If the user's credit is sufficient for application provisioning, 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 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. Qanbari, et al. Expires January 8, 2016 [Page 7] Internet-Draft Diameter of Things (DoT) July 2015 4. DoT Metering Token Messages This section defines DoT token message attributes that MUST be supported by all DoT implementations that conform to this specification. The CBOR message format is considered for the metering tokens transmission since it can decrease payload sizes compared to other data formats. ------------------------------------ | 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 (UTF8String) | | | | Resource Usage Array (Collection)| | +++++++++-------------------------------------------- | + Token +------- | +++++++++ | | | | | Encode/Decode |-----------------------| | Metering Token | | | | CoAP | Default Size= 1 KB | | | | ++++++++++++++++++++ | | | +Payload Data Model+ | | | + CBOR +------- | ++++++++++++++++++++ | | | |-----------------------| | | | UDP | | | ----------------------- ::= < 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 Qanbari, et al. Expires January 8, 2016 [Page 8] Internet-Draft Diameter of Things (DoT) July 2015 5. DoT-based IoT Application Overview The DoT application defined in this specification implements two different credit reservation model as well as direct debiting. 5.1. DoT-based Metering Policy In credit allocation model, the provisioning server ask resource control server to rate the IoT application topology and reserves resources and locks suitable amount of user's credit and 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. Resource control server realizes the IoT application topology metering policies using a predefined incident matrix. This Incidence Matrix represents the metering policies for our acyclic directed graph of IoT services. Such telemetry policy incident matrix P_t is a n x m matrix = [p_ij], where n is the number of nodes (vertices) and m is number of lines (Edges). If line N_j enters node V_i, then P_ij = cost/rate of call per granted unit (sessions & events). Therefore, when a client sends request containing tailored IoT application topology, the Resource control server is able to rate the request. In the application topology registered by the client, there might be two types of session based and event based service usage patterns. So, the provisioning server performs hybrid resource authorization. It submits the IoT application topology to the resource control server. Then Resource control server rates the whole topology according to the event-based and session-based metering policy, then using one or more hot-pool resources for IoT application topology delivery. Upon a successful credit allocation, the DoT client agent authorizes resource allocation and application provisioning to the end user and starts monitoring the usage of the granted underlying resource units. In case of resource consumption and service delivery, the service has been successfully delivered or terminated, the DoT client agent reports back to the Provisioning server the used amount. The provisioning server asks the Resource Control server to release the resource and deducts the billed amount from the end user's credit. Qanbari, et al. Expires January 8, 2016 [Page 9] Internet-Draft Diameter of Things (DoT) July 2015 5.2. 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 decoupled microservices to meet user's request. Each IoT microservice is predefined with a detailed information such as its ID, constraints and various usage patterns and policies. For instance, they can be advertised with diverse pricing models due to event-based or duration-based patterns for specific subscribers. The IoT microservices elasticity requirements and constraints (hardware or software resources) dictate our schedule and credit allocation. List 1. shows a sample of microservice's specification in a JSON object. { "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 end user's request can be received in the form of a JSON object. It contains of user information as well as the user requirements in terms of IoT composite application topology and its specification which are to be invoked to realize the intended behavior. After receiving the request, provisioning server generates a dependency graph of the application topology complying its specification. Dependency graph displays dependencies between different microservices which are requested to be in topology. Based on the DoT protocol, this dependency graph is used in forming transaction model for metering the IoT deployment unit. Qanbari, et al. Expires January 8, 2016 [Page 10] Internet-Draft Diameter of Things (DoT) July 2015 The dependency graph is a directional graph. Each node of the graph represents a microservice which is exist in the service package. Similarly, each edge the graph shows a dependency between two microservices (two nodes). The edge has direction which shows the execution order of microservices involved in this edge. Each edge has a label which shows the policy which is used for this connection. 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 Diameter of Things (DoT) Metering Token Structure Qanbari, et al. Expires January 8, 2016 [Page 11] Internet-Draft Diameter of Things (DoT) July 2015 6. Hybrid DoT Metering (session & event-based) For a Hybrid DoT, three main phases are involved. The first phase is called Initial Identification (II) which basically deals with clients' requirements identification together with the user authentication and authorization processes. The second phase is Request Realization (RR) that aims to deploy and provision the clients' IoT applications upon agreed terms. The final phase, entitled Value Verification (VV) to ensure 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, and VV phases is presented in Figure 4. End DoT AAA Provision Resource Metering BitCoin User Client Server Server Control Server Server Server | | | | | | | | | | | | | | |Register | AAA | | | | | |---------->| request | | | | | |Credential |--------->| | | | | |done |<---------| | | | | |<----------|AAA answer| | | | | | | | | | | | |IoT Service| | | | | | |submition | | | Submit app| | | |---------->| Submit app | & resource| | | | |------------------>| enquiry | | | | | | |---------->| IoT | | | | | | |-- hot-pool| | | | | | | |formation| | | | | | |<- | | | | | | |-- Reserve | | | | | | | | resource| | | | | | Granted |<- & credit | | | | | | resource &| | | | | | | units | | | | Request | Granted units |<----------| | | | granted |<------------------| | | | |<----------| | | | | | | | | | | | | Qanbari, et al. Expires January 8, 2016 [Page 12] Internet-Draft Diameter of Things (DoT) July 2015 | Start | | | | | | | service | | | | | | |---------->| Initiate service | | | | | |------------------>| Submit IoT app to meter| | | | | |----------------------->| | | | | | | |-- | | : : : : : | | | : : : : :<- metering| | |Used, Update units |Request | |transaction| | |------------------>|unit update| | | | | | |---------->| | | | | | | Grantd |-- | | | | | | resource &| | Reserve | | | | | | unit |<- resource| | | | Granted units |<----------| | | | |<------------------| | | | | : : : : : | | End of : : : : : | | service | | | | | | |---------->| Render service | Release | | | | |------------------>| resource &| Measure | | | | | |---------->| usage quota| | | | | | bill |----------->| | | |Stop user | | | |-- | | |--------->| | | | | | | |<---------| |Metering |Quota value |<- Commit &| | |End user | |acknowledge|<-----------| aggregate| | |Session | |<----------| | | | | | | | | | | | | | Terminate metering | | | | | |----------------------->| | | | | | | | | | | | | | Send for payment | | | | | |----------------------->| | | | | | | --| | | | | | micropayment| | | | | | | | ->| | | | | |<-----------------------| | | | | | Update client credit | Figure 4. Dot Hybrid Metering - Session & Event-based metering flow. The flow demonstrates the II, RR, and VV phases in DoT life-cycle. Qanbari, et al. Expires January 8, 2016 [Page 13] Internet-Draft Diameter of Things (DoT) July 2015 6.1. Initial Identification In this phase the end user requirements are modeled into an application topology using an acyclic directed graph. This graph can connect various IoT microservices available in diverse usage units. The deployment of such hybrid application will result in one global constant Session-ID followed by related Sub-Session-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 its been authorized for the whole transactions before. In the session-based diameter of things, before delivering the service to the end user, the Initial Identification (II) occurs. In the first request, the end user submits an IoT application topology to the DoT client. Initially the cost of the submitted IoT application is not clear. Therefore, the DoT client submits the IoT deployment units to the Provisioning server to ask the required resource units it need to run on. In this case the Provisioning server enquiry resource (including underlying resources and credit allocation) from Resource control server. The Resource control server is responsible for the device resource reservation. It keeps track of user credits fluctuations as a resource. The Resource control server analyzes the IoT service and rates the request and estimates the required units for each type of services. Then it reserve the needed resources and grant those resources to the IoT deployment units. It also informs the Provisioning server the granted units. Finally the Provisioning server sends the granted units to the DoT client as an allocated light hot-pool so the DoT client can watch the used units. This leads the application to the Request Realization (RR) phase to do the corresponding jobs. Qanbari, et al. Expires January 8, 2016 [Page 14] Internet-Draft Diameter of Things (DoT) July 2015 6.2. Request Realization (RR) 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/metering. In this regard, the Provisioning server submits the IoT app to the Metering server and ask it to establish metering mechanism for the newly opened session. Therefore the Metering server starts metering transaction. When all the granted resource units for specific IoT application are consumed by end user, the DoT client will send a new resource-update request to the Provisioning server. The detailed flow of RR phase is presented in Figure 5. Provision Resource Payment Metering Metering Agent Server Control Server Server Cohort | Server | | (Raspbery Node) | | | | | | | | |Request to | | Submit IoT app to meter |commit | |---------------------------------------->|(meter & | | | | |commit token)| | | | -- |------------>| | | | | | |-- Wake up | | | | | | | metering | | | | | |<- agent | | | | | | | | | | | |-- Create | | | | | | | token | | | | | |<- | | | | | | | | | | | |-- Meter | | | Commit | | | | IoT app & | | | Request| | |<- resource | | | Phase | | | usage | | | | | |-- | | | | | | | Write | | | | |Publish |<- token | | | | |token (Vote) | | | | | |<------------| | | | | |Stop agent | | | | | |------------>| Qanbari, et al. Expires January 8, 2016 [Page 15] Internet-Draft Diameter of Things (DoT) July 2015 | | | | |Token from | | | | | |entity B | | | | | |<-----* | | | | | |Token from | |Release | | | |entity C | |resource | | --| |<-----* | |---------->| | | -- | | | | Measure 2PC| | | | | usage quota | | | | |---------------------------->| | | | | | -- |-- Commit | | | | --| | | metering | | | | | |<-transaction| | | | | | | | | | Commit| |-- Summarize| | | | Phase | | | tokens | | | | | |<- | | | | | | | | | | | |-- Aggregate| | | | | | | tokens | | | | | |<- | | | Report the IoT app -- | | | | quota value | | | |<----------------------------| | | | | | | | | Send | | | | | for payment| | | | |----------->| | | | | | | | | | |-- | | | | Update | | micropayment| | | | client |<- | | | | credit | | | | |<-----------| | | | | | | | | Terminate metering | | |---------------------------------------->| | | | | | | Figure 5. DoT Hybrid Metering - 2PC transaction model When the new update request arrives at Provisioning server, it sends the request to the Resource Control server to request new resources. Therefore the Resource Control server rates the new request and then reserves the resources and grants them to the corresponding session in Provisioning server. Finally, the Provisioning server sends the granted units to the DoT client. Qanbari, et al. Expires January 8, 2016 [Page 16] Internet-Draft Diameter of Things (DoT) July 2015 6.3. 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 drop the user session throughout AAA server. 7. 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 is presented in the form of 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 Qanbari, et al. Expires January 8, 2016 [Page 17] Internet-Draft Diameter of Things (DoT) July 2015 8. Security Considerations This document has not conducted its security analysis, yet. 9. IANA Considerations This draft does not specified its IANA considerations, yet. 10. 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. 11. References 11.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. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2234] Paul Hoffman, "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, Internet Engineering Task Force (IETF), March 2014. 12. Acknowledgments We truly appreciate and commend the insight provided by Diameter implementers who have motivated us to incorporate the Diameter mechanisms in IoT domain. The result is a new lightweight protocol in which its specifications are proposed in this document. This document was prepared using 2-Word-v2.0.template.dot. Qanbari, et al. Expires January 8, 2016 [Page 18] Internet-Draft Diameter of Things (DoT) July 2015 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 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 January 8, 2016 [Page 19] Internet-Draft Diameter of Things (DoT) July 2015