INTERNET-DRAFT Werner Almesberger Jean-Yves Le Boudec EPFL ICA, Switzerland Tiziana Ferrari DEIS, Uni Bologna, INFN/CNAF, Italy March 1998 SRP essentials 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 inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This paper gives a succinct description of the design of SRP, a highly scalable resource reservation protocol for Internet traffic. 1. About this paper This paper is a short introduction to the "Scalable Reservation Protocol" (SRP). It aims to provide background information for discussions related to SRP and is, due to focussing only on the most essential issues, necessarily incomplete. Readers interested in all the gory details are kindly referred to [1]. This document is a summary of the current design of SRP. It is not just an update of . We also tried to align it better with concepts and terminology currently used in the diffserv [2] working group of IETF. The Web page of SRP is at http://lrcwww.epfl.ch/srp/ Almesberger, Ferrari & Le Boudec Expires 9/98 [Page 1] INTERNET-DRAFT draft-watfjyl-srp-00.txt March 1998 2. Overview SRP provides a light-weight reservation mechanism for adaptive multimedia applications [3]. Our main focus is on good scalability to very large numbers of individual flows. End systems (i.e. senders and destinations) actively participate in maintaining reservations, but routers can still control their conformance. Routers aggregate flows and monitor the aggregate to estimate the resources needed to support present and new reservations. There is no explicit signaling of flow parameters. 3. End-to-end service Many adaptive multimedia applications require a well-defined fraction of their traffic to reach the destination and to do so in a timely way. We call this fraction the minimum rate these applications need in order to operate properly. SRP aims to allow such applications to make a dependable reservation of their minimum rate. The sender can expect that, as long as it adheres to the agreed-upon profile, no RESERVED packets will be lost due to congestion. Furthermore, forwarding of RESERVED packets will have priority over best-effort traffic. 4. Reservation mechanism A source that wishes to make a reservation starts by sending data packets marked as REQUEST packets to the destination. Packets marked as REQUEST are subject to packet admission control by routers, based on the following principle. Routers monitor the aggregate flows of RESERVED packets and maintain a running estimate of what level of resources is required to serve them with a good quality of service. The resources are bandwidth and buffer on outgoing links, plus any internal resources as required by the router architecture. Quality of service is loss ratio and delay, and is defined statically. When receiving a REQUEST packet, a router determines whether hypothetically adding this packet to the flow of RESERVED packets would yield an acceptable value of the estimator. If so, the REQUEST packet is accepted and forwarded towards the destination, while still keeping the status of a REQUEST packet; the router must also update the estimator as if the packet had been received as RESERVED. In the opposite case, the REQUEST packet is degraded and forwarded towards the destination, and the estimator is not updated. Degrading a REQUEST packet means assigning it a lower traffic class, such as best effort. A packet sent as REQUEST will reach the destination as REQUEST only if all routers along the path have accepted the packet as REQUEST. Note that the choice of an estimation method is local to a router and actual estimators may differ in their principle of operation. Almesberger, Ferrari & Le Boudec Expires 9/98 [Page 2] INTERNET-DRAFT draft-watfjyl-srp-00.txt March 1998 The destination periodically sends feedback to the source indicating the rate at which REQUEST and RESERVED packets have been received. This feedback does not receive any special treatment in the network (except possibly for policing, see section "Security"). Upon reception of the feedback, the source can send packets marked as RESERVED according to a profile derived from the rate indicated in the feedback. If necessary, the source may continue to send more REQUEST packets in an attempt to increase the rate that will be indicated in subsequent feedbacks. Thus, in essence, a router accepting to forward a REQUEST packet as REQUEST allows the source to send a RESERVED packet in the future; it is thus a form of implicit reservation. 5. Aggregation Routers aggregate flows on output ports, and possibly on any contention point as required by their internal architecture. They use estimator algorithms for each aggregated flow to determine their current reservation levels and to predict the impact of accepting REQUEST packets. The exact definition of what constitutes an aggregated flow is local to a router. Likewise, senders and sources treat all flows between each pair of them as a single aggregate and use estimator algorithms for characterizing them. The estimator algorithms in routers and hosts do not need to be the same. In fact, we expect hosts to implement a fairly simple algorithm, while estimator algorithms in routers may evolve independently over time. We evaluated example host and router algorithms in [1]. 6. Further issues Further issues, such as support for multicast, are discussed in [1]. 7. Security Denial-of-service conditions may arise if flows can reserve disproportional amounts of resources or if flows can exceed their reservations. We presently consider fairness in accepting reservations a local policy issue (much like billing) which may be addressed at a future time. Sources violating the agreed upon reservations are a real threat and need to be policed. Policing can be efficiently implemented if policing points filter feedback messages and monitor the accepted reservations for the aggregate flows passing them. We assume that networks will typically perform policing only at their boundaries. Almesberger, Ferrari & Le Boudec Expires 9/98 [Page 3] INTERNET-DRAFT draft-watfjyl-srp-00.txt March 1998 8. Open issues - Definition of shaping behaviour of the source - Encoding of RESERVED and REQUEST packet types - Format of feedback (use RTCP ?) - Construction and evaluation of efficient estimator algorithms 9. References [1] Almesberger, Werner; Ferrari, Tiziana; Le Boudec, Jean-Yves. SRP: a Scalable Resource Reservation Protocol for the Internet, ftp://lrcftp.epfl.ch/pub/people/almesber/srp/srpMar98.ps.gz, Technical Report SSC/1998/009, EPFL, March 1998. [2] IETF, Differentiated Services (diffserv) working group. http://www.ietf.org/html.charters/diffserv-charter.html [3] Diot, Christophe; Huitema, Christian; Turletti, Thierry. Multimedia Applications should be Adaptive, ftp://www.inria.fr/rodeo/diot/nca-hpcs.ps.gz, HPCS'95 Workshop, August 1995. 10. Author's address Werner Almesberger Jean-Yves Le Boudec Institute for computer Communications and Applications Swiss Federal Institute of Technology (EPFL) CH-1015 Lausanne Switzerland email: Werner.Almesberger,Leboudec@epfl.ch Tiziana Ferrari DEIS, University of Bologna viale Risorgimento, 2 I-40136 Bologna Italy and Italian National Inst. for Nuclear Physics/CNAF viale Berti Pichat, 6/2 I-40127 Bologna Italy email: Tiziana.Ferrari@cnaf.infn.it Almesberger, Ferrari & Le Boudec Expires 9/98 [Page 4]