To connect your site to the NDN testbed please read these policies first, then contact [email protected].
A testbed is vital to the success of the NDN project. The NDN team maintains a testbed that includes all institutions participating in the project. The current status of the NDN Testbed can be seen here: http://ndndemo.arl.wustl.edu/
The team periodically receives requests from other institutions to connect to the NDN testbed. While researchers may (and are encouraged to) create their own NDN testbed, networks with a significant number of nodes are of great value both to the NDN team and to the research community. Therefore, the NDN team accepts requests from external sites to connect to the NDN testbed. However, in order to ensure proper testbed operation and maintenance we require that all sites (external and internal) abide by the policies outlined below.
Policies to connect to the NDN testbed:
- Provide one or more dedicated machines on-site to act as the gateway NDN router(s) to the NDN testbed. The machine(s) should have an IP address that belongs to the institution. If multiple machines are provided for multi-homing, the same rules apply to each machine. The gateway should not be used for any other tasks beyond its role as an NDN router. Guest institutions may have any number of other locally controlled NDN nodes and routers behind the gateway NDN router; such nodes will gain connectivity to the NDN testbed via the NDN gateway router.
- Provide root (or sudo) access to the NDN testbed management institution (currently Washington University in Saint Louis, MO).
- Allow the NDN testbed management institution to install, remove and update NDN related software as needed for the operation and maintenance of the network.
- Work with the NDN testbed management institution to solve any firewall and tunneling issues that may arise during the installation, configuration and operation of the NDN router(s).
- Provide the name, email and telephone information of an easily and quickly reachable site-specific NDN operator who will be the main contact whenever issues arise with the local NDN router(s). A backup operator, while not required, is highly encouraged. Operator email addresses must belong to the institution. All local operators will be required to join and regularly monitor an NDN operator mailing list and are required to respond to requests from the testbed management institution ASAP, but no later than 24 hours.
- Ensure that the machine has limited logins beyond the NDN account. A local operator account is highly encouraged, but general user accounts should not be present on the NDN router. In addition, only NDN-related software should be allowed to run on the machine.
- The machine may be a dedicated physical box or a virtual machine (VM) with a publicly routable IP address (i.e., should not be behind a NAT). The local operators should ensure that if the machine has usage limits or other restrictions (for example VMs on cloud services), those will not interfere with proper testbed operation.
- All gateway NDN routers will run the same operating system, probably an Ubuntu LTS release. The exact version will be determined by the tesbed management institution. Updates to the operating system will be managed by the NDN network operations team. The local operator at a site will be responsible for the initial operating system installation. Specific instructions for that installation will be made available.
- Suggested Hardware: There are no minimum hardware requirements for NDN routers; however, recent machines are both recommended and desirable.
- Suggested Location: Ideally, the NDN router should reside in a machine room in a rack; however, a PC on a safe, low traffic location, preferably connected to a UPS will also suffice.
- Suggested Network Connectivity: There is no minimum bandwidth requirement for NDN routers; however, higher network speeds are both recommended and desirable.
- Participating institutions may disconnect from the testbed upon giving appropriate (at least 24 hours) notice to the NDN testbed management institution. The same policy applies if the participating institution wishes to turn off the machine for maintenance and/or hardware upgrades. Early notification will allow the testbed management institution to take any actions necessary to prevent unnecessary disruption of service to the testbed.
- We strongly discourage and will not accept requests to join the NDN testbed if there is no intention to use it for productive research. Connecting to the testbed for the sake of being connected is a violation of the current policies.
- The NDN testbed management institution reserves the right to refuse or disconnect from the testbed any node that is found not to comply with the above policies, engages in abusive behavior, has non-responsive operators, and in general is deemed to either add no value or be a detriment to the general testbed operation.
- Transit and shared gateway connections are allowed. In other words, an existing institution may allow a new institution to join the NDN testbed through a connection facilitated by the existing institution. The new institution may connect via the existing institution’s gateway router, or via an internal node of the existing institution. To ensure smooth testbed operation, the existing institution will be asked to participate in addressing any issues that may arise with the new institution.
If the above policies cannot be met, we still encourage new institutions to contact the NDN team to discuss connection with the testbed. Connection approval lies solely with the NDN testbed management institution, but every effort will be made to accommodate connection requests.
As the testbed matures and other requirements become apparent, the policies above may change. When that happens, the policies will be announced on the operator mailing list.
For more information and to connect your site to the NDN testbed, contact [email protected].
Christos Papadopoulos, Colorado State
John DeHart, WUSTL