SIMAP: Concept, Requirements, and Use Cases

SIMAP: Concept, Requirements, and Use Cases Huawei

olga.havel@huawei.com

Everything OPS & Arrcus

Belgium benoit@everything-ops.net

Telefonica

oscar.gonzalezdedios@telefonica.com

Swisscom

thomas.graf@swisscom.com

Operations and Management Network Management Operations Service & Infrastructure Maps Service emulation Automation Network Automation Orchestration Service delivery Service provisioning Service flexibility Service simplification Network Service Digital Map Emulation Simulation Topology Multi-layer This document defines the concept of Service & Infrastructure Maps (SIMAP) and identifies a set of SIMAP requirements and use cases. The SIMAP was previously known as Digital Map. SIMAP evolves the earlier 'Digital Map' concept by making explicit the ties between service and infrastructure layers, clarifying expected outcomes for operations and automation, and addressing ambiguity associated with the term 'digital.' The document intends to be used as a reference for the assessment of the various topology modules to meet SIMAP requirements.

Introduction This document defines the concept of Service & Infrastructure Maps (SIMAP) and outlines associated requirements and use cases. SIMAP is a data model that provides a topological view of the operator's networks and services, including how it is connected to other models (e.g., inventory) and external data sources (e.g., observability data, and operational knowledge). This model represents a multi-layered topology and offers mechanisms to navigate amongst layers and correlate between them, including layers from physical to service topology. This model is applicable to multiple domains (access, core, data center, etc.) and technologies (Optical, IP, etc.). While this document refers to SIMAP as a data model to reflect the Working Group's intent that it be concretely implementable, the actual data model specification - including the choice of modelling language and implementation approach - is out of scope of this document and will be defined in companion specifications. In particular, SIMAP is not restricted to YANG. YANG is the expected first realization of SIMAP in the IETF context, and this document refers to YANG modules where that helps the reader, but the concept and the requirements in are intended to be independent of the modelling language. Specifically, the SIMAP modelling defines the core topological entities at each layer, core topological properties, and topological relationships (both inside each layer and between the layers), to ensure a multi-layered topology can be reconstructed, validated and queried in an unambiguous and interoperable manner. The core topological entities are the minimal set of objects required to represent a layer's topology (e.g., network, node, termination point, and link). The core topological properties are the essential attributes associated with these entities (e.g., identity, topology type, entity role in topology, directionality, cardinality, and cost/weight), enabling analysis of how the network structure affects services and operations. For example, topological reasoning, together with the routing and forwarding state linked from the SIMAP, can answer questions such as: 'If link X fails, what services are impacted?' or 'What is the full end-to-end data path of the service flow?'. The additional concepts or attributes (such as capacity, operational state, performance metrics, or inventory data) are modelled outside of SIMAP, the core set provides the necessary structure to support these extensions without losing architectural consistency. The SIMAP modelling also defines how to access other external models from a topology. SIMAP is a topological model that is linked to other functional models and connects them all: configuration, maintenance, assurance (KPIs, status, health, and symptoms), Traffic-Engineering (TE), different behaviors and actions, simulation, emulation, mathematical abstractions, AI algorithms, etc. These other models exist outside of the SIMAP and are not defined during SIMAP modelling. The SIMAP data consists of instances of network and service topologies at different layers. There may be a separate topology instance for each layer in a multi-layered network, or a single topology instance that encompasses multiple layers. Since SIMAP is a data model and data models can drive APIs ( describes such a data-model-driven API, where a client derives resource URLs and message structure from the YANG modules), the SIMAP provides access to this data via standard APIs for both read and write access, typically from a controller, with query capabilities and links to other data models (e.g., Service Assurance for Intent-based Networking (SAIN) , Service Attachment Points (SAPs) , Inventory , and potentially linking to non-YANG models). The SIMAP also provides write operations with the same set of APIs. These are not intended to change the live network by writing to the topology, as a configuration northbound interface from the controller would; changes are applied to the network via the normal controller operations. Write access serves two other purposes: online and offline simulation, and recording topology that cannot be discovered from the network, such as the intended topology and the passive topology. Both real network, online simulation, and offline simulation APIs can be built on the same data model. The real network API reflects actual changes in the topology as reported by a SIMAP server. Online simulation applies hypothetical changes to the current live model to assess immediate impacts (e.g., if link X fails, what services are disrupted), without altering the real network. Offline simulation applies hypothetical changes to a saved or alternate model, useful for planning, training, or evaluating changes before deployment. Each data source is reported as a distinct topology instance. Where the real network and online simulation data are merged into a single topology instance, every simulated element remains identifiable as simulated; the offline simulation remains separate. The simulated topology instance can be matched directly to the corresponding real network topology for comparison. This approach preserves independence between real and simulated data while enabling side by side analysis. These simulation capabilities, together with the different levels of abstraction at which a SIMAP can represent a network, are some of the building blocks of a Network Digital Twin. The relationship between SIMAP and the Network Digital Twin concept is discussed in . summarizes other IETF work related to topology modelling, including , and how it relates to the SIMAP. It is informative: this document does not prescribe which models are used as the basis for a SIMAP.

Terminology 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. The normative keywords in this document define requirements for future SIMAP specifications and implementations, and do not impose requirements on this document itself. This document does not define conformance criteria; a SIMAP specification is expected to state how conformance to it is assessed. This document makes use of the following terms:

Domain:

A collection of network resources, services, and management functions that are administered under a common set of policies or operational control. Domains may correspond to technology boundaries (e.g., optical, IP), functional areas (e.g., access, core, data center), or administrative partitions. Multi-domain SIMAP operations involve correlating topology and service information across such domains.

Topology:

Topology refers to the network and service topology. A network topology defines how physical or logical nodes, links and termination points are related and arranged. A Service topology defines how service components (e.g., VPN instances, customer interfaces, and customer links) between customer sites are interrelated and arranged.

There are several types of topologies, for example: point-to-point, bus, ring, star, tree, mesh, hybrid, and daisy chain.

Topologies may be unidirectional (all links unidirectional) or bidirectional (all links bidirectional), or contain combination of unidirectional and bidirectional links.

Where a link is bidirectional, the two directions may or may not be supported by the same underlay resources. Both cases, co-routed and non-co-routed (also referred to as associated) bidirectionality, need to be distinguishable, since they differ in fate sharing and therefore change the outcome of any impact analysis.

Multi-layered topology:

A multi-layered topology models relationships between different topology layers, where each layer represents a connectivity aspect of the network and services that needs to be configured, controlled and monitored. Each topology layer has a separate lifecycle.

also refers to this multi-layered topology as topology hierarchy (stack). It also uses layers when describing supporting relations (represent layered network topologies), underlay/overlay, network nodes and layering information. states that the model can be used for representation of layered network topologies.

is flexible and can support both the same network topology instance with multiple layers (e.g., Layer 2 and Layer 3) or separate network topology instances with supporting relations between them (e.g., separate Layer 2 and Layer 3). Therefore, multiple topology layers can be grouped into the same network topology instance, if solution requires.

Topology layer:

A topology layer represents Topology at a single layer in the multi-layered topology.

The topology layer can also represent what needs to be managed by a specific user or client application, for example the IGP layer can be of interest to the operator troubleshooting or optimizing the routing, while the optical layer may be of interest to the user managing the optical network.

Some topology layers may relate closely to OSI layers, like Layer 1 topology for physical topology, Layer 2 for link topology and Layer 3 for IPv4 and IPv6 topologies. The correspondence is deliberately loose: as defined above, each topology layer represents a connectivity aspect of the network and services that needs to be configured, controlled and monitored, and such layers are not required to map one to one onto the OSI layers.

Some topology layers represent the network topology of Layer 3 control protocols, like OSPF, IS-IS, or BGP.

The service layer represents the Service view of the connectivity, that can differ for different types of Services and for different providers/solutions.

The application/flow layer represents the view of Service data flows for different classes of service - video, voice and data traffic. The layers may differ depending on the solution, so the bottom and top layers may not be the same across all solutions. We can illustrate the concept of topology layers by listing the common set - e.g.,

physical: Layer 1, one or multiple layers, if fully modelling different optical layers. Used for WSON, OTN optical, OTN digital),
data link: Layer 2 for Ethernet, LAGs and VLAN,
network: Layer 3 for IPv4 and IPv6. IPv4 and IPv6 may be modelled as a single topology layer or as separate topology layers, since the two topologies are not necessarily congruent,
IGP/EGP: for routing inside or between ASs, different layers for underlay and overlay, for ISIS, OSPF, iBGP, eBGP,
tunnel/transport: for transport tunnels, paths and policies, for example GRE, IPsec, pseudowires, MPLS-TE LSPs, and SR/SRv6 policies,
service: for different overlay services, like L2VPNs, L3VPNs, slices, SD-WAN,
application: for video, voice and data traffic flows.

However, this list is illustrative only; it is not a prescriptive requirement. Different solutions may adopt alternative layering schemes or combine layers differently. Therefore, we will present the above as an example of one possible solution, while keeping the definition flexible enough to accommodate flexible layering.

Service:

A service represents network connectivity service provided over a network that enables devices, systems, or networks to communicate and exchange data with each other. It provides the underlying infrastructure and mechanisms necessary for establishing, maintaining, and managing connections between different endpoints. The example services are: L2VPN, L3VPN, EVPN, VPLS, and VPWS.

Resource:

Defined in .

Intent:

Defined in .

Termination Point:

Defined in , as follows:

The network-topology module defines a topology graph and components from which it is composed: nodes, edges, and termination points. Nodes (from the "ietf-network" module) represent graph vertices and links represent graph edges. Nodes also contain termination points that anchor the links.

A node has a list of termination points that are used to terminate links. An example of a termination point might be a physical or logical port or, more generally, an interface. Like a node, a termination point can in turn be supported by an underlying termination point, contained in the supporting node of the underlay network.

The document defines the following terms:

Service & Infrastructure Maps (SIMAP):: SIMAP is a data model that provides a topological view of the operator's networks and services, including how it is connected to other models (e.g., inventory) and external data sources (e.g., observability data, and operational knowledge). It specifically provides an approach to model multi-layered topology and an appropriate mechanism to navigate amongst layers and correlate between them. This includes layers from physical topology to service topology. This model is applicable to multiple domains (access, core, data centers, etc.) and technologies (Optical, IP, etc.)
: Therefore, SIMAP defines the core topological entities, their role in the network, core topological properties, and relationships both inside each layer and between the layers. It is a basic topological model with references/pointers to other models and connects them all: configuration, maintenance, assurance (KPIs, status, health, symptoms, etc.), traffic engineering, different behaviors, simulation, emulation, mathematical abstractions, AI algorithms, etc.
SIMAP modelling:: SIMAP modelling is the set of principles, guidelines, and conventions to model the SIMAP. They cover the network types (layers and sublayers), entity types, entity roles (network, node, termination point, or link), entity properties, relationship types between entities and relationships to other entities.
SIMAP data:: SIMAP data consists of instances of network and Service topologies at different layers. This includes instances of networks, nodes, links and termination points, topological relationships between nodes, links and termination points inside a network, relationships between instances belonging to different networks, links to other non-topological data for the instances (e.g., inventory, configuration, health, symptoms).
: The SIMAP data can be historical, real-time, or future data for 'what-if' scenarios.
: There may be multiple SIMAP data instances of the same kind at the same time, for example several snapshots, several potential topologies, or several intended topologies, each identifiable and retrievable independently.
SIMAP API:: SIMAP API is the set of interfaces that allow the client applications to create, read, update, and delete data that conforms to the SIMAP.
SIMAP client application:: Consumer of the SIMAP API. An application that consumes the SIMAP API. It sends requests to a SIMAP server, receives responses, and uses the returned data to drive its own logic. Typical clients include network management systems, orchestration tools, monitoring dashboards, capacity management applications, or any software that needs to read or modify the topology information defined by the SIMAP. The client is responsible for forming valid API calls, handling authentication/authorization, parsing responses, and translating the SIMAP into its own internal representation. A client application may be built to support a single use case or several of them; the set of use cases a given client covers is deployment-specific.
SIMAP server:: Provider of the SIMAP API. An application or a system that implements the API endpoints to expose the SIMAP data model to external consumers, building it from live network state or simulation scenarios. The server accepts requests to create, read, update, delete, or query instances of the SIMAP topology, validates input against the data model schema, persists changes (if any), and returns responses that conform to the SIMAP API specification. The server's implementation may reside inside a controller, orchestrator, device, service manager, or any other application/system, or be a standalone application/system, depending on the solution architecture. The server may offer ancillary services such as authentication, rate limiting, versioning, logging, and monitoring, but its primary role is to expose the SIMAP via programmable interface.

Sample SIMAP Use Cases The following subsections provide a non-exhaustive list of SIMAP use cases, with a focus on the related SIMAP client application requirements and its interactions with SIMAP server, in order to extract the SIMAP-related requirements (Section 4). In this section, the ability to retrieve "a topology layer" or "the topology at any layer" is always subject to what the client application is authorized to see: a SIMAP server may hide layers, or expose an abstraction of a layer in place of the layer itself, for security, administrative, or commercial reasons. Where the underlying resources are not disclosed, the client is presented with an abstract topology and navigates that instead (REQ-TOPOLOGY-ABSTRACTION).

Common Enablers for SIMAP This section identifies a set of enablers that are invoked when providing the various business-oriented SIMAP use cases. These enablers are grouped here to avoid duplication.

Service -> Resource The SIMAP APIs can be invoked to retrieve all Services for selected service types. A SIMAP client application that triggers such a request will be able to retrieve the topology for selected Services via the SIMAP APIs and, from the response, it will be able to navigate top-down to the lower layers via the supporting relationship provided by a SIMAP server. In doing so, the SIMAP client application will be able to determine what logical resources are used by a Service. The supporting relations to the lowest layer, provided by the SIMAP server, will help the SIMAP client application to determine what physical resources are used by the Service. This addresses a requirement for systems to be able to provide topology and resource views of services, at different levels of abstraction, using the SIMAP . Knowing the physical resources a service uses enables capacity planning, fault isolation, performance monitoring, and accurate billing.

Resource -> Service A SIMAP client application can navigate from the physical, Layer 2, or Layer 3 topology to the Services that rely upon specific resources. For example, the application will be able to select the resources and by navigating the supporting relationship bottom-up come to the Service and its nodes, termination points and links. These APIs can be invoked for Service impact analysis, for example.

Traffic Engineering (TE) Traffic Engineering (TE) is a network optimization technique designed to enhance network performance and resource utilization by intelligently controlling the flow of data, for example by enabling dynamic path selection based on constraints such as bandwidth availability, latency, and link costs. Its primary goals are to prevent network congestion, balance traffic loads, and ensure efficient use of bandwidth while meeting performance requirements. The use cases for network capacity planning (), network simulation and network emulation (), closed loop (), and potentially others, should consider TE if configured in the network.

Closed Loop A network closed loop refers to an automated and intelligent system where network operations are continuously monitored, analysed, and optimized in real time through feedback mechanisms. This self-adjusting cycle ensures that the network dynamically adapts to changes, resolves issues proactively, and maintains optimal performance without manual intervention. Key Characteristics of a network closed loop:

Real-time monitoring: Collects data from network devices, traffic flows, and applications to build a comprehensive view of network health and performance.
Automated analysis: Identify anomalies, predict potential failures, or detect security threats, for example leveraging AI and machine learning.
Proactive action: Automatically triggers corrective measures, such as reconfiguring devices, isolating compromised endpoints, or rerouting traffic.
Continuous optimization: Uses feedback from previous cycles to refine network policies and improve future responses.

A SIMAP client application will be able to retrieve a topology layer and any network/node/termination point/link instances from a SIMAP server via the SIMAP APIs and from the response it will be able to map the traffic analysis to the entities (typically links and router) for automated analysis. The corrective measures would be applied to the network through the controller's normal configuration interfaces, optionally after validating them in an offline simulation (see the simulation and traffic engineering use cases); the SIMAP then reflects the resulting topology.

Inventory Queries A network inventory refers to a comprehensive record or database that tracks and documents all the network components and devices within an organization's infrastructure. Key elements typically found in a network inventory include:

Hardware details:

Descriptions of physical devices such as routers (including their internal components such as cards, power supply units, pluggables), switches, servers, network cables, including model numbers, serial numbers, and manufacturer information. This information will facilitate locating additional details of the hardware in the manufacturer systems and the correlation with the purchase catalog of the company.
Software and firmware:

Versions of operating systems, network management tools, and firmware running on network devices. Note that a network device can have components with their own software and firmware.
Licensing information:

For any licensed software or devices, the network inventory will track license numbers, expiry dates, and compliance.

A network inventory lifecycle refers to the stages a network device or component goes through from its introduction to the network until its removal or replacement. It encompasses everything from acquisition and deployment to maintenance, upgrade, and eventually decommissioning. Managing the network inventory lifecycle efficiently is crucial for maintaining a secure, functional, and cost-effective network. A well-maintained network inventory helps organizations with network management, troubleshooting, asset tracking, security, and ensuring compliance with regulations. It also helps in scaling the network, planning upgrades, and responding to issues quickly. In order to facilitate the planning and troubleshooting processes it is necessary to be able to navigate from network inventory to network topology and Services. A SIMAP client application will be able to retrieve physical topology from a SIMAP server via the SIMAP APIs and from the response it will be able to retrieve the physical inventory of individual devices and cables and the customer information, if applicable. A SIMAP client application may request either one or multiple topology layers via the SIMAP APIs and from the response it will be able to navigate to any other data models outside of the core SIMAP topology to retrieve both physical and logical inventory. For access network providers the ability to have linkage in the SIMAP of the complete network (active + passive) is essential as it provides many advantages for optimized customer Service, reduced Mean Time To Repair (MTTR), and lower operational costs through truck roll reduction. For example, operators may use custom-tags that are readily available for a customer-facing device, then query the inventory based on that tag to correlate it with the inventory and then map it to the network/service topology. The mapping and correlation can then be used for triggering appropriate Service checks. See and for inventory modelling.

Service Placement Feasibility Checks Service placement feasibility checks refer to the process of evaluating whether a specific Service can be deployed and operated effectively in a given network. This includes assessing the various factors to ensure that the service will function as intended (e.g., based on traffic performance requirements) without causing network disruptions or inefficiencies and affecting other Services already provisioned on the network. Some of the factors that need assessing are network capabilities, status, limitations, resource usage and availability. The Service could be simulated during the feasibility checks to identify if there are any potential issues. The load testing could be done to evaluate performance under stress. The service placement feasibility check application will be able to retrieve the topology at any layer from a SIMAP server via the SIMAP APIs and from the response it will be able to navigate to any other data models outside of the core SIMAP topology to retrieve any other information needed, such as resource usage, availability, status, etc.

Intent/Service Assurance Network intent and Service assurance work together to ensure that the network aligns with business goals and that the Services provided meet the agreed-upon Service Level Agreements (SLAs). The Service Assurance for Intent-Based Networking Architecture (SAIN) approach emphasizes a comprehensive view of components involved in Service delivery, including network devices and functions, to effectively monitor and maintain Service health. The key objectives of this architecture include:

Global service monitoring:

