World IPv6 Day Specification
Subscribe

From OpenNMS

Jump to: navigation, search

Contents

World IPv6 Day Monitoring Project

Objective

To define a strategy/specification for how and what we will monitor on IPv6 day, June 8th, 2011.

Documentation

We are writing several pages that describe the final results of this effort

Strategy

The current strategy for monitoring will be to recruit as many community members as possible to remotely poll a number of publicly-facing websites using both IPv6 and IPv4 addresses. The websites will be selected from participants in World IPv6 Day and other sites that already have IPv6 connectivity (such as ipv6.google.com). The goal will be to gather statistics regarding which systems are successfully reachable over IPv6 by verifying DNS lookups and network connectivity. IPv6 connectivity will be monitored alongside IPv4 connectivity where possible to compare IPv6 connectivity to legacy IPv4 connectivity. IPv4-only remote poller systems will only succeed in monitoring the IPv4 versions of the publicly-facing sites and will provide an estimate of the IPv6 readiness of our community members who choose to participate in remote polling.

The idea would be to create a node with 2 services for each participant's site. One HTTP service for each IPv4 and IPv6 address.

Issues

  • How many remote pollers do we need to make this reasonable?

Design

  • Setup a 1.9 version of OpenNMS on a public ipv6 system
    • Choopa.com has provided us an IPv6 server
  • Configure and Provision the system with services for both the ipv4 and ipv6 enabled version of a number of sites
    • May be that we need to quickly develop a custom monitor to provide better support for this project
  • Setup remote polling packages that will monitor these services
  • Setup up monitoring locations based on the volunteering support for registering remote pollers.
    • Locations will consist of an aggregation something like 'Continent' as the area and 'Country' as the location. The driver is the number of remote pollers that have been volunteered from a location. SInce the USA has quite a large number, State and USA makes more sense than Country and Continent. The goal is to not to have to rely on 1 remote poller for a location.
    • Maybe other possibilities like ISP or something interesting like that
  • A REST API will expose the IPv6 vs IPv4 connectivity data as a provided for summary pages, graphs and apps.
  • A summary graphic or page will be provided to ISOC to display on their IPv6 Day monitoring site.
    • Cross site scripting is presenting a challenge when trying to pull data from the ISOC HTTP server
  • A summary page will be provided on the OpenNMS system that provides additional details that the graphic can link to.

Tasks

(note: There is a project in our Jira instance that we are using internally to track this project. We will look into exposing that project to the community)

  • Create a schedule for task completion
  • Test that remote polling works to IPv6 addresses and is reported properly
  • Setup a public host ipv6.opennms.org
  • Setup opennms on our public host and ensure remote polling works
  • Gather information regarding who would like to participate as a remote poller, their location and their ISP
  • Design a set of locations for monitor-locations.xml that shows an appropriate representation of the remote polling community
  • Recruit community members to establish remote polling locations
  • Develop and/or test RESTful API to monitoring data
  • Design summary page for OpenNMS site
  • Develop summary page for OpenNMS site
  • Design summary page/graphic for ISOC site
  • Develop summary page/graphic for ISOC site


ISOC Brief Summary UI

The UI portion of the summary page.

Strategy

Show the availability data for the Quad A record, A record, IPv6 and IPv4. This will be data over time and will be shown in a line/area chart. You will be able to select

Acceptance Criteria

  1. Configure remote pollers
  2. Point your browser here: http://localhost:8980/opennms/tbd
  3. View the Brief Summary page, a chart should show availability for all locations and hosts initially, with the ability to drill down to a single location and/or a single host.


ISOC REST API Specification

This specification outlines the goals for the RESTful api that will drive ISOC World IPv6 day, brief summary page, that will be hosted on the ISOC site on June 8th 2011.

Strategy

We have created a new module in features called isoc-ipv6-gui which will contain the brief summary page and the RESTful api to support it.

The RESTful api must support the following parameters:

resolution
The resolution of the data, similar to RRD resolution, supported resolutions will be daily,hourly and minute (which will default to 5min)
location
Used to specify which a specific location of interest
startTime
Used to specify start time of the availability data
endTime
Used to specify end time of the availability data, if left off will default to current time.
host
Used to specify a single host, defaults to all if not present.

Resulting in a url like the following: http://localhost:8980/opennms/rest/isoc/ipv6/?resolution=hour&location=all&startTime=1209614400000&endTime=1210046400000&host=google.com

Service Side Notes:

  • Must aggregate data from remote pollers

Acceptance Criteria

  • Proceed to REST URL: http://{opennms domain}/opennms/rest/isoc/ipv6/?location=all&resolution=hour&start=12&end=14
  • Check that it returns

{data:[{date:1209614400000, QuadA:3500, SingleA:40645, IPv6:1000, IPv4:60234}, {date:1209614400000, QuadA:3500, SingleA:40645, IPv6:1000, IPv4:60234}]}