Policy in the FPC draft - definitions, context transfer, keys, indexing, etc.

Hello folks,

Policy seems always to be complicated.  I wrote up a scenario that, I 
think, captures many of the complications and relevant areas of 
application.  I also think the explanations about policy management as 
used in the scenario mostly represent the intention of the text 
currently in the FPC draft.  If the description about how policy is 
managed for the handover scenario is appropriate, I would like to use it 
and carry out a slight reorganization of the descriptions in the draft.

Regards,
Charlie P.

==============================================================================

Example for mobile node movement from DPN-1 to DPN-2.

MN has two flows:

  *      = F1: best effort traffic
  *      = F2: voice call



When MN attaches to the access network of DPN-1, DPN-1 constructs a 
Mobility Context for MN.  It has the following (say, at network entry):

  *      = MN's IP address (MN_IP)
  *      = Policy X for F1
  *      = Policy Y for F2
  *      = other stuff (charging ID, current remaining credit, ...)



When MN moves to the access network of DPN-2, DPN-2 should receive the 
Mobility Context for MN from DPN-1, and make the necessary modifications 
so that the Mobility Context for MN is parameterized for operation with 
DPN-2.

Suppose that for this example, DPN-1 routes all traffic to/from MN 
through a common gateway G-11.  Also suppose that FPC Client has 
installed two policies on both DPN-1 and DPN-2 -- one for best effort 
traffic, one for voice.

Then DPN-1 might store in the Mobility Context for MN the following rules:

  *      = R1: If (packet belongs to flow F1), then route through G11
  *      = R2: If (packet belongs to flow F2), then route through G11
  *      = R3: Else, drop


In simplest terms, at DPN-1 don't support any fancy applications, and 
route all packets through G11.  Observe that the actual rules would 
certainly be different, but I think this is sufficient for the example.  
As this description of the scenario proceeds, the need for other 
policies will be considered.