By considering all elements involved in Service delivery, the architecture enables an assessment of service health.
Correlation of Service degradation:

It assists in linking Service performance issues to specific network components, facilitating precise identification of faults.
Impact assessment:

A SAIN implementation identifies which Services are affected by the failure or degradation of particular network components, aiding in prioritizing remediation efforts.

When a Service is degraded, a SAIN implementation will highlight where to look in the assurance Service graph, as opposed to going hop by hop to troubleshoot the issue. More precisely, it will associate a list of symptoms originating from specific SAIN subservices to each Service instance, corresponding to components of the network. These components are good candidates for explaining the source of a Service degradation. A SIMAP client application will be able to retrieve a topology layer and any network/node/termination point/link instances from a SIMAP server via the SIMAP APIs and from the response it will be able to determine the health of each instance by navigating to the SAIN subservices and its symptoms.

Service E2E and Per-link KPIs A SIMAP client application will be able to retrieve a topology at any layer from a SIMAP server via the SIMAP APIs and from the response it will be able to navigate to and retrieve any KPIs for selected topology entity.

Network Capacity Planning Network capacity planning refers to the process of analysing, predicting, and ensuring that the network has sufficient capacity (e.g., ), resources, and infrastructure to meet current and future demands. It involves evaluating the network's ability to handle increasing (including forecasted) amounts of data, traffic, and users' activity, while maintaining acceptable levels of performance, reliability, and security. The capacity planning primary goal is to ensure that a network can support business operations, applications, and services without interruptions, delays, or degradation in quality. This requires a thorough understanding of the network's current state, as well as future requirements and growth projections. Key aspects of network capacity planning include:

Traffic analysis: Monitoring and analysing network traffic patterns to identify trends, peak usage periods, and areas of congestion. For example, by generating a core traffic matrix with IPFIX flow record or deducting an approximate traffic matrix from the link utilization data.
Resource utilization: Evaluating the link utilization throughout the network for the current demand to identify bottlenecks and potential QoS performance issues.
Growth forecasting: Predicting future network growth based on business expansion, new applications, or changes in users' behavior.
What-if scenarios: Creating models to assess the network behavior under different scenarios, such as increased traffic, failure conditions (link, router or Shared Risk Link Group (SRLG) ), and new application deployments (such as a new Content Delivery Network source, a new peering point, a new data center...).
Upgrade planning: Identifying areas where upgrades or additions are needed to ensure that the network can minimize the effect of node/link failures, mitigate QoS problems, or simply to support growing demands.
Cost-benefit analysis: Evaluating the costs and benefits of upgrading or adding new resources to determine the most cost-effective solutions.

By implementing a robust capacity planning process, organizations can:

Ensure better network reliability: Minimize downtime and ensure that the network is always available when needed.
Improve performance: Optimize network resources to support business-critical applications and Services.
Optimize costs: Avoid unnecessary over-provisioning by making informed decisions based on data-driven insights.
Support business growth: Scale the network to meet increasing demands and support business expansion.

The capacity planning application will be able to retrieve a topology layer and any network/node/termination point/link instances from a SIMAP server via the SIMAP APIs and from the response it will be able to map the traffic analysis to the entities (typically links and router), evaluate their current utilization, evaluate which elements to add to the network based on the growth forecasting, and finally perform the 'what-if' failure analysis by simulating the removal of link(s) and/or router(s) while evaluating the network performance.

Network Design Network design involves defining both the logical structure, such as access, aggregation, and core layers, and the physical layout, including devices and links. It serves as a blueprint, detailing how these elements interconnect to deliver the intended network behavior and functionality. The application will generate a candidate network topology, based on the initial design and the current network topology; this candidate network topology can then undergo further analysis (e.g., perform traffic flow simulations to identify bottlenecks and redundancy checks to ensure resilience) before being transformed into actionable intent and, eventually, deployment actions. Throughout the network's lifecycle, the design rules embedded within a topology can be continuously validated. For example, a link rule might specify that a connection between core and aggregation layers must have its source(s) and destination(s) located within the same data center. Another example is to declare that a specific link type should only exist between Core <-> Aggregation layer with certain constraints on port optic speed, type (LR vs SR for instance), etc. The network design application can (via SIMAP API):

Write the intended network interconnect (topology + rules), this is the intent of the network topology that cannot be retrieved from the real network (e.g., Layer 2 topology interconnect intent, or Layer 3 topology interconnect intent). One network (in case of small network) or interconnect of multiple networks (bigger networks).
Retrieve the proposed network interconnect (topology + rules)
- Use case can be for purpose of traffic simulation, testing behavior under failures. Network simulation use case is described in .
- Use case can be for purpose of comparing different proposed network interconnects.
- Use case can be to build a simulated environment using this design. Network simulation use case is described in .
Retrieve the intended network interconnect (topology + rules)
At any point in time, compare the discovered topology with intended one
- Potentially validating discovered device configurations with intended ones assuming SIMAP has the external reference to configuration from topology.

Network Simulation and Network Emulation Network simulation is a process used to analyse the behaviour of networks via software. It allows network engineers and researchers to assess how the network protocols work under different conditions, such as different topologies, traffic loads, network failures, or the introduction of new devices. Network emulation, on the other hand, replicates the behavior of a real-world network, allowing for more realistic analysis compared to network simulation. While network simulation focuses on modeling and approximating network behavior, network emulation involves creating a real-time, functional network environment whose protocols behave exactly like a real network. Ideally, network emulation uses the same software images as the real network, but it could also be performed (with less accuracy) using generic software.

Types of Network Simulation There are several types of network simulations, each designed to address specific needs and use cases. The categories below are provided as background, to illustrate the range of simulation a SIMAP may be asked to support; this document does not define a new classification of network simulation.

Discrete event simulation:

This is the most common type of network simulation. It models a series of events that occur at specific points in time. Each event triggers a change in the state of a network component (e.g., a link is down, a card fails, or a packet arrives).
Continuous simulation:

In contrast to discrete event simulation, continuous simulation models systems where variables change continuously over time. Network parameters like bandwidth, congestion, and throughput can be treated as continuous functions.

The main use case is to model certain aspects of network performance that evolve continuously, such as link speeds or delay distributions in links that are impacted by environmental conditions (such as microwave or satellite links).
Monte Carlo simulation:

This type of simulation uses statistical methods to model and analyse networks under uncertain or variable conditions. Monte Carlo simulations generate a large number of random samples to predict the performance of a network across multiple scenarios. It is used for probabilistic analysis, risk assessment, and performance evaluation under uncertain conditions.

Goals of Network Simulation The simulations can be also classified depending on the goal of the simulation.

Network Protocol Analysis This type of simulation focuses on simulating specific networking protocols (IS-IS, OSPF, BGP, SR) to understand how they perform under different conditions. It models the protocol operations and interactions amongst devices in the network. For example, simulation can be used to assess the impact of changing a link metric. Moreover, specific features of the networking protocol can be tested. For example, how fast-reroute performs in a given network topology.

Traffic Simulation This simulation focuses on modelling traffic flow across the network, including packet generation, flow control, routing, and congestion. It aims to evaluate traffic's impact on network performance. The main use is to model the impact of different types of traffic (e.g., voice, video, mobile data, web browsing) and understand how they affect the network's bandwidth and congestion levels. It can be used to identify bottlenecks and assist the capacity planning process.

Simulation of Different Topologies Under Normal and Failure Scenarios This type of simulation focuses on the structure and layout of the network itself. It simulates different network topologies and their impact on the network's performance. It can be used, together with the traffic simulation, to evaluate the most efficient topology for a network under normal conditions and considering factors like fault tolerance.

Use of the SIMAP for Simulation and Emulation Whichever type of simulation is used, a SIMAP client application will be able to retrieve a topology layer, and any network/node/termination point/link instances, from a SIMAP server via the SIMAP APIs, and to navigate from those entities to the other models needed to parameterize the simulation, such as traffic metrics, capacity, or status. The hypothetical changes to be evaluated (e.g., removing a link, adding a node, or changing a link metric) are expressed by writing a potential network topology via the SIMAP APIs, either as a full topology or as the differences from the current snapshot, and the results are compared against the corresponding real network topology. Because a potential topology is distinct from the live one, the simulation does not alter the real network, and multiple alternative topologies can be evaluated and compared concurrently. For network emulation, the SIMAP serves as the source of the topology from which the emulated environment is built: the client application retrieves the multi-layered topology, at the layers relevant to the protocols being emulated, and instantiates the emulated nodes, links and termination points from it. The intended network topology can be used for this purpose where the emulation is to reflect a design rather than the current live network, as described in . The emulation itself, including the choice of software images and the runtime environment, is outside the scope of the SIMAP.

Postmortem Replay For the postmortem replay use case, the client application will use the SIMAP APIs for the purpose of analysis of network Service property evolution based on recorded changes. A collection of relevant timestamped network events, such as routing updates, configuration changes, link status modifications, traffic metrics evolution, and Service characteristics, is being made accessible from and/or within a SIMAP to support investigation and automated processing. Using a structured format, the stored data can be replayed in sequence, allowing network operators to examine historical network behavior, diagnose issues, and assess the impact of such events on Service assurance. The mechanism supports correlation with external data sources to facilitate comprehensive post-mortem analysis. Beyond centralizing and correlating such various sources of information, the SIMAP can supply the topology from which the network behaviour is simulated () to assist investigations. In essence, this use case builds upon a collection of other SIMAP use cases, such as inventory queries, intent/service assurance, Service KPIs, capacity planning, and simulation, to provide a thorough understanding of a network event impacting Service assurance. Note that this use case may serve as a component of Service Disruption Detection fine-tuning as described in .

Network Digital Twin (NDT) Per , Network Digital Twin (NDT) is a digital representation that is used in the context of Networking and whose physical counterpart is a data network (e.g., provider network or enterprise network). Also, as discussed in , network element models and topology models help generate a virtual twin of the network according to the network element configuration, operation data, network topology relationship, link state and other network information. The operation status can be monitored and displayed, the network configuration change and optimization strategy can be pre-verified and historical data can support, e.g., postmortem replay () further elaborates on the requirements on various interfaces:

Network-facing interfaces are twin interfaces between the real network and its twin entity. They are responsible for the information exchange between a real network and NDT. SIMAP APIs can be used within such interfaces.
Application-facing interfaces are between the NDT and applications. They are responsible for the information exchange between Network Digital Twin and network applications. SIMAP APIs can be used for specification of hypothetical network and service states for 'what-if' analysis, e.g., for service feasibility checks (), simulation or emulation (). Such analysis may be used in support of e.g., network capacity planning () or network design ().

recommends that these interfaces are open and standardized so as to avoid either hardware or software vendor lock and achieve interoperability. While network emulation () can be a component within an NDT, the NDT itself is a broader construct that integrates multiple modeling techniques, including emulation, simulation, and analytics, to support intelligent network operations. NDT uses network emulation and includes network emulation use case, but it also interacts with the real network to support intelligent operations, including predictive analytics, intent verification, and full lifecycle management of network and services.

SIMAP Operator Requirements The SIMAP operator requirements are split into three groups for different target audiences:

Functional requirements:

These requirements are collected from the operators and derived from the operators' use cases.
Design requirements:

These requirements are derived from the operator requirements. Although there is some duplication, these are focused on summarizing the operators' requirements for the design of the data model and API. These are functional requirements translated into low-level requirements for the model designers. The rationale for adopting this approach is to ensure that the data model is designed according to the operators' requirements and that they could be used for both design and review of the candidate data models.
Architectural requirements:

Architectural (non-functional) requirements are captured as well, as operators identified performance needs, large scale support, and network discovery. These are not data model requirements, but are requirements either to drive the APIs design itself (e.g., to better optimize performance) or for the SIMAP servers that expose a SIMAP API. Although, they may be common sense requirements not specific to SIMAP API, they are listed here for completeness.

The requirements in this section record what operators need from a SIMAP and are input to future SIMAP specifications. A requirement binds future SIMAP specifications and implementations only where it uses the normative keywords of in upper case: REQ-PROG-OPEN-MODEL (), and REQ-PERFORMANCE, REQ-CONGESTION and REQ-SECURITY (). The other requirements are written in lower case and are not conformance statements.

Functional Requirements The following are the operators' requirements for the SIMAP. Note that some of these requirements are supported by default by .

REQ-BASIC-MODEL-SUPPORT:: Basic model with network, node, link, and termination point entity types.
: This means that users of SIMAP must be able to reconstruct a topology at any layer in an unambiguous manner via these core concepts only, without the need to understand layer or technology specific information.
REQ-LAYERED-MODEL:: Topology layers from physical layer up to Service layer.
: SIMAP must provide views for all layers of network topology, from physical network (ideally optical), Layer 2, Layer 3 up to Service and intent views. It must provide flexibility to support both the same network topology instance with multiple layers (e.g., Layer 2 and Layer 3) or separate network topology instances with supporting relations between them (e.g., separate Layer 2 and Layer 3). Multiple topology layers can be grouped into the same network topology instance, if solution requires.
REQ-VIEWPOINTS:: SIMAP should provide different views to different client applications. For example, one client application may need to see Layer 2 and Layer 3 layers in a single network topology instance, while another client application may need to see them as separate network topology instances.
REQ-PASSIVE-TOPO:: SIMAP must support capability to model topology of the complete network. If the implementation requires passive topology to be part of the complete multi-layered topology, then SIMAP must support the capability to model the passive part of the network (in addition to the active part).
: For access network providers the ability to have linkage in the SIMAP of the complete network (active + passive) is essential as it provides many advantages for optimized customer Service, reduced MTTR, and lower operational costs through truck roll reduction.
: The passive topology must be either implemented in the SIMAP (what cannot be discovered can be added using the write API) or accessible from the SIMAP. Whether the passive topology is included as part of the SIMAP or accessible from the SIMAP is left to the solutions.
REQ-PROG-OPEN-MODEL:: Open and programmable SIMAP.
: This includes "read" operations to retrieve the view of the network, typically as application-facing interface of Software Defined Networking (SDN) controllers or orchestrators.
: It also includes "write" operations. These are not for directly changing the live network by writing to the SIMAP (e.g., changing the network or Service parameters), but for online and offline simulations, also known as what-if scenarios, and for recording topology that cannot be discovered from the network (see REQ-INTENDED and REQ-PASSIVE-TOPO).
: Running a "what-if" analysis requires the ability to take snapshots and to switch easily between them.
: Note that there is a need to distinguish between a change on the SIMAP for future simulation and a change that reflects the current reality of the network.
: SIMAP implementations and specifications MUST provide an unambiguous separation between real network topology state and simulation state. Simulation data MUST NOT overwrite, obscure, or be exposed as operational network state, and mechanisms MUST exist to ensure that simulated changes cannot be interpreted as real network conditions or configuration.
REQ-STD-API-BASED:: Standard-based SIMAP and APIs, for multivendor support.
: SIMAP must provide the standard APIs that provide for read, write, and query operations. These APIs must also provide the capability to retrieve the links to external data/models.
REQ-COMMON-API:: SIMAP and common APIs, for multi-domain.
: SIMAP and its APIs must be common over different network domains (campus, core, data center, etc.).
: This means that clients of the SIMAP APIs must be able to understand the topology model of layers of any domain without having to understand the details of any technologies and domains.
REQ-GRAPH-TRAVERSAL:: Topology graph traversal.
: SIMAP must be optimized for graph traversal to support both network path queries and other specific use case queries. This means that the SIMAP must provide an efficient means to retrieve network paths, to accommodate the difficulty operators experience when retrieving network paths via the chain termination-point->link->termination-point, without having a direct adjacency relation. Here, a network path is a path through the topology graph. The path that traffic actually takes additionally depends on routing and forwarding state, which can be linked from the SIMAP (see REQ-TOPO-ONLY and REQ-CONTROL-PLANE). Additionally, SIMAP must enable efficient retrieval of the data required by other use case queries.
REQ-TOPOLOGY-ABSTRACTION:: Navigation across the abstraction levels.
: A network (even a single layer network) can be represented in multiple ways providing different abstraction views of the same network. In such a case, it would be beneficial being able to navigate amongst the different levels of abstractions (e.g., to understand which set of nodes in the native topology are actually represented as a single node in an abstract topology being built on top of the native topology). This navigation is different and orthogonal to the multi-layer navigation where we need to report which Layer 2 path is supporting a given Layer 3 node or link. Nevertheless, it would not be the best practice to expose it via different topology APIs and model. Please refer to the for some background on the topology abstraction.
: SIMAP must provide a mechanism to navigate across the abstraction levels.
REQ-LIVE:: Live network topology.
: SIMAP must enable retrieval of multi-layered topology of a live network.
: Live network is the latest snapshot of the real network.
REQ-SNAPSHOT:: Network snapshot topology.
: SIMAP must enable retrieval of multi-layered topology of different snapshots.
: Snapshot is the view of the network at any given point in time.
REQ-POTENTIAL:: Potential new network topology.
: SIMAP must enable both retrieval and write access to a potential network topology.
: A potential new network topology is a provisional view at a given point in time that incorporates modifications relative to the current snapshot. It may represent the full topology or only the differences from the snapshot.
: The view is needed for what-if analysis, pre-configuration, and simulation.
REQ-INTENDED:: Intended network topology.
: SIMAP must enable both retrieval and write access to the intended network topology that cannot be discovered from the real network (e.g., intended Layer 2 Topology, intended Layer 3 Topology, and passive topology that cannot be discovered).
: The intended topology represents the desired topology, without always detailing the intermediate hops, devices or detailed links that the current live topology contains. It can be used to verify if the live topology complies with the intent.
REQ-SEMANTIC:: Network topology semantics.
: SIMAP must provide semantics for layered network topologies and for linking external models/data.

The following requirements are more specific requirements for semantics:

REQ-LAYER-NAVIGATE:

SIMAP must provide capability to navigate both within a topology layer and between topology layers.

Within-layer navigation means that SIMAP client applications should be able to move amongst entities that belong to the same layer. For example, in the IGP layer, the navigation should allow moving between OSPF/IS-IS management domains, OSPF/IS-IS areas, OSPF/IS-IS processes, OSPF/IS-IS interfaces, and OSPF/IS-IS links.

Between-layer navigation is the navigation across layers that should display the dependencies of entities in one layer on those in another. For instance, an IP interface that is supported by an Ethernet interface should be visible when moving between the corresponding layers.

REQ-EXTENSIBLE:

SIMAP must be extensible with metadata. As examples, a controller or the client application could add a custom "location" attribute to a node to record its physical site, or a controller could attach a "vendorId" field to a device node. This demonstrates that arbitrary key-value metadata can be appended to any element in the model without altering the core schema.

REQ-PLUGG:

SIMAP must be pluggable. That is,

Must connect to other data models for device configuration, inventory, configuration, assurance, etc. The SIMAP does not contain the detailed device configuration, so a mechanism is needed to be able to link it from SIMAP. SIMAP should also be linked to a 'logical configuration inventory'. Several examples of the type of logical information to be linked from SIMAP: inventory of logical interfaces, inventory of ACLs, inventory of routing policies, or geographic location.
Given that not all involved components can be available using YANG, there is a need to connect SIMAP with other modelling mechanisms.

REQ-BIDIR:

SIMAP must provide a mechanism to model bidirectional links. While data flows are unidirectional, the bidirectional links are also common in networking. Examples are Ethernet cables, bidirectional SONET rings, socket connection to the server, etc., where a link is modeled as bidirectional, which in turn might be supported as unidirectional links at the lower layer.

REQ-MULTI-POINT:

SIMAP must provide a mechanism to model multipoint links. A topology model should be able to model any topology type, including point to multipoint, bus, ring, star, tree, mesh, hybrid and daisy chain. A topology model should also be able to model any link cardinality, including point-to-point, point-to-multipoint, multipoint-to-multipoint

REQ-MULTI-DOMAIN:

SIMAP must provide a mechanism to model links and nodes between networks when the implementation requires multi-domain topologies, topologies with multiple IGP areas or any network partitioning. This requirement is about covering connectivity between different networks, subnetworks, or domains.

REQ-SUBNETWORK:

SIMAP must provide a mechanism to model network decomposition into subnetworks. The requirement is about modelling hierarchical networks, Autonomous Systems (ASes) with multiple areas, or a network with multiple domains (e.g., access, core, data center).

The network can be partitioned by providing capability to have multiple child network instances as part of a single parent network, with a relation between the parent network and child networks.

REQ-SUPPORTING:

SIMAP must provide a mechanism to model supporting relationships between different types of topological entities (e.g., a termination point is supported by a node or a node is supported by a network). This may be required to model supporting relationships for termination points which are supported by physical devices (e.g., a loopback interface on IP router).

REQ-STATUS:

Links and nodes that are down must appear in the topology. The status of the nodes and links must be either implemented in the SIMAP or accessible from the SIMAP. Whether the status is included as part of the SIMAP or accessible from the SIMAP is left to the solutions.

REQ-DATA-PLANE-FLOW:

Provider data plane (Flow) needs to be correlatable to underlay and customer data plane to overlay topology

An SRv6 example:

In an SRv6-enabled network, the sourceIPv6Address Information Element appears twice in the IPFIX Template Record and Data Record for a captured flow on an SRv6-enabled provider interface. The first occurrence is the source address of the outer header and belongs to the provider data plane in the underlay. The second occurrence is the source address of the inner header and belongs to the customer data plane in the overlay, that is, the customer traffic carried over that underlay.

SIMAP must provide the semantic capability that each sourceIPv6Address can be mapped to the overlay and underlay network topology. As the two topologies might not be uniquely addressed, the VPN context needs to be considered as well: in SRv6, the service SID carried as the outer IPv6 destination address, whose endpoint behavior (Sections 4.4 to 4.8 of ) identifies the VPN. defines the IPFIX Information Elements for exporting SRv6 segments and their endpoint behaviors.

IPFIX protocol, defined in , is the protocol for the exchange of flow information from an Exporting Process to a Collecting Process. describes the management of Templates and Option templates at the Exporting and Collecting Processes, and states the following:

If an Information Element is required more than once in a Template, the different occurrences of this Information Element SHOULD follow the logical order of their treatments by the Metering Process. For example, if a selected packet goes through two hash functions, and if the two hash values are sent within a single Template, the first occurrence of the hash value should belong to the first hash function in the Metering Process. For example, when exporting the two source IP addresses of an IPv4-in-IPv4 packet, the first sourceIPv4Address Information Element occurrence should be the IPv4 address of the outer header, while the second occurrence should be the address of the inner header. Collecting Processes MUST properly handle Templates with multiple identical Information Elements.

REQ-CONTROL-PLANE:: Control-plane routing state must be correlatable to the corresponding data-plane topology. For example, the underlay control-plane routing state must correlate to the underlay Layer 3 topology, while the overlay control-plane routing state must correlate to the overlay Layer 3 network topology.
: A BMP/BGP example:
: The BMP peer distinguisher () of an RD Instance Peer, or of a VRF Loc-RIB instance , needs to be correlatable to the VRF of a node. For routes of the VPN address families received from PEs or route reflectors in BMP Route Monitoring messages (), the BGP next hop needs to be correlatable to the underlay network topology, and the NLRI (Route Distinguisher and prefix) with its Route Targets to the overlay topology.

Design Requirements The following are the design requirements for the SIMAP data model:

REQ-TOPO-ONLY:

SIMAP should contain only topological information.

SIMAP is not required to contain all models and data required for all the management and use cases. However, it should be designed to support adequate pointers to other functional data and models to ease navigating in the overall system. For example:

ACLs and Route Policies are not required to be supported in the SIMAP, they would be linked to the SIMAP.
Dynamic paths may, depending on the solution, be either inside or outside of the SIMAP. If outside of SIMAP, dynamic paths could be linked to the SIMAP.

SIMAP should ensure that it is possible to represent the paths/routes and leave the choice of what level of dynamics to represent to the specific solution/implementations. The model needs to be rich enough to represent any level of dynamics. However, from experience, we suspect it can be the same model for all level of dynamics.

REQ-PROPERTIES:

SIMAP entities should mainly contain properties used to identify topological entities at different layers, identify their roles, and topological relationships between them.

SIMAP entities should also provide information required to define semantics for layered network topologies, such as:

link directionality,
link cost or metric, which can differ per direction,
the shared risk link groups (SRLGs) a link belongs to,
for a bidirectional link, whether its two directions are co-routed,
whether the links are multipoint or not and, if so, whether these links are point-to-multipoint or multipoint-to-multipoint,
role of the termination points in the link (source, destination, hub, spoke), and
some generic mechanism to add metadata.

REQ-RELATIONSHIPS:

SIMAP should contain all topological relationships inside each layer or between the layers (underlay/overlay)

SIMAP should contain links to other models/data to enable generic navigation to other data models in generic way.

The SIMAP relationships should also provide information required to define semantics for layered network topologies, such as providing:

underlay and overlay relations between different types of topological entities,
additional information that helps with navigation inside a layer and between the layers, for example, easy identification of resources at the physical layer in primary versus backup paths, if the underlay resources are used for load balancing or for backup,
capability to model nodes, termination points, and links contained in a network, but also nodes and links shared between networks, and
relationships between networks, either for modelling of underlay and overlay or modelling network that contains multiple networks.

REQ-CONDITIONAL:

Provide capability for conditional retrieval of parts of SIMAP.

REQ-TEMPO-HISTO:

Must support geospatial (geographic coordinates, region, zone, etc.), temporal (when some fact is true, e.g., the topology or topological entity created at 12:00 UTC), and historical data (time-stamped historical changes, e.g., all changes from 2019-01-01 to 2023-06-30).

The geospatial, temporal and historical can also be supported external to the SIMAP.

Architectural Requirements The following are the architectural requirements for the SIMAP server implementations that provide SIMAP API, they are the non-functional requirements for the SIMAP APIs and SIMAP server implementations:

REQ-SCALES:: The SIMAP APIs and SIMAP server implementations must be scalable, it must support any provider network, independent of its size.
REQ-PERFORMANCE:: The SIMAP APIs and SIMAP server implementations MUST support mechanisms that allow efficient retrieval of large topologies, including incremental, filtered, or paginated access to data. Implementations SHOULD support streaming or subscription-based mechanisms when appropriate to the protocol binding, to avoid requiring full-dataset retrieval for every request.
: This requirement ensures that SIMAP can operate effectively in environments with large-scale, multi-layer topologies without mandating specific latency targets or performance metrics.
REQ-CONGESTION:: SIMAP protocol bindings MUST ensure that SIMAP traffic cannot cause persistent congestion. Where the underlying transport provides congestion control, as with TCP-based bindings, this requirement is met by the transport. Where it does not, as with UDP used without a congestion control mechanism, the binding MUST restrict deployment to controlled environments with pre-provisioned or reserved capacity, and MUST bound the volume of traffic a SIMAP server can generate. See for background on UDP usage.
REQ-USABILITY:: The SIMAP APIs must be simple and easy to integrate with the client applications, whose developers may not be networking experts.
REQ-DISCOVERY:: A network SIMAP server must perform the initial and on-demand discovery of a network in order to provide the layered topology via the SIMAP APIs to a client application.
REQ-SYNCH:: The SIMAP server must perform the sync with the network in order to provide up-to-date layered topology via SIMAP APIs to a client application
REQ-SECURITY:: Any SIMAP interface MUST support strong client authentication and authorization before granting access to SIMAP operations and data.
: A SIMAP interface MUST also support authentication of a SIMAP server by the client. A client may send sensitive queries, write operations, and simulation requests, so a client that cannot authenticate the server risks disclosing that information to an impersonated server and acting on responses from it.
: For YANG-based NETCONF and RESTCONF protocols, access control SHOULD follow the Network Configuration Access Control Model (NACM) .
: For non YANG protocols, implementations MUST provide an access control mechanism with a level of protection similar to NACM. At a minimum, such a mechanism provides role-based authorization, fine-grained access restrictions, and the ability to restrict access to sensitive topology and service information, including the mappings between them.
: Because SIMAP connects highly sensitive multi layer topology with service and network data, implementations MUST ensure confidentiality, integrity, and replay protection for all SIMAP interactions, using security mechanisms appropriate to the transport protocol (e.g., TLS, SSH).
: SIMAP implementations MUST prevent unauthorized write or simulation operations and ensure that simulation functions cannot become unintended configuration changes.

Positioning SIMAP in the Context of the IETF Work advocates for a consistent classification of YANG modules and introduces two abstraction layers for YANG modules:

network element YANG modules
network service YANG modules

The IRTF defines the SDN layers and architecture and proposes the following interfaces:

southbound interfaces between the network devices and controllers/managers
service interface between controllers/managers and applications

defines where service model might fit into the SDN Architecture, although the service model does not require or preclude the use of SDN. It shows the following models at different layers of abstraction:

