snipped all but this response to reduce size. I believe you are close in your understanding.
Regarding policy. Policies have a couple of origins. They are typically referred to as "dynamic" (dynamically built) or "pre configured" (templates aka static policy). Prior to FPC the focus had been on dynamic or sending a 'dynamic' policy over the wire and remembering it. How pre-configuration works was largely out of the scope of most protocols but needed to be addressed in reality. The more pre-configuration of policy that was done, the more complexity was required in a dynamic only protocol so support it. Many operators referred to these static policies and their lifecycles as "magic" which is never a great sign when troubleshooting. Is the difference necessary? Yes. Pre-configuration works more as a template that needs some complementary runtime information to make it applicable to individual users. The value of templates are well understood as well as having entities pre-configured. Dynamic has trended toward highly customized policies. There are two origins of this in today's networks: - Application Detection - The Rule has a vague descriptor such as "bit torrent" or "example.com". This isn't really actionable. In 3GPP and other systems once the IP flows (5-tuple) is associated with the traffic, then the actions are associated with the 5-tuple (descriptor). In the case of 3GPP some configurations only use Application Detection to notify the policy decision point (PCRF in this case) of the 5-tuple and the PCRF will apply a rule on a gateway with the 5-tuple and action. - Application Function (AF) - There are many products that require different treatment (most people think QoS but it can be more general). The widest application is SIP / IMS based flows (which do require QoS). SDP based negotiations are dynamic and very narrow. They are, in effect, not very reusable. To support generic, re-usable Rules we put them in the Mobility-Context (not shown below) to reflect the fact that they are required but their assignment will change as the device moves. In the Assigned-DPN-Policy you have a couple of things that need to be noted: - DPN interface the Rule(s) are applied to - Complementary Settings which you described below (a 'fill in the blanks' set of attributes) - Rules to be assigned. The templates (Assigned-Policy-Key Set) and/or (dynamic) embedded rules We chose the term embedded to note it was part of the Context. It does not require being remembered once the Context is destroyed. per your question "But, stepping back a little bit... why do we need the Policies? We can have them, but we already have the Flow characterizations by using Descriptors in a natural way." I think you are talking about your proposed change. I would say I am against the Flow model you propose. Too granular of a flow makes the Context a Rule without an Action Set and why wouldn't you call it a Rule? When it is an IP address its a Session. If we nix the policy as you propose then it is truly just a Rule and we already have that convention in the model. I like the Request-Policy-Key and Assigned-Policy-Key. It's clear imo and should be adopted. The question becomes if the Embedded-Rules are vague enough they can be assigned to the top level (I *think* this is the case but will look at pcap files today to determine). If this is true then they would be a second class of Rule (one that does not need Descriptor-Id values or Action-Id) as it is never intended to be re-used after the Context is destroyed. Charlie, I would propose we keep working the Requested (template) and Embedded (disposable) first. I would like to see the updated context with the prefixes. I think we can describe the Agent/DPN logic then tackle the Flow vs. Prefix. It is a lot to try to address and we may change our views on the matter once we have an agreed up on approach for static vs. dynamic policy. Nice work! On Mon, Jan 22, 2018 at 11:18 PM, Charlie Perkins < charles.perk...@earthlink.net> wrote: > Hello again Lyle and all, > > Here's what it starts to look like. From discussion earlier today, all of > this data structure effectively resides in the DPN, and pertains to a > single mobile node that is current utilizing some of the resources of the > DPN. The DPN uses it to manage data-plane traffic to/from the Mobile Node. > > | >> +-[Mobility-Context] <G-Key> <Set> >> | +-[Interface-Group-Key] (O) >> | +-[Flow] (O) >> | | +-[Interface-Key] <Set> (O) >> | | | +-[Direction] (O) >> | | +-[Descriptor-Match-Type] (M) >> | | +-[Descriptor-Key] <Set> >> | | | +-[Descriptor-Value] >> | +-[Assigned-Policy-DPN-Key] <Set> >> | | +-[Complementary-DPN-Settings] >> | | +-[Interface-Id-Reference] >> | | +-[Embedded-Rule] <Set> (O) >> | | +-[Assigned-Policy-Key] <Set> (O) >> | +-[Requested-Policy-Key] <Set> (O) >> | +-[Complementary-Context-Settings] <Set> (O) >> > > I have been puzzling over the Policy entries for a good while and I still > am mostly in the dark. > > Here's my guess, based on the previously existing descriptions for the > terms. > > Somehow the DPN wants to know *which* policies are *available* for > managing traffic for a flow. From among those policies, the DPN wants to > know which policies have actually been *requested* for a flow. > > The available policies are called "Assigned", perhaps because they have > been assigned by the FPC Client as part of the Mobility Context (which up > until previous versions was per-flow, not per-mobile_node). Or maybe the > "assignment" was performed by the FPC Agent in charge of the DPN. > > For each "available" Policy, the actual policy is specialized from the > Policy definition (which is in the Indexed Set of policies) by including > some additional settings. In this part of the document, these settings are > called "Complementary", because they "complement" the Type of the Policy. > But in other places we have used "Values" to connote the operation of > supplying specific values for what might be thought of as "wild-card" > variable slots in the Policy definition. By the way, these wild-card slots > could either be in the Descriptor or in the Action, as I currently > understand it. > > But, stepping back a little bit... why do we need the Policies? We can > have them, but we already have the Flow characterizations by using > Descriptors in a natural way. > > Regarding Embedded-Rule... > > Since we have Rules in an indexed set, why can't the Embedded-Rule > reference the indexed Rule? I don't think that having a Rule in an Indexed > Set prevents the rule from being "embedded" in a Mobility Context. It > would be very natural for the DPN Agent (... errr, "FPC Agent") to initiate > processing for a new Flow by copying over the definition from the Indexed > Set of Rules (i.e., the Rule-Set). Or maybe this was really the intention > behind configuring the Assigned-Policy-DPN when the Mobility-Context was > first created (during registration). Even so, it would make definitional > sense to keep the *definitions* of the Rules in the indexed Rule-Set, while > still allowing them to be copied over and embedded whenever necessary for > efficiency. > > Thanks in advance for your consideration of my many questions. > > Regards, > Charlie P. > > </snip> >
_______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
