Table of Contents | ||
---|---|---|
|
Introduction
The BBS approach is to take advantages of the existing ONAP implementation as much as we can. In Nomadic ONT scenario, ONT is logically modeled to PNF. Restconf collector introduced in R3 is reused to collect ONT relocation notification. The notification will be converted into VES pnf registration event by VES Mapper micro service. PRH, which is the generic PNF Registration Handler micro service in ONAP, is enhanced to cover PNF re-registration logic. This newly defined PNF re-registration event triggers Policy engine to take actions over SDNC component to fulfill the ONT relocation procedure.
...
Nomadic ONT Flow (Original)
...
BBS Flows Cross Reference
The PNF Registration notification is used within the following use case scenarios:
PNF Registration and Re-registration Flow
Gliffy Diagram | ||||
---|---|---|---|---|
|
Gliffy Diagram | ||||||
---|---|---|---|---|---|---|
|
Figure 1. Nomadic ONT Flow Diagram
Here are the flow by steps:
- Access SDN M&C reports the ONT registration event to DCAE/PRH
- DCAE/PRH checks if there is an existing PNF entry in AAI for the ONT and if the service associated with this ONT is activated, post pnfUpdate events on DMAAP.
The BBS MS consumes pnfUpdate event, carries on ONT PNF updates in A&AI and publishes a Nomadic ONT event/DCAE_CL_Event with that CFS id from AAI on DMAAP.
- Policy engine will call SO API upon the DCAE_CL event based on the BBS ONT moving operational policy pre-deployed to it.
- SO serviceModification API initiates the service re-provisioning procedure per ONT location change.
- After ONT is back online, Edge SDN M&C will sent a RG Activation notification to ONAP to indicate the completion of Nomadic ONT.
- Upon receiving CPE Authentication event from DMAAP, BBS MS calls SO
...
- API to update the HSIA service based on the RG/CPE attributes within the event body.
DCAE
Restconf Collector
The APIs to Access SDN M&C leverage those specified
...
Figure 2. Domain Controller ↔ Restconf Collector Interfacing Diagram
In case of BBS Nomadic ONT, Restconf collector subscribes both of ONT Registration and RG Activation notifications through separate SSE connections with Access SDN M & C , each of the connection handler is assigned at design time to build JSON message with different topics of Restconf_Notification with certain Restconf2VES XML file indicator (in OID field for the time being ). The SB domain controller IP/port, authentication information and produced topic could be assigned at design time at blue print creation through DCAE-DS and configurable at control loop creation time from CLAMP.
ONT Registration Notification
Following is an example of ONT Registration notification received from Access SDN M&C - the domain controller.
Code Block | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
[
{
“notification” :
{
“event-time”: ”2018-03-15T08:15:32.000Z”,
“notification-id”: ”2541256”,
“message”:
{
“topic”:“resource”,
“object-type”:“ont”,
“version”: ”v1”,
“operation”: “Create”,
“target”: ”ont/ont=23hk1231231232”,
“content”:
{
“ont”:
{
“ontSN”:“48575443FA637D1A”,
“neName”:“MA5800T-001”,
“neUNIPort”:“0/1/6”,
“onuID”:“101”,
“accessID”:“HG65875420001”,
“remark”:“”,
}
}
}
}
}
] |
The output of Restconf Collector for the ONT Registration is the above JSON message being published on DMAAP with topic of RestConf_ONT_Registration.
RG Activation Notification
Following is an example of RG Activation notification received from Edge SDN M&C - the domain controller.
Code Block | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
[
{
“notification”
{
“event-time”: ”2018-04-15T08:15:32.000Z”,
“notification-id”: ”2541256”,
“message”:
{
“topic”:“resource”,
“object-type”:“Gateway”,
“version”: ”v1”,
“operation”: “Create”,
“target”: "Gateway/sn=83575443FA637D1A”,
“content” :
{
“Gateway”:
{
“gatewaySN”:“83575443FA637D1A”,
“mac”:“28-6E-D4-89-34-DD”,
“pppoeUserName”: ”587564@163.com”,
“ip”: "10.68.52.158”,
“state”:”Online”,
“ontSN”:“48575443FA637D1A”
}
}
}
}
}
] |
The output of Restconf Collector for the RG Activation is the above JSON message being published on DMAAP with topic of RestConf_RG_Activation.
DC=Domain
...
Controller RCC=Restconf Collector thread UVA=Universal VES Adaptor
...
thread SSE=SSE Connection
ORN=ONT Registration
...
Notification RN=Restconf Notification
...
topic PNF_R=PNF Registration Event
RAN=RG Activation Notification CPE_A=CPE Authentication
...
Event PRH=PNF Registration
...
Handler PU= PNF Update
Figure 2. Logic flow of Restconf Collector vs VES Mapper
VES Mapper
Restconf2VES Mapping
The Restconf2VES mapping rule (*.xml) is provided by the vendor for certain type of notification for ONT and defined as the following:
Code Block | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
The default mapping artifact (xml file) name is specified at the design time in VES Mapper micro-service blueprint at DCAE-DS and it is configurable through CLAMP at control loop creation time. The pre-condition is that the mapping file with correct naming convention should be available or on-boarded and stored in ONAP at design time. When the Nomadic ONT control loop is deployed, the mapping files retrievable and loaded to VES Mapper working space.
PNF Registration Event
VES Mapper converts the ONT Registration notification JSON message from DMAAP into the following PNF Registration event.
Code Block | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
This pnfRegistration Event definition can be found at link:
https://wiki.onap.org/display/DW/5G+-+PNF+Plug+and+Play#id-5G-PNFPlugandPlay-STAGE3-PNFREGISTRATIONVESEVENT
The field definitions use for the BBS Use case for ONT Registration:
eventName: pnfRegistration_<vendorName>_cpe
eventId: unique per CPE proxied – incremented as described
sourceName: <PNF-name/PNF correlation ID>: Format string: <Manufacturer
OUI>-<SerialNumber> or <Manufacturer OUI>-<Model>-<SerialNumber>
reportingEntityName:<thirdparty-sdnc-id> from esr request
additionalFields:
oltName: <OLT name>
oltPONSlot: <OLT PON Slot>
oltPONPort: <OLT PON Port>
|
PRH Extension
PNF Re-registration Detection
Refer
...
...
detection logic handled in 5G use case by extension of PRH micro-service.
PNF for ONT in A&AI
Refer to ONT/PNF definition
...
in ONT modeling.
PNF pnfUpdate Event
This event is the output of PRH active service detection and is consumed by BBS MS.
Code Block | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
Nomadic ONT Event/DCAE_CL_OUTPUT Event (WIP)
This event triggers Policy engine to call SO API to modify the associated HSIA service.
DCAE_CL_OUTPUT Event
Code Block | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
{
"closedLoopEventClient": "DCAE.BBS_mSInstance",
"policyVersion": "1.0.0.5",
"policyName": "Nomadic_ONT",
"policyScope": "service=HSIAService,type=SampleType,closedLoopControlName=CL-NomadicONT-d925ed73-8231-4d02-9545-db4e101f88f8",
"target_type": "VM",
"AAI": {
"service-information.service-instance-id" : "service-instance-id-example",
"pnf.ontSN" : "ontSN-example" //...what ever this is
},
"closedLoopAlarmStart": 1484677482204798,
"closedLoopEventStatus": "ONSET",
"closedLoopControlName": "ControlLoop-BBS-2179b738-fd36-4843-a71a-a8c24c70c88b",
"version": "1.0.2",
"target": "vserver.vserver-name",
"requestID": "97964e10-686e-4790-8c45-bdfa61df770f",
"from": "DCAE"
} |
A&AI Enrichment
The moving ONT associated (through pnfName) service ID is looked up in A&AI and enriched in the A&AI portion of the above DCAE_CL_OUTPUT Event which trigger the operational policy in the operational policy defined below.
Update Service Micro-service
A new micro-service, ONAP Micro-Service or ONAP SM SDK, that handles RG Online (or activation) notification will be introduced to consume a new type of VES event. This event is converted from RG Activation notification by VES Mapper.
The characters of this generic micro- service could be the following:
- hold a set of REST APIs
- consume VES events from DMAAP and the consumed event types will be configurable at both the design time and run time
- publish VES events to DMAAP and the published event types will be configurable at both the design time and run time
- run A&AI query A&AI enrichment logic
The Update Service MS could be built on top of DCAE service SDK ( https://gerrit.onap.org/r/#/admin/projects/dcaegen2/services/sdk - R4). A MS blueprint is defined at DCAE-DS and this service can be deployed from CLAMP or can be instantiated as a standalone container when DCAE is deployed.
Both pnfUpdate and CPE Authentication events will be consumed by this micro-service. HSIA re-provisioning action is triggered through Policy executing Nomadic ONT operational policy, while CPE Authentication event triggers HSIA service update by marking it as activated.
RG Activation(CPE Authentication) Event
This event is converted from the RG Activation notification by VES Mapper. Upon receiving this event UpdateService MS will look up for the associated HSIA service and trigger Policy engine to mark (calling SO API?) the service as activated.
Example in VES StateChange domain
The CPE Authentication Event is
...
defined here
...
in VES StateChange domain. It indicates if the ONT/CPE is successfully authenticated at the Edge after the ONT/CPE relocation is completed.
Policy
Apex Engine Triggering
PDP-A Configuration (JSON)
Code Block | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
Policy Schema
Logic Artifacts
Pdp-D Option
Operational Policy
Code Block | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
ontrolLoop:
version: 2.0.0
controlLoopName: ControlLoop-BBS-2179b738-fd36-4843-a71a-a8c24c70c88b
trigger_policy: unique-policy-id-16-ServiceModify
timeout: 3600
abatement: false
policies:
- id: unique-policy-id-16-ServiceModify
name: Connectivity Reroute
description:
actor: SO
recipe: serviceModification
target:
type: VM
retry: 3
timeout: 1200
success: final_success
failure: final_failure
failure_timeout: final_failure_timeout
failure_retries: final_failure_retries
failure_exception: final_failure_exception
failure_guard: final_failure_guard |
SO Recipe
Design Time
DCAE-DS
Micro-service Blueprints
Code Block | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
CLAMP
Control Loop (Micro-service) Orchestration
There are basically 2 ways of CL creation and micro-service orchestration in BBS Nomadic ONT scenario.
- Restconf collector + VES Mapper + PRH + Policy Engine
- VES Collector + PRH + Policy Engine
Notes:
Interestingly, this is the first case where DCAE/Policy seem playing roles together in a non-closed/loop or service assurance in sense of usage/solution in ONAP domain, However, this does not really matter in the sense of micro services since service is a service as long as it provides the functionality that meets the requirements in a solution, An argument could be that Policy engine does not have to be introduced in this case, However, the important functionality for policy engine is to decouple action takers from the trigger pullers and ultimately establish robust policy driving on this platform w/o code change.
...