diff options
Diffstat (limited to 'docs/Chapter7/Monitoring-And-Management.rst')
| -rwxr-xr-x | docs/Chapter7/Monitoring-And-Management.rst | 214 |
1 files changed, 107 insertions, 107 deletions
diff --git a/docs/Chapter7/Monitoring-And-Management.rst b/docs/Chapter7/Monitoring-And-Management.rst index a576a91..a0aa58e 100755 --- a/docs/Chapter7/Monitoring-And-Management.rst +++ b/docs/Chapter7/Monitoring-And-Management.rst @@ -62,7 +62,7 @@ While this document is focused on specifying some of the records from the ONAP perspective, there may be other external bodies using the same framework to specify additional records. For example, OPNFV has a VES project that is looking to specify records for OpenStack's internal telemetry to manage -application (xNFs), physical and virtual infrastructure (compute, storage, +application (VNFs or PNFs), physical and virtual infrastructure (compute, storage, network devices, etc.) and virtual infrastructure managers (cloud controllers, SDN controllers). It uses ONAP's VES Agent to generate VES events from the NF and Intel's collectD agent to generate infrastructure VES events. Note that @@ -143,7 +143,7 @@ sender and other identifying characteristics related to the domain and event. with the event * ``priority`` - the processing priority enumeration * ``reportingEntityName`` - name of the entity reporting the event or - detecting a problem in another xNF + detecting a problem in another VNF or PNF * ``sequence`` - the ordering of events communicated by an event source * ``sourceName`` - name of the entity experiencing the event issue, which may be detected and reported by a separate reporting entity @@ -310,13 +310,13 @@ Data Structure Specification of the Event Record .. req:: :id: R-520802 - :target: XNF PROVIDER + :target: VNF or PNF PROVIDER :keyword: MUST :introduced: casablanca :validation_mode: static :impacts: dcae - The xNF provider **MUST** provide a YAML file formatted in adherence with + The VNF or PNF provider **MUST** provide a YAML file formatted in adherence with the :doc:`VES Event Registration specification <../../../../vnfsdk/model.git/docs/files/VESEventRegistration_3_0>` that defines the following information for each event produced by the VNF: @@ -327,20 +327,20 @@ Data Structure Specification of the Event Record .. req:: :id: R-120182 - :target: XNF PROVIDER + :target: VNF or PNF PROVIDER :keyword: MUST :introduced: casablanca :validation_mode: static :impacts: dcae - The xNF provider **MUST** indicate specific conditions that may arise, and + The VNF or PNF provider **MUST** indicate specific conditions that may arise, and recommend actions that may be taken at specific thresholds, or if specific conditions repeat within a specified time interval, using the semantics and syntax described by the :doc:`VES Event Registration specification <../../../../vnfsdk/model.git/docs/files/VESEventRegistration_3_0>`. -**NOTE:** The Service Provider may override xNF provider Event +**NOTE:** The Service Provider may override VNF or PNF provider Event Registrations using the ONAP SDC Design Studio to finalizes Service -Provider engineering rules for the processing of the xNF events. +Provider engineering rules for the processing of the VNF or PNF events. These changes may modify any of the following: * Threshold levels @@ -349,26 +349,26 @@ These changes may modify any of the following: .. req:: :id: R-570134 - :target: XNF + :target: VNF or PNF :keyword: MUST :introduced: casablanca :validation_mode: in_service :impacts: dcae - The events produced by the xNF **MUST** must be compliant with the common + The events produced by the VNF or PNF **MUST** must be compliant with the common event format defined in the :doc:`VES Event Listener<../../../../vnfsdk/model.git/docs/files/VESEventListener_7_0_1>` specification. .. req:: :id: R-123044 - :target: XNF PROVIDER + :target: VNF or PNF PROVIDER :keyword: MUST :introduced: casablanca :validation_mode: in_service :impacts: dcae - The xNF Provider **MAY** require that specific events, identified by their + The VNF or PNF Provider **MAY** require that specific events, identified by their ``eventName``, require that certain fields, which are optional in the common event format, must be present when they are published. @@ -384,30 +384,30 @@ minimizing changes to data delivery. .. req:: :id: R-798933 - :target: XNF + :target: VNF or PNF :keyword: SHOULD :impacts: dcae :validation_mode: in_service :introduced: casablanca - The xNF **SHOULD** deliver event records that fall into the event domains + The VNF or PNF **SHOULD** deliver event records that fall into the event domains supported by VES. .. req:: :id: R-821839 - :target: XNF + :target: VNF or PNF :keyword: MUST :impacts: dcae :validation_mode: in_service :introduced: casablanca :updated: dublin - The xNF **MUST** deliver event records to ONAP using the common transport + The VNF or PNF **MUST** deliver event records to ONAP using the common transport mechanisms and protocols defined in this specification. The term 'Event Record' is used throughout this document to represent various -forms of telemetry or instrumentation made available by the xNFs -including, faults, status events, various other types of xNF measurements +forms of telemetry or instrumentation made available by the VNFs or PNFs +including, faults, status events, various other types of VNF or PNF measurements and logs. Common structures and delivery protocols for other types of data will be given @@ -415,21 +415,21 @@ in future versions of this document as we gain more insight into data volumes and required processing. In the following sections, we provide options for encoding, serialization and -data delivery. Agreements between Service Providers and xNF providers determine +data delivery. Agreements between Service Providers and VNF or PNF providers determine which encoding, serialization and delivery method to use for particular data sets. .. req:: :id: R-932071 - :target: XNF + :target: VNF or PNF :keyword: MUST :impacts: dcae :validation_mode: none :introduced: casablanca - The xNF provider **MUST** reach agreement with the Service Provider on + The VNF or PNF provider **MUST** reach agreement with the Service Provider on the selected methods for encoding, serialization and data delivery - prior to the on-boarding of the xNF into ONAP SDC Design Studio. + prior to the on-boarding of the VNF or PNF into ONAP SDC Design Studio. VNF or PNF Telemetry using VES/JSON Model @@ -437,13 +437,13 @@ VNF or PNF Telemetry using VES/JSON Model .. req:: :id: R-659655 - :target: XNF + :target: VNF or PNF :keyword: SHOULD :impacts: dcae :validation_mode: in_service :introduced: casablanca - The xNF **SHOULD** leverage the JSON-driven model, as depicted in Figure 2, + The VNF or PNF **SHOULD** leverage the JSON-driven model, as depicted in Figure 2, for data delivery unless there are specific performance or operational concerns agreed upon by the Service Provider that would warrant using an alternate model. @@ -457,13 +457,13 @@ VNF or PNF Telemetry using Google Protocol Buffers .. req:: :id: R-697654 - :target: XNF + :target: VNF or PNF :keyword: MAY :impacts: dcae :validation_mode: in_service :introduced: casablanca - The xNF **MAY** leverage the Google Protocol Buffers (GPB) delivery model + The VNF or PNF **MAY** leverage the Google Protocol Buffers (GPB) delivery model depicted in Figure 3 to support real-time performance management (PM) data. In this model the VES events are streamed as binary-encoded GBPs over via TCP sockets. @@ -473,7 +473,7 @@ VNF or PNF Telemetry using Google Protocol Buffers Figure 3. VNF or PNF Telemetry using Google Protocol Buffers -**NOTE:** For high-volume xNF telemetry, native (binary) Google Protocol +**NOTE:** For high-volume VNF or PNF telemetry, native (binary) Google Protocol Buffers (GPB) is the preferred serialization method. While supporting the GPB telemetry delivery approach described above, the default delivery method is the VES/REST JSON based model in DCAE. The purpose of the diagram above @@ -490,13 +490,13 @@ Bulk Telemetry Transmission .. req:: :id: R-908291 - :target: XNF + :target: VNF or PNF :keyword: MAY :introduced: casablanca :impacts: dcae, dmaap :validation_mode: in_service - The XNF **MAY** leverage bulk xNF telemetry transmission mechanism, as + The VNF or PNF **MAY** leverage bulk VNF or PNF telemetry transmission mechanism, as depicted in Figure 4, in instances where other transmission methods are not practical or advisable. @@ -519,13 +519,13 @@ VNF telemetry via standardized interface .. req:: :id: R-821473 - :target: XNF + :target: VNF or PNF :keyword: MUST :introduced: casablanca :impacts: dcae :validation_mode: in_service - The xNF MUST produce heartbeat indicators consisting of events containing + The VNF or PNF MUST produce heartbeat indicators consisting of events containing the common event header only per the VES Listener Specification. @@ -534,11 +534,11 @@ JSON .. req:: :id: R-19624 - :target: XNF + :target: VNF or PNF :keyword: MUST :updated: casablanca - The xNF, when leveraging JSON for events, **MUST** encode and serialize + The VNF or PNF, when leveraging JSON for events, **MUST** encode and serialize content delivered to ONAP using JSON (RFC 7159) plain text format. High-volume data is to be encoded and serialized using `Avro <http://avro.apache.org/>`_, where the Avro data @@ -584,32 +584,32 @@ Google Protocol Buffers (GPB) .. req:: :id: R-257367 - :target: XNF + :target: VNF or PNF :keyword: MUST :introduced: casablanca :validation_mode: in_service - The xNF, when leveraging Google Protocol Buffers for events, **MUST** + The VNF or PNF, when leveraging Google Protocol Buffers for events, **MUST** serialize the events using native Google Protocol Buffers (GPB) according to the following guidelines: * The keys are represented as integers pointing to the system resources - for the xNF being monitored + for the VNF or PNF being monitored * The values correspond to integers or strings that identify the operational state of the VNF resource, such a statistics counters and - the state of an xNF resource. + the state of an VNF or PNF resource. * The required Google Protocol Buffers (GPB) metadata is provided in the form of .proto files. .. req:: :id: R-978752 - :target: XNF PROVIDER + :target: VNF or PNF PROVIDER :keyword: MUST :introduced: casablanca :validation_mode: static - The xNF providers **MUST** provide the Service Provider the following - artifacts to support the delivery of high-volume xNF telemetry to + The VNF or PNF providers **MUST** provide the Service Provider the following + artifacts to support the delivery of high-volume VNF or PNF telemetry to DCAE via GPB over TLS/TCP: * A valid VES Event .proto definition file, to be used validate and @@ -624,20 +624,20 @@ Reporting Frequency .. req:: :id: R-146931 - :target: XNF + :target: VNF or PNF :keyword: MUST :introduced: casablanca :validation_mode: in_service - The xNF **MUST** report exactly one Measurement event per period + The VNF or PNF **MUST** report exactly one Measurement event per period per source name. .. req:: :id: R-98191 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF **MUST** vary the frequency that asynchronous data + The VNF or PNF **MUST** vary the frequency that asynchronous data is delivered based on the content and how data may be aggregated or grouped together. @@ -674,83 +674,83 @@ of bulk files. .. req:: :id: R-88482 - :target: XNF + :target: VNF or PNF :keyword: SHOULD - The xNF **SHOULD** use REST using HTTPS delivery of plain + The VNF or PNF **SHOULD** use REST using HTTPS delivery of plain text JSON for moderate sized asynchronous data sets, and for high volume data sets when feasible. .. req:: :id: R-84879 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF **MUST** have the capability of maintaining a primary + The VNF or PNF **MUST** have the capability of maintaining a primary and backup DNS name (URL) for connecting to ONAP collectors, with the ability to switch between addresses based on conditions defined by policy such as time-outs, and buffering to store messages until they can be delivered. At its discretion, the service provider may choose to populate - only one collector address for a xNF. In this case, the network will + only one collector address for a VNF or PNF. In this case, the network will promptly resolve connectivity problems caused by a collector or network - failure transparently to the xNF. + failure transparently to the VNF or PNF. .. req:: :id: R-81777 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF **MUST** be configured with initial address(es) to use + The VNF or PNF **MUST** be configured with initial address(es) to use at deployment time. Subsequently, address(es) may be changed through - ONAP-defined policies delivered from ONAP to the xNF using PUTs to a + ONAP-defined policies delivered from ONAP to the VNF or PNF using PUTs to a RESTful API, in the same manner that other controls over data reporting will be controlled by policy. .. req:: :id: R-08312 - :target: XNF + :target: VNF or PNF :keyword: MAY - The xNF **MAY** use another option which is expected to include REST + The VNF or PNF **MAY** use another option which is expected to include REST delivery of binary encoded data sets. .. req:: :id: R-79412 - :target: XNF + :target: VNF or PNF :keyword: MAY - The xNF **MAY** use another option which is expected to include TCP + The VNF or PNF **MAY** use another option which is expected to include TCP for high volume streaming asynchronous data sets and for other high volume data sets. TCP delivery can be used for either JSON or binary encoded data sets. .. req:: :id: R-01033 - :target: XNF + :target: VNF or PNF :keyword: MAY - The xNF **MAY** use another option which is expected to include SFTP + The VNF or PNF **MAY** use another option which is expected to include SFTP for asynchronous bulk files, such as bulk files that contain large volumes of data collected over a long time interval or data collected across many - xNFs. (Preferred is to reorganize the data into more frequent or more focused + VNFs or PNFs. (Preferred is to reorganize the data into more frequent or more focused data sets, and deliver these by REST or TCP as appropriate.) .. req:: :id: R-63229 - :target: XNF + :target: VNF or PNF :keyword: MAY - The xNF **MAY** use another option which is expected to include REST - for synchronous data, using RESTCONF (e.g., for xNF state polling). + The VNF or PNF **MAY** use another option which is expected to include REST + for synchronous data, using RESTCONF (e.g., for VNF or PNF state polling). .. req:: :id: R-03070 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF **MUST**, by ONAP Policy, provide the ONAP addresses - as data destinations for each xNF, and may be changed by Policy while - the xNF is in operation. We expect the xNF to be capable of redirecting + The VNF or PNF **MUST**, by ONAP Policy, provide the ONAP addresses + as data destinations for each VNF or PNF, and may be changed by Policy while + the VNF or PNF is in operation. We expect the VNF or PNF to be capable of redirecting traffic to changed destinations with no loss of data, for example from one REST URL to another, or from one TCP host and port to another. @@ -759,92 +759,92 @@ Asynchronous and Synchronous Data Delivery .. req:: :id: R-06924 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF **MUST** deliver asynchronous data as data becomes + The VNF or PNF **MUST** deliver asynchronous data as data becomes available, or according to the configured frequency. .. req:: :id: R-73285 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF **MUST** must encode, address and deliver the data + The VNF or PNF **MUST** must encode, address and deliver the data as described in the previous paragraphs. .. req:: :id: R-42140 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF **MUST** respond to data requests from ONAP as soon + The VNF or PNF **MUST** respond to data requests from ONAP as soon as those requests are received, as a synchronous response. .. req:: :id: R-34660 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF **MUST** use the RESTCONF/NETCONF framework used by + The VNF or PNF **MUST** use the RESTCONF/NETCONF framework used by the ONAP configuration subsystem for synchronous communication. .. req:: :id: R-86586 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF **MUST** use the YANG configuration models and RESTCONF + The VNF or PNF **MUST** use the YANG configuration models and RESTCONF [RFC8040] (https://tools.ietf.org/html/rfc8040). .. req:: :id: R-11240 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF **MUST** respond with content encoded in JSON, as + The VNF or PNF **MUST** respond with content encoded in JSON, as described in the RESTCONF specification. This way the encoding of a synchronous communication will be consistent with Avro. .. req:: :id: R-70266 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF **MUST** respond to an ONAP request to deliver the + The VNF or PNF **MUST** respond to an ONAP request to deliver the current data for any of the record types defined in `Event Records - Data Structure Description`_ by returning the requested record, populated with the current field values. (Currently the defined record types include fault fields, mobile flow fields, measurements for - xNF scaling fields, and syslog fields. Other record types will be added + VNF or PNF scaling fields, and syslog fields. Other record types will be added in the future as they become standardized and are made available.) .. req:: :id: R-332680 - :target: XNF + :target: VNF or PNF :keyword: SHOULD :impacts: dcae :validation_mode: in_service :introduced: casablanca - The xNF **SHOULD** deliver all syslog messages to the VES Collector per the + The VNF or PNF **SHOULD** deliver all syslog messages to the VES Collector per the specifications in Monitoring and Management chapter. .. req:: :id: R-46290 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF **MUST** respond to an ONAP request to deliver granular + The VNF or PNF **MUST** respond to an ONAP request to deliver granular data on device or subsystem status or performance, referencing the YANG - configuration model for the xNF by returning the requested data elements. + configuration model for the VNF or PNF by returning the requested data elements. .. req:: :id: R-43327 - :target: XNF + :target: VNF or PNF :keyword: SHOULD - The xNF **SHOULD** use `Modeling JSON text with YANG + The VNF or PNF **SHOULD** use `Modeling JSON text with YANG <https://tools.ietf.org/html/rfc7951>`_, If YANG models need to be translated to and from JSON{RFC7951]. YANG configuration and content can be represented via JSON, consistent with Avro, as described in "Encoding @@ -855,10 +855,10 @@ Security .. req:: :id: R-42366 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF **MUST** support secure connections and transports such as + The VNF or PNF **MUST** support secure connections and transports such as Transport Layer Security (TLS) protocol [`RFC5246 <https://tools.ietf.org/html/rfc5246>`_] and should adhere to the best current practices outlined in @@ -866,36 +866,36 @@ Security .. req:: :id: R-44290 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF **MUST** control access to ONAP and to xNFs, and creation + The VNF or PNF **MUST** control access to ONAP and to VNFs or PNFs, and creation of connections, through secure credentials, log-on and exchange mechanisms. .. req:: :id: R-47597 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF **MUST** carry data in motion only over secure connections. + The VNF or PNF **MUST** carry data in motion only over secure connections. .. req:: :id: R-68165 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF **MUST** encrypt any content containing Sensitive Personal + The VNF or PNF **MUST** encrypt any content containing Sensitive Personal Information (SPI) or certain proprietary data, in addition to applying the regular procedures for securing access and delivery. .. req:: :id: R-01427 - :target: XNF + :target: VNF or PNF :keyword: MUST :introduced: casablanca :updated: dublin - The xNF **MUST** support the provisioning of security and authentication + The VNF or PNF **MUST** support the provisioning of security and authentication parameters (HTTP username and password) in order to be able to authenticate with DCAE (in ONAP). @@ -907,12 +907,12 @@ Security .. req:: :id: R-894004 - :target: XNF + :target: VNF or PNF :keyword: MUST :introduced: casablanca :updated: dublin - When the xNF sets up a HTTP or HTTPS connection to the collector, it **MUST** + When the VNF or PNF sets up a HTTP or HTTPS connection to the collector, it **MUST** provide a username and password to the DCAE VES Collector for HTTP Basic Authentication. @@ -925,33 +925,33 @@ Bulk Performance Measurement .. req:: :id: R-841740 - :target: XNF + :target: VNF or PNF :keyword: SHOULD :introduced: casablanca :impacts: dcae, dmaap - The xNF **SHOULD** support FileReady VES event for event-driven bulk transfer + The VNF or PNF **SHOULD** support FileReady VES event for event-driven bulk transfer of monitoring data. .. req:: :id: R-440220 - :target: XNF + :target: VNF or PNF :keyword: SHOULD :introduced: casablanca :impacts: dcae, dmaap - The xNF **SHOULD** support File transferring protocol, such as FTPES or SFTP, + The VNF or PNF **SHOULD** support File transferring protocol, such as FTPES or SFTP, when supporting the event-driven bulk transfer of monitoring data. .. req:: :id: R-75943 - :target: XNF + :target: VNF or PNF :keyword: SHOULD :introduced: casablanca :impacts: dcae, dmaap - The xNF **SHOULD** support the data schema defined in 3GPP TS 32.435, when + The VNF or PNF **SHOULD** support the data schema defined in 3GPP TS 32.435, when supporting the event-driven bulk transfer of monitoring data. .. req:: |