ATM

Сервер

Сегодня для всех организаций вопросы стандартизации играют немалую роль. Не остаются в стороне от этого процесса и вопросы стандартизации сетевых решений.

Корпоративные сетевые стандарты позволяют обеспечить эффективное взаимодействие всех станций сети за счет использования одинаковых версий программ и однотипной конфигурации. Однако, значительные сложности возникают при унификации технологии доступа рабочих станций к WAN-сервису, поскольку в этом случае происходит преобразование данных из формата token ring или Ethernet в форматы типа X.25 или T1/E1. ATM обеспечивает связь между станциями одной сети или передачу данных через WAN-сети без изменения формата ячеек - технология ATM является универсальным решением для ЛВС и телекоммуникаций.

Нет сомнений в том, что скоростные технологии ЛВС являются основой современных сетей. ATM, FDDI и Fast Ethernet являются основными вариантами для организация сетей с учетом перспективы. Очевидно, что приложениям multimedia, системам обработки изображений, CAD/CAM, Internet и др. требуется широкополосный доступ в сеть с рабочих станций. Все современные технологии обеспечивают высокую скорость доступа для рабочих станций, но только ATM обеспечивает эффективную связь между локальными и WAN-сетями.

ATM - история и базовые принципы

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

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

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

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

ATM решает эту проблему за счет деления информации любого типа на небольшие ячейки фиксированной длины. Ячейка ATM имеет размер 53 байта, пять из которых составляют заголовок, оставшиеся 48 - собственно информацию. В сетях ATM данные должны вводиться в форме ячеек или преобразовываться в ячейки с помощью функций адаптации. Сети ATM состоят из коммутаторов, соединенных транковыми каналами ATM. Краевые коммутаторы, к которым подключаются пользовательские устройства, обеспечивают функции адаптации, если ATM не используется вплоть до пользовательских станций. Другие коммутаторы, расположенные в центре сети, обеспечивают перенос ячеек, разделение транков и распределение потоков данных. В точке приема функции адаптации восстанавливают из ячеек исходный поток данных и передают его устройству-получателю, как показано на рисунке 4.1.

Рисунок 4.1 Адаптация ATM

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

Пусть два устройства передают в сеть ATM данные, срочность доставки которых различается (например, голос и трафик ЛВС). Сначала каждый из отправителей делит передаваемые данные на ячейки. Даже после того, как данные от одного из отправителей будут приниматься в сеть, они могут чередоваться с более срочной информацией. Чередование может осуществляться на уровне целых ячеек и малые размеры последних обеспечивают в любом случае непродолжительную задержку.




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

Даже при чередовании и приоритизации ячеек в сетях ATM могут наступать ситуации насыщения пропускной способности. Для сохранения минимальной задержки даже в таких случаях ATM может отбрасывать отдельные ячейки при насыщении. Реализация стратегии отбрасывания ячеек зависит от производителя оборудования ATM, но в общем случае обычно отбрасываются ячейки с низким приоритетом (например, данные) для которых достаточно просто повторить передачу без потери информации. Коммутаторы ATM с расширенными функциями могут при отбрасывании ячеек, являющихся частью большого пакета, обеспечить отбрасывание и оставшихся ячеек из этого пакета - такой подход позволяет дополнительно снизить уровень насыщения и избавиться от излишнего объема повторной передачи. Правила отбрасывания ячеек, задержки данных и т.п. определяются набором параметров, называемым качеством обслуживания (Quality of Service) или QoS. Разным приложениям требуется различный уровень QoS и ATM может обеспечить этот уровень.

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

В заголовке ATM виртуальный канал обозначается комбинацией двух полей - VPI (идентификатор виртуального пути) и VCI (идентификатор виртуального канала.


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

Поскольку виртуальные устройства подобны реальным, они также могут быть "выделенными" или "коммутируемыми". В сетях ATM "выделенные" соединения называются постоянными виртуальными устройствами (PVC), создаваемыми по соглашению между пользователем и оператором (подобно выделенной телефонной линии). Коммутируемые соединения ATM используют коммутируемые виртуальные устройства (SVC), которые устанавливаются путем передачи специальных сигналов между пользователем и сетью. Протокол, используемый ATM для управления виртуальными устройствами подобен протоколу ISDN. Вариант для ISDN описан в стандарте Q.931, ATM - в Q.2931.

Виртуальные устройства ATM поддерживаются за счет мультиплексирования трафика, что существенно снижает расходы на организацию и поддержку магистральных сетей. если в одном из виртуальных устройств уровень трафика невысок, другое устройство может использовать часть свободных возможностей. За счет этого обеспечивается высокий уровень эффективности использования пропускной способности ATM и снижаются цены. Небольшие ячейки фиксированной длины позволяют сетям ATM обеспечить быструю передачу критичного к задержкам трафика (например, голосового). Кроме того, фиксированный размер ячеек обеспечивает практически постоянную задержку, позволяя эмулировать устройства с фиксированной скоростью передачи типа T1E1. Фактически, ATM может эмулировать все существующие сегодня типы сервиса и обеспечивать новые услуги. ATM обеспечивает несколько классов обслуживания, каждый из которых имеет свою спецификацию QoS.

Класс QoSКласс обслуживанияОписание

1	A	производительность частных цифровых линий (эмуляция устройств или CBR)
2	B	пакетные аудио/видео-конференции и multimedia (rt-VBR)
3	C	ориентированные на соединения протоколы типа frame relay (nrt-VBR)
4	D	протоколы без организации соединений типа IP, эмуляция ЛВС (ABR)
5	Unspecified	наилучшие возможности в соответствии с определением оператора (UBR)

Большая часть трафика, передаваемого через сети ATM использует класс обслуживания C, X или Y. Класс C определяет параметры QoS (качество обслуживания) для задержки и вероятности отбрасывания, но требует от пользователя аккуратного управления трафиком во избежание перенасыщения сети. трафик класса X дает пользователю большую свободу, но может не обеспечить стабильной производительности. Класс Y, называемый также "Available Bit Rate" (ABR или доступная скорость) позволяет пользователю и сети установить совместно скорость на основе оценки потребностей пользователя и возможностей сети.

ATM как современная инфраструктура

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

На рисунках , и показан типичный пользовательский сайт с устройствами, порождающими разнотипный трафик (голос, видео, данные). Эти три типа трафика могут передаваться с использованием сервиса ATM тремя показанными на рисунках способами.

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

Рисунок 4.2 Преобразование в ATM осуществляется оператором

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

Рисунок 4.3 Преобразование в ATM осуществляется у пользователя

3. Устройства оборудуются собственными интерфейсами ATM. Одно устройство доступа позволяет объединить весь пользовательский трафик в одном транке, связанном с сетью оператора. В этом случае на стороне пользователя устанавливается принадлежащее ему оборудование ATM, которое можно использовать для организации магистралей ЛВС или подключения настольных станций.

Рисунок 4.4 Сеть на базе ATM

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

Стандарт, определяющий интерфейс между операторами и пользователями ATM называется Public User Network Interface или Public UNI. Этот интерфейс определяется для различных значений скорости. Первые услуги ATM предлагались в основном со скоростью T3 (45 Мбит/с). Сейчас многие операторы предлагают скорость 155 Мбит/с и выше, но такая полоса обычно не требуется пользователям, да и стоимость подобных услуг весьма высока. Для большинства пользователей, планирующих организовать доступ к ATM или создать частную сеть ATM основной проблемой является стоимость оборудования.

Форум ATM - организация производителей оборудования ATM и пользователей работает в направлении развития стандартов и обеспечения интероперабельности оборудования. В конечном итоге это не может не привести к снижению цен. Кроме обеспечения интероперабельности ATM ведется большая работа по реализации ATM на скоростях меньше T3. Здесь возможно несколько вариантов:

Полнофункциональные решения ATM при скорости T1. Один стандарт для ATM T1 уже утвержден, но некоторые производители и пользователи считают, что связанные с реализацией этого стандарта накладные расходы слишком велики - канал T1 с полосой 1.544 Мбит/с может обеспечить полезную полосу только около 1.1 Мбит/с.

Так называемый dixie-стандарт (от акронима DXI - Data eXchange Interface). DXI был разработан как способ использования ATM в кадровом режиме с маршрутизаторами и другими устройствами передачи данных и специальными устройствами DSU, обеспечивающими преобразование кадров в реальные ячейки ATM. DXI работает через стандартные интерфейсы типа V.35 и HSSI.

Интерфейс пользователь - сеть Frame Relay или F-UNI (произностися как FOONY), являющийся стандартом использования frame relay для доставки "кадров данных ATM" в сеть, которая будет конвертировать их в ячейки непосредственно на границе сети.



Инверсное мультиплексирование ATM или AIM - стандарт для инверсного мультиплексирования множества линий T1 в один транк с полосой между T1 и T3. Такая полоса обеспечивает поддержку ATM для приложений, где скоростные запросы незначительно превышают возможности T1.

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

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

Рисунок 4.5 Многосвязная сеть

В многосвязной (каждый с каждым) сети ATM существует меньше транзитных точек, снижающих производительность и вносящих дополнительные задержки и насыщение. Такое решение обеспечивает существенное повышение стабильности работы приложений. Более того, каждый коммутатор является соседом для всех остальных коммутаторов и связан с ними напрямую. Это упрощает задачу динамического определения маршрута для протоколов маршрутизации типа RIP, используемого TCP/IP или NetWare, OSPF или IS-IS.Эти протоколы часто генерируют значительный трафик и могут существенно замедлить сеть при обмене конфигурационными данными (интервал сближения или конвергенции).

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

ATM как технология ЛВС

Технология ATM изначально создавалась как часть сервиса "Broadband ISDN" под эгидой CCITT (сейчас ITU). Однако возможности ATM можно эффективно использовать и в локальных сетях.

Современные крупные сети используются для передачи самых разных типов данных, включая изображения, звук, CAD/CAM и т.п. Несмотря на то, что большинство компьютерных приложений используется уже достаточно давно, возможности современных настольных компьютеров позволяют по новому подойти к организации работы. Однако, рост возможностей настольных компьютеров существенно опережает расширение сетевых возможностей (в частности, пропускной способности сетей).

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

Преимущества ATM не ограничиваются вертикальным рынком. Сегодня организации могут связать через магистрали ATM свои корпоративные серверы. Можно ожидать и достаточно широкого использования ATM в настольных компьютерах при работе пользователей с большими объемами данных или использовании критичных к задержкам приложений.

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

ATM позволяет не только организовать ЛВС, но может обеспечить передачу голосового и видео-трафика. Такое решение позволяет использовать настольные системы видеоконференций и приложения multimedia.

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

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

Функции подуровня сборки/разборки

В функции подуровня SAR входит прием от подуровня конвергенции протокольных блоков произвольной длины и нарезка из него протокольных блоков, содержащих 44 байта данных для передачи на уровень АТМ. Как видим, эти функции сильно отличаются от тех, которые определены в AAL 1. Конечно, его работа состоит не только в том, чтобы формировать короткие блоки из более длинных. Более детально его работа состоит в следующем:

Поскольку от подуровня конвергенции приходит большая порция информации, подуровню SAR нужно следить за тем, чтобы на приеме можно было бы из маленьких блоков по 44 байта собрать снова большой блок данных. Таким образом, ему нужно обеспечивать сохранность передаваемых данных. Это делается при помощи двух специальных полей в заголовке протокольного блока, изображенного на рис.11 - поля индикатора типа сегмента - Segment Type - ST и указателя длины полезной нагрузки - Length Indicator - LI. Указатель LI показывает число пользовательских байт в составе блока. Поле ST указывает, является ли этот блок началом, серединой, концом сообщения или односегментным сообщением - всего 4 значения. Как видим, эти поля такие же, как и в уровне AAL 2, и это связано с тем, что там также необходимо было выполнять функцию сохранности блоков. Заметим, что в системе AAL 1 этого делать было не нужно, поскольку информация передавалась в потоке, у которого нет начала и нет конца, и, поэтому, все протокольные блоки полностью заняты информацией, которая не разбита пользователем на блоки. Поле ST состоит из двух бит, поле LI - из 6 бит.

Если оказывается, что блок данных, помеченный как "продолжение сообщения" или "конец сообщения" появился на приеме раньше, чем блок в пометкой "начало сообщения", то система будет считать, что начало сообщения потеряно в сети, а принятый блок отбросит. Поскольку в системе применяется режим гарантированной доставки, то для этого нужно вводить функции обнаружения ошибок. Заметим, что именно обнаружения, а не исправления, поскольку исправление будет реализовано с помощью повторных передач ошибочных блоков.
Понятно, что в системах AAL 1 и AAL 2 этого было сделать нельзя, поскольку тогда сбилась бы синхронизация обмена между отправителем и получателем. Даже, если от системы не требуется защита от ошибок (режим негарантированных операций), то все равно обнаружение ошибок необходимо, поскольку нужно уведомлять пользователя о наличии ошибки. Эта функция реализуется с помощью поля CRC, содержащего проверочный полином. Если на приеме обнаруживается, что блок данных поражен ошибкой, то он просто отбрасывается. Гарантия целостности последовательности блоков в подуровне SAR обеспечивается с помощью последовательной нумерации протокольных блоков. Для этой цели служит поле порядкового номера - Sequence Number - SN. Его смысл точно такой же, как и у ранее описанных уровней AAL. Разница только в том, что здесь под это поле отведено 4 бита. Кроме того, если в AAL 1 порядковая нумерация протокольных блоков SAR использовалась для циклической нумерации в общем потоке данных, то здесь нумерация идет только в пределах одного сервисного блока, пришедшего от подуровня конвергенции. Таким образом, когда сервисный блок данных поступает на вход подуровня SAR и разбивается на протокольные блоки по 44 байта, то каждому такому протокольному блоку присваивается номер в диапазоне от 0 до 15. Следующий сервисный блок будет нумероваться отдельно. Заметим, что счетчик, согласно которому будут нумероваться протокольные блоки, не обязательно должен сбрасываться в ноль перед нумерованием первого. Если на приеме обнаруживается сбой в нумерации, то блок с неправильным номером отбрасывается и приемник больше никаких протокольных блоков, принадлежащих тому же сервисному блоку ожидать не будет. Значит, в целях защиты от ошибок придется повторно передавать весь сервисный блок. В процедуре предусмотрена возможность объединения нескольких соединений уровня AAL 3/4 в одно соединение АТМ. Значит, на приеме необходимо как-то разбираться в том, какие протокольные блоки к каким соединениям AAL относятся. Выше уже описывался пример, для чего это может использоваться.


Это разделение выполняется с помощью специального поля идентификации мультиплексирования - Multiplexing Identifier - MID, который сообщается в подуровень SAR от системы управления. В результате, если в один подуровень SAR вкладываются несколько подуровней конвергенции, то поток от каждого подуровня конвергенции будет снабжаться своим идентификатором MID. Это поле также присутствует в заголовке протокольного блока подуровня SAR и составляет 10 бит (см. рис. 11). Таким образом, теоретически в одно соединение АТМ можно заложить до 1024 соединений AAL 3/4, правда конкретное устройство вовсе не обязано поддерживать весь этот диапазон.

Рис. 11. Формат SAR-PDU в AAL типа 3/4

Раз несколько соединений может проходить одновременно, то в общий канал они будут выдаваться в перемешанном порядке. Следовательно, на приеме протокольные блоки SAR также будут перемешаны, однако вся обработка происходит только в пределах общего номера MID. Разумеется, что поскольку для всех соединений AAL используется одно и то же соединение АТМ, то параметры качества сервиса у них будут одинаковы.

Таким образом, мы видим, что функции сборки/разборки на уровне AAL 3/4 достаточно обширны, и почти все они связаны с контролем правильности доставки информации, хотя, собственно исправления ошибок здесь не производится. В случае обнаружения каких-либо сбоев - сбой в нумерации протокольных блоков, потеря блоков, помеченных как начало или конец сообщения или просто обнаружена ошибка в составе блока, то ничего не делается для исправления или переспроса поврежденной информации. Эти функции вынесены на подуровень конвергенции.

Функционирование МРОА-устройств

Для взаимодействия всех устройств МРОА спецификацией предусмотрен целый набор служебных потоков, которые нужны, во-первых, для распознавания друг друга, а, во-вторых, для обмена служебной информацией в процессе работы. Так, МРС и MPS обнаруживают друг друга с помощью сервера LECS, т.е. при настройке LANE. Значит, в эту настройку должны быть включены параметры МРОА, конкретно, имена устройств, их типы и АТМ-адреса. Если вспомнить, что говорилось в предыдущем разделе, то там на этот счет ничего сказано не было. Это было потому, что там описывалась первая версия LANE - 1.0. Для работы МРОА требуется следующая версия - 2.0. Отличия ее от версии 1.0 состоят в наличии набора дополнительных параметров настройки, в частности для МРОА.

Управляющие потоки между клиентом и сервером используются для управления внутренними таблицами - Cache Management. Процедуры запросов и ответов позволят клиенту-отправителю - Ingress МРС - устанавливать прямое соединение, а клиенту-получателю -Egress МРС - получить необходимые параметры для преобразований кадров перед выдачей их в свою подсеть. Кроме того, с помощью служебных потоков клиент-получатель или сервер может послать очищающее сообщение - Purge message - в случае, если он обнаружил, что содержимое внутренней таблицы перестало соответствовать реальной ситуации на сети.

Служебные потоки между серверами несут в себе информацию для работы процедуры маршрутизации и для работы протокола NHRP - Next Hop Resolution Protocol. Этот последний, как уже говорилось служит для определения пути между серверами через сеть АТМ.

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

Эволюция

Большинство организаций входят в одну из трех категорий с точки зрения перспектив использования ATM:

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

Организации, которые могут перейти на ATM в результате агрессивной ценовой политики поставщиков услуг.

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

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

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

Организации с "оборонной" стратегией, отмеченные в категории три, могут счесть наличие транкового порта ATM в коммутаторе достаточной для ближайших перспектив использования ATM (использовать не будем, но на всякий случай возьмем).

Компании, планирующие для ATM ключевую роль в своей сети, должны выбирать коммутаторы с портами ATM для подключения настольных станций. ATM обеспечивает широкий диапазон скоростей для подключения настольных станций - от 25 до 155 Мбит/с. ATM25 работает с кабельными системами категории 3 - 5 и может использоваться вместо token ring или 10BaseT для станций с высоким уровнем сетевых запросов.

Снижение цен на оборудование ATM для настольных станций играет важную роль, поскольку сегодня приложений, не способных обойтись без возможностей ATM, еще не так много. Скорей всего, пользователи первых станций ATM будут работать с одним из рассмотренных выше вариантов эмуляции ЛВС и большинство приложений будут скорее использовать эмуляцию, нежели естественные ATM API. Адаптеры ATM и коммутационные технологии должны удовлетворять потребности пользователей в течение 5 -8 лет, а скорость отказа от традиционных технологий ЛВС будет в значительной мере определяться темпами расширения числа видеоприложений.

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

Если вы предполагаете начать использование ATM в настольных станциях в течение ближайшей пары лет, вам нужно выбирать коммутаторы с учетом этой перспективы. Коммутаторы должны иметь порты для подключения станций и магистральны порты 155 и 622 Мбит/с для соединения коммутаторов. Порты ATM должны поддерживать эмуляцию ЛВС. Важно также обратить внимание на перспективы реализации в коммутаторах поддержки таких протоколов, как RFC 1577 и MPOA. наконец, транковый интерфейс для связи с другими коммутаторами должен поддерживать стандарт PNNI.

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


Остается ответить на вопрос "Какой тип ATM-сервиса использовать?"

Публичные или частные системы ATM будут нормально поддерживать подключение устройств frame relay через специальные преобразователи (ATM DSU/CSU). Если ваше соглашение с оператором ATM требует покупки такого оборудования для подключения других источников трафика к ATM, может оказаться более эффективной реализация сервиса frame relay на базе существующих коммутаторов и их связь с ATM через краевые устройства.

Если для подключения связывающих сети устройств (типа маршрутизаторов) к ATM вам потребуется покупать дополнительные устройства, лучше будет купить интерфейс ATM для коммутатора. Этот интерфейс можно будет использовать и после перехода на ATM, тогда как устройства DSU/CSU после такого перехода станут просто ненужными. Существует три варианта подключения ATM к коммутаторам:

Естественная форма ATM (ячейки) с прямым подключением цифрового транка ATM (обычно T1 или T3) к маршрутизатору. Этот тип интерфейса может поддерживать все типы сервиса ATM (включая multimedia). Такой вариант целесообразно выбирать при планировании перехода от маршрутизаторов к коммутаторам ATM.

DXI-форма ATM - интерфейс на основе кадров, поддерживающий только транспортный сервис ATM, ориентированный на передачу данных. Такой тип подключения хорош для систем, где не планируется замена маршрутизаторов на коммутаторы ATM. Выбирая этот вариант, следует помнить, что некоторые операторы ATM не поддерживают DXI-сервис и может потребоваться покупка ATM DSU/CSU для преобразования DXI в ячейки ATM.

Интерфейс F-UNI, который представляет собой вариант интерфейса frame relay с поддержкой сигнализации ATM. Этот вариант пока распространен недостаточно широко, но может обеспечить просто и недорогой переход для маршрутизаторов, которые уже поддерживают frame relay.

При любом варианте перехода на ATM в первую очередь возникает задача организации магистралей. Организация компактных магистралей (collapsed backbone) без использования технологии ATM в таком случае будет весьма рискованным решением.


Магистральные технологии при переходе на ATM приходится менять в первую очередь. Наиболее критичным при переходе на ATM будет первый шаг в сторону от традиционной коммутации ЛВС. В системах коммутации ЛВС без ATM-транков магистрали не используют технологии ATM и, следовательно, модернизация магистралей будет достаточно рискованным шагом. В идеальном случае коммутаторы ЛВС должны поддерживать магистрали ATM и других типов (например, FDDI).

Переход приложений на ATM будет постепенным. На настольных станциях ATM будет поначалу использоваться для эмуляции ЛВС и работы с набором традиционных приложений ЛВС. По мере расширения инфраструктуры ATM станет возможным связать большие группы пользователей в "чистые" сети ATM. Это позволит использовать специальные приложения, рассчитанные на качество обслуживания ATM (видео, multimedia и т.п.) или упростить работу с традиционными потоками данных за счет более высокой производительности ATM.

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

В долгосрочной перспективе ATM должна стать единой архитектурой внутрикорпоративных и межкорпоративных коммуникаций. Коммутируемые виртуальные устройства, используемые настольными системами могут быть расширены за счет поддержки соединений SVC операторами публичных сетей, делая ATM универсальной технологией multimedia-сетей. Протоколы типа NHRP являются средством обеспечения универсальной связи, но в конечном итоге набор протоколов ATM для multimedia будет, по-видимому, основан на службах каталогов.

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

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

Приведенная в документе техническая информация может быть изменена без предупреждения.
© 1997 Xylan Corporation.
Перевод на русский язык © 1998, BiLiM Systems Ltd.

Обработка ошибочных данных

1.2.3. Обработка ошибочных данных

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

В рекомендации описана процедура восстановления данных при обслуживании однонаправленного видеосервиса, т.е. для системы, где требуется высокое качество и нет возможности запросить повторную передачу. Метод основан на применении ошибкоисправляющих кодов. Используемые в спецификации коды позволяют исправлять до двух искаженных байт или четырех "затертых" байт. Затертым является байт с ошибкой, положение которого в теле блока точно известно. Однако, если просто добавлять в каждый блок данных проверочную последовательность, то никак не возможно будет исправить ошибки, связанные с потерей селлов - ведь вместе с данными потеряется и проверочная последовательность. Поэтому используется двумерное кодирование, проиллюстрированное на рис.6.

Рис. 6. Формат матрицы чередований

В системе на передаче организована матрица, куда будут записываться данные пользователя. Матрица содержит 47 строк и 128 столбцов. Данные от пользователя записываются, группируются по 124 байта, и к ним добавляется еще 4 байта проверочной последовательности. Получившиеся 128 байт записываются в строку матрицы. Таким образом, данные от абонента последовательно записываются в матрицу строка за строкой. Всего в матрицу будет записано 128*47=6016 байт - из них потом получится 128 селлов (заметим, что размер столбца матрицы соответствует размеру поля данных, подаваемого на уровень сборки/разборки).

Данные из матрицы считываются столбец за столбцом и каждый столбец будет затем занесен в отдельный селл АТМ. Следовательно, последовательность данных в канале вовсе не будет соответствовать последовательности, принятой от источника - восстановление произойдет на приеме.

В результате, если произойдет потеря одного селла, который будет заменен на приеме фиктивными данными, содержащими только "1", то эта потеря в матрице "расползется" по всем строкам: ведь данные в канал считывались по столбцам и поэтому все байты в столбце относились к разным строкам. Вспомним, что кодозащита вводилась на каждую строку и поэтому этот "фиктивный" байт в каждом селле можно будет исправить, тем более, что положение ошибочного байта в строке точно известно.

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

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

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

Таких ошибок можно обнаружить не более двух.

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

Конечно, все это дается не даром. Так, во-первых, вносится дополнительная избыточность, которая будет составлять 3.1%, а, во-вторых, довольно большая начальная задержка, которая требуется для заполнения матрицы. Правда, эта задержка вносится только в первый момент в начале соединения.

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

Общее назначение MPOA

Передача данных между подсетями типа IP, IPX или AppleTalk требуют, как известно, наличия маршрутизаторов на границах этих сетей, причем имеются в виду не административные границы и не границы между сетями различного типа, а границы между различными структурами сетевых адресов. Их самое общее назначение - это определение направления дальнейшей передачи пакетов, т.е. точки применения протоколов сетевого уровня. Такие подсети строятся, как правило, на базе технологий локальных сетей, из которых наиболее популярными являются Ethernet и Token Ring, и, кроме того, на базе WAN технологий при работе по магистральным каналам. Наиболее популярными из них являются рассмотренные нами выше системы HDLC, Frame Relay или Х.25. Теперь к ним добавилась также технология ATM, и описанный нами в предыдущем разделе режим LAN Emulation является примером ее использования.

Система LANE, как мы поняли, обеспечивает эмуляцию сервиса локальных сетей типа Ether-net или Token Ring при передаче данных через сеть ATM и при этом не имеет значения, какой конкретно тип сетевого протокола применяется - для ATM решительно все равно, передается ли через LANE трафик IP или IPX или AppleTalk или что-то еще. Иначе говоря, вся работа замыкается в рамках одной подсети без участия маршрутизаторов - ведь именно они должны разбираться в конкретных протоколах третьего уровня. При этом каждое оконечное ATM устройство может поддерживать более одной ELAN одновременно. Используемые в конкретной схеме сетевые протоколы не будут замечать, что между роутерами используется ATM.

Рис. 22. Пример построения сети с помощью ELAN

Таким образом, получается, что система ELAN позволяет организовывать различные подсети (т.е. участки, внутри которых не используется алгоритм третьего уровня), на границах которых установлены маршрутизаторы, с помощью которых происходит коммутация пакетов от одной подсети к другой, и эти маршрутизаторы уже вынесены из структуры АТМ. Значит, для построения разветвленной IP-сети требуется связать множество ELAN, и сеть АТМ уже не будет принимать участия в коммутации между ними.
Сказанное проиллюстрировано на ри- сунке 22, где показан пример построения большой сети на базе топологии АТМ. На рисунке 23 показано видение этой же самой сети с точки зрения маршрутизаторов.

Рис. 23. Видение сети, изображенной на рисунке 21, с точки зрения маршрутизаторов

Все это, конечно, замечательно, и должно нормально работать, но только можно заметить явную несуразность в этих двух рисунках. В самом деле, между подсетями LAN-1 и LAN-4 существует гораздо более короткий путь, который проходит через узел АТМ, не охваченный системой LANE. Наверное, можно было бы попытаться воспользоваться им, но в данном случае этого сделать нельзя, поскольку там нет маршрутизатора. Можно было бы усовершенствовать данную схему, объединив приведенные локальные сети каждая с каждой, и тогда, действительно, пакеты передавались бы между ними кратчайшим путем. Но если сеть разветвленная, то объединить все LAN каждую с каждой, наверное, затруднительно, особенно, если речь идет о такой структуре как Интернет и без участия транзитных маршрутизаторов все-таки не обойтись.

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

Нельзя ли попытаться как-то уменьшить эту задержку? Это можно сделать только одним путем - уменьшить количество транзитных роутеров либо множа ELAN, увеличивая, таким образом, связность сети, либо попытаться обеспечить передачу пакетов от отправителя до получателя минуя транзитные маршрутизаторы. Именно этот последний способ и реализован в системе МРОА. Получается, что его назначение - оптимизация работы системы LANE т.е.


ускорение передачи данных между ELAN. Помимо оптимизации процедуры выбора маршрутов через сеть АТМ система МРОА аналогичным образом оптимизирует пути прохождения кадров данных в рамках одной подсети, т.е. выполняет функцию моста (bridging) аналогичным образом. Ведь система LANE мало того, что действует только в рамках одной подсети, но также и в рамках одного сегмента - об этом также говорилось в предыдущем разделе.

Читателя может несколько смутить слово "Multiprotocol" в названии процедуры. Можно подумать, что речь пойдет об объединении различных протоколов, что-то типа трансляции или инкапсуляции. На самом деле ничего этого нет. Более того, в настоящее время в спецификации описан способ передачи только IP-пакетов. В будущем планируется обеспечить также и IPX - вот и будет оправдание слову "Multiprotocol".

Главной задачей МРОА является физическое разделение процессов маршрутизации и коммутации (forwarding) - производится так называемая виртуальная маршрутизация. Это позволяет добиться следующих преимуществ:

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

Построение МРОА схоже с системой LANE в том смысле, что она также основана на наличии клиентов и серверов - MPOA-client и MPOA-server и задает процедуры их взаимодействия. Основная задача - это найти укороченный маршрут - shortcut - между клиентом-отправителем и клиентом-получателем потока данных через сеть АТМ, минуя транзитные роутеры. Все взаимодействие роутеров между собой сохраняется в полной мере, т.е. они продолжают обмениваться между собой служебной информацией для построения маршрутных таблиц и реализации своих протоколов, например, OSPF.

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

Общее описание сервиса LANE

Эмулированная LAN обеспечивает передачу пользовательских кадров данных точно так же, как это происходит в физической локальной сети. Конечно, это не будет означать полное соблюдение тех же самых протоколов, но для пользователя будет полная эмуляция одной ЛВС, хотя они могут быть расположены в разных городах. Хотя в сети может одновременно сосуществовать несколько ELAN, данные не переходят между ними. Конечно, имеется возможность сопряжения нескольких ELAN, но сделать это можно будет, только поставив мост. Именно так объединяются между собой реальные локальные сети. Таким образом и в этом смысле имеется полная эмуляция.

Мы не будем касаться принципов объединения нескольких ELAN и ограничимся описанием работы только одной. В настоящее время документами АТМ-Форума описаны принципы эмуляции только двух типов ЛВС - Ethernet и Token Ring. Мы ограничимся описанием эмуляции Ethernet.

LAN Emulation используется в одной из двух конфигураций:

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

ELAN состоит из следующих компонент:

Набора клиентов LAN Еmulation - LEC. Клиентом LEC является та часть узла (или оконечной станции) АТМ, которая отвечает за порт ЛВС. Иначе говоря, это процедура обработки порта LAN. В его функции входит передача данных из ЛВС в сеть АТМ, Address Resolution Protocol (ARP) и некоторые другие функции управления. Напомним, что Address Resolution - это специфический протокол, необходимый для того, чтобы определить соответствие между адресом устройства на втором уровне и адресом на сетевом уровне, например, между МАС-адресом сетевой платы и связанным с ним АТМ-адресом. Сервера LANE (LES). Этот сервер осуществляет координацию всей эмулированной LAN.
Он регистрирует все объявленные МАС-адреса и привязку их к АТМ-адресам. Все клиенты LEC регистрируют свои рабочие станции в сервере LES. Когда клиенту нужно определить МАС-адрес удаленной рабочей станции, он обращается в сервер LES, т.е. в нем также реализован ARP. Сервера конфигурации LANE (LECS). С его помощью осуществляется привязка данного клиента LEC к указанной эмулируемой сети ELAN. Эта привязка осуществляется путем сообщения клиенту АТМ-адреса сервера LES, который для каждой ELAN должен быть один. Сервера широковещания - Broadcast and Unknown Server (BUS). С его помощью осуществляется глобальная рассылка информации всем станциям, подключенным к данной ELAN, а также однонаправленную передачу к конкретной рабочей станции в том случае, если серверу LES еще неизвестен АТМ-адрес удаленного клиента LEC, в ведении которого находится удаленная рабочая станция. Когда клиент LEC посылает запрос на многоадресную рассылку, сервер BUS перенаправляет его всем извеcтным ему клиентам в составе данной LANE в точности так же, как это делает рабочая станция в физической ЛВС. LEC в свою очередь разошлет его всем своим рабочим станциям и полученный ответ направит обратно в BUS.

Теоретически, каждая ELAN может содержать до 65278 клиентов LEC. При этом в каждой ELAN должен быть только один сервер LES и один сервер BUS.

Серверы LES, BUS и LECS могут быть частью либо оконечного АТМ-устройства или узла коммутации. Многие современные узлы АТМ имеют в своем составе клиента LANE и все другие перечисленные компоненты, хотя возможно, что они реализуются в отдельном устройстве.

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

На рис.16 приведена архитектура протоколов, используемых системой LANE. Как видим, в ее состав входит уровень адаптации AAL 5.Обмен между объектом LANE и объектом управления соединениями состоит в передаче запросов на установление соединения и разъединения. Обмен с уровнем управления состоит в инициализации и управлении процедурой LANE. Таким образом, система LANE с точки зрения сети АТМ является абонентом.

Рис. 16. Уровневая архитектура системы LANE

Общетехнические проблемы реализации режима LANE

Если мы сравним технические характеристики системы АТМ и любой из локальных сетей, то сразу бросится в глаза огромная разница в технологиях между ними. Это значит, что при реализации LANE необходимо как-то обеспечить совместимость этих технологий, причем таким образом, чтобы локальные сети на двух концах АТМ-сети не замечали того, что они соединены не напрямую.

На рис.14 показана сводная таблица наиболее существенных различий в этих двух технологиях. Базисным пунктом всех различий является то, что все ЛВС работают по принципу использования всеми рабочими станциями общей пропускной способности линии связи, тогда как в АТМ ресурсы под соединение отводятся заранее. Из этого следует, что скорость обмена в рамках установленного соединения не зависит от интенсивности работы других абонентов, тогда, как в ЛВС эта зависимость очень сильная. В некоторых технологиях ЛВС, в частности Ethernet все рабочие станции могут выдавать данные в канал одновременно, что приводит к коллизиям и снижению пропускной способности, тогда, как в АТМ коллизий быть не может, поскольку между узлами всегда двухточечная связь.

Рис. 14. Таблица наиболее существенных различий в технологиях АТМ и ЛВС

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

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

Как видим, есть много весьма своеобразных проблем и не существует специального уровня AAL для того, чтобы их разрешить. Подсистема LANE сама должна использовать один из вариантов AAL для своей работы, т.е.
с точки зрения сети является пользовательским приложением. Забегая вперед скажем, что LANE в своей работе опирается на AAL 5.

Когда мы говорим об объединении различных ЛВС, то естественным образом возникает вопрос о разделении общей сети на несколько доменов. Это требование приводит нас к понятию "эмулированной LAN - ELAN", которое означает несколько АТМ-устройств. Дело в том, что ЛВС невозможно подключить к АТМ непосредственно - нужно некоторое переходное устройство, которое будет выполнять все необходимые преобразования. С одной стороны к этому устройству подключена ЛВС, а с другой - сеть АТМ. Это необязательно должно быть отдельное устройство - большинство современных узлов АТМ имеет порты для подключения ЛВС. Здесь под ELAN понимается набор портов подключения. Сказанное проиллюстрировано на рис.15. К трем АТМ-устройствам подключено 5 локальных сетей. При этом пользователь хочет не просто объединить все эти сети в единую структуру с общим доступом, а сделать так, чтобы ЛВС 1, ЛВС3 и ЛВС4 были логически объединены в одну локальную сеть, а ЛВС2 и ЛВС5 - в другую. Таким образом, будет создано два домена локальных сетей и с точки зрения сети АТМ нужно сделать две "эмулированные" ЛВС. Иначе говоря, под ELAN понимается набор портов ЛВС в АТМ-устройствах, которые должны быть объединены в общую логическую структуру. При этом передача информации между рабочими станциями будет происходить только в пределах одной ELAN. Конечно, нельзя сделать так, чтобы часть рабочих станций в одной ЛВС принадлежала одной ELAN, а другая часть - другой. Вся эмуляция происходит только с ЛВС в целом. При этом не имеет никакого значения место расположения ЛВС на реальной сети. Имеется также возможность включения одной ЛВС сразу в несколько ELAN.

Рис. 15. Создание "эмулированной" LAN

Ограничение изменений времени задержки передачи

1.2.2. Ограничение изменений времени задержки передачи

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

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

Система накапливает в этом буфере некоторое количество блоков данных и только после того, как буфер заполнится, например, на 50%, эти данные начнут выдаваться пользователю. Теперь представим себе, что во время передачи вдруг возникла (из-за задержек в сети) пауза между блоками. Тогда эта пауза будет заполнена передачей абоненту данных из буфера. Конечно, если эта пауза будет слишком длинной, то при исчерпании буфера нужно либо оставить эту паузу и довести до абонента, либо заполнить паузу фиктивной информацией. Рекомендация указывает именно на второй путь и даже указывает, что фиктивные биты должны быть установлены в "1". При переполнении буфера информация из канала будет отброшена. Дело в том, что такой большой разброс времени доставки скорее всего был вызван потерей селлов или вставкой лишних селлов, попавших из других соединений. Если вместо потерянных не вставить фиктивные селлы буфер сам никогда не сможет заполниться до среднего значения. То, что данные именно потерялись, а не были задержаны, выявляется на основе анализа последовательных номеров, которыми снабжается каждый блок на уровне сборки/разборки.

Поскольку после паузы обязательно последует учащение потока селлов, то буфер снова заполнится до среднего уровня (поскольку общее количество переданных данных остается постоянным).

Аналогично процесс будет выглядеть в случае, если в потоке будет не пауза, а концентрация данных - буфер сгладит этот всплеск.

Основные сетевые приложения

А. Микуцкий, учебные материалы ЦИТ

1.

1.1.

1.2.

1.2.1.

1.2.2.

1.2.3.

2.

3.

3.1.

3.2.

4.

5.

5.1.

5.2.

5.3.

5.4.

5.5.

6.

6.1.

6.2.

6.3.

6.4.

Подключение к эмулированной LAN

В целом все действия, которые нужно предпринять для того, чтобы передавать данные внутри ELAN, сводятся к следующему:

Инициализация. Эта фаза достаточно сложная и ответственная, поэтому она разбита на несколько этапов.

Первый этап - начальное состояние. В это состояние система входит непосредственно после активизации. Клиент LEC определяет, заданы ли ему все параметры, необходимые для работы. Спецификация определяет большой список параметров, которые должны быть установлены в LEC. Всего этих параметров 28, но большинство их них имеют значения по умолчанию, а некоторые устанавливаются автоматически после прохождения различных этапов подключения на основе принимаемой информации. Правда, несколько параметров никак не могут быть определены без оператора. Список этих параметров показан на рис.19. Начальное состояние должно определяться не только у клиента, но и у сервера LES и BUS, т.е. им тоже задается почти такой же набор параметров, но с некоторыми дополнениями. Так, при конфигурации LEC оператор должен указать тип локальной сети - Ethernet, Token Ring или неопределенный. Определенность обязательно появится после обмена информацией с сервером LES. Также указывается максимальный размер кадра данных, является ли данный LEC proxy-агентом удаленных рабочих станций, параметры служебных виртуальных соединений с сервером BUS. В случае подключения сети Token Ring указывается еще несколько параметров. При конфигурировании сервера LES необходимо указать тип сети, максимальный размер кадра данных и АТМ-адрес сервера BUS.

Рис. 19. Перечень настраиваемых параметров LEC

После того, как LEC определил свои внутренние параметры начинается этап подключения к серверу LECS. Здесь клиент устанавливает виртуальное соединение с сервером LECS. Заметим, что в параметрах конфигурации клиента нет сведений об АТМ-адресе сервера LECS. Поэтому рекомендация определяет три способа, по которым клиент может установить соединение. Первый способ - это послать запрос через систему управления, чтобы она сообщила нужный АТМ-адрес.
Второй способ - это использование стандартного номера виртуального канала, зарезервированного специально для подключений к этому серверу. Этот стандартный номер определяется как VPI=0 и VCI=17. Третий этап - использование стандартного АТМ-адреса LECS. Дело в том, что АТМ-Форум выделил специальный АТМ-адрес сервера, который может поддерживать работу всех ELAN в мире. Правда, для того, чтобы это было возможно, оператор связи, предоставляющий услуги АТМ должен будет заявлять в этот сервер информацию обо всех ELAN, которые организованы в рамках его ответственности. Такой способ может быть использован только на самый крайний случай, когда другого способа нет. Этот сервер имеет следующий адрес в 16-ричном коде: 4700790000000000000000000000-А03Е000001-00.

После установления соединения клиент и сервер переходят на этап конфигурации, в рамках которого клиент запрашивает от сервера LECS АТМ-адрес сервера LES. Обмен информацией идет с помощью стандартных форматов. Заметим, что этот адрес заносится в сервер LECS оператором на этапе конфигурации ELAN, т.е. когда оператор сети создает эмулированную LAN, он должен занести в этот сервер адреса всех тех LES, которые будут созданы (каждой ELAN соответствует строго один сервер LES и BUS).

Когда клиент узнает АТМ-адрес сервера LES, он переходит к фазе подключения, в которой устанавливается виртуальное соединение с сервером LES, и запрашивает параметры ELAN, в которой будет работать. Клиент сообщает серверу свой МАС-адрес и АТМ-адрес, а сервер передает клиенту идентификатор, который присваивается ему в рамках данной ELAN, тип поддерживаемой LAN - Ethernet или Token Ring, указывает на максимально допустимый размер кадров данных. Кроме того, сервер может установить еще один виртуальный канал, точнее подключить клиента к существующему соединению "точка-много точек", которое охватывает всех клиентов LEC, участвующих в работе данной ELAN.

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


Эти адреса идут в дополнение к собственному МАС- адресу клиента, который уже был передан во время этапа подключения. Этот обмен также идет в стандартных форматах.

На следующем этапе клиенту необходимо установить соединение с сервером BUS, однако его АТМ-адрес пока еще неизвестен. Чтобы его узнать необходимо использовать Address Resolution Protocol, с помощью которого устанавливается соответствие между МАС-адресом и АТМ-адресом устройства. Известно, что МАС-адрес сервера BUS состоит из одних единиц - это адрес широковещания. Клиент посылает в сервер LES ARP-запрос, где содержится требование на сообщение АТМ-адреса того устройства, у которого МАС-адрес состоит из одних единиц. Этот адрес заносится в сервер LES оператором на этапе конфигурирования ELAN. Получив значение АТМ-адреса сервера BUS, клиент устанавливает к нему виртуальное соединение, причем конфигурация связи между LEC и BUS аналогична конфигурации связи между LEC и LES, т.е. имеется обычное дуплексное соединение, а также однонаправленное соединение типа "точка-много точек", устанавливаемое сервером.

После завершения всех этих действий клиент оказывается подключенным к ELAN и готов к работе, и может начинать передавать пользовательские данные. Однако, ему еще пока неизвестны никакие другие адреса рабочих станций, кроме своих собственных, и для того, чтобы узнавать их, а также для сообщения в сеть своих вновь подключаемых станций, ему необходимо будет использовать еще две фазы - регистрация и Address Resolution. Регистрация. Эта фаза по сути представляет собой продолжение описанного этапа начальной регистрации, т.е. объявление в сеть о вновь подключаемых рабочих станциях. Эти сообщения передаются в сервер LES по установленному ранее каналу управления. Address Resolution. Работа в этой фазе соответствует процедуре распознавания МАС-адреса сервера BUS, т.е. запрашивается соответствие между МАС-адресом и АТМ-адресом устройства. Такой запрос посылается клиентом LEC в сторону сервера LES в том случае, если он имеет данные для передачи в сторону абонента, АТМ-адрес которого ему неизвестен.


Заметим, что выясняется не АТМ-адрес рабочей станции, в физической ЛВС этого адреса у нее скорее всего просто нет, а выясняется АТМ-адрес того LEC клиента, к которому подключена та физическая ЛВС, в составе которой находится требуемая рабочая станция.

Необходимо сразу обратить внимание на то, что система Address Resolution в ELAN - LE_ARP - не заменяет собой обычный ARP, который существует в локальных сетях. Напомним, что в обычной ЛВС протокол ARP используется для определения соответствия сетевого адреса и МАС-адреса рабочей станции. Если в обычных ЛВС каждая станция имела два адреса, то здесь появляется третий - АТМ-адрес, о котором рабочая станция ничего не знает. Поэтому два ARP будут сосуществовать одновременно - один для обмена информацией между рабочими станциями, а другой - для обмена между клиентами LEC. Рассмотрим это на примере объединения локальных сетей, работающих по протоколу IP. На рис.20 показана схема рассылки запросов ARP и ответов на них.

Рис. 20. Процедуры ARP между рабочими станциями ЛВС и между клиентами LEC

Когда рабочая станция 1 посылает пакет к станции 2, но не знает ее МАС-адреса, она посылает ARP-запрос, в котором просит сообщить, какой МАС-адрес имеет станция, имеющая указанный IP-адрес. Это запрос попадает на каждую станцию, но ответ посылает только та, которая имеет именно этот IP-адрес. С точки зрения ELAN этот обмен является пользовательским. Единственно только, что ARP-запрос будет в широковещательном режиме разослан все участникам связи. Это происходит потому, что кадр, содержащий этот запрос, имеет МАС-адрес, состоящий из одних единиц - признак широковещания. Клиент LEC получит от своей рабочей станции кадр, содержащий ARP-запрос. Однако, он не знает ничего о том, что это именно ARP - он просто видит, что в составе этого кадра МАС-адрес получателя имеет все единицы, т.е. соответствует МАС-адресу сервера BUS, куда он и будет отправлен. Сервер BUS в широковещательном режиме передаст этот кадр всем зарегистрированным клиентам LEC, каждый из которых отправит его внутрь своей ЛВС, где он будет обрабатываться как обычный ARP-запрос.


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

Когда рабочая станция 1 ответит на этот запрос своим ARP-ответом, то в нем будет указано, какой МАС-адрес имеет рабочая станция с данным IP-адресом. Конкретно, будет указано, что станция 2, которой присвоен IP-адрес В, имеет МАС-адрес b. После этого рабочая станция 1 будет сопровождать все пакеты данных, направляемые к станции 2, указанием на ее МАС-адрес. Когда первый такой пакет придет к клиенту LEC1 ему придется посылать уже свой ARP-запрос, который будет направлен серверу LES, где содержится просьба сообщить АТМ-адрес того клиента LEC, который представляет рабочую станцию, имеющую МАС-адрес b. Сервер LES разошлет этот запрос всем зарегистрированным клиентам (если у него такой информации еще нет), но ответит на него только тот, к которому подключена рабочая станция 2. Вспомним, что в фазе регистрации каждый LEC сообщал в LES сведения о МАС-адресах подключенных рабочих станций, но это еще не значит, что зарегистрированными оказались все - ведь пока рабочая станция молчит, никому ничего не известно о ее адресе. В ответе от LEC будет содержаться АТМ-адрес, в направлении которого LEC 1 пошлет информацию. Теперь обмен данными между станциями 1 и 2 пойдет нормальным путем, поскольку все три адреса известны на передающем конце.

Таким образом мы видим, что процедура LE_ARP по своей сути совершенно аналогична процедуре ARP в обычных ЛВС, только выясняются соотношения между другими адресами.

Между прочим, такая процедура может идти даже в том случае, когда между парой клиентов LEC уже ранее было установлено виртуальное соединение. Просто, если LEC не знает АТМ-адреса, которому соответствует запрошенный МАС-адрес, то он не сможет выбрать нужное виртуальное соединение, по которому эти данные нужно послать.

Мы рассмотрели все служебные фазы работы системы LANE. Теперь посмотрим, как же происходит собственно установление соединений и передача данных.

Подуровень конвергенции

В задачи подуровня конвергенции входит принятие от пользователя кадров данных размером до 65535 байт (как раз максимальный размер IP-пакета) и обеспечение на приеме контроля за правильностью доставки информации. Под контролем понимается наблюдение за обнаружение сбоев в последовательности принятых блоков и т.д.

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

Рис. 12. Формат CPCS-PDU в AAL типа 3/4

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

Поле Btag - начальная метка работает в паре с полем Etag - конечная метка. Дело в том, что поскольку размер протокольного блока может быть очень длинный, то когда подуровень сборки/разборки нарежет из этого блока много маленьких блоков фиксированной длины, начало и конец исходного блока попадут в разные селлы при передаче. На приеме же необходимо иметь жесткую связку начала и конца протокольного блока. Поэтому метки начала и конца в каждом блоке всегда одинаковые и увеличиваются на единицу после окончания формирования блока. Нумерация меток ведется в диапазоне от 0 до 255.

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

Итак, рассмотрим процесс работы подуровня конвергенции в комплексе. Когда соединение установлено, передатчик активизирует счетчик, по данным которого будет устанавливаться начальная и конечная метка первого блока.
Когда этот блок приходит, передатчик создает заголовок протокольного блока, соединяет его блоком абонентских данных, дополняет объем этого абонентского блока до величины, кратной 4 байтам и прибавляет концевик. В результате получился протокольный блок подуровня конвергенции. Все это целиком отправляется на подуровень сборки/разборки, который нарежет его на куски фиксированной длины по 44 байта, присвоит каждому из них порядковый номер, защитит проверочным полиномом и отправит в канал.

На приеме оказывается, что функция сборки всех маленьких блоков по 44 байта каждый в единый блок данных произвольного размера возложена вовсе не на подуровень сборки/разборки, как можно было бы себе представить, а на подуровень конвергенции. При приеме сервисного блока, содержащего начало протокольного блока система выделяет размер памяти, соответствующий указанному значению в поле BAsize, а метка начала запоминается. Ее потом нужно будет сверить со значением конечной метки в последнем сервисном блоке.

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

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

о функциях процедур AAL необходимо

Перед тем, как говорить о функциях процедур AAL необходимо дать несколько определений.

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

Если представить себе подуровень конвергенции в качестве "черного ящика", то это будет устройство с двумя входами и двумя выходами. Через первый вход информация от пользователя поступает в систему, через второй вход блоки данных поступают на приеме от подуровня сборки/разборки. Соответственно, через первый выход блоки данных поступают на подуровень сборки/разборки, а через второй - поток данных передается принимающему абоненту.

Хотя поток данных от абонента непрерывный, система перед началом его обработки должна как-то его разделить на кусочки. Рекомендация I.363 говорит, что обмен данными между пользователем и AAL должен вестись не в потоке, а дискретными блоками, называемыми примитивами. Их всего два: с помощью одного данные принимаются от абонента, с помощью второго - отдаются абоненту на приеме. Не означает ли это, что от абонента тем самым требуют предварительного разбиения информации? Нет не означает, поскольку фактически это означает, что AAL просто дискретно во времени обращается к абоненту за данными для передачи. Это логически можно себе представить как некую процедуру управления потоком на интерфейсе V.24: AAL через строго фиксированные интервалы времени выдает сигнал на разрешение передачи информации, а между этими сигналами передающий абонент накапливает данные до следующего разрешения.
Разумеется, система работает в реальном времени, т.е. AAL обязан успеть обработать поступившую порцию информации до того момента, когда нужно будет запрашивать следующую. Верхний уровень просто должен иметь достаточно памяти, чтобы накопить данные в период между запросами. Как указывалось выше, уровень AAL 1 в качестве единицы информации от пользователя использует или один бит или один байт, следовательно, размер примитивов обмена с пользователем составляет один бит или один байт, к которому может добавляться еще и служебный бит. Согласно рекомендации с помощью этого служебного бита пользователь может указывать системе, являются ли данные пользователя неделимым потоком данных или какими-то структурированными последовательностями.

После того, как подуровень CS принял от пользователя информацию, он приступает к формированию протокольных блоков данных, с помощью которых будут реализовываться все те функции, которые должен реализовывать уровень AAL 1. Посмотрим, каким образом эти функции реализуются.

Подуровень сборки/разборки

В принципе функции, возложенные на этот уровень достаточно просты и выделены они в отдельную процедуру исключительно с той целью, чтобы отделить функции, общие для всех типов AAL от функций, зависящих от типа AAL. Функции подуровня SAR в целом состоят в следующем:

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

Формат протокольного блока подуровня SAR представлен на рис.3. Как видим, структура очень проста. Последовательный номер блока состоит из трех бит, что позволяет нумеровать блоки в диапазоне от 0 до 7. Обратим внимание на то, что это вовсе не значит, что в системе не может одновременно находиться не более 7 селлов (здесь нет ничего общего с понятием окна, которое мы разбирали в связи с процедурой Х.25), поскольку нет повторных передач и подтверждений из конца в конец.

Рис. 3. Формат SAR-PDU AAL типа 1

Что касается процедуры контроля ошибок, то в AAL она делается точно так же, как и на уровне АТМ, только в AAL по отношению к протокольным блокам, а в уровне АТМ - к селлам. Напомним, что на уровне АТМ анализировался заголовок селла, и если замечалась ошибка, то она исправлялась кодом, а сразу после этого система входила в режим обнаружения, где и находилась до тех пор, пока не встретится первый безошибочный селл.

Процедура обмена данными в LANE

Когда клиент-отправитель пользовательских данных точно знает, по какому АТМ-адресу (т.е. какому клиенту LEC) он должен послать эту информацию, то он устанавливает в его сторону соединение АТМ (если оно ранее уже не было установлено). Процедура установления соединения АТМ для целей LANЕ несколько отличается от обычной процедуры, которая описана в следующей главе, поэтому остановимся на ней. По установленному виртуальному каналу, называемому каналом данных - Data Direct VCC, никогда не будут передаваться управляющие запросы и ответы. Все управление будет идти через серверы.

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

Как видим, вызываемый клиент может получить сообщение Connect_Ack до того, как вызывающий получит сообщение Connect, поскольку Connect_Ack посылается местным узлом своей оконечной станции, а не от удаленного абонента. В результате может оказаться, что если вызывающий клиент начнет сразу передавать данные, то начало этих данных не сможет быть принято, поскольку вызывающий клиент не успел принять сигнальное сообщение Connect или не успел его обработать. Забегая несколько вперед скажем, что сообщения сигнализации, к которым относится и Connect, проходят через сеть по отдельному виртуальному каналу, и, следовательно, данные могут это сообщение обогнать. Поэтому вызываемая станция еще не входит в режим передачи данных после получения сообщения Connect Ack, а ждет прихода еще одного подтверждения Ready Ind, которое посылается вызывающей стороной. Она посылает это сообщение только после того, как ею будет принято сообщение Connect, и она будет готова к передаче данных. Иными словами, вызываемый абонент сможет передавать данные только после того, как убедится, что противоположная сторона сможет их принимать.

Рис. 21. Установление соединения: запрос/индикация вызова

Конечно, сообщение Ready Ind может потеряться, и для защиты от этого на вызываемой стороне после получения сообщения Connect Ack запускается таймер, значение которого дает достаточный запас времени для того, чтобы противоположная сторона успела принять Connect. Если Ready Ind не поступит за время действия этого таймера, то вызываемая сторона будет считать, что это сообщение потерялось в сети, а сам абонент уже готов к работе. Вызываемый тем не менее пошлет контрольное сообщение, содержащее запрос о готовности Ready Query, в ответ на которое вызывающий должен сразу ответить сообщение Ready Ind.

Может показаться странным, что такая многоуровневая зашита предусмотрена на потерю сообщения Ready Ind и ничего нет для защиты сообщения Connect, которое тоже может потеряться. Дело в том, что если оно потеряется, вызывающий абонент будет считать, что соединение не было установлено и по истечении таймаута возобновит его с самого начала, т.е. снова пошлет сообщение SETUP.

Итак, мы поняли, что передача пользовательских данных в рамках ELAN может проходить двумя способами. Первый - это прямой обмен между LEC по отдельному виртуальному каналу, и он используется, когда все адреса уже точно известны. Второй способ - это обмен через сервер широковещания BUS, и он используется для поддержки протокола ARP, а также в тех случаях, когда идет широковещательная передача.

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


Можно гарантировать только, что кадры, шедшие в рамках одного и того же канала придут с соблюдением исходной последовательности.

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

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

Надо заметить, что создание ELAN вовсе не может решить проблемы совместимости различных типов ЛВС, так, ELAN не поможет осуществить взаимодействие между Ethernet и Token Ring. Действительно, как мы уже заметили, сеть ELAN не производит никаких действий над пользовательскими кадрами, если не считать считывания поля адреса из их заголовков. Раз так, то для сопряжения между различными сетями необходим соответствующий мост, как и в случае соединения физических ЛВС.По этой же самой причине все приложения, характерные для ЛВС, могут передаваться через АТМ, которая для пользователей совершенно невидима.

Режим LAN Emulation (LANE)

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

Это оказалось одной из причин, почему сеть Интернет оказалась сейчас гораздо более популярной, чем система Х.25 и даже, чем Frame Relay. Дело в том, что технология Интернет гораздо ближе к технологиям локальных сетей и осуществить связь двух локальных сетей через вставку IP гораздо проще, чем через другие технологии. Кроме того, это гораздо быстрее, чем по Х.25, поскольку не требуется ни преобразования протоколов, ни дополнительных заголовков.

В случае, если вновь внедряемая технология будет не приспособлена к этому виду обмена информацией, то она никогда не привлечет клиентов. Более того, новая технология должна не просто позволять выполнить объединение локальных сетей - система Х.25 в принципе позволяет это сделать - она должна это делать как можно эффективнее и как можно более незаметно для пользователя. Так, например, в устройствах CISCO последних версий появился режим LAN Emulation, с помощью которого пользователи нескольких локальных сетей общаются друг с другом даже не замечая, что между ними имеется вставка глобальной сети. Правда, CISCO выполняет этот режим через подсистему TCP/IP, и, поэтому, скорость обмена по магистральному каналу намного уступает обмену внутри самой локальной сети, особенно, если используется высокоскоростная ЛВС типа, например, 100BaseT. Кроме того, такой режим не поддерживает всех функций LAN, в частности нельзя делать многоадресную доставку, т.е. использовать режим широковещания. Кроме того, нужно, чтобы администратор сети определил машину, которая будет играть роль ARP-сервера.

Режим LANE, о котором мы будем говорить в данном подразделе, призван использовать преимущества сети АТМ применительно к пользователям локальных сетей. С его помощью различные локальные сети будут фактически превращены в одну с сохранением всех функций локальных сетей.

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

сохранение доступности всех существующих приложений LAN через АТМ; использование сети АТМ в качестве просто транспортной среды между сетями; обеспечение доступа из LAN других рабочих станций и серверов, подключенных к АТМ непосредственно;

Сквозная ATM-парадигма для сетей

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

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

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

Использование новых API для "новых" приложений и эмуляция традиционных протоколов для существующих приложений.

Поскольку использование ATM обычно начинается с нескольких станций, которым требуются multimedia-приложения, требуется обеспечить эмуляцию традиционных протоколов ЛВС в сетях ATM. Это позволяет обеспечить надежное взаимодействие между новыми станциями на базе ATM и традиционными ЛВС. Для эмуляции ЛВС в системах на базе ATM (ATM LAN emulation) предложены два варианта - ATM Forum LAN Emulation (LANE) и RFC 1577. Говоря здесь об эмуляции, мы имеем в виду оба варианта.

Как LANE, так и RFC 1577 основаны на допущении что пользователи ATM применяют адаптеры, поддерживающие интерфейс ATM UNI. Поскольку этот интерфейс располагается со стороны пользователя, его иногда называют "Private UNI"; существует набор стандартов, определяющих данный интерфейс.
Стандарты Private UNI существуют для скоростей 25 Мбит/с (по медному кабелю), 100 Мбит/с (оптический кабель)и 155 Мбит/с (медь и оптика). Оба стандарта эмуляции ЛВС предполагают также, что пользователи подключены к коммутатору ATM. Некоторые ATM-коммутаторы поддерживают также станции других типов (не ATM). Такие коммутаторы обеспечивают взаимодействие между ЛВС Ethernet и token ring и сетями ATM. Коммутаторы также поддерживают порты (для подключения станций и серверов) и транки (для соединения коммутаторов ATM или подключения к магистральным коммутаторам) ATM. Интерфейс между коммутаторами основан на UNI, но включает дополнительно специальные сообщения для маршрутизации и управления состоянием маршрутов. ATM Forum называет этот интерфейс Private Network-to-Network Interface или P-NNI.

Эмуляция ЛВС во всех вариантах состоит из двух программных частей - функции клиента используются на конечных системах, подключенных к эмулируемым ЛВС, а функции сервера - реализуются в каждой группе клиентских станций. Группа клиентов и связанный с ней сервер называются эмулируемой ЛВС (Emulated LAN или ELAN).

Протоколы ЛВС являются многоуровневыми и, следовательно, любой стандарт, обеспечивающий взаимодействие традиционных ЛВС и ATM должен обеспечивать поддержку соответствующих уровней. В этом вопросе существующие стандарты эмуляции ЛВС существенно различаются. ATM LANE (стандарт ATM Forum) предназначен для эмуляции протоколов канального (MAC/LLC) уровня. Поскольку этот протокол занимает самый нижний для ЛВС уровень, LANE можно использовать со всеми протоколами ЛВС вышележащих уровней, включая TCP/IP, NetWare SPX/IPX, IBM SNA/LLC2. RFC 1577, с другой стороны, работает на сетевом уровне (уровень 3) и предназначен для протокола TCP/IP.

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


Сервер строит каталог адресной информации для последующего использования. По завершении регистрации клиенты и серверы переходят в режим ожидания пользовательского трафика.

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

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

Клиентская система, не имеющая виртуального устройства ATM, должна организовать его, но дейтаграмма является сообщением ЛВС и не содержит ATM-адреса получателя. Для получения этого адреса клиент посылает сообщение своему серверу, указывая получателя дейтаграммы с помощью адреса сетевого и/или канального уровня и запрашивая соответствующий адрес ATM. Сервер сообщает адрес, после чего клиент организует коммутируемое соединение ATM SVC с адресатом, в которое направляется поток дейтаграмм.

Сервер также обеспечивает поддержку широковещательного и неадресованного (broadcast and unknown) трафика для клиентов, рассылающих широковещательные и групповые (multicast() дейтаграммы.


Сервер в таких случаях пересылает принятые дейтаграммы всем зарегистрированным клиентам. Перед организацией SVC клиент может также использовать режим "broadcast and unknown" для рассылки дейтаграмм адресатам, для которых адреса ATM еще не получены.

Устройства традиционных ЛВС должны обмениваться данными со станциями ATM, работающими в эмулируемых ЛВС; коммутаторы обеспечивают функции proxy-клиента от имени станций традиционных ЛВС (не ATM). В этом случае станция ATM, вызывающая станцию ЛВС будет получать от сервера адрес proxy-клиента и организовывать SVC по этому адресу. Proxy-клиент будет в этом случае играть роль моста или маршрутизатора для передачи дейтаграмм нужной станции. На практике такое использование эмуляции является преобладающим, поскольку большинство настольных станций по-прежнему используют Ethernet или token ring.

Это может выглядеть как попытка создания всемирной "плоской" сети, но это не так. RFC 1577 задает ограничение на размер доменов эмуляции ЛВС - не более одной IP-подсети на домен. ATM Forum LANE не содержит такого ограничения, но практический размер домена устанавливается числом генерируемых многоадресных сообщений (с ростом этого числа растет нагрузка на сервер и клиентов). В действительности LANE представляет собой мост, а широковещательный и групповой трафик всегда является ограничивающим фактором для сетей на базе мостов.

Как связать между собой эмулируемые домены ЛВС? Лучшим способом является использование коммутаторов ЛВС. Поскольку коммутатор может одновременно работать с ATM LANE и дейтаграммами традиционных ЛВС, он может обеспечивать связь эмулируемых доменов (как подсетей IP или сегментов ЛВС).

Проблема возникает при использовании маршрутизаторов для соединения устройств ATM, использующих multimedia-приложения. Маршрутизаторы, как устройства, работающие без организации соединений, не могут обеспечивать гарантии качества обслуживания (QoS), предлагаемой коммутаторами ATM. Таким образом, маршрутизатор между двумя станциями ATM существенно ограничивает возможности связи между этими станциями (до уровня станций традиционных ЛВС).


Решения на базе коммутаторов позволяют сохранить гибкость и скорость ATM.

Естественные соединения ATM требуют коммутируемого пути между адресатом и отправителем. Если оба устройства подключены к одному коммутатору, проблем не возникает. Также просто организовать связь между устройствами, использующими услуги одного оператора или коммутаторы одного производителя. При соединении устройств в среде с разнотипным оборудованием может потребоваться использование PNNI для организации мостов между двумя или несколькими коммутаторами ATM и в тех случаях, когда ATM-соединение организуется через распределенную сеть (WAN).

Существует три варианта организации "реальных" соединений ATM через распределенную сеть:

Выделенная цифровая линия от оператора (T3, например) служить транком между двумя коммутаторами ATM - эти коммутаторы будут генерировать ячейки, обеспечивать сигнализацию ATM и поддерживать потоки трафика. Фактически, это вариант частной сети ATM.

Оператор ATM может обеспечивать виртуальный путь между парой коммутаторов. В этом случае оператор передает ячейки и принимает участие в управлении трафиком ATM, но соединенные между собой устройства управляются виртуальными устройствами как при использовании соединения по выделенной линии.

Может использоваться предоставляемое оператором коммутируемое соединение ATM SVC.

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

В долгосрочной перспективе ATM может полностью заменить технологии ЛВС и системы межсетевого взаимодействия в их современном виде. Сети на базе коммутаторов, в результате, будут значительно более гибкими, нежели связанные между собой ЛВС. Стоимость таких решений также может оказаться меньше. Многие пользователи верят в перспективность ATM и даже неизбежность успеха этой технологии. Однако переход к использованию ATM тормозится высокими ценами на оборудование и сложностью его использования.

Составные части МРОА и их назначение

Система МРОА работает по архитектуре клиент-сервер, причем существовать она может только на базе LANE, т.е. это абсолютно неразрывные системы. Клиент и сервер МРОА, структуры которых изображены на рисунке 24, находятся чаще всего в разных устройствах, подключенных к сети АТМ (хотя могут находиться и в одном) и соединены друг с другом через LANE, т.е. находятся в одной подсети.

Рис. 24. Структура клиента и сервера МРОА

Главная задача клиента - выявить короткий путь до получателя и установить АТМ-соединение до него. Для обеспечения этого он выполняет коммутацию данных, но никогда не занимается собственно протоколами маршрутизации. На стороне отправителя (ingress client) выполняется обнаружение потока данных, которые должны быть переданы через ELAN к роутеру, который содержит в своем составе сервер МРОА. Когда обнаружится, что этот поток достаточно регулярный, то принимается решение о том, что будет выгоднее установить прямой АТМ-путь непосредственно до получателя, начинается процесс установления АТМ-соединения до него. Казалось бы чего проще? Но это только на первый взгляд. В самом деле, представим себе IP-сеть, некоторые узлы которой связаны через АТМ-структуру (рисунок 25). Пусть от рабочей станции WS-1 исходит поток данных к станции WS-2. IP-адреса этих станций находятся в сетях, в которых нет устройств АТМ, следовательно, между ними невозможно установить прямое соответствие. Однако, в таблицах маршрутизации роутеров записано, что для достижения требуемой сети нужно переслать пакет по следующему пути: R1-R2-R3-R4. Роутеры R2, R3, R4 объединены через LANE и поэтому пакеты будут доставляться через транзитный роутер R3. При этом клиенты МРОА пока еще ничего не знают друг о друге. Когда выяснится, что поток между станциями WS-1 и WS-2 достаточно активный, то включится процедура выявления короткого пути (shortcut), задачей которого для МРС-1 является обнаружение МРС-2 и установления до него прямого виртуального канала. И вот для выполнения этой задачи и служит МРОА как таковая и все ее компоненты.
Если такой путь возможен, то клиент, инициировавший его установление, занесет сведения о получателе в свою внутреннюю таблицу (ingress cache), установит виртуальное соединение и в дальнейшем будет передавать все пакеты в направлении МРС-2 по нему, минуя роутер R-3. МРС-2 направляет все пакеты, принятые от МРС-1 в свою IP-сеть. Здесь тоже не все так просто. В самом деле, поскольку МРС-1 и МРС-2 находятся в разных сетях и в разных ELAN, то они могут быть организованы по-разному. В частности, ELAN-1 может работать по протоколам Ethernet, a ELAN-2 - по протоколам Token Ring. Следовательно, МРС-2 должен произвести еще и преобразование заголовков кадров второго уровня для перехода между этими двумя протоколами. Необходимость такого перехода передается в МРС-2 от сервера MPS, и его параметры заносятся в его внутреннюю таблицу (egress cache).

Рис 25. Задача установления прямого пути между клиентами МРОА

Что касается МРОА-сервера - MPS, то его назначение в перенаправлении информации сетевого уровня между клиентами. Для этих целей, в частности, используется Next Hop Resolution Protocol (NHRP), реализуемый в Next Hop Servers (NHS). Дело в том, что на пути между клиентами может находиться несколько MPS, т.е эти серверы объединены в сеть, и требуется найти путь в этой сети между сервером-отправителем и сервером-получателем. Кроме того, с их помощью определяются параметры необходимых преобразований в клиентах на кадровом уровне модели. Таким образом, серверы служат только лишь для организации правильного взаимодействия между клиентами и помогает им обнаружить друг друга.

Спецификация описывает несколько типов МРОА-устройств:

Пограничное устройство МРОА (МРОА edge device), которое включает в себя клиента МРОА, клиента LEC и порт связи с местной IP-сетью. Иначе говоря это устройство, которое позволяет транслировать IP-пакеты из местной подсети в другую подсеть через МРОА. МРОА Host. Это устройство отличается от предыдущего тем, что оно не имеет связи с местной IP подсетью, т.е это просто рабочая станция, оснащенная стеком АТМ и имеющая IP адрес. Роутер.Он состоит из клиента LEC, сервера МРОА (MPS), который в свою очередь включает еще и Next Нор Server (NHS). Кроме того, на него возложены также и функции маршрутизации.

При этом возможны комбинации этих устройств, например, возможно совмещение клиента и сервера МРОА, и это устройство будет и маршрутизировать пакеты и устанавливать прямое АТМ-соединение между клиентами.

Как видим, во всех устройствах присутствует клиент LEC, причем спецификация допускает подключение МРС и MPS сразу к нескольким клиентам LEC, что дает возможность подвести к одному устройству несколько подсетей. При этом, однако, у одного клиента LEC не может быть более одного МРОА-устройства.

предназначен для поддержки сервисов

Уровень AAL 3/ 4 предназначен для поддержки сервисов класса С и D. Как показано на рис.1, класс С обеспечивает предварительное установление соединения между пользователями (режим connection-oriented), отсутствие необходимости передачи сигналов тайминга между пользователями и переменную скорость работы. Класс D отличается только тем, что он не делает предварительное установление соединений (режим connection-less). Примером пользователя службы класса С является система х,25 или Frame Relay. Примером службы, использующий класс D является система TCP/IP. Оба этих класса предназначены, таким образом, для передачи данных, которая нечувствительна к задержкам передачи, но зато требует высокой достоверности данных. Кроме того, в отличие от систем передачи аудио и видео, передача будет вестись блоками, т.е. данные пользователя некоторым образом структурированы. Например, передача в системе TCP/IP ведется пакетами, размер которых колеблется от 1 до 65535 байт. Кроме того, IP-пакеты содержат в себе части TCP сообщения, т.е. исходный транспортный блок данных состоит из нескольких интерфейсных блоков, поступающих на вход AAL.

Уровень AAL 3/4 должен выполнять функции по адаптированию структурированных данных в поток, пригодный для вложения в селлы, т.е. выполняет сегментацию кадров пользователя в 48-байтные блоки.

На рис.8 представлена общая структурная схема AAL 3/4. Из него видно, что AAL 3/4 состоит из двух глобальных частей - подуровень для конкретного сервиса - service specific part -SSP и общая часть, используемая независимо от конкретного сервиса - common part. Подсистема SSP используется в тех случаях, когда пользователю нужно предоставить дополнительные функции. Однако, хотя наличие такого уровня и предусмотрено рекомендацией, пока нет никаких конкретных спецификаций его работы ни для каких видов сервиса, поэтому, мы больше этой части касаться не будем.



Рис. 8. Структура AAL типа 3/4

Общая часть обеспечивает последовательную прозрачную передачу пользовательских кадров переменной длины.
Здесь под кадрами надо понимать просто пользовательские блоки данных, будь то пакеты Х.25 или пакеты IP. Эта общая часть в свою очередь разбивается на общую часть подуровня конвергенции и подуровня сборки/разборки.

Прежде, чем приступать непосредственно к рассмотрению этих подуровней, рассмотрим в принципе особенности AAL 3/4. В системе предусмотрено два режима передачи:

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

AAL 3/4 имеет возможность поддерживать соединения точка-точка, а также точка-много точек. Использование системы передачи АТМ показано на рис.9. На входе в AAL существует набор сервисных точек доступа - AAL СТД. Сервисной точкой доступа называется адрес некоего регистра, через который происходит обмен сервисными блоками между уровнями или между пользователем и системой. В принципе абоненту может быть предоставлены различные классы качества сервиса, и каждой точке доступа соответствует определенный класс. Конечно, это не значит, что точек доступа должно быть столько же, сколько классов качества сервиса - их может быть гораздо больше - по числу одновременно поддерживаемых соединений. Абонент, когда желает установить соединение, обращается к одной из сервисных точек доступа. Далее система устанавливает связь с одной из сервисных точек доступа уровня АТМ.


Все АТМ- соединения проходят через разные СТД, т.е. когда идет обмен между пользователями, он проходит через одну и ту же точку СТД. Когда соединение отбивается, данная СТД может быть предоставлена другому соединению.



Рис. 9. Связь AAL-SAP и ATM-SAP

Как видно из рисунка, возможно мультиплексирование нескольких соединений уровня AAL в одно соединение АТМ. Это может быть нужно, например, в случае, когда несколько терминалов подключены к локальной сети, которая имеет шлюз в сеть АТМ (рис.10). Весь обмен происходит через сеть АТМ между терминалами и сервером в рамках одного АТМ-соединения. Сервер, таким образом, должен уметь разделять потоки данных от каждого из терминалов. Эти функции разделения также возложены на уровень AAL.

Таковы в самом общем виде функции уровня AAL 3/4. Теперь посмотрим, как эти функции реализуются в подуровне конвергенции и подуровне сборки/разборки.



Рис. 10. Связь локальных сетей через АТМ

очень похож на AAL

Уровень AAL 5 очень похож на AAL 3/4 в том смысле, что он также обеспечивает передачу данных в режиме с установлением и без установления соединения, т.е. реализует сервис класса С и D. Однако, как показала практика, AAL 3/4 не удовлетворяет требованиям пользователей, работающих в режиме с установлением соединения, а также производителей оконечного оборудования. Дело в том, что в системе AAL 3/4 довольно велики заголовки и концевики блоков - каждые 44 байта снабжаются 4 байтами заголовка. Кроме того, система обнаружения ошибочных блоков, потерь и вставок блоков может не обеспечивать требуемой защиты при передаче очень больших потоков данных.

В результате был разработан новый тип AAL, названный AAL 5. Целью его является обеспечить сервис пользователю меньшими затратами и улучшить систему обнаружения ошибок на подуровне конвергенции. При этом все характеристики остались на подуровне конвергенции точно такими же, что и в AAL 3/4, т.е. система только обнаруживает ошибки, но не исправляет их, следит за наличием одиночных ошибок в составе протокольного блока и за соблюдением соответствия переданной и принятой последовательности данных. Отличия заключаются только в способе реализации всех этих функций. Единственная разница состоит в том, что в AAL 5 нет системы мультиплексирования нескольких соединений AAL в одно соединение АТМ. МККТТ рекомендует для сервиса класса С использовать режим AAL 5. Формат протокольного блока подуровня конвергенции представлен на рис. 13.



Рис. 13. Формат CPCS-PDU AAL типа 5

На подуровне конвергенции теперь к пользовательским данным добавляется только концевик, функции которого несколько изменились. Так, сюда попал проверочный полином, который, как мы помним, в уровне AAL 3/4 присутствовал только на подуровне сборки/разборки, результатом чего было то, что одним полиномом защищался маленький кусочек информации, что не помогало в некоторых случаях обнаруживать потери или вставки селлов. Теперь одним полиномом защищается весь протокольный блок и тем самым дается полная гарантия того, что любая ошибка, будь то вставка или потеря данных будет обнаружена.
Размер этого полинома увеличился до 4 байт. Тем самым кроме того, увеличилось быстродействие, поскольку обработать один длинный полином быстрее, чем 1000 коротких.

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

Что касается поля PAD, то оно перешло из подуровня сборки/разборки. Здесь оно используется для дополнения длины протокольного блока (с учетом концевика) до длины, кратной 48 байт.

Поля Btag и Etag в данном случае уже не нужны, поскольку проверочный полином закрывает весь протокольный блок, и с его помощью можно всегда определить принадлежность каждого селла именно к данному блоку.

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

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

Таким образом, использование уровня AAL 3/4 осталось только для мультиплексирования нескольких соединений AAL в одно соединение АТМ. Если этого не требуется, то лучше использовать AAL 5.

предназначен для передачи информации

Напомним, что уровень AAL 2 предназначен для передачи информации с переменной скоростью, но с необходимостью синхронизации передатчика и приемника. С первого взгляда видно, что эта задача намного сложнее предыдущей, поскольку AAL 1 заранее знает скорость работы, и, поэтому, передать данные синхронизации было гораздо проще. Кроме того, раз данные идут с переменной скоростью, типичным явлением будет то, что блоки данных окажутся заполненными только частично. В самом деле, нельзя же задерживать передачу уже поступивших бит до тех пор, пока источник соблаговолит передать еще данные. Иначе говоря, в потоке возможны паузы, причем переменной длины, т.е. разные блоки будут заполнены разным количеством данных. Общая структура протокольного блока подуровня сборки/разборки представлена на рис.7.



Рис.7. Структура протокольного блока на AAL 2

Поле SN в нем нам уже знакомо - это последовательный номер блока, который передается от подуровня конвергенции. Следующее поле - IT - Information Type. Дело в том, что в связи с возможными паузами в потоке необходимо описать границы сообщения между двумя паузами. Если этого не сделать, приемник не сможет включить у себя кодозащиту, поскольку неизвестно будет, сколько конкретно бит было защищено кодом. Это поле может иметь три значения: "Начало сообщения", "Середина сообщения" и "Конец сообщения". Вслед за этим полем идет собственно поле данных.

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

Таковы самые общие принципы функционирования уровня AAL 2. Дело в том, что ни работа подуровня конвергенции, ни детальное описание полей форматов до сих пор в рекомендациях не описаны и оставлены для дальнейшего изучения. Поэтому пока еще система с переменной скоростью VBR нигде не реализована. Однако, описанные здесь принципы будут соблюдены в дальнейшем, когда появится спецификация.




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

Уровень AAL 1 подразделяется на подуровень конвергенции и подуровень сборки/разборки. Их общее назначение было описано выше. Работой AAL 1 управляет специальная процедура называемая "объект управления уровнем адаптации", в функции которого входит следующее:

Установление соединения между парой объектов AAL 1; Переустановление соединений в случае сбоев; Отбой соединений; Наблюдение за входным потоком на предмет соблюдения принципа постоянства скорости; Наблюдение за качеством сервиса, предоставляемого уровнем АТМ для данного AAL соединения в плане проверки наличия потерь селлов.

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

Рассмотрим подробнее все составляющие системы AAL1.

Установление МРОА-соединения

В своей работе МРОА осуществляет следующие действия:

Конфигурация. Эта фаза сродни фазе конфигурации в LANE, когда все устройства загружают свои настраиваемые параметры; Распознавание. В этой фазе клиенты и серверы с помощью LECS узнают параметры друг друга; Определение клиента-получателя - Target Resolution. В этой фазе Ingress МРС определяет АТМ-адрес клиента-получателя (Egress) с целью установления до него прямого виртуального канала. Управление соединением (Connection management). Установление, поддержка и разъединение VC; Передача данных.

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

В процессе распознавания ingress клиент узнал МАС-адреса всех серверов MPS, с которыми он напрямую связан через свои ELAN (напомним, что поскольку клиент может подключаться к нескольким ELAN, то и серверов, в составе этих ELAN может быть несколько). Теперь главная задача ingress-клиента - распознавать наличие потоков данных в одном и том же направлении. Пока такого распознавания нет - весь трафик пойдет через соответствующий роутер. В тот момент, когда регулярность потока установлена, то ingress-клиент должен выяснить АТМ-адрес того egress клиента, к которому этот поток направляется, и установить до него прямое АТМ-соединение. Для того, чтобы выяснить это, ingress-клиент направляет своему серверу специальный запрос - МРОА Resolution Request. Если сервер в состоянии этот запрос обработать, то клиенту возвращается ответ, где указан соответствующий АТМ-адрес.

Ingress-сервер должен уметь обрабатывать поступающие ему от клиентов запросы. Если отыскиваемый egress-клиент локальный, т.е. он работает в паре с тем же сервером, что и ingress, то этот сервер сам сгенерирует ответ и направит его клиенту. В противном случае понадобится еще дополнительное общение между серверами с помощью сервера NHS. Исходящий (ingress) сервер при ретрансляции этого запроса подставляет свои данные вместо данных, указанных в запросе от клиента.
Имеется в виду IP-адрес и АТМ-адрес. Это гарантирует, что запрос вернется именно к этому серверу. Все данные, указанные в этом запросе, которые поступили от клиента, заносятся в специальный буфер. При поступлении ответа его содержимое перенаправляется ingress-клиенту, где он будет обработан вышеописанным образом.

В случае, если egress-клиент подключен не к тому серверу, что и ingress, то по сети отправляется Next Hop Resolution Request, и когда он достигает egress-сервера, то он отправляет своему клиенту запрос о настройке его внутренней таблицы - Cache Imposition Request. Этот запрос содержит данные о структуре кадров, реализуемых на противоположном конце, а также информация, необходимая для поддержки соединения. Клиент в свою очередь отвечает на этот запрос, указывая свои адреса и свой статус. Эти данные возвращаются по сети обратно серверу-отправителю в виде Next Hop Reply. Когда этот ответ дойдет до ingress-клиента, процедура определения клиента-получателя завершается, и ingress MPC переходит к процедуре установления прямого соединения.

На рисунке 26 изображена общая схема процесса взаимодействия между клиентами МРОА. МРС-1 - клиент-отправитель (ingress). При поступлении пакета от верхнего уровня (в случае, если MPC в составе МРОА Host) или от одной из подключенных рабочих станций (если MPC в составе пограничного устройства МРОА) он отправляется через LANE к роутеру в MPS-1. В случае, если количество пакетов, направляемых в один и тот же адрес достигло заданного значения, то принимается решение о необходимости установления прямого пути (shortcut). Передача пакетов по этому пути отличается от передачи по умолчанию тем, что в первом случае пакеты передаются без кадровых заголовков, т.е. в формате данных отсутствует структура кадра. Это сделано из-за того, что на удаленном конце, возможно, реализован другой протокол второго уровня.

Puc. 26. Установление прямого пути для передачи информации между клиентами

Преимущества такой схемы - в ускорении процесса передачи и улучшении качества сервиса.

|

Виртуальные соединения, необходимые для поддержки LANE

Для управления ELAN в системе предусматривается довольно много служебных виртуальных каналов. Все сообщения управления, такие, как запросы на подключение к ELAN и прочее проходят по специальным каналам, а обмен данными идет по отдельному каналу. Таким образом, создается целая сеть виртуальных соединений между клиентами LEC и другими объектами ELAN.

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

По управляющим канала данные никогда не передаются. Устанавливаются они во время фазы инициализации связи. О том, через какие фазы проходит процедура установления соединения и передачи данных мы поговорим чуть позже.

К каналам управления относятся:

а) Канал конфигурации - Configuration Direct VCC. Этот канал устанавливается между клиентом LEC и сервером конфигурации LECS для того, чтобы получить из этого сервера общую информацию конфигурации ELAN, в частности, адрес сервера LES. Однако, даже после подключения, находясь в фазе передачи данных этот канал необходимо сохранять для возможных последующих запросов, например, для получения информации о другом клиенте LEC.

б) Канал управления - Control Direct VCC. Этот канал устанавливается между клиентом и сервером LES для обмена управляющей информацией. Он также устанавливается во время фазы инициализации. Схема подключения LEC к LES показана на рис.17. На этом рисунке показан еще один канал - управляющий широковещательный VCC. Этот канал (необязательно) устанавливается сервером LES в конфигурации "точка-много точек", с помощью которого он может передавать информацию, которая нужна всем клиентам. Канал управления также сохраняется в течение всего времени нахождения данного клиента в составе ELAN.
Процедура установления однонаправленной связи типа "точка-много точек" описана в следующей главе.

