IP Quality of Service

2

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

adaptive or should we modify the Internet to support inelastic behavior?

3

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”• E.g., control applications

QoS Defined

• The goal :Provide some level of predictability and control beyond the current IP “best-effort” service

• Fundamental principleLeave complexity at the “edges” and keep network “core” simple

4

QoS Metrics

• Performance attributes• Service availability• Delay• Delay variation (jitter)• Throughput• Packet loss rate

Vary according to Service Level Agreement (SLA)

5

Service Level Agreements (SLA)

6

QUALITY OF SERVICE PARAMETERS

Service Level Application Priority Mapping

1 Non-critical data Similar to Internet today No minimum information rate

guaranteed

Best-effort delivery Unmanaged performance

2 Mission-critical data VPN outsourcing, e-

commerce Similar to ATM VBR

Low loss rate Controlled delay and delay

variation

3 Real time applications Video streaming, voice,

videoconferencing

Low loss rate Low delay and delay variation

• What is the problem?• Different applications have different delay, bandwidth,

and jitter needs• Some applications are very sensitive to changing

network conditions: the packet arrival time distribution is important

• Solutions• Make applications adaptive• Build more flexibility into network

7

QoS’s Quest

The Holy Grail of computer networking is to design a network that has the flexibility and low cost of the

Internet, yet offers the end-to-end quality-of-service guarantees of the telephone network.

--S. Keshav

8

9

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 includes RSVP, Differentiated Services, and Integrated Services.

10

Overview

• Principles for QoS• Integrated Services (Intserv)• Differentiated Services (Diffserv)

11

Principles for QOS Guarantees

• Simple model for sharing and congestion studies (“dumbell topology”):

12

Principles for QOS Guarantees (more)• 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 accordingly.

13

Principles for QOS Guarantees (more)• 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

bandwidth requirements; Marking and Policing need to be done at the edges:

14

Principles for QOS Guarantees (more)• 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 use resources as efficiently as possible.

15

Principles for QOS Guarantees (more)• Cannot support traffic beyond link capacity.• PRINCIPLE 4: Need a Call Admission Process; application

flow declares its needs, network may block call if it cannot satisfy the needs .

16

Summary

17

Overview

• Motivation for QoS• Integrated Services (Intserv)• Differentiated Services (Diffserv)

18

IETF Intserv

• Focus on per-flow QoS.• Support specific applications such as video streaming.

• What is a flow?• Equivalent packets by some classification

• RSVP: Set of packets traversing a network element that are all covered by the same QoS request

• Packet classifier determines which packets belong to which flows• IPv6 includes a flow label to ease classification

• ISP usage (UUNET)• Microflow: TCP or similar bandwidth connection• Macroflow: Large aggregates of packets flowing between two

superhubs

• Because the Intserv model provides per-flow reservations, each flow is assigned a flow descriptor.

• The flow descriptor defines the traffic and QoS characteristics for a specific flow of data packets.

• The flow descriptor consists of a filter specification (filterspec) and a flow specification (flowspec)

19

• The filterspec identifies the packets that belong to a specific flow with the sender IP address and source port. • The information from the filterspec is used in the packet

classifier• Simplest filter: Source, Dest address/port pair• Data filter: classifies packets according to contents

• The flowspec contains a set of parameters that are called the invocation information. • The invocation information divides into two groups:

• Traffic Specification (Tspec)• Service Request Specification (Rspec)

20

21

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?• How is admission of new applications controlled?

22

Service Models

• 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)

• Service: contract between network and communication client

• Three common services• Best-effort (“elastic” applications)• Hard real-time (“real-time” applications)• Soft real-time (“tolerant” applications)

Worse-case : Guaranteed Services• Guaranteed service

• Targets hard real-time applications.• User specifies traffic characteristics and a service requirement.• Requires admission control at each of the routers.• Can guarantee bandwidth, delay, and jitter.

• Service contract• Network to client: guarantee a deterministic upper

bound on delay for each packet in a session • Client to network: the session does not send more than

it specifies• Algorithm support

• Admission control based on worst-case analysis• Per flow classification/scheduling at routers

23

Average-case: Controlled Load Service• 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 contract:

• Network to client: Average delay, jitter, bandwidth, e.g., makes network appear as an unloaded, best effort network with bandwidth and delay

• Client to network: the session does not send more than it specifies• Algorithm Support

• Admission control based on measurement of aggregates• Scheduling for aggregate possible

24

25

Service Interface

