Internet Engineering Task Force R. Guerin/S. Blake/S. Herzog
INTERNET DRAFT IBM/IBM/IPHighway
21 November 1997
Aggregating RSVP-based QoS Requests
draft-guerin-aggreg-rsvp-00.txt
Status of This Memo
This document is an Internet-Draft. 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 draft documents valid for a maximum of six
months, and may be updated, replaced, or obsoleted by other documents
at any time. It is not appropriate to use Internet Drafts as
reference material, or to cite them other than as a ``working draft''
or ``work in progress.''
To learn the current status of any Internet-Draft, please check
the ``1id-abstracts.txt'' listing contained in the internet-drafts
Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
Rim).
Abstract
This document describes issues and approaches related to aggregation
of QoS requests, when RSVP [BZB+97] is the protocol used to convey
such requests. Aggregation is an important component to provide
scalable QoS solutions, especially in the core of the backbone
where the sheer number of flows mandates some form of aggregation.
However, aggregation needs to be provided without impacting the
ability to provide end-to-end QoS guarantees to individual flows.
In this document, we review some of the main goals of aggregation
and describe possible solutions, that do not preclude support for
end-to-end QoS guarantees. Those solutions are targeted at unicast
flows as we expect them to represent a large fraction of the flows
requesting reservation, and hence to be the main contributors to
potential scalability problems with RSVP.
Guerin et al. Expires 26 May 1998 [Page i]
Internet Draft Aggregating RSVP-based QoS Requests 21 November 1997
Contents
Status of This Memo i
Abstract i
1. Introduction 1
2. Sample Scenario and Requirements for QoS Aggregation 2
3. Data Path Aggregation 4
3.1. Tunnel Based Aggregation . . . . . . . . . . . . . . . . 5
3.2. TOS Field Based Aggregation . . . . . . . . . . . . . . . 5
4. Control Path Aggregation 6
4.1. Tunnel Based Aggregation . . . . . . . . . . . . . . . . 7
4.1.1. Setting of Aggregate Reservations . . . . . . . . 8
4.2. TOS Field Based Aggregation . . . . . . . . . . . . . . . 9
4.2.1. Ingress-Egress Aggregation: Method 1 . . . . . . 10
4.2.2. Ingress-Egress Aggregation: Method 2 . . . . . . 13
4.2.3. Setting of Aggregate Reservations . . . . . . . . 14
5. Conclusion and Recommendations 15
A. Router Alert Options for Concealing ``Individual'' PATH Messages 17
A.1. IPv4 Syntax . . . . . . . . . . . . . . . . . . . . . . . 17
A.2. IPv6 Syntax . . . . . . . . . . . . . . . . . . . . . . . 18
Guerin et al. Expires 26 May 1998 [Page ii]
Internet Draft Aggregating RSVP-based QoS Requests 21 November 1997
1. Introduction
As described in [Bra97], there are several facets to the support
of QoS in the Internet. The aspect of QoS aggregation with RSVP
falls primarily in the areas of ``Control Model'', and to some
extent ``Scope'', as they are identified in [Bra97]. Specifically,
the focus of QoS aggregation is on both the granularity of QoS
guarantees, and their extent, i.e., from where to where.
In RSVP, the granularity of a QoS request is determined through
filters that specify destination address and port number, as well
as source address and port number in some instances (see [BZB+97]
for details). This corresponds to a very fine granularity of QoS
guarantees, i.e., per flow, and while this provides end-users with
accurate control, it can also translate into a substantial overhead
for the network. This is particularly true for backbone links,
where the sheer number of flows (there are 37,500 64kbps flows on
an OC-48 link) can introduce a scalability problem. Similarly, the
scope of RSVP QoS requests is end-to-end, i.e., from application to
application, and while this does again provide end-users with maximum
control, it can also impose substantial overhead. For example,
a network administrator may want to reserve a certain amount of
bandwidth to interconnect two sites across the network of an ISP.
This is not readily feasible under the current RSVP specifications,
which require that reservations be setup and managed between all
pairs of end-users in the two sites. A possible alternative is to
establish an RSVP ``tunnel'' between the two sites, and we discuss
this option, but it has the disadvantage of additional encapsulation
overhead and processing.
As a result, the issue of QoS aggregation in the context of RSVP
has two major components. The first, is an extension to RSVP to
support ``aggregate'' QoS requests, i.e., on behalf of a set of
flows rather than individual flows. For example, the set of flows
to which an aggregate request would apply, could correspond to
traffic between a given source subnet and a given destination subnet.
Support for such aggregate requests is not available from the current
RSVP specifications, and would require the definition of new filter
specifications. One possible example are the CIDR prefix based
filters suggested in [Boy97]. The introduction of such extensions is
certainly key to increasing the applicability of RSVP as a generic
reservation protocol, but in this document we instead focus on the
second and more immediate aspect of QoS aggregation for RSVP.
Specifically, we consider the problem of aggregating a large number
of individual RSVP requests to improve scalability, e.g., on backbone
links, without precluding support for individual QoS guarantees where
feasible, e.g., on low speed links and local networks. In other
Guerin et al. Expires 26 May 1998 [Page 1]
Internet Draft Aggregating RSVP-based QoS Requests 21 November 1997
words, the focus of QoS aggregation in this document, is to provide
the means for ensuring individual end-to-end QoS guarantees, but
without requiring that awareness of individual flows be maintained on
each and every segment of their path. This is an important issue as
the need for maintaining and updating a large number of individual
RSVP flow states has been often mentioned as a major obstacle to
the widespread deployment of RSVP. The goals of this document are,
therefore, to review and address the potential scalability problems
that have been identified with the CURRENT RSVP specifications, and
propose possible solutions.
The rest of this document is structured as follows. In Section 2,
we first describe a sample scenario illustrating the constraints
and aspects of QoS aggregation with RSVP. In Sections 3 and 4, we
identify specific goals when supporting QoS aggregation for RSVP, and
propose possible aggregation solutions to achieve them.
2. Sample Scenario and Requirements for QoS Aggregation
Consider the network topology of Figure 1. It consists of three
separate AS, with the two edge AS (AS1 and AS3) corresponding
to local AS and the middle one (AS2) representing a backbone
interconnecting the two. For the purpose of our discussion on QoS
aggregation, we assume that scalability is of concern only in the
backbone AS2, i.e., AS1 and AS3 are capable of maintaining RSVP state
information for all the individual flows that originate and terminate
in them. Furthermore, and without loss of generality, we focus on
RSVP flows between AS1 and AS3 that cross AS2. In that context, QoS
aggregation is of concern only for AS2.
AS1 AS2 AS3
________ ________________ _________
/ \ / \ / \
/ \ / \ / \
| Access | | Backbone | | Access |
| Network |----| Network |----| Network |
| | | | | |
\ / \ / \ /
\________/ \________________/ \_________/
Figure 1: Sample Network Configuration
Guerin et al. Expires 26 May 1998 [Page 2]
Internet Draft Aggregating RSVP-based QoS Requests 21 November 1997
Aggregation of individual RSVP flows through AS2 must satisfy a
number of requirements, which we briefly review.
R1 AS2 should not have to maintain awareness of individual RSVP
flows between AS1 and AS3. Instead, AS2 should be able to map
individual RSVP flows onto few internal service ``classes''.
R2 AS2 should ensure that it satisfies the QoS requirements of
individual RSVP flows, e.g., the resources allocated to a service
class in AS2 should at least be equal to the aggregate resources
required by all the individual flows mapped onto it.
R3 Isolation between flows should be maintained in AS2, i.e., even
when flows are aggregated into a common service class, the excess
traffic of one flow should not affect the performance guarantees
of another flow.
R4 Aggregation in AS2 should not prevent support for individual flow
reservations in AS1 and AS3.
Requirement R1 is the core scalability requirement expressed by AS2.
It basically states, that because QoS support within AS2 is provided
through much coarser mechanisms than the control and allocation of
resources to individual RSVP flows, of which there could be way too
many, it is necessary for individual RSVP flows to be mapped onto one
of the internal class-based mechanisms supported by AS2. Coarser
class-based mechanisms are usually mandated by the speed of the
backbone links, where the time available for making packet forwarding
and scheduling decisions is often not sufficient to accommodate per
flow operations. In addition to the constraint on forwarding and
scheduling decision, there is a similar limitation on the amount of
control information that a backbone node is capable of maintaining
and updating. Specifically, maintaining path and reservation control
blocks for individual flows may not be not practical in AS2.
Requirements R2 and R3 specify properties, that the mapping of
individual RSVP flows onto the coarser ``classes'' of AS2 has to
satisfy. First and foremost, requirement R2 expresses the need
for some coupling between the resources (bandwidth and buffer) and
level of service (priority) assigned to a class in AS2, and the
aggregation of the individual RSVP flows mapped onto that class. For
example, this means that the amount of bandwidth assigned to a class
should be sufficient to accommodate the traffic of all the RSVP flows
mapped onto it. This must remain true even as flows modify their
reservations. Furthermore, requirement R2 also points to the fact
that services classes in AS2 must be defined so as to ensure they
can meet the QoS guarantees of any individual flow mapped onto them.
This typically means that flows mapped onto the same service class
Guerin et al. Expires 26 May 1998 [Page 3]
Internet Draft Aggregating RSVP-based QoS Requests 21 November 1997
must exhibit some level of homogeneity in their QoS requirements, or
that the service class is dimensioned to meet the most stringent QoS
requirements of the individual flows mapped onto it.
Requirement R3 is a direct result of the aggregation of individual
flows. The QoS guarantees provided to an individual RSVP flow are
limited to its conformant packets, i.e., packets that comply with
the advertised TSpec of the flow. Checking compliance with a flow
TSpec is readily achieved when per flow awareness is maintained, but
is lost after flows have been aggregated. In particular, violation
of an aggregate TSpec (``sum'' of individual TSpec's) can be caused
by a single non-conformant flow, but can impact the QoS guarantees
experienced by all the flows that have been aggregated. As a result,
some mechanism is needed to identify non-conformant packet even
after flows have been merged. One possible approach is to use a
``tagging'' capability as suggested in [CW97].
Requirement R4 expresses the important constraint that satisfying
scalability in AS2, should not come at the expense of functionality
in AS1 and AS3. Specifically, the aggregation of control and data
path information in AS2 should be reversible, so that reservations in
AS1 and AS3 can default back to individual flows after crossing AS2.
In other words, the hiding of individual flow information in AS2
should not prevent reservations at a finer level of granularity in
AS1 and AS3, so that end-to-end RSVP reservations can be supported.
This means that for RSVP flows, AS2 should essentially behave as a
single RSVP ``node''. Reservation of resources within a node are
transparent to RSVP, but should not affect end-to-end operation.
In the next sections, we qualify how the above requirements translate
into specific goals to support aggregation, and also describe
possible approaches to satisfy these requirements.
3. Data Path Aggregation
On the data path, the main issue is the classification of data
packets to determine the level of QoS they are eligible to receive.
Performing this classification on the basis of bit patterns that are
specific to individual flows, i.e., source and destination addresses
and port numbers, may not scale. Specifically, storing all the
patterns corresponding to individual flows holding a reservation and
extracting the corresponding patterns from all incoming packets, can
represent a substantial per packet processing overhead. As a result,
the goal of an aggregation solution is to map all the bit patterns
used to classify individual flows with reservations onto a much
smaller number of patterns. There are several possible approaches to
achieve such a mapping.
Guerin et al. Expires 26 May 1998 [Page 4]
Internet Draft Aggregating RSVP-based QoS Requests 21 November 1997
3.1. Tunnel Based Aggregation
A first solution is to rely on RSVP tunnels. In other words, an RSVP
tunnel is created between any two ingress and egress points for which
there exists at least one RSVP flow across AS2. At the ingress,
packets (data and control) belonging to the corresponding RSVP
flows are encapsulated in IP packets with an IP destination address
identifying the egress point from AS2. The egress point is then
responsible for the reverse decapsulation process before forwarding
packets towards their next hop. As a result of encapsulation,
routers on the path in AS2 only require a single entry to classify
packets from all the associated RSVP flows. The main disadvantages
of this solution are the data and processing overheads associated
with encapsulation, as well as the need for close synchronization
with routing. Specifically, the mapping of individual RSVP flows
onto a given egress point from AS2 depends on routing information,
and route changes need to be closely monitored to determine if and
when they affect this mapping.
In addition to these disadvantages, tunnels *alone* do not easily
address the above requirement R3 concerning flow isolation. This
is because after encapsulation, conformant packets from one flow
cannot be distinguished from non-conformant packets of another flow.
As a result, it is necessary to discriminate between conformant
and non-conformant packets at the ingress point of a tunnel, e.g.,
send non-conformant packets as regular (non-encapsulated) packets
through AS2. While this satisfies requirement R3, it does so at the
cost of potentially unnecessary penalization of RSVP flows, e.g.,
out-of-order delivery, even in the absence of congestion in AS2.
3.2. TOS Field Based Aggregation
A number of other approaches for aggregation have been
brought forward, [CW97, BV97, Hei97, Kil97], with several
[CW97, Hei97, Kil97] proposing the use of fewer bits in the IP header
for classification purposes. In particular, it has been suggested to
use the TOS octet field [Pos81] to specify different service classes
as well as drop precedence. From the point of view of aggregation of
RSVP flows, this means that RSVP data packets are assigned a value
for the TOS field in their IP header, that is a function of both
their service class, e.g., Controlled Load [Wro97a] or Guaranteed
Service [SPG97], and whether the packet is conformant or not.
Specifically, several (the exact number is tbd and a function of the
number of distinct service classes that are deemed necessary) TOS
bits are used to specify service classes. Data packets from RSVP
flows entering AS2 then have the TOS field in their IP header set
Guerin et al. Expires 26 May 1998 [Page 5]
Internet Draft Aggregating RSVP-based QoS Requests 21 November 1997
accordingly to reflect the service class they have requested. As a
result, routers in AS2 can classify packets using TOS bit patterns
instead of full filters. Conceptually, on a link at a router in
AS2, each service class is identified through its assigned TOS bit
pattern and mapped onto a separate transmission queue, that has been
allocated sufficient resources (bandwidth and buffers) to satisfy the
QoS requirements of the aggregation of flows it carries.
In addition to the TOS bits identifying the service class to
which the data packets of RSVP flows belong to, one more bit from
the TOS field is needed to indicate conformance of packets from
each flow to their corresponding TSpec. This explicit indication
of non-conformant packets is key to enforcing flow isolation
(requirement R3) and ensuring that the QoS guarantees of individual
flows are met in spite of their aggregation into a common class.
For example, as has been suggested, the conformance bit can be used
by routers in AS2 to implement a ``drop precedence'' policy to
preferentially discard non-conformant packets in case of congestion.
In general, ensuring that the aggregate resources allocated to
each service class are adequate to satisfy the QoS guarantees of
individual RSVP flows, i.e., requirements R2 and R3, requires
coupling to the RSVP control path and this aspect is discussed in
the next section. However, before addressing this issue, it should
be noted that the above approach offers a number of benefits above
those afforded by the previous tunneling solution. First, it avoids
the overhead of encapsulation. Second, the ingress and egress
processing required is minimal, i.e., update of the TOS field in the
IP header (note that this could even be performed in the end-stations
themselves). Third, it does not require any interactions with
routing above and beyond what is normally required by RSVP. In other
words, aggregation is supported in a manner that is essentially
transparent to RSVP.
4. Control Path Aggregation
The aggregation of control information associated with individual
RSVP flows is just as important for scalability as its data path
counterpart. Specifically, maintaining PATH and RESV states for
individual RSVP flows can represent a substantial burden in backbone
routers which need to support a large number of flows. The goal of
QoS aggregation is then to eliminate or at least minimize the amount
of per flow control information that needs to be maintained. As
with data path aggregation, this needs to be done while maintaining
the QoS guarantees requested by individual flows. In particular,
the resources allocated to a set of aggregated flows must reflect
the ``sum'' of the reservation requests conveyed in individual RESV
Guerin et al. Expires 26 May 1998 [Page 6]
Internet Draft Aggregating RSVP-based QoS Requests 21 November 1997
messages. Making sure this and the several requirements identified
earlier (requirement R2, R3, and R4) are met, varies according
to the data path aggregation method used. Note that aggregation
also offers the opportunity for greater efficiency because of the
potential benefits of statistical multiplexing. However, some
care must be applied to avoid under-provisioning of resources in
the backbone, e.g., aggregation may affect measurement based call
admission rules in backbone routers.
4.1. Tunnel Based Aggregation
When QoS aggregation is achieved through the use of an RSVP tunnel,
all RSVP control messages for individual flows are encapsulated
and, therefore, not seen by any of the intermediate routers (in
AS2). However, because those messages are carried across the tunnel,
after decapsulation at the egress router, they will be forwarded as
usual so that reservations for individual RSVP flows can still be
established on the rest of the path, i.e., in AS1 and AS3. Note
that because individual PATH messages are encapsulated, their ADSPEC
is not updated as they cross the backbone. At the egress router of
the tunnel, updating the ADSPEC in the PATH messages of individual
flows is carried out using the corresponding ADSPEC fields from the
PATH messages of the tunnel itself. Specifically, hop count, path
latency, service specific quantities such as Guaranteed Service error
terms, etc., are all updated as if the ADSPEC values for the tunnel
were those of a single ``node'' (AS2 is considered as one node).
As far as the tunnel is concerned, its establishment is the
responsibility of the ingress and egress routers at its end-points,
which generate new RSVP control messages with their address as the
source and destination addresses (1). In addition, the traffic
specification (TSpec) and reservation levels (FLOWSPEC) specified in
these messages need to adequately reflect the requirements of the
flows aggregated into the tunnel. In particular, the type of service
used for a tunnel should match that of the flows being aggregated on
the tunnel, e.g., Controlled Load flows should be aggregated onto a
Controlled Load tunnel.
----------------------------
1. Note that a possible alternative is to
use a layer 2, e.g., ATM, tunnel, which would then be setup using the
available layer 2 signalling.
Guerin et al. Expires 26 May 1998 [Page 7]
Internet Draft Aggregating RSVP-based QoS Requests 21 November 1997
4.1.1. Setting of Aggregate Reservations
In the case of a Controlled Load tunnel, the aggregate TSpec used
in the PATH messages for the tunnel, needs to be selected so as to
accommodate the TSpec's of all the flows it aggregates. A natural
selection is to choose the sum of the TSpec's of all the individual
flows being aggregated (see [Wro97b] for a discussion on how TSpec's
are to be summed). Similarly, the TSpec specified in the FLOWSPEC
of the RESV messages for the tunnel should again be chosen to ensure
that the aggregated flows receive a level of service consistent with
their individual requests. One option is to again select the sum
of individual FLOWSPEC's, although as mentioned above the potential
benefits of statistical multiplexing may allow a lower reservation
level.
Irrespective of the aggregate reservation level specified, satisfying
the QoS guarantees of individual flows is also predicated on the
``proper'' handling of excess traffic, i.e., packets from each flow
that do not conform to their individual TSpec. Specifically, excess
traffic MUST NOT be forwarded onto the RSVP tunnel, unless some
form of explicit identification of excess traffic is provided. For
example, this could be achieved through the use of a bit from the TOS
field in the IP header of packets as suggested in Section 3.2.
The case of a Guaranteed Service Tunnel is somewhat more involved.
There are two issues that need to be addressed. The first is the
update of the ADSPEC in the PATH messages of individual flows at
the egress router (see [SPG97] for details on the use of ADSPEC).
The second is the selection of appropriate TSpec and RSpec for the
tunnel, so that the delay bounds of all individual flows can be
guaranteed. The handling of these two issues are not independent,
and there are many possible solutions. In this document, we outline
only one of several alternatives.
The update of the ADSPEC can be done as described before, using the
ADSPEC values of the tunnel. The determination of appropriate TSpec
and RSpec values for the tunnel, essentially follows the method
described in [RG97]. Specifically, the TSpec used for the tunnel
needs to be at least the ``sum'' of the TSpec's of the individual
flows. Similarly, the reserved rate R of the RSpec is determined
using eqs. (6) and (7) of [RG97], with the only difference that the
individual delay bounds used in eq. (7) are only for the portion of
the flows paths that coincide with the tunnel. This partial delay
bound for individual flows is readily computed from the TSpec of
individual flows, their RSpec, and the error terms for the portion of
their path that corresponds to the tunnel.
Guerin et al. Expires 26 May 1998 [Page 8]
Internet Draft Aggregating RSVP-based QoS Requests 21 November 1997
It should be pointed out that as mentioned in [RG97], the resulting
aggregate reservation rate for the tunnel can be either smaller or
bigger than the sum of the individual reservation rates. Another
point worth noting concerns the possible use of the slack term, in
particular when individual flows specify a non-zero slack and a
reservation rate R equal to their token rate r, i.e., they could
tolerate a higher delay but cannot ask for a lower rate. In the case
of a tunnel, the slack could be used to increase the individual delay
bound for that flow used in eq. (7), provided that the SUM of the
token rates of individual flows remains smaller than or equal to the
aggregate reservation rate.
4.2. TOS Field Based Aggregation
The case of TOS based QoS aggregation is different from that of
a tunnel because the egress point associated with a particular
flow is not identified *a priori* at the ingress router. This
has the advantage of eliminating the need for an ingress router
to continuously interact with routing to monitor possible changes
in egress routers and mapping of individual flows into tunnels.
However, this means that some other mechanisms are needed to ensure
that the appropriate amount of resources is reserved for RSVP flows
between the associated ingress and egress routers.
There are many possible approaches that one can follow, and in
this document we describe two, which we feel represent reasonable
trade-offs between simplicity and minimization of backbone overhead.
Other alternatives are clearly possible. In both approaches, as
in the tunneling case, a key goal is to avoid or at least minimize
awareness and/or processing of individual flows in the backbone.
Satisfying this goal has several requirements and implications:
- Disable processing of (most) individual RSVP messages in the
backbone, while still allowing their identification when they
arrive at egress or ingress routers.
- Identify transparently, i.e., without relying on interactions
with routing, the egress routers corresponding to individual
flows entering the backbone at an ingress router.
- Reserve the appropriate amount of resources on backbone links to
satisfy the requirements of individual flows routed over them.
- Properly update RSVP PATH messages of individual flows at egress
routers.
Guerin et al. Expires 26 May 1998 [Page 9]
Internet Draft Aggregating RSVP-based QoS Requests 21 November 1997
In what follows, we describe two possible approaches to achieving
those goals.
4.2.1. Ingress-Egress Aggregation: Method 1
Next, we describe a first approach, and the steps performed at
ingress and egress routers to both identify each other and ensure
proper aggregation of flows and allocation of resources between them.
- For new flows, the ingress router starts forwarding
``individual'' PATH messages carrying a Policy Object containing
its IP address. Receipt of those individual PATH messages
provides the associated egress routers with the identify of the
ingress router for the flow. The individual PATH messages are
initially processed by the backbone routers, and reach the egress
router with updated ADSPEC information.
- Upon receiving an ``individual'' PATH message with a policy
object specifying a new ingress router, the egress router logs
the association between the flow and the ingress router and
forwards the PATH message.
- Upon receipt of a RESV message (2) for a flow, the egress router
forwards the ``individual'' RESV message with a Policy Object
specifying its IP address. The Policy Object will eventually be
delivered to the ingress router, and inform it of the identity of
the egress router associated with the flow.
- Upon receipt of a RESV message identifying a new egress or
when the ingress router deems there are sufficient flows to a
given egress to consider aggregating them, it starts sending
PATH message destined to this egress and representing the
aggregation of all flows destined to it. At the same time, the
ingress router starts sending the PATH messages corresponding to
individual flows, in a format that ``hides'' them from backbone
routers (more on this below) but not the egress router.
- Upon receipt of a PATH message destined to itself, the egress
router sends a RESV message with an aggregate reservation for all
the flows it has logged as coming from the associated ingress
----------------------------
2. Alternatively, the egress router could generate a ``fake'', e.g.,
near zero reservation, RESV
message immediately after receiving the first PATH message. This has
the benefit of faster awareness about the egress at the ingress.
Guerin et al. Expires 26 May 1998 [Page 10]
Internet Draft Aggregating RSVP-based QoS Requests 21 November 1997
router. At the same time, it starts sending RESV messages for
the individual flows directly to the ingress router. This
ensures that they will not be processed by backbone routers, and
any existing reservations for individual flows in the backbone
will time out. Note that to lower the potential for call
admission failure, the egress router may want to progressively
increase the reservation level in its aggregate RESV message.
This may give it a better chance of recapturing bandwidth as it
is being released, when reservation states of individual flows
time out.
- Upon receipt of ``hidden'' PATH messages for individual flows,
the egress router changes them back to ``standard'' PATH messages
and updates them with the ADSPEC information from the PATH
message originated by the associated ingress router before
forwarding them downstream.
- Upon receipt of RESV messages for individual flows from a known
egress router, the ingress router simply forwards them upstream.
The above steps ensure that ingress and egress routers become aware
of each other without having to directly query routing, and also
ultimately removes awareness of individual flows in backbone routers.
However, it is still necessary to describe how route changes within
the backbone are handled. This is tightly coupled to the approach
used to ``hide'' RSVP PATH messages in the backbone, and we therefore
describe this next.
In the case of tunnels, individual RSVP messages were ``hidden''
on backbone links because they were encapsulated within another IP
header. As a result backbone routers would forward them as regular
IP packets. Furthermore, because the destination address in the
encapsulating IP header was that of the egress (ingress) router,
decapsulation would be performed and ensure proper identification and
processing of the RSVP messages. Such a solution is not applicable
in the case of TOS based aggregation, because of the decoupling from
routing, i.e., identity of egress or ingress, if known, cannot be
used to ensure delivery of RSVP messages
There are several possible options to overcome those problems while
avoiding processing of RSVP messages from individual flows in the
backbone. Processing of RSVP (PATH) messages from individual flows
in the backbone can be avoided simply by hiding the information
used to trigger RSVP processing, i.e., turn the router-alert option
[Kat97, KAPJ97] off at the ingress router. The problem is then that
without the router-alert option on, the egress router will also fail
to identify, and therefore intercept and process those PATH messages.
Guerin et al. Expires 26 May 1998 [Page 11]
Internet Draft Aggregating RSVP-based QoS Requests 21 November 1997
There are several possible solutions to this problem. One is
to use some other bit pattern in the IP header, that can be used
by egress routers to identify RSVP PATH messages from individual
flows. For example, a TOS bit combination could be assigned to
indicate ``aggregated control information.'' Routers responsible
for de-aggregating control information, e.g., egress routers, would
then intercept such packets, while other routers (backbone routers)
would ignore them. Another option is to require that egress routers
examine the protocol number of all arriving packets, even when
the router alert option is not set. This may, however, impose a
significant performance penalty. A third option is to keep the
router alert option set, but use a different protocol number inside
the backbone. Backbone routers would still intercept RSVP PATH
messages from individual flows, but not need to process them any
further, i.e., upon identifying the new protocol number they would
simply forward the packet on. A last option is to define a *new*
router alert option for ``Unaggregated RSVP'' messages, which would
be silently ignored by backbone routers, but recognized by access
(ingress/egress) routers.
This last alternative (see Appendix A for additional details)
appears to provide a reasonable trade-off, that ensures the required
functionality at egress routers while keeping the backbone overhead
reasonable.
Assuming that one of the above mechanisms is being used, PATH
messages for individual flows are now being automatically delivered
directly from ingress routers to the appropriate egress routers.
However, note that PATH messages are not being processed at any of
the backbone routers they traverse. The main implication for the
egress is that the ADSPEC field of the PATH messages has not been
updated to reflect the characteristic of the backbone path they have
traversed. As a result, they cannot be readily propagated forward
by the egress router, unless the information needed to properly
update their ADSPEC is *already* available at the egress router.
This is one of the motivations for the above choice of initially
sending individual PATH messages into the backbone, as this enables
the egress to first acquire the necessary information to update the
ADSPEC of ``hidden'' PATH messages. However, this approach does not
address the problem in case of route changes in the backbone.
Route changes in the backbone result in ``hidden'' PATH messages
being delivered to a *new* new egress, without being preceded by
corresponding ``clear'' PATH messages. As a result, the new egress
does not have the necessary information to update the ADSPEC of the
``hidden'' PATH messages it starts receiving. Hence, those messages
cannot be propagated forward. In order to address this problem,
the ingress router needs to become aware of the route change. The
Guerin et al. Expires 26 May 1998 [Page 12]
Internet Draft Aggregating RSVP-based QoS Requests 21 November 1997
simplest approach is to rely on RSVP soft states. Basically, the
ingress router will detect that it stops receiving RESV messages from
the old egress routers (at least for the flows affected by the route
change). It can then use that information as a trigger to start
forwarding the PATH messages of those flows again as *regular* RSVP
PATH messages. As a result, they will be processed by intermediate
backbone routers, and we are back to the initial case described
above.
4.2.2. Ingress-Egress Aggregation: Method 2
In this section, we describe a second alternative, which is mostly a
variation on the general method described in the previous section.
The main motivation for this variation is to avoid *all* processing
of individual RSVP flows in the backbone. This is desirable as
even the limited processing of individual RSVP flows required from
backbone routers by method 1, can represent a substantial processing
load when flows are of short duration. In addition, this second
method can avoid reliance on Policy Objects.
The main difference with the previous method is that the PATH
messages from individual flows are not sent directly in the backbone.
Instead, they are always forwarded as ``hidden''. The main issue is
then to determine how to inform the ingress router of the identity
of the egress router associated with each individual flow, without
relying on explicit queries to routing. We describe next, the
different steps involved in addressing this issue.
- Upon receipt of a new PATH message, the ingress router forwards
it as ``hidden'' into the backbone.
- On receipt of a hidden PATH message for a new flow, the
egress router immediately notifies the ingress router of its
existence (the identity of the ingress is carried in the PHOP
of the PATH message). This notification can take several
forms. One possibility is for the egress router to generate
a PATH_ERR message (with some appropriate new error code)
directly destined to the ingress router. Another possibility
is for the egress router to generate a ``fake'' RESV message
with near-zero reservation (FLOWSPEC). Note that as discussed
earlier, ``hidden'' PATH messages cannot be forwarded until the
information needed to update their ADSPEC is available (more on
this below).
- On receipt of a ``fake'' RESV or a PATH_ERR from a new egress,
the ingress proceeds to send a ``regular'' aggregate PATH message
to that egress.
Guerin et al. Expires 26 May 1998 [Page 13]
Internet Draft Aggregating RSVP-based QoS Requests 21 November 1997
- On receipt of an aggregate PATH message (destined to itself), the
egress now has the information necessary to update the ADSPEC of
the individual PATH message and can start forwarding it. The
main disadvantage here is the latency incurred in forwarding the
individual PATH message. However, this latency is typically only
incurred by the first flow from a given ingress. The egress can
use the ADSPEC from the aggregate PATH message to update and
immediately forward the PATH messages of subsequent flows from
that ingress.
- On receipt of a new RESV message for an individual flow, the
egress sends a RESV message associated with the aggregate PATH
from the corresponding ingress (or updates an existing RESV).
The individual RESV messages are then forwarded directly to the
ingress router.
As mentioned earlier, the method embodied in the above steps avoids
any processing of individual flows in the backbone. The cost is an
increased latency in propagating the first PATH message of the first
flow from the associated ingress.
4.2.3. Setting of Aggregate Reservations
Proper selection of appropriate aggregate reservation levels requires
some care, especially for Guaranteed Service flows. For Controlled
Load flows, it is only necessary that in backbone routers the queue
assigned to Controlled Load traffic, be allocated the proper service
rate. Since rate is an additive quantity, aggregate reservations
can be based on the sum of the FLOWSPECs of individual flows. The
situation is again more complex for Guaranteed Service flows.
The main difference with the tunnel-based case, is that on any link
in the backbone the overall aggregation of packets/flows with the
same TOS value (corresponding to the Guaranteed Service) is not know
to either the ingress or egress routers associated with individual
RSVP flows whose route through the backbone includes that link. As
a result, the egress router cannot use the approach of Section 4.1.1
to determine an appropriate aggregate service rate, that will ensure
that all individual delay bounds are met.
In order to support aggregated Guaranteed Service flows in this
setting, it is necessary to change the ``node model'' used to
represent the backbone. Specifically, an approach similar to the
one used in the ISSLL drafts to account for ATM networks, can be
used. It amounts to representing the backbone as a delay only node.
In other words, the backbone only contributes to the D error term
of the ADSPEC and not the C term. The main difference with an
Guerin et al. Expires 26 May 1998 [Page 14]
Internet Draft Aggregating RSVP-based QoS Requests 21 November 1997
ATM network is that, contrary to ATM switches, individual backbone
routers will update the ADSPEC in PATH messages. In order to ensure
a behavior consistent with that of a delay-only node, each individual
router needs to only update the D error term of the ADSPEC of PATH
messages it processes. The implication of this behavior is that the
scheduling and call admission support for Guaranteed Service flows in
backbone routers, will be based on ensuring a fixed delay upper bound
for the TOS queue assigned to Guaranteed Service packets. This delay
upper bound will then be the quantity used to update the D error
term in the ADSPEC field of PATH messages.
5. Conclusion and Recommendations
In this draft we have outlined issues and proposed possible
approaches to allow aggregation of individual RSVP flows, without
precluding support for individual reservations where available. This
can enable delivery of the end-to-end and per flow QoS guarantees
supported by RSVP and the Int-Serv Services, while avoiding possible
scalability limitations.
As a result of this exercise, several requirements emerged to
support the different aggregation methods that were discussed. These
requirements are summarized below':
- Allocation of one bit from the TOS field of the IP header to
specify in-profile and out-of-profile packets.
- Allocation of one bit pattern from the TOS field that can be
mapped to the Controlled Load service, and at least one bit
pattern from the TOS field that can be mapped to the Guaranteed
Service (two would be preferable to provide some granularity in
the delay bounds for Guaranteed Service flows).
- Support for a mechanism to selectively ``hide'' RSVP control
messages. Specifically, the preferred mechanism is through
the introduction of an new Router Alert option, that can be
selectively recognized or ignored in routers.
References
[Boy97] J. Boyle. RSVP extensions for CIDR aggregated data flows,
(draft-rsvp-cidr-ext-00.txt). Internet draft (work in
progress), Internet Engineering Task Force, February 1997.
[Bra97] S. Bradner. Internet protocol quality of service problem
statement, (draft-bradner-qos-problem-00.txt). Internet
Guerin et al. Expires 26 May 1998 [Page 15]
Internet Draft Aggregating RSVP-based QoS Requests 21 November 1997
draft (work in progress), Internet Engineering Task Force,
September 1997.
[BV97] S. Berson and S. Vincent. A ``classy'' approach to
aggregation for integrated services,
(draft-berson-classy-approach-00.txt). Internet draft
(work in progress), Internet Engineering Task Force, March
1997.
[BZB+97] R. Braden, L. Zhang, S. Berson, S. Herzog, and S. Jamin.
Resource reSerVation Protocol (RSVP) version 1, functional
specification. Request for comments, rfc 2205, (proposed
standard), Internet Engineering Task Force, September 1997.
[CW97] D. Clark and J. Wroclawski. An approach to service
allocation in the Internet, (draft-clark-diff-svc-alloc-00.txt).
Internet draft (work in progress), Internet Engineering
Task Force, July 1997.
[Hei97] J. Heinanen. Use of the IPv4 TOS octet to support
differential services, (draft-heinanen-diff-tos-octet-00.txt).
Internet draft (work in progress), Internet Engineering
Task Force, October 1997.
[KAPJ97] D. Katz, R. Atkinson, C. Partridge, and A. Jackson. IP
router alert option, (draft-ietf-ipngwg-ipv6-router-alert-03.txt).
Internet draft (work in progress), Internet Engineering
Task Force, July 1997.
[Kat97] D. Katz. IP router alert option. Request for comments,
rfc 2113, (proposed standard), Internet Engineering Task
Force, February 1997.
[Kil97] K. Kilkki. Simple integrated media access (SIMA).
(draft-kalevi-simple-media-access-01.txt). Internet draft
(work in progress), Internet Engineering Task Force, June
1997.
[Pos81] J. Postel. Internet protocol. Request for comments, rfc
791, (standard), Internet Engineering Task Force, September
1981.
[RG97] S. Rampal and R. Guerin. Flow grouping for reducing
reservation requirements for Guaranteed Delay service,
(draft-rampal-flow-delay-service-01.txt). Internet draft
(work in progress), Internet Engineering Task Force, July
1997.
Guerin et al. Expires 26 May 1998 [Page 16]
Internet Draft Aggregating RSVP-based QoS Requests 21 November 1997
[SPG97] S. Shenker, C. Partridge, and R. Guerin. Specification of
guaranteed quality of service. Request for comments, rfc
2212, (proposed standard), Internet Engineering Task Force,
September 1997.
[Wro97a] J. Wroclawski. Specification of the controlled-load
network element service. Request for comments, rfc 2211,
(proposed standard), Internet Engineering Task Force,
September 1997.
[Wro97b] J. Wroclawski. The use of RSVP with IETF integrated
services. Request for comments, rfc 2210, (proposed
standard), Internet Engineering Task Force, September 1997.
A. Router Alert Options for Concealing ``Individual'' PATH Messages
As discussed in Section 4.2, the scalability of RSVP is improved
when using TOS field based aggregation if the PATH messages from
individual applications are concealed from the interior routers in
the backbone. PATH messages are addressed either to a destination
host or multicast group and are transmitted with the IP router alert
option as defined in [Kat97] or [KAPJ97]. This allows routers along
their transit path to intercept the packets for RSVP processing.
To prevent the backbone routers from intercepting and processing
the PATH messages from individual applications, while allowing the
aggregating egress routers to recognize and intercept them, a new
router alert option value may be used.
The syntax of the IPv4 router alert option is defined as follows
[Kat97]:
A.1. IPv4 Syntax
The Router Alert option has the following format:
+--------+--------+--------+--------+
|10010100|00000100| 2 octet value |
+--------+--------+--------+--------+
Type:
Copied flag: 1 (all fragments must carry the option)
Option class: 0 (control)
Option number: 20 (decimal)
Length: 4
Guerin et al. Expires 26 May 1998 [Page 17]
Internet Draft Aggregating RSVP-based QoS Requests 21 November 1997
Value: A two octet code with the following values:
0 - Router shall examine packet
1-65535 - Reserved
The specification states that ``Unrecognized value fields shall be
silently ignored''.
The syntax of the IPv6 router alert option is defined as follows
[KAPJ97]:
A.2. IPv6 Syntax
The router alert option has the following format:
+--------+--------+--------+--------+
|00| TBD | Len= 2 | Value (2 octets)|
+--------+--------+--------+--------+
``TBD'' is the Hop-by-Hop Option Type number (To be allocated by the
IANA).
Nodes not recognizing this option type SHOULD skip over this option
and continue processing the header. This option MUST NOT change en
route. There MUST only be one option of this type, regardless of
value, per Hop-by-Hop header.
Value: A 2 octet code in network byte order with the
following values:
0 Datagram contains ICMPv6 Group Membership message.
1 Datagram contains RSVP message.
2 Datagram contains an Active Networks message
\cite{ANEP97}.
3-65535 Reserved to IANA for future use.
New value fields must be registered with the IANA.
This specification states that ``Unrecognized value fields MUST be
silently ignored and the processing of the header continued''.
There are two alternatives which will satisfy the requirement to
``hide'' application PATH messages (when necessary) from the backbone
routers:
Guerin et al. Expires 26 May 1998 [Page 18]
Internet Draft Aggregating RSVP-based QoS Requests 21 November 1997
- Define a 2 octet router alert option value for both IPv4 and IPv6
which signifies that the datagram contains an ``Unaggregated RSVP
Message''. The router should silently ignore this router alert
option and continue to forward the packet unless specifically
configured to recognize and intercept it.
- Define a 2 octet router alert option value for both IPv4 and IPv6
which signifies that the router should ``Ignore by Default''.
The router should silently ignore this router alert option and
continue to forward the packet unless specifically configured to
recognize and intercept it.
PATH messages from individual applications would be transmitted by
the aggregating ingress router using either router alert option
value (whichever is defined) whenever it employs TOS field based
aggregation to a particular egress router. Aggregated PATH messages
to that router would be transmitted with the default router alert
option value used for RSVP. The backbone routers would be configured
to ignore router alert options using this new option value. The
aggregating egress routers would be configured to intercept packets
transmitted with the new router alert option value.
Authors' Address
Roch Guerin
IBM T.J. Watson Research Center
P.O. Box 704
Yorktown Heights, NY 10598
Phone: +1 914 784-7038
Fax: +1 914 784-6205
Email: guerin@watson.ibm.com
Steven Blake
E95/664
IBM Corporation
800 Park Offices Drive
Research Triangle Park, NC 27709
Phone: +1-919-254-2030
Fax: +1-919-254-5483
Email: slblake@raleigh.ibm.com
Guerin et al. Expires 26 May 1998 [Page 19]
Internet Draft Aggregating RSVP-based QoS Requests 21 November 1997
Shai Herzog
IPHighway
Email: herzog@iphighway.com
Guerin et al. Expires 26 May 1998 [Page 20]