SRAN: Scaling Named Data Networking via Map-and-Encap

Lixia Zhang; Sirapop Theeranantachai; Tianyuan Yu

REVIEW 3 major objections 4 minor 33 references

SRAN: Scaling Named Data Networking via Map-and-Encap

T0 review · 3 major / 4 minor · reviewed 2026-08-01 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read SRAN separates name-prefix reachability from topological reachability, moving prefix mappings to edge routers so NDN core forwarding state scales with topology, not application names.

desk verdict A genuine NDN routing architecture with substantial implementation and evaluation, but the flagship claim that forwarding state scales with topology is only true for core routers; total state still grows with prefixes, just at the edge. read the letter →

arxiv 2607.20363 v1 pith:K45AKNZ5 submitted 2026-07-22 cs.NI

Tianyuan Yu , Sirapop Theeranantachai , Lixia Zhang This is my paper

classification cs.NI

keywords NamedDataNetworkingMap-and-EncaproutingscalabilityBIERmulticastforwardingprefixegresstableNDNcontrolplanedissemination

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

SRAN's central claim is that Named Data Networking can escape the routing-scalability trap that comes from fetching data by name. The paper proposes separating name-prefix reachability from topological reachability: edge routers maintain a Prefix Egress Table that maps application prefixes to egress routers, and the core forwards only on router-level names or BIER bitstrings. If true, core forwarding state stays fixed by topology — on the AS 1755 topology, 172 FIB and 172 BIFT entries while application prefixes grow to 1,200 — while prefix changes converge within roughly 99–133 ms with less control traffic than a broadcast baseline. A sympathetic reader would care because this is a concrete path to a data-centric network whose core does not carry per-application state, and the same mapping table serves unicast and multicast.

What carries the argument

The load-bearing mechanism is the Prefix Egress Table (PET), a prefix-to-router mapping that lives only at edge routers, together with the Prefix State Database (PSD), the synchronized control-plane store that populates PETs. Ingress edge routers do a two-phase lookup — PET first to choose an egress router, then FIB on that router's name — and encapsulate the original Interest in an NDNLPv2 header carrying either the egress-router identifier or a BIER BitString. Core routers forward on that header using a topology-bound FIB or BIFT, so the per-hop table stays independent of the number of application prefixes.

What would settle it

Run the AS 1755 forwarding-state measurement with 10,000 announced application prefixes and inspect the FIB at a core router: if any application-prefix entry appears, SRAN's claim that core state is topology-bound fails. The paper's forwarding-state sweep stops at 1,000 prefixes, so this is a direct test of the flat-core prediction.

Watch

Extended reading notes

Core claim

The paper's discovery is that NDN's routing state can be made to scale with the physical topology rather than the application namespace by applying Map-and-Encap. In SRAN, application prefixes are announced to edge routers, stored in a synchronized Prefix State Database, and materialized into a Prefix Egress Table at the edge; an ingress router encapsulates each Interest with either the chosen egress router's name (unicast) or a BIER BitString marking all target egress routers (multicast). Core routers therefore never see application names and consult only topology-bound FIB/BIFT tables. Evaluation on the Sprint PoP and AS 1755 topologies shows the expected split: core FIBs stay at 172 entri

Load-bearing premise

An ingress edge router must already have a PET entry for a name prefix when the first Interest for it arrives; if PSD synchronization has not yet delivered that mapping, the Interest is dropped rather than forwarded.

Editorial extensions

If this is right

If SRAN is correct, core routers in an SRAN domain keep a fixed number of forwarding entries regardless of how many application prefixes are announced; on AS 1755 the FIB and BIFT both remain at 172 entries while application prefixes grow to 1,200, versus a baseline that grows linearly.
Prefix announcements and migrations converge close to ordinary NDN routing — medians of 99 ms and 125 ms on Sprint PoP and 133 ms on AS 1755 — so the scalability gain does not require sacrificing convergence speed.
BIER-based dissemination of prefix state cuts control-plane packet overhead compared with broadcast Sync, with median announcement overhead on AS 1755 dropping from 8.65 packets to 2.45 packets per link.
Multicast forwarding state is also topology-bound: the same BIFT serves all multicast prefixes, because the PET supplies the target egress set as a BitString.
The same map-and-encap structure can be applied recursively between ASes, with an AS-level PET mapping prefixes to egress ASes and transit ASes forwarding on AS-level reachability.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

The design's benefit assumes the edge PET already contains a mapping for every Interest's name; during the PSD-synchronization window after a new announcement, an Interest for a not-yet-mapped prefix is dropped (Algorithm 1, lines 3–5). A testable extension would quantify the fraction of early traffic lost and whether application retries absorb it.
SRAN moves prefix state to the edge rather than eliminating it: edge PETs grow linearly with announced prefixes, so the trade-off is acceptable only when the edge is willing to absorb that memory. For networks with many edge routers, the aggregate edge state is the real scaling limit.
The paper's recursion to inter-domain routing implies an AS-level PET/PSD, but the hard open problem there is trusting prefix-to-AS mappings across administrative domains — the paper sketches the nested design but does not evaluate its convergence or security.
Because multicast and unicast share the PET, one could extend SRAN to dynamic group membership by treating joins and leaves as prefix updates; the paper does not explore how fast such churn could propagate through PSD.

Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

Here's the take: SRAN is a real architecture with real code and a real evaluation, and it deserves a serious referee. But the headline claim in the abstract — that “network forwarding state scales with the topology rather than the application-prefix count” — is only true for the core. Total network state still grows linearly with prefixes: every edge router's PET holds an entry for every announced prefix, so the scaling law is O(E·P), not topology-bound. The stress-test note is right about this. Fig. 6's right panel shows edge state climbing from about 646 to 1726 entries as unicast prefixes go from 100 to 1000. What SRAN actually does is move prefix state from all routers to edge routers, cutting the slope from R·P to E·P (61 vs 172 on AS 1755) and making core state fixed. That's a meaningful constant-factor and architectural improvement, but it's not the change of scaling the abstract implies.

What's genuinely new: SRAN is the first NDN routing design to combine L2.5 Interest encapsulation to egress routers with BIER bitstrings for multicast and native NDN Sync for disseminating prefix-to-egress mappings. The PET/PSD split is clean, and using NDN's existing security and Sync is elegant — the control plane falls out of the substrate rather than being bolted on. The implementation in NDNd is substantial, and the evaluation covers an all-edge topology and the intended core/edge case, with state snapshots, scaling sweeps, and analytical extrapolation to larger Rocketfuel topologies. The paper is also honest in the body: Section IV explicitly says SRAN “does not remove prefix state from the network; it moves that state to the edge.” The problem is the abstract and contributions don't carry that nuance.

Soft spots, in proportion: first, the scaling claim needs rewording in the abstract and Contribution 3; the data supports “core state is topology-bound” and “edge state absorbs prefix growth with a smaller slope.” Second, the AS 1755 convergence reporting is coarse: both announcement and migration come out at exactly 133 ms, and no baseline convergence is shown there — either the ns-3 model isn't distinguishing the control planes or the comparison got lost. Third, no code or artifact is released, so independent reproduction is impossible. Fourth, the miss path is unevaluated: Alg. 1 drops an Interest if the PET lacks a mapping, and the paper never quantifies traffic dropped during PSD convergence or after a withdrawal. Fifth, the security analysis is qualitative, which is acceptable at this stage, though “no additional protocol” overstates things since the PSD is a new control-plane component built on Sync.

Bottom line: this paper is aimed at NDN/ICN researchers, and they should read it. It's a solid candidate for peer review — a revision that fixes the claim, releases the code, and reports baseline convergence on AS 1755 would be strong. I'd send it to referees.

Referee Report

3 major / 4 minor

Summary. SRAN is an NDN routing architecture that applies the Map-and-Encap principle to separate name-prefix reachability from topological reachability. Edge routers maintain a Prefix Egress Table (PET) that maps name prefixes to egress routers; the PSD control-plane database is replicated across edge routers via NDN Sync and secured with NDN trust schemas. Core routers forward only on egress-router names (unicast) or BIER bitstrings (multicast), so core FIB/BIFT state is topology-bound. The paper reports a Go/NDNd prototype and evaluates it on Sprint PoP and Rocketfuel AS 1755, claiming reduced convergence overhead and core state independent of application-prefix count, while acknowledging that edge state still grows with prefixes.

Significance. The core architectural idea is well motivated: NDN's name-based forwarding indeed creates prefix-driven state in the entire network, and moving the prefix-to-locator mapping to the edge is a natural application of Map-and-Encap. The paper's concrete contributions include a unified unicast/multicast design using BIER, the use of NDN's native Sync and security to build the mapping dissemination plane, and an actual implementation with state-count measurements on real topologies. The paper also honestly reports that edge state grows with prefixes in Section IV.B, which is a useful data point. However, the abstract and Contribution 3 overstate the result as total state scaling with topology rather than prefix count, and the evaluation leaves key dynamic behaviors unexamined. With appropriate qualification and additional evaluation, the work would be a solid systems contribution; in its current form the headline claim is not supported by the paper's own data.

major comments (3)

[Abstract; §I Contribution 3; §IV.B 'The Effect of Application Dynamics' and Fig. 6] The abstract and Contribution 3 state that forwarding state scales with the network topology, not the application prefixes. This is contradicted by Fig. 6 (right), where SRAN edge PET state grows linearly from 645.92 to 1725.92 entries as the unicast prefix count U goes from 100 to 1000. Section IV.B itself says 'SRAN does not remove prefix state from the network; it moves that state to the edge.' Since the PSD is replicated to all edge routers, per-edge PET state is O(P) and total state is O(E·P) plus topology-bound core state. The supported claim is core-only topology-bounded state and a constant-factor reduction in total state slope (E vs. R), not prefix-independence of overall state. Please rewrite the headline claims to distinguish core, edge, and total state, and give the total-state formula.
[§III-B, Algorithm 1 lines 3–5; §IV.B] Algorithm 1 drops a vanilla Interest when PET.Lookup returns no E∪F, so an Interest for a prefix that has not yet propagated to the ingress edge, or that has just been withdrawn or migrated, is dropped at ingress. The evaluation measures convergence latency and packet overhead but does not quantify the fraction of Interests dropped during convergence windows. Because the core-state benefit depends entirely on edge-side mapping availability, this miss path should be evaluated (e.g., by injecting Interests during announce/migrate events at different rates) and its behavior justified. Without such a study, the claim of 'real-time' adaptation is not substantiated.
[§IV.B 'Prefix-Change Convergence and Overhead (AS 1755)'; Tab. IV] For AS 1755, the text reports that both announcement and migration converge in exactly 133 ms for both SRAN and the baseline, and only packet overhead differs. This exact equality suggests the ns-3 control-plane model does not differentiate the two designs in ways that affect convergence (e.g., Sync cycles, retransmissions, FIB update propagation). The convergence evidence on the target topology is therefore non-informative. Either model the control-plane dynamics more faithfully or explicitly state that convergence is pinned to a fixed topology-diameter delay, and separate the convergence claim from the overhead result.

minor comments (4)

[§IV.A] No artifact URL or repository is provided for the 'Golang-based SRAN implementation,' which limits reproducibility. The authors should add an availability statement with instructions for obtaining the code and running the experiments.
[Fig. 3b] The BIFT table for BFR-id 5 lists both BFR-id 4 and BFR-id 6 with BFR-NBR R6 and the same F-BM, and no row for BFR-id 5 itself. Please clarify whether rows are per BFR-NBR or per BFR-id, and how the F-BM for R6 can contain both bits 4 and 6.
[§III-C and §IV-A] The BitString length and NDNLPv2 encapsulation overhead are not discussed. A 172-router domain requires at least 172 bits; larger Rocketfuel topologies (624, 960 routers) would need proportionally larger headers. One sentence on header-size implications would help.
[§III-B / §III-C] Algorithm 1 appears in §III-B for unicast, while §III-C refers to 'Alg. 2' for the complete process. Make the numbering and cross-reference consistent so readers know where the multicast-specific algorithm is defined.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: SRAN's forwarding-state claims are design measurements, not reductions to their inputs.

full rationale

SRAN's derivation is an architectural construction (PET/PSD mapping, BIER encapsulation) followed by direct measurement and analytical table counting. No quantity called a prediction is obtained by fitting a parameter to the same data that defines it. The core-state reduction (172 FIB entries regardless of prefix count) follows from the design decision to keep application prefixes out of core FIBs and is verified by snapshots, not derived from the claim. The only self-reference is [9], the authors' own Map-and-Encap survey, used as motivation and design pattern, not as an unexamined premise; SRAN's contribution does not assume the conclusion that its state scales. The paper itself notes the edge absorbs prefix state ('SRAN does not remove prefix state from the network; it moves that state to the edge', Section IV-B, Fig. 6 discussion), so the abstract's unqualified 'network forwarding state scales with topology' is an overstatement, but an overstatement is a correctness/scope issue, not circularity. No self-definitional, fitted-prediction, or uniqueness-import steps were found.

Assumptions & free parameters 2 free parameters · 5 assumptions · 0 invented entities

No new physical or mathematical entities are introduced; PET/PSD are software-defined architectural components that are implemented and evaluated. The free parameters are workload choices and a measured constant used in extrapolation, none of which are fitted to the central conclusion.

free parameters (2)

Router/control prefix count per router (181.92) = 181.92 entries (avg; 180-188 in Tab VI)
Used as a constant in the analytical state-scaling model for AS 1755 (§IV.B 'Effect of Application Dynamics'). It is an average measured from the same simulation rather than fitted to the conclusion, but it is a hand-picked constant for extrapolation.
Number of egress routers per multicast prefix (3) = 3
Workload assumption in the forwarding-state snapshots (§IV.B 'Forwarding State Snapshot'): each multicast prefix attached to three egress routers. Not fitted, but it is a free workload parameter that shapes the PET/BIFT counts.

assumptions (5)

domain assumption Routers can securely obtain router-level reachability via an NDN routing protocol such as NLSR/distance-vector before SRAN operates.
§III-A 'SRAN assumes that all routers in the network have already securely obtained router reachability through an NDN routing protocol such as NLSR [19]'.
domain assumption NDN Sync protocols (e.g., SVS/PSync) provide correct and timely dataset synchronization that can carry PSD updates.
§III-D uses Sync group '/<network>/PSD/Sync' as the dissemination mechanism; correctness and scaling of Sync are taken from prior NDN work, not proved here.
domain assumption BIER BIFT can be computed from unicast FIB reachability, and BIFT rebuilds are consistent with FIB changes.
§IV.A 'BIFT is automatically rebuilt after FIB updates'; the paper assumes this consistency without evaluating convergence of BIFT during topological changes.
domain assumption The trust-schema (LVS) policies can be configured to authorize exactly the intended prefix announcements.
§III-E and §IV.C rely on Light VerSec to reject unauthorized announcements; no formal verification or experiment demonstrates the policy configuration is correct in all cases.
domain assumption The forwarding-state counts (FIB/PET/BIFT) are the relevant measure of 'forwarding state'; PIT state is excluded.
Footnote 1 in §III-C says SRAN does not remove PIT state; the evaluation counts only FIB/PET/BIFT, so the claim of topology-bound forwarding state applies to the name-prefix tables, not to the per-Interest PIT.

how reviews work

0 comments

Cite this review

Pith. "Pith review of SRAN: Scaling Named Data Networking via Map-and-Encap." pith.science (2026). https://pith.science/paper/K45AKNZ5

@misc{pith2026260720363,
  author       = {Pith},
  title        = {Pith review of: SRAN: Scaling Named Data Networking via Map-and-Encap},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/K45AKNZ5}},
  note         = {Machine review of arXiv:2607.20363}
}

read the original 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-and-Encap 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.

Figures

Figures reproduced from arXiv: 2607.20363 by the authors.

**Figure 2.** The SRAN system model illustrating the interaction [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗

**Figure 3.** Map-and-encap in SRAN. (a) The control-plane Prefix State Database (PSD) aggregates prefix reachability updates from [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗

Figures from the paper (4 more)

**Figure 4.** Figure 4: Applications register prefixes with an edge router through Prefix Announcements, while edge routers secure routing [PITH_FULL_IMAGE:figures/full_fig_p005_4.png]

**Figure 5.** Figure 5: Sprint PoP topology with prefix migration between the [PITH_FULL_IMAGE:figures/full_fig_p006_5.png]

**Figure 6.** Figure 6: Forwarding state as application prefixes increase in AS 1755. [PITH_FULL_IMAGE:figures/full_fig_p008_6.png]

**Figure 7.** Figure 7: Analytical state scaling across Rocketfuel topologies. State [PITH_FULL_IMAGE:figures/full_fig_p009_7.png]

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

33 extracted references · 1 linked inside Pith

[1]

Named data networking,

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

2014
[2]

NDN-RTC: Real-time videoconferencing over Named Data Networking,

P. Gusev and J. Burke, “NDN-RTC: Real-time videoconferencing over Named Data Networking,” Named Data Networking (NDN), Technical Report NDN-0033, 2015

2015
[3]

Exploring the de- sign of collaborative applications via the lens of ndn workspace,

T. Yu, X. Ma, V . Patil, Y . Kocaogullar, and L. Zhang, “Exploring the de- sign of collaborative applications via the lens of ndn workspace,” in2024 IEEE International Conference on Metaverse Computing, Networking, and Applications (MetaCom). IEEE, 2024, pp. 89–96

2024
[4]

Let’s chronosync: Decentralized dataset state synchronization in named data networking,

Z. Zhu, A. Afanasyev, J. Burke, V . Jacobson, and L. Zhang, “Let’s chronosync: Decentralized dataset state synchronization in named data networking,” inProceedings of the 20th IEEE International Conference on Network Protocols (ICNP), 2013, pp. 1–10

2013
[5]

COPSS: An efficient content oriented publish/subscribe system,

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

2011
[6]

Psync: Efficient synchronization of multiple named data streams,

M. Zhang, A. Afanasyev, J. Burke, and L. Zhang, “Psync: Efficient synchronization of multiple named data streams,” inProceedings of IEEE INFOCOM Workshops, 2016, pp. 1–6

2016
[7]

Svs: State vector sync for named data networking,

P. Moll, W. Shang, A. Afanasyev, and L. Zhang, “Svs: State vector sync for named data networking,” inProceedings of the 7th ACM Conference on Information-Centric Networking (ICN), 2020, pp. 122–132

2020
[8]

Sok: The evolution of distributed dataset synchronization solutions in ndn,

P. Moll, V . Patil, L. Wang, and L. Zhang, “Sok: The evolution of distributed dataset synchronization solutions in ndn,” inProceedings of the 9th ACM Conference on Information-Centric Networking (ICN), 2022

2022

Show all 33 references

[9]

From map-and-encap to BIER: Observations on network routing scalability,

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

2026 arXiv
[10]

A Brief Introduction to Named Data Networking,

A. Afanasyev, T. Refaei, L. Wang, and L. Zhang, “A Brief Introduction to Named Data Networking,” inProc. of IEEE MILCOM, Oct. 2018

2018
[11]

Schematizing trust in Named Data Networking,

Y . Yu, A. Afanasyev, D. Clark, K. Claffy, V . Jacobson, and L. Zhang, “Schematizing trust in Named Data Networking,” inProceedings of the 2nd ACM Conference on Information-Centric Networking (ICN), 2015, pp. 177–186

2015
[12]

A new API in support of NDN trust schema,

T. Yu, X. Ma, and L. Zhang, “A new API in support of NDN trust schema,” inProceedings of the 10th ACM Conference on Information- Centric Networking (ICN), 2023, pp. 122–131

2023
[13]

Automating access control via named data,

Z. Zhang, Y . Yu, A. Afanasyev, and L. Zhang, “Automating access control via named data,” in2018 IEEE Military Communications Con- ference (MILCOM). IEEE, 2018, pp. 1–9

2018
[14]

NDNLPv2: Named Data Networking link adaptation protocol v2,

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

2012
[15]

PCON: A practical congestion control scheme for Named Data Networking,

K. Schneider, C. Yi, B. Zhang, and L. Zhang, “PCON: A practical congestion control scheme for Named Data Networking,” inProceedings of the 3rd ACM Conference on Information-Centric Networking (ICN), 2016, pp. 21–30

2016
[16]

Effective NDN congestion control based on queue size feedback,

S. Song and L. Zhang, “Effective NDN congestion control based on queue size feedback,” inProceedings of the 9th ACM Conference on Information-Centric Networking (ICN), 2022, pp. 111–121

2022
[17]

NLSR: named-data link state routing protocol,

A. Hoque, C. Y . Amin, W. Lan, B. Zhang, and L. Zhang, “NLSR: named-data link state routing protocol,” inProceedings of the 3rd ACM SIGCOMM workshop on Information-centric networking, 2013, pp. 15– 20

2013
[18]

Multicast Using Bit Index Explicit Replication (BIER),

I. Wijnands, E. Rosen, A. Dolganow, T. Przygienda, and S. Aldrin, “Multicast Using Bit Index Explicit Replication (BIER),” RFC 8279,
[19]

NLSR: Named-data link state routing protocol,

A. Afanasyev, A. Hoque, S. O. Amin, L. Zhang, B. Zhang, and L. Zhang, “NLSR: Named-data link state routing protocol,” inProceedings of the 2nd ACM Conference on Information-Centric Networking. ACM, 2015, pp. 15–24

2015
[20]

Measuring isp topologies with rocketfuel,

N. Spring, R. Mahajan, and D. Wetherall, “Measuring isp topologies with rocketfuel,” inProceedings of ACM SIGCOMM, 2002, pp. 133– 145

2002
[21]

Poster: Distance vector routing for named data networking,

V . Patil, S. Theeranantachai, B. Zhang, and L. Zhang, “Poster: Distance vector routing for named data networking,” inProceedings of the 20th International Conference on emerging Networking EXperiments and Technologies, 2024, pp. 23–24

2024
[22]

Mini-NDN: A lightweight network- ing emulation tool for NDN,

Named Data Networking Project, “Mini-NDN: A lightweight network- ing emulation tool for NDN,” https://github.com/named-data/mini-ndn, accessed: 2026-05-22

2026
[23]

ns-3: A discrete-event network simulator,

ns-3 Project, “ns-3: A discrete-event network simulator,” https://www. nsnam.org/, accessed: 2026-05-22

2026
[24]

Intertrust: establishing inter-zone trust relationships,

T. Yu, X. Ma, H. Xie, Y . Kocao ˘gullar, and L. Zhang, “Intertrust: establishing inter-zone trust relationships,” inProceedings of the 9th ACM Conference on Information-Centric Networking, 2022, pp. 180– 182

2022
[25]

Multicast/BIER As A Service,

Z. Zhang, E. Rosen, D. Awduche, and G. Shepherd, “Multicast/BIER As A Service,” IETF, Internet-Draft draft-ietf-bier-multicast-as-a- service-03, Jul. 2022, work in Progress. [Online]. Available: https: //datatracker.ietf.org/doc/draft-ietf-bier-multicast-as-a-service/

2022
[26]

Inter-Domain Multicast Deployment using BIERv6,

L. Geng, J. Xie, M. McBride, G. Yan, and X. Geng, “Inter-Domain Multicast Deployment using BIERv6,” IETF, Internet-Draft draft-geng- bier-ipv6-inter-domain-02, Oct. 2020, expired. [Online]. Available: https://datatracker.ietf.org/doc/draft-geng-bier-ipv6-inter-domain/

2020
[27]

PIM Signaling Through BIER Core,

H. Bidgoli, S. Venaas, G. Mishra, Z. Zhang, and M. McBride, “PIM Signaling Through BIER Core,” IETF, Internet-Draft draft-ietf-bier- pim-signaling-13, Mar. 2025, work in Progress. [Online]. Available: https://datatracker.ietf.org/doc/draft-ietf-bier-pim-signaling/

2025
[28]

Snamp: Secure namespace mapping to scale ndn forwarding,

A. Afanasyev, C. Yi, L. Wang, B. Zhang, and L. Zhang, “Snamp: Secure namespace mapping to scale ndn forwarding,” in2015 IEEE Confer- ence on Computer Communications Workshops (INFOCOM WKSHPS). IEEE, 2015, pp. 281–286

2015
[29]

NDNS: A DNS-like name service for NDN,

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,” in2017 26th International Conference on Computer Communication and Networks (ICCCN). IEEE, 2017, pp. 1–9

2017
[30]

Internet Group Management Protocol, Version 3,

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

2002
[31]

Multicast Listener Discovery Version 2 (MLDv2) for IPv6,

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

2004
[32]

Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised),

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

2016
[2017]

Available: https://www.rfc-editor.org/info/rfc8279

[Online]. Available: https://www.rfc-editor.org/info/rfc8279

Pith tools

Reviewed August 1, 2026 · model on record in the stance chip above.

[1] [1]

Named data networking,

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

2014

[2] [2]

NDN-RTC: Real-time videoconferencing over Named Data Networking,

P. Gusev and J. Burke, “NDN-RTC: Real-time videoconferencing over Named Data Networking,” Named Data Networking (NDN), Technical Report NDN-0033, 2015

2015

[3] [3]

Exploring the de- sign of collaborative applications via the lens of ndn workspace,

T. Yu, X. Ma, V . Patil, Y . Kocaogullar, and L. Zhang, “Exploring the de- sign of collaborative applications via the lens of ndn workspace,” in2024 IEEE International Conference on Metaverse Computing, Networking, and Applications (MetaCom). IEEE, 2024, pp. 89–96

2024

[4] [4]

Let’s chronosync: Decentralized dataset state synchronization in named data networking,

Z. Zhu, A. Afanasyev, J. Burke, V . Jacobson, and L. Zhang, “Let’s chronosync: Decentralized dataset state synchronization in named data networking,” inProceedings of the 20th IEEE International Conference on Network Protocols (ICNP), 2013, pp. 1–10

2013

[5] [5]

COPSS: An efficient content oriented publish/subscribe system,

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

2011

[6] [6]

Psync: Efficient synchronization of multiple named data streams,

M. Zhang, A. Afanasyev, J. Burke, and L. Zhang, “Psync: Efficient synchronization of multiple named data streams,” inProceedings of IEEE INFOCOM Workshops, 2016, pp. 1–6

2016

[7] [7]

Svs: State vector sync for named data networking,

P. Moll, W. Shang, A. Afanasyev, and L. Zhang, “Svs: State vector sync for named data networking,” inProceedings of the 7th ACM Conference on Information-Centric Networking (ICN), 2020, pp. 122–132

2020

[8] [8]

Sok: The evolution of distributed dataset synchronization solutions in ndn,

P. Moll, V . Patil, L. Wang, and L. Zhang, “Sok: The evolution of distributed dataset synchronization solutions in ndn,” inProceedings of the 9th ACM Conference on Information-Centric Networking (ICN), 2022

2022