A DiffServ – IntServ Integrated QoS Provision Approach in BRAHMS Satellite System

This document illustrates the Quality of Service (QoS) architecture that has been developed within the BRAHMS (BRoadband Access for High Speed Multimedia via Satellite) IST project. In the target satellite access system, which is named BMSS (Broadband Multimedia Satellite System), User Terminals are provided with a transport service, based on the Internet technique, through which both user-to-user and user-to-network configurations (see Figure 1) are allowed. Besides the traditional best effort transport service, QoS treatment is provided in a framework that combines both DiffServ [IETF RFC 2474], [IETF RFC 2475] and IntServ [IETF RFC 1633] QoS models into a unique platform. Figure 1: BRAHMS Scenario I. Two Bit Architecture In document simplified DiffServ approach, named Two Bit Architecture [IETF RFC 2638], is considered instead of the traditional DiffServ one. The Two Bit Architecture is suggested as a first stage for DiffServ implementation, as it only considers two different services with better QoS guarantees than Best Effort, thus simplifying traffic control operations. Furthermore, the Two Bit Architecture is easily extendible and will be completely compatible with approaches that would define more levels of differentiation within a particular service, as standard DiffServ approach. The Two Bit Architecture services are: An “Assured” service to assign "expected capacity" usage profiles that are statistically provisioned. The assurance that the user of such a service receives is that traffic is unlikely to be dropped as long as it stays within the expected capacity profile. An Assured service traffic flow may exceed its profile. In this case it receives a lower assurance level. A "Premium" service that is provisioned according to peak capacity profiles that are strictly not oversubscribed and that is given its own high-priority queue in routers. A Premium service traffic flow is shaped and hard-limited to its provisioned peak rate and shaped so that bursts exceeding it are never injected into the network. In order to discriminate the two services from the traditional best-effort one, two bits in the IP header are used, which are called A and P bits. II. Dynamic Service Selection When a user requests a connection with a remote Internet host, it sends its QoS request to the Satellite Terminal (BSAT) which it is connected to, through the RSVP signalling protocol. The BSAT is provided with a specific table, called Next Domain Sub-nets Table, containing Hub Station’s (BHS) layer 2 addresses, which are associated with the list of Two Bit sub-nets that are directly connected with each BHS. If the destination IP sub-net address is contained in the table, the BSAT assumes that the destination host is within a Two-Bit domain directly connected to the HS. Thus, the BSAT entity treats this incoming request as a Two-Bit request. It first checks if there are sufficient resources for the incoming flow and then “simulates” the RSVP protocol operations, sending a RESV message to the User that originated the request. Otherwise, the destination IP sub-net is not present in the table, it treats the incoming request as a standard IntServ request. III. Traffic Control The traffic control module inside the BSAT includes individual policer for each flow whose QoS parameters have been advertised by RSVP signalling, as described before. GS [IETF RFC 2212] and CL [IETF RFC 2211] policing will be described later. Packets belonging to different flows are classified in individual queues and scheduled for transmission through the satellite link according to an Earliest Deadline First (EDF) scheduling policy. Resource allocation in the BSATs assures that the total amount of resources currently assigned to the BSAT will be at least equals to the global resources necessary to respect all the individual QoS flows’ requests. The remaining amount of resources is left for BE traffic packet transmission. In the BHSs, a mechanism to allocate resources according the given Service Level Agreements (SLA) to Assured packet flows coming from the external Internet is employed.. In this framework, it is assumed that the BHS meters the aggregate average rate of the global Assured traffic. When the classifier receives a new Assured packets’ flow from one of the DiffServ boundary routers to which it is connected, it lets this new flow pass through the downstream meter. If the measured rate is below a threshold previously agreed in the SLA, the new incoming flow is accepted. Otherwise, packets belonging to the new flow are dropped by the Classifier. In the proposed architecture, Assured traffic flows are policed in an aggregate way whereas Assured packet flows coming from the Internet will be classified in a unique queue. Figure 2: BRAHMS Global Traffic Control A high-level scheme of the BHS traffic control module is depicted in Figure 2. With reference to the scheme, IntServ and DiffServ flows are treated in an integrated way to respect both IntServ Services delay constraints, high priority delivery for P Service packets, and low drop probability for Assured packets. After being classified and before being enqueued packets pass through a DLB (Dual Leaky A