Internet-Draft Network Working Group March 2023
Chen, et al. Expires 5 September 2023 [Page]
Workgroup:
Internet Research Task Force
Internet-Draft:
draft-chen-nmrg-dtn-interface-03
Published:
Intended Status:
Informational
Expires:
Authors:
D. Chen
China Mobile
H. Yang
China Mobile
C. Zhou
China Mobile

Requirements and Design for Interfaces of Network Digital Twin

Abstract

The interfaces of Digital Twin Network can be divided as twin network southbound interface, internal interface and northbound interface. In order to build a digital twin network and realize its many advantages, different interfaces should be able to meet different requirements. And this memo introduces the requirements and design about interfaces of the Digital Twin Network.

Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 5 September 2023.

Table of Contents

1. Introduction

As defined in the[I-D.irtf-nmrg-network-digital-twin-arch] , the digital twin network is defined as "a network system with a physical network entity and a virtual twin, and the two can interact with each other in real time". And it has four core elements: data, model, mapping and interaction. Accordingly, a "three-layer, three-domain and double-closed loop" architecture is adopted.

Based on the above architecture definition of three-layer, three-domain and double-closed-loop, the interfaces of each layer and their positions of the digital twin network are shown in Figure 1. The network elements in the physical entity network exchange network data and network control information with the twin network layer through the twin southbound interface. The twin network layer contains three key subsystems, which are data sharing warehouse, service mapping model and digital twin management. Through the corresponding interface protocol, the construction and interaction requirements of the three key subsystems should be met. And through the internal interface of the twin layer, the interaction between the three key subsystems and the physical network layer and network application layer is realized. Network applications input requirements to the twin network layer through the twin northbound interface, and deploy services in the twin network layer through the model example. To sum up, there are differences in interface protocol requirements between different layers of DTN and within twin layers. In addition, the protocols supported by different devices in the physical network layer are also different, so the construction of DTN also needs to consider how to achieve efficient collaboration between different protocols.

+---------------------------------------------------------------------+
|                                                                     |
|                      Network Application Layer                      |
|                                                                     |
+-------^-------------------------^----------------------^------------+
        |                         |                      |
        |                         |                      |     Twin
        |                         |                      |   Northbound
        |                         |                      |   Interface
+-------v-------------------------v----------------------v-----------+
|                        Twin Network Layer                          |
|                                                                    |
|  +------------+           +----------+          +---------------+  |
|  |   data     |           | service  |          |    digital    |  |
|  |  sharing   <-----------> mapping  <---------->     twin      |  |
|  |  warehouse |   Twin    |  model   |          |   management  |  |
|  +------------+  Internal +----------+          +---------------+  |
|                 Interface                                          |
+--------^------------------------^-----------------------^----------+
         |                        |                       |  Twin
         |                        |                       | Southbound
         |                        |                       | Interface
+--------v------------------------v-----------------------v-----------+
|                                                                     |
|                      Physical Network Layer                         |
|                                                                     |
+---------------------------------------------------------------------+
Figure 1: Schematic Representation of DTN Interface

2. Requirements for Different Interfaces

3. Modules and Interfaces of Data Sharing Warehouse

As the base of realizing various capabilities of the digital twin network, data is the cornerstone of building the digital twin network. By building a unified data repository as the single source of truth for digital twin network, it can efficiently store historical and real-time data such as the configuration, topology, and status, logs, and user business of the physical network, providing data support for the network digital twin entity. In order to achieve these functions, the modlues and interfaces inside the data sharing warehouse should be standared.

According to the flow of data process, the data sharing warehouse should contain the following four modules: data collection module, data storage module, data service module and data management module.

+---------------------------------------------------------------------+
|              Service      Mapping        Model                      |
+-------^-------------------------^----------------------^------------+
        |                         |                      |
        |                         |                      |
+-------v-------------------------v----------------------v-----------+
|                        Data Sharing Warehouse                      |
|                                                                    |
|  +------------------------+                     +---------------+  |
|  |      Data Service      |  <------------->    |    Data       |  |
|  +------------------------+                     |               |  |
|                                                 |               |  |
|                                                 |               |  |
|  +-----------------------+                      |  Management   |  |
|  |    Data Storage       |   <------------->    |               |  |
|  +---------------------^-+                      |               |  |
|                        |                        |               |  |
|   +-----------------+  |                        |               |  |
|   | Data Collection | <--------------------->   |               |  |
|   +-----------------+  |                        +---------------+  |
+--------^---------------|--------------------------------^----------+
         |               |                                |
         |               |                                |
+--------v---------------|--------------------------------v-----------+
|   Data                 |                                            |
|  Source      +---------v--+            +----------------+           |
|              |Other Data  |            |Physical Network|           |
|              | Source     |            | Data Source    |           |
|              +------------+            +----------------+           |
+---------------------------------------------------------------------+
Figure 2: Schematic Representation of DTN Interface

4. Suggestions on the applicability of common protocols

With the development of communication networks, many North-South and intra-network communication protocols have been formed in the network, such as RESTCONFRFC 8527 [RFC8527], NETCONFRFC 8526 [RFC8526], OpenFlow, XMPPRFC 7622 [RFC7622], East-West Bridge, etc.. Because different communication protocols have different characteristics, the existing protocols are suitable for different twin network interfaces. In this draft, we attempt to give some suggestions about the applicability of some existing general protocols suitable for DTN construction.

5. Multi-protocol Coordination Interface Implementation

As mentioned above, the physical network in DTN covers various network types, such as mobile access network, core network, and data center network. Therefore, there are many types of network element (NE) devices, and the protocols supported by devices of different manufacturers are different. At the same time, the network application layer in DTN also should support a variety of protocols for different network applications. Therefore, the internal interface of the twin layer must be able to achieve multi-protocol collaboration to meet the diversified protocols and differentiated data formats supported by NEs or network devices of different manufacturers. In addition, the internal interface of the twin network layer must also support changes in requirements and adaptation changes of interface protocols brought about by different applications and application upgrades. At the same time, since the construction of the twin network layer is not only a simple, 1:1 complete copy of the physical network, but a physical network mapping through model abstraction, the implementation of protocol conversion and other processing through multi-protocol collaboration within the twin layer can not only achieve the simplification of the internal protocol of the twin layer, but also will not affect the original DTN system construction.

At present, in view of the problem that there are many types of protocols in the network, the industry has also carried out related research. It can be seen that the research of multi-protocol conversion and fusion has a certain basis, but how to achieve multi-protocol collaboration in DTN remains to be studied. In addition, for protocols of the twin northbound interfaces and twin southbound interfaces need to process are different, the protocol adaptation functions of the northbound interfaces and southbound interfaces are different.

Compared with the wide variety of protocols supported by NEs at the physical layer, the number of protocols used by applications at the current network application layer is small, and most applications based on Rest API are implemented. Therefore, compared with the protocol adaptation function of the southbound interface, the protocol adaptation function of the twin northbound interface is simpler. Similar to the southbound interface protocol adaptation function, the northbound interface protocol adaptation function also requires a protocol parsing and conversion module to convert the service requirements of Rest API-based network applications into protocols that can be executed at the network twin layer.

6. Security Considerations

TBD

7. IANA Considerations

This document has no requests to IANA.

8. References

8.1. Informative References

[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, "Digital Twin Network: Concepts and Reference Architecture", Work in Progress, Internet-Draft, draft-irtf-nmrg-network-digital-twin-arch-04, , <https://datatracker.ietf.org/doc/html/draft-irtf-nmrg-network-digital-twin-arch-04>.

8.2. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC7622]
Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Address Format", RFC 7622, DOI 10.17487/RFC7622, , <https://www.rfc-editor.org/info/rfc7622>.
[RFC8526]
Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, "NETCONF Extensions to Support the Network Management Datastore Architecture", RFC 8526, DOI 10.17487/RFC8526, , <https://www.rfc-editor.org/info/rfc8526>.
[RFC8527]
Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, "RESTCONF Extensions to Support the Network Management Datastore Architecture", RFC 8527, DOI 10.17487/RFC8527, , <https://www.rfc-editor.org/info/rfc8527>.

Authors' Addresses

Danyang Chen
China Mobile
Beijing
100053
China
Hongwei Yang
China Mobile
Beijing
100053
China
Cheng Zhou
China Mobile
Beijing
100053
China