NDNFlow: Software-Defined Named DataNetworking

Niels L. M. van Adrichem and Fernando A. Kuipers

Network Architectures and Services, Delft University of TechnologyMekelweg 4, 2628 CD Delft, The Netherlands{N.L.M.vanAdrichem, F.A.Kuipers}@tudelft.nl

Abstract—In this paper, we introduce NDNFlow: an open-source software implementation of a Named Data Networkingbased forwarding scheme in OpenFlow-controlled Software-Defined Networks (SDNs). By setting up an application-specificcommunication channel and controller layer parallel to theapplication agnostic OpenFlow protocol, we obtain a mechanismto deploy specific optimizations into a network without requiringa full network upgrade or OpenFlow protocol change.

Our open-source software implementation consists of bothan NDN-specific controller module and an NDN client plug-in.NDNFlow allows OpenFlow networks with NDN capabilities toexploit the benefits of NDN, by enabling the use of intermediatecaches, identifying flows of content and eventually performingtraffic engineering based on these principles.

I. INTRODUCTION

Recently, Software-Defined Networking (SDN) has gainedthe interest of both research and industry. For research, SDNopens up the possibility to implement optimizations thatpreviously were theoretical in nature due to implementationcomplexity. For industry, SDN delivers a way to dynami-cally monitor and control the network beyond the capabilitiesof self-organized distributed traffic engineering and failovermechanisms.

OpenFlow [1] is often considered to be the de facto standardto implement SDN. Other emerging future internet architec-tures, such as Information Centric Networking (ICN), intro-duce application-specific forwarding schemes. In particular,we believe that SDN and ICN can benefit from each other.SDNs can benefit from the power of caching from ICNs andin general need to be able to quickly adapt to new application-specific forwarding schemes, such as ICNs. ICNs, on the otherhand, greatly benefit if they can be adopted with little effort byalready existing SDNs. Furthermore, the benefits of SDN toIP, being greater management control and monitoring over thenetwork, also apply to ICNs. Finally, ICNs benefit from SDNsas they can efficiently distribute content in partially upgradednetworks, removing the necessity to upgrade the full networkand thus easing the deployment and transition phase.

In this paper, we discuss our experiences in setting up anSDN for the application-specific forwarding mechanism ofNamed Data Networking (NDN) [2], a popular ICN imple-mentation. Although this paper is dedicated to setting up an

SDN-supported ICN, our experiences and decisions also applyto other forwarding mechanisms that may emerge.

In section II, we first discuss the initial principles of SDNand OpenFlow. In section III, we explain the functionalityof the ICN implementation NDN. Section IV presents ourtwo initial proposals toward application-specific SDNs andreasons why we think these approaches are infeasible forstandardization. Section V proposes our mechanism in whichwe have divided the SDN in two layers: the regular OpenFlowlayer based on traditional forwarding mechanisms, supple-mented with an application-specific layer. Section VI presentsthe exact details of our implementation. Section VII presentsexperimental measurements performed on NDNFlow. Finally,section VIII concludes this paper.

II. SOFTWARE-DEFINED NETWORKING

In its initial form, Software-Defined Networking (SDN)concerns separating the control plane (decision functions) fromthe data plane (forwarding functions) in networks. This enablesa more flexible form of networking in which abstract businessrules in terms of robustness, security and QoS can be translatedinto a network configuration policy. In turn, the configurationpolicy can be configured in the networking devices using eitheran abstract configuration interface (such as OpenFlow [1],OpenFlow Config [3], OVSDB [4], ForCES [5] or NetConf[6]) or vendor-specific configuration parameters.

SDN allows applications to request QoS parameters on-the-fly from a network control agent. This enables scenarios inwhich applications can offer guaranteed quality by negotiatingthe service they need from the network and ultimately pay forthat service for the time they need it.

Software-Defined Networking is often associated with thenetwork configuration protocol OpenFlow [1]. OpenFlow isa vendor-independent protocol which can configure networknodes both in advance, and in a reactive fashion. OpenFlow-enabled switches connect to a single controller entity, whichconfigures the switches based on their topological propertiesand predefined rules concerning routing, firewalling and QoS.Additionally, when a switch receives a packet for which it hasno installed flows yet (i.e., it is a new connection not matchingany predefined rules), it sends this packet to the OpenFlowcontroller. The OpenFlow controller performs access control978-1-4799-7899-1/15/$31.00 c©2015 IEEE

