outcomes

IXP-Active

Proposed Approaches to Active Internet Measurement at IXPs

We need a way to direct measurement traffic through individual Internet exchange point (IXP) members. Systems install a single best route, even when an IXP has many options for a given destination. However, traditional looking glasses do not provide ability to ping or traceroute through a specific IXP member.

Needs

  • Researchers want to correlate control and data planes.
  • Network Operators want to understand the router-level path to a point in their network from outside their network.
  • Network Operators want to support active measurement of their networks without having to support measurement vantage points.
  • IXP operators might want to offer performance data for routes available at their IXP to inform network operator policies.

We present three possible approaches:

Proposed Approach 1: Transit Source Address

Transit Source Address: we source measurement traffic using a source address of our transit provider

  • Benefit: requires no special action from the member AS
  • Issue: member AS does not control the reverse path to the VP
Proposed Approach 2: Member Source Address

Member Source Address: we source measurement traffic using an address supplied by the IXP member

  • Benefit: member AS controls the reverse path
  • Issue: member AS has to provision an address and configure routing
Proposed Approach 3: Originated Source

Originated Source: we source measurement traffic using addresses in a /24 prefix we announce at the IXP

  • Benefit: well understood approach to peering and routing
  • Issue: we require address space to originate at each IXP

In all approaches, we would ask individual IXP members for their permission and cooperation.

Overall, researchers gain orders of magnitude more visibility into inter-domain routing. Network Operators gain the ability to debug network performance issues from a variety of network views. IXP operators can offer value-added services, such as data to support performance-aware routing.

Prototype System Requirements

We are seeking a small VM to support prototype development

  • Two Network Interfaces: one connected to IXP and one for transit
  • 2 cores, 4GB of RAM, 10GB disk, Linux or *BSD

The system will primarily conduct light-weight topology and delay measurements (ping and traceroute) with scamper. We will implement a system to allow IXP member access to the capability and data.