Resource Reservation Protocol and Admission Control

1. Resource Reservation Protocoland Admission Control

2. Resource Management

3. Motivation • Resource management in the access networks is important: • Needed to identify and monitor the bottleneck in the networks. • Needed to allocate network resources more efficiently to support a wide variety of services. • Resource reservation might be necessary to provide QoS guarantees, but we need to address the scalability issues: • Signaling overhead; • Overhead caused by maintenance of the reservation state; Overhead can be reduced by aggregating flows or reservation requests.

4. Basic Concepts • Resource reservation and allocation; • The manageable resources • Bandwidth, buffer, CPU time, and etc.; • Traffic description, resource descriptor and SLA • The SLA • SLA parameters • Traffic level; • Provider’s responsibilities in terms of network levels (throughput, loss rate, delays and jitter); • Times of availability; • Method of measurement; • Consequences if service levels aren't met or the defined traffic levels are exceeded by the customer; • All costs involved • Traffic conditioning rules • …

5. Basic Concepts (cont’d) • Resource reservation and allocation; • The SLA (cont’d) • Service Level Specification, the details of the operational characteristics for an SLA are further defined in terms of Service Level Specifications (SLS) and/or Objectives (SLOs). • expected throughput, drop probability, latency; • constraints on the ingress and egress points at which the service is provided, indicating the `scope' of the service; • traffic profiles which must be adhered to for the requested service to be provided; • disposition of traffic submitted in excess of the specified profile; • marking and shaping services provided. • An SLO partitions an SLA into individual objectives that can be mapped into policies that can be executed. The SLOs define metrics to enforce, police, and/or monitor the SLA. Some commonly used metrics to determine whether or not an SLA is being fulfilled include component system availability (e.g., up-time and MTBF), performance (e.g., response time), and serviceability (e.g., MTTR).

6. Basic Concepts (cont’d) • Resource reservation and allocation; • The SLA (cont’d) • Traffic Conditioning Specifications • Traffic conditioning control functions that can be applied to a behavior aggregate, application flow, or other operationally useful subset of traffic, e.g., routing updates. • These may include metering, policing, shaping, and packet marking. Traffic conditioning is used to enforce agreements between DiffServ domains, for example. • A Traffic Conditioning Agreement (TCA) is an agreement specifying classifier rules and any corresponding traffic profiles and metering, marking, discarding and/or shaping rules which are to apply to the traffic streams selected by the classifier. • A TCA encompasses all of the traffic conditioning rules explicitly specified within a SLA along with all of the rules implicit from the relevant service requirements. Core: traffic description, required service and resource descriptor Issue: how to define the optimal value of the amount of the requested resource

7. Basic Concepts (cont’d) • Resource reservation and allocation; • The SLA (cont’d) • Example

8. Basic Concepts (cont’d) • Resource reservation and allocation; • Reservation mechanism and Admission control (discussed in this section); • Packet Classifier; • Policing and shaping • the enforcement mechanism; • commonly-used mechanism; • Leakey bucket; • Token bucket; • Congestion avoidance methods; • The scheduling and queuing management (discussed in next section) • Link layer mechanisms; • To implement actually the resource allocation to achieve certain QoS level;

9. RSVPD Routing Process Application Policy Control Policy Control Admissions Control Admissions Control Packet Classifier Packet Scheduler Packet Classifier Packet Scheduler The Typical Overall Structure Host Router RSVPD D A T A DATA DATA Policy control determines whether the user has administrative permission to make the reservation.

10. Principles of Resource Management Reservation Network resources are shared by users, but the sharing process is regulated by the QoS mechanism, e.g. by using admission control; Allocation Network resources are allocated, or assigned, to a user, however, the network may temporarily reallocate some of the resources to other users in case when it detects that they are not fully used or if a severe congestion situation occurs; Dedication Network resources are dedicated to each communication. There is no overbooking, nor reallocation of unused resources during the communication; Best-effort Network resources are shared by all users, and there is not any regulations at all.

11. Principles of Resource Management(cont’d) Two types of guaranteed performance: Deterministic guarantees Generally speaking, upper bounds are provided for the performance parameters; Statistical guarantees As for the performance parameters, they are determined by some average numbers observed over a period of time, generally the duration of the session. Best-effort  no guarantees Reservation  statistical guarantees Allocation  statistical or deterministic guarantees Dedication  deterministic guarantees

12. Resource Oversubscription • The obvious solution to handle peak periods is to over-provision the network, to provide surplus bandwidth capacity in anticipation of these peak data rates during high-demand periods. • Equally obvious, however, is that this is not economically viable--at least not with today's bandwidth technologies and infrastructures – and especially for WAN links. • Since peak data rates and the network regions on which they might occur are seldom possible to predict, this is not a realistic alternative anyway. • IP is necessary and bandwidth is necessary, but neither is sufficient for all application needs under all conditions. • Best effort cannot always provide a usable service, let alone an acceptable one. • Even on a relatively unloaded IP network, delivery delays can vary enough to adversely affect applications that have real-time constraints. • To provide service guarantees--some level of quantifiable reliability--IP services must be supplemented with the ability to differentiate traffic and enable different service levels for different users and applications. However, QoS mechanism is necessary!

13. Resource Reservation Protocol---TheTypical Resource Reservation Mechanism

14. Reservation protocol: RSVP Upper layer protocols and applications IP service interface IP ICMP IGMP RSVP Link layer service interface Link layer modules

15. Documents • RFC 2205:Resource ReSerVation Protocol (RSVP)- Version 1 Functional Specification • RFC 2207:RSVP Extensions for ISPEC Data Flows • RFC 2209:Resource ReSerVation Protocol (RSVP)- Version 1 Message Processing Rules • RFC 2210: The Use of RSVP with Integrated Services • RFC 2211: Specification of the Controlled-Load Network Element Service

16. Documents (cont’d) • RFC 2212:Specification of Guaranteed Quality of Service • RFC 2215:General Characterization Parameters for Integrated Service Network Elements • RFC 2216:Network Element Service Specification Template

17. Integrated Services Flow Description Traffic Control Services Link-Layers Signaling RSVP QoS Routing Policy Traffic Descriptors Service Descriptors Admission Control Classifier Scheduler Guaranteed Controlled Load Best Effort Point-to-point ATM IEEE 802 LANs Low-bit-rate RSVP Integrated Services

18. Integrated Services • Classes of QoS on a per-flow basis • Request for QoS from hosts • reservation protocol (RSVP) • Reservation requires • Source traffic envelop • Two-stage token bucket • Level of resources required • Admission Control • Scheduling, Policing

19. Guaranteed Service • Provides a maximum end-to-end delay bound and no queuing loss for conforming packets guarantees (via bandwidth reservation). • Source traffic characteristics (Tspec) • peak rate (p), bucket depth (b), token rate (r), min. policed unit (m), max. packet size (M) • Reservation characteristics (Rspec) • bandwidth (R), slack term (S)

20. Guaranteed Service r • Two-stage token bucket p  r b > M X  Min(r T+b, pT+M) b M data p X  r T+b

21. Guaranteed Service • End-to-end delay bound • Without consideration of packet size • b/R + C/R + D • Consider max. packet size • p > R  r • R  p  r

22. Guaranteed Service • Parameters • C: rate-dependent error term (delay experienced due to rate parameter, e.g., fragmentation of a packet into ATM cells) • D: rate-independent error term (e.g., waiting for a slot in a slotted network) • Ctot:end-to-end value of C • Dtot:end-to-end value of D

23. Guaranteed Service • Policing and reshaping • Traffic must be policed at the edge of networks • Nonconforming packets are served by best-effort • Reshaping traffic to token bucket inside the network • At a branching point where incoming branch is the max. of outgoing branches • At a merging point where many incoming branches are shared with one outgoing branch

24. Controlled-Load Service • Commitment to offer the flow of a service equivalent to that seen by a best-effort flow on a lightly loaded network • Grade of service should not deteriorate as network load increases • Similar requirements as Guaranteed Service • Tspec, Policing, Admission • No end-to-end guarantee (Rspec)

25. Introduction of RSVP • A resource reservation setup protocol designed for an integrated services network. • RSVP is receiver oriented • Used by a host to request a specific QoS from the network. • QOS parameters are defined in RFC 2210 • RSVP reserve resources for simplex data streams • Operates on top of IPv4 or IPv6 • port 46

26. Introduction of RSVP • RSVP is not a routing protocol • Reserve resources along the existing route set up by some routing protocols • E.g., in the multicast case, a host sends IGMP messages to join a multicast group and then sends RSVP messages to reserve resources along the delivery path(s) of that group. • RSVP identifies a session by (destination address, transport protocol id, destination port number) • TCP=6, UDP=17

27. Introduction of RSVP • RSVP maintains soft state in routers and hosts • RSVP sends periodic refresh messages to maintain the state along the reserved path(s) • In absence of refreshes, the state will automatically time out and be deleted. • Provides three reservation models (styles)

28. RSVP in Hosts and Routers router/switch host RSVP Application RSVP process policy Control Routing process RSVP process policy Control admission control Admission control packet classifier packet scheduler packet classifier packet scheduler data data

29. RSVP Functions of Hosts/Routers • Policy Control • administration • Traffic Control • Packet classifier • determine QoS class • Admission control • check for resources • Packet scheduler • determine when to send a particular packet

30. 0 1 2 3 vers Flags RSVP Checksum Msg Type RSVP Length Reserved Send TTL RSVP Messages • Common Header Format • Message type • 1: Path 2: Resv • 3: PathErr 4: ResvErr • 5: PathTear 6: ResvTear • 7: ResvConf

31. 0 1 2 3 Length (bytes) Class-num C-Type Object contents RSVP Messages • Object format • Class-num: • NULL(0), SESSION(1), RSVP_HOP(3), INTEGRITY(4), TIME_VALUES(5), ERROR_SPEC(6), SCOPE(7), STYLE(8), FLOWSPEC(9), FILTER_SPEC(10), SENDER_TEMPLATE(11), SENDER_TSPEC(12), ADSPEC(13), POLICY_DATA(14), RESV_CONFIRM(15)

32. RSVP Messages RCV1 Resv ResvTear PathErr R3 RCV2 S1 R1 R2 Path PathTear ResvErr ResvConf RCV3 R4

33. Class Number • NULL • SESSION: (DestAddr, Protocol ID, Port) • RSVP_HOP: IP of previous or next RSVP-capable node • TIME_VALUES: refresh period • STYLE: reservation style (required in a Resv message) • FLOWSPEC: define QoS in a Resv message • FILTER_SPEC: define a subset of session data that should receive the desired QoS in a Resv message

34. Class Number • SENDER_TEMPLATE: sender IP, port number, flow label in a Path message • SENDER_TSPEC: source traffic char. (Path) • ADSPEC: OPWA data in a Path message • ERROR_SPEC: error in a PathErr, ResvErr, or ResvConf message • POLICY_DATA: info. for administration (Path, Resv, PathErr, ResvErr) • INTEGRITY: cryptographic data • SCOPE: list of hosts to be forwarded • RESV_CONFIRM: receiver that needs conf.

35. Path Message • <Path Message> ::= <Common Header> [<INTEGRITY>] <SESSION><RSVP_HOP> <TIME_VALUES> [<POLICY_DATA>…] [<sender descriptor>] • <sender descriptor> ::= <SENDER_TEMPLATE><SENDER_TSPEC> [<ADSPEC>]

36. Path Message • RSVP_HOP (P_HOP): last RSVP-capable node • Sender Template • Sender IP, port number (IPv4/IPv6), flow label (IPv6) (content is identified by C_TYPE) • Sender Tspec: • r, b, p, m, M • Adspec • Default General Parameters, Guaranteed Service, and/or Controlled-load Service

37. 0 1 2 3 overall length reserved ver length of service 1 data service # (1) reserved Parm 127 length Parm id (127) flags r b p m M Sender TSpec Object Token Bucket Tspec

38. Processing Path Message • Update path state • if absent, create one • path state: sender Tspec, Phop, Adspec • Set cleanup timer, restart timer • expiration of cleanup timer triggers deletion of path state • Path message is generated and forwarded • changes of path state • route changes • every refresh period (soft state)

39. ADSPEC • Default General Parameters • Minimum path latency (no queuing delay) • Path bandwidth (min. of link bandwidth) • Global break bit (exist of non-RSVP-capable) • IS hop count • PathMTU • Used by received to reset M of sender Tspec

40. ADSPEC • Guaranteed Service fragment • Ctot: end-to-end value for C • Dtot: end-to-end value for D • Csum: composed value for C since last reshaping point • Dsum: composed value for D since last reshaping point • Guaranteed Serrvice Break bit • Guaranteed Service General Parameters Headers/Values • overrides the corresponding value given in the Default General Parameters • e.g., reduced path bandwidth for Guaranteed service

41. ADSPEC • Controlled-Load Service fragment • Controlled-Load Service Break bit • Controlled-Load Service General Parameters Header/Values

42. One Pass With Advertising (OPWA) • Sender includes Adspec in a path message for receiver to determine the end-to-end service • Compute R and slack term based on • Sender Tspec: r, b, p, m • Adspec: path bandwidth, path MTU, Ctot , Dtot

43. Resv Message • <Resv Message> ::= <Common Header> [<INTEGRITY>] <SESSION> <RSVP_HOP> <TIME_VALUES> [<RESV_CONFIRM>] [<SCOPE>] [<POLICY_DATA>…] <STYLE><flow descriptor list> • <flow descriptor list> ::= <empty> | <flow descriptor list> <flow descriptor>

44. Resv Message • Three reservation styles: WF, FF, SE • flow descriptor • WF Style <flow descriptor list> ::= <WF flow descriptor> <WF flow descriptor> ::= <FLOWSPEC> • FF Style <flow descriptor list> ::= <FLOWSPEC> <FILTER_SPEC> | <flow descriptor list> <FF flow descriptor> <FF flow descriptor> ::= <FLOWSPEC> <FILTER_SPEC> • SE Style <flow descriptor list> ::= <SE flow descriptor> <SE flow descriptor> ::= <FLOWSPEC> <filter spec list> <filter spec list> ::= <FILTER_SPEC> | <filter spec list> <FILTER_SPEC> • flowspec consists of Rspec and Tspec • filterspec is used to identify the sender(s). It has the same format as sender template.

45. 0 1 2 3 overall length reserved ver length of service 1 data service # (5) reserved Parm 127 length Parm id (127) flags r b p m M FLOWSPEC Object (Controlled-Load)

46. FLOWSPEC Object (Guaranteed) 0 1 2 3 overall length reserved ver length of service 1 data service # (2) reserved Parm 127 length flags Parm id (127) r b p m M Parm id (130) flags Parm 130 length R S

47. Reservation Style • Types of reservation style • One concerns the treatment of reservations for different senders within the same session : establish a distinct reservation for each upstream sender, or else make a single reservation that is shared among all packets of selected senders. • Another controls the selection of senders; an explicit list of all selected senders, or a wildcard that implicity selects all the senders to the session.

48. Reservation Sender Selection Shared Distinct Fixed-Filter (FF) Style Shared-Explicit (SE) Style Explicit Wildcard-Filter (WF) Style Wildcard (None defined) Reservation Style • Fixed-Filter (FF) Style • Shared-Explicit (SE) Style • Wildcard-Filter (WF) Style

49. Reservation Style • Wildcard-Filter (WF) Style • Shared reservation and wildcard sender selection. • Creates a single reservation shared by all upstream senders. • WF ( *{Q} ) • Shared Explicit (SE) Style • Shared reservation and explicit sender selection. • Creates a single reservation shared by selected upstream senders. • SE ( {S1,S2,...}, {Q} ) • WF and SE styles are appropriate for those multicast applications in which multiple data sources are unlikely to transmit simultaneously (packetized audio).

50. Reserve Reserve Reserve (*{3B}) (*{4B}) (*{5B}) Example of WF Style Incoming resv message Ourgoing resv message WF(*{5B}) WF(*{2B}) WF(*{5B}) To S1, S2 WF(*{3B}) WF(*{2B}) WF(*{5B}) To S3, S4 WF(*{4B}) WF(*{5B}) To S5, S6