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 | | | ----------------------- ::= < 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: [, , , , , , ]. In return, the PATA response will contain the 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