Optimizing Network Services - Essay Example

IP Quality of Service CSN 11105 - Optimising Networks and Services Supervisor's Department Introduction Network services have been broadly classified into data and real-time services, where the first are sensitive to packet loss and the second are sensitive to delay and delay variation (jitter). Packet loss is an occasional must in any data network and is handled by application layer retransmissions as necessary. Delay and jitter are more difficult to manage since providing performance guarantees requires complex stochastic conditioning of traffic flows between the service endpoints and along the nodes en-route. This report considers the merit, methodologies, and tradeoffs of implementing Quality of Service (QoS) schemes across IP networks. Depending on scale and services involved, there is a choice between ignoring QoS and just over dimensioning resources and implementing QoS at one or more layers, using one of two architectures, through protocols of different robustness and complexity. Discussion A comprehensive discussion of QoS need to first provide a concise description of the broad topic of service quality handling in IP networks. There are several axes in addressing this topic. First, QoS has been known and practiced in layer 2 protocols: IEEE 802.3 series Media Access Control (MAC) protocols, Frame Relay, and Asynchronous Transfer Mode (ATM). Second, layer 3 QoS may be considered for two classes of IP networks: 1) IP WANs, where virtual channels between sites are realized using Frame Relay or ATM; and 2) IP VPNs, where Multi-Protocol Label Switching (MPLS), also known as layer 3 switching, is used for defining layer 3 flows though coloring corresponding IP packets Third and last, QoS can be implemented through one of two architectures, in the order of their development (RFC 2998): Integrated services (Intserv) and differential services (Diffserv). 1.1 Intserv architecture Intserv architecture defines two services (Vegesna 2001): 1. Guaranteed service--provides deterministic delay; and 2. Controlled load service--provides best-effort delivery under lightly loaded conditions Resource ReSerVation Protocol (RSVP) is the end-to-end signaling protocol used in the Intserv architecture, which requires guaranteed per-flow QoS over the IP network. RSVP incurs a scalability issue since the amount of state information that needs to be tracked about individual flows would become intractable as the number of flows increase in a realistic scenario. In an RSVP implementation, receiving nodes send bandwidth reservation messages to each router en-route back to the service source. This technique allows RSVP-enabled routers to take note of receiving nodes reserving resources for the same flows, inferring a multicast service and aggregating traffic for bandwidth efficiency (Oram 2002). The reservation components consist of a traffic receiver (RSVP sender), an RSVP receiver, and a number of RSVP-enabled routers. An RSVP-enabled router is equipped with two local decision modules: 1. Admission control, which determines the sufficiency of required resources to support the reservation; and 2. Policy control, which determines whether the user had administrative permission to make that reservation. Call admission control (CAC) determines the admissibility of real-time traffic to the network when there are not sufficient resources to accommodate such traffic, which cannot be simply dropped as could data traffic. A voice/video call that is being attempted when there are not enough bandwidth and delay guarantees would need to be attempted at a later time or possibly re-routed through PSTN or ISDN. Extensions are defined for policy control as well. If the reservation passes the two fore-mentioned controls, RSVP sets packet classification and packet scheduling parameters to achieve the desired QoS. RSVP runs directly over IP, with two main message types to note: PATH and RESV, which respectively describe flow parameters and corresponding needed resource guarantees (Vegesna 2001). Generally, RSVP's working principle of flow-based reservation implies that it wouldn't scale very well. RSVP has a good business case for small to medium intranets with relatively low link bit rates (below tens of Mbps). 1.2 Diffserv architecture Diffserv architecture differentiates packets of different flows by setting the IP packet header values of the Differentiated Service Code point (DSCP) field, for managing the packets' Per Hop Behavior (PHB). The DSCP field is used for packet marking following its classification. Diffserv architecture performs the following functions (Vegesna 2001): 1. Traffic Conditioning, in turn made of (Vegesna 2001): a. Packet Classification b. Traffic Shaping c. Traffic Policing 2. PHB Resource Allocation; Implemented used one or more of the following algorithms: WFQ, CBWFQ, and MWRR. 3. PHB Congestion Avoidance and Packet Drop Policy, operate jointly at TCP/IP levels using one or more of the following algorithms: RED, WRED, ECN, and SPD. The network boundary traffic conditioners consist of (Vegesna 2001): Marker (writes or re-writes the DSCP field), Classifier (classifies packet according to the DSCP field value), Metering (checks compliance to traffic profile), Shaper (delays traffic through buffering to comply with designated profile), and Dropper (drops packets not in compliance with profile). The following definitions are essential to understanding the above Diffserv framework (Vegesna 2001). Conditioning (classification, marking, policing, shaping) IP Precedence: A three-bit field in the Type of Service (ToS) byte, set to indicate the relative priority with which a packet should be handled. IP Precedence can be written by the application that created the packet or by a node in the network. PHB: A pre-defined traffic class that describes the forwarding behavior of a Diffserv node applied to a set of packets with identical DSCP values. A PHB class depends on traffic load, required resource allocation, and packet discard policy. Explicit Forwarding (EF) PHB: A resource allocation centered PHB that uses Diffserv domains to accommodate an assured bandwidth end-to-end service with low loss, latency, and jitter. Assured Forwarding (AF) PHB: Provides differentiated service levels among its four traffic classes, where each class is served in a separate queue (a total of 12 service levels). DSCP: A six-bit field used to indicate a certain PHB in a network. The DSCP field is an extension to the three bits used for IP precedence. It can be set to one of the following: Default DSCP, best-effort service (DSCP = 000 000) Class Selector, 7 possible precedence values (DSCP = "001 through 111" 000) EF PHB, defines premium service (DSCP = 101 110) AF PHB, 4 service classes, each has 3 drop precedence levels (12 possible DSCP values) QoS Group: A field (or label) in the packet data structure representation internal to the router that is not a part of the IP packet header. Routers perform packet marking based on the QoS Group using functions like CAR, PBR (Policy Based Router), and QPPB (QoS Policy Propagation using BGP exterior routing protocol. Resource allocation (queuing, scheduling) Weighted Fair Queuing (WFQ): Fair Queuing treats each flow in an own logical small queue and services a fractional amount of data in each queue in a round robin fashion. WFQ differentiates flows in the scheduling process, by assigning weights and prioritizing queue servicing, based on the IP Precedence value. WFQ limits packet discard to the most demanding flows. Class Based WFQ (CBWFQ): Allocates separate sub-queues for each traffic class, enabling users to directly specify the minimum required bandwidth per class. Modified Weighted Round Robin (MWRR): Round-robin scheduling serves a whole packet at a time instead of a small data unit such as a byte. WRR serves flows according to weights that are assigned to each. MWRR employs a deficit counter attributed to each WRR queue. Congestion avoidance & drop policy Random Early Detection (RED): A congestion avoidance queue management algorithm. It drops packets using a probabilistic function once the average queue size exceeds a threshold. The drop probability is set such that packets are dropped only from a few (a minority of) queues. Weighted RED (WRED): Employs packet drop probability to implement grades of packet service and also supports setting selective RED parameters based on IP Precedence. Explicit Congestion Notification (ECN): Signals congestion to the TCP source by marking a packet header rather than dropping the packet. It requires setting a bit in the IP packet header so that TCP endpoints could determine at session start whether ECN is enabled at each end. Selective Packet Discard (SPD): Distinguishes vital routing and network control traffic over user data traffic. Diffserv architecture achieves scalability by eliminating dependence on per-flow state information through a collection of simplified classification and conditioning functions, implemented only at network boundary nodes. PHB is applied to aggregates of traffic that have been appropriately marked using the DSCP (RFC 2472 - 1998). The combination of packet marking and well defined PHBs eliminates end-to-end signaling and flow state maintenance and results in a scalable, coarse-grained QoS solution. The disadvantages of Diffserv include (Cisco Systems 2005): Unlike RSVP, Diffserv PHB classes need to be configured across the involved network elements. The required traffic profiling is time-demanding. Management and billing involve setting counters to tally each packet class allowed through, while the customer only cares at the end about the delivered service quality. It is difficult to provide assurance for consistent quality of service of the same class of traffic from multiple sources. Hierarchical policies may need to be defined. The QoS process is treated separately from routing protocols, something that may result in non-optimal or conflicting traffic direction. 1.3 Combining Intserv and Diffserv frameworks IETF RFC 2998 describes a generic model in which a Diffserv network can be used in the context of the Intserv architecture to support the delivery of end-to-end QOS. It works by applying the Intserv model end-to-end across a network containing one or more Diffserv regions/domains. As viewed by Intserv, the Diffserv domains are analogous to virtual links connecting Intserv/RSVP capable routers or hosts. Routers within each Diffserv domain implement specific PHBs. The model is a clever engineering compromise between two extremities: pushing a Diffserv region all the way to the network edge, where source and destination hosts are RSVP capable; and pushing Intserv all the way to the core, with no Diffserv domains. Most current routers support both Intserv and Diffserv architectures and allow the above model of an end-to-end Intserv with multiple Diffserv domains. RSVP vs. PHB: RSVP carries the request through the network, visiting each node the network uses to carry the stream. At each node, RSVP attempts to make a resource reservation for the stream, before reporting back to the application and allowing the call/communication. PHB QoS checks the application traffic marking to provide priority on a PHB basis through the network. 1.4 IP VPN QoS Multi-Protocol Label Switching (MPLS) is a protocol that supports virtual switching over IP infrastructure; based on labeling IP datagram packets. MPLS VPN service offerings inherently offer full-mesh connectivity, the QoS administration paradigm shifts. Under a full-mesh design, the hub router still administers QoS for all campus-to-branch traffic, but it no longer fully controls the QoS for branch-to-branch traffic. Several options exist to meet strict SLA considerations for loss, delay, and jitter in the service-provider MPLS VPN core (Szigeti and Hattingh 2004): Aggregate bandwidth over provisioning Diffserv in the backbone MPLS traffic engineering (may or may not be used in with Diffserv in the backbone) Conclusions The report presented several facets of the broad topic of QoS in IP networks. IP was deigned to deliver upper layer service on a best-effort basis, leaving the issues of proper functioning and performance to be controlled by the transport layer (TCP) or the application protocol (HTTP, for example). The emergence of real-time application over intranets and the Internet has motivated further development of techniques to control end-to-end service quality. QoS has been implemented at layer in both Frame Relay and ATM. It was found essential that QoS must be implemented at the IP layer to better manage application performance, potentially in conjunction with layer 2 controls and also with TCP congestion avoidance mechanisms. Two architectures are currently in place for IP QoS: integrated services (Intserv) and differential services (Diffserv). Intserv, the earlier, is a more idealistic framework that relies on reserving network resources for each flow, which implied scalability limitations. Diffserv, on another hand, employs a number of functionalities to classify, mark, condition traffic and further to apply congestion avoidance and packet drop policies. Diffserv uses a non-trivial number of sophisticated algorithms, which altogether simplify its operation as it becomes more distributed and scalable. In addition, Diffserv can be implemented over multiple domains within the same network, where each domain acts as a virtual IP QoS pipe to end-to-end reservation-based Intserv. It is concluded that QoS cannot be taken within a limited context, or network layer, in isolation. For a large IP network, traffic engineering and estimation heuristics are required to divide the concerned network in terms of its layers, data and control domains, and overall topology such that feasible communication quality could be achieved at reasonable complexity. IP VPNs with MPLS promise the best potential for enterprise networks with properly configured QoS. Personal reflections The simplest approach to QoS has been to "generously" over dimension network resources to push the best-effort delivery paradigm to a point that it will "most likely" provide satisfactory performance (Wikipedia). Bandwidth is getting cheaper and there is no indication that we are approaching a physical limitation on bit rates and switching capacities. This approach is void of network engineering. It may work for cases that are well budgeted and where occasional "misses" on quality would be tolerable. The writer's main reflection is that all network layers need to collaborate to achieve quality. A complex process like this would be better handled ahead offline to come with conventions, rules of thumbs, and methods to make online implementation more intuitive and predictable. One may think of a limited-scope example such as PHB classes and how the fact that flows are characterized and classified ahead simplified the algorithmic handling of traffic conditioning. Thinking of conventions, a good argument is that we are currently dealing with several types of IP networks, of different scales: the Internet, IP WANs, and IP VPNs. Further study would produce a general QoS portray to be applied in each category. Considering the Internet example, the combined Intserv-Diffserv approach seems reasonable, since multiple Diffserv domains can be aligned with various ISPs while RSVP may or may not be enabled at network client and server edges. This would alleviate the interworking and cross-billing complexities resulting from the Internet operational ownership multiplicity. On another hand, small IP WANs may adopt the Intserv architecture provided that RSVP is supported by its network elements. There is no practical reason, as well, why Diffserv should not be implemented in this case. For large enterprise VPNs, MPLS traffic engineering has become the clear answer and is supported by all router suppliers. It provides excellent support to a label-based, virtually meshed layer 3 network, where Diffserv makes a very suitable candidate for the core part of the network. There is no one solution to fit all and QoS should rely on sophisticated traffic engineering that includes traffic measurement and simulation to facilitate the deployment of distributed algorithms. An example QoS implementation: analysis and configuration The topology of Figure 1 is an example IP WAN with one hub HQ router and two edge routers at site 1 and site 2. The hub router connects to the WAN via a T1 (1.54 Mbps) line. Figure 1: WAN configuration for QoS implementation There are three traffic flow requirements, in addition to the EIGRP routing protocol flows: Web traffic (subrate of 1 Mbps) VoIP traffic (a minimum of 4 simultaneous calls) FTP traffic (high priority with respect to any other traffic) Diffserv QoS architecture is used. For HTTP traffic, IP precedence level of 4 is set in the hub router for up to the subscribed subrate. Excess traffic is assigned an IP Precedence of 0, which means it would be delivered in a best effort basis. Assuming each VoIP call requires a sustained 64 Kbps with minimum delay and jitter (8 Kbps is now recognized for compressed voice). This means for each link, 256 Kbps needs to be allocated to voice calls admission, noting that all 4 calls can be between HQ and either site simultaneously. VoIP configuration requires both EF IP Precedence classification and RTP protocol priority queuing for delay-sensitive traffic using the default WFQ or CBWFQ (the later with class and policy maps); with the maximum possible rate (256 Kbps). Same bit rate will be configured for edge routers ingress and can be afforded by both link data rates. FTP traffic is assigned an IP Precedence of 3 to take priority next to VoIP and HTTP. References IETF RFC 2998, "A Framework for Integrated Service Operation over Diffserv Networks," Nov. 2000 Srinivas Vegesna, "IP Quality of Service," Cisco Press, 2001 Andy Oram, "A Nice Way to Get Network Quality of Service" IETF RFC 2474, "An Architecture for Differentiated Services," Dec. 1998 Cisco Systems White Paper, "Diffserv - The scalable end-to-end quality of Service Model," Aug. 2005 T. Szigeti and C. Hattingh, "End-to-End QoS Network Design," Cisco Press, Nov. 2004 Read More