1. Sprint PCS ® QoS JEM RSVP and Diff-SRV January 2001 Mark Lipford Wireless Industry Standards Technology and Advanced Systems Development

2. Page 1 Sprint PCS Overview u What is IP QoS? u History of IETF QoS u IETF Integrated Services u RSVP u IETF Differentiated Services u Diff Edge

3. Page 2 Sprint PCS What is IP QoS? Some observations: u Quality is an attribute of the end to end service u User’s perception of service quality is what counts u QoS is as much about perceived value as it is about performance –QoS requirements are driven top down beginning with users perception u IP networks support a multitude of applications u The mixture of IP applications have changed and will change over time –User application requirements impossible to specify reliably u All users/applications are treated equally with best effort delivery u Connectionless service required no dynamic resource management –QoS support complicates IP forwarding –Migration of IP networks to support QoS is difficult

4. Page 3 Sprint PCS ` ` Ethernet Hub Boundary IP Router Edge IP Router Boundary IP Router Dial Up Access Network Edge IP Router Carrier Network Carrier Network Wireless Access Network Enterprise Intranet Radio Access Point Modem Bank Edge IP Router Autonomous Domains Edge IP Router What is IP QoS - Internetworking?

5. Page 4 Sprint PCS History of IETF QoS u RSVP: a new resource ReSerVation Protocol, IEEE Network Magazine, Sept 1993 u RSVP working group established, 1994 u Integrated Services working group established, 1994 u Integrated Services over Specific Link Layers working group established, 1996 u RFC 2205 RSVP Functional Specification 1997 u RFC 2208 RSVP Applicability Statement 1997 u RFC 2211 Specification of the Controlled-Load Network Element Service, 1997 u RFC 2212 Specification of Guaranteed Quality of Service, 1997 u A Two-bit Differentiated Services Architecture for the Internet, Internet Draft, 1997 u MPLS working group established, 1998 u Policy working group established, 1998

6. Page 5 Sprint PCS History of IETF QoS u Differentiated Services working group established, 1998 u RFC 2381 Interoperation of Controlled-Load Service and Guaranteed Service with ATM, 1998 u RFC 2474 Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers, 1998 u RFC 2475 An Architecture for Differentiated Services, 1998 u RFC 2597 Assured Forwarding PHB Group, 1999 u RFC 2598 An Expedited Forwarding PHB, 1999 u RFC 2689 Providing Integrated Services over Low-bit rate Links, 1999 u IEEE 802.1p released u RFC 2816 A Framework for Integrated Services Over Shared and Switched IEEE 802 LAN Technologies, 2000 u MPLS Support of Differentiated Services, Internet Draft, 2000

7. Page 6 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: u Guaranteed Quality of Service (RFC 2212) u Controlled Load (RFC 2211) Integrated Services are specified using the Network Element Service Specification template (RFC 2216)

8. Page 7 Sprint PCS Guaranteed Quality of Service RFC 2212 u Guaranteed service provides firm (mathematically provable) bounds on end-to-end datagram queuing delays. u 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)

9. Page 8 Sprint PCS Guaranteed Quality of Service u 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 u (r,b) allows for bursty traffic, while p limits the total load u all packets less then m bytes in length are policed as if they were exactly m bytes long u 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)

10. Page 9 Sprint PCS Controlled Load RFC 2211 u 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) u 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)

11. Page 10 Sprint PCS Controlled Load u 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. u This is the same as saying the peak rate is the same as the line rate at the ingress interface u Non-conformant traffic (traffic that exceeds rT+b) is to treated as a normal condition, and given best effort service. u No quantitative performance guarantees.

12. Page 11 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

13. Page 12 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

14. Page 13 Sprint PCS RSVP Message Types: u RSVP messages are IP packets with PID = 46 u 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

15. Page 14 Sprint PCS SenderReceiverForwarding Node Forwarding Node Forwarding Node PATH RSVP Protocol u 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 u PATH message is forwarded, hop-by-hop u 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

16. Page 15 Sprint PCS SenderReceiverForwarding Node Forwarding Node Forwarding Node RESV PHOP RSVP u 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 u 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

17. Page 16 Sprint PCS RSVP Multicast u 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 u 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 u Largely due to possibility of path changes, RSVP path states must be refreshed periodically (every 20 seconds).

18. Page 17 Sprint PCS RFC 2208: RSVP Applicability Statement Issues around the deployment of RSVP and Integrated Services u Additional coordinated components required: message formats for QoS parameters router and host mechanisms to effect QoS policy objects admission control and security functions u Three deployment issues: scalability security policy control (migration)

19. Page 18 Sprint PCS RFC 2208: RSVP Applicability Statement Is RSVP and Integrated Services not scaleable? u The issue is overhead per IP flow versus the utility of per flow QoS u The most significany impact would be on traditional router implementations which have minimal signalling support u RSVP and Integrated Services can be used to provide QoS to aggregates of flows

20. Page 19 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: u Behavioral Aggregates (BAs) –groups of IP flows that are to receive similar forwarding treatment u Per Hop Behaviors (PHBs) –a description of the forwarding treatment at each network entity u 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.

21. Page 20 Sprint PCS version (4) header length (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) IP header first word of UDP/TCP header A 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:

22. Page 21 Sprint PCS SenderForwarding Node Forwarding Node Forwarding Node IP mflows BAs Forwarding Node BAs AccessEdgeInterior PHB Diff Serv Domain Differentiated Services Architecture

23. Page 22 Sprint PCS Wireless Access Network Differentiated Services Architecture ` ` Ethernet Hub Boundary IP Router Edge IP Router Boundary IP Router Dial Up Access Network Edge IP Router Carrier Network Carrier Network Enterprise Intranet Radio Access Point Modem Bank Edge IP Router Diff Serv Domains Edge IP Router RFC 2475 Behavioral Aggregates IP microflows

24. Page 23 Sprint PCS Per Hop Behaviors PHBs are the defining components of Diff Serv QoS: u The PHB concept captures the forwarding treatment giving to a flow of packets at a single node u The forwarding treatment is simply a combination of queuing and scheduling: –a PHB is, in practice, the treatment provided by a queuing discipline u There are many queuing solutions for a given PHB (considered an implementation issue)

25. Page 24 Sprint PCS Router Multi-Field Classifier Meter Queue Marker Policer/ Shaper Queue Scheduler Queue Manager Configuration and Control Traffic Conditioning Behavioral Classifier Per Hop Behavior a Differentiated Services Router Logical Model A few examples of queuing disciplines: u Weighted Fair Queuing (WFQ) u Priority Queuing (PQ) u Round Robin (RR) u Weighted Round Robin (WRR) u Class Based Queuing (CBQ)

26. Page 25 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)

27. Page 26 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

28. Page 27 Sprint PCS Expedited Forwarding EF PHB offers a low latency, low jitter, per hop behavior (RFC 2598) u 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 u This ensures that the EF queue will always be (nearly) empty u 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)

29. Page 28 Sprint PCS Assured Forwarding AF PHB offers relative differentiation (RFC 2597) u 4 AF classes, each with 3 drop precedences u Resources - buffer space and bandwidth - are allocated to each AF class in unequal portions u Between two AF classes under similar traffic loads, the class with greater buffer space and bandwidth will experience better forwarding performance u Under heavy traffic loads, packets with high drop precedence will be dropped before packets with medium drop precedence. u The three levels of drop precedence are set by the traffic conditioner

30. Page 29 Sprint PCS Router Multi-Field Classifier Meter Queue Marker Shaper/ Dropper Queue Scheduler Queue Manager Configuration and Control Traffic Conditioning Behavioral Classifier Per Hop Behavior a Differentiated Services Router Logical Model

31. Page 30 Sprint PCS Classification Multi-Field Classification u refers to the use of various fields of an IP packet to discriminate one IP traffic flow from another u classification usually based upon the IP 5-tuple (PID, SA, DA, SP, DP) u 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) u MF Classification is typically performed at the edges of a DS domain

32. Page 31 Sprint PCS Traffic Conditioning Traffic Conditioning: u metering of an IP flow to measure offered load u policing of an IP flow to ensure that the offered load does not exceed service limits u shaping of an IP flow that exceeds the load limits for a short time u marking of an MF classified IP flow with the appropriate DS Code Point

33. Page 32 Sprint PCS version (4) header length (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) IP header first word of UDP/TCP header The DSCP also identifies the Behavioral Aggregate CU (2) CU = currently unused Marking and the Diff Serv Code Point The DSCP (RFC 2474) is a six bit field identifying the PHB treatment

34. Page 33 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) AssignmentReferencesDSCP Po ol 3 2 1 xxxx01 xxxx11 100ppp 011ppp RFC 2597001ppp RFC 791, RFC 1122, RFC 1812xxx000 RFC 1812000000 ppp Drop Precedence 1100High 100Medium 010Low Code Point Space (RFC 2474)

35. Page 34 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) u 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 u red marked packets are dropped immediately u yellow marked packets are dropped if the queue is congested (e.g. RED) u green marked packets are forwarded The colors are encoded into the DSCPs (e.g. as AF drop precedents)

36. Page 35 Sprint PCS Will the Differentiated Services Approach Work? Many open questions: u What are the appropriate queuing disciplines to effect a PHB? u What traffic conditioning is most appropriate for each PHB? u What are the end to end services the will result? u How do you support services with strict performance requirements such as voice or video? u What happens with routers from different manufacturers in one DS domain? u What happens when you mix DS domains? u What about DS over different link layers (e.g. wireless)? u What about other service quality attributes such as reachability, reliability, data integrity? u 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.

37. Page 36 Sprint PCS Diff Edge Use of RSVP Request QoS in a Differentiated Services network (draft-ietf-issll-diffserv-rsvp-05.txt) u RSVP is originated by the end system (sender or receiver) as if the end system were talking to an Integrated Services network u The DS network traps the RSVP messages at the network edge, and maps the RSVP QoS request into a DSCP u 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 u The sender can then mark each packet with the appropriate DSCP u Diff Edge can be used to effect Admission Control in a DS access network. u RSVP DClass is supported by the Winsock 2 API (Windows 2000)

38. Page 37 Sprint PCS Will the Differentiated Services Approach Work? Many open questions: u What are the appropriate queuing disciplines to effect a PHB? u What traffic conditioning is most appropriate for each PHB? u What are the end to end services the will result? u How do you support services with strict performance requirements such as voice or video? u What happens with routers from different manufacturers in one DS domain? u What happens when you mix DS domains? u What about DS over different link layers (e.g. wireless)? u What about other service quality attributes such as reachability, reliability, data integrity? u How do you charge the user for a service that cannot be guaranteed? The prevalent response is to over-provision the network