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) <[email protected]> 
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 <[email protected]>
> Date: Tuesday, July 15, 2014 4:01 AM
> To: Sri Gundavelli <[email protected]>
> Cc: Marco Liebsch <[email protected]>, "[email protected]" <[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]>
>> Date: Saturday, July 12, 2014 12:36 AM
>> To: Sri Gundavelli <[email protected]>
>> Cc: Marco Liebsch <[email protected]>, "[email protected]" <[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

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

Reply via email to