Semantic Metadata Annotation for Network Anomaly Detection

provides an overall introduction into how anomaly detection is applied to the IP network domain and which operational data are needed. It approaches the problem space by automating what a network engineer would normally do when verifying a network connectivity service, monitoring the different network planes to understand wherever one network plane affects another negatively. As a Service Disruption Detection Systems may need to be fine tuned to effectively maintain good anomaly detection rates, the system need to generate analytical data that is reviewed by a network engineer. This process is defined in , where the human engineer can be kept out of the monitoring process but needs to be involved in the alarm verification process. This document describes what information is needed to understand the analytical results produced by the Service Disruption Detection System. The document proposes a set of semantically structured terms that can be used by a Service Disruption Detection System for comparing the results systematically, setting the baselines for supervised machine learning algorithms that require labeled operational data. This document proposes two YANG Service Models, a service topology model in to describe the topology context and a YANG symptom model in to describe the symptoms defined In . examples above Service Models in an Apache AVRO data model based on 'ietf-relevant-state.yang' data model defined in .

This document makes use of the terms defined in , and . The following terms are used as defined in : Outlier Detection Contextual Outlier Service Disruption Detection Service Disruption Detection System The following terms are used as defined in : Concern Score The following terms are used as defined in : System State Problem Symptom Alarm The following terms are used as defined in : Service Model

Observed network Symptoms are specified and categorized according to the following scheme:

Action:: The action that a network node performed for a packet in the Forwarding Plane, a path or adjacency in the Control Plane, or the representation of resource state in the Management Plane or statistical changes recorded by the resources and reported in the Management Plane. For Forwarding Plane we distinguish between missing, where the packet drop occurred outside the measured network node, drop, where the packet drop was performed by the measured network node, and delay, which defines the on-path delay measured on the network node. For Control Plane we distinguish between reachability, which refers to a change in the routing or forwarding information base (RIB/FIB) and adjacency which refers to a change in a peering or link-layer resolution. For Management Plane we refer to state or statistical change on the interface.

Reason:: For each action, the reason describe why this action was performed. For drops in Forwarding Plane we distinguish between Unreachable, because network layer reachability information was missing, Administered, because an administrator configured a rule preventing the forwarding of this packet, and Corrupt, where the network node was unable to determine the forwarding path due to a packet, software or hardware error. For on-path delay we distinguish between Minimum, Average and Maximum delay for a given flow. For Control Plane, we distinguish wherever a the reachability action was due to path updates or withdraws or the adjacency was established or teared down. For Management Plane, we distinguish between interfaces states that are shown as up and down, and statistical counters that refer to errors, packet discards or unknown protocol counters.

Trigger:: For each reason, the trigger describe why a network node has chosen that action.

consolidates the list of common symptoms related to the forwarding plane, defining the triplets action, reason and trigger. Description of symptoms and their actions, reason and trigger for Forwarding Plane.

Action	Reason	Trigger
Drop	Unreachable	next-hop
Drop	Unreachable	link-layer
Drop	Unreachable	Time To Life expired
Drop	Unreachable	Fragmentation needed and Don't Fragment set
Drop	Administered	Access-List
Drop	Administered	Unicast Reverse Path Forwarding
Drop	Administered	Discard Route
Drop	Administered	Policed
Drop	Administered	Shaped
Drop	Corrupt	Bad Packet
Drop	Corrupt	Bad Egress Interface
Delay	Min	-
Delay	Mean	-
Delay	Max	-

consolidates the list of common symptoms related to control plane, describing their actions, reasons and triggers. Description of symptoms and their actions, reasons and triggers related to Control Plane.

Action	Reason	Trigger
Reachability	Update	Imported
Reachability	Update	Received
Reachability	Withdraw	Received
Reachability	Withdraw	Peer Down
Reachability	Withdraw	Suppressed
Reachability	Withdraw	Stale
Reachability	Withdraw	Route Policy Filtered
Reachability	Withdraw	Maximum Number of Prefixes Reached
Adjacency	Established	Peer
Adjacency	Established	Link-Layer
Adjacency	Locally Teared Down	Peer
Adjacency	Remotely Teared Down	Peer
Adjacency	Locally Teared Down	Link-Layer
Adjacency	Remotely Teared Down	Link-Layer
Adjacency	Locally Teared Down	Administrative
Adjacency	Remotely Teared Down	Administrative
Adjacency	Locally Teared Down	Maximum Number of Prefixes Reached
Adjacency	Remotely Teared Down	Maximum Number of Prefixes Reached
Adjacency	Locally Teared Down	Transport Connection Failed
Adjacency	Remotely Teared Down	Transport Connection Failed

