Sprint PCS ® QoS JEM RSVP and Diff-SRV January 2001 Mark Lipford Wireless Industry Standards...

Sprint PCS ®

QoS JEM

RSVP and Diff-SRV

January 2001

Mark LipfordWireless Industry Standards

Technology and Advanced Systems Development

Sprint PCS

Overview

What is IP QoS? History of IETF QoS IETF Integrated Services RSVP IETF Differentiated Services Diff Edge

Sprint PCS

What is IP QoS?

Some observations: Quality is an attribute of the end to end service User’s perception of service quality is what counts QoS is as much about perceived value as it is about performance

– QoS requirements are driven top down beginning with users perception

IP networks support a multitude of applications The mixture of IP applications have changed and will change over

time– User application requirements impossible to specify reliably

All users/applications are treated equally with best effort delivery Connectionless service required no dynamic resource

management– QoS support complicates IP forwarding– Migration of IP networks to support QoS is difficult

Sprint PCS

``

Ethernet Hub

Boundary IP Router

Boundary IP Router

Boundary IP Router

Boundary IP Router

Edge IP Router

Boundary IP Router

Dial UpAccess

Network

Edge IP Router

CarrierNetwork

CarrierNetwork

Wireless AccessNetwork

EnterpriseIntranet

Radio Access Point

Modem Bank

Edge IP Router

Autonomous Domains

Edge IP Router

What is IP QoS - Internetworking?

Sprint PCS

History of IETF QoS

RSVP: a new resource ReSerVation Protocol, IEEE Network Magazine, Sept 1993

RSVP working group established, 1994 Integrated Services working group established, 1994 Integrated Services over Specific Link Layers working group

established, 1996 RFC 2205 RSVP Functional Specification 1997 RFC 2208 RSVP Applicability Statement 1997 RFC 2211 Specification of the Controlled-Load Network Element

Service, 1997 RFC 2212 Specification of Guaranteed Quality of Service, 1997 A Two-bit Differentiated Services Architecture for the Internet,

Internet Draft, 1997 MPLS working group established, 1998 Policy working group established, 1998

Sprint PCS

History of IETF QoS

Differentiated Services working group established, 1998 RFC 2381 Interoperation of Controlled-Load Service and

Guaranteed Service with ATM, 1998 RFC 2474 Definition of the Differentiated Services Field (DS Field)

in the IPv4 and IPv6 Headers, 1998 RFC 2475 An Architecture for Differentiated Services, 1998 RFC 2597 Assured Forwarding PHB Group, 1999 RFC 2598 An Expedited Forwarding PHB, 1999 RFC 2689 Providing Integrated Services over Low-bit rate Links,

1999 IEEE 802.1p released RFC 2816 A Framework for Integrated Services Over Shared and

Switched IEEE 802 LAN Technologies, 2000 MPLS Support of Differentiated Services, Internet Draft, 2000

Sprint PCS

IETF Integrated Services

The purpose of [the Integrated Services] working group is to specify [an] enhanced service model [for the transport of audio, video, real-time, and classical data traffic within a single network infrastructure] and then to define and standardize certain interfaces and requirements necessary to implement the new service model.

Two transport service models defined: Guaranteed Quality of Service (RFC 2212) Controlled Load (RFC 2211)

Integrated Services are specified using the Network Element Service Specification template (RFC 2216)

Sprint PCS

Guaranteed Quality of Service

RFC 2212 Guaranteed service provides firm (mathematically provable)

bounds on end-to-end datagram queuing delays. GQoS is specified by a TSpec and RSpec (RFC 2216):

– Traffic Specification (TSpec): token bucket token rate (r)

token bucket size (b)

peak rate (p)

minimum policed unit (m)

maximum datagram size (M)

– Service Specification (RSpec): rate (R)

slack (S)

Sprint PCS

Guaranteed Quality of Service

Token bucket flow specification:– r specifies the continually sustainable data rate– b defines the extent to which the data rate can exceed r for a limited

time - i.e. a “burst”– the peak rate, p, must be greater then or equal to the token bucket

rate, r– the amount of data sent cannot exceed M + min(pT, rT+b-M), over

any interval T– M must be less then or equal to the supported MTU size

(r,b) allows for bursty traffic, while p limits the total load all packets less then m bytes in length are policed as if they were

exactly m bytes long from these parameters, a finite bound on the queuing delay can be

calculated using a fluid flow model (c.f. RFC 2212 for the equation)

Sprint PCS

Controlled Load

RFC 2211 The equivalent of best effort service under lightly loaded

conditions:– high probability of packet delivery– transit delay will be near that of an unloaded network (zero queuing

delay)

Controlled load is specified by a TSpec (RFC 2216):