• Session must first declare its QoS requirement and characterize the traffic it will send through the network

• R-spec: defines the QoS being requested by receiver (e.g., rate r)

• 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 required; RSVP is a leading candidate for such signaling protocol.

• Once a connection is accepted, the host must use only the amount of resources reserved. It may not use more than that.

• What if the host is malicious and attempts to use more network resources than it reserved?

• It where Leaky Bucket comes to play

26

• Leaky Bucket• Used in conjunction with resource reservation to police

the host’s reservation• At the host-network interface, allow packets into the

network at a constant rate• Packets may be generated in a bursty manner, but after

they pass through the leaky bucket, they enter the network evenly spaced

27

• Leaky Bucket: Analogy

28

• The leaky bucket is a “traffic shaper”: It changes the characteristics of packet stream

• Traffic shaping makes more manageable and more predictable

• Usually the network tells the leaky bucket the rate at which it may send packets when the connection begins

• Polices the average rate

29

• Leaky Bucket doesn’t allow bursty transmissions• In some cases, we may want to allow short bursts

of packets to enter the network without smoothing them out

• For this purpose we use a token bucket, which is a modified leaky bucket

30

• Token Bucket• The bucket holds tokens instead of packets• Tokens are generated and placed into the token bucket

at a constant rate• When a packet arrives at the token bucket, it is

transmitted if there is a token available. Otherwise it is buffered until a token becomes available.

• The token bucket has a fixed size, so when it becomes full, subsequently generated tokens are discarded

31

32

• Token Bucket vs. Leaky Bucket

33

Case 1: Short burst arrivals

6543210

Arrival time at bucket

Departure time from a leaky bucketLeaky bucket rate = 1 packet / 2 time unitsLeaky bucket size = 4 packets

6543210

6543210

Departure time from a token bucketToken bucket rate = 1 tokens / 2 time unitsToken bucket size = 2 tokens

34

Case 2: Large burst arrivals

• Flow Specification: Token Bucket• Characterized by two parameters (r, b)

• r – average rate• b – token depth

• Assume flow arrival rate <= R bps (e.g., R link capacity)• A bit is transmitted only when there is an available token• Arrival curve – maximum amount of bits transmitted by time t

35

Packet Scheduling

• Implemented in hosts/routers to control link allocation

• Queuing algorithms• Weighted Fair Queuing (WFQ)• Class Based Queuing (CBQ)

• Queue management• Random Early Detection (RED)

Weighted Fair Queuing (WFQ)• Traffic placed into queues according to flow

specification, flow filter• Fair queuing

• Implements fairness of bit by bit scheduling on a per packet basis

• Gives queues a fair share of total bandwidth • Weighted

• Queue are not weighted evenly for scheduling• Proven: adequate for Guaranteed Service

Class Based Queuing (CBQ)• Combines scheduling and link sharing• Hierarchical link sharing

• Hierarchical queues• Enables protocol, organization isolation

• Scheduling• Does not define a particular scheduling algorithm• General scheduler for low latency when no

congestion• Link-sharing policing scheduler when congested• Scheduling per hierarchy

• CBQ Example

• Random Early Detection (RED)• Queue management algorithm for congestion control• This is a proactive approach in which the router

discards one or more packets before the buffer becomes completely full.

• Each time a packet arrives, the RED algorithm computes the average queue length, avg.

• If avg is lower than some lower threshold, congestion is assumed to be minimal or non-existent and the packet is queued

• If avg is greater than some upper threshold, congestion is assumed to be serious and the packet is discarded.

• If avg is between the two thresholds, this might indicate the onset of congestion. The probability of congestion is then calculated.

41

42

Call Admission

• Call Admission: routers will admit calls based on their R-spec and T-spec and base on the current resource allocated at the routers to other calls.

The Integrated Service model

• Integrated Services use the Resource Reservation Protocol (RSVP) for the signalling of the reservation messages

43

Resource Reservation Model

• Senders advertise using flowspecs• RSVP daemons forward advertisements to

receivers, update available bandwidth, minimum delay

• Receivers reservations use flowspec, filterspec combination (flow descriptor)

• Sender/receiver notified of changes• Reservations are merged in multicast case

44

RSVP

45

Role of RSVP

• Signaling protocol for establishing per flow state• Carry resource requests from hosts to routers• Collect needed information from routers to hosts• At each hop

• Consult admission control and policy module• Set up admission state or informs the requester of

failure

46

4747

Integrated Services Example: Data Path

