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]