INTSERV_DIFFSERV_RSVP.ppt

Mehran University of Engineering and Technology, Jamshoro

10TL- BATCH

This class will meet @: 8:00 a.m -10:00 a.m (Mondays)

10:00 a.m - 12:00 p.m (Tuesdays) 08:00 a.m - 10:00 a.m (Thursdays)

08:00 a.m -10:00 a.m (Fridays)

Today's Lecture: Lecture # 50 – Lec # 54 15-04-2013

Motivation

 _{Internet currently provides only single class of} “best-effort” service.

 No admission control and no assurances about

delivery

 _{Existing applications are elastic.}  Tolerate delays and losses

 Can adapt to congestion

 _{Future “real-time” applications may be inelastic.}  _{Should we modify these applications to be more}

Application Types

 _{Elastic applications.}

 Wide range of acceptable rates, although faster is better  E.g., data transfers such as FTP

 _{Continuous media applications.}

 Lower and upper limit on acceptable performance  Sometimes called “tolerant real-time” since they can

adapt to the performance of the network  E.g., changing frame rate of video stream  “Network-aware” applications

 _{Hard real-time applications.}

 Require hard limits on performance – “intolerant

real-time”

Improving QoS in IP Networks

 _{IETF groups are working on proposals to provide}

better QoS control in IP networks, i.e., going beyond best effort to provide some assurance for QoS.

 _{Work in Progress includes RSVP, Differentiated}

Overview

 _{Principles for QoS}

 _{Integrated Services (Intserv)}

 _{Differentiated Services (Diffserv)}

Principles for QoS Guarantees [1]

 _{Simple model for sharing and congestion}

Principles for QoS Guarantees [2]

 _{Consider a phone application at 1Mbps and an FTP} application sharing a 1.5 Mbps link.

 _{Bursts of FTP can congest the router and cause audio packets}

to be dropped.

 _{Want to give priority to audio over FTP.}

 _{PRINCIPLE 1: Marking of packets is needed for} router to distinguish between different classes; and new router policy to treat packets

Principles for QoS Guarantees [3]

 _{Applications misbehave (audio sends packets at a rate higher than}

1Mbps assumed above).

 _{PRINCIPLE 2: provide protection (isolation) for one class from}

other classes.

 _{Require Policing Mechanisms to ensure sources adhere to}

Principles for QoS Guarantees [4]

 _{Alternative to Marking and Policing: allocate a set portion of}

bandwidth to each application flow; can lead to inefficient use of bandwidth if one of the flows does not use its allocation.

 _{PRINCIPLE 3: While providing isolation, it is desirable to}

Principles for QoS Guarantees [5]

 _{PRINCIPLE 4: Need a Call Admission Process;}

A Short History of Internet QoS

 _{Lots of initial research in the late 80s and early} 90s.

 Often takes a telecommunications view of the

network.

 _{ATM QoS and Integrated services were} developed based on these results.

 Focus on per-flow, hard QoS.

 Effort was driven by perceived application needs.  _{In the last 5 years, the focus has shifted towards}

Differentiated services.

 Focus is on QoS for flow aggregates, e.g., all the

Overview

 _{Motivation for QoS}

 _{Integrated Services (Intserv)}

 _{Differentiated Services (Diffserv)}

IETF Intserv

 _{Focus on per-flow QoS.}

 Support specific applications such as video streaming.

 Based on mathematical guarantees.  _{Many concerns:}

 Complexity  Scalability

Components of Integrated Services

 _{Type of service model}

 What does the network promise?

 _{Service interface}

 How does the application describe what it wants?

 _{Packet scheduling}

 How does the network meet promises?

 _{Establishing the guarantee}

 How is the promise communicated to/from the

network?

Service Models [1]

 _{Network can support traffic streams with different} “quality of service”.

 Best effort

 Predictive or differentiated services

 Strong guarantees on the level of service (real-time)  _{The set of services that is supported on a specific}

network can be viewed as a service model.

 Model that can be used to select a service

 E.g., cost versus performance tradeoffs

 Network architecture that supports the set of

services

Service Models [2]

 _{Guaranteed service}

 Targets hard real-time applications.

 _{User specifies traffic characteristics and a service} requirement.

 _{Requires admission control at each of the routers.}

 Can mathematically guarantee bandwidth, delay, and jitter.

 _{Controlled load.}

 Targets applications that can adapt to network conditions within a certain performance window.

 _{User specifies traffic characteristics and bandwidth.}  _{Requires admission control at each of the routers.}

 _{Guarantee not as strong as with the guaranteed service.}

 e.g., measurement-based admission control.

Service Interface

 _{Session must first declare its QoS requirement and} characterize the traffic it will send through the

network

 _{Resource Specification (R-spec): defines the} QoS being requested by receiver (e.g., rate r)

 _{Traffic specification (T-spec): defines the traffic} characteristics of sender (e.g., leaky bucket with rate r and buffer size b).

 _{A signaling protocol is needed to carry the R-spec} and T-spec to the routers where reservation is

Packet scheduling

 _{Guaranteed service}

 Use token bucket filter to characterize traffic

 Described by rate r and bucket depth b

 Use WFQ at the routers

Call Admission

 _{Call Admission: routers will admit calls based}

Overview

 _{Motivation for QoS}

 _{Integrated Services (Intserv)}

 _{Differentiated Services (Diffserv)}

Differentiated Services

 _{Intended to address the following difficulties with} Intserv and RSVP;

 _{Scalability: maintaining states by routers in high} speed networks is difficult due to the very large number of flows

 _{Flexible Service Models: Intserv has only two} classes, want to provide more qualitative service

classes; want to provide ‘relative’ service distinction (Platinum, Gold, Silver, …)

Diffserv - Motivation

 _{Do fine-grained enforcement only at the edge of the} network.

 Typically slower links at edges  E.g., mail sorting in post office

 _{Label packets with a field.}

 E.g., a priority stamp

 _{The core of the network uses only the type field for} QoS management.

 Small number of types with well defined forwarding behavior

 Can be handled fast

Diffserv - Discussion

 _{Diffserv defines an architecture and a set of} forwarding behaviors.

 It is up to the service providers to define and implement end-to-end services on top of this architecture.

 Offers a more flexible service model; different providers can offer different service.

 _{One of the main motivations for Diffserv is scalability.}

 Keep the core of the network simple.

 _{Focus of Diffserv is on supporting QoS for flow} aggregates.

Edge Router/Host Functions

packets according to

classification rules to be specified.

 _{Metering: checks}

whether the traffic falls within the negotiated profile.

 _{Marking: marks traffic} that falls within profile.

Classification and Conditioning

 _{Packet is marked in the Type of Service (TOS)}

in IPv4, and Traffic Class in IPv6.

 _{6 bits used for Differentiated Service Code}

Point (DSCP) and determine PHB that the packet will receive.

Core Functions

 _{Forwarding: according to}

“Per-Hop-Behavior” or PHB specified for the particular packet class; such PHB is strictly based on class marking (no other header fields can be used to influence PHB).

 BIG ADVANTAGE:

Forwarding (PHB) [1]

 _{PHB result in a different observable} (measurable) forwarding performance behavior.

 _{PHB does not specify what mechanisms to use} to ensure required PHB performance behavior.  _Examples:

 Class A gets x% of outgoing link bandwidth over

time intervals of a specified length.

 Class A packets leave first before packets from

Forwarding (PHB) [2]

 _{Expedited Forwarding (EF):}

 Guarantees a certain minimum rate for the EF traffic.

 _{Implies isolation: guarantee for the EF traffic} should not be influenced by the other traffic classes.

 Admitted based on peak rate.

Forwarding (PHB) [3]

 _{Assured Forwarding (AF):}

 AF defines 4 classes with some bandwidth and

buffers allocated to them.

 The intent is that it will be used to implement

services that differ relative to each other (e.g., gold, silver,…).

 Within each class, there are three drop

priorities, which affect which packets will get dropped first if there is congestion.

 Lots of studies on how these classes and drop

priorities interact with TCP flow control.

Example of EF: A Virtual Leased

Line Service

 _{Service offers users a dedicated traffic pipe.}  Guaranteed bandwidth between two points.

 Very low latency and jitter since there should be

no queuing delay (peak rate allocation).

 _{Admission control makes sure that all links in} the network core have sufficient EF bandwidth.

 Simple case: sum of all virtual link bandwidth is

less than the capacity of the slowest link.

Differentiated Services Issues

research ongoing.

 _{The key to making Diffserv work is bandwidth} management in the network core.

 _{Simple for simple services such as the virtual pipe, but it is} much more challenging for complex service level

agreements.

 Notion of a “bandwidth broker” that manages the core network bandwidth.

 _{Definition of end-to-end services for paths that cross} networks with different forwarding behaviors

INTSERV and DIFFSERV [1]

 _{Complimentary:}

– DIFFSERV: aggregate, per customer/user/usergroup/ application

– INTSERV: per flow

 _{For example:}

Overview

 _{Motivation for QoS}

 _{Integrated Services (Intserv)}

 _{Differentiated Services (Diffserv)}

Components of Integrated Services

 What does the network promise?  _{Service interface}

 How does the application describe what it wants?  _{Packet scheduling}

 How does the network meet promises?  _{Establishing the guarantee}

 How is the promise communicated to/from the

network

Role of RSVP

 _{Rides on top of unicast/multicast routing}

protocols.

 _{Must be present at sender(s), receiver(s), and}

routers.

 _{Carries resource requests all the way through}

the network.

 _{At each hop consults admission control and}

Upper layer protocols and applications

IP

Link layer modules

ICMP IGMP RSVP

IP service interface

RSVP Goals

 _{Used on connectionless networks.}

 Should not replicate routing functionality.  _{Should co-exist with route changes.}

 _{Support for multicast.}

 _{Different receivers have different capabilities and want different}

