Internet DRAFT - draft-blockchain-as-detnet-use-case
draft-blockchain-as-detnet-use-case
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]
