We kicked off our intern program earlier this year and are pleased to welcome our very first OPNFV interns! They work directly with the community and receive hands-on development experience in NFV. Each intern works closely with an active OPNFV developer as their mentor on a project that suited interest and community need. This blog series aims to showcase these interns and the projects they work on, the mentors who are helping with their professional development, and their experience working in an open source community to help accelerate NFV.
About Zahra Jahedi:
Zahra is a PhD student at System and Computer Engineering Department of Carleton University. She worked as an intern with OPNFV last summer. During her internship she worked on the JOID project. She deployed Juju on top of MAAS. She deployed different VNFs from Juju charm store. She was involved in automating the Juju deployment on top of Openstack. She is now working on her PhD thesis which is about NFV in wireless networks and looking forward to be involved in the open source community.
In Her Own Words
We had a chance to chat with Zahra during LinuxCon earlier this year and caught it on video. Hear from Zahra directly about how she got started, her work on the Pharos labs to deploy Juju and MAAS, and what it’s like to work in the OPNFV community.
Arpit Joshipura a veteran tech executive who has worked at Dell, Ericsson and Nortel
In recognition of the increasingly central role open source technology has played for the networking sector, the Linux Foundation today named Arpit Joshipura as its general manager for networking and orchestration.
We’ve just issued the latest iteration of the OPNFV platform, OPNFV Colorado 3.0. While the initial Colorado 1.0 release was a major milestone, the work on Colorado did not stop at the release. Colorado 3.0 has 19 scenarios, including one new one. There are updated installation images for three installers, including updates for both x86 and ARM. And as with earlier versions, Colorado 3.0 has a choice of SDN controllers, different virtual switches for fast packet processing, and for using network features such as Service Function Chaining (SFC) and BGPVPN. Releasing Colorado 3.0 involved a lot more than just copying the Colorado 1.0 installer images and documentation to the server. One of the biggest opportunities these update releases provide is the opportunity for different OPNFV projects to implement bug fixes (both from the upstream projects and to enhance their own code base). However, what might seem like a “simple” change in one line of code is actually much more complicated; it involves testing of that code with different installers and with different combinations of projects.
To get an idea of the complexity of what goes into each release–whether a milestone release or a point release–visit this page on the OPNFV wiki. It lists all the different scenarios and their testing status for the Colorado 3.0 release. Each combination of an installer and related feature project is as a “scenario” that needs to be tested. There are currently seven different testing projects that test different aspects of the scenario across two different hardware architectures (Intel x86 and ARM). To tame this complexity, considerable focus has gone into OPNFV’s continuous integration (CI) system to make running theses tests and reporting the results much easier. While there is still work to be done, updated results can be found here. What you’ll find is that Colorado 3.0 presents an even more solid foundation for NFV applications and services. We encourage the community to start working with Colorado 3.0 and share any feedback on the OPNFV Users mailing list.
Meanwhile, we’re hard at work on the next major OPNFV release, Danube, which is expected in 1H2017. More about that later! On behalf of the TSC, I wish you happy holidays and a happy new year.
We’ve all been the victim of a dropped mobile phone call and know how frustrating it can be. However, virtualized networks provide network operators with powerful tools to detect and recover from network disruptions, or “faults,” that can drop calls for thousands of subscribers simultaneously. The Open Platform for Network Functions Virtualization (OPNFV) project together with OpenStack have developed features in software that add resiliency to mobile networks and enable them to recover from network and other outages.
At the recent OpenStack Summit in Barcelona, both groups demonstrated how new technologies in NFV can help minimize network disruptions. During the keynotes, technical leads from the OPNFV Doctor Project and OpenStack Vitrage project conducted a phone call using a 4G mobile system running on top of OpenStack. The mobile call continued without disruption even after a dramatic cutting of network cables. (You can watch the short demo in its entirety below.)
To get the skinny on how the technology works and what it took to pull off such a compelling demo, we sat down with folks involved with OPNFV, OpenStack and the Doctor project, including Ifat Afek (System Architect at Nokia Cloudband), Carlos Goncalves (Software Specialist at NEC), Ryota Mibu (Assistant Manager at NEC), and Ildiko Vancsa (Ecosystem Technical Lead at OpenStack Foundation).
OPNFV: Can you give an overview of the demo you did at OpenStack Summit?
OPNFV/OpenStack demo team: We performed two live mobile calls from stage and both were interrupted. The first call dropped when Mark Collier (COO at OpenStack Foundation) removed two cables from the servers powering the mobile system for the calls. After this failed call, Ryota Mibu enabled the OPNFV Doctor features and the teams made another call. During the second call, Mark cut the network cables with giant scissors, but this time the call continued without disruption.
The demo leverages OpenStack as the base for a 4G mobile system equipped with the functionality to perform a smooth failover in case of faults in the system (in a process called “Fault Management”). OpenStack laid the foundation for the cloud-based mobile platform and OPNFV—via the Doctor Fault Management project—filled the existing feature gaps and provided system integration. While we successfully showed how OpenStack operates in an NFV/Telecom environment, the demo was also an example of the fruitful collaboration between the OpenStack and OPNFV communities as development of the new features and additions were driven through Doctor “upstream” into OpenStack.
OPNFV: Can you talk a little more about fault management and why it’s important?
Demo team: There is no system without faults, errors, and failures, even in the cloud. Fault management is a component that allows operations teams to monitor, detect, isolate and automate the recovery of faults. With an efficient fault management system, countermeasures can negate the effects of any deployment faults, avoiding bad user experiences or violation of service-level agreements (SLAs).
To put this in perspective, think about the impact to network services during natural disasters or other emergencies. According to areport by NTT DOCOMO, the largest mobile phone operator in Japan, thousands of antennas and other infrastructure equipment went out of service as a result of the magnitude 9.0 earthquake and tsunami in March of 2011. The consequences, as we all know, were devastating. Millions of mobile subscribers were disconnected from the cellular network, unable to make emergency calls or check in with loved ones.
Service continuity of virtualized platforms has to be equally addressed. The features enabled by OPNFV and OpenStack add value toward helping operators quickly recover from small to large-scale faults, ultimately keeping our societies connected in times of need.
OPNFV: How can organizations implement Doctor’s Fault Management solution in their networks?
Demo team: While not standalone software that can be downloaded and installed directly, the core Doctor framework relies on OpenStack components. Any organization deploying recent versions of OpenStack (from Liberty onward) will have Doctor-prescribed enhancements already available out-of-the-box with little to no configuration. In other words, Doctor is now a part of OpenStack.
Extensive documentation covering requirements, use cases, gap analysis, architecture, design decisions, configuration and user guides are available. Head toOPNFV.orgto theOPNFV Colorado 2.0 Doctor documentation pagefor details.
OPNFV: Are there other use cases for Doctor that go beyond telecom? Will it work with other types of networks?
Demo team: Yes, definitely! There are a number of interesting cloud and enterprise applications that can use the framework; for example, those with time constraints, e.g. in the area of multimedia and real-time applications (for faster replacement of a video cache associated with peak user times). The OpenStack-powered fault management framework will be useful for anyone operating within contracted SLAs.
Individually-developed features can also be used beyond fault management scenarios. For example, event alarms can be leveraged for quicker triggering of administrative actions. Without this feature, events (or “faults”) can only be retrieved by periodically polling data from a database. In fact before Doctor, the time required to detect and recover from a fault was a few minutes. With Doctor, the time to recovery is less than one second!
OPNFV: What’s next for the Doctor project? Are there other cool implementations we can expect to see in 2017?
Demo team: We certainly hope so, but it will be hard to top our Barcelona demo! As a project and a part of a larger community, maintenance and continuous improvements to the functionality of fault monitoring, notification and handling are needed and planned for in OpenStack. And as integrators, the community needs rich monitoring functions that can be supported by the broader OpenStack/OPNFV ecosystem.
Recently, new open source communities have surfaced that aim to develop higher-layer network function management and orchestration systems. OPNFV has been supportive of these activities, and a plan to integrate them in the platform is on the horizon. That said, we may see Doctor joining additional collaborative efforts at some point.
OPNFV: Most importantly: How did Mark get those giant scissors through airport security?
Demo team: Mark made all of us sign a nondisclosure agreement that prevents us from sharing any details! (It was either that or he would sabotage the demo…)
For more information, please visit OPNFV and OpenStack NFV on the web or follow @opnfv on Twitter.
The OPNFV Project, a carrier-grade, integrated, open source platform intended to accelerate the introduction of new products and services using Network Functions Virtualization (NFV), today announced the 2017 OPNFV Summit will be held in Beijing, China, June 12-15, 2017 at the JW Marriott Beijing. The Summit provides an opportunity to reach the innovative communities, developers and companies transforming the networking industry through open source NFV.
The number of significant open source projects related to networking, automation, and orchestration likely number in the dozens. The reasons for this plethora of projects range from politics to pragmatism, and points in between.
We kicked off our intern program earlier this year and are pleased to welcome our very first OPNFV interns! They work directly with the community and receive hands-on development experience in NFV. Each intern works closely with an active OPNFV developer as their mentor on a project that suits interest and community need.
This blog series aims to showcase these interns and the projects they work on, the mentors who are helping with their professional development, and their experience working in an open source community to accelerate NFV.
About Daniel Tudares
Daniel is an electronics engineer with a major in Telecommunication. From Venezuela, he came to Canada two years ago to pursue a Master of Engineering degree in Electrical and Computer Engineering at Carleton University in Ottawa, which hhe’ll complete by the end of the Fall 2016 term.
During his Masters program, he did a lot of research on Cloud Computing, NFV, Software-Defined Networks and virtualization. He had the opportunity to join the Centre of Excellence in Next Generation Networks (CENGN), an associate member of OPNFV. His internship project consisted of deploying a bare metal lab infrastructure based on the OPNFV Pharos lab project specifications. As the only Pharos community lab available in Canada, it will help other students like Daniel to kcontinue research and give back to the OPNFV community.
In His Own Words
We had a chance to chat with Daniel during LinuxCon earlier this year. Watch the video below to hear from Daniel directly about how he got started, his project to build a Pharos Lab at CENGN, and what it’s like to work in the OPNFV community.
“Hopefully my experience will open me the doors to keep doing research in this field and to be able to keep working with great open source communities like the OPNFV!”
We are looking forward to hosting the OPNFV Plugfest the week of December 5 – 9, 2016 at the UNH Interoperability Lab. The week-long event is a great opportunity for organizations to test the interoperability of specific OPNFV implementations over multiple hardware platforms as well as Virtual Network Functions (VNF)applications.
Plugfests provide a venue for to do real-time, hands-on testing with others in the industry. These events can be extremely valuable during the early stages of technology. At just over two years old, OPNFV is a Collaborative Project at The Linux Foundation that facilitates the development and evolution of NFV components across various open source ecosystems. Through system level integration, deployment and testing, OPNFV creates a reference NFV platform to accelerate the transformation of enterprise and service provider networks. This will be the project’s second Plugfest, focused on its recent Colorado platform release. Details from the inaugural Plugfest held in May 2016 may be found in this report.
The upcoming OPNFV Plugfest will continue to focus on both hardware and software integration as well as deployment of commercial VNFs and controllers across various upstream open source ecosystems. The event will also include testing of OPNFV hardware based on the Open Compute Project (OCP), which will create a fully open implementation from hardware through software.
Though still evolving, options for OPNFV Interoperability Plugfest Test Cases include:
OPNFV members and non-members, alike, are invited to attend. Participation of developers from many diverse organizations is encouraged to ensure a well-rounded set of perspectives.
Additionally, and for the first time, a Hackfest has been organized for the same week as the Plugfest, and is expected to draw many more OPNFV developers. These events will provide a truly unique opportunity for participants and developers to advance the OPNFV platform. If there are things you’d like to see in the upcoming OPNFV releases, we encourage you to show up, participate, and get things done!
Lincoln Lavoie, Senior Engineer, Broadband Technologies, University of New Hampshire InterOperability Laboratory (UNH-IOL), www.iol.unh.edu. Lincoln Lavoie is the senior engineer in Broadband Technologies and acts as an industry lead for the executive steering body at the University of New Hampshire InterOperability Laboratory (UNH-IOL). In this role, he is responsible for the technical management of the broadband access technology grounds, including Digital Subscriber Line (DSL), Gigabit Passive Optical Network (GPON), and Technical Report 069 (TR-069).
m, 
Lincoln Lavoie