Программа курса 5

Скачать 0.58 Mb.

Название	Программа курса 5
страница	7/7
Тип	Программа курса

1 2 3 4 5 6 7

Форматы АТМ

На рис.8 представлена структура формата селла АТМ на стыке "пользователь-сеть". Внутрисетевой формат селла показан на рис.9. Как видим, в обоих случаях размер селла остается постоянным - 53 байта, а размер заголовка 5 байт. Различие только в том, что внутри сети в формате отсутствует поле GFC - общее управление потоком. За счет него увеличивается размер поля VPI - вместо 8 байт оно становится равным 12 байт.

Рис. 8. Структура селла АТМ на входе в сеть. GFC - обобщенное управление потоком;

Рис. 9. Структура заголовка селла АТМ на интерфейсе NNI

Поле данных селла, составляющее 48 байт, заполняется на уровне АТМ информацией верхних уровней и в процессе передачи данных никак не анализируется и не изменяется сетью. Заметим, что речь в этом смысле идет только о селлах, содержащих пользовательские данные. Когда идет процесс управления соединением или передача другой служебной информации, например, обмен маршрутными таблицами между узлами, конечно, содержимое селла анализируется, но это уже служебные данные. Уровень АТМ создает заголовок к каждому селлу и добавляет его к пользовательской информации. Соответственно, на приеме заголовок анализируется и отбрасывается. Между селлами в канале нет никаких промежутков или разделительных бит - они следуют друг за другом сплошным потоком.

Поле данных пользователя никак не участвует в работе сети и сейчас нам не интересно.

Поле GFC - общее управление потоком занимает первые 4 бита в первом байте заголовка и предусмотрено для управления потоком на участке между пользователем и сетью. На сегодня его функции спецификациями не определены. В будущем с его помощью планируется более тщательно, чем сегодня управлять потоком данных. Так, сейчас у сети нет никаких способов воздействия на абонента в случаях, когда он работает не по правилам, т.е. нарушает соглашения, установленные в процессе установления соединения. Единственное, что может делать сеть (и она это делает), это отбрасывать селлы в случае, когда скорость передачи данных не соответствует условленной. Напомним, что такое превышение будет чревато для сети тем, что память узлов будет переполняться, что вызовет рост задержек передачи других потоков, а сеть им уже дала свои обязательства по качеству обслуживания.

Когда функция управления потоком будет реализована, то сеть сможет притормаживать абонента с тем, чтобы, хоть и с некоторой задержкой, но передать пользовательские данные, и с тем, чтобы указать абоненту на его неправомочные действия.

Номера виртуальных каналов и виртуальных путей

В предыдущем подразделе мы уже касались назначения полей идентификаторов виртуального пути и виртуального канала.

На стыке с сетью согласно форматам можно установить не более 256 виртуальных путей, каждый из которых может содержать до 65536 виртуальных каналов, что в сумме дает более 16 миллионов соединений. Напомним, что пока работа ведется только по одному виртуальному пути, и, поэтому, число возможных соединений ограничено 65536 соединениями. Внутри сети на каждом межузловом участке может одновременно проходить до 4095 виртуальных путей. Такое расширение может быть нужно, поскольку по одному каналу могут проходить соединения от очень многих абонентов, и 16 миллионов номеров может не хватить. Дело в том, что АТМ планируется как универсальная международная сеть, через которую будет передаваться весь мировой информационный обмен и необходимо заранее предусмотреть резервы. Так, сегодня через международные каналы России проходят многие десятки тысяч разговоров одновременно и это число растет. Поэтому, на этих каналах необходимо будет использовать эту расширенную нумерацию.

Что касается виртуальных каналов, то почти все они используются именно для абонентской передачи за исключением первых 32, которые зарезервированы под передачу сигналов управления различного рода. Каждый вид сигналов управления согласно различным спецификациям должен проходить по строго определенному виртуальному каналу. Назначение некоторых из них показано на рис.10.

С нулевым номером VP и VC проходят так называемые "пустые" селлы. Их назначение в том, чтобы заполнить пропуски в абонентском потоке. Выше говорилось о том, что для целей синхронизации селлы в канале обязательно должны идти подряд без пропусков - иначе собьется механизм определения границ селлов. Но поскольку невозможно заставить абонента на 100% загрузить канал, то оставшиеся проценты загрузки будут заняты этими пустыми селлами, формат которых точно такой же, как и у информационных. Раз их назначение только в заполнении пауз, после прохода через канал они будут уничтожены сразу после приема и никак не повлияют на производительность узла, который таким образом работает только с нужными селлами.

Рис. 10. Зарезервированные номера VPI/VCI

Каналы метасигнализации имеют функцию, связанную с настройкой других каналов сигнализации. В самом деле, далеко не всегда нужно использовать все сигнальные потоки, предусмотренные рекомендацией. Поэтому заранее нельзя сказать, нужно будет их устанавливать или нет. А раз их можно не устанавливать, то они не могут быть образованы автоматически при включении устройства, тем более, что никогда заранее нельзя предсказать, через канал какой пропускной способности они будут проходить. Для того, чтобы можно было установить служебные соединения, служит канал метасигнализации, требующий очень мало пропускной способности, и работающий очень короткое время.

Канал широковещания используется для передачи пользовательских селлов, которые должны быть доставлены всем абонентам на данном интерфейсе.

Для целей управления отдельными соединениями и отдельными виртуальными путями служат два потока сигнализации - поток F4 и поток F5. Поскольку они задают сигнализацию, распространяющуюся только на один путь или канал, то они имеют тот же самый номер пути или канала.

Типы передаваемых данных

Уже говорилось о том, что поле данных пользователя никак не анализируется сетью. Однако, управляющие данные необходимо анализировать. Следовательно возникает вопрос: каким же образом сеть может определить, нужно ей осматривать содержимое селла или нет? Можно, конечно, попытаться всю управляющую информацию вкладывать в специально отведенные для этого виртуальные каналы, которых мы уже коснулись, но в некоторых случаях это неудобно, и, поэтому, приходится вставлять служебные селлы непосредственно в тот же канал, что и абонентские данные. Для отделения этих служебных данных от абонентских в рамках одного и того же виртуального канала служит поле 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 указывает на управление только между двумя соседними узлами, а другое - из конца в конец. Все это также будет подробно рассмотрено ниже.

Приоритеты селлов в системе

Еще один бит в заголовке указывает на приоритет селла. Если приоритет указан низким, т.е. если этот бит установлен в 1, то это значит, что в случае каких-либо перегрузок в узлах такой селл будет отброшен в первую очередь. При этом возможны два варианта - приоритет своему соединению и, соответственно, всем его селлам назначает пользователь, а второй вариант - сеть сама изменяет приоритет селлам внутри сети. Конечно, нас заинтересует только второй вариант.

Предположим, что некий абонент не совсем правильно выдерживает установленные ранее параметры трафика, т.е. работает с большей скоростью, чем это предполагалось. Сеть это сразу заметит и тем селлам, которые поступили в узел через слишком маленький интервал времени после предыдущего селла (т.е. их частота больше согласованной), снизит приоритет. В принципе, это еще не значит, что такие селлы будут обязательно в сети уничтожены. Если у узла несмотря на превышение согласованной интенсивности имеется достаточно ресурсов, чтобы обслужить такой поток, то этот селл будет передан дальше, хотя и с пониженным приоритетом. Отбрасывание селла произойдет только в том случае, если возникает угроза тому, что сеть не сможет выполнить взятые на себя обязательства - доставлять информацию со строго определенной задержкой. Это может произойти не обязательно в том же узле, который изменил селлу приоритет.

Таким образом, потери данных в сети могут происходить даже, если никаких помех в канале не было. С помощью этого бита в сети реализуется защита от перегрузок.

Последний, пятый байт заголовка селла содержит проверочную последовательность, с помощью которой защищается от ошибок предыдущие 4 байта заголовка. При этом используется код с исправлением ошибок, благодаря чему удается защититься от ошибок, связанных с неправильной маршрутизацией селлов - ведь если поражен заголовок, то скорее всего исказился номер виртуального канала, и селл будет доставлен не по адресу.

Кроме защиты от ошибок с помощью этого байта выполняется процедура выявления границ селлов, как это было описано выше.

Итак, мы видим, что функции обработки заголовков селлов в сети очень ограничены и по сути состоят только в коммутации на основании установленных маршрутов и в контроле за соблюдением установленных параметров соединения. Эту работу можно выполнить очень быстро, и, поэтому, система АТМ может работать на очень высоких скоростях. В принципе, конечно, можно изобрести такие вычислительные системы, которые смогли бы с такой же скоростью обрабатывать и пакеты TCP/IP или Х.25, однако, это не смогло бы заменить технологию АТМ, поскольку никогда нельзя было бы гарантировать постоянство времени передачи данных через сеть, хотя вероятность потерь данных и необнаруженных ошибок была бы весьма низкой. Впрочем, даже в рамках описанной технологии вероятность потерь данных удается удерживать на уровне 10-8, что вполне достаточно для большинства приложений. Могут быть системы, где даже такая вероятность ошибок недопустима, например, в военной области, телемедицине или системе управления космическими объектами, но там придется вводить дополнительную защиту от ошибок уже на пользовательском уровне.