summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc9316.txt
blob: 3d4e46321a355b0f15454fc643c085bc81aad396 (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592
1593
1594
1595
1596
1597
1598
1599
1600
1601
1602
1603
1604
1605
1606
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624
1625
1626
1627
1628
1629
1630
1631
1632
1633
1634
1635
1636
1637
1638
1639
1640
1641
1642
1643
1644
1645
1646
1647
1648
1649
1650
1651
1652
1653
1654
1655
1656
1657
1658
1659
1660
1661
1662
1663
1664
1665
1666
1667
1668
1669
1670
1671
1672
1673
1674
1675
1676
1677
1678
1679
1680
1681
1682
1683
1684
1685
1686
1687
1688
1689
1690
1691
1692
1693
1694
1695
1696
1697
1698
1699
1700
1701
1702
1703
1704
1705
1706
1707
1708
1709
1710
1711
1712
1713
1714
1715
1716
1717
1718
1719
1720
1721
1722
1723
1724
1725
1726
1727
1728
1729
1730
1731
1732
1733
1734
1735
1736
1737
1738
1739
1740
1741
1742
1743
1744
1745
1746
1747
1748
1749
1750
1751
1752
1753
1754
1755
1756
1757
1758
1759
1760
1761
1762
1763
1764
1765
1766
1767
1768
1769
1770
1771
1772
1773
1774
1775
1776
1777
1778
1779
1780
1781
1782
1783
1784
1785
1786
1787
1788
1789
1790
1791
1792
1793
1794
1795
1796
1797
1798
1799
1800
1801
1802
1803
1804
1805
1806
1807
1808
1809
1810
1811
1812
1813
1814
1815
1816
1817
1818
1819
1820
1821
1822
1823
1824
1825
1826
1827
1828
1829
1830
1831
1832
1833
1834
1835
1836
1837
1838
1839
1840
1841
1842
1843
1844
1845
1846
1847
1848
1849
1850
1851
1852
1853
1854
1855
1856
1857
1858
1859
1860
1861
1862
1863
1864
1865
1866
1867
1868
1869
1870
1871
1872
1873
1874
1875
1876
1877
1878
1879
1880
1881
1882
1883
1884
1885
1886
1887
1888
1889
1890
1891
1892
1893
1894
1895
1896
1897
1898
1899
1900
1901
1902
1903
1904
1905
1906
1907
1908
1909
1910
1911
1912
1913
1914
1915
1916
1917
1918
1919
1920
1921
1922
1923
1924
1925
1926
1927
1928
1929
1930
1931
1932
1933
1934
1935
1936
1937
1938
1939
1940
1941
Internet Research Task Force (IRTF)                                C. Li
Request for Comments: 9316                                 China Telecom
Category: Informational                                         O. Havel
ISSN: 2070-1721                                                A. Olariu
                                                     Huawei Technologies
                                                       P. Martinez-Julia
                                                                    NICT
                                                                J. Nobre
                                                                   UFRGS
                                                                D. Lopez
                                                         Telefonica, I+D
                                                            October 2022


                         Intent Classification

Abstract

   Intent is an abstract, high-level policy used to operate a network.
   An intent-based management system includes an interface for users to
   input requests and an engine to translate the intents into the
   network configuration and manage their life cycle.

   This document mostly discusses the concept of network intents, but
   other types of intents are also considered.  Specifically, this
   document highlights stakeholder perspectives of intent, methods to
   classify and encode intent, and the associated intent taxonomy; it
   also defines relevant intent terms where necessary, provides a
   foundation for intent-related research, and facilitates solution
   development.

   This document is a product of the IRTF Network Management Research
   Group (NMRG).

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Research Task Force
   (IRTF).  The IRTF publishes the results of Internet-related research
   and development activities.  These results might not be suitable for
   deployment.  This RFC represents the consensus of the Network
   Management Research Group of the Internet Research Task Force (IRTF).
   Documents approved for publication by the IRSG are not candidates for
   any level of Internet Standard; see Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   https://www.rfc-editor.org/info/rfc9316.

Copyright Notice

   Copyright (c) 2022 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.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.

Table of Contents

   1.  Introduction
     1.1.  Research Activities
     1.2.  Standards and Open-Source Activities
     1.3.  Scope
   2.  Abbreviations
   3.  Definitions
   4.  Abstract Intent Requirements
     4.1.  What is intent?
     4.2.  Intent Solutions and Intent Users
     4.3.  Benefits of Intents for Different Stakeholders
     4.4.  Intent Types That Need to Be Supported
   5.  Functional Characteristics and Behavior
     5.1.  Abstracting Intent Operation
     5.2.  Intent User Types
     5.3.  Intent Scope
     5.4.  Intent Network Scope
     5.5.  Intent Abstraction
     5.6.  Intent Life Cycle
     5.7.  Autonomous Driving Levels
   6.  Intent Classification
     6.1.  Intent Classification Methodology
     6.2.  Intent Taxonomy
     6.3.  Intent Classification for Carrier Solution
       6.3.1.  Intent Users and Intent Types
       6.3.2.  Intent Categories
       6.3.3.  Intent Classification Example
     6.4.  Intent Classification for Data Center Network Solutions
       6.4.1.  Intent Users and Intent Types
       6.4.2.  Intent Categories
       6.4.3.  Intent Classification Example
     6.5.  Intent Classification for Enterprise Solution
       6.5.1.  Intent Users and Intent Types
       6.5.2.  Intent Categories
   7.  Conclusions
   8.  Security Considerations
   9.  IANA Considerations
   10. Informative References
   Acknowledgments
   Contributors
   Authors' Addresses

1.  Introduction

   The vision of intent-based networks has attracted a lot of attention
   because it promises to simplify the management of networks by human
   operators.  This is done by simply specifying what should happen on
   the network without giving any instructions on how to do it.  This
   promise caused many researcher-led activities and telecom companies
   to start researching this new vision and many Standards Development
   Organizations (SDOs) to propose different intent frameworks.

   This document proposes an intent classification methodology and an
   intent taxonomy.  The scope of these proposals is to ensure a common
   understanding in the research community in terms of what the intent
   users, intent types, or intent solutions, etc., are for specific
   scenarios that are being considered.

   The document represents the consensus of the Network Management
   Research Group (NMRG).  It has been reviewed extensively by the
   Research Group (RG) members who are actively involved in the research
   and development of the technology covered by this document.  It is
   not an IETF product and is not a standard.

1.1.  Research Activities

   Intent-based networking is an active research topic spanning across
   different areas that could benefit from an intent classification and
   taxonomy.

   Some examples include:

   *  intent expression and recognition ([Bezahaf21], [Bezahaf19],
      [Jacobs18]).  The use of a common classification could provide
      consistency in the understanding of the various forms of intent
      expressions being proposed and investigated.

   *  the orchestration of cognitive autonomous radio access networks
      (RANs) [Banerjee21] where intents are classified based on their
      content.

   *  intent network verification [Tian19], where the authors are
      working to propose new intent language.

   Furthermore, this document is already proving to be extremely
   relevant to the research community as it has been used as the basis
   for proposing self-generated Intent-based systems [Bezahaf19], for
   advancing Virtual Network Function (VNF) placement solutions based on
   Internet-Based Networks (IBNs) that rely on defining user intent
   profiles corresponding to abstract network services [Leivadeas21],
   for improving existing solutions in provisioning intent-based
   networks, for proposing new approaches to service management
   [Davoli21], and even for defining grammars for users to specify the
   high-level requirements for blockchain selection in the form of
   intent [Padovan20].  As well, the document has been mentioned in
   surveys addressing the topic of intelligent intent-based autonomous
   networks [Mehmood21] [Szilagyi21].

   This document also describes an example on how this proposal has been
   successfully applied in an academic environment [POC-IBN] by
   researchers in the area of Software-Defined Networking / Network
   Function Virtualization (SDN/NFV) for defining the scope of their
   project.  The specific problem addressed by researchers is how to
   apply intent concepts at different levels that correspond to
   different stakeholders.

   The IEEE Communications Society Technical Committee on Network
   Operation and Management (IEEE-CNOM), IRTF Network Management
   Research Group, and IFIP WG6.6 have developed a taxonomy for network
   and service management [IFIP-NSM] that is used by the research
   community in network management and operations to structure the
   research area through a well-defined set of keywords and to improve
   quality of reviews in submissions to journals, conferences, and
   workshops.  The proposed intent taxonomy may be contributed as an
   extension to this taxonomy for intent-driven management.

1.2.  Standards and Open-Source Activities

   Several SDOs and open-source projects, such as the IRTF NMRG, Open
   Networking Foundation (ONF) [ONF] / Open Network Operating System
   (ONOS) [ONOS], European Telecommunications Standards Institute (ETSI)
   / Experiential Networked Intelligence (ENI), and TMF with its
   autonomous networks, have proposed intents for defining a set of
   network operations to execute in a declarative manner.

   More recently, the IRTF NMRG is working on "Intent-Based Networking -
   Concepts and Definitions" [RFC9315].  This document clarifies the
   concept of "Intent" and provides an overview of the functionality
   that is associated with it.  The goal is to contribute towards a
   common and shared understanding of terms, concepts, and functionality
   that can be used as the foundation to guide further definition of
   associated research and engineering problems and their solutions.

   The present document, together with [RFC9315], aims to become the
   foundation for future intent-related topic discussions regarding the
   NMRG.

   The SDOs usually come up with their own way of specifying an intent
   and their own understanding of what an intent is.  Additionally, each
   SDO defines a set of terms and level of abstraction, its intent
   users, and the applications and usage scenarios.

   However, most intent approaches proposed by SDOs share the same
   features:

   *  It must be declarative in nature, meaning that an intent user
      specifies the goal on the network without specifying how to
      achieve that goal.

   *  It must be vendor agnostic in the sense that it abstracts the
      network capabilities or the network infrastructure from the intent
      user, and it can be ported across different platforms.

   *  It must provide an easy-to-use interface, which simplifies the
      interaction of the intent users with the intent system through the
      usage of familiar terminology or concepts.

   *  It should be able to detect and resolve intent conflicts, which
      include, for example, static (compile-time) conflicts and dynamic
      (run-time) conflicts.

1.3.  Scope

   The focus of this document is on the definition of criteria enabling
   the categorization of intents from viewpoint of the stakeholders.
   Concepts and definitions related to IBN are provided in [RFC9315].

   This document mostly addresses intents in the context of network
   intents; however, other types of intents are not excluded, as
   presented in Sections 4.4 and 6.2.

   It is impossible to fully differentiate intents only by the common
   characteristics followed by concepts, terms, and intentions.  This
   document clarifies what an intent represents for different
   stakeholders through a classification on various dimensions, such as
   solutions, intent users, and intent types.  This classification
   ensures common understanding among all participants and is used to
   determine the scope and priority of individual projects, proof of
   concepts (PoCs), research initiatives, or open-source projects.

   The scope of intent classification in this document includes
   solutions, intent users, and intent types; the initial classification
   table is made according to this scope.  The methodology presented can
   be used to update the classification tables by adding or removing
   different solutions, intent users, or intent types to cater to future
   scenarios, applications, or domains.

2.  Abbreviations

   AI:  Artificial Intelligence

   CE:  Customer Equipment

   CFS:  Customer Facing Service

   CLI:  Command-Line Interface

   DB:  Database

   DC:  Data Center

   ECA:  Event Condition Action

   GBP:  Group-Based Policy

   GPU:  Graphics Processing Unit

   IBN:  Intent-Based Network

   NFV:  Network Function Virtualization

   O&M:  OAM & Maintenance

   ONF:  Open Networking Foundation

   ONOS:  Open Network Operating System

   PNF:  Physical Network Function

   QoE:  Quality of Experience

   RFS:  Resource Facing Service

   SDO:  Standards Development Organization

   SD-WAN:  Software-Defined Wide-Area Network

   SLA:  Service Level Agreement

   SUPA:  Simplified Use of Policy Abstractions

   VM:  Virtual Machine

   VNF:  Virtual Network Function

3.  Definitions

   A common and shared understanding of terms and definitions related to
   IBN is provided in [RFC9315] as follows:

   Intent:  A set of operational goals (that a network should meet) and
      outcomes (that a network is supposed to deliver) defined in a
      declarative manner without specifying how to achieve or implement
      them.

   Intent-Based Network:  A network that can be managed using intent.

   Policy:  A set of rules that governs the choices in behavior of a
      system.

   Intent User:  A user that defines and issues the intent request to
      the intent-based management system.

   Other definitions relevant to this document, such as intent scope,
   intent network scope, intent abstraction, intent abstraction, and
   intent life cycle are available in Section 5.

4.  Abstract Intent Requirements

   In order to understand the different intent requirements that would
   drive intent classification, we first need to understand what intent
   means for different intent users.

4.1.  What is intent?

   The term "Intent" has become very widely used in the industry for
   different purposes; sometimes its use is not even in agreement with
   SDO-shared principles mentioned in Section 1.  [RFC9315] brings
   clarification with relation to what an intent is and how it
   differentiates from policies and services.

   Different stakeholders have different perspectives of the network;
   therefore, they have different intent requirements.  Their intent is
   sometimes technical, non-technical, abstract, or technology specific.
   Therefore, it is important to start a discussion in the industry and
   academic communities about what intent is for different solutions and
   intent users.  It is also imperative to try to propose some intent
   categories/classifications that could be understood by a wider
   audience.  This would help us define intent interfaces, domain-
   specific languages, and models.

4.2.  Intent Solutions and Intent Users

   Intent types are defined by all aspects that are required to profile
   different requirements to easily distinguish between them.  However,
   in order to facilitate a clustered classification, we can focus on
   two aspects: the solution and intent user.  They can be considered to
   be the main keys to classify intents, as we can easily group
   requirements by solution and intent user.

   On the one hand, different solutions and intent users have different
   requirements, expectations, and priorities for intent-based
   networking.  Therefore, intent users require different intent types,
   depending on their context, since they participate in different use
   cases.  For instance, some intent users are more technical and
   require intents that expose more technical information.  Other intent
   users do not have knowledge of the network infrastructure and require
   intents that shield them from different networking concepts and
   technologies.

   The following are the solutions and intent users that intent-based
   networking needs to support:

           +============+=====================================+
           | Solutions  | Intent Users                        |
           +============+=====================================+
           | Carrier    | Network Operators, Service          |
           | Networks   | Designers / App Developers, Service |
           |            | Operators, Customers / Subscribers  |
           +------------+-------------------------------------+
           | DC         | Cloud Administrators, Underlay      |
           | Networks   | Network Administrators, Application |
           |            | Developers, Customers / Tenants     |
           +------------+-------------------------------------+
           | Enterprise | Enterprise Administrators,          |
           | Networks   | Application Developers, End Users   |
           +------------+-------------------------------------+

                Table 1: Intent Solutions and Intent Users

   These intent solutions and intent users represent a starting point
   for the classification and are expendable through the methodology
   presented in Section 6.1.

   *  For carrier network scenarios, for example, if a customer/
      subscriber wants to watch high-definition video, then the intent
      is to convert the video image to 1080p.

   *  For DC network scenarios, administrators have their own clear
      network intent such as load balancing.  For all traffic flows that
      need NFV service chaining, they can restrict the maximum load of
      any VNF node / container below 50% and the maximum load of any
      network link below 70%.

   *  For enterprise network scenarios, when hosting a video conference,
      multiple remote accesses are required.  An example of the intent
      from the network administrator is as follows: for any end user of
      this application, the arrival time of hologram objects of all the
      remote tele-presenters should be synchronized within 50 ms to
      reach the destination viewer for each conversation session.

4.3.  Benefits of Intents for Different Stakeholders

   Current network APIs and CLIs are too complex because they are highly
   integrated with the low-level concepts exposed by networks.
   Customers, application developers, and end users must not be required
   to set IP addresses, VLANs, subnets, or ports, whereas operators may
   still want to have both more technical and network visibility.  All
   stakeholders would benefit from simpler interfaces, such as:

   *  request gold VPN service between sites A, B, and C

   *  provide CE redundancy for the customer sites

   *  add access rules to the network service

   Operators and administrators manually troubleshoot and fix their
   networks and services.  They instead want to:

   *  simplify and automate network operations

   *  simplify definitions of network services

   *  provide simple customer APIs for value-added services (operators)

   *  be informed if the network or service is not behaving as requested

   *  enable automatic optimization and correction for selected
      scenarios

   *  have systems that learn from historic information and behavior

   Currently, intent users cannot build their own services and policies
   without becoming technical experts and performing manual maintenance
   actions.  They instead want to be able to:

   *  build their own network services with their own policies via
      simple interfaces, without becoming networking experts

   *  have their network services up and running based on intent and
      automation only, without any manual actions or maintenance

4.4.  Intent Types That Need to Be Supported

   Next to the intent solutions and intent users, another way to
   categorize the intent is through the intent types.  The following
   intent types and subtypes need to be supported in order to address
   the requirements from different solutions and intent users.

   *  Customer service intent

      -  for customer self service with SLA

      -  for service operator orders

   *  Network and underlay network service intent

      -  for service operator orders

      -  for intent-driven network configuration, verification,
         correction, and optimization

      -  for intent created and provided by the underlay network
         administrator

   *  Network and underlay network intent

      -  for network configuration

      -  for automated life-cycle management of network configurations

      -  for network resources (switches, routers, routing, policies,
         and underlay)

   *  Cloud management intent

      -  for DC configuration, VMs, DB servers, and Application servers

      -  for communication between VMs

   *  Cloud resource management intent

      -  for cloud resource life-cycle management (policy-driven self-
         configuration and auto-scaling and recovery/optimization)

   *  Strategy intent

      -  for security, QoS, application policies, traffic steering, etc.

      -  for configuring and monitoring policies, alarm generation for
         non-compliance, and auto-recovery

      -  for design models and policies for network and network service
         design

      -  for design workflows, models, and policies for operational task
         intents

   *  Operational task intents

      -  for network migration

      -  for device replacements

      -  for network software upgrades

      -  for automating any other tasks that operators/administrator
         often perform

   It is important to mention all of the previously mentioned types and
   subtypes may affect other intents.  For example, operational task
   intent can modify many other intents.  The task itself is short
   lived, but the modification of other intents has an impact on their
   life cycle, so those changes must continue to be continuously
   monitored and self corrected/optimized.

5.  Functional Characteristics and Behavior

   Intent can be used to operate immediately on a target (much like
   issuing a command) or whenever it is appropriate (e.g., in response
   to an event).  In either case, intent has a number of behaviors that
   serve to further organize its purpose, as described by the following
   subsections.

5.1.  Abstracting Intent Operation

   The modeling of intents can be abstracted using the following three-
   tuple:

   {Context, Capabilities, Constraints}

   *  Context grounds the intent and determines if it is relevant or not
      for the current situation.  Thus, context selects intents based on
      applicability.

   *  Capabilities describe the functionality that the intent can
      perform.  Capabilities take different forms depending on the
      expressivity of the intent as well as the programming paradigm(s)
      used.

   *  Constraints define any restrictions on the capabilities to be used
      for that particular context.

   Metadata can be attached via strategy templates to each of the
   elements of the three-tuple and may be used to describe how the
   intent should be used and how it operates as well as prescribe any
   operational dependencies that must be taken into account.

   Although different intent categories share the same abstracted intent
   model, each category will have its own specific context,
   capabilities, and constraints.

5.2.  Intent User Types

   Expanding on the introduction in Section 4.2, intent user types
   represent the intent users that define and issue the intent request.
   Depending on the intent solutions, there are specific intent users.
   Examples of intent users are customers, network operators, service
   operators, enterprise administrators, cloud administrators, underlay
   network administrators, or application developers.

   *  Customers and end users do not necessarily know the functional and
      operational details of the network that they are using.
      Furthermore, they lack skills to understand such details; in fact,
      such knowledge is typically not relevant to their job.  In
      addition, the network may not expose these details to its intent
      users.  This class of intent users focuses on the applications
      that they run and uses services offered by the network.  Hence,
      they want to specify policies that provide consistent behavior
      according to their business needs.  They do not have to worry
      about how the intents are deployed onto the underlying network and
      especially whether the intents need to be translated to different
      forms to enable network elements to understand them.

   *  Application developers work in a set of abstractions defined by
      their application and programming environment(s).  For example,
      many application developers think in terms of objects (e.g., a
      VPN).  While this makes sense to the application developer, most
      network devices do not have a VPN object per se; rather, the VPN
      is formed through a set of configuration statements for that
      device in concert with configuration statements for the other
      devices that together make up the VPN.  Hence, the view of
      application developers matches the services provided by the
      network but may not directly correspond to other views of other
      intent users.

   *  Network operators may have the knowledge of the underlying
      network.  However, they may not understand the details of the
      applications and services of customers.

5.3.  Intent Scope

   Intents are used to manage the behavior of the networks they are
   applied to and all intents are applied within a specific scope, such
   as:

   *  connectivity scope, if the intent creates or modifies a connection

   *  security/privacy scope, if the intent specifies the security
      characteristics of the network, customers, or end users

   *  application scope, when the intent specifies the applications to
      be affected by the intent request

   *  QoS scope, when the intent specifies the QoS characteristics of
      the network

   These intent scopes are expendable through the methodology presented
   in Section 6.1.

5.4.  Intent Network Scope

   Regardless of the intent user type, their intent request affects the
   network, or network components, which are representing the intent
   targets.

   Thus, the intent network scope, or policy target as known in the area
   of declarative policy, can represent VNFs or PNFs, physical network
   elements, campus networks, SD-WANs, RANs, cloud edges, cloud cores,
   branches, etc.

5.5.  Intent Abstraction

   Intent can be classified by whether it is necessary to feed back
   technical network information or non-technical information to the
   intent user after the intent is executed.  As well, intent
   abstraction covers the level of technical details in the intent
   itself.

   *  Non-technical intent users do not care how the intent is executed
      nor do they care about the details of the network.  As a result,
      they do not need to know the configuration information of the
      underlying network.  They only focus on whether the intent
      execution result achieves the goal and the execution effect such
      as the quality of completion and the length of execution.  In this
      scenario, we refer to an abstraction without technical feedback.

   *  Administrators, such as network administrators, perform intents,
      such as allocating network resources, selecting transmission
      paths, handling network failures, etc.  They require multiple
      feedback indicators for network resource conditions, congestion
      conditions, fault conditions, etc., after execution.  In this
      case, we refer to an abstraction with technical feedback.

   As per the definition of "intent" provided in [RFC9315], lower-level
   intents are not considered to qualify as intents.  However, we kept
   this classification to identify any PoCs / Demos / Use Cases that
   still either require or implement a lower level of abstraction for
   intents.

5.6.  Intent Life Cycle

   Intents can be classified into transient and persistent intents:

   Transient:  The intent has no life-cycle management.  As soon as the
      specified operation is successfully carried out, the intent is
      finished and can no longer affect the target object.

   Persistent:  The intent has life-cycle management.  Once the intent
      is successfully activated and deployed, the system will keep all
      relevant intents active until they are deactivated or removed.

5.7.  Autonomous Driving Levels

   In different phases of the autonomous driving network [TMF-AUTO], the
   intents are different.  Depending on the Autonomous Network Level of
   the overall solution, we may have different intent requirements and
   types.  For example, at lower levels, the customer intent is:

   *  automatically converted to configuration policies only while at
      the higher levels,

   *  covering the full life cycle,

   *  converted to both configuration and monitoring policies, and

   *  self assured using AI.

   Typical examples of autonomous driving networks level 0 to 5 are
   shown below.

   Level 0 - Traditional manual network:
      O&M personnel manually control the network and obtain network
      alarms and logs.

      - No intent

   Level 1 - Partially automated network:
      Automated scripts are used to automate service provisioning,
      network deployment, and maintenance.  The network provides shallow
      perception of the network status and decision making suggestions.

      - No intent

   Level 2 - Automated network:
      This entails the automation of most service provisioning, network
      deployment, and maintenance of a comprehensive perception of
      network status and local machine decision-making.

      - simple intent on service provisioning

   Level 3 - Self-optimization network:
      This entails a deep awareness of network status and automatic
      network control, meeting requirements of intent users of the
      network.

      - Intent based on network status cognition

   Level 4 - Partial autonomous network:
      In a limited environment, people do not need to participate in
      decision-making and networks can adjust themselves.

      - Intent based on limited AI

   Level 5 - Autonomous network:
      In different network environments and network conditions, the
      network can automatically adapt and adjust to meet people's
      intentions.

      - Intent based on AI

6.  Intent Classification

   This section proposes an approach to intent classification that may
   help to classify mainstream intent-related demos/tools.

   The three classifications in this document have been proposed from
   scratch (following the methodology presented) through three
   iterations: one for a carrier network intent solution, one for a DC
   intent solution, and one for an enterprise intent solution.  For each
   intent solution, we identified the specific intent users and intent
   types.  Then, we further identified intent scope, network scope,
   abstractions, and life-cycle requirements.

   These classifications and the generated tables can be easily
   extended.  For example, for the DC intent solution, a new category
   "resource scope" is identified, and the classification table has been
   extended accordingly.

   In the future, as new scenarios, applications, and domains emerge,
   new classifications and taxonomies can be identified, following the
   proposed methodology.

   The intent classifications have been documented to the best of our
   knowledge at the time of writing.  Additional classifications will
   most likely come to light in the future.

   The output of the intent classification is the intent taxonomy
   introduced in the subsections of this section.

   Thus, the subsections of Section 6 introduce the proposed intent
   classification methodology, the consolidated intent taxonomy for
   three intent solutions, and the concrete examples of intent
   classifications for three different intent solutions (e.g., carrier
   network, data center, and enterprise) that were derived using the
   proposed methodology and can be filled in for PoCs, demos, research
   projects, or future documents.

6.1.  Intent Classification Methodology

   This section describes the methodology used to derive the initial
   classification proposed in the document.  The proposed methodology
   can be used to create new intent classifications from scratch by
   analyzing the solution knowledge.  As well, the methodology can be
   used to update existing classification tables by adding or removing
   different solutions, intent users, or intent types in order to cater
   to future scenarios, applications, or domains.

             +------------------------------------------+
             |Solution Knowledge (requirements,         |
             |use cases, technologies, network, intent  |
             |users, intent requirements)               |
             +----------------+-------------------------+
                              | Input             Rx=Read
                              |                   Ux=Update (Add/Remove)
                     +--------V--------+
                     |1.Identify Intent|
                     |  Solution       +------------+
                     |                 |            |
                     +---------^-+-----+            |
                            R1 | | U1               |
   +---------------+ U8        | |    R2         +--v----------------+
   |8.Identify New +---------+ | |   +-----------> 2.Identify        |
   |  Categories   | R8      | | |   | U2        |   Intent          |
   |               <-------- | | |   | +---------+   User Types      |
   +--------^------+       | | | |   | |         +-------|-----------+
            |              | | | |   | |                 |
            |             ++-+-v-v---+-v-+               |
   +--------+------+ U7   |              | R3     +------v------------+
   |7.Identify     +------>   Intent     +--------> 3.Identify        |
   |  Life-Cycle   | R7   |Classification| U3     |   Type            |
   |  Requirements <------+              <--------+   of Intent       |
   +--------^------+      +^--^-+--^-+---+        +------|------------+
            |              || | |  | |                   |
            |              || | |  | |                   |
   +--------+-----+        || | |  | | R4        +-------v-----------+
   |6.Identify    | U6     || | |  | +-----------> 4.Identify        |
   |  Abstractions+---------| | |  |   U4        |   Intent          |
   |              <---------+ | |  +-------------+   Scope           |
   +-------^------+ R6        | |                +-------+-----------+
           |                  | |                        |
           |               U5 | |R5                      |
           |          +-------+-v--------+               |
           |          |5.Identify Network|               |
           +----------+  Scope           <---------------+
                      +------------------+

                Figure 1: Intent Classification Methodology

   The intent classification workflow starts from the solution
   knowledge, which can provide information on requirements, use cases,
   technologies used, network properties, intent users that define and
   issue the intent request, and requirements.  The following defines
   the steps to classify an intent:

   1.  Receive the information provided in the solution knowledge as
       input for identifying the intent solution (e.g., carrier,
       enterprise, and data center).  Intent solutions are reviewed
       against the existing classification and can either be used if
       present or added if not there; if not needed, they can be removed
       from the classification (R1-U1).

   2.  Identify the intent user types (e.g., customer, network
       operators, service operators, etc.).  Review the existing intent
       classification.  Then use the intent user type if present; add it
       if it is not there or remove it if not needed (R2-U2).

   3.  Identify the types of intent (e.g., network intent, customer
       service intent).  Review the existing classification and then
       use, add, or remove the intent type (R3-U3).

   4.  Identify the intent scopes (e.g., connectivity, application)
       based on the solution knowledge.  Then, review the existing
       classification.  Use, add, or remove the identified intent scope
       (R4-U4).

   5.  Identify the network scopes (e.g., campus, radio access).  Then,
       review the existing classification.  Either use, add, or remove
       the identified network scope (R5-U5).

   6.  Identify the abstractions (e.g., technical, non-technical).
       Then, review the existing classification and either use, add, or
       remove the abstractions (R6-U6).

   7.  Identify the life-cycle requirements (e.g., persistent,
       transient).  Then, review the existing classification.  Either
       use, add, or remove the life-cycle requirements (R7-U7).

   8.  Identify any new categories.  Use and add the newly identified
       categories.  New categories can be identified as new domains or
       applications emerge or as new areas of concern (e.g., privacy,
       compliance) arise that are not listed in the current methodology.

6.2.  Intent Taxonomy

   The following taxonomy describes the various intent solutions, intent
   user types, intent types, intent scopes, network scopes,
   abstractions, and life cycles.  The taxonomy represents the output of
   the intent classification tables for each of the solutions addressed
   (i.e., carrier, data center, and enterprise solutions).

   The intent scope categories in Figure 2 are shared among the carrier,
   DC, and enterprise solutions.  The abbreviations (Cx) in Sections
   6.3.2 and 6.4.2 are introduced with the scope of fitting as column
   title in the following tables.

                                   +--------------------------------+
                               +-->|Carrier  Enterprise  Data Center|
                               |   +--------------------------------+
                               |   +--------------------------------+
                               |   |Customer/Subscriber/End User    |
                 +----------+  |   |Network or Service Operator     |
               +>+Solution  +--+   |Application Developer           |
               | +----------+   +->|Enterprise Administrator        |
               |                |  |Cloud Administrator             |
               | +----------+   |  |Underlay Network Administrator  |
               +>+Intent    +---+  +--------------------------------+
               | |User      |      +--------------------------------+
               | |Type      |      |Customer Service Intent         |
               | +----------+      |Strategy Intent                 |
               | +----------+      |Network Service Intent          |
               +>+Intent    +----->|Underlay Network Service Intent |
      +------+ | |Type      |      |Network Intent                  |
      |Intent+-+ +----------+      |Underlay Network Intent         |
      +------+ |                   |Operational Task Intent         |
               | +----------+      |Cloud Management Intent         |
               +>+Intent    +---+  |Cloud Resource Management Intent|
               | |Scope     |   |  +--------------------------------+
               | +----------+   |  +--------------------------------+
               |                +->|Connectivity   Application  QoS |
               | +----------+      |Security/Privacy Storage Compute|
               +>+Network   +---+  +--------------------------------+
               | |Scope     |   |  +--------------------------------+
               | +----------+   |  |Radio Access      Branch        |
               |                +->|Transport Access  SD-WAN        |
               | +----------+      |Transport Aggr.   VNF      PNF  |
               +>+Abstrac-  +----+ |Transport Core    Physical      |
               | |tion      |    | |Cloud Edge        Logical       |
               | +----------+    | |Cloud Core        Campus        |
               | +----------+    | +--------------------------------+
               +>+Life      |    | +--------------------------------+
                 |Cycle     +--+ +>|Technical         Non-Technical |
                 +----------+  |   +--------------------------------+
                               |   +--------------------------------+
                               +-->|Persistent        Transient     |
                                   +--------------------------------+

                         Figure 2: Intent Taxonomy

6.3.  Intent Classification for Carrier Solution

6.3.1.  Intent Users and Intent Types

   This section addresses steps 1, 2, and 3 from Figure 1.  The
   following table describes the intent users in carrier solutions and
   intent types with their descriptions for different intent users.

   +=============+=============+=======================================+
   | Intent User | Intent Type | Intent Type Description               |
   +=============+=============+=======================================+
   | Customer/   | Customer    | Customer self service with SLA        |
   | Subscriber  | Service     | and value-added service.              |
   |             | Intent      |                                       |
   |             |             | Example: Always maintain a high       |
   |             |             | quality of service and high           |
   |             |             | bandwidth for gold-level              |
   |             |             | subscribers.                          |
   |             |             |                                       |
   |             |             | Operation statement: Measure the      |
   |             |             | network congestion status, give       |
   |             |             | different adaptive parameters to      |
   |             |             | stations of different priority;       |
   |             |             | thus, in a heavy load situation,      |
   |             |             | make the bandwidth of the high-       |
   |             |             | priority customers guaranteed.        |
   |             |             | At the same time, ensure the          |
   |             |             | overall utilization of the            |
   |             |             | system and improve the overall        |
   |             |             | throughput of the system.             |
   |             +-------------+---------------------------------------+
   |             | Strategy    | Customer designs models and           |
   |             | Intent      | policy intents to be used by          |
   |             |             | customer service intents.             |
   |             |             |                                       |
   |             |             | Example: Request reliable             |
   |             |             | service during peak traffic           |
   |             |             | periods for video-type apps.          |
   +-------------+-------------+---------------------------------------+
   | Network     | Network     | Service provided by the network       |
   | Operator    | Service     | service operator to the customer      |
   |             | Intent      | (e.g., the service operator).         |
   |             |             |                                       |
   |             |             | Example: Request network service      |
   |             |             | with delay guarantee for access       |
   |             |             | customer A.                           |
   |             +-------------+---------------------------------------+
   |             | Network     | Network operator requests             |
   |             | Intent      | network-wide (service underlay        |
   |             |             | or other network-wide                 |
   |             |             | configuration) or network-            |
   |             |             | resource configurations               |
   |             |             | (switches, routers, routing, or       |
   |             |             | policies).  Includes                  |
   |             |             | connectivity, routing, QoS,           |
   |             |             | security, application policies,       |
   |             |             | traffic steering policies, alarm      |
   |             |             | generation for non-compliance,        |
   |             |             | auto-recovery, etc.                   |
   |             |             |                                       |
   |             |             | Example: Request high priority        |
   |             |             | queuing for traffic of class A.       |
   |             +-------------+---------------------------------------+
   |             | Operational | Network operator requests             |
   |             | Task Intent | execution of any automated task       |
   |             |             | other than network service            |
   |             |             | intent and network intent (e.g.,      |
   |             |             | network migration, server             |
   |             |             | replacements, device                  |
   |             |             | replacements, or network              |
   |             |             | software upgrades).                   |
   |             |             |                                       |
   |             |             | Example: Request migration of         |
   |             |             | all services in network N to          |
   |             |             | backup path P.                        |
   |             +-------------+---------------------------------------+
   |             | Strategy    | Network operator designs models,      |
   |             | Intent      | policy intents, and workflows to      |
   |             |             | be used by network service            |
   |             |             | intents, network intents, and         |
   |             |             | operational task intents.             |
   |             |             | Workflows can automate any tasks      |
   |             |             | that the network operator often       |
   |             |             | performs in addition to network       |
   |             |             | service intents and network           |
   |             |             | intents.                              |
   |             |             |                                       |
   |             |             | Example: Ensure the load on any       |
   |             |             | link in the network is not            |
   |             |             | higher than 50%.                      |
   +-------------+-------------+---------------------------------------+
   | Service     | Customer    | Service operator's customer           |
   | Operator    | Service     | orders, customer service, or          |
   |             | Intent      | SLA.                                  |
   |             |             |                                       |
   |             |             | Example: Provide service S with       |
   |             |             | guaranteed bandwidth for              |
   |             |             | customer A.                           |
   |             +-------------+---------------------------------------+
   |             | Network     | Service operator's network            |
   |             | Service     | orders / network SLA.                 |
   |             | Intent      |                                       |
   |             |             | Example: Provide network              |
   |             |             | guarantees in terms of security,      |
   |             |             | low latency, and high bandwidth.      |
   |             +-------------+---------------------------------------+
   |             | Operational | Service operator requests             |
   |             | Task Intent | execution of any automated task       |
   |             |             | other than customer service           |
   |             |             | intent and network service            |
   |             |             | intent.                               |
   |             |             |                                       |
   |             |             | Example: Update service operator      |
   |             |             | portal platforms and their            |
   |             |             | software regularly.  Move             |
   |             |             | services from network operator 1      |
   |             |             | to network operator 2.                |
   |             +-------------+---------------------------------------+
   |             | Strategy    | Service operator designs models,      |
   |             | Intent      | policy intents, and workflows to      |
   |             |             | be used by customer service           |
   |             |             | intents, network service              |
   |             |             | intents, and operational task         |
   |             |             | intents.  Workflows can automate      |
   |             |             | any task that the service             |
   |             |             | operator often performs in            |
   |             |             | addition to network service           |
   |             |             | intents and network intents.          |
   |             |             |                                       |
   |             |             | Example: Request network service      |
   |             |             | guarantee to avoid network            |
   |             |             | congestion during special             |
   |             |             | periods such as Black Friday and      |
   |             |             | Christmas.                            |
   +-------------+-------------+---------------------------------------+
   | Application | Customer    | Customer service intent API           |
   | Developer   | Service     | provided to the application           |
   |             | Intent      | developers.                           |
   |             |             |                                       |
   |             |             | Example: API to request network       |
   |             |             | to watch HD video (4K/8K).            |
   |             +-------------+---------------------------------------+
   |             | Network     | Network service intent API            |
   |             | Service     | provided to the application           |
   |             | Intent      | developers.                           |
   |             |             |                                       |
   |             |             | Example: API to request network       |
   |             |             | service, monitoring, and traffic      |
   |             |             | grooming.                             |
   |             +-------------+---------------------------------------+
   |             | Network     | Network intent API provided to        |
   |             | Intent      | the application developers.           |
   |             |             |                                       |
   |             |             | Example: API to request network       |
   |             |             | resource configurations.              |
   |             +-------------+---------------------------------------+
   |             | Operational | Operational task intent API           |
   |             | Task Intent | provided to the application           |
   |             |             | developers.  This is for the          |
   |             |             | trusted internal operator /           |
   |             |             | service providers / customer          |
   |             |             | DevOps.                               |
   |             |             |                                       |
   |             |             | Example: API to request server        |
   |             |             | migrations.                           |
   |             +-------------+---------------------------------------+
   |             | Strategy    | Application developer designs         |
   |             | Intent      | models, policy, and workflows to      |
   |             |             | be used by customer service           |
   |             |             | intents, network service              |
   |             |             | intents, and operational task         |
   |             |             | intents.  This is for the             |
   |             |             | trusted internal operator /           |
   |             |             | service provider / customer           |
   |             |             | DevOps.                               |
   |             |             |                                       |
   |             |             | Example: API to design network        |
   |             |             | load-balancing strategies during      |
   |             |             | peak times.                           |
   +-------------+-------------+---------------------------------------+

            Table 2: Intent Classification for Carrier Solution

6.3.2.  Intent Categories

   This subsection addresses steps 4 to 7 from Figure 1.  The following
   are the proposed categories:

   Intent Scope:  C1=Connectivity, C2=Security/Privacy, C3=Application,
      C4=QoS

   Network Scope:

                   Network Domain:  C1=Radio Access, C2=Transport
         Access, C3=Transport Aggregation, C4=Transport Core, C5=Cloud
         Edge, C6=Cloud Core

                   Network Function (NF) Scope:  C1=VNFs, C2=PNFs

   Abstraction (ABS):  C1=Technical (with technical feedback), C2=Non-
      technical (without technical feedback) (see Section 5.2).

   Life cycle (L-C):  C1=Persistent (full life cycle), C2=Transient
      (short lived)

6.3.3.  Intent Classification Example

   This section contains an example of how the methodology described in
   Section 6.1 can be used in order to classify intents introduced in
   the "A Multi-Level Approach to IBN" PoC demonstration [POC-IBN].
   This PoC is led by academics carrying out research in the area of
   SDN/NFV, and the specific problem they are addressing is the
   application of the intent concept at different levels that correspond
   to different stakeholders.  For this research work, they considered
   two types of intents: slice intents and service chain intents.

   In this PoC [POC-IBN], a slice intent expresses a request for a
   network slice with two types of components: a set of top-layer
   virtual functions and a set of virtual switches and/or routers of L2/
   L3 VNFs.  A service chain intent expresses a request for a service
   operated through a chain of service components running in L4-L7
   virtual functions.

   Following the intent classification methodology described step by
   step in Section 6.1, the following can be derived:

   1.  The intent solution for both intents is carrier network.

   2.  The intent user type is network operator for the slice intent and
       service operator for the service chain intent.

   3.  The type of intent is a network service intent for the slice
       intent and a customer service intent for the service chain
       intent.

   4.  The intent scopes are connectivity and application.

   5.  The network scope is VNF, cloud edge, and cloud core.

   6.  The abstractions are with technical feedback for the slice intent
       and without technical feedback for the service chain intent.

   7.  The life cycle is persistent.

   The following table shows how to represent this information in a
   tabular form.  The "X" in the table refers to the slice intent; the
   "Y" in the table refers to the service chain intent.

+==========+===========+===========+=====+=================+=====+=====+
|Intent    |Intent Type|Intent     |NF   |Network          |ABS  |L-C  |
|User      |           |Scope      |Scope|Scope            |     |     |
|          |           +==+==+==+==+==+==+==+==+==+==+==+==+==+==+==+==+
|          |           |C1|C2|C3|C4|C1|C2|C1|C2|C3|C4|C5|C6|C1|C2|C1|C2|
+==========+===========+==+==+==+==+==+==+==+==+==+==+==+==+==+==+==+==+
|Customer/ |Customer   |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
|Subscriber|Service    |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
|          |Intent     |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
|          +-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|          |Strategy   |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
|          |Intent     |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+----------+-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|Network   |Network    |X |  |X |  |X |  |  |  |  |  |X |  |X |  |X |  |
|Operator  |Service    |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
|          |Intent     |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
|          +-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|          |Network    |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
|          |Intent     |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
|          +-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|          |Operational|  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
|          |Task Intent|  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
|          +-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|          |Strategy   |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
|          |Intent     |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+----------+-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|Service   |Customer   |Y |  |Y |  |Y |  |  |  |  |  |Y |Y |  |Y |Y |  |
|Operator  |Intent     |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
|          +-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|          |Network    |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
|          |Service    |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
|          |Intent     |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
|          +-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|          |Op Task    |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
|          |Intent     |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
|          +-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|          |Strategy   |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
|          |Intent     |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+----------+-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|App       |Customer   |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
|Developer |Intent     |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
|          +-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|          |Network    |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
|          |Service    |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
|          |Intent     |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
|          +-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|          |Network    |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
|          |Intent     |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
|          +-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|          |Op Task    |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
|          |Intent     |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
|          +-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|          |Strategy   |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
|          |Intent     |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+----------+-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

     Figure 3: Intent Classification Example for Carrier Solution

6.4.  Intent Classification for Data Center Network Solutions

6.4.1.  Intent Users and Intent Types

   The following table describes the intent users in DC network
   solutions and intent types with their descriptions for different
   intent users.

   +===============+=============+====================================+
   | Intent User   | Intent Type | Intent Type Description            |
   +===============+=============+====================================+
   | Customer/     | Customer    | Customer self service via tenant   |
   | Tenants       | Service     | portal.                            |
   |               |             |                                    |
   |               |             | Example: Request GPU computing and |
   |               |             | storage resources to meet 10k      |
   |               |             | video surveillance services.       |
   |               +-------------+------------------------------------+
   |               | Strategy    | This includes models and policy    |
   |               | Intent      | intents designed by customers/     |
   |               |             | tenants to be reused later during  |
   |               |             | instantiation.                     |
   |               |             |                                    |
   |               |             | Example: Request dynamic computing |
   |               |             | and storage resources of the       |
   |               |             | service in special and daily       |
   |               |             | times.                             |
   +---------------+-------------+------------------------------------+
   | Cloud         | Cloud       | Configuration of VMs, DB Servers,  |
   | Administrator | Management  | app servers, and communication     |
   |               | Intent      | between servers and VMs.           |
   |               |             |                                    |
   |               |             | Example: Request connectivity      |
   |               |             | between VMs A, B, and C in network |
   |               |             | N1.                                |
   |               +-------------+------------------------------------+
   |               | Cloud       | Policy-driven self configuration   |
   |               | Resource    | and recovery/optimization.         |
   |               | Management  |                                    |
   |               | Intent      | Example: Request automatic life-   |
   |               |             | cycle management of VM cloud       |
   |               |             | resources.                         |
   |               +-------------+------------------------------------+
   |               | Operational | Cloud administrator requests       |
   |               | Task Intent | execution of any automated task    |
   |               |             | other than cloud management        |
   |               |             | intents and cloud resource         |
   |               |             | management intents.                |
   |               |             |                                    |
   |               |             | Example: Request upgrade operating |
   |               |             | system to version X on all VMs in  |
   |               |             | network N1.                        |
   |               |             |                                    |
   |               |             | Operational statement: An intent   |
   |               |             | to update a system might           |
   |               |             | reconfigure the system topology    |
   |               |             | (connect to a service and to       |
   |               |             | peers), exchange data (update the  |
   |               |             | content), and uphold a certain QoE |
   |               |             | level (allocate sufficient network |
   |               |             | resources).  Thus, the network     |
   |               |             | carries out the necessary          |
   |               |             | configuration to best serve such   |
   |               |             | an intent, e.g., setting up direct |
   |               |             | connections between terminals and  |
   |               |             | allocating fair shares of router   |
   |               |             | queues considering other network   |
   |               |             | services.                          |
   |               +-------------+------------------------------------+
   |               | Strategy    | Cloud administrator designs        |
   |               | Intent      | models, policy intents, and        |
   |               |             | workflows to be used by other      |
   |               |             | intents.  Automate any tasks that  |
   |               |             | administrator often performs in    |
   |               |             | addition to life cycle of cloud    |
   |               |             | management intents and cloud       |
   |               |             | management resource intents.       |
   |               |             |                                    |
   |               |             | Example: In case of emergency,     |
   |               |             | automatically migrate all cloud    |
   |               |             | resources to DC2.                  |
   +---------------+-------------+------------------------------------+
   | Underlay      | Underlay    | Service created and provided by    |
   | Network       | Network     | the underlay network               |
   | Administrator | Service     | administrator.                     |
   |               | Intent      |                                    |
   |               |             | Example: Request underlay service  |
   |               |             | between DC1 and DC2 with bandwidth |
   |               |             | B.                                 |
   |               +-------------+------------------------------------+
   |               | Underlay    | Underlay network administrator     |
   |               | Network     | requests some DCN-wide underlay    |
   |               | Intent      | network configuration or network   |
   |               |             | resource configurations.           |
   |               |             |                                    |
   |               |             | Example: Establish and allocate    |
   |               |             | DHCP address pool.                 |
   |               +-------------+------------------------------------+
   |               | Operational | Underlay network administrator     |
   |               | Task Intent | requests execution of any          |
   |               |             | automated task other than underlay |
   |               |             | network service and resource       |
   |               |             | intent.                            |
   |               |             |                                    |
   |               |             | Example: Request automatic rapid   |
   |               |             | detection of device failures and   |
   |               |             | pre-alarm correlation.             |
   |               +-------------+------------------------------------+
   |               | Strategy    | Underlay network administrator     |
   |               | Intent      | designs models, policy intents,    |
   |               |             | and workflows to be used by other  |
   |               |             | intents.  Automate any tasks that  |
   |               |             | the administrator often performs.  |
   |               |             |                                    |
   |               |             | Example: For all traffic flows     |
   |               |             | that need NFV service chaining,    |
   |               |             | restrict the maximum load of any   |
   |               |             | VNF node/container below 50% and   |
   |               |             | the maximum load of any network    |
   |               |             | link below 70%.                    |
   +---------------+-------------+------------------------------------+
   | Application   | Cloud       | Cloud management intent API        |
   | Developer     | Management  | provided to the application        |
   |               | Intent      | developers.                        |
   |               |             |                                    |
   |               |             | Example: API to request            |
   |               |             | configuration of VMs or DB         |
   |               |             | Servers.                           |
   |               +-------------+------------------------------------+
   |               | Cloud       | Cloud resource management intent   |
   |               | Resource    | API provided to the application    |
   |               | Management  | developers.                        |
   |               | Intent      |                                    |
   |               |             | Example: API to request automatic  |
   |               |             | life-cycle management of cloud     |
   |               |             | resources.                         |
   |               +-------------+------------------------------------+
   |               | Underlay    | Underlay network service API       |
   |               | Network     | provided to the application        |
   |               | Service     | developers.                        |
   |               | Intent      |                                    |
   |               |             | Example: API to request real-time  |
   |               |             | monitoring of device condition.    |
   |               +-------------+------------------------------------+
   |               | Underlay    | Underlay network resource API      |
   |               | Network     | provided to the application        |
   |               | Intent      | developers.                        |
   |               |             |                                    |
   |               |             | Example: API to request dynamic    |
   |               |             | management of IPv4 address pool    |
   |               |             | resources.                         |
   |               +-------------+------------------------------------+
   |               | Operational | Operational task intent API        |
   |               | Task Intent | provided to the trusted            |
   |               |             | application developer (internal    |
   |               |             | DevOps).                           |
   |               |             |                                    |
   |               |             | Example: API to request automatic  |
   |               |             | rapid detection of device failures |
   |               |             | and pre-alarm correlation.         |
   |               +-------------+------------------------------------+
   |               | Strategy    | Application developer designs      |
   |               | Intent      | models, policy intents, and        |
   |               |             | building blocks to be used by      |
   |               |             | other intents.  This is for the    |
   |               |             | trusted internal DCN DevOps.       |
   |               |             |                                    |
   |               |             | Example: API to request load-      |
   |               |             | balancing thresholds.              |
   +---------------+-------------+------------------------------------+

     Table 3: Intent Classification for Data Center Network Solutions

6.4.2.  Intent Categories

   The following are the proposed categories:

   Intent Scope:  C1=Connectivity, C2=Security/Privacy, C3=Application,
      C4=QoS, C5=Storage, C6=Compute

   Network Scope

      Network Domain:  DC Network

      DCN Network (DCN Net) Scope:  C1=Logical, C2=Physical

      DCN Resource (DCN Res) Scope:  C1=Virtual, C2=Physical

   Abstraction (ABS):  C1=Technical (with technical feedback), C2=Non-
      technical (without technical feedback) (see Section 5.2).

   Life cycle (L-C):  C1=Persistent (full life cycle), C2=Transient
      (short lived)

6.4.3.  Intent Classification Example

   This section depicts an example on how the methodology described in
   Section 6.1 can be used by the research community to classify
   intents.  As mentioned in Section 6.3.3, a successful use of the
   classification proposed in this document is introduced in the PoC
   demonstration titled "A Multi-Level Approach to IBN" [POC-IBN].  The
   PoC is led by academics carrying out research in the area of SDN/NFV;
   the specific problem they are addressing is the application of the
   intent concept at different levels that correspond to different
   stakeholders.

   For their research work, they considered two types of intents: slice
   intents and service chain intents.  For the data center solution,
   only the slice intent is relevant.

   As already mentioned in Section 6.3.3, a slice intent expresses a
   request for a network slice with two types of components: a set of
   top-layer virtual functions and a set of virtual switches and/or
   routers of L2/L3 VNFs.

   Following the intent classification methodology described step by
   step in Section 6.1, we identify the following:

   1.  The intent solution is data center.

   2.  The intent user type is the cloud administrator for the slice
       intent and service chain intent.

   3.  The type of intent is a cloud management intent for the slice
       intent.

   4.  The intent scopes are connectivity and application.

   5.  The network scope is logical; the resource scope is virtual.

   6.  The abstractions are with technical feedback for the slice
       intent.

   7.  The life cycle is persistent.

   The following table shows how to represent this information in a
   tabular form; the "X" in the table refers to the slice intent.


   +===========+=============+=================+=====+=====+=====+=====+
   |Intent User| Intent Type |Intent           |DCN  |DCN  |ABS  |L-C  |
   |           |             |Scope            |Res  |Net  |     |     |
   |           |             +==+==+==+==+==+==+==+==+==+==+==+==+==+==+
   |           |             |C1|C2|C3|C4|C5|C6|C1|C2|C1|C2|C1|C2|C1|C2|
   +===========+=============+==+==+==+==+==+==+==+==+==+==+==+==+==+==+
   |Customer/  | Customer    |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
   |Tenants    | Service     |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
   |           | Intent      |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
   |           +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
   |           | Strategy    |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
   |           | Intent      |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
   +-----------+-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
   |Cloud Admin| Cloud       |X |  |X |  |  |  |X |  |X |  |X |  |X |  |
   |           | Management  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
   |           | Intent      |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
   |           +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
   |           | Cloud       |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
   |           | Resource    |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
   |           | Management  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
   |           | Intent      |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
   |           +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
   |           | Operational |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
   |           | Task Intent |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
   |           +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
   |           | Strategy    |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
   |           | Intent      |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
   +-----------+-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
   |Underlay   | Underlay    |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
   |Network    | Network     |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
   |Admin      | Intent      |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
   |           +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
   |           | Underlay    |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
   |           | Network     |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
   |           | Resource    |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
   |           | Intent      |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
   |           +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
   |           | Operational |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
   |           | Task Intent |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
   |           +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
   |           | Strategy    |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
   |           | Intent      |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
   +-----------+-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
   |App        | Cloud       |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
   |Developer  | Management  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
   |           | Intent      |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
   |           +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
   |           | Cloud       |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
   |           | Resource    |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
   |           | Management  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
   |           | Intent      |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
   |           +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
   |           | Underlay    |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
   |           | Network     |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
   |           | Intent      |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
   |           +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
   |           | Underlay    |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
   |           | Network     |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
   |           | Resource    |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
   |           | Intent      |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
   |           +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
   |           | Operational |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
   |           | Task Intent |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
   |           +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
   |           | Strategy    |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
   |           | Intent      |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
   +-----------+-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

      Figure 4: Intent Classification Example for Data Center Network
                                 Solutions

6.5.  Intent Classification for Enterprise Solution

6.5.1.  Intent Users and Intent Types

   The following table describes the intent users in enterprise
   solutions and their intent types.

   +---------------+-------------+------------------------------------+
   | Intent User   | Intent Type | Intent Type Description            |
   +---------------+-------------+------------------------------------+
   | End User      | Customer    | Enterprise end user self service   |
   |               | Service     | or applications; enterprise may    |
   |               | Intent      | have multiple types of end users.  |
   |               |             |                                    |
   |               |             | Example: Request access to VPN     |
   |               |             | service.  Request video conference |
   |               |             | between end user A and B.          |
   |               +-------------+------------------------------------+
   |               | Strategy    | This includes models and policy    |
   |               | Intent      | intents designed by end users to   |
   |               |             | be used by end-user intents and    |
   |               |             | their applications.                |
   |               |             |                                    |
   |               |             | Example: Create a video conference |
   |               |             | type for a weekly meeting.         |
   +---------------+-------------+------------------------------------+
   | Enterprise    | Network     | Service provided by the            |
   | Administrator | Service     | administrator to the end users and |
   | (internal or  | Intent      | their applications.                |
   | MSP)          |             |                                    |
   |               |             | Example: For any end user of       |
   |               |             | application X, the arrival of      |
   |               |             | hologram objects of all the remote |
   |               |             | tele-presenters should be          |
   |               |             | synchronized within 50 ms to reach |
   |               |             | the destination viewer for each    |
   |               |             | conversation session.  Create      |
   |               |             | management VPN connectivity for    |
   |               |             | type of service A.                 |
   |               |             |                                    |
   |               |             | Operational statement: The job of  |
   |               |             | the network layer is to ensure     |
   |               |             | that the delay is between 50-70 ms |
   |               |             | through the routing algorithm.  At |
   |               |             | the same time, the node resources  |
   |               |             | need to meet the bandwidth         |
   |               |             | requirements of 4K video           |
   |               |             | conferences.                       |
   |               +-------------+------------------------------------+
   |               | Network     | Administrator requires network-    |
   |               | Intent      | wide configuration (e.g., underlay |
   |               |             | or campus) or resource             |
   |               |             | configuration (switches, routers,  |
   |               |             | or policies).                      |
   |               |             |                                    |
   |               |             | Example: Configure switches in     |
   |               |             | campus network 1 to prioritize     |
   |               |             | traffic of type A.  Configure      |
   |               |             | YouTube as business non-relevant.  |
   |               +-------------+------------------------------------+
   |               | Operational | Administrator requests execution   |
   |               | Task Intent | of any automated task other than   |
   |               |             | network service intents and        |
   |               |             | network intents.                   |
   |               |             |                                    |
   |               |             | Example: Request network security  |
   |               |             | automated tasks such as web        |
   |               |             | filtering and DDoS cloud           |
   |               |             | protection.                        |
   |               +-------------+------------------------------------+
   |               | Strategy    | Administrator designs models,      |
   |               | Intent      | policy intents, and workflows to   |
   |               |             | be used by other intents.          |
   |               |             | Automate any tasks that the        |
   |               |             | administrator often performs.      |
   |               |             |                                    |
   |               |             | Example: In case of emergency,     |
   |               |             | automatically shift all traffic of |
   |               |             | type A through network N.          |
   +---------------+-------------+------------------------------------+
   | Application   | End-User    | End-user service / application     |
   | Developer     | Intent      | intent API provided to the         |
   |               |             | application developers.            |
   |               |             |                                    |
   |               |             | Example: API for request to open a |
   |               |             | VPN service.                       |
   |               +-------------+------------------------------------+
   |               | Network     | Network service API provided to    |
   |               | Service     | application developers.            |
   |               | Intent      |                                    |
   |               |             | Example: API for request network   |
   |               |             | bandwidth and latency for hosting  |
   |               |             | a video conference.                |
   |               +-------------+------------------------------------+
   |               | Network     | Network API provided to            |
   |               | Intent      | application developers.            |
   |               |             |                                    |
   |               |             | Example: API for requesting        |
   |               |             | network device configuration.      |
   |               +-------------+------------------------------------+
   |               | Operational | Operational task intent API        |
   |               | Task Intent | provided to the trusted            |
   |               |             | application developer (internal    |
   |               |             | DevOps).                           |
   |               |             |                                    |
   |               |             | Example: API for requesting        |
   |               |             | automatic monitoring and           |
   |               |             | interception for network security. |
   |               +-------------+------------------------------------+
   |               | Strategy    | Application developer designs      |
   |               | Intent      | models, policy intents, and        |
   |               |             | building blocks to be used by      |
   |               |             | other intents.  This is for the    |
   |               |             | trusted internal DevOps.           |
   |               |             |                                    |
   |               |             | Example: API for strategy intent   |
   |               |             | in case of emergencies.            |
   +---------------+-------------+------------------------------------+

          Table 4: Intent Classification for Enterprise Solution

6.5.2.  Intent Categories

   The following are the proposed categories:

   Intent Scope:  C1=Connectivity, C2=Security/Privacy, C3=Application,
      C4=QoS

   Network (Net) Scope:  C1=Campus, C2=Branch, C3=SD-WAN

   Abstraction (ABS):  C1=Technical (with technical feedback), C2=Non-
      technical (without technical feedback) (see Section 5.2)

   Life cycle (L-C):  C1=Persistent (full life cycle), C2=Transient
      (short lived)

   The following is the intent classification table example for
   enterprise solutions.


   +---------------+-------------+-----------+--------+-----+-----+
   | Intent User   | Intent Type | Intent    | Net    | ABS | L-C |
   |               |             | Scope     |        |     |     |
   |               |             +-----------+--------+-----+-----+
   |               |             |C1|C2|C3|C4|C1|C2|C3|C1|C2|C1|C2|
   +---------------+-------------+--+--+--+--+--+--+--+--+--+--+--+
   | End User      | Customer    |  |  |  |  |  |  |  |  |  |  |  |
   |               | Service     |  |  |  |  |  |  |  |  |  |  |  |
   |               | Intent      |  |  |  |  |  |  |  |  |  |  |  |
   |               +-------------+--+--+--+--+--+--+--+--+--+--+--+
   |               | Strategy    |  |  |  |  |  |  |  |  |  |  |  |
   |               | Intent      |  |  |  |  |  |  |  |  |  |  |  |
   +---------------+-------------+--+--+--+--+--+--+--+--+--+--+--+
   | Enterprise    | Network     |  |  |  |  |  |  |  |  |  |  |  |
   | Administrator | Service     |  |  |  |  |  |  |  |  |  |  |  |
   |               | Intent      |  |  |  |  |  |  |  |  |  |  |  |
   |               +-------------+--+--+--+--+--+--+--+--+--+--+--+
   |               | Network     |  |  |  |  |  |  |  |  |  |  |  |
   |               | Intent      |  |  |  |  |  |  |  |  |  |  |  |
   |               +-------------+--+--+--+--+--+--+--+--+--+--+--+
   |               | Operational |  |  |  |  |  |  |  |  |  |  |  |
   |               | Task        |  |  |  |  |  |  |  |  |  |  |  |
   |               | Intent      |  |  |  |  |  |  |  |  |  |  |  |
   |               +-------------+--+--+--+--+--+--+--+--+--+--+--+
   |               | Strategy    |  |  |  |  |  |  |  |  |  |  |  |
   |               | Intent      |  |  |  |  |  |  |  |  |  |  |  |
   +---------------+-------------+--+--+--+--+--+--+--+--+--+--+--+
   | Application   | End-User    |  |  |  |  |  |  |  |  |  |  |  |
   | Developer     | Intent      |  |  |  |  |  |  |  |  |  |  |  |
   |               +-------------+--+--+--+--+--+--+--+--+--+--+--+
   |               | Network     |  |  |  |  |  |  |  |  |  |  |  |
   |               | Service     |  |  |  |  |  |  |  |  |  |  |  |
   |               | Intent      |  |  |  |  |  |  |  |  |  |  |  |
   |               +-------------+--+--+--+--+--+--+--+--+--+--+--+
   |               | Network     |  |  |  |  |  |  |  |  |  |  |  |
   |               | Intent      |  |  |  |  |  |  |  |  |  |  |  |
   |               +-------------+--+--+--+--+--+--+--+--+--+--+--+
   |               | Operational |  |  |  |  |  |  |  |  |  |  |  |
   |               | Task        |  |  |  |  |  |  |  |  |  |  |  |
   |               | Intent      |  |  |  |  |  |  |  |  |  |  |  |
   |               +-------------+--+--+--+--+--+--+--+--+--+--+--+
   |               | Strategy    |  |  |  |  |  |  |  |  |  |  |  |
   |               | Intent      |  |  |  |  |  |  |  |  |  |  |  |
   +---------------+-------------+--+--+--+--+--+--+--+--+--+--+--+

            Figure 5: Intent Categories for Enterprise Solution

7.  Conclusions

   This document is aligned with the RG objectives and supports
   investigations into intent-based networking by proposing an intent
   categorization methodology and taxonomy.  It brings clarification to
   what an intent represents for different stakeholders through the
   proposal of an intent classification approach, ensuring that a common
   understanding among all the participants exists.  This, together with
   the proposed intent taxonomy provides a solid foundation for future
   intent-related discussions within the NMRG.

   The benefits of this intent classification document in the research
   community have been demonstrated through a PoC implementation
   [POC-IBN] in which the document's concepts have been applied at
   different levels corresponding to different stakeholders.

8.  Security Considerations

   This document identifies security and privacy as categories of the
   intent scope.  The intents could be solely security intents and
   privacy intents, or security can be embedded in the intents that
   include also connectivity, application, and QoS scope.

   Security and privacy scope is when the intent specifies the security
   characteristics of the network, customers, or end users, and privacy
   for customers and end users.

   More details of these security intents will be described in future
   documents that specify architecture, functionality, user intents, and
   models.  An analysis of the security considerations of the overall
   intent-based system is provided in Section 9 of [RFC9315].

9.  IANA Considerations

   This document has no IANA actions.

10.  Informative References

   [Banerjee21]
              Banerjee, A., Mwanje, S., and G. Carle, "Contradiction
              Management in Intent-driven Cognitive Autonomous RAN",
              September 2021.

   [Bezahaf19]
              Bezahaf, M., Hernandez, M., Bardwell, L., Davies, E.,
              Broadbent, M., King, D., and D. Hutchison, "Self-Generated
              Intent-Based System", 10th International Conference on
              Networks of the Future (NoF),
              DOI 10.1109/NoF47743.2019.9015045, October 2019,
              <https://doi.org/10.1109/NoF47743.2019.9015045>.

   [Bezahaf21]
              Bezahaf, M., Davies, E., Rotsos, C., and N. Race, "To All
              Intents and Purposes: Towards Flexible Intent Expression",
              IEEE 7th International Conference on Network
              Softwarization (NetSoft),
              DOI 10.1109/NetSoft51509.2021.9492554, July 2021,
              <https://doi.org/10.1109/NetSoft51509.2021.9492554>.

   [Davoli21] Davoli, G., "Programmability and Management of Software-
              Defined Network Infrastructures", 2021.

   [IFIP-NSM] IFIP, "Network and Service Management Taxonomy",
              <https://www.simpleweb.org/ifip/taxonomy.html>.

   [Jacobs18] Jacobs, A., Pfitscher, R., Ferreira, R., and L. Granville,
              "Refining Network Intents for Self-Driving Networks",
              Proceedings of the Afternoon Workshop on Self-Driving
              Networks (SelfDN), DOI 10.1145/3229584.3229590, August
              2018, <https://doi.org/10.1145/3229584.3229590>.

   [Leivadeas21]
              Leivadeas, A. and M. Falkner, "VNF Placement Problem: A
              Multi-Tenant Intent-Based Networking Approach", 24th
              Conference on Innovation in Clouds, Internet and Networks
              and Workshops (ICIN), DOI 10.1109/ICIN51074.2021.9385553,
              March 2021,
              <https://doi.org/10.1109/ICIN51074.2021.9385553>.

   [Mehmood21]
              Mehmood, K., Kralevska, K., and D. Palma, "Intent-driven
              Autonomous Network and Service Management in Future
              Networks: A Structured Literature Review",
              DOI 10.48550/arXiv.2108.04560, August 2021,
              <https://doi.org/10.48550/arXiv.2108.04560>.

   [ONF]      Open Networking Foundation, "Intent NBI - Definition and
              Principles", October 2016,
              <https://opennetworking.wpengine.com/wp-
              content/uploads/2014/10/TR-
              523_Intent_Definition_Principles.pdf>.

   [ONOS]     Koshibe, A., "Intent Framework", 2016,
              <https://wiki.onosproject.org/display/ONOS/
              Intent+Framework/>.

   [Padovan20]
              Padovan, S., "Design and Implementation of a Blockchain
              Intent Management System", November 2020.

   [POC-IBN]  Martini, B., Cerroni, W., Gharbaoui, M., and D. Borsatti,
              "A Multi-Level Approach to IBN", IETF 108 Hackathon
              Report, July 2020,
              <https://www.ietf.org/proceedings/108/slides/slides-108-
              nmrg-ietf-108-hackathon-report-a-multi-level-approach-to-
              ibn-02>.

   [RFC9315]  Clemm, A., Ciavaglia, L., Granville, L. Z., and J.
              Tantsura, "Intent-Based Networking - Concepts and
              Definitions", RFC 9315, DOI 10.17487/RFC9315, October
              2022, <https://www.rfc-editor.org/info/rfc9315>.

   [Szilagyi21]
              Szilágyi, P., "I2BN: Intelligent Intent Based Networks",
              Journal of ICT Standardization, Volume 9, Issue 2,
              DOI 10.13052/jicts2245-800X.926, June 2021,
              <https://doi.org/10.13052/jicts2245-800X.926>.

   [Tian19]   Tian, B., Zhang, X., Zhai, E., Liu, H., Ye, Q., Wang, C.,
              Wu, X., Ji, Z., Sang, Y., Zhang, M., Yu, D., Tian, C.,
              Zheng, H., and B. Zhao, "Safely and automatically updating
              in-network ACL configurations with intent language",
              SIGCOMM '19: Proceedings of the ACM Special Interest Group
              on Data Communication, DOI 10.1145/3341302.3342088, August
              2019, <https://doi.org/10.1145/3341302.3342088>.

   [TMF-AUTO] Boasman-Patel, A., Sun, D., Wang, Y., Maitre, C.,
              Domingos, J., Troullides, Y., Mas, I., Traver, G., and G.
              Lupo, "Autonomous Networks: Empowering Digital
              Transformation For The Telecoms Industry", May 2019.

Acknowledgments

   This document has benefited from reviews, suggestions, comments, and
   proposed text provided by the following members listed in
   alphabetical order: Mehdi Bezahaf, Brian E. Carpenter, Laurent
   Ciavaglia, Benoit Claise, Alexander Clemm, Yehia Elkhatib, Jerome
   Francois, Pedro Andres Aranda Gutierrez, Daniel King, Branislav
   Meandzija, Bob Natale, Juergen Schoenwaelder, Xiaolin Song, and Jeff
   Tantsura.

   We thank Barbara Martini, Walter Cerroni, Molka Gharbaoui, and Davide
   Borsatti for contributing with their "A multi-level approach to IBN"
   PoC demonstration, a first attempt to adopt the intent classification
   methodology.

Contributors

   The following people all contributed to creating this document:

   Contributed significant text:

   Xueyuan Sun
   China Telecom


   Will (Shucheng) Liu
   Huawei


   Contributed text in early draft versions of this document:

   Ying Chen
   China Unicom


   John Strassner
   Huawei


   Weiping Xu
   Huawei


   Richard Meade
   Huawei


Authors' Addresses

   Chen Li
   China Telecom
   Xicheng District
   No.118 Xizhimennei street
   Beijing
   100035
   China
   Email: lichen6@chinatelecom.cn


   Olga Havel
   Huawei Technologies
   Ireland
   Email: olga.havel@huawei.com


   Adriana Olariu
   Huawei Technologies
   Ireland
   Email: adriana.olariu@huawei.com


   Pedro Martinez-Julia
   NICT
   Japan
   Email: pedro@nict.go.jp


   Jeferson Campos Nobre
   Federal University of Rio Grande do Sul (UFRGS)
   Porto Alegre-RS
   Brazil
   Email: jcnobre@inf.ufrgs.br


   Diego R. Lopez
   Telefonica I+D
   Don Ramon de la Cruz, 82
   28006 Madrid
   Spain
   Email: diego.r.lopez@telefonica.com