RSVP and Integrated Services in the Internet: A Tutorial

1. RSVP and Integrated Services in the Internet: A Tutorial Paul P. White, University College London IEEE Communications Magazine, May 1997 Members:劉佳妮、陳駿元、魏君竹 Presenter:劉佳妮 Date:2002/12/10

2. Outline • Introduction • IETF integrated services • Guaranteed service • Controlled-Load service • RSVP(Resource reservation protocol) • Path messages • Reservation styles and merging • Slack Term • Summary

3. Introduction • The current Internet consists of a multitude of networksbuilt from various link-layer technologies and relies on the Internet Protocol (IP) to interwork between them. • IP offers an unreliable, connectionless network-layer service. • IP delivery model is often referred to as “best-effort” . • Transmission Control Protocol (TCP) required to provide end-to-end reliability.

4. Introduction(cont.) • For non-real-time Internet traffic such as File Transfer Protocol (FTP) data, the best-effort delivery model of IP has not been a problem. • Many real-time applications are delay sensitive to the point where the best-effort delivery model of IP can be inadequate. • Quality of service (QoS) with regard to bandwidth, packet delay, and loss through the RSVP.

5. IETF integrated services • In response to the growing demand for an integrated services Internet, the Internet Engineering Task Force (IETF) set up an Integrated Services (intserv) Working Group . • RSVP is one kind of QoS and the resource must be reserved along with the transmission schedling behavior. • The Intserv architecture defines two major classes of service: • Guaranteed service • Controlled-load service

6. Guaranteed service • Guaranteed Service provides an assured level of bandwidth,a firm end-to-end delay bound, and no queuing loss for conforming packets of a data flow. • It is intended for applications with stringent real-time delivery requirements, such as certain audio and video applications. • The token bucket model

7. Guaranteed service(cont.) • Leaky Bucket parameters (r,b) • r :Token bucket rate • b :Token bucket size • Tspec: • p : Peak data rate • m :Minimum policed unit • M :Maximum packet size • Rspec: • R: Reserved rate ( R>>r) • S: slack term (Signify the difference between the desired delay and the delay obtained by using reservation level R)

8. Guaranteed service(cont.) • Rspec: describes service requested from network • controlled-load: none • guaranteed: delay target • Tspec: describes flow’s traffic characteristics • average bandwidth + burstiness: token bucket filter • token rate r • bucket depth B • must have a token to send a byte • must have n tokens to send n bytes • start with no tokens • accumulate tokens at rate of r per second • can accumulate no more than B tokens

9. Guaranteed service(cont.) • Simple Delay bound : b/R • Request guarantee transmission rate is R • The amount of traffic generated over interval t is bounded by rt+b • The maximum queueing delay experienced by any packet will be bound by b/R • Multiplex Delay bound:b/R+C/R+D • The delay which depends on flow transmission rate is C. • Non-rate-dependent delay is D

10. Controlled-load service • Provides approximately the same QoS under heavy loads as under light loads. • Intended for applications that can tolerate a certain amount of loss or delay to a reasonable level. • Controlled-load service simply prioritizes the packets in the flow, ensuring that they do not wait too long in router queues as they cross the network.

11. RSVP • Resource ReSerVation Protocol. • Allows applications running in hosts to reserve resources in the Internet for their data flows. • RSVP software must be present in the receivers, sender, and routers. • Two principle characteristics of RSVP • It provides reservations for bandwidth in multicast trees(unicast is handled as a special case). • It is receiver-oriented. • RSVP is not a routing protocol and sometimes referred to as a signaling protocol that allows hosts to establish and tear-down reservations for data flows.

12. RSVP(cont.) • RSVP depends on an underlying routing protocol(unicast or multicast) to determine the routes for the flows. • Operation

13. RSVP(cont.)

14. Path Message • Originate at the senders and flow downstream towards the receivers. • The principle purpose of the path messages is to let the routers know on which links they should forward the reservation messages. • Each Path message includes the following information: • Phop • Sender Template • Sender Tspec • Adspec

15. Reservation styles and merging • A reservation message specifies whether merging of reservations from the same session is permissible. • A reservation style also specifies from which senders in a session the receiver desires to receive data. • There are currently three reservation styles • Fixed-filter style(FF) • Wildcard-filter style(WF) • Shared-explicit style(SE)

16. Fixed-filter style(FF) • It specifies a list of senders from which it wants to receive a data flow along with a single bandwidth reservation. These reservation are distinct, i.e., they are not to be shared.

17. Wildcard-filter style(WF) • It is telling the network that it wants to receive all flows from all upstream senders in the session and that its bandwidth reservation is to be shared among the senders.

18. Shared-explicit style(SE) • It specifies a list of senders from which it wants to receive a data flow along with a single bandwidth reservation. This reservation is to be shared among all the senders in the list.

20. Slack Term • Slack Term which S(ms) as well as the amount of bandwidth, R to be installed in each router along the path. • S represents the amount by which the end-to-end delay bound .

21. Slack Term(cont.) • R3 can only reserve a value of 2Mb/s which if used as the new reservation value in the propagated Resv message will cause an increase in the end to end delay bound di. • The request can be accepted and a reservation of 2Mb/s installed in R3.(R=2Mb/s, S2=S1-di) • R2 and R1 also reserving 2Mb/s.

22. Summary • In this tutorial we have looked at thecontrolled-load and guaranteed service classes that can provide end applications with enhanced QoS commitments over conventional best-effort delivery. • RSVP can be used by end applications to select and invoke the appropriate class and QoS level.