One document matched: draft-baker-rsvp-aggregation-00.txt
Draft RSVP Reservation Aggregation February 1999
Aggregation of RSVP for IP4 and IP6 Reservations
draft-baker-rsvp-aggregation-00.txt
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC 2026. Internet Drafts are
working documents of the Internet Engineering Task Force
(IETF), its Areas, and its Working Groups. Note that other
groups may also distribute working documents as Internet
Drafts.
Internet Drafts are valid for a maximum of six months and may
be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet Drafts as reference
material or to cite them other than as a "work in progress".
Comments should be made to the authors and the rsvp@isi.edu
list.
Abstract
A key problem in the design of RSVP version 1 is, as noted in
its applicability statement, that it lacks facilities for
aggregation of individual reserved sessions into a common
class. The use of such aggregation is recommended in the paper
by Clark, Shenker, and Zhang in SIGCOMM '92, and required for
scalability.
This document describes the use of a single RSVP reservation
to aggregate other RSVP reservations across a transit routing
region, in a manner conceptually similar to the use of Virtual
Paths in an ATM network. It proposes a way to dynamically
create the aggregate reservation, classify the traffic for
which the aggregate reservation applies, determine how much
bandwidth is needed to achieve the requirement, and recover
the bandwidth when the sub-reservations are no longer
required. It also contains recommendations concerning
algorithms and policies for predictive reservations.
Baker et al Expiration: August 1999 [Page 1]
Draft RSVP Reservation Aggregation February 1999
1. Introduction
A key problem in the design of RSVP version 1 is, as noted in
its applicability statement, that it lacks facilities for
aggregation of individual reserved sessions into a common
class. The use of such 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 reserved traffic with a suitable DSCP (e.g. EF). It may
be desirable to install one or more aggregate reservations
from ingress to egress of an "aggregation region" (defined
below) where each aggregate reservation carries similarly
marked packets from a large number of flows. This is to
provide high levels of assurance that the end-to-end
requirements of reserved flows will be met.
Throughout, we will talk about "Aggregator" and
"Deaggregator", referring to the routers at the ingress and
egress edges of an aggregation region.
1.1. Problem Statement: Aggregation Of Small Reservations
The problem of many small reservations has been extensively
discussed, and may be summarized in the observation that each
reservation requires a non-trivial amount of message exchange,
computation, and memory resources in each router along the
way. It would be nice to reduce this to a more manageable
level where the load is heaviest and aggregation is possible.
Aggregation, however, brings its own challenges. In
particular, it reduces the level of isolation between
individual flows, implying 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 no negative effect on
the mean delay of the flows, and actually leads to a reduction
of delay in the "tail" of the delay distribution (e.g. 99%
percentile delay) for the flows. These benefits of aggregation
to some extent offset the loss of strict isolation.
Baker et al Expiration: August 1999 [Page 2]
Draft RSVP Reservation Aggregation February 1999
1.2. Proposed Solution
The solution we propose involves the aggregation of several
individual reservations that cross an "aggregation region" and
share common ingress and egress routers into one larger
reservation from ingress to egress. We define an "aggregation
region" as a contiguous set of systems capable of performing
RSVP aggregation (as defined following) along any possible
route through this contiguous set.
Communication interfaces fall into two categories with respect
to an aggregation region; they are "exterior" to an
aggregation region, or they are "interior" to it. Routers that
have at least one interface in the region fall into three
categories with respect to a given RSVP session; they
aggregate, they deaggregate, or they are between an aggregator
and a deaggregator.
In this case, the IP Protocol Number in the individual
reservation's PATH and PATH-TEAR messages is changed from RSVP
to AGGREGATED-RSVP within the aggregation region, and restored
to RSVP at the deaggregator point. These messages are ignored
(no state is stored and the message is forwarded as a normal
IP datagram) by each router within the aggregation region
whenever a reservation follows an interior interface. Since
the deaggregating router perceives the previous hop on such
messages to be in aggregating router, other RESV and other
messages do not require this modification; they are unicast
from system to system anyway.
The token buckets (SENDER_TSPECs and FLOWSPECS) of these
reservations are, however, summed into the corresponding
information elements in aggregate PATH and RESV messages.
These PATH messages are sent from the aggregator to the
deaggregator(s) using RSVP's normal IP Protocol Number. The
RESV messages are sent back from the deaggregator to the
aggregator, thus establishing an aggregate reservation on
behalf of the set of individual flows that use this aggregator
and deaggregator. There may be several such reservations
between the same two routers, representing different classes
of traffic; the reservation is therefore for the traffic
marked with a particular DSCP Group.
Baker et al Expiration: August 1999 [Page 3]
Draft RSVP Reservation Aggregation February 1999
1.3. Definitions
We define an "aggregation region" as a set of RSVP-capable
routers for which normal RSVP messages arriving on an outside
interface of one router would in the set would traverse one or
more inside interfaces (of this and/or other routers in the
set) before finally traversing an outside interface.
Such an RSVP message is said to have crossed the aggreagation
region.
We define the "ingress" router for this flow as the first
router (the one which forwards the message from an ouside
interface to an inside interface). The ingress router
performs aggregation for this flow.
We define the "egress" router for this flow as the last router
(the one which forwards the message from an inside interface
to an outside interface). The egress router performs
deaggregation for this flow.
We define an "interior" router for this flow as any router in
the aggregation region which receives this message on an
inside interface and forwards it to another inside interface.
Interior routers neither perform aggregation nor deaggregation
for this flow.
1.4. Detailed Aspects of Proposed Solution
A number of issues jump to mind in considering this model.
1.4.1. Traffic Classification Within The Aggregation region
One of the reasons that RSVP Version 1 did not identify a way
to aggregate sessions was that there was not a clear way to
classify the aggregate. With the development of the
Differentiated Services architecture, this is at least
partially resolved; traffic of a 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
similar management component is set aside for all aggregated
traffic of the same class, and that sufficient bandwidth is
made available to carry the traffic that has been assigned to
Baker et al Expiration: August 1999 [Page 4]
Draft RSVP Reservation Aggregation February 1999
it. This bandwidth may be adjusted based on the total amount
of aggregated reservation traffic assigned to the same class.
Since the total offered load of reserved traffic is known
based on the Tspecs and Rspecs of the aggregated reservations,
it is reasonable to use the Expedited Forwarding PHB [EF] for
the aggregate reservations, or two similar local PHBs with
differing code points, prioritizing CBR voice over VBR video.
However, it may also be desirable to use one or more of the AF
classes for aggregated reservations. This allows non-
conformant traffic to be nevertheless forwarded as part of the
aggregate reservation, but with lower drop precedence.
Independent of which PHB is used, care needs to be take in an
environment where provisioned Diff-Serv and aggregated RSVP
are used in the same network, to ensure that the total offered
load for a single PHB is not excessive relative to the link
capacity allocated to that PHB. One solution to this is to
reserve one of the four AF classes strictly for the aggregated
reservation traffic while using other AF classes for
provisioned Diff-Serv.
Therefore, while a RSVP state per aggregate reservation is
maintained inside the aggregation region, a single
classification and scheduling state (e.g., a DSCP used for
classifying traffic) is maintained per aggregation reservation
class (rather than per aggregate reservation) inside the
aggregation region. For example, if "cbr-voice" service is
represented by the EF DSCP throughout the aggregation region,
there may be a reservation for each aggregator/deaggregator
pair in each router, but only the EF DSCP need be inspected at
each interior interface.
1.4.2. Deaggregator Determination
The first question is "How do we know which aggregate
reservation a particular flow should aggregate into?" To know
that, we must know three items of information: its aggregating
router, its deaggregating router, and (assuming DSCPs are used
to differentiate among various reservations between the same
two routers), the relevant DSCP.
The aggregator is trivial: we know that a flow reservation has
arrived at an aggregator when its PATH message arrives at a
so-configured system from another region. The DSCP is equally
easy, or at least it is in concept. Whatever policy would set
the DSCP in so doing selects the DSCP for the aggregate
Baker et al Expiration: August 1999 [Page 5]
Draft RSVP Reservation Aggregation February 1999
reservation.
The deaggregator is more involved. If an SPF routing protocol,
such as OSPF or IS-IS, is in use, and if it has been extended
to advertise information on Deaggregation roles, it can tell
us what selection of routers the deaggregator will be chosen
from among. However, if that set contains more than one
router, it would not tell us which. Also, even if the Link
State protocol was extended as mentioned above, multi-area
operation is likely to prevent proper advertisement of the
Deaggregation attributes and thus deaggregator selection.
One method for Deaggregator determination is manual
configuration. With this method the network operator would
configure the Aggregator and the Deaggregator the necessary
information.
Another method allows automatic Deaggregator determination and
corresponding Aggregator notification. When the RSVP PATH
message transits from either an aggregator or an interior
interface to a deaggregator interface, the deaggregating
router must advise the aggregating router of the correlation
between itself and the flow. This has the nice attribute of
not being specific to the routing protocol. It also has the
property of automatically adjusting to route change. For
instance, if because of a topology change, another
Deaggregator is now on the shortest path, this method will
automatically identify the new Deaggregator and swap to it.
1.4.3. Size of Aggregate Reservations
A range of options exist for determining the size of the
aggregate reservation, presenting a tradeoff between
simplicity and scalability. Simplistically, the size of the
aggregate reservation needs to be greater than or equal to the
sum of the bandwidth of the connections it aggregates, and its
burst capacity must be greater than or equal to the sum of
their burst capacities. However, if followed religiously, this
leads us to change the bandwidth of the aggregate reservation
each time an underlying reservation changes, which loses one
of the key benefits of aggregation, the reduction of message
processing cost in the aggregation region.
We assume, therefore, that there is some policy, not defined
in this specification (although sample policies are suggested
which have the necessary characteristics). This policy
Baker et al Expiration: August 1999 [Page 6]
Draft RSVP Reservation Aggregation February 1999
maintains the amount of bandwidth on a given aggregate
reservation at an amount greater than or equal to the sum of
the bandwidths of its underlying reservations, while changing
it but infrequently. This may require some level of trend
analysis if there is a significant probability that in the
next interval of time the current aggregate reservation will
be exhausted, the router must predict the necessary bandwidth
and request it. If the router has a significant amount of
bandwidth reserved but has very little probability of using
it, the policy may be to predict the amount of bandwidth
required and release the excess.
This policy is likely to benefit from introduction of some
hysteresis (i.e. ensure that the trigger condition for
reservation size increase is sufficiently different from the
trigger condition for reservation size decrease) to avoid
oscillation in stable conditions.
Clearly, the definition and operation of such policies are as
much business issues as they are technical, and are out of the
scope of this document.
1.4.4. Intra-domain Routes
RSVP directly handles route changes, in that reservations
follow the routes that their data follow. This follows from
the property that PATH messages contain the same IP source and
destination address as the data flow for which a reservation
is to be established. However, since we are now making
aggregate reservations by sending a PATH message from an
ingress to an egress router, the reserved data packets no
longer carry the same IP addresses as the relevant PATH
message. The issue becomes one of making sure that data
packets for reserved flows follow the same path as the PATH
message that established Path state for the aggregate
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, MPLS labeled tunnels, and so on. These each have
particular advantages, especially MPLS, which admits traffic
engineering. They each also have some cost in link overhead
and configuration complexity.
If data is not tunneled, then we are depending a
characteristic of IP best metric routing , which is that if
Baker et al Expiration: August 1999 [Page 7]
Draft RSVP Reservation Aggregation February 1999
the route from A to Z includes the path from H to L, and the
best metric route was chosen all along the way, then the best
metric route was chosen from H to L. Therefore, a path which
crosses a given aggregator 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, then we are forced to determine, perhaps by
measurement, what proportion of the traffic for a given
reservation is passing along each of the paths, and assure
ourselves of sufficient bandwidth for the present use. A
simple, though inelegant, way of doing this is to reserve the
total capacity of the aggregate route down each path.
For this reason, we believe it is advantageous to use one of
the above-mentioned tunneling mechanisms in cases where
multi-path routes may exist.
1.4.5. Inter-domain Routes
Again, RSVP responds directly to route changes, in that
reservations follow the routes that their data follow.
However, in this case, the best-path considerations do not
apply, as routing is by a combination of routing policy and
shortest AS path rather than simple best metric.
In this case, we must presume that a data flow might come in
on different aggregator interfaces and leave on different
deaggregator interfaces. It is possible that we could identify
this occurrence in some central system which sees the
reservation information for both of the apparent sessions, but
it is not clear that we could determine a priori how much
traffic went one way or the other apart from measurement.
As a result, we simply note that the problem can occur and
needs to be allowed for in the implementation. We recommend
that each such flow reservation be summed into each
appropriate aggregate reservation, even though this involves
over-reservation.
1.4.6. Reservations for Intra-domain Multicast Routing
Multicast routing, in this framework, acts much like a
superset of multipath unicast routing. It differs in that the
information from a given aggregator may divide at some
Baker et al Expiration: August 1999 [Page 8]
Draft RSVP Reservation Aggregation February 1999
interior router and proceed to more than one deaggregator. For
this reason, we recommend that multicast routes use a distinct
set of DSCPs, and that a form of shared explicit reservation
be used. Since such reservations must be from one source
(aggregator) to multiple destinations (deaggregator), and
Shared Explicit (SE) reservations traverse one session and
many filter specifications, we therefore choose to identify
the aggregator in the session object and the deaggregator in
the filter object.
1.4.7. Reservations for Inter-domain Multicast Routing
to be filled in:
Baker et al Expiration: August 1999 [Page 9]
Draft RSVP Reservation Aggregation February 1999
2. Elements of Procedure
To implement this, we define a number of elements of
procedure.
2.1. Receipt of Flow Reservation Path Message By aggregating
router
The very first event is the arrival of the PATH message for a
microflow at an exterior interface of an aggregator. RSVP
version 1's standard procedures are followed for this,
including consideration of what set of interfaces it needs to
be forwarded onto. These interfaces comprise zero or more
deaggregator interfaces and zero or more interior interfaces.
Service on deaggregator interfaces is handled as defined in
RSVP Version 1.
Service on interior interfaces is complicated by the fact that
the message needs to be included in some number of aggregate
reservations, but at this point it is not known which one,
because the deaggregator is not known. Therefore, the PATH
message is forwarded on the interface using the IP Protocol
number RSVP-AGGREGATE, but in every other respect identically
to the way it would be sent by RSVP Version 1.
2.2. Handling Of Flow Reservation Path Message By Interior
Routers
At this point, the message traverses zero or more interior
routers, which receive an RSVP-AGGREGATE message on an
interior interface and forward it to another interior
interface. The Router Alert IP Option alerts them to check
internally, but they find that the IP Protocol is RSVP-
AGGREGATE and the next hop interface is interior. As such,
they simply forward it as a normal IP datagram.
2.3. Receipt of Flow Reservation Path Message By
Deaggregating router
The PATH message finally arrives at a deaggegating router,
which receives it from an interior interface and forwards it
to an external interface. Again, the Router Alert IP Option
alerts it to intercept the message, but this time the IP
Baker et al Expiration: August 1999 [Page 10]
Draft RSVP Reservation Aggregation February 1999
Protocol is RSVP-AGGREGATE and the next hop interface is an
external interface.
At this point, the deaggregating router associates the flow
with an aggregate reservation. This selection is done on the
basis of policy, and may take into account not only the
aggregating router (whose IP Address may be found in the RSVP
Hop Object) but other information about the flow. If no such
aggregate reservation exists and the router is so configured,
it may generate a PATH ERROR with code NEW-AGGREGATE-NEEDED
back to the aggregating router. This should not result in any
reservation being taken down, but may result in the
aggregating router initiating the necessary path message.
The message is also changed from IP Protocol RSVP-AGGREGATE
back to IP Protocol RSVP, the ADSPEC information accumulated
by that aggregate reservation added into this ADSPEC, and the
PATH message is forwarded towards its intended destination.
2.4. Initiation of New Aggregate Reservation Path Message By
Aggregating router
The aggregating router is responsible to include the
SENDER_TSPEC information from individual flow reservations in
the SENDER_TSPEC being announced to its deaggregating router.
It may know that a reservation is associated with a given
deaggregator when one of two events occurs: it receives a PATH
ERROR message with the error code NEW-AGGREGATE-NEEDED, or
when it receives an RESV message from the deaggregator for the
flow. The DCLASS object in the message indicates which DSCP
the deaggregator believes that the flow belongs in. The
identity of the deaggregator itself is to be found in the
ERROR SPECIFICATION or the RSVP HOP object.
On receipt of either, if no corresponding aggregate
reservation exists and the router is configured to do so, it
should generate a PATH message for the aggregate reservation.
The destination address of the PATH message is the address of
the deaggregating router, and the message is sent with IP
protocol number RSVP.
For multicast, the PATH message could be sent to an "All
Deaggregators" multicast address. Shared Explicit signaling
could also be used to direct shared multicasts directly to
each of the indicated egress points. This latter, while
requiring perhaps a few more messages, means that we need
Baker et al Expiration: August 1999 [Page 11]
Draft RSVP Reservation Aggregation February 1999
neither a set of multicast addresses corresponding to all
permutations of possible egress routers, nor a way to handle
excess irrelevant messages.
2.5. Handling of Flow Reservation RESV Message by
Deaggregating Router
Having sent the flow PATH message on toward the destination,
the router must now expect to receive an RESV for the session.
On receipt, its responsibility is to assure itself that there
is sufficient bandwidth reserved to accomplish the task, and
if there is, then to forward the RESV to the aggregating
router.
Note that there is discussion among the authors as to whether
the aggregator or the de-aggregator should assure that the
aggregate reservation has enough bandwidth to support the
individual flow.
If there is insufficient bandwidth reserved, it should follow
the RSVP Version 1 procedures for a reservation being placed
with insufficient bandwidth to support the reservation. It may
also immediately attempt to increase the aggregate reservation
that is supplying bandwidth.
When sufficient bandwidth is available, it may now simply send
an RESV message with IP Protocol RSVP to the aggregating
router. This message should, in addition to other data,
contain the DCLASS object to indicate which DSCP the
deaggregating router expects the aggregator to use. It will
also add the token bucket from the FLOWSPEC object into its
internal understanding of how much of that reservation is in
use.
2.6. Initiation of New Aggregate Reservation RESV Message By
Deaggregating Router
If there is a PATH message for the aggregate reservation but
no RESV message, at this point the deaggregating router should
create such an RESV and set its initial request to a value not
smaller than the requirement of the flow it is supporting.
If there is not a PATH message, a deadlock exists; the sender
has not created one, meaning that it may have missed the PATH
ERROR message intended to trigger the event, or it may have
Baker et al Expiration: August 1999 [Page 12]
Draft RSVP Reservation Aggregation February 1999
not been configured to create the message. The deaggregator
should generate the necessary state with which to respond to
such a PATH message, initiate a PATH ERROR message as a
retransmission, and quiesce.
Once it has the PATH message for the aggregate, the
deaggregator sends a normal RESV message toward the aggregator
(e.g., to the previous hop), using the AGGREGATED-RSVP session
and filter specifications. Since the DSCP is in the SESSION
object, the DCLASS is unnecessary. However, the CONFIRM object
should be used, to assure that the reservation does indeed
arrive and is granted. The de-aggregator may presume any
confirmed bandwidth to be available to allocate to the flows
it supports.
2.7. Handling of Flow Reservation RESV Message by Interior
Routers
The RESV is handled in the usual manner, with respect to
bandwidth allocation and other aspects. However, since the
flow of the reservation differs from that of other session
types, it bears explaining.
RSVP V1 sessions proceed from a set of senders to a receiver
or class of receivers. For this reason, RSVP V1 uses the
receiver's address in the SESSION object and places senders in
the FILTER SPECIFICATION. This is backwards of that -
aggregated RSVP sessions proceed from a single aggregator
towards one or more deaggregators. Therefore, the aggregator's
IP Address is used in the SESSION object, and the filter-list
is essentially a list of receivers.
The interior routers, therefore, apply either the FF or SE
flow merging rules as appropriate, and in the multicast case
forward toward the aggregator the union of the sets of FILTER
specifications.
2.8. Handling of Flow Reservation RESV Message by Aggregating
Router
The RESV message is the final confirmation to the aggregating
router that a proportion of a given aggregate's bandwidth has
been reserved. At this point, it should assure itself that the
flow reservation is associated with an appropriate aggregate,
that the aggregator and deaggregator expectations synchronize,
Baker et al Expiration: August 1999 [Page 13]
Draft RSVP Reservation Aggregation February 1999
and that all things are in place. It should also assure itself
that the SENDER_TSPEC from the PATH message has been
accumulated into the aggregate PATH message. Under normal
circumstances, this is the only way it will be informed of
this association. It should now forward the flow's RESV to its
previous hop, following RSVP Version 1 rules.
2.9. Removal of Flow Reservation
Flow reservations are removed in the usual way via PATH TEAR,
RESV TEAR, timeout, or as the result of an error condition.
When they are removed, their FLOWSPEC information must also be
removed from the allocated portion of the aggregate
reservation. This same bandwidth may be re-used for other
traffic in the near future. When PATH messages are removed,
their SENDER_TSPEC information must also be removed from the
aggregate PATH.
2.10. Removal of Aggregate Reservation
Should an aggregate reservation go away (presumably due to a
configuration change, route change, or policy event), the
reservations it supports are no longer active. They must be
treated accordingly.
2.11. Handling of Data On Reserved Flow by Aggregating
Router
Prior to establishment that a given flow is part of a given
aggregate, the flow's data should be treated as general best
effort traffic by whatever policies prevail for such.
Generally, this will mean being given the same throughput
behavior as non-essential traffic. However, upon establishing
that, the aggregating router is responsible to mark any
related traffic with the correct DSCP and forward it in the
manner appropriate to traffic on that reservation. This may
imply forwarding it to a given IP next hop, or piping it down
a given link layer circuit, tunnel, or MPLS label switched
path.
Baker et al Expiration: August 1999 [Page 14]
Draft RSVP Reservation Aggregation February 1999
3. Protocol Elements
3.1. IP Protocol RSVP-AGGREGATE
This specification presumes the assignment of a protocol type
RSVP-AGGREGATE, whose number is at this point TBD. This is
used only on messages which require a router alert (PATH, PATH
ERROR, and RESV CONFIRM), and signifies that the message must
be treated one way when copied to an interior interface, and
another way when copied to en exterior interface.
3.2. Path Error Code
A PATH ERROR code NEW-AGGREGATE-NEEDED is presumed. This value
does not signify that a terminal error has occurred, but that
an action is required of the aggregating router to avoid an
error condition in the near future.
3.3. SESSION Object
The SESSION object contains two values: the IP Address of the
aggregating router, and the DSCP that it will use on the data
the reservation contains. This is exactly backwards of RSVP
Version 1, and is intended to support shared explicit
multicast reservations along a network route branching away
from the aggregator. Two types must be designed: one
specifying the aggregator by its IP4 Address, and one
specifying the aggregator by its IP6 address.
o IP4 SESSION object: Class = SESSION, C-Type = RSVP-AGGREGATE-IP4
+-------------+-------------+-------------+-------------+
| IPv4 Aggregator Address (4 bytes) |
+-------------+-------------+-------------+-------------+
| /////////// | Flags | ///////// | DSCP |
+-------------+-------------+-------------+-------------+
o IP6 SESSION object: Class = SESSION, C-Type = RSVP-AGGREGATE-IP6
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IPv6 Aggregator Address (16 bytes) +
| |
Baker et al Expiration: August 1999 [Page 15]
Draft RSVP Reservation Aggregation February 1999
+ +
| |
+-------------+-------------+-------------+-------------+
| /////////// | Flags | ///////// | DSCP |
+-------------+-------------+-------------+-------------+
3.4. SENDER_TEMPLATE Object
The SENDER_TEMPLATE is omitted from PATH messages for
aggregate reservations.
3.5. FILTER Object
The FILTER object identifies the deaggregating router, or set
of deaggregating routers in the event that there are several.
o IP4 SESSION object: Class = FILTER, C-Type = RSVP-AGGREGATE-IP4
+-------------+-------------+-------------+-------------+
| IPv4 De-aggregator Address (4 bytes) |
+-------------+-------------+-------------+-------------+
o IP6 SESSION object: Class = FILTER, C-Type = RSVP-AGGREGATE-IP6
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IPv6 De-aggregator Address (16 bytes) |
| |
+ +
| |
+-------------+-------------+-------------+-------------+
3.6. DCLASS Object
The DCLASS object indicates the DSCP that the deaggregator
expects the aggregator to use in marking the data. This may be
used for coherence checks.
o DCLASS object: Class = DCLASS, C-Type = Diff-serv
+-------------+-------------+-------------+-------------+
| ////////////////////////////////////// | DSCP |
Baker et al Expiration: August 1999 [Page 16]
Draft RSVP Reservation Aggregation February 1999
+-------------+-------------+-------------+-------------+
Baker et al Expiration: August 1999 [Page 17]
Draft RSVP Reservation Aggregation February 1999
4. Policies and Algorithms For Predictive Management Of
Blocks Of Bandwidth
The exact policies used in determining how much bandwidth
should be allocated to an aggregate reservation at any given
time are beyond the scope of this document, and may be
proprietary to the service provider in question. However, here
we explore some of the issues and suggest approaches.
In short, the ideal condition is that the aggregate
reservation always has enough to allocate to any flow
reservation that requires its support, and never takes too
much. Simply stated, but more difficult to achieve. Factors
that come into account include significant times in the
diurnal cycle: one may find that a large number of people
start placing calls at 8:00 AM, even though the hour from 7:00
to 8:00 is dead calm. They also include recent history: if
more people have been placing calls recently than have been
finishing them, a prediction of the necessary bandwidth a few
moments hence may call for more bandwidth than is currently
allocated. Likewise, at the end of a busy period, we may find
that the trend calls for declining reservation amounts.
We would recommend a policy something along this line. At any
given time, one should expect that the amount of bandwidth
required for the aggregate reservation is the larger of the
following:
(a) a requirement known a priori, such as from history of the
diurnal cycle at a particular week day and time of day,
and
(b) the trend line over recent history, with 90 or 99%
statistical confidence.
We would further expect that changes to that aggregate
reservation would be made no more often than every few
minutes, and ideally perhaps on larger granularity such as
fifteen minute intervals or hourly. The finer the granularity,
the greater the level of signaling required, while the coarser
the granularity, the greater the chance for error, and the
need to recover from that error.
In general, we expect that the aggregate reservation will not
ever add up to exactly the sum of the reservations it
supports, but rather will be an integer multiple of some block
reservation size, which exceeds that value.
Baker et al Expiration: August 1999 [Page 18]
Draft RSVP Reservation Aggregation February 1999
5. Security Considerations
Numerous security issues pertain to this document; for
example, the loss of an aggregate reservation to an aggressor
causes many calls to operate unreserved, and the reservation
of a great excess of bandwidth may result in a denial of
service. However, these issues are not confined to this
extension: RSVP itself has them. We believe that the security
mechanisms in RSVP address these issues as well.
6. IANA Considerations
Beyond allocating an IP Protocol, a PATH ERROR code, and an
RSVP Addressing object "type", there are no IANA issues in
this document. We do not define an object that will itself
require assignment by IANA.
7. Acknowledgments
The authors freely acknowledge that published documents and
discussion with several people materially contributed to the
correct specification of this function. The design derives
directly from an internet draft by Roch Guerin [Guerin] and
from Steve Berson's drafts on the subject. It is also
influenced by the design in the diff-edge draft by Bernet et
al [Bernet].
Baker et al Expiration: August 1999 [Page 19]
Draft RSVP Reservation Aggregation February 1999
8. References
[IP] RFC 791, "Internet Protocol". J. Postel. Sep-01-1981.
[HOSTREQ]
RFC 1122, "Requirements for Internet hosts -
communication layers". R.T. Braden. Oct-01-1989.
[FRAMEWORK]
Nichols, "Differentiated Services Operational Model and
Definitions", 02/11/1998, draft-nichols-dsopdef-00.txt
[PRINCIPLES]
RFC 1958, "Architectural Principles of the Internet". B.
Carpenter. June 1996.
[ASSURED]
Clark and Wroclawski, "An Approach to Service Allocation
in the Internet", 08/04/1997, draft-clark-diff-svc-
alloc-00.txt
[BROKER]
Nichols and Zhang, "A Two-bit Differentiated Services
Architecture for the Internet", 12/23/1997, draft-
nichols-diff-svc-arch-00.txt
{BERSON]
Berson and Vincent. Aggregation of Internet Integrated
Services State. draft-berson-rsvp-aggregation-00.txt,
August 1998
9. Author's Addresses
Fred Baker
Cisco Systems
519 Lado Drive
Santa Barbara, California 93111
Phone: (408) 526-4257
Email: fred@cisco.com
Carol Iturralde
Cisco Systems
250 Apollo Drive
Chelmsford MA,01824 USA
Phone: 978-244-8532
Email: cei@cisco.com
Baker et al Expiration: August 1999 [Page 20]
Draft RSVP Reservation Aggregation February 1999
Francois Le Faucheur
Cisco Systems
Office: 16 av du Quebec,
Villebon-BP 706, 91961 Les Ulis -
France
Phone: +33.1.6918 6266
Email: flefauch@cisco.com
Bruce Davie
Cisco Systems
250 Apollo Drive
Chelmsford MA,01824 USA
Phone: 978-244-8921
Email: bdavie@cisco.com
Baker et al Expiration: August 1999 [Page 21]
| PAFTECH AB 2003-2026 | 2026-04-22 07:03:58 |