SenderReceiver

• Per-flow classification

4848

Integrated Services Example: Data Path

SenderReceiver

• Per-flow buffer management

4949

Integrated Services Example

SenderReceiver

• Per-flow scheduling

How Things Fit Together

50

RSVP Reservation Model

• Performs signaling to set up reservation state for a session

• A session is a simplex data flow sent to a unicast or a multicast address, characterized by• <IP dest, protocol number, port number>

• Multiple senders and receivers can be in session

51

RSVP terminology

• Flow descriptor (Flow spec + Filter Spec)• Flow spec (Rate, max burst)

• Sender can Explicitly specify flow spec or not specify• Filter Spec (Sender address, TCP/UDP, Port#)

• Aids in combining similar flows• Filter can be shared (SE-style) or can use wild cards (all senders on a

given port or a given sender on all ports, etc)• The style may be shared or distinct in a sense that all reservations may be

handled as one single reservation or there may be a single reservation for each upstream sender respectively.

52

The Big Picture

53

54

RSVP Basic Operations

• Sender: sends PATH message via the data delivery path• Set up the path state each router including the address of previous

hop• Receiver sends RESV message on the reverse path

• Specifies the reservation style, QoS desired• Set up the reservation state at each router

• Things to notice• Receiver initiated reservation• Decouple routing from reservation• Two types of state: path and reservation

55

RSVP messages

• PATH message – sets up state along path followed by packets

• RESV message – request for reservation back along setup path path

• PATH_TEAR, RESV_TEAR, RESV_CONFIRM, RESV_ERROR, PATH_ERROR

56

RSVP Operation

57

RSVP PATH MESSAGE

• From sender to receiver (unicast or multicast)• Intercepted at each RSVP aware hop• Includes

• Sender TSpec : Traffic characteristics of the sender• Token bucket rate, depth, max flow rate, max packet size• forms one side of the ``contract'' between the data flow and the

service. • F-flag: specify whether filtered reservation is allowed

• Routers store:• Path state, i.e., PHOP address to previous hop (RSVP aware

node)• If F-flag is set, store sender and its flowspec• Otherwise, just add new link to multicast tree

58

RSVP RESV MESSAGE

• From receiver to sender(s) to reserve resources• Sent hop-by-hop using PHOP information • Reservation style and flow description

• Reservation style (FF,SE, WF)• Fixed-filter, Shared-explicit, wildcard-filter• Senders to which the reservation applies• Rspec, QoS specific requirements• RSpec is highly specific to the service required, and may include

information like bandwidth allocation, maximum delay, or packet loss probabilities etc.

• RESV messages processing at each hop• Merging of RESV messages• Forwards resv messages using PHOP

59

60

Receiver#1

Receiver#2

Receiver#3

Reservations mergeas they travel up tree.

R6

R3

R1

R4 R7

(1) 50Kbs

(2) 50Kbs

(3) 50Kbs

(4) 100 Kbs

(5) 100 Kbs

(6) 100 Kbs

(7) 100 Kbs

(8) 60Kbs

(9) 60Kbs

• Issue: who pays for service, how much?

• Merging different types of flows• Flow 1: Low delay, low

bandwidth• Flow 2: High delay, high

bandwidth• Flow with low delay, high

bandwidth satisfies Flows 1 and 2, but it may cost much more than Flow 1 or 2.

• Only certain flows can be easily merged given price constraints

RSVP UDP Reservation: an example (1)

61

R4

R5

R3R2

R1

Host A24.1.70.210

Host B128.32.32.69PATH

PATH

PATH

2

2. The Host A RSVP daemon generates a PATH message that is sent to the next hop RSVP router, R1, in the direction of the session address, 128.32.32.69.

PATH3

3. The PATH message follows the next hop path through R5 and R4 until it gets to Host B. Each router on the path creates soft session state with the reservation parameters.

1. An application on Host A creates a session, 128.32.32.69/4078, by communicating with the RSVP daemon on Host A.

1

RSVP UDP Reservation: an example (2)

62

R4

R5

R3R2

R1

Host A24.1.70.210

Host B128.32.32.69

PATHPATH

PATH

PATH

RESV

RESV

RESV

5

5. The Host B RSVP daemon generates a RESV message that is sent to the next hop RSVP router, R4, in the direction of the source address, 24.1.70.210.

RESV

6

6. The RESV message continues to follow the next hop path through R5 and R1 until it gets to Host A. Each router on the path makes a resource reservation.

4. An application on Host B communicates with the local RSVP daemon and asks for a reservation in session 128.32.32.69/4078. The daemon checks for and finds existing session state.

4

RSVP Routing Problems

• Routing is separated from admission control• If route changes, reservation must be made

along new route• New reservation takes time to setup• New reservation might fail• Old route could still be working fine

63

Route Pinning

• Problem: asymmetric routes• You may reserve resources on RS3S5S4S1S, but data

travels on SS1S2S3R !• Solution: use PATH to remember direct path from S to R,

i.e., perform route pinning

64

S1

S2

S3

SR

S5S4PATHRESV

IP routing

How Is the Token Bucket Used?

• Can be enforced by • End-hosts (e.g., cable modems)• Routers (e.g., ingress routers in a Diffserv domain)

• Can be used to characterize the traffic sent by an end-host

65

Source Traffic Characterization

• Arrival curve – maximum amount of bits transmitted during an interval of time Δt

• Use token bucket to bound the arrival curve

66

Δt

bits

Arrival curve

time

bps

QoS Guarantees: Per-hop Reservation• End-host: specify

• the arrival rate characterized by token-bucket with parameters (b,r,R)• the maximum maximum admissible delay D

• Router: allocate bandwidth ra and buffer space Ba such that • no packet is dropped• no packet experiences a delay larger than D

67

bits

b*R/(R-r)

slope rArrival curve

DBa

slope ra

End-to-End Reservation

• When R gets PATH message it knows• Traffic characteristics (tspec): (r,b,R)• Number of hops

• R sends back this information + worst-case delay in RESV• Each router along path provide a per-hop delay guarantee and forward

RESV with updated info • In simplest case routers split the delay

68

S1

S2

S3

SR(b,r,R) (b,r,R,3)

num hops

(b,r,R,2,D-d1)(b,r,R,1,D-d1-d2)(b,r,R,0,0)

(b,r,R,3,D)

worst-case delayPATHRESV

Reservation Style

• Motivation: achieve more efficient resource utilization in multicast (M x N)

• Observation: in a video conferencing when there are M senders, only a few can be active simultaneously• Multiple senders can share the same reservation

• Various reservation styles specify different rules for sharing among senders

69

Reservation Styles and Filter Spec• Reservation style

• use filter to specify which sender can use the reservation• Three styles

• Wildcard filter: does not specify any sender; all packets associated to a destination shares same resources• Group in which there are a small number of simultaneously active

senders• Fixed filter: no sharing among senders, sender explicitly identified

for the reservation• Sources cannot be modified over time

• Dynamic filter: resource shared by senders that are (explicitly) specified• Sources can be modified over time

70

Wildcard Filter Example

• Receivers: H1, H2; senders: H3, H4, H5• Each sender sends B• H1 reserves B; listen from one server at a time

71

• H2 reserves B

72

Wildcard Filter

• Advantages• Minimal state at routers

• Routers need to maintain only routing state augmented by reserved bandwidth on outgoing links

• Disadvantages • May result in inefficient resource utilization

73

Wildcard Filter: Inefficient Resource Utilization Example• H1 reserves 3B; wants to listen from all senders

simultaneously• Problem: reserve 3B on (S3:S2) although 2B

sufficient!

74

Fixed Filter Example

• Receivers: H2, H3, H4, H5; Senders: H1, H4, H5• Routers maintain state for each receiver in the

routing table

75

Fixed Filter Example

• H2 wants to receive B only from H4

76

Dynamic Filter Example

• H5 wants to receive 2B from any source

77

Soft State

• Per session state has a timer associated with it• path state, reservation state

• State lost when timer expires• Sender/Receiver periodically refreshes the state• Claimed advantages

• no need to clean up dangling state after failure• can tolerate lost signaling packets

• signaling message need not be reliably transmitted• easy to adapt to route changes

• State can be explicitly deleted by a Teardown message

78

Tear-down Example

• H4 leaves the group• H4 no longer sends PATH message• State corresponding to H4 removed

79

Tear-down Example

• H4 leaves the group• H4 no longer sends PATH message• State corresponding to H4 removed

80

RSVP Soft-state

• RSVP control messages need to be sent periodically• State will disappear if not refreshed• Periodic state refresh every t sec (30 sec)• If no refresh within n*t (n=3) , delete state

• RSVP messages sent as router-alert message• Intermediate routers intercept packets and

update state accordingly

81

Soft State (cont)

• Per session state has a timer associated with it• Path state, reservation state

• State lost when timer expires• Sender/Receiver periodically refreshes the state,

resends PATH/RESV messages, resets timer• Claimed advantages

• No need to clean up dangling state after failure• Can tolerate lost signaling packets

• Signaling message need not be reliably transmitted• Easy to adapt to route changes

• State can be explicitly deleted by a Teardown message

82

RSVP and Routing

• RSVP designed to work with variety of routing protocols

• Minimal routing service• RSVP asks routing how to route a PATH message

• Route pinning• addresses QoS changes due to “avoidable” route

changes while session in progress• QoS routing

• RSVP route selection based on QoS parameters• granularity of reservation and routing may differ

• Explicit routing• Use RSVP to set up routes for reserved traffic

83

Recap of RSVP

• PATH message• sender template and traffic spec• advertisement• mark route for RESV message• follow data path

• RESV message• reservation request, including flow and filter spec• reservation style and merging rules• follow reverse data path

• Other messages• PathTear, ResvTear, PathErr, ResvErr

84

Why did IntServ fail?

85

• Goal: provide support for wide variety of applications:• Interactive TV, IP telephony, on-line gamming

(distributed simulations), VPNs, etc• Problem:

• Best-effort cannot do it? • Intserv can support all these applications, but

• Too complex• Not scalable

86

Will RSVP Succeed?

• Telcos and long-haul ISPs want constant bit-rate allocations• RSVP will not control backbone allocations• Need simpler mechanism such as differentiated service

• Microsoft, networking vendors see demand for QoS over IP• RSVP is only alternative today• RSVP might find a home in corporate networks

87

88

Overview

• Motivation for QoS• Integrated Services (Intserv)• Differentiated Services (Diffserv)

89

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, …)

