| KIDS stands for Karlsruhe Implementation architecture of Differentiated Services and was developed for the design, evaluation, and use of quality-of-service (QoS) mechanisms in networks [Wehr01b]. KIDS is an abstract model describing the structure and interaction of quality-of-service mechanisms, and it allows you to define individual QoS behavior in a flexible way. The KIDS framework was implemented on various platforms, including Linux (kernel Version 2.4) and the OMNeT++ simulation tool. Though Linux already supports some QoS features (see Chapter 18), KIDS introduces several important benefits, as we will see in the further course of this chapter. The next two sections will introduce the general structure of the KIDS framework; however, we will leave out a few details to keep things short see [Wehr01a] for details. 22.2.1 Elementary QoS Components KIDS was designed to create a flexible, extendable, and modular framework for implementing individual QoS mechanisms. It is based on the use of components that implement the elementary QoS mechanisms, and so it is easy to combine them to more complex QoS mechanisms. Simple combination of components and ensuring all potential degrees of freedom and easy extendability were the most important factors in the design of the KIDS framework. KIDS can be thought of as a construction kit, similarly to the popular Lego system, consisting of components that have different interfaces. Components with similar interfaces can be connected (almost arbitrarily) to form complex constructions (in this case QoS mechanisms). We can distinguish two different interfaces in the components of the KIDS framework (as seen in Figure 22-1): At a packet interface ( ), a component, X to pass a data packet it received at its input to the successor component, B. By convention, a KIDS component has but a single input. At a message interface ( ), component X to pass a message to component B, requesting the latter for a packet.
Figure 22-1. Interactions at the interfaces between two KIDS components. 
By using these two interface types, we can distinguish five component classes, as shown in Figure 22-2. Each QoS mechanism can be assigned to one of these classes: Operative components (BHVR) operate on packets: They receive a packet and operate their algorithm on this packet. The algorithm implemented in a component either changes the packet (active operative component) or studies its output to forward the packet (passive operative component). Examples: Token Bucket, Shaper, Marker, Dropper, Classifier, Random Early Detection (RED). Queue components (QUEUE) are data structures used by components to enqueue or dequeue packets. Examples: FIFO Queue, Earliest-Deadline-First-Queue. Enqueuing components (ENQ_BHVR) enqueue packets in queues based on special methods, which is the reason why they have no outputs. Examples: Head-Enqueue, Tail-Enqueue, EDF-Enqueue. Dequeuing components (DEQ_BHVR) dequeue packets from a queue based on a special method. They receive a dequeue request on their message input and subsequently try to dequeue a packet from the queue. If successful, the packet is transported from the packet output; otherwise, a negative message is returned. Examples: Head-Dequeue, Tail-Dequeue. Strategic components (DEQ_DISC) implement special strategies that can be combined in a flexible way to serve queues. This means that they decide on the route for dequeue requests to dequeue components, which eventually serve the queue. Examples: Priority Queuing, Weighted Fair Queuing, Round Robin.
Figure 22-2. Five different KIDS component classes. 
By observing relatively simple rules to link components (see [Wehr01a]), we can design complex configurations. Figure 22-3 shows an example for such a configuration; it implements a router that distinguishes three service classes. Figure 22-3. Example of a KIDS configuration. 
22.2.2 Hooks QoS mechanisms extend the behavior of a protocol instance to enable us to handle packets in a differentiated way and obtain different qualities of service. Though the five component classes of the KIDS framework supply a construction system for flexible linking of QoS components to combine QoS mechanisms, we still don't know how a newly designed QoS mechanism can be integrated into the process of a conventional protocol instance. One of the most important factors is to select a location for the extension of a protocol instance, because we achieve a different set of packets, depending on these locations. KIDS implements the concept of hooking points?span>hooks, for short representing a defined extension of existing protocol instances to bind components of the KIDS framework. Figure 22-3 shows five strategic positions in the IP protocol and three in the data link layer, where hooks were integrated to subsequently hook in KIDS components at those points. Section 22.3.4 describes how these hooks were implemented on the basis of different interfaces in the Linux network architecture. We define three types of hooks: Packet hooks are used at positions where a packet normally passes without differentiated handling (e.g., IP_FORWARD is passed by all packets to be forwarded). Enqueuing and Dequeuing hooks are used at positions where we would normally use a FIFO queue (e.g., the output queues of network devices on the data-link layer).
|
