Re: 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]
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.



[cid:[email protected]]





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.


[cid:[email protected]]




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

_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm