| < draft-xia-ibnemo-icim-00.txt | draft-xia-ibnemo-icim-01.txt > | |||
|---|---|---|---|---|
| skipping to change at page 1, line 15 ¶ | skipping to change at page 1, line 15 ¶ | |||
| Expires: November 23, 2015 Y. Zhang, Ed. | Expires: November 23, 2015 Y. Zhang, Ed. | |||
| S. Hares | S. Hares | |||
| Huawei | Huawei | |||
| P. Aranda | P. Aranda | |||
| D. Lopez | D. Lopez | |||
| Telefornica | Telefornica | |||
| J. Crowcroft | J. Crowcroft | |||
| Cambridge University | Cambridge University | |||
| Y. Zhang | Y. Zhang | |||
| China Unicom | China Unicom | |||
| May 22, 2015 | November 30, 2015 | |||
| Intent Common Information Model | Intent Common Information Model | |||
| draft-xia-ibnemo-icim-00 | draft-xia-ibnemo-icim-01 | |||
| Abstract | Abstract | |||
| Intent Common Information Model (ICIM) generalizes a unified model | Intent Common Information Model (ICIM) defines a unified model for | |||
| for expressing different layers' intent whatever role, | expressing different layers' intent whatever role, responsibility, | |||
| responsibility, knowledge, etc. This document provides an information | knowledge, etc. This document provides an information model to be | |||
| model to be inherited and expanded to construct specific intent model | inherited and expanded to construct specific intent model in | |||
| in different areas. According to this information model, network | different areas. According to this information model, network intent | |||
| intent model is put forward which can satisfy users' need in | model is put forward which can satisfy users' need in different | |||
| different layers, such as, end-users, business developers, and | layers, such as, end-users, business developers, and network | |||
| network administers. | administers. | |||
| Status of this Memo | Status of this Memo | |||
| This Internet-Draft is submitted to IETF in full conformance with the | This Internet-Draft is submitted to IETF in full conformance with the | |||
| provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
| other groups may also distribute working documents as | other groups may also distribute working documents as | |||
| Internet-Drafts. | Internet-Drafts. | |||
| skipping to change at page 2, line 31 ¶ | skipping to change at page 2, line 31 ¶ | |||
| Table of Contents | Table of Contents | |||
| 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
| 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 | 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
| 2. Intent Common Information Model Overview . . . . . . . . . . . 4 | 2. Intent Common Information Model Overview . . . . . . . . . . . 4 | |||
| 2.1 Elements . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 2.1 Elements . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
| 2.1.1 User . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 2.1.1 User . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
| 2.1.2 Context . . . . . . . . . . . . . . . . . . . . . . . . 5 | 2.1.2 Context . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
| 2.1.3 Object . . . . . . . . . . . . . . . . . . . . . . . . 5 | 2.1.3 Object . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
| 2.1.4 Result . . . . . . . . . . . . . . . . . . . . . . . . 5 | 2.1.4 Result . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
| 2.1.5 Operation . . . . . . . . . . . . . . . . . . . . . . . 6 | 2.1.5 Operation . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
| 2.2 Relationships in ICIM . . . . . . . . . . . . . . . . . . . 6 | 2.2 Relationships in ICIM . . . . . . . . . . . . . . . . . . . 7 | |||
| 2.2.1 Relationship between Result and Operation . . . . . . . 6 | 2.2.1 Relationship between Result and Operation . . . . . . . 7 | |||
| 2.2.2 Relationship between Object and Operation . . . . . . . 7 | 2.2.2 Relationship between Object and Operation . . . . . . . 7 | |||
| 2.2.3 Relationship between Object and Result . . . . . . . . 7 | 2.2.3 Relationship between Object and Result . . . . . . . . 8 | |||
| 2.3 Intent and Policy . . . . . . . . . . . . . . . . . . . . . 7 | 2.3 Intent and Policy . . . . . . . . . . . . . . . . . . . . . 8 | |||
| 2.4 Layers of Intent . . . . . . . . . . . . . . . . . . . . . 8 | 2.4 Role-based Intent . . . . . . . . . . . . . . . . . . . . . 8 | |||
| 3. Intent Modeling . . . . . . . . . . . . . . . . . . . . . . . 8 | 3. Intent Modeling . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
| 3.1 Intent overview . . . . . . . . . . . . . . . . . . . . . . 8 | 3.1 Notation . . . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
| 3.2 Top level intent expression . . . . . . . . . . . . . . . . 8 | 3.2 Intent overview . . . . . . . . . . . . . . . . . . . . . . 9 | |||
| 3.3 Objects in the network . . . . . . . . . . . . . . . . . . 9 | 3.3 Top level intent expression . . . . . . . . . . . . . . . . 10 | |||
| 3.4 Type of result . . . . . . . . . . . . . . . . . . . . . . 10 | 3.4 Objects in the network . . . . . . . . . . . . . . . . . . 10 | |||
| 3.5 Operation composition . . . . . . . . . . . . . . . . . . . 10 | 3.5 Type of result . . . . . . . . . . . . . . . . . . . . . . 11 | |||
| 4 Security Considerations . . . . . . . . . . . . . . . . . . . . 12 | 3.6 Operation composition . . . . . . . . . . . . . . . . . . . 12 | |||
| 5 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 12 | 4 Security Considerations . . . . . . . . . . . . . . . . . . . . 14 | |||
| 6 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 | 5 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 14 | |||
| 7 Informative References . . . . . . . . . . . . . . . . . . . . 12 | 6 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 | 7 Informative References . . . . . . . . . . . . . . . . . . . . 14 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 | ||||
| 1 Introduction | 1 Introduction | |||
| Intent is a new philosophy to design open interface. Opposite to the | Network operations have traditionally been designed bottom-up | |||
| 'bottom up' method which opens what system has, Intent interface uses | starting with low level device interfaces designed by protocol | |||
| 'top down' method which opens what user's requirement. With this | experts.In order that interfaces could be wildly used by various | |||
| Intent interface, users just need to express what their requirements | users, information details are exposed as much as possible. It | |||
| are, rather than how to implement them, so Intent interface is user | enables better control of devices, but leaves huge burden of | |||
| friendly. Intent interface is much closer to user, but different | selecting useful information to users without well training. Since | |||
| users have different intention manifestations, which have different | the north bound interface (NBI) is used by network users, a more | |||
| granularity or different level. It depends on users' role, knowledge | appropriate design is to express user intent and abstract the network | |||
| and their purpose. Intent can be some final results of objects and | from the top down. The intent base NBI expresses what a network | |||
| also can be some specific operations on objects in specific context. | service consumer (e.g., application, operator) requires from the | |||
| Although dictating operations is the manifestation of intent, a user | network but it does not completely specify or constrain how that | |||
| just need to assign the operations he cares about, and has no need to | service may or should be delivered by the network. The intent is | |||
| plan complete and detailed operations list for the system to achieve | expected to be independent of protocols, network interface styles, | |||
| the intent. | vendor features, media attributes, or any other network | |||
| implementations. | ||||
| Intent Common Information Model (ICIM) generalizes a generic model | Intent Common Information Model (ICIM) specifies a generic model for | |||
| for expressing key components of intent interface and the | expressing key components of intent interface and the relationship | |||
| relationship between these components. This document provides a | between these components. This document provides a common model which | |||
| common model to be inherited and expanded to construct specific | could be inherited from and expanded to construct specific intent | |||
| intent interface in specific areas. According to this information | interface in dedicated areas. According to this information model, | |||
| model, intent interface in network area is put forward which can | intent interface in network area can satisfy users' intention in | |||
| satisfy user' intention in different layers or different roles, such | different roles, such as, end-users, business developers, network | |||
| as, end-users, business developers, network administers, etc | administers, etc | |||
| 1.1 Terminology | 1.1 Terminology | |||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
| document are to be interpreted as described in RFC 2119 [RFC2119]. | document are to be interpreted as described in RFC 2119 [RFC2119]. | |||
| 2. Intent Common Information Model Overview | 2. Intent Common Information Model Overview | |||
| Intent Common Information Model aims to generalize a unified | Intent Common Information Model aims to specify a unified information | |||
| information model which satisfied different areas, scenarios, and | model which satisfied different areas, scenarios, and other | |||
| other constraints. So, it is a complete and detailed information | constraints. So, it is a complete and detailed information model to | |||
| model to define the constituent elements of intent, but some elements | define the constituent elements of intent. However, not all elements | |||
| can be omitted or implied under some special situations when using | need to be present when mapping this model to a specific data model, | |||
| this model to express specific data model. | since some of the elements can be obtained by system automatically. | |||
| From the overall perspective, construction elements of intent can be | From the overall perspective, construction elements of intent can be | |||
| generalized into user of intent who author and own this intent, | described as: | |||
| intent content which is a desired purpose and the specific context | ||||
| for implementing intent. Furthermore, in general, person's intent | -user of intent who author and own this intent | |||
| content is often visioning ultimate state of some objects or | ||||
| performing actions to these objects, so intent content can be | -intent content which is a desired purpose and | |||
| abstracted into object which is the target for intent, result which | -the specific context which is the background circumstance | |||
| is a desired state and operation which is the specific actions to | information. | |||
| achieve a purpose. | ||||
| Furthermore, in general, person's intent content usually describes | ||||
| the ultimate state of some objects or applies actions to these | ||||
| objects. So intent content can be abstracted into further: | ||||
| -object which is the target for intent | ||||
| -result which is a desired state and | ||||
| -operation which is the specific actions to achieve a purpose. | ||||
| 2.1 Elements | 2.1 Elements | |||
| 2.1.1 User | 2.1.1 User | |||
| User is an abstract class which refers the subject and owner to | User is an abstract class which specifies the subject and owner to | |||
| express the intent. For example, end-users, business designers, | express the intent. It is a performance of roles in real world, that | |||
| network administrators are all instances of User class. Intent has a | is, each user serves as a role or a combination of roles actually. | |||
| strong relationship with the user. So intent is different for | For example, end-users, business designers, network administrators | |||
| specific user when this information model is applied to specific | are all instances of User class which act as specific roles. When a | |||
| scenario. So when ICIM is implemented, this class will involve a role | user is labeled as a role, he will have the desire and requirement to | |||
| mapping. | express intent belonged to this role. Owning to different network | |||
| abstraction views, intent is different for specific user when this | ||||
| information model is applied to specific scenario. | ||||
| Though one user serves as one role in most cases, it is sensible and | ||||
| acceptable that one user serves as multiple roles and intent of these | ||||
| users may involve more functions and huge operation scope. | ||||
| 2.1.2 Context | 2.1.2 Context | |||
| Context refers to a set of specific background information such as, | Context is an abstraction class which refers to a set of specific | |||
| timer, price, and so on. Context has a huge influence on a person | background information such as, timer, price, and so on. Context has | |||
| designing a detailed plan or selecting the best program to achieve a | a huge influence on a person designing a detailed plan or selecting | |||
| purpose. For example, when an enterprise plans to build a dedicated | the best program to achieve a purpose. For example, when an | |||
| connection between two sites, price and distance will be the context | enterprise plans to build a dedicated connection between two sites, | |||
| in this scenario. While may not be part of how an entity expresses or | price and distance will be the context in this scenario. While may | |||
| executes some intent, it is a factor that must be considered with the | not be part of how an entity expresses or executes some intent, it is | |||
| expression of intent. | a factor that must be considered with the expression of intent. | |||
| 2.1.3 Object | 2.1.3 Object | |||
| Object refers an abstract class which defines some entities affected | Object is an abstract class which refers an abstract class which | |||
| or managed by intent. For the management, users could manage life | defines some entities affected or managed by intent. For the | |||
| cycle of the objects through some concrete operations, such as, | management, users could manage life cycle of the objects through some | |||
| create, update, delete, etc. In addition, users could use other | concrete operations, such as, create, update, delete, etc. In | |||
| specific operations to affect the behavior of managed objects. For | addition, users could use other specific operations to affect the | |||
| example, a business designer want all traffic be filtered by a | behavior of managed objects. For example, a business designer want | |||
| special firewall. The object of this business designers intent could | all traffic be filtered by a special firewall. The object of this | |||
| be the all traffic flowing on a specific network (e.g. L3VPN), and | business designers intent could be the all traffic flowing on a | |||
| this intent impacts the forwarding behavior of the traffic network. | specific network (e.g. L3VPN), and this intent impacts the | |||
| Object is different in specific area. In network area, object is an | forwarding behavior of the traffic network. Object is different in | |||
| aggregation class with node, connection and flow. For objects, users | specific area. In network area, object is an aggregation class with | |||
| could construct some specific objects to achieve intent, and it is | node, connection and flow. For objects, users could construct some | |||
| also allowed for users to assign intent to existing resources. | specific objects to achieve intent, and it is also allowed for users | |||
| to assign intent to existing resources which is physical/virtual | ||||
| devices or defined by other ways. | ||||
| 2.1.4 Result | 2.1.4 Result | |||
| Result is a type of intent which refers to an ultimate state or | Result is a type of intent which refers to an final state or | |||
| something an individual wants to achieve. This type of intent shields | something an individual wants to achieve. This type of intent shields | |||
| difference and diversity of an environment away from the users' | difference and diversity of an environment away from the users' | |||
| intent. The person just envisions the ultimate state of objects | intent. The person just describes the final state of objects without | |||
| without worrying about how to achieve it. For example, a result could | worrying about how to achieve it. For example, a result could be that | |||
| be that the company accesses any sites on the Internet safely. It | the company accesses any sites on the Internet safely. It just | |||
| just defines a result that ignores technology details, such as, | defines a result that ignores technology details, such as, firewall, | |||
| firewall, ACL, and so on. | ACL, and so on. | |||
| Though desired state is a general requirement, violation state is | In addition to the expecting state, violation is another special | |||
| another special state which has an important status when achieving | state which has an important status when achieving integral | |||
| integral compliance. For example, a typical scenario is all virtual | compliance. For example, a typical scenario is that one specific | |||
| machines owned by different tenants should not be deployed in a same | tenant does not want his virtual machines to share a some hypervisor | |||
| hypervisor. This type of result just shows the undesired state which | with other tenants. This type of result just shows the undesired | |||
| is a type of violation state, and this kind of intent should be | state which express users' intent, so this kind of intent should be | |||
| involved in this information model. | another type of result. | |||
| 2.1.5 Operation | 2.1.5 Operation | |||
| Operation is a type of intent which refers to some specific actions | Operation is a type of intent which refers to some specific actions | |||
| an individual desires to take for realizing the purpose. This type of | an individual desires to take for realizing the purpose. This type of | |||
| intent formulates explicit plan to realize a purpose which may take a | intent formulates explicit plan to realize a purpose which may take a | |||
| better control of the whole system. According to the diversity of | better control of the whole system. According to the diversity of | |||
| system support capability, there are large sets of operations for | system support capability, there are large sets of operations for | |||
| users to take. | users to take. | |||
| Generally, operations can be divided into two categories. One is | Generally, operations can be divided into two categories. One is | |||
| action without condition which is called "command" usually. For | action without condition. For example, create a virtual machine. This | |||
| example, create a virtual machine. This kind of operation defines a | kind of operation defines a concrete action which is executed | |||
| concrete action which is executed immediately without any trigger. | immediately without any trigger. The other is action with condition. | |||
| The other is action with condition. For this kind of operations, | For this kind of operations, condition is a trigger for the action. | |||
| condition is a trigger for the action. And actions will not be | And actions will not be executed immediately until the condition | |||
| executed immediately until the condition clause is tested to be true. | clause is tested to be true. For example, "do load balancing when the | |||
| For example, "do load balancing when the utilization of a link | utilization of a link exceeds 80%". In this example, "utilization of | |||
| exceeds 80%". In this example, "utilization of a link" is the | a link > 80%" is the trigger, and "do load balancing" is the action. | |||
| trigger, and "do load balancing" is the action. Action will not be | Action will not be executed until the trigger is true. Actions are | |||
| taken until the trigger is true. Actions are different by stages | different according to users' role which has different abstraction | |||
| which depend on the layer of intent. Actions expressed in upper layer | views. And actions will not be detailed configurations in devices, | |||
| may lead to cascaded actions in other lower layers. For example, the | but high-level and packaged functions which are translated into | |||
| action "do load balancing" will bring out many actions which are | configurations. For example, the service providers' action "do load | |||
| depend on technologies and devices. | balancing" is device independent, and network operators' action may | |||
| configure load balance pools depending on specific devices. | ||||
| 2.2 Relationships in ICIM | 2.2 Relationships in ICIM | |||
| 2.2.1 Relationship between Result and Operation | 2.2.1 Relationship between Result and Operation | |||
| Users are free to express their intent, no matter it is an ultimate | Users are free to express their intent, no matter it is an final | |||
| result or specific operations in their mind, but there are some | result or specific operations in their mind, but there are some | |||
| relationships between these two basic types of intent. For result, | relationships between these two basic types of intent. Result refers | |||
| users just need to express the goal without worrying how to implement | to an ultimate and relatively permanent status, regardless which ways | |||
| it in a specific system which facilitates users to focus on real | to maintain it. However, operations specify what kinds of action need | |||
| requirement. When achieving the ultimate result, it needs some | to take explicitly, which more focus on temporary or specific | |||
| reasoning mechanisms to transfer it to real executable operations | behavior to achieve some goal. One typical service scenario is that | |||
| which are supported by specific system. So in a specific scenario, a | all links' utilization should not exceed 80%. By way of Result, the | |||
| result can generate concrete operations. For example, for a | intent will be expecting all links' utilizations are smaller than 80% | |||
| geographical distributed enterprise, its intent is constructing a | (or avoiding any link' utilization exceeds 80%). By way of Operation, | |||
| dedicated line between headquarters and branches at the least cost. | the intent will be if links' utilization exceeds 80%, redirect some | |||
| This intent just expresses a result without defining how to construct | flows to other links (or some other actions could achieve this | |||
| this dedicated line. So business designers will design the best | goal). | |||
| solution and concrete operations referring capability of devices, | ||||
| optional programs, prices, etc. | For result, users just need to express the goal without worrying how | |||
| to implement it in a specific system which allows users to focus on | ||||
| real requirement. To achieve the result, it needs some reasoning | ||||
| mechanisms to transfer it to real executable operations which are | ||||
| supported by specific system. So in a specific scenario, a result can | ||||
| generate a set of concrete operations. For the above example, if user | ||||
| just expresses the result, that is, all links' utilizations are | ||||
| smaller than 80%. The system will choose suitable operations to | ||||
| achieve this status automatically, i.e., expand the capacity of links | ||||
| whose utilization exceed 80%, or redirect flows to other links whose | ||||
| capacities are far less than 80%. | ||||
| 2.2.2 Relationship between Object and Operation | 2.2.2 Relationship between Object and Operation | |||
| Operation refers to some specific actions on some objects, so object | Operation refers to some specific actions on some objects, so object | |||
| is the target of an action. In general, any action will include some | is the target of an action. In general, any action will include some | |||
| objects to execute this action. When users want to execute some | objects to execute this action. When users want to execute some | |||
| actions to achieve goals, they may construct the target objects and | actions to achieve goals, they may construct the target objects and | |||
| assign specific actions on them, and it is allowed for users to use | assign specific actions on them, and it is allowed for users to use | |||
| existing resources to do some operations. Though object is the target | existing resources to do some operations. Though object is the target | |||
| of action, it offers the constraint for optional operations. For | of action, it offers the constraint for optional operations. For | |||
| example, for a virtual machine, the optional operations are create, | example, for a virtual machine, the optional operations are create, | |||
| delete, immigrant, etc. | delete, migrate, etc. | |||
| 2.2.3 Relationship between Object and Result | 2.2.3 Relationship between Object and Result | |||
| Result refers to some ultimate state for some objects. This type of | Result refers to some final state for some objects. This type of | |||
| intent does not define which specific operations to take but express | intent does not define which specific operations to take, but only | |||
| the desired state of objects. So it is independent on objects' | express the desired state of objects. So it is independent on | |||
| capability. For example, intent is all virtual machines' CPU | objects' concrete capability. For example, intent is all virtual | |||
| utilization could not exceed 80%. It does not assign specific | machines' CPU utilization could not exceed 80%. It does not assign | |||
| operations. So reasoning mechanism will choose suitable operations to | specific operations. So reasoning mechanism will choose suitable | |||
| satisfy this intent, such as, immigrant virtual machine or expand it. | operations to satisfy this intent, such as, migrate virtual machine | |||
| or expand it. | ||||
| 2.3 Intent and Policy | 2.3 Intent and Policy | |||
| In industry, Policy already has a clear definition, such as in | In industry, Policy already has a clear definition, such as in | |||
| RFC3060. Policy rule consists of an event, a set of conditions and a | RFC3060. Policy rule consists of an event, a set of conditions and a | |||
| set of actions. When an event occurs, actions will be taken until | set of actions. When an event occurs, actions will be taken until | |||
| condition clauses are evaluated to be true. | condition clauses are evaluated to be true. | |||
| As mentioned above, intent refers to a purpose in achieving ultimate | As mentioned above, intent refers to a purpose in achieving result or | |||
| result or performing operation. The intent has a larger scope | performing operation. The intent has a larger scope compared with the | |||
| compared with the policy since Intent can express both result and | policy since Intent can express both result and operation. On one | |||
| operation. On one hand if a result is described by intent, there may | hand if a result is described by intent, there may be no specific | |||
| be no specific action given to show how to achieve this intent. On | action given to show how to achieve this intent. On the other hand, | |||
| the other hand, if operation described by intent, conditions of | if operation described by intent, conditions of action is optional. | |||
| action is optional. Policy is a specific form of operation in | Policy is a specific form of operation in intent. | |||
| intent. | ||||
| 2.4 Layers of Intent | 2.4 Role-based Intent | |||
| Intent reflects a person's mental desire which depends on person's | In an integrated system, roles are divided into several categories | |||
| role, knowledge, and other contextual factors. So users in different | according to the division of work, architecture of system, etc. In | |||
| layers may have different intent. While different layer of intent has | network system, network abstraction will be quite different in the | |||
| some differences in content and implementation, the expression of | perspective of each role. So intent has strong dependencies on roles. | |||
| each layer of intent is same which defines an ultimate goal or | Intent expressed by different categories of roles will focus on | |||
| dictates specific operations. | different points and have different intent expression. | |||
| For example, in the network area the intent of end-users could be | For example, if an agent is labeled as service provider role, he may | |||
| safe connectivity between two sites which a technology independent | just care about the high-level services, such as, security | |||
| and device independent requirement. For business-based network | communication. And if he is labeled as network architecture role, he | |||
| designers, the network connectivity can be selected which is device- | will care about the details of the whole architecture. | |||
| independent but technology specific. An example of the business-based | ||||
| technology is the L3VPN. For network administrators, intent can be | ||||
| specific operations on a set of devices such as configuring IP | ||||
| addresses on network servers in a data center. | ||||
| 3. Intent Modeling | 3. Intent Modeling | |||
| This section defines the concept and hierarchy of intent, and | This section defines the concept and hierarchy of intent, and | |||
| describes the Intent Common Information Model. | describes the Intent Common Information Model. | |||
| 3.1 Intent overview | 3.1 Notation | |||
| The notation used in this document is adapted from the UML (United | ||||
| Modeling Language). We will use the UML for the intent information | ||||
| modeling. This section listed symbols that will be used in this | ||||
| document for relationships among information models. | ||||
| --> | ||||
| Stands for the association relationship. Association represents the | ||||
| static relationship shared among the objects of two classes. | ||||
| --A | ||||
| Stands for the aggregation relationship. Aggregation is a variant of | ||||
| the "has a" association relationship; aggregation is more specific | ||||
| than association. It is an association that represents a part-whole | ||||
| or part-of relationship. Aggregation can occur when a class is a | ||||
| collection or container of other classes, but the contained classes | ||||
| do not have a strong lifecycle dependency on the container. The | ||||
| contents of the container are not automatically destroyed when the | ||||
| container is. | ||||
| --C | ||||
| Stands for the composition relationship. Composition is a stronger | ||||
| variant of the "has a" association relationship. It is more specific | ||||
| than aggregation. Composition usually has a strong lifecycle | ||||
| dependency between instances of the container class and instances of | ||||
| the contained class. If the container is destroyed, normally every | ||||
| instance that it contains is destroyed as well. | ||||
| --G | ||||
| Stands for the generalization relationship. The Generalization | ||||
| indicates that one of the two related classes (the subclass) is | ||||
| considered to be a specialized form of the other (the super type) and | ||||
| the super class is considered a 'Generalization' of the subclass. In | ||||
| practice, this means that any instance of the subtype is also an | ||||
| instance of the super class. | ||||
| 3.2 Intent overview | ||||
| In general, intent is one's specific mental activity, so it strongly | In general, intent is one's specific mental activity, so it strongly | |||
| depends on the subject. Different users may have different | depends on the subject. Different users may have different intent. In | |||
| manifestations and intent. In addition, context, omitted usually, is | addition, context, omitted usually, is an important factor when | |||
| an important factor when achieving purpose, which offers necessary | achieving purpose, which offers necessary background information to | |||
| background information to impact the decision. Figure 1 illustrates | impact the decision. It illustrates the overview of the intent. | |||
| the overview of the intent. Figure 1 indicates that the user has | Figure 1 indicates that the user has intent in some context. For | |||
| intent in some context. For example, an enterprise wants to block all | example, an enterprise wants to block all http traffic in work time. | |||
| http traffic in work time. In this intent, the user is the | In this intent, the user is the enterprise, the intent is to block | |||
| enterprise, the intent is to block all http traffic in the work | all http traffic in the work hours, and the context includes the | |||
| hours, and the context includes the definition of the "enterprise" | definition of the "enterprise" and the "work hours". | |||
| and the "work hours". | ||||
| +------+ has +--------+ in +---------+ | +------+ has +--------+ in +---------+ | |||
| | user +-------->+ intent +------->+ context | | | user +-------->+ intent +------->+ context | | |||
| +------+ +--------+ +---------+ | +------+ +--------+ +---------+ | |||
| Figure 1 general prescription for intent | Figure 1 general prescription for intent | |||
| 3.2 Top level intent expression | 3.3 Top level intent expression | |||
| In Cambridge Dictionaries, the definition of "intent" is the fact | In Cambridge Dictionaries, the definition of "intent" is the fact | |||
| that you want and plan to do something. So, in general, intent refers | that you want and plan to do something. So, in general, intent refers | |||
| to an agent's purpose in getting an ultimate result or performing | to an agent's purpose on getting the result or performing some | |||
| some specific operation. In specific areas, these results or | specific operation. In specific areas, these results or operations | |||
| operations will relate to some objects. Figure 2 describes the | will relate to some objects. Figure 2 describes the general | |||
| general expression of intent. | expression of intent. | |||
| +----------+ | +----------+ | |||
| | intent | | | intent | | |||
| +-C--A--A--+ | +-C--A--A--+ | |||
| | | | | | | | | |||
| +-----------+ | +------------+ | +-----------+ | +------------+ | |||
| | | | | | | | | |||
| +---+----+ +---+----+ +-----+-----+ | +---+----+ +---+----+ +-----+-----+ | |||
| | object | | result | | operation | | | object | | result | | operation | | |||
| +--------+ +--------+ +-----------+ | +--------+ +--------+ +-----------+ | |||
| Figure 2 intent expression | Figure 2 intent expression | |||
| One type of intent is to express key operations that a user wants to | One type of intent is to express key operations that a user wants to | |||
| execute. The underlying intent system can generate a complete | execute. The underlying intent system can generate a complete | |||
| operation list from user's request. The other type of intent is to | operation list from user's request. The other type of intent is to | |||
| express an ultimate result or state without dictating any operations. | express the result or state without dictating any operations. | |||
| For example, intent of a user may be a result without defining how to | For example, intent of a user may be a result without defining how to | |||
| realize it, such as, requiring security communication between two | realize it, such as, requiring security communication between two | |||
| sites, or dictate some detailed operations in order to achieve a | sites, or dictate some detailed operations in order to achieve a | |||
| purpose, such as, filtering all traffics by firewall between these | purpose, such as, filtering all traffics by firewall between these | |||
| two sites. | two sites. | |||
| 3.3 Objects in the network | 3.4 Objects in the network | |||
| Object is an abstraction class which can be inherited and expanded in | Object is an abstraction class which can be inherited from and | |||
| different area. In network area, the object, i.e. the target of | expanded in different area. It, cared about by users, represents the | |||
| intent, can be generalized into Node, Connection and Flow, as shown | target of result and operations. In network area, the object, i.e. | |||
| in Figure 3. | the target of intent, can be generalized into Node, Connection and | |||
| Flow, as shown in Figure 3. | ||||
| +------+ | +------+ | |||
| +------+ node | | +------+ node | | |||
| | +------+ | | +------+ | |||
| +--------+G+-+ | +--------+G+-+ | |||
| | | +------------+ | | | +------------+ | |||
| | object |G+--------+ connection | | | object |G+--------+ connection | | |||
| | | +------------+ | | | +------------+ | |||
| +--------+G+-+ | +--------+G+-+ | |||
| | +------+ | | +------+ | |||
| skipping to change at page 10, line 11 ¶ | skipping to change at page 11, line 29 ¶ | |||
| +------+ | +------+ | |||
| Figure 3 common objects in network area | Figure 3 common objects in network area | |||
| The Node represents the functions a network node may provide in a | The Node represents the functions a network node may provide in a | |||
| network such as network services, forwarding functions (firewall, | network such as network services, forwarding functions (firewall, | |||
| load balancer, virtual router, and others), or a group of network | load balancer, virtual router, and others), or a group of network | |||
| elements. A group of network elements can be a subnet, an autonomous | elements. A group of network elements can be a subnet, an autonomous | |||
| system, or a confederation of autonomous systems. | system, or a confederation of autonomous systems. | |||
| The Connection describes logical connectivity between node entities. | The Connection describes the link resources between two nodes. These | |||
| This connection is not limited to any physical link, but just | link resources construct the foundation of communications between | |||
| expresses the communication capacity between nodes. | different nodes. User could take connection as physical link, and | |||
| assign bandwidth on it. | ||||
| The Flow refers to the traffic in network which describes data | The Flow refers to the traffic in network which describes data | |||
| packets have some certain common characters. | packets have some certain common characters. Flow model describes the | |||
| connectivity in virtual network, namely, if users want to describe | ||||
| the communications between nodes without direct connection, they have | ||||
| to define the flow and assign operation to allow the flow. | ||||
| 3.4 Type of result | 3.5 Type of result | |||
| Result refers an ultimate state which is expected or avoided. Figure | Result refers to the final state which is expected or avoided. Figure | |||
| 4 describes two types of result. For example, a user may express an | 4 describes two types of result. Both of the results just show the | |||
| intent is his computer's CPU utilization must less than 80%. This | performance of some objects, without caring about how to reach them. | |||
| expression is a type of result which describes an expected state. Of | ||||
| course, this user can also express this intent as it's an error when | Result could be expressed as a set of logic clause connected with | |||
| his computer's CPU utilization exceeds 80%. This expression is | propositional literals including AND, OR and NOT. The logic clause | |||
| another type of result which describe a avoid state. Users are free | could be described as an expression with relational operators, such | |||
| to describe either one. | as equal, greater-than, less-than, belong-to. | |||
| With this model, users could express the desired state as an | ||||
| expression. System will resolve the expression and seek ways to make | ||||
| it true. The result will be achieved when the expression is evaluated | ||||
| to be true. The typical examples are shown as follows: | ||||
| - For example, a user may express an intent as the network link | ||||
| utilization must less than 80%. This expression is a type of result | ||||
| which describes an expected state. The left operand is the | ||||
| utilization of all links, the right operand is 80%, and the operator | ||||
| is less-than. | ||||
| - Another example is an enterprise wants the development team and | ||||
| sales team not to share a common link. In this intent, the left | ||||
| operand is the union of the link set of development team occupied and | ||||
| the link set of sales team occupied. The operation will be equal, and | ||||
| the right operator is an empty set. | ||||
| Though a unified information model for the Result is proposed in | ||||
| here, it is still a preliminary version which just expresses the | ||||
| basic components. The formalization and standardization are still | ||||
| open issues need to be studied further. More comprehensive and | ||||
| detailed manifestations will be added in the next version. | ||||
| +--------+ | +--------+ | |||
| | result | | | result | | |||
| +-G----G-+ | +-G----G-+ | |||
| | | | | | | |||
| +-----+ +----+ | +-----+ +----+ | |||
| | | | | | | |||
| +---+----+ +---+---+ | +---+----+ +---+---+ | |||
| | expect | | avoid | | | expect | | avoid | | |||
| +--------+ +-------+ | +--------+ +-------+ | |||
| Figure 4 expression of Result | Figure 4 expression of Result | |||
| 3.5 Operation composition | 3.6 Operation composition | |||
| Operation refers to some specific actions in order to achieve some | Operation refers to some specific actions in order to achieve some | |||
| purposes. An operation must have some actions. However, if condition | purposes. An operation must have some actions. However, if condition | |||
| and constraint need to be defined in operations, it depends on | and constraint can be optionally defined in operations, it depends on | |||
| specific scenario and users' require. Once a condition is involved in | specific scenario and users' requirement. Once a condition is | |||
| operation, actions will not be executed immediately until condition | involved in operation, actions will not be executed immediately until | |||
| is true. In additional, constraint restricts action itself or the | condition is true. In additional, constraint restricts action itself | |||
| scope of action. | or the scope of action. | |||
| For example, redirect traffic to back-up link when the utilization of | ||||
| current link exceeds 80%, except the flow from VIP user. In this | ||||
| scenario, the condition is link utilization exceeds 80%, the action | ||||
| is redirect traffic, and the constraint is VIP flow could not be | ||||
| redirected. | ||||
| +-----------+ | +-----------+ | |||
| | operation | | | operation | | |||
| +-A---C---A-+ | +-A---C---A-+ | |||
| | | | | | | | | |||
| +-------------+ | +--------------+ | +-------------+ | +--------------+ | |||
| | | | | | | | | |||
| | | | | | | | | |||
| +-----+-----+ +---+----+ +------+-----+ | +-----+-----+ +---+----+ +------+-----+ | |||
| | condition | | action | | constraint | | | condition | | action | | constraint | | |||
| End of changes. 39 change blocks. | ||||
| 203 lines changed or deleted | 303 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||