Re: [Detnet] 答复: DetNet Use Cases additions - Deadline 10Sep17

["Grossman, Ethan A." <[e-mail]>]

​Thank you Daniel.

Ethan.

________________________________
From: [e-mail] <[e-mail]>
Sent: Tuesday, August 15, 2017 6:48 PM
To: Grossman, Ethan A.
Cc: [e-mail]; [e-mail]
Subject: 答复: Re: [Detnet] 答复: DetNet Use Cases additions - Deadline 10Sep17


Hi Ethan and everyone,

below is the latest text of blockchain text.

1. Use case description

Blockchain has been born together with bitcoin, while the latter operates and thrives in the open internet which is not supposed to be within the scope of Detnet. Nevertheless, blockchain has spread far beyond its original host into various industries such as smart manufacturing, logistics, security, legal rights etc. name only a few, because of its inherently innovative non-central business model.

Bear potential challenges from the bitcoin in mind, industry players realize it makes good sense taking advantage of blockchain in a controlled environments rather than the wild open internet. Both allied and private blockchain run in designated and carefully managed network in which deterministic networking requirements could be addressed in Detnet.



1.1 Blockchain with regard to network

Block runs as a container of a batch of primary items such as transactions, property records etc. The blocks are chained in such a way that the hash of the previous block works as the pointer header of the new block, where confirmation of each block requires a consensus mechanism. When an item arrives at a blockchain node, the latter broadcasts this item to the rest of nodes which receive and verify it and put it in the ongoing block. Block confirmation process begins as the amount of items reaches the predefined block capacity, and the node broadcasts its proved block to the rest of nodes to be verified and chained.

   The network treats the traffic from blockchain plainly on a best-effort basis, while efficiency and even raison detre of some blockchain applications such as security transaction, payment etc demands deterministic networking service to reduce latency as well as packet loss as low as possible.



1.2 Blockchain network architecture

Blockchain node communication and coordination is achieved mainly through frequent point to multi-point communication. Nonetheless, the node transports both the items and the blocks to the other nodes on a point to point basis, namely creates connections with each other node individually when it comes to the supporting network.

When a node initiates, it firstly requests other ongoing nodes’ address from a specific entity such as DNS, then creates connections with other nodes. If node A confirms an item, it sends the item to other nodes through the staying connections.

As a new block in a node completes and gets proved among the nodes, it starts propagating this block towards its neighbor nodes. Assume node A receives a block, it sends invite message after verification to its neighbor B, B checks if the designated block is available, it responds get message to A if it’s unavailable, and A send the complete block to B. B repeats the process as A to start the next round of block propagation.

As far as blockchain traffic is concerned, it’s hard to say there is significant pressure over the network because the data volume from both block and item stays between hundreds of bytes to a couple of mega bytes. Apart from the consensus mechanism of blockchain itself, the blockchain data needs to be transported with as low latency as possible in the network to guarantee the blockchain consensus process efficiency.



1.3 Security considerations

Blockchain addresses its security issues mainly in application level, where the cryptography as well as hash-based consensus play a leading role preventing both double-spending and malicious service attack. However, in the case of allied and private blockchain, it concerns the industry participants the network supporting blockchain could be highly likely the target of attack, particular for the scenarios where time efficiency is crucial and service is less delay tolerant.



2. Allied and private blockchain today

In allied and private blockchain, it runs in L2 or L3 VPN in some cases, but when it comes to the specific blockchain traffic transmission, namely the item broadcast and the block propagation among the participating nodes, the network has not yet address its deterministic requirements industry players start to concern.



3. Allied and private blockchain future

Blockchain requires deterministic networking service when it comes to accelerating consensus process. It would be valuable to design a network mechanism with the following properties:

• Transport the point to multi-point traffic in a coordinated network architecture rather than simply in application point to point level;

• Transport latency guarantee in a controlled platform;

• Specific mechanism to reduce the packet loss to an extent in which the packet retransmission-incurred delay could be ignorable.



4. Allied and private blockchain ask

• Layer 3 & Layer 2 multicast of blockchain traffic.

• Item and block delivery with bounded latency and packet loss as low as possible.

• Coexistence in a single network of blockchain and IT traffic.

• Blockchain is inherently a non-center system, so distributed configuration might be helpful.





Thanks,

Daniel





黄光平 huangguangping



预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product Operation Division


[cid:9ae3e214c17d49ed935d87c674ba3ee2]

