Skip to content

home

Jump to bottom
Dave Stern edited this page Jan 23, 2018 · 1 revision

The Problem

How does the United States Government (USG)/ Department of Defense (DoD) achieve reliable and guaranteed on demand (i.e. <=3 minutes) network connectivity between any two commercial endpoints worldwide. These endpoints are not only traditional carrier demarcation points, but will include non-traditional locations on college campuses, commercial datacenters, commercial carriers locations at conference centers, business parks, malls, offices, hotel rooms, etc., “Any to Any” on demand and reliable.

How we got here

This effort began as a concept between Level3 Communications and the Defense Information Systems Agency (DISA) as a follow on to internal efforts to automate the DISA core. This concept morphed into a Cooperative Research and Development Agreement between Level3 (now CenturyLink) and DISA to promote this technology. Collaboratively this effort started by connecting a DISA facility in Maryland to various datacenter locations throughout the world, on demand. Level3 developed an Application Program Interface (API) and installed networking automation equipment that allowed a DISA orchestrator to communicate requirements and setup information. Likewise, DISA also automated the configuration of it's communication equipment at the Maryland facility to completely automate the setup of the connectivity.

Envisioned Uses

RTFN is a dual use technology being developed that benefits national interests for civilian and defense needs. For humanitarian operations, this technology can serve the world by integrating the best network, compute, storage, and security capabilities that the world has to offer. This technology can serve as the way to integrate disparate systems/capabilities in a PRIVATE and MANAGED network to enable operations that require discretion due to the privacy and security requirements. Also, this technology could serve to post publicly releasable schedules such as seaport and airport relief deliveries while restricting access to securely edit and maintain that information on a multi-national basis. This reduced and/or removes the equipment needed to secure these types of networks from the entire Internet. Likewise, when you consider the military supporting various operations from forward locations, this capability will allow the the DOD to quickly establish virtual networks through commercial carriers. These private virtual networks may be more resilient than other network connection technologies in use today.

Technical Background/Components

Front End Components

Browser Code:

  1. HTML
  2. Javascript (JS)
  3. JS Frameworks (and CSS): leaflet-src, jquery-ui-themes-1.12.1, font-awesome-4.7.0, bootstrap-3.3.7-dist, leaflet-control-window-master, jquery-3.2.1.js, jquery-ui-1.12.1

UI-related Back End Components

  1. (Map Server) Open Street Map Server using ubuntu 14.04 "Trusty Tahr"
  2. (Web Server) Apache2 2.4.20-1~ubuntu14.04.2amd64 (Web Server) using ubuntu 14.04 "Trusty Tahr" [note for this project both the Map Server and the Web Server were placed on the same OS with 420GB storage/11MiB memory]
  3. Python Web Server CGI Scripts
  4. Hooks/STDOUT for back-end script visualization to CLI

CLI Interface and Python API/Device Integration Components

  1. Python Base utilizes the following packages

    • certifi (2017.11.5)
    • chardet (3.0.4)
    • ecdsa (0.13)
    • enum34 (1.1.3)
    • idna (2.6)
    • ipaddress (1.0.9)
    • lxml (3.4.4)
    • ncclient (0.5.3)
    • paramiko (1.15.2)
    • pip (9.0.1)
    • protobuf (3.0.0b2.post2)
    • pyang (1.6)
    • pyasn1 (0.2.2)
    • pycparser (2.17)
    • pycrypto (2.6.1)
    • requests (2.18.4)
    • setuptools (28.8.0)
    • six (1.10.0)
    • Twisted (16.1.1)
    • urllib3 (1.22)
    • wheel (0.29.0)
    • ydk (0.5.2)
    • ydk-models-cisco-ios-xr (6.1.2)
    • ydk-models-ietf (0.1.1)
    • ydk-models-openconfig (0.1.1)
    • zope.interface (4.3.3)

  2. Private OH Channel to Commercial Carrier (VLAN at Carrier Demarc)
    For this demonstration we implemented the first Department of Defense connection to a commercial carrier directly through a circuit provisioned for operational use. An Ethernet Virtual Circuit (EVC) is configured to the commercial provider (in this case it is a VLAN on our UNI connection). The carrier privately forwards the traffic originating from this VLAN to their orchestration system. Responses from the carrier orchestration system arrive on the same VLAN. This circuit is static and is not provisioned dynamically like the rest of the EVC's. The code protects against disrupting the local VLAN by preventing usage of that VLAN or deletion of that VLAN. BGP for this connection was installed manually and is outside the scope of this project although future versions will automate this form of onboarding of carriers.

    The overall intent is to build diversity for control through the carrier by having multiple orchestration connections. If the Military and Government allocated very small EVC's of all connections utilized, that provides the ability to communicate with the provider through as many connections as the service provider has with the Government. For some providers this is in the thousands.

  3. Python Code to Interface Commercial Carriers (API)

  4. Python Code to Interface Local Network Devices (Provider Edge)

  5. Python Code to Interface Commercial Connections into Datacenters

DataCenter Interfacing

  1. Overhead/Management
  2. Dataplanes
Clone this wiki locally