Internet DRAFT - draft-chen-nmrg-dtn-interface
draft-chen-nmrg-dtn-interface
Internet Research Task Force D. Chen
Internet-Draft H. Yang
Intended status: Informational C. Zhou
Expires: 5 September 2023 China Mobile
4 March 2023
Requirements and Design for Interfaces of Network Digital Twin
draft-chen-nmrg-dtn-interface-03
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.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
Chen, et al. Expires 5 September 2023 [Page 1]
Internet-Draft Network Working Group March 2023
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements for Different Interfaces . . . . . . . . . . . . 3
3. Modules and Interfaces of Data Sharing Warehouse . . . . . . 6
4. Suggestions on the applicability of common protocols . . . . 7
5. Multi-protocol Coordination Interface Implementation . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Informative References . . . . . . . . . . . . . . . . . 12
8.2. Normative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
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
Chen, et al. Expires 5 September 2023 [Page 2]
Internet-Draft Network Working Group March 2023
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
* Twin northbound interface
- The twin northbound interface is the interface between the
network application layer and the twin network layer. The
network application requirements are input from the twin
northbound interface to the twin network layer. The twin
northbound interface can support the rapid deployment of
network applications such as network operation and
optimization, network visualization, intent verification, and
network automatic driving with lower cost, higher efficiency,
Chen, et al. Expires 5 September 2023 [Page 3]
Internet-Draft Network Working Group March 2023
and less impact on live network services. Therefore, the twin
northbound interface should have the characteristics of the
following 4 aspects.
o Openness: The twin northbound interface must meet the
business requirements of different network applications and
can be input to the twin network layer, so it needs to have
good openness and compatibility;
o Scalability: There are a variety of network applications in
the network application layer, which will inevitably lead to
the generation of network applications. At the same time,
the continuous development of the network is bound to
introduce new network applications. With the upgrade of
network applications and the generation of new applications,
the twin northbound interface should be able to expand in
time to meet the needs of new network applications;
o Portability: There are twins with different sizes and
functions in the twin network layer. The same or similar
requirements of various applications in the network
application layer may be deployed on different twins.
Therefore, the twin northbound interface should be easily
transplanted and deployed on different twins;
o Flexible deployment: To reduce deployment time and cost,
twin northbound interfaces must be flexibly deployed.
* Twin Internal interface
- As shown in the "three-layer, three-domain, double-closed loop"
of DTN architecture, the twin network layer contains three key
subsystems, namely, data sharing warehouse, service mapping
model and digital twin management, which is the most critical
part of the digital twin network. The internal interface of
the twin layer refers to the interface within and between the
three subsystems: data sharing warehouse, service mapping model
and digital Twin management. In order to support the functions
of the three subsystems in the twin network layer and the
interaction between the three subsystems, the internal
interface of the twin layer should have the following four
functions.
o Unity: Each subsystem in the twin network layer should be
able to provide the same data format and data service for
other subsystems through the internal interface of the twin
layer, that is, the interface should have unity.
Chen, et al. Expires 5 September 2023 [Page 4]
Internet-Draft Network Working Group March 2023
o Adaptability: The twin network layer must interact with the
network application layer and the physical network layer,
and should be well adapted to various network devices and
interfaces. Therefore, the internal interfaces of the twin
layer also need to be adaptive.
o Portability: The data model instances provided by the
service mapping model subsystem for different applications
may have a high degree of similarity. In order to improve
efficiency, the data model instances must be able to be
provided and deployed through different internal interfaces
of twin layers.
o Flexible and extensible: The twin network layer must be able
to verify different new network services. In order to
shorten the implementation time of functions, the
implementation of functions inside the twin layer should be
simplified as far as possible. Therefore, the internal
interface of the twin network layer must be flexible and
extensible.
* Twin southbound interface
- The twin southbound interface is the interface between the twin
network layer and the physical entity network. Control updates
are delivered from the twin southbound interface to the
physical entity network, and various nes in the physical entity
network exchange network data and network control information
with the twin network layer through the twin southbound
interface. Therefore, the southbound twin interface should
have three functions.
o Information interaction capability: the twin southbound
interface should be able to collect the information of
different physical NEs or network devices, and send the
configuration information of the twin network to the
physical network for execution, that is, it can realize the
information interaction between the twin network layer and
the physical entity network.
o Real-time: The realization of twin network configuration
verification and other functions must have certain real-
time, so the information collected and uploaded from the
physical entity network and the configuration information
sent from the twin network to the physical network must have
certain real-time, in order to meet the real-time
requirements of the digital twin network.
Chen, et al. Expires 5 September 2023 [Page 5]
Internet-Draft Network Working Group March 2023
o Compatibility: Network devices and NEs from different
manufacturers use different interfaces and protocols. The
southbound interfaces must be compatible to ensure the
reliability of information collection and configuration
delivery.
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.
Chen, et al. Expires 5 September 2023 [Page 6]
Internet-Draft Network Working Group March 2023
+---------------------------------------------------------------------+
| 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.
Chen, et al. Expires 5 September 2023 [Page 7]
Internet-Draft Network Working Group March 2023
RESTCONF uses the Hypertext Transfer Protocol (HTTP) as the
transport protocol and XML/JSON as the message exchange format,
allowing WEB applications to access configuration and operation
data of network devices in a modular and extensible manner. It
applies to twin northbound interfaces.
NETCONF uses remote procedure call ( RPC) based mechanism to
provide a set of framework mechanism to add, modify, delete
network device configuration, query configuration, status and
statistics between the client and the server, and can be used as a
network administrator or network configuration application and
network device logical connection. NETCONF can transmit
configuration data and status data. So it can be used for twin
northbound interfaces and twin southbound interfaces.
OpenFlow are used for information exchange between OpenFlow
switches and controllers, so it appllies to twin southbound
interfaces.
Extensible Message Processing Thread Protocol (XMPP) is an open
technology for instant messaging, multi-party chat, voice and
video calling, collaboration, content syndication, and generic XML
data routing, so it is suitable for twin southbound interfaces and
twin internal interfaces.
Routing system interface protocols (I2RS) dynamically deliver
routing status and policies based on topology changes and traffic
statistics, enabling external applications or controlling entities
to read router information and it can also be used for twin
southbound interfaces and twin internal interfaces.
East-West Bridge is an application-layer protocol based on
Transmission Control Protocol/Secure Socket Protocol (TCP/SSL),
which has good portability and scalability. NEs can be abstracted
into concepts such as nodes, links, ports, and flows. The
extended link layer discovery protocol is used to obtain the ID,
capacity, and status of each NE in the domain. So it applies for
twin internal interfaces.
Simple Network Management Protocol (SNMP) is a standard protocol
specifically designed to manage network nodes over IP networks.
Network administrators can use SNMP to manage network performance,
identify and resolve network problems, and plan network growth.
It can be used for twin northbound interfaces and twin internal
interfaces.
Chen, et al. Expires 5 September 2023 [Page 8]
Internet-Draft Network Working Group March 2023
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.
Twin southbound interface protocol adaptation function
Chen, et al. Expires 5 September 2023 [Page 9]
Internet-Draft Network Working Group March 2023
- Based on the above research on protocol fusion and protocol
transformation, in order to realize the protocol transformation
between the twin network layer and the physical network layer,
ensure the efficiency of protocol processing, accurate and
executable configuration information distribution, and reduce
the complexity of protocol processing as much as possible, this
paper introduces the southbound interface protocol adaptation
function at the interaction between the twin network layer and
the physical network layer. As shown in Figure 2, the protocol
adaptation function of the southbound interface consists of
four modules: protocol configuration management, protocol
analysis and conversion, protocol identification and matching,
and data management.
+------------------------------------------------------------+
| Collaborative Adaptation of Southbound Interfaces |
| +-------------+ +------------+ +-------------+ +---------+ |
| |Configuration| | Analysis | | Identif. | | Data | |
| | Management | |& Conversion| |& Matching | | Manag. | |
| +-------------+ +------------+ +-------------+ +---------+ |
+------------------------------------------------------------+
Figure 3: Southbound Interface Protocol Adaptation Function
- o Protocol configuration management module: All packets sent
from the physical network layer to the twin network layer
are processed and the corresponding configuration
information is obtained, which provides the required
configuration information for the protocol identification
and matching module and the protocol analysis and conversion
module.
o Protocol identification and matching module: The twin
southbound interfaces interact with the physical network
layer. The protocols supported by the devices at the
physical network layer are identified and recorded based on
the device ID, terminal device information, and NE
information carried by access control, and the corresponding
terminal protocol table is formed according to these
information. In addition, function verification is
completed at the twin network layer and network
configuration is also generated. Then the network
configuration information is delivered to specific devices
on the physical network. In this case, the protocol
identification and matching module need to ensure that the
command transmission protocol is supported by the
corresponding device according to the terminal protocol
table.
Chen, et al. Expires 5 September 2023 [Page 10]
Internet-Draft Network Working Group March 2023
o Protocol analysis and conversion module: The information
uploaded from the physical network is analyzed and converted
into the protocol types supported by the three subsystems of
the twin network layer. Or reverse the processing, that is,
the data, model, and configuration information of the three
sub-systems in the twin layer is parsed and converted into
protocols supported by external applications or physical
devices. At the same time, the functions of different
subsystems in the twin network layer are different, so the
protocol parsing and conversion module must convert the
protocol into a unified protocol format supported by the
three subsystems in the twin network layer, so as to
simplify the protocol forwarding and information interaction
process in the twin network layer.
o Data management module: The different data formats of the
different protocols used in the physical network layer and
the network application layer are converted into the data
formats applicable to the protocols used inside the twin
network layer.
The twin-layer southbound interface protocol adaptation
function identifies, analyzes, and converts multiple protocols
used by different terminals and devices at the physical network
layer. It simplifies information exchange among the three sub-
systems at the twin-layer and between the twin-layer and the
physical network layer, and implements protocol-independent
information processing and data forwarding functions at the
twin-layer. By introducing the southbound interface protocol
adaptation unit, the network devices in the underlying physical
network do not need to be modified too much, and the protocol
conversion and adaptation work can be completed by the
southbound multi-protocol adaptation unit, which makes the
functions of the twin network layer easier to realize and
further reduces the complexity of the construction of digital
twin network.
Twin northbound interface protocol adaptation function
Chen, et al. Expires 5 September 2023 [Page 11]
Internet-Draft Network Working Group March 2023
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, 23 October 2023,
<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, March 1997,
<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, September 2015,
<https://www.rfc-editor.org/info/rfc7622>.
Chen, et al. Expires 5 September 2023 [Page 12]
Internet-Draft Network Working Group March 2023
[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, March 2019,
<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, March 2019,
<https://www.rfc-editor.org/info/rfc8527>.
Authors' Addresses
Danyang Chen
China Mobile
Beijing
100053
China
Email: chendanyang@chinamobile.com
Hongwei Yang
China Mobile
Beijing
100053
China
Email: yanghongwei@chinamobile.com
Cheng Zhou
China Mobile
Beijing
100053
China
Email: zhouchengyjy@chinamobile.com
Chen, et al. Expires 5 September 2023 [Page 13]
