Alexandre Denis
email: alexandre.denis@labri.fr

Meta-communications in Component-base Communication Frameworks for Grids

Applications are faced with several network-related problems on current grids: heterogeneous networks, firewalls, NAT, private IP addresses, non-routed networks, performance problems on WAN. Moreover, the requirements concerning communications are varied and the acceptable tradeoffs highly depends on the applications. A solution to reach the flexibility regarding communication on grids is the use of a component-based communication framework. The users then compose their own protocol stacks by assembling building blocks in the way they want. However, a truly flexible and dynamic component-based communication framework needs a meta-communication channel for its out-of-band communications required by dynamic component assembly in a consistent way on multiple nodes. The meta-communication channel is useful for some "brokered" communication methods, too, and in particular those designed to cross firewalls. The meta-communication channel has often been the "weakest link " of component-based communication frameworks: bottleneck for the performance, back-door from the security point of view, and limited connectivity.

In this article, we present an architecture for a meta-communication channel that suffers from none of the aforementioned limitations. It exhibits good properties regarding connectivity, security and performance. Thus, the gain in flexibility brought by software components may be fully exploited without trading anything against flexibility.

Introduction

The goal of grid computing is to aggregate the computing power of multiple clusters of PCs and parallel machines scattered throughout multiple sites. Undoubtly, network communications play a critical role to reach this purpose.

Communication management on grids is different from a lot of other applications involving networking. The main characteristic of networks in grids is heterogeneity. The networking technologies are various, ranging from highperformance networks between nodes of clusters (SAN) through wide area networks (WAN) with a latency of multiple tenths or hundreds of milliseconds and a random bandwidth. These multiple levels bring each their own issues, thus an application for grids is faced with all of them. We consider in particular the following problems on modern grids:

Connectivity -To protect their machines from intruder attacks, many site administrators have drastically restricted the connectivity to the Internet. Many sites are using firewall routers, non-routed private networks [START_REF] Rekhter | Address Allocation for Private Internets[END_REF], or hide their machines via Network Address Translation (NAT) [START_REF] Egevang | The IP Network Address Translator (NAT). Request for comments 1631[END_REF]. As a consequence, plain TCP/IP is not sufficient to get a full connectivity, from every node to every other on the grid. NAT and firewalls introduce nonsymmetry in the topology. Some nodes are hidden and not visible from the Internet. This is quite unusual for people used to parallel computing where it is traditional to have an all-to-all communication channel with no restriction.

Security -As WAN connections between sites cross the Internet, they are vulnerable to attackers. Thus, many application require authentication of communication peers and privacy based on encryption. The widespread solution to authentication and encryption is the use of the Transport Security Layer (TLS) [START_REF] Dierks | The TLS Protocol Version 1.0. Request for comments 2246[END_REF], a successor of the Secure Sockets Layer (SSL).

Performance -Since most applications on grids expect high performance, performance is a critical aspect of network communication. Different network have different performance properties. Even a given network may exhibit different performance results depending on the protocol used. For example, plain TCP can hardly exploit the bandwidth capacity of WAN connections. One solution to improve TCP performance in WANs is to use multiple TCP streams in parallel. The Globus implementation of GridFTP [START_REF] Allcock | GridFTP Protocol Specification[END_REF] is probably the best-known tool implementing this approach. Alternatively, WAN performance can be improved using data compression, as implemented, e.g., in the AdOC library [START_REF] Jeannot | Adaptive Online Data Compression[END_REF].

In this paper, we will use two different metrics for evaluating performance; we will consider separately the link utilization performance (characterized by the bandwidth and latency), and the connection establishment performance (characterized by the connection establishment delay).

The problems to overcome are very different and influence each other, e.g. usually improving security degrades performance, thus tradeoffs have to be made. However, the applications that may benefit from a deployment on grids are varied with very different requirements regarding security and performance from one application to another. There won't be any best tradeoff suitable for any application.

A communication framework for grids has to be able to utilize a very large spectrum of networking technologies, must be flexible enough to be adapted to the requirements of various applications, and must overcome the main problems of communication on grids, namely connectivity, security and performance. One solution to reach such a flexibility in a communication framework is the use of a component-based approach. The user is offered the ability to assemble itself the building blocks he/she wants to get a custom service. For a good flexibility and adaptability, we will see that it is welcome that the communication framework implements an overlay network for out-of-band communications, that we call a meta-communication channel. The meta-communication channel is often the weakest link of a component-based communication framework. It may introduce security holes, performance bottlenecks, or connectivity restrictions.

This paper presents on-going work on a component-based approach for the meta-communication channel itself, in order to solve all the aforementioned limitations at the same time.

The remaining of this paper is divided as follows: the second section analyzes component-based communication frameworks for grids and their needs and requirements for a meta-communication channel. Section 3 explains our proposal for managing such a meta-communication channel. Section 4 describes and evaluates our implementation of our proposal in the PadicoTM communication framework. Section 5 discusses related work, and section 6 draws conclusions and directions for further work.

Component-based Communication Frameworks

In this section, we study the principles and operation of component-based communication frameworks, and exhibit their need for a meta-communication channel.

Motivation and Principles

The most challenging part to manage communication on grids is the heterogeneity of the resources and the variety of applications -and thus their requirements for a communication sub-system. The networks are ranged from high-performance networks in cluster to wide-area networks between sites. Not only their properties are different, but their protocol, communication methods and programming interface are different. Moreover, the requirements for the communication sub-system depends on the application; the performance v.s. security tradeoff largely depends on the nature of the application and may not be hard-coded in a communication framework. Such a needed flexibility may hardly be reached by the usual two-layer portability model based on an abstraction layer and drivers for each supported resource. Considering the variety of cases to deal with, on grids it would be highly welcome to have communication methods be assembled by the users depending on the application and the kind of network and protocols involved. For example, a user may want to add compression or encryption on the fly to any communication method; another user may want no encryption at all to get the best achievable performance with non-critical data.

To reach such a flexibility, it has been proposed [START_REF] Bresnahan | The eXtensible Input Output library for the Globus Toolkit[END_REF][START_REF] Hutchinson | The x-kernel: An architecture for implementing network protocols[END_REF] to manage communications with a freely and dynamically assembled protocol stack made of several simple building blocks. Such a technique is nowadays commonly used in all fields of software development and is known under the name of software component.

In the remaining of this paper, we will call "component-based" a communication framework based on freely assembled building blocks.

Such a flexible assembled protocol stack based on "building blocks" has been implemented in particular in x-kernel [START_REF] Hutchinson | The x-kernel: An architecture for implementing network protocols[END_REF], Globus XIO [START_REF] Bresnahan | The eXtensible Input Output library for the Globus Toolkit[END_REF], NetIbis [START_REF] Olivier Aumage | Netibis: An efficient and dynamic communication system for heterogeneous grids[END_REF] and PadicoTM [START_REF] Denis | PadicoTM: An open integration framework for communication middleware and runtimes[END_REF].

Need for a Meta-communication Channel

In this section we introduce the concept of meta-communication and its motivations. Formally, we distinguish two classes of network communications: metacommunications and data communications.

• Data communications are communications carrying data from the upper levels -middleware or application-which are using the communication framework. These communications are controlled through the API of the communication framework.

• Meta-communications are communications used internally by the communication framework or one of its components. They are sometimes called service links, control channel or out-of-band communications in some other communication frameworks.

In the next paragraphs we explain why the meta-communications are welcome in a communication framework for grids.

Controlling the assembly. As a result of the component-baseness of a communication framework, various assembly schemes of building blocks may be selected to adapt to the requirement and networking resources. However, it introduces the problem of choosing the appropriate assembly and ensuring that all peers (i.e. client and server) are using the same assembly. For example, if a server uses zip compression over plain TCP and a client uses directly plain TCP, they are not likely to understand each other. At least two approaches are possible to solve this problem:

Static component stack -This is the approach used in Globus XIO [START_REF] Bresnahan | The eXtensible Input Output library for the Globus Toolkit[END_REF].

Client and server know in advance the protocol stack to use. Once the server is bound to a protocol stack, clients must use the same protocol stack. This approach is simple but suffers from a lack of flexibility; the servers must know in advance where the requests will come from. As a consequence, for a given server, all clients have to use the same protocol stack. However, the user may want to use a different protocol stack for example for connection coming from nodes on the same cluster reachable through a high-performance network and for connections that cross an insecure and slow WAN.

Dynamically assembled component stack -This is the approach used in PadicoTM [START_REF] Denis | PadicoTM: An open integration framework for communication middleware and runtimes[END_REF] and NetIbis [START_REF] Olivier Aumage | Netibis: An efficient and dynamic communication system for heterogeneous grids[END_REF]. Both parties agree on the fly on the protocol stack to use. Therefore a server is not required to know in advance where the requests will come from, and different clients to the same server may even use different protocol stacks. The dynamically assembled component stack strategy uses the following algorithm: when a client requests a new connection establishment, the communication framework first selects the assembly scheme to use according to configuration rules and depending on the nodes involved. Then the framework sends an assembly request to the framework of the server node; this request asks the server node to create an instance of the selected protocol stack (on the server side).

In the meantime, the client creates its own instance of the selected protocol stack. Finally, the client uses the usual connection mechanisms on his stack, and is sure that the server is already listening with the same protocol stack.

The main obstacle to dynamic assembly is that there must be a way of sending the assembly request to the framework on the server node even though the connection is not established yet. Thus we need a pre-existing framework-toframework communication channel to send meta-data. This is precisely the role of the meta-communication channel. Dynamic assembly using a control channel (meta-communication channel ) is depicted in Figure 1: on step 1, node B does not know the assembly that will be used (actually, it does not even know that a connection will be estbalished from node A); node A sends a connection request with the assembly description embedded in he request. On step 2, node B builds locally the requested assembly then sends an acknowledgement with connection information (the port number) to node A. On step 3, node A establishes the data connection through the selected component stack.

We should notice that we have restricted our study to the case of clientserver connection establishment. However, some other connection schemes are possible. For example, PadicoTM has the notion of circuit which is composed of a set of nodes (roughly similar to an MPI communicator). It is possible to apply the same algorithm to a larger set of nodes than two as in client-server, but we will only consider the case of client-server in the remaining of this paper to avoid useless overcomplexification.

Brokered communication. Some communication methods need to exchange information prior to establishing connections. Plain TCP is the best known example of this. To establish a TCP connection on an ephemeral port, the port Step 1 A sends assembly request through control channel

Step 2 B builds its communication stack

Step number has first to be transmitted from the server to the client before the client can connect to this port. There are various methods to solve this problem:

• listen on a well-known (fixed) port instead of an ephemeral port;

• use a third party that plays the role of directory (or "name service");

• send the port number through a meta-communication channel, preexisting before the data connection is attempted.

The first solution may not work in case the chosen port is busy, and does not supports multiple instances. The second solution supposes that all nodes are able to communicate with a third party; this means that actually the third party establishes an indirect route for meta-communications between nodes.

Other communication methods that plain TCP can benefit from a metacommunication channel. For example, in case a server is behind a firewall that drops incoming packets but not outgoing packets (common case), or behind a NAT [START_REF] Egevang | The IP Network Address Translator (NAT). Request for comments 1631[END_REF] gateway, we establish connections in the outgoing way; this is the socalled reverse connection method. Clients send a request to the server so that it connects to them. Another technique for crossing firewalls is TCP splicing (also called "simultaneous SYN " or "simultaneous initiation" in [START_REF] Postel | Transmission Control Protocol[END_REF]): both endpoints needs to exchange port numbers, and need to synchronize themselves to succeed in simultaneous connection. Both reverse connection and TCP splicing need to exchange meta-data. The availability of a meta-communication channel which allows component-to-component communications facilitates the use of plain TCP over dynamic ports and enables connection methods that wouldn't be available without it. Thus the meta-communication channel is a must, especially for communication methods designed to overcome the connectivity issues typically encountered in a grid environment.

To dynamically assemble component stack and to use brokered communication methods, we need a meta-communication channel which allows frameworkto-framework and component-to-component communications. We define the meta-communication channel as a communication channel that:

• allows communication from every node to every other node;

• exists before any data connection is attempted;

• exists implicitly, i.e. it is created without any explicit action from the user, as soon as the processes are started.

Requirements of a Meta-communication Channel

In this section, we define and analyze the requirements that a metacommunication channel must fulfill to be used in a communication framework for grids. Actually, the meta-communication channel is often designed with little care and is usually the "weakest link " of a communication framework. However, the whole communication framework cannot have a better connectivity, security, and performance than its meta-communication channel. Therefore, the meta-communication channel has the same requirements as the data communication channels, namely: connectivity, security, and performance.

Connectivity.

Nodes not reachable through the meta-communication channel are not able to use dynamically assembled component stacks since there is no way to send an assembly request. Moreover, without a meta-communication channel, no brokered communication method can be used. As a consequence, if a node is not reachable through plain TCP (because of firewalls, NAT, etc.) and is not reachable through a meta-communication channel, then it is not reachable for any data connection. Therefore, for a communication framework based on dynamically assembled component stacks -the most flexible model-, the set of nodes reachable for data connection is a subset of the nodes reachable through the meta-communication channel.

Security. Since the protocol stack is decided by clients, any intruder able to send meta-communication messages to a node may send forged assembly requests. Therefore, such an intruder may request unauthenticated and/or unencrypted connections to a server. A world-accessible meta-communication channel is undoubtly a back-door through which an intruder may change the security policy used for its own connection attempts. As a consequence, the security level of the whole communication framework cannot be higher than the security level of the meta-communication channel.

Performance. The meta-communication channel is used for assembly request and brokered communication methods when a data connection is attempted. It means that the meta-communication channel is on the critical path for data connection establishment. In other words, the data connection establishment performance is impacted by the meta-communication channel performance. Depending on the application, the data connection establishment delay may or may not be critical for overall performance. On the other side, the metacommunication channel connection establishment only affects the process initialization time.

An

Approach for a Flexible Metacommunication Channel

In this section, we describe our approach for a meta-communication channel suitable for a communication framework for grids.

As seen in the previous section, the meta-communication channel itself has roughly the same requirements as data communications: connectivity, security, and performance. We propose thus to use a similar solution to a similar problem; indeed, following the study of section 2.1, we propose the idea that the meta-communication channel might be implemented with dynamically assembled protocol stacks of software components. The remaining of this section explains such an approach where the meta-communication channel itself reaches a good flexibility and fulfills its requirements through a component-based architecture.

Overall architecture: two-step bootstrap

The main difficulty raised by the idea of a meta-communication channel following itself a component-based architecture is that it needs its own metacommunication channel -or rather: meta 2 -communication channel. However, the requirements for such a meta 2 -communication channel are not as high as for the meta-communication channel since it is used only at bootstrap time to build only the (primary) meta-communication channel. From now on, we will call this meta 2 -communication channel the bootstrap channel.

Undoubtly, the bootstrap channel has the same connectivity and security requirements as the meta-communication and data channels. However, the constraints on performance may be relaxed. The performance of the bootstrap channel only impacts the performance of the meta-communication connection establishment that takes place at process start-up. We choose to neglect this one-time initialization delay. As a consequence, the requirements and constraints for the bootstrap channel are:

• full connectivity (every node to every node);

• secure communications;

• uses no meta-communication channel (no meta 3 -communication channel);

• performance requirements are low.

With these hypothesis, we conclude that for the bootstrap channel, static component stack is mandatory since no meta-communication is possible for a dynamically assembled stack. This is no problem since a "one size fits all" approach is possible at the bootstrap channel level: we can guarantee security with an authenticated/encrypted communication method; we can bring the full connectivity through routing done by the communication framework on top of the encrypted transport. The performance of such a systematically routed and encrypted communication system is likely to be suboptimal, but it fulfills our requirements for a bootstrap channel.

Following this scheme, the sequence of initialization and data communication establishment is as follows:

1. start processes;

each process opens its bootstrap channel;

Each node has an initial basic connectivity to other nodes.

processes open meta-communication channel towards other nodes, using

the bootstrap channel for meta 2 -communications;

Each node has a meta-communication channel to other nodes.

4. upon data connection establishment attempt, an assembly request is sent to the other node through the meta-communication channel.

The internals of the bootstrap channel, the meta-communication channel, and various optimizations are detailed in the following sections.

Bootstrap channel

The goal of the bootstrap channel is to reach a basic initial full connectivity. This implies resource discovery, and basic messaging towards every known node. For scalability reason, we use a two-level hierarchical approach based on clusters of nodes.

Bootstrap channel architecture

The overall architecture of the bootstrap channel is depicted in Figure 2.

We define a node as a process involved in the considered application; there may be several nodes per hosts. We define a cluster as a set of nodes which are implicitly connected through an underlying native communication subsystem. A typical cluster is for example a set of nodes connected with a vendor-MPI on a parallel machine, or nodes connected through the Madeleine [START_REF] Olivier Aumage | A portable and efficient communication library for high-performance cluster computing[END_REF] communication library. Usually, the native intra-cluster communication subsystem is high-performance, non-TCP, and unsecure but isolated from the outside.

In each cluster, we distinguish a particular node that we call the leader. It should be able to connect to the internet with plain TCP, and be able to communicate with every node of the cluster with the native communication subsystem of the cluster. A typical example of cluster leader choice is the frontend of the cluster.

A particular node is dedicated to the directory management. We call this node the rendez-vous node. The rendez-vous node should be visible from the internet -or at least from all the cluster leaders, in case of a private grid. Typically, the rendez-vous node will be located on a gateway, outside of any firewall, and with a public IP address. The rendez-vous node manages a directory of nodes comprised in the current session. More precisely, it manages a table of node entries; each entry is composed of a node ID (actually an UUID [START_REF] Leach | A UUID URN Namespace[END_REF]), and the ID of the leader or a reference to the connection if the node is a leader. The rendez-vous node listens for incoming connections from the internet on a fixed port number, using a secure (e.g. SSL/TLS [START_REF] Dierks | The TLS Protocol Version 1.0. Request for comments 2246[END_REF]) communication method.

Discovery phase

The initial reference of the rendez-vous node is supplied to every node. When a process starts, it initializes its bootstrap connections. A standard node (nonleader) sends its ID to its leader. A leader node connects to the rendez-vous node with the secure communication method, using the supplied bootstrap initial reference; it sends its ID and the list of IDs of the nodes in its cluster. The rendez-vous node registers the IDs and the route to reach every known node. Then, it broadcasts the ID of new nodes to every already known leader, so as every node knows the list of currently running nodes. In case of a broken connection between a leader and the rendez-vous node, it unregisters the given leader and all the nodes of its cluster, and broadcasts the information to the other leaders.

The communication method used between the rendez-vous node and the leaders may be configured. For example, as an optimization one may want not to use authentication at all on a private grid. However, all leaders and the rendez-vous node must use the same configuration for a given session. The initial reference of the rendez-vous node is given similarly as a configuration parameter. It is not expected to change very often.

Messaging on bootstrap channel

Once the bootstrap channel is connected (i.e. the nodes are connected to their leader, and the leaders connected to the rendez-vous node), the messages on the bootstrap channel are routed, as depicted on example shown in figure 2. Since the topology of the bootstrap channel is a tree rooted in the rendez-vous node, the routing algorithm is straightforward. To send a message, a node sends it to its cluster leader. If the final recipient is in the same cluster, then the leader sends the message directly, else it forwards it to the rendez-vous node. Following its routing table, the rendez-vous node sends the message to the appropriate cluster leader, which finally forwards the message to its final recipient. The properties of such a bootstrap channel are:

• full connectivity, from every node to every other node;

• as secure as the chosen underlying transport layer;

• low performance, due to routing and the bottleneck in the rendez-vous node. However, every route is no longer than 4 hops;

• static protocol stack, does not require a meta-communication channel.

These properties fulfill the requirements for a bootstrap communication channel.

Meta-communication channel

The goal of the meta-communication channel is to provide the framework and the components with fast and secure connections from every node to every other node. The meta-communication channel is based on dynamically assembled protocol stacks. It has at its disposal the bootstrap channel.

The meta-communication may use the straightforward approach introduced in section 3.1: just after bootstrap, open all-to-all connections for the metacommunication channel. However, optimizations are highly welcome to overcome two main drawbacks: opening n 2 connections at the same time (n being the number of nodes) is likely to be a superfluous overload on the bootstrap channel -the rendez-vous node is a bottleneck-, and describing all the protocol stacks for every node to every other node is a tedious job.

Lazy connections. To solve the problem of the bootstrap channel flood, reduce startup time, and save on resources wasted by unneeded connections, the meta-communication channel uses lazy connection establishment. All nodes of the session are known as a result of the resource discovery phase, but it is not necessary to immediately open meta-communication connections to every known node. Therefore, it is lighter to open meta-communications connections ondemand, on the first message sent to a given node on the meta-communication channel.

Default configuration schemes. The assembly patterns used for protocol stacks are configured by the user as a set of rules defining which assembly pattern to use to reach which node. This is very powerful and may be used to describe the protocol stacks for any topology supported by the communication framework. However, the targeted topology are not random, thus one can want to optimize the configuration process for commonly encountered network topologies. It also saves the user's time by reducing the configuration complexity.

Basically, a configuration can be described as a default configuration strategy, and a list of exceptions. The default configuration is a sensible default scheme, for example: open direct TCP connections from every node to every other node (typically for small single-site, firewall-less, multi-cluster configurations); use native intra-cluster communication method for intra-cluster, establish direct connections between leaders, and route messages (max.: 3 hops). It can save a long distance round-trip if the rendez-vous node is far from both leaders; use bootstrap channel as meta-communication channel -a last resort option, but works everywhere. These default configurations are a basis upon which more advanced configurations are built in adding rules describing only exceptions.

Implementation and Evaluation

In this section, we describe our implementation of our meta-communication channel model in the PadicoTM [START_REF] Denis | PadicoTM: An open integration framework for communication middleware and runtimes[END_REF] communication framework for grids.

The PadicoTM communication framework

PadicoTM [START_REF] Denis | PadicoTM: An open integration framework for communication middleware and runtimes[END_REF] is a component-based communication framework for grids. Padi-coTM is designed to be as flexible as possible. It supports a wide range of networks, from high-performance networks to wide area networks. Moreover, several middleware systems -MPI, various CORBA implementations, Java RMI, SOAP implementations, HLA, ICE, DSM systems, JXTA-have been ported on top of PadicoTM thanks to its flexible personality layer that enables a seamless integration of existing code.

PadicoTM is based on a three-layer approach [START_REF] Denis | Network communications in grid computing: At a crossroads between parallel and distributed worlds[END_REF]: the lowest layer does multiplexing and arbitration between concurrent accesses to a given network, and between accesses to different networks (e.g. TCP/Ethernet and Myrinet) on the same machine; the middle layer is the abstraction layer, based on dynamically assembled components; the higher layer, or personality layer, adapts the API to the expectations of applications. The meta-communication channel is needed only for the abstraction layer, where the dynamic component assembly takes place.

Communication methods implemented

Various communication methods have been implemented in PadicoTM. Each communication method is provided in its own component and may be freely used in any assembly for supplying communication to any middleware system (MPI, CORBA, etc.). The supported communication methods are:

Plain TCP -This is the usual vanilla TCP connection, with access to some configuration parameters such as window size.

Madeleine -We use the Madeleine [START_REF] Olivier Aumage | A portable and efficient communication library for high-performance cluster computing[END_REF] communication library for access to high-performance networks in clusters. Supported networks are: Myrinet (through MX, GM or BIP), SCI, Quadrics QsNet, VIA.

Shmem -A shared memory communication component offers low-latency high-bandwidth inter-process communication on SMP hosts.

TCP derivatives for WAN -A large set of communication methods derived from TCP are implemented to overcome connectivity and performance problems specific to WAN. These methods are: TCP splicing (aka simultaneous connect) for crossing firewalls with no performance drop; one-way connection to always establish connections in the same direction, to cross firewalls when only one side is firewalled; SOCKS [START_REF] Leech | SOCKS Protocol Version 5. Request for comments 1928[END_REF] proxy; connection through SSH tunnels; parallel streams to improve TCP performance, as implemented in GridFTP [START_REF] Allcock | GridFTP Protocol Specification[END_REF].

Data filters -Some data filters are proposed. These filters may be composed atop any other communication method. The implemented filters in Padi-coTM are: compression -LZO, BZIP2, and AdOC [START_REF] Jeannot | Adaptive Online Data Compression[END_REF] (adaptive ZIP)-, and Gnu TLS for authentication/encryption.

Last resort -A last resort communication method is proposed. It performs tunneling through the meta-communication channel. The performance is likely to be low, but this solution works in any case where a metacommunication channel is established.

for the bootstrap channel. This is made possible by the fact that our bootstrap channel uses a configurable component assembly (even though it is static for the bootstrap channel). We should notice that getting even basic connectivity on such a topology is not possible for most communication frameworks, even component-based ones such as NetIbis [START_REF] Olivier Aumage | Netibis: An efficient and dynamic communication system for heterogeneous grids[END_REF].

Security analysis. Both the bootstrap and the meta-communication channels are built as component stacks for which the default is either TLS or a private intra-cluster network. Our approach introduces no world-accessible unsecured TCP server, unless explicitly asked by a user willing to trade security against performance in a controlled environment.

Performance analysis.

We have measured the quantitative impact of our approach for a component-based meta-communication channel. The performance of the meta-communication channel impacts the data connection establishment. Table 1 shows typical connection establishment performance.

