Folks,
at IETF91 we received the valid comment to converge on a definition of the term
'anchor'.
In the FPSM discussion, we so far distinguished Data-Plane Anchor (DPA),
traditionally a downlink encap function,
Data-Plane Node (DPN), which is more located in the access to terminate
tunnels, and regular transport nodes.
Another comment was about a scenario where a single flow may traverse multiple
DPAs on its way to the
MN.
I'd like to propose and discuss the following:
In a decentralized data-plane and a control-/data-plane separated deployment, I
consider it a reasonable
assumption that each of the so far unambiguously named data-plane nodes can
take the role of the other.
So, we may solely refer to a single type of function, e.g. Data-Plane Anchor
(DPA), which receives policies
from the Control-Plane.
For a certain deployment, it's the Control-Plane that determines the role and
associated policies for each involved
DPA.
Data-Plane nodes are agnostic to the role they play in mobility management.
Control-Plane determines the role of each DPA according to the preferred
deployment and configures the
policies accordingly.
I think such assumption allows flexible deployment and eases description in our
specifications.
I am not good in drawing ASCII, but I gave it a try (for downlink operation
only).
Using PMIP6 terms, the middle-DPA in the figure below serves as kind of LMA,
left DPA as MAG,
right DPA (one or multiple) may enforce per-host rules for traffic steering.
Would be happy to get your opinion on this proposal.
marco
+--------------------------+
| Control-Plane |
+--------------------------+
| | |
| | |
| | |
\ / V V V
+--+ -o- +---+ +---+ +---+ +--+
|MN| ---- |---|DPA|<========|DPA|<----|DPA|<--|CN|
+--+ | +---+ +---+ +---+ +--+
Rules: Rules: Rules:
Decap, Encap, host-route
Forward Forward,
qos
_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm
