Проблема управления потоком данных
при полнодуплексной работе
Простой отказ от поддержки алгоритма доступа к разделяемой
среде без какой-либо модификации протокола ведет к повышению вероятности потерь
кадров коммутаторами, так как при этом теряется контроль за потоками кадров,
направляемых конечными узлами в сеть. Раньше поток кадров регулировался методом
доступа к разделяемой среде, так что слишком часто генерирующий кадры узел
вынужден был ждать своей очереди к среде и фактическая интенсивность потока
данных, который направлял в сеть этот узел, была заметно меньше той
интенсивности, которую узел хотел бы отправить в сеть. При переходе на
полнодуплексный режим узлу разрешается отправлять кадры в коммутатор всегда,
когда это ему нужно, поэтому коммутаторы сети могут в этом режиме сталкиваться
с перегрузками, не имея при этом никаких средств регулирования
(«притормаживания») потока кадров.
Причина перегрузок обычно кроется не в том, что коммутатор
является блокирующим, то есть ему не хватает производительности процессоров для
обслуживания потоков кадров, а в ограниченной пропускной способности отдельного
порта, которая определяется временными параметрами протокола. Например, порт
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-B, который имеет специальные кадры управления потоком
«Приемник готов» (RR) и «Приемник не готов» (RNR), аналогичные по назначению
кадрам протокола LLC2 (это не удивительно, так как оба протокола принадле жат
семейству протоколов HDLC. Протокол LAP-B работает между соседними
коммутаторами сети Х.25 и в том случае, когда очередь коммутатора доходит до
опасной границы, запрещает своим ближайшим соседям с помощью кадра «Приемник не
готов» передавать ему кадры, пока очередь не уменьшится до нормального уровня.
В сетях Х.25 такой протокол необходим, так как эти сети никогда не использовали
разделяемые среды передачи данных, а работали по индивидуальным каналам связи в
полнодуплексном режиме.
При разработке коммутаторов локальных сетей ситуация
коренным образом отличалась от ситуации, при которой создавались коммутаторы
территориальных сетей. Основной задачей было сохранение конечных узлов в
неизменном виде, что исключало корректировку протоколов локальных сетей. А в
этих протоколах процедур управления потоком не было — общая среда передачи
данных в режиме разделения времени исключала возникновение ситуаций, когда сеть
переполнялась бы необработанными кадрами. Сеть не накапливала данных в
каких-либо промежуточных буферах при использовании только повторителей или
концентраторов.
Применение коммутаторов без изменения протокола работы
оборудования всегда порождает опасность потери кадров. Если порты коммутатора
работают в обычном, то есть в полудуплексном режиме, то у коммутатора имеется
возможность оказать некоторое воздействие на конечный узел и заставить его
приостановить передачу кадров, пока у коммутатора не разгрузятся внутренние
буферы. Нестандартные методы управления потоком в коммутаторах при сохранении
протокола доступа в неизменном виде будут рассмотрены ниже.
Если же коммутатор работает в полнодуплексном режиме, то
протокол работы конечных узлов, да и его портов все равно меняется. Поэтому
имело смысл для поддержки полнодуплексного режима работы коммутаторов несколько
модифицировать протокол взаимодействия узлов, встроив в него явный механизм
управления потоком кадров.
Работа над выработкой стандарта для управления потоком
кадров в полнодуплексных версиях Ethernet и Fast Ethernet продолжалась
несколько лет. Такой длительный период объясняется разногласиями членов
соответствующих комитетов по стандартизации, отстаивающих подходы фирм, которые
реализовали в своих коммутаторах собственные методы управления потоком.
В марте 1997 года принят стандарт IEEE 802.3x на управление
потоком в полнодуплексных версиях протокола Ethernet. Он определяет весьма
простую процедуру управления потоком, подобную той, которая используется в
протоколах LLC2 и LAP-B. Эта процедура подразумевает две команды —
«Приостановить передачу» и «Возобновить передачу», которые направляются
соседнему узлу. Отличие от протоколов типа LLC2 в том, что эти команды
реализуются на уровне символов кодов физического уровня, таких как 4В/5В, а не
на уровне команд, оформленных в специальные управляющие кадры. Сетевой адаптер
или порт коммутатора, поддерживающий стандарт 802.3х и получивший команду
«Приостановить передачу», должен прекратить передавать кадры впредь до
получения команды «Возобновить передачу».
Некоторые специалисты высказывают опасение, что такая
простая процедура управления потоком окажется непригодной в сетях Gigabit
Ethernet. Полная приостановка приема кадров от соседа при такой большой
скорости передачи кадров (1 488 090 кадр/с) может быстро вызвать переполнение
внутреннего буфера теперь у этого соседа, который в свою очередь полностью
заблокирует прием кадров у своих ближайших соседей. Таким образом, перегрузка
просто распространится по сети, вместо того чтобы постепенно исчезнуть. Для
работы с такими скоростными протоколами необходим более тонкий механизм
регулирования потока, который бы указывал, на какую величину нужно уменьшить
интенсивность потока входящих кадров в перегруженный коммутатор, а не
приостанавливал этот поток до нуля. Подобный плавный механизм регулирования
потока появился у коммутаторов ATM через несколько лет после их появления.
Поэтому существует мнение, что стандарт 802.3х — это временное решение, которое
просто закрепило существующие фирменные простые механизмы управления потоком
ведущих производителей коммутаторов. Пройдет некоторое время, и этот стандарт
сменит другой стандарт — более сложный и более приспособленный для
высокоскоростных технологий, таких как Gigabit Ethernet.