Network Working Group Q. Sun Internet Draft China Telecom Intended status: Informational W. Liu Expires: January 2020 Huawei Technologies K. Xie Beijing University of Posts and Telecommunications July 8, 2019 An Intent-driven Management Framework draft-sun-nmrg-intent-framework-00 Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 8, 2009. Copyright Notice Copyright (c) 2019 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 (http://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. Code Components extracted from this Liu, et al. Expires January 8, 2020 [Page 1] Internet-Draft Intent-based management framework July 2019 document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Abstract Intent was defined as an abstract high-level policy (or instruction) used to trigger network operations (not only configuration aspects, but also continuous tuning to adjust the measured/actual network state to an expected state). This document describes the intent- driven management architecture, its key elements, and interfaces. Table of Contents 1. Introduction ................................................. 2 2. Acronyms ..................................................... 3 3. Framework for Generic Intent-driven Management ............... 3 3.1. Overview ................................................ 3 3.2. Operation ............................................... 6 3.2.1 Intent layer ........................................... 6 (1) Intent management ..................................... 6 (2) Intent translation .................................... 7 (3) Verification module ................................... 8 (4) Decision module ....................................... 9 3.2.2 Control layer .......................................... 9 (1) Configuration delivery ............................... 10 (2) Network status collection ............................ 10 3.2.3 Network layer ......................................... 10 (1) Configuration execution .............................. 10 (2) Network status awareness ............................ 10 4. Security Considerations ..................................... 11 5. IANA Considerations ......................................... 11 6. Contributors ................................................ 11 7. Acknowledgments ............................................. 12 8. References .................................................. 12 8.1. Normative References ................................... 12 8.2. Informative References ................................. 12 1. Introduction The digital transformation and booming applications and new services (e.g., AR/VR) lead to a rapid growth in the variety and volume of traffic forwarded by underlying networks (including data centers). Existing network technologies and the limited operation and management manpower, make it more challenging. To support efficient and faster service delivery (by means of high level of automation) , Sun, et al. Expires January 8, 2020 [Page 2] Internet-Draft Intent-based management framework July 2019 the network must evolve from a static resource management system to a more dynamic system that consistently and continuousily meets business goals. The concept of Intent-driven management was proposed to deal with this issue. This is a networking model in which high level abstracted business requirements or business request, i.e., "intents", are formally defined and then the network continuously monitors whether these "intentions" are met. Such high-level abstracted business request are translated into actions (including configuration) and maintained by a set of management function blocks in one or more network management systems. [RFC7575] defines Intent as an abstract high-level policy used to operate the network. Intent management system includes an interface for users/applications to input requests and an engine to translate the intents into the network actions and manage their lifecycle. This document describes an Intent-driven architecture, its elements, and interfaces. 2. Acronyms CLI: Command Line Interface SDO: Standards Development Organization VPN: Virtual Private Network 3. Framework for Generic Intent-driven Management This section briefly describes the design and operation of the Intent-driven management framework. 3.1. Overview Figure 1 shows a simplified functional architecture of how Intent is used to manage a network (e.g., network element configuration falut, performance and security mangement, etc.). Sun, et al. Expires January 8, 2020 [Page 3] Internet-Draft Intent-based management framework July 2019 +-------------------------+-------------------------+ | | | | Operator | User / Application | | | | +----+--------------------+---------+---------------+ |Intent model/request |experience | | +------------------------------------------------------+ |Intent Layer | | +--------------+ +---------------+ | | | | | | | | | Management | | Translation | | +--------+ | | | | | | | | | +--------------+ +---------------+ | |Intent | |+-----------+ | | | || Intent | | |Designer+-->| Repository| | | | || | | | | |+-----------+ | | | | +--------------+ +---------------+ | | | | | | | Analyses | | +--------+ | | Decision | | Verification | | | +-|------------+ +----------------+ | +----------------|-------------------------------------+ | | | | configuration |Verify |monitor | | | +-----------------\-------------------\--------\-----------+ | | | Control Layer | | | +----------------------------------------------------------+ | Status Collection | Configuration | | +---------------\-----------------\--------\---------------+ | | | Network Element(i) | | | +----------------------------------------------------------+ Figure 1 Intent-driven Management Framework In the architecture of intent-driven management, the intent orchestration layer (hereinafter referred to as intent layer) consists of four functional modules, which are "intent management", "translation", "verification", and "decision" module. Sun, et al. Expires January 8, 2020 [Page 4] Internet-Draft Intent-based management framework July 2019 Combined with the request/experience from upper layer (including operators, administrators,users or applications. The different roles of identities in the network may cause different levels of abstraction involved in the intent request. The term "user" in this framework refers to all the entities who make intent requests), the intent-driven management system can collect the intent request, map out appropriate policy, verify correctness and then deploy configuration automatically. When the configuration is executed in the network (i.e. network element) the verification module should verify the validity of configuration implementation based on real-time statu. Therefore, the effectiveness of the configuration is repeatedly verified and monitored to ensure that the user's intent is effectively processed and implemented. In case of any unexpected situation is encountered, it can automatically make remedial measures instantly, and provide feedback to the user to achieve a complete lifecycle. In the intent-driven networking, the application layer or service layer no longer directly interacts with network layer, but communicates indirectly with the network layer through the intermediate intent layer with certain technical agreement. +---------------------------------+ | Intent model | | | +---------------+-----------------+ | | +---------------v-----------------+ | Service / Policy model | | | +---------------+-----------------+ | +---------------v-----------------+ | Device model(s) | | | +---------------------------------+ Figure 2 The Model Process of Intent Transformation Figure 2 presents the overall intent transformation process. At the entrance, the user or administrator needs to express their desired "intent" according to the intent model, which is collected by management module in a high-level language. Sun, et al. Expires January 8, 2020 [Page 5] Internet-Draft Intent-based management framework July 2019 With the help of policy database, the translation module and decision module can analyze the intent model and transform it into specific strategy or policy, namely service / policy model. Eventually the policy will be mapped into concrete configuration action which can be deployed and executed in device level, therefore referred as device model. The network elements used in this framework are: Control Layer, which represents one or more entities that are able to control the operation and management of a network infrastructure (e.g., a network topology that consists of Network Elements). Network Element, which can interact with local or remote Control Layer in order to exchange information, such as configuration information, policy enforcement capabilities, and network status. 3.2. Sample Operation 3.2.1 Intent layer (1) Intent management After receiving the user/application intent from the business layer, the intent orchestration layer needs to manage and coordinate these intents eligible intent will be further submitted to the intent translation module for analysis and processing, and the ineligible intent will be fed back to the user by the management module, for further modification and adjustment; the management module also needs to interact with the decision module, and may receive the negative feedback from decision module when the configuration execution does not work as expected, in which cases the management module would require translation module to do secondary processing (take optimization procedure or remedial solution). In the process of intent demand, the module of the intent layer not only processes once, but continuously verifies and updates the configuration in the closed loop to finally realize the user's intent demand, so the management module also needs to regulate the life cycle of the intent demand. In addition, because the intent needs to be from different identities, they contain different levels of demands and Sun, et al. Expires January 8, 2020 [Page 6] Internet-Draft Intent-based management framework July 2019 abstractions. The abstraction level of the intent demand can be roughly divided into the following levels: Device level (Level 0): In a traditional networking, the configuration of the device can be manually performed by the network administrator, such as configuring the ACL (Access Control List) of the device to allow an IP X to access a port of the server; Network level (level 1): In some partially automated networking, network administrators usually do not manually configure specific commands on specific underlying devices. Instead, they set corresponding network permission settings through the controller, such as setting an IP X can access a port of the server through an access point AP Abstract intent level 1 (level 2): In a fully automated networking, we hope that the network configuration can be completed in the form of intent demands, but the intent demands should include specific details, for example: set " a user A can access a specific service of a server in the campus from the internal network or the external network. " Abstract intent level 2 (level 3): In this level, we hope that the network can be optimized spontaneously, and the intent defined at this level is more abstract than the previous level, for example, a specific group of users can access a specific service in any way; Abstract intent level 3 (level 4): In this level, the network belongs to a part of the autonomous network, and the network can automatically decide a more appropriate configuration scheme, and the expression of the intention can be more abstract, for example, " Every user can access a service in a suitable way "; Abstract intent level 4 (level 5): At the highest level of the intent abstraction model, we hope that the network can achieve full autonomy, automatically decision-making and spontaneous optimization based on real-time network state information anytime and anywhere. This level expresses the expectation that the network will decide the solution autonomously and never fail. According to different levels of intent demands, the configuration should also be classified into different levels. Therefore, the management module needs to handle and treat the levels of "intent"- "configuration" one by one. (2) Intent translation Sun, et al. Expires January 8, 2020 [Page 7] Internet-Draft Intent-based management framework July 2019 The translation module needs to analyze the intent and formulate the corresponding configuration based on network status and analysis results in the intent-policy repository, and then output the configuration plan to the verification module. When the negative feedback of the management module is received subsequently, the intent analysis and translation module is also responsible for the dynamic adjustment and re-enactment of the strategy to finally achieve the user's intention; if the positive feedback is received, the configuration is handed over to the control layer. The scope of intent includes several aspects including access control, bandwidth management, QoS levels, security issue, energy consumption control, etc., which enables application providers and users to reasonably mobilize resources and self-service as needed. In the process of analyzing intent demands, first,the translation module needs to translat and split the semantics contained in the intent demand, because user-initiated intent demands are often complex and more natural-oriented, and to facilitate subsequent processing, the translation module needs to be translated and splited according to a specific model. In this step, the method and result of natural language processing (NLP) in the field of artificial intelligence (AI) can be used to train the AI agent as an auxiliary, and the analysis result of the AI auxiliary module is used as a reference for the translation module. (3) Verification module The verification module has two functions: one is the execution verification of the configuration, that is, the configuration plan obtained during the translation process needs to be verified whether it can be executed in the actual network environment according to the real-time network status, and provide relevant information to the decision module as feedback; the second function is validity verification, for the reason that, when the configuration is actually executed, the network status may not change as expected, in which cases, it is necessary to verify whether the execution of the configuration works out as expected and whether the configuration meets the user's intent. If the expected effect is achieved, the verification result is fed back to the decision module; if the verification fails, the "intent"-"configuration" translation procedure needs to be performed again. The network is dynamically changing, so network verification should be continuous in real time. The verification module is responsible for monitoring the global information in the network, especially those that have an impact on the intent of the implementation. The Sun, et al. Expires January 8, 2020 [Page 8] Internet-Draft Intent-based management framework July 2019 verification module needs to quickly reflect the monitoring information to the decision module to ensure that the execution of the configuration does not cause conflicts. (4) Decision module The decision module is responsible for the overall monitoring of the network status and configuration. It can process the data transmitted by the verification module, and then decide whether the configuration can be delivered to control layer. The decision module supports empirical knowledge from top administrators to help make decisions. When the user's intent is not implemented or the network status is getting abnormal, the decision module needs to make optimization or remedial measures by notifing the intent management module and the translation module to make prompt response. 5 Policy repository Regarding the storage of the intent model and the policy model by the policy repository, we must consider the different levels of the intent model and the policy model, and also consider under what conditions the data will be updated. Policy repository as a database of "intent" - "configuration" information should be able to interact with the intent management module and the translation module, provide relevant data for the intent model for the intent management module, and provide mapping between the "intent" and "configuration" for the translation module. According to the identity of the user, the abstraction level involved in different intent demands also needs to be graded. For the policy repository, the mapping between "intent" and "configuration" should be one-to-one correspondence at the abstract level. When the translation module finds that an "intent"-"configuration" mapping relationship exists in the policy repository, it cannot be directly deployed to the network layer, but also through the executable verification of the verification module, and then the decision-making module makes a decision whether to issue the decision, because the execution of the configuration needs to consider the actual network environment and state. When the management module or the translation module obtains the intent model or the configuration model that is not in the policy repository, after the intent demand is implemented, the new mapping information should also be updated by the management module into the policy repository to ensure subsequent use. 3.2.2 Control layer Sun, et al. Expires January 8, 2020 [Page 9] Internet-Draft Intent-based management framework July 2019 (1) Configuration delivery In an intent-driven networking, in consideration of the configuration set of the intent layer output, the intent layer performs configuration control and further delivery to the control layer through the downward interface to ensure that the configuration can be smoothly delivered to the network layer for execution. The configuration delivery module requires further fine- grained distribution, according to different network structures such as wired access or wireless access, virtual network infrastructure or physical network facilities, to achieve the ability of different networks to work together. (2) Network status collection The downward interface of the control layer should be able to perceive the physical or logical topology of the underlying network layer, network traffic, network device status, etc., and the upward interface can transmit information to the intent layer to assist the intent orchestration layer to formulate a reasonable scheduling strategy and better utilize the capabilities of the intelligent communication network. 3.2.3 Network layer (1) Configuration execution The configuration execution function can be configured with pre- defined rules and templates, or can be fully dynamically configured according to the controller: for example, through the control protocol between the controller and the network forwarding device, the network layer receives the result of the configuration control function and performs the forwarding and processing of the configuration. (2) Network status awareness In an intent-driven intelligent communication networking, the sensing information collection function supports the collection of network topology information, network traffic information, and business path information, and can interact in real time through dynamic protocols. Especially when the configuration is actually executed, feedback information can be output to the network state collection function for subsequent verification. Sun, et al. Expires January 8, 2020 [Page 10] Internet-Draft Intent-based management framework July 2019 4. Security Considerations This document does not have any Security Considerations. 5. IANA Considerations This document has no actions for IANA. 6. Contributors The following people all contributed to creating this document, listed in alphabetical order: Xueying Han Institute of Network Technology, Beijing University of Posts and Telecommunications, Xitucheng Road, Haidian District, Beijing 100876 Email: hanxueying@bupt.edu.cn Ruoshui Zhang China Telecom, No.118, Xizhimennei Street, Beijing 100035 P. R. China Email: zrs_1995@bupt.edu.cn Qiuhuan Ren China Telecom, No.118, Xizhimennei Street, Beijing 100035 P. R. China Email: renqiuhuan123@bupt.edu.cn Sun, et al. Expires January 8, 2020 [Page 11] Internet-Draft Intent-based management framework July 2019 7. Acknowledgments This document has benefited from reviews, suggestions, comments and proposed text provided by the following members, listed in alphabetical order: Mohamed Boucadair. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 8.2. Informative References [RFC3198] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J., Waldbusser, S., "Terminology for Intent-driven Management", RFC 3198, November 2001 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, October 2010. [RFC7285] R. Alimi, R. Penno, Y. Yang, S. Kiesel, S. Previdi, W. Roome, S. Shalunov, R. Woundy "Application-Layer Traffic Optimization (ALTO) Protocol", September 2014. [RFC8328] Liu, W., Xie, C., Strassner, J., Karagiannis, G., Klyus, M., Bi, J., Cheng, Y., and D. Zhang, "Policy-Based Management Framework for the Simplified Use of Policy Abstractions (SUPA)", March 2018. Sun, et al. Expires January 8, 2020 [Page 12] Internet-Draft Intent-based management framework July 2019 Authors' Addresses Qiong Sun China Telecom No.118, Xizhimennei Street, Beijing 100035 P. R. China Email: sunqiong.bri@chinatelecom.cn Will(Shucheng) Liu Huawei Technologies Bantian, Longgang District, Shenzhen 518129 P.R. China Email: liushucheng@huawei.com Kun Xie School of Software Engineering, Beijing University of Posts and Telecommunications Xitucheng Road, Haidian District, Beijing 100876 P.R. China Email: pat@bupt.edu.cn Sun, et al. Expires January 8, 2020 [Page 13]