QoS.

 _{Changes in group membership should not be expensive.}

 Reservations should be aggregate – I.e. each receiver in group

should not have to reserve.

 Should be able to switch allocated resource to different senders.

 _{Limit control overhead.}

 _{Modular design – should be generic “signaling” protocol.}  _Result:

Receiver-Initiated Reservation

 _{Receiver initiates reservation by sending a} reservation over the sink tree.

 _{Assumes multicast tree has been set up previously.}

 Also uses receiver-initiated mechanism.

 _{Hooks up with the reserved part of the tree.}

 _{How far the request has to travel to the source depends} on the level of service requested.

 _{Uses existing routing protocol, but routers have to store} the sink tree (reverse path from forwarding path).

 _Properties:

 _{Scales well: can have parallel independent connect and} disconnect actions – single shared resource required.  _{Supports receiver heterogeneity: reservation specifies}

Soft State

 _{Routers keep state about reservation.}  _{Periodic messages refresh state.}

 _{Non-refreshed state times out automatically.}  _{Alternative: Hard state}

 _{No periodic refresh messages.}  State is guaranteed to be there.  State is kept till explicit removal.  _{Why could there be a problem?}

 _{Properties of soft state:}

 Adapts to changes in routes, sources, and receivers.  _{Recovers from failures}

 _{Cleans up state after receivers drop outs}

RSVP Service Model

 _{Make reservations for simplex data streams.}  _{Receiver decides whether to make reservation}

 _{Control messages in IP datagrams (proto #46).}

 _{PATH/RESV messages sent periodically to}

refresh soft state.

 _{One pass:}

 Failed requests return error messages -

receiver must try again.

Basic Message Types

 _{PATH message}  _{RESV message}

 _{CONFIRMATION message}

 Generated only upon request.

 _{Unicast to receiver when RESV reaches node} with established state.

 _{TEARDOWN message}

PATH Messages

 _{PATH messages carry sender’s T-spec.}  Token bucket parameters

 _{Routers note the direction PATH messages}

arrived and set up reverse path to sender.

 _{Receivers send RESV messages that follow}

reverse path and setup reservations.

 _{If reservation cannot be made, user gets an}

RESV Messages

 _{RESV messages carry receiver’s R-spec.}  _{Forwarded via reverse path of PATH.}

 _{Queuing delay and bandwidth requirements.}  _{Source traffic characteristics (from PATH).}  _{Filter specification}

 Which transmissions can use the reserved

resources?

 Reservation style.

Router Handling of RESV

Messages

 _{If new request rejected, send error message.}  _{If admitted:}

 Install packet filter into forwarding dbase.  Pass flow parameters to scheduler.

RSVP reservations

 _{Reservations from multiple receivers for a}

single sender are merged together at branching points.

 _{Reservations for multiple senders may be}

added up:

 Video conference

 _{Reservations for multiple senders may not be}

added up:

Reservation Styles

 _{Three styles}

 Wildcard/No filter – does not specify a particular sender for group.

 _{Fixed filter – sender explicitly specified for a} reservation.

 Video conference

 Dynamic filter – valid senders may be changed over time.

Example

 _{Senders S1, S1, S3}  _{Receivers R1, R2, R3}

 _{Router interfaces A,B,C,C}

S1 A

S2, S3 B

C

R1

D _R2

Wildcard Filter Reservation

respectively (b is given rate).

S1 A

S2, S3 B

C

R1

D _R2

R3 4b

3b 4b

Fixed Filter Reservation

 _{R2 wants to reserve 3b for S1 and b for S3.}  _{R3 wants to reserve b for S1.}

S1 A

S2, S3 B

Dynamic Filter Reservation

 _{R2 wants to reserve 3b for S1 and S3 (shared).}  _{R3 wants to reserve 2b for S2.}

S1 A

S2, S3 B

C

R1

D _R2

R3 (S1,S2):b

(S1,S2,S3):3b S1:3b

Changing Reservation

 _{Receiver-oriented approach and soft state}

make it easy to modify reservation.

Routing Changes

 _{Routing protocol makes routing changes.}

 _{In absence of route or membership changes,}

periodic PATH and RESV messages refresh established reservation state.

 _{When change, new PATH messages follow}

new path, new RESV messages set reservation.

State in Switches

 _{Have to keep sink tree information.}

 _{No such thing as inverse multicast routing.}

 _{Also have to keep information on sources if filters are} used.

 _{Selected in path message.}

 _{Used in aggregation and propagating information to switches.}

 _{Also used in limiting protocol overhead.}

 _{Switches do not propagate periodic reservation and path}

messages.

 _{They periodically regenerate copies that summarize the}

information they have.

RSVP - Review

 _{Concentration on multicast may have been}

wrong idea.

 Unicast considered as special case of multicast.

 _{Receiver initiation – handle negotiation at}

application level.

 _{Receiver heterogeneity – how can}

low-capability receiver benefit from video sent at high bandwidth?

 Layered encoding

 _{Soft state}