I agree, "anchor" is not the right term. We can go with DPN or DPE.
A node is said to have DPN functionality if it can apply special forwarding policy to a set of nodes (as opposed to forwarding traffic based on aggregate routes, as a plain router would do). The policy is provided by a controller, or the mobile node, etc. A policy on the DPN may point to encapsulating traffic (forwarding via a tunnel). A tunnel is nothing but a kind of point-to-point link anyways. The figure looks great. Our good-old HA and LMA obviously has "DPN" functionality. But they also have something more: - They are located on a link where the home address/prefix belongs to. They are attached to a link where the IP packets sent to the node arrive based on regular Internet routing. - Through ND/ARP, they make sure to receive (intercept/consume) those packets -- impersonating the mobile node when it's off link. That's why LMA/HA is also considered an "anchor", on top of their DPN role. Alper On Dec 18, 2014, at 5:35 PM, <pierrick.se...@orange.com> <pierrick.se...@orange.com> wrote: > > > De : Marco Liebsch [mailto:marco.lieb...@neclab.eu] > Envoyé : jeudi 18 décembre 2014 15:45 > À : SEITE Pierrick IMT/OLN; dmm@ietf.org > Objet : RE: [DMM] Data-Plane anchors in a control-/data-plane separated > deyploment > > Hi Pierrick, > > thanks for the feedback. Agree that we can avoid the anchor term, since there > is always some > expectation on such node. DPE is good, or simply Data-Plane Node (DPN), as we > where using it in the past discussion. No strong opinion here. > > [PS] me too… no strong opinion … I was just trying to reflect the fact that > the DPN is the enforcement point of the control plane decision … > > The WG may still need to converge on a definition of the term ‘anchor’, > though it > depends solely on the policies being configured and enforced by a data-plane > node. > The work team on Advanced Anchor selection started to investigate on this. > Point for the FPSM work is that it’s the deployment and configuration which > can make > an anchor out of a data-plane node, not a specification and the architecture > behind. > > marco > > From: pierrick.se...@orange.com [mailto:pierrick.se...@orange.com] > Sent: Donnerstag, 18. Dezember 2014 15:10 > To: dmm@ietf.org; Marco Liebsch > Subject: Re: [DMM] Data-Plane anchors in a control-/data-plane separated > deyploment > > 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. > _________________________________________________________________________________________________________________________ > > 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 > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm
_______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
