Summary

  • RFC 5127 defines a treatment aggregate as several Diffserv service classes sharing one forwarding treatment, possibly while retaining several DSCP values.
  • Sharing a treatment does not merge the end-to-end performance requirements attached to the member classes.
  • The aggregate must meet the strictest loss, delay and jitter requirements among its members.
  • Member classes should have similar traffic characteristics and performance needs; a convenient mapping is not sufficient evidence of compatibility.
  • The identity of each original end-to-end service class must survive aggregation so another domain can make a different, informed mapping.
  • The preferred design classifies original DSCP values into a common queue without rewriting them; a locally rewritten mark must be restored at domain exit.
  • Each member service class still needs its own conditioning or admission control, even when the aggregate also receives policing on the sum.
  • The RFC's four treatment aggregates are an example, not a required minimum, maximum or proof of capacity.
  • Safe aggregation depends on link speed, utilization, queue depth, scheduler behavior, packet-size mix and transmit-rate mix.
  • A Real-Time aggregate assumes bounded admission at the edge; its queue name does not create that bound.
  • MPLS Traffic Class values and LSP selection are domain-local mappings, not portable evidence of observed per-hop behavior.
  • Leaders should keep service identity, entitlement, meter result, aggregate budget, installed queue, boundary restoration, measured performance and application outcome as separate receipts.

The queue count fell; the obligation count did not

Picture five streams reaching a backbone router: telephony, signaling, interactive video, broadcast video and a real-time control application. Their DSCP values are different because their tolerances are not identical. The operator nevertheless directs them into one Real-Time queue. One scheduler, one resource pool and one forwarding treatment now replace several physical queues.

That is the economy RFC 5127 describes. In a high-capacity network, maintaining every application-facing service class as a separate core treatment may add complexity without improving results. If several classes have compatible traffic patterns and performance requirements, one treatment can serve them. The move can be sensible. It is not semantic erasure.

The RFC makes the boundary unusually explicit. A treatment aggregate may carry traffic marked with multiple DSCPs. It differs from a behavior aggregate in which traffic shares one codepoint and one per-hop behavior. The aggregate is about how a segment forwards packets. The service class remains the end-to-end expression of what the application needs.

This distinction is the article's control surface. A diagram that collapses five service classes into one queue has simplified implementation. It has not proved that every member was admitted correctly, that the queue received enough resources, that its scheduler was installed as planned, that another domain preserved the class identity, or that a real application stayed inside its loss, delay and jitter budget.

The strictest member sets the floor

RFC 5127 requires the treatment aggregate to meet the strictest requirements of its member service classes. That rule prevents a dangerous averaging exercise. If one member tolerates moderate loss and another needs very low loss, the operator cannot average the two into a comfortable middle and claim both promises survived.

The strictest-member rule is not itself a capacity calculation. It says what the aggregate must be engineered to satisfy. It does not specify current demand, queue memory, scheduling weights, link utilization or failover load. Those facts must come from the network being operated.

The RFC therefore adds another constraint: classes grouped together should have similar traffic characteristics and performance requirements. Similarity has at least two dimensions. The applications may ask for comparable loss, delay and jitter. Their traffic may also arrive with comparable packet sizes, burst patterns and rates. A low-rate signaling stream and a high-rate video stream can share a latency objective while placing very different pressure on a queue.

This is why a taxonomy table cannot approve an aggregate by itself. The table proposes compatibility. Admission data, traffic measurement and scheduler tests decide whether the proposal survives contact with running traffic.

Identity must cross the compression boundary

The most important requirement in RFC 5127 is not the example of four aggregates. It is the instruction that individual end-to-end service classes must not be destroyed by aggregation. Each downstream domain may aggregate differently. It can do so only if the original class identity remains available.

The recommended method is plain: retain each original DSCP and use a classifier to direct several values into one queue. The common queue does not require a common mark. This gives the next domain enough information to separate the classes again, place them into a different aggregate, reject an unsupported class or apply a distinct contract.

Some domains use local markings. That creates a custody problem. RFC 5127 says the original end-to-end indication must be restored when traffic leaves such a domain. A tunnel is one possible way to preserve the outer and inner meanings. But the existence of a tunnel proves only that a custody mechanism was available. Operators still need the ingress mark, local mark, encapsulation state, decapsulation result and restored egress mark.

If restoration fails, the packet may remain perfectly deliverable while the next domain sees the wrong service identity. That is a silent failure: transport continues, yet policy portability has been lost. A packet capture at only the final hop cannot identify where the meaning changed.

Admission remains per class

Every treatment aggregate has finite resources. RFC 5127 consequently recommends conditioning or admission control for each service class before aggregation. It also permits additional policing on the aggregate total.

Those controls answer different questions. The per-class meter asks whether one member stayed inside its own envelope. Aggregate policing asks whether the combined load stayed within the shared resource budget. Passing the second test does not prove the first. A video class can consume more than its agreement while the total remains below the queue ceiling because another class is quiet. The queue may look healthy while the commercial or operational allocation has already been violated.

The reverse can also happen. Every member may remain inside its individual allowance, yet simultaneous peaks exceed the aggregate capacity. If the shared budget was built from average demand without accounting for correlated bursts, no individual offender exists. The aggregate model failed.

Historical traffic patterns can inform sizing, but the RFC warns through its examples that predictability differs. A point-to-point pseudowire may have a stable pattern; a multipoint VPLS can be more variable. History is planning evidence, not future admission. The more members share one failure domain, the more the operator must examine correlation rather than only individual averages.

Four aggregates were an example, not a constitution

RFC 5127 illustrates Network Control, Real-Time, Assured Elastic and Elastic aggregates. The paper explicitly says a domain may use more or fewer, support only a subset of the listed service classes, or handle unsupported classes according to local policy. Four is neither a minimum nor a maximum.

That matters because examples acquire symbolic authority. A vendor interface can display four colored bands, an audit can count them, and a procurement document can require them. None of those observations proves that the four-way map fits the network's traffic mix or resources.

Network Control protects traffic needed for network survival during a high-load event. The RFC also separates customer control traffic from a provider's own control traffic; a provider may treat its internal control plane differently. A single label called “control” would hide whose control is being protected and under which resource budget.

The Real-Time aggregate groups telephony, signaling, multimedia conferencing, real-time interactive traffic and broadcast video in the example. Its predictability depends on prior admission at the edge and enforceable bounds. Without those receipts, an EF-like queue is only an installed treatment, not a guarantee that admission assumptions held.

Assured Elastic traffic preserves multiple drop precedences. Elastic traffic may separate Default/CS0 from CS1 so lower-priority data drops earlier. One physical queue can therefore contain differentiated discard behavior. “Same queue” is not “same probability of survival.”

Faster links buy options, not proof

The degree of safe aggregation depends on link speed, queue depth, scheduler behavior, utilization, packet-size mix and transmit rates. RFC 5127 offers a rule of thumb: higher link speeds can permit more aggregation, assuming utilization remains within the engineered level.

The condition is essential. Link speed is a capability measure. It does not show current headroom after rerouting, failure protection, denial-of-service load or a burst of admitted sessions. A tenfold faster interface can still have a shorter usable margin if traffic and queue policy changed with it.

Queue depth also cuts both ways. More space can reduce drops during a burst but increase waiting time. A strict latency member may prefer visible loss to long delay. Scheduler configuration can protect one class or create head-of-line interference. Packet sizes change serialization delay and the way bursts occupy the queue. None of these variables can be inferred from the DSCP alone.

Operations therefore need measurements under the scenarios that matter: normal load, correlated peaks, reroute after a major link failure, scheduler reconfiguration and restoration after local remarking. A clean configuration snapshot is necessary but not sufficient.

A provider boundary is a new decision point

At inter-provider boundaries, RFC 5127 recommends basing the relationship on service classes rather than on a provider's internal treatment aggregates. The reason is structural. Two providers may use different numbers of queues and different mappings while still exchanging traffic for the same end-to-end class.

The durable interface is the service identity plus the agreement governing it. Provider A's Real-Time aggregate is not an instruction to Provider B to build the same queue. Provider B must map the received class into its own resource and policy model.

That autonomy prevents one local architecture from becoming an accidental global mandate. It also creates an evidence obligation. The handoff should record which classes are accepted, how marks are interpreted, what happens to unsupported traffic, what admission assumptions travel with the class, and what measurement demonstrates the receiving treatment.

A packet retaining EF at both edges proves mark continuity at those points. It does not prove an EF PHB at every hop, capacity admission in both domains or the application's end-to-end delay. The SLA and measurement trail must close that gap.

MPLS changes the carrier, not the burden of proof

The RFC's appendix shows how E-LSP Traffic Class values can realize the four treatment aggregates. The field was called EXP in the older documents; RFC 5462 later renamed it Traffic Class. The name change does not produce an operational receipt.

Each MPLS domain controls its own Traffic Class allocation. The same three bits can therefore participate in different local mappings. An E-LSP can infer a PHB Scheduling Class from the Traffic Class field, while an L-LSP carries one scheduling class per label-switched path. In the latter case, each treatment aggregate becomes a per-LSP decision.

The label, Traffic Class value and LSP selection establish carriage metadata. The installed classifier and scheduler establish configured treatment. Queue telemetry and packet measurement establish observed behavior. End-to-end application probes establish whether the service objective was met. Those layers should not be compressed merely because the packet crossed an MPLS core.

RFC 5127's example also exposes a sharp low-priority risk: CS1 can be starved under congestion in the shown Elastic mapping. That may be an intentional policy. It must still be observed and bounded. “Lower priority” is not a numeric promise about how much traffic survives or how long starvation lasts.

What the record proves

The RFC Editor and Datatracker records prove publication identity and Informational status. The IANA registry proves codepoint allocation. RFC 2474 and RFC 2475 define the DS field and Diffserv architecture; RFC 2597 defines Assured Forwarding; RFC 3246 and RFC 3247 bound Expedited Forwarding behavior and configuration; RFC 3270 supplies the MPLS mapping context; RFC 4594 supplies service-class guidance. Later RFC 5865 and RFC 8100 show that class and interconnection work continued.

None of those records proves that a named provider implements RFC 5127, uses four aggregates, restores every mark, preserves all admission assumptions, prevents starvation or meets a current SLA. The evidence packet contains no live deployment census, packet trace, incident or measured customer result. This article therefore reports a standards mechanism and its accountability boundary, not a present product claim.

Sources