Управляющий широковещательный VСС устанавливается однонаправленным, как и все соединения такого типа.

в) Соединения для передачи данных - Data Connections. Эти соединения связывают клиентов друг с другом и с сервером широковещания BUS. По этим соединениям и проходят кадры Ethernet или Token Ring. Хотя по этим каналам передаются одни и те же данные, структура связей между клиентами и между клиентом и сервером BUS различна. Так, связь между клиентами представляет собой обычный двунаправленный канал. Он устанавливается в том случае, когда клиент LEC точно знает АТМ-адрес того клиента, к которому подключена требуемая рабочая станция. Если же этот адрес ему неизвестен, клиент должен сформировать ARP-запрос к серверу LES, чтобы он сообщил ему этот адрес. Процедура принципиально ничем не отличается от той, которая реализована в обычной локальной сети, только там запрашивается другой тип адреса. Когда клиент получит ARP-ответ, то он сразу же начнет устанавливать канал для передачи данных.

В предыдущем материале мы уже вскользь упоминали, что в системе АТМ-соединение будет установлено только в том случае, если у всех его потенциальных участников имеется в наличии достаточно свободной пропускной способности, чтобы обслужить это соединение. Если же этих ресурсов нет, то соединение получает отказ. Ведь сеть АТМ не знает о том, что это соединение относится к LANE и обрабатывает его самым обычным образом. Следовательно, может возникнуть вопрос: как же может работать система LANE, если к части ее участников удалось установить соединение, а к другой части нет. Тогда уже не будет полной эмуляции обычной ЛВС.

Рис. 17. Управляющие соединения между LEC и LES

Дело в том, что в случае, когда у АТМ-устройства, где находится клиент, нет свободной пропускной способности, то будет отбито соединение с другим клиентом и за счет освободившейся пропускной способности установлено требуемое.



Соединение для передачи данных между клиентом и сервером BUS, по которому также передаются данные, устанавливается по такому же принципу, что и между клиентом и сервером LES, т.е. может организовываться два разных виртуальных канала. Один, называемый широковещательным каналом передачи - Multicast Send VCC является каналом "точка-точка" между этими объектами. Он устанавливается по инициативе клиента во время фазы инициализации. АТМ-адрес сервера BUS сообщается клиенту сервером LECS. Этот канал используется в тех случаях, когда требуется передать широковещательное сообщение ко всем рабочим станциям эмулированной LAN, а также в тех случаях, когда клиент не знает имя удаленного клиента, и, поэтому, необходимо передать всем клиентам широковещательный запрос, чтобы один из клиентов ответил, что требуемая рабочая станция подключена к нему.

Сам сервер BUS может в ответ на установление этого канала установить еще одно соединение "типа точка-много точек" по аналогии с сервером LES. В рамках этого канала будут передаваться эти широковещательные запросы. Схема подключения клиента к серверу BUS изображена на рис.18.



Рис. 18. Соединения между LEC и BUS

Восстановление на приемнике тактовой частоты передатчика

1.2.1. Восстановление на приемнике тактовой частоты передатчика

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

В рекомендации приведен способ такого доведения, состоящий в передаче специальных синхронных временных меток - Sinchronous Residual Time Stamp - SRTS, показанный на рис 5.3, который сводится к следующему.

Предположим, что абонент заказал соединение на скорости 2048 кбит/сек, в то время как сеть работает на скорости fсети =155.52 Мбит/сек. Генерация временных меток производится на достаточно длительном интервале времени N с использованием дополнительной промежуточной частоты fпром, соизмеримой (но не равной) с частотой пользователя fпольз. Для передачи сигналов цифровых систем Е/Т рекомендуется использовать генерацию меток на интервале N, равном 3008 периодов частоты абонента, т.е. время передачи 3008 бит информации (это число точно равно объему поля данных восьми протокольных блоков, выдаваемых на уровень АТМ). Промежуточная частота fпром должна быть не более, чем в два раза выше пользовательской частоты fпольз, которую определил абонент при запросе соединения.

В идеале, т.е. когда и частота сети, и пользовательская частота стабильны в цикл N (который составляет Т секунд) будет укладываться всегда одинаковое количество периодов промежуточной тактовой частоты, которое не обязательно будет целым. Пусть, например, для описываемого примера частота fпром выбрана равной 3000 кбит/сек.
Тогда при N=3008 (Т=N/ fпольз =1468, 75 ms) теоретическое количество периодов промежуточной частоты fпром составит Mном=3*106*1468,75*10-6=4436.

