Internet Engineering Task Force O. Akonjang Internet-Draft A. Feldmann Intended status: Informational DT Labs/TU Berlin Expires: September 3, 2009 S. Previdi B. Davie Cisco Systems, Inc. D. Saucez Universite catholique de Louvain March 2, 2009 The PROXIDOR Service draft-akonjang-alto-proxidor-00.txt Status of This Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 3, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Akonjang, et al. Expires September 3, 2009 [Page 1] Internet-Draft ALTO PROXIDOR March 2009 Abstract Several applications, such as peer-to-peer (P2P), content distribution and realtime services rely on selection mechanisms in order to select the peer or server from which to request the service. Examples of such services are: file sharing, media streaming and voice gateways. Application-layer selection algorithms do not typically take into account network-layer topology information; either that information is unavailable to them, or when such information is available (e.g., from BGP Looking Glass servers), it does not include sufficient information about the local topology in the neighbourhood of the application client(s). Therefore, most applications today make their selection decisions based on performance measurements (combined with some amount of random selection) and largely ignore network layer routing. It has been demonstrated that by keeping the traffic local (e.g., within the same Autonomous System) both infrastructure utilization and application performance may be improved. By enhancing selection algorithms through the use of accurate network-layer topology, applications may improve performance while network operators are also able to reduce the utilization of infrastructure resources by application traffic. At the same time, exchange of information between the application and the network should not be allowed to compromise confidentiality for either party. Detailed routing information owned by the service provider should not be made publicly available, while detailed information about the application should also not be made known to the service provider. This draft introduces a signaling protocol which we call "PROXIDOR". The PROXIDOR protocol is a request-response protocol in which a PROXIDOR Client (PxC) issues requests to and receives responses from a PROXIDOR Server (PxS). The questions of how a PxC discovers a PxS and how a PxS acquires network-layer topology information are beyond the scope of this document. Akonjang, et al. Expires September 3, 2009 [Page 2] Internet-Draft ALTO PROXIDOR March 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Historical Background of this Proposal . . . . . . . . . . 5 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Benefits of the PROXIDOR Service . . . . . . . . . . . . . . . 5 3.1. Benefits to End-users . . . . . . . . . . . . . . . . . . 5 3.2. Benefits to the ISP . . . . . . . . . . . . . . . . . . . 5 4. The PROXIDOR Architecture . . . . . . . . . . . . . . . . . . 5 4.1. Definitions and Terminologies . . . . . . . . . . . . . . 6 4.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.3. Design Goals . . . . . . . . . . . . . . . . . . . . . . . 7 4.4. Design Choices . . . . . . . . . . . . . . . . . . . . . . 7 5. Entities of the PROXIDOR System . . . . . . . . . . . . . . . 8 5.1. The PROXIDOR Client . . . . . . . . . . . . . . . . . . . 8 5.2. The PROXIDOR Server . . . . . . . . . . . . . . . . . . . 9 5.3. The Ranking System . . . . . . . . . . . . . . . . . . . . 9 6. PROXIDOR Messages . . . . . . . . . . . . . . . . . . . . . . 10 6.1. The Query Message . . . . . . . . . . . . . . . . . . . . 10 6.2. The Response Message . . . . . . . . . . . . . . . . . . . 10 7. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.1. The Oracle Use Case . . . . . . . . . . . . . . . . . . . 11 7.2. The Proximity Use Case . . . . . . . . . . . . . . . . . . 12 7.3. The IDIPS Use Case . . . . . . . . . . . . . . . . . . . . 13 8. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 14 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 11.1. Normative References . . . . . . . . . . . . . . . . . . . 15 11.2. Informative References . . . . . . . . . . . . . . . . . . 15 Akonjang, et al. Expires September 3, 2009 [Page 3] Internet-Draft ALTO PROXIDOR March 2009 1. Introduction This draft introduces the concept of a PROXIDOR service (PS). A PROXIDOR Service (PS) aims to deliver to selection algorithms at the application layer (or any other consumer of the PROXIDOR service) the topological guidance that will allow an improved selection scheme, taking into considerations the topology and infrastructure that is going to be used for transmitting data from/to a given selected peer, host or server. The protocol defined in this draft aims to be generic and exploitable by any application entity requiring such a service, no matter its architecture and implementation. This draft describes a signaling protocol through which a PROXIDOR Client (PxC) requests service from a PROXIDOR Server (PxS). In the current version of the document, the protocol is described only in high-level, abstract terms. As an example, a peer-to-peer client, once it has obtained from the application layer the list of peers through which a given content or service can be obtained, requests PROXIDOR services from a PROXIDOR server. The PROXIDOR query is built with the list of candidate peers' IP addresses and sent to the PxS. The PxS replies with the original list of IP addresses sorted by preference. The definition of "preference" in this context requires some further explanation. By assigning a higher preference to a particular address, the PxS indicates to the application that, all things being equal, the application should prefer that address to other addresses of lower preference. Exactly what the PxS means by higher preference, or how this preference is calculated, is intentionally not made explicit. As an example, preference may be calculated by using routing metric distance, with nodes that are a shorter distance from the requester being given a higher preference than those that are at a greater distance. Such a calculation could, for example, be performed by inspecting network-layer information (IGP, BGP, etc) and may also be influenced by policies of the service provider. We assume that the service provider cannot force the application to adhere to the preferences that the PROXIDOR service provides. Therefore, the service provider has an incentive to provide information that is useful to the application; otherwise it is likely to be ignored. Although we use IP addresses in the preceding example, similar ranking operations could also be performed on AS numbers, address prefixes, etc. While it is necessary to ensure interoperability through the standardization of the signaling protocol, there is no immediate need to standardize any algorithm or any computational Akonjang, et al. Expires September 3, 2009 [Page 4] Internet-Draft ALTO PROXIDOR March 2009 method that computes ranks or preferences. 1.1. Historical Background of this Proposal The architecture and protocol described in this document arose from the merger of three previous pieces of work: the Oracle service [1], the ISP-Driven Informed Path Selection (IDIPS) service [5] and the Proximity service [6]. The name PROXIDOR, like the proposal itself, contains elements of each of these three original work items. 2. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 3. Benefits of the PROXIDOR Service The PROXIDOR service offers many benefits to both end-users (consumers of the service) and Internet Service Providers (ISPs) (providers of the service). 3.1. Benefits to End-users Hosts that use the PROXIDOR service can benefit in multiple ways, e.g., they no longer need to infer topology information or measure path performance by themselves. They can take advantage of the knowledge of the ISP to avoid bottlenecks and boost performance. 3.2. Benefits to the ISP ISPs also benefit from the PROXIDOR service. It enables them to influence the neighborhood selection process of overlay networks to e.g. ensure locality of traffic and also regain the ability to efficiently engineer traffic that traverses backbone and transit links, thus allowing a better provisioning of the networking infrastructure. 4. The PROXIDOR Architecture The PROXIDOR architecture can be defined in terms of its entities, the set of messages that are exchanged between these entities and the rules governing the exchanges. Akonjang, et al. Expires September 3, 2009 [Page 5] Internet-Draft ALTO PROXIDOR March 2009 4.1. Definitions and Terminologies Autonomous System (AS): A single network or a collection of networks under the same administrative control. Autonomous System Number (ASN): A globally unique number, used to identify an AS and to exchange exterior routing information with other (neighboring) ASes. PROXIDOR client (PxC): An Internet end-host that requests for PROXIDOR services by creating and sending queries. PROXIDOR server (PxS): An Internet system that accepts and processes PROXIDOR queries. Metric: Criteria used by server to process/rank IP addresses, prefixes or ASNs in a query. PROXIDOR Query (PxQ): A message to request for a particular PROXIDOR service. PROXIDOR Response (PxR): An answer to a PROXIDOR query. PROXIDOR Error (PxE): Indicates non-conformity. PROXIDOR Failure (PxF): A PROXIDOR system malfunction. PROXIDOR Services (PS): A PROXIDOR service that can be directly requested by clients. PROXIDOR Service Protocol (PSP): The protocol used by PROXIDOR entities to communicate with each oher. PROXIDOR Source List (PSL): A list of sources that is sent to PxS for ranking. PROXIDOR Target List (PTL): A list of targets that is sent to PxS for ranking. PROXIDOR Couples (PC): A ranked list of . Akonjang, et al. Expires September 3, 2009 [Page 6] Internet-Draft ALTO PROXIDOR March 2009 PROXIDOR Source Address (PSA): Source IP or Prefix address used in PxQ when requesting for PROXIDOR services. Type Length Value (TLV): Data encoding format for PROXIDOR payloads. 4.2. Scope This draft defines the PROXIDOR service, describes its functionality and gives details of its architecture. Details of the PROXIDOR protocol itself (i.e., details of the messages that are exchanged between entities of the PROXIDOR service) are out of scope of this document. 4.3. Design Goals We expect the PROXIDOR service to be requested by a high number of simultaneous clients and therefore aspects such as simplicity, scalability, performance and flexibility are among the most important criteria: o Simplicity. The protocol must be lightweight in its content and state machinery. Different flavors may be defined in order to cope with different application scenarios. However, in most of practical cases, the protocol should carry the minimal set of information in its simplest form of encoding. o Scalability. The protocol is expected to be used by a large amount of consumers simultaneously, which means that providers will have to absorb a large amount of transactions. Protocol specification should take into account the scalability factors that would allow the protocol and its implementations to scale. o Performance. Related to scalability, PROXIDOR servers will have to handle a high number of simultaneous transactions and therefore the performance of handling protocol packets is critical for the overall scalability and deployability of the protocol. o Flexibility. The protocol should allow different modes of operations with different encoding techniques. 4.4. Design Choices Two major concerns of the PROXIDOR protocol design are scalability and performance. A server (or a cluster of servers) should be able to simultaneously handle a very large number of client requests and yet, suffer no penalties in terms of performance. To address these Akonjang, et al. Expires September 3, 2009 [Page 7] Internet-Draft ALTO PROXIDOR March 2009 concerns, important design choices need to be made, including; i) Choice of transport protocol: The PROXIDOR service SHOULD be able to function with UDP, TCP and HTTP. ii) Choice of approach: Although most aspects of the PROXIDOR protocol are new, advantage is still taken of already existing protocols, such as the Domain Name System (DNS) protocol. In principle, we see a lot of functional similarities between the DNS and the PROXIDOR service. The DNS is not only distributed and very scalable, but can also effectively handle many queries from a large number of clients simultaneously. The DNS protocol approach is thus partly adopted. Further concerns of the protocol design are flexibility and extensibility. The protocol should be flexible enough to adapt to changes in end-users' and ISPs' needs and be extensible enough to incorporate new types of services without the need to undergo a fundamental change. To address these concerns, PROXIDOR uses both Service Codes (to request for particular PROXIDOR services or to express their preferences) and Service Categories (to create and categorize (new) PROXIDOR service groups). 5. Entities of the PROXIDOR System A PROXIDOR system consists of PROXIDOR clients and PROXIDOR servers. Both entities implement the PROXIDOR protocol in order to interact with each other. Each entity independently plays an important role in the overall system architecture. 5.1. The PROXIDOR Client The PROXIDOR client can either be an end-user host that generates and sends queries to a PROXIDOR server or a PROXIDOR server that generates and/or forwards queries to other PROXIDOR servers. To use the PROXIDOR service, a client (PxC) must generate a standard PROXIDOR query (PxQ) and send to the PROXIDOR server (PxS). It can also optionally cache a copy of the sent packet. It MUST clear its cache before attempting to contact another PROXIDOR server. Akonjang, et al. Expires September 3, 2009 [Page 8] Internet-Draft ALTO PROXIDOR March 2009 5.2. The PROXIDOR Server A PROXIDOR server that receives a query, can generally react in one of the following ways: o grant the request by responding appropriately to the query, o silently drop the query if it is e.g., running out of resources, o send back a PROXIDOR error message (PxE), in case of a malformed request, o send back a PROXIDOR failure message (PxF), in case of system malfunction, o send back a re-direct message, re-directing the client to another PROXIDOR server, if it doesn't offer the requested service and knows another (trusted) server that does. The server MAY also decide to explicitly express the criteria it used in ranking the contents of the response message. It should be noted that revealing the criteria does not directly reveal the algorithm or functions that these criteria were used to construct. The PROXIDOR protocol may also be used between servers. When a server needs more accurate information that is not available in its database, it may also use the PROXIDOR service to request this information from another server. This could be typical in environments such as the global coordinate system in [2]. PROXIDOR protocol supports authentication between a client and a server and between servers. Authentication could be used to establish a kind of trust between PROXIDOR entities involved in a transaction. 5.3. The Ranking System The most common (perhaps the default) criteria for the ranking system is the minimal distance between the requester and each individual IP address in the query message. In this case the PxS evaluates the distance between requester and each address of the list and returns the list in an ordered fashion. Distance is evaluated according to the network-layer topology. A different preference criteria can be specified, relying on AS membership: Given an unsorted list of IP addresses, the PxS returns the list ordered by preference in AS membership. The ranked list starts with addresses belonging to the same AS of the requester, then all other addresses ordered according to the number of AS-hops between their AS and requester's AS. Akonjang, et al. Expires September 3, 2009 [Page 9] Internet-Draft ALTO PROXIDOR March 2009 The ranking system can also use criteria that are based on measured performance, such as available bandwidth and link delays, as well as those that are based on the ISP's private policies and need to be taken into consideration. Criteria MAY be used either alone or in combinations, when evaluating preferences. While a ranking is one way to assign preferences to addresses, prefixes, etc., it may also be desirable to assign a weight to the elements in the list, to indicate more clearly the extent to which some elements are preferred over others. This approach is described in [4]. The semantic of each ranking request is carried within the query message (implicitly or explicitly). However, the server MAY or MAY NOT take this into account. 6. PROXIDOR Messages There are generally two types of PROXIDOR messages; the PROXIDOR query (PxQ) message and the PROXIDOR response (PxR) message. 6.1. The Query Message A standard (default) PROXIDOR query (PxQ) is that which is sent from a PROXIDOR client (PxC) to a PROXIDOR server (PxS). A PROXIDOR server (PxS) can also query another PxS using the same message format. The PROXIDOR protocol differentiates between these two query types. Query messages may also carry requests that express desires for more specific information or services. The server is not compelled to grant them. The server MAY decide to grant or ignore them, depending on its own preferences or individual policies. For example, it can decide to grant server-generated desires sent by trusted PxS peers and ignore client-generated ones that it considers to be too intrusive. 6.2. The Response Message Response messages are similar in structure to query messages. Response messages can make use of attributes (optional) to send additional information about designated payload types, e.g., when responding to queries sent by a trusted PxS peer. Such peers could exist within an AS or in a global coordinate system, made up of PROXIDOR servers that are managed by different ISPs. The additional information supplied by the use of attributes can help the receiving Akonjang, et al. Expires September 3, 2009 [Page 10] Internet-Draft ALTO PROXIDOR March 2009 server make better decisions before responding to client-generated queries. The order of the items in the response message is very important. The first item indicates highest priority or preference and the last one, least priority or preference. There is no general derivable relationship between this order and the criteria used to create it, since the latter MAY depend on factors that are of the PROXIDOR Service Provider's individual choice. Although some characteristics of the response message is also determined by the same factors that affect those of the query message, all response packets MUST additionally adhere to the important factor of strict ranking. Ranking could force the response payload to be packaged in particular orders relative to each other, requiring the use of extra bytes in the response message than that used in the query. The details of this aspect is out of scope of this document. 7. Use Cases Use cases are grouped according to service categories, such as the Oracle service category, the Proximity service category and the IDIPS service category. 7.1. The Oracle Use Case i) The PROXIDOR service is used in a P2P environment to influence the neighborhood selection process. An end-host that wants to join a P2P overlay, first needs to locate and cretae a list of potential neighbors. Instead of randomly connecting to clients in the list, the end-host can use the PROXIDOR service to establish a more effective connection pattern. 1. The PROXIDOR client (PxC) creates a PROXIDOR Target List (PTL) from the list of potentials neighbors. 2. PXC contructs a PROXIDOR query message (PxQ) with the PTL as payload. 3. PxC then sends PxQ to a PROXIDOR server (PxS) for ranking. 4. PxS receives and extracts PTL from PxQ. It uses its knowledge of the network to re-arrange the list, ranking them according to some pre-defined criteria, e.g. locality and bandwidth. Akonjang, et al. Expires September 3, 2009 [Page 11] Internet-Draft ALTO PROXIDOR March 2009 + The list is ranked according to priority (or preference), i.e., from highest to lowest. + Proximal and optimal performing neighbors (relative to PxC) are given highest priority and are placed at the top of the list. + PxS can decide to supplement the response with extra information through the use of attributes and their values. 5. PxS then sends the ranked PTL back to PxC. 6. PxC can now use the ranked PTL to establish optimal overlay connections. ii) The PROXIDOR service is used in a P2P environment to influence the selection of sources from where content is downloaded. After a successful search or after joining a swarm, PxC may have multiple sources from which content could be downloaded. It can use the PROXIDOR service again to locate the best sources (from among these potential sources) to download from. 1. PxC creates a new PTL from the list of potential sources. 2. PxC constructs a new PxQ using the new PTL. 3. PxC sends the new PxQ to PxS. 4. PxS extracts and ranks the PTL according to optimal performance. 5. PxS sends the ranked PTL back to PxC. 6. PxC can now use the ranked PTL to download from the best ranked sources in a more efficient mannner. 7.2. The Proximity Use Case 1. PxC obtains from the application layer the list of servers/peers where data or service is available. PxC builds a list of IP addresses corresponding to these peers/servers. 2. PxC builds a PROXIDOR query (PxQ). PxC insert following information in the query: * PSA: the PxC IP address. Akonjang, et al. Expires September 3, 2009 [Page 12] Internet-Draft ALTO PROXIDOR March 2009 * PTL: the list of target IP addresses. * PRC: set to IP-Address-based or AS-based. 3. PxC sends the PxQ to the PxS. 4. PxS receives PxQ and extracts the following information: * PROXIDOR Source Address (PSA). PSA is the source IP address of the requester. * PROXIDOR Target List (PTL). PTL is the list of IP addresses for which PROXIDOR service is requested. * PROXIDOR Ranking Criteria. 5. PxS computes PROXIDOR algorithms and ranks the PTL based on PRC. Preference is determined according to network-layer topology information. 6. PxS creates a PxR message including: * PROXIDOR Source Address (PSA): the PSA address as received in the request packet. * PROXIDOR Target List (PTL): the ordered (ranked) original PTL (as received in the request packet). * PROXIDOR Ranking Criteria: same as PRC in PxR message. 7. PxC receives PxR, extracts PTL and may apply it to its selection scheme. 7.3. The IDIPS Use Case The PxC is connected to its network with, at the same time, a wireless and a wired connection. 1. PxC obtains from the application layer the list of servers/peers where data or service is available. PxC builds a list of IP addresses corresponding to these peers/servers. 2. PxC builds a PROXIDOR query (PxQ). PxC insert following information in the query: * PSL: the list of PxC IP addresses. Akonjang, et al. Expires September 3, 2009 [Page 13] Internet-Draft ALTO PROXIDOR March 2009 * PTL: the list of target IP addresses. * PRC: set to delay-based. 3. PxC sends the PxQ to the PxS. 4. PxS receives PxQ and extracts the following information: * PROXIDOR Source List (PSL). PSL is the list of IP addresses of the requester. * PROXIDOR Target List (PTL). PTL is the list of IP addresses for which PROXIDOR service is requested. * PROXIDOR Ranking Criteria. 5. PxS determines the feasible pairs where souces are in PSL and destinations are in PTL. PxS computes PROXIDOR algorithms and ranks the pairs. Preference is determined according to network-layer topology information. 6. PxS creates a PxR message including: * PROXIDOR Couples (PC): the ordered (ranked) list of pairs built with the original PSL and the original PTL. * PROXIDOR Ranking Criteria: same as PRC in PxQ message. 7. PxC receives PxQ, extracts PC and may apply it to its selection scheme. 8. Extensibility The protocol is capable of using different transport mechanisms and also allows both clients and servers to express particular desires. These aspects add a great deal of flexibility to the protocol construct. The use of service categories also creates enough room for extensibility when the need for such arises, e.g., when changes in end-users' or ISPs' needs necessitate the creation of additional service features or even totally new service groups. 9. Security Considerations The PROXIDOR system MUST ensure that data is exchanged between PROXIDOR servers in a secure manner. Details of this aspect and Akonjang, et al. Expires September 3, 2009 [Page 14] Internet-Draft ALTO PROXIDOR March 2009 further security considerations will be treated in future versions of this document. 10. Contributors We acknowledge with much thanks the enormous contributions made through discussions, remarks and suggestions by the following individuals (in alphabetical order): Vinay Aggarwal, Olivier Bonaventure, Pierre Francois, Benjamin Frank, Luigi Iannone, Jun Jiang, Ingmar Poese, Georgios Smaragdakis and Pengchun Xie. 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 11.2. Informative References [1] Aggarwal, V., Feldmann, A., and C. Scheideler, "Can ISPs and P2P systems co-operate for improved performance?", ACM SIGCOMM Computer Communications Review (CCR), 37(3):29-40, July 2007. [2] Aggarwal, V., Feldmann, A., and R. Karrer, "An Internet Coordinate system to enable collaboration between ISPs and P2P systems", In Proceedings of the 11th International ICIN Conference , October 2007. [3] Aggarwal, V., Akonjang, O., and A. Feldmann, "Improving User and ISP Experience through ISP-aided P2P Locality", In Proceedings of 11th IEEE Global Internet Symposium 2008 (GI '08) , 2008. [4] Shalunov, S., Penno, R., and R. Woundy, "ALTO Information Export Service", draft-shalunov-alto-infoexport-00 (work in progress) , October 2008. [5] Saucez, D., Donnet, B., and O. Bonaventure, "IDIPS: ISP- Driven Informed Path Selection", draft-saucez-alto-idips-01 (work in progress) , February 2008. [6] Previdi, S., "Routing Proximity Services", IETF 73, http://www.ietf.org/proceedings/08nov/slides/alto-0.pdf, November 2008. Akonjang, et al. Expires September 3, 2009 [Page 15] Internet-Draft ALTO PROXIDOR March 2009 Authors' Addresses Obi Akonjang DT Labs/TU Berlin Ernst-Reuter-Platz 7 10587 Berlin Germany EMail: obi@net.t-labs.tu-berlin.de Anja Feldmann DT Labs/TU Berlin Ernst-Reuter-Platz 7 10587 Berlin Germany EMail: anja@net.t-labs.tu-berlin.de Stefano Previdi Cisco Systems, Inc. Via Del Serafico Rome 00142 Italy EMail: sprevidi@cisco.com Bruce Davie Cisco Systems, Inc. 1414 Mass. Ave. Boxborough, MA 01719 USA EMail: bsd@cisco.com Damien Saucez Universite catholique de Louvain Place Sainte Barbe 2 Louvain-la-Neuve, 1348 Belgium EMail: damien.saucez@uclouvain.be Akonjang, et al. Expires September 3, 2009 [Page 16]