Hello Lyle,
I'm not sure I fully understand the scenarios that you have suggested.
Please let me know if my understandings are correct, as I interpolate
assertions and questions within the example text.
We’ll try to complete policy. I’ll set up a few use cases as well.
We’ll only focus on policy aspects of the context.
Here, I reckon "context" means "mobility context".
Proposed Use Case(s) (all assume DPN Selection has occurred)
I understand this to mean that various policies have been supplied to
the FPC Agents that are operating the DPNs involved with dataplane
service for the mobile node. I guess we are dealing with a single
mobile node -- is that correct?
3 policies are proposed
1. Account for and DROP all port 22 destined to the mobile.
2. Set the AMBR for all traffic from 10.5.5.0 to 3Mbps.
3. For (UE on port 318 and 10.6.5.5 port 9335) account on bucket X,
set traffic-class to Y, set max bit rate to 2Mbps.
Are these three policies for all mobile nodes (even though we may only
be dealing with one)?
The term bucket does not appear in the FPC draft document, and traffic
class seems to have something to do with ranges of IP addresses.
Are we distinguishing between AMBR and max bit rate? Is AMBR intended
to be for all mobile nodes, or for all flows of a particular mobile node?
Part 1 – Basic Policy Management
1. Create a Descriptor.
2. Create an Action.
3. Create a Rule.
4. Create a Policy.
Since we have three policies, I guess that these four items are each
replicated at least three times, with likely more for the Descriptors.
Performing the four items for Policy #1 might be pretty easy, but the
other two policies could bring up more subtle points. Anyway this will
be a very good exercise.
Any policy that puts a cap on aggregate bit rate from ALL mobile nodes
in the entire domain is going to require some protocol. Putting a cap on
the aggregate bit rates from all mobile nodes at a single DPN seems a
lot more manageable.
Part 2 – Mobility Policy Management (single context).
5. Create a Mobility Context with a pre-configured policy.
6. Create a Mobility Context with a dynamic policy.
7. Change the DPN assigned in the SGW / MAG role (mobile moves), aka
handover in a
a. make before break model.
b. break before make.
In (5) -- does this mean picking one of the three policies and creating
a Mobility Context? If we have it so that a Mobility Context is
associated with a mobile node (my very fond hope), then does the
preconfigured policy get to be installed at network entry? Or maybe
there is a sort of "generalized" Mobility Context that has Settings that
are configured for a particular mobile node at network entry, and
modified as needed as the mobile node moves and creates new flows and
finishes old flows and so on.
Is a Dynamic Policy something that changes as the mobile node moves around?
For (7), presumably the Context Transfer will be very similar, but the
handover protocol will be different. Of course I would like it, if FPC
had something to say about handover protocol. I did not see anything
about that yet in the document, but since the term MAG appears, I guess
we are to assume PMIP. For the purposes of this discussion, it might be
nice to have something similar to Figure 16, but redrawn in PowerPoint
for clarity.
As drawn in Figure 16, let's say that FPC Client lives in the control
plane on a node called the "LMA Controller (LMA-C)" and makes run-time
decisions. Is that your intention?
Part 3 – Secondary context (bearers)
8. Add a secondary context
9. Secondary context update based upon 7a and 7b.
10. Remove a secondary context
The term "Secondary context" does not appear in the FPC draft document.
But a bearer has some resemblance to a flow. So maybe you mean that the
identity of the mobile node establishes a primary context, and flow
creation establishes a secondary context. Is that correct? If so, then
there should not be much difference between 7a and 7b (I hope!).
Regards,
Charlie P.
_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm
