Source author record

Apoorv Shukla

Apoorv Shukla appears in the imported research catalog. Authorship, coauthor and topic links are available while profile ownership is still unclaimed.

ResearcherUnclaimed source record

Catalog footprint

What is connected

3works
3topics
4close collaborators

Actions

Connect this record

Log in to claim

Research graph

See the researcher in context

Open full explorer

Inspect adjacent papers, topics, institutions and collaborators without losing the researcher page.

Building this map preview

BZPEER is loading the nearby papers, people, topics and institutions for this page.

Published work

3 published item(s)

preprint2020arXiv

Towards Runtime Verification of Programmable Switches

Is it possible to patch software bugs in P4 programs without human involvement? We show that this is partially possible in many cases due to advances in software testing and the structure of P4 programs. Our insight is that runtime verification can detect bugs, even those that are not detected at compile-time, with machine learning-guided fuzzing. This enables a more automated and real-time localization of bugs in P4 programs using software testing techniques like Tarantula. Once the bug in a P4 program is localized, the faulty code can be patched due to the programmable nature of P4. In addition, platform-dependent bugs can be detected. From P4_14 to P4_16 (latest version), our observation is that as the programmable blocks increase, the patchability of P4 programs increases accordingly. To this end, we design, develop, and evaluate P6 that (a) detects, (b) localizes, and (c) patches bugs in P4 programs with minimal human interaction. P6 tests P4 switch non-intrusively, i.e., requires no modification to the P4 program for detecting and localizing bugs. We used a P6 prototype to detect and patch seven existing bugs in eight publicly available P4 application programs deployed on two different switch platforms: behavioral model (bmv2) and Tofino. Our evaluation shows that P6 significantly outperforms bug detection baselines while generating fewer packets and patches bugs in P4 programs such as switch.p4 without triggering any regressions.

preprint2016arXiv

Final Service Provider DevOps concept and evaluation

This report presents the results of the UNIFY Service Provider DevOps activities. First, we present the final definition and assessment of the concept. SP-DevOps is realized by a combination of various functional components facilitating integrated service verification, efficient and programmable observability, and automated troubleshooting processes. Our assessment shows that SP-DevOps can help providers to reach a medium level of DevOps maturity and allows significant reduction in OPEX. Second, we focus on the evaluation of the proposed SP-DevOps components. The set of tools proposed supports ops and devs across all stages, with a focus on the deployment, operation and debugging phases, and allows to activate automated processes for operating NFV environments. Finally, we present use-cases and our demonstrators for selected process implementions, which allowed the functional validation of SP-DevOps.

preprint2015arXiv

Service Provider DevOps network capabilities and tools

This report provides an understanding of how the UNIFY Service Provider (SP)-DevOps concept can be applied and integrated with a combined cloud and transport network NFV architecture. Specifically, the report contains technical descriptions of a set of novel SP-DevOps tools and support functions that facilitate observability, troubleshooting, verification, and VNF development processes. The tools and support functions are described in detail together with their architectural mapping, giving a wider understanding of the SP-DevOps concept as a whole, and how SP-DevOps tools can be used for supporting orchestration and programmability in the UNIFY NFV framework. The concept is further exemplified in a case study for deployment and scaling of an Elastic Firewall.