Рис. 4. Понятие синхронной остаточной временной метки (SRTS)

Все исходные значения известны и передатчику и приемнику, поэтому величина Мном им также известна.

Далее, фактически количество периодов промежуточной частоты в реальной работе не будет равна 4436, поскольку частоты у абонента и у сети не могут быть абсолютно стабильными, однако, они не будут различаться сильно. Так, например, в рекомендации указывается, что за время Т расхождение частот промежуточной частоты fпром не накопится больше, чем на 6 периодов. Эти предельно допустимые отклонения показаны на рис.4 интервалом от Мmin до Mmax.

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

Блок-схема процедуры вычисления временной метки показана на рис.5. Здесь счетчик А - это просто делитель частоты, который вырабатывает сигналы с интервалом времени, равным 3008 периодов частоты абонента fпольз. Блок ФОР - это формирователь промежуточной частоты на базе тактовой частоты сети (с помощью этого блока сетевую частоту 155.52 Мбит/сек преобразовали в 3Мбит/сек). Четырехбитный счетчик подсчитывает число периодов частоты fпром. Поскольку счетчик всего четырехбитный, то за время Т на его выходе будет не непосредственно количество периодов, а остаток его деления на 16. Этот остаток и представляет собой временную метку. Триггер пропускает на выход схемы значение метки в момент окончания интервала Т. В нашем примере в случае идеальных значений частот этот остаток будет равен 4 (4436/16=277*16+4). Если этот остаток увеличивается, то, значит, частота абонента меньше расчетной (если брать сетевую частоту неизменной) и наоборот.





Рис. 5. Генерация остаточной временной метки (RTS)

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

fпольз=2048ґ(1+(4-3)/4436)=2048,46кбит/сек,

где 4-3 - разность между номинальным и фактическим значением временной метки. Слагаемое (4-3)/4436 определяет отличие реальной частоты абонента на передаче от номинальной - это как раз доля, соответствующая одному периоду частоты fпром. Все вычисления даны в килобитах в секунду.

Таким образом, оба абонента будут работать с одинаковой частотой.

Временная метка передается приемнику в составе бита CSI заголовка блока SAR-PDU. Раз метка четырехбитовая, то для ее передачи требуется 4 таких блока. Однако, мы помним, что период синхронизации вычислялся как время передачи восьми протокольных блоков, т.е. в резерве остаются еще 4 бита, которые оставлены для других применений. Метка передается в составе нечетного блока в рамках цикла синхронизации, т.е. в блоках 1, 3, 5, 7.

Сеть АТМ разрабатывалась как универсальная

Сеть АТМ разрабатывалась как универсальная сеть, с помощью которой можно передавать самую различную информацию. Однако, очень многие приложения не могут непосредственно использовать сеть, поскольку необходимо выполнять различные требования, предъявляемые этими приложениями к системе передачи. Для того, чтобы реализовывать эти требования и согласовать их с технологическими параметрами сети существует так называемый уровень адаптации, который для различных пользовательских служб реализовывается по-разному. Иными словами, назначение уровня адаптации - ATM adaptation level - в том, чтобы приспособить информацию верхних уровней к сети АТМ. Сеть не может обслуживать информацию до тех пор, пока она не будет приведена к специфическому формату и иметь необходимые размеры. Она может работать только с селлами и их полем данных.
Так, информационные блоки, такие, как кадры, пакеты или непрерывный поток цифровых данных несовместимы с требованиями АТМ, поскольку их формат отличается от формата селла. Обычно все пользовательские данные имеют размер, гораздо больший, чем размер селла, и, более того, их размер переменный. Функции AAL таким образом задают мост между информацией пользователя и селлами АТМ.
AAL выполняет набор функций по вкладыванию пользовательской информации в блоки данных такого размера, чтобы их можно было бы вставить в селл. Соответственно, эти функции сильно различаются для работы с разной исходной информацией. Действительно, пользователем сети может быть рабочая станция, роутер, осуществляющий переход данных из сети АТМ в сеть другой природы и обратно, это может быть цифровая система коммутации каналов типа Е1 или DS-1 и т.д. По сути AAL - это граница сети.
Рабочая станция посылает данные в виде, например, IP-пакетов, которые гораздо больше селла. Цифровая система Е1 работает с непрерывным потоком данных со строго фиксированной скоростью 2048 кбит/сек. Очевидно, что с такими разными по своей природе потоками нужно работать по-разному.
В зависимости от различных требований, предъявляемых пользовательскими потоками уровень AAL разбивается на несколько категорий, каждая из которых задает различный тип сервиса для пользователя.
Все эти сервисные классы характеризуются набором из трех ключевых параметров, которые мы рассмотрим ниже. В зависимости от значения каждого из этих параметров на сегодня определено пять типов сервиса. Эти типы и значения каждого из параметров показаны на рис. 1. По сути все типы пользовательских данных можно разбить по классам сервиса в зависимости от необходимого набора этих трех параметров, которыми являются:
Наличие или отсутствие необходимости организовывать поддержку общего тактового сигнала на обоих концах соединения. Такая поддержка необходима в первую очередь для передачи цифрового потока, организованного по синхронной системе передачи типа Е1 или DS-1. Теоретически, обе системы на обоих концах соединения АТМ могут использовать каждый свой тактовый сигнал, частота и фаза которых, конечно, будут немного отличаться. Однако, в реальных системах на канале имеется всегда только один источник тактовой частоты, и, поэтому, AAL должен обеспечить поддержку синхронизации обоих устройств своими средствами. Скорость передачи данных фиксированная или переменная. Имеется в виду насколько регулярным является пользовательский поток. Такие приложения, как система Е1 или DS-1 требуют поддержки постоянной скорости работы, а системы TCP/IP или Х.25 работают в пульсирующем режиме - всегда в потоке передачи данных бывают паузы, которых не может быть в системе Е1. Требуется или не требуется предварительное установление соединения. Дело в том, что некоторые приложения, например, Х.25, перед началом обмена данными выполняют служебный диалог между оконечными станциями для того, чтобы удостовериться в возможности работы. Приложения типа TCP/IP этого не требуют. Следовательно, система АТМ может оповещать приложение о том, что к нему установлено соединение, а может этого и не делать. Этот параметр определяет необходимость такого оповещения для работы.

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


