Advancing LTE architecture with NFV and SDN
•
15 gostaram•2,612 visualizações
My presentation at LTE MENA 2015 in Dubai. It was the last one before some 5G discussions and after some good introductions to the NFV/SDN topics from the mobile operator perspective so I decided to do a remake of my NFV/SDN Orchestration presentation to address the maybe unwanted effects that NFV and SDN could have in the LTE network architecture. At the end I had to cut a couple of slides because I only had 20 minutes. Here is complete.
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Destaque
Destaque (9)
Semelhante a Advancing LTE architecture with NFV and SDN
Semelhante a Advancing LTE architecture with NFV and SDN (20)
Último
Último (20)
Advancing LTE architecture with NFV and SDN
- 1. Alberto Diez - alberto@posteo.net Advancing LTE Architecture with NFV/SDN
- 2. Alberto Diez – 2015 MNO survey about NFV/SDN 97% 93% 0% 20% 40% 60% 80% 100% Will you deploy? Infonetics Research: SDN and NFV Strategies: Global Service Provider Survey. March 2014 0% 20% 40% 60% 80% 100% Network optimization Multi-tenancy Operational efficiencies Commercial hardware Quick revenue Scaling up & down SDN NFV
- 3. Alberto Diez – 2015 NFV architecture Virtual Network Functions OSS/BSS NFV Orchestrator VNF Manager VNF EM VNF EM Virtualized Infrastructure Manager Network Functions Virtualization Infrastructure Management & Orchestration Infrastructure Applications Services
- 4. Alberto Diez – 2015 Doesn’t OpenStack do everything already? Network optimization Multi-tenancy Operational efficiencies Commercial hardware Quick revenue Scaling up & down Nova (Compute) Neutron (Networking) Cinder (Storage) Glance (Images) Swift (Objects) Ceilometer (Telemetry) Heat (Orchestration) Keystone (Id) Horizon (Dashboard)
- 5. Alberto Diez – 2015 VNF (LifeCycle) Manager Network optimization Multi-tenancy Operational efficiencies Commercial hardware Quick revenue Scaling up & down Instantiation Initial Configuration Update Modification Scaling Termination PM/FM Templates/Catalogue IT vs Telco
- 6. Alberto Diez – 2015 NFV Orchestrator Network optimization Multi-tenancy Operational efficiencies Commercial hardware Quick revenue Scaling up & down Network Services (CRUD) Forwarding Graphs (CRUD) Multiple VNF Managers Multiple NFVIs Authorize VNF Manager Transactional Data driven Configuration/State/Data Multi-protocol/Multi-vendor OSS/BSS integration VENDORS
- 7. Alberto Diez – 2015 Which role does SDN play? SDN is to networking what NFV is to hardware Control Data Flows Switch Switch Switch Switch Switch Switch Switch SDN Controller
- 8. Alberto Diez – 2015 SDx is not OpenFlow Network optimization Multi-tenancy Operational efficiencies Commercial hardware Quick revenue Scaling up & down All devices programmable via APIs Standard declarative modeling Configuration Management Discovery / auto-onboarding Relationships Policy / Authorization
- 9. Alberto Diez – 2015 Forwarding Graphs & Service Function Chaining NFV SDN VNF3 VNF1 VNF4 VNF2 VNF1 VNF2 VNF3 VNF4
- 10. Alberto Diez – 2015 Group Policies & Intents LB LB LB LB Group of Loadbalancers •Allowances •Security policies •QoS policies Applications Network SDN Controller A : Intent to reach D Apply policy in A Create path A & B Create path B & D
- 11. Alberto Diez – 2015 Policy Control PCRF Real-Time Subscriber awareness Service awareness Gw Application awareness VNF4 VNF2 TDF SFCtag Orchestrator/ SDN Controller VNF3 Applications Network PCRF
- 12. Alberto Diez – 2015 Orchestration, SDN and Policy Control NFV Orchestration Policy Control SDN Scaling up & down Innovative use cases Time-to-Market Time-to-Market Operational Efficiencies Multi-Tenancy Network Optimization OSS/BSS SDx CM Automation SON UP/CP Separation OpenFlow Auth Complex! App Awareness Subscriber Aware Real Time Service Chaining APIs Scripts System models Service models Network models Configuration Run-Time flexibility Intents Topology
- 13. Alberto Diez – 2015 What if Open Source is the new standard? OpenFlow YANG TOSCA SFC
- 14. Alberto Diez – 2015 Effects of NFV/SDN Scaling down Manageability of larger amount of deployments Support for different network setups Higher personalization ITification of telecommunications Open Source increased pace of standards
- 15. Alberto Diez – 2015 Radio Access Network Verticalization of the NFV/SDN Core Network Core Network MVNO Apps Web Video IoT … Radio Access Network MVNOApps Web Video IoT … Core Network Core Network Core Network Core Network
- 16. Alberto Diez – 2015 Verticalization: Enterprise, Google FI & M2M MANO Telco Network BSS Onboard new enterprise With these policies 1. Reserve virtual resources 2. Instantiate new elements (PDN-Gw, PCRF) 3. Configure networking (SDN) 4. Configure new elements 6. Configure existing elements (DRA, SGw) 5. Provision policies MVNOs can use network sharing M2M can use dedicated cores
- 17. Alberto Diez – 2015 Core Network for Priority Core Network for Internet Core Network IMS Internet Net-neutrality backdoor? Voice Emergency Internet Internet Voice Emergency Internet Internet Priority Video Internet Priority VideoPriority Video S D N No difference As long as they go on different pipe… Out of control of MNO
- 18. Alberto Diez – 2015 Mobility & Personalization MyNetwork MyNetwork MANO migrate Migrating VNFs to different clouds is still complex, it will require more orchestration Use case: extreme personalization “One user, one core”
- 19. Alberto Diez – 2015 Network @ the RAN Core Core Core Services Services Services MANO Deploying everything at the edge MNOs to operate low latency public data-centers near the RAN
- 20. Alberto Diez – 2015 Thank you! Takeaways MANO is key for NFV and SDN Operational efficient as top Orchestrator New architectures to improve service Upcoming Trends Hybrid MANO: physical, VMs, Containers New business models for operators Linux distro business model for vendors alberto@posteo.net Report for download http://www.slideshare.net/AlbertoDiez4/
Notas do Editor
- Two topics for the presentation: NFV/SDN Management and Orchestration and its effects creating new mobile architectures
- Quick revenue is 2: better time to market and innovative use cases Except commercial hardware and scaling everything is related to Management and Orchestration not to virtualization per se, and nevertheless scaling requires MANO
- Heat is focused in deploying the application and creating the network, even it can deploy groups of elements but until now not much more provided (some auto-scaling with ceilometer and policies) Unclear if it supports update/upgrade, it won’t really support much configuration management, requires to call Cheff or Puppet What if you don’t own the cloud? What if you have different clouds? What if you have several tenants?
- IT vs Telco Automation +Cheff/Puppet, OVF… // Cloudify, Juju, Heat and all the IT guys TOSCA vs YANG Telco vendors think they are going to provide one (e.g. Amdocs, Nokia, NEC) because they don’t like anyone messing up with their VNFs It is not orchestration because it does not really do CM in runtime, touch the network and it doesn’t update in run-time usually, its just scripts for deployment, start/stop possibly scale out; scale up/down and the initial configuration Also if you buy from telco vendors they don’t want you to touch their VNFs then you end up with two and that screws up It usually also doesn’t do the network topology thing ETSI: -VNF instantiation, including first configuration -Software update/upgrade -VNF instance modification -scaling out/in up/down -PM/FM per instance -Automated healing -Instance termination -Change notification -Integrity Uses a template called VNFD (with abstract description of resources requirementss)
- Its about provisioning services and decomposing that into mini tasks (transactional) That requires to touch devices & network (know net topology, WAN settings etc) It requires configuration, state and data-model – its data driven Multi-protocol and multi-vendor Multi-clouds and also physical components! Centralized component Inputs from OSS/BSS Take corrective actions OSS/BSS vendors want to come in too ETSI: Management of network services (CRUD, Graphs of VNFS) It is required if you have several VNF Managers It is required if you have several NFVI to manage resources across them Police/Authorize resources changes that the VNF Managers want to do
- SDN comes from the university and is widely used in data centers. It does to switches/networking what NFV does to hardware It plays a role because partly of the stuff what the operator is looking at is requires to change/adapt the network SDN is to networking what NFV is to hardware – they both need each other because one of the good things of SDN is have virtual switchs and you have no service without connectivity of the VNFs Mention OpenFlow as the protocol which permits to really control data flows in Switches SDN is actually three things -UP/CP separation -Automatization and programmability -Virtual networks overlays
- Configuration Management plays a role
- Establish forwarding graphs between the different VNFs to guarantee service is part of the Orchestrators role Talk about why this requires deep network topology , a change needs to be reflected immeadetely Orchestrator requires to know a lot about the network Does orchestrator also control the flow or just the networking?
- GBP provides simplicity by grouping elements of the same type Its somehow tied with Intent networking, declarative languages, express what you want to achieve and not how The SDN control layer as the bridge between applications and networks
- PCRF between application and network first collision with SDN control, which is conceptual SFC is second collision which is actual pragmatic
- OASIS Tosca IETF SFC NetConf Yang ONF OpenFlow ETSI ISG But at the end OPNFV, OpenStack, OpenDayLight
- IT makes a lot of sense because the core network that you need for each of these is totallly different, for example a IoT provider wants really low cost, for video or voice or gaming you may care about latency but for web or apps you may prefer to have better throughput
- 3GPP is already working in dedicated networks, per subscriber And of course network sharing which is with PLMN id
- This is just an idea, but if the traffic goes on different pipes its allowed to be non-neutral The falacy of Net Neutrality, I like someone said TCP is not neutral