5G Use Case Proposal for Dublin Ericsson

This proposal outlines the use of NETCONF for configuration management in 5G networks, focusing on Dublin. It covers topics like Configuration with NETCONF, NETCONF Overview, NETCONF Security, YANG Overview, and Proposed Use Cases and Requirements for Dublin. The proposal emphasizes the importance of supporting both PNFs and VNFs, NETCONF over TLS, and YANG 1.1 modules in addition to YANG 1.0 for efficient network management. It also suggests creating a new 5G sub-case on the ONAP wiki to track progress.

• 5G networks
• NETCONF
• Configuration management
• Dublin
• Ericsson

raina Follow

Uploaded on Aug 06, 2024 | 7 Views

Download Presentation

Please find below an Image/Link to download the presentation.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.

Presentation Transcript

1. 5G Use Case Proposal for Dublin Ericsson

2. Topics Configuration with NETCONF Bulk PM PNF Onboarding (postponed until next week)

3. Configuration with NETCONF

4. 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

5. 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 NETCONF Client Server Transport - Authentication - Data integrity - Confidentiality - Replay protection

6. 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

7. Proposed Use Cases and Requirements Proposed UC to focus on in Dublin for configuration with NETCONF Post-instantiation (triggered by SO) Including final configuration step (36/37) in the PNF PnP UC Configuration modification (e g triggered by Policy) Specific requirements on NETCONF support in ONAP - Officially support both PNFs and VNFs for north-bound controller APIs in the use cases Further discussion about controllers on the following slide - Support for NETCONF over TLS (RFC7589) - Support for YANG 1.1 (RFC7950) modules in addition to YANG 1.0 To track progress of the above items, it is also proposed to create a new 5G sub-case on the ONAP wiki

8. Project Impact Follow up with potentially impacted projects There are two possible controllers: APPC and SDNC How to provide a single NETCONF adapter and avoid duplication Clarify controller internal architecture Blueprint processing -> DGs -> Adapter? Use of shared modules (APPC/SDNC/CCSDK) Role of OpenDaylight and built-in NETCONF client PNF support TLS support YANG 1.1 support APPC SDNC CCSDK Investigate how to trigger configuration action SO NETCONF Policy Investigate AAF impact for NETCONF over TLS Also discuss in SECCOM meeting AAF Update applicable xNF requirements VNFREQS

9. Bulk PM

10. Overview - Casablanca PM support in Casablanca includes: - Data File Collector microservice - Notification: fileReady VES event - UC to collect PM files and distribute via Data Router - DFC listens for 'FileReady' VES events sent from an xNF via the VES collector. - as files become available DFC fetches them. - the collected data files are published internally on a DMaaP Data Router (DR) feed.

11. Overview Dublin PM support in Dublin proposal: - 3GPP PM Mapper microservice - perf3gpp: pmMeasResult VES event - UC to convert PM data from 3GPP XML input to VES pmMeasResult output: - micro-service subscribes to PM feed from DR - measurements from the PM files are extracted and mapped to VES pmMeasResult events

12. PM related Use Cases UC1: 3GPP PM Counter collection and VES creation in ONAP - 3GPP PM Mapper microservice - VES pmMeasResult (run-time, data flows and handling) - PM Dictionary handling (SDC-DS mapping config, artifact distribution) UC2: Closed Loop support using 3GPP PM data - Propose: PM Counter policy trigger of CM update Additional requirements: PM Handling enhancements - DFC robustness enhancement (fileReady for all files on the node; DFC retry handling) - DMaaP DR enhanced handling of PM feeds (enhancements for DFC metadata; optional DR consumer specified feed encoding; high availability and scaling support)

