| I2RS working group | S. Hares |
| Internet-Draft | Hickory Hill Consulting |
| Intended status: Standards Track | Q. Wu |
| Expires: September 04, 2014 | Huawei |
| March 03, 2014 |
An Information Model for Network policy
draft-hares-i2rs-info-model-policy-02
This document introduces an information model for network policies. This model operates as policy model that can be linked to other information model such as the I2RS RIB information model.
Some applications that utilize the services of I2RS client may require specific set of data in response to network events or conditions based on pre-established rules. In order to reduce the data flow through the network, the I2RS client needs to signal the I2RS agent to filter some of the collected data or events prior to transmission, or group the data prior to transmission to the i2rs client. This functionality is necessary to meet the requirements i2rs enabled services which include service-layer routing improvements, and control of traffic flows and exit points.
The information model is based on extensible information model for representing policies, for example, the Policy Core Information Model (PCIM) (RFC3060), and an extension to this model to address the need for QoS management, called the Quality of Service (QoS) Policy Information Model (QPIM)(RFC3644) and policy based routing.
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). 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 September 04, 2014.
Copyright (c) 2014 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 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.
The Interface to the Routing System (I2RS) provides read and write access to the information and state within the routing process within routing elements. The I2RS client interacts with one or more I2RS agents to collect information from network routing systems.
Processing of collected information at the I2RS agent may require the I2RS Agent to filter certain information or group pieces of information in order to reduce the data flow through the network to the I2RS client. Some applications that that utilize the services of I2RS client may also wish to require specific data in response to network events or conditions based on pre-established rules. This functionality is necessary to meet the requirements of i2rs enabled services which include service-layer routing improvements, and control of traffic flows and exit points.
This document introduces a basic information model for network policies. This policy model can be linked with other information models such as the I2RS RIB informational model [I-D.ietf-i2rs-rib-info-model] as a generic policy module. This basic policy model can be easily extended beyond the basic functions. The [I-D.ietf-i2rs-architecture] suggests that associated with the the i2RS RIB model there will be "Policy-based Routing (ACLs)" and RIB "policy controls". These basic policy functions can operate as part of this functional blocks providing the basic model for policy operators. This model can also be considered as the substance of the policy templates.
The basic but extendable policy model is a product of the industry approach to I2RS. The initial I2RS work is focusing on the initial RIB module, and basic functions to make the initial RIB model function within real networks. Subsequent drafts will provide building blocks upon this policy model that can be used to create network functions.
This information model leverages previous work done on extensible information model for representing policies, for example, the Policy Core Information Model (PCIM) [RFC3060] [RFC3060], and an extension to this model to address the need for QoS management, called the Quality of Service (QoS) Policy Information Model (QPIM) [RFC3644] [RFC3644].
Most policy within routing and forwarding systems has become hierarchical with individual specific policies being grouped as a set policy. The hierarchical policy rule definition enhances policy readability and reusability. Groups of network policies have labels to aid operational use. Named groups of policy are easily identified and reused as blocks.
The information model contains the following three components:
An I2RS client may also interact with other elements of the policy and provisioning system to retrieve policy to transmit to an I2RS agent to be use in processing collected information, or to pass to policy information bases (PIBs) within the routing system. How the I2RS client interacts with the policy and provision systems is currently outside the scope of I2RS.
I2RS architecture allows multiple I2RS Clients to communicate with the same agent I2RS agent, but requires that only one I2RS client has write control over one element. Specification on how the I2RS Clients handle multiple client interactions it out of scope at this time. The i2rs-architecture document specifies in section x.x that I2RS clients should avoid writing the same element. In the future, the I2RS WG may decide to specify these interactions. Therefore, this document’s policy information allows for extensions that will allow multiple clients.
I2RS needs its own implicit and explicit policy. This section provides an overview of the network policy model. The network policy model is defined by the following components, whose relationship is roughly depicted in the figure below.
+-----------------------+
| Network-Policy |
+-----------+-----------+
^
/|\
| "extends"
+-----------^-------------+
| Policy Set |
+--+-------------------+--+
^ ^ +-----------------+
/|\ /|\ ---|Local Policy Rule|
| "extends" | "extends" | +-----------------+
+--------^-------+ +-------^-------+ |
| Policy Group | | Policy Rule |<---|
+----------------+ +---------------+ |
: : | +-------------+
......: :..... ---| PBR Rule |
: : +-------------+
: :
+---------V---------+ +-V-------------+
| Policy Condition | | Policy Action |
+-------------------+ +---------------+
: : : : : :
.....: . :..... .....: . :.....
: : : : : :
+----V---+ +---V----+ +--V---+ +-V------++--V-----++--V---+
| Match | |Policy | |Policy| | Set || Policy ||Policy|
|Operator| |Variable| |Value | |Operator||Variable|| Value|
+--------+ +--------+ +------+ +--------++--------++------+
Figure 1: Overall model structure
The policy group component defines the basic network policy Group model. In addition, the Network-policy component defines the basic network policy rule model.
PolicySet, is introduced to provide an abstraction for a set of rules. It is derived from Policy, and it is inserted into the inheritance hierarchy above both PolicyGroup and PolicyRule. This reflects the additional structural flexibility and semantic capability of both subclasses.
Policy Rule is represented by semantics “If Condition then Action”, therefore condition and action comprise Policy Rule model. Condition models the elementary match operation “<variable> match <value>”. Action models the elementary set operation. "SET <variable> TO <value>". In Condition model, the ‘Match’ operator is usually implied while in the action model, the ‘Set’ operator is explicitly used.
The Local Config Component is extended from Policy Rule and contains a set of local policy state related to I2RS operation that the I2RS agent controls. The local system's local policy state linked to a particular information base (E.g. I2RS RIB) may have a write scope that one or more clients may write. The same write scope with that of one or more clients using an agent. An agent must check to determine if a local configuration state overlaps with existing installed state.
The Policy Based Routing Rule is also extended from Policy Rule and Contain a set of condition, action and attributes that are inherited from Policy Group Component. Routing decisions in policy based routing are based on several criteria beyond destination address, such as packet size, application, protocol used, and identity of the end system.
This section specifies the network policy information model in Routing Backus-Naur Form (RBNF, [RFC5511]). It also provides diagrams of the main entities that the information model is comprised of.
In order to provide hierarchical policy definition and associate policy rule with other constraint, the basic policy group model needs to be defined. The corresponding extensions are introduced in a component, whose structure is informally depicted in the following diagram.
+------------------------------------+
| Policy Group |....
+------------------------------------+ :
* * * * * ^ :
| | | | | :....:
| | | | |
| | | | |
| | | | |
+--------+ +--------+ +--------+| +-----------+
|Identity| | Role | |Priority|| |Policy Rule|
+--------+ +--------+ +--------+| +-----------+
* * | * * *
| | | | | |
+--- | | +---+---+ | ++----+
| | | |Enabled| | |Usage|
| | | +-------+ | +-----+
+-----+----+ +------+ | |
| Resource | |Scope | | |
+----------+ +------+ | |
* * | +--+------+
| | +----+------+ |Mandatory|
| | | Precedence| +---------+
| | +-----------+
| |
+-----++-----+
| Read||Write|
|Scope||Scope|
+-----++-----+
The basic information model works as follows: Within the policy group information model, hierarchy is used to model context or scope for the sub-rule actions. A policy group contains Identity, scope, priority,precedence, policy rule and policy group. Policy rule or policy group can be nested into policy group. Policy rule can inherit context from policy group as properties and also policy rule can have its own properties, eg., enabled, mandatory, usage properties.
A more formal depiction in RBNF format follows below:
<Policy-Group> ::= <Identity>
<Role>
<priority>
<precedence>
<Policy-Rule>
[<Supporting-Policy-Group>]
[<Policy-Group-Extension>]
<Scope> ::= <Read-Scope> |<Write-Scope>
<Role> ::= <Resource> | <Scope>
<Policy-Group-Extension> ::= <>
...
The elements of the Policy Group information model are as follows:
The following diagram contains an informal graphical depiction of the main elements of the information model:
+----------------+
| Policy Rule |<...
+----------------+ :
* * : :
| | :...:
| |
+---------+ +--------+
...>|Condition|<.......| Action |<...
: +---------+<.......+--------+ :
: : * * : :
:..... | : :... :
| :
+--------+...........:
|Operator|
+--------+
Roughly speaking, the basic information model works as follows: A policy rule contains conditions and actions. Each condition or each action in turn contains operator. A operator connects variable and value in the action or condition. Condition can map onto and be supported by other condition, while action can map onto and be supported by other actions. Policy rule can map onto other, policy rules.
The information model for the Network-policy component is more formally shown in the following diagram.
<network-policy-rule> ::= (<policy-rule>...)
<policy-rule> ::= <Identity>
<priority>
<precedence>
<Role>
(<Condition>
(<Action>...)
<Security-Model>
[<policy-rule-extension>]
<Scope> ::= (<Read> [<read-scope>]) |
(<Write> [<write-scope>])
<Role> ::= <Resource> | <Scope>
<Security-Model> ::= <First-Matching>|<All-Matching>
<policy-rule-extension> ::= <i2rs-policy-extension> |
...
<condition> ::= <variable>
(<value>...)
[<Match-Operator>]
[<condition-extension>]
<Match-Operator> ::= <IS-SET-MEMBER'>
|<IN-INTEGER-RANGE>
|<IP-ADDRESS-AS-RESOLVED-BY-DNS>
|<Match-Operator-extension>
<condition-extension> ::= <i2rs-condition-extension> |
...
<action> ::= <variable>
<value>
<Set-Operator>
[<action-extension> ]
<action-extension> ::= <i2rs-action-extension> |
...
The elements of the Network-Policy Rule information model are as follows:
Policy based Routing is a technique used to make routing decisions based on policies set by the network administrator. PBR enables network administrator to forward the packet based on other criteria than the destination address in the packet, which is used to lookup an entry in the routing table.
The policy based routing problem can be viewed as a resource allocation problem that incorporates business decision.
Policy based routing provides many benefits, including cost saving, load balancing and basic QoS.
Routing decisions in policy based routing are based on several criteria beyond destination address, such as packet size, application, protocol used, and identity of the end system.
Policy constraints are applied before applying QoS constraints since policy constraint overrides QoS constraint.
Policy constraints may be exchanged by routing protocols while updating routing information.
Policy based routing MUST tackle the following difficult questions:
A PBR rule is constructed using condition, action and attributes that are inherited from Policy Group Component.
+-----------------------+
| Policy Rule |
+-----------+-----------+
^
/|\ "extends"
+-----------^-----------+
| PBR Rule |
+--+-----------------+--+
: :
: : .......
: : : :
+--------V-------+ +-------V-------+ :
| PBR Condition | | PBR Action |<...
+----------------+ +-+----------+--+
/|\ /|\
"extends"| | "extends"
+---+ +--------+
| |
+-------^-------+ +-----^---------+
| QoS Action | |Forward Action |
+---------------+ +---------------+
: : : : : :
....: : :..... .....: : :.....
: : : : : :
+----V---+ +---V----+ +--V---+ +-V------++--V-----++--V-----+
|Set | |QoS | |QoS | |Forward ||Next Hop||Next Hop|
|Operator| |Variable| |Value | |Operator||Variable||Value |
+--------+ +--------+ +------+ +--------++--+-----++--------+
/|\
| "extends"
+---^----+
|Next Hop|
|Type |
+--------+
Figure 3: Policy based routing IM structure
As descried in [I.D-ietf-i2rs-rib-info-model], Routing instance contains a collection of RIBs, interfaces, and routing parameters.
PIB and RIB can not be used at the same time
Policy constraints information either comes from RSVP,BGP/IGP, or comes from manual configuration or policy configuration tool. Therefore PIB may has the following field:
The Local Config Component is the information links to the policy functions associated with a information model it is linked to. This component defines a set of groupings with auxiliary information required and shared by those other components.
Since the I2RS RIB model is the only currently agreed upon model, an example from this model may be helpful. The I2RS RIB model contains a RIB definition of routing instance that has 0-N interfaces and 1-N RIBs. Each RIB contains a set of routes. This policy operates on the elements of I2RS RIB model by combining one of the elements defined in the I2RS RIB model (Routing instance 1, RIB 1, route-attribute) within the context of a policy rule. The [I-D.ietf-i2rs-architecture] shows this as the RIB Policy Controls that impact the policy routing. The I2RS agent may only collect information on this RIB. On Write, the RIB Policy Rules may determine what portion of the Policy-Based RIBs are altered to provide the early exit or service routing features needed by the I2RS client.
The key benefit of this Policy Information Model is that it provides a common model of interactions of policy which can be saved as templates, and then enacted for specific functions associated with another model. The policy element an identity, scope, role, and security model. This allows the specific element to be easily tailor to identified by operations, enable for specific operations (via scope and role), and at a correct security level. As the example demonstrates, this blends with the I2RS RIB model to set conditions and actions. Additional drafts will show that it provides other service routing.
<local-policy-rule> ::= (<local-policy-rule>...)
<local-policy-rule> ::= <Identity>
<priority>
<precedence>
<Role>
(<Condition>)
(<Action>...)
<Security-Model>
<Scope> ::= (<Read> [<read-scope>]) |
(<Write> [<write-scope>])
<Role> ::= <Resource> |
<Scope>
<Security-Model> ::= <First-Matching>|
<All-Matching>
...
<condition> ::= <variable>
(<value>...)
[<Match-Operator>]
[<condition-extension>]
<Match-Operator> ::= <IS-SET-MEMBER'>
|<IN-INTEGER-RANGE>
|<IP-ADDRESS-AS-RESOLVED-BY-DNS>
|<Match-Operator-extension>
<condition-extension> ::= <i2rs-condition-extension> |
...
<action> ::= <variable>
<value>
<Set-Operator>
[<action-extension>]
<action-extension> ::= <i2rs-action-extension> |
...
The model extends the original network-policy model as follows:
Drafts that specify examples for this blended I2RS model are:
This draft includes no request to IANA.
TBD.