Data-Plane anchors in a control-/data-plane separated deyploment
2014-12-18 11:03:26 GMT
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
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
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
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.
| Control-Plane |
| | |
| | |
| | |
\ / V V V
+--+ -o- +---+ +---+ +---+ +--+
|MN| ---- |---|DPA|<========|DPA|<----|DPA|<--|CN|
+--+ | +---+ +---+ +---+ +--+
Rules: Rules: Rules:
Decap, Encap, host-route
_______________________________________________ dmm mailing list dmm@... https://www.ietf.org/mailman/listinfo/dmm