Supporting Virtualized Telco Applications with OpenStack
•Télécharger en tant que PPTX, PDF•
3 j'aime•1,206 vues
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à Supporting Virtualized Telco Applications with OpenStack
Similaire à Supporting Virtualized Telco Applications with OpenStack (20)
Dernier
Dernier (20)
Supporting Virtualized Telco Applications with OpenStack
- 1. © 2014 VMware Inc. All rights reserved. Supporting Virtualized Telco Functions with OpenStack Bruce Davie CTO, Networking
- 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
- 9. 4G LTE • LTE Network Elements X2 cell LTE-Uu LTE-UE Evolved Node B (eNB) S6a HSS S1-MME MME: Mobility Management Entity PCRF: Policy & Charging Rule Function S10 S7 Rx+ SGi S11 S1-U S5/S8 PDN GatewayServing Gateway SAE Gateway PDN PCRF MME Evolved UTRAN (E-UTRAN) Evolved Packet Core (EPC) 9
- 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.