Internet Engineering Task Force D. Huang Internet-Draft ZTE Intended status: Informational June 28, 2017 Expires: December 30, 2017 Allied and private blockchain as detnet use case draft-blockchain-as-detnet-use-case-00 Abstract This draft brings blockchain into the detnet use case list. Generally speaking, blockchain is both a technical term and a blockchain-based industry, which is spreading into a wide range of industries other than the thriving bitcoin. Blockchain would have to require the supporting network offer deterministic networking service rather than the ongoing best-effort, because of its inherent p2p and frequent multicast working mechanism. Blockchain working process, its current network mechanism and challenges ahead, as well as requirements to detnet will be illustrated in the draft. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on December 30, 2017. Copyright Notice Copyright (c) 2017 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 Huang Expires December 30, 2017 [Page 1] Internet-Draft DetNet Use Cases June 2017 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. Table of Contents 1. Use case description . . . . . . . . . . . . . . . . . . . . 2 1.1. Blockchain with regard to network . . . . . . . . . . . . 2 1.2. Blockchain network architecture . . . . . . . . . . . . . 3 1.3. Security considerations . . . . . . . . . . . . . . . . . 3 2. Allied and private blockchain today . . . . . . . . . . . . . 4 3. Allied and private blockchain future . . . . . . . . . . . . 4 4. Allied and private blockchain ask . . . . . . . . . . . . . . 4 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Use case description Blockchain is emerged 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, to name 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 to take advantage of blockchain in a controlled circumstance 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 and the rest of nodes will 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. After the confirmation process, the node broadcasts its proved block to the rest of nodes to be verified and chained. Huang Expires December 30, 2017 [Page 2] Internet-Draft DetNet Use Cases June 2017 The network treats the traffic from blockchain basiclly on best- effort , while efficiency and even raison detre of some blockchain applications such as security transaction, payment etc demand deterministic networking service to reduce latency and 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 networking. Nonetheless, the node transports both the items and the blocks to the other nodes on a point to point basis, namely creates connections with every node individually when it comes to the supporting network. When a node initiates, it firstly requests other ongoing nodes's 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. Once a new block in node completes to be proved among the nodes, This node starts propagating this block towards its neighbor nodes. Assuming node A receives a block, after verification, it sends invite message to its neighbor B, B checks if the designated block is available, it responds Get message to A if the block is 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. Huang Expires December 30, 2017 [Page 3] Internet-Draft DetNet Use Cases June 2017 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 player 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: o Transport the point to multi-point traffic in a coordinated network architecture rather than simply in application point to point level. o Transport latency guarantee in a controlled platform. o 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 o Layer 3 multicast of blockchain traffic. o Item and block delivery with bounded, lowest latency and packet loss. o Single network for blockchain and IT traffic. o Distributed configuration might be helpful. Author's Address Daniel Huang ZTE corporation, Inc. No.50 Software Avenue Nanjing, Jiangsu 210012 P.R.China Email: huang.guangping@zte.com.cn URI: http://www.zte.com.cn Huang Expires December 30, 2017 [Page 4]