RFC relevance of reservation

As per Relevance of the word reservation, we have this rfc below:

Network Working Group F.
Request for Comments: 3175 C.
Category: Standards Track F. Le
B.
Cisco
September 2001

Aggregation of RSVP for IPv4 and IPv6

Status of this

This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited

Copyright

Copyright (C) The Internet Society (2001). All Rights Reserved

This document describes the use of a single RSVP (
ReSerVation Protocol) reservation to aggregate other
reservations across a transit routing region, in a
conceptually similar to the use of Virtual Paths in an
(Asynchronous Transfer Mode) network. It proposes a way
dynamically create the aggregate reservation, classify the
for which the aggregate reservation applies, determine how
bandwidth is needed to achieve the requirement, and recover
bandwidth when the sub-reservations are no longer required. It
contains recommendations concerning algorithms and policies
predictive reservations

1.

A key problem in the design of RSVP version 1 [RSVP] is, as noted
its applicability statement, that it lacks facilities for
of individual reserved sessions into a common class. The use of
aggregation is recommended in [CSZ], and required for scalability

The problem of aggregation may be addressed in a variety of ways
For example, it may sometimes be sufficient simply to mark
traffic with a suitable DSCP (e.g., EF), thus enabling aggregation
scheduling and classification state. It may also be desirable
install one or more aggregate reservations from ingress to egress

Baker, et al. Standards Track [Page 1]

RFC 3175 RSVP Reservation Aggregation September 2001

an "aggregation region" (defined below) where each
reservation carries similarly marked packets from a large number
flows. This is to provide high levels of assurance that the end-to
end requirements of reserved flows will be met, while at the
time enabling reservation state to be aggregated

Throughout, we will talk about "Aggregator" and "Deaggregator",
referring to the routers at the ingress and egress edges of
aggregation region. Exactly how a router determines whether
should perform the role of aggregator or deaggregator is
below

We will refer to the individual reserved sessions (the sessions
are attempting to aggregate) as "end-to-end" reservations ("E2E"
short), and to their respective Path/Resv messages as E2E Path/
messages. We refer to the the larger reservation (that
represents many E2E reservations) as an "aggregate" reservation,
its respective Path/Resv messages as "aggregate Path/Resv messages".

1.1. Problem Statement: Aggregation Of E2E

The problem of many small reservations has been
discussed, and may be summarized in the observation that
reservation requires a non-trivial amount of message exchange
computation, and memory resources in each router along the way.
would be nice to reduce this to a more manageable level where
load is heaviest and aggregation is possible

Aggregation, however, brings its own challenges. In particular,
reduces the level of isolation between individual flows,
that one flow may suffer delay from the bursts of another
Synchronization of bursts from different flows may occur. However
there is evidence [CSZ] to suggest that aggregation of flows has
negative effect on the mean delay of the flows, and actually leads
a reduction of delay in the "tail" of the delay distribution (e.g.,
99% percentile delay) for the flows. These benefits of
to some extent offset the loss of strict isolation

1.2. Proposed

