Hi, Raj, [email protected] wrote: > > 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?
Strictly speaking, an autonomous system is the scope within which the same AS number is used and within which I-BGP runs. However, the scope in which an address can remain assigned to an MN would in reality be a subset of the AS, to be determined based on an engineering trade-off between the amount of BGP UPDATES, their scope, and the size of the routing tables you are able to maintain on the one hand, and the overhead of getting a new IP address assigned on the other. > 2. Is the eNB/BS the AR in the proposal (fig 2 for example)? Yes, that would be the idea. > 3. If the eNB/BS is the AR, do you foresee concerns with the amount of > updates resulting from MNs moving between eNBs/BS'? The UPDATEs only need to propagate up to the route reflector(s) if you are moving within a cluster. In that case, I don't think the update is any more overhead than the tunnel migration that is done today under an S-GW. If you are moving between clusters, then yes, the update has to propagate further. Again, you need to make an engineering tradeoff in terms of how far the UPDATEs are allowed to propagate vs. the overhead of getting a new address. > 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. The current solutions tend to lead to P-GWs/GGSNs with millions of sessions homed on them. While it is possible to build such animals with massive investments in fault tolerant hardware, a more scalable approach would be to distribute the state maintained into many smaller, cheaper boxes. > And similarly I don't know what is the benchmark against which you are > comparing performance either. The main performance drawback is the sub-optimal routing back to the anchor point. > Whether this architecture can scale > further to support billions of devices is of course an unknown and could > be an issue. Indeed. > 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? The text you quote says "many"; it does not say "all". Indeed, I think we need to support both kinds of MNs. The point is a softer one, in that we need to do our engineering for the most common case and worry less about the tail ends of the distribution. That's how we get good performance from the solution. Those MNs that need a fixed address should be supported, it's just that the longer you keep the address, and the more mobility events that you have during such a session, the more overhead and routing table bloat you get. Nodes that periodically re-request a new, local address and deprecate their old address are good citizens that help to reduce this overhead and routing table size. The paragraph just says there are likely to be many nodes that are capable of this behavior, so it is likely we can keep the routing table updates/sizes to a manageable level. > 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. If by "level of indirection" you mean a tunnel from the old AR to the new AR, that leads to some of the same drawbacks of the hierarchical architecture. Packets would need to traverse the backhaul 3 times to reach the MN and the old AR would become a single point of failure for that session. > 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. This needs to be studied. Caching the LTSS for frequently visited BSs will be a big help here. > 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? You wouldn't do this on every handover, only when you get a new IP address/prefix allocated. That's the beauty of decoupling address assignment from mobility management. > 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. Sorry if the text isn't clear. It assumes a fairly intimate understanding of how to configure I-BGP. Hopefully my presentation slides will give you a better picture of how it is supposed to work. > 10. The idea of integrating authentication with mobility is good and > should enable faster handoffs. The integration is at two points: 1) using link authentication with the AR to trigger network-based routing updates; 2) using MIP authentication with the HA to trigger the same network-based routing updates I hope we can work on standardizing both of these authentication steps to use the same credentials and operate with minimal round-trips. > The concept is interesting and I was wondering if you have any > simulations or results from such. Unfortunately not yet. We are working on it. Will keep you updated. > -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. _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