consolidates the list of common symptoms related to management plane, defining the triplets action, reason and trigger. Description of symptoms and their actions, reasons and triggers for Management Plane.

Action	Reason	Trigger
Interface State	Up	Link-Layer
Interface State	Down	Link-Layer
Interface Statistics	Errors	-
Interface Statistics	Discards	-
Interface Statistics	Unknown Protocol	-

Operational Metadata adds additional context to collected metrics. For instance, in a network, the software version of the network node defines the version of the software release that generated Management Plane metrics . Semantic Metadata, on the other hand, defines the meaning or ontology of the annotated data. In this section a YANG model is defined in order to provide a structure for the metadata related to anomalies occurred in a network. The module is intended to describe the metadata used for "annotating" the operational data collected from the network nodes, which include time series data, logs, as well as other forms of data that is "time-bounded". The aspects discussed in this document are grouped under the concept of "anomaly" which represents a collection of symptoms. The anomaly overall has a set of parameters that describe the overall behavior of the network in a given time-window including all the observed symptoms and outliers.

This section defines two YANG models, one defining a placeholder for the action reason trigger defined in this document, and one defining service topology information related to the anomaly.

contains the YANG tree diagram of the 'ietf-network-anomaly-symptom-cbl' module. It augments the 'ietf-relevant-state' module defined in . For each Symptom, the following parameters can be assigned: an Action, a Reason and a Trigger describing the Symptom; a Concern Score indicating how critical the Symptom is; and the associated network plane. Where the season enumeration declares wherever a workday or a holiday hase been taken into consideration for Contextual Outliers. The template describes which approach and parameters have been used in the Service Disruption Detection as described in Section 3.2 of

The module augments the anomaly of the 'relevant-state' container and the 'relevant-state-notification' of 'ietf-relevant-state' module defined in . The 'relevant-state' container is used for modifying the Symptom data in the Postmortem system, while the 'relevant-state-notification' is used for messaging from the Alarm Aggregation to the Postmortem and the Alarm and Problem Management system.

The YANG module has a grouping defining Action, Reason and Trigger and how symptom attributes to the network planes. WG List: Editor: Thomas Graf Wanting Du Alex Huang Feng Vincenzo Riccobene "; description "This module defines the semantic grouping to be used by a Service Disruption Detection Systems. The defined objects is used to augment the anomaly container. Describing the symptoms action and reason. Copyright (c) 2025 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Revised BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). All revisions of IETF and IANA published modules can be found at the YANG Parameters registry (https://www.iana.org/assignments/yang-parameters). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; revision 2025-11-15 { description "Initial version"; reference "RFC XXX: Semantic Metadata Annotation for Network Anomaly Detection"; } grouping cbl-symptom { description "Semantic metadata assocaited to a symptom for a detected connectivity service anomaly."; leaf action { type string; description "Operation performed by a network node when forwarding a packet."; } leaf reason { type string; description "Reason associated to the action performed by the network node."; } leaf trigger { type string; description "Describes what triggered the network node to this action."; } leaf network-plane { type enumeration { enum forwarding { description "Symptom associated to the Forwarding Plane."; } enum control { description "Symptom associated to the Control Plane."; } enum management { description "Symptom associated to the Management Plane."; } } description "Associated network plane."; } leaf template { type string; mandatory false; description "A group of configuration parameters contributing to the symptom detection computation"; reference "Section 3.2 in draft-ietf-nmop-network-anomaly-architecture."; } leaf season { type enumeration { enum workday { description "Contextual outlier associated to workday."; } enum holiday { description "Contextual outlier associated to holiday."; } } description "Associated season."; } } augment "/rsn:relevant-state/rsn:anomaly" + "/rsn:symptom" { description "Provide extension for the symptom description, specifically for connectivity services to the relevant state container"; uses cbl-symptom; } augment "/rsn:relevant-state-notification/rsn:anomaly" + "/rsn:symptom" { description "Provide extension for the symptom description, specifically for connectivity services to the relevant state notification"; uses cbl-symptom; } } ]]>

The YANG module has a service and a vpn-termination grouping defining a 'vpn-id', a 'vpn-name' 'site-ids' and a 'change-id' with 'start' and 'end time' for 'service' and 'hostname', 'VRF ID', 'VRF Name', 'BGP route-distinguisher', 'BGP peer ip address', 'BGP path next-hop', 'node interface-id' and 'node interface-name' for 'node-termination' list and 'hostname', 'BGP route-distinguisher', 'BGP path next-hop' and 'BGP peer ip address' for 'network-termination' list. Within the NMOP working group we discuss with the SIMAP authors which existing YANG nodes instead could be used to facilitate a service and network topology context view.

The 'ietf-network-anomaly-service-topology' module defines reusable groupings for augmenting the 'relevant-state' model. It defines placeholders for defining VPN information that is associated to the relevant state. WG List: Editor: Thomas Graf Wanting Du Alex Huang Feng Vincenzo Riccobene "; description "This module defines the symptom container to be used by a network anomaly detection system. The defined objects can be used to augment operational network collected observability data and analytical problem data equally. Describing the relevant-state of observed symptoms. Copyright (c) 2025 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Revised BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). All revisions of IETF and IANA published modules can be found at the YANG Parameters registry (https://www.iana.org/assignments/yang-parameters). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; revision 2025-11-15 { description "Initial version"; reference "RFC XXX: Semantic Metadata Annotation for Network Anomaly Detection"; } grouping l2vpn-service { description "Connectivity service of type VPN. This grouping is used to augment the relevant-state container."; list l2vpn-service { key "vpn-id"; description "List of VPN connectivity services of interest."; leaf vpn-id { type string; mandatory true; description "Unique ID of the VPN connectivity service."; } leaf uri { type inet:uri; description "URI to viusalize the VPN connectivity service inventory."; } leaf vpn-name { type string; description "Name of the VPN connectivity service."; } leaf-list site-ids { type string; description "List of unique site ID's of the VPN connectivity service."; } leaf change-id { type yang:uuid; description "Unique identifier of VPN connectivity service maintenance window within the relevant-state window."; } leaf change-start-time { type yang:date-and-time; description "Start date and time of the VPN connectivity service maintenance window within the relevant-state window."; } leaf change-end-time { type yang:date-and-time; description "End date and time of the VPN connectivity service maintenance window within the relevant-state window."; } } } grouping l3vpn-service { description "Connectivity service of type VPN. This grouping is used to augment the relevant-state container."; list l3vpn-service { key "vpn-id"; description "List of VPN connectivity services of interest."; leaf vpn-id { type string; mandatory true; description "Unique ID of the VPN connectivity service."; } leaf uri { type inet:uri; description "URI to viusalize the VPN connectivity service inventory."; } leaf vpn-name { type string; description "Name of the VPN connectivity service."; } leaf-list site-ids { type string; description "List of unique site ID's of the VPN connectivity service."; } leaf change-id { type yang:uuid; description "Unique identifier of VPN connectivity service maintenance window within the relevant-state window."; } leaf change-start-time { type yang:date-and-time; description "Start date and time of the VPN connectivity service maintenance window within the relevant-state window."; } leaf change-end-time { type yang:date-and-time; description "End date and time of the VPN connectivity service maintenance window within the relevant-state window."; } } } grouping vpn-node-termination { description "Node and Network Termination for the VPN Service instance. This grouping is used to augment the relevant-state container."; list vpn-node-terminations { key "hostname vrf-name"; description "List of Node Terminations of interest."; leaf hostname { type inet:host; description "The hostname of the network node. This value is usually configured on the node by the administrator to uniquely identify the node in the network."; } leaf vrf-id { type uint32; description "The VRF id obtained through IPFIX IE234 ingressVRFID or IE235 egressVRFID."; } leaf vrf-name { type string; description "The VRF name obtained through IPFIX IE236 VRFname or BMP peer_up VRF Table Name TLV."; } leaf route-distinguisher { type string; description "The BGP route-distinguisher obtained through IPFIX IE90 mplsVpnRouteDistinguisher or BMP route-monitoring or peer_up message type."; } leaf-list interface-id { type uint32; description "The interface identifier obtained through IPFIX IE10 ingressInterface, IE14 egressInterface or ietf-interfaces:interfaces/interface/if-index."; } leaf-list interface-name { type string; description "The interface name obtained through IPFIX IE82 interfaceName or ietf-interfaces:interfaces/interface/name."; } leaf-list peer-ip { type inet:ip-address; description "The BGP peering IP address learned through BMP route-monitoring, peer_up or peer_down message type."; } leaf-list next-hop { type inet:ip-address; description "The BGP next-hop IP address learned through BMP route-monitoring message type."; } } } augment "/rsn:relevant-state/rsn:service" { description "Provide extension for the service description, specifically for connectivity services to the relevant state container."; case l2vpn { description "Layer 2 VPN connectivity service."; uses l2vpn-service; } case l3vpn { description "Layer 3 VPN connectivity service."; uses l3vpn-service; } } augment "/rsn:relevant-state-notification/rsn:service" { description "Provide extension for the service description, specifically for connectivity services to the relevant state notification."; case l2vpn { description "Layer 2 VPN connectivity service."; uses l2vpn-service; } case l3vpn { description "Layer 3 VPN connectivity service."; uses l3vpn-service; } } augment "/rsn:relevant-state/rsn:anomaly" { description "Provide extension for the service description, specifically for connectivity services to the relevant state container."; uses vpn-node-termination; } augment "/rsn:relevant-state-notification/rsn:anomaly" { description "Provide extension for the service description, specifically for connectivity services to the relevant state notification."; uses vpn-node-termination; } } ]]>

Depending on implementation, a network operator might chose defined YANG models as data models or uses the YANG models as information data models and transform them to another schema format such as to use as data model for integration. Shows the entire notification schema of 'ietf-relevant-state.yang' from , 'ietf-network-anomaly-service-topology.yang' from and 'ietf-network-anomaly-symptom-cbl.yang' from as an Apache AVRO schema. The Apache AVRO schema is decomposed based on YANG groupings as following: RelevantStateNotification.avsc is based on 'relevant-state-grouping' defined in 'ietf-relevant-state.yang' with 'ietf.relevant.state.Publisher', 'ietf.relevant.state.Anomaly', 'ietf.relevant.state.VpnNodeTermination' and 'ietf.relevant.state.VpnService' AVRO schema imports. Publisher.avsc is based on 'publisher' container defined in 'ietf-relevant-state.yang'. Anomaly.avsc is based on 'anomaly-grouping' defined in 'ietf-relevant-state.yang' with 'ietf.relevant.state.Annotator' and 'ietf.relevant.state.Symptom' AVRO schema imports. Annotator.avsc is based on 'anotator-grouping' defined in 'ietf-relevant-state.yang'. Symptom.avsc is based on 'cbl-symptom' defined in 'ietf-network-anomaly-symptom-cbl.yang'. L2VpnService.avsc, L2VpnServiceContainer.avsc, L3VpnService.avsc and L3VpnServiceContainer.avsc is based on 'vpn-service' defined in 'ietf-network-anomaly-service-topology.yang'. VpnTermination.avsc is based on 'vpn-termination' defined in 'ietf-network-anomaly-service-topology.yang'.

This document registers the following two namespace URIs in the IETF XML Registry: URI: urn:ietf:params:xml:ns:yang:ietf-network-anomaly-symptom-cbl Registrant Contact: The IESG. XML: N/A; the requested URI is an XML namespace. URI: urn:ietf:params:xml:ns:yang:ietf-network-anomaly-service-topology Registrant Contact: The IESG. XML: N/A; the requested URI is an XML namespace. This document registers the following two YANG modules in the YANG Module Names registry: Name: ietf-network-anomaly-symptom-cbl Namespace: urn:ietf:params:xml:ns:yang:ietf-network-anomaly-symptom-cbl Prefix: smcblsymptom Reference: RFC XXXX Name: ietf-network-anomaly-service-topology Namespace: urn:ietf:params:xml:ns:yang:ietf-network-anomaly-service-topology Prefix: smtopology Reference: RFC XXXX

This section is modeled after the template described in . The "ietf-network-anomaly-symptom-cbl" and "ietf-network-anomaly-service-topology" YANG modules defines two data models that are designed to be accessed via YANG-based management protocols, such as NETCONF and RESTCONF . These protocols have to use a secure transport layer (e.g., SSH , TLS , and QUIC ) and have to use mutual authentication. The Network Configuration Access Control Model (NACM) provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. There are a number of data nodes defined in this YANG module that are writable/creatable/deletable (i.e., "config true", which is the default). All writable data nodes are likely to be reasonably sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) and delete operations to these data nodes without proper protection or authentication can have a negative effect on network operations. The following subtrees and data nodes have particular sensitivities/vulnerabilities: "There are no particularly sensitive writable data nodes." Some of the readable data nodes in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes. Specifically, the following subtrees and data nodes have particular sensitivities/ vulnerabilities: "There are no particularly sensitive readable data nodes."

This section provides pointers to existing open source implementations of this draft. Note to the RFC-editor: Please remove this before publishing.

A tool called Antagonist has been implemented and refined during the IETF 119 and 120 hackathons, in order to validate the application of the YANG models defined in this draft. Antagonist provides visual support for two important use cases in the scope of this document:

the generation of a ground truth in relation to Symptoms and Problems in timeseries data
the visual validation of results produced by automated network anomaly detection tools.

The open source code can be found here:

A real-time streaming based Service Disruption Detection System has been deployed in Swisscom production as a proof of concept in June 2024 monitoring approximate >13'000 L3 VPN's concurrently. The Apache AVRO schema described in is being implemented in April 2025 in the development enviroment and considered to be deployed in June 2025 in production.

The authors would like to thank , for his review and valuable comment. The authors would like to thank Antonio Roberto for his contribution to the ideas in this draft and Reshad Rahman, Mohamed Boucadair and Ruediger Geib for his review and valuable comments.