---

Figure 1. World map of AS facilities identified in this data set.

Terminology

• Interconnection facility: a physical location (a building or part of one) that supports interconnection of networks. These facilities lease customers secure space to locate and operate network equipment. They also provide power, cooling, fire protection, dedicated cabling to support different types of network connection, and in many cases administrative support. Most interconnection facilities are carrier-neutral, although some are operated by carriers. In large communication hubs, such as in large cities, an interconnection facility operator may operate multiple facilities in the same city, and connect them, so that networks participating at one facility can access networks at another facility in the same city.
• Internet Exchange Point (IXP): a physical infrastructure composed of layer-2 Ethernet switches, where participating networks can interconnect their routers using the switch fabric. Each IXP has one or more core switches. IXPs partner with interconnection facilities in the city where they operate, and install access switches at those facilities, connecting these switches to the core switch. Routers owned by members of an IXP may be located at different facilities associated with the same IXP.
• Interconnection Types: The interconnection type reveals the method used to connect two routers belonging to different companies (Figure 2):
  • Private Peering with Cross-connect uses a dedicated piece of circuit-switched network equipment that physically connects the interfaces of two networks present at the interconnection facility.
  • Public Peering (also referred to as Public Interconnect) is an interconnection between two members of an IXP via the IXP's switch fabric.
  • Private Interconnects over IXP (tethering) establishes a point-to-point virtual private line over the IXP's public switch fabric.
  • Remote Peering leverages transport networks to connect one's router to the IXP via an Ethernet-over-MPLS connection. In this way, one can peer with members at the facility without deploying (and maintaining) hardware there.

Methodology for Mapping AS interconnections to Facilities

Figure 3 depicts the overall methodology (detailed in Mapping Peering Interconnections to a Facility, 2015) and datasets used by the interconnection-to-facility inference process. In the first step, we extract the following information from a public data source (e.g., PeeringDB database): a list of interconnection facilities, their locations, and AS membership at each of these facilities. We complement geographic information available from PeeringDB with coordinate and population data from the Geoname geolocation database. We use CAIDA's AS-to-Organization dataset to find which ASes administratively belong to the same organization. Finally, we cull a list of prefixes belonging to the ASes in the PeeringDB data using AS-to-prefix mapping inferred from CAIDA's AS Relationships data set.

The second step requires conducting (or using archived) traceroute probing specifically targeting IP addresses belonging to the prefixes identified in the first step. We map each observed IP interface to an AS using CAIDA's AS Rank's prefix-to-AS map. We also perform alias resolution, i.e., collapse IP interfaces into routers, with CAIDA's MIDAR tool, and assign AS ownership to the inferred routers. The alias resolution process increases the accuracy of our IP-to-AS mappings, and provides additional constraints for mapping interfaces to facilities. Finally, this topology data, combined with the inferred mapping of ASes and IXPs to candidate facilities, becomes an input into our iterative Constraint Facilities Search algorithm that progressively narrows down the possible set of facility locations of a given interconnection relationship.

Format

This AS-to Facilities dataset was derived using measurement data collected in March-April 2017. It includes the following files.

The file mapped-aslinks.json contains the mapping of peering interconnections to the interconnection facilities. The data for each AS interconnection are encoded in JSON format with the following attributes:

{
   "near-end" : {
      "asn" : "6939"
      "facility_name" : "equinix stockholm bromma (sk1)",
      "facility_id" : "equinix stockholm bromma",
      "facility_operator" : "equinix",
      "city" : "stockholm",
      "country" : "se",
      "ip" : "184.105.64.106",
   },
   "far-end" : {
      "asn" : "49505"
   },
   "peering_type" : "private",
   "peering_subtype" : "tethering",
   "ixp":"EQUX"
}

• "near-end": attributes of the near-end AS of the interconnection
• "far-end": attributes of the far-end AS of the interconnection
• "peering_type": whether the peering is established over an IXP ("public") or directly ("private")
• "peering_subtype": whether the peering ASes are in the same facility ("cross-connect" for "private" type, "local" for "public" type), or in different facilities ("tethering" for "private" type, "remote" for "public" type)
• "ixp": the name of the IXP (ONLY for "public" peering types)

Additionally, "end" nodes may have the following attributes:

• "asn": AS number
• "facility_name": name of the facility where the border router is located
• "facility_id": id of facility where the border router is located
• "facility_operator": operator of facility where the border router is located
• "city": the city where the facility is located
• "country": the country of the facility (2-letter ISO code)
• "ip": the router interface IP

Except for the "asn" attribute, all other attributes are optional for the "far-end" node, depending on the peering type. For private cross-connects, the facility remains the same as the near end. We include the facility data of the "far-end" for private tethering only if we have inferred it.

The file asn-to-facilities.json contains the PeeringDB map of ASes to interconnection facilities.

{
   "ASN" : "10010",
   "facility_id" : "ntt data dojima"
}

The file facilities.json contains the information about individual interconnection facilities. Not all facilities have all fields.

{
   "operator" : "io data centers, llc",
   "address" : "615 N. 48th Street",
   "id" : "io phoenix one",
   "city" : "phoenix",
   "alternatenames" : [
      "AZIX "
   ],
   "geonameid" : "5131135",
   "name" : "io phoenix one",
   "country" : "US"
}

The file geonames.json contains a copy of the geonames cities used by the facilities. Documentation of these fields is in the Geoname's README file.

{
   "timezone" : "Europe/Andorra",
   "feature code" : "PPL",
   "alternatenames" : [
      "ehl tarter"
   ],
   "elevation" : "",
   "latitude" : "42.57952",
   "cc2" : "",
   "admin2 code" : "",
   "population" : "1052",
   "admin4 code" : "",
   "feature class" : "P",
   "geonameId" : "3039154",
   "name" : "El Tarter",
   "country code" : "AD",
   "dem" : "1721",
   "longitude" : "1.65362",
   "asciiname" : "El Tarter",
   "admin1 code" : "02",
   "admin3 code" : ""
}

Acceptable Use Agreement

Access to these data is subject to the terms of the following CAIDA Acceptable Use Agreement

When referencing this data (as required by the AUA), please use:

The CAIDA UCSD AS Facilities Mapping dataset - April 2017,
https://www.caida.org/catalog/datasets/as-facilities/

You are required to report your publications using this dataset to CAIDA.

Request Data Access

• Request Access to the CAIDA Interconnection Datasets