Re: demand for DMM traffic steering

Hi Pierrick,

The transport network controller below has a specific role, it could be building loop-free topology, or its performing some hich CPU computations. But, that controller has no mobility awareness. From the point of view of the MC, the transport controller is managing the forwarding state for non-mobile prefixes. When there is a Controller to Controller interface, potentially MC when it wants to realize a Routing Update, it can interface with  the Transport controller. But,  we don't have reflect those aspects. We can just state the requirement and that is the MC's ability to route infra. How that is done, using a MC to TC interface, or some thing else is out of scope for DMM, IMO.

Regards
Sri




From: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>
Date: Thursday, July 17, 2014 3:05 AM
To: Sri Gundavelli <[email protected]<mailto:[email protected]>>, "Hirschman, Brent B [CTO]" <[email protected]<mailto:[email protected]>>, Marco Liebsch <[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





Hi Sri,

Regarding the architecture… transport network may have their own controller, and, so, I’m not sure the mobility controller should have direct interface to transport network rressource.  I rather see an iteraction between mobility and transpoirt network conttroller… something like that:



[cid:[email protected]]

Pierrick




De : dmm [mailto:[email protected]] De la part de Sri Gundavelli (sgundave)
Envoyé : mercredi 16 juillet 2014 15:18
À : Hirschman, Brent B [CTO]; Marco Liebsch; Alper Yegin
Cc : [email protected]<mailto:[email protected]>
Objet : Re: [DMM] demand for DMM traffic steering

Brent – Agree. We need to capture this discussion. We can agree on a common terminology.


Regards
Sri

From: <Hirschman>, "Brent B [CTO]" <[email protected]<mailto:[email protected]>>
Date: Tuesday, July 15, 2014 12:10 PM
To: Sri Gundavelli <[email protected]<mailto:[email protected]>>, Marco Liebsch <[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

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.



[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






________________________________

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.

_________________________________________________________________________________________________________________________

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