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 <[email protected]
<mailto:[email protected]>>
Date: Wednesday, July 16, 2014 2:42 AM
To: Sri Gundavelli <[email protected] <mailto:[email protected]>>,
"Hirschman, Brent B [CTO]" <[email protected]
<mailto:[email protected]>>, Alper Yegin <[email protected]
<mailto:[email protected]>>
Cc: "[email protected] <mailto:[email protected]>" <[email protected]
<mailto:[email protected]>>
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:[email protected]]
*Sent:* Mittwoch, 16. Juli 2014 07:18
*To:* Marco Liebsch; Hirschman, Brent B [CTO]; Alper Yegin
*Cc:* [email protected] <mailto:[email protected]>
*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 <[email protected]
<mailto:[email protected]>>
*Date: *Tuesday, July 15, 2014 1:27 PM
*To: *"Hirschman, Brent B [CTO]" <[email protected]
<mailto:[email protected]>>, Sri Gundavelli <[email protected]
<mailto:[email protected]>>, Alper Yegin <[email protected]
<mailto:[email protected]>>
*Cc: *"[email protected] <mailto:[email protected]>" <[email protected]
<mailto:[email protected]>>
*Subject: *RE: [DMM] demand for DMM traffic steering
Sri, Brent,
my intent want not to enter the inter-admin domain discussion. Valid
point that ‘visited’ cries for
inter-domain associations. My interest is less about terms but more
about the relationship between the mentioned DPAs.
I read your home and access DPA functions as they always exist together
for an MN’s registration.
This is the case when we separate control- and user-plane of a PMIP LMA
and MAG.
But what matches the Home and what the Access DPA if client MIP is deployed?
I am wondering if DMM can work around the assumption of a single DPA
(probably the distributed and
selected home DPA), which binds an MN’s IP address. That works for MIP,
PMIP as well as routing-based DMM solutions, such as
Pete’s BGP, where the DPA is assumed co-located with base stations. Same
applies to Satoru’s concept of the
EPC-Edge, which is the DPA in the context of DMM.
marco
*From:*Hirschman, Brent B [CTO] [mailto:[email protected]]
*Sent:* Dienstag, 15. Juli 2014 21:10
*To:* Sri Gundavelli (sgundave); Marco Liebsch; Alper Yegin
*Cc:* [email protected] <mailto:[email protected]>
*Subject:* RE: [DMM] demand for DMM traffic steering
If I may jump in here for a quick comment:
I like the use of access and home network technologies. A single
operator may have multiple access networks so home and visited may not
have as much relevance. Also, the Service provider may be access
agnostic or have no specific access network, so Home may be a good
representation. Differentiating between Home and visited/access should
be an administrative point and not necessarily a commercial/business point.
*/Brent Hirschman/*
Tech Dev Strategist III
Sprint Corporation
6220 Sprint Parkway
Overland Park, KS 66251
Office – 913-762-6736
Mobile – 913-593-6221
*From:*dmm [mailto:[email protected]] *On Behalf Of *Sri Gundavelli
(sgundave)
*Sent:* Tuesday, July 15, 2014 1:33 PM
*To:* Marco Liebsch; Alper Yegin
*Cc:* [email protected] <mailto:[email protected]>
*Subject:* Re: [DMM] demand for DMM traffic steering
Marco,
The "visited" terminology is more modeled for supporting inter-operator
roaming scenarios. In such roaming scenario, the peering relation
between those SP networks between every DPA in one SP network and CPA in
another SP account is highly unlikely. Its more logical to assume the
peering is between a aggregation gateway (Home CPA/DPA) in the visited
network and the CPA/DPA in the home network. That way, we keep the
number of required security relations to a minimum set. So, by staying
with the "access" and "home" terminology, we can keep the business
relation outside the technical spec. The way I see it, the DPA always
stays in the home network, unless there is DP migration, impacting the
routing infra.
Sri
*From: *Marco Liebsch <[email protected]
<mailto:[email protected]>>
*Date: *Tuesday, July 15, 2014 11:20 AM
*To: *Sri Gundavelli <[email protected] <mailto:[email protected]>>,
Alper Yegin <[email protected] <mailto:[email protected]>>
*Cc: *"[email protected] <mailto:[email protected]>" <[email protected]
<mailto:[email protected]>>
*Subject: *RE: [DMM] demand for DMM traffic steering
I fully agree that we should not bring in LMA/MAG terms and map them to
the two types of
DPAs. Though your terms Access and Home DPA allow such association.
I think we should classify the DPA first. What about *Home DPA* and
*Visited DPA* (instead of Access DPA)?
A Home DPA is an anchor, which binds an MN’s topologically correct IP
address. Transferring that IP address
to a new anchor, this will be a Visited DPA, since the imported home
address does not
fit to the DPA’s network. When the MN’s IP address is deprecated and not
used for a data session
anymore, the MN may receive a new IP address from the current anchor,
which is topologically
correct again. This makes the Visited DPA to a Home DPA. Does that match
your model?
marco
*From:*Sri Gundavelli (sgundave) [mailto:[email protected]]
*Sent:* Dienstag, 15. Juli 2014 16:09
*To:* Alper Yegin
*Cc:* Marco Liebsch; [email protected] <mailto:[email protected]>
*Subject:* Re: [DMM] demand for DMM traffic steering
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.
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.
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 <[email protected] <mailto:[email protected]>>
*Date: *Tuesday, July 15, 2014 4:01 AM
*To: *Sri Gundavelli <[email protected] <mailto:[email protected]>>
*Cc: *Marco Liebsch <[email protected]
<mailto:[email protected]>>, "[email protected] <mailto:[email protected]>"
<[email protected] <mailto:[email protected]>>
*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 <[email protected] <mailto:[email protected]>>
*Date: *Saturday, July 12, 2014 12:36 AM
*To: *Sri Gundavelli <[email protected] <mailto:[email protected]>>
*Cc: *Marco Liebsch <[email protected]
<mailto:[email protected]>>, "[email protected] <mailto:[email protected]>"
<[email protected] <mailto:[email protected]>>
*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
------------------------------------------------------------------------
This e-mail may contain Sprint proprietary information intended for the
sole use of the recipient(s). Any use by others is prohibited. If you
are not the intended recipient, please contact the sender and delete all
copies of the message.
_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm
