Figure 1P-15 - Simple PolicyStatement

There is significant similarity between the most common types of PolicyConditions and PolicyActions. Specifically:<br/>        • PolicyConditions are of the form: “IF  is TRUE”<br/>        • PolicyActions are of the form: “SET  to #lt;value#gt;<br/>Both the condition clause and the action clause are in reality of the same form:<br/>{ variable, operator, value }<br/>where the braces are used to denote a tuple. To see this, we can write a PolicyCondition as:<br/>IF #lt;variable#gt; #lt;operator#gt; #lt;value#gt; is TRUE (1)<br/>For example, consider:<br/>IF sourcePort == 21 (2)<br/>In equation (2), sourcePort is an example of a variable, “==” is an example of an operator, and “21” is an example of a value. More formally, equation (2) tests the value of the sourcePort variable, to see if it is equal to the value 21 or not.<br/>Similarly, a PolicyAction can be represented as:<br/>#lt;operator  #lt;variable#gt; to #lt;value#gt;<br/>For example, consider:<br/>SET ToS = 5 (3)<br/>In equation (3), ToS is an example of a variable, “=” is an example of an operator, and “5” is an example of a value. More formally, equation (3) sets the value of the ToS (type of service) field in the IP header to the value of 5.<br/>Clearly, values can have different data types besides integers, and variables can represent any concept, not just fields in the IP header. In fact, the Policy model provides a standard set of variables and values, as well as the ability to represent custom variables and values, so that different applications can use the same set of classes to represent different policy expressions (which are called PolicyStatements in this model).<br/><br/>More specifically, this enables the model to generalize the standard form of a PolicyCondition and a PolicyAction into an object that is called a PolicyStatement. This has important implications, since a Policy Decision Point, a Policy Enforcement Point, and a Policy Execution Point can now share the same basic syntax. Both PolicyConditions as well as PolicyActions share the same variables and values; the difference in semantics is reflected in the types of operators that are allowed to be used for PolicyConditions versus PolicyActions. For conditions, we want the semantics of “variable relates to value”, where “relates to” is usually the match operator, but could also be other applicable operators (e.g., a comparison operator). For actions, we want the semantics of “set variable to value”. These semantics are enforced using OCL, but that is beyond the scope of this Addendum. A simplified representation of the PolicyStatement entity is shown in Figure below.<br/>The cardinality of each of the three aggregations that involve PolicyStatement (i.e., UsesValue, UsesOperator, and UsesVariable) are each 0..n on the PolicyStatement side. This means that a given PolicyValue, PolicyOperator, and PolicyVariable can be used in zero or more PolicyStatement entities, respectively. The 0..n is used to enable the design of each of these three entities independent of the PolicyStatement.<br/>The cardinality on the PolicyValue and PolicyVariable ends of the UsesValue and UsesVariable compositions is each 1..n. This means that a PolicyStatement must contain at least one or more PolicyValue and PolicyVariable entities, respectively, in order to be a valid PolicyStatement. Similarly, the cardinality on the PolicyOperator end of the UsesOperator composition is 1, because a PolicyStatement is a single clause, and therefore requires only a single PolicyOperator.<br/>The ValueConstraintInVariable association enables a PolicyVariable to use a constrained, or limited, set of PolicyValues, compared to what it would normally use. Similarly, the OperatorConstraintInVariable association limits the type of operators that could be used with a given PolicyVariable to a smaller subset. The power of these two association classes lies in the fact that an external policy application can adjust these constraints at run-time by populating the attributes of these classes. This enables the same generic model to be used for multiple applications for consistency. At the same time, it enables the effects of the changing environment to be taken into account at run-time in the form of these constraints.<br/>A PolicyOperator is a concrete class for modeling different types of operators in a PolicyStatement. By restricting the type of operator used in a PolicyStatement, one can effectively restrict the semantics of that PolicyStatement. This is done using the OperatorConstraintInVariable association.<br/>