A Review on Quality of Service Architectures for Internet Network Service Provider (INSP)

A Review on Quality of Service Architectures for Internet Network Service Provider (INSP) Herman and Azizah bte Abd. Rahman Faculty of Computer Science and Information System Universiti Teknologi Malaysia ABSTRACT This paper reviews some quality of service () architectures that can be implemented by Internet Network Service Providers (INSPs) to optimize the quality of network service as well as for maintaining efficiency and effectiveness of their network. Quality of service always involves with some components of the System. Discussion on architectures will describe and compare the characteristic of the components in each of architectures. Through this discussion what are advantages and disadvantages of the architecture will be identified in order to determine which architecture is more suit for certain application. KEYWORDS Internet Network Service Provider, Quality of Services () Architectures, IP Network Management 1. Introduction Internet Network Service Provider (INSP) offer Layer 3 packet forwarding services by operating an IP network. The network infrastructure provides the core packet transport service that an INSP bases its business upon. The infrastructure is built based on certain network architecture. The architecture describes the technology and properties related to the infrastructure. The architecture can be distinguished into four sub-architectures; Quality of Services () Architecture, Data Forwarding Architecture, Signaling Architecture, and Security Architecture. The Architecture describes the technical measures that provide quality of service. The nature of the architecture has strict consequences for the forwarding and signaling architecture. For example, Intserv as architecture make the use of a signaling protocol such as RSVP as part of the signaling architecture and works well with either a plain IP or a Multiprotocol Switching Label (MPLS) data forwarding architecture. The Data Forwarding Architecture describes the actual technical packet forwarding technology. INSP can use plain IP packet forwarding where every hop in the path of the packet through the network is an IP router that looks up IP header information in its routing table to decide on how to forward the packet. Alternative data forwarding is label switching packet using MPLS technology. The Signaling Architecture encompasses the different signaling and control protocols to manage the network. This includes interior and exterior routing protocols, signaling protocol and label distribution protocols. The Security Architecture used by an INSP is depends on many factors, for example, the IP-level security architecture, the quality of its implementation, router operating system security and the physical security of the network. This paper investigates some Architectures due to its function as general foundation upon which actual Systems are based. The range of technical forwarding services an INSP can offer to their customers depends on their System. The efficiency with which these services are provided also depends on the System. 1

2. Components of System Discussion on architectures involves with unique characteristics of every system s components that construct the system. In 2001, Schmitt proposed a definition of system and its components that are referred by this paper. In the definition, Schmitt combined technological aspects and strategic management on network providing business [1]. A system basically consists of Architecture that describes the technical part of the system and the Strategy that determines how an INSP exploits the technical features offered by the architecture. The strategy involves the configuration of the architecture, policy decision and tariffing. Furthermore, A architecture can be devided into declaration and procedure. The declaration forms the static part of the architecture and contains properties like service classes, parameters, and their specification units. procedures constitute the dynamic part of architecture and consist of the data path and control path mechanism. procedures on the data path are packet classification, packet scheduling, queue management, policing, shaping, and packet marking. procedures on control path are signaling, admission control and multicast. Figure 1 show inter-relation of System s components. 3. Integrated Service (Intsevr) Architecture The Integrated Service Network was introduced by Scott Shenker [2]. It described one network for all kinds of applications, especially real-time multimedia traffic like voice, video conferencing and TV like applications. In the early 1990s, Internet Engineering Task Force (IETF) realized that the Internet s egalitarian best-effort model is not suited for this kind of real-time multimedia traffic if the network is significantly loaded. To address this problem, IETF proposed Integrated Service (Intsevr) as a Architecture. The general Integrated Services (Intserv) Architecture is specified in RFC 1633 [3]. It builds upon a signaling protocol. The IETF proposed a dedicated signaling protocol - named Resource Reservation Protocol (RSVP). Furthermore, the IETF Intserv specification can be broken into two part, the signaling as RSVP part in RFC 2205 [4] and the integrated service specification in RFC 2212 [5]. procedures Data path architecture classification scheduling Quee Management Policing Shaping marking declarations System Control path Signaling Admission control Multicast Strategy Configuration Policy decisions Figure 1: System Components [1] Tariffing Guarantees are given for individual flows. For each flow, a path is reserved through the network. A flow is defined as a distinguishable stream of related datagram that result from a single user activity and require the same. Intserv model distinct real time traffic and elastic traffic of nonreal time services. The elastic traffic is treated as the traditional best-effort traffic and because default service is best-effort, application using it does not need any modifications. Furthermore, real-time traffic is categorized by whether it is tolerant to loss and whether it is adaptive to rate/ delay. Using RSVP, the application on the end system requests a specific end-to-end for one session from the network. A session in the context of RSVP/Intserv is defined by the IP address, protocol ID, and optionally a destination port. As the destination address 2

