Theoretical foundations and architecture
Laboratory: an end-to-end operator QoS chain from access to core. A three-tier scheme is built. 1. Ingress PE: customer policing, classification into four classes (voice EF, critical data AF31, video AF41, best effort CS0) and mapping to TC. 2. Core (PE1 and P1 on every output interface): Low Latency Queuing with a priority queue for voice (TC 5), CBWFQ for video and data (TC 4 and 3) and WRED for best effort; a parent shaper on top. 3. Egress PE: Short-Pipe, the queue towards the customer is chosen by the original DSCP. In addition voice is given a DS-TE Class-Type CT1, so the volume of voice is limited already at signaling. The result is verified by measurement: class counters, loss and jitter of the voice class under synthetic congestion (Iperf or TRex) are compared with the SLA targets; zero loss and a specific jitter must be confirmed, not assumed.
What exactly the lab builds
The goal is not a set of commands but a provable end-to-end chain: the customer DSCP on the CE, the TC on the ingress PE1, a queue by TC on every transit interface (PE1, P1) and Short-Pipe on the egress PE2. On top of that DS-TE is added: voice gets its own Class-Type CT1 and a tunnel with reserved bandwidth, so that the volume of voice in the core is limited at the signaling stage and not only in the queue. The result is verified not by the configuration but by measurement: class counters, loss and jitter under congestion.
| Node | Classification | Marking | Queue/limit |
|---|---|---|---|
| PE1 ingress (from CE-A) | By customer DSCP | EF -> TC 5, AF41 -> TC 4, AF31 -> TC 3, the rest -> TC 0 | EF policer 10 Mbit/s |
| PE1 egress (to the core) | By the TC of the top label | Unchanged | LLQ 10% + CBWFQ 20/30% + WRED, parent shaper 100 Mbit/s |
| P1 | By TC | Unchanged | The same classes and shaper on the output to PE2 |
| PE2 egress (to the CE) | By customer DSCP (Short-Pipe) | Unchanged | Priority by DSCP EF |
Capacity plan for one voice class
One G.711 call with two MPLS labels takes about 98 kbit/s on Ethernet (the calculation is in lesson 1). A 10 Mbit/s priority class fits roughly 100 calls; a 20% margin (up to 120 kbit/s per call with link overhead) reduces the number of calls to 83. The queue of the priority class is made small: 10 ms at 10 Mbit/s is 12,500 bytes, or 8 packets of 1500 bytes; a deeper queue turns congestion into jitter. The data class gets bandwidth percent 30 and WRED; Best Effort gets the remainder and the most aggressive WRED curve. The sum of guarantees (10 + 20 + 30) leaves 40% for default: more than 100% of the parent bandwidth cannot be guaranteed.
DS-TE: why a Class-Type is needed
Ordinary RSVP-TE keeps one bandwidth pool per interface: a tunnel with 10 Mbit/s of voice and a tunnel with 100 Mbit/s of bulk compete in the common pool, and nothing guarantees that room is left on a particular link specifically for voice. DS-TE (RFC 3564, the protocol in RFC 4124) introduces the Class-Type (CT0-CT7): independent accounting of reservations per class. A tunnel is signaled with the CLASSTYPE object; the head-end computes the path (CSPF) by the bandwidth of that CT, and the IGP (OSPF-TE/IS-IS-TE) floods the available bandwidth per TE-class. A TE-class is a pair (Class-Type, preemption priority); there are at most eight of them per domain. CT0 is ordinary traffic and compatibility with non-DS-TE nodes; voice is usually CT1.
Bandwidth constraint models: MAM and RDM
Bandwidth Constraints (BC) define how much bandwidth is available to each CT. In MAM (Maximum Allocation Model, RFC 4125) each CT is limited by its own BC independently: CTi <= BCi, and the sum of the BCs does not exceed the maximum reservable bandwidth. MAM isolates classes without preemption, but the unused bandwidth of CT1 remains unavailable to CT0. In RDM (Russian Dolls Model, RFC 4127) the constraints are nested: CT1 <= BC1, CT0 + CT1 <= BC0, where BC0 equals the maximum reservable bandwidth. The unused bandwidth of CT1 is available to CT0, but to protect the nested classes RDM is designed to work with preemption priorities. RFC 4128 compares the models. Example for a 100 Mbit/s link with a reservation maximum of 90: MAM - BC0 = 80, BC1 = 10; RDM - BC0 = 90, BC1 = 10 (if CT1 is not used, CT0 may take 90; if CT1 uses 10, CT0 gets 80).
The CT1, EF and LLQ link
DS-TE is accounting in the control plane: a reservation of 10 Mbit/s limits nothing in the data plane. Therefore three values must match: BC1 on the interface (10 Mbit/s), the rate of the priority queue (LLQ 10%) and the number of calls the SBC allows (CAC). If BC1 is larger than the LLQ, DS-TE will admit more voice than the queue can serve: under congestion the queue policer will cut all calls in the class at once instead of rejecting the extra ones at setup. The head-end must set TC 5 on the traffic going into the tunnel: on Cisco this is the marking policy on the ingress PE1, on Junos it is class-of-service 5 in the LSP parameters (EXP for all packets of the LSP). Only voice must be put into the tunnel: a static route to the subnet of the voice gateways or a policy on ingress; otherwise all traffic to PE2 would go into the 10 Mbit/s tunnel.
Test methodology
A traffic generator is needed: iperf3 or TRex. Voice: UDP of about 8 Mbit/s with DSCP 46 (iperf3 -u -b 8M -S 0xb8), video: UDP 30 Mbit/s with DSCP 34 (-S 0x88), data: TCP/UDP 50 Mbit/s with DSCP 26 (-S 0x68), bulk: 60 Mbit/s with DSCP 0. In total about 150 Mbit/s into a 100 Mbit/s shaper. Order: 1) without load - make sure from the policy counters that the TC is set (the L-VOICE class counts packets); 2) load above the shaper - voice must pass without loss and the other classes must get at least their guarantees; 3) disable the class policy on the PE1 output and repeat: voice loss will appear, which proves that it was the queue that protected the traffic; 4) link failure - the CT1 tunnel is re-signaled or finds no path. For jitter, measure the spread of receive intervals between UDP packets (iperf3 reports Jitter) and look at DSCP/TC in the capture.
Expected numbers
At a load of 8 (voice) + 30 (video) + 50 (data) + 60 (bulk) = 148 Mbit/s into 100 Mbit/s: voice gets its 8 Mbit/s without loss, and the remaining 92 Mbit/s are divided so that video gets at least 20, data at least 30, bulk at least 40 (with a correction of up to 2 Mbit/s for the unused voice bandwidth); the loss is concentrated in bulk. After the policy is disabled, the loss is spread across all classes in proportion to the load (about 32% at 148 into 100), including voice.
Typical failures
LLQ is specified as a percentage of the physical port while the parent shaper has already limited the rate: 10% of 1 Gbit/s (100 Mbit/s) instead of 10% of 100 Mbit/s, and voice displaces everything else. The classes on P1 are defined by match dscp while the packets already carry labels: the queues on the transit do not fire. BC1 is larger than the LLQ: CAC admits more calls than fit in the queue. The CT1 tunnel went down and the static route disappeared: voice went by the IGP path without guarantees. WRED is enabled in the priority class. On the Short-Pipe egress PE2 there is no DSCP policy: voice on the last link falls into Best Effort. The DS-TE reservation is assumed to be perfect although the actual voice exceeds 10 Mbit/s (the number of calls grew without changing CT1).
Architecture Diagram & Topology
+-------------+ Multi-Service Queue Scheduling (PE Interface) +-------------+
| PE-1 | ==========================================================> | P-1 |
| Service | [LLQ Strict Priority: Voice 10% (EXP 5)] | Linecard |
| Policy In | [CBWFQ Guaranteed: Video 20% (EXP 4) + Data 30% (EXP 3)] | WRED Active |
| Policy Out | [Default Fair-Queue: Best Effort 40% (EXP 0) with WRED] | Core Queue |
+-------------+ +-------------+Traffic Flow & Label Stack Scheme
Hardware Linecard Queuing Pipeline:
1. Packet arrives with MPLS TC=5 ---> Directed to Strict Priority LLQ (Serviced first, low latency).
2. Packets with TC=3..4 ---> Serviced via Deficit Weighted Round Robin (DWRR) proportional to allocated bandwidth.
3. Best-Effort (TC=0) ---> Enters default queue governed by Weighted Random Early Detection (WRED).
4. If interface saturates, WRED preemptively drops TCP Best-Effort to prevent global synchronization.