Hi Pete, Interesting proposal and approach to mobility. A few comments below:
1. The I-D mentions that the scope of an address space is within that of an autonomous system. Do you see this autonomous system as one that encompasses an operators entire network? I am just trying to get an understanding of how big this autonomous system is. Given that an operator could be serving millions of mobile nodes, how large can this single contiguous autonomous system be? 2. Is the eNB/BS the AR in the proposal (fig 2 for example)? 3. If the eNB/BS is the AR, do you foresee concerns with the amount of updates resulting from MNs moving between eNBs/BS'? 4. You state that legacy/hierarchical mobility based solutions "suffer from poor performance, scalability and failure point(s)". I think that the current networks have proven to be capable of supporting fairly large numbers of users/MNs. So I don't see scalability being an issue. And similarly I don't know what is the benchmark against which you are comparing performance either. Whether this architecture can scale further to support billions of devices is of course an unknown and could be an issue. 5. The I-D states: "In particular, we note that many MNs will not require a fixed IP address for the entire duration of their packet data session, as they will most likely be acting as clients and initiating short-lived connections to servers." This seems to be contradicting the solution which results in the address being registered in DNS and the reverse lookup by the target eNB/BS whenever there is a handover. Would it not be preferable to have a short-lived address as well as one that continues to exist beyond handovers? 6. Fig 2 shows an architecture wherein the eNB/BS itself is the 1st hop AR. Given the shrinking cell sizes (to increase capacity) the likelihood of Handovers even at pedestrian speeds goes up. Why not allow for a level of indirection? That would reduce the amount of signaling and reduce route updates. 7. Authentication upon attachment to re-attachment to a BS every time could become quite expensive even with advanced CPUs. I don't know how efficient the proposal to use the new breed of auth algorithms are on battery for example. 8. The I-D states: "Then the mobile node updates its home DNS server to point from its hostname to the new address." If an MN is moving at 70mph and doing handovers every few seconds/mins, does this approach work? Given the RTT for the DNS update? 9. The handovers and the route updates that happen within an autonomous system and/or across it are not entirely clear. Hope to see your presentation and explanation at IETF83. 10. The idea of integrating authentication with mobility is good and should enable faster handoffs. The concept is interesting and I was wondering if you have any simulations or results from such. -Raj On 3/6/12 8:36 AM, "ext Peter McCann" <[email protected]> wrote: >Hi, all, > >On Friday I submitted a new draft that outlines what I think is a novel >approach to mobility management in a totally flat network. The draft >can be found here: > >http://tools.ietf.org/html/draft-mccann-dmm-flatarch-00 > >Abstract > > Today's mobility management schemes make use of a hierarchy of > tunnels from a relatively fixed anchor point, through one or more > intermediate nodes, to reach the MN's current point of attachment. > These schemes suffer from poor performance, scalability, and failure > modes due to the centralization and statefulness of the anchor > point(s). The dmm (Distributed Mobility Management) working group is > currently chartered to investigate alternative solutions that will > provide greater performance, scalability, and robustness through the > distribution of mobility anchors. This document is an input to the > dmm discussion. It outlines a problem statement for the existing > mobility management techniques and goes on to propose (high-level) > solutions to two of the most vexing problems: MN authentication and > mobility management in a fully distributed, flat (non-hierarchical) > access network. These two aspects are often treated separately in a > layered architecture, but we argue there are important advantages to > considering how these two functions can work in tandem to provide a > simple and robust framework for the design of a wireless Internet > Service Provider network. > > >I'd like some time to present this draft during the meeting in Paris, >hopefully 15 minutes. > >-- >Peter J. McCann >Huawei Technologies (USA) >[email protected] >+1 908 541 3563 >Rm. C-0105, 400 Crossings Blvd. (2nd floor), Bridgewater, NJ 08807-2863 >USA > > >_______________________________________________ >dmm mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/dmm _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
