A Software Architecture for Highly Conﬁgurable Software-Deﬁned

Networks

Ichiro Satoh

National Institute of Informatics, 2-1-2 Hitotsubashi Chiyoda-ku Tokyo, Japan

Keywords:

Software-Deﬁned Network, Software Deployment, Conﬁgurable Protocol, First-Class Object.

Abstract:

We propose a novel architecture for software-deﬁned networking (SDN) that allows for dynamic addition

and modiﬁcation of functionalities. Existing SDN architectures separate data transfer from software changes,

making it difﬁcult to modify the latter in response to the former. In this paper, we treat the software that

deﬁnes communication protocols as ﬁrst-class objects, indistinguishable from data, enabling their transfer to

other computers. Our contribution to software engineering is to introduce a dynamic and uniﬁed mechanism

for software components involved in network processing, which enables ﬂexible and diverse customization.

To demonstrate the utility of our proposed approach, we implemented a prototype on a Java Virtual Machine

(VM) and designed and implemented several practical protocols for both data transmission and component

deployment.

1 INTRODUC TION

Network requirements are diverse and constantly

evolving. Real-world ne tworks, such as sensor n et-

works, experience changes not only in their applica-

tions but also in their requirements, which are inﬂu-

enced by shifts in the real world. A network may be

expected to meet multiple, potentially con ﬂicting re-

quirements simultaneously. These requirements often

necessitate modiﬁcations not only to the applications

but also to the network processing itself.

Software-Deﬁned Networking (SDN) tradition-

ally enables communication protocols—previously

deﬁned by hardware—to be implemented in sof tware.

When protocols are realized in software, it becomes

possible to customize network processing by updat-

ing or modify ing this software. However, in exist-

ing SDN architectures, network processing software

is often designed a t a low level, similar to ﬁrmware,

making runtime customization difﬁcult. Changes to

network processing through software modiﬁcations

during operation—such as updating ﬁrmware—are

typically not pe rmitted. Moreover, the deployment

of networking software at nodes is assumed to rely

on mechanisms outside of SDN, limiting the ﬂexi-

bility of software distribution. Additionally, current

SDN architectures assume software-based switching

across all communication nodes, which prevents ﬁne-

grained c ustomization at the level of individual ses-

sions or packets.

This paper aims to propose a new software archi-

tecture th a t ena bles a mor e ﬂexible SDN by introduc-

ing three key goals: First, allowing SDN customiza-

tion during operation; Second, in tegra ting the distri-

bution of protocol-deﬁning so ftware as a native func-

tion of SDN; And third, enabling the ﬁnest granular-

ity of customization, down to ind ividual packets or

nodes. To achieve the ﬁrst goal, our architecture en-

hances protocol-level isolation to support the coex-

istence of m ultiple p rotocols, even within the same

network layer, while minimizing the impact of swap-

ping software components that implement them. For

the second, it leverages SDN’s inherent ﬂexibility by

embedd ing protocol distribution capabilities into the

data communication process itself, e nabling dynamic

protocol changes. For the third, it supports ﬁne-

grained deployment of protocol-deﬁning so ftware to

appropriate nodes, allowing coexistence with oth e r

protocols. However, predicting which node s will re-

quire speciﬁc protocol software is n ot a lways feasi-

ble; therefore, we propose on-the-ﬂy deployment of

such software to relevant nodes during communica-

tion. To realize these goals, we pr opose a novel soft-

ware arch itecture for SDN based on a cross-layer a p-

proach , as conventional SDN architectures are insuf-

ﬁcient. For the ﬁrst objec tive, we adapt the concept

of the microkernel from operating systems to distin-

guish between dynamic and static software com po-

Satoh and I.

A Software Architecture for Highly Conﬁgurable Software-Deﬁned Networks.

DOI: 10.5220/0013559500003964

In Proceedings of the 20th International Conference on Software Technologies (ICSOFT 2025), pages 319-326

ISBN: 978-989-758-757-3; ISSN: 2184-2833

319

nents, maximizing the former while minimizing the

latter. Regarding the second goal, protocol-deﬁning

software is treated as a ﬁrst-class object, enabling it

to be transmitted between no des just like regular data.

For the third, protocol software can be distributed to

participating nodes dur ing ongoing communication.

Our contribution to software engineer ing lies in intro-

ducing a dynamic a nd uniﬁed mechanism for man ag-

ing software involved in network processing, thereby

enabling highly ﬂexible and diverse customization.

To validate our p roposal, we implemented a proto-

type of the architecture on the Java Virtual Machine

(JVM) and developed several practical protocols for

both data transmission and component deployment.

In this paper, we provide an overview of its struc -

ture. In Section 2, we delineate the fu ndamental con-

cepts and design of our approach. In Section 3, we

present the run time systems employed in our imple-

mentation. Section 4 focuses on the deployable pro-

tocols used in our approach. Section 5 presents the

initial experiences we encountered while developing

and testing our approach. We commence with a dis-

cussion of related work in Section 6. Finally, in Sec-

tion 7, we offer our conclusions based on our ﬁndings.

2 APPROACH

This paper proposes a software architecture that en-

ables dynamic modiﬁcation of applications and pro-

tocols. The architecture treats software components

that deﬁne applications and communication protocols

as ﬁrst-class objects, facilitating software adaptabil-

ity and a dynamic deployment m echanism. As a re-

sult, it allows the transfer of data and software with-

out distinctio n. In real-world networks, the follow-

ing requirements exist, and the architecture ca n de-

ploy an d execute software that deﬁnes applications

and comm unication protocols while meeting these re-

quirements:

• Resource Management: the architecture dynam-

ically allocates and manages network resources

such as bandwidth, proc essing power, and storage

to meet the diverse requirements of different ap-

plications.

• Quality of Service (QoS): it should provide vary-

ing levels of service quality to different applica-

tions, ensuring that critical applications receive

the necessary network r esources to meet their re-

quirements.

• Network Virtualization: it uses virtualization

techniques to create multiple virtual n etworks that

run different ap plications and pr ovide different

services, each with its own set of network re-

sources and requirements.

• Application-Speciﬁc Network Functions: it

should be able to deploy application-speciﬁc net-

work functions, such as ﬁrewalls, lo a d balancers,

and trafﬁc monitors, to provide custom network

services to different applications.

This architecture supports the d ynamic deployment of

both application and networking software, and the de-

ployment software c a n also be deployed in real-world

networks.

2.1 Architecture

To satisfy the above requirements, the architecture

introdu ces the following approaches: First, the dif-

ﬁculty in dynamically modifying network process-

ing software during operation in existing SDN can

be greatly mitigated by intr oducing the concept of

a microkernel from operating systems, wher e pro-

cesses related to communication are deﬁned by soft-

ware components operating outside the microkernel,

thus signiﬁcantly expanding the scope for customiza-

tion. However, unlike operating systems, communi-

cation involves the concept of protocol layers, a nd our

architecture differs from microkernel arc hitectures in

operating systems in the sense that our replaceable

software components themselves are structured hier-

archically. Nonetheless, sin c e layering itself tends to

rigidify the architecture, we enhance ﬂexibility by re-

alizing protocol layering through containment rela-

tionships among software components. These con-

tainment relationships can also be deﬁned by the sof t-

ware components them selves.

Additionally, while existing SDN relies on n on-

SDN mech anisms when deploying software that de-

ﬁnes communication proto c ols, our approach does

not distinguish between data and sof tware by treat-

ing the software deﬁning communication protocols as

ﬁrst-class objects, like data. This approach allows for

software distribution without differentiating it from

data transmission, thereby enabling dynamic software

deployment and modiﬁcations utilizing SDN capabil-

ities. Regarding the issue that existing SDN cannot

accommodate ﬁn e -grained customization at the level

of communication sessions or pa ckets, the proposed

solution ensures that software deﬁning relevant pro-

tocols can be distributed to n odes involved in com-

munication while data is being transmitted.

ICSOFT 2025 - 20th International Conference on Software Technologies

320

2.2 Layered Protocols as Hierarchical

Software Components

As most network protocols a re organized in a hier-

archy of layers, this architecture introduces network

protocols arranged in a hierarchy of layers, where

each layer provides an interface and extends services

from the layer below. However, the structure of lay-

ering itself can sometimes hinder the ﬂexible mod-

iﬁcation of protocols. T herefore, the architecture

does not deﬁne layering explicitly; instead, pr oto-

col layering is realized through containment relation-

ships among software components. The containment

structure of components allows network protocols for

components or data to be organized hierarchically.

That is, each network protocol stack is implemented

as a component hierarchy, and the deployment of a

component within a component hierarchy is intro-

duced as a basic mechanism for accessing services

provided by the underlying layer. Our component-

based protocols in the bottom layer are responsible for

establishing p oint-to-point cha nnels for transmitting

data or components between neighboring computers.

The middle layer is for routing protocols for transmit-

ting data or components beyond directly connected

nodes, and the architecture enables routing protocols

for component migration to be performe d by compo-

nents.

2.3 Deployable Software Components

as First-Class Objects

This architecture treats software components, includ-

ing their co ntaining components, as ﬁrst-class ob-

jects, enabling their transfer be twe en no des without

distinguishing them from data. Additionally, compo-

nents are introduced as autonomous program s that can

move between different computers under their own

control. Similar to mobile agents, when a software

component migrates to ano ther computer, not only the

component’s code but also its state is transferred to

the destination. However, unlike mobile agents, this

architecture is characterized by two novel con cepts:

component hierarchy and inter-component migra -

tion. The former im plies that one component can be

contained within another component as shown in Fig.

1. That is, components ar e organized in a tree struc-

ture. The latter means that each component can mi-

grate to other components as a whole, along with all

its inner components, as long as the destination com-

ponen t accepts it. Compone nts manage their inner

components and provide their serv ic e s and resources.

Network protocols for component migratio n are also

implemented w ithin components.

Migration

Component C

Component D

Component B

Component E

Component A

Step 1

Step 2

Component C

Component A

Component D

Component B

Component E

Figure 1: Hierarchical components and their mi grati on.

Inner

component A

Event from container agent

or runtime system

method 1

method 2

State

Service method 1

Service method 2

*OWPLJOHTFSWJDFT

Component

Services

Component

program

Inner

component B

Runtime system

Java VM / OS / Hardware

Network node

Figure 2: Structure of component.

3 COMPONENT-BASED

PROTOCOLS FOR DEPLOYING

COMPONENTS

In this section, we present the realization of the pro-

posed architecture along with an implementation ex-

ample of a protocol based on this architectur e. The

architecture c onsists not only of software components

that deﬁne communicatio n p rotocols, but also of a

runtime system that manages the execution of these

components. In the prototy pe implemen tation, b oth

the software components and the ru ntime system op-

erate on the Java Virtual Machine (JVM) . As men-

tioned earlier, this study introduces the concept of a

microkernel fro m operating systems in order to min-

imize the unchangeable parts of the software on each

node and maximize the parts that can be modiﬁed. To

achieve this, the runtime system deﬁnes only the min-

imal necessary functionality, and everything else is

deﬁned by components. Regarding communication,

the prototype implementation uses TCP and UDP p ro-

vided by the OS, but all other behaviors are deﬁned

and handled by components. To enable ﬁne-gra ined

and ﬂexible protocol modiﬁcations, the system allows

for preserving the program state (heap area) of a com-

ponen t even after replication or redeployment to an-

other node. Although retaining execution state and

resuming component operations from that state incur s

overhead, it enables communication to be resumed at

the new location, including communicatio n settings

and intermediate r esults.

A Software Architecture for Highly Conﬁgurable Software-Deﬁned Networks

321

Transmitter component

Routing Component

Transmitter Component

Channel

Node 1

Node 2

Runtime System

Network layer

Data-link layer

Application layer

Transmitter component

Routing component

Component A or Data

Channel

Node 3

Transmitter component

Routing Component

Transmission

Runtime System

Transmission

Component A or Data

Figure 3: Architecture of component-based protocols for transmitting data or components.

3.1 Runtime System

The run time system manages the execution of compo-

nents—such as startin g and stop ping them—as well

as the containment relationships among components.

Additionally, the runtime system provides functional-

ity for converting components into transferable data

during redeployment, and for reconstructing them

back into components afterward. Since components

in the prototype are implemented as Java programs,

Java’s serialization featu res are used for this pur-

pose. There is no distinctio n between software com-

ponen ts and data, so components and their contained

subcomponents can be transferred and executed on

other nodes. The runtime system also maintains an d

manages the containment relation ships among com-

ponen ts. It allows one service to be provided by one

or more components. Therefore, more than one dif-

ferent network protocol can be suppor te d by service

components that provide their own protocols for their

inner components. Componen ts can autonomously

select an appropr iate service component with suitable

protocols to meet their requirements and reposition

themselves into the selected components.

3.2 Deployable Protocols

Software components for deﬁning protocols are capa-

ble of being repositioned and operationa l, which al-

lows for extensive customization of network process-

ing. Each component is capable of containing one or

more components, with the outer components provid-

ing services to the inner components as sh own in Fig.

3. Since software components and data are not distin-

guished, components are capable of transferring th e ir

contained components by serializing their progr am

code and internal state, either within the same com-

puter or to components on a d ifferent computer. Each

component can be transmitted or duplicated to other

nodes. Components a re hierarchically organized as a

protocol stack, where each component at a lower layer

can b e seen as a service provider for components at an

upper lay e r. In addition to data, w hen one component

is repositioned within anothe r, the former component

is treated as contained by the latter. The containing

component can provide services such as tran smission

and transformation to its contained components. All

components in this architecture are programmable en-

tities. Protocols need to be deﬁned as abstract classes

in the Java language, but these basic protocols can be

easily extended to deﬁne a dvanced protocols. This ar-

chitecture demonstrates that the hierar c hical model of

communication protocols can be replicated.

Tr ansmission for Point-to-Point Channels

A transmitter component is provided to dynamically

deploy software components between neighb oring

nodes. The transmitter component is deployed on run-

time systems at the source and destination nodes and

establishes p oint-to-point chan nels for data and com-

ponen t transmission. This component can automati-

cally exchange its in te rnal components with the coun-

terpart transmitter component at the current or remote

node. Cur rently, the transmission of serialized com-

ponen ts is assumed to utilize TCP for perf ormance

reasons, but a TCP-equivalent com munication pr oto-

col can also be realized by components. To deploy a

component, it is serialized with its state and code be-

fore being sen t to th e destination transmitter compo-

nent. The r eceiving component reconstructs the com-

ponen t upon receipt. The transmitter component can

be customized with security extension s such as an au-

thentication mechanism and e ncryption. Dynamic de-

ployment of transmitter components is also possible.

Routing Protocol for Component Transmission

Compone nts can be deployed to on e or more desti-

nations under their own control, but determining the

itinerary is challenging. Two approaches for deter-

mining and ma naging component itineraries are intro-

duced. The ﬁrst approach is based on packet routing

mechanisms and is implemen te d as forwarder com-

ponen ts that redirect components or data to new des-

tinations. Each forwarder component holds a network

structure table and redirects received compon ents or

ICSOFT 2025 - 20th International Conference on Software Technologies

322

data to its destination or a closer forwarder compo-

nent. This process is repeated until the component

reaches its ﬁnal destination. The second approach

uses navigator components to convey the destination s

of their inner components. The navig ator component

migrates itself with all its inner components to the

next destination, propagates events to the inner com-

ponen ts, a nd continues to the next d estination. A se-

curity mechanism for encrypted component transmis-

sion is also provided.

Forwarding-Based Tr ansmission: The forwarder

mechanism is a pac ket routing approac h commonly

used in network systems. It consists of forwarder

components that redirect data compone nts to new des-

tinations. Forward er components are loc ated at inter-

mediate nodes in a network and store a table that de-

scribes the network structure. Upon receiving a data

component, the forwarder checks its destination, and

if it’s not the ﬁnal d estination, it redirects it to the ﬁ-

nal destination or to another forwarder closer to the

destination as shown in Fig. 4. Forwarder compo-

nents can propagate certain events to visiting compo-

nents, instructing them to perform actions b efore for-

warding them to their ﬁnal destinations. The process

is repeated until the da ta component reaches its ﬁnal

destination.

Step 1

Step 2

Node 2

Component

Forwarding

Node 1

Node 3

Node 2

Node 1

Node 3

Component

Forwarder component

Forwarder Component

Forwarder component

Node 4

Migration

Figure 4: Routing components for forwarding to the next

hosts.

Navigating-Based Transmission: Navigators are

service c omponents that convey the destinations of

inner components to these compone nts, as shown in

Fig. 5. The nav igator compon ents ca n move them-

selves and their inner components to the next loca-

tion, determined statically, algorithmically, or based

on the inner components’ previous computations and

the environment. The navigator components can

propagate events to their inner components up on ar-

rival, then continu e their itinerary. Secur ity m e cha-

nisms are implem ented in the navigators, which can

encrypt/decrypt components using their own encryp-

tion/decryption mechanisms.

Navigator Component

Monitor Component

Migration

Deployment

Navigation route

Navigation

route

Node 1

Node 3

Node 2

Step 1

Step 2

Node 1

Node 2

Node 3

Node 4

Figure 5: Navigator component with its inner components

for traveling among nodes.

3.3 Component-Based Protocol

Distribution for Deployi ng

Components

Service c ompone nts th at support protocols are de-

ployed in the system using one of three me chanisms:

autonomous migration to nodes where the protocols

are needed, passive deployme nt with components for

the protocols installed a t nodes, or active deployment

through a designated component that selects and in-

stalls the required protocols at nodes. Service com-

ponen ts for deﬁning protocols autonomously migrate

to nodes at which the protocols may be needed and

remain at the node s in a decentralized man ner. Com-

ponen ts for protocols are passively deployed at nodes

that may require them by using forwarder components

prior to utilizing the protocols as distributors o f pro-

tocols. Moving com ponents can carry service c om-

ponen ts for de ﬁning protocols inside themselves and

deploy the comp onents at nodes that the component

traverses.

4 EARLY EXPERIMENT

The current imple mentation runs on Java VM ver. 17

or later an d employs the common Java object seri-

alization package for marshaling an d unmarshaling

the states of components. The mechanism for mar-

shaling and unmarshaling co mponents is similar to

that used fo r marshaling and unmarshaling mobile

agents (Satoh, 2010). Transmitter components es-

tablish communication channels thr ough TCP, HTTP,

and SMTP, while forwarder a nd navigator compo-

nents traverse multiple nodes based on their static

routing tables and SNMP agents.

A Software Architecture for Highly Conﬁgurable Software-Deﬁned Networks

323

The curre nt implementation of the architecture

was not optimized for performance. However, its ba-

sic performance was evaluated on a distributed sys-

tem consisting of 8 PCs (Intel Cor e i5 2.4GHz) con-

nected by 1Gbps Ethernet. The per-hop latency (in

microseconds) and the throughput (in c omponents

per second) were measured. T he target compo nents

were minimal-sized components consisting of com -

mon callback meth ods invoked d uring changes in

their life-cycle state. The size of each compo nent was

approximately 4 Kbytes (zip-compre ssed ). The time

for migrating the compone nt w ithin a hierarchy and

between two nodes was also measured for reference.

Compone nt migration within a component hierarchy

took less than 1 millisecond, including the time for

checking entry permission. Migratio n between n odes

was performed using simple TCP-based transm itter

components and had a per-hop latency of 10 millisec-

onds and a throughput of 75 components per seco nd.

The latency included marshaling, compression, estab-

lishing a TCP connection, transmission , acknowledg-

ment, decompression, security veriﬁcation, and creat-

ing Java namespace components. The forwarder pro-

tocol had a per-hop latency of 13 milliseconds and a

throughput of 60 comp onents per second, while the

navigator protocol had a per-hop latency of 11 mil-

liseconds and a throughput of 62 components per sec-

ond. The f orwarder componen t determined the next

hop based on its routing table, while th e navigator mi-

grated itself and its inner components to the next node

by incorporating itself into a transmitter component.

The above results, obtained without performance

optimization, are not conclusive. The forwarder pro-

tocol performed better than the navigator protocol

because the latter also migrated the protocol itself.

When multiple components were migrated onto a net-

work, congestion on each computer was sometim e s

unbalan ced due to asynchronous execution. The over-

head of the component-based protocols in terms of

latency was signiﬁcant compare d to high-speed com-

munication protocols. However, the protoc ols were

sufﬁcient for high-level prototype s of a pplication-

speciﬁc protocols, such as data transmission in sen-

sor networks and monitoring of sensor nodes. The

throughput was limited by the security mechanisms

of the Java VM and r untime system, not by the proto-

cols.

4.1 Application

We present an application of the proposed architec-

ture here. The application is employed to gather data

from each sensor node in a sensor network and to

process the collected data using a pplication-speciﬁc

data processing pr ograms. The sensor network com-

prises one or a small number of intermediate nodes

and a large number of sensor nodes. The interme-

diate n ode collects data from the sensor nodes, pro-

cesses it, and then forwards it to the cloud. To mini-

mize data commu nication, edge comp uting is utilized

to perform some data processing at the sensor n odes.

4.2 Data Collection

Two approaches exist for collecting data in the sensor

network. The ﬁrst approach entails sending a request

message from the intermediate node to each sensor

node to collect measurement data. In this app roach,

the intermediate node collects data from numerous

sensor nodes by sending a request message and re-

ceiving reply messages containing measu rement data

from the sensor nodes. The second approach involves

sending a me ssage from the intermediate node to one

sensor node to query its measurement data. Each sen-

sor n ode subsequently sends messages containing its

measurement data to its neighboring nodes and ulti-

mately returns the message to the intermediate node

with the results of multiple sensor node measure -

ments.

Using Forwarder Components

The ﬁrst approach collects data at sensor nodes usin g

forwarder co mponents through transmitter co mpo-

nents in the interme diate node and the sensor nodes.

The forwarder component receives a data processing

component, creates duplicates of it, and transmits the

duplicated components to the target sensor nodes for

data pro c essing at the nodes. After each sensor node

receives a data processing component, it instructs the

component to execute data processing programs and

then returns the comp onent with its processing results

to the intermediate node. The forwarder compo nent

in the intermediate node aggregates the data or per-

forms further processing.

Using Navigator Components

The second approach collects data at sensor nodes

using navigator components between sensor nodes

or between a sensor node and an intermediate node

employing a transmitter co mponent. The navigator

component moves with the data pr ocessing compo-

nent according to its own path and executes the data

processing progr a m at the arriving sensor node. Af-

ter its execution, the navigator c omponent for ward s

the d ata processing component with its results to the

next sensor node and ﬁn ally back to the intermediate

node. This approach requires a larger amount of data

ICSOFT 2025 - 20th International Conference on Software Technologies

324

to be transferred, but with less frequent transfers, as

the navigator component is transferr e d along w ith the

data processing component.

Remarks

We compare the ﬁrst and second appro aches. The ﬁrst

approa c h necessitates a larger amount o f data to be

transferred but with less frequent transfers, as the nav-

igator component is transfe rred betwee n nodes along

with the data processing component. The second ap-

proach can reduce the number of data communication

instances and en a ble efﬁcient data processing and col-

lection.

5 RELATED WORK

The domain of dynamic deployment and conﬁgura-

tion of software in networks has seen the implemen-

tation of va rious techniques for application software.

However, the utilization of dynamic relocation for

network processing software is not as pr evalent. In

this section, we will analyze existing literature with

a speciﬁc emphasis on Software-Deﬁne d Networking

(SDN) and active networking technologies.

One reaso n SDN gained attention is that many ex-

isting network devices had to be conﬁgured by di-

rectly operating the device itself, making them un-

suitable for remote monitoring and operation. An-

other factor is the improvement in CPU (i.e., general-

purpose processors) performance, which made it pos-

sible to handle network processing not with dedicated

semiconductors (ASICs) but instead with general-

purpose processors and software. Initially, most SDN

research focused on remote network conﬁguration un-

der early frameworks such as OpenFlow (McKeown

et al., 2008a).

SDN adopts software-based controllers or APIs

to communicate with the un derlying hardware infras-

tructure. Dynamic reconﬁguration and deployment of

networking software are crucial in SDN, and there are

practical implemen ta tions, such as OpenFlow (McK-

eown et al., 2008b) and NETCONF (Enns et al.,

2006). The OpenFlow proto col separates the control

and data forwarding planes in software-deﬁned net-

working (SDN) a rchitecture. The control plane acts

as a controller to manage network infrastructure and

implement custom p olicies, while the data forward-

ing plane handles hardware forwarding. Communi-

cation between the two requires speciﬁc protocols.

NETCONF is a management p rotocol for modifying

network device conﬁgurations, but SDN reconﬁgura-

tion can be limited. Ac tive networking, which is pro-

grammable for custom services, has not been widely

adopted due to security and perf ormance issues. They

are too heavy to support networks in the real world.

Although SDN allows for customizing network

processing by distributing software tha t deﬁnes the

network behavior to each node , in practice, soft-

ware distribution is gen e rally handled using non-SDN

methods su ch as standard software deployment and

management tools (e.g., Chef or Ansible). ONAP

(Open Network Automation Platform) an d OPNFV

(Open Platform for NFV) enable comprehensive or-

chestration of NFV (Network Fun c tions Virtualiza-

tion) environments (Kirksey et al., 2017; The Linux

Foundation, 2017). While the SDN controller can de-

termine which nod es receive sof tware, the ac tual dis-

tribution itself uses mechanisms other than SDN.

On the other hand, distributing the very software

that constitutes SDN through SDN does enable cen-

tralized management, but there have bee n few at-

tempts in this area . One exam ple is P4Runtime.

P4Runtime is a protocol tha t transf e rs data-plane

behavior—such as packet processing logic described

in the P4 lan guage—from the controller to switches

for execution (Bosshart et al., 2014; Community, ).

With P4 Ru ntime, it is even possible to temporarily

run the active pipeline in parallel with a new version

of the pipeline (Jin et al., 2020). P4Runtime assumes

that the communication node s can execute programs

written in P4, but the method proposed in this pa-

per uses the Java Virtual Machine (JVM). If the code

can run on the JVM, it does not matter which pro-

gramming language is used. Also, while P4Runtime

can only chang e the communication settings on a per-

pipeline basis, ou r proposed method has the advan-

tage that it can be changed on a per-packet basis.

The present study proposes a framework for pro-

grammable networks, drawing upon the co ncept of

active networking (Tennenhouse et al., 1997). De-

spite being explo red by several researchers, a ctive

networking, characterized by its programmability for

custom services, has not gained wide spread adoption

due to secu rity and performance challenges. The pa-

per presents an architecture for programmable net-

works based on active networking, which has faced

challenges in terms of security and performance. The

framework utilizes mobile agent tech nologies a nd

aims to use software-deﬁned networking fo r edge

computing and sensor n etworking. It overcomes limi-

tations faced by previous propo sals for improved c on-

nectivity by keeping components related to network

processing small (less than 1 MB), enabling efﬁcient

adaptation of so ftware networking.

Our arch itec ture introduces the co ncept of hier-

archical software components, a unique approach to

A Software Architecture for Highly Conﬁgurable Software-Deﬁned Networks

325

conﬁguring SDNs in addition to rea l-world networks,

which has rarely been explored. The authors high -

light that ther e have been only a few attempts to in-

corporate hierarc hical components in SDNs and edge

computing conﬁgurations, with one example being a

policy description proposed by Ferguson et al. to

simplify la rge SDN networks through sub-policy con-

struction (Fergu son et al., 2012). Finally, it is note-

worthy that the proposed arch itec ture adopts mobile

agent technologies, instead of code migration tech-

niques, to facilitate programmable networks. Existing

works have a pplied mobile age nts in active networks

(Busse e t al., 1999); however, the se did not support

hierarchical components, unlike the proposed archi-

tecture.

6 CONCLUSION

In this paper, we proposed a new software architec-

ture for SDN, w hich makes several signiﬁcant con-

tributions. By incorporating the concept of a mi-

crokernel from operating systems, we differentiated

between static and changeable software within the

SDN architecture, minimizin g the fo rmer and max-

imizing the latter to facilitate dynamic adaptations.

By tre ating software that d eﬁnes co mmunication pro-

tocols as ﬁrst-class objects, akin to data, we enabled

seamless software delivery without distinguishing it

from data communication, thus leveraging SDN for

dynamic software distribution and mod iﬁca tion. Ad-

ditionally, we ensured that software deﬁning proto-

cols could be distributed to the nodes involved in d ata

transmission during communication. T hese capabil-

ities were preliminarily evaluated throug h its proto-

type implementation. Some readers may consider the

current architecture to have low communication per-

formance. However, in network infrastru ctures where

ﬂexible SDN is required, such as sensor networks, the

priority often lies in ﬂexible customiz a tion rather than

high communication performanc e, and the lower per-

formance is not typically a problem.

Lastly, futur e challenges ar e discussed. Although

we have evaluated the performance of the system on

a small scale, we intend to assess the performance

of the system on a larger scale and in more realis-

tic settings. The protocols implemented in this archi-

tecture are still few. We want to verify its versatility

by imp le menting protocols tailored for speciﬁc n et-

works, such as mobile ad -hoc networks, as well as

application-level protocols such as service discovery

and publish-subscribe models.

REFERENCES

Bosshart, P., Daly, D., Gibb, G., Izzard, M., McKeown,

N., Rexford, J., Schlesinger, C., Talayco, D., Vannac-

cione, A., Walker, D., and Wotherspoon, L. ( 2014).

P4: Programming protocol-independent packet pro-

cessors. ACM SIGCOMM Computer Communication

Review, 44(3):87–95.

Busse, I., Covaci, S., and Leichsenring, A. (1999). Auton-

omy and Decentralization in Active Networks: A Case

Study for Mobile Agents. In Proceedings of Work-

ing Conference on Act ive Networks, volume 1653 of

LNCS, pages 165–179. Springer.

Community, P. P4runtime speciﬁcation. https://p4.org/

p4runtime/. Accessed: 2025-03-03.

Enns, R. et al. (2006). IETF NETCONF Network Conﬁg-

uration protocol. Technical report, RFC 4741 (Pro-

posed Standard). Obsoleted by RFC 6241.

Ferguson, A. D., Guha, A., Liang, C., Fonseca, R., and

Krishnamurthi, S. (2012). Hierarchical policies for

software deﬁned networks. In Proceedings of the ﬁrst

workshop on Hot topics in software deﬁned networks

(HotSDN ’12), pages 37–42. ACM Press.

Jin, X., Gao, J., Liu, A. A., Dong, Z., Xie, G., and Zhang,

M. (2020). Dynamic control of programmable data

planes with P4Runtime. IEEE Transactions on Net-

work and Service Management, 17(4):2385–2398.

Kirksey, H. et al. (2017). OPNFV: An open platform to ac-

celerate NFV. IEEE C ommunications Standards Mag-

azine, 1(4):72–78.

McKeown, N., Anderson, T., Balakrishnan, H., Parulkar,

G., Peterson, L., R exford, J., Shenker, S., and Turner,

J. (2008a). OpenFlow: Enabling innovation in cam-

pus networks. ACM SIGCOMM Computer Communi-

cation Review, 38(2):69–74.

McKeown, N., Anderson, T., Balakrishnan, H., Parulkar,

G., Peterson, L., R exford, J., Shenker, S., and Turner,

J. (2008b). Openﬂow: enabling innovation in campus

networks. ACM SIGCOMM Computer Communica-

tion Review, 38(2):69–74.

Satoh, I. (2010). Mobile Agents. In Handbook of Ambient

Intelligence and Smart Environments, pages 771–791.

Springer.

Tennenhouse, D. L. et al. (1997). A Survey of Act ive

Network Research. IEEE Communication Magazine,

35(1).

The Linux Foundation (2017). Open Network Automation

Platform (ONAP): Overview and architecture white

paper. https://www.onap.org/. Accessed: 2025-03-03.

ICSOFT 2025 - 20th International Conference on Software Technologies

326