<?xml version="1.0" encoding="US-ASCII"?>
<!-- This is built from a template for a generic Internet Draft. Suggestions for
     improvement welcome - write to Brian Carpenter, brian.e.carpenter @ gmail.com 
     This can be converted using the Web service at http://xml.resource.org/ -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<!-- You want a table of contents -->
<!-- Use symbolic labels for references -->
<!-- This sorts the references -->
<!-- Change to "yes" if someone has disclosed IPR for the draft -->
<!-- This defines the specific filename and version number of your draft (and inserts the appropriate IETF boilerplate -->
<?rfc sortrefs="yes"?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc topblock="yes"?>
<?rfc comments="no"?>
<rfc category="info" docName="draft-chen-nmrg-dtn-interface-03"
     ipr="trust200902">
  <front>
    <title abbrev="Network Working Group">Requirements and Design for
    Interfaces of Network Digital Twin</title>

    <author fullname="Danyang Chen" initials="D." surname="Chen">
      <organization>China Mobile</organization>

      <address>
        <postal>
          <street/>

          <city>Beijing</city>

          <code>100053</code>

          <country>China</country>
        </postal>

        <email>chendanyang@chinamobile.com</email>
      </address>
    </author>

    <author fullname="Hongwei Yang" initials="H." surname="Yang">
      <organization>China Mobile</organization>

      <address>
        <postal>
          <street/>

          <city>Beijing</city>

          <code>100053</code>

          <country>China</country>
        </postal>

        <email>yanghongwei@chinamobile.com</email>
      </address>
    </author>

    <author fullname="Cheng Zhou" initials="C." surname="Zhou">
      <organization>China Mobile</organization>

      <address>
        <postal>
          <street/>

          <city>Beijing</city>

          <code>100053</code>

          <country>China</country>
        </postal>

        <email>zhouchengyjy@chinamobile.com</email>
      </address>
    </author>

    <!---->

    <date day="4" month="March" year="2023"/>

    <area>Networking</area>

    <workgroup>Internet Research Task Force</workgroup>

    <keyword>Network Digital Twin; interface</keyword>

    <abstract>
      <t>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.</t>
    </abstract>

    <note title="Requirements Language">
      <t>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 <xref
      target="RFC2119">RFC 2119</xref>.</t>
    </note>
  </front>

  <middle>
    <section anchor="intro" title="Introduction">
      <t>As defined in the<xref
      target="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.</t>

      <t>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.</t>

      <figure title="Schematic Representation of DTN Interface">
        <artwork>+---------------------------------------------------------------------+
|                                                                     |
|                      Network Application Layer                      |
|                                                                     |
+-------^-------------------------^----------------------^------------+
        |                         |                      | 
        |                         |                      |     Twin
        |                         |                      |   Northbound
        |                         |                      |   Interface
+-------v-------------------------v----------------------v-----------+
|                        Twin Network Layer                          |
|                                                                    |
|  +------------+           +----------+          +---------------+  |
|  |   data     |           | service  |          |    digital    |  |
|  |  sharing   &lt;-----------&gt; mapping  &lt;----------&gt;     twin      |  |
|  |  warehouse |   Twin    |  model   |          |   management  |  |
|  +------------+  Internal +----------+          +---------------+  |
|                 Interface                                          |
+--------^------------------------^-----------------------^----------+
         |                        |                       |  Twin
         |                        |                       | Southbound
         |                        |                       | Interface
+--------v------------------------v-----------------------v-----------+
|                                                                     |
|                      Physical Network Layer                         |
|                                                                     |
+---------------------------------------------------------------------+</artwork>
      </figure>
    </section>

    <section title="Requirements for Different Interfaces">
      <t><list style="symbols">
          <t>Twin northbound interface<list>
              <t>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.<list>
                  <t>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;</t>

                  <t>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;</t>

                  <t>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;</t>

                  <t>Flexible deployment: To reduce deployment time and cost,
                  twin northbound interfaces must be flexibly deployed.</t>
                </list></t>
            </list></t>

          <t>Twin Internal interface<list>
              <t>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.<list>
                  <t>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.</t>

                  <t>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.</t>

                  <t>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.</t>

                  <t>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.</t>
                </list></t>
            </list></t>

          <t>Twin southbound interface<list>
              <t>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.<list>
                  <t>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.</t>

                  <t>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.</t>

                  <t>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.</t>
                </list></t>
            </list></t>
        </list></t>
    </section>

    <section title="Modules and Interfaces of Data Sharing Warehouse">
      <t>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.</t>

      <t>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.</t>

      <t><figure title="Schematic Representation of DTN Interface">
          <artwork>+---------------------------------------------------------------------+
|              Service      Mapping        Model                      |
+-------^-------------------------^----------------------^------------+
        |                         |                      | 
        |                         |                      |  
+-------v-------------------------v----------------------v-----------+
|                        Data Sharing Warehouse                      |
|                                                                    |
|  +------------------------+                     +---------------+  |
|  |      Data Service      |  &lt;-------------&gt;    |    Data       |  |
|  +------------------------+                     |               |  |
|                                                 |               |  |
|                                                 |               |  |
|  +-----------------------+                      |  Management   |  |
|  |    Data Storage       |   &lt;-------------&gt;    |               |  |
|  +---------------------^-+                      |               |  |
|                        |                        |               |  |
|   +-----------------+  |                        |               |  |
|   | Data Collection | &lt;---------------------&gt;   |               |  |
|   +-----------------+  |                        +---------------+  |               
+--------^---------------|--------------------------------^----------+
         |               |                                |  
         |               |                                | 
+--------v---------------|--------------------------------v-----------+
|   Data                 |                                            |
|  Source      +---------v--+            +----------------+           |
|              |Other Data  |            |Physical Network|           |
|              | Source     |            | Data Source    |           |
|              +------------+            +----------------+           |
+---------------------------------------------------------------------+</artwork>
        </figure></t>
    </section>

    <section title="Suggestions on the applicability of common protocols">
      <t>With the development of communication networks, many North-South and
      intra-network communication protocols have been formed in the network,
      such as RESTCONF<xref target="RFC8527">RFC 8527</xref>, NETCONF<xref
      target="RFC8526">RFC 8526</xref>, OpenFlow, XMPP<xref
      target="RFC7622">RFC 7622</xref>, 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.<list>
          <t>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.</t>

          <t>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.</t>

          <t>OpenFlow are used for information exchange between OpenFlow
          switches and controllers, so it appllies to twin southbound
          interfaces.</t>

          <t>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.</t>

          <t>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.</t>

          <t>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.</t>

          <t>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.</t>
        </list></t>

      <t/>
    </section>

    <section title="Multi-protocol Coordination Interface Implementation">
      <t>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.</t>

      <t>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.</t>

      <t><list>
          <t>Twin southbound interface protocol adaptation function<list>
              <t>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.</t>

              <t><figure
                  title="Southbound Interface Protocol Adaptation Function">
                  <artwork>+------------------------------------------------------------+
|   Collaborative Adaptation of Southbound Interfaces        |
| +-------------+ +------------+ +-------------+ +---------+ |
| |Configuration| |   Analysis | |   Identif.  | | Data    | |
| |  Management | |&amp; Conversion| |&amp;   Matching | | Manag.  | |
| +-------------+ +------------+ +-------------+ +---------+ |
+------------------------------------------------------------+</artwork>
                </figure></t>

              <t><list>
                  <t>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.</t>
                </list><list>
                  <t>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.</t>
                </list><list>
                  <t>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.</t>
                </list><list>
                  <t>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.</t>
                </list>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.</t>
            </list></t>

          <t>Twin northbound interface protocol adaptation function</t>
        </list>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.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>TBD</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This document has no requests to IANA.</t>
    </section>
  </middle>

  <back>
    <references title="Informative References">
      <?rfc include="reference.I-D.irtf-nmrg-network-digital-twin-arch"?>
    </references>

    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>

      <?rfc include="reference.RFC.8527"?>

      <?rfc include="reference.RFC.8526"?>

      <?rfc include="reference.RFC.7622"?>
    </references>
  </back>
</rfc>
