Atlassian uses cookies to improve your browsing experience, perform analytics and research, and conduct advertising. Accept all cookies to indicate that you agree to our use of cookies on your device.
Atlassian uses cookies to improve your browsing experience, perform analytics and research, and conduct advertising. Accept all cookies to indicate that you agree to our use of cookies on your device. Atlassian cookies and tracking notice, (opens new window)
The PNF Registration and Re-registration Notification is generated whenever the a CPE is plugged into the network either for the first time (registration) or whenever the CPE is plugged into a different interface of an access node in the network (re-registration).
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 for processing by the DCAE/PRH uS.
BBS Flows Cross Reference
The PNF Registration notification is used within the following use case scenarios:
The PNF Registration Flow is documented here for the BBS use case.
PNF Re-registration Flow
Figure 1. BBS PNF Registration and Re-registration Notification Flow Diagram
Here are the flow by steps:
10) Access SDN M&C reports the PNF registration event to DCAE/PRH
20) DCAE/PRH then processes the PNF registration event logic where PRH determines if the event is a registration or re-registration event.
30) For the PNF re-registration, the BBS uS:
30.1) consumes PNF_UPDATE event from DMAAP,
30.2) looks up the service-instance-id by the pnf-name, checks PON UNI attachment point in 'additionalFields' against the attachment point in the PNF.
30.3) looks up a list of resources to be updated
30.4) triggers the Nomadic ONT policy
40) Updates the orchestration status of the CFS service instance in A&AI where an event is then emitted to indicates the resources of the service still need updated
50) SDNC API conducts the service resource re-provisioning upon the ONT location change. The PNF attachment point is updated upon successful provisioning.
60) Updates the orchestration status of the CFS service instance in A&AI where an event is then emitted to indicate the resources of the service have been updated
The BBS Use uses the ONAP pnfRegisration event with additional fields to identify the Access Node UNI to which the CPE is attached.
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:
attachment-point: Format: "<oltName>/<oltSlot>/<oltPort>" <x> denotes element
remote-id: Format: string - This represents the Remote ID within the DHCP Option 82 (Optional)
c-vlan: Format: int - This represents the Customer VLAN associated with the attachment point (Optional)
s-vlan: Format: int - The represents the Service VLAN of network interface connected to the attachment point (Optional)
PRH Extension
PNF Re-registration Detection
Refer to PNF Re-registration detection logic handled in 5G use case by extension of PRH micro-service.
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.
Policy
There are two options to author and execute the Nomadic ONT policy - Apex PDP(Pdp-A) or Drools PDP(Pdp-D).
Apex Engine Triggering
Apex PDP engine is configured to consumes the Nomadic ONT event/DCAE-CL_OUTPUT event from DMAAP and call the SDNC Rest API to take resource re-provisioning actions in the original design in Dublin. Later on, a workaround approach is taken for the BBS MS to consume the pnfUpdate event produced by PRH and eventually calls SNDC API to proceed the service associated resource re-provisioning after certain A&AI query and update. Therefore, the policy engine configuration and policy definition becomes very simple for the time being. The only reason for now to keep a no action policy is for the completeness of the control loop so that to the BBS workflow it is actually an open loop so that a CL can be defined and managed by CLAMP through which DCAE micro-services, such as, Restconf Collector, VES Mapper, PRH as well as the BBS MS can be orchestrated centralized.
Apex Policy for Nomadic ONT is created as following. It can be on-board as part of the service Tosca module at design time, distributed to an Apex PDP engine by the policy distribution engine through SDC.
NomadicONT Policy Model (WIP)
This is the Apex Policy state machine for Nomadic ONT. An open loop operational policy is going to be defined here to support the completeness of control loop in BBS use case in Dublin.
API for updating the service-instance is the same as before and only this one need to be called twice during ONT Relocation Policy execution.
PUT
/business/customers/customer/{global-customer-id}/service-subscriptions/service-subscription/{service-type}/service-instances/service-instance/{service-instance-id}
A&AI APIs Called Indirectly Through SO/SDNC
To update the attachment point of the PNF, when the old logical-link object is deleted, it should be automatically removed from the pnf relationship-list, then create a new logical-link object and PUT it into the pnf relationship-list, e.g. as the following
PUT /network/pnfs/pnf/{pnf-name}/relationship-list/relationship
To update the metadata on the service-instance, use the PUT on the metadatum objects. If there are new objects, then add them to the relationship-list on the cp/pnf/generic-vnf, etc, e.g. as the following
PUT /business/customers/customer/{global-customer-id}/service-subscriptions/service-subscription/{service-type}/service-instances/service-instance/{service-instance-id}/metadata/metadatum/{metaname}
PUT
/network/generic-vnfs/generic-vnf/{vnf-id}/relationship-list/relationship
Design Time Artifacts
DCAE-DS
Micro-service Blueprints
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.