Integration of CIF with ATM

Transcription

1 Integration of CIF with D. Meziat, A. García, G. López Departamento de Automática Universidad of Alcalá Escuela Politécnica Alcalá de Henares, Spain Phone: Fax: {jmarco, meziat, antonio, Abstract: In this article, the implementation of CIF together with is presented using Linux with scheduling algorithms plus the algorithm TPVP. Tests have been designed, with which to monitor the behaviour of parameters related to traffic in real time. The programs needed to carry out these tests have been developed. The results obtained, are in line with those attained previously. Keywords : QoS,,, Communication Protocols. 1 Introduction Many multimedia applications rely on the ability of the network to provide quality of service (QoS) guarantees in order to operate correctly. These guarantees are obtained by establishing certain parameters, usually bandwidth, delay, delay variation and packet loss rate. The main objective of this work is to improve the interconnection between the quality of service and classical networks like. One way of achieving this interconnection is based on the CIF architecture [1]. The generic topology is illustrated in figure 1. In the CIF operation, the Final (CIF F.S.) sends cells within an frame as well as a specific header. The CIF switch extracts the cells from the frames and sends them to the network. One of the elements necessary for the red to provide QoS is an appropriate scheduling algorithm, which needs to be implemented in the switches. A study of the different scheduling algorithms was carried out, which reached the conclusion that one doesn t exist that fully adapts to the necessities outlined, so we have proposed a new algorithm called Deficit Round Robin Alternated (DRRA) [2], with more suitable characteristics. An important limitation to this scene, is that the delay and the delay variation are not conveniently marked out for the necessities of multimedia applications in segments. To solve the problem, a new algorithm denominated Token Passing with Period Variable (TPVP) has been proposed, which reduces the maximum delay and its variation in the segments, so that finally it is possible t o provide end-to-end QoS. The algorithm DRRA together with other scheduling algorithms and the TPVP algorithm have been implemented in several scenarios, using Linux inside the CIF architecture. This implementation has allowed us to contrast the performances of the proposed algorithms. Tests has been also carried out to monitor the behaviour in real time of related parameters. 2 Implementations executed The generic topology, for which it is foreseen the results of the investigation will be applied, is shown in figure 1, in which local area networks are interconnected by an wide area network. The scenarios that have been worked with are modifications of the previous one. Video LAN WAN LAN Figure 1. Generic Topology Video

2 The first implementation has been made in the scenario shown in figure 2, which is a simplification of the network in figure 1. The simplification consists of joining two PCs, which act as final systems, by means of a single CIF switch and with half-duplex segments. (A) 100 Mbps full-duplex (B) 155 Mbps Figure 4. Scenario 2. (A) Hub 10 Mbps half-duplex Figure 2. Scenario 1. Hub 10 Mbps half-duplex (B) The last scenario considered (Figure 5), is a modification of the previous one which has been used to study the impact of the use of the TPVP algorithm when there is a half-duplex segment. Also in this case, tests have been carried out that are presented in this article. In this interconnection the protocol stack developed was entirely CIF (figure 3). We also worked to implement the proposed scheduling algorithm DRRA. Other algorithms have also been deployed in order to contrast them with the proposed one. The results show that with the inclusion of the scheduling algorithms, quality of service was obtained at the cost of some very insignificant losses, demonstrating that the DRRA performs better than the other algorithms tried [9]. (A) Hub 10 Mbps half-duplex CIFSwitch Figure 5. Scenario 3. (B) 155 Mbps APLICATION CS: AAL5 AAL SAR -CIF ETHERNET Final CIF (A) ETHERNET -CIF Physical Layer -CIF Physical Layer ETHERNET APLICATION CS: AAL5 AAL SAR -CIF ETHERNET Final CIF (B) The implementation of scenarios 2 and 3 has been developed starting from a Linux operating system with the Red Hat 4.2 distribution, the kernel version and with the protocol stack on Linux. 3 Kernel functions Figure 3. CIF Protocol stack. An important problem in figure 2, is that the delay and the delay variation are not bounded in the half-duplex segments. For this reason, the TPVP algorithm was implemented, having proven that it reduces the maximum delay and its variation, and causing losses tolerated by most multimedia applications [4]. The following scenario considered is shown in figure 4, where an network is introduced and the communication architecture, on Linux is used [3]. This architecture has been modified introducing CIF. Several scheduling algorithms have also been implemented in order to contrast their operations. Validation tests were carried out which will be described later. In this section, we discuss the changes we have made to both the final system and the switch in order to incorporate CIF in the architecture on Linux. These changes are included in a new network driver, called CIF logical driver which replaces the network adapter driver. These modifications have affected the final system A. The switch, in the other final system B, connected through has not been changed. Replacing the driver with the CIF logical driver, at the original levels, allows to work as if we had an network adapter, when in reality we have an network adapter, being an interface common to all the messages that use protocol stacks. In the above mentioned driver, the CIF layer and the communication with the network card are implemented. The initial protocol stack [5] has been modified as illustrated in figure 6.

3 socket PVC Signaling UNI 3.x BSD socket interface socket SVC socket INET TCP, UDP, ICMP,... In the phase in which a connection is established, the user's program calls the socket() function. Control is immediately transferred to the appropriate protocol, in this case. Then the atm_create() function reserves memory for a new Virtual Circuit VC. It then registers the VC in the list of circuits opened up by the logical driver by calling alloc_atm_vcc(). AAL0 AAL5 CIF Layer Classical IP Driver IP Figure 6. -CIF Protocol stack. Access Although there will be important similarities, the CIF logical driver will be different dependent upon whether it is located in the switch or the final system. The only significant differences however will be due to the fact that, the messages are not always sent to the switch but must be forwarded on. 3.1 Establishing a connection To see how our CIF logical driver works we will follow the steps needed to establish an communication, from the time a connection is made until the data is shipped. We will start with establishing a connection (Figure 5). socket() atm_create() alloc_atm_vcc() setsockopt() atm_setsockopt() bind() atm_connect() atm_do_connect() atm_init_aal5() adjust_tp() logicdev_open() cif_create_vcc() Then from the user's application, by means of atm_setsockopt(), we inform the system which quality of service describer we want for the connection. Then we call the bind(), function which calls the atm_connect() function telling it to establish the QoS parameters for the virtual circuit within its corresponding describer. This in turn calls the atm_do_connect() function which obtains the network device and binds it with the VC describer and also checks whether the vpi and vci values are within the preset ranges. Following this, the protocol initialisation function, situated in the VC describer s aal field, is called (on Linux in there are two possibilities, AAL0 or AAL5) in our case AAL5, so the function executed is atm_init_aal5(). Following this, calling adjust_tp(), depending on the layer of adaptation to, the maximum size of the PDU function is set. Finally the enter function of our CIF logical driver logicdev_open() is called, which activates several flags of the VC to indicate that it has been accepted by our driver. By means of the cif_create_vcc() function, the final action is to register the circuit in the list of circuits of the driver,. After executing all the previous functions the VC will be open with the requested quality of service. 3.2 Sending messages In the following phase connection use is described.the different functions that are called to both send and receive data can be seen in figure 6. We will now describe the functions in more detail. Sending data begins when the sendto() function is called from the user's application. One of the parameters being the message to be sent. Then the layer of functions are executed. The first being atm_sendmsg() where data from the user s space is copied to the kernel space in a skbuff structure [6]. Prior to this, the memory space needed in the kernel is reserved by means of alloc_tx(). After this the logicdev_send() function of our CIF logical driver, passes the user s PDU to the cif_send() function which fragments the PDU into one or more CIF frames for its subsequent transmission. Each CIF frame will be transmitted inside an frame by dev_queue_xmit(). Inside this function the scheduling algorithms are implemented. Finally our frame is delivered to the driver and from there to the network card. Figure 5. Establishing connections in -CIF.

4 sendto() atm_sendmsg() alloc_tx() logicdev_send() cif_send() cif_do_send() recvfrom() atm_recvmsg() atm_push_raw() atm_peek_aal5() measure network performance already exist, [13][14] they could not be used as they were designed for TCP/IP protocols, which are not used in our implementation. The tests have been carried out in scenarios 2 and 3. and in both the network connects final system A to the switch. The network, consisting of a cable, links the CIF switch to final B system. Final system A has a 3Com /100 Mbps network adapter. The CIF switch has an adapter similar to final system A and a PCA-200e adapter of Fore to 155 Mbps like that of final system B. The PCs used in the tests have a 266 MHz CPU and 32 Mbytes of RAM. dev_queue_xmit() dev->hard_start_xmit() 3.3. Frame reception Phisical media cif_recv() netif_rx() Figure 6: Sending and receiving messages. When an frame arrives at the network card, it is attended to by the interruption controller of that driver. Then the driver calls the netif_rx() function which passes the frame to the corresponding network protocol for processing. In our case the function called cif_recv(). Each frame this function receives may contain either pieces of a PDU or a complete one. If the PDU arrives in pieces the function will wait until it has the complete PDE joined together before it sends it to the superior layers for delivery to the user's program. This is done by means of a call to the protocol s atm_push_raw() function. The user's complete PDUs are queued in such a way that when the user's program calls recvfrom(), this takes the first PDU received by the atm_recvmsg() function and delivers it to the program copying the data from the kernel space the to that of the user s. 4 Validation tests To check the impact of implementing the switching algorithms and the TPVP algorithm in our scenario, we have measured traffic parameters such as throughput, delay, and delay variation (or jitter) and bandwidth allocation, in real time. We should point out, that the programs needed to carry out these tests have been especially developed, as although several applications to The tests have been repeated at least 4 times, enough to see that the results obtained were all very similar. As typical deviations are very low the reliability gap can be considered very narrow giving a high level of reliability. The main factors affecting the parameters measured are the following: size of the message, number of sessions, traffic flow direction, number of processes, kind of traffic and duration of tests. From the former parameters only message size will vary, the rest are fixed for reasons described in the following section. Tests have been made with a different number of sessions and it has been observed that they do not influence the results. The direction of traffic flow and the kind of traffic depends on each test. It can be unidirectional or bidirectional. Normally the kind of traffic is made by emitting packages periodically. The period is calculated from the emission speed introduced by keyboard. Control of the speed is not implemented in a closed loop. The number of processes determines how much of the computer s memory is occupied but it does not influence the loss of speed, that the implemented algorithm can cause. This is because the system alternates between the user s process and the kernel while sending the message. Thus, in theory, it does not matter when it returns to the user s process whether this is the same process or not. Consequently, an emitter process is located in one final system and the other process in the receptor of t he other. The time of each message was the habitual of 20 seconds. The size the message can be 40, 128, 512 and 1480 bytes. When it is fixed it is The throughput test was carried out to find the maximum transfer speed without losses. Delay measureme nts have been made indirectly by measuring the RTT between two final CIF systems, connected through the CIF switch. The kind of traffic generated consisted in sending a packet from one session

5 and waiting for the response before sending a packet from the following session. The delay variations are due to the transmission network and the operating system which can take more or less time to attend to the emission or reception of a message. 4.1 Tests with scheduling algorithms Figure 4 is the scenario for these tests in which there is a 100 Mbps full-duplex network and a 155 Mbps network. The first test is to measure throughput, and the results are shown in table 1. The average losses are approximately 5%. 155 Mbps network which has not been modified, as shown in figure 5. The results of the maximum speed without lost measured when introducing the algorithm TPVP, are shown in table 3. It can appreciated that the maximum losses are less than 1 Mbps. Without PTPV 4,19 6,68 8,9 9,64 With PTPV 3,56 5,89 8,04 9,49 Diff. en % 0,63 0,79 0,86 0,15 Table 3: Throughput (in Mbps) with and without the TPVP algorithm. DRRA 9,15 24,36 68,44 96,5 DRR 9,12 24,45 67,73 96,49 FIFO 9,6 25,55 72,06 96,59 Diff. FIFO-DRR 0,48 1,1 4,33 0,1 Diff. FIFO-DRRA 0,45 1,19 3,62 0,09 The delay tests gave results that are shown in table 4. In this table it can be observed that the different are low. Without PTPV With PTPV Diff Table 1: Throughput (in Mbps) with the scheduling algorithms. The second test is to measure the Round Trip Time or RTT, the results are shown in table 2. The maximum difference is of 4 usec. and in general it is worthless. FIFO DRR DRRA Diff. DRR2 -FIFO Diff. DRRA-FIFO Table 2: Delay (usec. ) with the scheduling algorithms. 4.2 Tests with the TPVP algorithm Table 4: Delay (usec.) with and without the TPVP algorithm. The result of the jitter tests with and without the TPVP algorithm, can be seen in figures 7 and 8. The average value measured without TPVP is usec. this value decreases 20% (2.212 usec.) with the TPVP algorithm. In the case of the maximum values, usec. without the TPVP, decreases 108 times to ( usec.). Jitter (usec.) Sample Figure 7. Variation in delay without the TPVP algorithm. It has been necessary to modify the scenario of the previous tests as the TPVP algorithm should be used in a scenario in which there is a half-duplex segment, so the 100 Mbps full-duplex network has been replaced by 10 Mbps half-duplex network and a

6 Jitter (usec.) Sample Figure 8. Variation in delay with the TPVP algorithm. 4.5 Conclusions From the results observed in the different tests, in the different scenarios, it can be concluded that the maximum speed without losses decreases slightly, with maximum losses of 5%. The additional delay is minimal, in the order of the usec. which is tolerated by most multimedia applications [10]. As for the variation in delay, it can be reduced to 10% of the of the maximum jitter value with the TPVP algorithm and totally eliminate the delay variation component commo n to. The results of these tests are in consonance with other works carried out previously [1][4]. [7] R. Jones "Netperf: A Benchmark for Measuring Network Performance. Homepage". [8] B. Adamson. "The MGEN Toolset". [9] J. M. Arco, B. Alarcos, D. Meziat, "A suitable service discipline for - interconnection European Conference on Universal Multiservice Networks ECUM 2000, pg , October [10] J. Rusell, chapter "Multimedia Networking Performance Requirements", from the " Networks" book. Ed. I. Viniotis and R.O. Onvural, Plenum, pp , References [1] J. M. Arco, A. Martínez, B. Alarcos, A. García, D. Meziat. Carrying Cells Over ". IEEE Euromicro 99, September [2] J. M. Arco, Propuesta de optimización de la interconexión de redes con calidad de servicio para aplicaciones multimedia". Tesis Doctoral, Universidad de Alcalá, January [3] W. Almesberger, on Linux: The Distribution. [4] J. M. Arco, D. Meziat. Reducción de la congestión y de la variación del retardo en redes. Libro de ponencias de las III Jornadas de Ingeniería Telemática JITEL 01, pp , September [5] W. Almesberger on Linux, 3rd International Linux Kongress, mayo [6] A. Cox, Network Buffers and memory Management". Linux Journal, September 1996.