The solution we propose involves the aggregation of several E2
reservations that cross an "aggregation region" and share
ingress and egress routers into one larger reservation from
to egress. We define an "aggregation region" as a contiguous set
systems capable of performing RSVP aggregation (as defined following
along any possible route through this contiguous set

Baker, et al. Standards Track [Page 2]

RFC 3175 RSVP Reservation Aggregation September 2001

Communication interfaces fall into two categories with respect to
aggregation region; they are "exterior" to an aggregation region,
they are "interior" to it. Routers that have at least one
in the region fall into one of three categories with respect to
given RSVP session; they aggregate, they deaggregate, or they
between an aggregator and a deaggregator

Aggregation depends on being able to hide E2E RSVP messages
RSVP-capable routers inside the aggregation region. To achieve
end, the IP Protocol Number in the E2E reservation's Path, PathTear
and ResvConf messages is changed from RSVP (46) to RSVP-E2E-
(134) upon entering the aggregation region, and restored to RSVP
the deaggregator point. These messages are ignored (no state
stored and the message is forwarded as a normal IP datagram) by
router within the aggregation region whenever they are forwarded
an interior interface. Since the deaggregating router perceives
previous RSVP hop on such messages to be the aggregating router,
and other messages do not require this modification; they are
from RSVP hop to RSVP hop anyway

The token buckets (SENDER_TSPECs and FLOWSPECS) of E2E
are summed into the corresponding information elements in
Path and Resv messages. Aggregate Path messages are sent from
aggregator to the deaggregator(s) using RSVP's normal IP
Number. Aggregate Resv messages are sent back from the
to the aggregator, thus establishing an aggregate reservation
behalf of the set of E2E flows that use this aggregator
deaggregator

Such establishment of a smaller number of aggregate reservations
behalf of a larger number of E2E reservations yields
corresponding reduction in the amount of state to be stored
amount of signalling messages exchanged in the aggregation region

By using Differentiated Services mechanisms for classification
scheduling of traffic supported by aggregate reservations (
than performing per aggregate reservation classification
scheduling), the amount of classification and scheduling state in
aggregation region is even further reduced. It is not
independent of the number of E2E reservations, it is also
of the number of aggregate reservations in the aggregation region
One or more Diff-Serv DSCPs are used to identify traffic covered
aggregate reservations and one or more Diff-Serv PHBs are used
offer the required forwarding treatment to this traffic. There
be more than one aggregate reservation between the same pair
routers, each representing different classes of traffic and
using a different DSCP and a different PHB

Baker, et al. Standards Track [Page 3]

RFC 3175 RSVP Reservation Aggregation September 2001

1.3.

We define an "aggregation region" as a set of RSVP-capable
for which E2E RSVP messages arriving on an exterior interface of
router in the set would traverse one or more interior interfaces (
this and possibly of other routers in the set) before
traversing an exterior interface

Such an E2E RSVP message is said to have crossed the
region

We define the "aggregating" router for this E2E flow as the
router that processes the E2E Path message as it enters
aggregation region (i.e., the one which forwards the message from
exterior interface to an interior interface).

We define the "deaggregating" router for this E2E flow as the
router to process the E2E Path as it leaves the aggregation
(i.e., the one which forwards the message from an interior
to an exterior interface).

We define an "interior" router for this E2E flow as any router in
aggregation region which receives this message on an
interface and forwards it to another interior interface.
routers perform neither aggregation nor deaggregation for this flow

Note that by these definitions a single router with a mix of
and exterior interfaces may have the capability to act as
aggregator on some E2E flows, a deaggregator on other E2E flows,
an interior router on yet other flows

1.4. Detailed Aspects of Proposed

A number of issues jump to mind in considering this model

1.4.1. Traffic Classification Within The Aggregation

One of the reasons that RSVP Version 1 did not identify a way
aggregate sessions was that there was not a clear way to classify
aggregate. With the development of the Differentiated
architecture, this is at least partially resolved; traffic of
particular class can be marked with a given DSCP and so classified
We presume this model

We presume that on each link en route, a queue, WDM color, or
management component is set aside for all aggregated traffic of
same class, and that sufficient bandwidth is made available to

Baker, et al. Standards Track [Page 4]

RFC 3175 RSVP Reservation Aggregation September 2001

the traffic that has been assigned to it. This bandwidth may
adjusted based on the total amount of aggregated reservation
assigned to the same class

There are numerous options for exactly which Diff-serv PHBs might
used for different classes of traffic as it crosses the
region. This is the "service mapping" problem described
[RFC2998], and is applicable to situations broader than
described in this document. Arguments can be made for using
EF or one or more AF PHBs for aggregated traffic. For example,
controlled load requires non-TSpec-conformant (policed) traffic to
forwarded as best effort traffic rather than dropped, it may
appropriate to use an AF class for controlled load, using the
drop preference for non-conformant packets

In conventional (unaggregated) RSVP operation, a session
identified by a destination address and optionally a protocol port
Since data belonging to an aggregated reservation is identified by
DSCP, the session is defined by the destination address and DSCP
For those cases where two DSCPs are used (for conformant and non
conformant packets, as noted above), the session is identified by
DSCP of conformant packets. In general we will talk about
aggregated traffic onto a DSCP (even if a second DSCP may be used
non-conformant traffic).

Whichever PHB or PHBs are used to carry aggregated reservations,
needs to be take in an environment where provisioned Diff-Serv
aggregated RSVP are used in the same network, to ensure that
total admitted load for a single PHB does not exceed the
capacity allocated to that PHB. One solution to this is to
one PHB (or more) strictly for the aggregated reservation
(e.g., AF1 Class) while using other PHBs for provisioned Diff-
(e.g., AF2, AF3 and AF4 Classes).

Inside the aggregation region, some RSVP reservation state
maintained per aggregate reservation, while classification
scheduling state (e.g., DSCPs used for classifying traffic)
maintained on a per aggregate reservation class basis (rather
per aggregate reservation). For example, if Guaranteed
reservations are mapped to the EF DSCP throughout the
region, there may be a reservation for each aggregator/
pair in each router, but only the EF DSCP needs to be inspected
each interior interface, and only a single queue is used for all
traffic

Baker, et al. Standards Track [Page 5]

RFC 3175 RSVP Reservation Aggregation September 2001

1.4.2. Deaggregator

The first question is "How do we determine
Aggregator/Deaggregator pair that are responsible for aggregating
particular E2E flow through the aggregation region?"

Determination of the aggregator is trivial: we know that an E2E
has arrived at an aggregator when its Path message arrives at
router on an exterior interface and must be forwarded on an
interface

Determination of the deaggregator is more involved. If an
routing protocol, such as OSPF or IS-IS, is in use, and if it
been extended to advertise information on Deaggregation roles, it
tell us the set of routers from which the deaggregator will
chosen. In principle, if the aggregator and deaggregator are in
same area, then the identity of the deaggregator could be
from the link state database. However, this approach would not
in multi-area environments or for distance vector protocols

One method for Deaggregator determination is manual configuration
With this method the network operator would configure the
and the Deaggregator with the necessary information

Another method allows automatic Deaggregator determination
corresponding Aggregator notification. When the E2E RSVP
message transits from an interior interface to an exterior interface
the deaggregating router must advise the aggregating router of
correlation between itself and the flow. This has the nice
of not being specific to the routing protocol. It also has
property of automatically adjusting to route changes. For instance
if because of a topology change, another Deaggregator is now on
shortest path, this method will automatically identify the
Deaggregator and swap to it

1.4.3. Mapping E2E Reservations Onto Aggregate

As discussed above, there may be multiple Aggregate
between the same Aggregator/Deaggregator pair. The rules for
E2E reservations onto aggregate reservations are policy
which depend on the network environment and network administrator'
objectives. Such a policy is outside the scope of this
and we simply assume that such a policy is defined by the
administrator. We also assume that such a policy is
accessible to the Aggregators/Deaggregators but the details of
this policy is made accessible to Aggregators/Deaggregators (
Configuration, COPS, LDAP, etc.) is outside the scope of
specification

Baker, et al. Standards Track [Page 6]

RFC 3175 RSVP Reservation Aggregation September 2001

An example of very simple policy would be that all the E2
reservations are mapped onto a single Aggregate Reservation (i.e.,
single DSCP) between a given pair of Aggregator/Deaggregator

Another example of policy, which takes into account the Int-
service type requested by the receiver (and signalled in the E2
Resv), would be where Guaranteed Service E2E reservations are
onto one DSCP in the aggregation region and where Controlled Load E2
reservations are mapped onto another DSCP

A third example of policy would be one where the mapping of E2
reservations onto Aggregate Reservations take into account
Objects (such as information authenticating the end user) which
be included by the sender in the E2E path and/or by the receiver
the E2E Resv

Regardless of the actual policy, a range of options are
for where the decision to map an E2E reservation onto an
reservation is taken and how this decision is communicated
Aggregator and Deaggregator. Both Aggregator and Deaggregator
be assumed to make such a decision independently. However,
would either require definition of additional procedures to
inconsistent mapping decisions (i.e., Aggregator and
decide to map a given E2E reservation onto different
Reservations) or would result in possible undetected misbehavior
the case of inconsistent decisions

For simplicity and reliability, we assign the responsibility of
mapping decision entirely to the Deaggregator. The Aggregator
notified of the selected mapping by the Deaggregator and follows
decision. The Deaggregator was chosen rather than the
because the Deaggregator is the first to have access to all
information required to make such a decision (in particular
of the E2E Resv which indicates the requested Int-Serv service
and includes information signalled by the receiver). This
faster operations such as set-up or size adjustment of an
Reservation in a number of situations resulting in faster E2
reservation establishment

1.4.4. Size of Aggregate

A range of options exist for determining the size of the
reservation, presenting a tradeoff between simplicity
scalability. Simplistically, the size of the aggregate
needs to be greater than or equal to the sum of the bandwidth of
E2E reservations it aggregates, and its burst capacity must
greater than or equal to the sum of their burst capacities. However
if followed religiously, this leads us to change the bandwidth of

Baker, et al. Standards Track [Page 7]

RFC 3175 RSVP Reservation Aggregation September 2001

aggregate reservation each time an underlying E2E
changes, which loses one of the key benefits of aggregation,
reduction of message processing cost in the aggregation region

We assume, therefore, that there is some policy, not defined in
specification (although sample policies are suggested which have
necessary characteristics). This policy maintains the amount
bandwidth required on a given aggregate reservation by taking
of the sum of the bandwidths of its underlying E2E reservations
while endeavoring to change it infrequently. This may require
level of trend analysis. If there is a significant probability
in the next interval of time the current aggregate reservation
be exhausted, the router must predict the necessary bandwidth
request it. If the router has a significant amount of
reserved but has very little probability of using it, the policy
be to predict the amount of bandwidth required and release
excess

This policy is likely to benefit from introduction of some
(i.e., ensure that the trigger condition for aggregate
size increase is sufficiently different from the trigger
for aggregate reservation size decrease) to avoid oscillation
stable conditions

Clearly, the definition and operation of such policies are as
business issues as they are technical, and are out of the scope
this document

1.4.5. E2E Path ADSPEC

As described above, E2E RSVP messages are hidden from the
routers inside the aggregation region. Consequently, the ADSPECs
E2E Path messages are not updated as they travel through
aggregation region. Therefore, the Deaggregator for a flow
responsible for updating the ADSPEC in the corresponding E2E Path
reflect the impact of the aggregation region on the QoS that may
achieved end-to-end. The Deaggregator should update the ADSPEC
the E2E Path as accurately as possible

Since Aggregate Path messages are processed inside the
region, their ADSPEC is updated by Interior routers to reflect
impact of the aggregation region on the QoS that may be
within the interior region. Consequently, the Deaggregator
make use of the information included in the ADSPEC from an
Path where available. The Deaggregator may elect to wait until
information is available before forwarding the E2E Path in order
accurately update its ADSPEC

Baker, et al. Standards Track [Page 8]

RFC 3175 RSVP Reservation Aggregation September 2001

To maximize the information made available to the Deaggregator
whenever the Aggregator signals an Aggregate Path, the
should include an ADSPEC with fragments for all service
supported in the aggregation region (even if the Aggregate
corresponds to an Aggregate Reservation that only supports a
of those service types). Providing this information to
Deaggregator for every possible service type facilitates accurate
timely update of the E2E ADSPEC by the Deaggregator

Depending on the environment and on the policy for mapping E2
reservations onto Aggregate Reservations, to accurately update
E2E Path ADSPEC, the Deaggregator may for example

- update all the E2E Path ADSPEC segments (Default
Parameters Fragment, Guaranteed Service Fragment, Controlled-
Service Fragment) based on the ADSPEC of a single Aggregate Path

- update the E2E Path ADSPEC by taking into account the ADSPEC
multiple Aggregate Path messages (e.g.,. update the
General Parameters Fragment using the "worst" value for
parameter across all the Aggregate Paths' ADSPECs, update
Guaranteed Service Fragment using the Guaranteed Service
from the ADSPEC of the Aggregate Path for the reservation used
Guaranteed Services).

By taking into account the information contained in the ADSPEC
Aggregate Path(s) as mentioned above, the Deaggregator should be
to accurately update the E2E Path ADSPEC in most situations

However, we note that there may be particular situations where
E2E Path ADSPEC update cannot be made entirely accurately by
Deaggregator. This is most likely to happen when the path
across the aggregation region depends on the service requested in
E2E Resv, which is yet to arrive. Such a situation could arise if
for example

- The service mapping policy for the aggregation region is such
E2E reservations requesting Guaranteed Service are mapped to
different PHB that those requesting Controlled Load service

- Diff-Serv aware routing is used in the aggregation region, so
packets with different DSCPs follow different paths (sending
over different MPLS label switched paths, for example).

As a result, the ADSPEC for the aggregate reservation that
guaranteed service may differ from the ADSPEC for the
reservation that supports controlled load

Baker, et al. Standards Track [Page 9]

RFC 3175 RSVP Reservation Aggregation September 2001

Assume that the sender sends an E2E Path with an ADSPEC
segments for both Guaranteed Services and Controlled Load. Then,
the time of updating the E2E ADSPEC, the Deaggregator does not
which service type will actually be requested by the receiver
therefore cannot know which PHB will be used to transport this E2
flow and, in turn, cannot pick the right parameter values to
in when updating the Default General Parameters Fragment.
mentioned above, in this particular case, a conservative
would be to always take into account the worst value for
parameter. Regardless of whether this conservative approach
followed or some simpler approach such as taking into account one
the two Aggregate Path ADSPEC, the E2E Path ADSPEC will be
(over-optimistic or over-pessimistic) for at least one service
actually requested by the destination

Recognizing that entirely accurate update of E2E Path ADSPEC may
be possible in all situations, we recommend that a
approach be taken in such situations (over-pessimistic rather
over-optimistic) and that the E2E Path ADSPEC be corrected as soon
possible. In the example described above, this would mean that
soon as the Deaggregator receives the E2E Resv from the receiver,
Deaggregator should generate another E2E Path with an
updated ADSPEC based on the knowledge of which aggregate
will actually carry the E2E flow

1.4.6. Intra-domain

RSVP directly handles route changes, in that reservations follow
routes that their data follow. This follows from the property
Path messages contain the same IP source and destination address
the data flow for which a reservation is to be established. However
since we are now making aggregate reservations by sending a
message from an aggregating to a deaggregating router, the
(E2E) data packets no longer carry the same IP addresses as
relevant (aggregate) Path message. The issue becomes one of
sure that data packets for reserved flows follow the same path as
Path message that established Path state for the
reservation. Several approaches are viable

First, the data may be tunneled from aggregator to deaggregator
using technologies such as IP-in-IP tunnels, GRE tunnels,
label-switched paths, and so on. These each have
advantages, especially MPLS, which allows traffic engineering.
each also have some cost in link overhead and
complexity

Baker, et al. Standards Track [Page 10]

RFC 3175 RSVP Reservation Aggregation September 2001

If data is not tunneled, then we are depending on a characteristic
IP best metric routing , which is that if the route from A to
includes the path from H to L, and the best metric route was
all along the way, then the best metric route was chosen from H to L
Therefore, an aggregate path message which crosses a given
and deaggregator will of necessity use the best path between them

If this is a single path, the problem is solved. If it is a multi
path route, and the paths are of equal cost, then we are forced
determine, perhaps by measurement, what proportion of the traffic
a given E2E reservation is passing along each of the paths,
assure ourselves of sufficient bandwidth for the present use.
simple, though wasteful, way of doing this is to reserve the
capacity of the aggregate route down each path

For this reason, we believe it is advantageous to use one of
above-mentioned tunneling mechanisms in cases where multiple equal
cost paths may exist

1.4.7. Inter-domain

The case of inter-domain routes differs somewhat from the intra
domain case just described. Specifically, best-path
do not apply, as routing is by a combination of routing policy
shortest AS path rather than simple best metric

In the case of inter-domain routes, data traffic belonging
different E2E sessions (but the same aggregate session) may not
an aggregation region via the same aggregator interface, and/or
not leave via the same deaggregator interface. It is possible
we could identify this occurrence in some central system which
the reservation information for both of the apparent sessions, but
is not clear that we could determine a priori how much traffic
one way or the other apart from measurement

We simply note that this problem can occur and needs to be
for in the implementation. We recommend that each such E2
reservation be summed into its appropriate aggregate reservation
even though this involves over-reservation

1.4.8. Reservations for Multicast

Aggregating reservations for multicast sessions is significantly
complex than for unicast sessions. The first challenge is
construct a multicast tree for distribution of the aggregate
messages which follows the same path as will be followed by the
packets for which the aggregate reservation is to be made. This
complicated by the fact that the path taken by a data packet

Baker, et al. Standards Track [Page 11]

RFC 3175 RSVP Reservation Aggregation September 2001

depend on many factors such as its source address, the choice
shared trees or source-specific trees, and the location of
rendezvous point for the tree

Once the problem of distributing aggregate Path messages is solved
there are considerable problems in determining the correct amount
resources to reserve at each link along the multicast tree.
of the amount of heterogeneity that may exist in an
multicast reservation, it appears that it would be necessary
retain information about individual E2E reservations within
aggregation region to allocate resources correctly. Thus, we may
up with a complex set of procedures for forming
reservations that do not actually reduce the amount of stored
significantly for multicast sessions

As noted above, there are several aspects to RSVP state, and
approach for unicast aggregates all forms of state: classification
scheduling, and reservation state. One possible approach
multicast is to focus only on aggregation of classification
scheduling state, which are arguably the most important because
their impact on the forwarding path. That approach is the
described in the current draft

1.4.9. Multi-level

Ideally, an aggregation scheme should be able to
recursive aggregation, with aggregate reservations being
aggregated. Multi-level aggregation can be accomplished using
procedures described here and a simple extension to the
number swapping process

We can consider E2E RSVP reservations to be at aggregation level 0.
When we aggregate these reservations, we produce reservations
aggregation level 1. In general, level n reservations may
aggregated to form reservations at level n+1.

When an aggregating router receives an E2E Path, it swaps
protocol number from RSVP to RSVP-E2E-IGNORE. In addition, it
write the aggregation level (1, in this case) in the 2 byte
that is present (and currently unused) in the router alert option
In general, a router which aggregates reservations at level n
create reservations at level n+1 will write the number n+1 in
router alert field. A router which deaggregates level n+1
reservations will examine all messages with IP protocol number RSVP
E2E-IGNORE but will process the message and swap the protocol
back to RSVP only in the case where the router alert field
the number n+1. For any other value, the message is
unchanged. Interior routers ignore all messages with IP

Baker, et al. Standards Track [Page 12]

RFC 3175 RSVP Reservation Aggregation September 2001

number RSVP-E2E-IGNORE. Note that only a few bits of the 2
field in the option would be needed, given the likely number
levels of aggregation

For IPv6, certain values of the router alert "value" field
reserved. This specification requires IANA assignment of a
number of consecutive values for the purpose of recording
aggregation level

1.4.10. Reliability

There are a variety of issues that arise in the context
aggregation that would benefit from some form of
acknowledgment mechanism for RSVP messages. For example, it
possible to configure a set of routers such that an E2E Path
protocol type RSVP-E2E-IGNORE would be effectively "black-holed",
it never reached a router which was appropriately configured to
as a deaggregator. It could then travel all the way to
destination where it would probably be ignored due to its non
standard protocol number. This situation is not easy to detect.
aggregator can be sure this problem has not occurred if an
PathErr message is received from the deaggregator (as described
detail below). It can also be sure there is no problem if an E2
Resv is received. However, the fact that neither of these events
happened may only mean that no receiver wishes to reserve
for this session, or that an RSVP message loss occurred, or it
mean that the Path was black-holed. However, if a neighbor-to
neighbor acknowledgment mechanism existed, the aggregator
expect to receive an acknowledgment of the E2E Path from
deaggregator, and would interpret the lack of a response as
indication that a problem of configuration existed. It could
refrain from aggregating this particular session. We note that
a reliability mechanism has been proposed for RSVP in [RFC291]
propose that it be used here

1.4.11. Message Integrity and Node

[RSVP] defines a hop-by-hop authentication and integrity check.
present specification allows use of this check on Aggregate
messages and also preserves this check on E2E RSVP messages for E2
RSVP messages

Outside the Aggregation Region, any E2E RSVP message may contain
INTEGRITY object using a keyed cryptographic digest technique
assumes that RSVP neighbors share a secret. Because E2E
messages are not processed by routers in the Aggregation Region,
Aggregator and Deaggregator appear as logical RSVP neighbors of
other. The Deaggregator is the Aggregator's Next Hop for E2E

Baker, et al. Standards Track [Page 13]

RFC 3175 RSVP Reservation Aggregation September 2001

messages while the Aggregator is the Deaggregator's Previous Hop
Consequently, INTEGRITY objects which may appear in E2E RSVP
traversing the Aggregation Region are exchanged directly between
Aggregator and Deaggregator in a manner which is entirely
to the Interior routers. Thus, hop-by-hop integrity checking for E2
messages over the Aggregation Region requires that the Aggregator
Deaggregator share a secret. Techniques for establishing that
are described in [INTEGRITY].

Inside the Aggregation Region, any Aggregate RSVP message may
an INTEGRITY object which assumes that the corresponding
neighbors inside the Aggregation Region (e.g., Aggregator
Interior Router, two Interior Routers, Interior Router
Deaggregator) share a secret

1.4.12. Aggregated reservations without E2E

Up to this point we have assumed that the aggregate reservation
established as a result of the establishment of E2E reservations
outside the aggregation region. It should be clear that
triggers are possible. As discussed in [RFC2998], an aggregate
reservation can be used to manage bandwidth in a diff-serv cloud
if RSVP is not used end-to-end

The simplest example of an alternative configuration is the
configuration of an aggregated reservation for a certain amount
traffic from an ingress (aggregator) router to an egress (de
aggregator) router. This would have to be configured in at least
system originating the aggregate PATH message (the aggregator).
deaggregator could detect that the PATH message is directed to it
and could be configured to "turn around" such messages, i.e.,
responds with a RESV back to the aggregator. Alternatively
configuration of the aggregate reservation could be performed at
the aggregator and the deaggregator. As before, an
reservation is associated with a DSCP for the traffic that will
the reserved capacity

In the absence of E2E microflow reservations, the aggregator can
a variety of policies to set the DSCP of packets passing into
aggregation region, thus determining whether they gain access to
resources reserved by the aggregate reservation. These policies
a matter of local configuration, as usual for a device at the edge
a diffserv cloud

Baker, et al. Standards Track [Page 14]

RFC 3175 RSVP Reservation Aggregation September 2001

Note that the "aggregator" could even be a device such as a
gateway which makes an aggregate reservation for the set of calls
another PSTN gateway (the deaggregator) across an intervening diff
serv region. In this case the reservation may be established
response to call signalling

From the perspective of RSVP signalling and the handling of
packets in the aggregation region, these cases are equivalent to
case of aggregating E2E RSVP reservations. The only difference
that E2E RSVP signalling does not take place and cannot therefore
used as a trigger, so some additional knowledge is required
setting up the aggregate reservation

2. Elements of

To implement aggregation, we define a number of elements
procedure

2.1. Receipt of E2E Path Message By Aggregating

The very first event is the arrival of the E2E Path message at
exterior interface of an aggregator. Standard RSVP procedures [RSVP
are followed for this, including onto what set of interfaces
message should be forwarded. These interfaces comprise zero or
exterior interfaces and zero or more interior interfaces. (If
number of interior interfaces is zero, the router is not acting as
aggregator for this E2E flow.)

Service on exterior interfaces is handled as defined in [RSVP].

Service on interior interfaces is complicated by the fact that
message needs to be included in some aggregate reservation, but
this point it is not known which one, because the deaggregator is
known. Therefore, the E2E Path message is forwarded on the
interface(s) using the IP Protocol number RSVP-E2E-IGNORE, but
every other respect identically to the way it would be sent by
RSVP router that was not performing aggregation

2.2. Handling Of E2E Path Message By Interior

At this point, the E2E Path message traverses zero or more
routers. Interior routers receive the E2E Path message on
interior interface and forward it on another interior interface.
Router Alert IP Option alerts interior routers to check internally
but they find that the IP Protocol is RSVP-E2E-IGNORE and the
hop interface is interior. As such, they simply forward it as
normal IP datagram

Baker, et al. Standards Track [Page 15]

RFC 3175 RSVP Reservation Aggregation September 2001

2.3. Receipt of E2E Path Message By Deaggregating

The E2E Path message finally arrives at a deaggregating router,
receives it on an interior interface and forwards it on an
interface. Again, the Router Alert IP Option alerts it to
the message, but this time the IP Protocol is RSVP-E2E-IGNORE and
next hop interface is an exterior interface

Before forwarding the E2E Path towards the receiver, the
should update its ADSPEC. This update is to reflect the impact
the aggregation region onto the QoS to be achieved E2E by the flow
Such information can be collected by the ADSPEC of Aggregate
messages travelling from the Aggregator to the Deaggregator. Thus
to enable correct updating of the ADSPEC, a deaggregating router
wait as described below for the arrival of an aggregate Path
forwarding the E2E Path

When receiving the E2E Path, depending on the policy for mapping E2
reservation onto Aggregate Reservations, the Deaggregator may or
not be in a position to decide which DSCP the E2E flow for
processed E2E Path is going to be mapped onto, as described above
If the Deaggregator is in a position to know the mapping at
point, then the Deaggregator first checks that there is an
Path in place for the corresponding DSCP. If so, then
Deaggregator uses the ADSPEC of this Aggregate Path to update
ADSPEC of the E2E Path and then forwards the E2E Path towards
receiver. If not, then the Deaggregator requests establishment
the corresponding Aggregate Path by sending an E2E PathErr
with an error code of NEW-AGGREGATE-NEEDED and the desired
encoded in the DCLASS Object. The Deaggregator may also at the
time request establishment of an aggregate reservation for
DSCPs. When receiving the Aggregate Path for the desired DSCP,
Deaggregator then uses the ADSPEC of this Aggregate Path to
the ADSPEC of the E2E Path

If the Deaggregator is not in a position to know the mapping at
point, then the Deaggregator uses the information contained in
ADSPEC of one Aggregate Path or of multiple Aggregate Paths to
the E2E Path ADSPEC. Similarly, if one or more of the
Aggregate Paths is not yet established, the Deaggregator
establishment of the corresponding Aggregate Path by sending an E2
PathErr message with an error code of NEW-AGGREGATE-NEEDED and
desired DSCP encoded in the respective DCLASS Object. When
the Aggregate Path for the desired DSCP, the Deaggregator then
the ADSPEC of this Aggregate Path to update the ADSPEC of the E2
Path

Baker, et al. Standards Track [Page 16]

RFC 3175 RSVP Reservation Aggregation September 2001

Generating a E2E PathErr message with an error code of NEW
AGGREGATE-NEEDED should not result in any Path state being removed
but should result in the aggregating router initiating the
aggregate Path message, as described in the following section

The deaggregating router changes the E2E Path message's IP
from RSVP-E2E-IGNORE to RSVP and forwards the E2E Path
towards its intended destination

2.4. Initiation of New Aggregate Path Message By Aggregating

The aggregating Router is responsible for generating a new
Path for a DSCP when receiving a E2E PathErr message with the
code NEW-AGGREGATE-NEEDED from the deaggregator. The DSCP value
include in the Aggregate Path Session is found in the DCLASS
of the received E2E PathErr message. The identity of
deaggregator itself is found in the ERROR SPECIFICATION of the E2
PathErr message. The destination address of the aggregate
message is the address of the deaggregating router, and the
is sent with IP protocol number RSVP

Existing RSVP procedures specify that the size of a
established for a flow is set to the minimum of the Path SENDER_
and the Resv FLOW_SPEC. Consequently, the size of an
Reservation cannot be larger than the SENDER_TSPEC included in
Aggregate Path by the Aggregator. To ensure that
Reservations can be sized by the Deaggregator without
limitations, the Aggregating router should always attempt to
in the Aggregate Path a SENDER_TSPEC which is at least as large
the size that would actually be required as determined by
Deaggregator. One method to achieve this is to use a SENDER_
which is obviously larger than the highest load of E2E
that may be supported onto this network. Another method is for
Aggregator to keep track of which flows are mapped onto a DSCP
always add their E2E Path SENDER_TSPEC into the Aggregate
SENDER_TSPEC (and possibly also add some additional bandwidth
anticipation of future E2E reservations).

The aggregating router is notified of the mapping from an E2E flow
a DSCP in two ways. First, when the aggregating router receives
E2E PathErr with error code NEW-AGGREGATE-NEEDED, the Aggregator
notified that the corresponding E2E flow is (at least temporarily
mapped onto a given DSCP. Secondly, when the aggregating
receives an E2E Resv containing a DCLASS Object (as described
below), the Aggregating Router is notified that the corresponding E2
flow is mapped onto a given DSCP

Baker, et al. Standards Track [Page 17]

RFC 3175 RSVP Reservation Aggregation September 2001

2.5. Handling of E2E Resv Message by Deaggregating

Having sent the E2E Path message on toward the destination,
deaggregator must now expect to receive an E2E Resv for the session
On receipt, its responsibility is to ensure that there is
bandwidth reserved within the aggregation region to support the
E2E reservation, and if there is, then to forward the E2E Resv to
aggregating router

The Deaggregating router first makes the final decision of
Aggregate Reservation (and thus which DSCP) this E2E reservation
to be mapped onto. This decision is made according to the
selected by the network administrator as described above

If this final mapping decision is such that the Deaggregator can
make a more accurate update of the E2E Path ADSPEC than done
forwarding the initial E2E Path, the Deaggregator should do so
generate a new E2E Path immediately in order to provide the
ADSPEC information to the receiver as soon as possible. Otherwise
normal Refresh procedures should be followed for the E2E Path

If no Aggregate Reservation currently exists from the
aggregating router with the corresponding DSCP, the
router will establish a new Aggregate Reservation as described in
next section

If the corresponding Aggregate Reservation exists but
insufficient bandwidth reserved to accommodate the new E2
reservation (in addition to all the existing E2E
currently mapped onto it), it should follow the normal
procedures [RSVP] for a reservation being placed with
bandwidth to support the reservation. It may also first attempt
increase the aggregate reservation that is supplying bandwidth
increasing the size of the FLOW_SPEC that it includes in
aggregate Resv that it sends upstream. As discussed in the
section, the Aggregating Router should ensure that the SENDER_
it includes in the Aggregate Path is always in excess of
FLOW_SPEC that may be requested in the Aggregate Resv by
Deaggregator, so that the Deaggregator is not unnecessarily
from effectively increasing the Aggregate Reservation bandwidth
required

When sufficient bandwidth is available on the corresponding
reservation, the Deaggregating Router may simply send the E2E
message with IP Protocol RSVP to the aggregating router.
message should include the DCLASS object to indicate which DSCP
aggregator must use for this E2E flow. The deaggregator will

Baker, et al. Standards Track [Page 18]

RFC 3175 RSVP Reservation Aggregation September 2001

add the token bucket from the E2E Resv FLOWSPEC object into
internal understanding of how much of the Aggregate reservation is
use

As discussed above, in order to minimize the occurrence of
where insufficient bandwidth is reserved on the
Aggregate Reservation at the time of processing an E2E Resv, and
turn to avoid the delay associated with the increase of
aggregate bandwidth, the Deaggregator MAY anticipate the
demand and increase the Aggregate Reservations size ahead of
requirements by E2E reservations

2.6. Initiation of New Aggregate Resv Message By Deaggregating

Upon receiving an E2E Resv message on an exterior interface,
having determined the appropriate DSCP for the session according
the mapping policy, the Deaggregator looks for the corresponding
state for a session with the chosen DSCP. If aggregate Path
exists, but no aggregate Resv state exists, the Deaggregator
a new aggregate Resv

If no aggregate Path state exists for the appropriate DSCP, this
be because the Deaggregator could not decide earlier the
mapping for this E2E flow and elected to not establish Aggregate
state for all DSCPs. In that case, the Deaggregator should
establishment of the corresponding Aggregate Path by sending a E2
PathErr with error code of NEW-AGGREGATE-NEEDED and with a
containing the required DSCP. This will trigger the Aggregator
establish the corresponding Aggregate Path. Once the
has determined that the aggregate Path state is established,
creates a new Aggregate Resv

The FLOW_SPEC of the new Aggregate Resv is set to a value not
than the requirement of the E2E reservation it is supporting.
Aggregate Resv is sent toward the aggregator (i.e., to the
hop), using the AGGREGATED-RSVP session and filter
defined below. Since the DSCP is in the SESSION object, no
object is necessary. The message should be reliably delivered
the mechanisms in [RFC2961] or, alternatively, the CONFIRM object
be used, to assure that the aggregate Resv does indeed arrive and
granted. This enables the deaggregator to determine that
requested bandwidth is available to allocate to the E2E flows
supports

In order to minimize the occurrence of situations where
corresponding Aggregate Reservation is established at the time
processing an E2E Resv, and in turn to avoid the delay
with the creation of this aggregate reservation, the Deaggregator

Baker, et al. Standards Track [Page 19]

RFC 3175 RSVP Reservation Aggregation September 2001

anticipate the current demand and create the Aggregate
before receiving E2E Resv messages requiring bandwidth on
aggregate reservations

2.7. Handling of Aggregate Resv Message by Interior

The aggregate Resv message is handled in essentially the same way
defined in [RSVP]. The Session object contains the address of
deaggregating router (or the group address for the session in
case of multicast) and the DSCP that has been chosen for the session
The Filterspec object identifies the aggregating router.
routers perform admission control and resource allocation as
and send the aggregate Resv on towards the aggregator

2.8. Handling of E2E Resv Message by Aggregating

The receipt of the E2E Resv message with a DCLASS Object is the
confirmation to the aggregating router of the mapping of the E2
reservation onto an Aggregate Reservation. Under
circumstances, this is the only way it will be informed of
association. It should now forward the E2E Resv to its previous hop
following normal RSVP processing rules [RSVP].

2.9. Removal of E2E

E2E reservations are removed in the usual way via PathTear, ResvTear
timeout, or as the result of an error condition. When they
removed, their FLOWSPEC information must also be removed from
allocated portion of the aggregate reservation. This same
may be re-used for other traffic in the near future. When E2E
messages are removed, their SENDER_TSPEC information must also
removed from the aggregate Path

2.10. Removal of Aggregate

Should an aggregate reservation go away (presumably due to
configuration change, route change, or policy event), the E2
reservations it supports are no longer active. They must be
accordingly

2.11. Handling of Data On Reserved E2E Flow by Aggregating

Prior to establishment that a given E2E flow is part of a
aggregate, the flow's data should be treated as traffic without
reservation by whatever policies prevail for such. Generally,
will mean being given the same forwarding behavior as best
traffic. However, upon establishing that the flow belongs to a
aggregate, the aggregating router is responsible for marking

Baker, et al. Standards Track [Page 20]

RFC 3175 RSVP Reservation Aggregation September 2001

related traffic with the correct DSCP and forwarding it in the
appropriate to traffic on that reservation. This may
forwarding it to a given IP next hop, or piping it down a given
layer circuit, tunnel, or MPLS label switched path

The aggregator is responsible for performing per-reservation
on the E2E flows that it is aggregating. The aggregator
metering of traffic belonging to each reservation to
compliance to the token bucket for the corresponding E2E reservation
Packets which are assessed in compliance are forwarded as
above. Packets which are assessed out of compliance must be
dropped, reshaped or marked to a different DSCP. The
policing behavior is an aspect of the service mapping described
[RFC2998].

2.12. Procedures for Multicast

Because of the difficulties of aggregating multicast
described above, we focus on the aggregation of scheduling
classification state in the multicast case. The main
between the multicast and unicast cases is that rather than
an aggregate Path message to the unicast address of a
deaggregating router, in the multicast case we send the "aggregate
Path message to the same group address as the E2E session.
ensures that the aggregate Path message follows the same route as
E2E Path. This difference between unicast and multicast is
in the Session objects defined below. A consequence of this
is that we continue to have reservation state per multicast
inside the aggregation region

A further challenge arises in multicast sessions with
receivers. Consider an interior router which must forward
for a multicast session on two interfaces, but has only received
reservation request on one of those interfaces. It receives
marked with the DSCP chosen for the aggregate reservation.
sending them out the interface which has no installed reservation,
has the following options

a) remark those packets to best effort before sending them out
interface

b) send the packets out the interface with the DSCP chosen for
aggregate reservation

The first approach suffers from the drawback that it requires
classification at an interior router in order to recognize the
whose packets must be demoted. The second approach requires over
reservation of resources on the interface on which no reservation

Baker, et al. Standards Track [Page 21]

RFC 3175 RSVP Reservation Aggregation September 2001

received. In the absence of such over-reservation, the packets
with the "wrong" DSCP would be able to degrade the
experienced by packets using that DSCP legitimately

To make MF classification acceptable in an interior router, it may
possible to treat the case of heterogeneous flows as an exception
That is, an interior router only needs to be able to recognize
individual microflows that have heterogeneous resource needs on
outbound interfaces of this router

3. Protocol

3.1. IP Protocol RSVP-E2E-

This specification requires the assignment of a