Laboratory of Network Programmability and Automation — Programmable Networking is taught at DISI, the Department of Computer Science and Engineering of the University of Bologna, by Franco Callegati, Andrea Melis and Lorenzo Rinieri, with industry seminars from practitioners. Lorenzo Rinieri is a Research Fellow at the ULISSE lab (Unibo Laboratory of Information and System SEcurity) and delivers twenty hours of lessons; Andrea Melis is Assistant Professor at DISI and founder of the same lab.
The teaching calendar interleaves three kinds of session, and that mix is itself a statement about the subject: theory lessons on industrial networks and on mobile networks from 1G to 5G, laboratory sessions on programmable industrial networks, and industry seminars — one from JMA Wireless on SDN and NFV for mobile solutions, one from BeatriQ on practical network programmability. The last weeks of the course are not lectures at all: students come to class and develop the project work under the guidance of the teacher.
The project work is developed by workgroups of 2 or 3 students, with a stated preference for teams of three. A team is finalised by sending an email to [email protected], with [email protected] and [email protected] in copy, subject "Project Work Team - Lab of Net Prog", listing name, surname and student number of each member.
| Track | What you build |
|---|---|
| Industrial networks | Apply network programmability concepts (P4) to industrial network protocols, and use the Asset Administration Shell to build digital twins of industrial assets and of the programmable network itself. |
| 5G networks | Set up an emulated 5G network and run services or execute simulated calls. This track explicitly involves no programmability. |
The final exam is a discussion about the project work: you explain what you did and the teachers ask questions. Two formats were proposed to the class — a single full-day session in which every team presents in front of the other teams, or a set of dates on which each team presents when it is ready.
This site consolidates the whole set of decks by topic rather than by date. Chapters 1 to 4 build the conceptual and practical ground (softwarised networks and the virtual laboratory); chapters 5 to 8 are the P4 core; chapters 9 to 11 cover industrial networks, OT security and the two Kathará labs that feed the project work; chapters 12 to 14 cover model-driven automation, mobile networks and the classical security functions.
The opening argument of the course is a diagnosis, not a technology pitch. In IP technologies there is a tight coupling of control and data planes: control and forwarding functionalities are embedded together and distributed across many network devices. On top of that, the network has accumulated a proliferation of middleboxes — firewalls, NATs, proxies, intrusion detection systems, traffic profilers — each a different physical device implementing a different function beyond pure IP forwarding, each adding cost and complexity.
The consequence is that the network is hard to configure, hard to manage and hard to evolve. The course gives this condition its usual name: network ossification. The related image is the Internet hourglass: a narrow waist (IP) that everything must pass through, which is exactly what made the Internet universal and also what makes it rigid.
Ossification is not a bug in a protocol, it is a structural property: when control logic lives inside every box, and every new function requires a new box, change requires touching everything. Programmability is proposed as the structural answer, not as a feature.
Before anything can be separated it has to be named. The course reminds you that networks are complex architectures and that production data — the user-oriented traffic — is just a little part of the whole story. Three planes coexist:
The outermost plane. It is where the operator expresses intent: what the network should look like, which services exist, which policies apply, how devices are provisioned and monitored over their lifecycle. In a traditional network this plane is a human with a CLI; the whole automation part of this course (chapter 12) is about turning it into an API.
The plane that computes network state: routing tables, forwarding decisions, session and mobility state. Its traffic is called signalling, and the course is explicit that signalling is control plane data — real packets on real links, not an abstraction. In mobile networks (chapter 13) signalling volume is a first-class design constraint.
The plane that moves user packets: match a field, look up an output port, forward. It must be fast, and historically it has been fast precisely because it was fixed. Chapters 5 to 8 are about making it fast and programmable.
The 5G PPP white paper, section 4.3 "Key Logical and Functional Architecture Design Paradigms", is quoted directly in the course because it states the principle in the language of a standards body: a key aspect of the architecture will be infrastructure programmability, that is, the capability to tailor control functions and data plane functions according to the network reality and service needs, together with a split of control and user planes that enables individual scalability of both planes and logically centralised control.
The course lists four CUPS objectives, and it is worth reading them as four different business cases rather than one technical idea:
| Objective | What it means concretely |
|---|---|
| De-coupling | Control plane and data plane may be designed independently; different QoS requirements may be applied only when needed. |
| Scalability | When more resources are needed, they are added where necessary — you grow the plane that is actually saturated, not the whole box. |
| Flexible design and provisioning | Vendors may focus on control plane or data plane and provide solutions independently of one another. |
| Optimized deployment | Locate functionalities where they are needed, instead of where the chassis happens to be. |
Set against ossified IP, a programmable network is claimed to do three things: facilitate network management and control, provide support to innovative service paradigms, and enable on-demand network services. The fourth claim is economic and is stated separately in the slides: treating the data plane as a commodity de-couples functionalities from the implementation and reduces both CapEx and OpEx.
That last point deserves emphasis because it is the thread that runs through the entire course. If the behaviour of a forwarding element is described by a program rather than burned into an ASIC datasheet, then the same hardware can be a router today and a Modbus-aware security appliance tomorrow (chapter 11), and the difference is a compilation step rather than a purchase order.
Be able to state the CUPS objectives (de-coupling, scalability, flexible design and provisioning, optimized deployment) and to connect them to the 5G PPP formulation: infrastructure programmability plus split of control and user planes, giving individual scalability of both planes and logically centralised control.
The market argument comes from GSMA. In An introduction to network slicing (GSMA, 2017) the claim is that with network slicing the 5G network is able to adapt to the external environment rather than the other way around. The course frames the problem around verticals: 5G will be a success if verticals exploit the network to enhance productivity and to launch new services and products. The obstacle is that different verticals have different requirements, and two facts follow immediately:
Network slicing is presented in three steps: exploit virtual networks, in order to create many logical networks, that share the physical infrastructure. The payoff is stated on both sides of the ledger: virtually independent business operations on one physical infrastructure; logical networks that match different vertical requirements while the shared physical infrastructure optimises OpEx and CapEx.
The slides organise the enablers by the layer they act on, and this three-line table is the map of the next three chapters:
| Layer | Enabler | What it gives you |
|---|---|---|
| Devices | Virtualization | Embed any application into a virtual machine (container, mini-OS, …) that can run in the cloud. |
| Infrastructure | Cloud computing | Flexible software function placement and management; tenant isolation. |
| Control and management | SDN and NFV | Design your own network topology on top of the physical network. |
Five acronyms are repeated deliberately throughout the introductory deck, each time as the heading of the section that explains it. They are the vocabulary of the whole course:
| Acronym | Expansion | Where it is developed here |
|---|---|---|
VNF | Virtual Network Function | Chapter 2 |
VNI | Virtual Network Infrastructure | Chapters 2 and 4 |
NFV | Network Function Virtualization | Chapter 2 |
SFC | Service Function Chaining | Chapter 3 |
SDN | Software Defined Networking | Chapter 3 |
Notice the ordering the slides impose. Virtualization is about a single function; cloud computing is about where functions live; SDN and NFV are about who decides. A design question that feels like "which technology" is usually a question about which of those three layers you are actually allowed to change.
The industry seminar by Andrea Margheritini (VEM Sistemi) approaches the same conclusion from the operations side rather than from the architecture side, and the numbers it quotes are the ones worth remembering:
The seminar pairs these with the three sentences that everyone in networking has heard: "every time we implement a network change something goes wrong"; "isn't it great, our switch hasn't been rebooted in six years"; "we can't update or change the network, our business won't allow it". The second one is the trap — an uptime record is being used as evidence of health when it is evidence of paralysis.
Against that, the stated goals are concrete and operational rather than visionary: cost reduction; simplicity; consistent configuration (policy conformance, elimination of human error); reduction in maintenance windows; reduction in time-consuming repetitive tasks; structured changes during the business day; a service catalogue for IT services; elastic scaling.
The seminar diagnoses misalignment along three axes, and the diagnosis is not technical:
| Axis | Symptoms named in the seminar |
|---|---|
| Culture | IT seen in the short term as a solver of contingent problems rather than as a proactive facilitator; IT leadership with a purely operational and technical background; lack of alignment between internal IT structures and from IT to the business. |
| Organization structure | Key people not involved in projects, or unclear roles and responsibilities; absence of ultimate decision makers. |
| Tools | Inadequate and ineffective communication between IT groups; lack of well-structured business cases; no requirements-engineering methodology. |
The seminar contrasts the old catalogue of protocol knowledge (ISDN, ARPANET, ISO-OSI, RS232, USB, HDLC, ALOHA, FDDI, ATM, distance vector, link state, OSPF, BGP, MPLS…) with three skill families that are now expected together:
Chapter 4 of this site is essentially the Linux-administration half of this column, done with ip netns, bridges and Open vSwitch.
Chapter 12 develops exactly this column: YANG as the data model, NETCONF and RESTCONF as the protocols, Ansible as the configuration-management tool.
The pyramid is read bottom-up and it is not decorative. An organisation that buys an abstraction layer without automation underneath ends up with a prettier way of making the same manual mistakes — which is precisely the 22% figure quoted above.
It is the condition in which the network is hard to configure, manage and evolve. Two causes are given in the course: the tight coupling of control and data planes in IP, with control and forwarding functionalities embedded and distributed in many network devices; and the proliferation of middleboxes — firewall, NAT, proxy, IDS, traffic profilers — each implemented as a different physical device, adding cost and complexity. The Internet hourglass is the related image: a narrow, universal, and therefore very hard to change, waist.
Management plane, control plane and user (data) plane. Signalling is control-plane data: it is real traffic on the network, generated by the control plane rather than by users. The course insists that user-oriented production data is only a little part of the whole story, precisely because control and management traffic and effort dominate.
De-coupling (control and data planes designed independently; QoS applied only when needed), scalability (resources added where necessary), flexible design and provisioning (vendors can specialise in control plane or data plane independently), and optimized deployment (functionalities located where they are needed).
Section 4.3, "Key Logical and Functional Architecture Design Paradigms", states that a key aspect of the architecture will be infrastructure programmability — the capability to tailor control functions and data plane functions according to the network reality and service needs — together with a split of control and user planes enabling individual scalability of both planes and logically centralised control.
Because different verticals impose different requirements, so one size cannot fit all; and because the obvious alternative — a replicated infrastructure per vertical — means a cost increase. Network slicing resolves the dilemma: exploit virtual networks to create many logical networks that share the physical infrastructure, so that logical networks match vertical requirements while the shared substrate optimises OpEx and CapEx.
That with network slicing the 5G network adapts to the external environment rather than the other way around. In an ossified network the customer shapes the service around what the network can do; with slicing the logical network is shaped around the customer.
Devices → virtualization: embed any application in a VM, container or mini-OS that can run in the cloud. Infrastructure → cloud computing: flexible software function placement and management, plus tenant isolation. Control and management → SDN and NFV: design your own network topology on top of the physical network.
VNF Virtual Network Function; VNI Virtual Network Infrastructure; NFV Network Function Virtualization; SFC Service Function Chaining; SDN Software Defined Networking.
74% of operators report that network changes have significantly impacted their business; 22% of unplanned outages are caused by human error; 97% of operators admit that human factors cause network outages. The stated goals that follow are cost reduction, simplicity, consistent configuration with elimination of human error, fewer maintenance windows, fewer repetitive tasks, structured changes during the business day, a service catalogue and elastic scaling.
Automation and programmability support centralized provisioning and visibility, which support simplification and abstraction, which finally deliver application agility. The order matters: abstraction without automation underneath only hides manual work, it does not remove it.
The exam is a discussion of the project work, developed in teams of two or three students (three preferred). The tracks are: industrial networks — apply P4 to industrial protocols and use the Asset Administration Shell to build digital twins of assets and of the programmable network itself; and 5G networks — set up an emulated 5G network and run services or simulated calls, explicitly with no programmability.