The first column shows transmission latency, which is the latency of a meta-communication channel using the given network. The second column shows connection establishment delay with a three-way handshake (native for TCP/Ethernet and TCP/WAN, at application level for Myrinet) and a static protocol stack (no meta-communication channel). The third column shows connection establishment delay with dynamic protocol stacks and metacommunication routed through a relay located in a site 100 ms apart from the hosts (not uncommon on large-scale grids). Finally, the fourth column shows connection establishment delay with dynamic protocol stacks and componentbased meta-communication channel (our proposed architecture).

The connection establishment delay on a dynamic component-based software with a basic meta-communication channel is bounded by the performance of the meta-communication channel. If the performance of the meta-communication channel is poor, e.g. caused by relaying through a WAN, then connection establishment is slow even if the remote machine is theoretically reachable through Myrinet. In contrast, our proposed architecture (rightmost column) gets performance results close to direct connection (delay ∼ +60%). This is made possible by the use of an appropriate communication method by the metacommunication channel itself. We can see that our approach greatly reduces the connection establishment delay and makes the overhead of using a dynamically assembled protocol stack acceptable.

Regarding scalability, it should be noted that the rendez-vous node may look like a bottleneck. However, only cluster leaders are connected to the rendezvous node and very little communication goes through the rendez-vous node (actually, only bootstrap communications).

In conclusion, our proposed architecture for a meta-communication channel enables connectivity in cases where most communication frameworks cannot even get basic connectivity, and gets better performance than other meta-communication-channel based approaches where it can compare, without compromising security.

Related Work

Many researchers are working on communication management for grids. Most of the works rely on the difference between intra-cluster high-performance communication and inter-cluster TCP communication, but only a few actually uses a component-based architecture for a flexibility pushed further than the binary intra-/inter-cluster approach.

Globus XIO [START_REF] Bresnahan | The eXtensible Input Output library for the Globus Toolkit[END_REF] is becoming a de facto standard for communication on grids. Its main concept is the driver stack which is an assembly of building blocks very similar to software components. However, its static driver stack approach, with no meta-communication channel, defeats most of the purpose of software components in communication frameworks. In particular, a server must know in advance the driver stack that clients will use, which limits the flexibility of the communication framework.

A widely used grid programming model is MPI. The most popular implementation for grids is MPICH-G2 [START_REF] Karonis | MPICH-G2: A grid-enabled implementation of the message passing interface[END_REF], an MPI implementation over Globus. However, WAN communications methods in MPICH-G2 are rudimentary; it does not cross firewalls nor NAT. The only communication methods that MPICH-G2 is able to utilize are vendor-MPI for intra-cluster communication and plain TCP for inter-cluster communication. PACX-MPI [START_REF] Gabriel | Implementing MPI with Optimized Algorithms for Metacomputing[END_REF] is an implementation of MPI that has been designed from scratch for grids. For each site, PACX-MPI uses a dedicated gateway node for relaying messages across the WAN. This static configuration solves some of the connectivity problems. However, it does not solve all problems caused by firewalls and introduce a performance penalty because of relaying. GridMPI [START_REF] Gridmpi | [END_REF] is another implementation of MPI designed from scratch for grids. It solves some connectivity problems but supports only vendor-MPI communications, plain TCP, and routing on top of these. Open-MPI [START_REF] Squyres | The component architecture of open MPI: Enabling third-party collective algorithms[END_REF] is becoming a major MPI implementation and is built with software components. However, software components are used as an engineering tool to ease development by independant people and not as a tool to reach flexibility and dynamicity. Components in OpenMPI are statically assembled by the end-user. None of these MPI implementations is as flexible as PadicoTM with dynamic protocol stack and brokered communication methods (splicing, reverse connections, etc.).

NetIbis [START_REF] Olivier Aumage | Netibis: An efficient and dynamic communication system for heterogeneous grids[END_REF] is another component-based communication framework for grids. It features dynamically assembled protocol stacks and brokered communication methods. Actually, this advances in NetIbis are our own work [START_REF] Denis | Wide-area communication for grids: An integrated solution to connectivity, performance and security problems[END_REF]. Our present work transposes these concepts in PadicoTM and goes further with a two-step bootstrap for better performance of the meta-communication channel and a hierarchical bootstrap channel.

Finally, Project JXTA [START_REF] Gong | Project JXTA: A technology overview[END_REF] is an alternative to solving connectivity problems in WAN with application-level relaying building an overlay network. This is very similar to our bootstrap channel. However, JXTA is targeted towards peer-topeer and very volatile nodes rather than grid computing. It will presumably not be suitable for high-performance communication [START_REF] Halepovic | JXTA performance study[END_REF].

Conclusion and Future Work

Applications are faced with connectivity and security problems in current grids. Moreover, the requirements concerning communications and the acceptable tradeoffs highly depends on the applications. A solution to reach the flexibility regarding communication on grids is the use of a component-based communication framework. The users are then completely free to configure and assemble the building block in the way they want. However, we have seen that a truly flexible and dynamic component-based communication framework needs a meta-communication channel for its out-of-band communications required by consistency and dynamic adaptability. The meta-communication channel is useful for some "brokered" communication methods, in particular those designed to cross firewalls. The meta-communication channel has often been the "weakest link" of component-based communication frameworks: bottleneck for the performance, back-door from the security point of view, and limiting connectivity to nodes reachable by plain TCP.

We proposed in this article an architecture for a meta-communication channel that suffers from none of the aforementioned limitations. It exhibits good properties regarding connectivity, security and performance. Thus, the gain in flexibility brought by software components may be fully exploited without trading anything against flexibility. The proposed architecture has been successfully implemented in the PadicoTM communication framework which is available [START_REF]The PadicoTM web site[END_REF] as open source software.

The following steps in our work are in multiple directions. The first direction is quite short term and consists in adding support for more communication methods, and in particular for the ubiquitous Globus Security Infrastructure (GSI) [START_REF] Foster | A security architecture for computational grids[END_REF]. The second direction consists in investigating precisely the scalability of our approach for thousands of nodes, and our envisaged solution with a federation of rendez-vous nodes. Finally, fault-tolerance which was not taken very much into account in our present study, will be investigated for very large scale experiments.

Figure 1 :

 1 Figure 1: Dynamically assembled communication stack from node A through node B, using ZIP compression over TLS over TCP/IP; node B does not know in advance the component assembly.

Figure 2 :

 2 Figure 2: The bootstrap channel uses a relayed protocol through a rendez-vous node. The route from node A2 to B2 goes through A1, rendez-vous node (R), and B1.

Acknowledgements

This work has been funded by the project "LEGO" [3] (contract number ANR-CICG05-11) from the French National Agency for Research (ANR).