– Traffic Specification (TSpec): token bucket token rate (r)

token bucket size (b)

peak rate (p)

minimum policed unit (m)

maximum datagram size (M)

Sprint PCS

Controlled Load

The traffic specification follows RFC 2216 for compatibility, and is identical to that for Guaranteed Quality of Service, except, the peak rate parameter, p, may be ignored for Controlled Load service.

This is the same as saying the peak rate is the same as the line rate at the ingress interface

Non-conformant traffic (traffic that exceeds rT+b) is to treated as a normal condition, and given best effort service.

No quantitative performance guarantees.

Sprint PCS

RSVP

The Resource ReSerVation Protocol (RFC 2205) is a control protocol designed to support the setup up of quality of service

– establishes resources based upon the receivers requirements– operates in-band; there is no explicit signaling channel/path– reserves resources for flows in one direction– works for unicast and multicast applications– works “hop-by-hop”: reservations are established at each network

element independently– is transparent to non-RSVP aware network elements (e.g. routers,

gateways)– maintains soft state in support for dynamic multicast membership and

adaptation to route changes– is not a routing protocol

Sprint PCS

RSVP

Reservation Model: – flow descriptor:

flow spec provides parameters for configuring flow treatment at a network element

filter spec, in conjunction with a session specification, defines the flow of packets that is to receive QoS treatment

– a filter spec is essentially a set of bit masks used in a packet classifier– the basic filter spec format gives the sender’s address and, optionally,

the sender’s UDP/TCP source port number– a flow spec is a reservation request, consisting of:

a service class

an RSpec that defines the desired QoS

a TSpec that describes the data flow

– the RSpec and TSpec are defined in the QoS models (e.g. Guaranteed Quality of Service and Controlled Load) and are opaque to RSVP

– c.f. RFC 2210 for the formats of the TSpec, RSpec and AdSpec for Integrated Services

Sprint PCS

RSVP

Message Types: RSVP messages are IP packets with PID = 46 A Common Header payload object identifies the type:

• PATH originates with sender, provides flow description

forwarded from source to destination (sender to receiver)

carries flowspec and, optionally, Adspec

• RESV originates with receiver, carries resource reservation, RSpec

forwarded hop-by-hop using local PHOP addresses

• PathErr• ResvErr• PathTear

instructs nodes to remove path state

• ResvTear instructs nodes to remove resource reservation state

• ResvConf optional reservation confirmation from sender to receiver

Sprint PCS

Sender ReceiverForwardingNode

ForwardingNode

ForwardingNode

PATH PATH PATH PATH

RSVP

Protocol Sender initiates PATH message:

– Previous HOP address– Sender Template provides a filter spec for the flow– Sender TSpec which describes the traffic characteristics of the flow– optional AdSpec which is a list of the QoS capabilities at each network

entity

PATH message is forwarded, hop-by-hop At each network entity (hop):

– stores the PATH state information (e.g. PHOP, flowspec, AdSpec, …)– sets the PHOP to its own IP address– optionally adds an entry to the AdSpec– forwards the PATH message to the next hop

Sprint PCS

Sender ReceiverForwardingNode

ForwardingNode

ForwardingNode

RESV RESV RESV RESV

PHOPPHOPPHOPPHOP

RSVP

Receiver receives a PATH message:• forms an RSpec from the Sender TSpec, and, optionally, from the AdSpec

list of the QoS capabilities of each network entity along the sender path• e.g. TSpec might provide token bucket, peak rate, MTU parameters• e.g. AdSpec might provide bandwidth, and latency estimates for each hop

Receiver returns a RESV message:• flowspec: RSpec and filter spec • returned along path identified by PHOPs stored at each network entity in

path state• at each network entity, the RESV state is stored, filters are set up and

resources are allocated to support the requested QoS

• if requested (by a flag in the RESV message), a RESV confirm is returned by the sender to the receiver

Sprint PCS

RSVP

Multicast A good portion of RFC 2205 is dedicated to the guidelines for

merging PATH Sender Templates, Sender TSpecs, and RESV flowspecs in support of QoS for multicast applications

Soft State Soft state is a feature of RSVP provided to support:

– asynchronous merging of resource reservations for multicast applications

– dynamic path changes– PATH and RESV tear down

Largely due to possibility of path changes, RSVP path states must be refreshed periodically (every 20 seconds).

Sprint PCS

RFC 2208: RSVP Applicability Statement

Issues around the deployment of RSVP and Integrated Services

Additional coordinated components required: • message formats for QoS parameters• router and host mechanisms to effect QoS• policy objects• admission control and security functions

Three deployment issues:• scalability• security• policy control• (migration)

Sprint PCS

RFC 2208: RSVP Applicability Statement

Is RSVP and Integrated Services not scaleable?

The issue is overhead per IP flow versus the utility of per flow QoS

The most significany impact would be on traditional router implementations which have minimal signalling support

RSVP and Integrated Services can be used to provide QoS to aggregates of flows

Sprint PCS

IETF Differentiated Services

The Differentiated Services working group was established to develop relatively simple and coarse methods of providing differentiated classes of service for Internet traffic. The differentiated services approach to providing quality of service in networks employs a small, well-defined set of building blocks from which a variety of aggregate behaviors may be built.The key components of DS:

Behavioral Aggregates (BAs)– groups of IP flows that are to receive similar forwarding treatment

Per Hop Behaviors (PHBs)– a description of the forwarding treatment at each network entity

Traffic Conditioning (TC)– modifies the characteristics of an IP flow to comply with the service

limitations

Diff-SRV provides only for a differentiation between the relative quality of service experienced by different behavioral aggregates.

Sprint PCS

version(4)

headerlength

(4)

type of service(8)

total length (in bytes)(16)

identification(16)

flags(3)

fragment offset(13)

time to live(8)

protocol(8)

header checksum(16)

source IP address(32)

destination IP address(32)

options

source port number(16)

destination port number(16)

IPheader

first wordof UDP/TCP

headerA BA is a collection of one or more IP microflows, each of which will receive the same forwarding treatment by the network entities

Behavioral Aggregates

An “IP microflow” is defined by the 5-tuple:

Sprint PCS

Sender ForwardingNode

ForwardingNode

ForwardingNode

IP mflows BAs BAs BAs

ForwardingNode

BAs

Access EdgeInterior

PHB PHB PHB PHB

Diff Serv Domain

Differentiated Services Architecture

Sprint PCS

Wireless AccessNetwork

Differentiated Services Architecture

``

Ethernet Hub

Boundary IP Router

Boundary IP Router

Boundary IP Router

Boundary IP Router

Edge IP Router

Boundary IP Router

Dial UpAccessNetwork

Edge IP Router

CarrierNetwork

CarrierNetwork

EnterpriseIntranet

Radio Access Point

Modem Bank

Edge IP Router

Diff Serv Domains

Edge IP Router

RFC 2475

BehavioralAggregates

IP microflows

Sprint PCS

Per Hop Behaviors

PHBs are the defining components of Diff Serv QoS:

The PHB concept captures the forwarding treatment giving to a flow of packets at a single node

The forwarding treatment is simply a combination of queuing and scheduling:

– a PHB is, in practice, the treatment provided by a queuing discipline

There are many queuing solutions for a given PHB (considered an implementation issue)

Sprint PCS

Router

Multi-FieldClassifier

Meter Queue

MarkerPolicer/Shaper

Queue

Queue

SchedulerQueue

Manager

Configuration and Control

Traffic Conditioning

Behavioral Classifier

Per Hop Behavior

a Differentiated Services Router Logical Model

A few examples of queuing disciplines: Weighted Fair Queuing (WFQ) Priority Queuing (PQ) Round Robin (RR) Weighted Round Robin (WRR) Class Based Queuing (CBQ)

Sprint PCS

Per Hop Behaviors

Defined PHBs:

– Default (Best Effort, RFC 1812)

– Expedited Forwarding (EF) (RFC 2598)

– Assured Forwarding (AF) (RFC 2597)

– Class Selector (IP Precedence, RFC 1812)

Sprint PCS

Best Effort

Best Effort is the classic IP datagram service (RFC 1812)

– Best effort delivery– No guarantee on timeliness of delivery– No guarantee on successful delivery

Sprint PCS

Expedited Forwarding

EF PHB offers a low latency, low jitter, per hop behavior (RFC 2598)

The EF PHB requires that the sum of the maximum ingress traffic across all ingress interfaces be less then the minimum bandwidth available for EF flows at the egress interface

This ensures that the EF queue will always be (nearly) empty Queuing delay is nearly constant (near zero jitter), and nearly zero

Note: the definition of EF as provided in RFC 2598 has recently been called into question (draft-charny-ef-definition-00.txt, July 2000)

Sprint PCS

Assured Forwarding

AF PHB offers relative differentiation (RFC 2597)

4 AF classes, each with 3 drop precedences Resources - buffer space and bandwidth - are allocated to each

AF class in unequal portions Between two AF classes under similar traffic loads, the class with

greater buffer space and bandwidth will experience better forwarding performance

Under heavy traffic loads, packets with high drop precedence will be dropped before packets with medium drop precedence.

The three levels of drop precedence are set by the traffic conditioner

Sprint PCS

Router

Multi-FieldClassifier

Meter Queue

MarkerShaper/Dropper

Queue

Queue

SchedulerQueue

Manager

Configuration and Control


Behavioral Classifier

Per Hop Behavior

a Differentiated Services Router Logical Model

Sprint PCS

Classification

Multi-Field Classification refers to the use of various fields of an IP packet to discriminate

one IP traffic flow from another classification usually based upon the IP 5-tuple (PID, SA, DA, SP,

DP) classification on other fields may be required:

• if the IP 5-tuple is not directly available (e.g. packet is encrypted)• if further discrimination is desired (e.g. for layer 7, or “deep” packet

classification) MF Classification is typically performed at the edges of a DS

domain

Sprint PCS


Traffic Conditioning:

metering of an IP flow to measure offered load policing of an IP flow to ensure that the offered load does not

exceed service limits shaping of an IP flow that exceeds the load limits for a short time marking of an MF classified IP flow with the appropriate DS Code

Point

Sprint PCS

version(4)

headerlength

(4)

DSCP(6)

total length (in bytes)(16)

identification(16)

flags(3)

fragment offset(13)

time to live(8)

protocol(8)

header checksum(16)

source IP address(32)

destination IP address(32)

options

source port number(16)

destination port number(16)

IPheader

first wordof UDP/TCP

header

The DSCP also identifies the Behavioral Aggregate

CU(2)

CU = currentlyunused

Marking and the Diff Serv Code Point

The DSCP (RFC 2474) is a six bit field identifying the PHB treatment

Sprint PCS

Class 4

Class 3

Class 2

Class 1

RFC 2598Expedited Forwarding PHB101110

010ppp

Experimental / Local Use(reserved for potential standards use)

Experimental / Local Use

Assured Forwarding PHB

Class Selector Code Points(compatible with IP Precedence Field)

Default PHB (Best Effort)

Assignment ReferencesDSCPPool

3

2

1

xxxx01

xxxx11

100ppp

011ppp

RFC 2597001ppp

RFC 791, RFC 1122, RFC 1812xxx000

RFC 1812000000

pppDrop Precedence

1100High

100Medium

010Low

Code Point Space (RFC 2474)

Sprint PCS

Peak Information Rate

Committed Information Rate

Time

Load

“red” packets“yellow” packets

Policing and Shaping

E.G. The Two Rate Three Color Marker, trTCM (RFC 2698) the IP flow is metered and marks packets as either “yellow”, “green” or

“red”– a packet is marked red if it exceeds the specified peak information rate– a packet is marked yellow if it exceeds the specified committed information

rates

red marked packets are dropped immediately yellow marked packets are dropped if the queue is congested (e.g. RED) green marked packets are forwarded

The colors are encoded into the DSCPs (e.g. as AF drop precedents)

Sprint PCS

Will the Differentiated Services Approach Work?

Many open questions: What are the appropriate queuing disciplines to effect a PHB? What traffic conditioning is most appropriate for each PHB? What are the end to end services the will result? How do you support services with strict performance requirements such

as voice or video? What happens with routers from different manufacturers in one DS

domain? What happens when you mix DS domains? What about DS over different link layers (e.g. wireless)? What about other service quality attributes such as reachability, reliability,

data integrity? How do you charge the user for a service that cannot be guaranteed?

The prevalent answer to most of these questions is to over-provision the network.

Sprint PCS

Diff Edge

Use of RSVP Request QoS in a Differentiated Services network(draft-ietf-issll-diffserv-rsvp-05.txt)

RSVP is originated by the end system (sender or receiver) as if the end system were talking to an Integrated Services network

The DS network traps the RSVP messages at the network edge, and maps the RSVP QoS request into a DSCP

The DSCP is encapsulated into an object - the DCLASS object (draft-ietf-issll-dclass-01.txt), and returned to the sender as part of the RESV message payload

The sender can then mark each packet with the appropriate DSCP

Diff Edge can be used to effect Admission Control in a DS access network.

RSVP DClass is supported by the Winsock 2 API (Windows 2000)

Sprint PCS

Will the Differentiated Services Approach Work?

Many open questions: What are the appropriate queuing disciplines to effect a PHB? What traffic conditioning is most appropriate for each PHB? What are the end to end services the will result? How do you support services with strict performance requirements

such as voice or video? What happens with routers from different manufacturers in one DS

domain? What happens when you mix DS domains? What about DS over different link layers (e.g. wireless)? What about other service quality attributes such as reachability,

reliability, data integrity? How do you charge the user for a service that cannot be

guaranteed?The prevalent response is to over-provision the network

Sprint PCS ® QoS JEM RSVP and Diff-SRV January 2001 Mark Lipford Wireless Industry Standards...

Documents

Transcript of Sprint PCS ® QoS JEM RSVP and Diff-SRV January 2001 Mark Lipford Wireless Industry Standards...