SIMAP: Concept, Requirements, and Use Cases

3.1. 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.¶

3.2. 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 IT 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.¶

The application will be able to retrieve physical topology from the controller via the SIMAP API and from the response it will be able to retrieve the physical inventory of individual devices and cables.¶

The application may request either one or multiple topology layers via the SIMAP API and from the response it will be able 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.¶

3.3. 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 accessing 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 effecting other services already provisioned on the network.¶

Some of the factors that need assesing 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 Feasibility Check application will be able to retrieve the topology at any layer from the controller via the SIMAP API and from the response it will be able to navigate to any other YANG modules outside of the core SIMAP topology to retrieve any other information needed, such as resource usage, availability, status, etc.¶

3.4. 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) [RFC9417] 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:¶

• Holistic Service Monitoring:

  By considering all elements involved in service delivery, the architecture enables a thorough 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:

  The architecture identifies which services are affected by the failure or degradation of particular network components, aiding in prioritizing remediation efforts.¶

When a service is degraded, the SAIN architecture will highlight where to look in the assurance service graph, as opposed to going hop by hop to troubleshoot the issue. More precisely, the SAIN architecture 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.¶

The application will be able to retrieve a topology layer and any network/node/termination point/link instances from the controller via the SIMAP API and from the response it will be able to determine the health of each instance by navigating to the SAIN subservices and its symptoms.¶

3.5. Service E2E and Per-link KPIs

The application will be able to retrieve a topology at any layer from a controller via the SIMAP API and from the response it will be able to navigate to and retrieve any KPIs for selected topology entity.¶

3.6. Capacity Planning

Network Capacity Planning refers to the process of analyzing, predicting, and ensuring that the network has sufficient capacity (e.g., [RFC5136]), 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 analyzing 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 [RFC7011] 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 peformance 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 Resource Group), 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 application will be able to retrieve a topology layer and any network/node/termination point/link instances from the controller via the SIMAP API 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.¶

3.7. 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 retrieve a candidate network topology as the initial design, which 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 contraints on port optic speed, type (LR vs SR for instance), etc.¶

The application can (via SIMAP API):¶

• Write the proposed network design (topology + rules), this is a new potential network. One network (in case of small network) or interconnect of multiple networks (bigger networks).¶

• Write the intended network design (topology + rules), this is the intent of the network topology that cannot be retrieved from the real network (e.g. our L2 topology intent, or L3 topology intent). One network (in case of small network) or interconnect of multiple networks (bigger networks).¶

• Retrieve the proposed network design (topology + rules)¶

  • Use case can be for purpose of traffic simulation, testing behavior under failures. Network simulation use case is described in Section 3.8.¶

  • Use case can be for purpose of comparing different proposed network designs.¶

  • Use case can be to build a simulated environment using this design. Network simulation use case is described in Section 3.8.¶

• Retrieve the intended network design (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.¶

3.8. 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 peformed (with less accuracy) using generic software.¶

3.9. Postmortem Replay

The postmortem replay use case consists of using SIMAPs 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 provide simulation of the network behaviour 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 [I-D.ietf-nmop-network-anomaly-architecture].¶

3.10. Network Digital Twin (NDT)

Per [I-D.irtf-nmrg-network-digital-twin-arch], 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 Section 9.2 of [I-D.irtf-nmrg-network-digital-twin-arch], 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 and the network configuration change and optimization strategy can be pre-verified.¶

Section 9.4 of [I-D.irtf-nmrg-network-digital-twin-arch] 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 API can be invoked 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 API can be used for feasibility checks (Section 3.3) or emulation (Section 3.8)).¶

Section 9.4 of [I-D.irtf-nmrg-network-digital-twin-arch] recommends that these interfaces are open and standardized so as to avoid either hardware or software vendor lock and achieve interoperability.¶

4.1. Operator Requirements

The following are the operators' requirements for the SIMAP. Note that some of these requirements are supported by default by [RFC8345].¶

REQ-BASIC-MODEL-SUPPORT:

Basic model with network, node, link, and termination point entity types.¶

This means that users of the SIMAP model must be able to understand a topology model at any layer via these core concepts only, without having to go to the details of the specific augmentations to understand the topology.¶

REQ-LAYERED-MODEL:

Topology layers from physical layer up to service layer.¶

SIMAP must provide the view for all layers of network topology, from physical network (ideally optical), layer 2, layer 3 up to service and intent views.¶

REQ-PASSIVE-TOPO:

Topology includes passive topology.¶

SIMAP must support topology of the complete network, including active and passive parts.¶

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.¶

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, not for the ability to directly change the SIMAP data (e.g., changing the network or service parameters), but for offline simulations, also known as what-if scenarios.¶

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.¶

REQ-STD-API-BASED:

Standard based SIMAP models and APIs, for multi-vendor support.¶

SIMAP must provide the standard YANG APIs that provide for read/write and queries. These APIs must also provide the capability to retrieve the links to external data/models.¶

REQ-COMMON-APP:

Common SIMAP models and APIs, for multi domain.¶

SIMAP models and APIs must be common over different network domains (campus, core, data center, etc.).¶

This means that clients of the SIMAP API 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 for paths. This means that only providing link nodes and source and sink relationships to termination-points may not be sufficient, we may need to have the direct relationship between the termination points or nodes.¶

REQ-TOPOLOGY-ABSTRACTION:

Navigation across the abstraction levels inside a single network layer.¶

In a multi-layer network we need to navigate across multiple layers. We can also define multiple abstraction levels for a single layer and there is a need to navigate across these abstraction levels as well. Please refer to the Appendix A.2 for some background on the topology abstraction.¶

In a nutshell, 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 API and model.¶

SIMAP must provide a mechanism to navigate across the abstraction levels inside a single network layer.¶

REQ-LIVE:

Live network topology.¶

SIMAP must enable retrieval of multi-layered topology of a live network.¶

Live network is the latest known view of the 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 the potential new network.¶

A potential new network is the view at a given point with modifications from the snapshot.¶

This view may contain either the full topology or just differences from the snapshot.¶

REQ-SEMANTIC:

Network topology sematics¶

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 inside the topology layer and between the topology layers¶

REQ-EXTENSIBLE:

SIMAP must be extensible with metadata.¶

REQ-PLUGG:

SIMAP must be pluggable. That is,¶

• Must connect to other YANG modules 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, or inventory of routing policies.¶

• Given that no all involved components can be available using YANG, there is a need to connect SIMAP YANG model 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. There is also the requirement for simplified service layer topology, where a link is modeled as bidirectional in order to be supported by 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 in a simple and explicit way, 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 in a simple and explicit way, including point-to-point, point-to-multipoint, multipoint-to-multipoint or hybrid.¶

REQ-MULTI-DOMAIN:

SIMAP must provide a mechanism to model links between networks. This requirement is about covering connectivity between different networks, sub-networks, or domains.¶

REQ-SUBNETWORK:

SIMAP must provide a mechanism to model network decomposition into sub-networks. 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).¶

REQ-SHARED:

SIMAP must provide a mechanism to share nodes, links, and termination points between different 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 the node). This may be required, e.g., if a termination point is not supported by the underlying a termination point, but by the node (e.g., a loopback does not have physical representation, so it is supported by physical device).¶

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¶

REQ-CONTROL-PLANE:

Underlay control plane routing state needs to be correlatable to underlay L3 topology. Overlay control-plane routing state needs to be correlate-able to overlay L3 network topology.¶

4.2. 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 either be outside of the SIMAP or part of traffic engineering data/models¶

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,¶

• whether the links are multipoint or not and, if so, are 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 YANG 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 geo-spatial, temporal, and historical data. The temporal and historical can also be supported external to the SIMAP.¶

4.3. Architectural Requirements

The following are the architectural requirements for the controller that provides SIMAP API, they are the non-functional requirements for the SIMAP API or controllers:¶

REQ-SCALES:

The SIMAP API must be scalable, it must support any provider network, independent of its size.¶

REQ-PERFORMANCE:

The SIMAP API must be performant, and have acceptable response-time. Although we are not to define¶

REQ-USABILITY:

The SIMAP API must be simple and easy to integrate with the client applications, whose developers may not be networking experts.¶

REQ-DISCOVERY:

A network controller must perform the initial and on-demand discovery of a network in order to provide the layered topology via the SIMAP API to a client/application.¶

REQ-SYNCH:

The controller must perform the sync with the network in order to provide up to date layered topology via SIMAP API to the client/application¶

REQ-SECURITY:

The conventional NACM control access rules [RFC8341] should apply. This includes module control access rules, protocol operation control access rules, data node control access rules, and notification control access rules.¶

8.1. Normative References

[RFC8341]

Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, <https://www.rfc-editor.org/rfc/rfc8341>.

