SRAN: Scaling Named Data Networking via Map-and-Encap Tianyuan Yu, Sirapop Theeranantachai, and Lixia Zhang
arXiv:2607.20363v1 [cs.NI] 22 Jul 2026
Department of Computer Science University of California, Los Angeles Los Angeles, CA, USA {tianyuan, stheera, lixia}@cs.ucla.edu
Abstract—Network routing scalability is hard to achieve when forwarding state is driven by external entities such as end users or multicast groups. Named Data Networking (NDN) faces this challenge acutely: it fetches data by name, which ties forwarding state to an unbounded number of application name prefixes. This paper presents SRAN, a scalable routing and forwarding architecture for NDN. Building on the Map-andEncap principle, SRAN separates name-prefix reachability from topological reachability by mapping prefixes to egress routers at the network edge. Consequently, the network core routes and forwards based solely on topological connectivity. SRAN extends this mapping to support multicast by adapting Bit Index Explicit Replication (BIER), encoding prefix-to-multiple-egress mappings as a BitString to enable stateless multicast delivery. Implemented on the NDN substrate, SRAN leverages NDN’s native security and dataset synchronization for secure routing and prefix-state dissemination, requiring no additional protocol. Evaluation on representative Rocketfuel topologies confirms that the network forwarding state scales with the topology rather than the application-prefix count, and adapts to prefix changes in real time with minimal dissemination overhead. Index Terms—Routing, Named Data Networking
I. I NTRODUCTION Named Data Networking (NDN) [1] fetches data by semantically meaningful names. Consumer applications issue Interest packets for named, secured data, routers forward those Interests toward producers, data delivery benefits from in-network caching, and the network can quickly adapt to failures and support load balancing through its stateful forwarding plane. NDN has been explored for efficient content retrieval, realtime media, collaborative applications, and Publish/Subscribe communication [2]–[5]. However, these exploratory experiments also reveal longstanding network routing challenges. First, forwarding named Interest packets causes network routing to scale with the number of name prefixes, which is unbounded. Second, NDN supports multiparty applications via its transport protocol Sync, which relies on network multicast forwarding to deliver Sync Interests to a group of participants in the same application [4], [6]–[8]. Unfortunately, traditional network multicast solutions cause routers’ forwarding state to grow with the number of multicast groups. The two problems share the same root cause: they require network routing to establish reachability to logical identifiers (application prefixes or group members) which are unbounded.
A recent study summarizes the evolution of IP network routing scalability efforts over the four decades and observes that Map-and-Encap is a recurring architectural pattern shared by all scalable routing solutions developed independently across different problem contexts [9]. The basic idea of Mapand-Encap is to map unbounded external identifiers to their attached topological points, enabling the network to route based on topological connectivity. [9] further unifies the scalability solution for unicast and multicast by explaining that a more recent multicast solution, Bit Index Explicit Replication (BIER), scales multicast forwarding by mapping the members of a multicast group to a binary string, thus falling under the Map-and-Encap design pattern. The paper also points out that a key component in Map-and-Encap is the creation and maintenance of the mapping system, as the external identifiers can appear and disappear dynamically, or change their topological attachment points over time. Following the map-and-encap paradigm, this paper introduces a Scalable Routing Architecture for NDN, SRAN, to support scalable unicast and multicast forwarding in a unified way. Specifically, we make three contributions: We design SRAN, a scalable routing architecture for NDN that separates prefix reachability from topological reachability. SRAN stores the mapping between the two at network edges, uses the same mapping for both unicast and multicast delivery, and enables network routing and forwarding based solely on network topology. • We implement SRAN on the NDN substrate. By leveraging the existing NDN security solutions and group dataset synchronization, SRAN has routing security natively built-in and provides prefix-to-routing mapping in a simple and straightforward way. • We develop a Golang-based SRAN implementation and our experiments show that routers’ forwarding states scale with the network topology, not the application prefixes used in Interest packet delivery, and SRAN achieves realtime dissemination of prefix-to-router mapping with low communication overhead. •
The remainder of this paper is organized as follows. Section II provides background information on NDN and BIER. Section III presents the SRAN design, including the forwarding design, multicast support, the control plane components,
Interest
Content Store
Pending Interest Table (PIT)
Strategy FIB
Data
Add Incoming Interface
Downstream
Drop or NACK
Upstream Router
Forward
Pending Interest Table (PIT)
Cache
Lookup Miss Lookup Hit
Content Store
Discard data
shared state among group entities. Sync abstracts the state as aInterest collection of [producer, seq] tuples that represent Name: group-chat.com/bob/seq=123 the aggregate group state as a cumulative vector. When a Forward Parameters: Lifetime = 1s producer generates data, it multicasts a Sync Interest carrying the updated state vector (as an encapsulated Data) to the group, allowing all participants to discover new data names promptly. The extensive use of Sync in NDN applications places a Data heavy demand on the network to support scalable multicast, Name: group-chat.com/bob/seq=123 a requirement SRAN addresses through its integration with Data Content: (Encrypted) Payload BIER. Signature: by Bob
Fig. 1: NDN forwarding pipeline. Upstream points toward data producers and downstream points toward data consumers. An Interest may be satisfied by cached Data, aggregated in the PIT, or forwarded by FIB lookup.
and routing security. Section IV describes our prototype implementation and evaluation results. Section V discusses related work and how SRAN recursively applies the same map-and-encap design in inter-domain routing, and Section VI concludes the paper. II. BACKGROUND A. Named Data Networking Named Data Networking (NDN) [1], [10] shifts network communication from host-to-host delivery to data retrieval, where applications fetch named and secured Data. Named Secured Data: NDN applications assign each data unit a semantically meaningful name (e.g.,“/group-chat.com /bob/seq=123”). These names serve as the key for application logic, transport protocols, and network-layer routing. Crucially, every Data packet is cryptographically signed by its producer, binding the name to the content and enabling data-centric security based on semantic naming [11]–[13]. Stateful Forwarding: NDN communication revolves around two packet types: Interests and Data. As illustrated in Fig. 1, a router processes an incoming Interest through a sequential lookup: it is first satisfied by the Content Store (CS) if cached, aggregated in the Pending Interest Table (PIT) if a matching request is already outstanding, or otherwise forwarded via the Forwarding Information Base (FIB) using a name-based strategy. This stateful pipeline ensures that returning Data follows the reverse path of the Interest, enabling request aggregation without source or destination addresses. Link Adaptation Layer (the L2.5): The NDNLPv2 protocol [14] provides a shim layer between the NDN network and link layers, encapsulating Interest or Data packets with extensible feature headers that carry auxiliary information. The feature headers are used by the forwarder in hop-by-hop tasks, ranging from fragmentation to network-assisted congestion control [15], [16]. SRAN extends this encapsulation framework to support its Map-and-Encap method. Dataset Synchronization: Multiparty NDN applications [2], [3], [17] typically use Sync protocols [4], [6]–[8] to maintain
B. Bit Index Explicit Replication (BIER) Bit Index Explicit Replication (BIER) [18] provides stateless multicast by carrying the receiver set in the packet. Each BIER-capable egress router is assigned a Bit Forwarding Router ID (BFR-ID), which corresponds to one bit position in a domain-wide BitString. Routers also compute a Bit Index Forwarding Table (BIFT), whose entries map BFR-IDs to the outgoing interface(s) that lead toward the corresponding egress routers. At the network ingress, a multicast packet is encoded with a BitString that marks the BFR-IDs of all target egress routers. For example, a packet destined for BFR-IDs {1, 3, 5} sets the first, third, and fifth bits of the BitString. Transit routers examine the set bits, group them by BIFT outgoing interface, and replicate one packet copy per interface. Each copy carries only the subset of bits reachable through that interface, ensuring that each egress router receives at most one copy under consistent unicast routing. BIER therefore enables stateless multicast, because the forwarding state it requires, i.e., the BIFT, is fundamentally topology-bound. III. SRAN D ESIGN This section presents SRAN design in an NDN network. We first give a system overview, then follow the packet path through the forwarding plane, describe BIER-based multicast support, explain the control plane that populates forwarding state, and close with the routing-security design. As discussed in Section V, the same system structure can be applied recursively at the AS level. A. System Overview SRAN assumes that all routers in the network have already securely obtained router reachability through an NDN routing protocol such as NLSR [19]. Therefore, the design centers on the Prefix Egress Table (PET) that maps application prefixes to egress routers in the forwarding plane, and a control plane database, the Prefix State Database (PSD), that keeps PET state synchronized across edge routers. As illustrated in Fig. 2, the system consists of three types of primary entities. Apps: Applications are the ultimate sources and sinks of Interest packets. They securely announce their name prefixes to local edge routers (Section III-E). Edge Routers: Edge routers form the boundary of the SRAN core and maintain the mapping between the application namespace and the router-level topology. They perform three functions: (i) Ingress Encapsulation: upon receiving an Interest
Ingress Router
Algorithm 1 Unicast Interest Forwarding (PIT and CS lookups are omitted) Application Entities
Core Routers
Other Networks Edge Routers
Egress Router
Fig. 2: The SRAN system model illustrating the interaction among applications, edge routers, and the prefix-unaware core.
from a local application, the ingress router queries the PET (Section III-B) to map the name to one or more egress routers, then encapsulates the Interest with either the target egress router’s name for unicast or a BIER bitstring for multicast (Section III-C); (ii) Egress Decapsulation: upon receiving an encapsulated packet destined to itself, the edge router removes the encapsulation header and delivers the original Interest to the local producer according to its local PET; and (iii) Control– Plane Management: edge routers accept authenticated prefix announcements, maintain PSD entries (Section III-D), and populate their local PETs from the synchronized PSD. Core Routers: Upon receiving an encapsulated Interest, a core router forwards the packet using either the egress-router identifier or the BIER bitstring carried in the encapsulation header. B. Forwarding Plane: Prefix Egress Table The Prefix Egress Table (PET) is SRAN’s prefix-to-router mapping. Each PET entry maps an application name prefix to a set of egress routers E, a set of local faces F , and a delivery type (unicast or multicast). Populated from the PSD, the PET is used directly on the forwarding path: ingress edge routers consult it before encapsulation, and egress edge routers consult it after decapsulation. Fig. 3a shows this relationship on router R1, where PSD state is materialized into PET entries used by the forwarding plane. Alg. 1 summarizes the router forwarding process. We walk through the edge-to-edge lifecycle of an Interest using the unicast scenario in Fig. 3b as a running example. Ingress Two-Phase Lookup: To bridge the application namespace and physical topology, the ingress router queries the PET to map the Interest name to a candidate set of Egress Routers (ERs), then selects the ER with the lowest routing-protocol cost. Then it queries the chosen ER name against its FIB, which maintains only the router reachability state, to find the outgoing face. For example, when ingress router R1 receives an Interest for “/P4/img” from an application, it maps P 4 to
Require: Incoming Packet P (Vanilla Interest Iv or SRAN Interest Ia ) Ensure: P forwarded, locally delivered, or dropped 1: if P is Iv then 2: (E, F) ← PET.Lookup(Iv .name) 3: if E ∪ F = ∅ then 4: drop P return 5: end if 6: if E = ∅ then 7: deliver Iv to F return 8: end if 9: R ← BestRoute(E) 10: Ia ← Encapsulate(Iv , R) 11: f ← FIB.Lookup(R) 12: forward Ia to f 13: else if P is Ia then 14: (Iv , Regress ) ← Decapsulate(P ) 15: if Regress = Rme then 16: ( , F) ← PET.Lookup(Iv .name) 17: deliver Iv to F 18: else 19: f ← FIB.Lookup(Regress ) 20: forward P to f 21: end if 22: end if
R2 and R4 as ERs. Assume that R4 has a lower routing cost; R1 therefore chooses R4 as the ER. The ingress router R1 then encapsulates the vanilla Interest from application within an NDNLPv2 header containing the target ER’s name. This tunnels the packet across the domain, shifting the complexity of the application name prefix lookup to the network edge. In our running example, R1 adds an NDNLPv2 header with R4 as the Interest ER. Transit Forwarding in the Core: Transit routers process encapsulated Interests strictly by their NDNLPv2 headers. Because core FIBs contain no application prefixes and store only router reachability state, these routers perform exact-match lookups on the ER name. Consequently, the forwarding state in core routers scales with the physical topology rather than the expanding prefix namespace. When the Interest reaches core router R6, R6 matches the R4 name in the NDNLPv2 header against its local FIB and forwards the Interest toward R4. Egress Delivery: The egress router detects that an Interest has reached its destination when the ER matches its own name. It strips the encapsulation header and performs a final local PET lookup to map the vanilla Interest name to a specific local face, delivering the Interest packet to the producer application. Upon receiving the Interest, R4 determines that the ER name in the NDNLPv2 header matches its own name, strips the encapsulation header, and directly delivers “/P4/img” to the attached producer. Because Interest forwarding opens PIT
BFR-id: 4
Control Plane
Forwarding Plane
Prefix State Database
Prefix Egress Table
R1
R2
P1 P2 P3
TTL U Fid={...} TTL M Fid={...} TTL M Fid={...} .......
P2 P3 P4
TTL M Fid={} TTL M Fid={} TTL U Fid={} .......
R4
P1
ER={R1}
Fid={...} U
P2
ER={R1, R2}
Fid={...} M
P3
ER={R1, R2, R3} Fid={...} M
P4
ER={R2, R4}
.......
U
.......
(a) Control-plane and forwarding-plane components of router R1.
R6
L2.5 ER: R4 Interest: /P4/img Encap BFR-id: 1
Fid={}
BFR-id: 6
Unicast
BIFT (BFR-id=5) BFR-id BFR-NBR F-BM 1 R1 000001 2 R2 000010 Assets 3 4 6
R3
R3
000100
R6 101000 R6 101000 BFR-id: 5
R1 R5 L2.5 Edge Encap BS: 000110 Interest: /P2/svs Core
BFR-id: 3
Multicast BFR-id: 2
R2 Edge
(b) A network forwards unicast and multicast Interests.
Fig. 3: Map-and-encap in SRAN. (a) The control-plane Prefix State Database (PSD) aggregates prefix reachability updates from routers to maintain the router-to-prefix mappings, which populate the forwarding-plane Prefix Egress Table (PET) that maintains the prefix-to-router mappings. (b) Ingress edge routers consult the PET to map an application prefix to topological locators: unicast Interest packets are encapsulated to a specific Egress Router (ER), while multicast Interest packets are encapsulated with a BitString (BS) and forwarded using BIFT entries that store per-face Forwarding Bit Masks (F-BMs).
entries along the path, the returning Data can be forwarded in the reverse direction without additional support. C. Supporting Stateless Interest Multicast SRAN supports stateless Interest multicast by adopting BIER forwarding1 . BIER requires the ingress router to know which BFR-IDs should receive a packet; in SRAN, the PET natively provides this mapping for name prefixes. Because a PET entry maps a multicast prefix to its participating egress routers, an ingress router can map an Interest name directly into the egress router set. In SRAN, each router is configured with a unique BFR-ID, representing a specific bit position in a domain-wide BitString (BS). Multicast prefixes are explicitly labeled in the PET, and an ingress router identifies multicast Interests and retrieves the destination egress routers directly through PET query. The ingress router then encodes those egress routers into a BS and replicates the packet to the appropriate outgoing faces learned from the BIFT lookup. Each BIFT entry stores a Forwarding Bit Mask (F-BM), the set of BFR-IDs reachable through a given outgoing face. As illustrated by the multicast scenario in Fig. 3b, when an application attached to R1 expresses a multicast Interest “/P3/svs”, through PET lookup, R1 identifies “/P3” as a multicast prefix and R2 and R3 as destination routers. It encodes their BFR-IDs in a single BS 000110 within the NDNLPv2 header and forwards the packet based on local BIFT. Core routers also process these Interests based on the topology-bound BIFT. Upon receiving an Interest, a router first checks whether its own BFR-ID is set in the incoming BS, indicating that the Interest has reached one of its destinations. If the bit is set, the router performs a PET lookup to deliver the Interest to local faces F, then clears its own bit from the BS to prevent local loopback. Afterwards, the router maps the remaining bits in BS to outgoing interfaces using BIFT and replicates the packet once per interface carrying at 1 SRAN does not remove NDN’s normal per-Interest PIT state, which is essential for Data forwarding.
least one destination. This approach ensures that the multicast forwarding state in the transit core remains invariant to the scale of active multicast groups. In Fig. 3b, the intermediate router R5 statelessly duplicates and forwards the Interest to both R2 and R3 based entirely on the 000110 BitString. The same forwarding state can be reused for any multicast prefix, such as “/P2”, because BIFT state is tied to router reachability rather than the application names. A complete forwarding process that summarizes both unicast and multicast scenarios can be found in Alg. 2. D. Control Plane: Prefix State Database The Prefix State Database (PSD) is the control plane source of PET as a replicated router-to-prefix mapping, updated by each participant router. Each subentry describes a prefix reachability object, including its Time-To-Live (TTL), delivery type (unicast or multicast), and local face identifiers (FIDs) through which local applications are attached. Applications announce their prefixes to their local edge router. After validating the announcement according to the security policy in Section III-E, the edge router updates its local PSD and materializes the corresponding PET entry. Remote edge routers learn the same prefix reachability state through PSD synchronization and update their own PETs accordingly. PSD Synchronization: To maintain a consistent PET view, SRAN synchronizes PSD instances among edge routers. We view PSD as an ordinary multi-party NDN application that uses the NDN Sync group “/<network>/PSD/Sync” to inform the group of the latest named secured data publication. Each edge router publishes local PSD updates as Data objects following the naming convention “/<network>/PSD/<router> /<seq>”. Here, “<network>” is the configured network name, while “<router>” and “<seq>” identify the producing router and its PSD update sequence number. As a result, each PSD Sync Interest carrying the Sync state vector is conservatively BIER-encapsulated toward all routers, avoiding the need to separately maintain an edge-router membership set. Routers then forward these BIER packets statelessly using their BIFT.
Authenticate Applications Trust Anchor sign
Bootstrap Routers
Network Admin
Key
Prefix Announcement
PSD Update
Name: /foobar.org/video/PA/v1
Name: /network/r1/PSD/seq=1
Lifetime: 3600s, Model: Unicast
Application foobar.org
Security Policies: "Prefix owner signs prefix announcements" "Routers sign PSD Sync state vectors" "PSD producer signs its own PSD data"
KeyLocator: /foobar.org/KEY/id123
Signature
Policy
Router
/network/r1
PSD Update KeyLocator: /network/r1/KEY/id223
Signature
Policy
Router
/network/r2
Fig. 4: Applications register prefixes with an edge router through Prefix Announcements, while edge routers secure routing state through signed PSD updates. Both verification chains terminate at the network trust anchor, and signing relationships are enforced by security policies. PSD Sync state vectors follow a similar naming convention with PSD updates and are therefore omitted for clarity.
Edge routers react to the latest state vector by expressing Interest based on the naming convention to fetch the missing PSD update, while the router reachability already pre-establishes the forwarding path for this Interest. The evaluation in Section IV further shows that this synchronization mechanism significantly reduces control plane communication overhead by avoiding network broadcast on new prefix announcement and migration. E. Routing System Security We design SRAN following the basic NDN principle that everything is named secured data. In the SRAN control plane, there are three types of data: the prefix announcement sent from applications to the edge routers, the PSD update among the edge routers, and the PSD Sync state vectors that announce new mapping updates. Each of them must be signed and the signing should be authorized through schematized security policies [11], [12]. SRAN does not introduce a separate routing-security protocol; instead, it merely utilizes the primitive NDN security functions and tools natively provided by the architectural substrate. The objective of the PSD security design is to prevent prefix hijacking by external attackers that inject false prefix state into the PSD and by applications that announce prefixes they do not control. The threat model assumes a valid local trust anchor owned by the network operator and does not cover active attacks against routing protocols or denial-of-service flooding by otherwise authorized entities. As the controller of the routing system, an SRAN network administrator defines a trust domain by self-signing a certificate for the network name as the system trust anchor. The administrator bootstraps each router with the trust anchor, a router certificate signed by the anchor, and the following security policies: (1) the owners of the DNS name N are authorized to announce prefixes under “/N”; for example, own-
ers of “foobar.org” can announce “/foobar.org/video”; (2) only routers are authorized to produce PSD Sync state vectors; and (3) PSD updates can only be legitimately signed by the same router. Thus, non-router entities cannot send legitimate PSD Sync Interest, and router “/network/r1” cannot produce Data under “/network/r2/PSD”. Fig. 4 illustrates a scenario in which the administrator of network “/network” sets up a network trust anchor by self-signing the network certificate and bootstraps two routers, “/network/r1” and “/network/r2”. To announce a prefix in the network, an endpoint application, such as the “/foobar.org” server, must be authenticated by the network administrator and obtain a certificate from the trust anchor.
Applications announce their prefixes to edge routers using PrefixAnnouncement Data named according to the convention “/<prefix>/PA/<version>”. The content includes the prefix lifetime (i.e., the TTL in PSD) and the delivery model. As illustrated in Fig. 4, the owner of the DNS name “foobar.org” has been authenticated and certified by the network administrator and wants to announce a unicast prefix “/foobar.org /video” to the network. It produces announcement Data with the corresponding content and signs it with the anchor-signed “foobar.org” key. Upon receiving the announcement, router “/network/r1” validates the signature against the public key of the trust anchor, then checks that the announcement name is authorized by its Data key locator. This verification ensures that edge routers accept prefix announcements only from authorized producers. Afterward, the router updates its local PSD and produces signed PSD Data with its bootstrapped certificate. The strict PSD update signing policy ensures that even if the key “/network/r1/KEY/id223” is compromised, the attacker cannot spread misinformation on behalf of other routers.
Prefix Migration Src
Prefix Migration Dst
Component
Details
OS CPU CPU topology CPU frequency Memory Storage GPU Kernel/toolchain
Ubuntu Linux 5.15.0-171-generic (x86 64) AMD EPYC 7702P 64-Core Processor 64 cores / 128 threads, 1 socket, 2 threads per core 1500–2183 MHz 251 GB RAM 776 GB NVMe SSD root volume, 22 TB home volume ASPEED Graphics Family (AST2500) Linux 5.15.0-171-generic, GCC 11.4.0
TABLE I: Evaluation server used for Mini-NDN emulation. Fig. 5: Sprint PoP topology with prefix migration between the farthest edge routers.
IV. I MPLEMENTATION AND E VALUATION This section evaluates the SRAN design described in Section III. We first describe an NDNd prototype that adds PSD/PET state management, NDNLPv2 encapsulation, BIER forwarding, and security implementation. We then measure whether SRAN preserves prefix-update convergence, reduces dissemination overhead, and keeps core forwarding state tied to topology rather than application-prefix scale. Finally, we qualitatively analyze whether the designed routing security mechanisms achieve its objectives. A. Implementation We implemented SRAN in NDNd, a Go-based NDN forwarder, by extending the forwarder and routing daemon while remaining backward-compatible with applications. SRAN uses NDNLPv2 as the encapsulation point: one extension field carries the unicast egress-router identifier, and another carries the BIER bitstring for multicast. Egress routers are represented by 16-bit identifiers derived from router names. Security is enforced using Light VerSec (LVS) trust-schema policies [11], [12]: applications announce prefixes via “/localhop/route” with signed PrefixAnnouncement Data, which are validated against the trust schema before the corresponding prefix state is accepted into the PSD. The routing daemon implements a PSD module that publishes prefix updates as signed Data objects according to the LVS policies. Updates are disseminated via BIER-encapsulated Sync Interests; edge routers apply received updates to their local PSD and populate the PET. We also implemented management commands that allow operators to inspect and update PSD entries. BIER forwarding is implemented with a BIFT module in the forwarder, where BIFT entries store the topology-derived next-hop bit masks used by BIER forwarding. BFR-IDs are assigned via management commands, and the BIFT is automatically rebuilt after FIB updates to remain consistent with the unicast best paths. B. Performance Evaluation SRAN changes where application-prefix state is kept: edge routers keep the prefix mappings, while the core forwards on topology-derived state. The evaluation therefore asks two
Operation Announce (SRAN) Announce (Baseline) Migrate (SRAN) Migrate (Baseline)
Min
Median
Q3 (P75)
Max
98ms 95ms 114ms 109ms
99ms 97ms 125ms 112ms
107ms 97ms 136ms 113ms
110ms 118ms 401ms 365ms
TABLE II: Prefix announcement and migration latency on the Sprint PoP topology. questions. First, does the PSD synchronize prefix changes quickly enough, and with less control traffic than the existing routing baseline? Second, after prefixes are moved out of the core FIB, does core forwarding state remain bounded by topology rather than by the number of application prefixes? We use two topologies to separate these effects. Sprint PoP is an all-edge topology: every router is applicationfacing, so SRAN cannot benefit from a prefix-unaware core. This is the least favorable case for state reduction, but it still tests whether BIER-based PSD dissemination reduces update overhead and whether hop-by-hop FIB lookup becomes smaller. Rocketfuel AS 1755 [20] has 111 core routers and 61 edge routers, and represents the intended SRAN deployment model. Both topologies use NDN Distance Vector Routing [21] to establish router reachability. The baseline is the existing NDNd forwarder and routing daemon, configured with the same topology and link settings as SRAN. The key difference is that the baseline installs application prefixes directly into the FIB at every router, whereas SRAN stores application-prefix mappings in the PET at edge routers and keeps the hop-by-hop FIB topology-bound. The measurements use two execution environments, chosen according to topology size. Topologies smaller than Rocketfuel AS 1755 are emulated with Mini-NDN [22] on the server summarized in Tab. I. The AS 1755 prefix-change experiments are simulated with ns-3 [23]. Forwarding state snapshots are read from the router tables produced by the corresponding runs. Finally, to show that the state trend is not specific to AS 1755, we analytically repeat the state calculation on two larger Rocketfuel topologies. Across the evaluation tables, Q3 (P75) denotes the 75th percentile. For prefix-change experiments, convergence time is the time until the changed prefix is reachable throughout the domain. The packet-overhead unit “p” denotes one packet
Operation
Min
Median
Q3 (P75)
Max
Announce (SRAN) Announce (Baseline) Migrate (SRAN) Migrate (Baseline)
2.43p 4.00p 4.88p 8.00p
2.43p 4.00p 7.29p 8.02p
2.43p 4.00p 7.29p 10.81p
4.02p 4.53p 7.46p 13.67p
FIB Entries
PET Entries
BIFT Entries
Min
Max
Min
Max
Min
Max
52 1260
52 1273
1260 1273 N/A
52
52
Router SRAN Baseline
N/A
TABLE III: Normalized per-link packet overhead for prefix announcement and migration on the Sprint PoP topology.
TABLE V: Forwarding state comparison between SRAN and Baseline on the Sprint PoP topology.
Operation
Min
Median
Q3 (P75)
Max
Router
Announce (SRAN) Announce (Baseline) Migrate (SRAN) Migrate (Baseline)
2.44p 4.00p 4.88p 8.00p
2.45p 8.65p 4.90p 18.86p
2.45p 13.31p 4.90p 25.07p
2.47p 27.27p 4.93p 40.62p
TABLE IV: Normalized per-link packet overhead for prefix announcement and migration on the AS 1755 topology.
traversal over one topology link, averaged over all links during the convergence window. Prefix-Change Convergence and Overhead (Sprint PoP): Sprint PoP represents the all-edge deployment case: every router is application-facing, and no prefix-unaware core exists from which SRAN can remove application prefixes. This experiment therefore asks whether SRAN’s PSD dissemination can reduce control traffic even before SRAN gets its main core-state benefit. As shown in Fig. 5, the emulated topology contains 52 routers and 84 links, and each link is configured with 1 Gbps bandwidth, 10 ms latency, and 0.1% packet loss. For announcement, an application prefix is registered at a randomly selected router. For migration, the prefix is withdrawn from its original router and immediately re-announced at the farthest edge router, seven hops away as illustrated in Fig. 5. We repeat both announcement and migration 50 times for SRAN and for the baseline. SRAN trades a small amount of convergence latency for lower dissemination overhead. Tab. II shows that SRAN keeps convergence latency close to the baseline. For announcement, the median increases from 97 ms to 99 ms. For migration, which includes both withdrawal and re-announcement across the farthest edge pair, the median increases from 112 ms to 125 ms. At the 75th percentile, the increases are 10 ms for announcement and 23 ms for migration. The long tail appears in both designs, suggesting that lossy links and Sync retransmission or timer behavior dominate the rare slow cases. The important point is that SRAN’s lower-overhead dissemination does not require a substantially slower convergence process. Tab. III shows where SRAN gains even in this unfavorable all-edge topology. For announcement, SRAN reduces median packet overhead from 4.00p to 2.43p, a 39.3% reduction. For migration, SRAN reduces the median from 8.02p to 7.29p and the Q3 from 10.81p to 7.29p, reductions of 9.1% and 32.6%, respectively. The baseline disseminates prefix changes
SRAN Core SRAN Edge Baseline
FIB Entries
PET Entries
BIFT Entries
Min
Max
Min
Max
Min
Max
172 172 1380
172 172 1388
8 22 1380 1388 N/A
172 172
172 172 N/A
TABLE VI: Forwarding state comparison between SRAN and baseline on the full 172-router Rocketfuel AS 1755 topology with 1000 unicast and 200 multicast application prefixes.
by broadcasting Sync Interests, which creates duplicate packet traversals on many links. SRAN instead BIER-forwards the PSD Sync Interest; the packet-carried BitString forms an implicit multicast tree and removes many of those duplicates. Forwarding State Snapshot (Sprint PoP): The second Sprint PoP experiment isolates lookup-path benefit from coreremoval benefit. Even when every router is an edge, SRAN should still shrink the table consulted at each hop. We randomly announce 1000 unicast prefixes and 200 multicast prefixes; each multicast prefix is attached to three egress routers. In the baseline, all 1200 application prefixes are installed into each router’s FIB, together with 60–73 control prefixes. In SRAN, those application prefixes move to the PET. The FIB therefore contains only the 52 router-level entries, and the BIFT contains one entry per BFR-ID. This shift matters because the FIB is consulted at every hop, while the PET is consulted only at ingress and egress. Even in the all-edge topology, SRAN reduces the hop-by-hop lookup table from 1260–1273 entries to 52 entries, a 95.9% reduction. The PET still contains 1260–1273 entries because every router is an edge router in this topology. The non-application entries come from distance-vector control prefixes and PSD prefixes. Their small variation reflects router degree, because higherdegree routers have more local control prefixes, rather than the application workload. Prefix-Change Convergence and Overhead (AS 1755): We repeat the prefix announcement and migration experiments on AS 1755 using ns-3 simulation. This topology has 111 core routers and 61 edge routers, so SRAN can avoid carrying application-prefix state through most of the network. We also configure each link with 1 Gbps bandwidth, 10 ms latency and the same 0.1% packet loss. Announcement and migration both converge in 133 ms in this simulation, so the main difference is packet overhead. Tab. IV shows that SRAN’s
States per Router
1,900
Baseline SRAN 950
0 100
500
Application Prefixes
1K 100
500
1K
Application Prefixes
Fig. 6: Forwarding state as application prefixes increase in AS 1755. Bars compare the baseline against total SRAN forwarding state, counted as the sum of FIB, PET, and BIFT entries. The left plot shows core routers; the right plot shows edge routers.
BIER dissemination becomes more valuable as the topology grows. For announcement, SRAN reduces median overhead from 8.65p to 2.45p and Q3 overhead from 13.31p to 2.45p. For migration, SRAN reduces median overhead from 18.86p to 4.90p and Q3 overhead from 25.07p to 4.90p. The reason is the same as in Sprint PoP, but the effect is larger: the baseline broadcast creates more duplicate traversals in a larger network, while BIER keeps dissemination close to a multicast tree. Forwarding State Snapshot (AS 1755): AS 1755 is where SRAN’s core/edge split should pay off: core routers avoid application-prefix mappings, while edge routers absorb them. Tab. VI shows the state placement under the same workload of 1000 unicast and 200 multicast prefixes. The baseline stores 1380–1388 FIB entries at every router: 1200 application prefixes plus 180–188 router/control prefixes. SRAN keeps the hop-by-hop FIB fixed at 172 router entries and keeps the BIFT fixed at 172 entries. The only table whose size depends on application prefixes is the PET, and its size depends on whether the router is an edge. This is the core SRAN tradeoff. Core routers keep only 8– 22 PET entries, all for local control state, because they do not fetch or serve application-prefix mappings. As a result, the table consulted by core routers at each hop drops from 1380– 1388 mixed FIB entries to 172 router-level FIB entries, an 87.6% reduction at the maximum. For the unicast lookup path, even if we conservatively add FIB and PET entries together, SRAN core routers store only 180–194 entries. Edge routers pay the mapping cost on that path: their PET contains the application-prefix mappings, so their combined FIB and PET state is 1552–1560 entries, exactly 172 entries more than the baseline because they also keep the topology FIB. The Effect of Application Dynamics: The previous snapshot shows one workload size. We next hold the AS 1755 topology fixed and increase the number of application prefixes. If SRAN works as intended, the baseline core FIB should grow with every new application prefix, while the SRAN core state should remain flat. We sweep the number of unicast prefixes U from 100 to 1000 in steps of 100 and set the multicast-prefix count to U/5.
Thus, the final sweep point matches the workload in Tab. VI. For the baseline, each router stores U + U/5 applicationprefix FIB entries plus router/control-prefix state. We use 181.92 entries per router for the router/control component, corresponding to the average of the 180–188 range in Tab. VI. For SRAN, we conservatively count the total local forwarding state as the sum of FIB, PET, and BIFT entries, although BIFT and FIB are never used at the same time in Interest forwarding. Fig. 6 shows the expected split. The baseline grows linearly from 301.92 entries per router at U = 100 to 1381.92 entries at U = 1000. In contrast, each SRAN core router remains fixed at 356.26 entries: 172 FIB entries, 12.26 PET entries on average, and 172 BIFT entries. This fixed cost is 18.0% higher than baseline at U = 100, but it does not grow with the application workload. At U = 1000, SRAN reduces total core forwarding state by 74.2%. At the edge, SRAN intentionally keeps application-prefix mappings in the PET, so edge state grows with the same slope as the baseline. The average SRAN edge state increases from 645.92 entries at U = 100 to 1725.92 entries at U = 1000. The difference from baseline is a fixed 344-entry offset from the router-level FIB and BIFT tables maintained alongside the edge PET. Thus, SRAN does not remove prefix state from the network; it moves that state to the edge and keeps the extra edge cost topology-bounded. The BIFT remains fixed at 172 entries throughout the sweep, showing that multicast forwarding state is bounded by router reachability rather than by the number of multicast prefixes. The Effect of Physical Topologies: Finally, we ask whether the same trend holds as the physical topology changes. The previous sweep varies application scale on one topology; this sweep asks how topology size shifts the point where SRAN’s fixed topology cost is outweighed by prefix growth. Because the forwarding tables are determined by topology and advertised prefixes, we conduct an analytical state-scaling study on three Rocketfuel topologies: AS 1755, AS 3356, and AS 2914. AS 3356 and AS 2914 contain 624 and 960 routers, respectively. We vary the application workload from 1000 to 10,000 prefixes announced at the edge and measure two quantities: the percentage of forwarding state that SRAN removes from core routers, and the additional forwarding state that SRAN introduces at edge routers. If SRAN core state is topology-bound, then as the prefix workload grows, the core-state reduction should approach 100%. Because the extra edge cost is fixed by the topology, its relative overhead should approach 0%. Fig. 7 reports the analytical results, using the same criterion of counting the combined FIB, PET, and BIFT entries as forwarding state. Across all three topologies, the corestate reduction increases as the application workload grows. The baseline core FIB absorbs every new application prefix, whereas SRAN core FIBs, PETs, and BIFTs remain topologybound. As the number of prefixes increases from 1000 to 10,000, the total core-state reduction increases from 69.9% to 96.5% on AS 1755, from 22.0% to 88.0% on AS 3356, and from 1.7% to 82.4% on AS 2914. All three curves
100
AS 1755 AS 3356 AS 2914
Percentage
80 60 40
AS 1755 AS 3356 AS 2914
20 0
1K
5K
Application Prefixes
10K 1K
Compromised Router Key: If “/network/r1”’s key is compromised, the attacker can publish state only under “/network /r1/PSD”. It cannot impersonate “/network/r2” or withdraw prefixes on behalf of other routers. Other edge routers, therefore, reject cross-router misinformation even when it is disseminated through normal Sync and BIER forwarding. V. D ISCUSSION AND R ELATED W ORK
5K
10K
Application Prefixes
Fig. 7: Analytical state scaling across Rocketfuel topologies. State reduction (left) measures the percentage of baseline core entries removed by SRAN. State overhead (right) measures the additional SRAN edge state relative to the baseline.
trend toward 100%, confirming that SRAN core forwarding state is bounded by the physical topology rather than by the application namespace. Larger topologies start with lower percentage reduction because they impose larger topologyderived SRAN state; they therefore require a larger prefix workload before the relative reduction approaches 100%. At the edge, SRAN adds a fixed topology-derived overhead of 344, 1248, and 1920 entries per router on AS 1755, AS 3356, and AS 2914, respectively. Because this overhead is fixed by the router set, its relative cost decreases as the application workload grows and trends toward 0%. C. Security Analysis We qualitatively analyze the routing security design from Section III-E. The security question is a state-admission question: can an attacker make an edge router install false prefix state? There are two admission points for such state: application PrefixAnnouncements and router-produced PSD updates. We use the same trust model as the design: routers are certified under the network trust anchor, and network administrators issue certificates to authorized application prefix owners. Unauthorized Prefix Announcement: An attacker may try to register a victim prefix, such as “/foobar.org/video”, without owning “/foobar.org”. Before installing PSD or PET state, the edge router validates the PrefixAnnouncement Data with the bootstrapped LVS trust schema. The schema checks both the certificate chain to the network anchor and the authorization relationship between the announced prefix and the signing key. An unsigned announcement, an announcement signed by a key from another namespace, or an announcement that over-claims beyond the signer’s delegated namespace is rejected before it changes forwarding state. Forged PSD Update: An attacker may inject fabricated or replayed PSD Data, for example under “/network/r2/PSD”. Receiving edge routers accept the update only if it is signed by the router authorized for that PSD name and carries a newer sequence number than the current state. Thus, non-router keys, cross-router signatures, and stale sequence numbers are rejected before they update the PET; prefix lifetimes further limit the effect of replayed announcements.
A. Extending SRAN in Inter-Domain Routing As a Map-and-Encap realization, the SRAN design is recursively applicable to different NDN routing scopes: inside one domain, PET/PSD map prefixes to egress routers; across domains, the analogous mapping target is an egress AS. Thus, the main technical difference for SRAN is not new forwarding primitives, but rather the prefix-to-AS mapping distribution across trust domains. We anticipate that the initial interconnection of NDN networks will consist of a small number of overlay networks that form a mutually authenticated federation, peer with one another, and run an inter-domain routing protocol only to establish AS-level reachability. An inter-domain SRAN deployment can then be viewed as two nested Map-and-Encap stages. At the outer stage, an AS-level PET maps an application prefix to one or more egress ASes, each identified by name. An AS-level PSD synchronizes this mapping state across the federation and is secured by a trust schema that validates updates across mutually authenticated trust domains [24]. The ingress AS edge encapsulates the Interest with the selected egress AS identifier, allowing transit domains to forward on AS-level reachability rather than application names. At the inner stage, the egress AS applies the intra-domain SRAN design from Section III: its local PET maps the same prefix to an egress router, and its core forwards based on the ER header. As a result, the core transit ASes only need to maintain AS reachability and ensure that their inter-AS forwarding states remain topology-bound. Not every edge AS needs to maintain the full prefix-to-AS mapping; edge ASes can instead map a default prefix to their providers. An AS-level PET can also map a multicast name prefix to the set of authorized receiver ASes. Border routers then BIER-forward Interests toward those ASes using AS-level reachability. After the Interest enters a receiver AS, the local PET maps the same name to receiver egress routers, and the local routers forward it using local BS encapsulation. This two-level BIER differs from existing inter-domain BIER mechanisms in IP [25]–[27], which tend to reintroduce the per-group state at the transit domain boundaries or require additional coordination between domains. B. Related Work NDN Routing Scalability: SNAMP [28] is the closest prior NDN effort on secure namespace mapping for scalable forwarding: it recognizes that forwarding directly on a large application namespace stresses router state and proposes a secure mapping layer based on NDNS [29], a DNS-like name service for NDN. It does not provide mechanisms to securely
synchronize the mapping and directly carries the topological locator in the Interest packets, while SRAN uses the native NDN Sync and security functions to securely synchronize the mapping and encapsulates Interest packets at L2.5. BIER Deployments in IP: In IP deployments, a BIER ingress router must already know the prefix-to-router mapping. Edge routers can learn host membership through IGMP/MLD [30], [31] and multicast routing protocols such as PIM-SM [32], while SRAN ingress directly learns the membership through the built-in PET that serves both unicast and multicast prefixes. Interest Multicast in NDN: The existing NDN forwarders do not provide forwarding support for Interest multicast. In both NFD2 and NDNd3 , “multicast” denotes a forwarding strategy that replicates an Interest to all FIB next hops selected for the name prefix, approximating the multicast semantic with broadcast. The network does not expose a multicast abstraction whose state can scale independently of group dynamics. VI. C ONCLUSION The evolution of internetworking architectures features a fundamental structural tension regarding routing scalability: the network core faces state explosion whenever its forwarding tables are driven by external entities. In IP networks, this pressure stems from end-user prefixes, which historically motivated the invention of the Map-and-Encap paradigm to isolate transit routers from edge volatility. NDN significantly magnified this challenge by elevating application name prefixes to first-class routing primitives, tying core forwarding states directly to an unbounded, dynamic application namespace. SRAN reconciles this dichotomy. By extending Map-andEncap to encapsulate prefix-to-multiple-egress mappings into a single BitString, SRAN provides a unified solution for scalable unicast and multicast routing through the same structural abstraction. This separation of name prefixes from topological connectivity proves that a data-centric network can scale globally. In addition, SRAN shows the profound benefits of building natively on the NDN substrate. By leveraging NDN’s intrinsic capabilities – data-centricity, built-in cryptographic protection, dataset synchronization, and modular functionality – SRAN inherits built-in routing security, secure mapping state dissemination out of the box, and NDNLPv2 as a readily available mapping information carrier for Interest packets which carry data names. Ultimately, SRAN establishes a balanced architectural blueprint where rich naming and datacentric security thrive flexibly at the network edge, while the transit core remains structurally simple, fast, and scales with topology. As next-generation communication demands grow, the structural principles validated by SRAN offer a viable, secure, and deployable path toward a global-scale data-centric Internet. 2 https://github.com/named-data/NFD 3 https://github.com/named-data/ndnd
A PPENDIX A. Interest Forwarding Algorithm Algorithm 2 Interest Forwarding (PIT and CS lookups are omitted) Require: Incoming Packet P (as Iv or Ia ) Ensure: P forwarded, locally delivered, or dropped 1: if P is Iv then 2: (E, F , type) ← PET.Lookup(Iv .name) 3: if E ∪ F = ∅ then 4: drop P return 5: end if 6: if type = Unicast then 7: R ← BestRoute(E) 8: if R = Rme then 9: deliver Iv to F return 10: end if 11: Ie ← Encapsulate(Iv , R) 12: forward Ie to FIB.Lookup(R) 13: else if type = Multicast then 14: if Rme ∈ E then 15: deliver Iv to F 16: end if 17: B ← ToBitString(E \ {Rme }) 18: for all Face f in BIFT do 19: Bout ← B AND BIFT[f ].F-BM 20: if Bout ̸= 0 then 21: forward Encapsulate(Iv , Bout ) to f 22: end if 23: end for 24: end if 25: else if P is Ia then 26: E ← Extension(P ) 27: if E is Regress then 28: if Regress = Rme then 29: Iv ← Decapsulate(P ) 30: ( , F , ) ← PET.Lookup(Iv .name) 31: deliver Iv to F 32: else 33: f ← FIB.Lookup(Regress ) 34: if f = ∅ then 35: drop P return 36: end if 37: forward P to f 38: end if 39: else if E is Bin then 40: if IsSet(Bin , BFR-IDme ) then 41: Iv ← Decapsulate(P ) 42: ( , F , ) ← PET.Lookup(Iv .name) 43: deliver Iv to F 44: Bin ← Bin \ {BFR-IDme } 45: end if 46: for all Face f in BIFT do 47: Bout ← Bin AND BIFT[f ].F-BM 48: if Bout ̸= 0 then 49: UpdateEncapsulation(P, Bout ) 50: forward P to f 51: end if 52: end for 53: end if 54: end if
▷ Unicast
▷ Multicast
R EFERENCES [1] L. Zhang, A. Afanasyev, J. Burke, V. Jacobson, K. Claffy, P. Crowley, C. Papadopoulos, L. Wang, and B. Zhang, “Named data networking,” ACM SIGCOMM Computer Communication Review, vol. 44, no. 3, pp. 66–73, 2014. [2] P. Gusev and J. Burke, “NDN-RTC: Real-time videoconferencing over Named Data Networking,” Named Data Networking (NDN), Technical Report NDN-0033, 2015.
[3] T. Yu, X. Ma, V. Patil, Y. Kocaogullar, and L. Zhang, “Exploring the design of collaborative applications via the lens of ndn workspace,” in 2024 IEEE International Conference on Metaverse Computing, Networking, and Applications (MetaCom). IEEE, 2024, pp. 89–96. [4] Z. Zhu, A. Afanasyev, J. Burke, V. Jacobson, and L. Zhang, “Let’s chronosync: Decentralized dataset state synchronization in named data networking,” in Proceedings of the 20th IEEE International Conference on Network Protocols (ICNP), 2013, pp. 1–10. [5] J. Chen, M. Arumaithurai, L. Jiao, X. Fu, and K. K. Ramakrishnan, “COPSS: An efficient content oriented publish/subscribe system,” in Proceedings of the 7th ACM/IEEE Symposium on Architectures for Networking and Communications Systems (ANCS), 2011, pp. 99–110. [6] M. Zhang, A. Afanasyev, J. Burke, and L. Zhang, “Psync: Efficient synchronization of multiple named data streams,” in Proceedings of IEEE INFOCOM Workshops, 2016, pp. 1–6. [7] P. Moll, W. Shang, A. Afanasyev, and L. Zhang, “Svs: State vector sync for named data networking,” in Proceedings of the 7th ACM Conference on Information-Centric Networking (ICN), 2020, pp. 122–132. [8] P. Moll, V. Patil, L. Wang, and L. Zhang, “Sok: The evolution of distributed dataset synchronization solutions in ndn,” in Proceedings of the 9th ACM Conference on Information-Centric Networking (ICN), 2022. [9] T. Yu, L. Wang, B. Zhang, and L. Zhang, “From map-and-encap to BIER: Observations on network routing scalability,” 2026. [Online]. Available: https://arxiv.org/abs/2605.07071 [10] A. Afanasyev, T. Refaei, L. Wang, and L. Zhang, “A Brief Introduction to Named Data Networking,” in Proc. of IEEE MILCOM, Oct. 2018. [11] Y. Yu, A. Afanasyev, D. Clark, K. Claffy, V. Jacobson, and L. Zhang, “Schematizing trust in Named Data Networking,” in Proceedings of the 2nd ACM Conference on Information-Centric Networking (ICN), 2015, pp. 177–186. [12] T. Yu, X. Ma, and L. Zhang, “A new API in support of NDN trust schema,” in Proceedings of the 10th ACM Conference on InformationCentric Networking (ICN), 2023, pp. 122–131. [13] Z. Zhang, Y. Yu, A. Afanasyev, and L. Zhang, “Automating access control via named data,” in 2018 IEEE Military Communications Conference (MILCOM). IEEE, 2018, pp. 1–9. [14] J. Shi and B. Zhang, “NDNLPv2: Named Data Networking link adaptation protocol v2,” Named Data Networking (NDN), Technical Report NDN-0006, 2012, https://redmine.named-data.net/projects/nfd/ wiki/NDNLPv2. [15] K. Schneider, C. Yi, B. Zhang, and L. Zhang, “PCON: A practical congestion control scheme for Named Data Networking,” in Proceedings of the 3rd ACM Conference on Information-Centric Networking (ICN), 2016, pp. 21–30. [16] S. Song and L. Zhang, “Effective NDN congestion control based on queue size feedback,” in Proceedings of the 9th ACM Conference on Information-Centric Networking (ICN), 2022, pp. 111–121. [17] A. Hoque, C. Y. Amin, W. Lan, B. Zhang, and L. Zhang, “NLSR: named-data link state routing protocol,” in Proceedings of the 3rd ACM SIGCOMM workshop on Information-centric networking, 2013, pp. 15– 20. [18] I. Wijnands, E. Rosen, A. Dolganow, T. Przygienda, and S. Aldrin, “Multicast Using Bit Index Explicit Replication (BIER),” RFC 8279, 2017. [Online]. Available: https://www.rfc-editor.org/info/rfc8279 [19] A. Afanasyev, A. Hoque, S. O. Amin, L. Zhang, B. Zhang, and L. Zhang, “NLSR: Named-data link state routing protocol,” in Proceedings of the 2nd ACM Conference on Information-Centric Networking. ACM, 2015, pp. 15–24. [20] N. Spring, R. Mahajan, and D. Wetherall, “Measuring isp topologies with rocketfuel,” in Proceedings of ACM SIGCOMM, 2002, pp. 133– 145. [21] V. Patil, S. Theeranantachai, B. Zhang, and L. Zhang, “Poster: Distance vector routing for named data networking,” in Proceedings of the 20th International Conference on emerging Networking EXperiments and Technologies, 2024, pp. 23–24. [22] Named Data Networking Project, “Mini-NDN: A lightweight networking emulation tool for NDN,” https://github.com/named-data/mini-ndn, accessed: 2026-05-22. [23] ns-3 Project, “ns-3: A discrete-event network simulator,” https://www. nsnam.org/, accessed: 2026-05-22. [24] T. Yu, X. Ma, H. Xie, Y. Kocaoğullar, and L. Zhang, “Intertrust: establishing inter-zone trust relationships,” in Proceedings of the 9th
ACM Conference on Information-Centric Networking, 2022, pp. 180– 182. [25] Z. Zhang, E. Rosen, D. Awduche, and G. Shepherd, “Multicast/BIER As A Service,” IETF, Internet-Draft draft-ietf-bier-multicast-as-aservice-03, Jul. 2022, work in Progress. [Online]. Available: https: //datatracker.ietf.org/doc/draft-ietf-bier-multicast-as-a-service/ [26] L. Geng, J. Xie, M. McBride, G. Yan, and X. Geng, “Inter-Domain Multicast Deployment using BIERv6,” IETF, Internet-Draft draft-gengbier-ipv6-inter-domain-02, Oct. 2020, expired. [Online]. Available: https://datatracker.ietf.org/doc/draft-geng-bier-ipv6-inter-domain/ [27] H. Bidgoli, S. Venaas, G. Mishra, Z. Zhang, and M. McBride, “PIM Signaling Through BIER Core,” IETF, Internet-Draft draft-ietf-bierpim-signaling-13, Mar. 2025, work in Progress. [Online]. Available: https://datatracker.ietf.org/doc/draft-ietf-bier-pim-signaling/ [28] A. Afanasyev, C. Yi, L. Wang, B. Zhang, and L. Zhang, “Snamp: Secure namespace mapping to scale ndn forwarding,” in 2015 IEEE Conference on Computer Communications Workshops (INFOCOM WKSHPS). IEEE, 2015, pp. 281–286. [29] A. Afanasyev, X. Jiang, Y. Huang, J. Li, C. Yi, L. Wang, B. Zhang, and L. Zhang, “NDNS: A DNS-like name service for NDN,” in 2017 26th International Conference on Computer Communication and Networks (ICCCN). IEEE, 2017, pp. 1–9. [30] B. Cain, S. Deering, I. Kouvelas, B. Fenner, and A. Thyagarajan, “Internet Group Management Protocol, Version 3,” RFC 3376, 2002. [Online]. Available: https://www.rfc-editor.org/info/rfc3376 [31] R. Vida and L. Costa, “Multicast Listener Discovery Version 2 (MLDv2) for IPv6,” RFC 3810, 2004. [Online]. Available: https://www.rfc-editor.org/info/rfc3810 [32] B. Fenner, M. Handley, H. Holbrook, I. Kouvelas, R. Parekh, Z. Zhang, and L. Zheng, “Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised),” RFC 7761, 2016. [Online]. Available: https://www.rfc-editor.org/info/rfc7761