@manual{ONF,
    title = {Open Network Foundation},
    note = "https://www.opennetworking.org/about/onf- overview",
}

@manual{Ryu,
    title = {Ryu controller},
    note = "https://osrg.github.io/ryu/",
}

@manual{ODL,
    title = {OpenDaylight controller},
    note = "https://www.opendaylight.org/",
}

@manual{ONOS,
    title = {Onos controller},
    note = "http://onosproject.org/",
}

@manual{Ostinato,
    title = {Ostinato, Network Traffic Generator and Analyzer},
    note = "http://ostinato.org/",
}

@manual{OVS_CVE_MPLS_buffer_overflow,
    title = {CVE-2016-2074: MPLS buffer overflow vulnerabilities in Open vSwitch},
    note = "http://openvswitch.org/pipermail/announce/2016-March/000082.html",
}

@article{OpenFlow,
    file = {:Users/aaronwang/Dropbox/SDN/openflow-spec-v1.3.3.pdf:pdf},
    pages = {1--164},
    title = {{OpenFlow Switch Specification}},
    volume = {3},
    year = {2013}
}

@manual{OFTest,
    title = {OFTest},
    note = "http://www.projectfloodlight.org/oftest/",
}

@manual{Ryu_cert,
    title = {Ryu certification},
    note = "https://osrg.github.io/ryu/certification.html",
}

@article{Spirent_whitepaper,
    author = {Spirent},
    file = {:Users/aaronwang/Library/Application Support/Mendeley Desktop/Downloaded/Paper - Unknown - OpenFlow Performance Testing.pdf:pdf},
    title = {{OpenFlow Performance Testing}},
    year = {2015},
}

@article{OFLOPS,
    abstract = {Recent efforts in software-defined networks, such as OpenFlow, give unprecedented access into the forwarding plane of networking equipment. When building a network based on OpenFlow however, one must take into account the performance characteristics of particular OpenFlow switch implementations. In this paper, we present OFLOPS, an open and generic software framework that permits the development of tests for OpenFlow-enabled switches, that measure the capabilities and bottlenecks between the forwarding engine of the switch and the remote control application. OFLOPS combines hardware instrumentation with an extensible software framework. We use OFLOPS to evaluate current OpenFlow switch implementations and make the following observations: (i) The switching performance of flows depends on applied actions and firmware. (ii) Current OpenFlow implementations differ substantially in flow updating rates as well as traffic monitoring capabilities. (iii) Accurate OpenFlow command completion can be observed only through the data plane. These observations are crucial for understanding the applicability of Open- Flow in the context of specific use-cases, which have requirements in terms of forwarding table consistency, flow setup latency, flow space granularity, packet modification types, and/or traffic monitoring abilities.},
    author = {Rotsos, Charalampos and Sarrar, Nadi and Uhlig, Steve and Sherwood, Rob and Moore, Andrew W.},
    doi = {10.1007/978-3-642-28537-0{\_}9},
    file = {:Users/aaronwang/Library/Application Support/Mendeley Desktop/Downloaded/Rotsos et al. - 2012 - OFLOPS An open framework for OpenFlow switch evaluation.pdf:pdf},
    isbn = {9783642285363},
    issn = {03029743},
    journal = {Lecture Notes in Computer Science (including subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics)},
    keywords = {switch},
    mendeley-tags = {switch},
    pages = {85--95},
    title = {{OFLOPS: An open framework for OpenFlow switch evaluation}},
    volume = {7192 LNCS},
    year = {2012}
}

@article{Bianco2010,
    abstract = {OpenFlow is an open standard that can be implemented in Ethernet switches, routers and wireless access points (AP). In the OpenFlow framework, packet forwarding (data plane) and routing decisions (control plane) run on different devices. OpenFlow switches are in charge of packet forwarding, whereas a controller set up switch forwarding table on a per-flow basis, to enable flow isolation and resource slicing. We focus on the data path and analyze the OpenFlow implementation in Linux based PCs. We compare OpenFlow switching, layer-2 Ethernet switching and layer-3 IP routing performance. Forwarding throughput and packet latency in underloaded and overloaded conditions are analyzed, with different traffic patterns. System scalability is analyzed using different forwarding table sizes, and fairness in resource distribution is measured.},
    author = {Bianco, Andrea and Birke, Robert and Giraudo, Luca and Palacin, Manuel},
    doi = {10.1109/ICC.2010.5502016},
    file = {:Users/aaronwang/Library/Application Support/Mendeley Desktop/Downloaded/Bianco et al. - 2010 - OpenFlow switching Data plane performance.pdf:pdf},
    isbn = {9781424464043},
    issn = {05361486},
    journal = {IEEE International Conference on Communications},
    keywords = {OpenFlow Switching: Data Plane Performance,switch},
    mendeley-tags = {switch},
    title = {{OpenFlow switching: Data plane performance}},
    year = {2010}
}
@inproceedings{Gelberger2013,
    abstract = {Software-Defined Networking (SDN) approaches were introduced as early as the mid-1990s, but just recently became a well-established industry standard. Many network architectures and systems adopted SDN, and vendors are choosing SDN as an alternative to the fixed, predefined, and inflexible protocol stack. SDN offers flexible, dynamic, and programmable functionality of network systems, as well as many other advantages such as centralized control, reduced complexity, better user experience, and a dramatic decrease in network systems and equipment costs. However, SDN characterization and capabilities, as well as workload of the network traffic that the SDN-based systems handle, determine the level of these advantages. Moreover, the enabled flexibility of SDN-based systems comes with a performance penalty. The design and capabilities of the underlying SDN infrastructure influence the performance of common network tasks, compared to a dedicated solution. In this paper we analyze two issues: a) the impact of SDN on raw performance (in terms of throughput and latency) under various workloads, and b) whether there is an inherent performance penalty for a complex, more functional, SDN infrastructure. Our results indicate that SDN does have a performance penalty, however, it is not necessarily related to the complexity level of the underlying SDN infrastructure.},
    author = {Gelberger, Alexander and Yemini, Niv and Giladi, Ran},
    booktitle = {Proceedings - IEEE Computer Society's Annual International Symposium on Modeling, Analysis, and Simulation of Computer and Telecommunications Systems, MASCOTS},
    doi = {10.1109/MASCOTS.2013.58},
    file = {:Users/aaronwang/Library/Application Support/Mendeley Desktop/Downloaded/Gelberger, Yemini, Giladi - 2013 - Performance analysis of Software-Defined Networking (SDN).pdf:pdf},
    isbn = {9780769551029},
    issn = {15267539},
    keywords = {switch},
    mendeley-tags = {switch},
    pages = {389--393},
    title = {{Performance analysis of Software-Defined Networking (SDN)}},
    year = {2013}
}
@article{SDN_Flow_tables,
    abstract = {Sourcing finished products and raw materials from China can be a challenging experience, replete with risks and obstacles at every turn. But the downside of ignoring China as a supply chain source far outweighs any of the potential pitfalls. New research and on-the-ground observations can help companies source more effectively in the industrial powerhouse that China has become.},
    author = {Handfield, Robert B. and Mccormack, Kevin},
    doi = {10.1007/978-3-319-15509-8},
    file = {:Users/aaronwang/Dropbox/SDN/WhatYouNeedtoKnowAboutSDNFlowTables.pdf:pdf},
    isbn = {9780309161398},
    journal = {Supply Chain Management Review},
    number = {September},
    pages = {29--36},
    title = {{What You Need to Know About SDN Flow Tables}},
    year = {2015}
}
@article{Jarschel2011,
    abstract = {The OpenFlow concept of flow-based forwarding and separation of the control plane from the data plane provides a new flexibility in network innovation. While initially used solely in the research domain, OpenFlow is now finding its way into commercial applications. However, this creates new challenges, as questions of OpenFlow scalability and performance have not yet been answered. This paper is a first step towards that goal. Based on measurements of switching times of current OpenFlow hardware, we derive a basic model for the forwarding speed and blocking probability of an OpenFlow switch combined with an OpenFlow controller and validate it using a simulation. This model can be used to estimate the packet sojourn time and the probability of lost packets in such a system and can give hints to developers and researchers on questions how an OpenFlow architecture will perform given certain parameters.},
    author = {Jarschel, Michael and Oechsner, Simon and Schlosser, Daniel and Pries, Rastin and Goll, Sebastian and Tran-Gia, Phuoc},
    file = {:Users/aaronwang/Library/Application Support/Mendeley Desktop/Downloaded/Jarschel et al. - 2011 - Modeling and performance evaluation of an OpenFlow architecture.pdf:pdf},
    isbn = {978-1-4577-1187-9},
    issn = {07437315},
    journal = {2011 23rd International Teletraffic Congress (ITC)},
    keywords = {OpenFlow,performance evaluation,switch},
    mendeley-tags = {switch},
    pages = {1--7},
    title = {{Modeling and performance evaluation of an OpenFlow architecture}},
    year = {2011}
}
@article{OFLOPS-Turbo,
    abstract = {The heterogeneity barrier breakthrough achieved by the OpenFlow protocol is currently paced by the variability in performance semantics among network devices, which reduces the ability of applications to take complete advantage of programmable control. As a result, control applications remain conservative on performance requirements in order to be generalizable and trade performance for explicit state consistency in order to support varying performance behaviours. In this paper we argue that network control must be optimized towards network device capabilities and network managers and application developers must perform informed design decision using accurate switch performance profiles. This becomes highly critical for modern OpenFlow-enabled 10 GbE optical switches which significantly elevate switch performance requirements. We present OFLOPS-Turbo, the integration of the OFLOPS switch evaluation platform, with the OSNT platform, a hardware-accelerated traffic generation and capture system supporting lossless 10 GbE functionality. Using OFLOPS-Turbo, we conduct an evaluation of flow table manipulation capabilities in a representative collection of 10 GbE production OpenFlow switch devices and interpret the evolution of OpenFlow support by comparison with historical data.},
    author = {Rotsos, Charalampos and Antichi, Gianni and Bruyere, Marc and Owezarski, Philippe and Moore, Andrew W.},
    doi = {10.1109/ICC.2015.7249210},
    file = {:Users/aaronwang/Desktop/OFLOPS-turbo.pdf:pdf},
    isbn = {9781467364324},
    issn = {15503607},
    journal = {IEEE International Conference on Communications},
    keywords = {High Performance,NetFPGA,Open-Source,OpenFlow,SDN,Testing},
    pages = {5571--5576},
    title = {{OFLOPS-Turbo: Testing the next-generation OpenFlow switch}},
    year = {2015}
}
@article{Tanyingyong2010,
    abstract = {In this paper, we propose an architectural design to improve lookup performance of OpenFlow switching in Linux using a standard commodity network interface card based on the Intel 82599 Gigabit Ethernet controller. We describe our design and report our preliminary results that show packet switching throughput increasing up to 25 percent compared to the throughput of regular software-based OpenFlow switching.},
    author = {Tanyingyong, V. and Hidell, M. and Sjödin, P.},
    doi = {10.1145/1872007.1872023},
    file = {:Users/aaronwang/Library/Application Support/Mendeley Desktop/Downloaded/Tanyingyong, Hidell, Sjödin - 2010 - Improving PC-based OpenFlow switching performance.pdf:pdf},
    isbn = {978-1-4503-0379-8},
    journal = {Architectures for Networking and Communications Systems (ANCS), 2010 ACM/IEEE Symposium on},
    keywords = {Flow-based switching,OpenFlow,Performance Evaluation,switch},
    mendeley-tags = {switch},
    pages = {8--9},
    title = {{Improving PC-based OpenFlow switching performance}},
    year = {2010}
}

@article{Kuzniar2012,
abstract = {Software-defined networking and OpenFlow in particular enable independent development of network devices and software that controls them. Such separation of concerns eases the introduction of new network functionality; however, it leads to distributed responsibility for bugs. Despite the common interface, separate development entails the need to test an integrated network before deployment. In this work-in-progress paper, we identify the challenges of creating an environment that simplifies and systematically conducts such tests. We dis- cuss optimizations required for efficient and reliable OpenFlow switch black-box testing and present a possible approach to address other challenges. In our preliminary prototype, we combine systematic state-space exploration techniques with real switches execution to explore an integrated network behavior. Our initial results show that such methods help detect previously unrevealed inconsistencies in the network.},
author = {Ku{\'{z}}niar, Maciej and Canini, Marco and Kosti{\'{c}}, Dejan},
doi = {10.1109/EWSDN.2012.21},
file = {:Users/aaronwang/Dropbox/SDN/OFTEN.pdf:pdf},
isbn = {9780769548708},
journal = {Proceedings - European Workshop on Software Defined Networks, EWSDN 2012},
mendeley-groups = {Proposal,OFBench},
pages = {54--60},
title = {{OFTEN testing OpenFlow networks}},
year = {2012}
}


@article{Phemius2013,
abstract = {In the OpenFlow framework, packet forwarding (data plane) and routing decisions (control plane) run on different devices. OpenFlow switches are in charge of packet forwarding, whereas a Controller, which can be situated very far from a networking point of view from the switches its manages, sets up switch forwarding tables on a per-flow basis. The connection between a switch and its Controller is thus of primary importance for the performances of the network. In this paper, we study the impact of the latency between an OpenFlow switch and its Controller. We show that UDP and TCP have different effects depending on the available bandwidth on the control link. Bandwidth arbitrates how many flows the Controller can process, as well as the loss rate if the system is under heavy load, while latency drives the overall behavior of the network, that is the time to reach its full capacity. Finally, we propose solutions to mitigate the phenomenons we outline.},
author = {Phemius, K. and Bouet, M.},
file = {:Users/aaronwang/Dropbox/SDN/OpenFlow- Why Latency Does Matter.pdf:pdf},
isbn = {9783901882500},
keywords = {Bandwidth,Hardware,OpenFlow framework,OpenFlow switch,OpenFlow switches,Process control,Protocols,Switches,TCP,Throughput,UDP,controller,latency,packet forwarding,routing decisions,switch forwarding tables,telecommunication network routing,transport protocols},
mendeley-groups = {Proposal,OFBench},
pages = {680--683},
title = {{OpenFlow: Why latency does matter}},
year = {2013}
}

@article{Huang2013,
abstract = {Software defined networks (SDNs) depart from traditional network architectures by explicitly allowing third-party software access to the network's control plane. Thus, SDN protocols such as OpenFlow give network operators the ability to innovate by authoring or buying network controller software independent of the hardware. However, this split design can make planning and designing large SDNs even more challenging than traditional networks. While existing network emulators allow operators to ascertain the behavior of traditional networks when subjected to a given workload, we find that current approaches fail to account for significant vendor-specific artifacts in the SDN switch control path. We benchmark OpenFlow-enabled switches from three vendors and illustrate how differences in their implementation dramatically impact latency and throughput. We present a measurement methodology and emulator extension to reproduce these control-path performance artifacts, restoring the fidelity of emulation.},
author = {Huang, Danny Yuxing and Yocum, Kenneth and Snoeren, Alex C.},
doi = {10.1145/2491185.2491188},
file = {:Users/aaronwang/Desktop/High-Fidelity Switch Models for Software-Defined Network Emulation.pdf:pdf},
isbn = {9781450321785},
journal = {Proceedings of the second ACM SIGCOMM workshop on Hot topics in software defined networking - HotSDN '13},
keywords = {modeling,openflow,sdn,software-defined networking},
mendeley-groups = {Proposal,OFBench},
pages = {43},
title = {{High-fidelity switch models for software-defined network emulation}},
year = {2013}
}

@inproceedings{Azodolmolky2013,
abstract = {Since the introduction of software-defined networking (SDN), scalability has been a major concern. There are different approaches to address this issue, and most of them can be addressed without losing the benefits of SDN. SDN provides a level of flexibility that can accommodate network programming and management at scale. In this work we present the recent approaches, which are proposed to address scalability issue of SDN deployment. We particularly select a hierarchical approach for our performance evaluation study. A mathematical framework based on network calculus is presented and the performance of the selected scalable SDN deployment in terms of upper bound of event processing and buffer sizing of the root SDN controller is reported.},
author = {Azodolmolky, Siamak and Wieder, Philipp and Yahyapour, Ramin},
booktitle = {Proceedings - 2013 2nd European Workshop on Software Defined Networks, EWSDN 2013},
doi = {10.1109/EWSDN.2013.18},
file = {:Users/aaronwang/Library/Application Support/Mendeley Desktop/Downloaded/Azodolmolky, Wieder, Yahyapour - 2013 - Performance evaluation of a scalable software-defined networking deployment.pdf:pdf},
isbn = {978-1-4799-2433-2},
keywords = {Buffer Sizing,Delay Bound,Hierarchical controller,Network Calculus,OpenFlow,Scalable SDN,controller},
mendeley-groups = {Proposal,OFBench},
mendeley-tags = {controller},
pages = {68--74},
title = {{Performance evaluation of a scalable software-defined networking deployment}},
year = {2013}
}

@article{Emmerich2014,
abstract = {Virtual switches, like Open vSwitch, have emerged as an important part of cloud networking architectures. They connect interfaces of virtual machines and establish the connec- tion to the outer network via physical network interface cards. Today, all important cloud frameworks support Open vSwitch as the default virtual switch. However, general understanding about the performance implications of Open vSwitch in different usage scenarios is missing. In this work we provide insights into the performance properties by systematically conducting mea- surements in virtual switching setups. We present quantitative and qualitative performance results of Open vSwitch in scenarios involving physical and virtual network interfaces.},
author = {Emmerich, Paul and Raumer, Daniel and Wohlfart, Florian and Carle, Georg},
doi = {10.1109/CloudNet.2014.6968979},
file = {:Users/aaronwang/Dropbox/SDN/Performance Characteristics of Virtual Switching.pdf:pdf},
isbn = {9781479927302},
journal = {2014 IEEE 3rd International Conference on Cloud Networking, CloudNet 2014},
keywords = {cloud,performance characterization,performance evaluation,platform virtualization,virtual switching},
mendeley-groups = {Proposal,OFBench},
pages = {120--125},
title = {{Performance characteristics of virtual switching}},
year = {2014}
}
