Hi Marco,
I definitely agree that a DP node can play different role; quoting the PMIP
example, a node can play either à MAG or LMA role, or even both rôles. A single
name thus makes sense. However, the term anchor is à bit confusing since it
refers implicitely to HA/ LMA. So, i suggest to use DPE node, standing for data
plane enfoncement node. The DPE can support different functions: tunnel
termination, encap, etc....
Pierrick
Envoyé depuis mon Sony Xperia SP d'Orange
---- Marco Liebsch a écrit ----
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
_________________________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm
