Re: [nmrg] [draft-irtf-nmrg-network-digital-twin-arch] Digital twin = Management datastore

Cheng Zhou <zhouchengyjy@chinamobile.com> Mon, 13 March 2023 08:14 UTC

Return-Path: <zhouchengyjy@chinamobile.com>
X-Original-To: nmrg@ietfa.amsl.com
Delivered-To: nmrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33DE7C1522A0 for <nmrg@ietfa.amsl.com>; Mon, 13 Mar 2023 01:14:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.895
X-Spam-Level:
X-Spam-Status: No, score=-6.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yzcViSS_L1so for <nmrg@ietfa.amsl.com>; Mon, 13 Mar 2023 01:14:39 -0700 (PDT)
Received: from cmccmta2.chinamobile.com (cmccmta2.chinamobile.com [221.176.66.80]) by ietfa.amsl.com (Postfix) with ESMTP id 075AFC1516F8 for <nmrg@irtf.org>; Mon, 13 Mar 2023 01:14:06 -0700 (PDT)
X-RM-TagInfo: emlType=0
X-RM-SPAM-FLAG: 00000000
Received: from spf.mail.chinamobile.com (unknown[172.16.121.5]) by rmmx-syy-dmz-app07-12007 (RichMail) with SMTP id 2ee7640edb48dac-3468b; Mon, 13 Mar 2023 16:14:00 +0800 (CST)
X-RM-TRANSID: 2ee7640edb48dac-3468b
X-RM-TagInfo: emlType=0
X-RM-SPAM-FLAG: 00000000
Received: from cmccPC (unknown[10.2.55.24]) by rmsmtp-syy-appsvr03-12003 (RichMail) with SMTP id 2ee3640edb44e32-cc5f5; Mon, 13 Mar 2023 16:14:00 +0800 (CST)
X-RM-TRANSID: 2ee3640edb44e32-cc5f5
From: Cheng Zhou <zhouchengyjy@chinamobile.com>
To: "'Schwarz Albrecht (ETAS-DAP/XPC-Fe6)'" <Albrecht.Schwarz=40etas.com@dmarc.ietf.org>, nmrg@irtf.org
References: <AM6PR10MB3079E0C5266EFD4D7156DF2BF9949@AM6PR10MB3079.EURPRD10.PROD.OUTLOOK.COM> <VE1PR10MB3086C75E594E78163E4554B5F9B79@VE1PR10MB3086.EURPRD10.PROD.OUTLOOK.COM>
In-Reply-To:
Date: Mon, 13 Mar 2023 16:13:58 +0800
Message-ID: <04f701d95583$c3e65830$4bb30890$@com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_04F8_01D955C6.D2099830"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AdigObrSjzuLrTwzRRW5znGzb8fVFCw3+o9wACcCJXAAYUXvkA==
Content-Language: zh-cn
Archived-At: <https://mailarchive.ietf.org/arch/msg/nmrg/L6yn0K_zmc-fUmuyPkM8JfRomjo>
Subject: Re: [nmrg] [draft-irtf-nmrg-network-digital-twin-arch] Digital twin = Management datastore
X-BeenThere: nmrg@irtf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Network Management Research Group discussion list <nmrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/nmrg>, <mailto:nmrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nmrg/>
List-Post: <mailto:nmrg@irtf.org>
List-Help: <mailto:nmrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/nmrg>, <mailto:nmrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Mar 2023 08:14:44 -0000

Dear Dr. Albrecht Schwarz, 

 

Very sorry to say I missed your mail sent last year for some unknown reason, then didn’t reply in time.

 

On behalf of co-authors, below are several key points that shall address your concerns.  

-        DTN is conceptually and architecturally new by introducing Digital Twin technology in the networking field. High-fidelity representation, data driven modeling, high-efficient emulation, multi-round pre-verification, and interactive mapping are key differences with other existing architectures. It can help realize efficient and cost effective data driven network management and accelerate network innovation. 

-        Technically, existing techniques or tools (YANG, xCONF, RPC, SNMP, Telemetry, etc.) is possible to help build a DTN system with low maturity, which can present or monitor the physical network. And, many other innovative techniques should be researched toward constructing a more mature DTN system with high-level capabilities (i.e. Data service, Twin modelling, Interactive mapping, Intelligence, Trustworthiness, etc. ). 

1)      From data perspective,  we collect topology data, KPI data, alarm data, incident data, how these data can be correlated at different layer in the layered twin network, how these data can be verified, simulated, what-if scenario looks like? How these data can be used to trigger network optimization.

2)      Regarding ‘network modeling’, data driven AI/ML models should be researched facing similar Network-AI challenges; and basic models for efficient policy pre-verification should also be studied, possible solutions can be simulation/emulation tools or via some other mathematic methods (e.g. formal methods for network verification) . And, YANG models probably require an evolution to accommodate or cooperate with other modeling mechanisms. 

3)      Regarding ‘real time synchronizing’, the real-time of interactive mapping includes timely information collection, timely analysis and processing, timely pre-verification and timely configuration delivery. NETCONF/YANG can help achieve timely configuration delivery. However, more real-time data collection still needs to rely on more new solutions (Telemetry, INT, In-Suit OAM, etc.). Fast twin-layer analysis and decision processing need efficient model reasoning abilities.

 

>From more replies, please check the inline texts on your original long mail. 

 

Any comments are welcome. 

 

Thanks and Best Regards,

Cheng Zhou 

 

 

-----Original Message-----
From: nmrg [mailto:nmrg-bounces@irtf.org] On Behalf Of Schwarz Albrecht (ETAS-DAP/XPC-Fe6)
Sent: Wednesday, March 8, 2023 1:43 AM
To: nmrg@irtf.org
Subject: Re: [nmrg] [draft-irtf-nmrg-network-digital-twin-arch] Digital twin = Management datastore

 

Dear all,

 

like to take the current DT discussion for the resumption of my indication from last year (see below).

 

The DT information models (for an xyz DT like a network DT) might be divided in multiple information modelling dimensions, typically

1. structural information model;

2. behavioural information model;

3. visual information model;

4. process lifecycle information model;

5. ...

 

IRTF NMRG deals with ICT systems from operations and management perspective.

Correspondent xyz DT information models comprise consequently primarily (1) and (4; lifecycle states according to e.g. ITU-T M3701).

 

Conclusions: 

* that's exactly the same information model scope as in charter of IETF NETCONF, NETMOD, ...;

* there's an exact match of a DT(1,4) information model with correspondent YANG models (and their aggregation in an xCONF management datastore)!

* any IRTF NMRG document on DTs should carry the message "= YANG" for that very DT core information models!

(sure, with all the underlying premises and conditions, but that proposition is very general in context of NMRG due to the type of the twinned real entity, which is normally a technical entity similar like physical or virtual, constrained or unconstrained  IoT devices ... up to an entire network)

 

I'm aware that draft-irtf-nmrg-network-digital-twin-arch-02 provides already first indications to YANG, but the justification might be more explicit, or even a recommendation that YANG is the NRMG DT preferred DT data/information modelling language.

 

My thoughts on that topic,

regards,

Albrecht

 

 

 

Dr. Albrecht Schwarz

Systems Engineer

 

T +49 711 3423-2380

M +49 173 979 2632

Albrecht.Schwarz@etas.com

 

ETAS GmbH, ETAS-DAP/XPC-Fe6

Borsigstraße 24, 70469 Stuttgart, Germany

www.etas.com

 

ETAS – Empowering Tomorrow’s Automotive Software

 

Managing Directors: Dr. Thomas Irawan, Mariella Minutolo, Götz Nigge

Chairman of the Supervisory Board: Dr. Walter Schirm

Registered Office: Stuttgart, Registration Court: Amtsgericht Stuttgart, HRB: 19033

-----Original Message-----

From: nmrg <nmrg-bounces@irtf.org> On Behalf Of Schwarz Albrecht (ETAS-DAP/XPC-Fe6)

Sent: 26 July 2022 17:38

To: nmrg@irtf.org

Subject: [nmrg] [draft-irtf-nmrg-network-digital-twin-arch] Digital twin = Management datastore

 

Dear all,

 

just reviewed your draft "Digital Twin Network: Concepts and Reference Architecture", - without knowing the discussion history from the past.

 

On a first glance, I'm wondering actually what's really new to be proposed?

Is this just an academic and research type of discussion?

[Cheng Zhou] This draft is to apply Digital Twin technology in the networking field so as to develop various rich network applications and realize efficient and cost effective data driven network management and accelerate network innovation. This discussion is firstly of research type. After get more consensus, we think it will have industrial value to help achieve autonomous network management.  

 

Quoting NMRG charter:

“ The Network Management Research Group (NMRG) provides a forum for

researchers to explore new technologies for the management of the Internet.

In particular, the NMRG will work on solutions for problems that are not

yet considered well understood enough for engineering work within the IETF.”

You will see NMRG focuses on research topic or solution that is not well understood by IETF, digital twin network architecture fit into the scope of NMRG.

Also as we know digital twin technology has been widely applied in Industry 4.0 field, but how does this technology can be used in the network field such as data center network, operator’s network,  how data driven approach can be used to improve the network management, without manual involvement, in the meanwhile reduce trial cost is still a challenging issue.

 

Some feedback from the industry (not from academic side):

 

Digital representations of physical entities are actually fully  identical to the managed entities in management architectures of distributed systems.

The managed entity is represented by a data model (managed object), the collection of a relevant information is subject of a management datastore (at the granularily level of twin entities)..

 

I) Technologies

All technologies are already available:

1) YANG as management data modelling language, covering all type of management services and its fundamental typological data categories of configuration data and operational state data.

Whether that datum/data is finally used as primary data, meta-data, etc (3GPP 32.156, RFC 8342, cl. 5.3.4) is subject of the semantical specification.

 

2) Concept of management datastores (RFC 8342) and datastore architectures capture all digital twin needs, e.g., by its datastore instances startup, running, operational state, etc

 

3) The synchronization of twins across a geographical distance, whether pure local, proximity based or remote could be simply achieved via management protocols.

The xCONF suite allows to address many industry domains:

- NETCONF for native twin management

- RESTCONF for web-based twin management

- CORECONF for constrained physical entities.

What's missing?

[Cheng Zhou] Thanks for the information. 

NETCONF/RESTCONF and YANG are enabler of network management automation, these technologies are mature enough and can be used to define telemetry interface, intent interface, management interface, however, how data can be aggregated, abstract, correlated within the digital twin network platform or analytics platform, these don’t need to be modelled using YANG, many other modelling technologies can be used.

Therefore for external interface, you can use NETCONF/RESTCONF/YANG, but for internal interface between components within digital twin platform, YANG is not required in most cases, more powerful other modelling technology can be used.

Technically, existing techniques or tools (YANG, xCONF, RPC, SNMP, Telemetry, etc.) can be used to build a DTN system. And, many other innovative techniques also need to be researched toward constructing a more mature DTN system with high-level capabilities (i.e. Data service, Twin modeling, Interactive mapping, Intelligence, Trustworthiness, etc. ), and also to meet the challenges discussed later.   

 

 

Would also to recommend for digital twin reference architectures in differentiation of multiple synchronization dimensions (in order to differentiate twin use cases in  more detail):

a) synchronization dimension "time": the management datastore at management manager level (= the "copy of the copied" twin) is timely synchronized with the management datastore at management agent level (= the "copied" twin) in various degrees (time scales, push or pull mode, etc)

b) synchronization dimension "content": ... a filtered, a subset view ...

c) synchronization dimension "semantic": the semantic information of the twin copy data might be semantically enhanced by consideration of additional contextual data, further meta-data All that synchronization dimensions could be inherently supported by the referred management architectures and technologies.

(And there seems to be further enhancements such as in OPSAWG, draft-claise-opsawg-collected-data-manifest ...).

[Cheng Zhou] Good point on synchronization, especially the dimension of ‘Semantic’. Actually, another draft ‘draft-zcz-nmrg-digitaltwin-data-collection’ is discussing the data collection requirements and methods for DTN. Surely, draft-claise-opsawg-collected-data-manifest can be one for the candidate tools on collecting some specific data.  

 

II) Reference architectures

Starting point are the well-known management architecture patterns as designed for distributed systems.

Whether of type IoT or non-IoT isn't a major aspect here.

E.g.,

ITU-T X.703 as basic reference model.

ITU-T Y.4500.1.

RFC 7426

SDNM (SW-defined Network Management)

-...

Recommended (in my view) for digital twin reference architectures = ITU-T Y.4702 as reference.

[Cheng Zhou] Quite valuable references. The ‘Device/Resource layer’ and ‘Application layer’ in RFC7426 or Y.4702 are similar as the ‘Physical Network layer’ and ‘Application layer’ in the network. The major difference for Digital Twin Network is that the ‘Digital Twin layer’ can represent the physical network in high fidelity, generate and pre-verify optimization policies,  and emulate/control the physical network in time. 

 

 

III) Services for digital twins

All services as identified by your draft could be mapped on basic (twin) management service categories, e.g., ITU-T Recs

    M.3700: Common management services - Object management - Protocol neutral requirements and analysis

    M.3701: Common management services - State management - Protocol neutral requirements and analysis

    M.3702: Common management services - Notification management - Protocol neutral requirement and analysis

    M.3703: Common management services - Alarm management – Protocol neutral requirements and analysis

    M.3704: Common management service - Performance management - Protocol neutral requirements and analysis

    M.3705: Common management services - Log management - Protocol neutral requirements and analysis

    M.3706: Common management services - Test Management - Protocol Neutral Requirements and Analysis

 

or similar specs. from other SDOs like the work on oneM2M.

[Cheng Zhou] The services in specs list above are common for network management systems. And some of the services, especially the data repository in twin layer can be mapped on basic  management service categories. However, as mentioned in the draft, the key difference compared to traditional network management systems is the interactive virtual-real mapping and data driven approaches to build closed-loop network automation. So, the services of basic models and functional models are unique services that are essential to build the digital twin system. 

 

IV) Challenges to Build Digital Twin Network Like to reply on your five indicated challenges under the assumption of reference architecture of digital twins and digital twin networks, based on

a) reference management architectures for distributed systems;

b) YANG as twin representation and twin data modelling language;

c) NETCONF (or ...) as "inter-twin communication and synchronization" protocol

 

With regards to:

1) Large scale challenge

Reply: scaling of large ..., i.e., big number of twins in parallel is essentially a key aspect of IoT architectures ("thousands of things assigned to a single manager").

Thus, the scalability item is covered in such reference architectures.

[Cheng Zhou] Agree. Large-scale network is not only the challenge of traditional network management system, but also the challenge of DTN system. For DTN system, more information and more types of user services should be twinned on the virtual network to improve the fidelity and accuracy of simulation. Therefore, the challenge of large model data processing under large-scale network will be greater.

 

2) Interoperability

Reply: Recommend your IRTF WG to reference to IEEE 2413 / IEC 61802 levels of compatibility, in order that you get a more fine granular interoperability model.

Here: the protocol (c) and data modelling language (b) are basically orthogonal, of course somehow coupled in case of YANG and xCONF.

However, just following (b) by using YANG as twin modelling language (and other protocols) allows to achieve the levels of interworkable and even interoperable.

[Cheng Zhou] Thanks for the valuable information. 

It is true that YANG and xCONF can help mitigate the challenge of interoperability. Some additional interoperability concerns are:

- Some new data collection methods (e.g. INT, Sketch based measurement, etc.) should be standardized.

- Interfaces between digital twin network and application should be either open-source or standardized.

- And it would be better if internal interfaces (e.g. between data repository and models) within digital twin network can be standardized. 

 

3) Data modeling difficulties

Reply: fail to see anyreal modeling issues in case in using YANG. The scope of a management data modelling language addresses exactly all the modelling aspects as required for twins.

[Cheng Zhou] YANG can help to obtain information about nodes, topology and configuration of the network. However, these are far from building mature twin networks. The models in the twin network need not only to support the network configuration and state presentation, but also to have the network function simulation, performance evaluation, and intelligent decision-making capabilities. This requires comprehensive use of various technologies for network modeling according to different network types and application requirements, including but not limited to YANG Model, simulation tool, mathematical abstraction method, AI algorithms, etc.

 

4) Real-time requirements

Reply: timing requirements of communication services are orthogonal to the communication protocol in use. Actually, "every" protocol could be operated at multiple time scales.

Here: management protocols can and are operated at the time-scale of twin realtime objectives.

Particularly notification management services (as required here).

Fault management and alarm reporting are realtime examples.

NETCONF supports that.

[Cheng Zhou] The real-time of interactive mapping includes timely information collection, timely analysis and processing, timely pre-verification and timely configuration delivery. NETCONF/YANG can help achieve timely configuration delivery. However, more real-time data collection still needs to rely on more new solutions (Telemetry, INT, In-Suit OAM, etc.). Fast twin-layer analysis and decision processing need efficient model reasoning ability.

 

5) Security risks

Reply: nothing special here,

Security architectures as overlay architectures for management architectures are rather the normal case (in ICT mandatory, in IT recommended) when the exception.

NETCONF and YANG security architectures incorporate ...

[Cheng Zhou] Compared with traditional network management architectures, digital twin network system is aiming to achieve more goals (analyze, diagnose, emulate, etc.) rather than ‘network manage’, then help promote intelligent capabilities of the network system. In this purpose, more data are required to build twin network, and more capabilities will be exposed to user. And this will inevitably increase the security risks of the whole system. 

 

V) Automation

Above outlined management reference architectures, as fully applicable for digital twin network reference architectures, are subject of ongoing automation. Fully concur.

The industry wants to move from manual-dominated management towards more and more automated management.

I would recommend that your draft checks

- tmforum IG1251 Autonomous Networks – Reference Architecture v1.0.0

- ETSI's Zeor-touch reference architecture (https://www.etsi.org/technologies/zero-touch-network-service-management)

- RFC 8969 (your RFC Mr Boucadair 😊)

 

All that said, I think there's a wealth of prior art and technologies available, just all the hundred pieces from the YANG and xCONF technology arena, that provide already everything as required for digital twin reference architectures.

Being aware that technology progress is still ongoing like in NETMOD, OPSAG (e.g., draft-claise-opsawg-collected-data-manifest ), ...

[Cheng Zhou] The core value and characteristics of Digital twin network are High-fidelity representation, data driven modeling, high-efficient emulation, multi-round pre-verification, and interactive mapping. DTN system’s maturity level varies with the capability of several dimensions including data service, twin modelling, interactive mapping, intelligence and Trustworthiness. As mentioned above, existing technologies can help build a DTN system with low maturity and low capabilities. To build a high maturity DTN system, many other innovative techniques also need to be researched.

 

The value of draft-irtf-nmrg-network-digital-twin-arch might be a mapping on existing reference management architectures.

The scope of draft-irtf-nmrg-network-digital-twin-arch could be even extended by not limiting on physical entities only, rather to cover also virtual entities in general (see e.g. ITU-T Y.2060), because management architectures cover both, physical and virtual entities as managed entities.

The result of digitalization and connectivity (as behind digital twins) leads to CPS (cyber-physical systems) whenever physical entities are considered. That's certainly the major scope of draft-irtf-nmrg-network-digital-twin-arch. However, nothing prevents a generalization in adding also pure cyber systems in my view.

[Cheng Zhou] Agree. The term 'Physical Network/Entity' seems not accurate enough to cover all network elements in 'physical space'. The 'network physical space' can include both physical entities and some virtual entities (e.g. vSwitches, NFVs, etc.), which together carry traffic and provide actual network services. 

We will consider rename the ‘Physical Network’ to ‘Real Entity' or 'Real Network Entity’.    

 

Any clarification by draft-irtf-nmrg-network-digital-twin-arch with regards to the aspect  that digital twins are neither architecturalyl nor technologically wise really new things might be beneficial in my view!

[Cheng Zhou]Just a summary with above clarifications:

-        DTN is conceptually and architecturally new by introducing Digital Twin technology in the networking field. High-fidelity representation, data driven modeling, high-efficient emulation, multi-round pre-verification, and interactive mapping are key differences with other existing architectures. It can help realize efficient and cost effective data driven network management and accelerate network innovation. 

-        Technically, existing techniques or tools (YANG, xCONF, RPC, SNMP, Telemetry, etc.) is possible to help build a DTN system with low maturity, which can present or monitor the physical network. And, many other innovative techniques should be researched toward constructing a more mature DTN system with high-level capabilities (i.e. Data service, Twin modelling, Interactive mapping, Intelligence, Trustworthiness, etc. ). 

 

 

Pleas excuse my finally rather long email.

Best regards,

Albrecht 

 

Dr. Albrecht Schwarz

Systems Engineer

 

T +49 711 3423-2380

M +49 173 979 2632

Albrecht.Schwarz@etas.com

 

ETAS GmbH, ETAS-DAP/XPC-Fe6

Borsigstraße 24, 70469 Stuttgart, Germany www.etas.com

 

ETAS – Empowering Tomorrow’s Automotive Software

 

Managing Directors: Christoph Hartung, Günter Gromeier, Götz Nigge Chairman of the Supervisory Board: Dr. Walter Schirm Registered Office: Stuttgart, Registration Court: Amtsgericht Stuttgart, HRB: 19033 _______________________________________________

nmrg mailing list

nmrg@irtf.org

https://www.irtf.org/mailman/listinfo/nmrg