Subject: [DMM] Reformulation of policy lifecycle ideas in FPC draft

From: Charlie Perkins <[email-masked]>
Date: Thu, 1 Feb 2018 13:19:26 -0800

Hello folks,

I would like to propose a bit of reorganization for the current policy 
handling as specified in the current FPC document.

Roughly speaking, a policy can exist in one of three "forms".

A policy definition can be referenced in an Indexed Set by making use of 
a Policy Key.  This key enables an FPC Client or FPC Agent to retrieve 
the policy definition.  The policy attributes are exhibited in the 
policy definition within the data structure in the Indexed Set.  Some of 
the attributes may not have any values, because the values need to be 
determined for any particular scenario in which the policy is enforced.  
Some of the attributes may have default values, which can be changed 
(e.g., port on which a certain kind of streaming data is received).  
Some of the attributes do not require any value (e.g., an Action to 
"drop all packets"), or have a particular value which is never changed.

When an FPC Client configures an FPC Agent with a set of Policies as 
retrieved from the Indexed Set, the Client can supply some needed 
attribute values, or non-default attribute values, as part of the 
configuration process.  Then the Agent has access to those policies for 
future data-plane operations.  Such attribute values are called 
"Settings" or "Values" in the current document.  For the purposes of 
this email, I will call these configured attribute values to be 
Settings.  In policy definitions, Settings can apply either to the 
Descriptors or the Actions of the Rules in the policy.

When a mobile node arrives at a DPN (for instance, an access point), the 
FPC agent is triggered to create a Mobility Context for the mobile node 
(MN).  This will involve applying certain policies to the traffic to and 
from MN.  In order to apply the policies, the FPC Agent will likely have 
to insert more Settings to the policy attributes.  For instance, the 
traffic descriptor might need the IP address of the mobile node.  The 
maximum bitrate for MN traffic might depend upon its authorizations, 
which are not available to the FPC Agent until runtime.  Once the policy 
attributes are fully updated with Settings appropriate for MN (the 
mobile node), then the policy can be enforced.  We might say that once 
all attribute values are known, the policy is "activated". New policies 
can be activated (or old policies deactivated) as MN creates or deletes 
new Flows.

The three forms of a Policy, according to the above description, evolve 
according to various specializations that proceed by updating more and 
more policy attributes, until all attribute values have known values, 
and can be used for traffic management to/from the mobile node.  Observe 
that some policies don't necessarily have to be specific to a mobile 
node.  Some are domain-wide policies, and may have all attribute values 
assigned already when the FPC Client configures them into the FPC Agent. 
Throughout this evolution in time, the data structures for a Policy in 
memory (e.g., as known to the FPC Agent) still maintain the same Policy 
Key, but may acquire more and more Settings.

The above description of policy configuration and further configuration 
amounts to another way of looking at the concepts in the current FPC 
document -- in particular, Assigned Policies, Requested Policies, and 
Embedded Policies.  It is an important matter of current discussion 
about what parts of the existing terminology to retain for the upcoming 
revision of the specification.  Input from the [dmm] WG is cordially 
requested.

We have also discussed changing what is now called a "policy definition" 
to instead be a "policy template".  The latter terminology evokes the 
process of configuration and reconfiguration as described above.  Please 
let us know what you think.

Happy Bloody Moon Groundhog Eve,
Charlie P.