Классы А и В, используются для аудио- и видеоприложений, а также для передачи цифровых регулярных потоков. Для этих классов общим является требование по синхронизации оконечных установок и необходимость предварительного оповещения приемника о готовящемся обмене. Класс А предназначен для работы на постоянной скорости и поэтому называется CBR - constant bit rate, и это на сегодняшний день один из двух наиболее часто используемых классов. Класс В определен для работы с переменной скоростью, однако, пока он не имеет спецификации. Классы С и D используются для передачи данных, причем не только абонентских, но и между объектами управления. Класс С обеспечивает соединения типа connection-oriented, класс D - connection-less. Надо заметить, что, конечно, соединения типа connection-less гораздо более популярны, чем connection-oriented в первую очередь потому, что по этому принципу работают все локальные вычислительные сети, сеть Интернет и некоторые другие менее популярные системы. Поэтому класс D наряду с классом А наиболее популярен сегодня.
Для пояснения общей структуры уровня AAL любого типа рассмотрим рис.2, где изображена структура стека уровней АТМ. Из него видно, что уровень AAL состоит из двух подуровней - конвергенции (Convergence Sublayer - CS) и сборки/разборки (Segmentation And Reassembly - SAR).

Рис. 2. Схема функций различных подуровней модели
Основное назначение подуровня сборки/разборки состоит в разбивке пользовательского потока на блоки, пригодные для укладывания их в селл АТМ, и обратное преобразование на приеме. Назначение подуровня конвергенции более интеллектуальное, и они уже зависят от конкретного типа AAL. В эти функции могут входить: идентификация сообщения, восстановления синхросигнала и т.д. Для некоторых типов AAL подуровень конвергенции разбивается еще на два подуровня: общая часть - common part convergence sublayer - CPCS и сервис-специфическую часть - service specific convergence sublayer - SSCS. Некоторым приложениям достаточно тех условий, которые предоставляет собственно сеть, и они уровень AAL пропускают.
Обмен сервисными блоками данных (SDU) между AAL и АТМ уровнями происходит через специальную сервисную точку доступа. Для различных типов AAL предусмотрены разные адреса этих точек с тем, чтобы на приеме уровень АТМ знал, какой конкретно AAL запускать.
Теперь, после того, как мы описали общие принципы, по которым разделяется уровень AAL, рассмотрим те его конкретные варианты, которые описаны в спецификациях. Как видно из рис. 1, классу А соответствует AAL 1, классу В - AAL 2, классу C - AAL 3/4, классу D - AAL 5.
|

---

---