Internet Draft S. Berson
Expiration: September 1997 ISI
File: draft-berson-classy-approach-00.txt S. Vincent
ISI
A ``Classy'' Approach to Aggregation for Integrated Services
March 26, 1997
Status of 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 inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
To learn the current status of any Internet-Draft, please check the
linebreak "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
The current Integrated Services (IS) architecture has a fundamental
scaling problem in that per flow state is maintained everywhere. Our
approach is to use aggregation as a technique to address this
problem. There is a wide spectrum of approaches towards aggregation
of IS state, with different tradeoffs in the amount of state
required. This draft describes one promising approach to aggregating
IS state within defined regions of a network. Service classes are
configured on all of the routers in a region. At the edges of the
region, routers keep detailed IS state and map packets into the
configured traffic service classes. In the interior of this region,
routers need keep only a bounded amount of IS state.
Table of Contents
Berson, Vincent Expiration: September 1997 [Page 1]
Internet Draft "Classy" Aggregation March 1997
1. Introduction
In order to deploy Integrated Services (IS) in the Internet,
resources are needed in the routers to keep state and to process
packets. As currently defined [1], this state is on a per session
basis, where a session is a unicast destination or a multicast group.
Thus, widespread use of IS would mean a large amount of state at
routers in the core of the internet. This large amount of state and
related processing could overwhelm routers, so aggregation models
that do not require per-session state need to be explored. This memo
describes a particular approach to reducing this IS state.
Several types of per-session state are used with integrated services.
First, there is scheduling state that consists of the different
traffic service queues for packet forwarding. Second, there is
packet classifier state. Classifier state is used to assign each
arriving packet to a packet scheduling queue for forwarding. Third,
there is the state for the setup protocol, e.g. state carried in RSVP
PATH and RESV messages. Finally, current multicast routing
algorithms also store state, either per source and session (e.g.
DVMRP, PIM-DM) or per session shared-tree (e.g. CBT, PIM-SM). While
approaches to aggregation of routing state are similar to aggregation
of RSVP state, they are beyond the scope of this note.
Any aggregation scheme entails some tradeoffs. Keeping full
integrated services state at all routers allows the resources
dedicated to the flow of packets from each admitted session to be
isolated from the resources for packets from all other sessions.
This isolation means that resources reserved for one session, if
needed, will be used only on the reserving session. The disadvantage
of doing aggregation is the lesser degree of flow isolation,
since with aggregation many flows would share the same traffic
service class. The benefits of additional flow isolation achievable
from keeping full IS state is unknown.
2. Framework
This draft proposes an approach to reducing the amount of IS state
based on configured traffic service classes within aggregating
regions. Configuring a fixed number of traffic service classes
bounds the amount of scheduler state. Establishing aggregating
regions (described below) and storing full IS state only at the edges
reduces the classifier state and setup protocol state.
We make several assumptions:
1. We assume that an explicitly definable region (e.g. one or more
Berson, Vincent Expiration: September 1997 [Page 2]
Internet Draft "Classy" Aggregation March 1997
contiguous autonomous systems), called an "aggregating region",
will aggregate and will implement supporting mechanisms at its
boundary points.
2. We assume that the choice to aggregate and the mechanism used to
do so is an intra-domain issue, not an inter-domain issue and
therefore there can be variability across regions so long as at
the boundaries routers continue to pass along adequate messages
to support RSVP upstream and downstream.
3. We assume current multicast and unicast routing within the
aggregating region; but with no other enhancements.
3. Approach
In our approach, traffic service classes are defined at all routers
in an aggregating region. While the exact form of these traffic
service classes is the subject of continuing research, the scheduling
algorithms used by these service classes could include features such
as priority queueing and/or weighted fair queueing. Each traffic
service class is subject to admission control and traffic policing
(additional subjects of continuing research) but only at the ingress
to the region. Note that no changes to packet forwarding are needed
in the interior of the aggregating region. Similarly, no RSVP
processing is needed in the interior of the region. When an RSVP
reservation message arrives at an ingress to the region (from an
egress), and that reservation passes admission control, then packets
from that flow are assigned to a traffic service class. Data packets
belonging to a traffic class are "tagged" on entry to the aggregating
region with some identifier indicating which class of service the
packets should receive. This identifier can consist of some bits in
the packet header (e.g. type of service bits) or the packet could be
encapsulated. The tag (or encapsulation) encodes the traffic service
class that this packet will receive across the aggregating region.
Tagging or encapsulating each packet minimizes the classifier state
in the interior of the aggregating region.
In summary our approach provides for reduction of packet scheduler
state, packet classifier state, and setup protocol (e.g. RSVP) state
in the following ways. A bounded amount of packet scheduler state at
all routers in an aggregating region is achieved by using
preconfigured traffic service classes. A bounded amount of packet
classifier state at all interior routers in the aggregating region is
accomplished by tagging or encapsulating each packet with its traffic
service class. No setup protocol state at interior routers is
achieved by doing admission control and policing only at the edges of
the aggregating region.
Berson, Vincent Expiration: September 1997 [Page 3]
Internet Draft "Classy" Aggregation March 1997
4. Open Issues
Aggregation provides opportunities for increased multiplexing and
resource usage efficiency, but it also brings up several challenges
in admission control and policing. First there is an issue of how
many service classes are to be used and of how to configure the
service classes on the routers. Second, there is an issue of how and
when to assign flows to the service classes, i.e. aggregate admission
control. Finally, there is the issue of how and when to police an
aggregate reservation. Good solutions to these problems will provide
integrated services across aggregating regions with greatly reduced
state requirements.
5. Acknowledgements
This draft is the result of discussions with many people particularly
Bob Braden, Deborah Estrin, and Daniel Zappala.
REFERENCES
[1] Braden, R., Zhang, L., Berson, S., Herzog, S., and Jamin, S.,
"Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
Specification," Internet Draft, November 1996.
[2] Floyd, S., and Jacobson, V., "Link-sharing and Resource Management
Models for Packet Networks," IEEE/ACM Transactions on Networking,
Vol. 3 No. 4, pp. 365-386, August 1995.
[3] Rampal, S., "Flow Grouping for Reducing Reservation Requirements for
Guaranteed Delay Service," Internet Draft, December 1996.
Security Considerations
Security considerations have not been addressed in this draft.
Author's Address
Berson, Vincent Expiration: September 1997 [Page 4]
Internet Draft "Classy" Aggregation March 1997
Steven Berson
USC Information Sciences Institute
4676 Admiralty Way
Marina del Rey, CA 90292
Phone: +1 310 822 1511
EMail: berson@isi.edu
Subramaniam Vincent
USC Information Sciences Institute
4676 Admiralty Way
Marina del Rey, CA 90292
Phone: +1 310 822 1511
EMail: svincent@isi.edu
Berson, Vincent Expiration: September 1997 [Page 5]