Hi, As an operator guy, I will not dispute a use-case dealing with roaming :-). However I think that it is out of the scope of our considerations here (I mean, from the IETF standpoint). IMU, the goal of DMM is not to specify a full system architecture (to which statement (1) below seems to refer); the goal of DMM is, in a first stage, to assess the use of legacy protocols in a distributed anchoring deployment.
Moreover, statement (2) below, is more a solution hints than a requirement. Typically, (2) is about HA/LMA relocation which may be, or not, a solution to meet Anthony's req#1. So, IMHO, req#1 addresses your concern. That's only my opinion; let's see what others think. BR, Pierrick > -----Message d'origine----- > De : [email protected] [mailto:[email protected]] > Envoyé : vendredi 25 mai 2012 12:28 > À : SEITE Pierrick RD-RESA-REN; [email protected] > Cc : [email protected] > Objet : RE: [DMM] draft requirement REQ-1: Distributed deployment > (single-operator and cross-operator?) > > Hi Pierrick, > > The goal of such a requirement is to emphasize that the DMM protocol(s) > that will be designed/specified by the DMM WG should be agnostic to > whether users are roaming/moving into wireless coverage area(s) managed > by either one single operator or by more than one operators. > I think that this will have an impact on some of the requirements > listed already by Anthony! > Security association is one such requirement, other requirements are > related to for example the possibility of the DMM protocol(s) to (1) > easily use the user profile and mobility information when users are > roaming away from their home operator, (2) use and support seamless, > real time and dynamic change of the mobility anchors that could be > located in different communication area(s) managed by different > operators. > > Best regards, > Georgios > > > > > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] > > Sent: vrijdag 25 mei 2012 9:49 > > To: Karagiannis, G. (EWI); [email protected] > > Cc: [email protected] > > Subject: RE: [DMM] draft requirement REQ-1: Distributed deployment > > (single-operator and cross-operator?) > > > > 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