[RFC8345]

Clemm, A., Medved, J., Varga, R., Bahadur, N., Ananthakrishnan, H., and X. Liu, "A YANG Data Model for Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 2018, <https://www.rfc-editor.org/rfc/rfc8345>.

8.2. Informative References

[I-D.ietf-ccamp-network-inventory-yang]

Yu, C., Belotti, S., Bouquier, J., Peruzzini, F., and P. Bedard, "A YANG Data Model for Network Hardware Inventory", Work in Progress, Internet-Draft, draft-ietf-ccamp-network-inventory-yang-02, 9 July 2023, <https://datatracker.ietf.org/doc/html/draft-ietf-ccamp-network-inventory-yang-02>.

[I-D.ietf-ivy-network-inventory-topology]

Wu, B., Boucadair, M., Zhou, C., and Q. Wu, "A Network Data Model for Inventory Topology Mapping", Work in Progress, Internet-Draft, draft-ietf-ivy-network-inventory-topology-01, 4 February 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-ivy-network-inventory-topology-01>.

[I-D.ietf-ivy-network-inventory-yang]

Yu, C., Belotti, S., Bouquier, J., Peruzzini, F., and P. Bedard, "A Base YANG Data Model for Network Inventory", Work in Progress, Internet-Draft, draft-ietf-ivy-network-inventory-yang-05, 28 February 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-ivy-network-inventory-yang-05>.

[I-D.ietf-nmop-network-anomaly-architecture]

Graf, T., Du, W., and P. Francois, "An Architecture for a Network Anomaly Detection Framework", Work in Progress, Internet-Draft, draft-ietf-nmop-network-anomaly-architecture-01, 20 October 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-nmop-network-anomaly-architecture-01>.

[I-D.ietf-nmop-network-incident-yang]

Hu, T., Contreras, L. M., Wu, Q., Davis, N., and C. Feng, "A YANG Data Model for Network Incident Management", Work in Progress, Internet-Draft, draft-ietf-nmop-network-incident-yang-03, 19 February 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-nmop-network-incident-yang-03>.

[I-D.ietf-nmop-terminology]

Davis, N., Farrel, A., Graf, T., Wu, Q., and C. Yu, "Some Key Terms for Network Fault and Problem Management", Work in Progress, Internet-Draft, draft-ietf-nmop-terminology-12, 22 February 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-nmop-terminology-12>.

[I-D.ietf-opsawg-ntw-attachment-circuit]

Boucadair, M., Roberts, R., de Dios, O. G., Barguil, S., and B. Wu, "A Network YANG Data Model for Attachment Circuits", Work in Progress, Internet-Draft, draft-ietf-opsawg-ntw-attachment-circuit-16, 23 January 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ntw-attachment-circuit-16>.

[I-D.ietf-opsawg-teas-attachment-circuit]

Boucadair, M., Roberts, R., de Dios, O. G., Barguil, S., and B. Wu, "YANG Data Models for Bearers and 'Attachment Circuits'-as-a-Service (ACaaS)", Work in Progress, Internet-Draft, draft-ietf-opsawg-teas-attachment-circuit-20, 23 January 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-teas-attachment-circuit-20>.

[I-D.ietf-teas-te-topo-and-tunnel-modeling]

Bryskin, I., Beeram, V. P., Saad, T., and X. Liu, "TE Topology and Tunnel Modeling for Transport Networks", Work in Progress, Internet-Draft, draft-ietf-teas-te-topo-and-tunnel-modeling-06, 12 July 2020, <https://datatracker.ietf.org/doc/html/draft-ietf-teas-te-topo-and-tunnel-modeling-06>.

[I-D.irtf-nmrg-network-digital-twin-arch]

Zhou, C., Yang, H., Duan, X., Lopez, D., Pastor, A., Wu, Q., Boucadair, M., and C. Jacquenet, "Network Digital Twin: Concepts and Reference Architecture", Work in Progress, Internet-Draft, draft-irtf-nmrg-network-digital-twin-arch-10, 28 February 2025, <https://datatracker.ietf.org/doc/html/draft-irtf-nmrg-network-digital-twin-arch-10>.

[I-D.ogondio-nmop-isis-topology]

de Dios, O. G., Barguil, S., Lopez, V., Ceccarelli, D., and B. Claise, "A YANG Data Model for Intermediate System to intermediate System (IS-IS) Topology", Work in Progress, Internet-Draft, draft-ogondio-nmop-isis-topology-00, 4 March 2024, <https://datatracker.ietf.org/doc/html/draft-ogondio-nmop-isis-topology-00>.

[I-D.ogondio-opsawg-ospf-topology]

de Dios, O. G., Barguil, S., and V. Lopez, "A YANG Data Model for Open Shortest Path First (OSPF) Topology", Work in Progress, Internet-Draft, draft-ogondio-opsawg-ospf-topology-01, 23 October 2023, <https://datatracker.ietf.org/doc/html/draft-ogondio-opsawg-ospf-topology-01>.

[I-D.wzwb-opsawg-network-inventory-management]

Wu, B., Zhou, C., Wu, Q., and M. Boucadair, "A YANG Network Data Model of Network Inventory", Work in Progress, Internet-Draft, draft-wzwb-opsawg-network-inventory-management-04, 19 October 2023, <https://datatracker.ietf.org/doc/html/draft-wzwb-opsawg-network-inventory-management-04>.

[RFC5136]

Chimento, P. and J. Ishac, "Defining Network Capacity", RFC 5136, DOI 10.17487/RFC5136, February 2008, <https://www.rfc-editor.org/rfc/rfc5136>.

[RFC7011]

Claise, B., Ed., Trammell, B., Ed., and P. Aitken, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information", STD 77, RFC 7011, DOI 10.17487/RFC7011, September 2013, <https://www.rfc-editor.org/rfc/rfc7011>.

[RFC7426]

Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software-Defined Networking (SDN): Layers and Architecture Terminology", RFC 7426, DOI 10.17487/RFC7426, January 2015, <https://www.rfc-editor.org/rfc/rfc7426>.

[RFC7926]

Farrel, A., Ed., Drake, J., Bitar, N., Swallow, G., Ceccarelli, D., and X. Zhang, "Problem Statement and Architecture for Information Exchange between Interconnected Traffic-Engineered Networks", BCP 206, RFC 7926, DOI 10.17487/RFC7926, July 2016, <https://www.rfc-editor.org/rfc/rfc7926>.

[RFC8199]

Bogdanovic, D., Claise, B., and C. Moberg, "YANG Module Classification", RFC 8199, DOI 10.17487/RFC8199, July 2017, <https://www.rfc-editor.org/rfc/rfc8199>.

[RFC8299]

Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, "YANG Data Model for L3VPN Service Delivery", RFC 8299, DOI 10.17487/RFC8299, January 2018, <https://www.rfc-editor.org/rfc/rfc8299>.

[RFC8309]

Wu, Q., Liu, W., and A. Farrel, "Service Models Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, <https://www.rfc-editor.org/rfc/rfc8309>.

[RFC8453]

Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for Abstraction and Control of TE Networks (ACTN)", RFC 8453, DOI 10.17487/RFC8453, August 2018, <https://www.rfc-editor.org/rfc/rfc8453>.

[RFC8466]

Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG Data Model for Layer 2 Virtual Private Network (L2VPN) Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October 2018, <https://www.rfc-editor.org/rfc/rfc8466>.

[RFC8795]

Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and O. Gonzalez de Dios, "YANG Data Model for Traffic Engineering (TE) Topologies", RFC 8795, DOI 10.17487/RFC8795, August 2020, <https://www.rfc-editor.org/rfc/rfc8795>.

[RFC8944]

Dong, J., Wei, X., Wu, Q., Boucadair, M., and A. Liu, "A YANG Data Model for Layer 2 Network Topologies", RFC 8944, DOI 10.17487/RFC8944, November 2020, <https://www.rfc-editor.org/rfc/rfc8944>.

[RFC8969]

Wu, Q., Ed., Boucadair, M., Ed., Lopez, D., Xie, C., and L. Geng, "A Framework for Automating Service and Network Management with YANG", RFC 8969, DOI 10.17487/RFC8969, January 2021, <https://www.rfc-editor.org/rfc/rfc8969>.

[RFC9179]

Hopps, C., "A YANG Grouping for Geographic Locations", RFC 9179, DOI 10.17487/RFC9179, February 2022, <https://www.rfc-editor.org/rfc/rfc9179>.

[RFC9182]

Barguil, S., Gonzalez de Dios, O., Ed., Boucadair, M., Ed., Munoz, L., and A. Aguado, "A YANG Network Data Model for Layer 3 VPNs", RFC 9182, DOI 10.17487/RFC9182, February 2022, <https://www.rfc-editor.org/rfc/rfc9182>.

