Рисунок 4.3.5.3. Иллюстрация работы алгоритма GCRA
gcra имеет два параметра. Один из них характеризует максимально допустимую скорость передачи (PCR - peak cell rate; T=1/PCR - минимальное расстояние между ячейками), другой - допустимую вариацию значения скорости передачи (CDVT=L). Если клиент не собирается посылать более 100000 ячеек в секунду, то Т=10 мксек. На Рисунок 4.3.5.3 представлены разные варианты следования ячеек. Если ячейка приходит раньше чем T-t, она считается неподтверждаемой и может быть отброшена. Ячейка может быть сохранена, но при этом должен быть установлен бит CLP=1. Применение бита CLP может быть разной для разных категорий услуг (смотри таблицу 4.3.5.3.). Данный механизм управления трафиком сходен с алгоритмом "дырявое ведро", описанным в разделе "Сети передачи данных".
Можно вычислить число подтверждаемых ячеек N, которые могут быть переданы при пиковом потоке ячеек PCR=1/t. Пусть время ячейки в пути равно d. Тогда N = 1 + (l/(T-d)). Если полученное число оказалось нецелым, оно должно быть округлено до ближайшего меньшего целого.
Трудно устранимой проблемой для atm является предотвращение перегрузки на промежуточных коммутаторах-переключателях. Коммутаторы могут иметь 100 внешних каналов, а загрузка может достигать 350000 ячеек/сек. Здесь можно рассматривать две задачи: подавление долговременных перегрузок, когда поток ячеек превосходит имеющиеся возможности их обработки, и кратковременные пиковые загрузки. Эти проблемы решаются различными способами: административный контроль, резервирование ресурсов и управление перегрузкой, привязанное к уровню трафика.
В низкоскоростных сетях с относительно медленно меняющейся или постоянной загрузке администратор вмешивается лишь при возникновении критической ситуации и предпринимает меры для понижения скорости передачи. Очень часто такой подход не слишком эффективен, так как за время доставки управляющих команд приходят многие тысячи ячеек. Кроме того, многие источники ячеек в ATM работают с фиксированной скоростью передачи (например, видеоконференция).
Требование понизить скорость передачи здесь достаточно бессмысленно. По этой причине в АТМ разумнее предотвращать перегрузку. Но для трафика типа CBR, VBR и UBR не существует никакого динамического управления перегрузкой и административное управление является единственной возможностью. Когда ЭВМ желает установить новый виртуальный канал, она должна охарактеризовать ожидаемый трафик. Сеть анализирует возможность обработки дополнительного трафика с учетом различных маршрутов. Если реализовать дополнительный трафик нельзя, запрос аннулируется. В отсутствии административного контроля несколько широкополосных пользователей могут блокировать работу массы узкополосных клиентов сети, например, читающих свою почту.
Резервирование ресурсов по своей сути близко административному контролю и выполняется на фазе формирования виртуального канала. Резервирование производится вдоль всего маршрута (во всех коммутаторах) в ходе реализации процедуры setup. Параметрами резервирования может быть значение пикового значения полосы пропускания и/или средняя загрузка.
Для типов сервиса CBR и VBR отправитель даже в случае перегрузки не может понизить уровень трафика. В случае UBR потери не играют никакой роли. Но сервис ABR допускает регулирование трафика. Более того, такое управление здесь весьма эффективно. Существует несколько механизмов реализации такого управления. Так предлагалось, чтобы отправитель, желающий послать блок данных, сначала посылал специальную ячейку, резервирующую требуемую полосу пропускания. После получения подтверждения блок данных начинает пересылаться. Преимуществом данного способа следует считать то, что перегрузки вообще не возникает. Но данное решение не используется из-за больших задержек (решение ATM-форума).
Другой способ сопряжен с посылкой коммутаторами специальных ячеек отправителю в случае возникновения условий перегрузки. При получении такой ячейки отправитель должен понизить скорость передачи вдвое. Предложены различные алгоритмы последующего восстановления скорости передачи.
Но и эта схема отвергнута форумом atm из-за того, что сигнальные ячейки могут быть потеряны при перегрузке. Действительно данный алгоритм не всегда можно признать разумным. Например, в случае, когда коммутатор имеет 10 каналов с трафиком по 50 Мбит/с и один канал с потоком в 100 кбит/c, глупо требовать понижения трафика в этом канале из-за перегрузки.
Третье предложение использует тот факт, что граница пакета помечается битом в последней ячейке. Коммутатор просматривает входящий поток и ищет конец пакета, после чего выбрасывает все ячейки, относящиеся к следующему пакету. Этот пакет будет переслан позднее, а отбраcывание M ячеек случайным образом может вынудить повторение передачи m пакетов, что значительно хуже. Данный вариант подавления перегрузки был также не принят, так как выброшенный пакет совсем не обязательно послан источником, вызвавшим перегрузку. Но этот способ может быть использован отдельными производителями коммутаторов.
Обсуждались решения, сходные с тем, что используется в протоколе TCP "скользящее окно". Это решение требует слишком большого числа буферов в коммутаторах (как минимум по одному для каждого виртуального канала). После длинных дискуссий был принят за основу совершенно другой метод.
После каждых М информационных ячеек каждый отправитель посылает специальную RM-ячейку (resource management). Эта ячейка движется по тому же маршруту, что и информационные, но RM-ячейка обрабатывается всеми коммутаторами вдоль пути. Когда она достигает места назначения, ее содержимое просматривается и корректируется, после чего ячейка посылается назад отправителю. При этом появляются два дополнительных механизма управления перегрузкой. Во-первых, RM-ячейки могут посылаться не только первичным отправителем, но и перегруженными коммутаторами в направлении перегрузившего их отправителя. Во-вторых, перегруженные коммутаторы могут устанавливать средний PTI-бит в информационных ячейках, движущихся от первоисточника к адресату. Но даже выбранный метод подавления перегрузки не идеален, так как также уязвим из-за потерь управляющих ячеек.
SAR | (segmentation and reassemble) делит пакеты высокого уровня, передает atm и наоборот (сборка сообщений из сегментов). |
CS | (convergent sub-layer) зависит от вида услуг (обработка случаев потери пакета, компенсация задержек, мониторирование ошибок и т.д.). Этот подуровень может в свою очередь делиться на две секции: CPCS (common part convergence sublayer) – общая часть субуровня конвергенции и SSCS (service-specific convergence sublayer) – служебно-ориентированный подуровень конвергенции (последний может и отсутствовать). |