13. Bulk PM File Upload and Performance Event Generation File VES Message Router Data Router Analytics Application PM VES Collector Collector VNF PNF Collector Mapper HTTP/TLS Bulk PM File Upload and Performance Event Generation Network Function (NF) establishes a HTTP/TLS connection to the DCAE VES Collector. 1 Authenticate connection 1 1 HTTP/TLS Send FileReady event 2 NF sends FileReady notification Event to DCAE VES Collector. Event is encoded in JSON and sent via HTTP/TLS. HTTP/TLS connection is set up and torn down every time a FileReady notification event is sent. 2 2 3 Publish Event DCAE VES Collector publishes the event to appropriate topic in DMaaP Message Router (MR). Retrieve Event 4 3 3 FTPES DCAE File Collector retrieves the FileReady notification event from DMaaP MR. 5 Upload PM file 4 4 Publish PM Data + metadata 6 File Collector uploads PM File from NF using a secure file transfer protocol; FTPES supported in Casablanca. NF authenticates the connection. 5 5 Retrieve PM Data +metadata 7 File Collector publishes PM Data to DMaaP Data Router (DR). 6 6 Publish 3GPP Performance Event 8 PM Mapper retrieves PM Data from DR and generates 3GPP Performance events as configured by PM Mapper File. 7 7 Retrieve 3GPP Performance Event 9 PM Mapper publishes Performance events to MR. 8 8 Analytics Applications (AA) retrieve the 3GPP Performance events of interest from MR. AA analyze the data to produce statistics and KPIs and optimization recommendations. 9 9

14. Casablanca 3GPP PM Mapper microservice (Dublin perf3gpp domain specific interactions) Dublin Data Router Message Router 3GPP PM XML DMaaP VES sample VES perf3gpp pmMeasResults file metadata XML sample DCAE create PM event(s) 3GPP PM Mapper 3GPP data Mapping rules DFC 3GPP PM XML metadata Validation: - XML schema compliance Schema file validation schema metadata Design Studio (DCAE-DS) Policy PM PM Mappings PM Configuration Instantiate new or update existing Dictionaries

15. pmMeasResult event schema (json) { "$schema":"http://json-schema.org/draft-04/schema#", "title":"VES Event Listener Common Event Format", "type":"object", "properties":{ }, "definitions":{ "commonEventHeader":{ }, "event":{ }, "eventList":{ }, "internalHeaderFields":{ }, "hashMap":{ }, "perf3gppFields":{ }, "measDataCollection":{ }, "measInfo":{ }, "iMeasInfoId":{ }, "measInfoId":{ }, "iMeasTypes":{ }, "measTypes":{ }, "compactMeasValue":{ }, "measValue":{ }, "integerMeasResult":{ }, "numberMeasResult":{ }, "nullMeasResult":{ } } Schema: Version proposed for Dublin, includes generic stringMeasResult to support vendor specified counter types. JSON schema updated to match rtPM proto as of 10-05, based on proto to json mapping as defined in: } https://developers.google.com/protocol-buffers/docs/proto3#json

16. PM Dictionary support PM measurement definitions (PM Dictionary support) - PM Dictionary artifact proposed for Dublin (Nokia contrib) - Ericsson has proposed some extensions, incl. support for vendor specified measurement types (e.g. string for the result, PM Dictionary describes the contents). PM Dictionary proposed to be included in PNF Package

17. Datafile Collector Enhancements Improve DFC file collection robustness, i.e. missed collection handling - In Casablanca xNF are required to send only new files available for collection in the fileReady notification. As a result, files may be potentially missed e.g. if a fileReady message is lost - fileReady notification update: recommend that as long as a file is still available on the xNF it should be included in the fileReady notification do not propose change to fileReady message, only the contents - xNF which sends only new files in the fileReady still works, but will not benefit from the enhanced handling at DFC add new VNF req to define the improved handling

18. DMaaP Data Router Enhancements DMaaP DR: optional support will allow consumers to specify the encoding for their DR feed: If DR has support, then content is encoded and sent to consumer in requested format If DR has no support, error indicating unsupported encoding requested - DCAE DFC: Small impact. DFC publishes in source format from NF. Same behaviour as Casablanca. DFC provides metadata in DR feed DMaaP DR will introduce a new API minor version update that will A) deprecate ATT specific headers, B) introduce new headers replacing the ATT specific ones, C) pass through header "content-encoding" if supplied by the producer. Producer or Subscriber will be able to use either the old version or new version of the interface. This allows DMaaP to be updated and existing Producers and Subscribers do not need to be updated.

19. 3GPP PM Mapper microservice (consumer specified content encoding) Safe transcoding pub/sub handler (AT&T uSvc contrib??) Casablanca DMaaP Data Router Dublin Files are published from NFs in their native format consumer spec. encoding (e.g. gzip) 3GPP PM XML file Consumers specify preferred encoding Files are collected from NFs in their native format metadata 3GPP PM XML file DFC 3GPP PM XML metadata E.g. 3GPP PM Mapper NF (e.g. 5G PNF)

20. s Thank You!