• Simpler signaling: (than RSVP) many applications and users may only want to specify a more qualitative notion of service

90

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

• Example: expedited service versus best effort• Evolution rather than revolution

91

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.• Although architecture does not preclude more fine-grained

guarantees.

• Classification and marking of packets at the edge of the network makes the packets accessible to QoS handling within the network

92

• Optimized queuing and forwarding in the core of the network (PHB-Per Hop Behavior) allows for fast efficient delivery

93

94

Edge Router/Host Functions

• Classification: marks 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.• Conditioning: delays and then forwards, discards, or

remarks other traffic.

95

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.

• 2 bits are currently unused.

96

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:No state info to be maintained by routers!

97

Forwarding (PHB)

• PHB result in a different observable (measurable) forwarding performance behavior.

• PHBs are defined as “black box”• 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 class B.

Default PHB

• RFC2474, Definition of Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers

• Default PHB• Good old Best-effort behavior• Recommended DSCP: “000000”

• Note: Each PHB has a “recommended” DSCP value but ISPs can use different value in their network

98

99

Forwarding (PHB)

• Expedited Forwarding (EF):• RFC2598• Guarantees a certain minimum rate for the EF traffic.• EF PHB can be used to build a low loss, low latency, low jitter,

assured bandwidth, end-to-end service• Targets VoIP, Virtual Leased Lines• Assured traffic sees no (or very small) queues/delay• Constraint: Requires bounding rates such that, at every transit node,

