NFV and NFV-based Security Services 363
The counterpart of network data plane is its control plane. In Openstack, Neutron is
the default virtual networking API, and we use an SDN controller to achieve many challenging goals such as scaling, flexibility and reliability. OPNFV integrated several well‐
developed options for the SDN controller. OpenDaylight (ODL) [25] is a sister Linux
Foundation project focused on developing an open‐source SDN controller. ODL is
backed by many networking industry major corporations. The Open Network Operating
Systems (ONOS) [26] is another open‐source project spearheaded by ON.lab and other
members, which has also become a Linux Foundation project. ONOS closely collaborates with the AT&T CORD (Central Office Re‐architected as Data center) [27] project.
As we have discussed, the SDN controller is the back end to deliver a certain networking
area function abstraction. In Openstack, Neutron is the abstraction that comes natively
by default. Let us take Open vSwitch (OVS) as an example of the data plane, and ODL
as an example of the controller. Users make a Neutron API call to create an on‐demand
virtual network. This request passes to and is implemented by ODL, which in turn
interacts with OVS via OpenFlow. There is much more complexity in the steps taken to
realize the simple virtual network abstraction, of course, but Neutron abstraction itself
is quite simple.
For NFV, Neutron’s simple abstraction is often not enough, because it has to have the
ability to represent many different networking technologies and use cases. For instances,
virtualization of broadband access networks (vCPE: virtual Customer Premises
Equipment) and VPN based on BGP/MPLS [28] for core networks will not fit into the
simple Neutron model neatly. If we consider 5G use cases such as IoT, automobile,
healthcare and other industries outside of traditional telco, this situation is even more
complex. We have several ways to solve this problem. We could extend Neutron, but
this option can make Neutron very complex and be a burden on enterprise applications
that may not need or want that complexity. We could develop a separate service that
specifically addresses telco networking needs (e.g. the Openstack Gluon project) [29].
Or, we could implement those networking abstractions outside of Openstack altogether
by deploying SDN controller as a separate instance of VIM (Figure 15.4).
There are several abstractions in Openstack to capture different storage needs. Glance
is an image service for all application software images; Swift is an API for object store;
and Cinder is an API for block storage. OPNFV currently integrates a Ceph open‐source
project [30] to implement virtual storage from various storage hardware, for example,
economical local hard drives in the servers. Other storage back ends exist and can be
more common in deployments.
In Openstack, Keystone implements Openstack’s identity API, supporting API client
authentication, service discovery, and distributed multi‐tenant authorization services
for the entire Openstack deployment. A client asks Keystone for an authentication
token by providing its valid credentials. This token is then used in the REST API to
access an Openstack service, such as the X‐Auth‐Token request header. Keystone
also supports integration with existing LDAP directories for authentication and
authorization.
Finally, in the Danube release cycle, OPNFV is integrating two MANO (Management
and Orchestration) open‐source projects. OPEN‐O [31] is a Linux Foundation‐backed
project “that enables telecommunications and cable operators to effectively deliver end‐
to‐end services across Network Functions Virtualization (NFV) Infrastructure. ”
The Open Baton project [32] is supported by TU Berlin, Fraunhofer FOKUS, and the
The counterpart of network data plane is its control plane. In Openstack, Neutron is
the default virtual networking API, and we use an SDN controller to achieve many challenging goals such as scaling, flexibility and reliability. OPNFV integrated several well‐
developed options for the SDN controller. OpenDaylight (ODL) [25] is a sister Linux
Foundation project focused on developing an open‐source SDN controller. ODL is
backed by many networking industry major corporations. The Open Network Operating
Systems (ONOS) [26] is another open‐source project spearheaded by ON.lab and other
members, which has also become a Linux Foundation project. ONOS closely collaborates with the AT&T CORD (Central Office Re‐architected as Data center) [27] project.
As we have discussed, the SDN controller is the back end to deliver a certain networking
area function abstraction. In Openstack, Neutron is the abstraction that comes natively
by default. Let us take Open vSwitch (OVS) as an example of the data plane, and ODL
as an example of the controller. Users make a Neutron API call to create an on‐demand
virtual network. This request passes to and is implemented by ODL, which in turn
interacts with OVS via OpenFlow. There is much more complexity in the steps taken to
realize the simple virtual network abstraction, of course, but Neutron abstraction itself
is quite simple.
For NFV, Neutron’s simple abstraction is often not enough, because it has to have the
ability to represent many different networking technologies and use cases. For instances,
virtualization of broadband access networks (vCPE: virtual Customer Premises
Equipment) and VPN based on BGP/MPLS [28] for core networks will not fit into the
simple Neutron model neatly. If we consider 5G use cases such as IoT, automobile,
healthcare and other industries outside of traditional telco, this situation is even more
complex. We have several ways to solve this problem. We could extend Neutron, but
this option can make Neutron very complex and be a burden on enterprise applications
that may not need or want that complexity. We could develop a separate service that
specifically addresses telco networking needs (e.g. the Openstack Gluon project) [29].
Or, we could implement those networking abstractions outside of Openstack altogether
by deploying SDN controller as a separate instance of VIM (Figure 15.4).
There are several abstractions in Openstack to capture different storage needs. Glance
is an image service for all application software images; Swift is an API for object store;
and Cinder is an API for block storage. OPNFV currently integrates a Ceph open‐source
project [30] to implement virtual storage from various storage hardware, for example,
economical local hard drives in the servers. Other storage back ends exist and can be
more common in deployments.
In Openstack, Keystone implements Openstack’s identity API, supporting API client
authentication, service discovery, and distributed multi‐tenant authorization services
for the entire Openstack deployment. A client asks Keystone for an authentication
token by providing its valid credentials. This token is then used in the REST API to
access an Openstack service, such as the X‐Auth‐Token request header. Keystone
also supports integration with existing LDAP directories for authentication and
authorization.
Finally, in the Danube release cycle, OPNFV is integrating two MANO (Management
and Orchestration) open‐source projects. OPEN‐O [31] is a Linux Foundation‐backed
project “that enables telecommunications and cable operators to effectively deliver end‐
to‐end services across Network Functions Virtualization (NFV) Infrastructure. ”
The Open Baton project [32] is supported by TU Berlin, Fraunhofer FOKUS, and the