]> Digital Map: Concept, Requirements, and Use Cases Huawei
olga.havel@huawei.com
Huawei
benoit.claise@huawei.com
Telefonica
oscar.gonzalezdedios@telefonica.com
Swisscom
thomas.graf@swisscom.com
Operations and Management Network Management Operations Service emulation Automation Network Automation Orchestration service delivery Service provisioning service flexibility service simplification Network Service Digital Map Digital Twin Emulation Simulation Topology Multi-layer This document defines the concept of Digital Map, explains its connection to the Digital Twin, and identifies a set of Digital Map requirements and use cases. The document intends to be used as a reference for the assessment effort of the various topology modules to meet Digital Map requirements. Discussion Venues Discussion of this document takes place on the Network Management Operations Working Group mailing list (nmop@ietf.org), which is archived at . Source for this draft and an issue tracker can be found at .
Introduction
Digital Twin Overview The network digital twin (referred to simply as Digital Twin) concepts and a reference architecture are discussed in the "Digital Twin Network: Concepts and Reference Architecture" . That reference document defines the core elements of Digital Twin: Data, Models, Interfaces, and Mapping. The Digital Twin, constructed based on the four core technology elements, is intended to analyze, diagnose, emulate, and control the physical network in its whole lifecycle with the help of optimization algorithms, management methods, and expert knowledge. Also, that document states that a Digital Twin can be seen as an indispensable part of the overall network system and provides a general architecture involving the whole lifecycle of physical networks in the future, serving the application of innovative network technologies (e.g., network planning, construction, maintenance and optimization, improving the automation and intelligence level of the network).
Digital Map Digital Map provides the core multi-layer topology model and data for the Digital Twin and connects them to the other Digital Twin models and data. This includes layers from physical topology to service topology. The Digital Map modelling defines the core topological entities (network, node, link, and interface) at each layer, their role in the network, core properties, and relationships both inside each layer and between the layers. The Digital Map model can be approached as a topological model that is linked to other functional parts of the Digital Twin 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. The Digital Map data consists of virtual instances of network and service topologies at different layers. The Digital Map provides the access to this data via standard APIs for both read and write operations (write operations for offline simulations), with query capabilities and links to other YANG modules (e.g., Service Assurance for Intent-based Networking (SAIN) , Service Attachement Points (SAPs) , Inventory , and non-YANG models.
Digital Map as a Prerequisite for Digital Twin One of the important requirements for Digital Twin is to ease correlating all models and data to topological entities at different layers in the layered twin network. The Digital Map aims at providing a virtual instance of the topological information of the network, based on this Digital Map Model. Building a Digital Map is prerequisite towards the Digital Twin. The Digital Map model/data provide this missing correlation between the topology models/data and all other models/data: KPIs, alarms, incidents, inventory (with UUIDs), configuration, traffic engineering, planning, simulation ("what-if"), emulations, actions, and behaviors. Some of these models/data provide a device view, some provide a network or subnetwork view, while others focus more on the customer service perspective. All these views are needed for both inner and outer closed-loops. It is debatable what is part of the Digital Map itself versus what are pointers from the Digital Map to some other sources of information. As an example, a Digital Map should not specifically include all information about the device inventory (product name, vendor, product series, embedded software, and hardware/software versions, as specified in a Network Inventory. A pointer to another inventory system might be sufficient or support of means that ease the mapping between inventory and topology. Similarly, Digital Map should not specifically contain incidents, configuration, data plane monitoring, or even assurance information, simply to name a few, but should provide pointers to the different data sources.
Scope This document defines the concept of Digital Map, explains its connection to the Digital Twin, and identifies a set of Digital Map requirements and use cases. The document intends to be used as a reference for the assessment effort of the various topology modules to meet Digital Map requirements.
Terminology The document defines the following terms:
Digital Twin:
Virtual instance of a physical system (twin) that is continually updated with the latter's performance, maintenance and health status data throughout the physical system's life cycle (as defined in
Topology:
Network topology defines how physical or logical nodes, links and interfaces are related and arranges. Service topology defines how service components (e.g., VPN instances, customer interfaces, and customer links) between customer sites are interrelated and arranged. There are at least 8 types of topologies: point to point, bus, ring, star, tree, mesh, hybrid and daisy chain. Topologies may be unidirectional or bidirectional (bus, some rings).
Topology layer:
Defines a layer in the multilayer topology. A multilayer topology models relationships between different layers of connectivity, where each layer represents a connectivity aspect of the network and service that needs to be configured, controlled and monitored.
The topology layer can also represent what needs to be managed by a specific user, for example IGP layer can be of interest to the operator troubleshooting or optimizating 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 L1 topology for physical topology, Layer 2 for link topology and Layer 3 for IPv4 and IPv6 topologies.
Some topology layers represent the control aspects of Layer 3, 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 top layer represents the application/flow view of connectivity.
Digital Map:
Basis for the Digital Twin that provides a virtual instance of the topological information of the network. It provides the core multi-layer topology model and data for the Digital Twin and connects them to the other Digital Twin models and data.
Digital Map modelling:
The set of principles, guidelines, and conventions to model the Digital Map using the IETF approach. They cover the network types (layers and sublayers), entity types, entity roles (network, node, termination point or link), entity properties and relationship types between entities.
Digital Map model:
Defines the core topological entities, their role in the network, core properties and relationships both inside each layer and between the layers.
It is the basic topological model that is linked to other functional parts of the Digital Twin and connects them all: configuration, maintenance, assurance (KPIs, status, health, symptoms, etc.), traffic engineering, different behaviors, simulation, emulation, mathematical abstractions, AI algorithms, etc.
Digital Map 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 functional data for the instances, including configuration, health, symptoms. :The data can be historical, real-time, or future data for 'what-if' scenarios.
Sample Digital Map Use Cases The following are sample Digital Twin use cases that require Digital Map:
  • Generic inventory queries
  • Service placement feasibility checks
  • Service-> subservice -> resource
  • Resource -> subservice -> service
  • Intent/service assurance
  • Service E2E and per-link KPIs on the Digital Map (delay, jitter, and loss)
  • Capacity planning
  • Network design
  • Simulation
  • Closed loop
Overall, the Digital Map is needed to break down data islands and have a Digital Twin for emulation and closed loop, which is a catalyst for autonomous networking.
Digital Map Requirements
Core Requirements The following are the core requirements for the Digital Map (note that some of them are supported by default by ):
REQ-BASIC-MODEL-SUPPORT:
Basic model with network, node, link, and interface entity types. This means that users of the Digital Map model must be able to understand 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:
Layered Digital Map, from physical network (ideally optical, layer 2, layer 3) up to service and intent views.
REQ-PROG-OPEN-MODEL:
Open and programmable Digital Map.
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 Digital Map 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 Digital Map for future simulation and a change that reflects the current reality of the network.
REQ-STD-API-BASED:
Standard based Digital Map Models and APIs, for multi-vendor support.
Digital Map 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:
Digital Map models and APIs must be common over different network domains (campus, core, data center, etc.). This means that clients of the Digital Map 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-SEMANTIC:
Digital Map must provide semantics for layered network topologies and for linking external models/data.
REQ-LAYER-NAVIGATE:
Digital Map must provide intra-layer and inter-layer relationships.
REQ-EXTENSIBLE:
Digital Map must be extensible with metadata.
REQ-PLUGG:
Digital Map must be pluggable. That is,
  • Must connect to other YANG modules for inventory, configuration, assurance, etc.
  • Given that no all involved components can be available using YANG, there is a need to connect Digital Map YANG model with other modelling mechanisms.
REQ-GRAPH-TRAVERSAL:
Digital Map 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.
Design Requirements The following are design requirements for modelling the Digital Map:
REQ-TOPO-ONLY:
Digital Map should contain only topological information.
Digital Map is not required to contain all data required for all the management and use cases. However, it should be designed to support adequate pointers to other functional Digital Twin data and models to ease navigating in the overall system. For example:
  • ACLs and Route Policies are not required to be supported in the Digital Map, they would be linked to Digital Map
  • Dynamic paths may either be outside of the Digital Map or part of traffic engineering data/models
REQ-PROPERTIES:
Digital Map entities should mainly contain properties used to identify topological entities at different layers, identify their roles, and topological relationships between them.
REQ-RELATIONSHIPS:
Digital Map should contain only topological relationships inside each layer or between the layers (underlay/overlay).
REQ-CONDITIONAL:
Provide capability for conditional retrieval of parts of Digital Map.
REQ-TEMPO-HISTO:
Must support geo-spatial, temporal, and historical data. The temporal and historical can be supported external to the Digital Map.
Architectural Requirements The following are the architectural requirements for the Digital Map:
REQ-DM-SCALES:
Scale, performance, ease of integration.
REQ-DM-DISCOVERY:
Initial discovery and dynamic (change only) synch with the physical network.
Security Considerations As this document covers the Digital Map concepts, requirements, and use cases, there is no specific security considerations. However, the RFC 8345 Security Considerations aspects will be useful when designing the solution.
IANA Considerations This document has no actions for IANA.
References Normative References 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. Informative References Network Digital Twin: Concepts and Reference Architecture China Mobile China Mobile China Mobile Huawei Orange Orange Digital Twin technology has been seen as a rapid adoption technology in Industry 4.0. 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 concepts of Digital Twin Network, provides the basic definitions and a reference architecture, lists a set of application scenarios, and discusses such technology's benefits and key challenges. 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 YANG Data Model for Network Inventory Huawei Technologies Nokia Vodafone TIM Cisco This document defines a base YANG data model for network inventory that is application- and technology-agnostic. This data model can be augmented with application-specific and technology-specific details in other, more specific network inventory data models. 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 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. 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. 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 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 Huawei 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' data model 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 YANG Data Model for Network Hardware Inventory Huawei Technologies Nokia Vodafone TIM Cisco This document defines a YANG data model for network hardware inventory data information. The YANG data model presented in this document is intended to be used as the basis toward a generic YANG data model for network hardware inventory data information which can be augmented, when required, with technology-specific (e.g., optical) inventory data, to be defined either in a future version of this document or in another document. The YANG data model defined in this document conforms to the Network Management Datastore Architecture (NMDA). A YANG Network Data Model of Network Inventory Huawei China Mobile Huawei Orange This document defines a base YANG data model for network inventory that is application- and technology-agnostic. This data model can be augmented with application-specific and technology-specific details in other, more specific network inventory data models. This document is meant to help IVY base Network Inventory model discussion and ease agreement on a base model that would be flexible enough to be augmented with components that are covered by the IVY Charter. The hardware components definition are adapted from draft-ietf-ccamp- network-inventory-yang-02. A Network Inventory Topology Model Huawei China Mobile Huawei Orange This document defines a YANG model for network inventory topology to correlate the network inventory data with the general topology model to form a base underlay network, which can facilitate the mapping and correlation of the layer (e.g. Layer 2, Layer3) topology information above to the inventory data of the underlay network for agile service provisioning and network maintenance analysis. A Network YANG Data Model for Attachment Circuits Orange Juniper Telefonica Nokia Huawei Technologies 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) Orange Juniper Telefonica Nokia Huawei Technologies This document specifies a YANG service data model for Attachment Circuits (ACs). This model can be used for the provisioning of ACs before or during service provisioning (e.g., Network Slice Service). The document also specifies a service model for managing bearers over which ACs are established. Also, the document specifies a set of reusable groupings. Whether other service models reuse structures defined in the AC models or simply include an AC reference is a design choice of these service models. Utilizing the AC service model to manage ACs over which a service is delivered has the advantage of decoupling service management from upgrading AC components to incorporate recent AC technologies or features. 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 Huawei Ciena A network incident refers to an unexpected interruption of a network service, degradation of a network service quality, or sub-health of a network service. Different data sources including alarms, metrics, and other anomaly information can be aggregated into a few amount of network incidents by data correlation analysis and the service impact analysis. This document defines a YANG Module for the network incident lifecycle management. This YANG module is meant to provide a standard way to report, diagnose, and help resolve network incidents for the sake of network service health and root cause analysis.
Related IETF Activities
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.
Core Digital Map Components The following specifications are core for the Digital Map:
  • 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 OSFP topology
    • A YANG data model for IS-IS topology
Additional Digital Map Components The Digital Map 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 RFC8345 like the two Internet-Drafts that it evolved from and . correlates the network inventory with the general topology via RFC8345 augmentations that reference inventory.
  • KPIs: delay, jitter, loss
  • Attachment Circuits (ACs) and
  • Configuration: L2SM , L3SM , L2NM , and L3NM
  • Incident Management for Network Services
Acknowledgments Many thanks to Mohamed Boucadair (mohamed.boucadair@orange.com) for his valuable contributions, reviews, and comments. Many thanks to Nigel Davis ndavis@ciena.com for the valuable discussions and his confirmation of the modelling requirements.
Contributors Swisscom
Ahmed.Elhassany@swisscom.com