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.
_______________________________________________
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm
