1. 5G Use Case Configuration & PNF SW Upgrade using NETCONF ONAP DDF, Jan 9, 2019
Ericsson

2. Contents Introduction to NETCONF and YANG
Dublin Use Cases and Requirements
SO and Controller Workflows
Controllers and API Options
Proposed design
Links

3. NETCONF Overview
NETCONF is an RPC-based protocol to manipulate and monitor configuration and state of network devices
Latest version is defined in RFC6241
It is one of the options included in ONAP xNF requirements for configuration management
It is expected to be used for management of PNFs and VNFs in 5G networks
YANG solution set has been defined by 3GPP for the 5G NRM (28.541)
ONAP
Controller
NETCONF
PNF/VNF

4. NETCONF Security
NETCONF assumes that security is provided by the chosen transport protocol
NETCONF over SSH (RFC6242) is mandatory but other options have also been standardized
NETCONF over TLS with mutual X.509 authentication (RFC7589)
ONAP security sub-committee has recommended use of NETCONF over TLS
Secure Communication to Network Functions
Authenticated client identity passed to NETCONF layer for access control
Client
Server
NETCONF
Transport
- Authentication - Data integrity - Confidentiality
- Replay protection

5. YANG Overview
YANG is a data modeling language intended for use with network management protocols such as NETCONF
Can describe configuration data, state data, RPCs and notifications
The latest version is YANG 1.1 described in RFC7950
But this RFC doesn’t obsolete YANG 1.0 described in RFC6020
A NETCONF server can support a mix of YANG 1.0 and 1.1 modules, subject to some constraints listed in RFC7950
ONAP currently mandates use of YANG 1.0
But in the future modules defined both by SDOs and vendors will increasingly use the latest version

6. Dublin Use Cases and Requirements
Proposed Use Cases for Dublin
Post-instantiation configuration of PNF or VNF using NETCONF (triggered by SO)
For PNFs, overlaps with PnP use case (step 36/37)
(Stretch goal) Configuration modification (e g triggered by Policy)
Possible impacts related to controller APIs and PNF support
(Stretch goal) In-place PNF SW Upgrade (continuation)
In Casablanca, PNF upgrade was demonstrated using communication from controller to external EM
In Dublin, look at upgrade option where controller communicates directly with PNF using NETCONF
Specific requirements on NETCONF support in ONAP
Officially support both PNFs and VNFs for north-bound controller APIs in the use cases
Support for NETCONF over TLS (RFC7589)
Support for YANG 1.1 (RFC7950) modules in addition to YANG 1.0
This is generic functionality, but wanted for 5G

7. PNF PnP Configuration Step
36-37: Configure PNF

8. ONAP Controller (SDNC/APPC)
PNF SW Upgrade
Upgrade via external EM, partially implemented in R3
Direct upgrade option for Dublin and beyond
Operator requests execution of PNF SW upgrade workflow
SO checks the PNF entry and identifies the appropriate Controller
SO requests SW upgrade pre-check
Controller performs all necessary upgrade pre-checks
SO requests SW upgrade
Controller performs software upgrade steps including download of SW to the PNF and then activating it
SO requests SW upgrade post-check
Controller performs all necessary upgrade post-checks
Controller updates A&AI
Controller steps 3-5 are PNF-specific and should be model-driven
Operator
(e.g. VID/UUI, timer) SO
PNF
A&AI
(1)
(2)
(3)
(4)
(5)
(6)
DCAE
PRH
ONAP Controller (SDNC/APPC)

9. SO and Controller Workflows
Re-usable building blocks
Assumes standard controller APIs
Flexibility in how building blocks are combined
Include/exclude
One-touch or multiple steps SO
VNF Creation
PNF Registration
Configuration
In-place Upgrade (PNF)
Pre-condition
pre-check/ upgrade/ post-check
Detailed PNF/VNF-level workflows
Examples of steps are instance data lookup, template processing and download
Must be possible to model per PNF/VNF type
In addition same type can have different requirements for different services where it is included
configure/ activate
Controller

10. Controllers and API Options
In Dublin there will be three controller APIs related to CM and LCM with own implementations and design tools
The two LCM APIs share syntax, but implementation differences means duplication of effort
The new Self-service API can potentially replace both in the future but is not backwards compatible (neither API or workflow nodes)
New in Dublin, provided by the CDS blueprint processor mS
CCSDK
Clone of APPC API with different, more basic implementation
LCM API
Self-Service API
SDNC
APPC
LCM API
Self-Service API
appc-provider-lcm
LCM API
Self-Service API
Main APPC API today, VNF only
Present but not used?

11. Self-Service API ”commonHeader”, ”actionIdentifiers”: {
”blueprintName”,
”blueprintVersion”,
”actionName”,
”mode” },
”payload”
Self-contained controller blueprint archive (CBA)
...
workflows:
workflowName:
steps:
Self-Service API request
This is the CDS run- time component
Blueprint Processor
DmaaP listener(?), HTTP or gRPC endpoint
<<Artifact>>
Workflow Engine
Distributed to run-time from SDC
Capability Components

12. Proposed Design (Configuration UC)
Configuration with NETCONF - Status Update
Proposed Design (Configuration UC)
Other APIs
Self-Service API
Controller
Controller Core
Blueprint Processor mS
DmaaP listener, RESTCONF endpoints
DmaaP listener(?), HTTP or gRPC endpoint
Service Logic Interpreter
Workflow Engine
Service Logic Plugin
Capability Component 2 1
ODL
RESTCONF
Keys and certificates for TLS
NETCONF/TLS
To be used for for upgrade also?
PNF/VNF

13. Wiki Links
5G - Configuration with NETCONF
5G - PNF SW Upgrade

14. Thank You!