[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/