Hi, Dapeng, liu dapeng wrote: > Hi Peter, > > As we discussed offline earlier, I have a similar proposal which is > also rely on IBGP to update the routing system and thence allow the MN > keep its address unchanged even after handover. I have not submit the > draft for this upcoming meeting. > > The difference is that my proposal does not relay on DNS. Since the AR > needs to do reverse lookup every time a MN attaches to it, it may > result in performance issue.
There needs to be some way for the new AR to discover the prefixes associated with the MN. DNS seems to be a relatively easy and light-weight way of doing that. > Another point is for the inital state, the prefixes could be > aggregated at the reflector and confine the routing update whin the > domain but after a period of time, many MNs would roam in the domain > and the prefixes would be diffcult to aggregate. To solve this one > option is to design a upper level router above all the domain > reflectors and by carefully address planning, to make all the MN's > prefix belong to that router. You can have multiple layers of route reflectors. The UPDATE can be confined to the appropriate scope. > The idea could be extended to not only depends on IBGP. more general > speaking, it allows mobility management interacting with routing > system and will result in several different alternative designs. Agreed, but BGP seems to offer the policy flexibility (with LOCAL_PREF) that we need to ensure that the latest UPDATE is used by all the routers. > Besides authentication, there are many other aspects need to explore, > e.g: address management, billing system etc.. In general I am striving for an architecture that is free of RADIUS and Diameter. Granted, I have only addressed the first A in AAA, but I think there are good solutions for the other two As that won't require round-trips to the home network. -Pete > Regards, > Dapeng Liu > > 2012/3/6, Peter McCann <[email protected]>: >> 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