[RFC9291]

Boucadair, M., Ed., Gonzalez de Dios, O., Ed., Barguil, S., and L. Munoz, "A YANG Network Data Model for Layer 2 VPNs", RFC 9291, DOI 10.17487/RFC9291, September 2022, <https://www.rfc-editor.org/rfc/rfc9291>.

[RFC9408]

Boucadair, M., Ed., Gonzalez de Dios, O., Barguil, S., Wu, Q., and V. Lopez, "A YANG Network Data Model for Service Attachment Points (SAPs)", RFC 9408, DOI 10.17487/RFC9408, June 2023, <https://www.rfc-editor.org/rfc/rfc9408>.

[RFC9417]

Claise, B., Quilbeuf, J., Lopez, D., Voyer, D., and T. Arumugam, "Service Assurance for Intent-Based Networking Architecture", RFC 9417, DOI 10.17487/RFC9417, July 2023, <https://www.rfc-editor.org/rfc/rfc9417>.

[RFC9418]

Claise, B., Quilbeuf, J., Lucente, P., Fasano, P., and T. Arumugam, "A YANG Data Model for Service Assurance", RFC 9418, DOI 10.17487/RFC9418, July 2023, <https://www.rfc-editor.org/rfc/rfc9418>.

[RFC9522]

Farrel, A., Ed., "Overview and Principles of Internet Traffic Engineering", RFC 9522, DOI 10.17487/RFC9522, January 2024, <https://www.rfc-editor.org/rfc/rfc9522>.

A.1. Network Topology

Interestingly, we could not find any network topology definition in IETF RFCs (not even in [RFC8345]) or Internet-Drafts. However, it is mentioned in multiple documents. As an example, in Overview and Principles of Internet Traffic Engineering [RFC9522], 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 [RFC8453] that defines native topology, abstract topology, black topology, grey topology, but all in the context of actual topology and physical topology that are not specifically defined.¶

A.2. Topology Abstraction

Please refer to the following for some background on topology abstractions:¶

• [RFC7926] defines topology abstraction¶

• Section 5 of [RFC8453] describes the topology abstraction methods and discusses topology abstraction factors, types and their context in the ACTN architecture¶

• Section 3.13 of [RFC8795] defines abstract TE topologies¶

• Section 4.1 of [RFC8795] defines native TE topologies¶

• Section 4.4 of [RFC8795] describes how to deal with multiple abstract TE topologies provided by the same provider¶

• Section 1.3 of [I-D.ietf-teas-te-topo-and-tunnel-modeling] gives some background on topology abstraction.¶

A.3. Core SIMAP Components

The following specifications are core for the SIMAP:¶

• IETF network model and network topology model [RFC8345]¶

• A YANG grouping for geographic location [RFC9179]¶

• IETF modules that augment [RFC8345] for different technologies:¶

  • A YANG data model for Traffic Engineering (TE) Topologies [RFC8795]¶

  • A YANG data model for Layer 2 network topologies [RFC8944]¶

  • A YANG data model for OSFP topology [I-D.ogondio-opsawg-ospf-topology]¶

  • A YANG data model for IS-IS topology [I-D.ogondio-nmop-isis-topology]¶

A.4. Additional SIMAP Components

The SIMAP may need to link to the following models, some are already augmenting [RFC8345]:¶

• Service Attachment Point (SAP) [RFC9408], augments 'ietf-network' data model [RFC8345] by adding the SAP.¶

• SAIN [RFC9417] [RFC9418]¶

• Network Inventory Model [I-D.ietf-ivy-network-inventory-yang] focuses on physical and virtual inventory. Logical inventory is currently outside of the scope. It does not augment RFC8345 like the two Internet-Drafts that it evolved from [I-D.ietf-ccamp-network-inventory-yang] and [I-D.wzwb-opsawg-network-inventory-management]. [I-D.ietf-ivy-network-inventory-topology] correlates the network inventory with the general topology via RFC8345 augmentations that reference inventory.¶

• KPIs: delay, jitter, loss¶

• Attachment Circuits (ACs) [I-D.ietf-opsawg-ntw-attachment-circuit] and [I-D.ietf-opsawg-teas-attachment-circuit]¶

• Configuration: L2SM [RFC8466], L3SM [RFC8299], L2NM [RFC9291], and L3NM [RFC9182]¶

• Incident Management for Network Services [I-D.ietf-nmop-network-incident-yang]¶