Проблема управления потоком
данных при полнодуплексной работе
Простой отказ от поддержки
алгоритма доступа к разделяемой среде без
какой-либо модификации протокола ведет к
повышению вероятности потерь кадров
коммутаторами, так как при этом теряется
контроль за потоками кадров, направляемых
конечными узлами в сеть. Раньше поток
кадров регулировался методом доступа к
разделяемой среде, так что слишком часто
генерирующий кадры узел вынужден был ждать
своей очереди к среде и фактическая
интенсивность потока данных, который
направлял в сеть этот узел, была заметно
меньше той интенсивности, которую узел
хотел бы отправить в сеть. При переходе на
полнодуплексный режим узлу разрешается
отправлять кадры в коммутатор всегда, когда
это ему нужно, поэтому коммутаторы сети
могут в этом режиме сталкиваться с
перегрузками, не имея при этом никаких
средств регулирования («притормаживания»)
потока кадров.
Причина перегрузок обычно
кроется не в том, что коммутатор является
блокирующим, то есть ему не хватает
производительности процессоров для
обслуживания потоков кадров, а в
ограниченной пропускной способности
отдельного порта, которая определяется
временными параметрами протокола. Например,
порт Ethernet не может передавать больше 14 880
кадров в секунду, если он не нарушает
временных соотношений, установленных
стандартом.
Поэтому, если входной трафик
неравномерно распределяется между
выходными портами, легко представить
ситуацию, когда в какой-либо выходной порт
коммутатора будет направляться трафик с
суммарной средней интенсивностью большей,
чем протокольный максимум. На рис. 4.28
изображена как раз такая ситуация, когда в
порт 3 коммутатора направляется трафик
от портов 1,2,4 и 6, с суммарной
интенсивностью в 22 100 кадров в секунду. Порт 3
оказывается загружен на 150 %, Естественно,
что когда кадры поступают в буфер порта со
скоростью 20 100 кадров в секунду, а уходят со
скоростью 14 880 кадров в секунду, то
внутренний буфер выходного порта начинает
неуклонно заполняться необработанными
кадрами.
Рис. 4.28. Переполнение буфера
порта из-за несбалансированности трафика
Какой бы ни был объем буфера
порта, он в какой-то момент времени
обязательно переполнится. Нетрудно
подсчитать, что при размере буфера в 100
Кбайт в приведенном примере полное
заполнение буфера произойдет через 0,22
секунды после начала его работы (буфер
такого размера может хранить до 1600 кадров
размером в 64 байт). Увеличение буфера до 1
Мбайт даст увеличение времени заполнения
буфера до 2,2 секунд, что также неприемлемо. А
потери кадров всегда очень нежелательны,
так как снижают полезную
производительность сети, и коммутатор,
теряющий кадры, может значительно ухудшить
производительность сети вместо ее
улучшения.
Коммутаторы локальных сетей - не
первые устройства, которые сталкиваются с
такой проблемой. Мосты также могут
испытывать перегрузки, однако такие
ситуации при использовании мостов
встречались редко из-за небольшой
интенсивности межсегментного трафика,
поэтому разработчики мостов не стали
встраивать в протоколы локальных сетей или
в сами мосты механизмы регулирования
потока. В глобальных сетях коммутаторы
технологии Х.25 поддерживают протокол
канального уровня LAP-В, который имеет
специальные кадры управления потоком «Приемник
готов» (RR) и «Приемник не готов» (RNR),
аналогичные по назначению кадрам протокола
LLC2 (это не удивительно, так как оба
протокола принадлежат семейству
протоколов HDLC. Протокол LAP-B работает между
соседними коммутаторами сети Х.25 и в том
случае, когда очередь коммутатора доходит
до опасной границы, запрещает своим
ближайшим соседям с помощью кадра «Приемник
не готов» передавать ему кадры, пока
очередь не уменьшится до нормального
уровня. В сетях Х.25 такой протокол необходим,
так как эти сети никогда не использовали
разделяемые среды передачи данных, а
работали по индивидуальным каналам связи в
полнодуплексном режиме.
При разработке коммутаторов
локальных сетей ситуация коренным образом
отличалась от ситуации, при которой
создавались коммутаторы территориальных
сетей. Основной задачей было сохранение
конечных узлов в неизменном виде, что
исключало корректировку протоколов
локальных сетей. А в этих протоколах
процедур управления потоком не было - общая
среда передачи данных в режиме разделения
времени исключала возникновение ситуаций,
когда сеть переполнялась бы
необработанными кадрами. Сеть не
накапливала данных в каких-либо
промежуточных буферах при использовании
только повторителей или концентраторов.
ПРИМЕЧАНИЕ Здесь речь идет о
протоколах МАС - уровня (Ethernet, Token Ring и т. п.),
так как мосты и коммутаторы имеют дело
только с ними. Протокол LLC2, который умеет
управлять потоком данных, для целей
управления потоком кадров в коммутаторах
использовать нельзя. Для коммутаторов
протокол LLC (все его процедуры: 1,2 и 3)
прозрачен, как и все остальные протоколы
верхних уровней, - коммутатор не
анализирует заголовок LLC, считая его просто
полем данных кадра МАС - уровня.
Применение коммутаторов без
изменения протокола работы оборудования
всегда порождает опасность потери кадров.
Если порты коммутатора работают в обычном,
то есть в полудуплексном режиме, то у
коммутатора имеется возможность оказать
некоторое воздействие на конечный узел и
заставить его приостановить передачу
кадров, пока у коммутатора не разгрузятся
внутренние буферы. Нестандартные методы
управления потоком в коммутаторах при
сохранении протокола доступа в неизменном
виде будут рассмотрены ниже.
Если же коммутатор работает в
полнодуплексном режиме, то протокол работы
конечных узлов, да и его портов все равно
меняется. Поэтому имело смысл для поддержки
полнодуплексного режима работы
коммутаторов несколько модифицировать
протокол взаимодействия узлов, встроив в
него явный механизм управления потоком
кадров.
Работа над выработкой стандарта
для управления потоком кадров в
полнодуплексных версиях Ethernet и Fast Ethernet
продолжалась несколько лет. Такой
длительный период объясняется
разногласиями членов соответствующих
комитетов по стандартизации, отстаивающих
подходы фирм, которые реализовали в своих
коммутаторах собственные методы
управления потоком.
В марте 1997 года принят стандарт
IEEE 802.3x на управление потоком в
полнодуплексных версиях протокола Ethernet. Он
определяет весьма простую процедуру
управления потоком, подобную той, которая
используется в протоколах LLC2 и LAP-B. Эта
процедура подразумевает две команды - «Приостановить
передачу» и «Возобновить передачу»,
которые направляются соседнему узлу.
Отличие от протоколов типа LLC2 в том, что эти
команды реализуются на уровне символов
кодов физического уровня, таких как 4В/5В, а
не на уровне команд, оформленных в
специальные управляющие кадры. Сетевой
адаптер или порт коммутатора,
поддерживающий стандарт 802.3x и получивший
команду «Приостановить передачу», должен
прекратить передавать кадры впредь до
получения команды «Возобновить передачу».
Некоторые специалисты
высказывают опасение, что такая простая
процедура управления потоком окажется
непригодной в сетях Gigabit Ethernet. Полная
приостановка приема кадров от соседа при
такой большой скорости передачи кадров (1 488
090 кадр/с) может быстро вызвать переполнение
внутреннего буфера теперь у этого соседа,
который в свою очередь полностью
заблокирует прием кадров у своих ближайших
соседей. Таким образом, перегрузка просто
распространится по сети, вместо того чтобы
постепенно исчезнуть. Для работы с такими
скоростными протоколами необходим более
тонкий механизм регулирования потока,
который бы указывал, на какую величину
нужно уменьшить интенсивность потока
входящих кадров в перегруженный коммутатор,
а не приостанавливал этот поток до нуля.
Подобный плавный механизм регулирования
потока появился у коммутаторов АТМ через
несколько лет после их появления. Поэтому
существует мнение, что стандарт 802.3х - это
временное решение, которое просто
закрепило существующие фирменные простые
механизмы управления потоком ведущих
производителей коммутаторов. Пройдет
некоторое время, и этот стандарт сменит
другой стандарт - более сложный и более
приспособленный для высокоскоростных
технологий, таких как Gigabit Ethernet.
дальше |содержание |назад
|