idnits 2.17.1 draft-sun-nmrg-intent-framework-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 10 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 249 has weird spacing: '...intents eligi...' -- The document date (July 8, 2019) is 1753 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC7575' is mentioned on line 105, but not defined == Unused Reference: 'RFC2119' is defined on line 494, but no explicit reference was found in the text == Unused Reference: 'RFC3198' is defined on line 499, but no explicit reference was found in the text == Unused Reference: 'RFC6020' is defined on line 504, but no explicit reference was found in the text == Unused Reference: 'RFC7285' is defined on line 507, but no explicit reference was found in the text == Unused Reference: 'RFC8328' is defined on line 511, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Q. Sun 2 Internet Draft China Telecom 3 Intended status: Informational W. Liu 4 Expires: January 2020 Huawei Technologies 5 K. Xie 6 Beijing University of Posts and Telecommunications 7 July 8, 2019 9 An Intent-driven Management Framework 10 draft-sun-nmrg-intent-framework-00 12 Status of this Memo 14 This Internet-Draft is submitted in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at 26 http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six 29 months and may be updated, replaced, or obsoleted by other documents 30 at any time. It is inappropriate to use Internet-Drafts as 31 reference material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on January 8, 2009. 35 Copyright Notice 37 Copyright (c) 2019 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with 45 respect to this document. Code Components extracted from this 46 document must include Simplified BSD License text as described in 47 Section 4.e of the Trust Legal Provisions and are provided without 48 warranty as described in the Simplified BSD License. 50 Abstract 52 Intent was defined as an abstract high-level policy (or instruction) 53 used to trigger network operations (not only configuration aspects, 54 but also continuous tuning to adjust the measured/actual network 55 state to an expected state). This document describes the intent- 56 driven management architecture, its key elements, and interfaces. 58 Table of Contents 60 1. Introduction ................................................. 2 61 2. Acronyms ..................................................... 3 62 3. Framework for Generic Intent-driven Management ............... 3 63 3.1. Overview ................................................ 3 64 3.2. Operation ............................................... 6 65 3.2.1 Intent layer ........................................... 6 66 (1) Intent management ..................................... 6 67 (2) Intent translation .................................... 7 68 (3) Verification module ................................... 8 69 (4) Decision module ....................................... 9 70 3.2.2 Control layer .......................................... 9 71 (1) Configuration delivery ............................... 10 72 (2) Network status collection ............................ 10 73 3.2.3 Network layer ......................................... 10 74 (1) Configuration execution .............................. 10 75 (2) Network status awareness ............................ 10 76 4. Security Considerations ..................................... 11 77 5. IANA Considerations ......................................... 11 78 6. Contributors ................................................ 11 79 7. Acknowledgments ............................................. 12 80 8. References .................................................. 12 81 8.1. Normative References ................................... 12 82 8.2. Informative References ................................. 12 84 1. Introduction 86 The digital transformation and booming applications and new services 87 (e.g., AR/VR) lead to a rapid growth in the variety and volume of 88 traffic forwarded by underlying networks (including data centers). 89 Existing network technologies and the limited operation and 90 management manpower, make it more challenging. To support efficient 91 and faster service delivery (by means of high level of automation) , 92 the network must evolve from a static resource management system to 93 a more dynamic system that consistently and continuousily meets 94 business goals. 96 The concept of Intent-driven management was proposed to deal with 97 this issue. This is a networking model in which high level 98 abstracted business requirements or business request, i.e., 99 "intents", are formally defined and then the network continuously 100 monitors whether these "intentions" are met. Such high-level 101 abstracted business request are translated into actions (including 102 configuration) and maintained by a set of management function blocks 103 in one or more network management systems. 105 [RFC7575] defines Intent as an abstract high-level policy used to 106 operate the network. Intent management system includes an interface 107 for users/applications to input requests and an engine to translate 108 the intents into the network actions and manage their lifecycle. 109 This document describes an Intent-driven architecture, its elements, 110 and interfaces. 112 2. Acronyms 114 CLI: Command Line Interface 116 SDO: Standards Development Organization 118 VPN: Virtual Private Network 120 3. Framework for Generic Intent-driven Management 122 This section briefly describes the design and operation of the 123 Intent-driven management framework. 125 3.1. Overview 127 Figure 1 shows a simplified functional architecture of how Intent is 128 used to manage a network (e.g., network element configuration falut, 129 performance and security mangement, etc.). 131 +-------------------------+-------------------------+ 132 | | | 133 | Operator | User / Application | 134 | | | 135 +----+--------------------+---------+---------------+ 136 |Intent model/request |experience 137 | | 138 +------------------------------------------------------+ 139 |Intent Layer | 140 | +--------------+ +---------------+ | 141 | | | | | | 142 | | Management | | Translation | | 143 +--------+ | | | | | | 144 | | | +--------------+ +---------------+ | 145 |Intent | |+-----------+ | 146 | | || Intent | | 147 |Designer+-->| Repository| | 148 | | || | | 149 | | |+-----------+ | 150 | | | +--------------+ +---------------+ | 151 | | | | | | Analyses | | 152 +--------+ | | Decision | | Verification | | 153 | +-|------------+ +----------------+ | 154 +----------------|-------------------------------------+ 155 | | | 156 | configuration |Verify |monitor 157 | | | 158 +-----------------\-------------------\--------\-----------+ 159 | | 160 | Control Layer | 161 | | 162 +----------------------------------------------------------+ 163 | Status Collection | Configuration 164 | | 165 +---------------\-----------------\--------\---------------+ 166 | | 167 | Network Element(i) | 168 | | 169 +----------------------------------------------------------+ 171 Figure 1 Intent-driven Management Framework 173 In the architecture of intent-driven management, the intent 174 orchestration layer (hereinafter referred to as intent layer) 175 consists of four functional modules, which are "intent management", 176 "translation", "verification", and "decision" module. 178 Combined with the request/experience from upper layer (including 179 operators, administrators,users or applications. The different roles 180 of identities in the network may cause different levels of 181 abstraction involved in the intent request. The term "user" in this 182 framework refers to all the entities who make intent requests), the 183 intent-driven management system can collect the intent request, map 184 out appropriate policy, verify correctness and then deploy 185 configuration automatically. 187 When the configuration is executed in the network (i.e. network 188 element) the verification module should verify the validity of 189 configuration implementation based on real-time statu. Therefore, 190 the effectiveness of the configuration is repeatedly verified and 191 monitored to ensure that the user's intent is effectively processed 192 and implemented. In case of any unexpected situation is encountered, 193 it can automatically make remedial measures instantly, and provide 194 feedback to the user to achieve a complete lifecycle. 196 In the intent-driven networking, the application layer or service 197 layer no longer directly interacts with network layer, but 198 communicates indirectly with the network layer through the 199 intermediate intent layer with certain technical agreement. 201 +---------------------------------+ 202 | Intent model | 203 | | 204 +---------------+-----------------+ 205 | 206 | 207 +---------------v-----------------+ 208 | Service / Policy model | 209 | | 210 +---------------+-----------------+ 211 | 212 +---------------v-----------------+ 213 | Device model(s) | 214 | | 215 +---------------------------------+ 216 Figure 2 The Model Process of Intent Transformation 218 Figure 2 presents the overall intent transformation process. At the 219 entrance, the user or administrator needs to express their desired 220 "intent" according to the intent model, which is collected by 221 management module in a high-level language. 223 With the help of policy database, the translation module and 224 decision module can analyze the intent model and transform it into 225 specific strategy or policy, namely service / policy model. 227 Eventually the policy will be mapped into concrete configuration 228 action which can be deployed and executed in device level, therefore 229 referred as device model. 231 The network elements used in this framework are: 233 Control Layer, which represents one or more entities that are able 234 to control the operation and management of a network infrastructure 235 (e.g., a network topology that consists of Network Elements). 237 Network Element, which can interact with local or remote Control 238 Layer in order to exchange information, such as configuration 239 information, policy enforcement capabilities, and network status. 241 3.2. Sample Operation 243 3.2.1 Intent layer 245 (1) Intent management 247 After receiving the user/application intent from the business layer, 248 the intent orchestration layer needs to manage and coordinate these 249 intents eligible intent will be further submitted to the intent 250 translation module for analysis and processing, and the ineligible 251 intent will be fed back to the user by the management module, for 252 further modification and adjustment; the management module also 253 needs to interact with the decision module, and may receive the 254 negative feedback from decision module when the configuration 255 execution does not work as expected, in which cases the management 256 module would require translation module to do secondary processing 257 (take optimization procedure or remedial solution). 259 In the process of intent demand, the module of the intent layer not 260 only processes once, but continuously verifies and updates the 261 configuration in the closed loop to finally realize the user's 262 intent demand, so the management module also needs to regulate the 263 life cycle of the intent demand. 265 In addition, because the intent needs to be from different 266 identities, they contain different levels of demands and 267 abstractions. The abstraction level of the intent demand can be 268 roughly divided into the following levels: 270 Device level (Level 0): In a traditional networking, the 271 configuration of the device can be manually performed by the network 272 administrator, such as configuring the ACL (Access Control List) of 273 the device to allow an IP X to access a port of the server; 275 Network level (level 1): In some partially automated networking, 276 network administrators usually do not manually configure specific 277 commands on specific underlying devices. Instead, they set 278 corresponding network permission settings through the controller, 279 such as setting an IP X can access a port of the server through an 280 access point AP 282 Abstract intent level 1 (level 2): In a fully automated networking, 283 we hope that the network configuration can be completed in the form 284 of intent demands, but the intent demands should include specific 285 details, for example: set " a user A can access a specific service 286 of a server in the campus from the internal network or the external 287 network. " 289 Abstract intent level 2 (level 3): In this level, we hope that the 290 network can be optimized spontaneously, and the intent defined at 291 this level is more abstract than the previous level, for example, a 292 specific group of users can access a specific service in any way; 294 Abstract intent level 3 (level 4): In this level, the network 295 belongs to a part of the autonomous network, and the network can 296 automatically decide a more appropriate configuration scheme, and 297 the expression of the intention can be more abstract, for example, " 298 Every user can access a service in a suitable way "; 300 Abstract intent level 4 (level 5): At the highest level of the 301 intent abstraction model, we hope that the network can achieve full 302 autonomy, automatically decision-making and spontaneous optimization 303 based on real-time network state information anytime and anywhere. 304 This level expresses the expectation that the network will decide 305 the solution autonomously and never fail. 307 According to different levels of intent demands, the configuration 308 should also be classified into different levels. Therefore, the 309 management module needs to handle and treat the levels of "intent"- 310 "configuration" one by one. 312 (2) Intent translation 313 The translation module needs to analyze the intent and formulate the 314 corresponding configuration based on network status and analysis 315 results in the intent-policy repository, and then output the 316 configuration plan to the verification module. When the negative 317 feedback of the management module is received subsequently, the 318 intent analysis and translation module is also responsible for the 319 dynamic adjustment and re-enactment of the strategy to finally 320 achieve the user's intention; if the positive feedback is received, 321 the configuration is handed over to the control layer. The scope of 322 intent includes several aspects including access control, bandwidth 323 management, QoS levels, security issue, energy consumption control, 324 etc., which enables application providers and users to reasonably 325 mobilize resources and self-service as needed. 327 In the process of analyzing intent demands, first,the translation 328 module needs to translat and split the semantics contained in the 329 intent demand, because user-initiated intent demands are often 330 complex and more natural-oriented, and to facilitate subsequent 331 processing, the translation module needs to be translated and 332 splited according to a specific model. In this step, the method and 333 result of natural language processing (NLP) in the field of 334 artificial intelligence (AI) can be used to train the AI agent as an 335 auxiliary, and the analysis result of the AI auxiliary module is 336 used as a reference for the translation module. 338 (3) Verification module 340 The verification module has two functions: one is the execution 341 verification of the configuration, that is, the configuration plan 342 obtained during the translation process needs to be verified whether 343 it can be executed in the actual network environment according to 344 the real-time network status, and provide relevant information to 345 the decision module as feedback; the second function is validity 346 verification, for the reason that, when the configuration is 347 actually executed, the network status may not change as expected, in 348 which cases, it is necessary to verify whether the execution of the 349 configuration works out as expected and whether the configuration 350 meets the user's intent. If the expected effect is achieved, the 351 verification result is fed back to the decision module; if the 352 verification fails, the "intent"-"configuration" translation 353 procedure needs to be performed again. 355 The network is dynamically changing, so network verification should 356 be continuous in real time. The verification module is responsible 357 for monitoring the global information in the network, especially 358 those that have an impact on the intent of the implementation. The 359 verification module needs to quickly reflect the monitoring 360 information to the decision module to ensure that the execution of 361 the configuration does not cause conflicts. 363 (4) Decision module 365 The decision module is responsible for the overall monitoring of the 366 network status and configuration. It can process the data 367 transmitted by the verification module, and then decide whether the 368 configuration can be delivered to control layer. The decision module 369 supports empirical knowledge from top administrators to help make 370 decisions. When the user's intent is not implemented or the network 371 status is getting abnormal, the decision module needs to make 372 optimization or remedial measures by notifing the intent management 373 module and the translation module to make prompt response. 375 5 Policy repository 377 Regarding the storage of the intent model and the policy model by 378 the policy repository, we must consider the different levels of the 379 intent model and the policy model, and also consider under what 380 conditions the data will be updated. Policy repository as a database 381 of "intent" - "configuration" information should be able to interact 382 with the intent management module and the translation module, 383 provide relevant data for the intent model for the intent management 384 module, and provide mapping between the "intent" and "configuration" 385 for the translation module. According to the identity of the user, 386 the abstraction level involved in different intent demands also 387 needs to be graded. For the policy repository, the mapping between 388 "intent" and "configuration" should be one-to-one correspondence at 389 the abstract level. 391 When the translation module finds that an "intent"-"configuration" 392 mapping relationship exists in the policy repository, it cannot be 393 directly deployed to the network layer, but also through the 394 executable verification of the verification module, and then the 395 decision-making module makes a decision whether to issue the 396 decision, because the execution of the configuration needs to 397 consider the actual network environment and state. When the 398 management module or the translation module obtains the intent model 399 or the configuration model that is not in the policy repository, 400 after the intent demand is implemented, the new mapping information 401 should also be updated by the management module into the policy 402 repository to ensure subsequent use. 404 3.2.2 Control layer 405 (1) Configuration delivery 407 In an intent-driven networking, in consideration of the 408 configuration set of the intent layer output, the intent layer 409 performs configuration control and further delivery to the control 410 layer through the downward interface to ensure that the 411 configuration can be smoothly delivered to the network layer for 412 execution. The configuration delivery module requires further fine- 413 grained distribution, according to different network structures such 414 as wired access or wireless access, virtual network infrastructure 415 or physical network facilities, to achieve the ability of different 416 networks to work together. 418 (2) Network status collection 420 The downward interface of the control layer should be able to 421 perceive the physical or logical topology of the underlying network 422 layer, network traffic, network device status, etc., and the upward 423 interface can transmit information to the intent layer to assist the 424 intent orchestration layer to formulate a reasonable scheduling 425 strategy and better utilize the capabilities of the intelligent 426 communication network. 428 3.2.3 Network layer 430 (1) Configuration execution 432 The configuration execution function can be configured with pre- 433 defined rules and templates, or can be fully dynamically configured 434 according to the controller: for example, through the control 435 protocol between the controller and the network forwarding device, 436 the network layer receives the result of the configuration control 437 function and performs the forwarding and processing of the 438 configuration. 440 (2) Network status awareness 442 In an intent-driven intelligent communication networking, the 443 sensing information collection function supports the collection of 444 network topology information, network traffic information, and 445 business path information, and can interact in real time through 446 dynamic protocols. Especially when the configuration is actually 447 executed, feedback information can be output to the network state 448 collection function for subsequent verification. 450 4. Security Considerations 452 This document does not have any Security Considerations. 454 5. IANA Considerations 456 This document has no actions for IANA. 458 6. Contributors 460 The following people all contributed to creating this document, 461 listed in alphabetical order: 463 Xueying Han 464 Institute of Network Technology, 465 Beijing University of Posts and Telecommunications, 466 Xitucheng Road, Haidian District, Beijing 100876 468 Email: hanxueying@bupt.edu.cn 470 Ruoshui Zhang 471 China Telecom, 472 No.118, Xizhimennei Street, Beijing 100035 473 P. R. China 475 Email: zrs_1995@bupt.edu.cn 477 Qiuhuan Ren 478 China Telecom, 479 No.118, Xizhimennei Street, Beijing 100035 480 P. R. China 482 Email: renqiuhuan123@bupt.edu.cn 484 7. Acknowledgments 486 This document has benefited from reviews, suggestions, comments and 487 proposed text provided by the following members, listed in 488 alphabetical order: Mohamed Boucadair. 490 8. References 492 8.1. Normative References 494 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 495 Requirement Levels", BCP 14, RFC 2119, March 1997. 497 8.2. Informative References 499 [RFC3198] Westerinen, A., Schnizlein, J., Strassner, J., 500 Scherling, M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, 501 J., Waldbusser, S., "Terminology for Intent-driven Management", RFC 502 3198, November 2001 504 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 505 Network Configuration Protocol (NETCONF)", RFC 6020, October 2010. 507 [RFC7285] R. Alimi, R. Penno, Y. Yang, S. Kiesel, S. Previdi, W. 508 Roome, S. Shalunov, R. Woundy "Application-Layer Traffic 509 Optimization (ALTO) Protocol", September 2014. 511 [RFC8328] Liu, W., Xie, C., Strassner, J., Karagiannis, G., Klyus, 512 M., Bi, J., Cheng, Y., and D. Zhang, "Policy-Based Management 513 Framework for the Simplified Use of Policy Abstractions (SUPA)", 514 March 2018. 516 Authors' Addresses 518 Qiong Sun 519 China Telecom 520 No.118, Xizhimennei Street, Beijing 100035 521 P. R. China 523 Email: sunqiong.bri@chinatelecom.cn 525 Will(Shucheng) Liu 526 Huawei Technologies 527 Bantian, Longgang District, Shenzhen 518129 528 P.R. China 530 Email: liushucheng@huawei.com 532 Kun Xie 533 School of Software Engineering, 534 Beijing University of Posts and Telecommunications 535 Xitucheng Road, Haidian District, Beijing 100876 536 P.R. China 538 Email: pat@bupt.edu.cn