Re: [DMM] Using traffic Descriptors to characterize flows in a Mobility Context

[Charlie Perkins]

Hello Lyle and all,

Follow-up below...

On 1/23/2018 5:38 AM, Bertz, Lyle T [CTO] wrote:

The current Mobility Context uses the assigned address or prefixes in 
conjunction with device information, or similar information in an ancestor (if 
this is a child/descendent), to let the DPN know all traffic serviced with the 
Mobility Context information MUST have a destination/source matching the 
address(es) (per the direction of the traffic).


I think this means that the DPN provides service to a flow in a way that 
depends on the source/destination addresses of the traffic of the flow.




This is an implicit Descriptor if you would like to view it that way.  It was 
placed in the original documents in this manner I would assume for consistency 
with the current and next gen designs.


Check.  In fact, a flow could be defined to also depend on other things 
about the traffic (port number, packet size, ...).




The implication of what you are proposing is a more granular (sub-session) 
context with possible no actions.


I am O.K. with having actions as well.  Granularity is according to 
whatever is convenient for whoever defines the flows.




The current implementation allows Rules to be assigned to DPNs in the 
underlying list.   The Rule containing the Descriptors and associated Actions.


This will very simple to provide, and I will change the rough draft to 
reflect this.  Suppose the Rule is something like "if byte count exceeds 
current payment, send warning".  Is that related to what you have in mind?




I would stick to the current design; placing lists of Descriptors (beyond the 
Addresses) w/o Rule and DPN assignment creates too much ambiguity, validation 
cross checking in the DPN / Agent and would result in large, granular 
hierarchies.


Does the above resolve your concern?  I don't think I grasp the 
implication of your last clause, but if associating Rules with flows is 
acceptable, then all is good.


Regards,
Charlie P.

= end of new text ===




From: Charlie Perkins 
Sent: Monday, January 22, 2018 10:08 PM
To: Bertz, Lyle T [CTO]
Cc: dmm@ietf.org
Subject: Using traffic Descriptors to characterize flows in a Mobility Context

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] 
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 

[DMM] Using traffic Descriptors to characterize flows in a Mobility Context

[Charlie Perkins]

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] 
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