OF-ICN: OpenFlow-based Control Plane For Information-Centric Networking
OF-ICN:OpenFlow-based control plane forInformation-Centric NetworkingbyRajendran Jeeva, B EDissertationPresented to theUniversity of Dublin, Trinity Collegein fulfillmentof the requirementsfor the Degree ofMaster of Science in Computer ScienceUniversity of Dublin, Trinity CollegeSeptember 2016
DeclarationI, the undersigned, declare that this work has not previously been submitted as anexercise for a degree at this, or any other University, and that unless otherwise stated, ismy own work.Rajendran JeevaAugust 31, 2016
Permission to Lend and/or CopyI, the undersigned, agree that Trinity College Library may lend or copy this thesisupon request.Rajendran JeevaAugust 31, 2016
Dissertation SummarySoftware-Defined Networking(SDN) is a networking architecture, that is proposed todecouple the complex control functions out of the network switching elements and forma separate control layer. Thus, the infrastructure in network elements can carry out lesscomplex forwarding operations and the control layer can programme this infrastructure,based on the control policies directed by the network applications. OpenFlow is an SDNapproach, that provides a centralised controller for the underlying OpenFlow switches.OpenFlow switches are equipped with flow tables, that can be managed by the controller through an interface,OpenFlow protocol. OpenFlow yields a lot of benefits to thenetwork, including, a global view of the network for better network control, flow-basedtraffic control, clear separation between the infrastructure and the control layer for easyconversion of business needs into low-level instructions and proactive management decisions. Information-Centric Networking(ICN) is a future internet architecture aims to shiftthe internet architecture from ’host-centric’ to ’content-centric’, by keeping the contentas the first primitive in network communication, instead of addressing the end-points.ICN is gaining a lot of interest from the industry and academic research due to its abilityto solve a number of performance issues, that are faced by today’s Internet due to theenormous increase in the amount of data being handled on the Internet. ICN providesa number of benefits, including, mobility, secured contents, improved content availabilityand multicast communication. Recently, researchers commenced the idea of integratingOpenFlow and ICN in order to practice the benefits of one over the other. There aresome thoughts in literature to integrate OpenFlow and ICN, without modifying any ofthe architectures under consideration. They involve workarounds and plugins, that needa lot of efforts and fail to provide a clean state integration of OpenFlow and ICN. Onthe other hand, a number of studies tried to extend OpenFlow to some extent, to enableICN features, but they lack in the amount of ICN functionalities that are supported andiv
the scope of the extensions was minimal. Most of the studies remain conceptual. Thisdissertation aimed to study the potential of OpenFlow to support ICN, by creating anOpenFlow-based control plane for the ICN network. This is achieved by designing an integration solution ’OF-ICN’, by extending the necessary OpenFlow elements: OpenFlowswitch, OpenFlow controller and OpenFlow protocol, with the ICN functionalities andICN data structures. OF-ICN is implemented using an open source Python OpenFlowcontroller, POX. The OpenFlow switch component provided by POX is extended to include ICN-related data structures: Forwarding Information Base, Pending Interest Tableand Content Store. Similarly, the OpenFlow controller component is extended with thename-based routing database and a cache to store contents. POX’s OpenFlow library ismodified to introduce new messages, actions and events, to be used between the switchand the controller. The implementation of OF-ICN is evaluated by benchmarking theICN functionalities supported by it and also by comparing its behaviour with a numberof existing ICN implementations. The results show that, with the necessary modificationsto the underlying elements and library, a clean state integration between OpenFlow andICN can be achieved and, OpenFlow can provide a control plane to manage the underlyingICN-enabled network. In addition to providing an experimental solution for integratingOpenFlow and ICN, this dissertation has also contributed towards a complete analysis ofexisting literature towards combining OpenFlow and ICN and reported the gaps identifiedin them. It also ensured to utilise the generic ICN architecture which can be adapted toany specific ICN implementation. A modularized code is produced out of this dissertation, which can be separated into modules and plugged into a relevant codebase. Thisstudy has identified the ICN naming scheme, scalability and security as future researchdirections over the proposed approach.v
AcknowledgmentsI would like to take this opportunity to thank my supervisor, Dr. Stefan Weber, for hisexcellent guidance and motivation throughout the dissertation. I would also like to extendmy thanks to my mum, who always holds me in my ups and downs. Many thanks to Nina,for her patience and continuous support.Rajendran JeevaUniversity of Dublin, Trinity CollegeSeptember 2016vi
OF-ICN:OpenFlow-based control plane forInformation-Centric NetworkingRajendran JeevaMSc in Computer Science (Networks and Distributed Systems)University of Dublin, Trinity College, 2016Supervisor: Weber StefanOpenFlow is a Software-Defined Networking (SDN) approach, that is used to separate thedata plane and the control plane of a network. This is achieved by defining and separatingthe network communication into different flows and by controlling the paths of these flowsusing OpenFlow. The work on the OpenFlow protocol currently focuses and relies onIP-based networking. Information-Centric Networking (ICN) is an alternative Internetarchitecture, that provides network communications based on the named contents insteadof addresses as in current Internet architecture. However, current ICN approaches lackthe definition of a control plane and current OpenFlow specifications do not support thecontrol of ICN flow by default. Therefore, this study analyses the potential of OpenFlowin supporting ICN and tries to port ICN functionalities in OpenFlow by modifying andextending OpenFlow components; switch, controller and the protocol. The results fromthis study reveal that, upon making necessary modifications to the underlying protocol,OpenFlow can successfully support ICN functionalities by making forwarding and cachingdecisions for ICN flows in the network.vii
ContentsAcknowledgmentsviAbstractviiList of TablesxivList of FiguresxvChapter 1 Introduction1.11Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21.1.1SDN and OpenFlow for ’Today’ . . . . . . . . . . . . . . . . . . . .21.1.2ICN for ’Tomorrow’ . . . . . . . . . . . . . . . . . . . . . . . . . . .51.2Project Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .71.3Literature Synopsis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .81.4Project Aims . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .91.5Project Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .91.6Project Contribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.7Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11Chapter 2 State of Art2.114On Information-Centric Network . . . . . . . . . . . . . . . . . . . . . . . 152.1.1NDN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.1.2NFD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16viii
2.22.32.42.52.1.3NLSR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.1.4CCNx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.1.5CONET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.1.6An ICN node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.1.7Expressing the interest . . . . . . . . . . . . . . . . . . . . . . . . . 182.1.8Bi-directional communication . . . . . . . . . . . . . . . . . . . . . 192.1.9Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20On OpenFlow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.2.1OpenFlow software switches . . . . . . . . . . . . . . . . . . . . . . 222.2.2Controller implementations . . . . . . . . . . . . . . . . . . . . . . 232.2.3Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25On functional similarities and variations . . . . . . . . . . . . . . . . . . . 262.3.1On packet format . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262.3.2On matching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282.3.3On forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282.3.4On caching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30On initiatives from industry to integrate OpenFlow and ICN . . . . . . . . 302.4.1OFELIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312.4.2ALIEN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31On non-extension approaches . . . . . . . . . . . . . . . . . . . . . . . . . 322.5.1Short term OFELIA approach . . . . . . . . . . . . . . . . . . . . . 332.5.2Wrapper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342.5.3SDN-NDNFlow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342.5.4Fixed identifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342.5.5Hierarchical hashing . . . . . . . . . . . . . . . . . . . . . . . . . . 352.5.6Service-based overlay approaches . . . . . . . . . . . . . . . . . . . 352.5.7CoLoR based controller . . . . . . . . . . . . . . . . . . . . . . . . . 362.5.8Cache-based approaches . . . . . . . . . . . . . . . . . . . . . . . . 37ix
2.5.9CRoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372.5.10 Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382.5.11 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392.6On extension based approaches . . . . . . . . . . . . . . . . . . . . . . . . 402.6.1Metadata extraction . . . . . . . . . . . . . . . . . . . . . . . . . . 422.6.2Long term OFELIA approach . . . . . . . . . . . . . . . . . . . . . 422.6.3Vendor messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432.6.4Cache improvements . . . . . . . . . . . . . . . . . . . . . . . . . . 432.6.5Network-level interest aggregation . . . . . . . . . . . . . . . . . . . 442.6.6A view on the switch . . . . . . . . . . . . . . . . . . . . . . . . . . 452.6.7Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45Chapter 3 Problem Formulation483.1Abstracted view of the solution . . . . . . . . . . . . . . . . . . . . . . . . 483.2Difference from existing approaches . . . . . . . . . . . . . . . . . . . . . . 493.3Targets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503.4Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513.5Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53Chapter 4 Design544.1Functional architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544.2Switch design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554.34.2.1Forwarding Information Base . . . . . . . . . . . . . . . . . . . . . 564.2.2Pending Interest Table . . . . . . . . . . . . . . . . . . . . . . . . . 564.2.3Content Store . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574.2.4Face . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584.2.5Extended messages . . . . . . . . . . . . . . . . . . . . . . . . . . . 584.2.6Extended actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60Controller design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62x
4.3.1Routing database . . . . . . . . . . . . . . . . . . . . . . . . . . . . 624.3.2Controller cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 634.3.3Extended messages . . . . . . . . . . . . . . . . . . . . . . . . . . . 644.4Packet design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 674.5Reactive processing algorithm . . . . . . . . . . . . . . . . . . . . . . . . . 684.6Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71Chapter 5 Implementation735.1Technical architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 735.2POX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 755.2.15.3Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75Test environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 765.3.1Logical entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 785.4Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 795.5Raw ethernet frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 815.6Threads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 825.7Table data structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 835.8Pipeline processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 865.8.15.9OFP MATCH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95OpenFlow library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 975.9.1Adding a message . . . . . . . . . . . . . . . . . . . . . . . . . . . . 975.9.2Binary encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 995.9.3Adding an action . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1015.9.4Adding an event and event handler . . . . . . . . . . . . . . . . . . 1025.10 Source code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1045.11 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105Chapter 6 Evaluation and Discussion6.1108Categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109xi
6.2Category 1 : ICN functionalities over OpenFlow . . . . . . . . . . . . . . . 1096.2.1Labeling content ’vs’ end to end addressing. . . . . . . . . . . . . 1096.2.2Requests aggregation . . . . . . . . . . . . . . . . . . . . . . . . . . 1106.2.3Multicasting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1116.2.4Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1126.2.5Compatibility with IP-packets . . . . . . . . . . . . . . . . . . . . . 1146.2.6Flow rule based advantages . . . . . . . . . . . . . . . . . . . . . . 1146.2.7In-network caching . . . . . . . . . . . . . . . . . . . . . . . . . . . 1166.2.8Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1196.2.9Transport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1196.2.10 Multiple tables support . . . . . . . . . . . . . . . . . . . . . . . . . 1216.36.4Routing based operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1226.3.1Forward-by-name . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1226.3.2FIB management . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122Content based operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1256.4.1Interest and Data forwarding . . . . . . . . . . . . . . . . . . . . . 1256.4.2Caching decisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1256.4.3Caching notifications . . . . . . . . . . . . . . . . . . . . . . . . . . 1296.4.4Proactive caching . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1296.4.5Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1306.5Category 2 : Preserve OpenFlow functionalities . . . . . . . . . . . . . . . 1306.6Category 3 : Implementation level verifications6.7Category 4 : Compare with existing ICN implementations . . . . . . . . . 1346.8. . . . . . . . . . . . . . . 1336.7.1CCNx - CCNPing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1346.7.2Mini-CCNx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140xii
Chapter 7 Conclusions1437.1Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1447.2Future works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1467.3Final remarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148Appendix A Abbreviations149Appendix B Switch and Controller use cases150B.1 Switch use cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150B.2 Controller use cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150Bibliography153xiii
List of Tables5.1OF-ICN Ethernet frame structure . . . . . . . . . . . . . . . . . . . . . . . 825.2OF-ICN switch state . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 876.1Evaluating the presence of content name in OF-ICN . . . . . . . . . . . . . 1106.2Evaluating request aggregation procedure . . . . . . . . . . . . . . . . . . . 1126.3Evaluating OF-ICN multicasting functionality . . . . . . . . . . . . . . . . 1136.4Evaluating the compatibility of OF-ICN with both IP and ICN packets . . 1156.5Evaluating the time difference between a controller flow and a flow basedon the flow rule in switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1176.6Evaluating the time difference between a cache flow and cache-less flow . . 1186.7Evaluating flow balancing with duplicate data packets . . . . . . . . . . . . 1206.8Evaluating ’Forward-by-name’ operation . . . . . . . . . . . . . . . . . . . 1236.9Evaluating FIB management when the switch’s FIB is full . . . . . . . . . 1246.10 Evaluating the interest and data forwarding process by OF-ICN . . . . . . 1266.11 Evaluating OF-ICN behaviour when the switch’s cache is full . . . . . . . . 1286.12 Evaluating statistics update from switch to controller . . . . . . . . . . . . 1316.13 Functional Test Cases used to evaluate OF-ICN features . . . . . . . . . . 142B.1 Switch use cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151B.2 Controller use cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152xiv
List of Figures1.1Comparison between a closed switch and SDN architecture. . . . . . . .32.1An ICN node and its elements . . . . . . . . . . . . . . . . . . . . . . . . . 192.2Relation between SDN and OpenFlow [1] . . . . . . . . . . . . . . . . . . . 222.3Non-extension approaches on OpenFlow and ICN integration - Timelinemap from 2012 to 2016 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322.4Extension based approaches on OpenFlow and ICN integration - Timelinemap from 2012 to 2016 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413.1OF-ICN : Abstracted view of the proposed solution . . . . . . . . . . . . . 493.2Difference between existing approaches and OF-ICN . . . . . . . . . . . . . 504.1Functional architecture : OF-ICN design components . . . . . . . . . . . . 554.2FIB structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564.3PIT structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574.4Content Store structure4.5Structure of controller routing database . . . . . . . . . . . . . . . . . . . . 634.6Structure of controller cache . . . . . . . . . . . . . . . . . . . . . . . . . . 644.7OF-ICN packet structures . . . . . . . . . . . . . . . . . . . . . . . . . . . 684.8OF-ICN reactive processing sequence . . . . . . . . . . . . . . . . . . . . . 685.1Implementation Architecture - Switch (Left side) and Controller (Right. . . . . . . . . . . . . . . . . . . . . . . . . . . . 58side) components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74xv
5.2Implementation of connection between the components in OF-ICN . . . . . 805.3Interest processing by OF-ICN switch . . . . . . . . . . . . . . . . . . . . . 895.4Data processing by OF-ICN switch . . . . . . . . . . . . . . . . . . . . . . 936.1Labeling content : Snapshot from Wireshark showing the content name inthe packet and the packet is not addressed with the end-point IP address . 1116.2Evaluating request aggregation : The faces that requested for the samecontent are aggregated in a list in PIT . . . . . . . . . . . . . . . . . . . . 1116.3In-network caching : The time taken to receive a content from a cache islesser than the time taken to receive it from the end-point producer . . . . 1166.4Security : New OpenFlow messages are encoded in binary format . . . . . 1196.5ICN-based multiple tables in OF-ICN switch: CS, PIT, FIB . . . . . . . . 1216.6Evaluation of Interest processing by OF-ICN switch. Procedure in Table6.10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1276.7OF-ICN switch clearing the cache when it receives CLEAR CS messagefrom the controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1276.8OF-ICN and CCNPing comparison : Snapshot from CCNPing showing theRTT for multiple pings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1356.9OF-ICN and CCNPing comparison : Snapshot from OF-ICN showing theRTT for multiple interests from the same host . . . . . . . . . . . . . . . . 1366.10 Graph comparing the RTT between CCNPing and OF-ICN for three subsequent requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1366.11 OF-ICN and Mini-CCNx comparison : Topology used for the experiment . 1376.12 OF-ICN and Mini-CCNx comparison : Scenario where all intermediateswitches have enough forwarding details for a content. Mini-CCNx receivescontent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138xvi
6.13 OF-ICN and Mini-CCNx comparison : Scenario where all intermediateswitches have enough forwarding details for a content. OF-ICN host receives content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1386.14 Graph comparing the RTT between Mini-CCNx and OF-ICN for threesubsequent requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1396.15 OF-ICN and Mini-CCNx comparison : Scenario where some intermediateswitches have less forwarding details. Mini-CCNx times out. . . . . . . . 1406.16 OF-ICN and Mini-CCNx comparison : Scenario where some intermediateswitches have less forwarding details. OF-ICN host receives content . . . . 140xvii
Dissertation MapThis dissertation is divided into following chapters: Chapter 1 - This chapter introduces the reader to the motivation for this study. Italso lists some background concepts and terminologies that are used in the remainingchapters of the dissertation Chapter 2 - This chapter presents the past research and current on-going researchactivities in OpenFlow and ICN, giving particular attention to their integration.The research works are categorized into major sections that are addressed by thisdissertation Chapter 3 - This chapter compares the architectural differences between OpenFlow and ICN and formulates a solution, ’OF-ICN’, for the gap in OpenFlow extension, which the previous studies failed to address Chapter 4 - This chapter puts forward the architectural design of ICN enabledOpenFlow switch and control plane, by quoting the suggested extensions for theOpenFlow, in terms of new messages and actions Chapter 5 - This chapter shows the implementation details of OF-ICN and briefsthe technologies used for the implementation Chapter 6 - This chapter evaluates the approach of OF-ICN, using the implemented experiment and comparing it with existing ICN prototypes. It also ensuresthat OF-ICN provides essential ICN functionalities Chapter 7 - This chapter derives the conclusion based on the evaluation resultsshown in the previous chapter and also sets the future research directionsxviii
Chapter 1IntroductionSoftware-Defined Networking(SDN) is a network architecture paradigm, that decouplesthe complex network control and management operations of the network elements fromtheir forwarding operations[2]. These separated control and management functions willform a control layer for the underlying network elements. OpenFlow is an SDN approach,that follows the principles of SDN and, provides a centralised controller and a programming interface for the network switches, that are OpenFlow-enabled[3]. OpenFlow provides a clear separation between the control policies and the switch infrastructure so thatthe switches can be less complex and carry out the essential forwarding operations. OpenFlow divides the network communication into various ’flows’ to provide better control andtraffic engineering [3]. Information-Centric Networking(ICN) is a future Internet architecture that shifts the network architecture from being ’host-centric’ to ’content-centric’[4]. ICN provides network communication by keeping the ’data’ or ’content’ as the firstprimitive and enables the network to fetch the content from anywhere in the network usinga ’name’ to identify the content [5]. ICN aims to provide better availability of content inthe network resulting in better user experience and minimal network traffic to the contentproducer [4]. OpenFlow, by default, has the complete support for the IP-based networkcommunication flows. However, none of the OpenFlow specifications has the support forcontrolling ICN flows [6, 7, 8, 9]. On the other side, ICN architectures have no definition1
of a centralised control plane to enhance the controlling process for the ICN networks[5]. There are some studies in literature, which tried integrating OpenFlow and ICN byeither providing an overlay solution or providing workarounds on OpenFlow with extramodules or plugins for handling ICN flows [10, 11]. There are very fewer considerationsto move OpenFlow towards a clean state ICN support [12, 13, 14], but the scope andthe supported ICN functionalities are minimal. This dissertation studies the potentialfor the OpenFlow to support ICN by extending the essential OpenFlow elements withICN features. To achieve this, this study aims to create an OpenFlow-based control planeusing an OpenFlow controller, POX [15] and, modifies it based on the proposed solutions.The following section outlines the background of OpenFlow and ICN, followed by theaims of this project. Next section presents an abstracted view of the literature outliningthe gaps, followed by the approach proposed by this dissertation to fill those gaps. Specificproject contributions are listed in the following section and this chapter concludes with alist of terminology that will be used throughout this report.1.1BackgroundThis section describes the background details on SDN, OpenFlow and ICN.1.1.1SDN and OpenFlow for ’Today’Network switches are the network elements that help to connect machines to the networkand are essential in network operations between these machines [16]. The network operations include packet lookup, packet switching and packet buffering activities [1, 17]. Aswitch has two main components to carry out these operations: a ’datapath’ which is usedto forward the packets in the network and a ’control block’ to make decisions on switchconfigurations and operations, which includes management protocols like SNMP [18] and,routing protocols like OSPF [19] and BGP [20]. These components are tightly coupled toa network switch, leading to a closed architecture, wherein the data plane and the control2
plane are packed together by the vendor. Moreover, the switch interfaces are not exposedto the outer world. This closed-nature of switches, delays the process of experimentingnew networking architectures on the network switches [1]. Furthermore, the network operators have to manually enter the control policies into the switch infrastructure. This is acomplex process of converting the high-level logics into low-level switch implementations[21]. These manual operations are error prone and therefore, attempting new innovationson the network switches is hindered, resulting in ’Internet ossification’ [22]. Businessmenmust wait for a long period of time, for their ideas to be realised in the network.Figure 1.1: Comparison between a closed switch and SDN architectureSDN aims to provide a solution for this problem, by decoupling the complex networkcontrol and management operations of the switches, from the forwarding operations and,forming a separate control layer [2]. Figure 1.1 shows the comparison between a closedswitch and SDN architecture. Through this, SDN tries to realise a less complex dataplane layer, that can be programmed by the centralised control layer. A network operator can build applications over this control layer, which use the interfaces providedby the control layer to programme the underlying switches [23]. The intelligence of the3
network is abstracted into this control layer and used to control the elements with theaim of getting a better quality of service out of the network. This also helps to realisethe frequently changing business needs with little programming efforts instead of a wholepainful hardware change or upgradations. SDN is welcomed by many industries like datacentres, to have a better control over the underlying storage elements [2]. SDN helpsfor the continuous evolution of the networking architectures. SDN can be compared toearlier ’Active Networks’ [24] which tried providing an experimental network architecturethrough special packets called ’capsules’ which carry network programs along with theordinary messages and the networks elements that process them, will execute those programs in their machines. The problems with active networks are isolation, performanceand complexity. SDN ha
Information-Centric Networking Rajendran Jeeva MSc in Computer Science (Networks and Distributed Systems) University of Dublin, Trinity College, 2016 Supervisor: Weber Stefan OpenFlow is a Software-De ned Networking (SDN) approach, that is used to separate the data plane and the control plane of a network. This is achieved by de ning and separating
OpenFlow Switch Specification OpenFlow Switch Specification,Version 0.8.1 (Draft) The standards document that describes the protocol that is used between an OpenFlow Switch and the OpenFlow Controller. Cover the components and the basic functions of the switch, and the OpenFlow protocol to manage an
2 OpenFlow Evolution OpenFlow protocol have evolved during ONF's standardization process, from version 1.0 where there are only 12 fixed match fields and a single flow table to the . services for applications such as IP telephony and video streaming. To implement QoS in OpenFlow switches[13], OpenFlow 1.0 provides an optional "enqueue .
lated environment to this end, such as the Network Simu-lator 3 (ns-3) [6]. It is a discrete-event simulator, targeted primarily for research and educational use, and distributed as free software. ns-3 simulations can model OpenFlow switches via the existing OpenFlow module [7], which re-lies on an external OpenFlow switch library linked to the
The Beacon OpenFlow Controller David Erickson Stanford University Stanford, CA, USA daviderickson@cs.stanford.edu ABSTRACT Beacon is a Java-based open source OpenFlow controller created in 2010. It has been widely used for teaching, research, and as the basis
Linux OpenStack Platform Management GUI Network Application Orchestration & ServicesServices OpenStack Neutron NTN Coordinator OpenDay Light API's (REST) OVSDB NETCONF LISP BCP PCEP SNMP OpenFlow OpenFlow Enabled Devices Additional Virtual & . specifying action
sible and adaptable security analysis of OpenFlow (protocol and network setups), using the STRIDE [11] vulnerability modeling technique. By combining STRIDE with attack tree approaches [12], we provide a fitting methodology for an-alyzing OpenFlow from a security perspective, uncovering potential vulnerabilities and describing exploits.
Data Plane Broker OSM DPB WIM Connector Fabric Adapter Openflow Switch B Openflow Switch C Openflow Switch A Configure Service_Id Creation: Connection Points, Bandwidth Deletion: S
dance with Practices C 31, C 192, C 617 and C 1231 and Test Methods C 42 and C 873. 4.3 The results of this test method are used as a basis for 1 This test method is under the jurisdiction of ASTM Committee C09 on quality control of concrete proportioning, mixing, and placing