and computes the appropriate path for the new data flow andconfigures all switches accordingly.

III. NAMED DATA NETWORKING

In this section, we summarize Named Data Networking(NDN) [2] and its implementation CCNx [7]. CCNx im-plements an Information Centric Network (ICN) by using aroute-by-name principle. In contrast to identifying by sourceand destination IP addresses, NDN identifies Interest andContentObject packets by one or more name components (forexample, Bob could publish his holiday photos under thename /bob.eu/holidayPhotos). A user-client requests contentby sending out an Interest containing a name describing thedesired information. Intermediate nodes on the path fromclient to server forward the expressed Interest hop-by-hop tothe generator responsible for the requested name. When theInterest reaches a node that has a cached copy satisfying thedescription of the Interest, the Interest is dropped and the datais delivered from cache. If not, the Interest travels the pathto the content generator, which creates a ContentObject anddelivers it to the client accordingly.

The resulting content is encapsulated in a ContentObjectand forwarded along the exact reverse path back to the client.Functionally, each intermediate node administers the followingthree tables in its memory:

1) The ContentStore (CS), which contains cached copiesof previously delivered content.

2) The Pending Interest Table (PIT), which stores recentlyforwarded Interests and their originating interfaces.

3) The Forwarding Information Base (FIB), containingforwarding rules based on the NDN names.

Each incoming Interest is compared to the content of the CSto determine if it can be fulfilled from cache immediately.If not, the packet name is compared to the PIT content toprevent forwarding of duplicate requests. Finally, the FIB isconsulted to determine the forwarding actions. The Interestand its originating interface are added to the PIT, enabling theresulting ContentObject to travel to the requester by source-based routing. Where IP prefix matches on a fixed numberof bits, NDN prefix matches on a variable number of sub-sequent name components. With each subsequent component,the Interest name adds a restrictive element to the possibleset of valid ContentObjects. For example, an Interest named/bob.eu/holidayPhotos prefix matches a ContentObject for/bob.eu/holidayPhotos/2013, as the requester did not specifythe exact holiday period or location.

IV. RELATED WORK

In order to use SDN and OpenFlow to set up ICN networks,we have evaluated multiple techniques before coming to ourfinal proposal in section V. In this section, we discuss previousinitiatives and parts of our early work and argue why we thinkthese are not feasible for standardization.

A straightforward way to implement ICN using SDNsis to implement ICN functionality into the Open vSwitchspecification and enhance the OpenFlow protocol to support

ICN names, as suggested in [8]. We, however, think the jointmaturing of both ICN protocols and the OpenFlow protocolwill increase the complexity of realizing a stable standard-ization of OpenFlow that supports both regular IP/Ethernetforwarding and ICN. As [9] shows, the concept of naming inNDN is, among others, still subject to further optimization todecrease routing table size and thereby increase the forwardingefficiency. Given that the standardization of OpenFlow forregular packet forwarding is already a complex task, chancesthat standardization will include application-specific forward-ing schemes are small.

Even if standardization would include an ICN protocol, weforesee a rise in application-specific forwarding schemes ingeneral to optimize the Internet for the most frequently usedapplications. One application-specific adaptation of OpenFlow,or any SDN paradigm for that matter, would exclude otherapplication-specific forwarding schemes facing identical prob-lems.

Both [10] and [11] propose to reuse IP’s address andport fields to contain hashes of content names in order toallow OpenFlow switches to forward Interests to an OpenFlowcontroller that performs path calculation. Where [10] usesadditional IP-options to indicate ICN packets, [11] remainsagnostic to how ICN packets are distinguished from regularIP packets. We argue that this approach leads to an excessiveincrease in IP routing table complexity.

Similarly, we at first intended to wrap or encapsulate ICNstreams in IP packets containing a reserved IP anycast addressto allow fine-grained control beyond the scope of ICN-capableswitches. We found this method to be less trivial than itappears. Where CCNx is already capable of performing UDPover IP encapsulation, it uses static ports for each connection,disabling a switch to differentiate between different flows.As the CCNx application is OpenFlow unaware by nature,changing it by generating different tuples of source IP addressand the 4 bytes of the UDP source and destination portsimplied a drastic change to the internal functions of the CCNxdaemon. More generically, forcing developers to create porttuples in such a specific way in order to benefit from SDNfunctionality is in contrast with the open philosophy of SDN.Furthermore, OpenFlow switches may not send the completeincoming CCNx packet to the controller, they may applybuffering to recreate the original message when necessary, butinstead might only forward the first part of the message. Thisimplies possibly losing parts of the ICN name, informationnecessary for the ICN controller to perform path computation.

