[rbridge] Draft problem statement
Erik.Nordmark at Sun.COM
Thu May 27 14:32:01 PDT 2004
> But it is so tempting to use this for mobile ad-hoc networks, localized
> (or micro-) mobility management, etc :) And I think it is hard to
> prevent that. We should eventually have some understanding on the
> scalability characteristics, and maybe have some appropriate warning
At an abstract level I think there are some traffic observations and
assumptions that drive for different approaches when you take movement into
I think Manet is looking at cases when everything moves (including routers
in the sense that nodes relay packets for other nodes). At that end
of the scale if you propagate all movement information to everybody
you might end up using more bandwidth for the routing updates than
data traffic (especially if each host/node does not generate much traffic).
Hence it makes sense to look at propagating information in limited scopes
and/or being able to find a node on demand when there is a packet
for that node.
If you instead start off at the end of the scale where almost nothing moves,
then it makes sense optimizing the data path by propagating information
about movement everywhere whether or not there is data traffic.
For localized mobility management there might be (unstated?) assumtions
as well. For instance, and I'm speculating here, if you assume that
there is little or no local traffic between the mobile nodes i.e., almost
all the traffic is to/from hosts outside the local part of the network,
then there isn't much use in propagating information above movement throughout
the network; it does make sense to propagate this information
so that packets arriving from the outside can be forwarded efficiently
towards the moving host.
If the rate of movement is low one can presumably live without any
optimizations based on the above assumptions, but the higher the rate of
movement the more suboptimal things would be compared to a solution that
explicitly optimizes for some movement pattern and traffic pattern.
It makes sense to me to first work out how a solution could work
assuming a low rate of movement and later look at how it behaves
with a high rate of movement; otherwise I think the tradeoffs would be
way to complicated.
More information about the rbridge