 network. On the northbound, it provides to the applications the network information base (NIB) with the network's observations such as nodes, links, topology, and statistics. Applications use this state to make management decisions. The controller software runs on com- modity servers, which consists of multiple controller processes and provides a single consistent view. Figure 4.5 shows an overview of the controller. On the south- bound, controller installs instructions to switches. These forwarding 4 Software-Defined Networks Principles and Applications Customer/operator Figure 4.5 SDN portal controller overview. BSS/OSS Orchestration layer Protocols Applications Libraries Statistics OVS-DB Topology NetConf viewer Debugger OF-Config Other gateway NetFlow protocols availability OpenFlow speaker OpenFlow-enabled hardware instructions should be independent of the particular switch hardware and should support the flow-level control granularity. The controller provides high-level names and their bindings in the network view allows any application to convert a high-level name into low-level addresses. This high-level view is provided to the applications. Vertically, an SDN controller should contain three components: the protocol handler that deals with traditional network protocols, the set of applications that makes use of its network information, and the libraries that support various southbound interfaces. On top of the SDN controller, network orchestration tools, operational support system (OSS)/business support system (BSS), and other customized tools can be built. When an incoming packet matches a flow entry at a switch, the switch updates the appropriate counters and applies the correspond- ing actions. If the packet does not match a flow entry, it is forwarded to a controller process. Controllers use these flow initiations and other forwarded traffic to construct the network view and determine where to forward. Besides packet-in event, the SDN controller also handles other network changes, such as link failur