Internet Engineering Task Force Olivier Bonaventure INTERNET DRAFT UCL Bruno Quoitin FUNDP June, 2003 Expires December, 2003 Common utilizations of the BGP community attribute draft-bq-bgp-communities-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Abstract Since its introduction in RFC1997, the BGP community attribute has been used by many Autonomous Systems to build more scalable routing policies. We describe here the most common utilizations of the BGP community attribute and provide some examples. 1 Introduction The BGP Community attribute is an optional transitive attribute introduced in RFC1997 [TCL96] to help scale the management of routes within an AS. This attribute consists of a set of four octet values, each of which specifies a community value. [TCL96] reserves for standard use the community values ranging from 0x0000000 through 0x0000ffff and 0xffff0000 through 0xffffffff. Among them, three Bonaventure/Quoitin [Page 1] draft-bq-bgp-communities-00.txt June 2003 communities are defined with global significance: NO_EXPORT (0xffffff01) which mark routes that should not be advertised outside a BGP confederation, NO_ADVERTISE (0xffffff02) which mark routes that must not be advertised to other peers, and NO_EXPORT_SUBCONFED (0xffffff03) which mark routes that must not be advertised to peers outside the boundary of a subconfederation. Besides those reserved community values, a lot of room is left for experimentation, creativity and so on. [TCL96] proposed nevertheless to equally delegate this remaining community space to all the ASes. For this purpose, the remaining community values were divided by using an AS number in the two high-order octets. Thus, each AS received 65536 values of the community space, meaning that for instance, ASx is free to use community values ranging from ASx:0 to ASx:65535. However, [TCL96] did not specify whether the community values corresponding to the private AS space (i.e. community values 64512:00 - 65534:65535 as defined in [HB96]) could be used in the global Internet. Since the introduction of the community attribute, it has been used for various purposes by ISPs. A recent analysis of the BGP routing tables [QUB02] revealed that, depending on the measurement point, between 40% and 50% of the routes contained in those tables carried a community attribute with up to several dozens of distinct community values inside some routes. Despite this widespread utilization of community values, there is, to our knowledge, no public document describing the main utilizations of this attribute except [CB96], but this document only covers a very limited utilization of the community attribute. In this document, we describe the most common utilizations of the BGP community attribute in the global Internet. We base our analysis on the information available in the RIPE whois database and on discussions with ISPs. This document is organized as follows. First, we discuss in section 2 the current utilizations of the BGP community attribute and provide several examples. We discuss the problem of documenting community values in section 3 and some operational issues in section 4. Then, in section 5 we discuss the problem of encoding those policies in a limited number of community values and provide several examples from ISPs. We do not discuss in the document the utilization of communities or extended communities to support VPN services [RR99] or to block denial of service attacks [Tur03]. 2 Common utilizations of the BGP Community attribute The operation of a BGP router can be summarized as a set of Bonaventure/Quoitin [Page 2] draft-bq-bgp-communities-00.txt June 2003 operations performed on each received BGP UPDATE message announcing one or several prefixes. First, the received UPDATE messages are placed unprocessed in the Adj-RIB-In of the BGP peer from which the messages were received. A per-peer import policy is applied by the BGP router to determine which received messages will be placed in the Loc-RIB. The application of the import policy may result in the modification of some attributes of the selected messages (e.g. addition of local- pref). The BGP-decision process is then applied to the content of the Loc-RIB to select a best route toward each destination. The BGP router will then use a per-peer export policy to determine which routes of the Loc-RIB will be placed in the Adj-RIB-Out of each peer. The application of the export policy may result in the modification of some attributes of the message placed inside the Adj-RIB-Out. A more detailed description of the operation of BGP may be found in [RLH02]. +--------+ +---------+ | Prov1 | | Prov2 | |[London]| | [Miami] | | RD | | RC | +--------+ +-----\-+ +--//-----+ | Peer2 | \ // | RB | +-------+ +------\---//---------+ | // | | | | RW1 RW2 | +//------+ | RA=========RX ASX RY===IX [Brussels] |[Oslo] | | | \ |Peer1 | | RZ1 RZ2 | +-\-----+ +-------+ +------//-----\-------+ | RC | // \ | | +-----//-+ +--\-----+ | Peer3 | | RH | | RI | +--------+ |[Paris] | |[Tokyo] | | Cust1 | | Cust2 | +--------+ +---------+ Figure 1: Reference configuration In this document, we utilize the reference environment shown in figure 1 and focus on ASX in the middle of the figure. This AS has two upstream providers (Prov1 and Prov2, three peers (Peer1, Peer2 and Peer3) and two customers (Cust1 and Cust2). Note that the examples given in the document may not include all the ASes that appear in figure 1. To better understand the utilization of the BGP community values, it is useful to introduce a small classification that we will use Bonaventure/Quoitin [Page 3] draft-bq-bgp-communities-00.txt June 2003 throughout this document. We are conscious that such a classification is somewhat approximate because communities were designed as an open- ended attribute. This classification nevertheless helps to explain today's common practices. Although the BGP community values are defined as opaque values, most utilizations of those values can be divided in a few subtypes. In the remainder of this document, we will use the word local to indicate that a community value was attached by a router belonging to the AS to which this community has been delegated by [TCL96]. We will use the word foreign for a community value attached by a router belonging to a different AS. For example, in figure 1, community value ASX:123 would be considered as local if attached by router RX and foreign if attached by router RA. A second classification of the community values can be defined on the basis of how they influence the processing of the BGP UPDATE messages. We call informational a community value that only provides information and does not directly affect the processing of BGP UPDATE messages. Those community values are typically used to aid debugging or to provide information to allow remote peers to determine which remotely attached communities should be used to influence the processing of the BGP UPDATEs by distant BGP routers. We call coloring community a community value that is used to color the routes sharing a given property. Those colors may influence the processing of the BGP UPDATE messages by some routers. Finally, we call signalling community a community value that is used to explicitly request a downstream router or AS to perform a given action when receiving a BGP UPDATE message with this community value attached. In this section, we will refer to the community values by using symbolic names and examples. We discuss the encoding of those symbolic community values inside 32 bits wide community values in section 5. 2.1 Informational communities Informational communities are usually attached by their owner. Those values are used by an AS to indicate the location where the route was originated or received from an external peer. Many ASes have documented the utilization of such communities today. Based on the needs of each AS, different types of locations are used in practice : geographic location, interconnection point, or autonomous system (AS). Bonaventure/Quoitin [Page 4] draft-bq-bgp-communities-00.txt June 2003 2.1.1 Geographic location Network operators often want to tag routes with the geographic location where they were learned. The types of geographic locations used by each AS depend on the size of this AS. A national AS might want to tag the city where each route was learned, while an international AS would instead tag each route with the country or continent where it was learned. For example, in our reference configuration, ASX could define several community values inside its community space to tag the city and the continent where each route was learned. In this case, router RY would append community values ASX:Brussels,ASX:Europe to the routes learned from Peer2 and Peer3 while router RZ2 would attach community values ASX:Tokyo,ASX:Asia. This geographical information can be used for several purposes. First, it can be useful for debugging purposes. Second, the geographical information can be used by customers or possibly peers to aid in the selection of their best route. For example, consider a content provider with servers located in Paris, Tokyo, New-York and San Francisco. Based on the informational communities advertised by its peers, this content provider could configure its BGP routers in Paris to prefer the routes originated in Europe or learned from European peers, while the BGP routers in Tokyo could be configured to prefer the routes learned from Asian peers, .... 2.1.2 Interconnection point In some cases, ASes also utilize communities to indicate the interconnection point where each route was learned. Knowing the interconnection point where a route was learned can be useful for debugging purposes or used by remote peers as discussed above. For example, in our reference configuration, ASX could define one distinct community value for each IX where it is present. If ASX uses those community values, router RY would append community value ASX:IX to the routes learned from Peer2 and Peer3. A few ASes also use informational communities to remember the AS from which each route was learned. This utilization of the community attribute is redundant with the AS-Path attribute, but could be useful to simplify the configuration of some routers. 2.2 Coloring communities Bonaventure/Quoitin [Page 5] draft-bq-bgp-communities-00.txt June 2003 A second type of BGP communities are those that are used to color routes sharing the same property. Those community values are usually local. Coloring communities are typically used by large ISPs to build scalable routing policies. In this case, the ISP defines a few types of BGP peers (typically customer, peering partner and transit provider) and tags each received route with a community indicating to which types of peers the received route should or should not be advertised. This tagging can be used to ensure that customers receive all routes and that peers and providers only receive the internal and customer routes. For example, in our reference environment, ASX supports three types of peers : customers, peers and providers. ASX could want to configure its routers to ensure that the routes received from customers are advertised to customers, peers and providers while the routes learned from providers or peers are only advertised to customers. This routing policy can be achieved by defining three community values. ASX:ToCustomers would be used to tag a route that needs to be announced to customers, ASX:ToProviders to providers and ASX:ToPeers to peers. In this case, router RX would append AS:ToCustomers to the routes learned from Peer1 while router RZ2 would append ASX:ToCustomers,ASX:ToPeers,ASX:ToProviders to the routes learned from Cust2. Router RX would also be configured to only advertise the routes with the AS:ToPeers community value on the eBGP session with Peer1. Router RZ2 would be configured to only advertise the routes with the AS:ToCustomers on the eBGP session with Cust2. Coloring communities can also be used to provide different services to different customers. For example, a provider could offer a cheaper limited transit service in which only the customers and the peers of this ISP are reachable. In our reference configuration, this can be achieved by using two types of local coloring communities. First, the routes learned from a customer with a limited transit service would be tagged with only the ASX:ToCustomers community value. Second, communities would be defined to tag the type of peer from which a route has been learned. The export policies of the BGP sessions attached to customers with a limited transit service would then be configured to only announce the routes learned from customers. By using additional community values, it is possible to support different types of transit service, for example on a geographical basis. 2.3 Signalling communities In addition to the local coloring community values that are widely Bonaventure/Quoitin [Page 6] draft-bq-bgp-communities-00.txt June 2003 used by ISPs today, several ISPs have deployed signalling community values that can be used by their customers to influence the distribution of their routes to remote ASes. A first type of such communities are the ``do not announce'' communities. In this case, the community is attached to a route to indicate that this route should not be announced to a specified peer, at a specified interconnection point or to a given set of peers. For example, in our reference environment, ASX could allow its customers to indicate which routes should not be announced to each of its upstream providers, peers or at the IX. This can be achieved by defining several community values. For example, a route containing the ASX:NotProv1 would not be announced to provider Prov1. Several tens of ASes have documented their support for this kind of community values [QB02]. Many ASes utilize community values to indicate that a route should not be announced to a given AS or at a given interconnection point. Some ASes also allow the utilization of such communities to indicate that a route should not be announced outside a given region or continent. To support the utilization of those ``do not announce'' communities, an ISP should rely on the appropriate informational communities. For example, if an ISP wishes to allow its customers to utilize ``do not announce'' communities targeted at a given interconnection point, then it would be useful to also support informational communities that allow its customers to determine at which interconnection point each route was learned. Besides requesting that a route should not be announced to a given peer, remotely attached export communities are also often used to request the utilization of AS-Path prepending when announcing a route to a specified peer or set of peers. This can also be achieved by defining several community values. For example, ASX could configure its routers to prepend once (resp. three times) its own AS number when advertising to Prov1 a route containting the ASX:Prepend1Prov1 (resp. ASX:Prepend3Prov1) community value. Based on the content of the RIPE whois database in October 2001, many ISPs rely on remotely attached export communities to allow their customers to request the utilization of AS-Path prepending when announcing some routes to specified external peers, at specified interconnection points or in specified regions [QB02]. A final utilization of the signalling communities is to influence the BGP decision process by setting the LOCAL_PREF attribute of received routes while applying the import policy as documented in [CB96]. This utilization of the BGP community attribute is still present in Bonaventure/Quoitin [Page 7] draft-bq-bgp-communities-00.txt June 2003 the RIPE whois database and [QB02] has found that different levels of preference are provided. For instance: low local preference for customer (backup), normal local preference for customer, high local preference for customer, reduced peering, normal peering, preferred interconnect (private peering), upstream peer and other specific preferences. In our reference configuration, ASX could allow its customers to set the value of the preference at 80 or 120 instead of its default of 100 inside ASX by using community values ASX:Pref80,ASX:Pref120. 3 Documenting community values Autonomous Systems relying on BGP community values to implement scalable routing policies will often need to document the chosen community values. This documentation can be internal to the AS in the case of local community values, but often it needs to be distributed to peers and customers. Since the RPSL language [AVG^+99] was defined to specify routing policies, it would be normal to use it to precisely define the utilization of the community values inside an AS. RPSL contains several constructs that can be used to define this utilization of the community values, but unfortunately, a precise RPSL specification of a routing policy with several community values becomes quickly difficult to read. Due to the difficulty of documenting the utilization of community values by using RPSL, many ASes have chosen to provide in their RPSL policy, a set of remarks that informally describe the community values supported by this AS. This textual information is often sufficient to allow a human operator to determine the meaning of a given community value, but unfortunately it cannot be processed by tools that build or verify router configurations. 4 Operational issues The BGP Community attribute is a transitive optional attribute. ASes that do not utilize BGP community values in their router's configurations usually do not change the content of the BGP community attribute of received UPDATE messages. An AS willing to utilize informational, coloring or signalling community values should first install filters on its ingress and egress BGP routers. Those filters will depend on the types of community values that are used by the AS. If the AS uses informational communities, then its ingress BGP router should be configured to remove those community values from the UPDATE Bonaventure/Quoitin [Page 8] draft-bq-bgp-communities-00.txt June 2003 messages received over eBGP sessions. If those communities are only used internally and are not documented, then they should also be removed from the UPDATE messages sent to external peers since those values do not carry information understandable by the global Internet. If those communities are documented and are useful for external peers, they may be left in the UPDATE messages sent to external peers. In practice, it can be expected that few external ASes will utilize the informational communities defined by other ASes. To avoid polluting the BGP routing tables, an AS should only send its local informational community values to interested BGP peers, typically only to its own customers. If the AS uses local coloring community values, then its ingress BGP routers should be configured to remove those community values if they are found inside UPDATE messages received from external peers. Furthermore, since those community values have only a meaning inside the AS, they should be removed from the UPDATE messages sent over eBGP sessions to avoid polluting the BGP routing tables of the entire Internet. If the AS supports signalling community values, then it would typically configure its ingress filters to only allow those community values over eBGP sessions with customers and remove such communities from UPDATE messages received over eBGP sessions with peers and providers. Since those community values have only a local meaning, they should be removed from the UPDATE messages sent to any external peer. Another problem that should be taken into account is the aggregation of routes containing BGP community values. In [TCL96] the rule proposed to aggregate such routes is to place inside the aggregated route all the community values found in the individual routes. This rule is applicable for information community values, but using it to aggregate routes containing coloring or signalling community values could cause problems. Unfortunately, the encoding of the community values does not usually allow a router to determine the type of a given community value. 5 Encodings of BGP communities A practical issue that occurs when using community values to support routing policies as described in the previous section is that each AS needs to define the numerical values that it will support. In practice, a constraint on this encoding is that each AS has only been delegated a space of 65536 distinct community values [TCL96]. In this section, we briefly describe several encodings found in the RIPE whois database. Bonaventure/Quoitin [Page 9] draft-bq-bgp-communities-00.txt June 2003 5.1 Informational communities As discussed in section 2.1, the informational communities can be used to tag the geographical location, the AS and the IX at which each route was learned. 5.1.1 Geographic location Often, an AS that utilizes such community values relies on an unstructured list of values and associates a location to each value. For example, AS13129 (Global Access Telecommunications, Inc.) defined in [RIW02] the values shown in table 2 to tag routes learned in specific cities. ----------------------- |13129:3010|Frankfurt | ----------------------- |13129:3020|Munich | ----------------------- |13129:3030|Hamburg | ----------------------- |13129:3040|Berlin | ----------------------- |13129:3050|Dusseldorf| ----------------------- |13129:3210|London | ----------------------- |13129:3220|Paris | ----------------------- |13129:3610|New York | ----------------------- Table 2: Tagging communities published by AS13129 Some ASes have devised structured encodings of those route tagging community values such as the one documented by AS286 (EUnet) shown in table 3. With this encoding, the value used to tag a received route is based on the telephone country code. These communities are documented in [RIW02]. For example, according to this community setting, a route with community 286:3032 would have been learned by EUnet from a customer located in Belgium. ----------------------------------------------------------- | 286:1000 + countrycode |Public peer routes | ----------------------------------------------------------- | 286:2000 + countrycode |Private peer routes | ----------------------------------------------------------- | 286:3000 + countrycode |Customer routes | ----------------------------------------------------------- Bonaventure/Quoitin [Page 10] draft-bq-bgp-communities-00.txt June 2003 |where countrycode is the E.164 international dial prefix.| ----------------------------------------------------------- Table 3: Tagging communities published by AS286 Another example is the encoding chosen by AS3561 (Cable & Wireless) shown in table 4 that relies on the ISO 3166 codes for countries. The resulting communities are documented in [CW02]. ------------------------------------------------- |3561:SRCCC|S is the source (peer or customer)| | |R is the regional code | | |CCC is the ISO 3166 country code | ------------------------------------------------- Table 4: Informational communities used by AS3561 5.1.2 Informational communities indicating IXes Example of such informational communities, documented by AS13129 in [RIW02], are shown in table 5. We have not encountered structured encodings for the community values used to tag the interconnection point where routes were learned. ------------------- |13129:2110|DE-CIX| ------------------- |13129:2120|INXS | ------------------- |13129:2130|SFINX | ------------------- |13129:2140|LINX | ------------------- Table 5: Tagging communities published by AS13129 5.2 Signaling and coloring communities In this section, we provide example encodings of signaling and coloring communities based on information found in the RIPE whois database [RIW02]. 5.2.1 Coloring communities In this case, those community values are only used inside the AS and they are usually not documented. 5.2.2 Signalling communities Most of the ASes that support signalling communities rely on a Bonaventure/Quoitin [Page 11] draft-bq-bgp-communities-00.txt June 2003 structured list of community values for this purpose. For example, table 6 shows some of the community values used by AS1755 (OpenTransit) and documented in [RIW02]. ---------------------------------------------------- | Value |Meaning | ---------------------------------------------------- |1755:1000|Do not announce to US upstreams/peers | |1755:1101|Do not announce to Sprintlink(US)/AS1239| |1755:1102|Do not announce to UUNET(US)/AS701 | |1755:1103|Do not announce to Abovenet(US)/AS6461 | | ... | | |1755:2000|No announcement to European peers | | ... | | ---------------------------------------------------- Table 6: ``Do not announce'' communities used by AS1755 However, a few ASes rely on a more structured encoding of the community values used for this purpose. For example, AS9057/AS3356 (Level3) has chosen to reuse a range of community values corresponding to the private AS space as shown in table 7. -------------------------------------------------- | Value |Meaning | -------------------------------------------------- |65000:XXX |do not announce on peerings to AS XXX| | 65001:0 |prepend once to all peers | |65001:XXX |prepend once at peerings to AS XXX | | 65002:0 |prepend twice to all peers | |65002:XXX |prepend twice at peerings to AS XXX | -------------------------------------------------- Table 7: ``Do not announce'' communities used by AS9057/AS3356 Similar encodings are used for signalling communities requesting AS- Path prepending. For example, AS3561 (Cable & Wireless) has devised an interesting set of communities to allow peers to ask not to export or ask to prepend. This set can be found in table 8 (the list of peers to which these community values are supported may be found in [CW02]). ---------------------------------------- |3561:30PPN|PP is the peer code | | |N = 0, do not export | | | = 1, prepend once | | | = 2, prepend twice | | | = 3, prepend three times| ---------------------------------------- Table 8: Signalling communities supported by AS3561 Bonaventure/Quoitin [Page 12] draft-bq-bgp-communities-00.txt June 2003 Before deploying signalling communities, ISPs should note that the IETF is currently developing a new type of extended communities [BCH^+03] called ``redistribution communities''. Those redistribution communities can be used to influence the export policy of routers. Compared to the signalling communities, the redistribution communities have two advantages. First, ISPs willing to support them do not have to configure complex policies on their routers. This simplifies the configuration of routers and reduces the risk of misconfiguration. Second, the redistribution communities are non- transitive. This reduces the risk of polluting the BGP routing tables. Finally, the community values suggested in [CB96] are still used today. A typical example of the encoding of those communities is the one used by AS702 (UUNET Europe). This encoding is based on the 2 community values shown in table 9. ----------------------------------------- |702:80 |Set Local Pref 80 within AS702 | ----------------------------------------- |702:120|Set Local Pref 120 within AS702| ----------------------------------------- Table 9: Signalling communities defined by AS702 6 Conclusion In this document, we have described the main utilizations of the BGP community attribute in the global Internet. We have shown that several types of community values are used in practice. Some community values are purely informational. Community values can also be used to color routes sharing the same property. Other community values are used for signalling purposes, for example by setting the value of local-pref. We have also provided several examples and discussed configuration guidelines. Given the widespread utilization of community values in the global Internet, it might be useful to define a few sets of standardized community values to better support the common needs of various ISPs. For example, if a single type of informational community value indicating the geographical origin of a route could be defined, then it could be used by any BGP router. Today, each AS defines its own type of informational community. ISPs willing to support signalling community values could consider the utilization of the redistribution communities, a standardized type of extended communities being defined by the IETF [BCH^+03]. Bonaventure/Quoitin [Page 13] draft-bq-bgp-communities-00.txt June 2003 Another issue is that due to the utilization of community values, it becomes cumbersome to precisely specify the routing policies used by ISPs with RPSL. Most ISPs only document the community values used as remarks in their RPSL policies. This implies that the RPSL policies stored in the IRR do not reflect the deployed policies and it thus becomes impossible to utilize tools to check the consistency of the Internet routing policies. Acknowledgements This work was partially supported by the European Commission within the IST ATRIUM project. We would like to thank RIPE for their whois database and the RIPE RIS project. We thank Tim Griffin for his comments. References [AVG^+99] C. Alaettinoglu, C. Villamizar, E. Gerich, D. Kessens, D. Meyer, T. Bates, D. Karrenberg, and M. Terpstra. Routing Policy Specification Language (RPSL). Internet Engineering Task Force, RFC2622, June 1999. [BCH^+03] O. Bonaventure, S. De Cnodder, J. Haas, B. Quoitin, and R. White. Controlling the redistribution of BGP routes. Internet draft, draft-ietf-grow-bgp-redistribution-00.txt, work in progress, June 2003. [CB96] E. Chen and T. Bates. An Application of the BGP Community Attribute in Multi-home Routing. Internet Engineering Task Force, RFC1998, August 1996. [CW02] Communities defined by Cable & Wireless. available from http://infopage.cary.cw.net/Routing_Registry/communities.htm , January 2002. [HB96] J. Hawkinson and T. Bates. Guidelines for creation, selection, and registration of an Autonomous System (AS). Internet Engineering Task Force, RFC1930, March 1996. [QB02] B. Quoitin and O. Bonaventure. A survey of the utilization of the BGP community attribute. Technical report Infonet-TR-2002-02, http://www.infonet.fundp.ac.be/doc/tr/, March 2002. [QUB02] B. Quoitin, S. Uhlig, and O. Bonaventure. Using redistribution communities for interdomain traffic engineering. In COST263 Workshop of Quality of future Internet Services, LNCS. Springer-Verlag, October 2002. Bonaventure/Quoitin [Page 14] draft-bq-bgp-communities-00.txt June 2003 [RIW02] Whois database. RIPE NCC, http://abcoude.ripe.net/ris/rawdata, January 2002. [RLH02] Y. Rekhter, T. Li, and S. Hares. A Border Gateway Protocol 4 (BGP-4). Internet draft, draft-ietf-idr-bgp4-18.txt, work in progress, October 2002. [RR99] E. Rosen and Y. Rekhter. BGP/MPLS VPNs. Request for Comments 2547, Internet Engineering Task Force, March 1999. [TCL96] P. Traina, R. Chandrasekeran, and T. Li. BGP Communities Attribute. Internet Engineering Task Force, RFC1997, August 1996. [Tur03] D. Turk. Configuring bgp to block denial-of-service attacks. Internet draft, draft-turk-bgp-dos-04.txt, work in progress, January 2003. Authors' Addresses Olivier Bonaventure Universite catholique de Louvain (UCL), Belgium URL : http://www.info.ucl.ac.be/people/OBO/ Bruno Quoitin Infonet group, University of Namur (FUNDP) Rue Grandgagnage 21, B-5000 Namur, Belgium Email: Bruno.Quoitin@info.fundp.ac.be Bonaventure/Quoitin [Page 15]