Finally, P4 [12] and POF [13] respectively implement apacket processor description language and forwarding archi-tecture design to allow protocol-oblivious forwarding, workresulting in the ONF OF-PI proposal [14]. However, P4 im-plements static field sizes, rendering it unsuitable for use withthe CCNx implementation, which carries a variable amountof variable-sized name components. Furthermore, while using{offset, length} search keys as proposed in POF may work,we consider the complexity of rewriting all abstract compar-isons and functions to bit-wise operators too tedious.

OF Controller

Interest

ICN Module

(a) Step 1, local NDN daemon receives an unasso-ciated Interest and forwards this Interest to the ICNmodule of the OpenFlow Controller.

OF Controller

Interest

ICN Module

Content

(b) Step 2, with the knowledge on topology and ICNcapabilities, the ICN module computes a feasiblepath and configures the appropriate ICN-enabledswitches accordingly.

OF Controller

Interest

ICN Module

Content

(c) Step 3, the ICN module instructs the legacyOpenFlow controller to configure the necessaryIP/Ethernet rules on all intermediate OpenFlow en-abled switches.

Fig. 1: An overview of the steps necessary to configure an ICN flow over an OpenFlow-enabled network. All switches areOpenFlow capable, doubly-circled nodes additionally have ICN capabilities.

V. NDNFLOW

Given that neither extending the OpenFlow protocol forapplication-specific forwarding schemes nor using application-specific IP broadcast addresses to distinguish ICN traffic fromregular IP traffic is feasible, NDNFlow introduces a secondapplication-specific layer to OpenFlow. NDNFlow implementsa separate communication channel and controller module par-allel to the already existing OpenFlow communication channeland process.

In this application-specific layer, all communication andpath computation regarding the ICN are handled separatelyfrom the regular IP and Ethernet plane. By separating the ICNlayer from the regular OpenFlow layer, we introduce SDNfunctionality independent of changes and restrictions in thestandardization of the OpenFlow protocol. This prevents inter-dependencies on versions of protocols, easing the deploymentand future maintenance. As shown in figure 1, switches that areICN enabled set up a communication channel, parallel to theirregular OpenFlow communication channel, to the ICN moduleof the OpenFlow controller. This ICN channel is then usedto announce ICN capabilities, information availability andrequests for unreserved flows. The controller’s ICN modulecomputes paths for ICN flows, and configures both the ICNcapable and legacy IP and Ethernet switching fabric to allowICN flows to pass through the network. Hence, we introduce aseparate SDN control mechanism for the application-specificOSI Layers 5 to 7 (ICN), independent from OSI Layers 2 to4, reusing the separation of layer responsibilities to maintainoverall network manageability.

Where ICN-enabled switches receive ICN-specific flowsdirectly, flows between ICN-enabled switches that are ini-tially unreachable due to intermediate legacy IP and Ethernetswitches are realized by setting up IP-encapsulated tunnels.The legacy switches are configured by the legacy OpenFlowcontroller to forward those tunnels accordingly. Hence, theconfiguration procedure consists of 4 steps shown in figure 1,where a doubly-circled node represents a switch capable ofboth ICN and OpenFlow.

Due to the fact that both the ICN-enabled switches and theICN controller module are aware of the specifics of the ICNforwarding mechanism, they have equal understanding of anICN flow and its details. Furthermore, their communication

protocol can be extended to contain flow-specific parameters,such as the needed bandwidth and the expected duration of aflow, without changing the OpenFlow protocol.

VI. IMPLEMENTATION

Our software currently runs on general purpose x64 archi-tecture servers running Ubuntu Server. On these servers, wehave installed stock Open vSwitch 2.0.2 [15] to enable config-uration of operation by the OpenFlow protocol. In addition, weenable switches with ICN capabilities by installing the CCNxdaemon [7], the open-source implementation of NDN.

A. OpenFlow controller implementation

In order to implement our proposal, we have extended thePOX (branch betta) controller [16] by designing an additionalcustom ICN module. We use the native POX Discoverymodule to perform topology discovery and learn a switchadjacency matrix. We reuse the OpenNetMon [17] forwardingmodule to perform legacy path computation and enable end-to-end IP forwarding. Additionally OpenNetMon may be usedto perform fine-grained monitoring of flows. Finally, we im-plement a CCNx specific plug-in that is added to communicatewith ICN-enabled switches and perform ICN-specific pathcomputations. The implementation of NDNFlow is publishedopen source and can be found at our GitHub web page [18].

B. CCNx daemon implementation

The CCNx daemon is extended by implementing an addi-tional SDN plug-in, which sets up a connection to the POXICN module, parallel to Open vSwitch’s regular OpenFlowconnection, and announces its ICN capabilities, capacity andinformation availability. The extension is realized similarly toour plug-in solving global NDN routing table complexity [9].Whenever a CCNx daemon receives an Interest for which noflow or previously defined forwarding rule exists, it forwardsthis Interest to the POX ICN module. In turn, the POX ICNmodule looks up the appropriate location or exit-point ofthat Interest, calculates the appropriate path based on thetopology information learned from the discovery module andannouncements from CCNx-enabled switches and configuresthe intermediate NDN nodes accordingly. Finally, the OpenvSwitch is configured by the controller as shown in figure 1.

C. Protocol Implementation

We chose to use the JavaScript Object Notation (JSON)to facilitate communication between the CCNx and SDNmodule due to its generic implementation and high supportin different programming languages. Currently, we imple-ment the following abstract messages to support our actions.

Announce{DPID : <DataPathID > ,IP : <I n e t A d d r e s s>

}

The Announce message is used by nodes to prop-agate their ICN abilities. More precisely they statewhere they are connected in the OpenFlow network us-ing the unique Datapath ID (DPID) of the switch,and how the ICN functions can be accessed by IP.

A v a i l a b l e C o n t e n t {C o n t e n t : [

<(ContentName ) Name> : {Cost : <I n t e g e r > ,P r i o r i t y :< I n t e g e r >

}]

}

After authentication, the ICN-enabled switch propagatesthe information it has access to using the AvailableContentmessage. Each item can be stored locally or accessed else-where, for example via a network outside of the scope ofthe SDN, and additional costs can be added which are takeninto account by routing discovery. Absolute backup replicas,which are only to be accessed when the primary replicas areunavailable, can be announced by increasing the value of thePriority field. Hence, robustness can easily be implemented byplacing redundant copies of information across the network.

I n c o m i n g I n t e r e s t {Name : <ContentName>

}

The IncomingInterest message is used by the CCNxmodule to request the controller what action to per-form with unmatched incoming and following Interests.

I n s t a l l F l o w {name : <ContentName > ,a c t i o n : <FaceType > ,a c t i o n P a r a m s : [<params >]

}

After computing the appropriate actions, the controller is-sues an InstallFlow message to all the switches along the pathto install the correct forwarding rules, reducing the originalinterest name to match the name prefix of a complete flowor segmented piece of information. The FaceType and actionparameters can be used to configure flow-specific parameters.Among others, we use them to set up IP-encapsulated tunnelsbetween ICN nodes that are separated by one or more ICN-

incapable switches to enable flow exchange between them.

VII. EXPERIMENTAL EVALUATION

In this section, we will first discuss our experimental setupand the used measurement techniques, followed by the con-ducted experiments and results.

A. Testbed environment

We have conducted our experiments on a testbed of phys-ical, general-purpose, servers all having a 64-bit Quad-CoreIntel Xeon CPU running at 3.00 GHz with 4.00 GB of mainmemory and 1 Gbps networking interfaces. OpenFlow switchfunctionality is realized using the Open vSwitch 2.0.2 softwareswitch implementation, Named Data Networking functionalityby installing CCNx 0.8.2, both running in parallel on UbuntuServer 14.04.1 LTS with GNU/Linux kernel version 3.13.0-29-generic. The CCNx is connected to Open vSwitch via a socketto the internal bridge interface to realize connectivity, hencedata is forwarded to and from CCNx through the OpenFlowLOCAL port.

Throughout, we use a 2-switch topology on which thediscussed switching fabric and additional plug-ins from sectionVI are configured. A third server is configured as controllerusing the POX controller and modules discussed in section VI.

In order to measure the delay time between requesting andreceiving content we use ccnping [19], an NDN alternativeto the popular application ping that can be used to confirmconnectivity and measure round-trip times in classical IP net-works. Similar to ping, ccnping sends an Interest per intervalto a given destination prefix concatenated with a randomvalue. When sending, ccnping stores the timestamp of creationand computes the round-trip time (RTT) upon arrival of theappropriate ContentObject. The ccnping server and client areinstalled on the 2 switches and connect to the CCNx switchfabric using the application interface.

B. Experiments and results

Using the described testbed and tools, we have performed4 types of experiments to evaluate the suitability and stabilityof NDNFlow. In our experiments, we differentiate betweenthe proactive and reactive SDN approaches in which flowsare respectively configured in advance, or on-the-fly. As thedecision between proactive and reactive configuration canbe made independent for both the CCNx and OVS specificforwarding fabric, we perform the following 4 experiments:(1) We determine a baseline by measuring RTTs using astatically configured CCNx over classic IP. (2) We determinethe overhead of Open vSwitch and the NDNFlow CCNx-plug-in by measuring RTTs in a proactively configured CCNx andOpen vSwitch network. Since the biggest difference betweenproactive and reactive configuration lies within the delay ofsetting up the flow (measurable by the delay of the firstpacket), we continue measuring the delay of the first packetof every new flow with a reactive configuration of CCNx inboth a (3) proactive and (4) reactive configured OVS network.

4

3

2

1

0

Dela

y (

ms)

1000080006000400020000

Sample (t)

Open vSwitchRegular IP

Fig. 2: Baseline measurements usingCCNx over regular IP and OVS.

2000

1500

1000

500

0

Dela

y (

ms)

1000080006000400020000

Sample (t)

Reactive NDN and IPReactive NDN

Fig. 3: Measured delay of CCNx pathsetup in pro- and reactive configuration.

300

250

200

150

100

50

0

Dela

y (

ms)

Regular IP Open vSwitch Reactive NDNReactive NDN and IP

Fig. 4: Delay averages and 95% confi-dence interval.

While experiment (3) shows the delay invoked by comput-ing and configuring the path of the content flow, (4) shows thedelay invoked by additionally configuring the legacy IP partof the OpenFlow network. We measured 10, 000 samples foreach configuration.

Figure 2 shows the results for (1) and (2), while figure 3shows the results for (3) and (4). Figure 4 shows the relativeaverages and 95% confidence interval, giving: (1) a baseline of1.534±0.101 ms for CCNx over IP networks, (2) 1.834±0.115ms for a fully proactive configuration of CCNx and OVS,and (3, 4) 64.006 ± 5.028 and 304.630 ± 34.191 ms for areactive NDNFlow configuration in a proactive and reactiveOVS configuration, respectively, to determine the additionalcosts of configuring the content flows in CCNx and OVS.

The measured values show that, on average, OVS adds anadditional delay of 0.300 ms, while configuring a new contentflow using NDNFlow costs an additional 62.172 ms at theCCNx daemon and another 240.624 ms at the OVS daemon.Although setting up new flows can be considered costly, theadditional delay only applies to the first packet of a newflow. Once a flow has been installed, the delays of experiment(2) apply. Using a completely proactive configuration wouldremove the additional delay of methods (3) and (4) altogether,though at the cost of losing the flexibility of computing flow-specific paths.

VIII. CONCLUSION

In this paper, we have presented and designed a mechanismand implemented a prototype to realize application-specificforwarding schemes in OpenFlow-controlled Software-Defined Networks (SDNs). Specifically, we have implementeda popular Information Centric Networking proposal, NamedData Networking and its implementation CCNx. Comparedto other application-specific SDN implementations, we arguethat our implementation is architecturally less complex toimplement, easier to extend and furthermore applicableto multiple application-specific forwarding schemes dueto the stricter separation of functionalities. With thisimplementation, we provide the tools to control and manageapplication-specific flows in SDNs.

REFERENCES

[1] N. McKeown, T. Anderson, H. Balakrishnan, G. Parulkar, L. Peterson,J. Rexford, S. Shenker, and J. Turner, “OpenFlow: enabling innovation incampus networks,” ACM SIGCOMM Computer Communication Review,vol. 38, no. 2, pp. 69–74, 2008.

