[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
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).


   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 <draft-almesberger-srp-00.txt>. 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

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

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,
       Technical Report SSC/1998/009, EPFL, March 1998.
     [2]  IETF, Differentiated Services (diffserv) working group.
     [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
   email: Werner.Almesberger,Leboudec@epfl.ch

   Tiziana Ferrari
   DEIS, University of Bologna
   viale Risorgimento, 2
   I-40136 Bologna
   Italian National Inst. for Nuclear Physics/CNAF
   viale Berti Pichat, 6/2
   I-40127 Bologna
   email: Tiziana.Ferrari@cnaf.infn.it

Almesberger, Ferrari & Le Boudec          Expires 9/98          [Page 4]