Sprint PCS ® QoS JEM RSVP and Diff-SRV January 2001 Mark Lipford Wireless Industry Standards...
-
Upload
john-daniels -
Category
Documents
-
view
214 -
download
0
Transcript of 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
Page 2 Sprint PCS
Overview
What is IP QoS? History of IETF QoS IETF Integrated Services RSVP IETF Differentiated Services Diff Edge
Page 3 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
Page 4 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?
Page 5 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
Page 6 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
Page 7 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)
Page 8 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)
Page 9 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)
Page 10 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)
Page 11 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.
Page 12 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
Page 13 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
Page 14 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
Page 15 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
Page 16 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
Page 17 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).
Page 18 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)
Page 19 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
Page 20 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.
Page 21 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:
Page 22 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
Page 23 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
Page 24 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)
Page 25 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)
Page 26 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)
Page 27 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
Page 28 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)
Page 29 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
Page 30 Sprint PCS
Router
Multi-FieldClassifier
Meter Queue
MarkerShaper/Dropper
Queue
Queue
SchedulerQueue
Manager
Configuration and Control
Traffic Conditioning
Behavioral Classifier
Per Hop Behavior
a Differentiated Services Router Logical Model
Page 31 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
Page 32 Sprint PCS
Traffic Conditioning
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
Page 33 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
Page 34 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)
Page 35 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)
Page 36 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.
Page 37 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)
Page 38 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