Network Working Group R. Braden Request for Comments: 1633 ISI Category: Informational D. Clark MIT S. Shenker Xerox PARC June 1994 Integrated Services in the Internet Architecture: an Overview Status of this Memo This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Abstract This memo discusses a proposed extension to the Internet architecture and protocols to provide integrated services, i.e., to support real- time as well as the current non-real-time service of IP. This extension is necessary to meet the growing need for real-time service for a variety of new applications, including teleconferencing, remote seminars, telescience, and distributed simulation. This memo represents the direct product of recent work by Dave Clark, Scott Shenker, Lixia Zhang, Deborah Estrin, Sugih Jamin, John Wroclawski, Shai Herzog, and Bob Braden, and indirectly draws upon the work of many others. Table of Contents 1. Introduction ...................................................2 2. Elements of the Architecture ...................................3 2.1 Integrated Services Model ..................................3 2.2 Reference Implementation Framework .........................6 3. Integrated Services Model ......................................11 3.1 Quality of Service Requirements ............................12 3.2 Resource-Sharing Requirements and Service Models ...........16 3.3 Packet Dropping ............................................18 3.4 Usage Feedback .............................................19 3.5 Reservation Model ..........................................19 4. Traffic Control Mechanisms .....................................20 4.1 Basic Functions ............................................20 4.2 Applying the Mechanisms ....................................23 4.3 An example .................................................24 5. Reservation Setup Protocol .....................................25 Braden, Clark & Shenker [Page 1] RFC 1633 Integrated Services Architecture June 1994 5.1 RSVP Overview ..............................................25 5.2 Routing and Reservations ...................................28 6. Acknowledgments ................................................30 References ........................................................31 Security Considerations ...........................................32 Authors' Addresses ................................................33 1. Introduction The multicasts of IETF meetings across the Internet have formed a large-scale experiment in sending digitized voice and video through a packet-switched infrastructure. These highly-visible experiments have depended upon three enabling technologies. (1) Many modern workstations now come equipped with built-in multimedia hardware, including audio codecs and video frame-grabbers, and the necessary video gear is now inexpensive. (2) IP multicasting, which is not yet generally available in commercial routers, is being provided by the MBONE, a temporary "multicast backbone". (3) Highly-sophisticated digital audio and video applications have been developed. These experiments also showed that an important technical element is still missing: real-time applications often do not work well across the Internet because of variable queueing delays and congestion losses. The Internet, as originally conceived, offers only a very simple quality of service (QoS), point-to-point best-effort data delivery. Before real-time applications such as remote video, multimedia conferencing, visualization, and virtual reality can be broadly used, the Internet infrastructure must be modified to support real-time QoS, which provides some control over end-to-end packet delays. This extension must be designed from the beginning for multicasting; simply generalizing from the unicast (point-to-point) case does not work. Real-time QoS is not the only issue for a next generation of traffic management in the Internet. Network operators are requesting the ability to control the sharing of bandwidth on a particular link among different traffic classes. They want to be able to divide traffic into a few administrative classes and assign to each a minimum percentage of the link bandwidth under conditions of overload, while allowing "unused" bandwidth to be available at other times. These classes may represent different user groups or different protocol families, for example. Such a management facility is commonly called controlled link-sharing. We use the term integrated services (IS) for an Internet service model that includes best-effort service, real-time service, and controlled link sharing. The requirements and mechanisms for integrated services have been the subjects of much discussion and research over the past several years Braden, Clark & Shenker [Page 2] RFC 1633 Integrated Services Architecture June 1994 (the literature is much too large to list even a representative sample here; see the references in [CSZ92, Floyd92, Jacobson91, JSCZ93, Partridge92, SCZ93, RSVP93a] for a partial list). This work has led to the unified approach to integrated services support that is described in this memo. We believe that it is now time to begin the engineering that must precede deployment of integrated services in the Internet. Section 2 of this memo introduces the elements of an IS extension of the Internet. Section 3 discusses real-time service models [SCZ93a, SCZ93b]. Section 4 discusses traffic control, the forwarding algorithms to be used in routers [CSZ92]. Section 5 discusses the design of RSVP, a resource setup protocol compatible with the assumptions of our IS model [RSVP93a, RSVP93b]. 2. Elements of the Architecture The fundamental service model of the Internet, as embodied in the best-effort delivery service of IP, has been unchanged since the beginning of the Internet research project 20 years ago [CerfKahn74]. We are now proposing to alter that model to encompass integrated service. From an academic viewpoint, changing the service model of the Internet is a major undertaking; however, its impact is mitigated by the fact that we wish only to extend the original architecture. The new components and mechanisms to be added will supplement but not replace the basic IP service. Abstractly, the proposed architectural extension is comprised of two elements: (1) an extended service model, which we call the IS model, and (2) a reference implementation framework, which gives us a set of vocabulary and a generic program organization to realize the IS model. It is important to separate the service model, which defines the externally visible behavior, from the discussion of the implementation, which may (and should) change during the life of the service model. However, the two are related; to make the service model credible, it is useful to provide an example of how it might be realized. 2.1 Integrated Services Model The IS model we are proposing includes two sorts of service targeted towards real-time traffic: guaranteed and predictive service. It integrates these services with controlled link- sharing, and it is designed to work well with multicast as well as unicast. Deferring a summary of the IS model to Section 3, we first discuss some key assumptions behind the model. Braden, Clark & Shenker [Page 3] RFC 1633 Integrated Services Architecture June 1994 The first assumption is that resources (e.g., bandwidth) must be explicitly managed in order to meet application requirements. This implies that "resource reservation" and "admission control" are key building blocks of the service. An alternative approach, which we reject, is to attempt to support real-time traffic without any explicit changes to the Internet service model. The essence of real-time service is the requirement for some service guarantees, and we argue that guarantees cannot be achieved without reservations. The term "guarantee" here is to be broadly interpreted; they may be absolute or statistical, strict or approximate. However, the user must be able to get a service whose quality is sufficiently predictable that the application can operate in an acceptable way over a duration of time determined by the user. Again, "sufficiently" and "acceptable" are vague terms. In general, stricter guarantees have a higher cost in resources that are made unavailable for sharing with others. The following arguments have been raised against resource guarantees in the Internet. o "Bandwidth will be infinite." The incredibly large carrying capacity of an optical fiber leads some to conclude that in the future bandwidth will be so abundant, ubiquitous, and cheap that there will be no communication delays other than the speed of light, and therefore there will be no need to reserve resources. However, we believe that this will be impossible in the short term and unlikely in the medium term. While raw bandwidth may seem inexpensive, bandwidth provided as a network service is not likely to become so cheap that wasting it will be the most cost-effective design principle. Even if low-cost bandwidth does eventually become commonly available, we do not accept that it will be available "everywhere" in the Internet. Unless we provide for the possibility of dealing with congested links, then real-time services will simply be precluded in those cases. We find that restriction unacceptable. o "Simple priority is sufficient." It is true that simply giving higher priority to real-time traffic would lead to adequate real-time service at some times and under some conditions. But priority is an implementation mechanism, not a service model. If we define the service by means of a specific mechanism, we may not get the exact features we want. In the case of simple priority, Braden, Clark & Shenker [Page 4] RFC 1633 Integrated Services Architecture June 1994 the issue is that as soon as there are too many real-time streams competing for the higher priority, every stream is degraded. Restricting our service to this single failure mode is unacceptable. In some cases, users will demand that some streams succeed while some new requests receive a "busy signal". o "Applications can adapt." The development of adaptive real-time applications, such as Jacobson's audio program VAT, does not eliminate the need to bound packet delivery time. Human requirements for interaction and intelligibility limit the possible range of adaptation to network delays. We have seen in real experiments that, while VAT can adapt to network delays of many seconds, the users find that interaction is impossible in these cases. We conclude that there is an inescapable requirement for routers to be able to reserve resources, in order to provide special QoS for specific user packet streams, or "flows". This in turn requires flow-specific state in the routers, which represents an important and fundamental change to the Internet model. The Internet architecture was been founded on the concept that all flow-related state should be in the end systems [Clark88]. Designing the TCP/IP protocol suite on this concept led to a robustness that is one of the keys to its success. In section 5 we discuss how the flow state added to the routers for resource reservation can be made "soft", to preserve the robustness of the Internet protocol suite. There is a real-world side effect of resource reservation in routers. Since it implies that some users are getting privileged service, resource reservation will need enforcement of policy and administrative controls. This in turn will lead to two kinds of authentication requirements: authentication of users who make reservation requests, and authentication of packets that use the reserved resources. However, these issues are not unique to "IS"; other aspects of the evolution of the Internet, including commercialization and commercial security, are leading to the same requirements. We do not discuss the issues of policy or security further in this memo, but they will require attention. We make another fundamental assumption, that it is desirable to use the Internet as a common infrastructure to support both non- real-time and real-time communication. One could alternatively build an entirely new, parallel infrastructure for real-time services, leaving the Internet unchanged. We reject this Braden, Clark & Shenker [Page 5] RFC 1633 Integrated Services Architecture June 1994 approach, as it would lose the significant advantages of statistical sharing between real-time and non-real-time traffic, and it would be much more complex to build and administer than a common infrastructure. In addition to this assumption of common infrastructure, we adopt a unified protocol stack model, employing a single internet-layer protocol for both real-time and non-real-time service. Thus, we propose to use the existing internet-layer protocol (e.g., IP or CLNP) for real-time data. Another approach would be to add a new real-time protocol in the internet layer [ST2-90]. Our unified stack approach provides economy of mechanism, and it allows us to fold controlled link-sharing in easily. It also handles the problem of partial coverage, i.e., allowing interoperation between IS-capable Internet systems and systems that have not been extended, without the complexity of tunneling. We take the view that there should be a single service model for the Internet. If there were different service models in different parts of the Internet, it is very difficult to see how any end- to-end service quality statements could be made. However, a single service model does not necessarily imply a single implementation for packet scheduling or admission control. Although specific packet scheduling and admission control mechanisms that satisfy our service model have been developed, it is quite possible that other mechanisms will also satisfy the service model. The reference implementation framework, introduced below, is intended to allow discussion of implementation issues without mandating a single design. Based upon these considerations, we believe that an IS extension that includes additional flow state in routers and an explicit setup mechanism is necessary to provide the needed service. A par