Hi Georgios, It seems to me that the requirement: "need of supporting both single-operator and cross-operator mobility management" is a deployment requirement. I understand the requirement but I do not see how to "translate it" into an IP generic wording. FSo, fcusing only on protocols (as we are supposed to) how would you reformulate your requirement? Is talking about "capability to establish security associations between mobility entities" would be acceptable?
Br, Pierrick > -----Message d'origine----- > De : [email protected] [mailto:[email protected]] De la part de > [email protected] > Envoyé : vendredi 25 mai 2012 07:49 > À : [email protected] > Cc : [email protected] > Objet : Re: [DMM] draft requirement REQ-1: Distributed deployment > (single-operator and cross-operator?) > > Hi Anthony, > > I am not sure whether it can be incorporated in REQ-4 or whether it > could be considered as being an additional requirement! > I am in favour of adding a new requirement that satisfies this issue! > > Best regards, > Georgios > > ________________________________________ > Van: h chan [[email protected]] > Verzonden: donderdag 24 mei 2012 19:36 > Aan: Karagiannis, G. (EWI) > CC: [email protected] > Onderwerp: RE: [DMM] draft requirement REQ-1: Distributed deployment > (single-operator and cross-operator?) > > Georgios, > > Do you think whether REQ-4 may be a better place to discuss. REQ-4 is > talking about compatibility. It already includes compatibility with > other (such as 3GPP) mobility protocols. We can check what else are > needed there for cross-operator mobility. > > If you agree, we can move this cross-operator issue over the REQ-4 > thread. > > H Anthony Chan > > -----Original Message----- > From: [email protected] [mailto:[email protected]] > Sent: Thursday, May 24, 2012 1:06 AM > To: h chan > Cc: [email protected] > Subject: RE: [DMM] draft requirement REQ-1: Distributed deployment > (single-operator and cross-operator?) > > Hi Anthony, Hi all, > > During the last DMM meeting in Paris, I have raised the issue of > cross-operator mobility management support. > Not sure if this issue can be satisfied by incorporating it into REQ-1 > Distributed deployment, or if it will be needed to create an additional > requirement that incorporates the need of supporting both single- > operator and cross-operator mobility management. > > Best regards, > Georgios > > ________________________________________ > Van: [email protected] [[email protected]] namens h chan > [[email protected]] > Verzonden: donderdag 24 mei 2012 1:20 > Aan: Jouni; Peter McCann > CC: [email protected] > Onderwerp: Re: [DMM] draft requirement REQ-1: Distributed deployment > > An attempt to clean up the text for REQ-1 below: > > REQ-1: Distributed deployment > IP mobility, network access and routing solutions provided by DMM SHALL > enable a distributed deployment of mobility management of IP sessions > so that the traffic can be routed in an optimal manner without > traversing centrally deployed mobility anchors. > REQ-1M (Motivation for REQ-1) > The goals of this requirement are to match mobility deployment with > current trend in network evolution: more cost and resource effective to > cache and distribute contents when combining distributed anchors with > caching systems (e.g., CDN); improve scalability; avoid single point of > failure; mitigate threats being focused on a centrally deployed anchor, > e.g., home agent and local mobility anchor. > RELEVANT problems: > PS1: Non-optimal routes > Routing via a centralized anchor often results in a longer route, and > the problem is especially manifested when accessing a local or cache > server of a Content Delivery Network (CDN). > PS2: Non-optimality in Evolved Network Architecture > The centralized mobility management becomes non-optimal as network > architecture evolves and flattens. > PS3: Low scalability of centralized route and mobility context > maintenance > Setting up such special routes and maintaining the mobility context > including the tunnel state for each MN is more difficult to scale in a > centralized design with a large number of MNs. Distributing the route > maintenance function and the mobility context maintenance function > among different networks can be more scalable. > PS4: Single point of failure and attack > Centralized anchoring may be more vulnerable to single point of failure > and attack than a distributed system. > > H Anthony Chan > > -----Original Message----- > From: Jouni [mailto:[email protected]] > Sent: Saturday, May 19, 2012 4:23 AM > To: Peter McCann > Cc: h chan; [email protected] > Subject: Re: [DMM] draft requirement REQ-1: Distributed deployment > > > Hi > > On May 18, 2012, at 5:55 PM, Peter McCann wrote: > > > Hi, Jouni, > > > > jouni korhonen wrote: > >> Breaking the silence.. > >> > >> On May 7, 2012, at 8:55 PM, h chan wrote: > >> > >>> REQ-1: Distributed deployment > >>> IP mobility, network access and routing solutions provided by DMM > >>> SHALL enable the functions of mobility management of IP sessions to > be > >>> distributed so that the traffic is routed in an optimal manner > without > >>> relying on centrally deployed anchors. > >> > >> Few comments/questions.. > >> o "SHALL enable the functions of mobility management" does that > imply > >> the > >> DMM "solution" must always involve or extend a mobility protocol? > IMHO > >> that should not be a SHALL requirement. > > > > To the extent that DMM provides an "IP mobility...solution" I think > it does > > involve or extend a mobility protocol. However, I don't think the > requirement > > implies that we will necessarily extend an existing mobility > protocol. > > Excerpt from the charter: > > on managing the use of care-of versus home addresses in an > efficient manner for different types of communications. > > Just making sure the right flavor or address is used does not > necessarily > extend or require any mobility protocol support. > > >> o "centrally deployed anchors" what if the access network routing is > >> laid > >> out in a way that even pure IP routing would lead packets to go > >> through a central site/edge router? Doesn't that lead to similar > >> deficiencies than with mobility anchors? > > > > It does indeed, which is why a good network deployment will have > redundant > > back-up paths throughout the network. Unfortunately, it is difficult > to > > provide redundancy when the path involves tunnel state at an anchor > point. > > > >>> REQ-1M (Motivation for REQ-1) > >>> The goals of this requirement are to match mobility deployment with > >>> current trend in network evolution: > >>> more cost and resource effective to cache and distribute contents > when > >>> combining distributed anchors with caching systems (e.g., CDN); > >>> improve scalability; reduce signaling overhead; avoid single point > of > >>> failure; mitigate threats being focused on a centrally deployed > >>> anchor, e.g., home agent and local mobility anchor. > >> > >> Reduce signaling overhead.. is a very good goal. However, if any DMM > >> solution builds on top of an existing mobility protocol that hardly > >> reduces anything. Also if setting up optimal routes require > >> establishing new tunnels, signaling is bound to increase. I would > say > >> here "does not increase the amount of present signaling" and the aim > >> for solutions that would reduce it somehow. > > > > It should be possible to completely avoid mobility management > signaling > > when the MN is stationary or doesn't need a fixed address. I would > say > > that reduces signaling. > > From that point view ok. Extra care is then needed that one does not > move the signaling to another layer.. take DSMIP6 (S2c) as an example, > which avoids BU/BA exchange but then expanded the IKE signaling :) > > >>> RELEVANT problems: > >>> PS1: Non-optimal routes > >>> Routing via a centralized anchor often results in a longer route, > >>> and > >>> the problem is especially manifested when accessing a local or > cache > >>> server of a Content Delivery Network (CDN). > >>> PS2: Non-optimality in Evolved Network Architecture The centralized > >>> mobility management can become non-optimal as Network architecture > >>> evolves and become more flattened. > >> > >> More flat is kind of superfluous.. take e.g. EPS example. You have, > in > >> an optimal case, an eNodeB connected directly to a combined SGW/PGW > >> from the user plane point of view. And the SGW/PGW you can allocate > >> close to you eNodeB based on its topological location. How you can > >> make that more flat? SGW relocation changes the situation a bit but > still.. > > > > Putting an SGW/PGW (or an LGW) inside in eNB would indeed be a > maximally > > Putting SGW/PGW into eNodeB is not too realistic for a wider are > deployment. LGWs we already got out there but the mobility in that > case ain't too great as far as I remember. > > > flat architecture. However, we would then need to deal with a change > of > > anchor point during the life of a session, which is something that > wasn't > > contemplated by 3GPP. That is exactly the area that DMM should focus > on, > > IMHO. > > With a cost of additional signaling and new tunnel state? > > >>> PS3: Low scalability of centralized route and mobility context > >>> maintenance Setting up such special routes and maintaining the > >>> mobility context for each MN is more difficult to scale in a > >>> centralized design with a large number of MNs. > >> > >> Can I assume the mobility context involves a possible per MN tunnel > >> state? > > > > Yes, I think the per-MN tunnel state is part of the mobility context > > being talked about here. > > - Jouni > > > > > > -Pete > > > >>> Distributing the route maintenance function and the mobility > context > >>> maintenance function among different networks can be more scalable. > >>> PS4: Single point of failure and attack Centralized anchoring may > be > >>> more vulnerable to single point of failure and attack than a > >>> distributed system. > >>> > >>> (The above is drafted with contributions, inputs and discussions > >>> from various people. Additional contributions and comments are most > >>> welcome.) > >>> > >> > >> - Jouni > >> > >> > >> > >>> H Anthony Chan > >>> > >>> > >>> _______________________________________________ > >>> dmm mailing list > >>> [email protected] > >>> https://www.ietf.org/mailman/listinfo/dmm > >> > >> _______________________________________________ > >> dmm mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/dmm > > > > > > > > _______________________________________________ > dmm mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmm > _______________________________________________ > dmm mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmm _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