Experimentations were performed on the Grid'5000 [1] platform funded by the ACI GRID from the French Ministry of Research.

Meta-communication channels in PadicoTM

In PadicoTM, the concept of cluster is guided by Madeleine. The rendez-vous node is a dedicated process that can be started on any accessible host. Three schemes are available for the bootstrap channel:

• rendez-vous node on an internet-visible host, connections from leaders to rendez-vous node through TLS over TCP. This closely follows the model described in section 3.2.

• rendez-vous node on the machine of the user who launches processes, connections from leaders to rendez-vous node through SSH tunnels. The advantage is that it does not require an Internet-visible host and works even if some leaders have no access to the public Internet.

• rendez-vous node on some random machine, connections through plain TCP. This avoids unnecessary TLS certificates mangling when deploying on a private network.

Bootstrap connections from cluster nodes to cluster leaders are done through Madeleine. The implementation of the meta-communication channel is quite straightforward following the model described in section 3.3.

Evaluation

We have evaluated our component-based approach of meta-communication channel on various grid configurations.

Connectivity analysis.

We deployed PadicoTM on multiple sites of Grid'5000 [START_REF]The grid'5000 project[END_REF] and some sites outside Grid'5000. Grid'5000 as a whole is a private network without routing towards the outside Internet (private IP address without NAT) except one gateway per site allowed to connect to the outside. Most sites outside Grid'5000 are themselves protected by stateful firewalls.

In all cases, we were able to establish a bootstrap channel from every node to every other node and thus reach a full connectivity for the meta-communication channel and data links. When there are nodes inside a private network without NAT and nodes outside, there is no choice but to use proxies or SSH tunnels


Louis Cony

Olivier Ramalho

Abadie

Towards the definition of an indoor air quality index for residential buildings based on long-and short-term exposure limit values

Keywords: IAQ, Indicator, Indices, Guideline value, Health assessment, Good IAQ, Bad IAQ 1

In the Framework of the IEA EBC Annex68 Subtask 1 working subject, we aimed at defining an indoor air quality index for residential buildings based on long-and short-term exposure limit values. This paper compares 8 indoor air quality indices (IEI, LHVP, CLIM2000, BILGA, GAPI, IEI Taiwan, QUAD-BBC and DALY) by using the French IAQ Observatory database that includes pollutant concentration measurements performed in 567 dwellings between 2003 and 2005. This comparison allows to make a relevant analysis of each index and determines their pros and cons i.e. the calculation method, selected pollutants, threshold concentrations, subindices and their aggregation. From this analysis, a new index is proposed in order to be as consistent as possible in regards of health impacts by taking both long-and short-term exposure limit values into account.

INTRODUCTION

Due to the huge number of various sources of emissions, pollutants, health impacts and toxicity levels, assessment of Indoor air Quality (IAQ) is a complex task [START_REF] Hulin | Indoor air pollution and childhood asthma: variations between urban and rural areas[END_REF], Wolkoff, 2013;[START_REF] Haverinen-Shaughnessyu | An assessment of indoor environmental quality in schools and its association with health and performance[END_REF]. One of the required tools to achieve that goal is a single Indoor Air Quality Index that would describe air quality in regards of health impacts. During the last decades, such indices were defined, yet, none was accepted as sufficiently relevant by the international scientist community. In this paper, we analyze 8 of them to evaluate their main pros and cons, expanding a first comparison study performed by [START_REF] Wei | Applicability and relevance of six indoor air quality indexes[END_REF]. Selected Indoor Air Quality Indices are IAPI [START_REF] Sofuoglu | The link between symptoms of office building occupants and in-office air pollution: the Indoor Air Pollution Index[END_REF], LHVP [START_REF] Castanet | Contribution à l'étude de la ventilation et de la qualité de l'air intérieur des locaux[END_REF], CLIM 2000 [START_REF] Castanet | Contribution à l'étude de la ventilation et de la qualité de l'air intérieur des locaux[END_REF], BILGA [START_REF] Castanet | Contribution à l'étude de la ventilation et de la qualité de l'air intérieur des locaux[END_REF], GAPI [START_REF] Cariou | Utilisation d'un indice global de la qualité de l'air intérieur pour suivre l'ensemble des COV présents et leur impact sur la santé humaine[END_REF], IEI Taiwan [START_REF] Chiang | A study on the comprehensive indicator of indoor environment assessment for occupants' health in Taiwan[END_REF], QUAD-BBC (Quad-BBC, 2012) and DALY (Logue et al., 2011). In a first part, the methodology used to compare the different indices is presented along with the description of the 8 IAQ indices, the pollutants of concern and their associated Exposure Limit Values (ELVs). Comparison and discussion are given in a second partwhich results in the definition of a new IAQ index.

METHOD

IAQ Indices

A total of 8 indices are studied in this paper: IEI, LHVP, CLIM 2000, BILGA, GAPI, IEI Taiwan, Quad-BBC, and DALY. Table 1 gathers all calculation equations of the different indices along with the reference studies that defined them. (1

)
where I is the number of level-3 groups, J, the number of level-2 groups in each level-3 group, K, the number of level-1 pollutant variables in each level-2 group and max and min are the measured maximum and minimum concentrations of the BASE study (Girman et al., 1995), respectively. Most indices from literature are based upon the same principle:an average indoor concentration is divided by an ELV, quite similar to hazard quotients used for health risk assessment. ELV are usually health-based but may be different to toxicological reference values and vary according to the index. Many indices use sub-indices dedicated to one pollutant that are aggregated to obtain a unique index. Nevertheless, the presence of subindices and its aggregation are important questions that induce debates. From Table 1, 4 main types of aggregation emerged:

-Sum-average:Most indices are based on a sum of pollutants' concentrations compared to a reference value. Sometimes the sum is divided by the number of studied pollutants. The aim is to quantify average level of quality in a room by considering each pollutant as equally important.

-Maximum: The BILGA index is calculated by taking the maximum value of all its sub-indices. The pollutant with highest toxicity exposure is the only one taken in account to assess IAQ. -Specific formula: Some indices are not based on a concentration divided by an ELV but on a specific formula that returns a value per pollutant, which can be summed up to all pollutants to obtain a global health risk assessment level. -Score using breakpoint concentration: the IEI Taiwan is based on the attribution of a score for each pollutant using 4 ranges of concentrations between breakpoints. Scores are summed in the category except if one score of the category is below 60, in which case the minimum score of the category is chosen. Scores of respective categories are then summed and weighted by a category coefficient.

Table 2 summarizes the main pros and cons of the published indices.

Target pollutants