the aggregate’s max arrival rate is less than the aggregate min departure rate

• Implies isolation: guarantee for the EF traffic should not be influenced by the other traffic classes.

• Admitted based on peak rate.• Non-conformant traffic is dropped or shaped.• Recommended DSCP=101110

100

Forwarding (PHB)

• Assured Forwarding (AF): • RFC2597• Assured Forwarding (AF) PHB Group is meant to offer different

levels of forwarding assurances for IP packets received from a customer DS domain

• 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.

• Non-conformant traffic is remarked.

•Currently defined4 independently forwarded AF classes (ie 4 “queues” and 4 virtual networks with independent capacity management) Within each AF class, 3 levels of drop precedenceWithin each AF class, RED-like buffer mgt

•DS node should implement all 4 general AF classes•DS node must allocate a configurable minimum amount of forwarding resources to each implemented AF class

101

102

Diff-Serv Functional BlocksClassifier Conditioner Forwarding PHB

MeteringDroppingMarkingShapingAccounting

SchedulingDiscard

ACLQPPB

CARTS

Netflow

CEF CBWFQPQ

WRED

Implementation Features

103

Differentiated Services Issues

• AF and EF are not even in a standard track yet… 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• Some packets will be handled differently in different routers.• Some routers are not DiffServ capable.