2. Принципы синхронизации в АТМ В любой пакетной системе приемник должен иметь возможность определять границы пакета. Например, в системе HDLC, где разрешается прохождение кадров переменной длины, границы кадра задаются с помощью флагов. Для гарантирования того, чтобы не произошло ложное обнаружение границ, вводится процедура бит-стаффинга. Такую же систему можно было бы включить и в сеть АТМ, но на высоких скоростях процедура бит-стаффинга нежелательна. Однако, ввиду постоянства длины селлов, возможны другие механизмы определения границ. Было предложено несколько вариантов такого алгоритма; мы рассмотрим тот, который был принят МККТТ.
Рис. 5. Диаграмма состояний для определения границ селла
На рис. 5 представлена диаграмма состояний приемника в смысле выявления границ селла. Устройство может находиться в одном из трех состояний - синхронизм, предсинхронизм и рассинхронизм. В состоянии рассинхронизма система находится в первоначальный момент времени, когда процесс синхронизации еще не начался, и тогда, когда синхронизм потерян. В этом состоянии приемник просматривает канал на предмет обнаружения правильного селла. Когда он обнаружен, система переходит в состояние предсинхронизма и находится в нем до тех пор, пока не будет выявлено определенное количество правильно принятых подряд селлов, после чего считается, что синхронизм установлен. Переход в состояние рассинхронизма из синхронного состояния происходит в момент, когда границу селла не удалось выявить несколько раз подряд, после чего процесс начинается заново. Как же происходит выявление границы селла? Этот процесс основан на том, что в составе заголовка каждого селла присутствует проверочный байт, с помощью которого осуществляется защита от ошибок бит заголовка, о чем уже говорилось выше. В состоянии рассинхронизма система просматривает входной поток бит за битом, байт за байтом до тех пор, пока не будет обнаружено совпадение проверочной последовательности. Дело в том, что заголовок селла состоит из пяти байт, последний из которых содержит проверочную последовательность. Приемник, записав четыре байта, на основании следующего - пятого оценивает, соответствует ли последовательность в этом пятом байте значению предыдущих четырех. Если соответствует, то это значит, что скорее всего это и есть заголовок селла, т.к. пятый бит является линейной комбинацией первых четырех. В этот момент приемник входит в состояние предсинхронизма. Поскольку известна длина каждого селла - 53 байта, то система отсчитает еще 48 байт и после этого вновь примется анализировать соответствие четырех последующих байт пятому и т.д. Когда такая ситуация произойдет n раз подряд, будет принято решение о том, что синхронизм достигнут и система перейдет в соответствующее состояние. Выход из синхронного состояния происходит в случае, если m раз подряд значение заголовка селла не совпадет со значением проверочного полинома.
Вследствие злонамеренных или непреднамеренных действий может получиться так, что поле информации в селле точно повторяет корректный заголовок, из-за чего период вхождения в синхронизм может сильно увеличиться. Для того, чтобы защититься от этого, в систему на передаче добавляется скремблер, который преобразует информацию пользователя к виду, близкому к псевдослучайной последовательности, т.е. убирает статистическую зависимость бит данных друг от друга.
Таким образом, мы видим, что прямая связь между передатчиком и приемником в смысле синхронности отсутствует - приемник настраивается по входному полезному сигналу. Это значит, что не требуется передача специального синхросигнала от источника до получателя. Этим и объясняется термин "асинхронный" в названии режима передачи.
Разумеется, система не может работать так, чтобы заставлять пользователя все время посылать какую-то информацию. Передатчик всегда имеет возможность остановиться, если передавать больше нечего. Не произойдет ли выход из синхронизма, если нет данных для передачи? Не произойдет, причем за счет того, что передатчик всегда заполняет паузы абонентского трафика специальными "пустыми" селлами, не содержащими полезной информации, но также состоящими из 53 байт с корректным заголовком. Конечно, в поле PTI, о котором недавно говорилось, будет указано на то, что этот селл "пустой" и его не нужно отправлять приемнику.
3. Структура стека протоколов АТМ В начале нашего курса говорилось о том, что модель ВОС очень удачна и широко используется для моделирования всех видов коммуникационных систем. МККТТ в рекомендации I.321 описал логическую иерархию широкополосной системы АТМ, однако в ней приведено только описание нижних уровней. Полностью соответствие АТМ и модели ВОС еще не приведено, поэтому придется ограничиться неофициальным взглядом на это.
Модель предполагает использование концепции нескольких плоскостей для разделения пользовательских функций, функций управления и контроля. Структура такой плоскостной модели приведена на рис. 6 и содержит эти три плоскости: пользовательскую - для передачи абонентской информации, плоскость контроля - для передачи информации сигнализации и плоскость управления - для системы эксплуатации сети и реализации операторских функций. Кроме того добавлено третье измерение в структуре, называемое управлением плоскостями, которое отвечает за управление системой в целом. Впрочем, поскольку технология АТМ находится еще в стадии становления, очень много функций управления до сих пор не стандартизированы.
Рис. 6. Модель стека протоколов в сети АТМ
Как видно из рисунка, каждая плоскость охватывает несколько уровней модели, причем уровни, как и положено, функционируют независимо друг от друга и общаются между собой стандартными протокольными блоками. Взаимосвязь уровней АТМ и уровней модели ВОС пока не описано в МККТТ, но можно умозрительно установить такую взаимосвязь: физический уровень более или менее совпадает по функциям с первым уровнем модели ВОС и занимается обработкой потока бит. Уровень АТМ располагается в нижней части второго уровня стандартной модели. Уровень адаптации АТМ - АТМ adaptation layer - AAL - выполняет задачи приспособления протоколов верхних уровней, неважно, пользовательской или сигнальной информации, к селлам АТМ фиксированной длины. Для плоскости контроля информация сигнализации эквивалентна нижней части второго уровня ВОС, а пользовательская плоскость больше приложима к нижней части транспортного уровня, поскольку адаптация пользовательских данных выполняется из конца в конец между абонентскими установками. Функции системы можно разделить между уровнями АТМ так, как представлено на рис. 7. Физический уровень отвечает за передачу бит/селлов, уровень АТМ занимается коммутацией и маршрутизацией, а также мультиплексированием информации AAL (ATM adaptation layer), который в свою очередь отвечает за привязку пользовательских данных к потоку селлов, причем эта привязка для различных типов служб может делаться по-разному.
Эти три уровня в свою очередь делятся на подуровни, каждый из которых также реализует свои функции.
Рис. 7. Схема функций различных подуровней модели
3.1 Физический уровень Физический уровень состоит из подуровня физической среды и подуровня конвергенции, т.е. "подтягивания" вида передаваемых данных к виду, удобному для передачи по каналам. Подуровень физической среды отвечает за корректную передачу и прием битов по каналу. Иначе говоря, с его помощью осуществляется ввод потока данных в канал связи. Кроме того, этот уровень выполняет битовую синхронизацию на канале (отметим, что битовая синхронизация на канале никак не связана с синхронизацией селлов, о которой говорилось выше - селл может быть выдан в канал в произвольный момент времени, т.е. битовая синхронизация присутствует в любой системе, а кадровая синхронизация может отсутствовать).
Подуровень конвергенции в первую очередь выполняет адаптацию к системе передачи, например, это может быть система 8В/10В или SONET. Это значит, что этот подуровень выполняет функции формирования той информационной структуры, которая соответствует системе передачи. Например, здесь осуществляется вкладывание потока селлов в кадры SONET или 8В/10 и формирование самих этих кадров. На приеме производится изъятие селлов из кадров и кроме того, на этом подуровне осуществляется помехозащита заголовка селлов, соответственно, на нем лежит и функция селловой синхронизации, поскольку, как уже говорилось, она неотделима от системы кодирования заголовка. Помимо синхронизации, здесь также выполняются все функции, связанные с обработкой ошибок в заголовке. Все это означает, что здесь выполняются некоторые функции по формированию селлов - добавление в заголовок проверочного байта.
Раз здесь реализуется синхронизация селлов, то здесь же должен выполняться механизм вставки и изъятия "пустых" селлов, которые, как уже говорилось, нужны для того, чтобы не образовывалось пауз в потоке.
3.2 Уровень АТМ Работа уровня АТМ полностью независима от работы физического уровня, который выдает селлы, проверенные по заголовкам и готовые к маршрутизации. Соответственно, основными функциями уровня АТМ является мультиплексирование потока селлов из разных виртуальных путей в один канал для передачи, необходимые преобразования заголовков, например, переназначение номера виртуального пути при переходе с участка на участок, также выполняются некоторые функции управления на основании поля PTI в заголовке селла, а также формирование и изъятие заголовка.
3.3 Уровень адаптации АТМ Уровень AAL обеспечивает связку сервиса, поставляемого уровнем АТМ с пользовательскими уровнями. На нем лежит реализация функций пользовательской плоскости, плоскости контроля и управления. Поскольку системой могут пользоваться различные службы, то и вариантов реализации уровня AAL также несколько, и они зависят от потребностей служб.
В целом уровень AAL разделяется на два подуровня - подуровень сборки/разборки селлов и подуровень конвергенции ("подтягивания"). Функции подуровня сборки/разборки достаточно прозрачны и состоят в "нарезке" входной информации на части, годные для вставления в селл и обратное преобразование на приеме. Подуровень конвергенции выполняет функции идентификации сообщений, синхронизации абонентских установок (если соответствующая служба этого требует) и т.д. В тех случаях, когда условия работы сети АТМ пользователя устраивают, т.е. не требуется синхронизации абонентских установок и параметры качества сети (задержки и уровень ошибок) пользователя устраивает, этот подуровень может быть пропущен. В настоящее время организациями по стандартизации определено пять способов реализации уровня AAL, каждый из которых предназначен для поддержки своего типа службы.
4. Форматы АТМ На рис.8 представлена структура формата селла АТМ на стыке "пользователь-сеть". Внутрисетевой формат селла показан на рис.9. Как видим, в обоих случаях размер селла остается постоянным - 53 байта, а размер заголовка 5 байт. Различие только в том, что внутри сети в формате отсутствует поле GFC - общее управление потоком. За счет него увеличивается размер поля VPI - вместо 8 байт оно становится равным 12 байт.
Рис. 8. Структура селла АТМ на входе в сеть. GFC - обобщенное управление потоком;
Рис. 9. Структура заголовка селла АТМ на интерфейсе NNI
Поле данных селла, составляющее 48 байт, заполняется на уровне АТМ информацией верхних уровней и в процессе передачи данных никак не анализируется и не изменяется сетью. Заметим, что речь в этом смысле идет только о селлах, содержащих пользовательские данные. Когда идет процесс управления соединением или передача другой служебной информации, например, обмен маршрутными таблицами между узлами, конечно, содержимое селла анализируется, но это уже служебные данные. Уровень АТМ создает заголовок к каждому селлу и добавляет его к пользовательской информации. Соответственно, на приеме заголовок анализируется и отбрасывается. Между селлами в канале нет никаких промежутков или разделительных бит - они следуют друг за другом сплошным потоком.
Поле данных пользователя никак не участвует в работе сети и сейчас нам не интересно.
Поле GFC - общее управление потоком занимает первые 4 бита в первом байте заголовка и предусмотрено для управления потоком на участке между пользователем и сетью. На сегодня его функции спецификациями не определены. В будущем с его помощью планируется более тщательно, чем сегодня управлять потоком данных. Так, сейчас у сети нет никаких способов воздействия на абонента в случаях, когда он работает не по правилам, т.е. нарушает соглашения, установленные в процессе установления соединения. Единственное, что может делать сеть (и она это делает), это отбрасывать селлы в случае, когда скорость передачи данных не соответствует условленной. Напомним, что такое превышение будет чревато для сети тем, что память узлов будет переполняться, что вызовет рост задержек передачи других потоков, а сеть им уже дала свои обязательства по качеству обслуживания.
Когда функция управления потоком будет реализована, то сеть сможет притормаживать абонента с тем, чтобы, хоть и с некоторой задержкой, но передать пользовательские данные, и с тем, чтобы указать абоненту на его неправомочные действия.
4.1 Номера виртуальных каналов и виртуальных путей В предыдущем подразделе мы уже касались назначения полей идентификаторов виртуального пути и виртуального канала.
На стыке с сетью согласно форматам можно установить не более 256 виртуальных путей, каждый из которых может содержать до 65536 виртуальных каналов, что в сумме дает более 16 миллионов соединений. Напомним, что пока работа ведется только по одному виртуальному пути, и, поэтому, число возможных соединений ограничено 65536 соединениями. Внутри сети на каждом межузловом участке может одновременно проходить до 4095 виртуальных путей. Такое расширение может быть нужно, поскольку по одному каналу могут проходить соединения от очень многих абонентов, и 16 миллионов номеров может не хватить. Дело в том, что АТМ планируется как универсальная международная сеть, через которую будет передаваться весь мировой информационный обмен и необходимо заранее предусмотреть резервы. Так, сегодня через международные каналы России проходят многие десятки тысяч разговоров одновременно и это число растет. Поэтому, на этих каналах необходимо будет использовать эту расширенную нумерацию.
Что касается виртуальных каналов, то почти все они используются именно для абонентской передачи за исключением первых 32, которые зарезервированы под передачу сигналов управления различного рода. Каждый вид сигналов управления согласно различным спецификациям должен проходить по строго определенному виртуальному каналу. Назначение некоторых из них показано на рис.10.
С нулевым номером VP и VC проходят так называемые "пустые" селлы. Их назначение в том, чтобы заполнить пропуски в абонентском потоке. Выше говорилось о том, что для целей синхронизации селлы в канале обязательно должны идти подряд без пропусков - иначе собьется механизм определения границ селлов. Но поскольку невозможно заставить абонента на 100% загрузить канал, то оставшиеся проценты загрузки будут заняты этими пустыми селлами, формат которых точно такой же, как и у информационных. Раз их назначение только в заполнении пауз, после прохода через канал они будут уничтожены сразу после приема и никак не повлияют на производительность узла, который таким образом работает только с нужными селлами.
Рис. 10. Зарезервированные номера VPI/VCI
Каналы метасигнализации имеют функцию, связанную с настройкой других каналов сигнализации. В самом деле, далеко не всегда нужно использовать все сигнальные потоки, предусмотренные рекомендацией. Поэтому заранее нельзя сказать, нужно будет их устанавливать или нет. А раз их можно не устанавливать, то они не могут быть образованы автоматически при включении устройства, тем более, что никогда заранее нельзя предсказать, через канал какой пропускной способности они будут проходить. Для того, чтобы можно было установить служебные соединения, служит канал метасигнализации, требующий очень мало пропускной способности, и работающий очень короткое время.
Канал широковещания используется для передачи пользовательских селлов, которые должны быть доставлены всем абонентам на данном интерфейсе.
Для целей управления отдельными соединениями и отдельными виртуальными путями служат два потока сигнализации - поток F4 и поток F5. Поскольку они задают сигнализацию, распространяющуюся только на один путь или канал, то они имеют тот же самый номер пути или канала.
4.2 Типы передаваемых данных Уже говорилось о том, что поле данных пользователя никак не анализируется сетью. Однако, управляющие данные необходимо анализировать. Следовательно возникает вопрос: каким же образом сеть может определить, нужно ей осматривать содержимое селла или нет? Можно, конечно, попытаться всю управляющую информацию вкладывать в специально отведенные для этого виртуальные каналы, которых мы уже коснулись, но в некоторых случаях это неудобно, и, поэтому, приходится вставлять служебные селлы непосредственно в тот же канал, что и абонентские данные. Для отделения этих служебных данных от абонентских в рамках одного и того же виртуального канала служит поле PTI - Payload Type Identifier. Это поле имеет длину 3 бита. Структура его кодирования приведена на рис.11.
Как видно из рисунка, на сегодня используется только 6 типов кодов для поля данных селла и из этих шести четыре связаны с различными типами селлов, содержащих пользовательские данные. Они разделяются по признаку наличия или отсутствия перегрузки, а также по признаку, является ли данный селл конечным в передаваемом сообщении, или содержит продолжение сообщения. Разумеется, признак продолжения или конца сообщения может быть известен только уровню адаптации. Когда селл передается с уровня AAL на уровень АТМ первый указывает на этот признак. В случае, если селл является продолжением сообщения, то в протокольном блоке, который проходит между уровнями в передающем устройстве, указывается признак "type 0". Селл, заканчивающий сообщение содержит признак "type 1", и этот признак type будет включен в состав заголовка селла на уровне АТМ. Таким образом, в составе поля данных этот признак не передается.
Рис. 11. Кодирование поля PTI
На приемной стороне поле данных пользователя оформляется в протокольный блок, который выдается на уровень AAL, и в составе этого протокольного блока будет содержаться соответствующая метка type 0 или type 1. Заметим, что признака "начала сообщения" нет. Этот признак используется только при работе с уровнем адаптации типа AAL 5. Все другие уровни адаптации всегда указывают данные как тип 0.
Помимо признака начала и конца сообщения в составе поля PTI передается также признак уведомления о перегрузке. Этот признак предназначен приемнику и проставляется не источником информации, т.е. не передающим АТМ-уровнем, а тем узлом сети, который отметил у себя наличие перегрузки. Когда приемник получит селл с этим признаком, он в принципе может начать у себя процедуру управления потоком с целью заставить передатчик снизить интенсивность потока данных. Однако, этот механизм, во-первых, никак не может быть подвластен сети, а, во-вторых, он еще не стандартизирован. При этом нет никакой информации о том, где именно на сети произошла перегрузка.
Следующие два значения поля PTI относятся к служебным селлам управления. Ранее уже говорилось, что вся сигнализация и управление проходят по отдельным виртуальным каналам, а здесь этот признак вставляется в состав селлов в рамках того же виртуального канала, что и данные пользователя. Дело в том, что есть один вид управления, который относится к внутриканальной сигнализации, т.е. сигнализации между узлами коммутации и связан с управлением только данным конкретным соединением, поэтому он был включен с состав пользовательского канала. Одно значение поля PTI указывает на управление только между двумя соседними узлами, а другое - из конца в конец. Все это также будет подробно рассмотрено ниже.
4.3 Приоритеты селлов в системе Еще один бит в заголовке указывает на приоритет селла. Если приоритет указан низким, т.е. если этот бит установлен в 1, то это значит, что в случае каких-либо перегрузок в узлах такой селл будет отброшен в первую очередь. При этом возможны два варианта - приоритет своему соединению и, соответственно, всем его селлам назначает пользователь, а второй вариант - сеть сама изменяет приоритет селлам внутри сети. Конечно, нас заинтересует только второй вариант.
Предположим, что некий абонент не совсем правильно выдерживает установленные ранее параметры трафика, т.е. работает с большей скоростью, чем это предполагалось. Сеть это сразу заметит и тем селлам, которые поступили в узел через слишком маленький интервал времени после предыдущего селла (т.е. их частота больше согласованной), снизит приоритет. В принципе, это еще не значит, что такие селлы будут обязательно в сети уничтожены. Если у узла несмотря на превышение согласованной интенсивности имеется достаточно ресурсов, чтобы обслужить такой поток, то этот селл будет передан дальше, хотя и с пониженным приоритетом. Отбрасывание селла произойдет только в том случае, если возникает угроза тому, что сеть не сможет выполнить взятые на себя обязательства - доставлять информацию со строго определенной задержкой. Это может произойти не обязательно в том же узле, который изменил селлу приоритет.
Таким образом, потери данных в сети могут происходить даже, если никаких помех в канале не было. С помощью этого бита в сети реализуется защита от перегрузок.
Последний, пятый байт заголовка селла содержит проверочную последовательность, с помощью которой защищается от ошибок предыдущие 4 байта заголовка. При этом используется код с исправлением ошибок, благодаря чему удается защититься от ошибок, связанных с неправильной маршрутизацией селлов - ведь если поражен заголовок, то скорее всего исказился номер виртуального канала, и селл будет доставлен не по адресу.
Кроме защиты от ошибок с помощью этого байта выполняется процедура выявления границ селлов, как это было описано выше.
Итак, мы видим, что функции обработки заголовков селлов в сети очень ограничены и по сути состоят только в коммутации на основании установленных маршрутов и в контроле за соблюдением установленных параметров соединения. Эту работу можно выполнить очень быстро, и, поэтому, система АТМ может работать на очень высоких скоростях. В принципе, конечно, можно изобрести такие вычислительные системы, которые смогли бы с такой же скоростью обрабатывать и пакеты TCP/IP или Х.25, однако, это не смогло бы заменить технологию АТМ, поскольку никогда нельзя было бы гарантировать постоянство времени передачи данных через сеть, хотя вероятность потерь данных и необнаруженных ошибок была бы весьма низкой. Впрочем, даже в рамках описанной технологии вероятность потерь данных удается удерживать на уровне 10-8, что вполне достаточно для большинства приложений. Могут быть системы, где даже такая вероятность ошибок недопустима, например, в военной области, телемедицине или системе управления космическими объектами, но там придется вводить дополнительную защиту от ошибок уже на пользовательском уровне.
