CC-NIE Integration: Advancing Science Through Next Generation SDN Networks

Grants & Projects

This University of Kentucky CC-NIE Integration project is focused on the ever-growing demands for improved cyber infrastructure to support

data-intensive scientific research. This project, a partnership led by UK Information Technology using technology and services from UK

Computer Science, the Laboratory for Advanced Networking, and the UK Center for Computational Sciences, provides software-defined network (SDN) infrastructure and control to UK researchers and affiliates. The project not only upgrades network components, it also provides a programmable network infrastructure tailored to the needs of researchers. Separation of UK research traffic from administrative and academic traffic enables research traffic to avoid the institutional policy constraints currently placed on all traffic.

The resulting SDN network will have a lasting impact on research projects spanning a wide range of areas including astrophysics, bio-medical, computer vision, visualization, and networking research. The most obvious improvement will be enhanced capacity for data-intensive research applications, with transmission speeds of up to 10 Gbps at the research access layer, 10 Gbps from the distribution layer to the UK research core, and 10+ Gbps from the research core to Internet2 and the regional networks (KyRON and KPEN). In addition, system administrators will be able to apply fine-grained control and prioritization of traffic across the campus backbone. It will also enable end-to-end user-defined provisioning of network access and capacity so that each research project can obtain precisely the performance it requires of the network. Finally, being integrated with the GENI network will enable researchers to access additional resources all across the GENI network.


-100G* Internet2 via UK regional research network

-100G* Remote data center for research computing expansion

-Bypass existing firewalls, distributions, and edge devices.

-Deployment of GENI Racks

-Deployment of OpenStack cluster for education

-Deployment of 40G Research network SDN switching core

-Deployment of 40/100G Research network SDN routing core.

-Deployment of 40G HPC Data Transfer Node (DTN)

-Deployment of 40G Network Address Translation (NAT) server

-Deployment of 40G Virtual Research Cluster (VRC)

-Consolidate replacement of 100Mb and 1Gb access layer with 1Gb access layer in 2.5 buildings ~1400x1Gb ports

Encyclopedia of Cloud Computing : Educational Applications of the Cloud


This chapter covers a broad range of cloud computing concepts, technologies, and challenges related to education. We will define educational applications as resources related to learning, encompassing stages of development from preschool through higher and continuing education. In the second section we describe the ways cloud technology is being adopted in education. We will cover the benefits and barriers of cloud adoption based on technology found in education. In the third section we describe cloud resources used in the direct instruction of students, front-office applications (user facing), and back office-applications (administrative). The final section will describe cloud computing in research.

Publisher Link

Bumgardner, V. K., Victor Marek, and Doyle Friskney. “Educational Applications of the Cloud.” Encyclopedia of Cloud Computing (2016): 505-516.

Collating time-series resource data for system-wide job profiling


Through the collection and association of discrete time-series resource metrics and workloads, we can both provide benchmark and intra-job resource collations, along with system-wide job profiling. Traditional RDBMSes are not designed to store and process long-term discrete time-series metrics and the commonly used resolution-reducing round robin databases (RRDB), make poor long-term sources of data for workload analytics. We implemented a system that employs “Big-data” (Hadoop/HBase) and other analytics (R) techniques and tools to store, process, and characterize HPC workloads. Using this system we have collected and processed over a 30 billion time-series metrics from existing short-term high-resolution (15-sec RRDB) sources, profiling over 200 thousand jobs across a wide spectrum of workloads. The system is currently in use at the University of Kentucky for better understanding of individual jobs and system-wide profiling as well as a strategic source of data for resource allocation and future acquisitions.

Published in: Network Operations and Management Symposium (NOMS), 2016 IEEE/IFIP
Date of Conference: 25-29 April 2016
Date Added to IEEE Xplore: 04 July 2016
ISBN Information:
Electronic ISSN: 2374-9709

INSPEC Accession Number: 16124063
DOI: 10.1109/NOMS.2016.7502958
Publisher: IEEE

Bumgardner, VK Cody, Victor W. Marek, and Ray L. Hyatt. “Collating time-series resource data for system-wide job profiling.” Network Operations and Management Symposium (NOMS), 2016 IEEE/IFIP. IEEE, 2016.

GENI Monitoring Alerts

Grants & Projects

GENI Monitoring Alerts

The GENI monitoring alerts system is based on the detection of events based on metric data that polled from remote systems. Raw data is published to a queueing system, which allows multiple complex event queries to operate on the same data stream in parallel. Output of complex queries can generate Nagios alerts, log results to a database, or both.

Poll to raw metric stream

As part of the polling process raw data is both recorded in a database and pushed to a queue. The queue serves as a fanout interface for a one-to-many raw metric subscription service.


In the previous figure P represents our polling agent, which publishes data to a queue exchange represented by X. Clients, designated as C1 and C2, subscribe to exchanges by binding their own queues to exchanges. In the example, data published by P is replicated by X to client queues amq.gen-RQ6.. for client C1 and amq.gen-As8… for client C2.

Stream query of metric stream

The publish/subscribe queuing system allows streams of raw metric data to be replicated between many processes in parallel. This allows us to instantiate one or more complex event processing engines CEPE per replicated data stream and one or more queries inside of each CEPE. We make use of the Esper CEPE.

Esper complex event processing engine

Esper allows us to analyze large volumes of incoming messages or events, regardless of whether incoming messages are historical or real-time in nature. Esper filters and analyzes events in various ways, and respond to conditions of interest. An example of the Esper CEPE architecture is shown in the figure below.


Simply, CEPE queries are pattern-based (matching) subscriptions describing a possible future event. If the described event occurs, a described output is emitted from the CEPE.

Esper query format

In a typical database we query existing data based on some declarative language. We can think of and Esper query like an upside down SQL, where if events occur in the future, results will be emitted. The Using the ESPER query language, EPL (similar to SQL) complex events can are described. The EPL language reference and examples can be found here: []

Consider the following EPL query:

select count(*) from MyEvent(somefield = 10).win:time(3 min) having count(*) >= 5

  • There exist a stream of events named MyEvent.
  • In the MyEvent stream there are events that contain a field named: somefield
  • In a 3 minute window, if somefield = 10 five or more times, emit data.

Just as traditional relational databases, and their related SQL queries, use specific data type operations based on column data types, data streams processed by Esper are defined by strongly typed object classes. In the previous EPL query the somefield field would have to defined as a numeric time in order for mathematical comparison to work.

GENI monitoring stream data format

For GENI Monitoring alerts, we use the LogTick class shown in the code block below:

public static class LogTick


        String source;

        String urn;

        String metric;

        long ts;

        double value;

        public LogTick(String source, String urn, String metric, long ts, double value)


            this.source = source;

            this.urn = urn;

            this.metric = metric;

            this.ts = ts;

            this.value = value;


        public String getSource() {return source;}

        public String getUrn() {return urn;}

        public String getMetric() {return metric;}

        public long getTs() {return ts;}

        public double getValue() {return value;}



        public String toString()


        return “source: ” + source + ” urn:” + urn + ” metric:” + metric + ” timestamp:” + ts + ” value:” + value;



Example GENI monitoring stream queries

Note how the following data types are used in the example queries.


        String source;

        String urn;

        String metric;

        long ts;

        double value;


There exist two types of queries:

Alert Queries: are used to send remote alerts to remote Nagios hosts. These queries require 5 explicitly defined values to be emitted by the query including, “nagiosserver”, “hostname”, “servicename”, alertlevel, and “alertmessage”. The function used to generate the payload sent to your Nagios server is shown below:

public void alert(String hostName, String serviceName, String alertLevel, String alertMessage)


        MessagePayload payload = new MessagePayloadBuilder()



            //.withServiceName(“Service Name”)





The following queries are examples of Alert Queries:

  • If metric gpo:is_available is set to 1 emit OK select ‘’ AS nagiosserver, urn AS hostname, metric AS servicename, ‘OK’ AS alertlevel, ‘Alert comes from rack ‘ || ‘ source:’ || source AS alertmessage from LogTick(metric=’gpo:is_available’) where value = 1
  • If metric gpo:is_available is set to 1 emit CRITICAL select ‘’ AS nagiosserver, urn AS hostname, metric AS servicename, ‘CRITICAL’ AS alertlevel, ‘Alert comes from rack ‘ || ‘ source:’ || source AS alertmessage from LogTick(metric=’gpo:is_available’) where value = 0
  • If a urn with the metric gpo:is_available is observed once, but not observed again for 60 min emit WARNING select ‘’ AS nagiosserver, a.urn AS hostname, a.metric AS servicename, ‘WARNING’ AS alertlevel, ‘Alert comes from monitoring system ‘ || ‘ source:’ || a.source AS alertmessage from pattern [ every a=LogTick(metric=’is_responsive’) -> (timer:interval(60 min)) and not LogTick(urn=a.urn) ] group by a

In addition to Alert Queries there are Report Queries. Report Queries do not provide external alerting, but don’t require a specific output format. The output of a Report Query will be stored in a database, which is accessible from the Monitoring site.

The following queries are examples of Report Queries:

  • Ping times greater than 10,000ms select * from LogTick(metric=’ping_rtt_ms’) where value > 10000.0
  • If a urn is seen and then not seen again for 60min select count(*) from pattern [ every a=LogTick -> (timer:interval(60 min)) and not LogTick(urn=a.urn) ] group by a

Creating stream queries

  1. Login to the GENI Monitoring site: []
  2. Click on the Alerting System under the GENI Reporting tab, as shown in the figure below.

  1. On the Alert page click on Build New Alert on the top right of the screen, shown in the figure below.

  1. You are now in the stream query builder page, shown in the figure below.
  1. On the stream query builder page, click on Query Node under Add Alert Node, shown in the figure below.
  1. In the query node fill in the Query Name and Query String fields. The query name field should describe your query and the query string should be a valid EPL query, which uses the LogTick class.
  1. Click on the left edge of your query node and connect your query node to the source node. The source node is the source of LogTick events, based on raw polling metrics. An example query is shown in the figure below.
  1. You must now provide a destination for the query output. On the stream query builder page, click on Destination Node under Add Alert Node, shown in the figure below.
  1. Using the dropdown box on your destination node select your query destination, then connect your destination node to your query node, much how you connected your query node to your source node.
  1. Once a source, query and destination have been configured, as shown in the figure below, click on Submit Alert on the Alert Building Tools toolbar.


*Image from RabbitMQ tutorial

**Image from Esper

Scalable hybrid stream and hadoop network analysis system


Collections of network traces have long been used in network traffic analysis. Flow analysis can be used in network anomaly discovery, intrusion detection and more generally, discovery of actionable events on the network. The data collected during processing may be also used for prediction and avoidance of traffic congestion, network capacity planning, and the development of software-defined networking rules. As network flow rates increase and new network technologies are introduced on existing hardware platforms, many organizations find themselves either technically or financially unable to generate, collect, and/or analyze network flow data. The continued rapid growth of network trace data, requires new methods of scalable data collection and analysis. We report on our deployment of a system designed and implemented at the University of Kentucky that supports analysis of network traffic across the enterprise. Our system addresses problems of scale in existing systems, by using distributed computing methodologies, and is based on a combination of stream and batch processing techniques. In addition to collection, stream processing using Storm is utilized to enrich the data stream with ephemeral environment data. Enriched stream-data is then used for event detection and near real-time flow analysis by an in-line complex event processor. Batch processing is performed by the Hadoop MapReduce framework, from data stored in HBase BigTable storage.

In benchmarks on our 10 node cluster, using actual network data, we were able to stream process over 315k flows/sec. In batch analysis were we able to process over 2.6M flows/sec with a storage compression ratio of 6.7:1.

Bumgardner, Vernon KC, and Victor W. Marek. “Scalable hybrid stream and hadoop network analysis system.” Proceedings of the 5th ACM/SPEC international conference on Performance engineering. ACM, 2014.