[2] V. Jacobson, D. K. Smetters, J. D. Thornton, M. F. Plass, N. H. Briggs,and R. L. Braynard, “Networking named content,” in Proceedings of the5th international conference on Emerging networking experiments andtechnologies. ACM, 2009, pp. 1–12.

[3] Open Networking Foundation, “OF-CONFIG 1.2: OpenFlowManagement and Configuration Protocol,” https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/openflow-config/of-config-1.2.pdf, 2014.

[4] B. Pfaff and B. Davie, “The Open vSwitch Database ManagementProtocol,” RFC 7047 (Informational), Internet Engineering Task Force,Dec. 2013. [Online]. Available: http://www.ietf.org/rfc/rfc7047.txt

[5] A. Doria, J. H. Salim, R. Haas, H. Khosravi, W. Wang, L. Dong,R. Gopal, and J. Halpern, “Forwarding and Control Element Separation(ForCES) Protocol Specification,” RFC 5810, Internet Engineering TaskForce, Mar. 2010. [Online]. Available: http://www.ietf.org/rfc/rfc5810.txt

[6] R. Enns, M. Bjorklund, J. Schoenwaelder, and A. Bierman,“Network Configuration Protocol (NETCONF),” RFC 6241, InternetEngineering Task Force, Jun. 2011. [Online]. Available: http://www.ietf.org/rfc/rfc6241.txt

[7] Palo Alto Research Center, “CCNx,” http://www.ccnx.org/, Dec. 2012.[8] J. Suh, “OF-CCN: CCN over OpenFlow,” http://

netlab.pkusz.edu.cn/wordpress/wp-content/uploads/2012/07/Content-Networking-over-OpenFlow.pdf, 07 2012.

[9] N. L. M. van Adrichem and F. A. Kuipers, “Globally accessible namesin named data networking,” in Proc. IEEE INFOCOM Workshop onEmerging Design Choices in Name-Oriented Networking (NOMEN).IEEE, 2013.

[10] N. Blefari-Melazzi, A. Detti, G. Mazza, G. Morabito, S. Salsano, andL. Veltri, “An openflow-based testbed for information centric network-ing,” Future Network & Mobile Summit, pp. 4–6, 2012.

[11] X. N. Nguyen, D. Saucez, T. Turletti et al., “Efficient caching inContent-Centric Networks using OpenFlow,” in INFOCOM 2013 StudentWorkshop, 2013.

[12] P. Bosshart, D. Daly, G. Gibb, M. Izzard, N. McKeown, J. Rexford,C. Schlesinger, D. Talayco, A. Vahdat, G. Varghese, and D. Walker,“P4: Programming Protocol-independent Packet Processors,” SIGCOMMComput. Commun. Rev., vol. 44, no. 3, pp. 87–95, Jul. 2014.

[13] H. Song, “Protocol-oblivious forwarding: Unleash the power of SDNthrough a future-proof forwarding plane,” in Proceedings of the secondACM SIGCOMM workshop on Hot topics in software defined network-ing. ACM, 2013.

[14] Open Networking Foundation, “OF-PI: A protocol independentlayer,” https://www.opennetworking.org/images/stories/downloads/sdn-resources/white-papers/OF-PI A Protocol Independent Layerfor OpenFlow v1-1.pdf, 09 2014.

[15] B. Pfaff, J. Pettit, K. Amidon, M. Casado, T. Koponen, and S. Shenker,“Extending Networking into the Virtualization Layer.” in Hotnets, 2009.

[16] M. McCauley, “About POX,” http://www.noxrepo.org/pox/about-pox/,Aug. 2014.

[17] N. L. M. van Adrichem, C. Doerr, and F. A. Kuipers, “OpenNetMon:Network Monitoring in OpenFlow Software-Defined Networks,” inNetwork Operations and Management Symposium (NOMS). IEEE,2014.

[18] N. L. M. van Adrichem and F. A. Kuipers, “TUDelftNAS/SDN-NDNFlow,” https://github.com/TUDelftNAS/SDN-NDNFlow, Mar.2015.

[19] (2014, Dec.) NDN-Routing/ccnping. https://github.com/NDN-Routing/ccnping.