ARC: Definitions and requirements
for SO/APP-C/VF-C discussion
including call notes
Chris Donley
July 5, 2017
Agenda
• Review of ONAP Architecture Principles
• Definitions
• Goals/discussion questions
• Possible Deployments
• Vimal
Proposed ONAP Architecture Principles (For Review – from May Developer meeting)

Support Complete Life Cycle Management of Software Defined Network Functions / Services


High Level of Automation at Every Phase of Life Cycle Management – e.g. Onboard, Design, Deployment,
Instantiation, Upgrade, Monitoring, Management, to end of life cycle:








From VNF On-Boarding, Service Definition, VNF/Service Instantiation, Monitoring, Upgrade, to retirement
Rich, User Friendly Design Studio to Capture Full Life Cycle Management (Recipes, Policy, Analytics, etc.)
Common Approach to Manage Various Network Functions from Different Vendors

Standard templates for instantiations

Standard language for configuration

Standard Telemetry for monitoring and management
ONAP Platform is NF / Services / Product Agnostic (each service provider / integrator to use ONAP to manage
their specific environment with artifacts created via Design Studio)
Standard Interfaces for Integrating with External OSS / BSS / VNFM/ EMS systems
Standard interfaces / abstraction layer to support multiple infrastructure and network controllers
Maintain ONAP Platform Integrity while Evolving it to Target End State Vision
Maintain Platform Backward Compatibility with Every New Release
Call note: Jason also drew our attention to: https://wiki.onap.org/display/DW/Draft+Architecture+Principles
3
Definitions
• Orchestration - Wikipedia
- Aligning business request with applications, data, and infrastructure
• Service Orchestrator - Mulesoft
- The coordination and arrangement of multiple services exposed as a single aggregate service
• NFV Orchestrator (NFV-O) - Mehmet Ersue (ETSI NFV MANO Co-Chair at IETF 88)
-
coordinates, authorizes, releases and engages NFVI resources
•
•
•
•
on-boarding of new Network Service (NS), VNF-FG and VNF Packages
NS lifecycle management (including instantiation, scale-out/in, performance measurements, event correlation, termination)
global resource management, validation and authorization of NFVI resource requests
policy management for NS instances
• VNF Manager (VNFM) – Mehmet Ersue
- lifecycle management of VNF instances
• (including instantiation, scale-out/in, termination, etc.)
- overall coordination and adaptation role for configuration and event reporting between NFVI and the E/NMS
• Controller - Margaret Rouse, Techtarget
- configure network devices and choose the optimal network path for application traffic
• Notes from the call: We acknowledged language difficulties crossing between domains (particularly
vis. Controller/manager). We agreed to use ‘controller’ for both ‘controller’ and ‘manager’ for now,
but could revisit if we need to in the future.
Goals and Questions
• Goals
- Flexibility for operator deployment
- Minimize impact to different
components (e.g. DCAE, A&AI)
• Some impacts to SO and possible SDC
- Minimize impact to VNF vendors
• VNFSDK will publish unified VNF
specification format and adapt as
needed to work with ONAP
components
• We expect the architecture to evolve
over time, and this may impact VNF
vendors
- Align with ONAP charter
- Capable of delivering for R1
- Microservices-based
• Questions (Goals? Non-goals?)
-
Avoid replication of functionality?
ETSI MANO alignment?
Feature parity between APP-C/VF-C?
Modular? Well-defined interfaces?
Notes from the call: We agreed that modular, well-defined
interfaces are a key requirement. We might not get there in
R1, but This needs to be our target for R2. We do generally
want feature parity, but it will not be a blocking issue if there
is some divergence. We generally want ETSI alignment, but
it will not be blocking. We want to minimize replication of
functionality (long-term); some will be acceptable as it
allows innovation. Since R1 timelines are short, we might
accept more initially as we work through the integration.
Functional Definitions
• Note: the following definitions apply to functions, not ONAP modules.
Modules will be referred to by their acronyms for clarity (e.g., SO,
APPC, VFC)
• Service Orchestrator is responsible for decomposing a complex
network service into its constituent parts.
a) Decompose service template into connectivity and application components
b) Call controllers/managers to configure the network and instantiate VNFs
Notes from the call: we did not proceed beyond here, as we ran out of
time. Please review these (and the mapping to be sent by Vimal) for
discussion next time.
Functional Definitions (2)
•
NFV orchestrator (including Resource Orchestrator)
a) Management of Network Services deployment templates and VNF Packages (e.g. on-boarding new Network Services and VNF Packages). During on-boarding of NS and
VNF, a validation step is required. To support subsequent instantiation of a NS, respectively a VNF, the validation procedure needs to verify the integrity and authenticity of
the provided deployment template, and that all mandatory information is present and consistent. In addition, during the on-boarding of VNFs, software images provided in
the VNF Package for the different VNF components are catalogued in one or more NFVI-PoPs, using the support of VIM.
b) Network Service instantiation and Network Service instance lifecycle management, e.g. update, query, scaling, collecting performance measurement results, event
collection and correlation, termination.
c) Management of the instantiation of VNF Managers where applicable.
d) Management of the instantiation of VNFs, in coordination with VNF Managers.
e) Validation and authorization of NFVI resource requests from VNF Managers, as those may impact Network Services (granting of the requested operation needs to be
governed by policies).
f)
Management of the integrity and visibility of the Network Service instances through their lifecycle, and the relationship between the Network Service instances and the VNF
instances, using the NFV Instances repository.
g) Management of the Network Service instances topology (e.g. create, update, query, delete VNF Forwarding Graphs).
h) Network Service instances automation management (e.g. trigger automatic operational management of NS instances and VNF instances, according to triggers and actions
captured in the on-boarded NS and VNF deployment templates and governed by policies applicable to those NS and VNF instances).
i)
Policy management and evaluation for the Network Service instances and VNF instances (e.g. policies related with affinity/anti-affinity, scaling, fault and performance,
geography, regulatory rules, NS topology, etc.).
j)
Validation and authorization of NFVI resource requests from VNF Manager(s), as those may impact the way the requested resources are allocated within one NFVI-PoP or
across multiple NFVI-PoPs (granting of the requested resources is governed by policies, and may require prior reservation).
k) NFVI resource management across operator's Infrastructure Domains including the distribution, reservation and allocation of NFVI resources to Network Service instances
and VNF instances by using an NFVI resources repository, as well as locating and/or accessing one or more VIMs as needed and providing the location of the appropriate
VIM to the VNFM, when required.
l)
Supporting the management of the relationship between the VNF instances and the NFVI resources allocated to those VNF instances by using NFVI Resources repository
and information received from the VIMs.
m) Policy management and enforcement for the Network Service instances and VNF instances (e.g. NFVI resources access control, reservation and/or allocation policies,
placement optimization based on affinity and/or anti-affinity rules as well as geography and/or regulatory rules, resource usage, etc.).
n) Collect usage information of NFVI resources by VNF instances or groups of VNF instances, for example, by collecting information about the quantity of NFVI resources
consumed via NFVI interfaces and then correlating NFVI usage records to VNF instances.
Functional Definitions (3)
• VNFM
a) VNF instantiation, including VNF configuration if required by the VNF deployment
template (e.g. VNF initial configuration with IP addresses before completion of the
VNF instantiation operation).
b) VNF instantiation feasibility checking, if required.
c) VNF instance software update/upgrade.
d) VNF instance modification.
e) VNF instance scaling out/in and up/down.
f) VNF instance-related collection of NFVI performance measurement results and
faults/events information, and correlation to VNF instance-related events/faults.
g) VNF instance assisted or automated healing.
h) VNF instance termination.
i) VNF lifecycle management change notification.
j) Management of the integrity of the VNF instance through its lifecycle.
k) Overall coordination and adaptation role for configuration and event reporting
between the VIM and the EM.
Module mappings
• SO:
- Service Orchestrator a&b
- NFV Orchestrator a, c, d, j, k, l
• APPC
- NFV Orchestrator b, g, h
- VNFM a-k
• VFC
- NFV Orchestrator a-n
- VNFM a-k (optional – using OPEN-O G-VNFM; other gVNFM or sVNFM possible)
• DCAE
- NFV Orchestrator b, n
- VNFM f
• Policy
- NFV Orchestrator i, m
Possible deployments
ONAP Controller – Option A (ONS starting point)
Service Orchestrator
New
Current APP-C NBI
APP-C
Os-Nfvo
VF-C
OpenStack/MultiVIM API
VNFs
Or-Vnfm
ONAP Controller – Option B (Jamil)
Service Orchestrator
New
Os-Nfvo
VF-C
New
APP-C
Or-Vnfm
APP-C as VNFM
OpenStack/MultiVIM API
VNFs
ONAP Controller – Option C (Vimal Option 2)
Service Orchestrator
Current APP-C NBI
APP-C
New
Os-Nfvo
VF-C
Or-Vnfm
OpenStack/MultiVIM API
VNFs
ONAP Controller – Option A1 (runtime selection)
Service Orchestrator
APP-C
VF-C
VNFs
ONAP Controller – Option A2 (runtime selection)
Service Orchestrator
APP-C
VF-C
VNFs