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. > 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. >> 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 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. >> 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. -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
