| Table of Contents | ||
|---|---|---|
|
Introduction
The CPE Authentication Notification is generated whenever the authentication state of gateway functionality associated with a CPE (e.g., ONT) changes from either Authenticated to Unauthenticated and vice-versa.
Upon reception of the notification within ONAP by a DCAE collector, the notification is mapped into a VES event and placed on the DMaaP bus by the DCAE/BBS uS which then processes the event invoking a Policy to update the subscribers HSIA CFS. The DCAE, Policy and SO interactions and associated artificat definitions are defined in this document.
BBS Flows Cross Reference
The CPE Authentication notification is used within the following use case scenarios:
CPE Authentication Flow
| Gliffy Diagram | ||||
|---|---|---|---|---|
|
The above diagram reflects the interactions that updates the HSIA service's operation state with the following steps:
10) Edge SDN M&C reports the CPE Authentication Notification to DCAE RestConf VES Collector
The Restconf VES Collector/Mapper receives the CPE Authentication Notification and using the logic and structure defined in the Restconf Collector and VES Mapper for BBS places a CPE Authentication VES Event onto the DMaaP bus.
The domain of the VES Event is defined in this document.
20/30) This section is still under discussion (what uS can we use to trigger a Policy in order kick-off BPMN recipe that updates the state of the HSIA CFS and sends an external notification through the External API.
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.
CPE Authentication VES Event
The CPE Authentication VES event is defined as follows:
| Field | Type | Required? | Description |
|---|---|---|---|
Version | number | Yes | Version of the event header.See the VES Event Specification for the correct digits to use. |
eventName | string | Yes | StateChange_<vendorName>_cpe_authentication |
domain | string | Yes | stateChange |
eventId | string | Yes | Event key that is unique to the event source cpe_authentication_yyyyyyyy where yyyyyyyy is an integer starting at 0 and incremented by 1 for every CPE Authentication event sent by this CPE. The key must be unique within notification life cycle similar to EventID from 3GPP. It could be a sequential number, or a composite key formed from the event fields, such as domain_sequence. The eventId should not include whitespace. |
eventType | string | No | applicationNf |
sourceId | string | No | UUID identifying the entity experiencing the event issue (note: the AT&T internal enrichment process shall ensure that this field is populated) Not used |
sourceName | string | Yes | Name of the entity experiencing the event issue <PNF-name/PNF correlation ID>: Format string: <Manufacturer OUI>-<SerialNumber> or <Manufacturer OUI>-<Model>-<SerialNumber> |
reportingEntityId | string | No | UUID identifying the entity reporting the event, for example an OAM VM (note: the AT&T internal enrichment process shall ensure that this field is populated) Not used |
reportingEntityName | string | Yes | Name of the entity reporting the event, for example, an EMS name. May be the same as the sourceName. For synthetic events generated by DCAE, it is the name of the app generating the event. <thirdparty-sdnc-id> from esr request |
priority | string | Yes | Processing priority enumeration: ‘High’, ‘Medium’, ‘Normal’, ‘Low’ Normal |
startEpochMicrosec | number | Yes | the earliest unix time aka epoch time associated with the event from any component--as microseconds elapsed since 1 Jan 1970 not including leap seconds current time |
lastEpochMicrosec | number | Yes | the latest unix time aka epoch time associated with the event from any component--as microseconds elapsed since 1 Jan 1970 not including leap seconds current time |
sequence | integer | Yes | Ordering of events communicated by an event source instance (or 0 if not needed) 0 |
internalHeader Fields | Internal Header Fields | No | Fields (not supplied by event sources) that the VES Event Listener service can use to enrich the event if needed for efficient internal processing. This is an empty object which is intended to be defined separately by each provider implementing the VES Event Listener. Empty. Not used |
| vesEventListenerVersion | string | Yes | Version of the VES event listener API Spec that this event is compliant with (As "#" or "#.#" or "#.#.#" where # is a digit. |
| timeZoneOffset | string | No | Offset to GMT to indicate local time zone for device formatted as 'UTC+/-hh.mm'; see https://en.wikipedia.org/wiki/List_of_time_zone_abbreviations for UTC offset examples |
stateChange FieldsVersion | number | Yes | Version of the stateChangeFields block as "#.#", where # is a digit (currently: 1.0). See the VES Event Specification for the correct digits to use. |
serialNumber | string | Yes | TS 32.692 serialNumber = serial number of the PNF; e.g. 6061ZW3 |
| modelNumber | string | No | TS 32.692 versionNumber = version of the unit from vendor; e.g. AJ02. Maps to AAI equip-model used when registering the PNF. |
vendorName | string | Yes | TS 32.692 vendorName = name of manufacturer; e.g. Nokia. Maps to AAI equip-vendor used when registering the PNF. |
macAddress | string | Yes | MAC Address of the RG for the PNF |
| accessID | string | No | The Access Id associated with the HSIA service Internet profile |
newState | string | Yes | New state of the entity: ‘inService’, ‘maintenance’, ‘outOfService’ (Authenticated = inService, Unauthenticated = outOfService) |
oldState | string | Yes | Previous state of the entity: ‘inService’, ‘maintenance’, ‘outOfService’ (Authenticated = inService, Unauthenticated = outOfService) |
stateInterface | string | Yes | Card or port name of the entity that changed state Empty. Not used |
Policy
Apex Engine Triggering
PDP-A Configuration (JSON)
| language | text |
|---|---|
| firstline | 1 |
| title | Nomadic ONT PDP-A Configuration |
| linenumbers | true |
| collapse | true |
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
| language | text |
|---|---|
| firstline | 1 |
| title | MS Blueprints |
| linenumbers | true |
| collapse | true |
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.