Task and Evidence Information Model for AINETOps

Introduction Network operational tasks may be handled collaboratively by multiple Network Management Agents (NMAs). For example, one agent may collect network state information while another proposes path optimization. Because different systems may represent task objectives, network objects, and related evidence differently, semantic inconsistencies can arise in cross-vendor or cross-domain collaboration. To address this issue, this document defines two related information models. The Task Information Model describes the objectives, scope, expected outcomes, and execution constraints of network operational tasks. The Evidence Information Model describes task-related evidence, including its source, time, and type. The two models are logically associated through task identifiers. To support different network operational scenarios, both models distinguish a common part (Core) from extensions for particular domains (Profiles). This document specifies common information elements and Profile extension rules; specific message encodings and transport protocols are outside its scope. The JSON representations in this document are illustrative only.

Terminology and Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

NMA (Network Management Agent): A software agent that performs or assists with network management tasks.
Business Task: Work with a defined network operational objective that may be handled collaboratively by one or more NMAs.
Task Core: Information elements and their semantics common to different network operational tasks.
Task Profile: Extended information and its semantics for a particular type of task.
Evidence Core: Information elements and their semantics common to different types of evidence.
Evidence Profile: Information and its semantics defined for a particular type of evidence.

In the structure diagrams, (1) indicates a mandatory element that occurs exactly once, (0..1) indicates an optional element, and (1..n) indicates one or more occurrences. In the Elements tables in Sections 5 and 6, Req indicates whether an element is mandatory or optional, while Type denotes its conceptual type. All elements listed in the Elements tables belong to the Core. In the Ext column, T means Task Profile, E means Evidence Profile, and - means a non-extension element. The marked containers permit their Profile to define internal information elements.

Relationship to Existing Work

AINETOps Use Cases discusses AINETOps application scenarios, including network fault handling, network optimization, and service assurance. This document provides reusable task descriptions and evidence information semantics for these scenarios without specifying particular network operational algorithms.

NMA Northbound Task Interface discusses requirements for the northbound interface through which an OSS or management system delegates tasks to an NMA. This document is related to the representation of task objectives and constraints, but defines general Task and Evidence information models applicable to different network operational scenarios rather than an interface for a particular direction of communication.

Overall Information Model The Task Information Model and the Evidence Information Model each consist of a Core and a Profile. The Core defines information elements that remain consistent across scenarios, while a Profile defines information specific to a particular task or evidence type. Figure 1 illustrates the relationship between the two models. Figure 1: Task and Evidence Information Models

Scope and Relationships This document specifies the common information elements of Task Core and Evidence Core, as well as requirements for Profiles. Specific Profiles, such as those for path optimization, fault diagnosis, and network observation, may be defined in separate specifications. The Profiles presented in Sections 5 and 6 only illustrate the extension mechanism; implementations are not required to support all of them. Each Business Task is identified by task_id and may be associated with another Business Task through ref_task_id. An evidence set is identified by evidence_id, and related evidence may refer to a Business Task through ref_task_id.

Common Profile Requirements Consistent interpretation of scenario-specific information across vendors requires recognition of the same Profile and its semantics. Therefore, each Profile MUST have a clearly defined identifier. Its specification MUST define versioning and compatibility rules and describe the meanings, required or optional status, units, and value constraints of its information elements. A Profile MUST NOT change the meaning or type of information elements defined by the Core, nor may it introduce undefined top-level elements.

Task Information Model

Structure The Task Information Model represents a Business Task as a Task Instance. Figure 2 shows the corresponding information structure. The extensible elements under task_spec are defined by the applicable Task Profile. Figure 2: Task Information Model Structure

Elements Table 1 summarizes the common information elements of Task Core. Req uses MUST and MAY to indicate mandatory and optional elements, respectively. Requirements for nested elements apply within their parent elements. Type denotes a conceptual type rather than a particular programming-language or network-protocol data type. Table 1: Task Core Elements task_id identifies the Business Task, and ref_task_id associates it with other Business Tasks. task_type identifies the task type, allowing the recipient to determine the corresponding Task Profile. task_spec.objective describes the task objective and is a mandatory textual element of the task specification. scope indicates the network objects or scope to which the task applies, target indicates the expected outcomes or metrics, and constraints indicates restrictions that the task must observe. profile_data accommodates additional scenario-specific information that does not fall into these categories. The internal structures of these four composite elements are defined by the Task Profile.

