Meeting notes 10/07/2018
- Michael Lando
Meeting notes:
Presentation by 5G about there proposal for PNF support in SDC.
summery thanks to @Benjamin Cheung
FAULT/ALARM DICTIONARY REVIEW
ALARM DICTIONARY INDEX – We discussed questions from Ericson (Oskar and Rebecca) on the Nokia proposal for the Fault & Alarm Dictionary (Nokia/Ben C. and Marge). There was a concern that the ALARM ID would be confused with the 3GPP TS32.111 definition for Alarm Id, which indicates an instance ID rather than an alarm index number. We all discussed a new more appropriate name and arrived at “ALARM DICTIONARY INDEX”. This would be an index into the Alarm Dictionary with a value that could be specified in the incoming VES event.
VES EVENT OVERLAP – Rebecca raised some concern that the Alarm Dictionary and the VES Fault event has overlapping information. The thought is that information in the VES Fault Event contains all the information would needed by Analytics events. In our discussion though of the fields we see that only 3 out of the 13 fields have direct mapping to the VES fault event.
ALARM DICTIONARY OPTIONAL USAGE – Ericsson suggested that we add in the VES Fault event an optional field called “ALARM DICTIONARY INDEX” which can be used to indicate the actual Alarm Dictionary Index number. This number would be filled out by the PNF when it sends the VES Fault Event. Because this field is optional, if this were not filled with anything, this would mean that this alarm does not have an Alarm Dictionary entry, or that an Alarm Dictionary is not used. This design would allow for the Alarm Dictionary itself to be optional in case some vendors do not wish to support a dictionary.
ALARM DICTIONARY RAISON D’ETRE – We discussion the purpose, meaning, and application of an Alarm Dictionary. There was a discussion of why it was needed, and how it might be used. Ben described that an Alarm Dictionary can have 3 purposes: (1) DICTIONARY - it allows for a readily accessible body of the entire set of alarms & faults that are managed by a PNF. It would allow for an operator to see all of the alarms & faults of a PNF without having to wait for individual alarms & faults to arrive in ONAP. (2) Analytics facilitator – A dictionary would allow for a variety of vendor specific (or vendor agnostic) analytics applications to be developed. There are a variety of fields in the Alarm Dictionary that would facilitate such analytics capabilities as correlation, escalation, isolation, recovery actions, self-healing, and life cycle management functions. (3) GENERAL ANALYTICS – The strength of ONAP is the potential ability to coordinate information from multiple sources, different vendors, and disparate types of NFs. A dictionary can form the foundation for generalized analytics that are vendor agnostic.
FAULT DICTIONARY – There was a discussion about why a fault dictionary was needed, and how it was different from an Alarm Dictionary. Ben described that a Fault can be a condition encountered in run-time that does not necessarily create a customer-facing alarm. An alarm is intended to result in a visual notification to a service provider to take action. An analogy would be the “Check engine” light in your car which would correspond to an Alarm. A solenoid, a carburetor, or distributor fault all might lead to a “Check engine” light. A driver (service provider) may not be able to directly act on the specific fault (or indeed care about the fault); but when the “check engine” light went on would know to take some action (go to the service station).
DELIVERY IN CASABLANCA – We believe that the use of dictionaries cannot make it into R3 Casablanca, so this would be work in Dublin (R4) release. We discussed a statement made by Michael Lando who said on July 3, that no additional artifacts can be supported in R3, that these discussions we have been having in the modeling calls w.r.t. to the FM, PM dictionary is mature enough to go “live”.
PNF MODELING
MODELING PARAMETERS – We discussed the PNF modeling parameters, pnfExtConnPt, contactID, pnfSWVersionList, PackageVersion and NF Controller. It was our understanding that these should be incorporated into the Generic PNF Template. We thought this was already a “done deal” and there were no further open issues per se with this. So it is an open point to still discuss can this be incorporated into R3 Casablanca. Perhaps we should have a discussion on this sooner than next Tuesday (July 19).
NF CONTROLLER – A new parameter suggested from our A&AI discussion with Christina is the addition of a NF controller parameter in the PNF model. This would indicate the kind of controller that this PNF uses. These might be APP-C, SDN-C, VF-C for instance. This would be set by the operator during design time, and it might affect how information is distributed to components in ONAP. For example if APP-C was the controller indicated for this PNF, APP-C would know if the distributed artifacts are relevant for it.
A&AI DISCUSSION – We discussed the four parameters that we suggested to add to A&AI (Geo-location info, Active/Passive S/W version(s), Cloud home, and Manager IP address. The results of these discussions are captured in the PnP Plug and Play A&AI project impacts. This requires further discussion
MANAGER IP ADDRESS – We discussed the CM Use Case & Software Management Use Case (Hwawei) which is asking for the EMS to take commands from ONAP. And Christina’s suggestion of modeling the EMS as a PNF and modeling it as having a connection with the PNF. This also needs further discussion.
Action items:
Recording:
Chat:
Links:
5G Use Case Web Page URL:
https://wiki.onap.org/display/DW/Use+case+proposal%3A+5G-+RAN+deployment%2C+Slicing%2C+SON
Direct Document Link:
FAULT/ALARM DICTIONARY REVIEW
ALARM DICTIONARY INDEX – We discussed questions from Ericson (Oskar and Rebecca) on the Nokia proposal for the Fault & Alarm Dictionary (Nokia/Ben C. and Marge). There was a concern that the ALARM ID would be confused with the 3GPP TS32.111 definition for Alarm Id, which indicates an instance ID rather than an alarm index number. We all discussed a new more appropriate name and arrived at “ALARM DICTIONARY INDEX”. This would be an index into the Alarm Dictionary with a value that could be specified in the incoming VES event.
VES EVENT OVERLAP – Rebecca raised some concern that the Alarm Dictionary and the VES Fault event has overlapping information. The thought is that information in the VES Fault Event contains all the information would needed by Analytics events. In our discussion though of the fields we see that only 3 out of the 13 fields have direct mapping to the VES fault event.
ALARM DICTIONARY OPTIONAL USAGE – Ericsson suggested that we add in the VES Fault event an optional field called “ALARM DICTIONARY INDEX” which can be used to indicate the actual Alarm Dictionary Index number. This number would be filled out by the PNF when it sends the VES Fault Event. Because this field is optional, if this were not filled with anything, this would mean that this alarm does not have an Alarm Dictionary entry, or that an Alarm Dictionary is not used. This design would allow for the Alarm Dictionary itself to be optional in case some vendors do not wish to support a dictionary.
ALARM DICTIONARY RAISON D’ETRE – We discussion the purpose, meaning, and application of an Alarm Dictionary. There was a discussion of why it was needed, and how it might be used. Ben described that an Alarm Dictionary can have 3 purposes: (1) DICTIONARY - it allows for a readily accessible body of the entire set of alarms & faults that are managed by a PNF. It would allow for an operator to see all of the alarms & faults of a PNF without having to wait for individual alarms & faults to arrive in ONAP. (2) Analytics facilitator – A dictionary would allow for a variety of vendor specific (or vendor agnostic) analytics applications to be developed. There are a variety of fields in the Alarm Dictionary that would facilitate such analytics capabilities as correlation, escalation, isolation, recovery actions, self-healing, and life cycle management functions. (3) GENERAL ANALYTICS – The strength of ONAP is the potential ability to coordinate information from multiple sources, different vendors, and disparate types of NFs. A dictionary can form the foundation for generalized analytics that are vendor agnostic.
FAULT DICTIONARY – There was a discussion about why a fault dictionary was needed, and how it was different from an Alarm Dictionary. Ben described that a Fault can be a condition encountered in run-time that does not necessarily create a customer-facing alarm. An alarm is intended to result in a visual notification to a service provider to take action. An analogy would be the “Check engine” light in your car which would correspond to an Alarm. A solenoid, a carburetor, or distributor fault all might lead to a “Check engine” light. A driver (service provider) may not be able to directly act on the specific fault (or indeed care about the fault); but when the “check engine” light went on would know to take some action (go to the service station).
DELIVERY IN CASABLANCA – We believe that the use of dictionaries cannot make it into R3 Casablanca, so this would be work in Dublin (R4) release. We discussed a statement made by Michael Lando who said on July 3, that no additional artifacts can be supported in R3, that these discussions we have been having in the modeling calls w.r.t. to the FM, PM dictionary is mature enough to go “live”.
PNF MODELING
MODELING PARAMETERS – We discussed the PNF modeling parameters, pnfExtConnPt, contactID, pnfSWVersionList, PackageVersion and NF Controller. It was our understanding that these should be incorporated into the Generic PNF Template. We thought this was already a “done deal” and there were no further open issues per se with this. So it is an open point to still discuss can this be incorporated into R3 Casablanca. Perhaps we should have a discussion on this sooner than next Tuesday (July 19).
NF CONTROLLER – A new parameter suggested from our A&AI discussion with Christina is the addition of a NF controller parameter in the PNF model. This would indicate the kind of controller that this PNF uses. These might be APP-C, SDN-C, VF-C for instance. This would be set by the operator during design time, and it might affect how information is distributed to components in ONAP. For example if APP-C was the controller indicated for this PNF, APP-C would know if the distributed artifacts are relevant for it.
A&AI DISCUSSION – We discussed the four parameters that we suggested to add to A&AI (Geo-location info, Active/Passive S/W version(s), Cloud home, and Manager IP address. The results of these discussions are captured in the PnP Plug and Play A&AI project impacts. This requires further discussion
MANAGER IP ADDRESS – We discussed the CM Use Case & Software Management Use Case (Hwawei) which is asking for the EMS to take commands from ONAP. And Christina’s suggestion of modeling the EMS as a PNF and modeling it as having a connection with the PNF. This also needs further discussion.