Обратная связь
|
Связь механизмов управления трафиком Систему единого управления потоками ячеек пользователей можно представить в несколько уточненном виде (рис. 15.5).
Контроль за установлением соединения
Контроль за установлением соединения (САС) отвечает за доступ в сеть и определяет, будет ли запрошенное соединение установлено или заблокировано. При этом он учитывает параметры, указанные в трафик-контракте. Если ресурсов достаточно и запрошенное качество обслуживания может быть удовлетворено (так что другие соединения и их качество обслуживания не пострадают), то соединение принимается сетью. Если нет – запрос на соединение отклоняется. Контроль за установлением соединения выполняется на каждом коммутаторе в пути от отправителя к получателю. На рис. 15.6 показана общая схема функционирования САС. В первом (верхнем) случае соединение будет установлено, во втором – нет.
В табл. 15.5 описана возможная реализация схемы контроля за установлением соединения. В третьем столбце указана дополнительная полоса пропускания, которая может быть использована другими службами.
Таблица 15.5. Примерная реализация контроля за установлением соединения
Категория сервиса
| Действие
| Дополнительная полоса пропускания, доступная для ABR/UBR
| Высокое QoS, CBR
| Выделяются две полосы, равные PCR
| PCR
| Среднее QoS, CBR
| Выделяется PCR
| Нет
| Высокое QoS, rtVBR
| Выделяется PCR
| PCR минус SCR
| Среднее QoS, rtVBR
| Выделяется 1.5 SCR
| Половина SCR
| nrtVBR
| Выделяется SCR
| Нет
| ABR
| Выделяется MCR + 0.01 % от скорости канала
| Нет
| UBR
| Выделяется 0.01 °А от скорости канала
| Нет
|
Контроль за использованием полосы пропускания
Контроль за использованием полосы пропускания сети (UPC) означает выполнение некоторых действий с целью отслеживания трафика и контроля за ним. Этот механизм проверяет корректность VPI/VCI, обеспечивает наблюдение за согласованным трафик-контрактом и, если необходимо, помечает или отбрасывает ячейки, которые нарушают достигнутое соглашение. Иными словами, UPC реализует проверку соответствия параметров поступающего трафика с параметрами, зафиксированными в трафик-контракте. Функционально механизм контроля за использованием полосы пропускания обычно реализуется на входном коммутаторе в сеть и использует один или два алгоритма, получивших название «дырявое ведро» (Leaky Bucket). Этот алгоритм документирован в рекомендации 1.371 комитета ITU. Такое название алгоритм получил из-за того, что его можно сравнить с ведром с отверстием фиксированного размера в днище. Ячейки заполняют это ведро, а затем «протекают» в сеть. Если происходит переполнение, то «перелившиеся» через край «ведра» ячейки маркируются как несоответствующие.
Тест на соответствие запускается каждый раз, когда ячейка поступает в сеть. Соответствующие ячейки – это те, которые прошли этот тест; им разрешено движение по сети. Несоответствующие ячейки – это те, которые не прошли тест. Они либо отбрасываются до поступления в сеть, либо помечаются с помощью бита CLP в заголовке и следуют далее. Следует отметить, что данный тест не настолько строг, чтобы пропускать только соответствующие ячейки; обычно виртуальные соединения содержат ячейки обоих типов.
При тестирования алгоритм «дырявого ведра» сравнивает параметры качества обслуживания с основными параметрами трафика. Следует отметить, что может быть организована серия тестов с помощью нескольких «дырявых ведер», имеющих различные параметры. Количество «дырявых ведер» зависит от типа трафика и «жесткости» заключенного договора. Например, коммутатор, который проверяет соединения с постоянной скоростью передачи использует одно «дырявое ведро», в то время как для соединений с переменной скоростью необходимо применить два.
Механизм NPC предназначен для проверки параметров потока ячеек на интерфейсе NNI, иными словами, на интерфейсе между сетями. При этом используются те же методы, что и в UPC.
Формирование трафика
Механизм формирования трафика изменяет входной поток ячеек от пользователя, чтобы соблюсти требования, оговоренные в трафик-контракте. При этом устраняются всплески трафика и его неравномерности. Сглаживание входного потока ячеек для каждого соединения позволяет формировать более предсказуемый профиль трафика, снижая при этом возможные потери ячеек и «взрывные» захваты сетевых ресурсов.
Ключевым элементом в трафик-контракте, с точки зрения пользователя, является характеристика последовательности ячеек, которая может быть послана в сеть без нарушения трафик-контракта. Метод, описанный в стандарте, называется «shaping». Иными словами, пользовательское оборудование обрабатывает, формирует исходный поток ячеек таким образом, чтобы входящий в сеть поток соответствовал параметрам трафика. Данная функция отмечена в стандарте как необязательная, но если она не реализована, то сеть не сможет гарантировать качество обслуживания. Сеть может использовать механизм формирования трафика при передаче потока в другую сеть для согласования скорости и соблюдения других условий трафик-контракта, заключенного между сетями. Механизм формирования трафика необходим, например, в такой ситуации, когда коммутатор или пользовательское приложение могут принимать только трафик определенного типа (например, без больших вариаций – иначе буферная память переполнится).
В стандартах и в технической литературе на эту тему описано несколько механизмов реализации формирования трафика:
q Буферизация. Использование буферов в сочетании с алгоритмом «дырявого ведра» позволит гарантировать, что ячейки не нарушат параметры трафика, так как они буферизуются и ожидают обработки «дырявым ведром»;
q Разделение. Ячейки от нескольких виртуальных соединений помещаются в очереди, и их отправление планируется таким образом, чтобы не нарушались параметры трафика;
q Понижение PCR. Пиковую скорость передачи ячеек можно понизить, если отправитель будет работать на меньшей пиковой скорости, чем та, которая указана в трафик-контракте. Таким образом значительно снижается вероятность нарушения достигнутого соглашения;
q Ограничение размера выброса. Работает аналогично предыдущему механизму: отправитель просто ограничивает размер выброса до значения, меньшего параметра MBS, указанного в трафик-контракте.
q Ограничение скорости отправителя. Наиболее строгий механизм формирования трафика – реальная скорость передачи ячеек ограничивается до некоторого значения.
Контроль потока ABR
Службе ABR уделено основное внимание в спецификации Traffic Management 4.0, принятой в феврале 1996 года Форумом ATM. Основной особенностью этой службы является механизм обратной связи (feedback), который позволяет отправителю определить количество доступных в настоящий момент времени сетевых ресурсов. Так как каналы связи ATM работают с достаточно высокими скоростями, механизм обратной связи должен поддерживаться на аппаратном уровне.
Выделяют три типа обратной связи:
q явная индикация перегрузки при прямой передаче (Explicit Forward Congestion Indication, EFCI, рис. 15.7);
q явная индикация скорости (Explicit Rate, ER, рис. 15.8);
q метод виртуальных отправителей и получателей (Virtual Source/Virtual Destination, VS/VD).
Служба ABR требует периодического включения в поток служебных ячеек, которые предназначены для управления ресурсами (Resource Management, RM). Обычно на 32 ячейки с данными требуется две служебные ячейки. Основная цель использования служебных ячеек состоит в доставке информации о степени загруженности сети отправителю данных. Ячейки, следующие в направлении передачи данных, называются прямыми ячейками (Forward Resource Management, FRM), а служебные ячейки, следующие в противоположном направлении, – обратными (Backward Resource Management, BRM).
При использовании механизма EFCI станция-отправитель передает коммутатору ATM ячейки с данными и прямые служебные ячейки. Коммутатор записывает код EFCI в служебные поля ячеек с данными и передает их по назначению. Получатель преобразует прямые служебные ячейки в обратные, устанавливая при этом бит индикации перегрузки (CI) обратных ячеек в соответствии со значением кода EFCI в ячейках с данными. После этого отправитель данных получает обратные служебные ячейки и регулирует скорость передачи с учетом содержащейся в них информации.
При использовании механизма явной индикации скорости (ER) отправитель передает ячейки с данными и служебные ячейки (FRM), в которых указана желательная для него скорость. Коммутаторы ATM при необходимости уменьшают значение скорости в служебных ячейках (прямых и обратных) до той величины, которая нужна им. Получатель преобразует прямые служебные ячейки (FRM) в обратные (BRM) и также может уменьшить значение скорости. После этого отправитель данных получает обратные служебные ячейки и выравнивает скорость передачи в соответствии с информацией в них. Таким образом, пройдя путь от отправителя до получателя и обратно, служебные ячейки содержат максимальную скорость, допустимую для самого медленного устройства на пути.
В табл. 15.6 содержатся основные параметры, определяемые во время установления виртуального соединения для службы ABR. В этом наборе параметров выделяют обязательные, которые необходимо задать при установлении соединения, и дополнительные. В табл. 15.6 перечислены не все дополнительные параметры.
Таблица 15.6. Параметры службы ABR ER
Параметры
| Описание
| Обязательные
| PCR (Peak Cell Rate)
| Разрешенная пиковая скорость отправителя ячеек
| MCR (Minimum Cell Rate)
| Минимальная скорость, гарантируемая отправителем
| ICR (Initial Cell Rate)
| Скорость посылки ячеек отправителем после простоя
| RIF (Rate Increase Factor)
| Используется для вычисления коэффициента повышения скорости после получения RM-ячейки
| RDF (Rate Decrease Factor)
| Используется для вычисления коэффициента понижения скорости после получения RM-ячейки
| TBE (Transient Buffer Exposure)
| Число ячеек, которые отправитель должен послать в течение стартового периода
| FRTT (Fixed Round-Trip Time)
| Время пересылки от отправителя до самого дальнего получателя и обратно
| Дополнительные
| Nrm
| Максимальное число ячеек, которое отправитель может послать для каждой ячейки FRM
| ACR (Allowed Cell Rate)
| Текущая скорость ячеек, которую разрешено поддерживать отправителю
| ADTF (ACR Decrease Time Factor)
| Разрешенное время между посылкой RM-ячеек до снижения скорости до ICR
|
В табл. 15.7 описан формат служебных ячеек.
Таблица 15.7. Содержимое служебных ячеек
Поле
| Байт
| Описание
| Заголовок
| 1-5
| Заголовок ячейки с полем PTI-110
| ID
|
| Идентификатор протокола
| DIR ...
| 7
| Направление: 0 = прямое, 1 = обратное
| BN
| 7
| BECN, BN = 1 указывает на отправителя RM-ячейки
| CI
| 7
| Указатель перегрузки (CI = 1); отправитель должен снизить ACR
| N1
| 7
| Используется, если коммутатор обнаружил возможность возникновения перегрузки
| RA
| 7
| Не используется в спецификации ABR Форума ATM
| Зарезервировано
| 7
| -
| ER
| 8-9
| Точная скорость передачи ячеек
| CCR (Current Cell Rate)
| 10-11
| Текущая скорость передачи ячеек; CCR = ACR, когда отправитель посылает RM-ячейку
| MCR
| 12-13
| Минимальная скорость передачи ячеек
| QL
| 14-17
| Размер очереди; не используется в спецификации ABR Форума ATM
| SN
| 18-21
| Номер; не используется в спецификации ABR Форума ATM
| Зарезервировано
| 22-51
| -
| Зарезервировано
|
| -
| CRC-10
| 52-53
| -
|
Механизм виртуальных отправителей и получателей (VS/VD) идентичен схеме ER, за исключением следующих отличий: каждый виртуальный получатель может преобразовывать прямые служебные ячейки в обратные, и каждый виртуальный отправитель должен генерировать прямые служебные ячейки и реагировать на обратные (рис. 15.9). Этот механизм реализуется на промежуточных коммутаторах ATM; он обеспечивает более эффективную работу служб ABR в больших сетях.
Преимущество такой схемы заключается в том, что время обратной связи значительно снижается. Кроме того, служба ABR освобождается от необходимости регулировать обмен данными в масштабах всей сети одновременно. Так как пары VS/VD соответствуют спецификациям Форума ATM для отправителей и получателей, они могут также служить для поддержки стандартов ABR. Каждый виртуальный отправитель должен иметь соответствующего виртуального получателя, но их взаимодействие реализуется различными производителями по-разному: общий стандарт для него пока не определен.
Механизм обратной связи нацелен на решение главной задачи – борьбу с перегрузками в сети. Особенностью этих механизмов является то, что они стараются работать как можно ближе к грани, за которой может наступить перегрузка. Для реализации всех возможностей обратной связи требуется тонкая настройка элементов сети, но в результате достигается максимальная пропускная способность.
Контроль приоритетов
Одной из задач, решаемых коммутатором ATM, является выбор ячейки, которая должна быть послана следующей. Наиболее простым методом выбора является строгое следование схеме приоритетов. Например, если в буфере находятся ячейки, относящиеся к трафику с постоянной скоростью (CBR), они должны быть отправлены в первую очередь. Если же таких нет, то нужно передавать ячейки, относящиеся к службе rtVBR. Если такие ячейки также отсутствуют, то передаются ячейки службы nrtVBR и т. д., до тех пор, пока не будут обслужены все категории трафика (рис. 15.10)
К сожалению, описанная методика наталкивается на проблему нехватки ресурсов. Можно допустить, чтобы трафик CBR имел приоритет перед любыми другими категориями, поскольку он не порождает внезапных всплесков и всегда оставляет часть полосы пропускания доступной для остальных служб. Однако если наивысший приоритет получит трафик VBR, не исключено, что многочисленные виртуальные соединения данного типа одновременно начнут передачу на максимальной скорости. В результате общий объем передаваемых данных может превысить имеющуюся полосу пропускания, и тогда менее приоритетные службы могут быть полностью приостановлены. При этом возможно возникновение временного тайм-аута для пользовательских приложений, которые обязаны провести повторную передачу данных, что может привести к перегрузке сети. Данная проблема еще более усугубляется, если дать приоритетные права службам UBR или ABR. Дело в том, что данные службы рассчитаны на использование всей имеющейся полосы пропускания, так что ячейки с более низким приоритетом будут постоянно дискриминироваться.
Более сложная, но менее проблематичная схема выбора ячеек для передачи сводится к тому, чтобы при наиболее высоком приоритете службы CBR (необходимом для достижения высокого качества сервиса), поддерживалось некоторое взвешенное распределение полосы пропускания между остальными службами (рис. 15.11).
На практике значения, указанные на рис. 15.11, приходится рассчитывать заново при установлении или разрыве очередного виртуального соединения.
|
|