Tom DeReggi wrote:
No the problem with Mesh is it adds many hops to the path, therefore
adding significant latency, and inability to control QOS, or identify
where the QOS lies. Self interference is impossible to avoid without
killing every other in town at the same time.
Mesh doesn't have to add hops where they aren't needed or wanted.
Further, there is no inherent added latency for a mesh network.
Certainly hops and TDM add latency, but that is the case with all
network architectures.
Well that brings nother issues up. Adding complexity where it is not
needed in many cases. There is reliabity added by doing it at layer2.
Fewer compenent to fail and manage. There is a benefit to centralized
management and configuration, when scaling large projects. When end
users have routers at the DMarc, there is often little need to route,
as the path is rarely peer to peer in nature, and all tend to follow
the path to backbone. Not that I'm not saying Routing doesn;t have
its importance to be implemented at the right strategic places. Its
jsut not needed every hop along the path. There are automated routing
tasks like RIP and OSPF, or simlar, but its awefully risky allowing
route advertizing to the front edge of ones network, or the consumer
radio to have the abilty to advertise routes. Layer2 virtual circuits
and VPN, are also often adequate solution to solve problems of
deployment.
Unless we are talking best effort, all customers should have their own
VLAN and therefore any network will have an upper limit on its size
without routers. Clearly some combination of layer 2 and layer 3 is the
right way to go for even a medium size network.
The Super cell gives the ISP better central control and simplicity.
I don't believe an argument has been made to back up your above statement.
Mesh has its purpose, but as a last resort in my opinion. When a Super
cell is unable to reach the clientel. But I'd argue many samll
repeater cells is a better way to go, so reliabilty and shortest path
can be engineered into every site. When paths from point A to point
B change automatically, its difficult to loose control of performance
levels an individual may have at one point in time over another. QOS
is near impossible to guarantee on MESH. I look at MESH as a Best
effort service, and it should be deployed only when thatlevel of
service isrequired. Reliability and QOS is all about creating shortest
number of hops, with most direct solid links. Just my opinion. We'll
see what the Muni Mesh network brings to the table after their many
future case studies to come. Its the Mesh companies that are the ones
pushing it,and in their eye. The reason has to do with assets not
technology. Muni's don;t own the roof tops and towers. They own the
street poles. Mesh works from the Street poles. MESH is a way to
intiate a project, without third parties getting in the way. The Muni
controls the assets required for the Technology to pull off its job.
Its building management companies and owners that control the
expansion of Broadband in the Super Cell.
I think you may be mixing too many arguments. We are using a fully
meshed MPLS network for our fiber backbone. Our choice of a mesh
architecture for our fiber backbone has nothing to do with client
reachability, politics, vendor's opinions, or anything else outside of
practical requirements. Our network devices can and do make routing
decisions on the fly that result in better throughput, lower latency,
and better QoS than traditional star and ring architectures can achieve.
Understand that every major ISP is now either running a fully meshed
MPLS network or has plans to migrate to one.
Muni has two choices... Go Mesh, or partner with the Local WISP, that
already own the rights to the roof tops and spectrum, toguarantee
quick progress. There are some exceptions to this, as many Muni's
control water towers, if they are strategically located.
I don't think Muni choices whatever they are should have anything to do
with an technical discussion regarding the merits of mesh as a network
architecture.
-Matt
--
WISPA Wireless List: wireless@wispa.org
Subscribe/Unsubscribe:
http://lists.wispa.org/mailman/listinfo/wireless
Archives: http://lists.wispa.org/pipermail/wireless/
