На рис.1 представлен спектр технологий коммутации. Из него видно, что режимы передачи, располагающиеся в центре оси, являются наиболее оптимальными в смысле сложности реализации и возможности работы с переменными скоростями, т.е. представляют "золотую середину". Системы быстрой коммутации пакетов охватывают несколько альтернатив, все они представляют пакетную коммутацию с минимальным набором функций, реализуемых сетью. Наиболее известной сегодня разновидностью является АТМ - асинхронный режим передачи, которому и будет посвящен данный материал. Акроним "асинхронный" означает, что реализуется асинхронное взаимодействие между тактовой частотой передатчика и приемника. Разница между этими частотами сглаживается за счет вставки\удаления пустых\неассоциированных пакетов в информационный поток, т.е. пакетов, не содержащих полезной информации.
Главное достоинство режимов, расположенных в середине оси, в том, что они предоставляют возможность передачи любых видов служб независимо от того, какую скорость они требуют, требований качества и импульсивности трафика.
Действительно, режим коммутации каналов приспособлен для работы на постоянной скорости передачи (имеется в виду, конечно, цифровая передача), и не допускается никаких всплесков нагрузки. Если же пользователь все же генерирует в какой-то момент более интенсивный поток данных, то он все равно при входе в систему будет ограничен скоростью работы системы, естественно, с потерей качества. С другой стороны, система пакетной коммутации очень хорошо может работать с переменной скоростью передачи, не ограничивая в принципе абонента по скорости (за исключением того, что поток от абонента физически не может пройти по имеющимся каналам из-за ограниченной пропускной способности линий связи), однако, механизмы реализации этого режима слишком сложны и технология коммутации такова, что не все виды сервиса можно с ее помощью обслужить, поскольку задержка передачи данных произвольная, чего нельзя допускать при передаче некоторых типов сигналов, например, видеосигнала. Как можно заключить из рис.1 технология АТМ вобрала в себя достоинства систем, расположенных на обоих краях оси, правда, не избежала и некоторых присущих им обоим недостатков. Например, статистическое уплотнение соединений в линии выполняется менее эффективно, чем в системе классической пакетной коммутации. Это выражается в том, что если абонент заказал пропускную способность для своего соединения, но фактически ею не пользуется, то она не может быть предоставлена под вновь устанавливаемое соединение - система считает, что абонент может начать ее использовать в любой момент, и, поэтому, не может установить еще одно соединение под уже заказанные, но неиспользуемые ресурсы. В этом есть нечто от системы коммутации каналов. Правда, в отличие от последней, неиспользуемые в описываемом случае ресурсы системы могут отводиться под уже установленные соединения, чего нет в коммутации каналов. Однако преимущества системы АТМ, выражающиеся в способности передавать трафик любого типа с гарантированным качеством, перевешивают некоторые недостатки. Эти преимущества были главными для МККТТ, чтобы определить АТМ как режим передачи будущих широкополосных сетей. Внедрение технологии АТМ позволит добиться следующих преимуществ.
Гибкость. Развитие систем кодирования и сжатия данных приводит к уменьшению требований по скорости передачи. В будущем, возможно, возникнут новые службы с новыми требованиями. Все эти изменения не потребуют модификации сети АТМ и не приведут к ухудшению использования каналов.
Эффективное распределение ресурсов. Все доступные ресурсы сети могут использоваться всеми службами с оптимальным статистическим разделением. Не предусматривается никаких специализаций ресурсов по видам служб. Здесь имеется в виду более эффективное распределение по сравнению с наиболее распространенными сегодня системами коммутации каналов. Конечно, система Х.25 или TCP/IP распределяют ресурсы более эффективно, но в ущерб качеству.
Единая универсальная сеть. Поскольку требуется разработать и поддерживать только одну сеть, то полная стоимость системы может быть меньше, чем суммарная стоимость всех существующих сетей.
Итак, перечислив главные достоинства универсальной сети, перейдем непосредственно к рассмотрению основ построения АТМ.
1.1 Никакой защиты от ошибок и процедур управления потоком на участках между узлами В случае, если на какой-либо линии между узлами или между пользователем и сетью возникают ошибки, или линия временно перегружена, что вызывает отбрасывание пакетов, в узле не предпринимается никаких действий для исправления возникающих сбоев (например, запросов на повторные передачи ошибочных пакетов). Процедуры защиты от ошибок на канале можно убрать из-за того, что каналы в сети очень высокого качества. По этой причине невозможно использовать в сети АТМ аналоговые каналы, поскольку на них никогда нельзя добиться такого низкого уровня ошибок, при котором из сети можно было бы выкинуть эти функции. Приемлемым для АТМ является канал, уровень ошибок на котором не выше 10-8. Что касается ошибок, вызванных потерей данных в узлах коммутации, то вероятность таких событий удерживается на допустимом уровне за счет очень точного резервирования ресурсов системы под каждый абонентский поток. Системы управления потоком также не реализуются. Разумеется, необходимо как-то распределять ресурсы между пользователями, и в данном случае это делается с помощью анализа количества незанятой пропускной способности каналов и последующем статистическом прогнозе о длине очередей пакетов на доступ к каналу. Эти вероятные размеры очередей не должны будут выйти за пределы имеющейся у узла памяти. Все это позволяет обеспечивать заданную частость переполнений памяти, вызывающих потери пакетов. В результате вполне достижимой оказывается величина вероятности потери пакета на уровне 10-8-10-12.
Уже говорилось, что ошибки при передаче и при переполнении памяти приводят к потерям различного рода - простые поражения битов данных, потери пакетов и вставки пакетов. Поражения единичных битов связаны, как правило, с шумами в канале и с рассинхронизацией. В сетях коммутации каналов не предпринимается никаких действий внутри сети для исправления таких ошибок, тогда как в классической пакетной коммутации вводится механизм повторных передач. В системе АТМ как и в телефонной сети все проблемы по устранению подобных ошибок перекладываются на плечи абонента, т.е. на протокол из конца в конец.
Ошибки типа вставки и потери пакетов связаны с ошибками, наложившимися на заголовок данных, что типично для всех пакетных сетей. В сети АТМ предпринимаются некоторые действия по исправлению подобных ошибок, но делается это по совершенно другому принципу, чем в обычных пакетных сетях. Так, если в пакетных сетях все это можно исправить с помощью повторной передачи недоставленных пакетов, то в сети АТМ этого делать уже нельзя, поскольку каждый переспрос данных вызовет большую задержку передачи, которая в общем случае недопустима. Поэтому вводится система кодирования с исправлением ошибок, но только по отношению к заголовку пакетов. Восстановление потерянных вследствие переполнений памяти пакетов здесь не производится, но зато реализуются некоторые превентивные действия по минимизации самой возможности такого переполнения, основаннные на том, что на этапе установления соединения проверяется, имеется ли в наличии достаточное количество ресурсов сети. Конечно, невозможно заранее предсказать, какой интенсивности поток будет исходить от абонента в течение всего времени соединения, и, поэтому, потери пакетов достаточно типичны для сетей АТМ в силу того, что у сети нет средств по управлению абонентским потоком, однако величину этих потерь удается удерживать в допустимых пределах за счет того, что система работает по принципу ориентации на соединения (connection-oriented). Это значит, что перед началом обмена данными проводится этап установления соединения, в котором можно оговорить допустимые параметры трафика. Управление абонентским потоком реализовать достаточно сложно, поскольку это требует оперативного обмена служебной информацией непосредственно во время передачи данных и обработка этой информации будет требовать времени и вносить задержку. Хотя, в форматах пакетов АТМ, которые мы будем рассматривать ниже, предусмотрена возможность для вставки в них такой служебной информации, но сама процедура пока не реализована.
Перед тем, как начать передачу данных, выполняется фаза установления соединения, во время которой в сети отводятся под это соединение определенные ресурсы. Если необходимых ресурсов в системе нет, соединение получает отказ. По этой причине вероятность переполнения памяти в узле, а значит, вероятность потерь пакетов, удерживается на очень низком уровне - 10-8-10-12. По окончании соединения ресурсы возвращаются в систему. Это позволяет системе гарантировать минимальный уровень потерь пакетов и, соответственно, максимальное качество. При этом под соединение отводится не жесткое значение пропускной способности, а статистические значения, т.е. среднее и максимальное значение потока. Поэтому вероятность переполнения памяти все-таки присутствует.
1.2 Ограничение функций обработки заголовка Для того, чтобы обеспечивать быструю обработку пакетов, их заголовок должен быть относительно коротким. Основная функция заголовка сводится к идентификации виртуального соединения (в это понятие здесь вкладывается точно такой же смысл, как и в сетях Х.25). Как и в Х.25 производится мультиплексирование многих виртуальных соединений в одной линии. Последствием поражения заголовка ошибкой будет неверная маршрутизация пакета - т.е. однократная ошибка приведет к потере всего пакета. Это можно расценить как ситуацию, когда в пакете оказался ошибочным каждый бит. Для того, чтобы уменьшить эту вероятность вводится механизм защиты заголовка по принципу обнаружения или исправления ошибок (ранее говорилось, что защиты от ошибок нет, но имелось в виду, что нет защиты от ошибок поля данных).
В случае, если бы не выполнялось защиты от ошибок в заголовке, то, во-первых, данный пакет не был бы доставлен получателю, т.е. имело бы место пропадание пакета в данном виртуальном соединении, а, во-вторых, этот пакет был бы доставлен не тому получателю, у которого произошла бы вставка лишнего пакета. Иначе говоря, в этом случае однократная ошибка вызвала бы две ошибки типа вставки и выпадения пакета. Если мы введем в заголовок функцию обнаружения ошибок, т.е. отбрасывания пакета при наложении ошибки на заголовок, то он не будет доставлен не тому получателю, а только отброшен. Следовательно, ошибка вызовет только одну потерю. Если же ввести в заголовок функцию исправления ошибок, то ошибок типа выпадений и вставок по причине искажений бит уже не будет. Именно на этом принципе остановились разработчики процедуры АТМ. Все было бы хорошо, если бы на заголовок не могла наложиться множественная ошибка, т.е. если много бит в заголовке оказались поражены. Уже говорилось о том, что большинство ошибок либо одиночные, либо пакетные, т.е. множественные. Единичные ошибки можно исправить помехозащитным кодом. Пакетную ошибку исправить гораздо труднее, и это требует значительной избыточности. С другой стороны, маловероятно, что пакетная ошибка поразила только заголовок - скорее всего поражены также и информационные биты. Поэтому, исправлять их в заголовке бесполезно. Это значит, что если ввести функцию исправления однократной ошибки, то это решит большинство связанных с этим проблем. По этой причине в системе АТМ был введен оригинальный адаптивный метод коррекции ошибок (рис. 2). Его суть состоит в следующем. В нормальном режиме, т.е. когда ошибок нет, заголовок обрабатывается в режиме коррекции однократных ошибок. В случае, если система обнаружила ошибку и исправила ее исходя из возможностей исправления только одной ошибки, то она сразу переходит в режим обнаружения (но не исправления) ошибок. Это сделано для того, что в том случае, если ошибка была пакетная (а это значит, что исправление было неправильным), только этот первый пакет прошел дальше в сеть с искаженным заголовком - все последующие пакеты, в которых обнаружена ошибка, будут уничтожены. Если же ошибка была все-таки однократная, то следующий пакет скорее всего будет безошибочным, что и отметит механизм обнаружения и вернется в режим с коррекцией ошибок. Это значит, что после первого исправления ошибок, отбрасываться будут только следующие друг за другом искаженные пакеты.
Рис. 2. Адаптивный мехпнизм обнаружения/исправления ошибок в заголовке пакета
Помимо перечисленного на заголовок накладывается еще очень ограниченный набор функций, связанных с эксплуатацией соединений. Все остальные функции заголовка, имеющиеся в классической пакетной коммутации изъяты. Благодаря этому имеется возможность тратить на обработку одного пакета очень мало времени и работать с большими скоростями.
Для того, чтобы уменьшить размеры памяти в узлах и ограничить время ожидания пакетов в очередях, поле информации пакета сравнительно мало. В самом деле, малый объем буфера означает малое время ожидания и небольшие флуктуации этого времени.
1.3 Размер поля информации Уже говорилось, что размер поля данных в пакетах АТМ должен быть достаточно маленьким. Однако, необходимо было определить, какой именно. Прежде всего дебаты разгорелись вокруг вопроса, делать ли пакет переменной или постоянной длины. Первым предложением было сделать пакеты фиксированной длины размером всего 16 байт. На самом деле как у переменной, так и у постоянной длины есть свои выгоды и недостатки. При этом исходили из оценки эффективности использования канала, затрат на коммутацию, сложности реализации и задержки.
Ясно, что с точки зрения использования канала переменная длина пакета предпочтительнее, поскольку если сообщение короткое или его длина не кратна фиксированному размеру пакета, то потребуется дополнять последний пакет до полного объема, на что уходит пропускная способность. Кроме того, при постоянной длине пакета придется вводить дополнительные функции в заголовок данных для того, чтобы определять, где именно в составе пакета кончаются пользовательские данные и начинаются биты заполнения (впрочем, это можно делать и на более высоком уровне).
С другой стороны, чем длиннее сообщение, тем это преимущество переменной длины менее заметно, поскольку доля вносимой избыточности становится малой по сравнению с пользовательскими данными - ведь дополнять объем поля данных до фиксированного размера придется только последнему пакету. Если же пакет переменной длины, то все равно придется вносить особые функции в заголовок с целью определения границ пакета наподобие того, как это делается в процедуре HDLC. Тем более, что все равно нужно как-то ограничивать максимальную длину - нельзя же допускать размер пакета, исчисляемый килобайтами!
В целом можно сказать, что с точки зрения эффективности использования канала переменная длина пакета выгоднее, чем постоянная, правда, очень незначительно.
Что касается затрат на коммутацию, и сложности реализации, то на это влияют два основных фактора: скорость обработки данных и требования по размеру памяти.
Скорость обработки зависит от объема операций и времени, отводимой на это. Одной из важных функций системы АТМ является обработка заголовка. Предположим, что заголовок обрабатывается независимо от того, используется ли переменная или постоянная длина пакета. Для того, чтобы работать в реальном времени, необходимо успеть обработать заголовок пакета за время приема следующего пакета. Если система рассчитана на работу со скоростью 150 Мбит/сек, то при длине пакета 53 байта это время составит 2.8 мксек. Если же представить себе систему с переменной длиной пакета, то ориентироваться по скорости обработки нужно на наихудший случай, т.е. когда пакет имеет минимальную длину, например, 10 байт. В этом случае при той же скорости заголовок должен быть полностью обработан за 533 наносекунды, т.е. требования по быстродействию значительно ужесточаются.
Что касается требований по управлению памятью, то в случае фиксированной длины пакета резервировать память гораздо проще. В случае переменной длины, резервировать память пришлось бы в расчете на максимальную длину, что менее производительно и экономно, или же динамически резервировать память побайтно, что значительно сложнее.
В отношении задержки можно сказать, что она напрямую зависит от длины пакета, и эта длина не может быть очень большой, поскольку в противном случае задержки передачи возрастают. Действительно, когда поток битов от пользователя поступает в сеть, то при формировании пакета первый бит должен ждать, пока придет последний, и только когда объем накопленной информации будет достаточным для заполнения пакета, он будет отправлен в канал. Следовательно, чем больше пакет, тем дольше будет информация ожидать в передатчике момента начала передачи. Поэтому при больших длинах пакетов становится проблематичной передача видео и голоса. Поэтому, даже, если и делать пакеты переменной длины, она сможет варьироваться в очень узких пределах.
Таким образом, преимущества переменной длины пакета над постоянной ничтожны, и в результате МККТТ остановился на принятии пакетов фиксированной длины. Ввиду этого возникла необходимость называть этот блок данных по-другому, поскольку существующее слово "пакет" означает блок данных произвольной длины. Остановились на слове "cell" , что в дословном переводе означает "ячейка". Однако, поскольку мне не попадались официальные переводы соответствующих документов на русский язык, которых может быть и не существует, я не возьму на себя смелость давать самостоятельный невыверенный перевод этого слова и в дальнейшем изложении буду называть его в английской транскрипции - СЕЛЛ.
Когда МККТТ выбирал конкретное значение длины селла, то при этом принималась во внимание использование канала, задержка передачи и сложность реализации. С точки зрения использования канала лучше сделать селл побольше, т.к. при этом доля служебной информации - заголовки - уменьшается, однако, чем больше длина селла, тем больше задержка в сети. Далее, чем больше длина селла, тем больше времени у системы на обработку заголовка, что упрощает построение коммутатора, но при этом ему требуется большая память, которая чем больше, тем медленнее. Все дебаты по выбору длины селла вращались вокруг диапазона между 32 и 64 байтами.
На задержку коммутации влияет во многом соотношение между длиной заголовка и длиной поля данных. Эта зависимость представлена на рис.3. Расчеты производились исходя из скорости каналов в 150 Мбит/сек. По оси абсцисс отложено отношение длины поля данных к длине заголовка. Попробуем физически объяснить поведение этих графиков.
При росте длины поля L увеличивается время обслуживания селлов в очереди, т.е. увеличивается задержка. Это происходит потому, что требуется больше времени для считывания данных из очереди и записи в нее. С другой стороны, при очень маленьких значениях L время обработки увеличивается из-за того, что селлов становится очень много, и объем заголовка относительно возрастает, следовательно, возрастает и время обслуживания, поскольку нужно изучить много таких заголовков.
В результате долгих дебатов, когда обсуждалось два предложения - сделать поле данных селла 32 или 64 байта, было принято решение выбрать середину - 48 байт, на которые накладываются еще пять байт заголовка - итого 53 байта.
Рис. 3. Зависимость задержки в очереди от соотношения длин поля данных и заголовка пакета при различных значениях нагрузки
1.4 Процедура обработки заголовка
Уже говорилось, что основной характеристикой АТМ является ограничение функций системы по обработке заголовка. Основой этого является то, что АТМ - это принципиально система, ориентированная на предварительное установление соединения - как и Х.25. Значит, не нужно в каждом селле анализировать адреса абонентов. Каждое соединение, как и в Х.25 идентифицируется уникальным номером. В системе отсутствует защита от ошибок, которая вынесена на процедуру из конца в конец и реализуется в рамках пользовательской службы (если это требуется). Отсутствует также механизм управления потоком. Таким образом, основной функцией заголовка остается только анализ идентификатора виртуального соединения и маршрутизация в соответствии с ним. Для этой цели имеется два раздельных идентификатора - идентификатор виртуального канала (virtual channel identifier - VCI) и идентификатор виртуального пути (virtual path identifier - VPI). При этом VCI определяет динамически создаваемые соединения, а VPI - статически создаваемые. Под идентификатор VCI в формате заголовка отводится 16 бит. Присвоение VCI выполняется на этапе установления соединения, и этот номер, так же, как и логические каналы в системе Х.25, меняются от участка к участку. Может показаться странным: зачем вводить два разных идентификатора для одного и того же соединения. Дело в том, что при проектировании технологии АТМ предполагалось, что в рамках одного сеанса связи можно делать несколько различных соединений. Например, при телевещании по одному VCI можно передавать видеосигнал, а по другому - звук. Можно привести еще множество примеров такого рода. Кроме того, при необходимости можно в рамках одного сеанса устанавливать новые соединения, например, если два абонента во время разговора хотят обменяться факсами или файлами данных. Таким образом, в рамках абонентского соединения можно оперативно создавать и убирать виртуальные каналы, т.е. регулировать пропускную способность. Поэтому VC являются динамическими. Впрочем, процедура динамического создания VC в рамках соединения до сих пор не описана с точки зрения управления. Пока это только теоретическая возможность. Более того, существующие сегодня узлы коммутации устанавливают все свои соединения только по единственному виртуальному пути - VPI=0. Это значит, что фактически для идентификации соединений используется только один идентификатор - номер виртуального канала. Это значит, что между парой абонентов, конечно, можно установить более одного соединения, но с точки зрения сети это будут совершенно не связанные друг с другом соединения. Другими словами, современные узлы коммутации являются коммутаторами VC, а не VP.
На рис. 4 приведен самый общий пример установления виртуального пути между пользователем А и пользователем С, в рамках которого организуется 2 индивидуальных соединения, каждый со своим номером VC. Из рисунка видно, что номер пути и номер канала меняется от участка к участку (как логические каналы в Х.25). Итак, пользователи А и В соединены каналами 1, 2 и 3, а пользователи А и С - каналами 3 и 4. Заметим, что канал №3 присутствует в двух виртуальных путях, однако они не путаются т.к. они относятся к разным виртуальным путям. При едином для всех номере виртуального пути номера виртуальных каналов не могли бы совпадать. Под идентификатор виртуального пути в заголовке селла отводится от 8 до 12 бит, что позволяет создавать на участке до 256 или до 4096 путей, каждый из которых "набирается" из виртуальных каналов.
Рис. 4. Понятие VPI в сети АТМ
Еще одной функцией заголовка является разделение логических соединений по приоритетам. Приоритет означает, что на некоторые селлы допускается большая вероятность потери, чем на остальные. Приоритеты могут задаваться на виртуальный канал, или же на каждый селл в отдельности.
Ясно, что отсутствие приоритетов гарантирует лучшее разделение ресурсов, чем приоритетная система, но не позволяет делать различия между службами с разной чувствительностью к прозрачности сети.
Для функций эксплуатации сети и мониторинга соединений используются несколько дополнительных бит заголовка. Естественно, встает вопрос о разделении информационных селлов и селлов управления. Делается это с помощью специальных битов заголовка, называющихся "идентификатор типа поля данных" - Payload Type Identifier - PTI. С его помощью в абонентский поток данных можно вставлять селлы управления, которые обрабатываются сетью как обычные, но они содержат служебную информацию - например, такой служебный селл может добавляться пользовательской службой на передаче и содержать в себе проверочную последовательность для контроля ошибок предшествующих селлов. Кроме того, они могут содержать всякого рода тестовую информацию.
