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

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

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

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

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

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

PNF PnP Configuration Step 36-37: Configure PNF

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)

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

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?

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

Proposed Design (Configuration UC) Configuration with NETCONF - Status Update 2018-12-19 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

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

Thank You!