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

This is a multi-part message in MIME format.
--===============3553091882392222429==
Content-Type: multipart/alternative;
 boundary="------------CB1595955967FF47C40BCA60"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------CB1595955967FF47C40BCA60
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit


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?



--------------CB1595955967FF47C40BCA60
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit

<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p><br>
      Hello folks,<br>
      <br>
      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.<br>
      <br>
      Regards,<br>
      Charlie P.<br>
      <br>
==============================================================================<br>
      <br>
      Example for mobile node movement from DPN-1 to DPN-2.<br>
      <br>
      MN has two flows:<br>
      <br>
    </p>
    <ul>
      <li>    = F1: best effort traffic</li>
      <li>    = F2: voice call</li>
    </ul>
    <p><br>
      <br>
      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):<br>
      <br>
    </p>
    <ul>
      <li>    = MN's IP address (MN_IP)</li>
      <li>    = Policy X for F1</li>
      <li>    = Policy Y for F2</li>
      <li>    = other stuff (charging ID, current remaining credit, ...)</li>
    </ul>
    <p><br>
      <br>
      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.<br>
      <br>
      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.<br>
      <br>
      Then DPN-1 might store in the Mobility Context for MN the
      following rules:<br>
      <br>
    </p>
    <ul>
      <li>    = R1: If (packet belongs to flow F1), then route through
        G11</li>
      <li>    = R2: If (packet belongs to flow F2), then route through
        G11</li>
      <li>    = R3: Else, drop</li>
    </ul>
    <p><br>
      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.<br>
      <br>
      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.<br>
      <br>
      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.<br>
      <br>
      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.<br>
      <br>
      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.<br>
      <br>
      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.<br>
      <br>
      This depends on how the policy rules are stored on DPN-1.  Here is
      one possibility:<br>
      <br>
    </p>
    <ul>
      <li>    = DPN-specific policies are not transferred with the
        Mobility Context</li>
      <li>    = 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.</li>
      <li>    = MN-specific policy key P-51 is transferred</li>
      <li>    = Flow-specific policy keys P-12 and P-37 are transferred.</li>
    </ul>
    <p><br>
      <br>
      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.<br>
      <br>
      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).<br>
      <br>
      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.<br>
      <br>
      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.<br>
      <br>
      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.<br>
      <br>
      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.<br>
      <br>
      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.<br>
      <br>
      Also, for each Policy Key, the referenced policy lives in various
      "states":<br>
      <br>
    </p>
    <ul>
      <li>    = In the Indexed Set, the Policy Key determines a Policy
        definition</li>
      <li>    = In the Assigned Policies on a DPN, the Policy Key allows
        reference to a partially instantiated policy</li>
      <li>    = After specialization for a particular mobile node and
        its flows, the Policy Key refers to a fully instantiated
        (?"embedded"?) policy.</li>
    </ul>
    <p><br>
      <br>
      Maybe we could put a similar example in an Appendix.<br>
      <br>
===========================================================================<br>
      <br>
      PS. Did I ever mention that I thought Policy stuff is complicated?<br>
      <br>
      <br>
    </p>
  </body>
</html>

--------------CB1595955967FF47C40BCA60--


--===============3553091882392222429==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============3553091882392222429==--