idnits 2.17.00 (12 Aug 2021) /tmp/idnits1427/draft-xia-ibnemo-icim-01.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 178 has weird spacing: '...etailed plan ...' == Line 195 has weird spacing: '...N), and this ...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (November 30, 2015) is 2364 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Y. Xia, Ed. 3 Intended Status: Standards Track T. Zhou, Ed. 4 Expires: November 23, 2015 Y. Zhang, Ed. 5 S. Hares 6 Huawei 7 P. Aranda 8 D. Lopez 9 Telefornica 10 J. Crowcroft 11 Cambridge University 12 Y. Zhang 13 China Unicom 14 November 30, 2015 16 Intent Common Information Model 17 draft-xia-ibnemo-icim-01 19 Abstract 21 Intent Common Information Model (ICIM) defines a unified model for 22 expressing different layers' intent whatever role, responsibility, 23 knowledge, etc. This document provides an information model to be 24 inherited and expanded to construct specific intent model in 25 different areas. According to this information model, network intent 26 model is put forward which can satisfy users' need in different 27 layers, such as, end-users, business developers, and network 28 administers. 30 Status of this Memo 32 This Internet-Draft is submitted to IETF in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF), its areas, and its working groups. Note that 37 other groups may also distribute working documents as 38 Internet-Drafts. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 The list of current Internet-Drafts can be accessed at 46 http://www.ietf.org/1id-abstracts.html 47 The list of Internet-Draft Shadow Directories can be accessed at 48 http://www.ietf.org/shadow.html 50 Copyright and License Notice 52 Copyright (c) 2015 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2. Intent Common Information Model Overview . . . . . . . . . . . 4 70 2.1 Elements . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 2.1.1 User . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 2.1.2 Context . . . . . . . . . . . . . . . . . . . . . . . . 5 73 2.1.3 Object . . . . . . . . . . . . . . . . . . . . . . . . 5 74 2.1.4 Result . . . . . . . . . . . . . . . . . . . . . . . . 6 75 2.1.5 Operation . . . . . . . . . . . . . . . . . . . . . . . 6 76 2.2 Relationships in ICIM . . . . . . . . . . . . . . . . . . . 7 77 2.2.1 Relationship between Result and Operation . . . . . . . 7 78 2.2.2 Relationship between Object and Operation . . . . . . . 7 79 2.2.3 Relationship between Object and Result . . . . . . . . 8 80 2.3 Intent and Policy . . . . . . . . . . . . . . . . . . . . . 8 81 2.4 Role-based Intent . . . . . . . . . . . . . . . . . . . . . 8 82 3. Intent Modeling . . . . . . . . . . . . . . . . . . . . . . . 8 83 3.1 Notation . . . . . . . . . . . . . . . . . . . . . . . . . 9 84 3.2 Intent overview . . . . . . . . . . . . . . . . . . . . . . 9 85 3.3 Top level intent expression . . . . . . . . . . . . . . . . 10 86 3.4 Objects in the network . . . . . . . . . . . . . . . . . . 10 87 3.5 Type of result . . . . . . . . . . . . . . . . . . . . . . 11 88 3.6 Operation composition . . . . . . . . . . . . . . . . . . . 12 89 4 Security Considerations . . . . . . . . . . . . . . . . . . . . 14 90 5 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 14 91 6 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 92 7 Informative References . . . . . . . . . . . . . . . . . . . . 14 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 95 1 Introduction 97 Network operations have traditionally been designed bottom-up 98 starting with low level device interfaces designed by protocol 99 experts.In order that interfaces could be wildly used by various 100 users, information details are exposed as much as possible. It 101 enables better control of devices, but leaves huge burden of 102 selecting useful information to users without well training. Since 103 the north bound interface (NBI) is used by network users, a more 104 appropriate design is to express user intent and abstract the network 105 from the top down. The intent base NBI expresses what a network 106 service consumer (e.g., application, operator) requires from the 107 network but it does not completely specify or constrain how that 108 service may or should be delivered by the network. The intent is 109 expected to be independent of protocols, network interface styles, 110 vendor features, media attributes, or any other network 111 implementations. 113 Intent Common Information Model (ICIM) specifies a generic model for 114 expressing key components of intent interface and the relationship 115 between these components. This document provides a common model which 116 could be inherited from and expanded to construct specific intent 117 interface in dedicated areas. According to this information model, 118 intent interface in network area can satisfy users' intention in 119 different roles, such as, end-users, business developers, network 120 administers, etc 122 1.1 Terminology 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in RFC 2119 [RFC2119]. 128 2. Intent Common Information Model Overview 130 Intent Common Information Model aims to specify a unified information 131 model which satisfied different areas, scenarios, and other 132 constraints. So, it is a complete and detailed information model to 133 define the constituent elements of intent. However, not all elements 134 need to be present when mapping this model to a specific data model, 135 since some of the elements can be obtained by system automatically. 137 From the overall perspective, construction elements of intent can be 138 described as: 140 -user of intent who author and own this intent 142 -intent content which is a desired purpose and 143 -the specific context which is the background circumstance 144 information. 146 Furthermore, in general, person's intent content usually describes 147 the ultimate state of some objects or applies actions to these 148 objects. So intent content can be abstracted into further: 150 -object which is the target for intent 152 -result which is a desired state and 154 -operation which is the specific actions to achieve a purpose. 156 2.1 Elements 158 2.1.1 User 160 User is an abstract class which specifies the subject and owner to 161 express the intent. It is a performance of roles in real world, that 162 is, each user serves as a role or a combination of roles actually. 163 For example, end-users, business designers, network administrators 164 are all instances of User class which act as specific roles. When a 165 user is labeled as a role, he will have the desire and requirement to 166 express intent belonged to this role. Owning to different network 167 abstraction views, intent is different for specific user when this 168 information model is applied to specific scenario. 170 Though one user serves as one role in most cases, it is sensible and 171 acceptable that one user serves as multiple roles and intent of these 172 users may involve more functions and huge operation scope. 174 2.1.2 Context 176 Context is an abstraction class which refers to a set of specific 177 background information such as, timer, price, and so on. Context has 178 a huge influence on a person designing a detailed plan or selecting 179 the best program to achieve a purpose. For example, when an 180 enterprise plans to build a dedicated connection between two sites, 181 price and distance will be the context in this scenario. While may 182 not be part of how an entity expresses or executes some intent, it is 183 a factor that must be considered with the expression of intent. 185 2.1.3 Object 187 Object is an abstract class which refers an abstract class which 188 defines some entities affected or managed by intent. For the 189 management, users could manage life cycle of the objects through some 190 concrete operations, such as, create, update, delete, etc. In 191 addition, users could use other specific operations to affect the 192 behavior of managed objects. For example, a business designer want 193 all traffic be filtered by a special firewall. The object of this 194 business designers intent could be the all traffic flowing on a 195 specific network (e.g. L3VPN), and this intent impacts the 196 forwarding behavior of the traffic network. Object is different in 197 specific area. In network area, object is an aggregation class with 198 node, connection and flow. For objects, users could construct some 199 specific objects to achieve intent, and it is also allowed for users 200 to assign intent to existing resources which is physical/virtual 201 devices or defined by other ways. 203 2.1.4 Result 205 Result is a type of intent which refers to an final state or 206 something an individual wants to achieve. This type of intent shields 207 difference and diversity of an environment away from the users' 208 intent. The person just describes the final state of objects without 209 worrying about how to achieve it. For example, a result could be that 210 the company accesses any sites on the Internet safely. It just 211 defines a result that ignores technology details, such as, firewall, 212 ACL, and so on. 214 In addition to the expecting state, violation is another special 215 state which has an important status when achieving integral 216 compliance. For example, a typical scenario is that one specific 217 tenant does not want his virtual machines to share a some hypervisor 218 with other tenants. This type of result just shows the undesired 219 state which express users' intent, so this kind of intent should be 220 another type of result. 222 2.1.5 Operation 224 Operation is a type of intent which refers to some specific actions 225 an individual desires to take for realizing the purpose. This type of 226 intent formulates explicit plan to realize a purpose which may take a 227 better control of the whole system. According to the diversity of 228 system support capability, there are large sets of operations for 229 users to take. 231 Generally, operations can be divided into two categories. One is 232 action without condition. For example, create a virtual machine. This 233 kind of operation defines a concrete action which is executed 234 immediately without any trigger. The other is action with condition. 235 For this kind of operations, condition is a trigger for the action. 236 And actions will not be executed immediately until the condition 237 clause is tested to be true. For example, "do load balancing when the 238 utilization of a link exceeds 80%". In this example, "utilization of 239 a link > 80%" is the trigger, and "do load balancing" is the action. 240 Action will not be executed until the trigger is true. Actions are 241 different according to users' role which has different abstraction 242 views. And actions will not be detailed configurations in devices, 243 but high-level and packaged functions which are translated into 244 configurations. For example, the service providers' action "do load 245 balancing" is device independent, and network operators' action may 246 configure load balance pools depending on specific devices. 248 2.2 Relationships in ICIM 250 2.2.1 Relationship between Result and Operation 252 Users are free to express their intent, no matter it is an final 253 result or specific operations in their mind, but there are some 254 relationships between these two basic types of intent. Result refers 255 to an ultimate and relatively permanent status, regardless which ways 256 to maintain it. However, operations specify what kinds of action need 257 to take explicitly, which more focus on temporary or specific 258 behavior to achieve some goal. One typical service scenario is that 259 all links' utilization should not exceed 80%. By way of Result, the 260 intent will be expecting all links' utilizations are smaller than 80% 261 (or avoiding any link' utilization exceeds 80%). By way of Operation, 262 the intent will be if links' utilization exceeds 80%, redirect some 263 flows to other links (or some other actions could achieve this 264 goal). 266 For result, users just need to express the goal without worrying how 267 to implement it in a specific system which allows users to focus on 268 real requirement. To achieve the result, it needs some reasoning 269 mechanisms to transfer it to real executable operations which are 270 supported by specific system. So in a specific scenario, a result can 271 generate a set of concrete operations. For the above example, if user 272 just expresses the result, that is, all links' utilizations are 273 smaller than 80%. The system will choose suitable operations to 274 achieve this status automatically, i.e., expand the capacity of links 275 whose utilization exceed 80%, or redirect flows to other links whose 276 capacities are far less than 80%. 278 2.2.2 Relationship between Object and Operation 280 Operation refers to some specific actions on some objects, so object 281 is the target of an action. In general, any action will include some 282 objects to execute this action. When users want to execute some 283 actions to achieve goals, they may construct the target objects and 284 assign specific actions on them, and it is allowed for users to use 285 existing resources to do some operations. Though object is the target 286 of action, it offers the constraint for optional operations. For 287 example, for a virtual machine, the optional operations are create, 288 delete, migrate, etc. 290 2.2.3 Relationship between Object and Result 292 Result refers to some final state for some objects. This type of 293 intent does not define which specific operations to take, but only 294 express the desired state of objects. So it is independent on 295 objects' concrete capability. For example, intent is all virtual 296 machines' CPU utilization could not exceed 80%. It does not assign 297 specific operations. So reasoning mechanism will choose suitable 298 operations to satisfy this intent, such as, migrate virtual machine 299 or expand it. 301 2.3 Intent and Policy 303 In industry, Policy already has a clear definition, such as in 304 RFC3060. Policy rule consists of an event, a set of conditions and a 305 set of actions. When an event occurs, actions will be taken until 306 condition clauses are evaluated to be true. 308 As mentioned above, intent refers to a purpose in achieving result or 309 performing operation. The intent has a larger scope compared with the 310 policy since Intent can express both result and operation. On one 311 hand if a result is described by intent, there may be no specific 312 action given to show how to achieve this intent. On the other hand, 313 if operation described by intent, conditions of action is optional. 314 Policy is a specific form of operation in intent. 316 2.4 Role-based Intent 318 In an integrated system, roles are divided into several categories 319 according to the division of work, architecture of system, etc. In 320 network system, network abstraction will be quite different in the 321 perspective of each role. So intent has strong dependencies on roles. 322 Intent expressed by different categories of roles will focus on 323 different points and have different intent expression. 325 For example, if an agent is labeled as service provider role, he may 326 just care about the high-level services, such as, security 327 communication. And if he is labeled as network architecture role, he 328 will care about the details of the whole architecture. 330 3. Intent Modeling 332 This section defines the concept and hierarchy of intent, and 333 describes the Intent Common Information Model. 335 3.1 Notation 337 The notation used in this document is adapted from the UML (United 338 Modeling Language). We will use the UML for the intent information 339 modeling. This section listed symbols that will be used in this 340 document for relationships among information models. 342 --> 344 Stands for the association relationship. Association represents the 345 static relationship shared among the objects of two classes. 347 --A 349 Stands for the aggregation relationship. Aggregation is a variant of 350 the "has a" association relationship; aggregation is more specific 351 than association. It is an association that represents a part-whole 352 or part-of relationship. Aggregation can occur when a class is a 353 collection or container of other classes, but the contained classes 354 do not have a strong lifecycle dependency on the container. The 355 contents of the container are not automatically destroyed when the 356 container is. 358 --C 360 Stands for the composition relationship. Composition is a stronger 361 variant of the "has a" association relationship. It is more specific 362 than aggregation. Composition usually has a strong lifecycle 363 dependency between instances of the container class and instances of 364 the contained class. If the container is destroyed, normally every 365 instance that it contains is destroyed as well. 367 --G 369 Stands for the generalization relationship. The Generalization 370 indicates that one of the two related classes (the subclass) is 371 considered to be a specialized form of the other (the super type) and 372 the super class is considered a 'Generalization' of the subclass. In 373 practice, this means that any instance of the subtype is also an 374 instance of the super class. 376 3.2 Intent overview 378 In general, intent is one's specific mental activity, so it strongly 379 depends on the subject. Different users may have different intent. In 380 addition, context, omitted usually, is an important factor when 381 achieving purpose, which offers necessary background information to 382 impact the decision. It illustrates the overview of the intent. 383 Figure 1 indicates that the user has intent in some context. For 384 example, an enterprise wants to block all http traffic in work time. 385 In this intent, the user is the enterprise, the intent is to block 386 all http traffic in the work hours, and the context includes the 387 definition of the "enterprise" and the "work hours". 389 +------+ has +--------+ in +---------+ 390 | user +-------->+ intent +------->+ context | 391 +------+ +--------+ +---------+ 393 Figure 1 general prescription for intent 395 3.3 Top level intent expression 397 In Cambridge Dictionaries, the definition of "intent" is the fact 398 that you want and plan to do something. So, in general, intent refers 399 to an agent's purpose on getting the result or performing some 400 specific operation. In specific areas, these results or operations 401 will relate to some objects. Figure 2 describes the general 402 expression of intent. 404 +----------+ 405 | intent | 406 +-C--A--A--+ 407 | | | 408 +-----------+ | +------------+ 409 | | | 410 +---+----+ +---+----+ +-----+-----+ 411 | object | | result | | operation | 412 +--------+ +--------+ +-----------+ 414 Figure 2 intent expression 416 One type of intent is to express key operations that a user wants to 417 execute. The underlying intent system can generate a complete 418 operation list from user's request. The other type of intent is to 419 express the result or state without dictating any operations. 421 For example, intent of a user may be a result without defining how to 422 realize it, such as, requiring security communication between two 423 sites, or dictate some detailed operations in order to achieve a 424 purpose, such as, filtering all traffics by firewall between these 425 two sites. 427 3.4 Objects in the network 429 Object is an abstraction class which can be inherited from and 430 expanded in different area. It, cared about by users, represents the 431 target of result and operations. In network area, the object, i.e. 432 the target of intent, can be generalized into Node, Connection and 433 Flow, as shown in Figure 3. 435 +------+ 436 +------+ node | 437 | +------+ 438 +--------+G+-+ 439 | | +------------+ 440 | object |G+--------+ connection | 441 | | +------------+ 442 +--------+G+-+ 443 | +------+ 444 +------+ flow | 445 +------+ 447 Figure 3 common objects in network area 449 The Node represents the functions a network node may provide in a 450 network such as network services, forwarding functions (firewall, 451 load balancer, virtual router, and others), or a group of network 452 elements. A group of network elements can be a subnet, an autonomous 453 system, or a confederation of autonomous systems. 455 The Connection describes the link resources between two nodes. These 456 link resources construct the foundation of communications between 457 different nodes. User could take connection as physical link, and 458 assign bandwidth on it. 460 The Flow refers to the traffic in network which describes data 461 packets have some certain common characters. Flow model describes the 462 connectivity in virtual network, namely, if users want to describe 463 the communications between nodes without direct connection, they have 464 to define the flow and assign operation to allow the flow. 466 3.5 Type of result 468 Result refers to the final state which is expected or avoided. Figure 469 4 describes two types of result. Both of the results just show the 470 performance of some objects, without caring about how to reach them. 472 Result could be expressed as a set of logic clause connected with 473 propositional literals including AND, OR and NOT. The logic clause 474 could be described as an expression with relational operators, such 475 as equal, greater-than, less-than, belong-to. 477 With this model, users could express the desired state as an 478 expression. System will resolve the expression and seek ways to make 479 it true. The result will be achieved when the expression is evaluated 480 to be true. The typical examples are shown as follows: 482 - For example, a user may express an intent as the network link 483 utilization must less than 80%. This expression is a type of result 484 which describes an expected state. The left operand is the 485 utilization of all links, the right operand is 80%, and the operator 486 is less-than. 488 - Another example is an enterprise wants the development team and 489 sales team not to share a common link. In this intent, the left 490 operand is the union of the link set of development team occupied and 491 the link set of sales team occupied. The operation will be equal, and 492 the right operator is an empty set. 494 Though a unified information model for the Result is proposed in 495 here, it is still a preliminary version which just expresses the 496 basic components. The formalization and standardization are still 497 open issues need to be studied further. More comprehensive and 498 detailed manifestations will be added in the next version. 500 +--------+ 501 | result | 502 +-G----G-+ 503 | | 504 +-----+ +----+ 505 | | 506 +---+----+ +---+---+ 507 | expect | | avoid | 508 +--------+ +-------+ 510 Figure 4 expression of Result 512 3.6 Operation composition 514 Operation refers to some specific actions in order to achieve some 515 purposes. An operation must have some actions. However, if condition 516 and constraint can be optionally defined in operations, it depends on 517 specific scenario and users' requirement. Once a condition is 518 involved in operation, actions will not be executed immediately until 519 condition is true. In additional, constraint restricts action itself 520 or the scope of action. 522 For example, redirect traffic to back-up link when the utilization of 523 current link exceeds 80%, except the flow from VIP user. In this 524 scenario, the condition is link utilization exceeds 80%, the action 525 is redirect traffic, and the constraint is VIP flow could not be 526 redirected. 528 +-----------+ 529 | operation | 530 +-A---C---A-+ 531 | | | 532 +-------------+ | +--------------+ 533 | | | 534 | | | 535 +-----+-----+ +---+----+ +------+-----+ 536 | condition | | action | | constraint | 537 +-----------+ +--------+ +------------+ 539 Figure 5 composition of operation 541 4 Security Considerations 543 TBD 545 5 IANA Considerations 547 This draft includes no request to IANA. 549 6 Acknowledgements 551 The authors would like to thanks the valuable comments made by Wei 552 Cao, Sheng Jiang, Zhigang Ji, Xuewei Wang, Shixing Liu, Yan Zhang. 554 7 Informative References 556 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 557 Requirement Levels", BCP 14, RFC 2119, March 1997. 559 Authors' Addresses 561 Yinben Xia 562 Huawei Technologies Co., Ltd 563 Q14, Huawei Campus, No.156 Beiqing Road 564 Hai-Dian District, Beijing, 100095 565 P.R. China 567 EMail: xiayinben@huawei.com 569 Tianran Zhou 570 Huawei Technologies Co., Ltd 571 Q14, Huawei Campus, No.156 Beiqing Road 572 Hai-Dian District, Beijing, 100095 573 P.R. China 575 EMail: zhoutianran@huawei.com 577 Yali Zhang 578 Huawei Technologies Co., Ltd 579 Q14, Huawei Campus, No.156 Beiqing Road 580 Hai-Dian District, Beijing, 100095 581 P.R. China 583 EMail: zhangyali369@huawei.com 584 Susan Hares 585 Huawei Technologies Co., Ltd 586 7453 Hickory Hill 587 Saline, MI 48176 588 USA 590 Email: shares@ndzh.com 592 Pedro Andres Aranda 593 Telefornica I+D, 594 Don Ramon de la Cruz, 82 Street 595 Madrid, 28006, Spain 597 EMail: pedroa.aranda@telefonica.com 599 Diego R. Lopez 600 Telefornica I+D, 601 Don Ramon de la Cruz, 82 Street 602 Madrid, 28006, Spain 604 EMail: diego.r.lopez@telefonica.com 606 Jon Crowcroft 607 University of Cambridge Computer Laboratory 608 William Gates Building, 15 JJ Thomson Avenue 609 Cambridge, CB3 0FD UK 611 Email: jon.crowcroft@cl.cam.ac.uk 613 Yan Zhang 614 China Unicom P.R. China 616 Email: zhangy1036@chinaunicom.cn