Constraints task_id MUST be unique within the management domain of the task publisher. When used across management domains, the parties involved SHOULD specify the scope of the task identifier. ref_task_id indicates a business association only. task_type MUST identify an applicable Task Profile. scope, target, constraints, and profile_data are optional in the Core; a Profile may determine their specific content and conditions of use according to the requirements of the task type.

Task Profile Example This section uses the path_optimization type to illustrate a Task Profile. The Profile uses scope to identify the source and destination nodes, target to specify desired latency and bandwidth, constraints to indicate whether changes to production network configurations are permitted, and profile_data to specify the analysis time window. Figure 3 applies only to this illustrative Profile. Figure 3: Illustrative Path Optimization Profile latency_lt_ms specifies that end-to-end latency must be strictly less than the given value in milliseconds. bandwidth_gte_gbps specifies that the available bandwidth must be greater than or equal to the given value in Gbps. no_production_changes indicates whether changes to production configurations are prohibited. The start and end times of analysis_window define the analysis time window.

Example Task Instance The following JSON illustrates one possible representation of the Task Information Model.

Evidence Information Model

Structure The Evidence Information Model represents an evidence collection as an Evidence Set, which contains at least one Evidence Entry. Figure 4 shows the corresponding information structure. The internal structure of content is defined by the applicable Evidence Profile. Figure 4: Evidence Information Model Structure

Elements Table 2 summarizes the common information elements of Evidence Core. evidence[].* denotes elements within each Evidence Entry; therefore, the corresponding MUST requirements apply to every entry. Table 2: Evidence Core Elements evidence_id identifies the Evidence Set, and ref_task_id associates it with a Business Task. item_id identifies an individual entry within the evidence set. type identifies the evidence type and its Evidence Profile; source identifies the system from which the evidence originates; and timestamp indicates when the evidence was collected or generated. content contains evidence-type-specific information and is interpreted according to the corresponding Profile.

Constraints evidence_id MUST be unique within the management domain of the evidence publisher. An Evidence Set MUST contain at least one Evidence Entry; each Evidence Entry MUST contain item_id, type, source, timestamp, and content. item_id MUST be unique within its Evidence Set. An individual evidence entry can be referenced by the combination of evidence_id and item_id. When evidence is associated with a specific Business Task, ref_task_id SHOULD be provided. timestamp indicates when evidence was collected or generated. source and timestamp describe only the provenance and time of the evidence; they do not, by themselves, establish its authenticity or integrity.

Evidence Profile Example This section uses the observation type to illustrate an Evidence Profile. It uses content to represent the observed object, metrics, and measured values. In Figure 5, measurements is a collection containing at least one measurement record; method is an optional description of the measurement method. Figure 5: Illustrative Network Observation Profile

Example Evidence Instance The following JSON illustrates one possible representation of the Evidence Information Model.

Security Considerations Task information may contain network topology, device identifiers, and service paths. Evidence information may expose network operational status, measurement data, or sensitive service information. Systems using this model should provide appropriate access controls and transport protection according to the sensitivity of the information. A task description does not itself constitute authorization for network operations, and the source and timestamp associated with evidence do not guarantee its authenticity. Authentication, access control, and evidence integrity protection are provided by other security mechanisms used in the deployment.

IANA Considerations This document defines only protocol-independent information models and requests no IANA registrations.

Future Work Future work may map these information models to specific data models and further define Profile naming, versioning, and compatibility rules. Profiles for fault diagnosis, path optimization, telemetry, and simulation may be standardized separately.

References

Normative References

, Key words for use in RFCs to Indicate Requirement Levels.
, Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words.

Informative References

, Artificial Intelligence (AI) for Network Operations.
, Problem Statement for Standardizing the Northbound Task Interface (NTI) of the Network Management Agent.