OpenStack is now synonymous with NFV as the dominant platform for deploying and managing virtual network functions. Major telecommunications companies worked with the OpenStack community to optimize OpenStack for NFV use cases. Both ETSI and OPNFV have defined NFV reference platforms that select OpenStack as the virtualization integration manager and for additional management and orchestration functions. OpenStack supports NFV through projects like Nova, Neutron, and Cinder that provide the virtual infrastructure and networking capabilities required by NFV.
OpenStack is now synonymous with NFV as the platform of choice for deploying and managing virtual network functions. Major telecommunications providers and standards bodies like ETSI and OPNFV have selected OpenStack as the virtualization infrastructure manager for NFV reference architectures. OpenStack provides the necessary capabilities for NFV like networking, compute, storage, and lifecycle management of virtual network functions through projects like Neutron, Nova, Cinder, and others. Global adoption of OpenStack for NFV is growing as it provides agility, flexibility, and cost savings compared to proprietary hardware appliances.
A survey of 188 IT professionals from Nordic countries found:
- 72% worked in application development and most had a developer background
- Web applications and big data workloads could benefit most from cloud computing
- One third were already running production workloads in public clouds, while others were using clouds for development or overflow
- The main obstacle to cloud adoption was security risks
- The primary benefits of cloud computing expected were access to on-demand infrastructure and the pay-as-you-go model
OVNC 2015-THE NEW IP - Open Networking Architecture with SDN & NFVNAIM Networks, Inc.
[Open & Virtual Networking Conference 2015]
- THE NEW IP - Open Networking Architecture with SDN & NFV (Brocade Orcun Tezel 시스템 엔지니어링 아태지역 수석이사)
- 2015.02.05 (목) 09:10~17:50
- 양재동 엘타워
KEYNOTE @ NFV World Congress 2017, San José
Francisco-Javier Ramón | Head of Network Virtualisation, GCTO | Telefónica
Chair | ETSI OSM
ABSTRACT:
- How Telefónica is architecting its new Core Network with NFV to enable the dynamic re-allocation of capacity wherever needed.
- Why orchestration is the latest technical challenge to realize this vision, and what Telefónica is doing in this space.
- How Open Source MANO (OSM) has become the reference platform for interoperability after the launch of its third release.
- How this fits into Telefónica plans for virtualization.
OpenStack is now synonymous with NFV as the platform of choice for deploying and managing virtual network functions. Major telecommunications providers and standards bodies like ETSI and OPNFV have selected OpenStack as the virtualization infrastructure manager for NFV reference architectures. OpenStack provides the necessary capabilities for NFV like networking, compute, storage, and lifecycle management of virtual network functions through projects like Neutron, Nova, Cinder, and others. Global adoption of OpenStack for NFV is growing as it provides agility, flexibility, and cost savings compared to proprietary hardware appliances.
A survey of 188 IT professionals from Nordic countries found:
- 72% worked in application development and most had a developer background
- Web applications and big data workloads could benefit most from cloud computing
- One third were already running production workloads in public clouds, while others were using clouds for development or overflow
- The main obstacle to cloud adoption was security risks
- The primary benefits of cloud computing expected were access to on-demand infrastructure and the pay-as-you-go model
OVNC 2015-THE NEW IP - Open Networking Architecture with SDN & NFVNAIM Networks, Inc.
[Open & Virtual Networking Conference 2015]
- THE NEW IP - Open Networking Architecture with SDN & NFV (Brocade Orcun Tezel 시스템 엔지니어링 아태지역 수석이사)
- 2015.02.05 (목) 09:10~17:50
- 양재동 엘타워
KEYNOTE @ NFV World Congress 2017, San José
Francisco-Javier Ramón | Head of Network Virtualisation, GCTO | Telefónica
Chair | ETSI OSM
ABSTRACT:
- How Telefónica is architecting its new Core Network with NFV to enable the dynamic re-allocation of capacity wherever needed.
- Why orchestration is the latest technical challenge to realize this vision, and what Telefónica is doing in this space.
- How Open Source MANO (OSM) has become the reference platform for interoperability after the launch of its third release.
- How this fits into Telefónica plans for virtualization.
Summit 16: Bridging Open Source & Open Standards - Oma Survey ResultsOPNFV
The traditional means of innovating the mobile network has been through the thoughtful and consensus based efforts of technologists working in a standards setting environment. However, the maturation of the Internet as an app platform and the related rise of Internet-enabled device and service providers, esp on the Web, have helped renew a focus on innovation and differentiation. The development of 5G networks and the Internet of Things (IoT) will employ a process likely to be dominated by agile development of technology and platform prototypes often in open source, collaborative projects, which put a premium on "code first.†In March 2016, OMA launched an industry-wide survey to study attitudes and industry needs for better collaboration between the SDOs that build specifications, and Open Source communities that would like to use them. In this session, OMA will present the results.
Rose Schooler
Vice President, Intel Architecture Group
General Manager, Communications and Storage Infrastructure Group
Intel Corporation
ONS2015: http://bit.ly/ons2015sd
ONS Inspire! Webinars: http://bit.ly/oiw-sd
Watch the talk (video) on ONS Content Archives: http://bit.ly/ons-archives-sd
NFV aims to virtualize network functions that were traditionally run on dedicated hardware appliances. This allows the functions to run on commercial off-the-shelf servers and switches in data centers. NFV promises to reduce costs, increase flexibility and speed up innovation cycles compared to proprietary hardware appliances. A key enabler is virtualization technology which allows multiple virtual machines to run in isolation on shared server hardware through the use of hypervisors.
This publication gives an insight into what is real and usable today in FIRE. FIRE Facility projects funded by the European Commission under FP7 ICT Objective 1.6, are presented here, with a focus on examples of experimentation. The FIRE outcome is open and public for all experimenters who find the facilities offered suited to their R&D needs. The FIRE Facility projects invite you as exploratory users: profit from the experimentation and help shaping the FIRE Facility according to your needs!
1. Network Function Virtualization (NFV) aims to address issues with proprietary hardware appliances by using standard virtualization technology to consolidate network equipment into commodity servers and switches.
2. NFV allows network functions to be implemented as software that can run on commercial off-the-shelf hardware and be moved to different locations as needed.
3. Telecom companies in Brazil like Telefonica and TIM are in the process of virtualizing parts of their networks using NFV in order to reduce costs and more quickly launch new services.
Summit 16: Bridging Open Source & Open Standards - Oma Survey ResultsOPNFV
The traditional means of innovating the mobile network has been through the thoughtful and consensus based efforts of technologists working in a standards setting environment. However, the maturation of the Internet as an app platform and the related rise of Internet-enabled device and service providers, esp on the Web, have helped renew a focus on innovation and differentiation. The development of 5G networks and the Internet of Things (IoT) will employ a process likely to be dominated by agile development of technology and platform prototypes often in open source, collaborative projects, which put a premium on "code first.†In March 2016, OMA launched an industry-wide survey to study attitudes and industry needs for better collaboration between the SDOs that build specifications, and Open Source communities that would like to use them. In this session, OMA will present the results.
Enabling MEC as a New Telco Business OpportunityMichelle Holley
The document discusses Multi-access Edge Computing (MEC) and how it can provide new business opportunities for telecommunications companies. It introduces Wind River's virtualization platforms that address key challenges for MEC, including Titanium Cloud for data centers and Titanium Edge for small-footprint edge applications. The platforms provide carrier-grade reliability, security, and performance for virtualized applications at the edge. A demonstration of bandwidth guidance for optimized video delivery is also presented.
Cloud native architecture is emerging for Telecom workloads. To support these emerging trends, Intel is targeting enhancements to the Dataplane Development Kit (DPDK). The enhancements would target network service mesh with dedicated sidecar accelerators and the mechanism to build the mesh dynamically.
Speaker: Gerald Rogers. Gerald Rogers is a Principal Engineer in the Network Products Group focused on virtual switching, network function virtualization and Data Plane Development Kit (DPDK). After joining Intel in 2005, Gerald has worked as a software engineer and architect in the embedded and networking groups. For the past 7 years Gerald has led the network virtual switching software and hardware acceleration effort to drive Intel architecture into the networking and telecommunications industry. Gerald holds a Bachelor’s degree in Electrical Engineering and a Master’s degree in Computer Science, and has 20 years of experience in the networking and telecommunications industry.
After almost two years of collaboration, OPNFV has released two major releases and its artifacts are used in first commercial deployments. In addition, the OPNFV community is still growing as new members are joining the project. The first objective of this panel is to learn from OPNFV service provider members about their experience with OPNFV so far and discuss things that went well and things that could have gone better. The second objective of the panel is learn about requirements, suggestions and plans for the next steps in OPNFV and discuss about missing features, new work (new and potential future projects), but also expectations from newer members.
Redes LTE Comunitárias no Brasil: Modelamento, Implantação e Manutenção Sustentáveis com base em Novos Paradigmas de Redes.
Projeto financiado pela FAPESP Processo: 18/23101-0
Resumo
Em relatório publicado pelo Comitê Gestor da Internet no Brasil (CGI.br) em 2018, em termos de acesso à Internet por banda larga no Brasil, há uma ampla desigualdade entre as classes econômicas A/B (maior) e D/E (menor), fato evidenciado nas análises entre as áreas urbanas e rural. Além de evidenciar que cerca de 34% dos brasileiros ainda não possuem acesso à Internet, o relatório também explica que o acesso à Internet é um catalisador de desenvolvimento social, econômico e tecnológico: fato consagrado em diversas pesquisas internacionais e enfatizado pela organização Internet Society. Redes sem fio comunitárias têm se tornado um meio sustentável de promover meios acessíveis de conexão à Internet,tanto em áreas rurais remotas quanto em regiões urbanas densas. Em sua ampla maioria, redes sem fio comunitárias adotam a tecnologia wifi, no entanto apenas recentemente, devido ao desenvolvimento de tecnologias de código livre e de baixo custo, o padrão Long-Term Evolution (LTE) começou a ser explorado para estes fins. Logo, não há conhecimento na literatura acadêmica de estudos que busquem utilizar e melhorar o padrão LTE aplicado à redes sem fio comunitárias. Nesse escopo, esta proposta busca trazer conceitos inovadores de novos paradigmas de redes, Redes Definidas por Software (Software Defined Networks -SDN) e Virtualização de Funções de Rede (Network Functions Virtualization - NFV), para o desenvolvimento de redes LTE comunitárias. Por meio de uma metodologia ágil de testes,conceitos de SDN e NFV serão aplicados no desenvolvimento de mecanismos que realizem o gerenciamento inteligente de recursos de redes LTE comunitárias visando desempenho eficiente e tolerância a falhas robusta, i.e., a sustentabilidade da rede. Todos estes estudos serão feitos tendo por base um levantamento de características de redes sem fio comunitárias em operação no Brasil proposto para o início do projeto. Ao final, a execução desta proposta irá produzir um material didático elucidando as formas de modelamento, implantação, e manutenção sustentável de uma rede LTE comunitária nos moldes dos estudos realizados por esta proposta (i.e., com todos os dados, avaliações, metodologias, e protótipos). Este material será utilizado como base de uma proposta de implantação de uma rede LTE comunitária no Brasil junto ao programa "Beyond the Net" da Internet Society.
Evento: https://www.lasse.ufpa.br/co5gam/
Video: https://www.youtube.com/watch?v=5dEb9oIAaPY
Deploying Single Stack IPv4 with NAT44 is the most costly way for mobile operators to deal with IPv4 address exhaustion due to increasing bandwidth demands and NAT44 session state over time. Building a path to IPv6 is the most effective way to reduce per-subscriber capex costs associated with NAT44. Capex is neutral when transitioning to IPv6 by deploying Dual Stack IPv6 with NAT44 versus deploying Single Stack IPv6 with NAT64, though opex costs may vary between operators. A test of Single Stack IPv6 found 85-90% of smartphone apps worked via IPv6 or NAT64, with the remaining requiring support on the user endpoint for 464XLAT.
The document discusses Edge computing and the Akraino Edge Stack project. It provides an overview of the Linux Foundation Edge (LF Edge) organization and its goals of establishing an open source framework for edge computing. It then summarizes the Akraino Edge Stack project, which aims to address telco, enterprise, and industrial IoT use cases through the creation of tested and validated deployment-ready blueprints for edge cloud configurations. It outlines several blueprints that were released in Akraino R1 and previews new blueprints and enhancements planned for the future.
Your Path to Edge Computing - Akraino Edge Stack UpdateLiz Warner
The Akraino community was proud to announce the availability of its release 1 on June 6th. The community has experienced extremely rapid growth over the past year, in terms of both membership and community activity. Before Akraino, developers had to download multiple open source software packages and integrate/test on deployable hardware, which prolonged innovation and increased cost. The Akraino community came up with a brilliant way to solve this integration challenge with the Blueprint model. An Akraino Blueprint is not just a diagram; it’s real code that brings everything together so users can download and deploy the edge stack in their own environment to address a specific edge use case. Learn more about the Akraino Edge Stack. In this talk, we will share details about R1 blueprints and their use, R2 goals, and how to engage and contribute to the Akraino Community.
Transforming the Modern City with the Intel-based 5G Smart City Road Side Uni...DESMOND YUEN
The document discusses Capgemini Engineering's 5G Smart Road Side Unit solution which uses the ENSCONCE Edge Computing Platform and cloud-native architecture to enable intelligent transportation applications through visual computing and 5G connectivity. The solution places computing capabilities at the network edge using an all-weather Intel-based device to support applications like traffic management and connected vehicles with low latency. It addresses challenges of legacy infrastructure and complexity by providing an integrated platform for edge applications.
The document discusses using systems intelligence and artificial intelligence/neural networks to enhance semiconductor electronic design automation (EDA) workflows by collecting telemetry data from EDA jobs and infrastructure and analyzing it using complex event processing, machine learning models, and messaging substrates to provide insights that could optimize EDA pipelines and infrastructure. The approach aims to allow both internal and external augmentation of EDA processes and environments through unsupervised and incremental learning.
1. The document discusses key trends impacting future networks including softwarization, cloudification, network functions virtualization, modularization, and open source.
2. It notes that over 80% of telco operators demand or prefer open systems for their networks and over 95% see open source as a positive attribute for NFV solutions.
3. The document outlines how open source is playing a role at each layer of future networks from the infrastructure to orchestration to the OSS/BSS and discusses the needs, facts, and status at each layer.
Software Defined Networks (SDN) is an evolutionary paradigm that will not only change how the vendors will built their products and technologies, but also change how the organizations are going to consume these capabilities. That said, adoption of these SDN capabilities is very low. Some of them is shaped by the myths and expectations around what SDN can versus cannot do. It is therefore important to understand these adoption challenges and correspondingly use some of the consultative services frameworks to overcome these challenges.
Summit 16: Cengn Experience in Opnfv ProjectsOPNFV
CENGN, the first associate member of OPNFV is beginning to contribute to OPNFV projects by way of creating a Pharos Community lab and participating in JOID and Yardstick projects with OPNFV interns. This session will cover our learnings on the design and deployment of the Pharos lab, our experience with student interns contributing to the OPNFV projects and partnerships with innovative companies like Kontron
Zettar: Moving Massive Amounts of Data across Any Distance Efficientlyinside-BigData.com
In this video from the Rice Oil & Gas Conference, Chin Fang from Zettar presents: Moving Massive Amounts of Data across Any Distance Efficiently.
The objective of this talk is to present two on-going projects aiming at improving and ensuring highly efficient bulk transferring or streaming of massive amounts of data over digital connections across any distance. It examines the current state of the art, a few very common misconceptions, the differences among the three major type of data movement solutions, a current initiative attempting to improve the data movement efficiency from the ground up, and another multi-stage project that shows how to conduct long distance large scale data movement at speed and scale internationally. Both projects have real world motivations, e.g. the ambitious data transfer requirements of Linac Coherent Light Source II (LCLS-II) [1], a premier preparation project of the U.S. DOE Exascale Computing Initiative (ECI) [2]. Their immediate goals are described and explained, together with the solution used for each. Findings and early results are reported. Possible future works are outlined.
Watch the video: https://wp.me/p3RLHQ-lBX
Learn more: https://www.zettar.com/
and
https://rice2020oghpc.rice.edu/program-2/
Sign up for our insideHPC Newsletter: http://insidehpc.com/newsletter
Summit 16: Bridging Open Source & Open Standards - Oma Survey ResultsOPNFV
The traditional means of innovating the mobile network has been through the thoughtful and consensus based efforts of technologists working in a standards setting environment. However, the maturation of the Internet as an app platform and the related rise of Internet-enabled device and service providers, esp on the Web, have helped renew a focus on innovation and differentiation. The development of 5G networks and the Internet of Things (IoT) will employ a process likely to be dominated by agile development of technology and platform prototypes often in open source, collaborative projects, which put a premium on "code first.†In March 2016, OMA launched an industry-wide survey to study attitudes and industry needs for better collaboration between the SDOs that build specifications, and Open Source communities that would like to use them. In this session, OMA will present the results.
Rose Schooler
Vice President, Intel Architecture Group
General Manager, Communications and Storage Infrastructure Group
Intel Corporation
ONS2015: http://bit.ly/ons2015sd
ONS Inspire! Webinars: http://bit.ly/oiw-sd
Watch the talk (video) on ONS Content Archives: http://bit.ly/ons-archives-sd
NFV aims to virtualize network functions that were traditionally run on dedicated hardware appliances. This allows the functions to run on commercial off-the-shelf servers and switches in data centers. NFV promises to reduce costs, increase flexibility and speed up innovation cycles compared to proprietary hardware appliances. A key enabler is virtualization technology which allows multiple virtual machines to run in isolation on shared server hardware through the use of hypervisors.
This publication gives an insight into what is real and usable today in FIRE. FIRE Facility projects funded by the European Commission under FP7 ICT Objective 1.6, are presented here, with a focus on examples of experimentation. The FIRE outcome is open and public for all experimenters who find the facilities offered suited to their R&D needs. The FIRE Facility projects invite you as exploratory users: profit from the experimentation and help shaping the FIRE Facility according to your needs!
1. Network Function Virtualization (NFV) aims to address issues with proprietary hardware appliances by using standard virtualization technology to consolidate network equipment into commodity servers and switches.
2. NFV allows network functions to be implemented as software that can run on commercial off-the-shelf hardware and be moved to different locations as needed.
3. Telecom companies in Brazil like Telefonica and TIM are in the process of virtualizing parts of their networks using NFV in order to reduce costs and more quickly launch new services.
Summit 16: Bridging Open Source & Open Standards - Oma Survey ResultsOPNFV
The traditional means of innovating the mobile network has been through the thoughtful and consensus based efforts of technologists working in a standards setting environment. However, the maturation of the Internet as an app platform and the related rise of Internet-enabled device and service providers, esp on the Web, have helped renew a focus on innovation and differentiation. The development of 5G networks and the Internet of Things (IoT) will employ a process likely to be dominated by agile development of technology and platform prototypes often in open source, collaborative projects, which put a premium on "code first.†In March 2016, OMA launched an industry-wide survey to study attitudes and industry needs for better collaboration between the SDOs that build specifications, and Open Source communities that would like to use them. In this session, OMA will present the results.
Enabling MEC as a New Telco Business OpportunityMichelle Holley
The document discusses Multi-access Edge Computing (MEC) and how it can provide new business opportunities for telecommunications companies. It introduces Wind River's virtualization platforms that address key challenges for MEC, including Titanium Cloud for data centers and Titanium Edge for small-footprint edge applications. The platforms provide carrier-grade reliability, security, and performance for virtualized applications at the edge. A demonstration of bandwidth guidance for optimized video delivery is also presented.
Cloud native architecture is emerging for Telecom workloads. To support these emerging trends, Intel is targeting enhancements to the Dataplane Development Kit (DPDK). The enhancements would target network service mesh with dedicated sidecar accelerators and the mechanism to build the mesh dynamically.
Speaker: Gerald Rogers. Gerald Rogers is a Principal Engineer in the Network Products Group focused on virtual switching, network function virtualization and Data Plane Development Kit (DPDK). After joining Intel in 2005, Gerald has worked as a software engineer and architect in the embedded and networking groups. For the past 7 years Gerald has led the network virtual switching software and hardware acceleration effort to drive Intel architecture into the networking and telecommunications industry. Gerald holds a Bachelor’s degree in Electrical Engineering and a Master’s degree in Computer Science, and has 20 years of experience in the networking and telecommunications industry.
After almost two years of collaboration, OPNFV has released two major releases and its artifacts are used in first commercial deployments. In addition, the OPNFV community is still growing as new members are joining the project. The first objective of this panel is to learn from OPNFV service provider members about their experience with OPNFV so far and discuss things that went well and things that could have gone better. The second objective of the panel is learn about requirements, suggestions and plans for the next steps in OPNFV and discuss about missing features, new work (new and potential future projects), but also expectations from newer members.
Redes LTE Comunitárias no Brasil: Modelamento, Implantação e Manutenção Sustentáveis com base em Novos Paradigmas de Redes.
Projeto financiado pela FAPESP Processo: 18/23101-0
Resumo
Em relatório publicado pelo Comitê Gestor da Internet no Brasil (CGI.br) em 2018, em termos de acesso à Internet por banda larga no Brasil, há uma ampla desigualdade entre as classes econômicas A/B (maior) e D/E (menor), fato evidenciado nas análises entre as áreas urbanas e rural. Além de evidenciar que cerca de 34% dos brasileiros ainda não possuem acesso à Internet, o relatório também explica que o acesso à Internet é um catalisador de desenvolvimento social, econômico e tecnológico: fato consagrado em diversas pesquisas internacionais e enfatizado pela organização Internet Society. Redes sem fio comunitárias têm se tornado um meio sustentável de promover meios acessíveis de conexão à Internet,tanto em áreas rurais remotas quanto em regiões urbanas densas. Em sua ampla maioria, redes sem fio comunitárias adotam a tecnologia wifi, no entanto apenas recentemente, devido ao desenvolvimento de tecnologias de código livre e de baixo custo, o padrão Long-Term Evolution (LTE) começou a ser explorado para estes fins. Logo, não há conhecimento na literatura acadêmica de estudos que busquem utilizar e melhorar o padrão LTE aplicado à redes sem fio comunitárias. Nesse escopo, esta proposta busca trazer conceitos inovadores de novos paradigmas de redes, Redes Definidas por Software (Software Defined Networks -SDN) e Virtualização de Funções de Rede (Network Functions Virtualization - NFV), para o desenvolvimento de redes LTE comunitárias. Por meio de uma metodologia ágil de testes,conceitos de SDN e NFV serão aplicados no desenvolvimento de mecanismos que realizem o gerenciamento inteligente de recursos de redes LTE comunitárias visando desempenho eficiente e tolerância a falhas robusta, i.e., a sustentabilidade da rede. Todos estes estudos serão feitos tendo por base um levantamento de características de redes sem fio comunitárias em operação no Brasil proposto para o início do projeto. Ao final, a execução desta proposta irá produzir um material didático elucidando as formas de modelamento, implantação, e manutenção sustentável de uma rede LTE comunitária nos moldes dos estudos realizados por esta proposta (i.e., com todos os dados, avaliações, metodologias, e protótipos). Este material será utilizado como base de uma proposta de implantação de uma rede LTE comunitária no Brasil junto ao programa "Beyond the Net" da Internet Society.
Evento: https://www.lasse.ufpa.br/co5gam/
Video: https://www.youtube.com/watch?v=5dEb9oIAaPY
Deploying Single Stack IPv4 with NAT44 is the most costly way for mobile operators to deal with IPv4 address exhaustion due to increasing bandwidth demands and NAT44 session state over time. Building a path to IPv6 is the most effective way to reduce per-subscriber capex costs associated with NAT44. Capex is neutral when transitioning to IPv6 by deploying Dual Stack IPv6 with NAT44 versus deploying Single Stack IPv6 with NAT64, though opex costs may vary between operators. A test of Single Stack IPv6 found 85-90% of smartphone apps worked via IPv6 or NAT64, with the remaining requiring support on the user endpoint for 464XLAT.
The document discusses Edge computing and the Akraino Edge Stack project. It provides an overview of the Linux Foundation Edge (LF Edge) organization and its goals of establishing an open source framework for edge computing. It then summarizes the Akraino Edge Stack project, which aims to address telco, enterprise, and industrial IoT use cases through the creation of tested and validated deployment-ready blueprints for edge cloud configurations. It outlines several blueprints that were released in Akraino R1 and previews new blueprints and enhancements planned for the future.
Your Path to Edge Computing - Akraino Edge Stack UpdateLiz Warner
The Akraino community was proud to announce the availability of its release 1 on June 6th. The community has experienced extremely rapid growth over the past year, in terms of both membership and community activity. Before Akraino, developers had to download multiple open source software packages and integrate/test on deployable hardware, which prolonged innovation and increased cost. The Akraino community came up with a brilliant way to solve this integration challenge with the Blueprint model. An Akraino Blueprint is not just a diagram; it’s real code that brings everything together so users can download and deploy the edge stack in their own environment to address a specific edge use case. Learn more about the Akraino Edge Stack. In this talk, we will share details about R1 blueprints and their use, R2 goals, and how to engage and contribute to the Akraino Community.
Transforming the Modern City with the Intel-based 5G Smart City Road Side Uni...DESMOND YUEN
The document discusses Capgemini Engineering's 5G Smart Road Side Unit solution which uses the ENSCONCE Edge Computing Platform and cloud-native architecture to enable intelligent transportation applications through visual computing and 5G connectivity. The solution places computing capabilities at the network edge using an all-weather Intel-based device to support applications like traffic management and connected vehicles with low latency. It addresses challenges of legacy infrastructure and complexity by providing an integrated platform for edge applications.
The document discusses using systems intelligence and artificial intelligence/neural networks to enhance semiconductor electronic design automation (EDA) workflows by collecting telemetry data from EDA jobs and infrastructure and analyzing it using complex event processing, machine learning models, and messaging substrates to provide insights that could optimize EDA pipelines and infrastructure. The approach aims to allow both internal and external augmentation of EDA processes and environments through unsupervised and incremental learning.
1. The document discusses key trends impacting future networks including softwarization, cloudification, network functions virtualization, modularization, and open source.
2. It notes that over 80% of telco operators demand or prefer open systems for their networks and over 95% see open source as a positive attribute for NFV solutions.
3. The document outlines how open source is playing a role at each layer of future networks from the infrastructure to orchestration to the OSS/BSS and discusses the needs, facts, and status at each layer.
Software Defined Networks (SDN) is an evolutionary paradigm that will not only change how the vendors will built their products and technologies, but also change how the organizations are going to consume these capabilities. That said, adoption of these SDN capabilities is very low. Some of them is shaped by the myths and expectations around what SDN can versus cannot do. It is therefore important to understand these adoption challenges and correspondingly use some of the consultative services frameworks to overcome these challenges.
Summit 16: Cengn Experience in Opnfv ProjectsOPNFV
CENGN, the first associate member of OPNFV is beginning to contribute to OPNFV projects by way of creating a Pharos Community lab and participating in JOID and Yardstick projects with OPNFV interns. This session will cover our learnings on the design and deployment of the Pharos lab, our experience with student interns contributing to the OPNFV projects and partnerships with innovative companies like Kontron
Zettar: Moving Massive Amounts of Data across Any Distance Efficientlyinside-BigData.com
In this video from the Rice Oil & Gas Conference, Chin Fang from Zettar presents: Moving Massive Amounts of Data across Any Distance Efficiently.
The objective of this talk is to present two on-going projects aiming at improving and ensuring highly efficient bulk transferring or streaming of massive amounts of data over digital connections across any distance. It examines the current state of the art, a few very common misconceptions, the differences among the three major type of data movement solutions, a current initiative attempting to improve the data movement efficiency from the ground up, and another multi-stage project that shows how to conduct long distance large scale data movement at speed and scale internationally. Both projects have real world motivations, e.g. the ambitious data transfer requirements of Linac Coherent Light Source II (LCLS-II) [1], a premier preparation project of the U.S. DOE Exascale Computing Initiative (ECI) [2]. Their immediate goals are described and explained, together with the solution used for each. Findings and early results are reported. Possible future works are outlined.
Watch the video: https://wp.me/p3RLHQ-lBX
Learn more: https://www.zettar.com/
and
https://rice2020oghpc.rice.edu/program-2/
Sign up for our insideHPC Newsletter: http://insidehpc.com/newsletter
Four companies - Cyan, RAD, Fortinet, and Certes Networks - will demonstrate a multi-vendor NFV proof of concept sponsored by CenturyLink at Light Reading’s Big Telecom Event. The demonstration will showcase RAD network equipment running Fortinet firewall and Certes encryption virtual network functions orchestrated by Cyan's Blue Planet system. The proof of concept aims to show the benefits of distributed NFV by deploying virtual functions at the customer edge to quickly deliver new services in a cost-effective manner.
White Paper: OPNFV: Paving the Way to Open Source NFVOPNFV
Introduced in September 2014 as an outgrowth of the ETSI NFV Industry Specification Group (ETSI NFV ISG), this document is the project's first white paper and provides a detailed overview of the project.
Companies should
strive to incorporate more agility and SOFT in their
processes and IT systems, which will enable them to
respond faster to changes in customer requirements and
market conditions.
Distributed NFV: Ensuring that the Benefits of Virtualization Exceed the CostsNir Cohen
Dr. Yuri Gittik is taking a closer look at the different approaches to implement NFV solutions is carrier networks, the advantages and disadvantages of each approach and how these approaches are affecting the implementation costs.
OPNFV is a new open source project that will provide an open platform for deploying NFV solutions. It aims to enable industry collaboration and ensure consistency, performance, and interoperability among virtualized network infrastructures. Initially, OPNFV will focus on providing the NFV Infrastructure, Virtualized Infrastructure Management, and APIs to other NFV elements to form the basic infrastructure for Virtualized Network Functions and orchestration. It will work with upstream open source projects and standards bodies to help realize NFV requirements and drive consistent implementation of an open NFV reference platform.
This document introduces OPNFV, an open source project that aims to provide an open platform for deploying NFV solutions. OPNFV will enable industry collaboration to advance NFV and ensure consistency, performance, and interoperability among virtualized network infrastructures. It will work closely with standards bodies to implement a common NFV reference platform. The initial scope is to provide the NFV infrastructure, virtualized infrastructure management, and APIs required for virtualized network functions and management.
1. Open Baton enables dynamic VNF placement in emerging SDN/NFV-based 5G testbeds like the 5G Berlin testbed.
2. Open Baton and the Fraunhofer FOKUStoolkits can be used to set up federated SDN testbeds across Europe.
3. The toolkits include implementations for 5G core networks, multimedia, and more that can be deployed and configured on demand using Open Baton.
This curriculum vitae summarizes the professional experience and qualifications of Shree Duth Awasthi. He has over 4 years of experience in networking and exploring new technologies. Some of his key skills include OpenStack, network virtualization, TCP/IP protocols, and working knowledge of technologies like Neutron, Nova, and Cinder. He has worked on projects involving network functions virtualization and the Flexi platform. Currently employed by Hewlett Packard, his previous experience includes work at Tata Consultancy Services focusing on research and development related to OpenStack.
Automation, Agility and NFV
The document discusses automation, agility, and network functions virtualization (NFV) in responding to over-the-top providers. It covers automation opportunities across the service lifecycle including order fulfillment, configuration, security, and analytics. Agility requires a DevOps approach using modeling languages and tools. NFV enables new services but faces challenges around integration and standards. Open source projects are important for NFV management and orchestration. Web giants like Facebook and Amazon use custom hardware and management tools rather than just commodity solutions.
NFV aims to reduce network operators' costs and improve service delivery speeds by using virtualization technology to consolidate network functions onto industry-standard servers and switches located in data centers. This allows functions like routing, firewalls, and load balancing to be delivered as software rather than via proprietary hardware appliances. NFV promises benefits like reduced capital and operational expenditures, increased flexibility and agility to deploy new services, and easier scaling of network functions. The ETSI NFV working group is working to define requirements and approaches for NFV implementation through industry collaboration.
This paper focuses on the evolutionary stages for cloudification then covers the key software building blocks that will be needed to enable NFV, and ultimately ICT transformation to 5G. It describes how Intel® Open Networking Platform (Intel® ONP) Server running on innovative new networking platforms based on Intel® silicon can help reduce the cost and effort required for service providers and vendors alike to adopt and deploy SDN and NFV architectures.
Ildikó Váncsa, Chris Price, and Carsten Rossenhövel's presentation at the 2017 Open Networking Summit.
Communications service providers (CSPs) have a wide range of options when building virtualized services from the ground up including multiple choices for each functional block in the ETSI NFV reference architecture. CSPs prefer heterogeneous systems with building blocks from different vendors including open source software; for such deployments interoperability becomes a crucial requirement.
OpenStack, as the NFVI and VIM, serves as a widely used cloud platform for telecom and NFV use cases. As a common base, OpenStack offers the means for vendors and other open source projects to ease the interoperability challenge by providing a set of open API’s while focusing on upgradeability and backward compatibility.
However, when it comes to productization, interoperability testing often falls short and is sometimes left to the carrier as shown by the testing programs actively run by no fewer than 10 organizations today.
Join Carsten Rossenhövel from the European Advanced Networking Test Center (EANTC) and the rapporteur (editor) of ETSI’s NFV interoperability standards, Ildikó Váncsa from the OpenStack Foundation, and Chris Price, Ericsson and OpenStack board director to learn more about
The ETSI NFV Release 2 interoperability testing activities - standardization and recently completed ETSI PlugTest. Over 40 commercial and open source implementations were tested for interoperability, including 20 virtual network functions, 10 management and orchestration solutions and 10 NFV platforms.
The New IP Agency (NIA) interoperability testing campaigns of commercial NFV implementations executed by EANTC, focusing on results, lessons learned and recommendations.
How vendors and open source projects are stepping up to the challenge, realizing they must work together.
How to stay up-to-date with OpenStack releases and the community.
How to get involved to ensure you are aware of the latest developments and contribute what you need to OpenStack.
What will I learn from attending this session?
CSPs, open source projects and vendors alike will learn more about the recent ETSI PlugTest and NIA-commissioned interoperability testing, their results and how to architect full NFV solutions that will work together. Interoperability API tests and associated marks from OpenStack will be covered, as well as features to help stay current on OpenStack releases. Attendees will also hear from Ericsson about a vendor’s point of view, and how other projects such a OPNFV are evolving and expanding in scope to address this challenge.
This document provides a reference architecture for Verizon's SDN-NFV network. It defines the framework, components, and interfaces involved in deploying and managing software-defined networking (SDN) and network functions virtualization (NFV). The architecture supports standalone and hybrid NFV/SDN environments. It describes the infrastructure, orchestration, descriptors, controllers, interfaces, and considerations for reliability, security, and performance. The goal is to transform Verizon's network using SDN and NFV to simplify operations and prepare for new technologies like 5G.
This document provides an overview of network function virtualization (NFV) and software-defined networking (SDN) concepts from a Hewlett-Packard presentation. It discusses NFV benefits like reduced costs and increased business agility. It outlines the NFV standardization effort through ETSI and HP's involvement. It also describes early NFV use cases and a four-level model of NFV adoption capabilities.
Network Function Virtualization - Telkomsel Perspective (SDN NFV Day ITB 2016)SDNRG ITB
This document provides an overview of network function virtualization (NFV) from the perspective of an Indonesian telecommunications company, Telkomsel. It discusses the definition and benefits of NFV, including cost reductions, increased flexibility, and faster time to market for new services. It also outlines Telkomsel's insights into NFV and considers various deployment strategies and scenarios for migrating network functions to virtualized environments. Overall, the document examines how NFV can help Telkomsel and other telecom providers address rising data traffic and costs through the virtualization of network functions.
F5 perspective of nfv+sdn (SDN NFV Day ITB 2016)SDNRG ITB
This document discusses SDN versus NFV and F5's involvement with NFV. It defines SDN as separating the control plane from the data plane in forwarding elements, while NFV focuses on porting network functions to commercial off-the-shelf hardware. F5 participates in various NFV standards bodies and supports leading orchestration solutions. F5's products can be integrated with NFV frameworks through standard APIs and virtualization support across major hypervisors.
2. CONTRIBUTORS
Russell Bryant, Senior Principal Software Engineer, Red Hat
Kathy Cacciatore, Consulting Marketing Manager, OpenStack Foundation
Stephen Gordon, Senior Technical Product Manager, Red Hat
Eric Ji, Senior Manager, Partner Marketing and Technology Alliances, Mirantis
Armando Migliaccio, Project Technical Lead (PTL) for OpenStack Neutron; Software Architect, HP Networking
Iben Rodriguez, NFVI Architect, OPNFV Consulting
Alan Sardella, Senior Technical Marketing Manager, OPNFV Project, Linux Foundation
Tapio Tallgren, Lead SW Architect in MBB Architecture, Nokia
Brandon Wick, Integrated Marketing Manager, OPNFV Project, Linux Foundation
Ashlee Young, Distinguished Architect, Huawei Technologies
NFV USER CONTRIBUTORS
Truman Boyes, CTO Office, Head of Networks, Bloomberg LP
Axel Clauberg, Vice President, IP and Optical Architecture, Deutsche Telekom
Toby Ford, OpenStack Board of Directors; AVP, Cloud Technology, Strategy and Planning, AT&T
Takayuki Kamei, NFV / OpenStack /Application Engineer, NTT Communications
Toshikazu Ichikawa, Senior Research Engineer, NTT Software Innovation Center
Jincheol Kim, Professional Research Scientist, Software Engineer and Data Scientist, SK Telecom
Fernando Oliveira, Fellow SDN/NFV/Cloud Architect, Verizon
This work is licensed under the Creative Commons Attribution-NoDerivatives 4.0 International
License. To view a copy of this license, visit http://creativecommons.org/licenses/by-nd/4.0/
3. 3www.openstack.org Accelerating NFV Delivery with OpenStack
““Network Functions Virtualization (NFV) is
now synonymous with OpenStack. When
people say NFV, there is an implication that
they are talking about OpenStack.”1
Executive Overview
Expensive. Proprietary. Inflexible. These were some of the pain points business leaders
experienced with traditional networking, and what prompted a consortium of network
operators to develop something new. Network Functions Virtualization (NFV) allows
telecom and enterprise network operators to control their networking functions—physical,
virtual and functional domains—using commercial off-the-shelf hardware, and open
source software as a single control pane for management and orchestration.
Early on, telecommunications companies and networking vendors recognized the
potential for OpenStack as the platform for NFV, so they began working with vendors and
developers in the OpenStack community to optimize OpenStack software for NFV
use cases.
Both the European Telecommunications Standards Institute and Linux Foundation
collaboration project OPNFV have defined specifications and released reference platforms
for NFV that select OpenStack as the Virtualization Integration Manager. Additionally,
OpenStack is the dominant choice for additional management and orchestration functions.
An independent evaluator2
tested the interoperability between four NFV infrastructure
platforms that use OpenStack and various virtualized network functions. While the
evaluator noted that interoperability is still a work in progress, especially with emerging
NFV technology, the majority of configurations surpassed the evaluator’s expectations with
a “great result.”
This paper describes NFV, its business value, and how OpenStack supports NFV. It details
specific projects, use cases, and the experience of major carriers and enterprises including
AT&T, Verizon, NTT Group, SK Telecom, and Bloomberg.
Although NFV is in its infancy, NFV on OpenStack offers an agile, scalable, and
rapidly maturing platform with compelling technical and business benefits for
telecommunications providers and large enterprises.
1 “Dimensioning OpenStack Neutron for NFV Systems”, Mark Lambe writing for SDx Central, September 2014.
https://www.sdxcentral.com/articles/contributed/dimensioning-openstack-neutron-nfv-systems-mark-lam-
be/2014/09/.
2 http://img.lightreading.com/downloads/NIA-Test-Report-Final.pdf?p_redirone=yes&piddl_promo=.
4. 4www.openstack.org Accelerating NFV Delivery with OpenStack
Exploring NFV
What is Network Functions Virtualization (NFV)?
Simply put, it’s a new way to define, create, and
manage networks by replacing dedicated network
appliances with software and automation. To
put it into context, it’s a continuation of the IT
mindshift away from physical hardware that’s
inflexible, proprietary, and expensive. In an NFV
environment, a virtual network function (VNF)
takes on the responsibility of handling specific
network functions that run on one or more virtual
machines (VMs), on bare metal, or in containers,
on top of the physical networking infrastructure.
VNFs range from mobile deployments, where
mobile gateways (e.g. SGW, PGW, etc.) and
related functions (e.g. MME, HLR, PCRF, etc.)3
3 A fuller description of these mobile gateways and functions, which are part of the System Architecture Evolution, can be found
at https://en.wikipedia.org/wiki/System_Architecture_Evolution.
Figure 1. NFV functional overview
5. 5www.openstack.org Accelerating NFV Delivery with OpenStack
are deployed as VNFs, to deployments with
“virtual” customer premise equipment (CPE),
tunneling gateways (e.g. VPN gateways), firewalls
or application level gateways and filters (e.g. web
and email traffic filters) to test and diagnostic
equipment (e.g. to monitor service level
agreements). 4
For a deeper exploration of NFV through the
original ETSI NFV white paper and a technical
overview of OPNFV, visit https://portal.etsi.org/
NFV/NFV_White_Paper.pdf and https://www.
opnfv.org/software/technical-overview.
The benefits of NFV stem from the fact that it
runs on general purpose servers and switches
in virtual machines or containers and is built
with standard open APIs. NFV relies on open
source development and offers a wide range
of networking capabilities dynamically and
adaptively. In general, the aim of NFV is to
offer agility, flexibility, and simplicity. The
detailed operational and technical benefits
that network operators expect from NFV
implementation include:
4 See https://www.opnfv.org/software/technical-overview.
NFV and software-defined networking
(SDN) complement each other, but
solve different problems in different
environments across different domains.
SDN emerged to make network devices
programmable and controllable from a
central element. NFV aimed at accelerating
service innovation and provisioning using
standard IT virtualization technologies.
SDN requires new interfaces, control
modules, and applications, while NFV
typically involves moving networking
applications to virtual machines or
containers that run on commodity
hardware. NFV is highly complementary
to SDN, but not dependent on it (or vice-
versa), although the two concepts and
solutions can be combined and potentially
greater value accrued.
Figure 2. Example physical network functions for VNF
replacement
7. 7www.openstack.org Accelerating NFV Delivery with OpenStack
“
OPNFV, built on widespread developer
collaboration across many telecommunications
providers and enterprises, is well-positioned to
integrate the work of standards bodies, open
source communities and commercial suppliers
to deliver a functional, standard open source
NFV platform. OPNFV project members, including
AT&T, China Mobile, NTT DOCOMO, Telecom
Italia, Vodafone, Ericsson, Huawei, Red Hat,
Intel, CenturyLink, KT, Orange, SK Telecom, and
Sprint initially focused on the NFV infrastructure,
including the virtualization infrastructure (NFVI)
and the virtualized infrastructure manager (VIM).
In December 2015, OPNFV expanded its scope to
include MANO in future releases. OPNFV offers
the industry end-to-end integration and bare
metal deployment of a modular platform for NFV.
In addition to OpenStack, open source projects
OpenDaylight, Open vSwitch and KVM are used in
the first release of the reference platform.
OPNFV has an “upstream first” philosophy which
states that necessary adaptations to the included
projects will be developed as much as possible
within the scope of such projects—OpenStack
for example. The OPNFV community contributes
developers and code to accelerate the features
in OpenStack.
NFV is incorporated across the board within
OpenStack. OpenStack NFV feature proposals
and development are integral to all projects
and processes:
Telecom users bring their requirements to
the User Committee
ETSI NFV ISG requests for OpenStack
features are published to their website
The OPNFV and OpenStack communities
are in close contact, and processes are in
place to succinctly identify and advocate
NFV features7
“OpenStack plays a key role in OPNFV—in the community,
the projects, and the platform. We look forward to continued
collaboration as we move the industry closer to open source NFV.”
Jonathan Bryce, Executive Director, OpenStack Foundation, January 2016
7 See https://wiki.opnfv.org/community/openstack for more information.
8. 8www.openstack.org Accelerating NFV Delivery with OpenStack
Why OpenStack for NFV
The OpenStack platform provides the foundation
for the NFV architecture, which is essentially a
fit-for-purpose cloud for deploying, orchestrating
and managing virtual network functions.
OpenStack enables multiple datacenter
management from a single pane of glass,
complete with common security, identity services,
APIs, and user interfaces. The open, modular
and interoperable framework of the OpenStack
project offers telecoms and enterprises the
ability to design the NFV system of their choosing,
without unnecessary components.
Why OpenStack is “synonymous” with NFV:
Proven architecture for largest public clouds, which are available to masses on COTS hardware
(closest comparable implementation)
Standardized interfaces between NFV elements and infrastructure
Pluggable architecture with documented APIs, UIs, shared services, operations, automation
options for VNFs and other function integration
All popular open source and commercial network plug-ins and drivers
Proven telecom and enterprise implementations: AT&T, China Mobile, SK Telecom, Ericsson,
Deutsche Telekom, Comcast, Bloomberg, and more
Outstanding global community contributing to rapid pace of innovation, working on unique
NFV requirements from users, related communities and standards developing organizations
OpenStack Neutron networking project mature and in production use in most all installations
NFV features in every release since 2013
Network/element deployment automation, rollout efficiency
Resource pools cover all network segments
Broad industry support
9. 9www.openstack.org Accelerating NFV Delivery with OpenStack
OpenStack is identified as one main component
in the ETSI NFV architectural framework.
As a reference implementation of the ETSI
NFV specification, the OPNFV project has
implemented OpenStack for the Virtualization
Integration Manager (VIM) components in the
first release, Arno (releases are named for rivers),
on the lower right side of Figure 3.
It should be noted that the ETSI NFV diagram
wasn’t meant to be a formalized architecture—it’s
a model. This is why Figure 4 (Arno) doesn’t look
exactly like an implementation of Figure 3 (ETSI
spec), although it is.
With the release of Arno, OPNFV has taken the
first step toward implementing the vision of
NFV that ETSI first described. The first release
focuses on the VIM and NFVI with five projects.
This early open source implementation aims
to accelerate the development of VNFs and
other NFV components by defining a consistent,
functional stack that developers will adopt as a
de facto standard. Arno also provides telecoms
and enterprises with a base for integration and
testing, enabling faster iteration in the future.
The next release, Brahmaputra8
, slated for
February 2016 delivery, is planned as the first
“lab-ready” release, incorporating numerous
enhancements in areas such as installation,
installable artifacts, continuous integration,
improved documentation, and sample test
scenarios. The project is evolving towards lab-
readiness for the testing and interoperability
of NFV functionality and use cases. In addition
to support for more virtual networking
solutions, Brahmaputra plans also include
8 OPNFV Brahmaputra Release Page, https://wiki.opnfv.org/releases/brahmaputra.
Figure 3: ETSI NFV Specification Model with OPNFV Arno Release Subset (dotted box)
10. 10www.openstack.org Accelerating NFV Delivery with OpenStack
support for multi-site data centers, additional
fault management, and upgradeability
and deployment solutions. It will include
approximately 30 projects, demonstrating
effective interworking with several upstream
communities. Brahmaputra will include the
Liberty release of OpenStack; OpenStack remains
the sole VIM platform.
The next section will describe the OpenStack
projects key to NFV, including the “why and
how.” It will also provide recently incorporated
examples of NFV features and plans for
the future.
Figure 4: OPNFV Arno Instantiation with Open Source Software
11. 11www.openstack.org Accelerating NFV Delivery with OpenStack
Telecom Requirements
for NFV with OpenStack
Today, in ETSI NFV and OPNFV, OpenStack is
fundamental to the Virtualized Infrastructure
Manager (VIM). The VIM is the part of the
Management and Orchestration (MANO) function
that controls the assignment of virtualized
compute, storage and network resources from
the NFVI to support the VNFs. The primary
OpenStack projects involved are
OpenStack Compute (code named Nova)
for managing virtual or bare metal servers.
A related project—Magnum—uses Nova
instances to run application containers.
OpenStack Block Storage (code named
Cinder) for virtual storage, supporting
practically any storage back end
OpenStack Networking (code named
Neutron) providing virtual networking.
From this point forward, we’ll use the ubiquitous
code names for each OpenStack project. Newer
projects are only known by their code names.
There are too many NFV-enhancing features in
OpenStack to list. Primary telecom requirements
will be accompanied by a few examples of the
features OpenStack includes today and future
plans. Telecom environments and NFV have
stringent requirements in the areas of scaling,
performance, and faster and more deterministic
responses to failures, as well as IPv6 and many
more specific features. The requirement for
deterministic responses refers to predictable
performance, including how to avoid the vagaries
of the hypervisor and host OS scheduler affecting
performance-sensitive applications.
OpenStack has continually addressed carrier-
grade performance, scalability, and resiliency
requirements. All projects are charged with
prioritizing features for scalability, resiliency,
manageability, modularity and interoperability in
the Mitaka release and beyond.9
The OpenStack
Technical Committee has begun the conversation
to further define a consistent scaling framework
based on user expectations. All projects will
implement features with regard to this common
framework as well.
Performance
The performance requirement is largely about
high-performance packet processing: how to get
a packet off the network, into a VM, processed
quickly and back out again on the network.
One of the available techniques is to give VMs
direct physical access to the network via SR-IOV.
DPDK-accelerated Open vSwitch for fast packet
processing and multi-queue vhost-user with
accelerated virtual switches are also supported
in Neutron.
A set of related enhancements allows operators
to define flavors, and application owners to
define image properties, which between them
control things like vCPU topology, vCPU to pCPU
pinning, the placement of applications in relation
to NUMA nodes and making huge pages available
to the applications.
In the future we can expect real-time
enablement for Cloud Radio Access
Networks and further performance tuning
9 Watch key Project Technical Leaders (PTLs) cover planned Mitaka features for their projects in video interviews accessible at
this YouTube playlist: https://www.youtube.com/playlist?list=PLKqaoAnDyfgpMle_oc7rRrjvQ80pDA1jF.
12. 12www.openstack.org Accelerating NFV Delivery with OpenStack
of the hypervisor and network (by Nova and
Neutron respectively) as well as the guest
configuration. https://wiki.openstack.org/wiki/
VirtDriverGuestCPUMemoryPlacement
lists the key things that can help optimize
compute performance.
While it would seem natural that Network
Functions Virtualization comes under networking,
and thus Neutron, in fact, much of the work
involves Nova. Nova manages the life cycle of
compute instances in an OpenStack environment.
Responsibilities include spawning, scheduling
and decommissioning of machines on demand.
Most of Nova is relevant to NFV use cases. For
example, the scheduler is crucial for performance
and resiliency. It must launch new instances
fast, both initially and especially in reaction to
fault detection.
Scalability, High Availability
and Resiliency
Traditionally, telecoms emphasize the need
for “carrier grade” infrastructure, demanding
extremely high reliability for each infrastructure
component. One of the architectural tenets of
cloud platforms (including OpenStack) is that
both scalability and reliability are achieved via
massive horizontal scale. This is a new approach
for many telecoms in that it pushes more of the
HA requirement up to the application. In cloud
environments, an individual host cannot in and
of itself provide “five nines” of uptime, but an
application with many instances across many
hosts in a distributed cloud can. Recognizing that
failures are bound to occur, the NFV conversation
on OpenStack has to focus on resiliency
monitoring, fault detection and response.
Cells (groups of hosts) management for
geographic scaling is a Nova component.
Cells v2 enables the deployment of larger
OpenStack clouds by providing a way to group
together resources to be managed more easily.
Administrators can partition existing resources
into cells and the system will know where to
find them.
As PayPal’s Anand Palmisani puts it, “[PayPal]...
used the new and improved Nova Cells service
for the first time to increase availability and
scalability. For the uninitiated, the Nova Cells
service adds scaling and geographic distribution
capabilities without the complicated database
or MQ clustering of Zones. They also allow
operators to separate host scheduling from
cell scheduling.”10
OpenStack continues to incorporate high
availability and resiliency functionality in every
release. Most recently, the Liberty release
includes these network-specific examples:
Router high availability (L3 HA / VRRP) when
layer 2 population (l2pop) is enabled
VPNaaS reference drivers with HA routers
Networks used for VRRP traffic for HA
routers may now be configured to use
a specific segmentation type or physical
network tag.
An OVS agent may be restarted without
affecting data plane connectivity.
Event alarms trigger an action when an
event is received.
But these enhancements may not reassure every
company that’s considering NFV on OpenStack.
An independent view of OpenStack’s role in NFV
availability, entitled “Is Carrier-grade NFV Really
Important?”11
, addresses and debunks common
beliefs—that users must architect HA with
redundant components and VNFs, and enhance
the platform to maintain state during failures.
The author, Tom Nolle, President of CIMI Corp.,
concludes that OpenStack does exactly what it
claims to do, but VNF developers need to build
HA into their VNFs—just as other cloud-aware
developers build HA into their apps. There’s
a good example of this in Project Clearwater.
Clearwater is an open source implementation
of IMS (the IP Multimedia Subsystem) designed
for massively scalable deployment in the
cloud. Clearwater combines the economics of
over-the-top style service platforms with the
standards compliance expected of telecom-grade
10 “How PayPal Runs the World’s Largest Private OpenStack Cloud”, December 8, 2015, http://blog.appformix.com/how-paypal-
runs-the-worlds-largest-private-openstack-cloud?awesm=awe.sm_eN70t.
11 http://blog.cimicorp.com/?p=2372
13. 13www.openstack.org Accelerating NFV Delivery with OpenStack
communications network solutions, and its cloud-
oriented design makes it extremely well suited
for deployment in an NFV environment.
Resiliency is implemented in other, multiple ways
as well. Bloomberg, a large network operator
and OpenStack NFV user, is moving away from
synchronizing states to less stateful and more
autonomous functions across many computers,
to spread resiliency throughout the environment.
They are deploying many small firewall and load
balancer VNFs as opposed to fewer large ones.
This provides better SLAs at a higher level. The
trade-off is management of more systems but the
approach reduces risk.
For the OPNFV reference platform, Doctor is the
fault management and maintenance project. The
goal of Doctor is to build a fault management
and maintenance framework for high availability
of network services on top of virtualized
infrastructure. The key feature is immediate
notification of unavailability of virtualized
resources from VIM, to process recovery of VNFs
on them.
The Doctor community affects this mission
primarily in OpenStack’s Monasca project—
reflecting OPNFV’s “upstream first” approach.
Monasca is a high performing, scalable, reliable
and fault-tolerant Monitoring as a Service
(MONaaS) solution that scales to service provider
levels of metrics throughput. Performance,
scalability and high availability have been
designed in from the start.
Monasca can process hundreds of thousands
of metrics/second and can offer data retention
periods of greater than a year with no data loss
while still processing interactive queries. Other
key features include:
Rest API for storing and querying metrics
and historical information. Most monitoring
solutions use special transports and
protocols, such as CollectD or NSCA
(Nagios). In Monasca, http is the only
protocol used. This simplifies the overall
design and also allows for a much richer
way to describe the data via dimensions.
Multitenant and authenticated
Metrics defined using a set of (key, value)
pairs called dimensions
Real-time thresholding and alarming (single
and compound alarms) on metrics
Compound alarms
Monitoring agent supporting built-in
system and service checks and Nagios
checks and statsd.
Multisite
Telecoms require an NFV infrastructure
distributed across multiple geographical
locations. The platform must be able to support
application-level redundancy across different
datacenters, network management across
multiple sites, and between physical and virtual
infrastructure, multisite image replication, and
global and per-site quota management.
Multiple connected OpenStack deployments
as VIMs and high availability among them are
required for a distributed, multi-geography NFV
infrastructure. The OPNFV Multisite Virtualized
Infrastructure project focuses on enhancements
to the OpenStack Nova, Cinder, Neutron, Glance
(Image Service), Ceilometer (Telemetry), and
Keystone (Identity) projects, so that OpenStack as
the VIM is able to support multi-site NFV clouds.
Learn more about the OPNFV Multisite project at
https://wiki.opnfv.org/multisite.
Recognizing that failures are bound to occur, the
NFV conversation on OpenStack has to focus on
resiliency—monitoring, fault detection and response.
14. 14www.openstack.org Accelerating NFV Delivery with OpenStack
Service Function Chaining
Service Function Chaining (SFC) is a mechanism
for overriding the basic destination-based
forwarding that is typical of IP networks. A simple
example of a service chain would be to force all
traffic from point A to point B to go through a
firewall even though the firewall is not literally
between point A and B from a routing table
perspective. A more complex example is an
ordered series of functions, each implemented in
multiple VMs, such that traffic must flow through
one VM at each hop in the chain but uses a
hashing algorithm to distribute different flows
across multiple VMs at each hop.
In current data centers, deployment of a service
chain is through static, complex, and rigid
configurations since they are tightly coupled
with physical network topology and physical
resources. The introduction of new services
into a network usually requires the
reconfiguration of most (if not all) network
elements. The physical chain must be redefined
for NFV with automatic setup according to service
chain requirements. Scaling-out the network of
these service functions to handle added load
or scaling-in to reduce the resource usage is an
integral part of an SFC solution.
In OpenStack, there are two steps in creating a
service chain. First, services VMs, such as firewall
VMs, need to be created and connected to a
Neutron network via Neutron ports. After that,
selected traffic flows need to be steered through
an ordered sequence of these service VM ports.
Prior to OpenStack’s Liberty release OpenStack
already supported creation of service VMs and
attachment of these service VMs to Neutron
network ports. In the Liberty release, Neutron
was extended with the experimental SFC
project networking-sfc. Features of networking-
sfc are:
Creation of Service Function Chains
consisting of an ordered sequence of
Service Functions. SFs are virtual machines
(or potentially physical devices) that
perform a network function such as
firewall, content cache, packet inspection,
or any other function that requires
processing of packets in a flow from point
A to point B.
Reference implementation
with Open vSwitch
Flow classification mechanism (ability to
select and act on traffic)
Vendor neutral API
Modular plugin driver architecture.
Detailed, subject-to-change documentation is
available at http://docs.openstack.org/developer/
networking-sfc/.
Addressing the Rest of MANO:
NFVO and VNFM
In December 2015, OPNFV elected to expand
the scope of projects as needed to facilitate NFV
deployments.12
For instance, the community will
now incubate and propose projects on additional
topics, including MANO (the “heart and brains” of
NFV). In addition to the VIM, covered earlier, NFV
MANO includes:
12 See the blog describing the removal of scope constraints at https://www.opnfv.org/news-faq/blog/2015/12/opnfv-board-re-
moves-scope-constraints.
In current data centers, deployment of a service chain is
through static, complex, and rigid configurations since
they are tightly coupled with physical network topology
and physical resources.
15. 15www.openstack.org Accelerating NFV Delivery with OpenStack
NFV Orchestrator: Responsible for
onboarding of new network services (NS)
and virtual network function (VNF) packages;
NS life-cycle management; global resource
management; validation and authorization
of network functions virtualization
infrastructure (NFVI) resource requests
VNF Manager: Oversees life-cycle
management of VNF instances; coordination
and adaptation role for configuration and
event reporting between NFVI and E/NMS
(element or network management system).
The OpenStack Tacker project addresses the
NFVO and VNFM. Tacker is building an Open
NFV Orchestrator with an integrated general
purpose VNF Manager to deploy and operate
Virtual Network Functions (VNFs), with Service
Function Chaining. It is based on the ETSI MANO
Architectural Framework and provides a fully
functional stack to orchestrate VNFs end-to-
end (Figure 5). Tacker provides a VNF Catalog
to on-board VNF Descriptors (written using
OASIS TOSCA NFV standards) and provides APIs
for Life-Cycle Management of VNFs along with
capabilities like VNF monitoring, auto-scaling and
self-healing. Tacker plans to expand to NFVO
capabilities like Network Service Descriptors
(NSD) and Forwarding Graph Descriptor (VNFFGD)
support in upcoming cycles. Tacker utilizes
OpenStack Compute (Nova), Neutron and Heat to
execute the VNF life-cycle:
Figure 5: OpenStack Tacker addresses ETSI NFV MANO NFVO and VNFM functions
16. 16www.openstack.org Accelerating NFV Delivery with OpenStack
““OpenStack NFV deployments are the wave of the future.”13
Tacker API deploys VNF
from the VNF Catalog
Instantiates one or more VMs described in
TOSCA NFV template
Tacker facilitates configuration injection into
VNFs and provides a loadable framework for
KPI monitoring and healing
Terminate VNF will delete all VMs and other
resources associated with VNF instance
Tacker has many supporters and developers in
the OPNFV community and is projected to be an
option in a future OPNFV release. Although there
are no definitive plans at this time, the Tacker PTL
says “the OPNFV C-release could integrate nicely
with Tacker’s OpenStack Mitaka release.” There
are several technical Tacker presentation videos
from the November 2015 OPNFV Summit.
Watch the Tacker presentation and
demo at https://www.youtube.com/
watch?v=EfqWArz25Hg. For more information
on Tacker, visit https://wiki.openstack.org/wiki/
Tacker.
Other Key OpenStack Projects
Several additional OpenStack projects
support NFV implementations. Here are the
ones to watch.
Astara: Provides integrated network
service orchestration (routing, firewall, load
balancing, VPN) for connecting and securing
multitenant OpenStack environments. Wiki:
https://wiki.openstack.org/wiki/Astara
Blazar (previously Climate): Reservation-
as-a-Service, including resource reservation,
reservation update and “give me an offer”/
best effort reservation, and reservation
scheduling. Provides solution to
requirements from OPNFV Promise project.
Wiki: https://wiki.openstack.org/wiki/Blazar.
Congress: Policy-as-a-Service. Provides
governance as a service across any
collection of cloud services in order to
monitor, enforce, and audit policy over
dynamic infrastructure. Wiki: https://wiki.
openstack.org/wiki/Congress.
Mistral: Workflow service. Allows
description of complex business processes
(workflows) as a set of tasks and task
relationships, such that Mistral handles
state management, correct execution
order, parallelism, synchronization and high
availability. Mistral also provides flexible
task scheduling. Wiki: https://wiki.openstack.
org/wiki/Mistral.
Neutron: an OpenStack project to provide
“networking as a service” between interface
devices (e.g., vNICs) managed by other
Openstack services (e.g., Nova). Neutron
offers flexibility and choice with drivers
and plug-ins from numerous leading
telecom vendors so users do not have
to worry about altering their APIs or
modifying code if they decide to switch the
underlying implementation technology.
This paper covers Neutron features for
NFV performance (above). 88 percent
of OpenStack users have implemented
Neutron. For more information, please
visit http://docs.openstack.org/developer/
neutron/.
Neutron “Stadium” subprojects: An official
set of Neutron subprojects, the Stadium
includes many NFV-related projects and
maintains support for most popular drivers
and plug-ins. See the full list at http://
governance.openstack.org/reference/
projects/neutron.html.
Senlin: A clustering service and libraries
for the management of groups of
homogeneous objects exposed by other
OpenStack services. Wiki: https://wiki.
openstack.org/wiki/Senlin.
13 “Brocade Talks Real-World OpenStack NFV Deployments”, October 2015 https://www.sdxcentral.com/articles/featured/open-
stack-nfv-brocade-demofriday-sign-up/2015/10/.
17. 17www.openstack.org Accelerating NFV Delivery with OpenStack
NFV to OpenStack
Requirements Processes
NFV requirements, similar to others, are
introduced in various ways: by user request,
the ETSI NFV ISG or OPNFV community. The
tables below show these requirements become
OpenStack blueprints, which are used to track the
implementation of significant features.
OpenStack Users and Ecosystem
OpenStack users submit requirements via
the OpenStack User Committee or Operators
Working Group. Requirements are also initiated
by the OpenStack ecosystem, often based on
relationships with and Request for Proposals
(RFPs) from telecom clients. These requirements
generally mirror the requirements from ETSI NFV
or OPNFV, as the requesting companies begin
implementing the standard framework.
Here are examples of telecom and ecosystem
submitted requirements:
DESCRIPTION SUBMITTED BY OPENSTACK PROJECT BLUEPRINT STATUS
Support multiple IPv6
prefixes and addresses
for IPv6 network
Comcast Neutron https://blueprints.launchpad.net/
neutron/+spec/multiple-ipv6-prefixes
Complete
Processor core affinity
for a VM
Verizon Nova https://blueprints.launchpad.net/
nova/+spec/virt-dedicated-cpus-placement-
policy
Pending
approval
Resource reservation NTT • Nova Reservation
API
• Blazar
https://wiki.openstack.org/wiki/Blueprint-
nova-planned-resource-reservation-api
https://blueprints.launchpad.net/blazar
• Passed to
Blazar project
• Varies
NUMA topology
awareness
Red Hat and
Intel on behalf
of Telefónica
Nova https://blueprints.launchpad.net/
nova/+spec/virt-driver-vcpu-topology
Complete
VLAN-aware VMs and
support Neutron trunk
ports in Nova
Ericsson Neutron and Nova https://blueprints.launchpad.net/
neutron/+spec/vlan-aware-vms
Started,
planned for
Mitaka
Support failure
correlation
Huawei Monasca https://blueprints.launchpad.net/
monasca/+spec/suppot-failure-correlation
New
18. 18www.openstack.org Accelerating NFV Delivery with OpenStack
ETSI NFV ISG
The ETSI NFV Industry Specification Group (ISG)
submitted formal requirements14
to OpenStack
in 2014, but has since made the process more
open, publishing specification drafts and gaps15
for public review. The gaps result in OpenStack
blueprints, which initiate and track OpenStack
feature and project development through
completion. Here are examples of how ETSI
requirements are integrated into OpenStack’s
open design processes:
OPNFV SUBMITTING
PROJECT
DESCRIPTION
OPENSTACK
PROJECT
OPENSTACK BLUEPRINT
STATUS (AS OF
JAN. 2016)
Doctor Change the state of compute
service "down" immediately
Nova https://blueprints.launchpad.net/
nova/+spec/mark-host-down
Complete
Doctor Multiple blueprints for anomaly
detection and sensor monitoring
Monasca https://blueprints.launchpad.net/
monasca/
Varies
Promise Implement support of volume
reservation
Blazar https://blueprints.launchpad.net/
blazar/+spec/basic-volume-plugin
Approved, under
evaluation
Multisite Expose quiesce/unquiesce API Nova https://blueprints.launchpad.net/
nova/+spec/expose-quiesce-unquiesce-api
In progress for
Mitaka
Copper Multiple blueprints for event-
driven policy engine
Congress https://blueprints.launchpad.net/
congress/
Varies
ONOS Add a Neutron/ML2 plugin for
ONOS
Neutron https://blueprints.launchpad.net/
neutron/+spec/onos-neutron-interaction
Complete
14 https://wiki.openstack.org/w/images/c/c7/NFV(14)000154r2_NFV_LS_to_OpenStack.pdf
15 ETSI NFV Drafts, http://www.etsi.org/technologies-clusters/technologies/nfv.
NFV ENTITY
ETSI NFV SPEC
IDENTIFIER
DESCRIPTION
OPENSTACK
PROJECT
OPENSTACK BLUEPRINT STATUS
MANO Virtual
Machine
Descriptor
Vi-Vnfm and VDU in
VNF Descriptor
PCI Passthrough SR-IOV
support
Nova https://blueprints.launchpad.
net/nova/+spec/sriov-pf-
passthrough-neutron-port
Complete
VIM & MANO
Virtual Machine
Descriptor
Vi Vnfm and Service
VNF & Infrastructure
Descriptor–Se–Ma
NUMA and IO locality Nova https://blueprints.launchpad.
net/nova/+spec/sriov-pf-
passthrough-neutron-port
Approved
Vi-VNFM,
NFVO-Vi
Virtualized resource
management
Operations comprising the
management of resource
reservations
Blazar Blazar’s blueprints at https://
blueprints.launchpad.net/
blazar
Varies
OPNFV Community
The OpenStack community receives NFV
requirements via collaboration with OPNFV and
directly from telecoms involved in the project.
OPNFV can serve as an intermediary for telecoms
that might not be contributing code upstream
to OpenStack, yet want to share requirements
and collaborate in a familiar language. These
requirements are assimilated into one or more
OpenStack projects. OpenStack and OPNFV are
broader in scope than one another, yet there is
a large intersection between them. The OPNFV
requirements and development processes are
very much like OpenStack’s. Many community
members work on both projects. Here are
examples of features defined, submitted and
usually worked on by the OPNFV community:
19. 19www.openstack.org Accelerating NFV Delivery with OpenStack
Production Ready in 2016
OpenStack for NFV will be production ready
in 2016 based on development blueprints of
documented telecom, OPNFV and ETSI NFV
requirements. Having said that, the world’s
largest communications companies and
enterprise network operators are implementing
NFV with OpenStack today because of compelling
benefits. Here are a few examples. Others include
China Mobile, Telus Communications, Telecom
Italia, Wells Fargo, and Telefónica.
AT&T
In the last eight years, data traffic on the AT&T
network has increased a staggering 100,000
percent, driven primarily by video. Keeping up
by using more sophisticated, complex routers,
switches and other vertically scaled gear just
isn’t feasible for much longer—performance,
inefficiency and cost are huge issues.
AT&T’s next generation network emulates the
function of complex hardware with software
that runs on standard off-the-shelf hardware.
Powered by SDN and NFV technologies, AT&T can
add capacity faster and push out upgrades at the
speed of the Internet.
John Donovan, the company’s senior executive
vice president of technology and network
operations, said there are now millions of AT&T
wireless subscribers connected to virtualized
network services—many will be relying on
the AT&T Integrated Cloud (AIC), which is
based on OpenStack. AT&T’s internal tools
and the customer-facing applications share
the same code in the cloud. OpenStack is the
most important of the SDN projects to AT&T’s
current requirements and the company is also
contributing to OpenNFV, OpenDaylight,
and ONOS. 16
AT&T is well on its way to implementing a
common infrastructure for all VNFs, and the
first VNFs are in production with many soon
to follow. By 2020, AT&T plans to virtualize
and control more than 75 percent of its network
using this new software-defined architecture to
meet the growing demands of data- and video-
hungry users.
Verizon
The amount of Verizon’s traffic is exploding,
generally driven by demand for video and cloud
services. Contrary to popular belief, the network
itself delivers a low ROI because carrier networks
are built for peak usage, and as such are over-
provisioned most of the time.
Verizon is taking NFV very seriously, seeing it
as a way to build lower-cost network agility and
flexibility without support staff for proprietary
network functions. It is building a company-wide
common OpenStack platform for running VNF’s
(Virtual Network Functions), as well as other
internal applications. Production is around
the corner.
Verizon counts on OpenStack because:
It offers de facto implementation of a VIM
(Virtual Infrastructure Manager)
A critical mass of vendors are porting and
developing applications (VNFs) targeted
at OpenStack
16 “Half of AT&T’s networks are controlled by open-source SDN code”, Richard Chirgwin writing for The Register, January 2016.
http://www.theregister.co.uk/2016/01/08/att_expanding_sdn/.
20. 20www.openstack.org Accelerating NFV Delivery with OpenStack
Integrators have developed the necessary
deployment expertise using OpenStack
OpenStack is a common environment that
reduces vendor dependencies
OpenStack components are being tuned
to the needs of carriers, a trend that is
essential to Verizon’s ongoing efforts
Fixes can be pushed upstream so patches
do not have to be retrofitted again and
again, so Verizon can focus on innovatin.
Note that Verizon’s test lab is built on Kilo, which
is one release behind the current Liberty release.
Verizon acknowledges all the improvements they
can now take advantage of in the areas of high
availability, SR-IOV and DPDK support, NUMA
memory and scheduling, and SSD as cache.
NTT Group
NTT Communications is the long-distance &
international communications and ICT solution
provider company of Nippon Telephone and
Telegraph Corporation (NTT), headquartered
in Japan and the third-largest communications
company in the world by revenue. It desires NFV
platforms that can federate NFV services between
distributed heterogeneous sites: Carrier network,
clouds and user sites. NTT Communications
deployed a large proof of concept, built with the
same architecture and topology as its commercial
ISP backbone and cloud services.
NTT plans to launch OpenStack-based NFV
services with VNFs to their enterprise customers,
including managed network functions like firewall
and load-balancer. Customers can use the VNF
vendors’ features, for example rules, since
vendor-native APIs will be exposed. Customers
will be able to change their own network topology
by attaching and detaching NTT-managed VNFs.
They tested deployment, orchestration,
interoperability to disparate distributed sites,
monitoring of commercial VNFs: vFirewall,
vRouter, vDPI, WAN Acceleration/Optimization,
URL filter, and DDoS detection and mitigation.
They not only tested OpenStack as the Virtualized
Infrastructure Manager, but also as the MANO
components NFV Orchestrator and VNF Manager
using Heat and early stage projects Tacker and
Mistral. They also tested commercial MANO
products. The conclusions on MANO are that
the commercial solutions are difficult to use
completely, and introduced vendor lock-in
and flexibility issues. Conversely, OpenStack
advantages are openness, flexibility and
interoperability for VNFs.
NTT Group won the OpenStack Superuser
Award in part due to its in-depth testing of NFV,
identifying places for improvement, submitting
user stories and blueprints, and contributing
upstream to fill these gaps (see the table of
requirements submitted and resolved by
OpenStack telecoms in a prior section). These
videos are available for more detail on NTT
Communications’ NFV PoC and other production
implementations of OpenStack:
NTT’s Journey with OpenStack: https://www.
youtube.com/watch?v=Cu-MF8k7G_A
NTT Communications: NFV Service
Federation Across Heterogenous Sites:
https://youtu.be/IsqwpsIERys
NTT Communications: Enhancement of
OpenStack Networking for Carrier Cloud
Platform: https://www.youtube.com/
watch?v=u1VKXUO0LcE
Gohan: An Open Source Service
Development Engine for SDN/NFV
Orchestration: https://www.youtube.com/
watch?v=CEkhGUxD2oM
Delivering an End-to-End Automated and
Carrier Class NFV (Network Functions
Virtualization) Use Case: https://www.
youtube.com/watch?v=uwX27wsWPww
Deutsche Telekom
Deutsche Telekom (DT) is embracing
OpenStack as the optimum platform for NFV.
DT understands the need to avoid specialized
hardware made obsolete by new paradigm
services. NFV allows DT to deploy virtual network
functions and scale them up and down quickly,
without new investments in hardware.
21. 21www.openstack.org Accelerating NFV Delivery with OpenStack
Deutsche Telekom is well on its way to NFV in
production. In March 2015, it announced its first
production NFV workload running OpenStack, a
cloud VPN service available in Croatia, Slovakia
and Hungary. Deutsche Telekom supports
OpenStack 100 percent, and contributes
requirements and code to help advance NFV
features more rapidly.
SK Telecom
SK Telecom, the largest wireless carrier in South
Korea, is moving toward Chief Technology
Officer Dr. Alex Jinsung Choi’s vision of the all-IT
telecom infrastructure, which is to operate all
of the telecom network functions on the cloud
core in their software-defined data center. When
complete, all components in the core networks in
data centers and local network operation centers
will be running as virtualized network functions in
OpenStack cloud infrastructure.
Currently, SKT is focusing on virtualization of
the traditional Telecom network functions such
as IMS and EPC for elastic scale-out and control
for service traffic explosion. These VNFs will be
used for providing customer-specific, dedicated
multi-tenant telecom services with orchestrated
service chaining. The VNFs will also be used for
enhancing service quality and reliability with
elastic VNF resource management and load
balancing control.
SKT’s Network R&D Center succeeded in
deploying parts of the operating IMS services as
vIMS in its commercial operation environment
with OpenStack and is currently operating them
successfully. It will also commercialize more
parts of the IMS services to vIMS soon, and put it
into production. Next up is vEPC. The company’s
Network-IT Convergence R&D Center is
establishing the foundational NFV infrastructure
with OpenStack as an advanced VIM and NFVO
with advanced VNF controls.
SK Telecom expects to realize these benefits from
NFV using OpenStack:
Reduce service downtime and cost, and
improve network utilization by using
automation
Create more business opportunities with
an agile, flexible, and programmable
infrastructure
Evolve more diversely, opening the company
to various business and technology options.
Bloomberg LP
Telecoms aren’t the only organizations to
benefit from NFV. The financial services
industry is proving the relevance of NFV for
large enterprises. Bloomberg has been running
OpenStack in production for more than three
years providing self-service and rapid delivery to
more than 3,500 developers. Bloomberg
is implementing SDN and NFV to allow
programmatic networking and to lower costs.
OpenStack SDN and NFV capabilities allow
every computer to participate in network
scaling. Today, Bloomberg has implemented
DNS in software, Firewall-as-a-Service and Load
Balancing-as-a-Service, with much more to come.
Deep Packet Inspection (DPI) hardware is one of
many physical appliances that will be replaced
and virtualized with NFV software. Others include
Customer Premise Equipment (CPE), CDNs, WAN
acceleration, Network Address Translation (NAT),
Tester/Quality of Experience monitors, Provider
Edge (PE) routers (these sit at regional levels, e.g.
Japan), and more.
In addition to the benefits others have
established, Bloomberg has a few unique
observations:
More servers running networking functions
require management, but not specialists for
each specific physical appliance.
Automation further reduces the
operator effort.
In the financial markets industry, a specific
agility advantage is that modern networking
allows Bloomberg to make application
decisions based on in-packet inspection with
application protocols, such as FIX, a market
data protocol.
22. 22www.openstack.org Accelerating NFV Delivery with OpenStack
How To Get Involved
There are many ways to get involved, based on your needs and interest in contributing.17181920
NEED AUDIENCE APPROACH
Strategic level involvement Users or potential users Join the User Committee list
Articles, interviews and news Anyone Read OpenStack Superuser publication18
Operational insight Operators and admins Join the Operators List
Specific vendor direction Anyone Engage with your vendors for roadmap,
tested and verified offerings
Actual use case details Architects Review videos from the recent OpenStack
summits
Networking, general discussions Anyone Join a nearby OpenStack User Group,
attend meetups, or talk to your local
OpenStack Ambassador19
Contributing to any OpenStack projects Potential contributors and developers How to Contribute wiki20
Technical NFV information OpenStack enthusiasts and developers #openstack-nfv IRC channel on irc.
freenode.net.
Technical OPNFV information OPNFV project members and interested parties OPNFV OpenStack Community wiki21
17 http://superuser.openstack.org/
18 All found at https://www.openstack.org/community/.
19 https://wiki.openstack.org/wiki/How_To_Contribute
20 https://wiki.opnfv.org/community/openstack
23. 23www.openstack.org Accelerating NFV Delivery with OpenStack
Summary
As indicated by major telecommunications
companies, ETSI NFV, OPNFV, and large
enterprise network providers, OpenStack is the
best fit infrastructure for NFV implementations.
With support, requirements and community
collaboration from all relevant sources, and its
open source nature, ongoing rapid innovation for
NFV users is guaranteed.
There are many ways to directly influence and
contribute to OpenStack. Whether you choose
to implement a solution based on the OPNFV
framework, a vendor solution, or build it in-house
based on the ETSI NFV specification, OpenStack
is at the heart of most offerings. OpenStack
enjoys the support of more than 550 companies,
many of which are incorporating OpenStack into
their NFV solutions. Visit them in the OpenStack
Marketplace at https://www.openstack.org/
marketplace/ or at https://www.openstack.org/
foundation/companies/.