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.
We can reword "functions of mobility management" to avoid such implication. H Anthony Chan -----Original Message----- From: jouni korhonen [mailto:[email protected]] Sent: Thursday, May 17, 2012 6:46 PM To: h chan Cc: [email protected] Subject: Re: [DMM] draft requirement REQ-1: Distributed deployment 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. 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? > > 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. > > 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.. > 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? > 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
