Internet DRAFT - draft-janz-nmrg-performance-digital-twin
draft-janz-nmrg-performance-digital-twin
Network Management Research Group C. Janz
Internet-Draft Y. You
Intended status: Informational Huawei Canada
Expires: 15 September 2023 A. Guo
Futurewei Technologies
14 March 2023
Functional Design Aspects of Performance-Oriented Digital Twins
draft-janz-nmrg-performance-digital-twin-00
Abstract
Performance-Oriented Digital Twins (PODTs) provide "what-if" analysis
- predictions of performance or, perhaps, of other behaviours in
hypothetical situations of network, services, traffic, etc. Key
functional and design aspects of PODTs in support of multiple,
concurrently-operating use case Management Plane (MP) applications
are discussed. Data and model management in concurrent session
handling, inter-working with variable composition (from data and
functional model perspectives) networks, performance and scalability
are considered.
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 15 September 2023.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
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.
Janz, et al. Expires 15 September 2023 [Page 1]
Internet-Draft Performance-Oriented Digital Twins March 2023
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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Data and Model Management Supporting Concurrent Scenario-Based
Computational Sessions . . . . . . . . . . . . . . . . . 4
4. Data and Model Management Supporting Differences and Evolutions
in MP Applications and Physical Networks . . . . . . . . 6
5. Performance-Related Functional Design Aspects . . . . . . . . 8
6. Functional Design Implications of NDT Functional Extension
Beyond Analysis . . . . . . . . . . . . . . . . . . . . . 9
7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 10
8. Manageability Considerations . . . . . . . . . . . . . . . . 10
9. Security Considerations . . . . . . . . . . . . . . . . . . . 10
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
11. Informative References . . . . . . . . . . . . . . . . . . . 10
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
A Network Digital Twin (NDT) - also referred to as a Digital Network
Twin (DNT) - is a virtual replica of a real network (often referred
to as a 'physical' network) that faithfully mimics the behaviours of
the real network [I-D.draft-zhou-nmrg-digitaltwin-network-concepts].
Its role may be limited to synthesizing behavioural information, such
as performance predictions, for consumption by other MP functions;
such analytical Performance-Oriented Digital Twins (PODTs) are
considered in [I-D.draft-paillisse-nmrg-performance-digital-twin].
Alternatively, the NDT may be held to encompass further management
functions, such as closed loop components beyond data analysis, and
thus to exercise active control over the physical network, services,
etc. In such cases, the functional equivalent of a PODT lies at the
heart of the NDT. Therefore, this draft focuses discussion on PODTs;
considerations related to functional extension of the NDT role,
beyond an analytical one, are considered in Section 6.
In [I-D.draft-paillisse-nmrg-performance-digital-twin], PODT
implementation challenges and certain implementation options -
especially concerning key functional models - are discussed, as are
required interfaces and related standards (Sections 4 and 7 of the
reference, respectively). This draft looks not at details of models
Janz, et al. Expires 15 September 2023 [Page 2]
Internet-Draft Performance-Oriented Digital Twins March 2023
or interfaces but rather at general aspects of functional design.
Several functional design principles are considered that may apply
generically to PODTs.
One such functional design principle is based on the fact that the
behavioural or performance prediction information, synthesized from
data by a particular PODT, may be used by multiple use case-based MP
applications, and these applications may - usefully - operate
concurrently. What is different among such applications - or even
among successive predictions sought by a single application - is not
the nature of the behavioural or performance information yielded.
The difference lies, rather, in the details of the scenarios for
which prediction information is sought. A PODT supporting multiple
concurrent MP functions and applications requires careful handling of
data and modeling to accommodate differences in scenario-driven data
used in (what amount to) parallel - or at least, different -
computational sessions. This aspect is considered in Section 3.
Another important functional design principle is related to the fact
that, in practice, there are likely to be - among real network
instances for which use of the PODT is desired, or with respect to
evolutions of a given real network instance over time - considerable
variations in network details, including network size, equipment
types used, available instrumentation or other data sources, etc.
Additionally, differences among MP applications, in terms of the
nature and degree of hypotheticals involved in the scenarios they
generate for performance prediction, may also drive variations in
data types, availability, precision, etc. As a practical matter, a
PODT should be able to accommodate such variations, while
consistently providing the best possible scenario-based performance
predictions in support of all MP applications. This, too, has
implications for data and model management. This aspect is
considered in Section 4.
Finally, supporting multiple, concurrently operating MP applications
- many of which (e.g. optimization-related applications) may require
performance prediction on large numbers of different, detailed
scenarios - requires high-performance PODT implementations. Models
may be more or less complicated and computationally intensive; data
consumed may be considerable and run to large archived volumes over
time. Performance and scalability considerations are discussed in
Section 5.
2. Terminology
* Network Digital Twin (NDT): a virtual replica of a real network
(often referred to as a 'physical' network) that faithfully mimics
the behaviours of the real network.
Janz, et al. Expires 15 September 2023 [Page 3]
Internet-Draft Performance-Oriented Digital Twins March 2023
* Digital Network Twin (DNT): an alternative term for NDT.
* Performance-Oriented Digital Twin (PODT): An analytical NDT
generates performance-oriented information based on "what-if"
scenarios specified by other Management Plane applications.
* Optical Performance Digital Twin (OPDT): A PODT that generates
optical transmission performance predictions.
3. Data and Model Management Supporting Concurrent Scenario-Based
Computational Sessions
That multiple use case-based MP applications may rely on the same
PODT-based analytical function and information that it synthesizes,
is illustrated in
[I-D.draft-paillisse-nmrg-performance-digital-twin]: for greater
simplicity and coherence, what follows refers specifically to the use
cases associated with the Optical Performance Digital Twin (OPDT)
that are described in that reference (Section 6). However, as
discussed in the reference, several of these use cases have generic
counter-parts (i.e. are applicable to networks other than optical
transmission networks) and, additionally, further use case categories
are considered.
With respect to OPDTs,
[I-D.draft-paillisse-nmrg-performance-digital-twin] describes the
following use cases:
(1) Optical service (re-)provisioning
(2.a) Optical service/network risk planning
(2.b) Optical service/network dynamic restoration planning
(3) Optical service planning
(4) Optical network planning (incremental/brown field to green field)
(5) Optical services/network optimization
Note that: (1) describes an active operation undertaken on deployed
and operating optical networks, potentially in an automation or semi-
automation context; (2.a) and (2.b) describe potentially coupled
analysis & planning operations that may be undertaken periodically or
on an event-driven basis on deployed and operating optical networks,
potentially in an automation or semi-automation context; (3)
describes a planning operation, that may be undertaken periodically
or on an event-driven basis on deployed and operating optical
networks, potentially in an automation or semi-automation context;
Janz, et al. Expires 15 September 2023 [Page 4]
Internet-Draft Performance-Oriented Digital Twins March 2023
(4) describes a planning operation, relevant to either deployed and
operating optical networks or to hypothetical future optical
networks. In either context, optical service planning (3) may be an
'embedded' function; (5) describes an 'embedded' function used in
support of (2) through (4).
All of these use cases may be handled by MP applications that rely on
the same OPDT - or at least the same type and style of OPDT -
generating the same type and format of transmission performance
information (predictions) from the same fundamental data, using
fundamentally the same models. The differences consist in the
detailed sourcing of data - in particular, between real network and
service data and postulated, hypothetical data - and in the detailed
usage of models. For example, the OPDT-based modeling implicated in
cases (1) and (3) above involves performance, status and other data
strictly from the network as-deployed and operating, but also
involves at least partly hypothetical postulated optical service
states. On the other hand, the OPDT-based modeling implicated in
cases (2) and (4) involves performance, equipment specification and
status, and other network data that is at least partly (and may be
wholly - e.g. green field planning) hypothetical, as well as at least
partly (and potentially wholly) hypothetical optical service states.
All of these applications, and especially the potentially embedded
application case (5), furthermore involve some degree of sequential
or parallel presentation of multiple, partly differing scenarios for
performance prediction.
Accommodating these realities requires (ideally) concurrent operation
of multiple, scenario-based computational 'sessions', requiring
careful management of the different data sets and models involved in
each, as well as of their differing life cycles. Note that whether a
given implementation is better described as operating concurrent
sessions of the same OPDT, or as concurrently operating multiple OPDT
instances of the same type, is largely a distinction without a
meaningful difference for purposes of this discussion.
OPDT (or, more broadly, PODT) computational sessions - in the sense
just described - thus make use of network, service and other data
that generally only partly map to current (or historical) data from
the real twin. However, that 'real' data must remain accessible to
every session and uncorrupted by the partial substitution of real
data with hypothetical data occurring differentially in each session,
while being continuously updated and kept current with new data from
the real network, management and control systems, etc. There are
different implementation methods available to achieve this, but
careful design and implementation is critical.
Janz, et al. Expires 15 September 2023 [Page 5]
Internet-Draft Performance-Oriented Digital Twins March 2023
Different PODT computational sessions also generally involve
different detailed functional model compositions. First, scenarios
may involve additions to, deletions from, or other modifications to
the set of deployed equipment or other elements, changes in
connection configurations, etc. Where network functional models are
generated through composition from atomic equipment or element
instances and their related models, differential network model
composition by scenario-based session is clearly required. Second,
details of functional models invoked may differ depending on whether
the counter-part to the digital instance is real - i.e. deployed and
potentially operating - or hypothetical. For example, in the case of
OPDTs, the important erbium-doped fibre amplifier (EDFA) network
element is a critical focal point for functional modeling. According
to [EDFA1], such functional models may be - in increasing order of
accuracy and precision - generic, type-specific but instance-generic,
or both type-and instance-specific. Where the scenario-based network
is fully deployed and operational, the latter models may be available
and will yield more accurate performance predictions than the
alternatives; whereas if the scenario-based network is entirely
hypothetical (e.g. green field planning) then only type-specific
models may be available (and would be preferred to generic models).
This issue will be re-visited in Section 4.
Finally, scenario-based computational session life cycles must be
managed. Such sessions may be short-lived, e.g. seeking one-time
"what-if" scenario-based predictions; or, they may be long-lived,
e.g. seeking continuous generation of prediction data as real twin-
sourced data evolves. MP application consumers of PODT-generated
information control these life cycles, but PODT implementations must
be equipped to manage them.
4. Data and Model Management Supporting Differences and Evolutions in
MP Applications and Physical Networks
In practical application, PODTs are likely to be required to operate
in conjunction with real networks that vary in a number of ways,
including network size, specific equipment types involved, available
instrumentation or other data sources, types and quality, etc.
Additionally, as discussed in Section 3, differences among MP
applications - in terms of the nature and degree of hypotheticals
involved in the scenarios they generate for performance prediction -
may also drive variations in data types, availability, precision,
etc. PODTs should be able to accommodate these variations, while
always providing the best possible scenario-based performance
predictions. This has implications for both session-based functional
model management and data management.
Janz, et al. Expires 15 September 2023 [Page 6]
Internet-Draft Performance-Oriented Digital Twins March 2023
As a rule, the network functional models 'composed' for each MP
application-driven PODT computational session, should make use of the
most accurate atomic functional models available and usable under the
circumstances. For example, as discussed in Section 3, better
functional models may be available when a given network element is
deployed and operating - its type and potentially instance-specific
information thus being known - than when it is a hypothetical
element, in which case, only generic or type-specific models may be
available. Further, a real network may include equipment types for
which type- and instance-specific models are not available; in such
cases, generic models must be used, or a selection made from type-
specific models thought to best represent the behaviours of the real
equipment in question.
Available data to 'feed' functional models may also vary according to
circumstances of both real network and MP application-driven
scenarios. Functional models and available data should be used in
flexible combination to deliver the best possible performance
predictions under all circumstances. This idea may be illustrated
with an example based on optical transmission networks and OPDTs.
Channel input powers to the various optical amplifiers in the network
represent important input data to amplifier functional models. If a
given modeled amplifier is deployed and operating, then channel input
powers - for channels currently operating - may possibly be measured
on the real network directly at amplifier inputs. If such
measurements are not available, or the optical service channel in
question is only a hypothetical, prospective channel, or if the
scenario for modeling includes other hypothetical changes to the
network or service configuration or state; then alternatives must be
sought. For example, if optical fibre link losses are accurately
known at proximate channel wavelengths, they may be used in
conjunction with measured or modeled channel powers at upstream
points to estimate amplifier ingress powers. Note that fibre link
losses may have been obtained by direct or indirect measurement -
meaning, in the latter case, inferred from available data (e.g. fibre
link input and output powers on proximate operating channel
wavelengths). Finally, if fibre link losses are not accurately known
- for example, in brown or green field planning scenarios, such data
may not be available in respect of prospective incremental or new
fibre plant - default loss coefficients and hypothesized fibre link
lengths may be used to generate fibre link loss estimations.
Again: functional models and available data should be used in
flexible combination to deliver the best possible performance
predictions under all circumstances. Increased 'instrumentation' of
the real network - scope and quality of relevant data generation -
reduces the scope and degree of required modeling and leads to
improved performance prediction results, but modeling may generally
Janz, et al. Expires 15 September 2023 [Page 7]
Internet-Draft Performance-Oriented Digital Twins March 2023
be used in combination with available data to close 'gaps' in such
instrumentation. In respect of any needed input data to elements of
session-based composed network functional models, a 'preference
hierarchy' of data, and sources of data, may be established a priori
and used in operation. For example, considering the case of the
prior paragraph: if directly measured channel input power is
available, use it; if not, and if measured proximate channel fibre
link losses have been directly measured, use them; if not, use
default loss coefficient for the posited fibre type and length. Data
'tables' may be dynamic and built up through increasing measurement
experience, and even PODT-based functional modeling experience, with
respect to a given real or (partly) hypothetical network. Increasing
effective data quality may thus yield improvements in performance
prediction quality over time - over and above the impacts of any
experience-driven improvement to functional models.
It should also be noted that flexible conjoint use of data and models
may yield ways to verify the accuracy of data and models, through
'prediction of measurables' - i.e. using modeling to generate data
which is in fact directly measurable or available on the real
network. For example, fibre link losses or channel power
measurements may be used to 'predict' - i.e., to use functional
models to calculate - the optical signal to noise ratio of an
operating channel at each point in an amplified transmission span.
If such ratios are in fact directly measured by available network
instrumentation, then the measured and 'modeled' values, in respect
of operating optical service channels, may be compared. Differences
may be due to either data/measurement inaccuracies, functional model
accuracy limitations, or both. Where functional models have been
established to be accurate, discrepancies may indicate variations in
data - assumed or measured vs. 'actual' - that may prove useful in
e.g. 'soft fault' detection, classification or localization.
5. Performance-Related Functional Design Aspects
The support of multiple, concurrently operating MP applications -
many of which (e.g. optimization-related applications) may require
performance prediction on large numbers of different, detailed
scenarios - requires high-performance PODT implementations.
Functional models themselves may be more or less complicated and
computationally-intensive, and data consumed may be considerable and
run to large archive volumes over time.High-performance data
collection methodologies are considered in
[I-D.draft-zcz-nmrg-digitaltwin-data-collection]. Data comes from
other MP applications e.g. network or service configuration, from
managed entities - the real network - or from the real network
through MP applications.
Janz, et al. Expires 15 September 2023 [Page 8]
Internet-Draft Performance-Oriented Digital Twins March 2023
Various techniques can be used to support high-performance PODT to
support functional design and implementation. The common idea is to
split functional modeling into smaller tasks. Such tasks can be of
two types: having dependencies on other tasks, or independent of
other tasks. Independent tasks can be assigned to different compute
resources (workers), and executed in parallel:
* In an embedded system, a multiple worker-thread strategy can be
used to support high performance;
* On a server-based platform, a PODT may run under a microservices
architecture, with workers located in difference processors or on
different servers depending on the size and complexity of the
emulated network. These distributed computing systems can greatly
improve performance and support complex functional modeling of
large-scale networks and concurrent sessions supporting multiple
MP applications.
* Processors on real network elements can serve as distributed
worker resources as well, performing functional modeling tasks
directly related to them, and easy computational requirements on
server-based platforms.
Dependent tasks need orchestration to schedule, synchronize and
dispatch compute requests to tasks. Stream processing framework -
like Kafka - are effective frameworks to support this.
6. Functional Design Implications of NDT Functional Extension Beyond
Analysis
As described in Section 1 (and in e.g.
[I-D.draft-zhou-nmrg-digitaltwin-network-concepts]), some functional
conceptions of NDTs extend beyond the analytical function of PODTs to
encompass further management functions, such as closed loop
components extending to decision and action. Such NDTs may thus
exercise active control over the real network, service
configurations, etc.
However, in such cases, the functional equivalent of a PODT lies at
the heart of the NDT - i.e. representing the data and analysis
closed loop components. Therefore, the PODT-specific functional
design aspects considered in this document may be considered to apply
to NDTs broadly, with the qualification that what amount to the MP
applications driving and using the functional equivalent of PODTs -
in the manner described in this document - are partly or wholly
encompassed within the functional perimeter of the NDT.
Janz, et al. Expires 15 September 2023 [Page 9]
Internet-Draft Performance-Oriented Digital Twins March 2023
7. Conclusion
PODTs represent an important class of NDTs in their own right, and
their functional equivalent lies at the heart of NDTs with active
network-driving capabilities. The 'what-if' scenarios analyzed by
PODTs are generated by various use case-oriented MP applications.
Information and model management among concurrent computational
sessions, driven by such MP applications, is thus an important
functional design concern. Also important is information and model
management to accommodate variations and evolutions among real
network co-operating with PODTs. Functional design for high and
scalable operational performance is a further important functional
design criterion.
8. Manageability Considerations
TBD
9. Security Considerations
TBD
10. IANA Considerations
This document requires no IANA actions.
11. Informative References
[EDFA1] You, Y., Jiang, Z., and C. Janz, "Machine Learning-Based
EDFA Gain Model",
Web https://doi.org/10.1109/ECOC.2018.8535397, September
2018.
[I-D.draft-paillisse-nmrg-performance-digital-twin]
Paillisse, J., Almasan, P., Ferriol, M., Barlet, P.,
Cabellos, A., Xiao, S., Shi, X., Cheng, X., Janz, C., Guo,
A., Perino, D., Lopez, D., and A. Pastor, "Performance-
Oriented Digital Twins for Packet and Optical Networks",
Work in Progress, Internet-Draft, draft-paillisse-nmrg-
performance-digital-twin-01, 24 October 2022,
<https://datatracker.ietf.org/doc/html/draft-paillisse-
nmrg-performance-digital-twin-01>.
Janz, et al. Expires 15 September 2023 [Page 10]
Internet-Draft Performance-Oriented Digital Twins March 2023
[I-D.draft-zcz-nmrg-digitaltwin-data-collection]
Zhou, C., Chen, D., Martinez-Julia, P., and Q. Ma, "Data
Collection Requirements and Technologies for Digital Twin
Network", Work in Progress, Internet-Draft, draft-zcz-
nmrg-digitaltwin-data-collection-02, 12 March 2023,
<https://datatracker.ietf.org/doc/html/draft-zcz-nmrg-
digitaltwin-data-collection-02>.
[I-D.draft-zhou-nmrg-digitaltwin-network-concepts]
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-zhou-nmrg-digitaltwin-
network-concepts-07, 5 March 2022,
<https://datatracker.ietf.org/doc/html/draft-zhou-nmrg-
digitaltwin-network-concepts-07>.
Acknowledgments
TBD
Authors' Addresses
Christopher Janz
Huawei Canada
Email: christopher.janz@huawei.com
Yuren You
Huawei Canada
Email: yuren.you@huawei.com
Aihua Guo
Futurewei Technologies
Email: aihuaguo.ietf@gmail.com
Janz, et al. Expires 15 September 2023 [Page 11]
