Background
Google supports the exchange of BGP community tags with GGC nodes and peering sessions to signal important properties of a prefix for reporting, load-balancing, or policy enforcement. All information exchanged should be considered advisory.
Google will use reasonable efforts to honor the preferences indicated, but may discard any of this information if it conflicts with a higher-priority policy on the Google network.
All communities supported by GGC/Google peerings are in the "15169:" space, to avoid conflict with any communities already in use on your network. The same community tags can be used with GGC nodes as well as direct interconnections to AS15169.
Supported Communities
Communities for Indicating Access Technology
The GGC software currently supports communities that indicate the class of connectivity that clients have in the last mile. From this information, the GGC serving system may make determinations about things like:
- Buffering parameters in the stream sent to the client (controlling the amount that the server over-sends to the client to minimize the number of bytes wasted in serving to the client while maintaining a high-quality user experience)
- TCP parameters that may be more optimized for certain classes of connectivity
- Providing performance breakdowns by access technology in the Google ISP portal
In cases where the connectivity level can vary among clients within a subnet, the provider should advertise all applicable technologies available to that subnet. Google encourages providing specific announcements that cover only a single access technology per block, as these provide the most useful reporting data.
Access Technology Communities
| Community | Access Technology |
|---|---|
| 15169:10010 | GPRS Mobile Broadband |
| 15169:10020 | 2.5G/Edge Mobile Broadband |
| 15169:10030 | 3G Mobile Broadband |
| 15169:10040 | 4G Mobile Broadband |
| 15169:10050 | Dial-Up |
| 15169:10060 | ISDN |
| 15169:10070 | Cable |
| 15169:10080 | Cable-Business |
| 15169:10090 | Ethernet/Enterprise Access |
| 15169:10100 | Fiber to the Home |
| 15169:10110 | Fiber to the Premises-Business |
| 15169:10120 | ADSL |
| 15169:10130 | ADSL-Business |
| 15169:10140 | VDSL |
| 15169:10150 | VDSL-Business |
| 15169:10160 | Wholesale/Transit- Not directly user-facing |
| 15169:10170 | Satellite |
For technologies that specify Business, this is meant as a distinction to refer to an access product marketed towards business customers.
Communities for Indicating Differentiated Product Offerings
Google provides the ability for providers to get performance reporting by product. Products can be built inside the Google ISP Portal product editor by matching against access technologies. If a company offers a fiber and a DSL product they can set up each as an independent product in the product editor. Performance reporting is available on a per-product basis.
In the event that an ISP offers a differentiated offering using the same access type, a group of communities is provided to help distinguish among them. In order for reporting to be provided, the prefixes must also be tagged with an access technology community.
The range for product differentiation is 15169:11000 - 15169:11005.
| Community | Product Differentiation Community |
|---|---|
| 15169:11000 | Product Differentiator #1 |
| ... | Product Differentiator #2 - #5 |
| 15169:11005 | Product Differentiator #6 |
BGP specified and Web Specified Communities
In addition to specifying communities via BGP, Google supports the ability for providers to specify communities with CSV files at the ISP Portal.
The header of the CSV file must be "Prefix, ASN, Community ID". The format of each line in the file must follow this format.
Google will cross-reference the provided community mappings in the web CSV file with the prefixes received via BGP. Web specified communities always override BGP specified communities.
This means that if a prefix at a given ASN was tagged with community 1 in BGP but the web prefix tagged it with community 2, the prefix will be considered in community 2.
In the case that more generic prefixes are specified via web communities, the BGP prefixes that are more specific than the web prefix will assume the community ID of the web community.
If more specific prefixes are specified via web communities, the BGP prefixes are broken out accordingly. Only prefixes up to /24 are supported for product breakouts.
Please note that web prefixes are evaluated in the order that they are listed in the CSV.
In the case that multiple BGP communities within the same range are advertised for the same prefix on different routers, Google uses the largest community ID in the range. This doesn't apply to communities specifying router preferences.
For product reporting, all prefixes are grouped into a community. If not otherwise specified, they will be placed in a special default community with tag 0. ISPs can associate communities to products at the ISP Portal.
Please note the following:
- Both Web specified communities and BGP specified communities are used to annotate data that we show you at the ISP Portal, to help you debug problems in your network and create customized reports.
- Only BGP specified communities are considered for Preferred Ingress Signalling, and for Carrier Grade NAT configuration.
- BGP specified communities are considered while making traffic management decisions. Web specified communities are not considered.
Communities for Carrier Grade NAT
Google supports the integration of Google Global Cache (GGC) into Carrier Grade NAT (CGN) systems.
Complete documentation for this particular use of community tags can be found here.
Communities for Indicating Preferred Ingress Points
Google allows peers and ISPs hosting GGC servers to send advisory data indicating preference about traffic ingress points into their networks.
Google has chosen to not use MEDs to reflect the fact that these policies are not routing-level priorities: they are advisory and they can span multiple different interconnection types with Google.
- 15169:13000-13300 is the preference for receiving traffic at a particular ingress point for a particular block.
- 15169:13300 indicates the highest preference, while 15169:13000 is the lowest priority.
- Multiple egress-points can share the same preference and in this case Google will treat them as equal choices from the perspective of the peer network.
- If no tag is applied, 15169:13200 is assumed as the priority.
The same community tags can be used with GGC nodes as well as direct interconnections to AS15169 or AS36040. When preference is expressed across different deployment types or different peer ASNs, they will be treated globally across all inbound traffic to a particular ASN.
| Community | Preferred Ingress Signalling Range |
|---|---|
| 15169:13000 | Lowest preference to receive traffic for this prefix at this interconnection point (try to not serve traffic here). Attempt to serve traffic on an indirect path (through other upstreams or peers) before using this prefix. |
| ... | 15169:13001 - 15169:13099 indicates very low preference (the higher the tag, the higher the preference). Any prefix tagged in this range is less preferred than an indirect path. |
| 15169:13100 | Default priority of traffic on an indirect path. Tagging with this community indicates that the preference is equal to receiving traffic over an indirect path. |
| ... | 15169:13101 - 15169:13199 indicates low preference. Any prefix tagged in this range is preferred over indirect paths but not preferred to an interconnection point where the prefix is untagged. |
| 15169:13200 | Default priority to receive traffic for this prefix at this interconnection point (the same as if the prefix is untagged). |
| ... | 15169:13201 - 15169:13299 indicates high preference (the higher the tag the higher the preference). |
| 15169:13300 | Highest preference to receive traffic for this prefix at this interconnection point (try to serve traffic here). |
Frequently Asked Questions
Q: What happens if Google receives inconsistent communities on the same prefix in multiple locations
(GGC nodes and/or PNIs)?
A: This depends on the community.
- For access technology communities, we will assume that all communities received on any session apply (since multiple access communities can be supplied on any prefix).
- For preferred-ingress signalling, differing communities on different sessions is intended. The differentiation allows you to specify which session has a high or low preference for serving a particular block.
Q: What happens if Google receives a community in one place, but not another?
A: This depends on the community.
- For access technology communities, we will assume that all communities received on any session apply (since multiple access communities can be supplied on any prefix).
- For preferred-ingress signalling, any prefix that does not have a community is assumed to have the default priority: 15169:13200.
Appendix: Full Reference Table
| Community | Access Technology |
|---|---|
| 15169:10010 | GPRS Mobile Broadband |
| 15169:10020 | 2.5G/Edge Mobile Broadband |
| 15169:10030 | 3G Mobile Broadband |
| 15169:10040 | 4G Mobile Broadband |
| 15169:10050 | Dial-Up |
| 15169:10060 | ISDN |
| 15169:10070 | Cable |
| 15169:10080 | Cable-Business |
| 15169:10090 | Ethernet/Enterprise Access |
| 15169:10100 | Fiber to the Home |
| 15169:10110 | Fiber to the Premises-Business |
| 15169:10120 | ADSL |
| 15169:10130 | ADSL-Business |
| 15169:10140 | VDSL |
| 15169:10150 | VDSL-Business |
| 15169:10160 | Wholesale/Transit- Not directly user-facing |
| 15169:10170 | Satellite |
| Community | Product Differentiation Community |
|---|---|
| 15169:11000 | Product Differentiator #1 |
| ... | Product Differentiator #2 - #5 |
| 15169:11005 | Product Differentiator #6 |
| Community | Preferred Ingress Signalling Range |
|---|---|
| 15169:13000 | Lowest preference to receive traffic for this prefix at this interconnection point (try to not serve traffic here). Attempt to serve traffic on an indirect path (through other upstreams or peers) before using this prefix. |
| ... | 15169:13001 - 15169:13099 indicate very low preference (the higher the tag the higher the preference). Any prefix tagged in this range is less preferred than an indirect path. |
| 15169:13100 | Default priority of traffic on an indirect path. Tagging with this community indicates that the preference is equal to receiving traffic over an indirect path. |
| ... | 15169:13101 - 15169:13199 indicate low preference. Any prefix tagged in this range is preferred over indirect paths but not preferred to an interconnection point where the prefix is untagged. |
| 15169:13200 | Default priority to receive traffic for this prefix at this interconnection point (the same as if the prefix is untagged). |
| ... | 15169:13201 - 15169:13299 indicate high preference (the higher the tag the higher the preference). |
| 15169:13300 | Highest preference to receive traffic for this prefix at this interconnection point (try to serve traffic here). |