can be a multicast address, a session is a data flow from possibly multiple senders to multiple receivers. Intserv introduced Guarantee of Service (GS) concept, while GS offer a deterministic service with zeroloss guarantees and delay bound guarantees. If every router in the flow s path supports GS, the flow experiences a delay-bounded service with no queuing loss for all conforming packets. Figure 2 illustrate the control path of Intserv. Sender PATH & data RESV reserved rate needed for admission control at a link can be derived from the package state. In the SCORE architecture based on DPS, core routers have to trust the information carried in the packet headers. A single faulty router can disrupt the service in the entire core, therefore these solution are not enough robust. Then, an enhancement of SOCRE fair queuing algorithm is proposed by Stoica [7]. Core routers no longer blindly trust the incoming packet state. Instead, they statistically verity and contain flows whose packet are incorrectly labeled. 5. Different Service (Diffserv) Architecture Receiver A Merging of reservations Receiver B Figure 2: Intserv Control Path 4. Stateless Core Architectures (SCORE) Intserv very concerns with scalability especially in backbone networks. Then, many researches went into analyzing stateless core (SCORE) architecture. The idea is to have a network where only edge routers have to perform per-flow management while core routers do not. There are some proposals for SCORE architecture and the most famous one is Dynamic Stage (DPS). The basic idea of DPS as described by Stoica and Zhang in 1999 is that the edge router inserts information into the IP header [6]. This information is used and updated by the core routers to provide deterministic service guarantees like GS in Intserv. The core routers are using a special scheduling mechanism that only depends on the DPS and does not require per-flow state on the data path. In addition, the control path is made stateless in the core as the aggregate Different Service (Diffserv) Architecture is specified in RFC 2475 [8]. The Diffserv is response of IETF to concerns about the complexity of Intserv/RSVP. Diffserv takes a more abstract and local view on resource allocation. It is a SCORE approach, the core nodes of a network do not have to keep perflow state. Per-flow state is kept at edge node only where operations like policing and marking area also done exclusively. On the data path, packets of different flows are aggregated into behavior aggregates (BA) at the edge node. A BA is associated with a certain service class. It is identified by the six bit Diffserv CodePoint (DSCP). The DSCP is contained in the Diffserv field of the IPv4 IP header or the traffic class octet of the IPv6 IP header. The main feature of Diffserv architecture is the Per-hop Behaviour (PHB) that specifies the forwarding behavior of one router for packets of a DSCP that is locally mapped to that PHB. The edge-to-edge behavior in a network of one service class named Per Domain Behavior (PDB) - results from the concatenation of PHBs. It is assumed that useful services can be constructed from the different PHBs in the standardization process. A Diffserv domain is a network over which a consistent set of differentiated service policies are administered in a coordinated fashion. Typically, this equals the network of a single INSP. As a flow will typically pass several Diffserv domains for end-to-end, a coordination of those is required. 3

