[apps-discuss] Two new Internet Drafts (Independent Submissions)

[Neng Geng Huang <[e-mail]>]

Hello, everybody:

I have submitted two revised Internet Drafts as Independent Submissions.

https://datatracker.ietf.org/doc/draft-huangng-utid/
https://datatracker.ietf.org/doc/draft-huangng-idtp/

Here is a brief introduction to the concepts of UTID and IDTP and discuss
their use through three small examples, showing the potential to construct
a new kind of application architecture for the Internet of Things.

UTID is a unique identifier for a physical thing or a virtual thing in the
world, which consists of three components with the following syntax:

Id~catalog$dns

It is a character-based identifier, where dns is a domain name of
organization who named the thing, catalog is used by the organization to
classify the thing, and id is unique in the scope of dns and catalog.
Examples are 125.product~db$com1.test, ~db$com1.test,
125.product~$com1.test, and ~$com1.test.

IDTP is a communication protocol to tracing messages of things identified
by UTIDs, which adapt request/response model and like a hybrid of HTTP and
Web Service but using JSON data format rather than XML format. It is
characterized by using UTID rather than URL to indicate the destination
address and using build-in forward mechanism to trace the messages of
UTIDs. The forward rules are UTID suffix match (called *tracing rule* in
this paper) and namespace match (called *tracing track* in this paper). The
underlying protocol of IDTP may be TCP, UDP, UDP multicast, HTTP, Web
Service, or local handling without forwarding.

The first example is tracing of products message. A company (com1.test)
produced a product and then sold it to another company (com2.test), where
UTID is used to identify the product and IDTP is used to trace the message
of the product.

Fig. 1 Tracing reference between two databases  (visit
http://www.utid.org/utid/NewArchitecture.html to see the pictures)

A record was inserted into database of company com1.test with empty value
of tracing key when a product was produced by company com1.test and marked
as 125.product~db$com1.test, which may be used to trace to the record by
IDTP in the company com1.test (Fig. 1).

A record was inserted into database of company com2.test when the product
was purchased by company com2.test and re-marked as
312.purchase~db$com2.test, whose message was send back to company com1.test
by the following IDTP request:

idtp:0.9/1

utid:125.product~db$com1.test

ns:u.iot.db

name:UtidEcho

len:39



{"refUtid":"312.purchase~db$com2.test"}

This request was forwarded to the database of company com1.test by the
tracing mechanism of IDTP using the UTID carried by the request as
destination address and was used to update the field of tracing key of the
record. Then a response was returned back:

idtp:0.9/1

code:200 OK

len:17



{"msg":"success"}

Therefore, tracing references between the two databases were established,
just like a foreign key reference in a relational database system. The
difference is that the tracing reference is build between two independent
databases and any client application may trace any UTIDs through tracing
references by IDTP protocol.

The second example is tracing different properties of same UTID. A company
(com1.test) has a temperature sensor, which sends temperature value to a
database server every 10 minutes. The company has an internal network,
which consists of a database server that saves historical temperature
value, a tracing bridge that connect to the temperature sensor, and a
tracing gateway that forwards request based on tracing rule and tracing
track. A tracing bridge may be a system with very low capacity of
computation, such as a single chip microcomputer with Ethernet interface,
which acts as a connection node between IDTP node and non-IDTP node (Fig.
2).

The sensor was marked as 56.loc1.t~s$com1.test. A request was forwarded to
the tracing bridge by the tracing gateway if the namespace (field ns in the
request) is u.iot.sensor when a user sent a request for real time
temperature value. The tracing bridge got temperature value from the sensor
and returned the value to the requester. A request with the same UTID was
forwarded to the database server by the tracing gateway if the namespace is
u.iot.db when a user sent a request for historical temperature value. The
database server retrieved temperature values from database and returned the
value to the requester.

Fig. 2 Tracing to different node by namespace with same UTID (visit
http://www.utid.org/utid/NewArchitecture.html to see the pictures)

The tracing rule and tracing track on the tracing gateway is listed in Tab.
1 and Tab. 2.

Tab. 1 Tracing rule on the tracing gateway

*utid suffix*

*Rule*

$com1.test

ruel1

Tab. 2 Tracing track on the tracing gateway

*Rule*

*Namespace*

*Protocol*

*Address*

*Port*

rule1

u.iot.db

tcp

db.com1.test

8091

rule1

u.iot.sensor

tcp

bridge.com1.test

8092



The third example is for local request and remote request. A database
server of a company (com1.test) has various kinks of tracing keys, which
reference to local database or remote databases. A request may be handled
locally or forwarded to remote servers. In this case, the server may deal
with this situation easily by set up settings as listed in Tab. 3 and Tab.
4. There is no tracing rule for dns other than itself dns because that IDTP
will forward all unmatched requests to TCP port 25604 (default port number
for IDTP, registered in IANA) of the server indicated by the dns of the
UTID carried by a request.

Tab. 3 Tracing rule on the database server

*utid suffix*

*Rule*

$com1.test

ruel1

Tab. 4 Tracing track on the database server

*Rule*

*Namespace*

*Protocol*

*Address*

*Port*

rule1

*

local







It is encouraged to use IDTP request for local calls because of its high
efficiency to form a unified API both for local calls and remote calls.
This mechanism will help designers to develop highly interoperable
application.

Despite of the differences between IDTP and Web Service, IDTP is
conditional compatible with Web Service, adapts WSDL as data format
definition of request and response, and adapt UDDI for the discovery of
IDTP service.

In summary, UTID and IDTP suggested a new kind of application architecture
for the Internet of Things that is universal, simple, low cost, and high
efficiency. The architecture simplifies the design of application
framework, promote the efficiency of system development, and increase the
interoperability of application system.


Best regards,


Huang

-- 
------------------------------
Mr. Huang Neng Geng
------------------------------
Associate Professor
School of the Internet of Things
Wuxi Institute of Technology
Wuxi, Jiangsu, China, 214121
Mobile: [phone]
email: [e-mail]