Author : S.chandrashekhar Designation: Project Leader Company : Sasken Communication Technologies

Transcription

1 White Paper On Sasken IP Quality of Service Integrated Services Operation Over Differentiated Service Networks & Policy Based Admission Control in RSVP Author : S.chandrashekhar Designation: Project Leader Company : Sasken Communication Technologies mailto:s.chandrashekhar@sasken.com Abstract: This document describes about the architectures for IP Quality of Service (QoS) in the Internet and the need for Sasken Quality of service. Both Differentiated services architecture and integrated services architecture have got some disadvantages. An integrated Diffserv - Intserv solution seems to be the most affordable and efficient one. That is what SASKEN QoS is intended to perform. The goal is to provide flexible usage of Intserv or Diffserv or both depending on the deployment. The proposed solution involves mapping of Intserv services over a Diffserv service (aggregation) along with the policy based admission control. The ultimate goal is to achieve Intserv QoS for the aggregated flows within the Diffserv cloud. The basic idea is to use "RSVP_ Aggregation/Diffserv" approach in the "Core Network" and "RSVP/Intserv" approach in the "Access Network".. 1 of 18

2 IP- Quality of Service Need for QoS in IP Networks. IP networks provide best effort data delivery by default. Best effort IP allows the complexity to stay in end-hosts, so the network can remain relatively simple. As more and more hosts are connected, network service demands eventually exceed capacity, but service is not denied. Instead it degrades. Although the resulting variability in delivery delays (jitter) and packet loss do not adversely affect typical Internet applications such as , file transfer and web applications, but other applications cannot adopt to inconsistent service levels. Delivery delays cause problems for real-time applications with real-time requirements, such as those that deliver multimedia, the most demanding of which are two-way applications like telephony. Increasing bandwidth is the necessary first step for accommodating these real time applications, but it is still not enough to avoid jitter during traffic bursts. Even on a relatively unloaded IP network, delivery delays can vary enough to continue to adversely affect real time applications. To provide adequate service - some level of quantitative or quantitative determinism - IP services must be supplemented. This requires adding some smarts to the net to distinguish traffic from those that can tolerate delay, jitter and loss. This is what quality of service (QoS) protocols are designed to do. QoS does not create bandwidth, but manage it, so that it is used more effectively to meet the wide range of applications requirements. The goal of QoS is to provide some level of predictability and control beyond the current IP best-effort service. To avoid potential problems as QoS protocols are applied to the net, the end-toend principle is still the primary focus of QoS architects. As a result, the fundamental principle of Leave complexity at the edges and keep the network core simple is a central theme among QoS architecture designs. Architectures for QoS in the Internet There is more than one way to characterize Quality of Service (QoS). Generally speaking, QoS is the ability of a network element (e.g. an application, a host or a router) to provide some level of assurance for consistent network data delivery. Some applications are more stringent about their QoS requirements than others, and for this reason, we have two basic types of QoS architectures available: Resource reservation (Integrated Services): Network resources are apportioned according to an application s QoS request, and subject to bandwidth management policy. 2 of 18

3 Prioritization (Differentiated Services): Network traffic is classified and apportioned network resources according to bandwidth management policy criteria. To enable QoS, network elements give preferential treatment to classifications identified as having more demanding requirements. These types of QoS can be applied to individual application flows or to flow aggregates, hence there are two other ways to characterize types of QoS: Per Flow: A flow is defined as an individual, unidirectional, data stream between two applications (sender and receiver), uniquely identified by a 5-tuple (transport protocol, source address, source port number, destination address, and destination port number). Intserv provides per flow mechanism. Per Aggregate: An aggregate is simply two or more flows. Typically the flows will have something in common (e.g. any one or more of the 5-tuple parameters, a label or a priority number, or perhaps some authentication information). Diffserv provides per aggregate mechanism. Integrated Services Architecture The Internet Integrated Services architecture was originated by the End-to-End Research Group of the Internet Research Taskforce in the years 1991 and The RFC 1663 containing proposed IIS Architecture, the extended service model (known as IIS model) and reference model for implementation was finalized in Currently, the IIS extended services consist of two new service classes, Controlled-Load Service and Guaranteed Service. The guaranteed service is intended for applications that require a perfectly reliable upper bound on the network delay. The controlled-load service is intended for applications that work well with a non-congested network providing best-effort service. The guaranteed service ensures that packets do arrive before the requested maximum delivery time and they are not dropped due to network congestion. However, the application using the service must ensure that the traffic keeps within the specified traffic parameters. Currently, a token bucket is used to parameter the traffic. The guaranteed service does not specify the delay jitter, minimum or average delay of packets, although in order to calculate the maximum delay the data path latency, i.e. minimum delay, has to be determined. The controlled-load service ensures that the applications get QoS similar to unloaded network even when the network is heavily loaded. There is no delay bound or any other guarantees. The provided service is minimalistic on purpose; it allows implementations, which utilize network resources in an extremely efficient way. The controlled-load service suits well for soft real-time 3 of 18

4 applications or audio/video applications that recover gracefully from occasionally lost frames. The IIS Implementation Framework includes the network functions that are needed to realize the new service classes and the resource reservation. They include QoS support from underlying network layer, the traffic control functions, the RSVP protocol functions and the functions enforcing the policing. Figure 1. RSVP Reservation along the path between sender and receiver RSVP is a signalling protocol used for resource reservation in routers and hosts. But it differs radically from the traditional signalling protocols. Among other things, it features only simplex reservations made by receiver, combining reservations within a multicast tree, soft reservation state along the data flow, and dynamic change of resource requests. Figure 2: Integrated services model In the IIS architecture each QoS-capable node feeds all incoming packets to the packet classifier. The packet classifier decides to which route and QoS class each packet belongs. A packet scheduler then queues and forwards the packets according the promised QoS. The packet scheduler may have to negotiate the QoS parameters for traffic with data link layer. In all the nodes resource reservation requests are handled by two modules, admission control module and policy control module. The admission control 4 of 18

5 module makes sure that the network resources suffice for the request. The policy control module determines who can and who cannot reserve network resources on node. The policy control module can also query permission for reservation requests from separate policy server. The packet classifier, the packet scheduler and the admission control module form the traffic control. They actually implement the QoS new service models defined by the IIS architecture. There is also an RSVP process in each IIS network node. In a network host the RSVP daemon provides an API to the application programs. It also receives and sends the RSVP messages, authenticates requests with the policy control module and relays the objects concerning flow classifying, scheduling and admission control to the appropriate traffic control modules within the local host. Those objects are opaque data to RSVP process itself. In a router, the RSVP process relays the appropriate objects to the traffic control. It also stores those objects in the flow state. The RSVP process uses the routing databases to route RSVP messages to appropriate destinations. Differentiated Services Architecture In response to demand for a robust, common system for service classification, an IETF Working Group (Diffserv) has defined a framework and definitions for a Differentiated Services (DS) mechanism. DS will not be based on priority, application, or flow, but on the possible forwarding behaviours of packets, called Per-Hop Behaviours (PHBs). DS is rule based. Therefore, it is a unique mechanism for policy-based network management. Instead of applying faster, more expensive, advanced technology, networks can be managed by appropriate network policies, applying current network technology and resources while considering in-house traffic and upstream and downstream networks, whether they are the corporate LAN backbone or external WANs. DS is analogous to consumer-based differentiated service industries, such as travel services. A person can travel by bus, train, or airplane; 1st class, business class, coach, or standby. Each class of service can be characterized by how fast you reach your destination, how many stops you make along the way, and what kind of service amenities you receive enroute, if any. Some services may have limitations, such as when you can travel, and others, such as standby, include risk of not reaching your destination in the time frame expected. In all cases, you pay more for higher quality services. The Differentiated Services framework offers the same kind of classification system. Based on network policies, different kinds of traffic can be marked for different kinds of forwarding. Resources can then be allocated according to the 5 of 18

6 marking and the policies. Just as a travel ticket encodes your travel service level, in the DS architecture, The Ipv4 header contains the TOS byte. The DS field is used to replace the TOS octet in Ipv4 and IPv6 Traffic class octet as shown in figure 4. The six bits out of the eight bits of the DS field are used as a code point i.e., DSCP (Differentiated Service Code Point). The rest two bits are reserved for future definitions. Figure 3 : TOS byte before Diffserv Figure 4: TOS byte after Diffserv The DS field can be marked with specific DSCP. The DSCP maps the packet to a particular forwarding behaviour (PHB) for processing by a DS-compliant router; The PHB provides a particular service level (bandwidth, queuing, and dropping decisions) in accordance with network policy. For example, the mission-critical packets could be encoded with a DSCP that indicated a high bandwidth, zero-frame-loss routing path. Interactive video conferencing data and all data from the CEO s computer may carry the same 6 of 18

7 requirement and be aggregated with mission-critical packets. and web browsing data could be coded with a DSCP indicating routine traffic handling with minimal packet drops. The DS-compliant boundary router would then make route selections and forward the packets accordingly as defined by network policy and the PHBs the network supports. The highest-class traffic would get preferential treatment in queuing and bandwidth while the lower class packets would be relegated to slower service. Since the DSCP is six bits wide, it can allow, coding for up to 64 different forwarding behaviours and DSCP retains backward compatibility with the three precedence bits, so that non-ds compliant, TOS-enabled nodes will not conflict with the DSCP mapping. Differentiated Services provides a simple and coarse method of classifying services of various applications. Although others are possible, there are currently two standard per hop behaviours (PHs) defined that effectively represent four service levels (traffic classes): Expedited Forwarding (EF): Has a single code point (Diffserv value). It minimizes delay, jitter and provides the highest level of aggregate quality of service. Any traffic that exceeds the traffic profile (which is defined by local policy) is discarded. Assured Forwarding (AF): Has four classes and three-drop precedences within each class (so a total of twelve code points). Excess AF traffic is not delivered with as high probability as the traffic within profile, which means it may be demoted but not necessarily dropped. DROP Precedence Class #1 Class #2 Class #3 Class #4 Low Drop Precedence (AF11) (AF21) (AF31) (AF41) Medium Drop Precedence (AF12) (AF22) (AF32) (AF42) High Drop Precedence (AF13) (AF23) (AF33) (AF43) Figure 5: Recommended AF Code Point Values. 7 of 18

8 Class Selector (CS) : Backward compatible with the TOS/IP Precedence solution. Default Forwarding (DF) - Best effort Figure 6 shows how DSCP Encoding is achieved at the Diffserv domain boundaries. Figure 6 : Per hop behaviour encoding (PHB Encoding) Figure 7 provides a sample mapping of services with packet classification (DSCP) and forwarding treatment (PHB). Services here are listed in descending order from highest priority, or most critical (e.g. VoIP), to lowest priority, or least critical (e.g. DNS). Though the values listed below are recommended QoS queues, multiple types of traffic are often assigned a specific PHB. Service Class (Associated Services) DSCP Value (Binary Number) Forwarding Treatment (Per Hop Behaviour) Telephony (VoIP, Voice band data,...) 46 ( ) Expedited Forwarding Signalling (Peer-to-Peer IP, signalling for IPTV 40 ( ) Class Selector 5 8 of 18

9 apps,...) Multimedia Conferencing (Video conferencing, mission critical apps,...) 34 ( ) Assured Forwarding 4 Real-Time Interactive (Interactive Gaming, IP VPN,...) 32 ( ) Class Selector 4 Multimedia Streaming (Buffered Streaming Audio, webcasts,...) 26 ( ) Assured Forwarding 3 Broadcast Video (Video surveillance, video on demand,...) 24 ( ) Class Selector 3 Low-Latency Data (Web transactions, financial wire transfers,...) 18 ( ) Assured Forwarding 2 High-Throughput Data (File transfers, ,...) 10 ( ) Assured Forwarding 1 Standard (DNS, DHCP,...) 0 ( ) Default Forwarding Figure 7: Sample Mapping of Service Classes to Forwarding Treatment Traffic Conditioning Edge routers perform traffic conditioning and assign the DSCPs on the basis of an SLA - Service Level Agreement - negotiated between the customer and the network provider. The classifier reads the DSCP and/or other field (source IP, destination IP, source port, destination port, etc.), selects and routes packets to a Traffic Conditioner (TC). The role of the traffic conditioner is to ensure that the flows are in line with the SLA. This is done by: 9 of 18

10 Monitoring the temporal traffic flow of each packet stream (meter) to see if it is within the required profile and by triggering re-marking, dropping, or shaping, if it is out of profile. Changing the DSCP, if necessary, in order to change the forwarding behaviour (Marker). Delaying packets of an out of line flow, in order to cause it to conform to the agreed traffic profile (shaper). Dropping the packet, if allowed (Dropper). Figure 8: Traffic conditioning elements in Diffserv Router. In order to specify a Diffserv architecture, it is therefore necessary to specify the building blocks illustrated in Figure 5, i.e., to specify 1. The quantitative parameters for a given PHB to be applied to aggregate flows. 2. The traffic conditioning functions such as filters and the corresponding traffic profiles. 3. Miscellaneous configuration information including routing information or media support. Classifier Packet classifiers select packets in a traffic stream based on the content of some portion of the packet header such as DSCP, source or destination IP address, etc. Classifiers are used to steer packets matching some specified rule to an element of a traffic conditioner for further processing. Behaviour Aggregate (BA) or Multi-field (MF) classification can be performed. A Behaviour Aggregate classifier selects packets based only in the contents of the DSCP field, while a Multi-field classifier selects packets based on the content of some arbitrary 10 of 18

11 number of header fields; typically some combination of source address, destination address, DS field, protocol ID, source port and destination port. Usually BA classifier is performed on the interior nodes of a Diffserv domain, while MF classifiers are located at the ingress or egress nodes of a Diffserv domain. Meter The meter function will be governed by a policing function intended to assure that each class is in conformance with the SLA. In the platform, conformance to the SLA will be verified using a single or multiple token bucket approach. Also, the exponential token bucket will be used as a means of metering for the SLAs based on the respective PHBs. Marker Packet markers set the DS field of a packet to a particular code point, classifying the marked packet to a particular DS behaviour aggregate. The marker may be configured to mark all packets, which are steered to it to a single code point, or may be configured to mark a packet to one of a set of code points used to select a PHB in a PHB group, according to the state of a meter. When a marker changes the code point in a packet, it is said to have re-marked the packet the sender has already marked. DSCP re-marking may be performed in egress and core nodes, according to the SLS. Need for SASKEN QoS Best effort delivery has no guarantee of service. Therefore applications that require QoS cannot run over purely best effort networks. Intserv has been proposed by IETF to reserve resources in advance, so that selected flows can enjoy the privilege of being treated with guaranteed resources. That s not an exhaustive solution, anyway, as problems occur when mapping this model over a real network. Intserv makes routers very complicated. Intermediate routers have to have modules to support RSVP reservations and also treat flows according to the reservations. In addition they have to support RSVP messages and coordinate with policy servers It is not scalable with the number of flows. As the number of flows increases, routing becomes incredibly difficult. The backbone core routers become slow when they try to accommodate an increasing number of RSVP flows. RSVP imposes maintenance of soft states at the intermediate routers. This implies that routers have to constantly monitor and update states on a perflow basis. In addition the periodic messages sent add to the congestion in the network. 11 of 18

12 To solve scalability problems, the alternative solution of pure Diffserv scenario has been defined within IETF. However, this solution has several disadvantages. QoS is granted to traffic aggregated, not to individual flows. Providing quality of service to traffic flows on a per-hop basis often cannot guarantee end-to-end QoS. Diffserv cannot account for dynamic SLAs between the customer and the provider. It assumes a static SLA configuration. But in the real world network topologies change very fast. Diffserv is sender-oriented. Once again, in many flows, the receiver s requests have to be accounted for. Persistent flows like, high bandwidth videoconferencing, better benefit of perflow guarantees. But Diffserv only provides guarantees for the aggregates. An integrated Diffserv - Intserv solution seems to be the most affordable and efficient one. That is what SASKEN QoS is intended to perform. The goal is to provide flexible usage of Intserv or Diffserv or both depending on the deployment. SASKEN QoS The proposed solution is to achieve Intserv QoS for the aggregated flows within the Diffserv cloud, based on policy based admission control. Figure 9: Sample Network Configuration. 12 of 18

13 The idea is to use RSVP Aggregation / Diffserv approach in the Core Network and RSVP / Intserv approach in the Access Network. In this scenario, a key role is played by internetworking devices called Edge Routers (Aggregator, De-aggregator) placed at the borders between the two domains as shown in figure 6. The aggregator receives RSVP path messages from RSVP sources, stores the PATH state and forwards the messages toward the destination. Figure 10: RSVP-DiffServ interoperation The routers in the core simply ignore the RSVP messages and forward them transparently (i.e., without processing them). When PATH message reaches deaggregator (RSVP capable), it is interpreted and forwarded towards the final destination. The routers within the Diffserv cloud (Aggregated Region) are capable of performing RSVP aggregation. Aggregate PATH messages are sent from the aggregator to the de-aggregator using RSVP s normal IP protocol number. Aggregate RESV messages are sent back from the de-aggregator to the aggregator, thus establishing aggregate reservation. On the receipt E2E RESV the de-aggregator applies the mapping policy (using the policy based admission control) to map the E2E RESV on to an aggregate reservation. Having determined an appropriate DSCP, the de-aggregator performs admission control of E2E RESV on to aggregate RESV for that particular DSCP. Then the de-aggregator forwards the E2E RESV to the aggregator, including a DCLASS object, conveying the selected mapping onto specific DSCP. The aggregator records the DSCP mentioned in the DCLASS 13 of 18

14 object and removes the DCLASS object and forwards E2E RESV towards the sender. To achieve policy based admission control, original RSVP needs to be extended to carry policy information. RSVP messages are extended to carry POLICY_DATA objects that contain policy information. Only sender or receiver can generate or modify policy objects. Messages without the policy objects will be ignored. The exchange of POLICYDATA object between the policy capable nodes along the data path supports the generation of consistent end-to-end policies. The two main architectural elements for policy control are the PEP and PDP as shown in figure 8. RSVP capable router will in turn acts as PEP and PDP is a remote entity that may reside at a policy server. The request for policy control from PEP to the PDP contains one or more policy elements (encapsulated in to one or more policy objects) in addition to the admission control information. The PDP refers the policy database and returns the policy decision. Then the PEP enforces the policy decision by appropriately accepting or denying the request. The policy will be applied based on User or Application Identity. This identity information is carried as AUTH_DATA policy element in a POLICY_DATA object. Figure 11: The Policy framework 14 of 18

15 COPS protocol is used to exchange the policy information between PEP and PDP. RSVP messages are encapsulated in the COPS object (ClientSI object) of REQ message and sent from PEP to remote PDP. PDP is a RSVP knowledgeable node, which understands the ClientSI object and returns the decision using a decision object in DEC message to the PEP. SASKEN QoS Features RSVP aggregation The flows are aggregated with the help of Netfilter classifier, using aggregation identifier. For each service (CL,G i.e., for the corresponding DSCP), resources are allocated by using aggregate PATH and aggregate RESV messages within the aggregation region. The selection of specific DSCP for a particular flow, which belongs to a specific aggregation, is done, by using policy based admission control, at the de-aggregator, which acts as PEP. Support for Intserv basic services The basic services provided by Intserv are Controlled Load Service and Guaranteed Service.. The resources for these basic services (i.e., for the corresponding DSCPs) is allocated, by using aggregate PATH and RESV messages within the aggregation region. Each service is provided with the corresponding DSCP from the policy database at the de-aggregator. NULL Service This proposal will provide support for Null Service by using policy information. With the help of identity information, the QoS is applied for that application. A corresponding DSCP is put into DCLASS object that is part of RESV message. The user will use this DCLASS information and mark the packets with the corresponding DSCP. Extending RSVP POLICY_DATA object Since the current RSVP implementation does not support policy based admission control, the policy object in RSVP messages does not carry any information. So to provide policy control this object will be modified to carry policy information. Identity based policy control This proposal aims to provide admission control based on identity of user and application. POLICY_DATA object contains AUTHJDATA, policy element that provides identity information. Conclusion Brilliant solutions don t always have to be complicated. In the case of QoS, in fact, simple and direct is the best paradigm. 15 of 18

16 Apply the solution close to the source of the problem (it s more efficient, less disruptive, less costly, etc.) Apply the most efficient and useful technique to each type of traffic problem, but coordinate the efforts through an integrated solution (or your optimizations may conflict with each other, which can cancel out the benefits) Think flexibility bandwidth optimization and customer support are moving targets in the age of the Internet. The ultimate solution is the one that allows you to change your solution to meet the challenges of a new day. 16 of 18

17 IETF References Title Date Organization Integrated service mappings for Differentiated services Networks Format of the RSVP DCLASS Object Specification of the Null Service Type A Framework for Integrated Services Operation over Diffserv Networks Aggregation of RSVP for Ipv4 and IPv6 Reservations RSVP Extensions For Policy Control Identity Representation For RSVP COPS Usage For RSVP February 2001 November 2000 November 2000 November 2000 September 2001 December 2001 December 2001 January 2000 IETF- ISSLL Working Group IETF- ISSLL Working Group IETF- ISSLL Working Group IETF - ISSLL Working Group IETF- ISSLL Working Group IETF - Resource Allocation Protocol Working Group IETF - Resource Allocation Protocol Working Group IETF - Resource Allocation Protocol Working Group 17 of 18

18 Definitions, Acronyms and Abbreviations RSVP Resource Reservation Protocol KAL Kernel Abstraction Layer RTAP Real Time Application Protocol PEP Policy Enforcement Point PDP Policy Decision Point LDAP Light Weight Directory Access Protocol PIB Policy Information Base Diffserv Differentiated Services Intserv Integrated Services E2E End-to-End DCLAS Differentiated Class DSCP Differentiated Services Code Point IETF Internet Engineering Task Force RFC Request For Comments Ipv4 Internet Protocol Version 4 QoS Quality of Service COPS CLI CVS IIS API Common Open Policy Service Command Line Interface Concurrent Versions System Internet Integrated Services Application Programming Interface 18 of 18