The pollutants used in the calculation of each index are listed in Table 3. ). According to the definition, there is no known health impact for the selected period below the threshold concentration.

Note that, among the 4 main ELV used, TRV are not accurate and may differ from one study to another; LRV and IRV are too old and too lax. IAGV seems to be the most relevant one, because it is current, accurate, and based on known health impacts.

Comparison procedure

In order to proceed with the comparison of IAQ indices, a common set of inputs is necessary. Most studied IAQ indices require both pollutants concentration levels and Exposure Limit Values (ELVs).Regarding the first kind of inputs, the French dwellings survey conducted from 2003 to 2005 by OQAI (French Indoor Air Quality Observatory) on 567 housings [START_REF] Kirchner | Etat de la qualité de l'air dans les logements français[END_REF]was chosen as a reference for IAQ assessment in residential buildings.

In this survey, only long-term effects were taken in account. NO 2 , SO 2 , O 3 , mold and bacteria were not measured. Whenever a pollutantconcentration is not available but is needed in the calculation, the index formula was readapted so that it does not bias the results. As much as possible, all indices were calculated the same way as it was firstly described in the literature. Most indices need ELVs for considered pollutants. If the ELV was not clearly defined, the French Indoor Air Guideline Value (IAGV) was chosen (ANSES, 2011). If not available, international reference values were used instead e.g. WHO(WHO 2010), OEHHA (2016)...

The following procedure is applied to compare the indices.A first graph presents the distribution of the studied index according to its original scaleconsidering the 567 dwellings(Figure 1, left). A second one is produced to transform the results using a common 3 level-scale with the following interpretation: good, intermediate or bad IAQ (Figure 1, right).All indices have an interpretation to determine if IAQ is good or bad in a dwellingin their original definition except for DALY and GAPI. The first approach quantifies DALY lost per year per 100,000 persons due to exposure to indoor air pollutants but there is no indication on how many DALYs should be lost per year to consider IAQ as good or bad. The GAPI index returns a value that relies on the weight of the selected criteria without any scientific signification.

A last graph (Figure 2) intends to detect eclipsing as defined by [START_REF] Sharma | National Air Quality Index[END_REF] and inconsistencies. Most of IAQ indices employ aggregation (maximum, sum, weighted averages, root-mean-square formulation…) of sub-indices at some point so that information for a particular pollutant can be hidden by the weight of the other pollutants. In this analysis, the studied indices are plotted against the maximum value of the concentration of each pollutant to its ELV ratio (MAX) in order to identify whether the indices are not hiding critical cases or not. In Figure 2, some points are encircled in red, they are associated with dwellings that have a bad IAQ according to IAPI value whereas it has an excellent IAQ according to MAXindex (<0.5). On the contrary, points encircled in blue correspond to dwellings with an intermediate IAQ whereas MAX(>1) characterizesa very bad IAQ (one pollutant at least is above short-term IAGV). In this example the dispersion is so high that IAPI is not able to distinguish the level of IAQ as shown by the green region of equal MAXand IAPI ranging from 4 to 10 and the orange region where IAPI predicts the same level of IAQ with a MAXranging from 0.2 to 3.5. Short term IAGV was used as ELV to detect bad IAQ with certainty.

RESULTS AND DISCUSSION

IAQ indices comparison

All results obtained by calculating the 8 IAQ indices are compiled in Figure 3 to 5. Since PM 2.5 weights about 90% of DALYs lost and was not measured in every dwelling, we decided to considereronly the dwellingswhere PM 2.5 was measured (noted as "DALY (with PM 2.5 )" hereafter). Figure 3 shows that some indices do not distinguish well the differences among the buildings (LHVP, GAPI, IEI Taiwan) whereas the others do. Figure 4 strengthens this observation. In particular, only two indices clearly classify the building population according to the interpretation scale: IAPI and DALY. However, they interpret the IAQ in opposite way with 70% and 20% of bad IAQ for IAPI and DALY, respectively. Figure 5highlights the lack of correlation between the indices and the MAX except for DALY and, to a lower extent, BILGA and IAPI.

Proposal of a new index

Since there is no current consensus about the definition of good or bad IAQ, we propose a few statements that IAQ should reflect in our opinion:

-IAQ is good if there is no known health impact in a long-term perspective. Long-term (usually 1 year period) IAGV can be seen as the minimum threshold to be considered. -IAQ is bad when the long-term (annual) average concentration is above short-term exposure maximum threshold. Short-term IAGV represents themaximal threshold for a long-term(annual) average concentration. -Since the comparison is made with a critical threshold, if only one pollutant reaches this threshold, it is sufficient to affirm that IAQ is bad with certainty, no matter how low the concentration of the other pollutants are. The most unfavourable situation is relevant to define an IAQ index. -There is no point in letting IAQ index values range from ]-∞;+∞[.If the long-term (annual) average concentration of one pollutant is above critical threshold, no matter how high the concentration, IAQ remains bad; a maximum value for the index can be then defined. In the same way, concentration below the minimum ELV threshold refers to good IAQ so that an index minimum value can be proposed. Based on the previous points, the proposed formula for a new index, called ULR-IAQ, is the following:

𝐼 𝑈𝐿𝑅-𝐼𝐴𝑄 = 𝑚𝑎𝑥 10 𝐶 𝑖𝑛𝑑 ,𝑖 -𝐼𝐴𝐺𝑉 𝐿𝑇 ,𝑖 𝐼𝐴𝐺𝑉 𝑆𝑇 ,𝑖 -𝐼𝐴𝐺𝑉 𝐿𝑇 ,𝑖

IAGV LT,i is the indoor air guideline value for long-term exposure (usually 1 year) to apollutant, IAGV ST,i is the indoor air guideline value for short-term exposure (shortest available) and C ind,i is the indoor concentration of pollutant i. If C ind,I > IAGV ST,I then C ind,I =IAGV ST,I and if C ind,I <IAGV LT,I then C ind =IAGV LT,i .

This index varies from 0 to 10. A value of 0 means that IAQ is good; there is no known health impact due to the target indoor air pollutants. Index equals to 10 meansa very bad IAQ; it is dangerous for human health even on short-term exposure and something must be done to improve IAQ. Between those two boundaries, a linear trend is used for sake of simplicity as we cannot currently define intermediate situations between good and bad IAQ.

The pollutants accounted for this new index have been selected according to the existence of a long-and short-term exposure IAGV and concentration level availability in the OQAI campaign (OQAI, 2007).

Evaluation of the proposed index

As for the previous indices, ULR-IAQ was calculated over the whole French dwellings measurement campaign of 567 housings. Results are presented inFigure 6. The new index shows another picture of the IAQ in French buildings: about 28% bad, 10% good and the remaining 62% with intermediate IAQ. This picture is close to the finding of [START_REF] Wei | Applicability and relevance of six indoor air quality indexes[END_REF], using a more complex combination of index classification: 34% bad, 6% good and 60% intermediate IAQ. The third graph confirms the capability of detecting bad IAQ; this result is obvious as it is part of the definition of ULR-IAQ. One key element to evaluate the IAQ is the list of target pollutants to be considered. A total of 12 pollutants have been used to evaluate the new index. However, not all pollutants have the same importance on the ULR-IAQ final value. Figure 7 reports how frequent each pollutant has the first, second and third highest sub-index, respectively noted "pollutant 1, 2 and 3". Theresult clearly pointsformaldehyde, acrolein, benzene, PM 10 , PM 2.5 and carbon monoxide as unavoidable when evaluating IAQ in dwellings. However, from literature, at least three more pollutants of interest should be added to the list i.e. radon, nitrogen dioxide and mould. Their harmful effects are known but there was no available data in the French survey to take them into account.

CONCLUSION

This work is based on the comparison of IAQ indices. Eight indices found in the literature were calculated and compared using thedata of the French dwelling measurement campaign (567 housings) as inputs. By analysing the outputs and indices' original definitions, the advantages and drawbacks have been listed and the definition of a new index called ULR-IAQ has been proposed.The new index seems to give a better representation of the IAQ of the studied dwellings. In particular, the index allows the detection of bad IAQ caused by one (or more) pollutants, ability not included in the existing indices.The new index permits to limit the list of pollutants of interest to a minimum, alist in agreement with previous prioritization studies [START_REF] Index | The INDEX project: Critical Appraisal of the Setting and Implementation of Indoor exposure Limits in the EU[END_REF][START_REF] Kirchner | Etat de la qualité de l'air dans les logements français[END_REF].

AKNOWLEDGEMENTS

The authors want to thank the Nouvelle Aquitaine Region (CPER 2015-2020 "Bâtiment Durable") and Health Agency (former ARS-Poitou-Charentes) for funding this research project.

Figure 1 :

 1 Figure 1: Representation of indices (left: original scale; right: common scale) -Example for IAPI.

Figure 2 :

 2 Figure 2: Detection of hidden information -Example for IAPI.

Figure 3 :

 3 Figure 3: Representation of indices according to their original scale.

Figure 4 :

 4 Figure 4: Representation of indices according to their interpretation scale.

Figure 5 :

 5 Figure 5: Comparison of indices with the MAX index.

Figure 6 :

 6 Figure 6: Results of ULR-IAQ, original scale (left), interpretation scale (middle) and comparison with max(right).

Figure 7 :

 7 Figure 7: Frequency of pollutants corresponding to the 3 most unfavourable on the whole dwelling measurement campaign.

Table 1 :

 1 previously proposed approaches to define IAQ index

	Index	Equation

Table 2 :

 2 Main pros and cons for IAQ indices and types of formula.

	Type	of	Corresponding	Main pros	Main cons
	aggregation		indices
	Sum-average	IEI, CLIM2000,	IEI values are limited between 0	Loss of information by ambiguity or
			LHVP,	Quad-	and 10. Quad-BBC has an	eclipsing (Ministry of Environment,
			BBC		adaptive formula depending on	Forests	and	Climate	Change,
					the type of room.	2014):importance of a high value can be
						reduced in a mass of low values even if it
						exceeds hazardous threshold level.
	Maximum		BILGA		Based on the most unfavourable	ELVs used are old and need to be updated
					pollutant level.
					Take into account both limited
					risks and important risks.
	Specific		GAPI,DALY	GAPI has a flexible formula that	GAPI value has no real signification.
	formula				can be readapted to any pollutants	DALY approach is very approximate and
					and many studies criteria. DALY	many pollutants lack of availabledata to
					is based exclusively on health	be usedefficiently.
					impacts.
	Score	by	IEI Taiwan	IEI Taiwan gathers both Sum-	In practice, it is almost equal to Maximum
	breakpoint				average and Maximum type	type. Breakpoint concentrations and
	concentration			advantages.	categories	weights	are	defined
						subjectively without a related health
						correlation

Table 3 :

 3 Pollutants used inthe calculation of each index. Almost every index use Exposure Limit Value (ELV) to quantify the exposure level to a pollutant. Among the studied indices, 4 different types of ELV are used: -Limited Risk Value (LRV): For exposure below LRV, health impacts are limited, null, or unknown. -Important Risk Value (IRV): If exposure is above IRV, health impacts are proven, corresponding to irreversible lesions, chronic diseases, or even death. -Toxicological Reference value (TRV): Based on animal toxicological studies by applying a conversion factor, or sometimes based on human epidemiologic studies. -Indoor Air Guideline Values (IAGV): Threshold values defined by national or international organizations, e.g. the French Agency of Health and Environment Security (ANSES

	Indices	Pollutants
	IAPI	Formaldehyde, Benzene, Acrolein, Carbon monoxide, Carbon dioxide, PM 10 , PM 2.5
	LHVP	Carbon monoxide, Carbon dioxide
	CLIM 2000	Carbon monoxide, Carbon dioxide, Formaldehyde
	BILGA	Carbon monoxide (1h), Carbon monoxide(8h), Carbon dioxide, Formaldehyde, Radon
	GAPI	Formaldehyde, Acetaldehyde, Acrolein, Hexaldehyde, Benzene, 1-Methoxy-2-propanol,
		Trichloroethylen, Toluene, Tetrachloroethylene, 1-Metoxy-2-Propyl, Acetate, Ethylbenzene,
		m,p-xylenes, styrene, o-xylene, 2-Butoxyethanol, 124-Trimethylbenzene, 1,4-
		dichlorobenzene, n-decane, 2-Butoxy ethyl acetate, n-undecane
	IEI Taïwan	Carbon monoxide, Formaldehyde, Carbon dioxide, PM 2.5 and Total volatile organic
		compounds (TVOC)
	Quad-BBC	Carbon monoxide, Formaldehyde, PM 2.5 , Radon, Toluene, o-xylene, Acetone, PM 10
	DALY	PM 2.5 , Carbon monoxide, Acrolein, Formaldehyde, Benzene
	2.3 Exposure Limit Values (ELV)

All pollutants are presented as follows: name [long-term ELV; short-term ELV]. All units are in µg.m -3 except for carbon monoxide which is in mg.m -3