RSVP aggregation further enhances RSVP scalability within an RSVP/DiffServ network as shown in the figure above by allowing
the establishment of aggregate reservations across an aggregation region. This allows for aggregated connection admission
control on core/interior device interfaces. Running RSVP on the core/interior devices allows for more predictable bandwidth
use during normal and failure scenarios.
The voice gateways are running classic RSVP, which means RSVP is keeping a state per flow and also classifying, marking,
and scheduling packets on a per-flow basis. The edge/aggregation devices are running RSVP with scalability enhancements for
admission control on the exterior interfaces connected to the voice gateways and running RSVP aggregation on the interfaces
connected to core/interior devices 1 and 3. The core/interior devices in the RSVP/DiffServ network are running RSVP for the
establishment of the aggregate reservations. The edge and core/interior devices inside the RSVP/DiffServ network also implement
a specific per hop behavior (PHB) for a collection of flows that have the same DSCP.
The voice gateways identify voice data packets and set the appropriate DSCP in their IP headers so that the packets are classified
into the priority class in the edge/aggregation devices and in core/interior devices 1, 2, 3 or 1, 4, 3.
The interior interfaces on the edge/aggregation/deaggregation devices (labeled A and B) connected to core/interior devices
1 and 3 are running RSVP aggregation. They are performing admission control only per flow against the RSVP bandwidth of the
aggregate reservation for the corresponding DSCP.
Admission control is performed at the deaggregator because it is the first edge node to receive the returning E2E RSVP RESV
message. CBWFQ is performing the classification, policing, and scheduling functions on all nodes within the RSVP/DiffServ
network including the edge devices.
Aggregate reservations are dynamically established over an aggregation region when an E2E reservation enters an aggregation
region by crossing from an exterior to an interior interface; for example, when voice gateway C initiates an E2E reservation
to voice gateway D. The aggregation is accomplished by "hiding" the E2E RSVP messages from the RSVP nodes inside the aggregation
region. This is achieved with a new IP protocol, RSVP-E2E-IGNORE, that replaces the standard RSVP protocol in E2E PATH, PATHTEAR,
and RESVCONF messages. This protocol change to RSVP-E2E-IGNORE is performed by the aggregator when the message enters the
aggregation region and later restored back to RSVP by the deaggregator when the message exits the aggregation region. Thus,
the aggregator and deaggregator pairs for a given flow are dynamically discovered during the E2E PATH establishment.
The deaggregator device 2 is responsible for mapping the E2E PATH onto an aggregate reservation per the configured policy.
If an aggregate reservation with the corresponding aggregator device 1 and a DSCP is established, the E2E PATH is forwarded.
Otherwise a new aggregate at the requisite DSCP is established, and then the E2E PATH is forwarded. The establishment of this
new aggregate is for the fixed bandwidth parameters configured at the deaggregator device 2. Aggregate PATH messages are sent
from the aggregator to the deaggregator using RSVP’s normal IP protocol. Aggregate RESV messages are sent back from the deaggregator
to the aggregator, thus establishing an aggregate reservation on behalf of the set of E2E flows that use this aggregator and
deaggregator. All RSVP capable interior nodes process the aggregate reservation request following normal RSVP processing including
any configured local policy.
The RSVP-E2E-IGNORE messages are ignored by the core/interior devices, no E2E reservation states are created, and the message
is forwarded as IP. As a consequence, the previous hop/next hop (PHOP/ NHOP) for each RSVP-E2E-IGNORE message received at
the deaggregator or aggregator is the aggregator or deaggregator node. Therefore, all messages destined to the next or previous
hop (RSVP error messages, for example) do not require the protocol to be changed when they traverse the aggregation region.
By setting up a small number of aggregate reservations on behalf of a large number of E2E flows, the number of states stored
at core/interior devices and the amount of signal processing within the aggregation region is reduced.
In addition, by using differentiated services mechanisms for classification and scheduling of traffic supported by aggregate
reservations rather than performing per aggregate reservation classification and scheduling, the amount of classification
and scheduling state in the aggregation region is further reduced. This reduction is independent of the number of E2E reservations
and the number of aggregate reservations in the aggregation region. One or more RSVP/DiffServ DSCPs are used to identify the
traffic covered by aggregate reservations, and one or more RSVP/DiffServ per hop behaviors (PHBs) are used to offer the required
forwarding treatment to this traffic. There may be more than one aggregate reservation between the same pair of devices, each
representing different classes of traffic and each using a different DSCP and a different PHB.