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.
- Your description seems to imply that there are separate mobility
contexts for each mobility session (i.e., for each bearer, or flow) that
terminates (or originates) on the mobile node.
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".
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.
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:[email protected]]
Sent: Monday, January 22, 2018 5:49 AM
To: Charlie Perkins <[email protected]>; Bertz, Lyle T [CTO]
<[email protected]>
Cc: Satoru Matsushima <[email protected]>; Sri Gundavelli (sgundave)
<[email protected]>; Moses, Danny <[email protected]>; Weaver, Farni [CTO]
<[email protected]>; Matsushima Satoru <[email protected]>
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:[email protected]]
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
[email protected]
https://www.ietf.org/mailman/listinfo/dmm
