ETSI GS NFV-EVE 005 V1.1.1 (2015-12)

Network Functions Virtualisation (NFV); Ecosystem; Report on SDN Usage in NFV Architectural Framework

DGS/NFV-EVE005

General Information

• Status: Published
• Publication Date: 17-Dec-2015
• Technical Committee: NFV EVE - Evolution and Ecosystem
• Current Stage: 12 - Completion
• Due Date: 28-Dec-2015
• Completion Date: 18-Dec-2015

Standards Content (Sample)

GROUP SPECIFICATION
Network Functions Virtualisation (NFV);
Ecosystem;
Report on SDN Usage in NFV Architectural Framework
Disclaimer
This document has been produced and approved by the Network Functions Virtualisation (NFV) ETSI Industry Specification
Group (ISG) and represents the views of those members who participated in this ISG.
It does not necessarily represent the views of the entire ETSI membership.

2 ETSI GS NFV-EVE 005 V1.1.1 (2015-12)

Reference
DGS/NFV-EVE005
Keywords
NFV, SDN
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
The present document can be downloaded from:
http://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the only prevailing document is the
print of the Portable Document Format (PDF) version kept on a specific network drive within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying
and microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© European Telecommunications Standards Institute 2015.
All rights reserved.
TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members.
TM
3GPP and LTE™ are Trade Marks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.
ETSI
3 ETSI GS NFV-EVE 005 V1.1.1 (2015-12)
Contents
Intellectual Property Rights . 7
Foreword . 7
Modal verbs terminology . 7
1 Scope . 8
2 References . 8
2.1 Normative references . 8
2.2 Informative references . 8
3 Definitions and abbreviations . 9
3.1 Definitions . 9
3.2 Abbreviations . 9
4 Overview of SDN in the NFV architectural framework. 10
4.1 Introduction . 10
4.2 SDN scope . 10
4.3 SDN in the NFV architectural framework . 11
4.3.1 General . 11
4.3.2 SDN management plane . 11
4.3.3 Position of SDN resources in an NFV architectural framework . 12
4.3.4 Position of the SDN controller in an NFV architectural framework . 12
4.3.5 Position of SDN applications in an NFV architectural framework . 13
4.4 SDN controller interfaces in the NFV architectural framework . 14
4.4.1 Introduction. 14
4.4.2 SDN resource control interface options . 16
4.4.3 SDN controller orchestration interface options. 17
4.4.4 SDN application control interface options . 18
4.5 SDN controller to controller interface in NFV . 20
4.5.1 SDN controller to controller interface options in NFV . 20
4.5.2 SDN controller federation options in NFV . 21
5 Design patterns of SDN in the NFV architectural framework . 21
5.1 Introduction . 21
5.2 SDN technology integration options with NFV . 22
5.2.0 Introduction. 22
5.2.1 Interconnecting VNFCs using SDN . 22
5.2.2 Interconnecting VNFs using SDN . 22
5.2.2.0 Introduction . 22
5.2.2.1 Chaining based on network service designed according to a VNF-FG . 22
5.2.2.2 Chaining based on customer policy/service . 22
5.2.2.3 Chaining based on VNF processing . 23
5.2.2.4 Load balancing across VNF's . 23
5.3 SDN across multiple VIM . 23
5.3.0 Introduction. 23
5.3.1 SDN controller interfaces . 23
5.3.2 Scenarios for SDN across multiple VIMs . 24
5.3.3 Challenges for SDN across multiple VIMs . 24
5.3.4 Analysis of SDN across multiple VIMs . 24
5.3.4.1 SDN across multiple VIMs located in a single NFVI-PoP . 24
5.3.4.2 SDN across multiple VIM in different NFVI-PoPs . 24
5.3.4.2.0 Introduction . 24
5.3.4.2.1 VNFs across multiple NFVI-PoP locations with a static bit pipe between them . 25
5.3.4.2.2 VNFs across multiple NFVI-PoP locations, SDN-based NaaS between them . 25
5.3.4.2.3 VNFs across multiple NFVI-PoP locations - NFVI-PoP and WAN in a common trust domain
(Option A) . 26
5.3.4.2.4 VNFs across multiple NFVI-PoP locations - NFVI-PoP and WAN in different trust domains -
client access to virtual WAN resources (Option B) . 26
ETSI
4 ETSI GS NFV-EVE 005 V1.1.1 (2015-12)
5.3.4.2.5 VNFs across multiple NFVI-PoP locations - NFVI-PoP and WAN in different trust domains -
client access to physical host resources (Option C) . 27
5.3.4.2.6 SDN based NFV IaaS across multiple administration domains . 28
5.3.4.2.7 Multiple VIM for a mobile network . 30
5.4 SDN controller hierarchy . 30
5.4.1 Introduction. 30
5.4.2 Technical and business scenario . 31
5.4.2.1 SDN controller hierarchy scenarios overview . 31
5.4.2.2 SDN controller hierarchy for distributed performance, scalability and reliability for multilayer
and single-layer transport network . 31
5.4.2.3 SDN controller hierarchy for distributed, cross-SP or cross-domain services . 32
5.4.2.4 SDN controller hierarchy for NaaS . 33
5.4.2.5 SDN controller hierarchy for multi-domain, transport network fast fault recover . 33
5.4.3 Mapping of SDN controller to the ETSI NFV architecture . 34
5.4.3.1 Introduction . 34
5.4.3.2 Hierarchy of SDN controllers in the NFVI . 34
5.4.3.3 Hierarchy of SDN controllers in a VNF . 35
5.4.3.4 Hierarchy of SDN controller across functional blocks . 35
5.4.3.5 Hierarchy of SDN controllers below the WIM . 35
5.5 SDN controller in a Virtualised environment . 35
5.5.1 Introduction. 35
5.5.2 Virtualisation of SDN Controller . 35
5.5.3 SDN controller across multiple Virtualised environment . 36
5.6 SDN and VNF forwarding graph . 37
5.6.1 General . 37
5.6.2 Static NCT . 37
5.6.3 Dynamic NCT . 37
5.7 SDN controllers in the tenant and the infrastructure domains . 38
5.8 Service Function Chaining . 40
5.8.1 Introduction. 40
5.8.2 Service Function Chaining (SFC) . 40
5.8.3 SFC and SDN . 41
5.8.4 SFC, SDN and NFV with a single NFVI domain . 42
5.8.4.0 Introduction . 42
5.8.4.1 Service function chain in the NFVI . 43
5.8.4.2 Service function chain in the tenant domain . 45
5.8.4.3 Different options to control a dynamic service chain . 46
5.8.5 End to end carrier network with SFC, SDN and NFV . 47
5.8.6 SFC, SDN, NFV with multi-domain, scalability, etc. . 48
6 Functional recommendations . 49
6.1 Introduction . 49
6.2 Functional recommendations related to security . 52
6.3 Functional recommendations related to SDN controller . 52
6.4 Functional recommendations on connectivity and interfaces . 53
6.5 Functional recommendations on NFV Management and Orchestration . 54
6.5.1 General . 54
6.5.2 Inter-administrative domain connectivity coordination . 54
6.5.3 Support of operations to an SDN controller below the VIM . 55
6.5.4 Support of ordering and charging operations between multiple administrative domains . 55
6.6 Recommendations on operational aspects . 55
Annex A (informative): SDN in ETSI NFV POC . 57
A.0 Introduction . 57
A.1 POC#1: Open NFV Framework Project . 57
A.2 POC#2: Service Chaining for NW function selection in Carrier Networks . 60
A.3 POC#8: Automated Network Orchestration . 62
A.4 POC#13: Multi-Layered Traffic Steering for Gi-Lan . 64
ETSI
5 ETSI GS NFV-EVE 005 V1.1.1 (2015-12)
A.5 POC#14: Forces applicability for NFV and integrated SDN . 66
A.6 POC#15: Subscriber Aware Sgi/Gi-lan Virtualisation . 68
A.7 POC#16: NFVIaaS with Secure SDN-controlled WAN Gateway . 70
A.8 POC#21: network intensive and compute intensive hardware acceleration . 72
A.9 POC#23: E2E orchestration of Virtualised LTE Core-Network functions . 74
A.10 POC#26: Virtual EPC with SDN functions in Mobile Backhaul Networks . 76
A.11 POC#27: VoLTE Service based on vEPC and vIMS architecture . 78
A.12 POC#28: SDN Controlled VNF Forwarding graph . 80
A.13 POC#34: SDN-enabled Virtual EPC Gateway . 84
A.14 POC#38: Full ISO-7 layer stack fulfilment, activation and orchestration of VNFs in carrier
networks . 85
Annex B (informative): SDN Use Cases in NFV environment . 91
B.1 Introduction . 91
B.2 Multi-Layer Bandwidth on Demand . 91
B.2.1 Introduction . 91
B.2.2 Problem Description . 91
B.2.3 Solution Description . 92
B.3 Bandwidth Defragmentation . 92
B.3.1 Problem Description . 92
B.3.2 Solution Description . 93
B.4 Policy Based Configuration . 93
B.4.1 Problem Description . 93
B.4.2 Solution Description . 93
B.4.3 Scope of Policy Based Configuration . 95
B.4.4 Questions raised by Policy Based Configuration . 95
B.5 Virtual CPE . 95
B.5.1 Problem Description . 95
B.5.2 Solution Description . 96
Annex C (informative): Comparison of Opensource SDN Controller . 99
C.1 Introduction . 99
C.2 List of Opensource SDN controller . 99
C.2.0 Introduction . 99
C.2.1 Floodlight . 100
C.2.2 OpenDaylight . 100
C.2.3 OpenContrail . 104
C.2.4 Ryu . 106
C.2.5 ONOS . 108
C.2.5.1 Introduction. 108
C.2.5.2 ONOS Architecture. 109
C.2.5.3 ONOS User Interface . 110
C.2.6 MidoNet . 111
C.3 Comparison criteria . 113
C.3.1 List of Comparison Criteria . 113
C.3.2 Impact of Docker . 114
C.4 Comparison table . 115
C.5 ETSI NFV POC with Opensource SDN Controller . 115
C.5.1 List of POC and Opensource Controller used . 115
ETSI
6 ETSI GS NFV-EVE 005 V1.1.1 (2015-12)
C.6 Lessons learnt . 116
C.7 Other Opensource SDN components. 117
C.7.1 Switch Software and Stand-Alone OpenFlow Stacks. 117
C.7.2 Controller Platforms . 117
C.7.3 Special Purpose Controllers . 117
C.7.4 Misc . 118
Annex D (informative): Authors & contributors . 119
Annex E (informative): Change History . 121
History . 125

ETSI
7 ETSI GS NFV-EVE 005 V1.1.1 (2015-12)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (http://ipr.etsi.org).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This Group Specification (GS) has been produced by ETSI Industry Specification Group (ISG) Network Functions
Virtualisation (NFV).
Modal verbs terminology
In the present document "shall", "shall not", "should", "should not", "may", "need not", "will", "will not", "can" and
"cannot" are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of
provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.

ETSI
8 ETSI GS NFV-EVE 005 V1.1.1 (2015-12)
1 Scope
The present document identifies the most common design patterns for using SDN in an NFV architectural framework. It
also identifies potential recommendations to be fulfilled by the entities that perform the integration.
2 References
2.1 Normative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
reference document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
http://docbox.etsi.org/Reference.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are necessary for the application of the present document.
Not applicable.
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
reference document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] ETSI GS NFV-INF 005 (V.1.1.1) - (12-2014): "Network Functions Virtualisation (NFV);
Infrastructure; Network Domain".
[i.2] ETSI GS NFV-MAN 001 (V1.1.1) - (12-2014): "Network Functions Virtualisation (NFV);
Management and Orchestration".
[i.3] ETSI GS NFV 002 (V1.2.1) - (12-2014): "Network Functions Virtualisation (NFV); Architectural
Framework".
[i.4] ETSI GS NFV 003 (V1.2.1) - (12-2014): "Network Functions Virtualisation (NFV); Terminology
for Main Concepts in NFV".
[i.5] ETSI GS NFV-SWA 001: "Network Functions Virtualisation (NFV); Virtual Network Functions
Architecture".
[i.6] Open Networking Foundation TR-502: "SDN Architecture", Issue 1.0, June 2014.
[i.7] Metro Ethernet Forum (V1.1) (February 2012): "Carrier Ethernet for Delivery of Private Cloud
Services".
[i.8] Recommendation ITU-T Y.3300 (06-2014): "Framework of software-defined networking".
[i.9] IETF SFC Architecture.
NOTE: Available at http://tools.ietf.org/pdf/draft-ietf-sfc-architecture-07.pdf.
ETSI
9 ETSI GS NFV-EVE 005 V1.1.1 (2015-12)
[i.10] IETF Service Function Chain Extension Architecture.
NOTE: Available at https://tools.ietf.org/pdf/draft-gu-sfc-extend-architecture-00.pdf.
[i.11] IETF I2NSF Interface to Network Security Functions.
NOTE: Available at http://datatracker.ietf.org/doc/charter-ietf-i2nsf/. ®
[i.12] Floodlight : http://www.projectfloodlight.org/floodlight/. ®
[i.13] OpenDaylight : http://www.opendaylight.org/.
[i.14] OpenContrail: http://www.opencontrail.org/. ®
[i.15] ONOS : http://onosproject.org/.
[i.16] Ryu: http://osrg.github.io/ryu/. ®
[i.17] Midonet : https://www.midonet.org/.
[i.18] IETF RFC 5493 (April 2009): "Requirements for the Conversion between Permanent Connections
and Switched Connections in a Generalized Multiprotocol Label Switching (GPMLS) Network".
NOTE: Available at https://tools.ietf.org/html/rfc5493.
[i.19] IETF RFC 6830 (January 2013): "The Locator/ID Separation Protocol (LISP)".
[i.20] IETF RFC 7285 (September 2014): "Application-Layer Traffic Optimization (ALTO) Protocol".
[i.21] IETF RFC 7348: "Virtual eXtensible Local Area Network (VXLAN): A Framework for
Overlaying Virtualized Layer 2 Networks over Layer 3 Networks".
NOTE: Available at http://www.rfc-editor.org/rfc/rfc7348.txt.
[i.22] IETF RFC 7426 (January 2015): "Software-Defined Networking (SDN): Layers and Architecture
Terminology".
NOTE: Avaiable at http://www.rfc-editor.org/rfc/rfc7426.txt.
[i.23] IETF RFC 7432: "BGP MPLS-Based Ethernet VPN".
NOTE: Avaiable at https://tools.ietf.org/rfc/rfc7432.txt. ®
[i.24] ONOS Developer's Guide.
NOTE: Available at https://wiki.onosproject.org/display/ONOS/Developer's+Guide.
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the terms and definitions given in ETSI GS NFV 003 [i.4] and the following
apply:
Openflow: trademark from the Open Networking Foundation (ONF) for an SDN standard protocol which enables
remote programming of the forwarding plane
3.2 Abbreviations
For the purposes of the present document, the abbreviations given in ETSI GS NFV 003 [i.4] and the following apply:
DC Data Center
EM Element Manager
ETSI European Telecommunications Standards Institute
FIB Forwarding Information Base (OSI Layer 3 forwarding table)
ETSI
10 ETSI GS NFV-EVE 005 V1.1.1 (2015-12)
HSDN Hierarchical SDN
ISG Industry Standards Group
ITU-T International Telecommunication Union-Standardization Sector
LFIB Label Forwarding Information Base (MPLS forwarding table)
MPLS Multi-Protocol Label Switching
OAM Operation and Management
NCT Network Connectivity Topology
NE Network Element
NFP Network Forwarding Path
POP Point of Presence
SDN Software Defined Networks
SFC Service Function Chaining
SP Service Provider
VTN Virtual Tenant Network
4 Overview of SDN in the NFV architectural framework
4.1 Introduction
ETSI ISG NFV has defined an NFV architectural framework operating on the basis of the principle of separating
network functions from the hardware they run on by using virtual hardware abstraction. The major components in this
framework are (From ETSI GS NFV 002 [i.3]):
• Network Functions Virtualisation Infrastructure (NFVI): subsystem which encompasses Compute, Network
and Storage resources, i.e. the totality of all hardware and software components that build up the environment
in which VNFs are deployed.
• Management and Orchestration (MANO): subsystem which includes the Network Functions Virtualisation
Orchestrator (NFVO), the Virtualised Infrastructure Manager (VIM) and Virtual Network Function Manager
(VNFM).
• Virtual Network Functions (VNFs): deployed in the NFVI.
The present document provides an overview of SDN in relation to this ETSI NFV architectural framework as well as a
summary of current industry work including a comparison of network controllers and PoCs including NFV and SDN.
4.2 SDN scope
Recommendation ITU-T Y.3300 [i.8] defines SDN as 'a set of techniques that enables to directly program, orchestrate,
control and manage network resources, which facilitates the design, delivery and operation of network services in a
dynamic and scalable manner'. Although this broad definition translates in many different ways in terms of
specifications and implementations, most SDN-labelled solutions relocates the control of network resources to
dedicated network elements, namely SDN controllers and might be mapped to the 3-layers reference model depicted in
figure 1.
Figure 1: Concept of SDN (from Recommendation ITU-T Y. 3300 [i.8])
ETSI
11 ETSI GS NFV-EVE 005 V1.1.1 (2015-12)
While there are other possible models, the present document focuses on the model described in figure 1.
Within the NFV architectural framework [i.3], SDN solutions might be used in the infrastructure domain, in the tenant
domain or both.
When used in the infrastructure domain, the SDN controller acts as a Network Controller, as per
ETSI GS NFV-MAN 001 [i.2]. In the present document SDN refers to software control of physical or virtual network
resources that use standard interfaces (open APIs) to facilitate interoperability and evolution in a multi-vendor
environment.
The SDN controller is not necessarily a stand-alone physical entity, e.g. a software component(s) of the VIM. Ideally,
when the SDN technology is used in the infrastructure domain, the VIM, the SDN controller, and the Network
Resources (physical or virtual) form a hierarchy for delivering connectivity services. In some cases, multiple SDN
controllers form a hierarchy across management and resources, depending on the placement of the functionality. The
SDN controller responsibility includes very specific control functions, interfacing with management agents responsible
for control and management functions.
NOTE: SDN applications, SDN controllers and SDN resources come from one or different vendors, and are
typically implemented in different VNF. The NFVO while on-boarding these VNFs would want to know
that they are related and able to communicate with each other.
There is a large landscape of SDN architectures (NFV and non-NFV) and SDN controller functionality encompassing a
variety of capabilities e.g. service negotiation, network element provisioning, and control of resources. This broader
interpretation of SDN is beyond the scope of the present document.
4.3 SDN in the NFV architectural framework
4.3.1 General
As stated above, the focus of the present document lays on how network services and associated resources
implemented, according to an SDN architecture, might be integrated with the NFV architectural framework by
identifying possible design patterns and associated requirements. Many technical and non-technical issues need to be
formulated and answered regarding all the functional entities that constitute this integrated architectural framework,
such as:
• The position of the SDN resources.
• The position of the SDN controller.
• The softwarization & virtualisation of the various SDN entities.
• The interaction between the Element Managers, VNF Managers, SDN controllers and SDN applications that
become enabled VNFs.
• The hierarchy of SDN networks.
• The position of the overlay SDN networks.
• Others.
4.3.2 SDN management plane
IETF RFC 7426 [i.22] discusses the distinction between control and management plane in an SDN environment. In
brief the control plane is mostly responsible for making decisions on how packets are forwarded by one or more
network resources and pushing such decisions down to the network resources for execution, whilst the management
plane is mostly responsible for monitoring, configuring, and maintaining network devices, e.g. making decisions
regarding the state of a network resources.
IETF RFC 7426 [i.22] also discusses the differentiation between these two planes by identifying their characteristics. It
does so by showcasing four characteristics: (1) timescale, i.e. how often and how fast resources are configured and state
persistence; (2) longevity of the state; (3) locality, i.e. centralized or distributed; (4) insights from the CAP theorem, e.g.
the control plane is available, whilst the management plane is consistent.
ETSI
12 ETSI GS NFV-EVE 005 V1.1.1 (2015-12)
Actually the CAP theorem (https://en.wikipedia.org/wiki/CAP_theorem) states that it is impossible for a distributed
computer system to simultaneously provide consistency, availability and partition tolerance.
NOTE: The distinction between the control and management plane has become somewhat muddled due to the
logical centralization of the control plane which is more of the domain of the management plane.
4.3.3 Position of SDN resources in an NFV architectural framework
The first entities to be considered are the SDN resources. Multiple scenarios might be envisaged for their actual location
or for their images:
• Case a: physical switch or router
• Case b: virtual switch or router
• Case c: e-switch, software based SDN enabled switch in a server NIC
• Case d: switch or router as a VNF
In case d the resource might be logically part of the NFVI or belong to an independent tenant's domain. An example of
case d is illustrated in NFV PoC#14 (clause B.5). This PoC has demonstrated the usage of SDN in an NFV environment
by splitting the Service Gateway (SGW) and Packet Gateway (PGW) of the Long Term Evolution (LTE) architecture
into a control and data plane for each, using an open interface, in this case IETF's ForCES. PoC#14 demonstrates that
the data plane functionality might be deployed as VNF and controlled as a network resource.
Figure 2 shows the functional entities in the NFV architectural framework [i.3] for the scenarios identified above.

Figure 2: Possible SDN Resource Locations in the NFV Architectural Framework
(adaptation from [i.3])
4.3.4 Position of the SDN controller in an NFV architectural framework
The second entity in this context is the SDN controller, which interfaces with SDN network resources via the Resource
Control Interface. One SDN controller might interface with multiple SDN network resources.
Multiple scenarios exist to illustrate the possible locations of an SDN Controller in the context of an NFV framework:
• Case 1: the SDN controller is merged with the Virtualised Infrastructure Manager functionality.
ETSI
13 ETSI GS NFV-EVE 005 V1.1.1 (2015-12)
• Case 2: the SDN controller is Virtualised as a VNF.
• Case 3: the SDN controller is part of the NFVI and is not a VNF.
• Case 4: the SDN controller is part of the OSS/BSS.
• Case 5: the SDN controller is a PNF.

Figure 3: Possible SDN Controller Locations in the NFV Architectural Framework
Case 1: SDN controller functionality merged with the VIM functionality, in such case the two functions are not
distinguishable.
Case 2: SDN controller as a VNF is typically the case of an SDN controller Virtualised as a VNF itself, or being
part of a VNF. This VNF might be logically part of the NFVI and therefore belong to a special
infrastructure tenant or belong to an independent tenant.
Case 3: SDN controller in the NFVI is a classic case of SDN controller for the network connectivity in the NFVI,
where the SDN controller is not implemented as a VNF.
Case 4: SDN controller part of the OSS, is illustrated in clause 5.7, figures 27 and 28 as the tenant SDN
controller.
Case 5: SDN controller as a PNF - while this case exists, it has not been studied in the rest of the present
document.
4.3.5 Position of SDN applications in an NFV architectural framework
The third entity to be considered is the SDN application which interfaces with the SDN controller. An SDN application
might interface with multiple SDN controllers. Multiple case scenarios might be envisioned, for the position of the SDN
applications in the NFV architectural framework, such as:
• Case i: as part of a PNF
• Case ii: as part of the VIM
• Case iii: Virtualised as a VNF
• Case iv: as part of an EM
• Case v: as part of the OSS/BSS
ETSI
14 ETSI GS NFV-EVE 005 V1.1.1 (2015-12)

Figure 4: Possible SDN Application Locations in the NFV Architectural Framework
The positions of the SDN applications are further expanded:
Case i: the network hardware might be a physical appliance talking to an SDN controller, or a complete solution
including multiple SDN components, such as SDN controller + SDN application for instance.
Case ii: the VIM might be an application interfacing with an SDN controller in the NFVI - for instance OpenStack
Neutron as a VIM interfacing with an SDN controller in the NFVI.
Case iii: the SDN application might be a VNF talking to
...