In the context of the European Commission funded OneLab project, we are currently trying to propose a taxonomy of the BGP Communities attribute.

The BGP Communities attribute is defined in RFC 1997. The BGP Community attribute is an optional transitive attribute of variable length. The attribute consists of a set of four octet values that specify a community. The community attribute values are encoded with an Autonomous System (AS) number in the first two octets, with the remaining two octets defined by the AS. A prefix can have more than one community attribute. A BGP speaker that sees multiple community attributes in a prefix can act based on one, some or all the attributes. A router has the option to add or modify a community attribute before the router passes the attribute on to other peers.

Our current efforts in classifying the BGP Communities are based on the Quoitin and Bonaventure IETF draft proposed in 2002 and our inversitagations of whois information. Our current classification, sketched in the figure below (click to increase the size),

Blackhole

The blackhole category is a particular community used by an ISP to block packets. One can distinguish three types of blackholing by their scope, as shown on the figure above:

• Global blackholing. Packets are blocked everywhere in the ISP network.
• Border blackholing. Packets are blocked at the ISP border routers.
• Upstream blackholing. Packets are blockec by the ISP's transit provider before they enter its own network.

Inbound Communities

Inbound communities refer to communities added when a route is received by a router on an eBGP session. We divide the inbound communities into two categories, as depicted on the figure above:

• Localpref. This type of community sets the Localpref value in the As receiving the route. An example from AS174: 174:10 sets the Localpref to 10, i.e., below everything (least preferred). This corresponds to the BGP communities usage described in RFC 1998.
• Routes tagging. This type of community is used by an AS to indicate the location where the route was received from an external peer. A route might be tagged in different ways. In our taxonomy, we consider four different types of tag:
  • IXP. This type of community informs on the interconnection point where a given route was received. For instance, 4589:14901, from AS4589, indicates that the route was received at DE-CIX.
  • Type of Peer. Different types of BGP peers have been defined, such as customer (national or international), peering partner, or transit provider. An AS might use this classification in order to tag each received route with a community indicating the type of peer from which the route was received. For instance, the community 286:900, from AS286, describes transit routes.
  • Geographic. An AS might specify the geographic location where the route was received. This location might be quite general (i.e., a continent), or more precise (i.e., a city). For instance, 86:4013, from AS86, informs that the route was received in Brussels.
  • AS. This community indicates the AS from which a route was learned. This is different from the Type of Peer type as it does not give any information on the type of route. For instance, for AS8938, all routes learned from TeleGlobe are tagged with 8938:2100.

Outbound Communities

Outbound communities are used by a router to modulate BGP announcements. We refine the concept of outbound communities by considering that these communities follow traffic engineering purpose: a community is inserted by the originator of the route in order to influence its redistribution by downstream
routers. The outbound communities affect thus the routes redistribution. We divide the routes redistribution communities into two categories, as shown on the figure above:

• Announcement. The community is attached to a route to indicate whether the route should or should not be announced to a specified peer or at a specified interconnection point. For instance, the community 8938:4000, from AS8938, means ``Do not announce to any upstream provider''.
• ASPATH Prepending. This type of community aims at prepending n times to the ASPATH when announcing the route to a specified peer. For example, the communities 286:1n, from AS286, prepends n (where 1 <= n <= 4) times 286 to European peers.

Documents

The draft of paper on BGP communities is available here.

The documented BGP Communities according to our taxonomy is available here.

The DTD for the XML file is available here.