Summary

  • RFC 3175 let an aggregation region hide end-to-end RSVP messages from interior routers and carry many flows inside a DSCP-associated aggregate reservation. It reduced signalling and state in the core; it did not remove the need to prove each flow's edge mapping and admission.
  • The deaggregator chose the aggregate, returned the selected DSCP in DCLASS, and counted the flow's token bucket against available capacity. The aggregator then marked packets. A reservation block, a DSCP, a successful message and delivered service were different records.
  • Predictive sizing made the aggregate deliberately inexact, while a misdirected RSVP-E2E-IGNORE message could disappear quietly. Safe operation therefore needed receipts from both edges, capacity state, interior treatment and observed traffic—not confidence borrowed from one green aggregate.

The scaling problem lived in every router

RSVP version 1 could describe a reservation for one flow with precision. That precision had a price. Every reservation required messages, computation and memory at each RSVP-capable router along the path. Multiply one flow by the number of flows and then by the routers they crossed, and the core inherited an inventory whose size followed customer demand.

RFC 3175 did not reject per-flow intent. It moved where that intent had to remain visible. Several end-to-end reservations sharing an ingress and an egress could traverse an aggregation region inside one larger reservation. Interior routers could schedule a class rather than keep every member's reservation state. The first edge became the aggregator; the last became the deaggregator. For the same packet journey, the routers between them were deliberately less informed.

This was not a retreat from end-to-end service. It was an attempt to preserve it without requiring the transit core to reproduce the edge's complete customer ledger. The architecture compressed mandatory shared state. It did not authorize the edges to forget which flows consumed the block.

Protocol 134 made ignorance explicit

Ordinary RSVP Path messages use the RSVP IP protocol number and Router Alert so RSVP-aware routers examine them. Aggregation depended on preventing the interior from doing exactly that. When a Path entered the region, the aggregator changed its protocol number to RSVP-E2E-IGNORE. IANA records that function as protocol number 134. Interior routers forwarded it as ordinary traffic instead of creating per-flow RSVP state. The deaggregator restored RSVP when the message left the region.

That rewrite was a bounded instruction: ignore this message here, then recover its end-to-end meaning at the correct edge. It was not a statement that the flow no longer existed. Nor was protocol number 134 a certificate that a deaggregator would be found. RFC 3175 warned that a wrongly configured path could carry the altered message past the intended region, perhaps all the way to a destination that ignored the unfamiliar protocol. The disappearance could be hard to detect.

The lesson is sharper than the mechanism. A core can be designed not to know an object only when another control surface retains custody of it. The aggregator needs evidence that the deaggregator received and understood the hidden message. Silence in the middle is a scaling feature; silence at the exit is a failure.

One DSCP named a class, not a customer promise

Inside the region, one or more DSCPs identified traffic covered by aggregate reservations, and corresponding per-hop behaviours supplied treatment. Many Guaranteed Service reservations might map to one aggregate and another class to a different one. The document left the mapping policy to the network administrator.

It did not leave responsibility ambiguous. The deaggregator made the mapping decision because it first saw the receiver's end-to-end Resv and the requested service information. It returned the chosen DSCP in a DCLASS object. The aggregator recorded that mapping, removed DCLASS before forwarding the Resv upstream, and marked the matching data packets at ingress.

Those steps form a custody chain. A DSCP in a packet proves only the bits observed at that point. A DCLASS object proves that one signalling message carried a selected mapping. Neither proves that the edge classifier matched the right five-tuple, that the aggregate had capacity, that every interior scheduler installed the intended PHB, or that the receiver obtained the requested result. The mark is a coordinate. Authority comes from the local mapping policy; service evidence comes later.

The deaggregator kept the admission ledger

When sufficient bandwidth existed, the deaggregator could send the end-to-end Resv back to the aggregator with DCLASS. It also added the flow's token bucket to its internal account of aggregate use. This was the crucial record hidden by the pleasing simplicity of one large reservation.

An aggregate of 1,000 units did not mean that the next request for 10 units was accepted. The deaggregator had to identify the relevant aggregate, see current committed use, apply policy and decide whether capacity was available. If aggregate Path state existed but Resv state did not, it had to create the reservation. If the block was too small, it had to enlarge it or delay the flow rather than treating the block's existence as admission.

The core's state could therefore be independent of the number of member flows while edge state could not. That asymmetry was the point. Aggregation saved shared machinery by concentrating per-flow accountability where it could be joined to the end-to-end request.

Exact accounting would have destroyed the benefit

The obvious safe size for an aggregate is the sum of all member bandwidth and burst requirements. But resizing the aggregate after every arrival and departure would recreate signalling load in another form. RFC 3175 therefore separated exact member accounting from coarse aggregate provisioning.

It discussed blocks larger than the current sum and policies that changed them infrequently. Historical time-of-day demand and recent trends could inform a prediction. Finer adjustment reduced unused capacity but increased signalling; coarser adjustment reduced churn but increased error and recovery risk. The specification did not define one universal algorithm.

This is not a defect to conceal. Prediction belonged to the operator because traffic, objectives and tolerance for spare capacity were local. But the freedom created an evidence obligation. A forecast is not available bandwidth. A configured block is not admitted use. An admission decision is not the queue's runtime state. And a correctly scheduled packet is not the application's outcome.

Aggregation traded isolation for scale

Individual reservations isolate flows more strictly. Aggregation lets bursts interact inside a common class. RFC 3175 acknowledged that one flow could suffer delay from another and that burst synchronization could occur. It also cited research suggesting favourable mean and tail-delay behaviour under the studied conditions.

Standards text cannot convert that cited evidence into a result for an unnamed network twenty-five years later. The relevant proof would require the implementation, topology, traffic mix, queue configuration, measurement method and observation interval. The historical RFC establishes the trade: fewer state objects in the core in exchange for less individual isolation and more responsibility at the edges.

The same concentration enlarged failure domains. Loss or malicious capture of an aggregate reservation could leave many calls unreserved. Excess reservation could deny resources to others. A faulty classifier could place unrelated packets in the protected class. Compression reduced the number of control objects; it increased the consequence of each object.

Integrity protected messages, not service truth

RFC 3175 preserved RSVP integrity across two different neighbor structures. For the hidden end-to-end exchange, aggregator and deaggregator appeared as logical RSVP neighbors even when interior routers separated them. Aggregate messages inside the region retained hop-by-hop relationships among adjacent nodes.

A valid keyed digest could show that the configured peer produced an unaltered message. It could not show that the mapping policy was correct, the secret was still authorized, capacity was sufficient, marking occurred, the PHB was applied or the application succeeded. Cryptographic acceptance is one receipt in the chain, not the chain itself.

The protocol-number rewrite created an additional risk. An attacker or bad configuration could change the value so later routers ignored signalling, and could even restore it before the endpoint, hiding the interference. The RFC discussed IPsec authentication and recommended limiting rewriting to specific RSVP message types. The warning matters because operational convenience had opened a new authority: the ability to decide which routers were allowed to notice a control message.

Later specifications exposed the first aggregate's limits

RFC 4804 adapted aggregation to MPLS TE and DS-TE tunnels. RFC 4860 later defined generic aggregate reservations because RFC 3175 could not represent multiple aggregates with the same source address, destination address and PHB tuple. RFC 5350 revised Router Alert allocation guidance. The IANA registries still show protocol 134 and the aggregate IPv4/IPv6 C-Types.

These records establish specification history, not deployment history. A registry row does not prove a router implements it. A later extension does not prove operators encountered a particular failure. A current code point does not say whether packets use it. The durable contribution of RFC 3175 is architectural: the Internet could make the core forget per-flow detail only by making edge custody more explicit.

Lu Heng's running-code lens clarifies the bargain. The minimum shared layer should carry only what interoperability requires; discretionary policy should remain local. The reality-layer lens then prevents local policy, registered code point, configured reservation, observed forwarding and economic outcome from being collapsed. Those are later analytical frames, not claims by the RFC's authors, but they reveal why aggregation must compress state without compressing proof.

Sources and limits

The evidence was frozen on 2 October 2026, Asia/Shanghai. It supports RFC 3175's mechanism, IANA allocations and later specification history. It does not prove implementation, adoption, present use, state reduction, traffic volume, performance, a named outage, operator conduct or delivered application quality. Predictive examples remain recommendations, not measurements.