2. Agenda
• NFV Architecture Overview
• Role of Network Virtualization in NFV
• Service Chaining Example
• OpenStack Neutron and Service Chaining
• Open Virtual Networking (OVN)
• Conclusion
2
3. NFV in a nutshell
Source: European Telecommunications Standards Institute (ETSI)
Network Functions Virtualization
Approach
3
4. NFV Benefits for Operators
• Decouple services from hardware
– E.g. 3G services and 4G services use same physical infrastructure
• Elastic capacity
– With uniform pool of resources, apply them to services that need them
– Long and short-term demand changes
• Deploy new services more rapidly
– SW install/upgrade vs. physical install & cable
• Highly customizable
– E.g. deploy unique service chains for each customer or class of customer
4
5. NFV Architecture
5
Operations and Business Support Systems (OSS / BSS)
Service, VNF & Infrastructure Description
Sample textCompute Hardware Storage Hardware Network Hardware
Virtual Compute Virtual Storage Virtual Network
Virtualization Layer
EMS1
VNF1
EMS2
VNF2 VNF3
Orchestrator
Virtual
Infrastructure
Manager
EMS3
VNF
Managers
NFVI
VNF
NFV M&O
Nova NeutronCinder/Swift
6. Role of Network Virtualization
• Note: Network Virtualization != NFV
• Agility of networking required for NFV, just like in public cloud
• Multi-tenancy and isolation
• Decouple network services from physical infrastructure
• Dynamic service chaining
6
7. Reference OpenStack Neutron Architecture
Authentication & Authorization via OpenStack keystone
Core Neutron API API Extensions
Horizon Web UI Neutron CLI Heat - Orchestration Other tools
API Tools
Open vSwitch
Nova Compute
Open vSwitch
Nova Compute
Open vSwitch
Nova Compute
Neutron Pluggable Backend layer
Open vSwitch Plugin
OpenStack Neutron API Server
• Integrated AuthN/AuthZ with OpenStack
Keystone
• Pluggable backend allows various
network virtualization solutions
• Advanced feature API extensions.
• VMware NSX plugin available
8. Top NFV Use Cases
• Mobile Operators:
– Evolved Packet Core (EPC) – the complex control & data plane for data services in 4G/LTE networks
• Wireline Operators:
– “virtual CPE” or “NFVaaS” – providing routing, firewall, etc. for enterprise customers on SP cloud
infrastructure
8
10. vCPE: VNF as a Service
• A collection of network services hosted by a
service provider
• Based on Virtual Network & Security
Functions (VNFs) from NSX & Partners
• Example Services
– Routing
– NAT
– IPsec & SSL VPN
– Firewall Services (Native/3rd party)
– IDS/IPS
• Fully virtualized networking and security on
x86 compute, managed by SP
• Network virtualization roles:
– Native network services (e.g. DFW)
– Speed/Agility
– Multitenant service chaining at scale
– Topology & location independence
10
• What is vCPE?
vCPE
VNF Service Chaining
Other
VNF
Firewall
VPN
IPsec/SSL
11. Service Chaining
• Creating a graph of services (e.g. load balance, firewall, WAN optimize, etc.)
• Network virtualization provides a natural way to do this in automated manner
• Often need to pass metadata along the chain
– e.g. make the results of a classification step available to a later node
– Ongoing argument about how to pass this metadata – VXLAN not really adequate
• Load balancing, HA & scale out considerations
WAN OptFirewall
VPN
IPsec/SSL
11
Useful reference: draft-ietf-sfc-use-case-mobility-03.txt
VNF1
Classifier
VNF2
VNF3
VNF1a VNF2a
12. Service Chaining Example: E-W Firewall & Routing
Logical View
Hypervisor1Hypervisor1
vSwitch
Hypervisor1Hypervisor2
vSwitch
3rd Party FW 3rd Party FW
Physical View
Web App
Web App
12
13. Neutron scorecard for service chaining
+ Builds general topologies at L2 and L3
+ Can insert some services
- No general purpose metadata
- Not all insertion models supported (e.g. bump in wire, selective insertion)
13
15. What is OVN?
• Virtual networking for OVS
• Provides L2/L3 virtual networking
– Logical switches and routers
– Security groups
– L2/L3/L4 ACLs
– Multiple tunnel overlays (Geneve, STT, and VXLAN)
– Physical and DPDK-based logical-physical gateways
• Work on same platforms as OVS
– Linux (KVM and Xen)
– Containers
– DPDK
– Hyper-V
• Integration with OpenStack (and other CMPs eventually)
16. OVN Development
• Developed by the same team that started and maintains Open vSwitch
• Apache license
• Vendor-neutral
• Architecture and implementation have all occurred on public mailing lists:
• Core OVN is being developed on ovs-dev mailing list:
– http://openvswitch.org/pipermail/dev/
• Neutron plugin for OVN is being developed here:
– http://git.openstack.org/stackforge/networking-ovn.git
• Watch Tuesday’s presentation:
OVN: Native Virtual Networking for Open vSwitch
• Network Heresy Blog Post:
http://networkheresy.com/2015/01/13/ovn-bringing-native-virtual-networking-to-ovs/
16
17. Summary
• NFV has large industry thrust behind it, many stakeholders hoping it will succeed
• As operators seek to differentiate themselves, need agility to roll new services quickly
• Cost is a driver, but far from the only justification
• OpenStack quite a good fit, but not fully fleshed out
– Some room for enhancements to Neutron
• Need to avoid siloed solutions
• Need to remember the “other” parts besides compute
17
Notes de l'éditeur
This slide comes directly from one of the early ETSI white papers proposing NFV. The left hand side is the old telco way – vertically integrated boxes. The right hand side is the NFV way – which clearly looks a lot like SDDC. So it’s easy to see where VMware has a role in NFV.
Note also that some of the boxes on the left could be implemented as VMs, which could run on standard infrastructure, while other functions, like firewalls, are native components of NSX. So our 2-pronged strategy to tackle NFV is to partner with companies who can provide virtualized functions, and to incorporate some functions natively.
Neutron Plugins taxonomy
Built-in
Solution (management, control, and data plane) entirely contained in the Quantum source tree
3rd party
Plugin proxies request to an external “controller”
Can use one or more built-in components (e.g.: DHCP Agent, L3 agent)
3rd party plugins can either be Open Source or Commercial
(some) things to consider when choosing a plugin
Free vs. Commercially Supported
Advanced Features (exposed as API extensions)
Scalability and High Availability (control & data plane)
Hypervisor Compatibility
Network HW Compat (vendor specific? Allow L3 scale-out?)
4G LTE is an all-IP network. Significant changes are introduced at both Radio Access Network, as well as in the core network.
On the Radio Access network, node B and RNC are now combined, with more intelligence being pushed to the edge. This is now called eNodeB. Architecture wise, eNodeB also can be thought of having two logic components: radio module, and digital module. Radio Module mainly handles A2D, D2A with modulation and demodulation techniques, while digital module handles basic L1 to L2 packet processing, as well as pushing the packet back to core network. Deployment wise, fiber channel is being widely used to connect the radio module with digital module, and many carriers in Asia are centralizing digital modules into their Central office. This architecture is called C-RAN and many PoCs are being done to virtualize centralized digital module of eNodeB. Commercial deployment is probably still 2 years out.
Inside core network, the entire system is flattened and greatly simplified to be an all IP network. This is now called evolved packet core (EPC). This is also a major infrastructure upgrade for carriers, and they are taking this opportunity to standardize applications around COTS hardware and virtualization. Further more, backward compatibility is built into these product so operators can gradually redirect their 3G traffic over EPC, thus maximize the ROI. Virtualization is definitely the future for EPC and VMware needs to dominate this space.