MIN: Co-Governing Multi-Identifier Network Architecture and its Prototype on Operator's Network

IP protocol is the core of TCP/IP network layer. However, since IP address and its Domain Name are allocated and managed by a single agency, there are risks of centralization. The semantic overload of IP address also reduces its scalability and mobility, which further hinders the security. This paper proposes a co-governing Multi-Identifier Network (MIN) architecture that constructs a network layer with parallel coexistence of multiple identifiers, including identity, content, geographic information, and IP address. On the management plane, we develop an efficient management system using consortium blockchain with voting consensus, so the network can simultaneously manage and support by hundreds or thousands of nodes with high throughput. On the data plane, we propose an algorithm merging hash table and prefix tree (HTP) for FIB, which avoids the false-negative error and can inter-translate different identifiers with tens of billions of entries. Further, we propose a scheme to transport IP packets using CCN as a tunnel for supporting progressive deployment. We deployed the prototype of MIN to the largest operators' network in Mainland China, Hongkong and Macao, and demonstrated that the network can register identifier under co-governing consensus algorithm, support VoD service very well.


INTRODUCTION
e Internet architecture based on IP has continuously evolved during the last decades. Its end-to-end transmission mode accelerated its deployment worldwide. However, in IP based network, the allocation and management of IP addresses are controlled by a single agency. Such centralization brings risks. On the other hand, IP addresses represent both the location and the identity information of nodes, causing semantic overload. ese problems hinder the scalability of routing and its adaptation to mobile devices. e lack of identity tracking and managing also reduce the security of IP-based networks [5,15,16]. e defects in security and tractability make the IP network unsuitable for supporting emerging scenarios, such as Content-Centered Network (CCN), highspeed mobile network, Internet of ings, and Industrial Internet. e situation poses urgent demand for a new generation of future network architectures.
To improve the performance of IP-based networks, European Union launched the rst phase of Future Internet Research and Experimentation (FIRE) program [6] to explore future network and service mechanisms. e project focused on exploring the self-adapting management mechanism in the future network to increase its level of intelligence. However, this study did not produce a new network architecture design. e NDN project [21] backed by the National Science Foundation (NSF) aims to develop a network architecture based on content. e MobilityFirst project [18] prioritizes the identity of nodes and e ciently manage the movement of nodes. It uses the General Delay-Tolerant Network (GDTN) to enhance the robustness and availability of network.
To decentralize the management of the network architecture, blockchain [14] and other solutions [3,4,8,9,17] have recently been applied to build a future network under cogoverning. Namecoin [13] and Blockstack [1] rst applied blockchain to decentralize the management of domain name system. However, its underlying system based on public blockchain creates bo leneck for its performance. To solve the problem, Benshoof et al. proposed an alternative solution of DNS system based on blockchain and distributed hash table named D 3 N S [2], which provides solutions to current DNS vulnerabilities such as DDoS a acks. However, it risks leaking users' IP information and increases the di culty to deploy in large-scale. To mitigate the problem, HyperPub-Sub system [22] uses the passive publish/subscribe receiving mode to reduce the tra c load and the delay caused by blockchain.
e above methods improve performance of network and level of decentralization, respectively, but are unable to meet both requirements [20] simultaneously. is paper proposes a Multi-Identi er Network (MIN) architecture that constructs a network layer with parallel coexistence of multiple identi ers, including identity, content, geographic information, and IP address. To solve the two major defects of the traditional network, we decentralize the management of post-IP identi er using consortium blockchain, address or intertranslate identi ers with tens of billions of entries using HPT for FIB. We also enhance the progressive deployment through novel IP-CCN-IP tunnel scheme. As part of the work, we implement the generation, management, and resolution in MIN and ensure it compatible with the traditional IP network, to support progressive deployment.
We experimented and veri ed MIN in operators' network deploy from Beijing to Guangzhou, Shenzhen, Hongkong and Macao for streaming high-de nition video. We also tested the transmission including IP to CCN to IP, IP to CCN, CCN to IP, and CCN to IP to CCN. e results demonstrate that the network achieves excellent performance and can support real-world applications with further development.
As contributions, this paper proposes a novel Multi-Identi er Network. Speci cally, 1) On the management plane, we design an e cient consensus mechanism of consortium blockchain to achieve decentralized management of identi ers, which is the multiidenti er system(MIS). MIS takes the same role as DNS in IP, actually the function of DNS is only a subset of MIS.
2) On the data plane, we improve HPT-FIB by combining hash table and pre x tree, which is integrated into the multi-identi er router (MIR) of MIN as a key part. Such improvement enables identity-centered forwarding and intertranslation between di erent kind of identi ers in a magnitude of tens of billions of entries.
3) We also introduce a scheme to transport IP packets using CCN as a tunnel to support progressive deployment of the data plane (being compatible with IP-based network). We implemented various transmission scenarios, such as IP-CCN-IP, IP-CCN, CCN-IP, and CCN-IP-CCN. e rest of this paper is organized as follows. Section 2 describes the proposed Multi-Identi er Network. Section 3 demonstrates the key technologies. Section 4 presents the quantitative results of the prototype, and section 5 provides some concluding remarks and discusses ongoing and future research directions.

MULTI-IDENTIFIER NETWORK
For the co-governing Multi-Identi er Network, its decentralized management and large resolution capability enable a progressive transition from the existing network architecture to a new one.

Network Architecture
MIN supports the coexistence of Network Identi ers including identity, content, geographic information, and IP address. Identi ers in the network are identity-centric. For example, the content identi ers of all resources are bound to the identity identi ers of their publishers. e protocol architecture of MIN is shown in Figure.1.   Figure. 2. It divides the whole network into hierarchical domains from top to bo om. e nodes in the top-level domain belong to the organizations of the major countries which jointly maintain a consortium blockchain. e respective regional organizations govern the other domains. Among them, the registration and management mode of identi ers and the speci c implementation details can vary. is low coupling guarantees the security of the network and enables customization of each domain [10] [11].  Figure 2: Network hierarchy of MIN e function of a complete node in the network is to participate in the intra-domain management of users and the registration process of identi ers on the blockchain, as well as provide inter-translation and resolution services (in this case called Multi-Identi er Router, MIR). Also, there are supervisory nodes, individual users, and enterprise users. Supervisory nodes are set up as the data access interfaces between the upper and lower domains. Each supervisory node has multiple identi ers. e architecture of MIN includes a management plane and a data plane. e management plane is responsible for generation and management of identi ers. A er the supervisory nodes verify the identi er and reach a consensus through the consensus algorithm, it records the relevant a ribution information and operation information on the blockchain, to make the data in the whole network uni ed, tamper-resistant and traceable. e reason for storing only the important data on-chain is to ensure e ciency, while all the information of the identi ers are stored o -chain.

Inter-Chain Communication
e data plane provides the resolution for identity, content, geographic information and other identi ers, and is also responsible for packet forwarding and ltering.

Operation Flow
In MIN, all resources are required to register an identi er with a regulatory organization within the domain. Devices can only access a resource in the network a er its identi er has been approved by most organizations and successfully wri en on the blockchain. e registration process is as follows. S1: e user who owns the resource submits a request for identi er registration to the node of a regulatory organization.
S2: A er receiving the user's request, MIR transmits the registration data to its corresponding domain according to a speci c routing protocol.
S3: e blockchain node of the corresponding domain reviews the compliance of the resource a er receiving its identi er registration request. If so, the resource's identi er is then voted by all the blockchain nodes in the domain to reach consensus.
S4: e blockchain node then returns the registration result to the original requesting node. Since the complete identi er information is stored in the o -chain database rather than the on-chain block, all databases are synchronized frequently throughout the network to ensure consistency.
MIR's process to resolve the identi er is as follows. S1: MIR judges that the identi er is (1) IP address, then query in HPT-FIB. If it exists, it will be resolved. Otherwise, access the traditional IP network through proxies; (2) identity, content and other identi ers, then query in the cache and HPT-FIB. If it exists, it will be resolved. Otherwise, go to S2. S2: If MIR cannot nd the identi er, recursively query the upper domain until acquiring it. S3: If the identi er is not found up to the top-level domain, then query the lower domain according to the information carried by the identi er until the lowest. If it exists, MIR will return the resolved result. Otherwise, return an error message.
In MIN, users' behaviors of publishing and accessing are protected and managed, and the blockchain undeniably records illegal actions. erefore, MIN will keep the cyberspace in an orderly and secure state, which will direct tra c to the post-IP multi-identi er network tied to the user's identity.

KEY TECHNOLOGIES
As mentioned above, we use consortium blockchain, HPT for FIB, and tunnel algorithm to improve the security, performance, and scalability. In this section, we introduce those technologies.

Consensus Algorithm for Consortium Blockchain
On the management plane of the MIN architecture, we come up with the APoV (Advanced Proof of Vote) consensus based on our self-designed PoV (Proof of Vote) [12], a non-forking consensus algorithm for consortium blockchain. e core lies in the separation of voting rights and bookkeeping rights. e bookkeeping nodes work in a joint e ort to conduct decentralized arbitration according to the votes of the consortium nodes.

(1)Concept Description
APoV de nes that data on the blockchain is stored in block groups. A block group consists of a block group header and a block group body. Each block group header contains the height and voting result. e block group body includes blocks approved by the majority of consortium nodes. Where, each block consists of the hash value of the previous block group, the Merkle root, the public key of the bookkeeping node, the timestamp, and the set of transactions.
e APoV consensus divides the blockchain nodes into three identities: consortium node, bookkeeping node, and leader node.
• e consortium node is responsible for voting on the generated blocks and potential bookkeeping nodes. e number of consortium nodes in each round is a xed constant, denoted as n c . Based on the principle of "the minority is subordinate to the majority", the voting results are regarded as proof of the validity of the block and the identity of the bookkeeping node.
• e bookkeeping node is responsible for generating blocks in the current consensus round. e number of bookkeeping nodes is n b . At the end of the term, the consortium nodes vote on the potential bookkeeping nodes to produce the next bookkeeping nodes.
• e leader node is responsible for counting votes and writing the voting result into the block group header as proof. Each consensus round has a di erent leader node, whose number is recorded in the previous block group header.
ere are two types of voting messages in APoV for the transactions of identi ers and election: con dence vote and veri cation vote.
• e validation vote is a validation of the block group. e consortium node votes for the blocks they agree to generate. Each block must obtain more than half of the votes to be considered as a legal block. Similarly, to correct a result, more than half of the consortium nodes must agree. • e con dence vote is a successful proof for the next bookkeeping nodes. Before the end of the current bookkeeping nodes' term, each potential bookkeeping node proposes a transaction of election and receives votes from consortium nodes. e voting result indicates the trust of consortium nodes in these nodes competing for bookkeeping rights, thus can also be considered as the reliability of them. e nodes with higher reliability ranking are deemed successful in the election, with bookkeeping rights from the next consensus round until the end of their term.
(2)Process of Consensus e consensus process is shown in Figure. 3. Each round of the APoV consensus consists of the following steps. S1: Each bookkeeping node generates a block and publishes it to the network. Each blockchain node collects all the blocks in this step. S2: When the consortium node collects all the block generated in S1, it votes for each block and sends a total voting message to the leader node. e voting message contains the hash value of each block, as well as the agreed opinion and signature.
S3: e leader node collects the voting messages sent in S2 and counts the voting results. Statistical results and all voting messages will be stored in the block group header when the approval or disapproval of each block is more than half of the number of consortium nodes. e leader node then generates a random number as the number of the next leader node and writes it into the block group header. Finally, the leader node publishes the block group header to the network.
S4: When the blockchain node receives the block generated by the bookkeeping nodes and the block group header generated by the leader node, it will store them in the database as a block group.

Improved FIB
ere are multiple identi ers including identity, content, geographic information, and IP address on the data plane of MIN. However, in the traditional FIB, the length of content names leads to a too large table and reduces lookup speed. On the one hand, we design the inter-translating algorithm with multiple identi ers. On the other hand, by building hash tables and pre x trees, we optimize the FIB algorithm to improve the lookup speed at massive scale.  Table and Prex Tree (1)Reconstructing HPT-FIB To support binary search, every true pre x of the content name stored in the table must also have corresponding entries.
e process of checking whether pre xes exist and adding corresponding non-real entries is known as FIB reconstruction. Typically, in a reconstructed FIB, table entries can be divided into two categories: real entry and non-real entry. To avoid the false-negative error in traditional binary search, we subdivide non-real entry into the virtual entry and the semi-virtual entry.

Input:
H : HT and trie-based FIB n: n = "/c 1 /c 2 /.../c N " is the content name to insert f : e corresponding forwarding information of n Output: H : HT and trie-based FIB, with n inserted 1: lookup n in HT 2: if n is the name of a real entry (n, e) then 3: update e's forwarding information with f 4: else if n is the name of a non-real entry (n, e) then 5: set e's type to real, e's forwarding information to f 6: for each virtual entry (∼, e * ) in e's subtree do 7: set e * 's type to semi-virtual 8: end for 9: else 10: create entry (n, e N ) and insert it to HT 11: set e N 's type to real, e N 's forwarding information to f 12: for i = N − 1 to 1 do 13: lookup n i = "/c 1 /c 2 /.../c i " in HT 14: if n i is the name of an entry (n i , e) then 15: add e i +1 to e's child list, set e i +1 's parent to e 16: if e is virtual then 17: set e j (i < j < N )'s type to virtual 18: add e i to r oot 's child list, set e i 's parent to r oot 28: set e j (0 < j < N )'s type to virtual 29: end if e content names in the real entries referred to the actual data are used to forward Interest packets. All of the table entries are real before FIB reconstruction. Content names in non-real entries do not refer to data or guide the forwarding of Interest packets but are only used to support the binary search algorithm. A non-real entry is called a virtual entry if it has no real pre x. If the non-real entry has a real prex, the table entry is called semi-virtual entry and requires backtracking before the end. We present the semi-virtual entry to avoid the false-negative error in HPT-FIB when the binary search process ends with a virtual entry. e HPT-FIB is shown in Figure.4. In the hash table, each content name (such as /c1/c4/c5) is calculated as the key, and its value points to the node in the pre x tree. Edges in the pre x tree represent a content name component (such as /c1). Each node represents a content name, which splices all the components on the path from this node to the root. In a tree node, there are ve pieces of information: state, parent node pointer, child node pointer, brother node pointer, forward pointer, which maintain the structure of the tree.

Input:
H : HT and trie-based FIB n: n = "/c 1 /c 2 /.../c N " is the content name to delete Output: H : HT and trie-based FIB, with n deleted 1: lookup n in HT 2: if n is not the name of a real entry (n, e) then 3: return 4: end if 5: if for n's entry (n, e), if e is not a leaf then 6: set e's forwarding information to N/A 7: if e's parent is semi-virtual or real then 8: set e's type to semi-virtual 9: else 10: create an empty queue q and insert e into it 11: while q is not empty do 12: e * = q.pop() 13: set e * 's type to virtual 14: insert all e * 's semi-virtual child nodes into q 15: end while 16: end if 17: else 18: remove e from its parent's child list 19: delete entry (n, e) in HT 20: for i = N − 1 to 1 do 21: for n i = "/c 1 /c 2 /.../c i " and its entry (n i , e i )

22:
if e i is non-real and e i is a leaf then 23: remove e i from its parent's child list 24: Establishing HPT-FIB includes two basic operations: insertion and deletion, whose algorithms are shown in Algorithm. 1 and Algorithm. 2 respectively.
(2) e Inter-translating Scheme In the network, routers in each domain maintain the HPT-FIB of multiple identi ers. is table records various identi ers of resources. e identi er inter-translating scheme is used to provide translation between di erent identi ers when users query resources.
When users register and publish content resources on MIN, the bounded identi ers are stored in the pre x tree whose array header is maintained by forwarding pointer (P F or war d ). When users query with content name, it routes without translation. When users query with another identier, the network searches the P F or war d of the content, then selects the corresponding content name for routing.

(3) e Lookup Algorithm
In order to meet MIN's requirement of large-scale and fast routing, we design a high-speed lookup algorithm of HPT-FIB. It adopts binary search under the longest pre x matching (LPM) principle. As introducing semi-virtual entries, the return values for di erent HITs are di erent from traditional binary searches. Speci cally, there are three pa erns based on the category of the last HIT entry.
• If it is a real entry, the search for LPM is successful, and return the corresponding information. • If it is a virtual entry, it is sure that there is no matching real pre x in the table, so return with no match. • If it is a semi-virtual entry, there is at least one matching real pre x in the table. We can backtrack in the pre x tree to nd the matching real pre x out and return it. Since backtracking in the pre x tree does not involve searching, this process has a minimal time overhead.
So, there are two kinds of lookup results. One is HIT, which means that there is a corresponding real entry in HPT-FIB (i.e., the last HIT entry is real entry or semi-virtual entry). e other is MISS, which means that the corresponding real entry does not exist (i.e., the last HIT entry is virtual). We test these two application scenarios in Section 4.2.

Tunnel Transmission
To promote the progressive deployment of MIN, we propose a tunnel scheme based on the new typed networks. Taking CCN as an example, this section describes the process of using it as a tunnel to transport IP packets.
(1)Problem Description CCN [7] has revolutionized the address-centric transport architecture based on TCP/IP protocol. To realize the progressive deployment, TCP and CCN need to communicate mutually. ere are many di culties with this process. First, TCP is an end-to-end protocol that communicates through IP addresses and port numbers, which contradicts CCN's content-based philosophy. Second, in CCN, communication is a user-initiated process of "pulling" the required data. However, in TCP, it is a "push" process in which the sender sends data, and the receiver replies the acknowledgment message. e two are fundamentally di erent in semantics.
ird, TCP ensures reliable end-to-end transmission, which CCN does not address.

(2)Tunnel Scheme
In the scheme, CCN is directly deployed on the MAC layer of Ethernet to get rid of the dependence on IP completely. e architecture of combining Ethernet transmission, TCP transmission, and UDP transmission is shown in Figure.5.  To enable the two TCP ends to communicate through CCN, the scheme sets a pair of conversion nodes at the boundary between the IP network and the CCN. e transformation between identi ers and encapsulation of packets are carried out in MIR. Each MIR has a name mapped to its IP address as the routing pre x on the CCN, allowing CCN packets to ow smoothly to the designated multi-identi er router for further processing.

IP Network
Connection Establishment: In this scheme, the threeway handshake to establish a connection between two TCP ends of IP networks is modi ed into the three-way Interest packet switches, as shown in Figure.6. e TCP end sends SYN, SYN + ACK, and ACK control signaling to MIR. e CCN transports the TCP control signaling by encapsulating it into the Interest packet header. Finally, the receiving MIR forwards the control signaling to the other TCP end, thus completing the connection establishment of IP-CCN-IP transmission. e four-way handshake of connection termination between the two TCP ends is modi ed to the four-way Interest packet switches. e logic of Interest packets switching in this process is similar to that of the connection establishment.

PROTOTYPE AND EXPERIMENT
We developed a prototype of MIN and deployed it on the actual operators' network. is section tests and analyzes its ability on generation, management, and resolution, including the performances of the consensus algorithm, HPT-FIB query, and VoD service.

Advanced Proof of Vote
is section calculates the throughput of the blockchain consensus algorithm on the management plane of MIN. In APoV, since a new round of consensus can start only a er the end of the current one, we calculate throu hput through the time spent on each round of consensus. Consensus time consists of computation time and transmission time, that is, (1)

(1)Calculation of the Transmission Time t t r an
According to the consensus steps in Section 3.1, in S1, the communication tra c of each bookkeeping node is the sum of block messages sent by it, and the communication tra c of each consortium node is all the block messages it receives. e communication pressure of the bookkeeping node is higher than that of the consortium node, so the transmission time in S1 is the communication time of the bookkeeping node, t 1 t r an = (n b + n c − n bc − 1) · (M + H + T · K)/band (2) where n b , n c and n bc are the number of bookkeeping nodes, consortium nodes and nodes concurrently holding these two identities respectively. M, H and T are the size of the message header, the block header, and the transaction, respectively. K is the maximum number of transactions that can be placed within each block. band is the bandwidth of each node (assuming the same uplink and downlink bandwidth).
To balance the computing power between nodes, we assume that the leader node does not concurrently serve as the consortium node. In this case, the transmission time in S2 is where H and V b are the size of the vote header and the single vote, respectively.
Similarly, the transmission time in S3 is Consider a simple network scenario of consortium blockchain with two servers, where Server A runs a blockchain node, and Server B runs multiple blockchain nodes. To reduce the waste of computing power, we set each node as both bookkeeping node and consortium node. We make the node on Server A the leader node.
Since the bandwidth in Server B is much larger than that between A and B, the transmission time of nodes on Server B can be regarded as 0, and the transmission time of Server A still follows the conclusion above. e advantage of this scenario is that it eliminates the impact of asynchronous transmission on performance in distributed networks, and only analyzes computational factors. e blockchain parameters of the prototype are K = 10000, M = 266B te, H = 692B te, T = 40B te, H = 400B te, V b = 100B te, H r = 170B te, R b = 400B te, band = 1Gbps = 125MB/s, and the CPU of the server is Intel Xeon Silver 4114@2.20GHz. From the perspective of Server A, the states of the single blockchain node and the whole blockchain network can be observed simultaneously. We run 10 rounds of consensus at di erent scales. e time consumption of each step and each round is measured on Server A and averaged, as shown in Table. 1.
According to the consensus steps in Section 3.1, the relationship between the time consumption of S1, S2 and S4 and the number of nodes n is linear. In S3, when n increases, the number of blocks that each consortium node needs to vote increases, so its time consumption can be described by a quadratic function. e time consumption of each step in Table. 1 is ed to t 1 comp = 0.0041n + 0.0174 t 2 comp = 0.0130n + 0.0229 t 3 comp = 0.0012n 2 − 0.0082n + 0.0415 t 4 comp = 0.0052n + 0.0062 (6) Further understanding of Equation (6) is that, t 1 comp is re ected in the computation of the bookkeeping node, t 2 comp in the computation of the consortium node, t 3 comp in the computation of the leader node, and t 4 comp in the computation of each node.
According to Equation (2)-(5), the transmission time t t r an is a cubic function of the number of nodes n, so the consensus time t cons can be described by a cubic function. e consensus time in Table. 1 is ed to t cons = 0.0312n 3 − 0.1920n 2 + 2.0714n + 11.2500 125 Substitute the parameter value of the prototype into Equation (2)-(5) to get the transmission time is t t r an = t 1 t r an + t 2 t r an + t 3 t r an = 0.0001n 3 + 0.0008n 2 + 0.3213n − 0.3214 125 (8) According to Equation (1), the computation time is t comp = t cons − t t r an = 0.0311n 3 − 0.1928n 2 + 1.7501n + 11.5714 125 Consider the further understanding of Equation (6). Take the computing power of the servers in the prototype as the standard. For a blockchain network with computing power a, that is, the maximum computing power used by all nodes for consensus is a times of the standard computing power, then the minimum computation time is shown in Equation (10).
According to Equation (5) and (10), the minimum consensus time in the network is t cons = t comp + t t r an (11) To sum up, the upper limit of throughput within the blockchain network is shown in Equation (12).
Based on Equation (12), it is possible to estimate the upper limit of performance in the real blockchain network composed of servers and switches using APoV consensus algorithm. In the consortium blockchain network, each server typically runs only one node. Assuming that the other congurations of nodes are the same, when their CPUs are Intel Xeon Silver 4114@2.20GHz, Intel Xeon Silver 4116@2.10GHz, and Intel Xeon Gold 5118@2.30GHz respectively 1 , the upper limit of throughput is a ected by n and band, as shown in Figure.7 (1)- (3). When the bandwidth of nodes is set as 1Gbps, 8Gbps and 10Gbps respectively, the in uence of n and a on the upper limit of throughput is shown in Figure.7 (4)- (6).
When the number of nodes is small (generally less than 10), the computing power used for consensus is not fully utilized, so the number of nodes is the main factor a ecting the throughput. When the number of nodes increases, the performance can be approximately increased with the improvement of computing power and bandwidth.
At present, the throughput of most blockchain consensus algorithms is less than 100 thousand transactions per second [19]. We measure the prototype consisting of 20 blockchain nodes, each of which is responsible for both voting and bookkeeping. e APoV consensus can achieve a stable throughput of more than 300 thousand transactions per second. Although the actual value is much lower than the theoretical value in Figure. 7, it greatly exceeds other  consensus algorithms. We will continue optimizing the algorithm code of APoV to utilize the computing power and bandwidth in the network entirely.

FIB Combining Hash Table and Pre x Tree
is section calculates the scale and throughput of HPT-FIB algorithm on the data plane of MIN.
(1)Scalability e data source of the experiment is the self-generated CCN content names. As CCN has not deployed on a large scale, it is di cult to obtain large-scale CCN dataset from the real network. erefore, we extract statistical features from the current network ow and obtain a large number of random URL-like names through simulation to generate a large-scale HPT-FIB. e test of building time for HPT-FIB is shown in Table. 2.
e test result indicates that the HPT-FIB in this scheme can support large-scale pre x of content names storage.
(2)Lookup Performance In this section, we test the lookup speed of HPT-FIB. e contrast algorithm includes LPM-based linear search and LPM-based binary search without backtracking in the pre x tree. As mentioned above, there are two kinds of lookup results: HIT and MISS. We test these two application scenarios.
For every testing, we lookup 500,000 times in HPT-FIB, which contains 5 million real entries. e above experiments are carried out ten times, and we count up their average values for evaluation and analysis. For the sake of comparison, the measurement is set to Operation roughput, which is inversely proportional to the average operating time. Also, the throughput rate for linear search is set to 1 as a benchmark.
When the average length of the content names to be searched is N , and the result is all MISS, which means that none inquired content name correspond to a real entry in HPT-FIB, the performances are shown in Table. 3.
When lookup does not HIT, the linear search needs to traverse all pre xes of content names. e time cost is proportional to the length of content names, causing problems about e ciency and security. In contrast, binary search reduces the computational overhead of the LPM algorithm to the logarithmic level, which signi cantly improves the throughput. Also, since our algorithm needs no backtracking when lookup ends without HIT, the time cost is close to the original binary search. As a result, we solve the false negative error with acceptable costs.
For the lookup test of all HIT which means that every inquired content name corresponds to a real entry in HPT-FIB, we assume that the average length of content names is M with distribution ρ(N ;λ). Since the average length of domain names is 2 or 3 and CCN content names are generally longer than URL requests in HTTP, we use M = 4, 5 as the test parameter. e performances of all HIT are shown in Table. 4.
When lookup ends with HIT, the average time cost of the linear search is proportional to (N −M +1). e time of binary search is almost not a ected by M and is approximately proportional to lo (N ). For the scenarios with long content  e prototype realizes tunnel transmission under various  network scenarios, including IP-CCN-IP, IP-CCN, CCN-IP, and CCN-IP-CCN. e topology is shown in Figure.8. Based on this, the prototype can provide High De nition Video on Demand (HDVoD) service with multiple transmission channels.

Tunnel Transmission
e exporting bandwidth of the servers in Peking University Shenzhen Graduate School (PKUSZ) is 100M special broadband, and that of other institutions is also more than 50M. On top of the bandwidth constraint, the network environment di erences between operators and between mainland China, Hong Kong, and Macao may limit the transmission rates. e following are the experimental results of our prototype under four scenarios.

(1)IP-CCN-IP Transmission
Video resources are uploaded on the node pkusz1 of China Telecom Futian and the node pkusz3 of China Telecom Nanshan. We rst use node10 of PKUSZ as MIR and node9 of PKUSZ as the IP node to pull the video from pkusz1 to node9. Figure.9 shows the detailed topology and the experimental result. It can be seen that the transmission rate reaches 2.65MB/s. We then pull the video resource from pkusz3 to node9. e detailed topology and the experimental result are shown in Figure.10, where the transmission rate is 2.44MB/s. When video resources on pkusz1 and pkusz3 are pulled to node9 simultaneously, the rates of the two transmission channels are 1.18MB/s and 1.71MB/s respectively, as shown in Figure.11. e transmission rate is lower than before when pulling from a single node, but the total transmission rate remains the same. e main reason is that the access bandwidth of node9 is limited, resulting in the performance bo leneck.
(2)IP-CCN Transmission e video resource is uploaded on the node host2 of China Unicom Tongle in CCN. As with the IP-CCN-IP transmission, we get the video from host2 to node9 through node10. e tested transmission rate is 0.65MB/s.

(3)CCN-IP Transmission
e video resource is uploaded on the node dcni1 of Guangdong Communications & Networks Institute (DGCNI) in the IP network. Similarly, we pull the video from dcni1 to the node host1 of Kingso . e tested transmission rate is 1MB/s.

(4)CCN-IP-CCN Transmission
We have also implemented the CCN-IP-CCN transmission in the prototype of MIN. In this experiment, we place the video resource on the node host2 of China Unicom Yuandong, and pull it to the node SCUT of South China University of Technology (SCUT). e tested transmission rate is 2.65MB/s.

CONCLUSION AND FUTURE WORK
A future network should be decentralized, secure and compatible with the existing IP-based network. In this paper, we propose a Multi-Identi er Network that constructs a network layer with parallel coexistence of multiple identi ers, including identity, content, geographic information, and IP address. e network provides the generation, management, and resolution services of identi ers and use consortium blockchain to enable decentralized management. To further accelerate the forwarding process, we improve HPT for FIB by combining hash table and pre x tree. In addition, we propose a scheme of transporting IP packet using CCN as a tunnel to support progressive deployment. Finally, we develop the prototype to operators' networks and verify its performances of the consensus algorithm, FIB query, and VoD service.
e test results illustrate that the network achieves excellent performance and can support real-world applications a er further development.