Ее цель - познакомить российских читателей с некоторыми размышлениями автора о будущем перспективных сетевых технологий. Мы считаем, что отечественный компьютерный рынок находится на той стадии развития, когда знания и опыт таких специалистов, как Ник Липпис, становятся просто необходимы при проектировании и развитии информационных систем. Если Вас - наших читателей - заинтересует опубликованный ниже материал, мы постараемся сделать колонку Липписа постоянной рубрикой, чтобы дать Вам возможность взглянуть на состояние рынка сетевых и телекоммуникационных технологий глазами Ника Липписа.
Последние полтора года производители коммутационного оборудования, не жалея слов, восхваляли решения с использованием ATM. Однако когда дело доходило до продажи продуктов, то оказывалось, что те же самые производители не могли предложить ничего лучшего, чем коммутаторы Ethernet.
Почему так происходит? Администраторы сетей, посетившие апрельскую выставку Networld+Interop в Лас-Вегасе, имели возможность убедиться, почему ATM внедряется так медленно, в то время как рынок коммутаторов Ethernet процветает.
ATM прекрасно работает в среде небольших рабочих групп, где все оборудование рассчитано на работу с ATM. Однако использование ATM в качестве магистрали неоднородной территориальной сети с большим объемом трафика незамедлительно приводит к возникновению проблем. Особенно обескураживает вера многих людей, что магистраль объединенной сети - это именно то место, где без производительности, обеспечиваемой ATM, просто не обойтись, и, следовательно, коммутаторы ATM имеют больше всего шансов на успех.
НИКАК НЕ ОБОЙТИСЬ?
ATM обещает два фундаментальных преимущества, благодаря которым он якобы незаменим на магистрали территориальной сети. Во-первых, это низкая цена при высокой пропускной способности, а во-вторых, - обеспечение качества услуг. Однако поставщики коммутаторов ATM столкнулись с трудностями в обеспечении и того, и другого.
Сегодня никакая иная широкодоступная технология сетевой магистрали, за исключением суперкомпьютерной технологии HIPPI (высокоскоростной параллельный интерфейс), не может сравниться с асинхронным режимом передачи по скорости каналов (155 и 622 Мбит/с). Определенно, никто не может предложить такую скорость передачи данных по столь низкой цене. Однако использование ATM в качестве магистрали можно уподобить строительству 10-рядной супермагистрали, выехать на которую можно только по извилистой сельской дороге. Путь оказывается слишком труден.
Поэтому производителям коммутаторов предстоит решить несколько нетривиальных инженерных проблем, среди которых слишком большое время настройки коммутируемых виртуальных каналов (SVC), неэффективность передачи трафика TCP/IP и значительные потери на переходах между Ethernet и ATM.
Коммутаторам требуется полсекунды на установление с нуля одного виртуального канала ATM. В мире высокопроизводительных локальных сетей это очень и очень большая задержка - как правило, в сотни раз превышающая время прохождения пакета от отправителя адресату.Верно, конечно, что установление виртуального канала происходит один раз при регистрации пользователя в сети. Виртуальный канал обычно кэшируется, а, следовательно, когда пользователь запрашивает его в следующий раз, устанавливается гораздо быстрее (обычно меньше чем за 10 секунд). Однако в крупной территориальной сети пользователи постоянно запрашивают новые соединения через магистраль с различными серверами. И каждый раз им приходится ждать лишних полсекунды или около того. Ни один администратор сети не станет убеждать начальство потратить миллионы долларов на новую территориальную сеть ATM только для того, чтобы пользователи постоянно жаловались на задержки.
В отношении Internet задержка на установление виртуальных каналов ставит еще более серьезную проблему. Если бы коммутируемые виртуальные каналы ATM стали использоваться в Internet, то пользователи должны были бы ждать установления канала каждый раз при посещении нового узла World Wide Web. Вот почему ребята из группы инженерной поддержки Internet считают, что ATM рискует разделить судьбу модели OSI.
Время, необходимое на установление виртуального канала, делает неэффективным использование полосы пропускания. Если на установление одного канала уходит полсекунды или даже 10 мс при кэшировании, то не составит труда подсчитать, сколько времени понадобится на установление сотен или тысяч виртуальных каналов для заполнения канала на 155 Мбит/с. Во время установления канала, по крайней мере, часть полосы не используется.
Теперь о проблемах трафика TCP/IP и переходе между ATM и Ethernet. ATM доставляет полезный груз, размер которого в битах не является степенью двойки. Это может привести к расхождениям между размером полезного груза ячеек и буфера конечной станции. Попытки разрешения этого противоречия могут привести к зацикливанию сеанса TCP/IP между тайм-аутами и повторными передачами. В результате передача файла так и не состоится, а полоса пропускания будет использоваться вхолостую.
<$t4>Многие коммутаторы Ethernet для рабочих групп поставляются теперь с интерфейсом для ATM на 155 Мбит/с для подсоединения их к магистрали объединенной сети. Однако тесты, проведенные Strategic Networks Consulting, показывают, что коммутаторы сталкиваются с серьезными трудностями в наполнении канала ATM. Корень проблемы в медленности доступа. Результаты тестирования можно найти на узле http://www.snci.com.
РАБОТА ИДЕТ ПОЛНЫМ ХОДОМ
Поставщики продуктов для ATM и иже с ними в поте лица работают над разрешением этих проблем. Задержка в установлении виртуального канала вовсе не обязательна для ATM. Она является следствием используемого в настоящее время сигнального программного обеспечения для управления соединением. Программное обеспечение виртуального канала второго поколения станет поддерживать тысячи соединений SVC в секунду, при этом виртуальный канал будет устанавливаться в первый раз за десятки, а не за тысячи миллисекунд.
Работа ведется и над тем, чтобы приложение само выбирало между виртуальным каналом ATM и маршрутным соединением в зависимости от задачи. При этой схеме, предложенной рабочей группой IETF "Классический IP поверх ATM", приложения, требующие высокого качества услуг, будут применять виртуальные каналы, в то время как остальные будут работать через маршрутизатор. Маршрутизатор может использовать постоянные виртуальные каналы ATM (ATM PVC) или работать в режиме с промежуточной буферизацией.
Такой подход имеет два преимущества: число устанавливаемых коммутатором виртуальных каналов сводится к минимуму, а сами виртуальные каналы могут использовать сервисы защиты информации. Однако истинная красота этого решения в том, что администраторы сетей могут одновременно воспользоваться преимуществами сетей с маршрутизаторами и ATM. К сожалению, пройдет некоторое время, прежде чем этот подход будет реализован в конкретном продукте.
Сегодня мы бы посоветовали администраторам ограничиться пробным внедрением ATM в рамках небольшой рабочей группы. Если ATM нужен на магистрали, то мы рекомендуем использовать только постоянные виртуальные каналы, так как они не приводят к свойственным коммутируемым виртуальным каналам задержкам.
Однако в большинстве случаев администраторам сетей, строящим корпоративную магистраль, предпочтительно выбрать апробированные технологии, а не ATM. Традиционные коммутаторы Ethernet, Ethernet на 100 Мбит/с, Token Ring и FDDI не могут сравниться с ATM в предоставлении гарантированной полосы пропускания, но обеспечивают адекватную для большинства сегодняшних применений полосу пропускания магистрали. Кроме того, они не имеют характерных для ATM технических недоработок. А так как обещанное качество услуг никем пока не поддерживается, то администраторы вполне могут подождать.
Николас Дж. Липпис III - президент и учредитель корпорации Strategic Networks Consulting, занимающейся консультированием по всем вопросам компьютерных сетей. Липпис - всемирно признанный авторитет в области архитектуры, реализации и управления объединенными корпоративными сетями. Он консультировал многие фирмы, из числа Global 1000, в том числе Barclays Bank, Schering-Plough Research Institute, Hughes and Liberty Mutual, по вопросам организации корпоративной сети. Кроме того, в качестве одного из редакторов он ведет колонку в журнале Data Communications. Липпис был в составе организационного комитета крупнейшей международной торговой выставки NetWorld+Interop.