[cid:24242e5637af428891c4db731e7765ad]
南京市雨花区软件大道50号中兴通讯1号楼
R&D Building, ZTE Corporation Software Road No.50,
Yuhua District, Nanjing, P..R.China, 210012
M: [phone]
E: [e-mail]
www.zte.com.cn<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.zte.com.cn_&d=DwMGaQ&c=lI8Zb6TzM3d1tX4iEu7bpg&r=ZcHC6wX_gDwPDcfMaFNZiQ&m=AQ6fkQW7GzbJZrIiL0JwxUk8Kdf_3-zMkXmfzbe3_08&s=Y116WQ6lVJv7okWxyKRyJC7tspXDTCQ9JYmvikLBb28&e=>

原始邮件
发件人： <[e-mail]>;
收件人：黄光平10039714;
抄送人： <[e-mail]>; <[e-mail]>;
日 期 ：2017年08月15日 23:59
主 题 ：Re: [Detnet] 答复:  DetNet Use Cases additions - Deadline 10Sep17


Hello Daniel,
Yes, I realize we already discussed blockchain, but I would like you to supply what you consider the “final result” so that we don’t have any misunderstanding about what I  thought was the final result, since I am not an expert in that area. If you would please copy to the list the most recent text as you understand it, that would help everyone (for example Hesham, per his email below) to see exactly what we are saying about  blockchain.
Thanks,
Ethna.

From: Hesham ElBakoury [mailto:[e-mail]]
Sent: Tuesday, August 15, 2017 5:51 AM
To: Grossman, Ethan A. <[e-mail]>
Subject: FW: [Detnet] 答复: DetNet Use Cases additions - Deadline 10Sep17

Hi Ethan,

Where the blockchain use case is described ?

Thanks

Hesham

From: detnet [mailto:[e-mail]] On Behalf Of [e-mail]<mailto:[e-mail]>
Sent: Tuesday, August 15, 2017 3:37 AM
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: [Detnet] 答复: DetNet Use Cases additions - Deadline 10Sep17


Hi Ethan and all,

sufficient discussions wrt blockchain use case have been made in this mail list, I do not have additional updates to the text unless further comments and suggestions will be raised, and of coure appreciated.

Thanks,

Daniel Huang











黄光平 huangguangping



预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product Operation Division


[cid:[e-mail]62110]

[cid:[e-mail]62110]
南京市雨花区软件大道50号中兴通讯1号楼
R&D Building, ZTE Corporation Software Road No.50,
Yuhua District, Nanjing, P..R.China, 210012
M: [phone]
E: [e-mail]<mailto:[e-mail]>
www.zte.com.cn<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.zte.com.cn_&d=DwMGaQ&c=lI8Zb6TzM3d1tX4iEu7bpg&r=ZcHC6wX_gDwPDcfMaFNZiQ&m=7rt5YGkQgjWJAMbdHjubAQHuOnKVaRCizAinf9pAWdU&s=GE-DDxGXchM_LhwtP02_F_8xOu3adVfIXEmiOfTd6gM&e=>

原始邮件
发件人： <[e-mail]<mailto:[e-mail]>>;
收件人： <[e-mail]<mailto:[e-mail]>>;
日 期 ：2017年08月15日  05:31
主 题 ：[Detnet] DetNet Use Cases additions - Deadline 10Sep17


Hi Folks,
The DetNet Use Cases draft 12 will expire in October, i.e. before IETF 100, so I plan to have an update before then. According to my notes, there are five items to address,  which I enumerate below. If you are one of the people mentioned below, please reply to indicate your current suggestion for new text for the draft.

I expect such text to be in a form consistent with the existing use cases, however it could be plain text or a Word doc, i.e. it doesn’t have to be in XML.

In several of the cases we have had some email exchanges regarding text wording – it is possible that I already have the latest text, but I would like for you to send me what  you understand to be the latest, to make sure we are in sync.


1.       Diego Duovne: Mining Industry use case.

2.       Maik Seewald: “Comments on section: 3.1.1.2 Intra-Substation Process Bus Communications” and  “for IEC 61850 installations only part 9-3 applies:”

3.       Hassan Halabian: 5G Packet Fronthaul

4.       Daniel Huang: Blockchain use case

5.       Xavier Vilajosana: Wind Farm use case

If anyone else has any suggestions or comments, or if I somehow lost track of your request and didn’t list it below, please reply.

Please send your replies for each of these potential additions by September 10, 2017 so that I have time to review and integrate.

Thanks,
Ethan.