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.
On 1/22/2018 8:08 PM, Charlie Perkins wrote:
Hello Lyle and all,
I had an idea about characterizing the flows in a Mobility Context.
Namely, it seems that they can be characterized using the same kind of
Descriptors that are already used in the Rules. A Rule matches
traffic against a Descriptor expression and if the traffic satisfies
the Descriptor, some action is taken.
That's just about what we want to say about a flow -- namely, that it
matches some Descriptor expression.
I am proposing to modify the Mobility Context to have some
mobile-node-specific information and a List of Descriptors, just as we
already reference under the Policy structure. Since the Descriptors
are located in an Indexed Set, the Mobility Context only has to supply
the Descriptor-Key along with Descriptor-Values as before.
I am hoping this will provide a boost towards improving the
naturalness of the Information Model for Mobility Context.
Comments?
Regards,
Charlie P.
On 1/22/2018 1:28 PM, Bertz, Lyle T [CTO] wrote:
More inline.
-----Original Message-----
From: Charlie Perkins [mailto:charles.perk...@earthlink.net]
Sent: Monday, January 22, 2018 2:27 PM
To: Bertz, Lyle T [CTO] <lyle.t.be...@sprint.com>
Cc: dmm@ietf.org
Subject: Re: [DMM] Parent versus child mobility context
Hello Lyle,
More follow-up inline. We're getting closer.
On 1/22/2018 11:27 AM, Bertz, Lyle T [CTO] wrote:
Hello Lyle and all,
I think I agree with most of what you say below. I'm concerned with
how to organize the information in the model. So, for that purpose,
please verify whether my following understandings are correct.
- The mobility context resides on a DPN.
- The mobility context provides necessary information (e.g., QoS)
for a single mobile node.
- The DPN uses it to manage data-plane traffic for that mobile node.
This may be too broad of a view. What about a mobile node with
multiple mobility sessions? In such a case it may be managing one or
more (but not necessarily all of) the mobile node's mobility
sessions
Yes. This is why I did not put "all" between "manage" and "data-plane".
LB > Ok. We should probably be more explicit though for the casual
observer if this language is used in the specification.
In my earlier email on this subject, I was using Mobility Context as
describing something more associated with a mobile node, than with a
particular flow. If you want it to mean "bearer", then we ought to
call it a Bearer.
Maybe it would be easier to understand if we had something called a
"Mobile-Node Context", and in that context we had a set of Bearer
Contexts (or, just Bearers). Each bearer would inherit from the
Mobile Node context simply by being part of it. The Mobile Node
context (serving as "parent") would determine max bandwidth, IP
address, etc. Back in the old days, we also defined security aspects
and some other factors, as part of what FPC would call the "mobility
context".
We have several concepts that have hierarchy, e.g. Service Level
(sr-id or APN - apn-oi if I recall), device level, Mobility
Session, bearers, flow based filters (effectively living within a
bearer).
There isn't anything about Service Level in the first part of the
document, and I did not find anything about Service-ID that
referenced mobility context. Mobility Context does not define
Service Level. Similarly for APN. The string "-oi" does not occur in
the document.
Device level is a mystery to me.
Now, this isn't to say that your comment is irrelevant. But, at
minimum, the relevance is not spelled out in the current document.
LB> Ack. They are not mentioned these in the documents; I was merely
providing examples.
We also have the 5G concepts as well.
We have, in fact, an infinitude of mutually contradictory 5G concepts.
I might suggest that they look at Mobile IP, which was designed exactly
to provide high-speed, low-latency, application-independent mobility
management. But, I digress.
LB> I am in agreement here but I believe that as Release 15 is
finalized in 3GPP we will see clarity. My question would be if other
next generation standards / technologies follow so that we have a
tractable problem space but I too, digress.
The one thing that is obvious is that the idea of hierarchy
applies whether it is pacers/shapers, bearers or filters that
apply some charging / gating / marking. A light touch of
lifecycle (fate sharing) amongst the hierarchy, data does not
need to be repeated within the hierarchy and building the data
structure by requiring a parent id if it was a child (implying the
parent must exist!) was the best we could do without necessarily
making decisions that may appear to preclude a specific set of
mobile network technologies.
We certainly agree on the existence of hierarchy pervading our problem
space. And on the need to consider fate-sharing for between mobile-node
authorizations and allocated bearers. But my suggested approach of
having the Bearers delineated under an inclusive Mobility Context
provides for that in a natural way. Perhaps the word "bearer" shows too
much bias towards 3GPP, in which case we could simply use "mobility
session" or "flow".
LB> Ack. I think I would object to the use of Bearer. Flow(s) may be
too granular. Maybe a verbal delineation between a Flows-Context
(implying 1 or more) and some other concept such as Session-Context
(old terminology) or Mobility-Context. imo though it may be more
beneficial to state it as a context type and imply some hierarchy?
============ end of my follow-up for this email ===================
Regards,
Charlie P.
If you really want to maintain Parent Context and Child Context as
independent structure elements, then we need to make a new indexed
set for them.
We just used a pointer from a Context to a Parent Context. If the
value was non-empty it was a child and the parent Id must point to
a valid Context.
Regards,
Charlie P.
On 1/22/2018 5:30 AM, Bertz, Lyle T [CTO] wrote:
++ mailing list
I agree with you Marco.
Keeping the parent/child relation is crucial. Although we often
cite dedicated vs. default bearers (LTE) we need to also ack that
we use hierarchical concepts throughout mobility and forwarding
management protocols, e.g. meters, session and sub-session
(includes accounting), etc.
Lifecycle association here (fate sharing of the children with the
parent) is an important concept. Many of the mobility systems
assume gateways (LMAs and MAGs) have knowledge of the relationships
between sessions and sub-session and will often kill the session in
order to reduce signaling overhead. They also assume when
installing a session / sub-session that any violation of hierarchy
rules, e.g. setting a child's max bit rate above a parent's, would
be properly enforced, i.e. it is an error or the child's value is
ignored.
For FPC we also use it to avoid sending redundant data (does one need
to send the mobile's IP address for any sort of sub-session work if it
is tied to a parent that already has it?)
-----Original Message-----
From: Marco Liebsch [mailto:marco.lieb...@neclab.eu]
Sent: Monday, January 22, 2018 5:49 AM
To: Charlie Perkins <charles.perk...@earthlink.net>; Bertz, Lyle T
[CTO] <lyle.t.be...@sprint.com>
Cc: Satoru Matsushima <satoru.matsush...@gmail.com>; Sri Gundavelli
(sgundave) <sgund...@cisco.com>; Moses, Danny <danny.mo...@intel.com>;
Weaver, Farni [CTO] <farni.wea...@sprint.com>; Matsushima Satoru
<satoru.matsush...@g.softbank.co.jp>
Subject: RE: Parent versus child mobility context
That has been introduced to reflect e.g. dedicated bearers which
come on top of default bearers hence have some level of dependency.
If context associated with a default bearer gets closed, dependent
context will follow. To me it makes sense. Others?
marco
-----Original Message-----
From: Charlie Perkins [mailto:charles.perk...@earthlink.net]
Sent: Montag, 22. Januar 2018 06:29
To: Bertz, Lyle T [CTO]
Cc: Marco Liebsch; Satoru Matsushima; Sri Gundavelli (sgundave);
Moses, Danny; Weaver, Farni [CTO]; Matsushima Satoru
Subject: Parent versus child mobility context
Hello folks,
I have looked at this several times, and I would like to propose
simplifying it to simply be a mobility context. I don't see that
the extra complication is worth it, especially right now. If, in
the future, we need it for something, we could put it back in.
Thanks for your consideration of this request.
Regards,
Charlie P.
________________________________
This e-mail may contain Sprint proprietary information intended for
the sole use of the recipient(s). Any use by others is prohibited.
If you are not the intended recipient, please contact the sender
and delete all copies of the message.
_______________________________________________
dmm mailing list
dmm@ietf.org
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdmm&data=02%7C01%7CLyle.T.Bertz%40sprint.com%7C44b677e7e34c4d5060f008d561d67569%7C4f8bc0acbd784bf5b55f1b31301d9adf%7C0%7C1%7C636522496081025164&sdata=wz8DMRig03al9oWMNVJgcFMm1tiHWToTM6KwI%2FMAiiA%3D&reserved=0
_______________________________________________
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm
_______________________________________________
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm
_______________________________________________
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm
