В результате развития устройств для беспроводных ЛВС (БЛВС) их пропускная способность возросла почти в сто раз. Однако, чем более совершенной становится та или иная технология, тем меньше возможностей у производителей для революционных инноваций в этой области. Поэтому, когда мы слышим о некоей компании, которой вроде бы удалось значительно опередить конкурентов, мы начинаем активно интересоваться ею.
В данном случае объектом нашего внимания стала фирма Meru Networks. Дело в том, что между продуктами компаний Aruba Networks, Cisco Systems и Symbol Technologies, являющихся лидерами рынка корпоративных БЛВС, гораздо больше общего, чем различий, так как они реализуют идентичную архитектуру БЛВС с контроллерами и двухдиапазонными “тонкими” точками доступа (ТД), которые располагают довольно близко друг к другу (с перекрытием зон действия). Фирма же Meru разработала уникальные решения, отличные от традиционной архитектурной концепции БЛВС. В противоположность сложной многоканальной конструкции БЛВС одноканальная сетевая архитектура Meru облегчает развертывание сети, обеспечивает лучшую ее масштабируемость, реализует усовершенствованные функции роуминга и механизмы QoS, названные ею Air Traffic Control.
Мы уже давно заинтригованы технологическими решениями фирмы Meru и после ряда неудачных попыток привлечь ее к участию в наших испытаниях наконец-то получили ее оборудование для тестирования. С одобрения представителей Meru мы сравнивали ее продукты с оборудованием компании Cisco. Для подтверждения объективности нашего анализа результаты испытаний были представлены обоим производителям. В ходе тестирования, проводившегося в реальных условиях (в здании) и в изолированной от внешних радиосигналов камере (см. “Методика тестирования”), мы общались с заказчиками продуктов Meru, а также обсуждали технические вопросы с ведущими специалистами обеих компаний.
В процессе проведения испытаний мы стали значительно лучше понимать, как работает оборудование фирмы Meru, технические показатели которого произвели на нас сильное впечатление. При передаче трафика VoIP и обычного трафика данных одновременно (такая комбинация трафика все более характерна для корпоративных БЛВС) оборудование фирмы, стабильно пересылая потоки данных, продемонстрировало превосходное качество голосовой связи. Когда же мы оценивали производительность оборудования в распространенной сегодня смешанной среде (с клиентскими устройствами стандартов 802.11b и 802.11g) система Meru не позволяла устройствам стандарта 802.11b тормозить работу клиентов стандарта 802.11g, что, увы, характерно для большинства конкурирующих систем. Хотя наша тестовая среда была слишком мала для того, чтобы оценить работу функции роуминга, мы все же пришли к выводу, что и при выполнении последней одноканальная архитектура Meru обладает определенными преимуществами перед архитектурами БЛВС конкурентов.
Результаты нашего тестирования подтвердили истинность рекламных заявлений Meru, и нам очень захотелось узнать, как же фирма добилась этого. Мы уже давно имеем дело с БЛВС стандартов 802.11 и хорошо понимаем ограничения, характерные для их архитектуры с разделяемой средой передачи сигналов, доступ к которой осуществляется по методу CSMA/CA. Отсутствие в базовой спецификации 802.11 механизмов QoS — ее общепризнанный недостаток, и, хотя уже появился стандарт 802.11e, в значительной мере устраняющий его, радоваться, как говорится, еще рано: поддержка этого стандарта еще не получила широкого распространения в оборудовании для БЛВС. Тем не менее инженеры фирмы Meru каким-то образом умудрились реализовать многие из функциональных возможностей, предусмотренных стандартом 802.11е, при работе их оборудования с обычными клиентскими средствами стандартов 802.11.
К сожалению, представители фирмы не были откровенными с нами в отношении принципов функционирования своего оборудования — по-видимому, это такая же большая тайна, как рецептура “Кока-Колы”.
Осуществив захват и анализ последовательностей пакетов, мы пришли к выводу, что у секрета фирмы Meru “горький привкус”. Иными словами, в работе стандартной БЛВС могут возникнуть серьезные проблемы, если по соседству с ней будет задействована система Meru на том же самом частотном канале. Специалисты компании Cisco прямо заявляют, что инженеры фирмы Meru нарушают стандарты 802.11, изменяя значение NAV (Network Allocation Vector) в поле Duration (“Длительность”) заголовка кадра 802.11 (см. “Длительность, длительность, длительность”). В Meru отвергают любые обвинения в отходе от стандартов. На наш взгляд, упреки Cisco более аргументированы, чем оправдания Meru, но с окончательными выводами мы подождем до тех пор, пока эксперты института IEEE и организации Wi-Fi Alliance не выскажут свое суждение о результатах нашего тестирования.
Стоит отметить, что суть наблюдавшихся нами проблем в работе БЛВС выходит за рамки простого влияния радиопомех: она связана с тем, как устройства стандартов 802.11 реализуют протокол, регулирующий доступ к среде передачи. В большинстве компаний БЛВС строятся на базе оборудования одного производителя, и даже если Meru действительно нарушает стандарты, то негативные последствия от этого могут проявляться лишь в зданиях, в которых расположены офисы разных компаний. Но и в случае возникновения таких проблем есть пути их решения.
Однако даже если совсем отбросить вопрос о соответствии или несоответствии системы фирмы Meru стандартам, все равно в настоящее время мы не можем безоговорочно рекомендовать ее использование. Да, в наших тестах на производительность она опередила решение компании Cisco, но мы обнаружили в ней ряд дефектов и столкнулись с проблемами в плане ее технической поддержки. К тому же представители фирмы проигнорировали наши многочисленные просьбы дать нам координаты заказчиков системы, чтобы узнать их мнение о ней.
С третьей попытки
За последние годы мы протестировали сотни беспроводных продуктов, но при работе с оборудованием фирмы Meru у нас с самого начала все пошло не так. В частности, представители фирмы потребовали, чтобы ее продукты тестировались только на открытом воздухе, а это было проблематично, если принять во внимание изобилие БЛВС в Сиракузском университете, где находится наша тестовая лаборатория. Действительно, в реальных условиях эксплуатации помехи могут существовать, но ведь совершенно невозможно проводить сравнительное тестирование оборудования, никак не контролируя их уровень. Чтобы удовлетворить требования фирмы Meru, первоначальные испытания мы провели между полуночью и 6 часами утра, предварительно отключив (при содействии ИТ-персонала университета) все производственные БЛВС, сигналы которых могли бы исказить наши результаты.
Первый раунд ночного тестирования дал результаты, никак не соответствовавшие ожиданиям специалистов Meru. Во втором раунде мы задействовали обновленный сценарий конфигурирования, но результаты опять оказались слишком низкими. На третий раз все прошло хорошо — система показала ожидаемую от нее производительность, чему поспособствовал инженер фирмы Meru, который специально прилетел, чтобы понаблюдать за тестированием.
Когда мы обратились в Meru, первые две неудачи ее представители объяснили наличием дефекта в точке доступа, и у нас, в общем-то, не было оснований сомневаться в этом. Однако сам процесс его поиска оказался настолько трудоемким, что мы несколько разочаровались в продукции фирмы. Дефект, приведший к низкой производительности в тесте с включенным шифрованием по методу WPA2-PSK (Preshared Key), успешно устранили, но мы были шокированы тем, что эти представители попытались уговорить нас ничего не писать о нем.
Еще одной проблемой для нас стала низкая оперативность реагирования служб Meru. В ходе тестирования мы неоднократно обращались в фирму за новым оборудованием, обновленным ПО, технической поддержкой и информацией о заказчиках. На все наши запросы представители Meru реагировали с огромной задержкой или не отвечали вовсе. Поскольку мы понимали, что наша методика испытаний не позволяет оценить масштабируемость системы, мы несколько раз просили сотрудников фирмы связать нас с заказчиками, развернувшими у себя большие сети на базе ее оборудования, но всякий раз получали отказ.
Несмотря на отсутствие помощи со стороны фирмы, нам все же удалось поговорить с двумя ее заказчиками. Оба они высоко оценили ее продукты, но при том ни у одного из них не было достаточно большой сети, которая позволила бы нам оценить правдивость заявлений представителей Meru о производительности и масштабируемости ее решения.
Как это обычно бывает при сравнительном тестировании продуктов, мы вовлекли в данный процесс их производителей — Cisco и Meru — и по мере получения результатов обсуждали их с обеими сторонами. Однажды мы попросили представителей компании Cisco высказать свое мнение относительно того, почему результаты, показанные оборудованием фирмы Meru в нескольких тестах, были более высокими.
Ответ Cisco удивил нас: вместо того чтобы тщательно проанализировать результаты, представители компании без промедления заявили, что Meru нарушает стандарты 802.11. Они предоставили нам данные проведенного ими исследования, указывающие на то, что инженеры Meru произвольно изменяют содержимое поля Duration, которое имеет большое значение для функционирования предусмотренного стандартом 802.11 механизма контроля виртуальной несущей (virtual carrier sense).
Сначала представители Meru категорически отвергли утверждения специалистов Cisco, заявив, что это всего лишь очередное ложное обвинение в адрес их фирмы, череда которых началась еще в то время, когда компании Meru и Airespace были новичками на рынке корпоративных БЛВС и активно старались привлечь к себе внимание сетевой общественности.
Но, когда мы предъявили результаты анализа захваченных в ходе тестирования оборудования фирмы Meru пакетов, свидетельствующие о завышенных значениях времени в поле Duration, позиция ее представителей изменилась. Нашу тестовую лабораторию посетили исполнительный директор (CEO) фирмы Ихаб Абу-Хакима и главный разработчик ее продуктов Джо Эпштейн. Сначала они заверили нас в том, что причиной этого завышения является ошибка в алгоритме адаптации скорости передачи, а затем вдруг заявили, что изменение содержимого поля Duration не играет никакой роли в обеспечении радиосистеме фирмы Meru конкурентных преимуществ. Господин Абу-Хакима извинился за ошибку и сказал, что его фирма делает значительные инвестиции в систему обеспечения качества продукции. Он также не преминул покритиковать своих конкурентов, заявляя, что они нередко неверно истолковывают факты.
Господин Эпштейн обсудил с нами ошибку в алгоритме адаптации скорости передачи и ответил на наши многочисленные вопросы об элементах архитектуры и функциональности системы Meru, включая ее работу на одном частотном канале. Еще он снабдил нас подробной и оказавшейся весьма полезной интерпретацией результатов нашего тестирования. После этой встречи мы были готовы признать “невиновность” Meru, но пакеты с завышенными значениями Duration были зафиксированы снова, и нам ничего не оставалось, как снова обсуждать это с представителями фирмы, которые еще раз изменили свои “показания”.
Повторное тестирование
После встречи с руководством фирмы Meru мы начали повторно испытывать ее оборудование с последней версией ПО, на этот раз в экранированной камере, где исключалась всякая возможность радиопомех от других сетей. Информацией о захваченных в ходе тестирования пакетах мы поделились с Cisco и Meru.
На следующий день специалисты Cisco представили нам новые доказательства некорректности содержимого поля Duration, на этот раз при использовании механизма CTS-to-Self (Clear-To-Send-to-Self). Уточним, что инженеры Cisco только проанализировали полученную от нас информацию, указав на чрезмерные значения времени в поле Duration, само же тестирование мы проводили без них в нашей лаборатории.
И вновь представители Meru поменяли “показания”, заявив, что они всего лишь используют преимущества QoS-механизма, определенного новым стандартом 802.11e. Если говорить более конкретно, они сослались на предусмотренную указанным стандартом возможность передавать множество пакетов в течение временного интервала TXOP (Transmission Opportunity). Но мы считаем, что эта функция зарезервирована только для устройств стандарта 802.11e. Представители Cisco сообщили, что в Meru реализуют не все положения стандарта 802.11e — в частности, нарушены требования в отношении содержимого поля TXOP Limit в сигнальных (beacon) пакетах 802.11e. Наши попытки обсудить это с представителями Meru не увенчались успехом, поскольку они попросту не реагировали на наши запросы. Когда сроки тестирования почти истекли, мы в последний раз обратились в Meru, и Эпштейн все же ответил нам, заявив при этом, что продукты его фирмы полностью соответствуют стандартам 802.11, он также извинился за задержку с ответом, ссылаясь на поломку ноутбука, не позволившую ему вовремя соединиться с VPN-сетью фирмы.
Удалось ли нам раскрыть “секретную формулу” Meru? Вряд ли. Мы знаем только, что сетевая архитектура Meru позволяет ее оборудованию в значительной мере управлять доступом клиентских устройств стандартов 802.11 к радиоканалу, и, похоже, это управление осуществляется путем увеличения содержимого поля Duration. Но вполне возможно, что это далеко не вся “формула”.
Не в первый и не в последний раз
Очевидный вопрос, который могут задать сегодняшние и потенциальные клиенты фирмы Meru: а кому какое дело, если Meru и “подправляет” стандарт, чтобы повысить производительность сети, раз это действительно работает? Принимая во внимание факт, что зоны действия многих БЛВС на предприятиях не выходят за границы их территорий, разве так уж важно, что система Meru может помешать соседним сетям? Вопросы справедливые.
Это не первый случай, когда производитель отходит от стандартов. Многие компании, включая саму Cisco, предлагают разные фирменные расширения, ориентированные на улучшение работы сети, что является одним из способов, позволяющим выпускать продукты лучше, чем у конкурентов.
И раньше стандарты 802.11 “творчески переосмысливались”. Например, лидер на рынке беспроводных VoIP-продуктов — компания SpectraLink уже несколько лет обеспечивает своим телефонам приоритетный доступ к сети, реализуя в них алгоритм работы с нулевым временем ожидания (zero-backoff), что вызывает сомнения в соответствии аппаратов требованиям стандартов 802.11. Другим бросающимся в глаза примером стали домашние Wi-Fi-шлюзы с фирменными технологиями объединения каналов, что негативно влияет на функционирование соседних сетей, на какие бы каналы они ни были настроены. Данный факт заставил организацию Wi-Fi Alliance разработать политику добрососедства, нарушение которой может привести к отказу в выдаче Wi-Fi-сертификата или к его аннулированию.
Стоит отметить, что Wi-Fi Alliance сертифицировал систему фирмы Meru и что она не предполагает использования каких-либо фирменных средств и технологий на клиентских устройствах Wi-Fi для достижения преимуществ в производительности. При определенных условиях БЛВС-система фирмы, взаимодействуя со стандартными клиентскими средствами, работает быстрее решений конкурентов.
Надо признать, что приоритизированный доступ к среде передачи не единственное отличие системы фирмы Meru от системы конкурентов. Ее одноканальная архитектура тоже идет вразрез с отраслевыми нормами, но она не требует частотного планирования сети и тем самым значительно упрощает построение последней. Хотя у одноканальной архитектуры сети есть свои недостатки в плане емкости, эту архитектуру имеет смысл использовать, если предприятие больше заинтересовано именно в широте радиопокрытия, а не в максимально высокой емкости.
Впрочем, высокоемкую сеть можно построить и на оборудовании Meru, если задействовать ее устройство Radio Switch с несколькими радиомодулями. Так, по крайней мере, заявляют представители фирмы, но они не предложили нам протестировать это устройство и не указали ни одного заказчика, которого мы могли бы расспросить о нем. Поэтому у нас нет ни собственного мнения, ни чьего-либо свидетельства о том, насколько хорошо оно работает.
Реалии рынка таковы, что архитектура БЛВС фирмы Meru вряд ли победит. Учитывая тот факт, что свыше 95% установленных БЛВС-продуктов поддерживают многоканальную архитектуру, совершенно нереально, что производители вдруг изменят свои подходы к их проектированию. Да, с применением основных корпоративных БЛВС-продуктов фирм Aruba, Cisco, Symbol и др. связаны определенные проблемы, но со временем они будут решены путем совершенствования стандартов, если БЛВС станут играть важную роль в корпоративных сетях будущего..
Автор Дэйв Молта, Джеймсон Блэндфорд
Вязто с Сети и системы связи