Nama: Arrizky Ayu Faradila Purnama

NIM: 2101191004

Self-Programming Networks (SPN)

SPN vs SDN (Software-Defined
Introduction
Self-Programming Networks (SPN) is Networking)
currently an ongoing research effort to make SDN (Programmable) SPN (Autonomous)
networks autonomous, as the rapid growth
and wide adoption of cloud computing
platforms have made them very complex to
operate and manage. Technically, SPN is a
shim layer on top of the existing data center
network. It 1) senses data emitted by the
network, 2) infers states of the network, 3)
learn the best responses to the rapidly
changing load and operating conditions, and
finally 4) exert control to the network.

Architecture
The figure on the left shows the
schematic of a Self-Programming Network vis-
a-vis the underlying (Data Center Network)
DCN. SPN layers on top of the DCN, storing
and processing the data it senses from the DCN
and applying appropriate controls to it. The
controls are a function of both the sensed data
and operator policies/preferences. The SPN
layer provides the operator (or user) with an interactive dashboard and query engine interface.

The sensors and controllers of the SPN are placed at

the NICs. Hence, SPNs have a NIC-centric architecture for
sensing and control. Figure on the right shows the NIC-centric
architecture (how the SPN interfaces with the underlying
DCN). For the purpose of illustration, the servers/NICs of the
DCN as logically placed on the equator, with applications
running on different (and possibly overlapping) subsets of
servers in the northern hemisphere, and the traffic generated
by these applications traversing the DCN fabric in the southern hemisphere. By virtue of their
proximity to applications running in the servers on one hand and to the traffic entering/exiting DCNs
on the other hand, NICs are well-placed to provide visibility into the performance of the applications
and correlating it with the network bottlenecks and failures revealed by reconstruction.

Conclusion
In a nutshell, a Self-Programming Network will: 1) do its own configuration, maintenance, and
verification; 2) maximize its resource utilization; 3) provide differentiated and deterministic SLAs to
applications and users; 4) support varying workloads; and 5) provide an interactive dashboard for
users and operators; all by itself with high level policies by the operator.