Internet Research Task Force D. Chen Internet-Draft H. Yang Intended status: Informational C. Zhou Expires: 11 January 2024 China Mobile 10 July 2023 Requirements adn Design for Interfaces of Network Digital Twin draft-chen-nmrg-dtn-interface-02 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 11 January 2024. Copyright Notice Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved. Chen, et al. Expires 11 January 2024 [Page 1] Internet-Draft Network Working Group July 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. Suggestions on the applicability of common protocols . . . . 6 4. Multi-protocol Coordination Interface Implementation . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.1. Informative References . . . . . . . . . . . . . . . . . 11 7.2. Normative References . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 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 Chen, et al. Expires 11 January 2024 [Page 2] Internet-Draft Network Working Group July 2023 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 Chen, et al. Expires 11 January 2024 [Page 3] Internet-Draft Network Working Group July 2023 - 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, 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 Chen, et al. Expires 11 January 2024 [Page 4] Internet-Draft Network Working Group July 2023 - 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. 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 Chen, et al. Expires 11 January 2024 [Page 5] Internet-Draft Network Working Group July 2023 - 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. 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. 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. 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. Chen, et al. Expires 11 January 2024 [Page 6] Internet-Draft Network Working Group July 2023 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 11 January 2024 [Page 7] Internet-Draft Network Working Group July 2023 4. 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 11 January 2024 [Page 8] Internet-Draft Network Working Group July 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 2: 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 11 January 2024 [Page 9] Internet-Draft Network Working Group July 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 11 January 2024 [Page 10] Internet-Draft Network Working Group July 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. 5. Security Considerations TBD 6. IANA Considerations This document has no requests to IANA. 7. References 7.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-03, 27 April 2023, . 7.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, . [RFC7622] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Address Format", RFC 7622, DOI 10.17487/RFC7622, September 2015, . Chen, et al. Expires 11 January 2024 [Page 11] Internet-Draft Network Working Group July 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, . [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, . 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 11 January 2024 [Page 12]