Re: [DMM] demand for DMM traffic steering
Hi Sri, Hi all, Agree with Sri that the discussions were kept on a high level. Please note that the following draft tried to provide the work items that were discussed http://www.ietf.org/id/draft-liebsch-dmm-framework-analysis-03.txt I thought that we had agreed on these work items, but apparently we need to spend more time on this! Best regards, Georgios Van: dmm [dmm-boun...@ietf.org] namens Sri Gundavelli (sgundave) [sgund...@cisco.com] Verzonden: donderdag 17 juli 2014 22:23 Aan: Alper Yegin CC: dmm@ietf.org Onderwerp: Re: [DMM] demand for DMM traffic steering Alper, What we broadly agreed in Nov/Mar IETF's (based on offline discussion) to go with a design group approach. Approach of Individual I-D's, comparing them, selecting the best will go no where, IMO. There are like dozen proposal on the table. With that goal in mind we have had several conf calls (with smaller group of folks) in Jan time frame. What we discussed there and in f2f meetings was summarized in IETF 89 WG slides. Off course, that does not give it a WG status, but the goal is to come to some agreement on the approach and then document the approach. Fair comment on lack of details and that its at a high-level. The discussion is purposely kept at a high-level and we need to work out the details. We should have more formal design meetings and if we converge, we should then write a I-D(s). Sri From: Alper Yegin alper.ye...@yegin.orgmailto:alper.ye...@yegin.org Date: Thursday, July 17, 2014 1:06 PM To: Sri Gundavelli sgund...@cisco.commailto:sgund...@cisco.com Cc: Marco Liebsch marco.lieb...@neclab.eumailto:marco.lieb...@neclab.eu, dmm@ietf.orgmailto:dmm@ietf.org dmm@ietf.orgmailto:dmm@ietf.org Subject: Re: [DMM] demand for DMM traffic steering Sri, You SDNize a solution, then co-locate two entities, and voila the mobility protocol vanishes, and all that's left is OpenFlow. That's why there's no mobility protocol in that picture. It'd really be good if we see your solution documented, it's not easy to fully grasp it in a QA style. (I'm saying this to save us energy. If we read your I-D, we can all see how it meets the requirements. Otherwise, we are going to have to ask about them and have lengthy discussions to understand things). Alper On Jul 17, 2014, at 10:51 PM, Sri Gundavelli (sgundave) wrote: Alper, There is no mobility protocol here in this below deployment modek. Mobility protocol based on GTP/PMIP comes into the second case when we introduce the access and the home network based separation. In a flat model, its just a SDN interface between the CP and DP functions. But, the way we perform gateway selection, allocate application specific gateways, migrate a data plane session, allow UE the gateway indicators ..it meets every single DMM requirement that we have discussed in this group and with the side-affect of realizing CP/DP separation. CA18E534-121E-4582-90A4-14AA394AEDEE.png Sri From: Alper Yegin alper.ye...@yegin.orgmailto:alper.ye...@yegin.org Date: Thursday, July 17, 2014 12:39 PM To: Sri Gundavelli sgund...@cisco.commailto:sgund...@cisco.com Cc: Marco Liebsch marco.lieb...@neclab.eumailto:marco.lieb...@neclab.eu, dmm@ietf.orgmailto:dmm@ietf.org dmm@ietf.orgmailto:dmm@ietf.org Subject: Re: [DMM] demand for DMM traffic steering Sri, PMIP is a solution. You can apply SDN approach to it by splitting CP and DP. For example, a draft like draft-bernardos-dmm-pmip-03 talks about access network anchoring. And you can apply SDN to it (as you already mentioned jun your examples on this thread), or not. Alper On Jul 17, 2014, at 9:21 PM, Sri Gundavelli (sgundave) wrote: I do not know your definition of approach vs solution, but one can argue DMM itself is about a deployment model and an approach. I always insisted its less of a protocol work and more about a tying many aspects. So, what we have been discussing is a solution approach which has the essential properties of CP/DP separation, aspect of optimized/stateless data plane, application specific gateway allocations .. etc and that at the end is an approach for realizing DMM. Sri On 7/17/14 10:59 AM, Alper Yegin alper.ye...@yegin.orgmailto:alper.ye...@yegin.org wrote: Intense readingŠ :-) Lot of abstractions, which I can only follow by relating to specific solutions. In my understanding, what Sri is describing is about how to apply UP/CP separation to various DMM solutions. In the examples I see a number of DMM solutions defined with UP/CP separation using Sri's terminology (e.g., per-flow mobility, access network anchoring, host-specific route based solutions, etc). So, it's not a solution by itself, but it's an approach that can be applied to various solution techniques to SDNize them. And that indeed has value. Alper ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman
Re: [DMM] demand for DMM traffic steering
I am only about functions, not picky about terms. But with certain terms there is some expectation of the function behind. We need to be clear about the roles of both, access and home DPA for mobility management and assess their role in driving the different DMM scenarios. marco From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com] Sent: Donnerstag, 17. Juli 2014 06:37 To: Marco Liebsch; Hirschman, Brent B [CTO]; Alper Yegin Cc: dmm@ietf.org Subject: Re: [DMM] demand for DMM traffic steering Hi Marco, If there should be the use of word, Anchor in access DPA term is a minor issue, IMO. We can always fix that and come up with a better term. The key point is the distinction in roles and functionalities of these two entities and which we seem to agree. Home DPA is clearly the routing anchor and access DPA is entity that is providing some mobility support and it is also the first-hop router. We also need to highlight that the functional role is always in the context of a mobility session. The Access DPA may assume the role of Home DPA for one specific MN's session, while it may offer the Access DPA function to another mobility session. If we bring in offload at an Access DPA, the Access DPA provides a different IP address to the MN and becomes the Home DPA for traffic using that IP. The role of the original Home DPA may be solely to determine which traffic to offload at the Access DPA. When we discuss offload at the Access DPA, we should qualify this and state that this offload is for certain IP flows for a session anchored on a remote Home DPA. While there may be another session anchored on the same Access DPA for that MN (with the access DPA acting as a Home DPA for that local session), but that session will have not relation to the Home DPA of the first session and so making sure your last sentence above did not suggest that. Its strictly the UE choice on address selection for local offload. On the aspect of session migration across Home DPA's you had a comment in one of your earlier emails. I see session migration as a tool used in very specific scenarios. When we migrate a session from Home-DPA-1 to Home-DPA-2, truly the session is completely migrated to the new Home DPA; even the routing infra is updated and that allows us to completely forget the previous Home-DPA where the session was previously hosted. For a mobility session, at a point of time, we have states in the Controller, Home DPA and Access DPA (optionally) and that's about it. Home DPA may have been changed, Access DPA may have been changed as well, but the state is always present in these three entities. Regards Sri From: Marco Liebsch marco.lieb...@neclab.eumailto:marco.lieb...@neclab.eu Date: Wednesday, July 16, 2014 2:31 PM To: Sri Gundavelli sgund...@cisco.commailto:sgund...@cisco.com, Hirschman, Brent B [CTO] brent.hirsch...@sprint.commailto:brent.hirsch...@sprint.com, Alper Yegin alper.ye...@yegin.orgmailto:alper.ye...@yegin.org Cc: dmm@ietf.orgmailto:dmm@ietf.org dmm@ietf.orgmailto:dmm@ietf.org Subject: RE: [DMM] demand for DMM traffic steering Sri, please see inline. From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com] Sent: Mittwoch, 16. Juli 2014 15:32 To: Marco Liebsch; Hirschman, Brent B [CTO]; Alper Yegin Cc: dmm@ietf.orgmailto:dmm@ietf.org Subject: Re: [DMM] demand for DMM traffic steering Marco, If the idea is DP anchor relocation after every L3 mobility event, you have a single-node DPA model. The MN attach point at every location will take the Home DPA Role after each Relocation trigger. Any time you cannot relocate a Home DPA, you end with a two node Access/Home DPA model, which IMO offers nice flexibility with respect to when to initiate DP relocation and when to go with a two-node DPA model. Yes, that's close to the model I had in mind. Remain anchored at the DPA, which preforms mobility management. Then, at some point when it makes sense (not every L3 handover, but when e.g. the routing path can be optimized), relocate the DPA. The new DPA may provide a new, topologically correct IP to the MN, or may import and bind the previous IP if IP address continuity is required. In the latter case tailored routing rules for traffic steering are required. The role of the Access DPA in case the Home DPA performs mobility management I left aside so far, as it serves more as locator (access gateway). It's not necessarily an anchor in terms of mobility management, unless we talk about a hierarchy of mobility anchors. If we bring in offload at an Access DPA, the Access DPA provides a different IP address to the MN and becomes the Home DPA for traffic using that IP. The role of the original Home DPA may be solely to determine which traffic to offload at the Access DPA. With all this (the Access DPA becoming a Home DPA..) I am wondering if the Access DPA deserves the term Anchor. Also according to your description we only have Home DPAs, which bind
Re: [DMM] demand for DMM traffic steering
Intense reading… :-) Lot of abstractions, which I can only follow by relating to specific solutions. In my understanding, what Sri is describing is about how to apply UP/CP separation to various DMM solutions. In the examples I see a number of DMM solutions defined with UP/CP separation using Sri's terminology (e.g., per-flow mobility, access network anchoring, host-specific route based solutions, etc). So, it's not a solution by itself, but it's an approach that can be applied to various solution techniques to SDNize them. And that indeed has value. Alper ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] demand for DMM traffic steering
Understood. If there is agreement on the functional roles, the terms can be worked out. Sri From: Marco Liebsch marco.lieb...@neclab.eumailto:marco.lieb...@neclab.eu Date: Thursday, July 17, 2014 8:30 AM To: Sri Gundavelli sgund...@cisco.commailto:sgund...@cisco.com, Hirschman, Brent B [CTO] brent.hirsch...@sprint.commailto:brent.hirsch...@sprint.com, Alper Yegin alper.ye...@yegin.orgmailto:alper.ye...@yegin.org Cc: dmm@ietf.orgmailto:dmm@ietf.org dmm@ietf.orgmailto:dmm@ietf.org Subject: RE: [DMM] demand for DMM traffic steering I am only about functions, not picky about terms. But with certain terms there is some expectation of the function behind. We need to be clear about the roles of both, access and home DPA for mobility management and assess their role in driving the different DMM scenarios. marco From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com] Sent: Donnerstag, 17. Juli 2014 06:37 To: Marco Liebsch; Hirschman, Brent B [CTO]; Alper Yegin Cc: dmm@ietf.orgmailto:dmm@ietf.org Subject: Re: [DMM] demand for DMM traffic steering Hi Marco, If there should be the use of word, Anchor in access DPA term is a minor issue, IMO. We can always fix that and come up with a better term. The key point is the distinction in roles and functionalities of these two entities and which we seem to agree. Home DPA is clearly the routing anchor and access DPA is entity that is providing some mobility support and it is also the first-hop router. We also need to highlight that the functional role is always in the context of a mobility session. The Access DPA may assume the role of Home DPA for one specific MN's session, while it may offer the Access DPA function to another mobility session. If we bring in offload at an Access DPA, the Access DPA provides a different IP address to the MN and becomes the Home DPA for traffic using that IP. The role of the original Home DPA may be solely to determine which traffic to offload at the Access DPA. When we discuss offload at the Access DPA, we should qualify this and state that this offload is for certain IP flows for a session anchored on a remote Home DPA. While there may be another session anchored on the same Access DPA for that MN (with the access DPA acting as a Home DPA for that local session), but that session will have not relation to the Home DPA of the first session and so making sure your last sentence above did not suggest that. Its strictly the UE choice on address selection for local offload. On the aspect of session migration across Home DPA's you had a comment in one of your earlier emails. I see session migration as a tool used in very specific scenarios. When we migrate a session from Home-DPA-1 to Home-DPA-2, truly the session is completely migrated to the new Home DPA; even the routing infra is updated and that allows us to completely forget the previous Home-DPA where the session was previously hosted. For a mobility session, at a point of time, we have states in the Controller, Home DPA and Access DPA (optionally) and that's about it. Home DPA may have been changed, Access DPA may have been changed as well, but the state is always present in these three entities. Regards Sri From: Marco Liebsch marco.lieb...@neclab.eumailto:marco.lieb...@neclab.eu Date: Wednesday, July 16, 2014 2:31 PM To: Sri Gundavelli sgund...@cisco.commailto:sgund...@cisco.com, Hirschman, Brent B [CTO] brent.hirsch...@sprint.commailto:brent.hirsch...@sprint.com, Alper Yegin alper.ye...@yegin.orgmailto:alper.ye...@yegin.org Cc: dmm@ietf.orgmailto:dmm@ietf.org dmm@ietf.orgmailto:dmm@ietf.org Subject: RE: [DMM] demand for DMM traffic steering Sri, please see inline. From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com] Sent: Mittwoch, 16. Juli 2014 15:32 To: Marco Liebsch; Hirschman, Brent B [CTO]; Alper Yegin Cc: dmm@ietf.orgmailto:dmm@ietf.org Subject: Re: [DMM] demand for DMM traffic steering Marco, If the idea is DP anchor relocation after every L3 mobility event, you have a single-node DPA model. The MN attach point at every location will take the Home DPA Role after each Relocation trigger. Any time you cannot relocate a Home DPA, you end with a two node Access/Home DPA model, which IMO offers nice flexibility with respect to when to initiate DP relocation and when to go with a two-node DPA model. Yes, that’s close to the model I had in mind. Remain anchored at the DPA, which preforms mobility management. Then, at some point when it makes sense (not every L3 handover, but when e.g. the routing path can be optimized), relocate the DPA. The new DPA may provide a new, topologically correct IP to the MN, or may import and bind the previous IP if IP address continuity is required. In the latter case tailored routing rules for traffic steering are required. The role of the Access DPA in case the Home DPA performs mobility management I left aside so far, as it serves more as locator (access gateway
Re: [DMM] demand for DMM traffic steering
I do not know your definition of approach vs solution, but one can argue DMM itself is about a deployment model and an approach. I always insisted its less of a protocol work and more about a tying many aspects. So, what we have been discussing is a solution approach which has the essential properties of CP/DP separation, aspect of optimized/stateless data plane, application specific gateway allocations .. etc and that at the end is an approach for realizing DMM. Sri On 7/17/14 10:59 AM, Alper Yegin alper.ye...@yegin.org wrote: Intense readingŠ :-) Lot of abstractions, which I can only follow by relating to specific solutions. In my understanding, what Sri is describing is about how to apply UP/CP separation to various DMM solutions. In the examples I see a number of DMM solutions defined with UP/CP separation using Sri's terminology (e.g., per-flow mobility, access network anchoring, host-specific route based solutions, etc). So, it's not a solution by itself, but it's an approach that can be applied to various solution techniques to SDNize them. And that indeed has value. Alper ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] demand for DMM traffic steering
Hi Pierrick, Using the term Anchor in Access DPA is not a minor issue IMHO, because it implicitly assimilates anchoring and traffic redirection function. I'm fine with the removal of the Anchor term from the Access DPA. Access Gateway, Data Plane Redirection function ..(except Locator or any terms which ties the architecture to a specific protocol) is fine to me. Now, let’s consider the example above: the UE initiates a first IP flow , flow#1,using the address obtained from the DPA of its current access (DPA#1), i.e. using the local address… Here, no mobility support, no DPR coming into play… . Then the UE attaches to a new access, i.e. changes the first-hop router, and obtain an IP address from the DPA of the new access ( DPA#2). Flow#1 remains anchored to DPA#1 and dataplane is updated to the DPR of the new access. The DPR may, or may not, be supported by the first-hop router of the new access. The DPR may, or may not be collocated with the DPA function. Then the UE intiates a second flow, flow#2, with address obtained from DPA#2 as source address. The UE is thus served by two DPAs, each handling their own mobility sessions; mobility functions are DPA#1 and DPR for flow#1 and only DPA#2 for flow#2. What I want to stress here is 1) a UE can be served by more than one home DPA and 2) the DPR function comes into play only when mobility support is required, i.e. when the UE attaches to a new first-hop router. Sure. One conclusions: #1: Agree. A UE can be served by more than two home DPA's. I thought this is the same example I gave as well. This is where the gateway selection on Application basis comes into picture. #2. Agree. I said earlier, While there may be another session anchored on the same Access DPA for that MN (with the access DPA acting as a Home DPA for that local session), but that session will have not relation to the Home DPA of the first session and ... Access DPS function is not needed when the access gateway where to MN is attached too serves as its Home DPA. But, while I agree with the conclusions I'm not following this comment. The DPR may, or may not, be supported by the first-hop router of the new access. The DPR may, or may not be collocated with the DPA function. We do need some function in the access gateway which can ensure the traffic for the first flow reaches its home. That interface could be Routing infra, Open Flow .. but some magic needs to happen there. Regards Sri From: pierrick.se...@orange.commailto:pierrick.se...@orange.com pierrick.se...@orange.commailto:pierrick.se...@orange.com Date: Thursday, July 17, 2014 2:48 AM To: Sri Gundavelli sgund...@cisco.commailto:sgund...@cisco.com, Marco Liebsch marco.lieb...@neclab.eumailto:marco.lieb...@neclab.eu, Hirschman, Brent B [CTO] brent.hirsch...@sprint.commailto:brent.hirsch...@sprint.com, Alper Yegin alper.ye...@yegin.orgmailto:alper.ye...@yegin.org Cc: dmm@ietf.orgmailto:dmm@ietf.org dmm@ietf.orgmailto:dmm@ietf.org Subject: RE: [DMM] demand for DMM traffic steering Hi, Just to be sure that we are on the same page…. De : dmm [mailto:dmm-boun...@ietf.org] De la part de Sri Gundavelli (sgundave) Envoyé : jeudi 17 juillet 2014 06:37 À : Marco Liebsch; Hirschman, Brent B [CTO]; Alper Yegin Cc : dmm@ietf.orgmailto:dmm@ietf.org Objet : Re: [DMM] demand for DMM traffic steering Hi Marco, If there should be the use of word, Anchor in access DPA term is a minor issue, IMO. We can always fix that and come up with a better term. The key point is the distinction in roles and functionalities of these two entities and which we seem to agree. Home DPA is clearly the routing anchor and access DPA is entity that is providing some mobility support and it is also the first-hop router. We also need to highlight that the functional role is always in the context of a mobility session. The Access DPA may assume the role of Home DPA for one specific MN's session, while it may offer the Access DPA function to another mobility session. If we bring in offload at an Access DPA, the Access DPA provides a different IP address to the MN and becomes the Home DPA for traffic using that IP. The role of the original Home DPA may be solely to determine which traffic to offload at the Access DPA. When we discuss offload at the Access DPA, we should qualify this and state that this offload is for certain IP flows for a session anchored on a remote Home DPA. While there may be another session anchored on the same Access DPA for that MN (with the access DPA acting as a Home DPA for that local session), [PS] Access DPA and Home DPA should be considered as different network functions and not be confused with network entities. Using the term Anchor in Access DPA is not a minor issue IMHO, because it implicitly assimilates anchoring and traffic redirection function. Actually, we should talk about DPA, i.e. the node where IP address are topologically correct and data plane
Re: [DMM] demand for DMM traffic steering
Sri, PMIP is a solution. You can apply SDN approach to it by splitting CP and DP. For example, a draft like draft-bernardos-dmm-pmip-03 talks about access network anchoring. And you can apply SDN to it (as you already mentioned jun your examples on this thread), or not. Alper On Jul 17, 2014, at 9:21 PM, Sri Gundavelli (sgundave) wrote: I do not know your definition of approach vs solution, but one can argue DMM itself is about a deployment model and an approach. I always insisted its less of a protocol work and more about a tying many aspects. So, what we have been discussing is a solution approach which has the essential properties of CP/DP separation, aspect of optimized/stateless data plane, application specific gateway allocations .. etc and that at the end is an approach for realizing DMM. Sri On 7/17/14 10:59 AM, Alper Yegin alper.ye...@yegin.org wrote: Intense readingŠ :-) Lot of abstractions, which I can only follow by relating to specific solutions. In my understanding, what Sri is describing is about how to apply UP/CP separation to various DMM solutions. In the examples I see a number of DMM solutions defined with UP/CP separation using Sri's terminology (e.g., per-flow mobility, access network anchoring, host-specific route based solutions, etc). So, it's not a solution by itself, but it's an approach that can be applied to various solution techniques to SDNize them. And that indeed has value. Alper ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] demand for DMM traffic steering
Sri, You SDNize a solution, then co-locate two entities, and voila the mobility protocol vanishes, and all that's left is OpenFlow. That's why there's no mobility protocol in that picture. It'd really be good if we see your solution documented, it's not easy to fully grasp it in a QA style. (I'm saying this to save us energy. If we read your I-D, we can all see how it meets the requirements. Otherwise, we are going to have to ask about them and have lengthy discussions to understand things). Alper On Jul 17, 2014, at 10:51 PM, Sri Gundavelli (sgundave) wrote: Alper, There is no mobility protocol here in this below deployment modek. Mobility protocol based on GTP/PMIP comes into the second case when we introduce the access and the home network based separation. In a flat model, its just a SDN interface between the CP and DP functions. But, the way we perform gateway selection, allocate application specific gateways, migrate a data plane session, allow UE the gateway indicators ..it meets every single DMM requirement that we have discussed in this group and with the side-affect of realizing CP/DP separation. CA18E534-121E-4582-90A4-14AA394AEDEE.png Sri From: Alper Yegin alper.ye...@yegin.org Date: Thursday, July 17, 2014 12:39 PM To: Sri Gundavelli sgund...@cisco.com Cc: Marco Liebsch marco.lieb...@neclab.eu, dmm@ietf.org dmm@ietf.org Subject: Re: [DMM] demand for DMM traffic steering Sri, PMIP is a solution. You can apply SDN approach to it by splitting CP and DP. For example, a draft like draft-bernardos-dmm-pmip-03 talks about access network anchoring. And you can apply SDN to it (as you already mentioned jun your examples on this thread), or not. Alper On Jul 17, 2014, at 9:21 PM, Sri Gundavelli (sgundave) wrote: I do not know your definition of approach vs solution, but one can argue DMM itself is about a deployment model and an approach. I always insisted its less of a protocol work and more about a tying many aspects. So, what we have been discussing is a solution approach which has the essential properties of CP/DP separation, aspect of optimized/stateless data plane, application specific gateway allocations .. etc and that at the end is an approach for realizing DMM. Sri On 7/17/14 10:59 AM, Alper Yegin alper.ye...@yegin.org wrote: Intense readingŠ :-) Lot of abstractions, which I can only follow by relating to specific solutions. In my understanding, what Sri is describing is about how to apply UP/CP separation to various DMM solutions. In the examples I see a number of DMM solutions defined with UP/CP separation using Sri's terminology (e.g., per-flow mobility, access network anchoring, host-specific route based solutions, etc). So, it's not a solution by itself, but it's an approach that can be applied to various solution techniques to SDNize them. And that indeed has value. Alper ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] demand for DMM traffic steering
Alper, What we broadly agreed in Nov/Mar IETF's (based on offline discussion) to go with a design group approach. Approach of Individual I-D's, comparing them, selecting the best will go no where, IMO. There are like dozen proposal on the table. With that goal in mind we have had several conf calls (with smaller group of folks) in Jan time frame. What we discussed there and in f2f meetings was summarized in IETF 89 WG slides. Off course, that does not give it a WG status, but the goal is to come to some agreement on the approach and then document the approach. Fair comment on lack of details and that its at a high-level. The discussion is purposely kept at a high-level and we need to work out the details. We should have more formal design meetings and if we converge, we should then write a I-D(s). Sri From: Alper Yegin alper.ye...@yegin.orgmailto:alper.ye...@yegin.org Date: Thursday, July 17, 2014 1:06 PM To: Sri Gundavelli sgund...@cisco.commailto:sgund...@cisco.com Cc: Marco Liebsch marco.lieb...@neclab.eumailto:marco.lieb...@neclab.eu, dmm@ietf.orgmailto:dmm@ietf.org dmm@ietf.orgmailto:dmm@ietf.org Subject: Re: [DMM] demand for DMM traffic steering Sri, You SDNize a solution, then co-locate two entities, and voila the mobility protocol vanishes, and all that's left is OpenFlow. That's why there's no mobility protocol in that picture. It'd really be good if we see your solution documented, it's not easy to fully grasp it in a QA style. (I'm saying this to save us energy. If we read your I-D, we can all see how it meets the requirements. Otherwise, we are going to have to ask about them and have lengthy discussions to understand things). Alper On Jul 17, 2014, at 10:51 PM, Sri Gundavelli (sgundave) wrote: Alper, There is no mobility protocol here in this below deployment modek. Mobility protocol based on GTP/PMIP comes into the second case when we introduce the access and the home network based separation. In a flat model, its just a SDN interface between the CP and DP functions. But, the way we perform gateway selection, allocate application specific gateways, migrate a data plane session, allow UE the gateway indicators ..it meets every single DMM requirement that we have discussed in this group and with the side-affect of realizing CP/DP separation. CA18E534-121E-4582-90A4-14AA394AEDEE.png Sri From: Alper Yegin alper.ye...@yegin.orgmailto:alper.ye...@yegin.org Date: Thursday, July 17, 2014 12:39 PM To: Sri Gundavelli sgund...@cisco.commailto:sgund...@cisco.com Cc: Marco Liebsch marco.lieb...@neclab.eumailto:marco.lieb...@neclab.eu, dmm@ietf.orgmailto:dmm@ietf.org dmm@ietf.orgmailto:dmm@ietf.org Subject: Re: [DMM] demand for DMM traffic steering Sri, PMIP is a solution. You can apply SDN approach to it by splitting CP and DP. For example, a draft like draft-bernardos-dmm-pmip-03 talks about access network anchoring. And you can apply SDN to it (as you already mentioned jun your examples on this thread), or not. Alper On Jul 17, 2014, at 9:21 PM, Sri Gundavelli (sgundave) wrote: I do not know your definition of approach vs solution, but one can argue DMM itself is about a deployment model and an approach. I always insisted its less of a protocol work and more about a tying many aspects. So, what we have been discussing is a solution approach which has the essential properties of CP/DP separation, aspect of optimized/stateless data plane, application specific gateway allocations .. etc and that at the end is an approach for realizing DMM. Sri On 7/17/14 10:59 AM, Alper Yegin alper.ye...@yegin.orgmailto:alper.ye...@yegin.org wrote: Intense readingŠ :-) Lot of abstractions, which I can only follow by relating to specific solutions. In my understanding, what Sri is describing is about how to apply UP/CP separation to various DMM solutions. In the examples I see a number of DMM solutions defined with UP/CP separation using Sri's terminology (e.g., per-flow mobility, access network anchoring, host-specific route based solutions, etc). So, it's not a solution by itself, but it's an approach that can be applied to various solution techniques to SDNize them. And that indeed has value. Alper ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] demand for DMM traffic steering
Sri and all I didn’t capture all the discussion, but I agree with your architecture and terminology in this pictures. Sir, where can i find your architecture draft of this? regards, ryuji On 2014/07/15, at PM 11:09, Sri Gundavelli (sgundave) sgund...@cisco.com wrote: Alper, We should not attempt to map these terms to existing protocol functions at this stage. All we are saying, in a controller-based model the CP is terminated on the controller/(Home CPA) and the user-plane is terminated on the Home DPA. The interface between these entities (CPA and DPA) is OpenFlow/FORCES/XYZ. Unless, we bring the access and the home level separation, there is no classic mobility protocol interface in such model. If we keep this very flat, there is just a controller and a bunch of data-plane nodes with a OpenFlow type interface. In one variation, the access DPN and the Home DPA can be colored in the same way with the same function, keeping it very flat. Alternatively, the Access DPN can have forwarding state that will allow it forward the packets to the Home DPA. 763C6945-9163-4593-B1B1-B8418DC06CF6.jpg If we bring the Access and Home network aspects in the above model, the CPA functions can be split into Access CPA and Home CPA. In such model, the classic mobility protocol interfaces can be used between these two entities. 659612F5-BC77-40CD-9686-FBE918D6735B.jpg Here, I can map the functions as following: Home CPA == Home Agent (CP), LMA (CP), GGSN (CP), PGW (CP) Home DPA == Home Agent (UP), LMA (UP), GGSN (UP), PGW (UP) Access CPA == Foreign Agent (CP), MAG (CP), SGSN (CP), SGW (CP), Access DPN == Foreign Agent (UP), MAG (UP), SGSN (CP), SGW (UP), Regards Sri From: Alper Yegin alper.ye...@yegin.org Date: Tuesday, July 15, 2014 4:01 AM To: Sri Gundavelli sgund...@cisco.com Cc: Marco Liebsch marco.lieb...@neclab.eu, dmm@ietf.org dmm@ietf.org Subject: Re: [DMM] demand for DMM traffic steering Sri, I was asking about that for the sake of getting all of the details (or following the discussion better). HoA to COA binding change (EID to Locator mapping) should not be looked at as gateway relocation. Unless we move the address across anchors by updating the routing infrastructure, there is never a DPA migration. The moment we talk about Locator, it implies we have access DPA and home DPA, and change of access DPA is not relocation, its only a state change on the home DPA. So, in your terminology MAG is a access DPA and LMA is a home DPA, right? And as such, both MAG and LMA are called anchors. Calling MAG an anchor may come as a surprise to some people. We need to nail down the terminology. Alper On Jul 15, 2014, at 10:00 AM, Sri Gundavelli (sgundave) wrote: Alper – That can be fixed. Sri From: Alper Yegin alper.ye...@yegin.org Date: Saturday, July 12, 2014 12:36 AM To: Sri Gundavelli sgund...@cisco.com Cc: Marco Liebsch marco.lieb...@neclab.eu, dmm@ietf.org dmm@ietf.org Subject: Re: [DMM] demand for DMM traffic steering Sri and Marco, Is any of what you are describing captured in the existing drafts? If so, please provide the pointers. Alper ___ 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
Re: [DMM] demand for DMM traffic steering
Ryuji, We need to capture this discussion. Goal for next week is for all to agree on few things and write-up some text right there Š. Regards Sri On 7/16/14 12:03 AM, Ryuji Wakikawa ryuji.wakik...@gmail.com wrote: Sri and all I didn¹t capture all the discussion, but I agree with your architecture and terminology in this pictures. Sir, where can i find your architecture draft of this? regards, ryuji ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] demand for DMM traffic steering
I agree the below points. - Jouni 7/16/2014 4:32 PM, Sri Gundavelli (sgundave) kirjoitti: Marco, If the idea is DP anchor relocation after every L3 mobility event, you have a single-node DPA model. The MN attach point at every location will take the Home DPA Role after each Relocation trigger. Any time you cannot relocate a Home DPA, you end with a two node Access/Home DPA model, which IMO offers nice flexibility with respect to when to initiate DP relocation and when to go with a two-node DPA model. 1. Yes, Home DPA does not mean Centralized DPA. But, we have to agree this is a special case of a two node (Access/Home) DPA model. 2. Yes. Home DPA can be in the access Base Station, but that node MUST function as a L3 router. We cannot put this functionality on a L2 bridging device, as that creates lot of technical issues. We should just say, Home DPA can be hosted in any node that can function as a L3 router Also, for this approach we need to scope the size of the mobility domain given the high-frequency routing updates. This model works when the size of the admin domain is relatively small. Any case, we need to qualify those aspects. Regards Sri From: Marco Liebsch marco.lieb...@neclab.eu mailto:marco.lieb...@neclab.eu Date: Wednesday, July 16, 2014 2:42 AM To: Sri Gundavelli sgund...@cisco.com mailto:sgund...@cisco.com, Hirschman, Brent B [CTO] brent.hirsch...@sprint.com mailto:brent.hirsch...@sprint.com, Alper Yegin alper.ye...@yegin.org mailto:alper.ye...@yegin.org Cc: dmm@ietf.org mailto:dmm@ietf.org dmm@ietf.org mailto:dmm@ietf.org Subject: RE: [DMM] demand for DMM traffic steering Sri, I think this matches my description and model very well. For traffic steering I consider the MN’s current Home DPA of particular relevance, without looking further into the mobility protocol specifics between the Home and the Access DPA. My view of anchor relocation is to change the Home DPA mid-session. Binding an existing HoA/HNP to the new Home DPA requires steering of the MN’s traffic northbound to the Home DPA. To conclude from that discussion: Home DPA does not mean centralized DPA, but the Home DPA can be distributed to an extreme (access, Base Station, ..) if the deployment model considers this. Does your model consider offloading traffic at the Access DPA? marco *From:*Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com] *Sent:* Mittwoch, 16. Juli 2014 07:18 *To:* Marco Liebsch; Hirschman, Brent B [CTO]; Alper Yegin *Cc:* dmm@ietf.org mailto:dmm@ietf.org *Subject:* Re: [DMM] demand for DMM traffic steering Hi Marco, DMM can absolutely support a Single DPA model, but we have to acknowledge that this is a special case of the two-node (Access-DPA and Home-DPA) model. The home and access DPA functions collapse into a single entity, eliminating the need for a tunnel or other overlay forwarding state. The same argument goes for the Single Controller model; the very flat model with a single controller that is managing similarly colored DPA nodes (or Access and Home DPA nodes) in the network. This is the special case of the two node (Access and Home CPA) model.The Access and Home CPA functions collapse, eliminating the need for a mobility protocol interface. Now, to your point as how these functions map to different vEPC models and proposals, 1. In the very flat model that Pete wants to realize, the Access DPA and Home DPA functions collapse into a single entity. In that model, there is no access DPA, the aggressive domain-wide route routing updates will ensure the current/serving access DPA is the topological anchor for the address. The base station/first-host access router where the MN is attached is truly the routing anchor. 2. Looking at the Satoru-san's and wakikawa-san's proposal, its again a flat model. They goal is to remove mobility specific states from the forwarding nodes. The fundamental difference between the flat model and is about the interface between the Controller and the DPA entities. In one model its the OpenFlow/FORCES interface and the other approach is about a hitchhiking on the BGP transport. But, in both the models there is single DPA. While I'm not opposed to the very flat model, but I do believe we can look at the flat model as an sub-case of the other approach with access and DPA/CPA functions. 3. On the question on how this maps to client mobility protocols, the Access DPA for a client-based system is a just a first-hop router. That node is not providing any mobility functions. This is the case for both IPSec/IKEv2, MIPv6 as well. The mobility states and the relation is only at the MN and at the home CPA/DPA. Regards Sri *From: *Marco Liebsch marco.lieb...@neclab.eu mailto:marco.lieb...@neclab.eu *Date: *Tuesday, July 15, 2014 1:27 PM *To: *Hirschman, Brent B [CTO] brent.hirsch...@sprint.com mailto:brent.hirsch...@sprint.com, Sri Gundavelli sgund...@cisco.com mailto:sgund...@cisco.com
Re: [DMM] demand for DMM traffic steering
Hi Marco, If there should be the use of word, Anchor in access DPA term is a minor issue, IMO. We can always fix that and come up with a better term. The key point is the distinction in roles and functionalities of these two entities and which we seem to agree. Home DPA is clearly the routing anchor and access DPA is entity that is providing some mobility support and it is also the first-hop router. We also need to highlight that the functional role is always in the context of a mobility session. The Access DPA may assume the role of Home DPA for one specific MN's session, while it may offer the Access DPA function to another mobility session. If we bring in offload at an Access DPA, the Access DPA provides a different IP address to the MN and becomes the Home DPA for traffic using that IP. The role of the original Home DPA may be solely to determine which traffic to offload at the Access DPA. When we discuss offload at the Access DPA, we should qualify this and state that this offload is for certain IP flows for a session anchored on a remote Home DPA. While there may be another session anchored on the same Access DPA for that MN (with the access DPA acting as a Home DPA for that local session), but that session will have not relation to the Home DPA of the first session and so making sure your last sentence above did not suggest that. Its strictly the UE choice on address selection for local offload. On the aspect of session migration across Home DPA's you had a comment in one of your earlier emails. I see session migration as a tool used in very specific scenarios. When we migrate a session from Home-DPA-1 to Home-DPA-2, truly the session is completely migrated to the new Home DPA; even the routing infra is updated and that allows us to completely forget the previous Home-DPA where the session was previously hosted. For a mobility session, at a point of time, we have states in the Controller, Home DPA and Access DPA (optionally) and that's about it. Home DPA may have been changed, Access DPA may have been changed as well, but the state is always present in these three entities. Regards Sri From: Marco Liebsch marco.lieb...@neclab.eumailto:marco.lieb...@neclab.eu Date: Wednesday, July 16, 2014 2:31 PM To: Sri Gundavelli sgund...@cisco.commailto:sgund...@cisco.com, Hirschman, Brent B [CTO] brent.hirsch...@sprint.commailto:brent.hirsch...@sprint.com, Alper Yegin alper.ye...@yegin.orgmailto:alper.ye...@yegin.org Cc: dmm@ietf.orgmailto:dmm@ietf.org dmm@ietf.orgmailto:dmm@ietf.org Subject: RE: [DMM] demand for DMM traffic steering Sri, please see inline. From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com] Sent: Mittwoch, 16. Juli 2014 15:32 To: Marco Liebsch; Hirschman, Brent B [CTO]; Alper Yegin Cc: dmm@ietf.orgmailto:dmm@ietf.org Subject: Re: [DMM] demand for DMM traffic steering Marco, If the idea is DP anchor relocation after every L3 mobility event, you have a single-node DPA model. The MN attach point at every location will take the Home DPA Role after each Relocation trigger. Any time you cannot relocate a Home DPA, you end with a two node Access/Home DPA model, which IMO offers nice flexibility with respect to when to initiate DP relocation and when to go with a two-node DPA model. Yes, that’s close to the model I had in mind. Remain anchored at the DPA, which preforms mobility management. Then, at some point when it makes sense (not every L3 handover, but when e.g. the routing path can be optimized), relocate the DPA. The new DPA may provide a new, topologically correct IP to the MN, or may import and bind the previous IP if IP address continuity is required. In the latter case tailored routing rules for traffic steering are required. The role of the Access DPA in case the Home DPA performs mobility management I left aside so far, as it serves more as locator (access gateway). It’s not necessarily an anchor in terms of mobility management, unless we talk about a hierarchy of mobility anchors. If we bring in offload at an Access DPA, the Access DPA provides a different IP address to the MN and becomes the Home DPA for traffic using that IP. The role of the original Home DPA may be solely to determine which traffic to offload at the Access DPA. With all this (the Access DPA becoming a Home DPA..) I am wondering if the Access DPA deserves the term Anchor. Also according to your description we only have Home DPAs, which bind an MN’s IP and perform mobility management. The Access-thing is not an anchor until it performs offload, which makes a Home DPA out of it. Isn’t it more a Data Plane Access Gateway until it becomes a real anchor? marco ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] demand for DMM traffic steering
Hi Marco, Might be difficult to converge over email on this topic. But, I will try. Then: If we think about the case 2b below, that implies that the initially selected DPA (is it the home DPA in your model?) binds a HoA which is topologically not correct from the very beginning. Here, traffic steering may be required from the first registration already. I am just wondering if there is a reasonable use case behind this. PI address binding? The entity (CP and/or DP) where the subscriber's control plane state got created is always Home CPA and the entity where the subscriber home address (lets say EID :) ) is topologically anchored is always the home DPA. There is no reason for the home CPA to allocate a DPA and a prefix that have not topological relation. IMO, the CPA should ensure it allocates a topologically correct address, by selecting a DPA and the allocated address pool associated with that anchor. Any incorrect allocation may happen for supporting session chaining in roaming scenarios, but truly the home CPA in such scenario is outside the admin domain. If our goal is for realizing optimized routing, we rather ensure there is no traffic steering requirement after the first registration. But again, there are two scenarios here. The a.) very flat model with a controller and a bunch of DPA's that Pete was interested in (Pete's model), and the b) model of splitting CP and DP in access and home domains. For the former case, the DPA (Home+Access) will always be a floating anchor, but for the later case, its only the access DPA which is a floating anchor. IMO, in both the cases, the aspect of CPA migration is rare and for very specific use-cases that we need to qualify. Moving a mobile’s mobility state (binding a HoA to a locator) from a previous DPA to a new DPA is gateway relocation. Well, relocation of the data plane anchor. The control plane anchor will/may stay the same. HoA to COA binding change (EID to Locator mapping) should not be looked at as gateway relocation. Unless we move the address across anchors by updating the routing infrastructure, there is never a DPA migration. The moment we talk about Locator, it implies we have access DPA and home DPA, and change of access DPA is not relocation, its only a state change on the home DPA. The DPA relocation is mainly for the very flat, pete's model. But, again, that model will be bounded in size, given the # of routes. Agree, the CPA relocation is rare, specially in the controller-based architectures. We have some use cases for Geo-Redundancy where CPA migration will be needed, but again we need to qualify that use-cases as that comes at some cost. Regards Sri From: Marco Liebsch marco.lieb...@neclab.eumailto:marco.lieb...@neclab.eu Date: Monday, July 14, 2014 5:50 AM To: Sri Gundavelli sgund...@cisco.commailto:sgund...@cisco.com, dmm@ietf.orgmailto:dmm@ietf.org dmm@ietf.orgmailto:dmm@ietf.org Subject: RE: [DMM] demand for DMM traffic steering Hi Sri, Thanks for your prompt response. please see inline. From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com] Sent: Freitag, 11. Juli 2014 19:46 To: Marco Liebsch; dmm@ietf.orgmailto:dmm@ietf.org Subject: Re: [DMM] demand for DMM traffic steering Hi Marco, I think we may have to qualify the term anchor. In our conf calls we used the terms, Control Plane Anchor (CPA), Data Plane Anchor (DPA) with Home/Access prefix tags. I thought that gets clear from my description, but you are right. This thread focuses on the data/user plane anchor. At the start of a session, the selected anchor assigns a topologically correct address. I guess you’re referring to the mobility session, not the data session. Yes, that’s today’s procedure: Select (data-plane) anchor first, then assign an IP address which fits to the anchor’s network. The HoA/HNP for a mobile node's session is always topologically anchored on that node. That anchor is the Home CPA/DPA (Integrated case) and for the controller scenario, those functions are split across two nodes. However, once the MN changes its point of attachment, then the selected anchor for that attachment can be the Acces-CPA/Access-DPA in relation to the home CPA/DPA. The session is still anchored on the home CPA/DPA, but the access CPA/DPA is providing the CoA (pardon me, its your locator per the LISP terminology, or our classic CoA) and the routing state. However, this access CPN/DPN is also a Home CPN/DPN as the MN can create a new session and may obtain a new HoA/MNP. I think it can be even the same CPA that controls multiple DPAs, whether it’s the home or the access. About the terms: I like the identifier/locator terms as they apply to any mobility solution without taking a particular one (e.g. PMIP) as base line for a discussion. This is not LISP-specific. See, MIP maps an identifier (HoA) to a locator (CoA). Northbound to the HA, the HoA serves as both, identifier and locator assuming
Re: [DMM] demand for DMM traffic steering
Alper – That can be fixed. Sri From: Alper Yegin alper.ye...@yegin.orgmailto:alper.ye...@yegin.org Date: Saturday, July 12, 2014 12:36 AM To: Sri Gundavelli sgund...@cisco.commailto:sgund...@cisco.com Cc: Marco Liebsch marco.lieb...@neclab.eumailto:marco.lieb...@neclab.eu, dmm@ietf.orgmailto:dmm@ietf.org dmm@ietf.orgmailto:dmm@ietf.org Subject: Re: [DMM] demand for DMM traffic steering Sri and Marco, Is any of what you are describing captured in the existing drafts? If so, please provide the pointers. Alper ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] demand for DMM traffic steering
Hi Sri, Thanks for your prompt response. please see inline. From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com] Sent: Freitag, 11. Juli 2014 19:46 To: Marco Liebsch; dmm@ietf.org Subject: Re: [DMM] demand for DMM traffic steering Hi Marco, I think we may have to qualify the term anchor. In our conf calls we used the terms, Control Plane Anchor (CPA), Data Plane Anchor (DPA) with Home/Access prefix tags. I thought that gets clear from my description, but you are right. This thread focuses on the data/user plane anchor. At the start of a session, the selected anchor assigns a topologically correct address. I guess you're referring to the mobility session, not the data session. Yes, that's today's procedure: Select (data-plane) anchor first, then assign an IP address which fits to the anchor's network. The HoA/HNP for a mobile node's session is always topologically anchored on that node. That anchor is the Home CPA/DPA (Integrated case) and for the controller scenario, those functions are split across two nodes. However, once the MN changes its point of attachment, then the selected anchor for that attachment can be the Acces-CPA/Access-DPA in relation to the home CPA/DPA. The session is still anchored on the home CPA/DPA, but the access CPA/DPA is providing the CoA (pardon me, its your locator per the LISP terminology, or our classic CoA) and the routing state. However, this access CPN/DPN is also a Home CPN/DPN as the MN can create a new session and may obtain a new HoA/MNP. I think it can be even the same CPA that controls multiple DPAs, whether it's the home or the access. About the terms: I like the identifier/locator terms as they apply to any mobility solution without taking a particular one (e.g. PMIP) as base line for a discussion. This is not LISP-specific. See, MIP maps an identifier (HoA) to a locator (CoA). Northbound to the HA, the HoA serves as both, identifier and locator assuming a topologically correct HoA at that anchor. Same for PMIP; or even Cellular IP, where the locator is an output port, or BGP, where the locator is a hext hop :) So I think this is suitable terminology to discuss DMM, in particular if we still differentiate the northbound and the southbound operation from a distributed data plane anchor viewpoint. Questions to answer are then how are packet routed to selected DPA in particular if the assigned HoA is topologically incorrect at the used DPA. The protocol southbound to the DPA may use any mobility specific transport, e.g. tunnel (to the locator :)) . The aspect of session relocation is relevant for the initial session and at that point your case#2 comes into picture. Yes, that was the rationale behind. At this point, we have a choice to keep both Access CPN/DPN and Home CPN/DPN and apply traditional schemes for forwarding traffic, or relocate the session to the new Access CPA/DPA and make that as the Home CPA/DPN for the initial session. But, the access CPA/DPA is always a local gateway (typically first-hop router) and so not sure how the gateway selection can be relevant in this context. Moving a mobile's mobility state (binding a HoA to a locator) from a previous DPA to a new DPA is gateway relocation. Well, relocation of the data plane anchor. The control plane anchor will/may stay the same. Gateway selection is relevant in a two node architecture with access and home anchors, and selection being about the home anchor. Selection is an orthogonal problem. Of course an initial DPA and a target DPA must be selected during DPA relocation. But the mechanism to transfer binding context and to steer traffic to the new anchor is a different technology compared to selection. Then: If we think about the case 2b below, that implies that the initially selected DPA (is it the home DPA in your model?) binds a HoA which is topologically not correct from the very beginning. Here, traffic steering may be required from the first registration already. I am just wondering if there is a reasonable use case behind this. PI address binding? marco Regards Sri From: Marco Liebsch marco.lieb...@neclab.eumailto:marco.lieb...@neclab.eu Date: Friday, July 11, 2014 8:59 AM To: dmm@ietf.orgmailto:dmm@ietf.org dmm@ietf.orgmailto:dmm@ietf.org Subject: [DMM] demand for DMM traffic steering Folks, I would like to discuss the demand for DMM traffic steering as preparation for Toronto. DMM enables smart deployment and selection of network components serving as User-Plane anchor to the mobile node. The MN's IP address or prefix (HNP/HoA) is assigned to the selected anchor and bound to the MN's locator (CoA, pCoA, ..) Now, there are two cases: (1) Selected anchor is in the network of the MN's HoA/HNP (topologically correct address) (2) Selected anchor is not in the network of the MN's HoA/HNP (topologically incorrect address) Case (1) is what IP mobility assumed so far. Default routes in the transport network deliver
Re: [DMM] demand for DMM traffic steering
Hi Alper, the discussed procedures were always on the table in the context of decentralized anchors. There are expired drafts but also active ones, which address the use case to change a data plane anchor while keeping the previously assigned HoA in use. Also our ID about a DMM framework addresses these use cases in the context of traffic steering above data plane anchor level. Hope that helps. marco From: Alper Yegin [mailto:alper.ye...@yegin.org] Sent: Samstag, 12. Juli 2014 09:36 To: Sri Gundavelli (sgundave) Cc: Marco Liebsch; dmm@ietf.org Subject: Re: [DMM] demand for DMM traffic steering Sri and Marco, Is any of what you are describing captured in the existing drafts? If so, please provide the pointers. Alper On Jul 11, 2014, at 8:45 PM, Sri Gundavelli (sgundave) wrote: Hi Marco, I think we may have to qualify the term anchor. In our conf calls we used the terms, Control Plane Anchor (CPA), Data Plane Anchor (DPA) with Home/Access prefix tags. At the start of a session, the selected anchor assigns a topologically correct address. The HoA/HNP for a mobile node's session is always topologically anchored on that node. That anchor is the Home CPA/DPA (Integrated case) and for the controller scenario, those functions are split across two nodes. However, once the MN changes its point of attachment, then the selected anchor for that attachment can be the Acces-CPA/Access-DPA in relation to the home CPA/DPA. The session is still anchored on the home CPA/DPA, but the access CPA/DPA is providing the CoA (pardon me, its your locator per the LISP terminology, or our classic CoA) and the routing state. However, this access CPN/DPN is also a Home CPN/DPN as the MN can create a new session and may obtain a new HoA/MNP. The aspect of session relocation is relevant for the initial session and at that point your case#2 comes into picture. At this point, we have a choice to keep both Access CPN/DPN and Home CPN/DPN and apply traditional schemes for forwarding traffic, or relocate the session to the new Access CPA/DPA and make that as the Home CPA/DPN for the initial session. But, the access CPA/DPA is always a local gateway (typically first-hop router) and so not sure how the gateway selection can be relevant in this context. Gateway selection is relevant in a two node architecture with access and home anchors, and selection being about the home anchor. Regards Sri From: Marco Liebsch marco.lieb...@neclab.eumailto:marco.lieb...@neclab.eu Date: Friday, July 11, 2014 8:59 AM To: dmm@ietf.orgmailto:dmm@ietf.org dmm@ietf.orgmailto:dmm@ietf.org Subject: [DMM] demand for DMM traffic steering Folks, I would like to discuss the demand for DMM traffic steering as preparation for Toronto. DMM enables smart deployment and selection of network components serving as User-Plane anchor to the mobile node. The MN's IP address or prefix (HNP/HoA) is assigned to the selected anchor and bound to the MN's locator (CoA, pCoA, ..) Now, there are two cases: (1) Selected anchor is in the network of the MN's HoA/HNP (topologically correct address) (2) Selected anchor is not in the network of the MN's HoA/HNP (topologically incorrect address) Case (1) is what IP mobility assumed so far. Default routes in the transport network deliver the packet into the network which hosts the MN's assigned anchor. Case (2) can happen in 2 cases: (a) MN gets assigned a new anchor mid-session but wants to keep its HoA/HNP. That's what has been called so far anchor re-location (b) MN has a stable IP address (e.g. profile-bound) but the network wants to select an anchor according to the requested service, i.e. anchor should be close to a local server or CDN cache. In that case the MN's IP address will be topologically incorrect from the very beginning of its attachment. All cases (a) and (b) may require steering the MN's traffic according to a host policy, as the route deviates from the default. First questions we may rise: I)Are we on the same page regarding the above cases? II) What comes first in DMM: IP address configuration or anchor selection? Hope we can discuss some opinions ahead of the meeting. marco ___ dmm mailing list dmm@ietf.orgmailto:dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] demand for DMM traffic steering
Sri and Marco, Is any of what you are describing captured in the existing drafts? If so, please provide the pointers. Alper On Jul 11, 2014, at 8:45 PM, Sri Gundavelli (sgundave) wrote: Hi Marco, I think we may have to qualify the term anchor. In our conf calls we used the terms, Control Plane Anchor (CPA), Data Plane Anchor (DPA) with Home/Access prefix tags. At the start of a session, the selected anchor assigns a topologically correct address. The HoA/HNP for a mobile node's session is always topologically anchored on that node. That anchor is the Home CPA/DPA (Integrated case) and for the controller scenario, those functions are split across two nodes. However, once the MN changes its point of attachment, then the selected anchor for that attachment can be the Acces-CPA/Access-DPA in relation to the home CPA/DPA. The session is still anchored on the home CPA/DPA, but the access CPA/DPA is providing the CoA (pardon me, its your locator per the LISP terminology, or our classic CoA) and the routing state. However, this access CPN/DPN is also a Home CPN/DPN as the MN can create a new session and may obtain a new HoA/MNP. The aspect of session relocation is relevant for the initial session and at that point your case#2 comes into picture. At this point, we have a choice to keep both Access CPN/DPN and Home CPN/DPN and apply traditional schemes for forwarding traffic, or relocate the session to the new Access CPA/DPA and make that as the Home CPA/DPN for the initial session. But, the access CPA/DPA is always a local gateway (typically first-hop router) and so not sure how the gateway selection can be relevant in this context. Gateway selection is relevant in a two node architecture with access and home anchors, and selection being about the home anchor. Regards Sri From: Marco Liebsch marco.lieb...@neclab.eu Date: Friday, July 11, 2014 8:59 AM To: dmm@ietf.org dmm@ietf.org Subject: [DMM] demand for DMM traffic steering Folks, I would like to discuss the demand for DMM traffic steering as preparation for Toronto. DMM enables smart deployment and selection of network components serving as User-Plane anchor to the mobile node. The MN’s IP address or prefix (HNP/HoA) is assigned to the selected anchor and bound to the MN’s locator (CoA, pCoA, ..) Now, there are two cases: (1) Selected anchor is in the network of the MN’s HoA/HNP (topologically correct address) (2) Selected anchor is not in the network of the MN’s HoA/HNP (topologically incorrect address) Case (1) is what IP mobility assumed so far. Default routes in the transport network deliver the packet into the network which hosts the MN’s assigned anchor. Case (2) can happen in 2 cases: (a) MN gets assigned a new anchor mid-session but wants to keep its HoA/HNP. That’s what has been called so far anchor re-location (b) MN has a stable IP address (e.g. profile-bound) but the network wants to select an anchor according to the requested service, i.e. anchor should be close to a local server or CDN cache. In that case the MN’s IP address will be topologically incorrect from the very beginning of its attachment. All cases (a) and (b) may require steering the MN’s traffic according to a host policy, as the route deviates from the default. First questions we may rise: I)Are we on the same page regarding the above cases? II) What comes first in DMM: IP address configuration or anchor selection? Hope we can discuss some opinions ahead of the meeting. marco ___ 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
Re: [DMM] demand for DMM traffic steering
Hi Marco, I think we may have to qualify the term anchor. In our conf calls we used the terms, Control Plane Anchor (CPA), Data Plane Anchor (DPA) with Home/Access prefix tags. At the start of a session, the selected anchor assigns a topologically correct address. The HoA/HNP for a mobile node's session is always topologically anchored on that node. That anchor is the Home CPA/DPA (Integrated case) and for the controller scenario, those functions are split across two nodes. However, once the MN changes its point of attachment, then the selected anchor for that attachment can be the Acces-CPA/Access-DPA in relation to the home CPA/DPA. The session is still anchored on the home CPA/DPA, but the access CPA/DPA is providing the CoA (pardon me, its your locator per the LISP terminology, or our classic CoA) and the routing state. However, this access CPN/DPN is also a Home CPN/DPN as the MN can create a new session and may obtain a new HoA/MNP. The aspect of session relocation is relevant for the initial session and at that point your case#2 comes into picture. At this point, we have a choice to keep both Access CPN/DPN and Home CPN/DPN and apply traditional schemes for forwarding traffic, or relocate the session to the new Access CPA/DPA and make that as the Home CPA/DPN for the initial session. But, the access CPA/DPA is always a local gateway (typically first-hop router) and so not sure how the gateway selection can be relevant in this context. Gateway selection is relevant in a two node architecture with access and home anchors, and selection being about the home anchor. Regards Sri From: Marco Liebsch marco.lieb...@neclab.eumailto:marco.lieb...@neclab.eu Date: Friday, July 11, 2014 8:59 AM To: dmm@ietf.orgmailto:dmm@ietf.org dmm@ietf.orgmailto:dmm@ietf.org Subject: [DMM] demand for DMM traffic steering Folks, I would like to discuss the demand for DMM traffic steering as preparation for Toronto. DMM enables smart deployment and selection of network components serving as User-Plane anchor to the mobile node. The MN’s IP address or prefix (HNP/HoA) is assigned to the selected anchor and bound to the MN’s locator (CoA, pCoA, ..) Now, there are two cases: (1) Selected anchor is in the network of the MN’s HoA/HNP (topologically correct address) (2) Selected anchor is not in the network of the MN’s HoA/HNP (topologically incorrect address) Case (1) is what IP mobility assumed so far. Default routes in the transport network deliver the packet into the network which hosts the MN’s assigned anchor. Case (2) can happen in 2 cases: (a) MN gets assigned a new anchor mid-session but wants to keep its HoA/HNP. That’s what has been called so far anchor re-location (b) MN has a stable IP address (e.g. profile-bound) but the network wants to select an anchor according to the requested service, i.e. anchor should be close to a local server or CDN cache. In that case the MN’s IP address will be topologically incorrect from the very beginning of its attachment. All cases (a) and (b) may require steering the MN’s traffic according to a host policy, as the route deviates from the default. First questions we may rise: I)Are we on the same page regarding the above cases? II) What comes first in DMM: IP address configuration or anchor selection? Hope we can discuss some opinions ahead of the meeting. marco ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] demand for DMM traffic steering
Hi Sri, Thanks for your explanation! I think I agree with most of your explanatory text. The gateway selection comes in place for both situations that you described, where the gateway is the access CPA/DPA mentioned in your example. Each time that the MN changes its point of attachment a gateway selection procedure needs to take place. Since a suitable anchor (gateway) should be selected (e.g. close to local service, such as a CDN cache) The issues that arise here are: = What comes first: Anchor (Gateway) Selection or IP address (HNP/HoA) assignment? = How is the traffic steering supported? Please note that traffic steering is required when: o) Transport network’s default routes do not convey traffic to MN’s anchor o) After anchor (gateway) relocation and demand for IP address continuity o) At initial anchor assignment when MN’s configured IP address does not topologically fit into the selected anchor’s network Best regards, Georgios PS. please note that I am on holidays and have very sporadic Internet access Van: dmm [dmm-boun...@ietf.org] namens Sri Gundavelli (sgundave) [sgund...@cisco.com] Verzonden: vrijdag 11 juli 2014 19:45 Aan: Marco Liebsch; dmm@ietf.org Onderwerp: Re: [DMM] demand for DMM traffic steering Hi Marco, I think we may have to qualify the term anchor. In our conf calls we used the terms, Control Plane Anchor (CPA), Data Plane Anchor (DPA) with Home/Access prefix tags. At the start of a session, the selected anchor assigns a topologically correct address. The HoA/HNP for a mobile node's session is always topologically anchored on that node. That anchor is the Home CPA/DPA (Integrated case) and for the controller scenario, those functions are split across two nodes. However, once the MN changes its point of attachment, then the selected anchor for that attachment can be the Acces-CPA/Access-DPA in relation to the home CPA/DPA. The session is still anchored on the home CPA/DPA, but the access CPA/DPA is providing the CoA (pardon me, its your locator per the LISP terminology, or our classic CoA) and the routing state. However, this access CPN/DPN is also a Home CPN/DPN as the MN can create a new session and may obtain a new HoA/MNP. The aspect of session relocation is relevant for the initial session and at that point your case#2 comes into picture. At this point, we have a choice to keep both Access CPN/DPN and Home CPN/DPN and apply traditional schemes for forwarding traffic, or relocate the session to the new Access CPA/DPA and make that as the Home CPA/DPN for the initial session. But, the access CPA/DPA is always a local gateway (typically first-hop router) and so not sure how the gateway selection can be relevant in this context. Gateway selection is relevant in a two node architecture with access and home anchors, and selection being about the home anchor. Regards Sri From: Marco Liebsch marco.lieb...@neclab.eumailto:marco.lieb...@neclab.eu Date: Friday, July 11, 2014 8:59 AM To: dmm@ietf.orgmailto:dmm@ietf.org dmm@ietf.orgmailto:dmm@ietf.org Subject: [DMM] demand for DMM traffic steering Folks, I would like to discuss the demand for DMM traffic steering as preparation for Toronto. DMM enables smart deployment and selection of network components serving as User-Plane anchor to the mobile node. The MN’s IP address or prefix (HNP/HoA) is assigned to the selected anchor and bound to the MN’s locator (CoA, pCoA, ..) Now, there are two cases: (1) Selected anchor is in the network of the MN’s HoA/HNP (topologically correct address) (2) Selected anchor is not in the network of the MN’s HoA/HNP (topologically incorrect address) Case (1) is what IP mobility assumed so far. Default routes in the transport network deliver the packet into the network which hosts the MN’s assigned anchor. Case (2) can happen in 2 cases: (a) MN gets assigned a new anchor mid-session but wants to keep its HoA/HNP. That’s what has been called so far anchor re-location (b) MN has a stable IP address (e.g. profile-bound) but the network wants to select an anchor according to the requested service, i.e. anchor should be close to a local server or CDN cache. In that case the MN’s IP address will be topologically incorrect from the very beginning of its attachment. All cases (a) and (b) may require steering the MN’s traffic according to a host policy, as the route deviates from the default. First questions we may rise: I)Are we on the same page regarding the above cases? II) What comes first in DMM: IP address configuration or anchor selection? Hope we can discuss some opinions ahead of the meeting. marco ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
