INTEGRATED SERVICES AND DIFFERENTIATED SERVICES: A FUNCTIONAL COMPARISON

Transcription

1 INTEGRATED SERVICES AND DIFFERENTIATED SERVICES: A FUNCTIONAL COMPARON Franco Tommasi, Simone Molendini Faculty of Engineering, University of Lecce, Italy franco.tommasi@unile.it, simone.molendini@unile.it Abstract: The increasing demand of Quality of Service (QoS) has lead in the last years to the definition of architectures that modify the best-effort Internet, though in a backward compatible way. The Integrated Services () architecture, tightly coupled with the RSVP protocol, is first one that has been developed by IETF. Soon after its deployment some experimentation of networks raised a serious problem, due to the high overhead introduced in network elements. Someone has then started working on an new solution alternative to : the Differentiated Services () architecture. In each domain a set of services the network can offer to customers is specified. Then, this offer is properly mapped with the neighbour s offer, and the application s needs. The result is a lighter architecture that is more scalable but satisfying the QoS demands in a coarser way. Therefore, we can say that the is application-oriented and the network-oriented. In this paper we will compare different solutions to the same basic problems in both the architectures. KEYWOR: QoS, Integrated Services, Differentiated Services. 1. INTRODUCTION The increasing demand of Quality of Service (QoS) has lead in the last years to the definition of architectures that modify the best-effort Internet, though in a backward compatible way. The Integrated Services () architecture [4], tightly coupled with the RSVP protocol [5], is first one that has been developed by IETF. The architecture specifies with a very high degree of granularity the QoS needs of applications, and RSVP transmits them to all routers along the data path. Soon after its deployment, some experimentation on networks raised a serious problem, due to the high overhead introduced in network elements. Someone is trying to mitigate the effects of this problem redefining parts of the RSVP protocol [2][10] or studying aggregation mechanisms [1], someone else has started working on an new solution alternative to : the Differentiated Services () architecture [3]. According to developers, the architecture is perhaps an overkill: an effective and efficient mechanism to offer prioritized services to applications could be sufficient. In each domain a set of services the network can offer to customers is specified. Then, this offer is properly mapped with the neighbour s

2 offer, and the application s needs. The result is a lighter architecture that is more scalable but satisfying the QoS demands in a coarser way. We can say that the is application-oriented and the is network-oriented. In the following we will compare different solutions to the same basic problems in both the architectures. 2. APPLICATIONS In order to use the QoS services, an application must supply the network with the necessary information to receive the desired treatment. So a QoS architecture impacts the way applications are designed. The Resource reservation Protocol (RSVP) has been designed as a signalling protocol that applications use to convey QoS specs in routers. The architecture requires that network s nodes are notified about each application s QoS requests, therefore a strong overhead is introduced in RSVP routers which manage lots of QoS data flows. RSVP is the most widely used mechanism to transmit QoS requests to all routers in a QoS path, though it is not mandatory in the architecture [11]: other signalling mechanisms can be used. The access to the local RSVP process by applications is simplified through calls to a standard RAPI (Resource API). Though no end-to-end signalling is required in the architecture, datagrams must be marked somewhere with the proper Differentiated Services Code Point (CP) value, and this can be made in two different ways: Host marking Each host marks datagrams for each application. In order to pursuit the proper CPs, the hosts should maintain local tables provided by routers of the network they belong to. Router marking Datagrams are marked by routers in the local domain s network, maybe the first one. A mechanism like RSVP is therefore needed for the first-hop signalling, to allow applications to notify the router. More interestingly, packets can be remarked as they move to a different domain. 3. TYPE OF SERVICES A service is the way applications specify their QoS needs: what is the flexibility of the services an application can use? In the architecture an application specifies the QoS needs choosing a service and a related set of parameters, therefore a network must be ready to treat an arbitrary number of different QoS requests. In the architecture an application specifies a service selecting a Per Hop

3 Behaviour (PHB) in a limited set of choices: the QoS demand can t be defined in the absolute terms of basic parameters (data rate, delay and so on). A CP is served with a PHB; interestingly, a set of CPs has a scope that is local to a domain. A best-effort service is applied to datagrams when no service is used; in this case, no kind of signalling is then required. Two different services are now standardized: Controlled Load Service [12] Applications are allowed to specify some statistic parameters of the flow (data rate, peek rate, token bucket size). This service is used to obtain an unloaded path with an high throughput and low packet loss rate. Guaranteed Service [9] Applications can also specify the end-to-end delay: real-time applications are a natural target of this service. Three classes of PHB are now standardized: Class Selector Compliant PHB Groups [8] This group of PHB is a way to keep a backward compatibility with the Precedence bits, coded with the three leftmost bits of the ToS field in IPv4. To this purpose, 8 CP are then used to give high priority to network (e.g. routing) traffic. Inside this class, a Default PHB is applied to best-effort datagrams and the 0 code is used in the field. Expedited Forwarding PHB [7] The Expedited Forwarding ( EF ) PHB is used to obtain a service with low packet losses, low delay, low jitter. To do this, the EF queue in routers is low-sized and served with an high priority. Assured Forwarding PHB [6] The Assured Forwarding (AF) PHB group is a way to offer different levels of forwarding assurances for IP packets inside a domain. Four AF classes are defined and each class is so assigned a defined amount of resources; inside each class to a packet is assigned one of four different drop precedence. So, 16 CP are used for the AF PHB group. 4. ADMSION CONTROL AND POLICY CONTROL In QoS networks, the usage of network s resources is restricted to the available amount of resources and sometimes planned. An allocation request takes place only if there are enough free resources in the network, and if the requester is permitted to use them. Thus, the Admission Control module verifies that the network has a sufficient amount of resources to accept the user s request. The

4 Policy Control module verifies that the user has sufficient administrative permissions to request resources. Otherwise, if one of the two controls fails the request is rejected. The Admission Control and Policy Control is made at each hop of the End-to-End QoS path. This leads to the scaling problem in core routers because of the intense activity they carry on. The Admission Control and Policy Control is made in the network s border. A Border Router verifies the correctness of the incoming requests at the ingress of a domain; in these same points traffic is shaped (and maybe reshaped). Internal Routers (that perhaps concentrate lots of the traffic) don t verify the amount of used resources. In this way, some of the QoS complexity is bounded to border of a domain. 5. CLASSIFIERS A QoS network treats datagrams in different ways depending upon the kind of traffic they are used for, to this purpose a QoS architecture must provide a classifier in the forwarding path inside a router. A classifier selects datagrams and forward them in different service queues. The most straightforward way to serve data flows is to dedicate a scheduler s queue to each one. A classifier switches each datagram in the proper scheduler s queuelooking at the 5-ple (Source IP address, Destination IP address, Source Transport Port, Destination Transport Port, Transport Protocol ID): traffic is identified with a per-application granularity. A router looks for these fields in the IP and Transport headers of all datagrams to find IP packets belonging to allocated flows, and this leads to an high amount of work. Moreover, fragmentation must be avoided because transport-level information is used. All datagrams with the same CP have the same treatment. The field is 6- bits-long, so the total number of queues/behaviours is limited to a number of 64, and different data flows are served by the same queue. Datagrams are distinguished by the field. This field is contained in the IPv4 ToS field, or in the IPv6 Traffic Class field. A single field is checked to this purpose.

5 REFERENCES [1] Baker F., Iturralde C., Le Faucheur F., Davie B., Aggregation of RSVP for IPv4 and IPv6 Reservations, draft-ietf-issll-rsvp-aggr-02.txt, Work in progress, March [2] Berger L., Gan D., Swallow G., Pang P., Tommasi F., Molendini S., RSVP Refresh Overhead Reduction Extensions, draft-ietf-rsvp-refresh-reduct-04.txt, Work in progress, March 2000 [3] Blake S., Black D., Carlson M., Davies E., Wang Z., Weiss W., An Architecture for Differentiated Services, RFC2475, December [4] Braden R., Clark D., Shenker S., Integrated Services in the Internet Architecture: an Overview, RFC1633, June [5] Braden R., Zhang L., Berson S., Herzog S., Jamin S., Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification, RFC2205, September [6] Heinanen J., Baker F., Weiss W., Wroclawski J., Assured Forwarding PHB Group, RFC2597, June [7] Jacobson V., Nichols K., Poduri K., An Expedited Forwarding PHB, RFC2598, June [8] Nichols K., Blake S., Baker F., Black D., Definition of the Differentiated Services Field ( Field) in the IPv4 and IPv6 Headers, RFC2474, December [9] Shenker S., Partridge C., Guerin R., Specification of Guaranteed Quality of Service, RFC2212, Septemebr [10] Wang L., Terzis A., Zhang L., RSVP Refresh Overhead Reduction by State Compression, draft-ietf-rsvp-state-compression-03.txt, Work in progress, March [11] Wroclawski J., The Use of RSVP with IETF Integrated Services, RFC2210, September 1997 [12] Wroclawski J., Specification of the Controlled-Load Network Element Service, RFC2211, September 1997.