02
2
◎
Day objective — the why (transformation, NaaS, MEF 3.0), the how (control/data-plane separation, OpenFlow, NETCONF), the who (ONOS, OpenDaylight, ONF), and the proof (Lab 2 — you re-route traffic from a controller).
2.1
Why Networks Are Transforming
Applications moved to the cloud and became elastic; the WAN connecting to them stayed manual, hardware-defined and quarterly-provisioned. That gap is the entire business case for everything in this course.
The pressure test — legacy WAN vs what the business now expects
| Dimension | Legacy network | Software-driven target |
|---|---|---|
| Provisioning a site | Weeks–months, truck rolls, manual CLI per box | Minutes–days, zero-touch, API-ordered |
| Change model | Per-device config, error-prone, snowflake configs | Central policy pushed to the fleet |
| Capacity | Fixed CIR, over-provisioned for peak | On-demand, elastic bandwidth |
| Function delivery | Appliance per function (router, FW, WAN-opt) | Software functions on shared cloud (NFV, Day 3) |
| Buying model | CapEx boxes + long contracts | Service subscription — NaaS |
| Inter-provider | Email/phone quotes, weeks of swivel-chair | LSO Sonata API calls (Day 4) |
The race that made the industry change — order a new branch, two ways
Provision a new site · legacy vs NaaS, in real time
LEGACYManual, hardware-definedready
NaaSSoftware-driven, API-orderedready
Press Order a new branch. The legacy path plods through quotes, a truck roll and box-by-box CLI; the NaaS path is an API order with zero-touch provisioning. Same outcome — weeks vs minutes.
Cloud adoption
Apps live in IaaS/SaaS across regions. Traffic patterns inverted: branch→DC became branch→many clouds, so static hub-and-spoke WANs backhaul traffic pointlessly.
Automation
Manual CLI cannot match cloud change velocity, and humans mis-type. APIs, controllers and orchestration make the network programmable infrastructure.
On-demand services
Enterprises expect to order connectivity like cloud compute: quote in seconds, activate in minutes, scale by API, pay for what's used.
- Cloud adoption — traffic goes to many clouds; the WAN must be cloud-aware, not DC-centric
- Automation — from device-by-device CLI to fleet-wide, API-driven, intent-based change
- On-demand services — consumption model shifts from owning capacity to subscribing to outcomes
2.2
Network as a Service & MEF 3.0
NaaS is the delivery model; MEF 3.0 is the framework that makes it real across providers: standardized service definitions + LSO automation APIs + certification, so a service means the same thing everywhere.
Worked example — order a real MEF 3.0 service over LSO (the three pillars, made concrete)
Scenario — Acme Corp needs a 200 Mbps Access E-Line (MEF 6.3 EVPL, point-to-point) from its Pune site to a cloud on-ramp. SP-A serves Pune, but the on-ramp is off-net — reachable only through partner SP-B. So SP-A buys the off-net OVC segment from SP-B over LSO Sonata. Every step is machine-ordered — no email, no truck-roll. This is NaaS: the standardized service (attributes), delivered by LSO automation, guaranteed by certification.
The agreed Service Attributes (what "200 Mbps E-Line" actually means)MEF 6.3 · 10.4 · 26.2 · 23.2
| Attribute | Value | Spec |
|---|---|---|
| Service type | Access E-Line (EVPL) — point-to-point, VLAN-mapped | MEF 6.3 |
| Endpoints | UNI at Pune (Subscriber) · ENNI to SP-B (operator handoff) | MEF 26.2 |
| Bandwidth Profile (trTCM) | CIR 200 Mbps · CBS 50 KB · EIR 50 Mbps · EBS 50 KB · color-aware | MEF 10.4 |
| Class of Service | CoS H — one-way delay ≤ 10 ms · FLR ≤ 0.01% · IFDV ≤ 3 ms | MEF 23.2 |
| Frame handling | MTU 1522 B · S-VLAN 601 at the ENNI · L2CP = tunnel | MEF 45.1 |
LSO Sonata — SP-A buys the off-net OVC segment from SP-B (POQ → Quote → Order → Inventory)# ① Serviceability — "CAN you deliver it, and by when?"
POST /productOfferingQualification
productOfferingQualificationItem: [{ id: "1", action: "add",
product: { productOffering: { id: "ACCESS_E_LINE" },
place: [{ role: "INSTALL_LOCATION", city: "Pune", country: "IN" }] } }]
← 201 · qualificationResult: green · installationInterval: 10 business days
# ② Quote — "WHAT will it cost, at these attributes?"
POST /quoteManagement/quote
quoteItem: [{ id: "1", action: "add", product: {
productOffering: { id: "ACCESS_E_LINE" },
productConfiguration: { bandwidthProfile: { cir: 200, eir: 50, unit: "Mbps" }, cos: "H" } } }]
← 201 · state: approved.answered · price: USD 640/mo · quoteValidFor: 30 days
# ③ Order — "BUILD it." (references the accepted quote)
POST /productOrderingManagement/productOrder
productOrderItem: [{ id: "1", action: "add", quoteItem: { quoteId: "Q-8841", id: "1" } }]
← 201 · state: acknowledged → inProgress → completed (buyer subscribes to notifications)
# ④ Inventory — "what do I now HAVE?"
GET /productInventory/product?state=active
← 200 · OVC-55217 · ACCESS_E_LINE · active · CIR 200 Mbps · since 2026-07-23
▸
Which LSO reference point carries each step — Acme→SP-A order rides Cantata (CUS↔BUS); SP-A's BSS drives its orchestrator over Legato (BUS↔SOF); the off-net buy from SP-B is the Sonata flow above (BUS↔BUS) and is operated over Interlude (SOF↔SOF); each orchestrator programs its network via Presto (SOF↔ICM) → Adagio (ICM↔ECM). One order, six reference points — exactly the MEF 55.1 map in the explorer above. You execute this Sonata flow yourself in Lab 4.
- NaaS concept — network connectivity and functions consumed as a subscription service with a cloud-like lifecycle: self-service ordering, rapid activation, elastic change, usage visibility▶ watch the lifecycle ↑
- MEF 3.0 framework — the global federation of standardized, orchestrated services across provider networks (LSO Sonata/Interlude carry them between operators)▶ see the LSO map ↑
- Standardized services + automation — service definitions (what you buy) + LSO APIs (how it's ordered and operated) are the inseparable halves of NaaS▶ what a service is ↑
≡
Language discipline — in MEF vocabulary a service is defined by its attributes (agreed behaviors at interfaces like UNI/ENNI), not by the technology that implements it. Day 3 makes this concrete with Carrier Ethernet; Day 4 does it for SD-WAN.
2.3
MEF-NF Domain Map
Six domains, one mental model: SDN and NFV are the enabling technologies, Carrier Ethernet and L2/L3 services are the products, SD-WAN is the overlay product, and LSO is the automation fabric around all of it.
Filter by role
drag any domain to rearrange · click one for the full breakdown
zoom
The six domains, mapped to the actual standards that define themMEF 3.0 body of work
| Domain | Role | Defining standards | What it delivers |
|---|---|---|---|
| SDN | Enabler | ONF architecture (MEF-referenced) | Control/data-plane separation + a programmable, centrally-viewed network (2.4–2.6) |
| NFV | Enabler | ETSI NFV ISG (MEF-referenced) | Network functions as software — VNFs/CNFs on pooled cloud (Day 3) |
| Carrier Ethernet | Product (L2) | MEF 6.3 · 10.4 · 26.2 · 45.1 | E-Line / E-LAN / E-Tree / E-Access at UNI & ENNI (Day 3) |
| IP / L3 services | Product (L3) | MEF 61.1 (IP) · 69 (Internet Access) | IP-VPN & Internet access, defined by IP Service Attributes (Day 1 → Day 4) |
| SD-WAN | Overlay product | MEF 70.1 · 117 (SASE) · 88 (security) | Application-aware overlay over any underlay (Day 4) |
| LSO | Automation fabric | MEF 55.1 + Sonata/Interlude/Legato/Presto/Adagio APIs | Order → activate → assure → bill, across providers (Day 4) |
◆
One service can touch all six — an enterprise SD-WAN service (MEF 70.1) whose off-net underlay is a Carrier Ethernet E-Access (MEF 6.3), whose edges are NFV CNFs steered by an SDN controller, ordered and assured end-to-end over LSO — with the IP service attributes (MEF 61.1) governing the routed layer. That single sentence is the whole MEF-NF exam in one breath.
- Enablers vs products vs fabric — SDN/NFV enable; Carrier Ethernet, L2/L3 and SD-WAN are sold; LSO automates the lifecycle around them all▶ explore the live map ↑
- Exam lens — MEF-NF tests all six domains plus the transformation / NaaS narrative that links them▶ explore the live map ↑
- Day 1 was the prerequisite — every domain assumes you can read an IP plan and a routing table▶ explore the live map ↑
2.4
SDN Core Principle
Classic routers bundle a brain (control plane) and muscle (data plane) in every box; each brain learns the topology by protocol gossip. SDN removes the brains and centralizes them into a controller with a global view.
Distributed brains vs central brainthe one diagram to remember
data links southbound control channel
See it move — fail a link and watch each model react
Same 4-node network · two control models
MODE
Traditional (distributed)
[control model] The same four nodes, two ways to run the control plane. Toggle Traditional vs SDN, then fail link n1–n2 and compare how each recovers. In SDN mode, try ⚡ Kill controller — the forwarding survives.
Inside one box — the three planes, anatomically
- Control plane — decides where traffic goes: topology, routes, policies (was: OSPF/BGP per box; now: controller logic)▶ see it anatomically ↑
- Data plane — moves packets at line rate by matching tables; keeps working even if its instructions stop updating▶ walk the ASIC pipeline ↑
- Separation — the planes talk over an open southbound protocol, so forwarding hardware becomes interchangeable▶ toggle the two models ↑
- Centralized intelligence — one consistent network view enables global optimization no per-box protocol can compute▶ fail a link, compare models ↑
2.5
SDN Architecture & Interfaces
Three tiers: applications express intent northbound; the controller compiles intent into state; southbound protocols program the devices. Know OpenFlow and NETCONF at message level.
The 3-tier SDN stack and its two named interfacesarchitecture
the two interfaces the exam names
Southbound protocols — OpenFlow vs NETCONF (both matter, different jobs)
| Property | OpenFlow (ONF) | NETCONF (IETF RFC 6241) |
|---|---|---|
| Programs | Forwarding behavior — match-action flow tables | Device configuration — structured config data |
| Data model | Flow entries: match fields → actions → counters | YANG models (RFC 7950) |
| Key messages | packet-in (miss → controller), flow-mod (install rule), packet-out | get-config, edit-config, commit (candidate datastore, transactional) |
| Transport | TCP/TLS, port 6653 | SSH, port 830 |
| Granularity | Per-flow, reactive or proactive | Per-device, transactional (all-or-nothing) |
| Typical use | Pure SDN fabrics, research, OVS control | Config automation on conventional routers; RESTCONF (RFC 8040) as its REST sibling |
Message level — watch each protocol's actual conversation
One OpenFlow flow entry, anatomicallymatch: in_port=1, eth_type=0x0800, ipv4_dst=10.0.0.2 ← the packet predicate
actions: set_queue:2, output:3 ← what to do with matches
priority: 40000 idle_timeout: 30s counters: pkts/bytes ← arbitration + telemetry
table-miss (no match) → send packet-in to controller — the "reactive" model of Lab 2
Be the ASIC — build a packet, watch the table arbitrate it
Live flow table · highest priority wins, first match executes
| priority | match | actions | counters |
|---|---|---|---|
| 40000 | in_port=1, eth_type=0x0800, ipv4_dst=10.0.0.2 | set_queue:2, output:3 | 0 pkts |
| 30000 | eth_type=0x0806 (any ARP) | FLOOD | 0 pkts |
| 20000 | eth_type=0x0800, ipv4_dst=10.0.0.0/8 | output:2 | 0 pkts |
| 0 | table-miss (matches everything) | CONTROLLER · packet-in | 0 pkts |
[flow table] Build a packet above and send it through the table. Entries are checked highest priority first; the first match executes and stops — exactly how the silicon arbitrates.
The OpenFlow cycle — watch a reactive flow get programmed
packet-in → flow-mod → forward
SWITCH FLOW TABLE
empty — table-miss sends to controller
[OpenFlow] An OpenFlow switch has no routing brain — on a table-miss it asks the controller. Watch the first packet of a flow trigger packet-in → flow-mod, then send the same flow again to see it match locally at line rate.
- SDN Controller — the network operating system: topology service, path computation, device drivers, app platform▶ watch it program a flow ↑
- Southbound — OpenFlow — flow-table programming; packet-in / flow-mod / packet-out cycle▶ read the full message ladder ↑
- Southbound — NETCONF — transactional device configuration against YANG models (candidate → commit, all-or-nothing)▶ watch the transaction ↑
- Northbound APIs — REST/intent interfaces apps call; no single standard, which is why controller choice matters▶ the 3-tier map ↑
2.6
Controllers & Ecosystem
Two open-source controllers dominate the operator space — ONOS and OpenDaylight — under standards bodies (ONF) and model frameworks (TAPI) you must be able to place.
The ecosystem scorecard
| Name | What it is | Signature traits | Where you'll meet it |
|---|---|---|---|
ONOS | Open Network Operating System — carrier-grade SDN controller | Clustered/distributed core for HA · intent framework (say what, it computes how) · CLI + GUI + REST | Lab 2 option A; operator fabrics |
OpenDaylight | Linux Foundation modular controller platform | MD-SAL: everything is a YANG model · huge plugin ecosystem · RESTCONF northbound | Lab 2 option B; vendor products built on it |
ONF | Open Networking Foundation — standards body | Publishes OpenFlow, Stratum/P4 work, TAPI · drove the SDN movement | The org behind the southbound protocol |
TAPI | ONF Transport API | Technology-agnostic YANG API for transport/optical networks: topology, connectivity, path computation | Controller↔orchestrator boundary; used with MEF LSO Presto |
Inside each one — four architectures, fully animated
- ONOS — distributed core, intents, carrier focus; born at ON.Lab, now ONF-hosted▶ watch the cluster fail over ↑
- OpenDaylight — model-driven (YANG/MD-SAL), broadest plugin set, foundation of several commercial controllers▶ follow a model through the SAL ↑
- ONF — the standards home of OpenFlow and TAPI▶ map the ecosystem ↑
- TAPI — the API that lets an orchestrator drive transport controllers without knowing the optical vendor▶ provision a wavelength ↑
i
Intent vs flow — in ONOS you can say
add-host-intent h1 h2 and the controller computes paths, installs flows on every switch, and re-computes on failure. Lab 2 lets you do both levels: raw flows (feel the plumbing) and intents (feel the abstraction). Intent-based networking — say what, not how, then watch it self-heal
ONOS intent framework · one command, whole-fabric flows
INTENT
onos> add-host-intent h1 h2
not submitted
[intent] You don't program switches — you declare a goal: "connect h1 and h2". Submit it and watch ONOS compile the path and install flows on every switch itself. Then cut a link and watch the intent re-compile automatically.
2.7
Benefits & Trade-Offs
SDN's upside is programmability, agility and one policy point. Its costs are engineering problems you must name: controller scale, resiliency, and the migration path.
Benefits
- Programmability — the network becomes an API target; CI/CD for connectivity
- Agility — new services = new controller apps, not new hardware
- Centralized policy — one place to express security/QoS; no config drift
- Global optimization — path computation over the whole graph (traffic engineering)
- Vendor freedom — open southbound → white-box switches
Trade-offs — and their mitigations
- Controller as SPOF — mitigate with clustering (ONOS distributed core; ODL cluster); switches keep forwarding on existing rules if the controller blips ("headless" mode)
- Scaling — reactive packet-in per new flow melts at scale; production designs pre-install proactive rules
- Latency of control — first packet of a reactive flow detours via controller
- Southbound fragmentation — pure OpenFlow fabrics are rare; hybrid NETCONF/BGP designs dominate real WANs
- Operational maturity — debugging a compiled intent needs new skills (hence this course)
The claims lab — don't take the table's word for it, watch each one
- Programmability / agility / central policy — the exam's expected benefit triple▶ prove all three ↑
- Scaling considerations — flow-table size, packet-in rate, controller horizontal scale▶ melt a controller, then fix it ↑
- Resiliency considerations — controller clustering, headless forwarding, state resync on reconnect▶ kill the active controller ↑
LAB
Lab 2 · Program Traffic Flows on an SDN Controller
Goal — experience centralized control of forwarding. First feel the silence of a network with no flows, then bring it alive from the controller — and re-route it with one call. The simulator below is the exact sequence you'll run in Mininet + ONOS/ODL.
SDN flow programmer — live simulator
[00:00] Topology discovered: 4 switches, 2 hosts, 6 links. Flow tables: EMPTY — try ①.
Hands-on · Day 2
Lab activities (the real thing)
⚗- 1Build a Mininet topology:
sudo mn --topo linear,3 --controller=remote,ip=<ctl> --switch ovsk,protocols=OpenFlow13 - 2Connect it to ONOS or OpenDaylight; watch switches register in the GUI
- 3Observe hosts with no flows installed —
h1 ping h2fails (or triggers packet-in) - 4Push flow rules through the controller northbound REST API
- 5Verify connectivity establishment — ping succeeds; inspect
ovs-ofctl -O OpenFlow13 dump-flows s1 - 6Modify the forwarding path centrally (delete + re-post flows, or use an intent)
- 7Confirm the data plane changed: counters shift to the new path's flow entries
Deliverables — controller screenshots · flow definitions (JSON) · demonstration of centralized forwarding control
MininetONOS / OpenDaylightOpen vSwitchWireshark
✓
Pass criteria — ping fails with empty tables; succeeds after your REST call; the path change is visible in flow counters without touching any switch CLI. You have now been the control plane.
Prove it — the Day-2 mastery quiz (100+ questions, every topic)