device model, between network elements and controllers
network model, between controllers and network orchestrators
service model, between network orchestrators and service orchestrators
customer service model, between service orchestrators and customer

describes the ACTN architecture in the context of the YANG service models. It shows how ACTN interfaces relate to device model, network model and customer service model. describes a framework for Service and network management automation that takes advantage of YANG modelling technologies. This framework is drawn from a network operator perspective irrespective of the origin of a data model. introduces "network service models" and describes the layering and representation of models within a network operator as follows:

device model, between device and controller
network model (operator oriented), between controller (that includes network orchestration function) and service orchestrator
service model (customer oriented), between service orchestrator and customer, this is network service model

The SIMAP can be used at different layers of abstraction and SIMAP can provide topology at different interfaces. Although the SIMAP and APIs is primarily positioned as northbound multi-layered topology model from (SDN) Controllers, it can also be positioned as follows:

In the context of , SIMAP can provide multi-layered topology YANG module as part of both network element and network service YANG modules
In the context of , SIMAP can provide multi-layered topology interface as part of both Southbound and Service Interfaces
In the context of , SIMAP can provide multi-layered topology model as part of device model, network model, service model and customer service model
In the context of , SIMAP can provide multi-layered topology model as part of SBI (southbound interface to network), MPI (interface between multi-domain service coordinator and network controller) and CMI (interface between customer network controller and multi-domain service coordinator)
In the context of , SIMAP can provide multi-layered topology model as part of device model, network model and network service model

Appendix A documents some other IETF activities related to topology modeling, it does not want to prescribe how SIMAP should be modeled or which base models should be used, and it is added for illustrational purposes only. Therefore, it is not included in this section, but added to the Appendix.

Security Considerations SIMAP provides a unified access point to multi layer topology, and relations to services and resources across network domains. Although this document defines concepts and implementation requirements rather than a concrete implementations and protocols, these requirements introduce significant security considerations that any SIMAP implementation or protocol must address.

Data sensitivity:: SIMAP aggregates information that is highly sensitive in operational environments, including physical/logical/service topology, logical to physical relations, service relations, identifiers such as SRv6 SIDs, and references to configuration, inventory, assurance, and telemetry systems. Unauthorized read access to this information could enable targeted attacks, lateral movement, or large scale service disruption. Implementations MUST ensure that confidentiality protections and fine-grained access control policies are applied to all SIMAP data.
Authentication:: Any SIMAP implementation, regardless of modelling language or protocol, MUST provide mutual authentication. The server MUST authenticate the client before granting access to SIMAP data or operations, and the client MUST be able to authenticate the server before sending queries, write operations, or simulation requests. Authentication mechanisms depend on the underlying protocol binding (e.g., TLS server and client certificates, SSH host and user keys, OAuth based API authentication), but the requirement for strong mutual authentication is universal.
Authorization and protocol binding scope:: Because SIMAP explicitly allows non YANG protocol bindings (REQ-PLUGG), NACM applies only to YANG based bindings. Non YANG bindings MUST provide an access control mechanism that offers protections equivalent to those of NACM. At a minimum, such a mechanism provides role-based authorization, fine-grained access restrictions, and the ability to restrict access to sensitive topology and service information, including the mappings between them.
Data integrity of write and simulation operations:: SIMAP supports operations that may modify data or simulate modifications (e.g., what if analysis). Even when write operations are limited to simulation, implementations MUST ensure that such operations cannot become unintended configuration changes, and that simulation results cannot be used to infer privileged or hidden information.
Cross domain aggregation:: SIMAP may expose information aggregated from multiple administrative domains. Implementations MUST ensure that access control policies are consistently enforced across domains and that cross domain data leakage does not occur. Policy mismatches or inconsistent authorization models across domains can create unintended disclosure paths.
Transport security:: SIMAP implementations MUST ensure confidentiality, integrity, and replay protection for all protocol exchanges, regardless of the underlying protocol binding. TLS , SSH , DTLS and IPsec are examples of mechanisms that can provide these protections; the choice depends on the protocol binding.

These considerations are not exhaustive; protocol specifications and implementations of SIMAP must define additional security mechanisms appropriate to their deployment environments. discusses further security consideration for YANG, NETCONF, RESTCONF and specifically for ietf-network and ietf-network-topology modules.

IANA Considerations This document has no actions for IANA.

References Normative References Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Network Configuration Access Control Model The standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) or the RESTCONF protocol requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF or RESTCONF protocol access for particular users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. This document defines such an access control model. This document obsoletes RFC 6536. Informative References Zero-Touch Network and Service Management (ZSM); ZSM Framework for NaaS ETSI On the Difference between Information Models and Data Models There has been ongoing confusion about the differences between Information Models and Data Models for defining managed objects in network management. This document explains the differences between these terms by analyzing how existing network management model specifications (from the IETF and other bodies such as the International Telecommunication Union (ITU) or the Distributed Management Task Force (DMTF)) fit into the universe of Information Models and Data Models. This memo documents the main results of the 8th workshop of the Network Management Research Group (NMRG) of the Internet Research Task Force (IRTF) hosted by the University of Texas at Austin. This memo provides information for the Internet community. The YANG 1.1 Data Modeling Language YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF). RESTCONF Protocol This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF). Service Assurance for Intent-Based Networking Architecture This document describes an architecture that provides some assurance that service instances are running as expected. As services rely upon multiple subservices provided by a variety of elements, including the underlying network devices and functions, getting the assurance of a healthy service is only possible with a holistic view of all involved elements. This architecture not only helps to correlate the service degradation with symptoms of a specific network component but, it also lists the services impacted by the failure or degradation of a specific network component. A YANG Network Data Model for Service Attachment Points (SAPs) This document defines a YANG data model for representing an abstract view of the provider network topology that contains the points from which its services can be attached (e.g., basic connectivity, VPN, network slices). Also, the model can be used to retrieve the points where the services are actually being delivered to customers (including peer networks). This document augments the 'ietf-network' data model defined in RFC 8345 by adding the concept of Service Attachment Points (SAPs). The SAPs are the network reference points to which network services, such as Layer 3 Virtual Private Network (L3VPN) or Layer 2 Virtual Private Network (L2VPN), can be attached. One or multiple services can be bound to the same SAP. Both User-to-Network Interface (UNI) and Network-to-Network Interface (NNI) are supported in the SAP data model. A Base YANG Data Model for Network Inventory Huawei Technologies Nokia Vodafone FiberCop Cisco This document defines a base YANG data model for reporting network inventory. The scope of this base model is set to be application- and technology-agnostic. The base data model can be augmented with application- and technology-specific details. A YANG Data Model for Network Topologies This document defines an abstract (generic, or base) YANG data model for network/service topologies and inventories. The data model serves as a base model that is augmented with technology-specific details in other, more specific topology and inventory data models. Some Key Terms for Network Fault and Problem Management This document sets out some terms that are fundamental to a common understanding of network fault and problem management within the IETF. The purpose of this document is to bring clarity to discussions and other work related to network fault and problem management -- in particular, to YANG data models and management protocols that report, make visible, or manage network faults and problems. Intent-Based Networking - Concepts and Definitions Intent and Intent-Based Networking are taking the industry by storm. At the same time, terms related to Intent-Based Networking are often used loosely and inconsistently, in many cases overlapping and confused with other concepts such as "policy." This document clarifies the concept of "intent" and provides an overview of the functionality that is associated with it. The goal is to contribute towards a common and shared understanding of terms, concepts, and functionality that can be used as the foundation to guide further definition of associated research and engineering problems and their solutions. This document is a product of the IRTF Network Management Research Group (NMRG). It reflects the consensus of the research group, having received many detailed and positive reviews by research group participants. It is published for informational purposes. Overview and Principles of Internet Traffic Engineering This document describes the principles of traffic engineering (TE) in the Internet. The document is intended to promote better understanding of the issues surrounding traffic engineering in IP networks and the networks that support IP networking and to provide a common basis for the development of traffic-engineering capabilities for the Internet. The principles, architectures, and methodologies for performance evaluation and performance optimization of operational networks are also discussed. This work was first published as RFC 3272 in May 2002. This document obsoletes RFC 3272 by making a complete update to bring the text in line with best current practices for Internet traffic engineering and to include references to the latest relevant work in the IETF. A YANG Network Data Model for Inventory Topology Mapping Huawei Orange China Mobile Huawei This document specifies a YANG data model that extends the network topology data model (RFC 8345) to map network topologies with inventories. The data model introduces the "inventory-topology" network type and augmentations for physical entity mappings and capabilities, which may be used by any overlay network topology for service provisioning validation, network maintenance, and capacity planning. Defining Network Capacity Measuring capacity is a task that sounds simple, but in reality can be quite complex. In addition, the lack of a unified nomenclature on this subject makes it increasingly difficult to properly build, test, and use techniques and tools built around these constructs. This document provides definitions for the terms 'Capacity' and 'Available Capacity' related to IP traffic traveling between a source and destination in an IP network. By doing so, we hope to provide a common framework for the discussion and analysis of a diverse set of current and future estimation techniques. This memo provides information for the Internet community. Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information This document specifies the IP Flow Information Export (IPFIX) protocol, which serves as a means for transmitting Traffic Flow information over the network. In order to transmit Traffic Flow information from an Exporting Process to a Collecting Process, a common representation of flow data and a standard means of communicating them are required. This document describes how the IPFIX Data and Template Records are carried over a number of transport protocols from an IPFIX Exporting Process to an IPFIX Collecting Process. This document obsoletes RFC 5101. Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) This document specifies routing extensions in support of carrying link state information for Generalized Multi-Protocol Label Switching (GMPLS). This document enhances the routing extensions required to support MPLS Traffic Engineering (TE). [STANDARDS-TRACK] A Framework for a Network Anomaly Detection Architecture Swisscom Swisscom INSA-Lyon Deutsche Telekom This document describes the motivation and architecture of a Network Anomaly Detection Framework and the relationship to other documents describing network Symptom semantics and network incident lifecycle. The described architecture for detecting IP network service interruption is designed to be generic applicable and extensible. Different applications are described and examples are referenced with open-source running code. Network Digital Twin (NDT): Concepts and Reference Architecture China Mobile China Mobile China Mobile Huawei Orange Orange The application of Digital Twin technology in the networking field is meant to develop various rich network applications, realize efficient and cost-effective data-driven network management, and accelerate network innovation. This document presents an overview of the concept of Network Digital Twin (NDT), provides the basic definitions and a reference architecture, lists a set of application scenarios, and discusses such technology's benefits and key challenges. This document is a product of the Network Management Research Group (NMRG) of the Internet Research Task Force (IRTF). This document reflects the consensus of the research group. It is not a candidate for any level of Internet Standard and is published for informational purposes. Information Model for IP Flow Information Export (IPFIX) This document defines the data types and management policy for the information model for the IP Flow Information Export (IPFIX) protocol. This information model is maintained as the IANA "IPFIX Information Elements" registry, the initial contents of which were defined by RFC 5102. This information model is used by the IPFIX protocol for encoding measured traffic information and information related to the traffic Observation Point, the traffic Metering Process, and the Exporting Process. Although this model was developed for the IPFIX protocol, it is defined in an open way that allows it to be easily used in other protocols, interfaces, and applications. This document obsoletes RFC 5102. Segment Routing over IPv6 (SRv6) Network Programming The Segment Routing over IPv6 (SRv6) Network Programming framework enables a network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header. Each instruction is implemented on one or several nodes in the network and identified by an SRv6 Segment Identifier in the packet. This document defines the SRv6 Network Programming concept and specifies the base set of SRv6 behaviors that enables the creation of interoperable overlays with underlay optimization. Export of Segment Routing over IPv6 Information in IP Flow Information Export (IPFIX) This document introduces new IP Flow Information Export (IPFIX) Information Elements (IEs) to identify a set of information related to Segment Routing over IPv6 (SRv6) such as data contained in a Segment Routing Header (SRH), the SRv6 control plane, and the SRv6 Endpoint behavior that traffic is being forwarded with. BGP Monitoring Protocol (BMP) This document defines the BGP Monitoring Protocol (BMP), which can be used to monitor BGP sessions. BMP is intended to provide a convenient interface for obtaining route views. Prior to the introduction of BMP, screen scraping was the most commonly used approach to obtaining such views. The design goals are to keep BMP simple, useful, easily implemented, and minimally service affecting. BMP is not suitable for use as a routing protocol. Support for Local RIB in the BGP Monitoring Protocol (BMP) The BGP Monitoring Protocol (BMP) defines access to local Routing Information Bases (RIBs). This document updates BMP (RFC 7854) by adding access to the Local Routing Information Base (Loc-RIB), as defined in RFC 4271. The Loc-RIB contains the routes that have been selected by the local BGP speaker's Decision Process. UDP Usage Guidelines The User Datagram Protocol (UDP) provides a minimal message-passing transport that has no inherent congestion control mechanisms. This document provides guidelines on the use of UDP for the designers of applications, tunnels, and other protocols that use UDP. Congestion control guidelines are a primary focus, but the document also provides guidance on other topics, including message sizes, reliability, checksums, middlebox traversal, the use of Explicit Congestion Notification (ECN), Differentiated Services Code Points (DSCPs), and ports. Because congestion control is critical to the stable operation of the Internet, applications and other protocols that choose to use UDP as an Internet transport must employ mechanisms to prevent congestion collapse and to establish some degree of fairness with concurrent traffic. They may also need to implement additional mechanisms, depending on how they use UDP. Some guidance is also applicable to the design of other protocols (e.g., protocols layered directly on IP or via IP-based tunnels), especially when these protocols do not themselves provide congestion control. This document obsoletes RFC 5405 and adds guidelines for multicast UDP usage. YANG Module Classification The YANG data modeling language is currently being considered for a wide variety of applications throughout the networking industry at large. Many standards development organizations (SDOs), open-source software projects, vendors, and users are using YANG to develop and publish YANG modules for a wide variety of applications. At the same time, there is currently no well-known terminology to categorize various types of YANG modules. A consistent terminology would help with the categorization of YANG modules, assist in the analysis of the YANG data modeling efforts in the IETF and other organizations, and bring clarity to the YANG- related discussions between the different groups. This document describes a set of concepts and associated terms to support consistent classification of YANG modules. Software-Defined Networking (SDN): Layers and Architecture Terminology Software-Defined Networking (SDN) refers to a new approach for network programmability, that is, the capacity to initialize, control, change, and manage network behavior dynamically via open interfaces. SDN emphasizes the role of software in running networks through the introduction of an abstraction for the data forwarding plane and, by doing so, separates it from the control plane. This separation allows faster innovation cycles at both planes as experience has already shown. However, there is increasing confusion as to what exactly SDN is, what the layer structure is in an SDN architecture, and how layers interface with each other. This document, a product of the IRTF Software-Defined Networking Research Group (SDNRG), addresses these questions and provides a concise reference for the SDN research community based on relevant peer-reviewed literature, the RFC series, and relevant documents by other standards organizations. Service Models Explained The IETF has produced many modules in the YANG modeling language. The majority of these modules are used to construct data models to model devices or monolithic functions. A small number of YANG modules have been defined to model services (for example, the Layer 3 Virtual Private Network Service Model (L3SM) produced by the L3SM working group and documented in RFC 8049). This document describes service models as used within the IETF and also shows where a service model might fit into a software-defined networking architecture. Note that service models do not make any assumption of how a service is actually engineered and delivered for a customer; details of how network protocols and devices are engineered to deliver a service are captured in other modules that are not exposed through the interface between the customer and the provider. Framework for Abstraction and Control of TE Networks (ACTN) Traffic Engineered (TE) networks have a variety of mechanisms to facilitate the separation of the data plane and control plane. They also have a range of management and provisioning protocols to configure and activate network resources. These mechanisms represent key technologies for enabling flexible and dynamic networking. The term "Traffic Engineered network" refers to a network that uses any connection-oriented technology under the control of a distributed or centralized control plane to support dynamic provisioning of end-to- end connectivity. Abstraction of network resources is a technique that can be applied to a single network domain or across multiple domains to create a single virtualized network that is under the control of a network operator or the customer of the operator that actually owns the network resources. This document provides a framework for Abstraction and Control of TE Networks (ACTN) to support virtual network services and connectivity services. A Framework for Automating Service and Network Management with YANG Data models provide a programmatic approach to represent services and networks. Concretely, they can be used to derive configuration information for network and service components, and state information that will be monitored and tracked. Data models can be used during the service and network management life cycle (e.g., service instantiation, service provisioning, service optimization, service monitoring, service diagnosing, and service assurance). Data models are also instrumental in the automation of network management, and they can provide closed-loop control for adaptive and deterministic service creation, delivery, and maintenance. This document describes a framework for service and network management automation that takes advantage of YANG modeling technologies. This framework is drawn from a network operator perspective irrespective of the origin of a data model; thus, it can accommodate YANG modules that are developed outside the IETF. The Transport Layer Security (TLS) Protocol Version 1.3 This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document obsoletes RFC 8446, which specified TLS 1.3. This document obsoletes RFC 5246 (specifying TLS 1.2) and RFCs 5077, 6961, 7627, and 8422, all of which pertain to TLS 1.2 or earlier, and updates RFCs 5705 and 6066. This document also specifies new requirements for TLS 1.2 implementations. The Secure Shell (SSH) Transport Layer Protocol The Secure Shell (SSH) is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH transport layer protocol, which typically runs on top of TCP/IP. The protocol can be used as a basis for a number of secure network services. It provides strong encryption, server authentication, and integrity protection. It may also provide compression. Key exchange method, public key algorithm, symmetric encryption algorithm, message authentication algorithm, and hash algorithm are all negotiated. This document also describes the Diffie-Hellman key exchange method and the minimal set of algorithms that are needed to implement the SSH transport layer protocol. [STANDARDS-TRACK] The Datagram Transport Layer Security (DTLS) Protocol Version 1.3 This document specifies version 1.3 of the Datagram Transport Layer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. The DTLS 1.3 protocol is based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security guarantees with the exception of order protection / non-replayability. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document obsoletes RFC 6347. Security Architecture for the Internet Protocol This document describes an updated version of the "Security Architecture for IP", which is designed to provide security services for traffic at the IP layer. This document obsoletes RFC 2401 (November 1998). [STANDARDS-TRACK] Problem Statement and Architecture for Information Exchange between Interconnected Traffic-Engineered Networks In Traffic-Engineered (TE) systems, it is sometimes desirable to establish an end-to-end TE path with a set of constraints (such as bandwidth) across one or more networks from a source to a destination. TE information is the data relating to nodes and TE links that is used in the process of selecting a TE path. TE information is usually only available within a network. We call such a zone of visibility of TE information a domain. An example of a domain may be an IGP area or an Autonomous System. In order to determine the potential to establish a TE path through a series of connected networks, it is necessary to have available a certain amount of TE information about each network. This need not be the full set of TE information available within each network but does need to express the potential of providing TE connectivity. This subset of TE information is called TE reachability information. This document sets out the problem statement for the exchange of TE information between interconnected TE networks in support of end-to-end TE path establishment and describes the best current practice architecture to meet this problem statement. For reasons that are explained in this document, this work is limited to simple TE constraints and information that determine TE reachability. YANG Data Model for Traffic Engineering (TE) Topologies This document defines a YANG data model for representing, retrieving, and manipulating Traffic Engineering (TE) Topologies. The model serves as a base model that other technology-specific TE topology models can augment. TE Topology and Tunnel Modeling for Transport Networks Individual Juniper Networks Juniper Networks Volta Networks This document describes how to model TE topologies and tunnels for transport networks, by using the TE topology YANG model [I-D.ietf- teas-yang-te-topo] and the TE tunnel YANG model [I-D.ietf-teas-yang- te]. A YANG Grouping for Geographic Locations This document defines a generic geographical location YANG grouping. The geographical location grouping is intended to be used in YANG data models for specifying a location on or in reference to Earth or any other astronomical object. A YANG Data Model for Layer 2 Network Topologies This document defines a YANG data model for Layer 2 network topologies. In particular, this data model augments the generic network and network topology data models with topology attributes that are specific to Layer 2. A YANG Data Model for Layer 3 Topologies This document defines a YANG data model for Layer 3 network topologies. A YANG Data Model for Open Shortest Path First (OSPF) Topology Telefonica Nokia Nokia This document defines a YANG data model for representing an abstracted view of a network topology that contains Open Shortest Path First (OSPF) information. This document augments the 'ietf- network' data model by adding OSPF concepts and explains how the data model can be used to represent the OSPF topology. The YANG data model defined in this document conforms to the Network Management Datastore Architecture (NMDA). A YANG Data Model for Intermediate System to intermediate System (IS-IS) Topology Telefonica Nokia Nokia Cisco Everything OPS This document defines a YANG data model for representing an abstracted view of a network topology that contains Intermediate System to Intermediate System (IS-IS). This document augments the 'ietf-network' and 'ietf-network-topology' data models by adding IS- IS concepts and explains how the data model can be used to represent the IS-IS topology. The YANG data model defined in this document conforms to the Network Management Datastore Architecture (NMDA). A YANG Data Model for Service Assurance This document specifies YANG modules for representing assurance graphs. These graphs represent the assurance of a given service by decomposing it into atomic assurance elements called subservices. The companion document, "Service Assurance for Intent-Based Networking Architecture" (RFC 9417), presents an architecture for implementing the assurance of such services. The YANG data models in this document conform to the Network Management Datastore Architecture (NMDA) defined in RFC 8342. A Network YANG Data Model for Attachment Circuits This document specifies a network model for attachment circuits. The model can be used for the provisioning of attachment circuits prior or during service provisioning (e.g., VPN, Network Slice Service). A companion service model is specified in the YANG Data Models for Bearers and 'Attachment Circuits'-as-a-Service (ACaaS) (I-D.ietf- opsawg-teas-attachment-circuit). The module augments the base network ('ietf-network') and the Service Attachment Point (SAP) models with the detailed information for the provisioning of attachment circuits in Provider Edges (PEs). YANG Data Models for Bearers and Attachment Circuits as a Service (ACaaS) Delivery of network services assumes that appropriate setup is provisioned over the links that connect customer termination points and a provider network. The required setup to allow successful data exchange over these links is referred to as an attachment circuit (AC), while the underlying link is referred to as a "bearer". This document specifies a YANG service data model for ACs. This model can be used for the provisioning of ACs before or during service provisioning (e.g., RFC 9543 Network Slice Service). The document also specifies a YANG service data model for managing bearers over which ACs are established. A YANG Data Model for Layer 2 Virtual Private Network (L2VPN) Service Delivery This document defines a YANG data model that can be used to configure a Layer 2 provider-provisioned VPN service. It is up to a management system to take this as an input and generate specific configuration models to configure the different network elements to deliver the service. How this configuration of network elements is done is out of scope for this document. The YANG data model defined in this document includes support for point-to-point Virtual Private Wire Services (VPWSs) and multipoint Virtual Private LAN Services (VPLSs) that use Pseudowires signaled using the Label Distribution Protocol (LDP) and the Border Gateway Protocol (BGP) as described in RFCs 4761 and 6624. The YANG data model defined in this document conforms to the Network Management Datastore Architecture defined in RFC 8342. YANG Data Model for L3VPN Service Delivery This document defines a YANG data model that can be used for communication between customers and network operators and to deliver a Layer 3 provider-provisioned VPN service. This document is limited to BGP PE-based VPNs as described in RFCs 4026, 4110, and 4364. This model is intended to be instantiated at the management system to deliver the overall service. It is not a configuration model to be used directly on network elements. This model provides an abstracted view of the Layer 3 IP VPN service configuration components. It will be up to the management system to take this model as input and use specific configuration models to configure the different network elements to deliver the service. How the configuration of network elements is done is out of scope for this document. This document obsoletes RFC 8049; it replaces the unimplementable module in that RFC with a new module with the same name that is not backward compatible. The changes are a series of small fixes to the YANG module and some clarifications to the text. A YANG Network Data Model for Layer 2 VPNs This document defines an L2VPN Network Model (L2NM) that can be used to manage the provisioning of Layer 2 Virtual Private Network (L2VPN) services within a network (e.g., a service provider network). The L2NM complements the L2VPN Service Model (L2SM) by providing a network-centric view of the service that is internal to a service provider. The L2NM is particularly meant to be used by a network controller to derive the configuration information that will be sent to relevant network devices. Also, this document defines a YANG module to manage Ethernet segments and the initial versions of two IANA-maintained modules that include a set of identities of BGP Layer 2 encapsulation types and pseudowire types. A YANG Network Data Model for Layer 3 VPNs As a complement to the Layer 3 Virtual Private Network Service Model (L3SM), which is used for communication between customers and service providers, this document defines an L3VPN Network Model (L3NM) that can be used for the provisioning of Layer 3 Virtual Private Network (L3VPN) services within a service provider network. The model provides a network-centric view of L3VPN services. The L3NM is meant to be used by a network controller to derive the configuration information that will be sent to relevant network devices. The model can also facilitate communication between a service orchestrator and a network controller/orchestrator. A YANG Data Model for Network Incident Management CMCC Telefonica Huawei Ciena This document defines a YANG data model for the network incident lifecycle management. This YANG module provides a standard way to report, diagnose, and help reduce troubleshooting tickets and resolve network incidents for the sake of network service health and probable root cause analysis.

Related IETF Activities

Note: The models cited in this section are provided for illustration purposes. It is out of scope to recommend which models will be used as base to build the SIMAP.

Network Topology Interestingly, we could not find any network topology definition in IETF RFCs (not even in ) or Internet-Drafts. However, it is mentioned in multiple documents. As an example, in Overview and Principles of Internet Traffic Engineering , which mentions:

To conduct performance studies and to support planning of existing and future networks, a routing analysis may be performed to determine the paths the routing protocols will choose for various traffic demands, and to ascertain the utilization of network resources as traffic is routed through the network. Routing analysis captures the selection of paths through the network, the assignment of traffic across multiple feasible routes, and the multiplexing of IP traffic over traffic trunks (if such constructs exist) and over the underlying network infrastructure. A model of network topology is necessary to perform routing analysis. A network topology model may be extracted from:

Network architecture documents

Network designs

Information contained in router configuration files

Routing databases such as the link state database of an interior gateway protocol (IGP)

Routing tables

Automated tools that discover and collate network topology information.

Topology information may also be derived from servers that monitor network state, and from servers that perform provisioning functions.

Another example is that defines native topology, abstract topology, black topology, and grey topology, but all in the context of actual topology and physical topology that are not specifically defined.

Topology Abstraction Please refer to the following documents for some background on topology abstractions:

defines topology abstraction.
describes the topology abstraction methods and discusses topology abstraction factors, types, and their context in the ACTN architecture.
defines abstract TE topologies.
defines native TE topologies.
describes how to deal with multiple abstract TE topologies provided by the same provider.
gives some background on topology abstraction.

Core SIMAP Components The following specifications are relevant to the core functions provided by the SIMAP:

IETF network model and network topology model
A YANG grouping for geographic location
IETF modules that augment for different technologies:
- A YANG data model for Traffic Engineering (TE) Topologies
- A YANG data model for Layer 2 network topologies
- A YANG data model for Layer 3 topologies
Individual Internet-Drafts that augment (work in progress):
- A YANG data model for OSPF topology
- A YANG data model for IS-IS topology

Additional SIMAP Components The SIMAP may need to link to the following models, some are already augmenting :

Service Attachment Point (SAP) , augments 'ietf-network' data model by adding the SAP.
SAIN
Network Inventory Model focuses on physical and virtual inventory. Logical inventory is currently outside of the scope. It does not augment .
correlates the network inventory with the general topology via RFC8345 augmentations that reference inventory.
KPIs: delay, jitter, loss
Attachment Circuits (ACs) and
Configuration: The L2SM , L3SM , L2NM , and L3NM
Incident Management for Network Services

Acknowledgments Many thanks to Mohamed Boucadair and Reshad Rahman for their valuable contributions, reviews, and comments. Many thanks to Adrian Farrel for his SIMAP suggestion and helping to agree the terminology. Many thanks to Chongfeng Xie, Dan Voyer, Brad Peters, Diego Lopez, Ignacio Dominguez Martinez-Casanueva, Alex Huang Feng, Italo Busi, Wu Bo, Sherif Mostafa, Christopher Janz, Rob Evans, Daniele Ceccarelli, Sergio Belotti, Aihua Guo, Jen Linkova, Michael Tuexen, Stewart Bryant, Mališa Vučinić and many others for their contributions, suggestions and comments. Many thanks to Nigel Davis for the valuable discussions and his confirmation of the modelling requirements.

Contributors Swisscom

Ahmed.Elhassany@swisscom.com