SDN in NFV Architectural Framework

Marie-Paule Odini, HPE


With NFV focusing on the virtualization of network functions, and SDN focusing on the decoupling of control and data plane, combining the two is now a hot topic in the telecom community. ETSI NFV has recently published GS NFV-EVE 005 a Report on SDN Usage in NFV Architectural Framework that analyzes architecture, design patterns and use cases to drive some recommendations for the NFV community. Some of these recommendations are already included or investigated for ETSI NFV Release 2 specifications are in progress, and further work may be conducted for other topics. This article provides some highlights of the main topics.

One of the first element that is described is the positioning of SDN controller in ETSI NFV architectural framework (Fig 1)

  • 1- SDN controller as a VIM, Virtualized Infrastructure Manager
  • 2- SDN controller as a VNF
  • 3- SDN controller in the NFVI
  • 4- SDN controller in the OSS/BSS
  • 5- SDN controller as a PNF

For some of these cases, some recommendations were articulated, such as:

  • REC#2: support of the SDN controller as a PNF
  • REC#22: requirement be specified for the Nf-Vi interface to support operations going to an SDN controller.

Figure 1

Fig 1. SDN controller in NFV architectural framework (source: ETSI NFV GS-EVE 005)

Further positioning were studied for SDN resources, SDN applications but also interactions between those different elements and the need for new reference points.

Another aspect that was also investigated was the relationship that the SDN controller may have with its environment being SDN resources and SDN applications, but also with other SDN controllers and with NFV Management and Orchestration. While the first two are pretty well covered in the industry between standards, open source and vendor implementations, the other two: controller to controller whether it is for hierarchy or federation, and controller to NFV Orchestrator to synchronize some NFV and SDN topologies, or orchestration, are still immature and require further study as recommended in REC#4 (Fig 2).

Figure 2

Fig 2. SDN controller interfaces (source: ETSI NFV GS-EVE 005)

This whole study was conducted with contributions from over 30 different companies and contributors, and supported by some real case implementation with more than 14 ETSI NFV Proof of Concepts (POC) that combined SDN with NFV and provided concrete feedback to the team. As an example the following POC#34 conducted by Hewlett Packard Enterprise with Telenor, Vodafone and other vendors, demonstrated at the SDN World Congress in Dusseldorf and at MWC’16, reported on the usage of SDN in a vEPC (Fig 3.)

Figure 3

Fig 3. SDN enabled Virtual EPC – ETSI NFV POC#34 (source: ETSI NFV)

This case is particularly interesting as it paves the road for 5G with next generation mobile core decoupling the control plane and data plane and introducing SDN and NFV combined and orchestrated across multiple domains, and multivendor environments.

The interconnections of different domains is a critical topic in a telecom network with multiple data centers and distributed architecture. As such the notion of partitioning and multi-site was discussed and also presented to OPNFV and OpenDaylight to ensure that support of multiple SDN controllers under a VIM being OpenStack for instance was taken into account (Fig 4).

Figure 4

Fig 4. NFVI-PoP interconnection with pre-provisioned static pipe (source: ETSI NFV GS-EVE 005)

This type of scenario was further refined exploring the different dimensions of WAN underlying options, but also having multiple administrative domain sharing NFVI-PoPs. One example of those is the following Fig 5 that highlights a case where Service Provider A1 with his own NFV Orchestrator has resources deployed in multiple domains, one being A2 with its own VIM A2 and the other being A1 with its VIM A1 and A1 resources, that is hosted in another service provider B1 NFVI-PoP. This case brings many interesting configuration aspects, such as the interactions between SDN Controller A1 and SDN controller A2 and the potential risk that A1 introduces some unexpected flows in A2 SDN environment, which has been leading to recommendation REC-SEC#3 on attack mitigation, but this also brings the questions of having the A1 NFVO coordinate between the WAN Infrastructure Manager/SDN controller (WIM and underlying layers) and the VIM A1 and A2 to ensure proper configuration of the end to end path across these different domains.

Figure 5

Fig 5. Multiple trust domain (source: ETSI NFV GS-EVE 005)

Overall the topic is pretty complex and while the team was conscious that some design pattern may have been underestimated, the main ones have been covered to highlight some of the main principles. As SDN gets deployed in carrier networks, a use case that comes to mind is the transport network and the different layers between optical, Ethernet, underlay, overlay and the hierarchy of SDN controllers. This has been illustrated with a failure and switchover scenario in Fig 6: typically if the SDN controller in charge of the primary line detects a failure, he will report an alarm to the upper layer SDN controller that will trigger the switchover to the backup line.

Figure 6

Fig 6. SDN controller hierarchy and failover scenario (source: ETSI NFV GS-EVE 005)

Last but not least, Service Chaining is also a hot topic when talking SDN with NFV. Extensive studies were conducted with ETSI NFV POCs, typically POC#28 in conjunction with ONF, led by Huawei, POC#33 led by NTT Labs and POC#37 with China Mobile and HPE. These POCs leveraged the Service Function Chaining (SFC) RFCs and draft produced by IETF SFC architecture and contributed to clause 5.8 of the ETSI NFV report. In parallel a review of SDN controller open source projects was performed which indicated that SFC was implemented in a similar way in OpenDaylight based on IETF principles and using LISP and other mechanism quite popular in the market. With OPNFV integrating OpenDaylight and SFC with OpenStack, the road to SDN & NFV is getting brighter and brighter with more and more aligned across the industry.



Marie-Paule OdiniMarie-Paule Odini holds a master's degree in electrical engineering from Utah State University. Her experience in telecom experience including voice and data. After managing the HP worldwide VoIP program, HP wireless LAN program and HP Service Delivery program, she is now HP CMS CTO for EMEA and also a Distinguished Technologist, NFV, SDN at Hewlett-Packard. Since joining HP in 1987, Odini has held positions in technical consulting, sales development and marketing within different HP organizations in France and the U.S. All of her roles have focused on networking or the service provider business, either in solutions for the network infrastructure or for the operation.



Antonio ManzaliniAntonio Manzalini received the M. Sc. Degree in Electronic Engineering from the Politecnico of Turin. In 1990 he joined CSELT, which then became Telecom Italia Lab. He started his activities on research and development of technologies and architectures for future optical networks. In this RTD avenue, he was actively involved in leading positions in several EURESCOM and EC funded Projects (e.g., MWTN, LION, NOBEL). He chaired (during two consecutive Study Periods) two ITU-T Questions on transport networks. He is author of a book on Network Synchronization (for SDH) and his RTD results are published in more than 110 papers. In 2008 he was awarded the International Certification of Project Management by PMI. He was member of technical and program committee of several IEEE Conferences. He is Chairing the IEEE SDN Initiative, leading a technical community of 2600 participants. He is currently joining the Strategy and Innovation Dept. of Telecom Italia addressing innovation activities mainly concerning future Telco-ICT networks and services technologies (e.g., Software Defined Networks, Network Function Virtualization and 5G).



Subscribe to IEEE Softwarization

Join our free SDN Technical Community and receive IEEE Softwarization.

Subscribe Now


Article Contributions Welcomed

Download IEEE Softwarization Editorial Guidelines for Authors (PDF, 122 KB)

If you wish to have an article considered for publication, please contact the Managing Editor at


Past Issues

March 2018

January 2018

December 2017

September 2017

July 2017

May 2017

March 2017

January 2017

November 2016

September 2016

July 2016

May 2016

March 2016

January 2016

November 2015

IEEE Softwarization Editorial Board

Laurent Ciavaglia, Editor-in-Chief
Mohamed Faten Zhani, Managing Editor
TBD, Deputy Managing Editor
Syed Hassan Ahmed
Dr. J. Amudhavel
Francesco Benedetto
Korhan Cengiz
Noel Crespi
Neil Davies
Eliezer Dekel
Eileen Healy
Chris Hrivnak
Atta ur Rehman Khan
Marie-Paule Odini
Shashikant Patil
Kostas Pentikousis
Luca Prete
Mubashir Rehmani
Stefano Salsano
Elio Salvadori
Nadir Shah
Alexandros Stavdas
Jose Verger