This coordination is done on the control path by the use of Service Level Agreement (SLA) and potentially Bandwidth Broker (BB). Figure 3 shows the main functionality of Diffserv edge and core routers. The ingress edge routers of a Diffserv domain perform several operations on packet arriving from outside the Diffserv domain. A multi-field classification is necessary to identify the flow, as flow aggregate to which the packet belongs, and to look up the associated traffic conditioning specification and the traffic profile. The multi-field classification is base on the value of one or more IP header fields such as source address, destination address, etc. For the most services, further processing by the traffic conditioning module is necessary. When a packet arrives at a Diffserv core router, the operations are of less complexity. Only a single-field classifier is necessary, it reads the DSCP from Diffserv field and determines the PHB that is locally mapped to that DSCP. The buffer management and scheduling algorithm treat the packet according to the PHB. Data path Sender Diffserv core router Routing SFC SFC Receiver B Receiver A Outgoing link. 6. Overprovisioned Best-Effort The currently dominating approach to improving is adding bandwidth and buffer to best-effort network. This approach is called the overprovisioned best-effort and is based on the fact that packet travelling through a relatively lightly loaded network experiences little to no loss and little queuing delay. For many applications, this can be enough and relatively good. The advantage of this solution is that the basic architecture does not have to be changed. A disadvantage is that in the absence of admission control and service differentiation, and INSP cannot give service guarantees. Also, an INSP cannot offer technically different services with that approach. Data path Diffserv edge router Routing MF C MF C MFC = Multi-field classifier SFC = Single-field classifier TC = Traffic conditioning = Pre-class scheduler Figure 3: Diffserv Edge and Core Routers 7. Alternative Best-Effort Outgoing link. Alternative Best-Effort (ABE) is an enhancement of IP best-effort. The Idea is to have two service classes that provide a delay against throughput trade-off [9]. Each IP packet is marked green or blue. The green packets receive a lower delay but via a possibly higher loss probability lower throughput than the blue packets. TC TC One important property of the ABE service is that green packets do not distract blue packets. If an application marks some or all of its packets green, the service received by 4

application that marks all their packets blue is not degraded. Therefore, if the ABE service model would be introduced in the Internet unmark packets would be considered to be blue packets and no harm would be done to applications unaware of the ABE service. Application aware of the ABE service would mark their packets blue of green or even mix both colors by marking some blue and other green. sequence is preserved within the blue and within the green queues only, therefore when mixing the colors, packet reordering can be induced. [7] Stoica, I. et al. (2002). Self Verifying CSFQ. Proceedings of the IEEE Conference on Computer Communication and Networking (INFOCOM 2002) Page:21-30. [8] Black, D. et al. (1998). An Architecture for Differentiated Services, RFC 2475. [9] Hurley, P. et al. (2000). Providing a Low-Delay Service within the Best Effort. IEEE Network Magazine 15 (3). Page 60-69. 8. Conclusion Network architecture consists of the architecture, the data forwarding architecture, the signaling and the security architecture. The most commonly used architecture is the plain best-effort architecture. The Diffserv is becoming more and more popular as architecture with the increase importance of -sensitive applications like for example, VoIP, Video on Demand, IPTv, etc. Intserv, the Architecture that is introduced previously still can be implemented, especially for systems that utilize RSVP protocol for multimedia data. References [1] Schmitt, J.B. (2001). Heterogeneous Network Quality of Services System. MA, USA: Kluwer Academic Publisher. [2] Shenker, S. (1995). Fundamental Desigh Issues for the Future Internet. IEEE Journal on Selected Areas in Communication 13 (7), 1176-1188 [3] Braden, R. Clark. and Shenker, S. (1994). Integrated Services in the Internet Architecture: an Overview, RFC 1633. [4] Braden, R. Clark. et al. (1997) Resource Reservation Protocol (RSVP) Version 1. Functional Specification, RFC 2205. [5] Shenker, S. et al. (1997). Specification of Guaranteed Quality of Service, RFC 2212. [6] Stoica, I. and Zhang, H. (1999). Providing Guaranteed Services Without Per-Flow Management. Proceeding of the ACM Special Interest Group on Data Communication Conference (SIGCOMM 99. Page: 81-94 5