White Papers

Understanding OPNFV

Issue link: https://read.uberflip.com/i/1344850

Contents of this Issue


Page 65 of 144

Understanding OPNFV 65 distributed for HA and scaling ● Policies are centralized, so conflicts are eliminated ● Rapid deployment of network-related changes through the centralized control plane is manageable using scripting and other programmatic means ● Event-based reconfiguration of networking elements is possible OPNFV integrates five SDN controllers: OpenStack Neutron OpenStack Neutron is both an API translation layer and an SDN controller. If used only as an API layer, it utilizes core plugins to connect to third-party SDN controllers through their respective northbound interfaces. If used as both an API layer and an SDN controller, Neutron manages OVS (see NFVI Virtual Switching below) and external physical switches through drivers. Typically, Neutron is not used as an SDN controller in complex environments, and instead it is used only as an API translation layer. Also, if you weren't confused by the dual personality of Neutron, the project actually also has service plugins that would traditionally be thought of as VNFs, such as load balancer as a service (LBaaS), firewall as a service (FWaaS), VPN as a service (VPNaaS) and so on. OpenDaylight Like OPNFV, OpenDaylight (ODL), is also a Linux Foundation project. It is a full blown modular SDN controller that caters to multiple use cases such as NFV, IoT, and enterprise applications. It supports numerous southbound interfaces to manage virtual and physical switches (OpenFlow, Netconf and other protocols). For the northbound interface to OpenStack or other orchestration layers, ODL uses YANG (a standard modeling language) models to describe the network, various functions, and the final state. The ODL community is large, with Brocade, Cisco, Ericsson, HPE, Intel, and Red Hat being just a few of the companies supporting the initiative.

Articles in this issue

Links on this page

view archives of White Papers - Understanding OPNFV