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