Re: Data-Plane anchors in a control-/data-plane separated deyploment
Alper Yegin <[email protected]>
| Newsgroups | gmane.ietf.nemo |
|---|---|
| Message-ID | <[email protected]> |
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, <[email protected]> <[email protected]> wrote: > > > De : Marco Liebsch [mailto:[email protected]] > Envoyé : jeudi 18 décembre 2014 15:45 > À : SEITE Pierrick IMT/OLN; [email protected] > 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: [email protected] [mailto:[email protected]] > Sent: Donnerstag, 18. Dezember 2014 15:10 > To: [email protected]; 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 > [email protected] > https://www.ietf.org/mailman/listinfo/dmm _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm