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
