OSI 7 Layers

Layer 1: Physical Layer (Ethernet)

Layer 2: Data Link Layer

Layer 3: Network Layer (IP)

Layer 4: Transport Layer (TCP, UDP)

Layer 5: Session Layer (RPC)

Layer 6: Presentation Layer (encryption)

Layer 7: Application Layer (HTTP, FTP)

OpenFlow: Enabling Innovation in Campus Networks

OpenFlow is originally designed for research purposes. It is like a sandbox for the network, separating a part of the network traffic for testing new protocols while protecting other working traffic from being influenced.

We believe that OpenFlow is a pragmatic compromise: on one hand, it allows researchers to run experiments on hetero- geneous switches in a uniform way at line-rate and with high port-density; while on the other hand, vendors do not need to expose the internal workings of their switches.

The network has become so critical in our daily life that it is hard to apply any changes to the existing network architecture. It is even more challenging to test new protocols and research ideas since they accidentally influence other ongoing network traffics. This white paper aims at solving this problem by designing a virtualized programmable network for researchers to run experiments and test their ideas.

The idea of virtualized programmable network isn’t new, but the previous version GENI is too ambitious. It proposed a nationwide research facility, which may take years to be deployed. Compared to GENI, OpenFlow is more practical and focused. It focuses on a short-term question:

As researchers, how can we run experiments in our campus networks?

Based on this question, the author proposes 4 goals OpenFlow needs to achieve:

  1. Ameable to high-performance and low-cost implementations
  2. Capable of supporting a broad range of research
  3. Assured to isolate experimental traffic from production traffic
  4. Consistent with vendors’ need for closed platforms

1. High-Performance and Low-Cost Implementations

An OpenFlow Switch consists of at least three parts: a flow table, a secure channel, and an OpenFlow protocol. The controller uses OpenFlow protocol to communicate with the OpenFlow Switch through the secure channel, and the rules specified by the controller are stored in the flow table, which controls how to process each flow.

2. Support for a Broad Range of Research

The OpenFlow protocol allows researchers to specify detailed rules on how flows are processed.

3. Assurance to isolate Experimental Traffic from Production Traffic

OpenFlow-enabled switches support both OpenFlow features and normal Layer 2 and Layer 3 processing. Production traffic not specified in the flow table can be forwarded to the normal Layer 2 and Layer 3 pipeline of the switch.

4. Consistency with Vendors’ need for Closed Platforms




Weka APIs




Remove specified attributes (columns)


Valid options are:

 -R <index1,index2-index4,...>
  Specify list of columns to delete. First and last are valid
  indexes. (default none)

-V Invert matching sense (i.e. only keep specified columns)


public Instances trainCV(int numFolds, int numFold)

This function split the training dataset for cross-validation. It does not randomize the input dataset before splitting.


public Instances trainCV(int numFolds, int numFold, java.util.Random random)

This function only randomizes the dataset after splitting.

Save Dataset

 ArffSaver saver = new ArffSaver();
 saver.setFile(new File("./data/test.arff"));
 saver.setDestination(new File("./data/test.arff"));   // **not** necessary in 3.5.4 and later