How did rules R1, R2, and R3 get installed on DPN-1?  Presumably the FPC 
Client has a list of policies that are supported in the Domain (i.e., 
operator's network).  One policy (X) could be called 
"Handling-Best-Effort" with Policy-Key P-12 and the other policy (Y) 
could be called "Handling-Voice" with Policy-Key P-37.  Keys P-12 and 
P-37 are unique within the namespace available to the FPC-Client for 
data-plane nodes in its Domain.

When MN registers at DPN-1, DPN-1 should already have policies P-12 and 
P-37 available for insertion into MN's mobility context. Let's say that 
these two policies are in the set of Assigned Policies at DPN-1 and 
DPN-2, and that the FPC client configures those policies at the time the 
data-plane topology is established that contains DPN-1 and DPN-2.  The 
FPC Client might have more policies that are pertinent to all flows on 
the mobile node, and when a mobile node registers at a DPN, the DPN 
process determines which of those policies are associated with a 
particular mobile node, according to the flow information that is 
provided during registration.  For our mobile node, suppose that policy 
P-51 applies to every flow on the mobile node.

There might be some other policies that are applied for traffic to/from 
every mobile node, regardless of the specific credentials or flows 
supported on that mobile node.  These might be Domain policies, or they 
might be configured only for a particular Interface Group, or both.  
Domain policies might pertain to a particular class of mobile nodes, 
such as visitors from another specific domain.  This is a matter for 
discussion.

There might be another category of policies that are DPN-specific.  Such 
policies would apply to every Mobility Context resident on a particular 
DPN, regardless of the particular mobile node.  But another DPN might 
not have any of the policies of the first DPN, or only some of them.  
Let's call those DPN policies.

Back to the scenario where the MN moves from DPN-1 to DPN-2. Suppose 
that the mobility management system wants to do a smooth handover, and 
that this requires transferring MN's Mobility Context from DPN-1 to 
DPN-2.  Suppose that on DPN-1 there are DPN-specific policies P-40 and 
P-41 that apply to the mobile node, and Domain policies P-50 and P-52.

This depends on how the policy rules are stored on DPN-1.  Here is one 
possibility:

  *      = DPN-specific policies are not transferred with the Mobility
    Context
  *      = Domain policy keys P-50 and P-52 COULD be transferred, or we
    could specify that DPN-2 determines what Domain policies apply even
    though we would expect them to be the same policies.
  *      = MN-specific policy key P-51 is transferred
  *      = Flow-specific policy keys P-12 and P-37 are transferred.



In this formulation, the Mobility Context transfer has to carry the Key 
information for the relevant policies, but not the full policy 
definitions.  For that to work, DPN-2 has to be able to locate each 
Policy definition by using only its Policy key.  To insure that will 
work, we might as well specify that all of the policy keys are based on 
a Domain-wide indexed set of policy definitions.  Each of the policies 
that are likely to be needed at a DPN would be preconfigured at the DPN, 
and accessible by the Policy Key.  I think this is the intention of the 
collection of Assigned Policies that is mentioned in the current draft.  
The Assigned Policies could reside on the DPN, and not part of any 
particular Mobility Context.  The process of preconfiguring the Policies 
on the the DPN should include copying over all the necessary Rule 
information (Descriptors and Actions) to the local memory of the DPN, 
and applying DPN-specific Descriptor Values and Action Values as 
appropriate at the DPN upon which the policies are being preconfigured.

Given such a Domain-wide indexed set of Policies and this method of 
preconfiguration, DPN-2 is almost able to establish the Mobility Context 
for mobile node MN as part of the smooth transfer.  But there are likely 
to be some mobile-node specific Attribute Values for some of the 
Descriptor or Action attributes of policies P-51, P-12, and P-37.  
Depending on the formulation, even Domain policies P-50 and P-52 (as 
copied into the local memory of DPN-2) might require that some such 
Attribute values be updated upon arrival of the mobile node MN (e.g., 
MN's IP address).

Consequently, as part of the transfer process for the Mobility Context 
from DPN-1 to DPN-2, DPN-1 might have to supply some attribute values so 
that DPN-2 can properly instantiate the rules of the applicable Policies.

DPN-2 might determine that flow F1 goes to gateway G21, and flow F2 goes 
to voice interface gateway G22.  These Action treatments are different 
than what was appropriate for DPN-1.  They are not Domain policies, but 
they might be Interface-Group policies or DPN-specific policies or even 
mobile-node-specific policies.  In any case, we would like to have it 
that all of the policy definitions are already available on DPN-2 (say, 
as installed in the list of Assigned Policies at DPN-2) and accessible 
using the same Policy Keys transferred from DPN-1 as part of the 
Mobility Context Transfer.  When DPN-2 accesses the applicable policies, 
it also extracts any Attribute Values from the context-transfer message 
and uses them to complete the instantiation (or, "embedding"?) of all 
the Policy rules so that the traffic to/from the mobile node can be 
properly controlled.  In this way, Assigned Policies become Requested 
Policies (or, "embedded"?), using the terminology of the draft.  But I 
think it might be better to have a different name for this.

I have elaborated this handover scenario as a way of understanding the 
various kinds of policies, and where they reside when they are used.  
For simplicity, I suggest that the Policy Keys enable access to the same 
policies throughout a Domain.  That way, the formulation of an Indexed 
Set makes good sense and seems to be reasonably manageable at the Domain 
level.

There is a tradeoff between the number of Policies in the Set, versus 
the level of generality of the Policy definition.  The more general the 
definition, the more Attribute values have to be filled in whenever the 
policy definition is used within the Mobility Context (or elsewhere).  
Since we are designing data-plane Information Models for mobility 
management, we may find that *all* applicable policies should be 
represented as part of the Mobility Context for a mobile node, even 
though many such policies would NOT be mobile-node-specific.  
Alternatively, each DPN would apply some policies to all traffic, and 
then after that the DPN would apply policies that depend on the 
particular mobile node.  The second alternative would imply that the DPN 
has two places to look for applicable policies.  But still we could 
specify that all such policies have definitions in a Domain-wide indexed 
set and have the same Policy Keys.  In the example handover I used 
above, the flows had Policy Keys P-12 and P-37. Flow F2 has the same 
Descriptors at both DPN-1 and DPN-2, but the Action for flow F2 was 
different at DPN-2 than it was at DPN-1. We might instead decide that 
modifying the Action to have a different Gateway is not natural, and 
would instead apply a new Policy Key to flow F2 at DPN-2.  In my mind, 
it is easier for the purposes of context transfer to have the same 
Policy but new Action attribute values.  Or, we could conceivably 
transfer Descriptor Keys instead of Policy Keys, since a flow is able to 
be described by using Descriptors.

If there are several FPC-Clients that have access to the same 
data-plane, then we will have to be very careful to avoid conflicts.  
But at least I think we would have to mandate that they all use the same 
Policy Keys, in order to avoid insanity.

Also, for each Policy Key, the referenced policy lives in various "states":

  *      = In the Indexed Set, the Policy Key determines a Policy definition
  *      = In the Assigned Policies on a DPN, the Policy Key allows
    reference to a partially instantiated policy
  *      = After specialization for a particular mobile node and its
    flows, the Policy Key refers to a fully instantiated (?"embedded"?)
    policy.



Maybe we could put a similar example in an Appendix.

===========================================================================

PS. Did I ever mention that I thought Policy stuff is complicated?

_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm