Summary

  • RFC 5160 deliberately confines each provider-to-provider QoS guarantee to one administrative domain; compatible bilateral bindings are components of a path, not an end-to-end performance receipt.
  • The decisive operating record must join the actual forward and reverse routes, per-domain measurements, admission and capacity state, customer entitlement, fault attribution and remedy at the same observation time.

Imagine five providers carrying a latency-sensitive session. Each has a signed agreement with its neighbor. Each can produce evidence that its own local class met the delay, jitter and loss bounds associated with a common Meta-QoS-Class. The application still performs badly. Which agreement failed?

RFC 5160's answer begins by refusing to let any one of those bilateral agreements pretend to cover the other four domains. That is not timidity. It is the document's scalability design.

The promise was cut at the administrative boundary

The rejected model is an end-to-destination service-provider chain. In that model, an upstream provider promises a customer or neighbor a performance level across several downstream networks. When service degrades, the claim travels from legal partner to legal partner until the faulty domain is found, then compensation is meant to travel back. RFC 5160 calls the result a liability chain.

The difficulty is not merely the number of invoices. Internet paths are dynamic, the providers may not know one another, and some are competitors. An upstream provider would be asked to pay for performance it neither controlled nor directly observed. Worse, every renegotiation of a local agreement could disturb many remote promises that silently depended on it. The document names that dependency the SP-chain trap and the resulting inability to change the network “glaciation.”

Its replacement is exact: a provider guarantees only the crossing performance of its own domain to a direct neighbor. Liability is one hop. A change does not require the consent of every distant contract that once used the path. This keeps commercial agency local.

The trade is equally exact. The framework removes the fiction that a bilateral contract owns a remote path. It does not create a new actor who owns the assembled path.

An MQC is a compatibility label, not a path certificate

Inside each domain, the operator may engineer QoS by any method. RFC 5160 abstracts that work as a local QoS class, or l-QC, described by one-way delay, delay variation and loss. A provider binds its l-QC to one in the adjacent downstream domain. It chooses from what it knows about its own class and its neighbor's class; it intentionally ignores conditions more than one domain away.

The Meta-QoS-Class supplies a common vocabulary for that binding. Two local classes may bind only when both conform to the same MQC. The label can state which application family the class suits, performance intervals, traffic constraints and assumptions about resources relative to admitted load. Bandwidth, availability and repair time still need separate agreement terms.

That distinction matters operationally. A common label can show that adjacent capabilities were judged compatible. It cannot show which route carried a packet, whether the agreed capacity was already consumed, whether every later domain remained in the same plane, or whether the sum of local delay and loss still satisfied the customer request.

The framework itself demonstrates the gap. Its example allows domains to add delay values to a propagated path and lets the receiving provider compare the total with a customer's requested limit. That arithmetic depends on the domains actually traversed, the validity window of each contribution and the route selected at that moment. A stale advertisement and a perfect bilateral contract can coexist.

The return path is a second service

Provider agreements in the RFC are directional. A reverse agreement may exist, but it is not implied by the forward one. Inter-domain paths are often asymmetric; a provider visible on the outbound path may be absent on the return path. A voice or interactive session therefore needs two compositions, not one duplicated assumption.

This is where dashboards routinely overstate certainty. “All peers compliant” is a statement about local relationships. “The application had 70 ms in both directions” is a statement about two routed, measured paths under a defined load and time. One cannot be derived from the other without joining route identity, domain sequence, local class, admission state and measurements.

Even route selection can perturb the thing it optimizes. RFC 5160 notes that selecting the apparently best QoS path everywhere may concentrate traffic on it, a QA-rush effect that deteriorates performance. A control-plane choice is therefore neither an outcome nor a durable entitlement.

The evidence object leadership actually needs

An auditable service record should not be one green MQC badge. It should be a time-bounded composition:

  1. the customer's requested service and authorized traffic profile;
  2. the exact forward and reverse routes, including the domains actually traversed;
  3. each bilateral agreement version and its direction;
  4. the effective l-QC-to-l-QC mapping at every border;
  5. admitted volume against separately contracted bandwidth;
  6. per-domain delay, jitter, loss, availability and measurement window;
  7. the rule used to compose those metrics;
  8. the end-to-end observation; and
  9. the fault-localization and remedy record when the result missed the promise.

This record respects RFC 5160's local liability design. It does not turn a distant provider into a party to a contract it never signed. But it gives the provider selling the customer-facing service enough evidence to distinguish three cases: a local breach, a downstream breach, and a path composition that was never justified in the first place.

The final distinction is the most valuable. All providers may have honoured their local limits while the full path still misses the application threshold. That is not automatically fraud or failure. It can be a commissioning error: compatible components were assembled without proving the composite.

Sources