>> 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.
---------------------------- Regarding above comment: I think the reduction of mobility signaling here applies more to REQ-2 (e.g., not using the HoA from the previous network you don't need to) but not REQ-1. In the motivation for this REQ-1, we can delete "reduce signaling overhead" 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
