Course/Day 3/NFV, Telco Cloud & Carrier Ethernet

Day Three · Functions become software, connectivity becomes product

NFV, Telco Cloud & Carrier Ethernet

Explain NFV and Telco Cloud, then differentiate Carrier Ethernet service types and Layer 2 vs Layer 3 connectivity services — down to the CIR/EIR bandwidth profile math.

◎

Day objective — the ETSI NFV/MANO model and cloud-native CNFs on one side; MEF's E-Line/E-LAN/E-Tree/E-Access services, their UNI/ENNI/EVC building blocks and bandwidth profiles on the other. Lab 3 makes you do both.

3.1

NFV Concept — VNFs & CNFs

NFV decouples the network function (routing, firewalling, load-balancing) from the box it ships in. Started by the ETSI NFV ISG (2012, founded by major operators), it turned appliances into deployable software.

Appliance → VNF → CNF — one function, three delivery formsevolution

NFV step (2012+) Telco Cloud step (now)

VNF vs CNF — the differences that matter operationally

Property	VNF	CNF
Packaging	Virtual machine (full guest OS)	Containers (shared kernel, image layers)
Orchestrator	MANO (NFVO+VNFM) over a VIM like OpenStack	Kubernetes (often under MANO as "CISM")
Startup / footprint	Minutes · GBs	Seconds · MBs
Scaling	Scale-up or clone whole VMs	Horizontal pod autoscaling per microservice
Upgrade	Image swap, service-affecting windows	Rolling updates, canary, no downtime by design
Typical examples	vRouter, vFW, vEPC nodes	5G core NFs (AMF/SMF/UPF), cloud-native BNG

See the decoupling happen — one function, three lives

Decoupling functions from hardware — the function becomes a licensed software artifact (image + descriptor); capacity is generic, pooled compute. Deploy = copy + boot; scale = another instance; failure = respawn elsewhere — the hardware is interchangeable ETSI NFV ISG · Oct 2012white paper by 13 operatorsPNF → VNF → CNFship+rack weeks → copy+boot minutes ▶ watch it leave the box ↑
VNFs — VM-packaged functions, the first NFV generation: a full guest OS per instance (the density tax), booted on a hypervisor over a VIM like OpenStack, nursed like pets — with live-migration and HA machinery to keep state alive GBs · boots in minuteshypervisor · KVM/ESXiVIM = OpenStackstrong isolation · own kernelvRouter · vFW · vEPC ▶ compare the stacks layer by layer ↑
CNFs — container/Kubernetes-native functions, the current generation: microservices on a shared kernel (cattle, ~10× density), healed and scaled by the reconciliation loop. Packet-heavy ones (UPF-class) need an engineered data path — SR-IOV/DPDK via a Multus second interface MBs · starts in secondsK8s under MANO = CISM5G core is CNF-first · AMF/SMF/UPFeth0 control · net1 packets ▶ race the two packet paths ↑
Why operators care — the four levers: CapEx→OpEx (COTS pools, not per-function boxes), service velocity (new function = a deploy), vendor decoupling (anyone's function on the same pool), scaling economics (capacity follows demand — both directions). Honest costs: you now operate a cloud, and line rate must be engineered CapEx → OpExweeks → minutes≈10× density (CNF)pay-while-used elasticitymulti-vendor on one pool ▶ spike the load, watch it scale ↑

3.2

ETSI MANO Framework

Software functions need machinery to deploy, connect, scale and heal them. ETSI's NFV reference model names three management blocks — NFVO, VNFM, VIM — collectively "MANO", beside the infrastructure (NFVI) they manage.

ETSI NFV reference model — blocks and reference pointsETSI NFV ISG

MANO-internal reference points MANO ↔ functions/infrastructure

The three MANO blocks — exam-grade one-liners

Block	Manages	Granularity	Open-source example
`NFVO`	End-to-end network services (chains of VNFs) + global resource orchestration	Service	OSM (ETSI), ONAP (LFN)
`VNFM`	Lifecycle of individual VNFs: deploy, configure, scale, heal	Function	OSM generic VNFM, vendor VNFMs
`VIM`	NFVI resources: compute/storage/network allocation, images, quotas	Infrastructure	OpenStack; Kubernetes for containers

Run the machinery — instantiate a network service, then break a VNF and watch MANO heal it

ETSI NFV lifecycle · live sequencer

NS STATE NOT INSTANTIATED VNFs running: 0 / 2

[MANO] Press Instantiate to watch a network-service order walk the reference points: Os-Ma-nfvo → NFVO → Or-Vnfm → VNFM → Vi-Vnfm → VIM → Nf-Vi → NFVI. Then kill a VNF and watch the heal loop.

Inside a VNFD (SOL001 · TOSCA) — the recipe the VNFM readsvdu: image: vrouter-7.2 vcpu: 4 mem: 8Gi ← the VMs/containers to create connection_points: mgmt · data-in · data-out ← CPDs: how it wires to VLs scaling_aspect: add 1× vdu when cpu > 80% (max 5) ← the policy ▲ Scale out uses anti_affinity: replicas on different hosts ← failure-domain placement lifecycle: day-0 bootstrap · day-1 config · day-2 ops ← the ops vocabulary

Exam trap — EM vs VNFM: the Element Manager manages the function's application logic (FCAPS of the vFW itself); the VNFM manages its lifecycle as a workload (instantiate/scale/heal). Package format is SOL004 (CSAR); descriptors SOL001; the APIs you integrate are SOL003 (Or-Vnfm) and SOL005 (Os-Ma-nfvo).

NFV Orchestrator — composes VNFs into network services and arbitrates resources across sites
VNF Manager — the per-function babysitter (lifecycle events, KPI-driven scaling)
VIM — the cloud manager MANO delegates to; one NFVO can drive many VIMs
ETSI NFV reference model — memorize the triangle NFVO→VNFM→VIM and reference points Os-Ma-nfvo, Ve-Vnfm, Nf-ViSOL005 · Os-Ma-nfvoSOL003 · Or-VnfmSOL002 · Ve-VnfmSOL004 · CSAR packageSOL001 · TOSCA VNFDanti-affinity placement

3.3

Telco Cloud & Cloud-Native

"Telco Cloud" = cloud infrastructure engineered for network workloads: predictable latency, packet-pushing performance, distributed edge sites — increasingly Kubernetes-based and cloud-native.

Virtualization vs cloud-native — not the same thing

Aspect	Virtualization (VNF era)	Cloud-native (CNF era)
Unit	VM with guest OS	Container / pod
Design	Lift-and-shift monolith	Microservices, 12-factor, stateless where possible
State	In the VM (pets)	Externalized to data stores (cattle)
Scaling	Manual / VNFM-triggered VM clones	Kubernetes HPA — automatic, per-microservice
Healing	Restart / respawn VM	K8s reconciliation loop restarts pods in seconds
Delivery	Quarterly image releases	CI/CD pipelines, canary + rolling upgrades

Kubernetes in one panel — the parts a network engineer needs

Pod — smallest deployable unit (1+ containers)Deployment — declared replica count, rolling updatesService — stable virtual IP in front of podsNode — worker machine (VM or metal)CNI — the pluggable pod network (Calico, Cilium…)Operator — controller that automates an app's ops knowledge

The core idea is the reconciliation loop: you declare desired state ("6 UPF pods"), Kubernetes relentlessly makes reality match. That loop — not containers per se — is what gives CNFs their healing and scaling behavior. For packet-heavy CNFs, add SR-IOV/DPDK network attachments (via Multus) because the default CNI is built for requests, not line-rate forwarding.

The reconciliation loop, live — kill a UPF pod and time the heal

Kubernetes desired-vs-actual · a CNF under fire

DEPLOYMENT upf desired: 4 actual: 4

[k8s] The deployment declares desired: 4 UPF pods. Kill one and watch the reconciliation loop notice the drift and respawn it — this loop, not containers per se, is what makes CNFs self-healing.

The "telco" in Telco Cloud — placement is a latency decision

Where does the UPF live? · one packet, two placements

[placement] Control NFs (AMF/SMF) tolerate tens of ms → they live central. The UPF is the data path — put it at the far edge and traffic breaks out locally instead of hairpinning through the core. Race the two placements.

Virtualization vs cloud-native — VM-hosted monoliths vs declaratively-managed microservices
Containers — process-level isolation sharing the host kernel; images make functions portable
Kubernetes — the de-facto CNF platform: pods, deployments, services, reconciliationHPA autoscalingCNI + Multus · SR-IOV net1GitOps · desired state in gitUPF at far edge ~1–5 msvDU needs PTP/SyncE + RT kernel
Cloud-native network functions — designed-for-K8s functions (5G core is CNF-first), delivered by CI/CD

3.4

SDN + NFV Integration

NFV creates the functions; SDN steers traffic through them. Together they produce service chains — the programmable data paths beneath every NaaS product in this course.

Service function chaining — SDN steers, NFV processesintegration view

control programming chained data pathInsert/remove a function = a flow-rule change, not a truck roll.

Steer it yourself — send traffic through the chain, then remove a function with one rule change

Service chain · SDN steering over NFV functions

[SFC] The chain is ingress → vRouter → vFirewall → WAN-opt → egress. Send traffic to see it, then remove the firewall — the controller re-steers with one flow-rule change. No truck roll, no recabling.

Programmable forwarding — SDN redirects flows to whichever function instance NFV just spun upSFC encap = NSH · RFC 8300SRv6 chaining · modern altstateful ⇒ flow affinity fwd+revGi-LAN · the classic operator SFCfail-open vs fail-closed
Software-based network functions — NFV supplies elastic capacity; SDN makes it reachable instantly
Together = NaaS engine — order arrives (LSO) → NFVO instantiates functions → SDN wires the chain → service active in minutes

≡

Keep the roles straight for the exam — SDN = where traffic goes (forwarding control). NFV = what processes it (functions as software). MANO = who deploys/heals the functions. LSO (Day 4) = who orders and assures the whole service.

3.5

Carrier Ethernet Service Types

Four service constructs cover every Ethernet WAN sold on Earth. They differ only in the EVC topology — point-to-point, any-to-any, hub-and-spoke — and whether the handoff is to a subscriber or another operator.

E-service explorer — switch the EVC topology

[MEF 6.3] E-Line — point-to-point EVC between two UNIs. Port-based = EPL; VLAN-multiplexed = EVPL. The workhorse: DC interconnect, cloud on-ramps, mobile backhaul.

The four service types (MEF 6.3 subscriber services + E-Access wholesale)

Type	EVC topology	Port-based	VLAN-aware	Signature use case
`E-Line`	Point-to-Point	EPL	EVPL	Site-to-DC, cloud connect
`E-LAN`	Multipoint-to-Multipoint	EP-LAN	EVP-LAN	Any-to-any enterprise WAN
`E-Tree`	Rooted-Multipoint	EP-Tree	EVP-Tree	Hub-and-spoke with leaf isolation
`E-Access`	OVC-based (operator↔operator)	Access EPL	Access EVPL	Wholesale last-mile via ENNI

E-Line — 2 UNIs, one P2P EVC; EPL dedicates the port, EVPL multiplexes by CE-VLAN
E-LAN — any-to-any MP2MP EVC; the provider network emulates one big switch
E-Tree — roots reach everything; leaves reach only roots (topology-enforced isolation)
E-Access — the wholesale building block: an OVC from subscriber UNI to an ENNIMEF 51.1 · + Transit E-Line/E-LANL2CP handling · MEF 45.1 tunnel/peer/discardMTU is an ordered attribute

3.6

Building Blocks — UNI · ENNI · EVC

Every Carrier Ethernet service is assembled from three nouns: the demarcation to the customer (UNI), the demarcation between operators (ENNI), and the connection that links them (EVC/OVC).

One retail service across two operators — all blocks in one pictureMEF 26.2

operator OVC segments the EVC the customer buysOrdering the far-side OVC from Operator B automatically? That's LSO Sonata (Day 4).

Block definitions you must recite

Block	Expansion	Definition	Key attributes
`UNI`	User Network Interface	Demarcation between subscriber and provider responsibility	Speed (10M–100G), CE-VLAN map, bundling, BW profiles
`ENNI`	External Network-Network Interface	Demarcation between two operators composing one service	S-VLAN mapping, OVC endpoints, per-OVC profiles
`EVC`	Ethernet Virtual Connection	Association of 2+ UNIs — frames enter one UNI, may exit only the others in the same EVC	Type (P2P/MP2MP/RMP), CE-VLAN preservation, CoS
`OVC`	Operator Virtual Connection	One operator's segment of an end-to-end service (UNI↔ENNI or ENNI↔ENNI)	The unit E-Access sells and Sonata orders

Ride a frame end-to-end — watch the tags change at every block

One frame · two operators · every demarcation

FRAME [ payload | C-VLAN 100 ] at subscriber site A

[MEF 26.2] Press Ride the frame. Watch the C-VLAN enter at the UNI, get wrapped in an S-VLAN across the ENNI, and unwrap at the far UNI — the tag chip above updates at every block.

UNI — where the customer plugs in; everything the SLA promises is measured here
ENNI — where operators shake hands; makes multi-operator services composableQ-in-Q = 802.1adS-tag 0x88A8 · C-tag 0x8100dual-homed ENNI for resilienceper-OVC CoS + profiles
EVC — the service's connectivity object; its type is the service type of panel 3.5

3.7

Service Attributes & Bandwidth Profile

A MEF service is its attribute list. The one attribute everyone negotiates is the bandwidth profile: CIR/CBS and EIR/EBS, enforced by a two-rate three-color token-bucket meter (MEF 10.4). Run it live below.

Bandwidth-profile meter — two-rate three-color simulator live

CIR — Committed Information Rate 40 Mb/s

EIR — Excess Information Rate 30 Mb/s

Offered load 60 Mb/s

Burst depth — CBS/EBS deep (64 KB)

Traffic shape Meter mode

green (committed, SLA)40 Mb/s

yellow (excess, best-effort)20 Mb/s

red (dropped at ingress)0 Mb/s

Green frames get the SLA (delay/loss/availability). Yellow are delivered only if capacity exists — no SLA. Red never enter the network. CBS/EBS burst depth decides how "spiky" traffic can be and still color green/yellow.

C-bucketfills @ CIR · depth CBS

E-bucketfills @ EIR · depth EBS

green = compliant yellow = excess red = discard

The attribute set (MEF 10.4) — what a service order actually specifies

Attribute	Meaning	Unit / example
`CIR`	Committed Information Rate — SLA-backed throughput	e.g. 100 Mb/s
`CBS`	Committed Burst Size — token depth for green bursts	e.g. 12 KB
`EIR`	Excess Information Rate — permitted best-effort extra	e.g. 50 Mb/s
`EBS`	Excess Burst Size — token depth for yellow bursts	e.g. 12 KB
`CoS`	Class of Service — per-class performance objectives (delay, jitter, loss), marked by PCP/DSCP	e.g. H/M/L classes
Service OAM	CFM connectivity checks (CCM), loss (LM) & delay (DM) measurement per MEG level	IEEE 802.1ag · ITU-T Y.1731

Service OAM, live — heartbeats, L2 ping, and the measurements that prove the SLA

CFM / Y.1731 · MEG level 6 · UNI-to-UNI

MEG STATUS UP · CCM every 1s

[SOAM] The SLA isn't a promise — it's measured. MEPs at each UNI exchange CCM heartbeats (802.1ag); LBM/LBR is Layer-2 ping, LTM the traceroute; DMM/DMR measures FD & IFDV; LMM/SLM measures FLR (Y.1731). Try each.

≡

Where the SLA numbers come from — MEF 23.2 (CoS Implementation Agreement) defines the H / M / L class objectives per Performance Tier (metro → regional → continental → global): FD, IFDV and FLR targets that stretch as distance grows. And at turn-up, operators prove the profile with ITU-T Y.1564 service-activation testing (per-CoS CIR/EIR ramp + SLA validation) — not RFC 2544, which is a lab benchmark.

CIR / CBS — the committed envelope; the meter's green bucket refills at CIR up to CBS deep
EIR / EBS — the excess envelope; deliverable but explicitly SLA-less
Class of Service — multiple CoS names per EVC, each with its own profile + performance tierMEF 23.2 · H/M/L per Performance Tiermetro→regional→continental→globalcolor-aware at ENNI · blind at UNICF=1: green tokens overflow to E-bucketY.1564 turn-up test · not RFC 2544
Service OAM basics — CCM heartbeats detect faults; Y.1731 LM/DM prove the SLA numbers

3.8

Layer 2 vs Layer 3 Services

The last decision of Day 3: should the provider bridge your frames (Ethernet/VPN services) or route your packets (IP-VPN)? The answer decides who runs routing, how multi-site scaling behaves, and what you can control.

Service selection — the decision table Lab 3 asks you to defend

Criterion	Layer 2 service (E-Line/E-LAN/E-Tree)	Layer 3 service (IP-VPN, MEF 61.1)
Provider forwards on	Ethernet frames (MAC/VLAN)	IP packets (routes)
Who runs routing	Subscriber — full control of IGP/BGP across sites	Provider — you exchange routes at the IP UNI
Protocol freedom	Anything over Ethernet (incl. non-IP)	IP only
Multi-site scaling	You manage the any-to-any routing yourself	Provider's backbone does any-to-any natively
Operational burden	Higher (your CE routers, your convergence)	Lower (provider-managed core)
Typical buyer	Network-strong enterprises, DC interconnect, ISPs	Enterprises outsourcing WAN routing
MEF spec	MEF 6.3 service definitions	MEF 61.1 IP service attributes

The duel, animated — same two sites, opposite contracts

Ethernet/VPN services — transparent L2 pipes; the provider never sees your routing decisions
IP-VPN services — routed service; IPVC connects IP UNIs, provider participates in routingMEF 61.1 · IPVC + IP UNIstatic or BGP at the UNIE-LAN reality: MAC-table limits per UNIhybrid: L2 for DCI + L3 for branches
Selection criteria — control vs convenience, protocol needs, in-house routing skill, site count
MEF 3.0 context — both families live in the same NaaS portfolio, both orderable via LSO

Classic exam distractor — "E-LAN is a Layer 3 service because it connects many sites." False: E-LAN is L2 any-to-any. Multipoint ≠ routed. What layer the provider forwards on is the only test.

Decision helper — answer four questions, get a defensible verdict (use it in Lab 3)

L2 or L3? · the Lab-3 justification builder

Non-IP / exotic L2 protocols needed?

In-house routing skill?

How many sites?

What do you value more?

LAB

Lab 3 · Deploy a Network Function and Design a Carrier Ethernet Service

Goal — gain practical NFV experience (a containerized NF you can ping through) and produce a defensible E-LAN design with real bandwidth-profile numbers.

Hands-on · Day 3

Lab activities

⚗

1Deploy a containerized network function: a virtual router (FRR container) or virtual firewall
2Instantiate with Docker / Docker Compose — note how instantiation ≈ what a VNFM automates
3Verify traffic forwarding through the NF (ping across it; watch counters)
4Design an E-LAN service for HQ + Branch 1 + Branch 2 + Branch 3
5Define CIR, EIR and CoS mapping per UNI (defend them with the token-bucket simulator in 3.7)
6Determine and justify suitability of a Layer 2 vs Layer 3 service for this customer (use the 3.8 table)

Deliverables — running containerized NF · Carrier Ethernet service design template · bandwidth-profile spreadsheet

Docker / Docker ComposeFRR / VyOS containersdraw.ioMEF-aligned service templatesLibreOffice Calc

Starter — FRR as a containerized NF (step 1–2)$ docker run -d --name vrouter --privileged \ -v $(pwd)/frr:/etc/frr frrouting/frr:latest $ docker exec -it vrouter vtysh # same CLI as Lab 1 — the function survived losing its box

E-LAN design template — the table you hand in (sample values)

UNI	Speed	CIR	EIR	CoS mapping
HQ	1G	200 Mb/s	100 Mb/s	Voice→H (PCP 5) · Apps→M (PCP 3) · Bulk→L (PCP 1)
Branch 1	100M	50 Mb/s	30 Mb/s	same 3-class map
Branch 2	100M	30 Mb/s	30 Mb/s	same 3-class map
Branch 3	100M	30 Mb/s	20 Mb/s	same 3-class map

✓

Pass criteria — traffic demonstrably transits your container NF; the E-LAN sheet has per-UNI CIR/EIR + CoS with one-line justifications; your L2-vs-L3 verdict cites at least two criteria from the selection table.

Prove it — the Day-3 mastery quiz (100+ questions, every topic)