Потеря кадров - врожденная болезнь коммутаторов
Причины потери коммутаторами кадров можно разделить на две категории - блокирующая производительность коммутатора и перегрузка выходного порта или портов.
Блокирующая производительность - это ситуация, когда выходные порты коммутатора могли бы передать в сеть все поступающие потоки кадров, но производительность внутренних элементов коммутатора недостаточна для обработки этих потоков. Многие модульные модели коммутаторов страдают от этого недостатка. Как правило, он является следствием появления в номенклатуре коммутатора высокоскоростных модулей, например, модулей FastEthernet, ATM и GigabitEthernet, уже после выпуска общих элементов коммутатора, например, коммутационной матрицы, блока общей памяти, пассивной общей шины и т.п. В результате - нехватка производительности для особенно тяжелых режимов работы.
Но, если недостаточную производительность элементов коммутатора можно устранить, заменив их более скоростными, то производительность порта коммутатора ограничена стандартом соответствующего протокола - Ethernet, TokenRing, FastEthernet и АТМ.
Например, порт Ethernet не может передавать больше 14880 кадров в секунду, если он не нарушает временных соотношений, установленных стандартом. Какой бы ни был объем буфера порта, он в какой-то момент времени может переполниться, так как является разделяемым ресурсом для многих потоков кадров.
Потеря кадра может привести к снижению полезной для приложения пропускной способности в несколько раз. Количественно ущерб зависит от того, какой протокол занимается восстановлением потерянных в кадре данных. Если это протокол прикладного или транспортного уровня, то при тайм-аутах в сотни миллисекунд, рассчитанных на работу в больших маршрутизируемых составных сетях, снижение производительности может доходить до десятков раз, например, 20 Кбайт/c вместо 600 Кбайт/c, это наблюдали Б. Алдерсон и Дж. Скотт Хогдал в сети NetWare, теряющей только 3% кадров Ethernet ("Сети", N8, 1995 г.). Исправление потерь кадров на нижних уровнях делает сеть менее чувствительной к этому фактору, но в локальных сетях такая ситуация наблюдается только при использовании протокола NetBIOS или же стека SNA компании IBM в сетях TokenRing, а это не такой уж большой процент сетей.
Тенденции таковы, что все чаще в локальных сетях будет использоваться протоколы стека TCP/IP, а протокол TCP, решающий проблему восстановления потерянной информации, вычисляет тайм-аут адаптивно, в зависимости от времени прихода подтверждений от узла-собеседника. При работе через Internet это время может составлять сотни милисекунд, замедляя процесс восстановления кадров так же, как и в сетях NetWare.
Потери кадров при перегрузках выходных портов вообще типичны для полнодуплексных сетей, построенных на основе коммутаторов. Нужно заметить, что такие сети давно используются - это почти все виды глобальных сетей: Х.25, framerelay и АТМ. Индивидуальными в них являются только связи между абонентами сети и первыми коммутаторами, а связи коммутатор - коммутатор всегда разделяются во времени между потоками кадров нескольких абонентов. И если в сетях framerelay и ATM разработаны достаточно тонкие процедуры для поддержания требуемого баланса использования общих каналов между абонентами сети - процедуры управления качеством обслуживания - то в коммутаторах локальных сетей такие процедуры либо не поддерживаются вообще, либо реализуются в самой рудиментарной форме.
Угроза потери кадров - плата за отказ от разделяемой среды на участке сети "компьютер-концентратор". Коммутатор ускоряет работу сети, но при этом пропадает эффект, создаваемый алгоритмом доступа, когда на среду передачи данных разрешалось в каждый момент времени помещение кадра только от одного компьютера. Тем самым регулировался входной поток кадров от компьютеров и гарантировалась невозможность потери кадра при корректной работе оборудования.
Поэтому, локальные сети на основе коммутаторов, как и глобальные, требуют решения задачи управления потоком данных - то есть встраивания в коммутаторы и сетевые адаптеры механизма, который бы притормаживал конечные узлы при перегрузках коммутаторов сети.
При разработке коммутаторов локальных сетей ситуация коренным образом отличалась от ситуации, при которой создавались коммутаторы территориальных сетей.
Основной задачей было сохранение конечных узлов в неизменном виде, что исключало корректировку протоколов локальных сетей. Поэтому разработчики коммутаторов были вынуждены пойти на некоторые хитрости - например, использование фиктивных встречных кадров в методе "обратного давления" или же уменьшении паузы после коллизии по сравнению с ее стандартным значением, что давало коммутатору преимущество при захвате Среды по сравнению с сетевым адаптером.
Для полнодуплексных версий протоколов дело обстоит проще. Так как эти версии разрабатываются заново, то можно включить в них механизмы управления потоком. Это и было сделано многими производителями сначала в виде частных решений, а в марте 1997 года комитет 802.3 IEEE принял спецификацию 802.3x, которая определяет простой способ управления потоком кадров в сетях, построенных на коммутаторах Ethernet.
При переполнении внутренних буферов коммутатор просто передает устройствам, подключенным к его входным портам команду X-off, запрещающую передавать кадры, а при разгрузке буферов - команду X-on, разрешающую продолжить передачу кадров. Многие специалисты считают, что такая простая схема может привести не к улучшению, а к ухудшению ситуации с перегрузкой коммутаторов сети, учитывая максимальную скорость GigabitEthernet в 1 480 000 кадров в секунду. "Слишком просто и слишком медленно" - так охарактеризовал механизм управления потоком профессор Леонард Клейнрок, известный специалист в применении теории массового обслуживания к анализу вычислительных систем. Говард Фрэйзер, председатель группы 802.3z и сетевой специалист компании Cisco, считает, что спецификация 802.3х разработана как низкоуровневое и временное решение проблемы переполнения коммутаторов. Некоторые специалисты считают, что на начальной стадии коммутаторы GigabitEthernet будут переживать те же трудности с управлением потоков кадров, что и коммутаторы АТМ на начальной стадии становления АТМ.
Предупреждение потерь кадров - это только самый начальный уровень управления качеством обслуживания.
Нужны следующие шаги, и для технологий, не включающих поддержку качества обслуживания на уровне протокола, реализация таких механизмов в коммутаторах - единственный способ конкуренции с технологией АТМ.
Существуют частные решения производителей по управлению качеством обслуживания, например, механизм PACE компании 3Com, приписывающий каждый порт коммутатора к одному из трех уровней приоритетов, а затем поддерживающий внутри коммутатора три очереди для каждого выходного порта. Сравнительно недавно появились проекты стандартов такого механизма у комитета 802.1 IEEE - 802.1q и 802.1p. С помощью стандарта 802.1q коммутаторы смогут помечать кадры метками для образования виртуальных сетей и обозначения приоритета трафика. Стандарт 802.1p описывает способ сигнализации, с помощью которого конечная станция может запросить приоритет обслуживания у коммутатора. Однако, эти стандарты не дают никаких гарантий относительно получаемой конечной станцией полосы пропускания и тем более, величины задержек в сети. Приоритет кадра говорит только о том, что в коммутаторе он будет обслуживаться раньше кадров с более низким уровнем приоритета. Низкоприоритетные кадры больших размеров все равно могут заставить высокоприоритетный кадр ожидать достаточно большое время в очереди, если обслуживание низкоприоритетного кадра уже началось к моменту поступления высокоприоритетного.
У приверженцев технологии АТМ возможность достижения высокого качества обслуживания для разных видов трафика с помощью стандартов 802.1q/p вызывает большие сомнения и они кажутся достаточно обоснованными.
