Методы инкапсуляции данных
Выбор конкретного механизма инкапсуляции трафика канального и более высоких уровней модели OSI в ячейки ATM оказывает существенное влияние на стоимость, производительность, масштабируемость и простоту эксплуатации сети в целом. В сетях доступа на основе ATM over ADSL наибольшее распространение получили четыре метода инкапсуляции (рис. 2).
Рис.2. Методы инкапсуляции трафика
Транспортировка пакетов Ethernet по сети асинхронной передачи. Этот метод, определенный в документе RFC 1483 консорциума Internet Engineering Task Force (IETF), сводится к простому встраиванию пакетов Ethernet в блоки данных (PDU) пятого адаптационного уровня ATM (AAL5), которые затем транспортируются по соединениям PVC. Основные преимущества такого решения заключаются в простоте реализации и совместимости с огромным парком оборудования Ethernet, используемого по всему миру. Недостаток состоит лишь в том, что конечный сегмент сети доступа остается ориентированным на классическую пакетную передачу. Это обстоятельство не сулит особых неприятностей, если все ограничивается обычной Web-навигацией или удаленным доступом к файлам на корпоративном сервере, однако негативно сказывается на работе пользователей, когда дело доходит до передачи мультимедиа-трафика или запуска приложений реального времени. Впрочем, неэффективность транспортировки больших пакетов путем их разбиения на ячейки ATM (которые к тому же должны сосуществовать с "естественными" 53-байтными ячейками) минимизируется благодаря высокой скорости на линиях ADSL.
Передача IP-пакетов по сети ATM (IP over ATM). В настоящее время это самый распространенный способ транспортировки IP-трафика по сети ATM, поддерживаемый разнообразными моделями ATM-устройств. Появление данной технологии предвосхитило создание стандарта на обработку многопротокольного трафика в сети асинхронной передачи MultiProtocol over ATM (MPOA). В документе RFC 1577 регламентированы как непосредственная инкапсуляция IP-трафика в ячейки ATM все на том же уровне AAL5, так и функции преобразования адресов для постоянных и коммутируемых виртуальных соединений.
Операции с соединениями SVC были позднее определены в документе RFC 1755.
PPP over ATM. Технические спецификации IETF, регламентирующие данный метод, пока существуют на уровне проекта. Как и в предыдущих случаях, ключевая роль в транспортировке инкапсулированного трафика отводится уровню AAL5. Несмотря на отсутствие индустриального стандарта, передача трафика PPP по сетям ATM получает все большую поддержку производителей. С подачи нескольких ведущих поставщиков (Alcatel, Cisco, FORE Systems, U.S. Robotics, Westell) корпорация Microsoft стала включать функции PPP over ATM в свои продукты. Последнее обстоятельство представляется особенно важным с точки зрения совместимости транспортных механизмов на всем протяжении пути следования данных - от пользовательского оборудования до сети ISP. Использование Point-to-Point Protocol гарантирует высокую совместимость данной технологии с традиционными процедурами сетевой обработки. Наконец, реализация в сетях с протоколом PPP алгоритмов динамического присвоения IP-адресов, маршрутизации по умолчанию и возможность применения серверов DNS заметно упрощают удаленное администрирование.
Непосредственное использование ATM на "последней миле". В этом случае обмен данными между настольным компьютером и сетью ATM можно осуществлять напрямую, без "посреднических" протоколов вроде TCP/IP. На практике для такой цели чаще всего применяются расширения Winsock2 ATM компании Microsoft.
Если при использовании других методов соединения PVC заканчиваются в мультиплексоре DSLAM, то в данном случае они простираются до абонентского оборудования. Приложения, непосредственно работающие с трафиком ATM, пока не получили широкого распространения, однако их очевидные преимущества состоят в высокой производительности, малом значении задержки при передаче данных, в поддержке мультимедиа-трафика и разных уровней QoS, хорошей масштабируемости (поскольку вместо IP-адресов задействуются схемы адресации ATM). Кроме того, появляется возможность обойтись без дорогостоящих средств межсетевого взаимодействия как на уровне абонентских устройств доступа, так и в центральном офисе NAP или на входе в сеть Internet-провайдера.
Недостатком указанного подхода является необходимость организации отдельного соединения PVC для каждого пользователя, тогда как, скажем, в методах, основанных на сохранении кадров PPP (пусть и в инкапсулированном виде), количество таких соединений можно значительно уменьшить.
В отношении последних двух методов инкапсуляции следует сделать ряд важных замечаний. Как известно, PPP практически всегда используется в сетях доступа в качестве протокола второго уровня - идет ли речь о подключении через аналоговый модем или по линии ISDN. Пакеты вышележащих протоколов, вроде IP или IPX, упаковываются в кадры PPP передающим оборудованием, а затем восстанавливаются принимающим устройством. Может показаться, что полное замещение PPP соответствующими конструкциями ATM упростит сетевую обработку, поскольку позволит избавиться от лишней процедуры инкапсуляции пакетов. Однако инкапсуляция PPP over ATM имеет и сильные стороны.
Прежде всего, из-за повсеместной распространенности PPP полный переход на ATM может потребовать настолько существенной модернизации коммуникационных приложений, что проще прибегнуть к инкапсуляции трафика. Еще существеннее то обстоятельство, что в протоколе PPP предусмотрены средства аутентификации пользователей и защиты данных, которые невозможно получить в среде ATM, не переписав изрядной доли используемого ПО.
Процедуру инкапсуляции выполняет модем ATM/ADSL, на вход которого настольный компьютер посылает обычные кадры PPP. Модем сначала преобразует эти кадры в блоки данных AAL5 PDU, а затем разбивает их на части для отправки в сеть в составе ячеек ATM. На принимающем конце соединения те же операции выполняются в обратном порядке. Главное достоинство такой схемы состоит в прозрачности промежуточных преобразований для оконечного оборудования (пользовательского ПК и сервера, к которому осуществляется доступ).
Впрочем, схема PPP over ATM также таит в себе подводные камни. Изначально создававшийся для удаленного доступа в сеть с единичного компьютера, протокол PPP в своем классическом виде плохо приспособлен для дистанционного подключения локальной сети удаленного офиса.Кроме того, он создает значительную нагрузку на ЦП компьютеров, обрабатывающих кадры этого протокола, что может сильно ограничивать расширяемость основанных на нем решений.
