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

В протоколе IP-адреса устройств в сети назначаются независимо от их физиче­ских адресов. Для доставки информации по сети ATM программное обеспечение должно определить соответствие АТМ-адреса устройства с его IP-адресом. При­кладные программы в большинстве случаев используют именно IP-адреса. Для определения соответствия между адресами необходим специальный протокол.

В локальных сетях, поддерживающих механизм широковещания на каналь­ном уровне, эта задача решается с помощью протокола ARP. Однако сеть ATM относится к классу NBMA (Non-Broadcast Multiple Access Networks, нешироко­вещательные сети со множественным доступом).

Для решения вопросов, связанных с функционированием протокола IP в сетях ATM, рабочая группа ION разработала технологию «классический IP и ARP для ATM» (Classical IP and ARP over ATM) и опубликовала ее в документе RFC 1577 в январе 1994 года. Эта технология предназначена для поддержки протокола IP в одной логической подсети (Logical IP Subnet, LIS) сети ATM. Логическая подсеть состоит из группы устройств, которые подключены к одной сети ATM и принадлежат к одной и той же IP-подсети (то есть используют единые номер сети/подсети и маску подсети).

Для определения соответствия логических и физических адресов устройств каждая подсеть LIS включает один сервер ATMARP, который поддерживает од­ноименный протокол. Каждое устройство (клиенты LIS) в логической подсети настраивается с уникальным АТМ-адресом этого сервера. Протокол ATMARP основан на протоколе ARP, но включает ряд дополнений, необходимых для ра­боты в нешироковещательной сети.

Основная задача сервера ATMARP заключается в управлении специальной таблицей, записи которой определяют соответствие между IP- и АТМ-адресами устройств. Область действия сервера не ограничивается одной логической под­сетью, он может обслуживать клиентов в нескольких подсетях. Внутренняя таблица сервера строится в результате обмена сообщениями между ним и клиентами.

Когда клиент начинает свою работу в логической подсети, он устанавливает виртуальное соединение с сервером по известному ему АТМ-адресу сервера. После того как сервер обнаружил соединение, он посылает запрос Inverse ARP (InATMARP) (рис. 16.3). Цель этого запроса состоит в получении IP- и АТМ-адреса клиента, который возвращает их в ответном сообщении. Сервер проверит записи в своей таблице и, если этих адресов нет в таблице, добавит новую за­пись, которая будет считаться действительной минимум 20 мин.

Если другому клиенту в этой логической подсети необходимо передать дан­ные клиенту 1, и соединение уже установлено, то информация может быть по­слана немедленно через это соединение. Если соединение не установлено, а АТМ-адрес клиента 1 неизвестен, потребуются услуги сервера ATMARP, кото­рому будет послан запрос ATMARP, содержащий IP-адрес клиента 1. Если в таблице сервера существует запись для этого IP-адреса, сервер вернет в ответе ATMARP соответствующий АТМ-адрес, который требуется для установления виртуального соединения (рис. 16.4). Если в таблице такой записи не существу­ет, будет послано сообщение ATM_NAK. В табл. 16.1 перечислены сообщения ATMARP.

Таблица 16.1. Сообщения протокола ATMARP

Сообщение	Описание
Запрос ATMARP	Посылается от клиента к серверу для получения АТМ-адреса получателя. Сообщение содержит IP- и АТМ-адреса отправителя (клиента) и IP-адрес получателя
Ответ ATMARP	Посылается сервером в ответ на запрос ATMARP. Содержит искомый АТМ-адрес получателя
Запрос InATMARP	Посылается от сервера к клиенту для получения его IP-адреса. Содержит АТМ-адрес клиента, IP- и АТМ-адреса сервера
Ответ InATMARP	Посылается в ответ на запрос InATMARP от клиента. Содержит IP-адрес клиента
Ответ ATMARP-NAK	Отрицательный ответ на запрос ATMARP. Посылается от сервера к клиенту

При очевидной простоте классический IP не лишен некоторых недостатков. Основной недостаток связан именно с его «классичностью»: любые данные, ад­ресованные за пределы логической подсети, должны посылаться маршрутизато­ру по умолчанию. Такая схема работы становится менее эффективной в сетях ATM, поскольку в них может существовать множество логических подсетей и поддерживается прямое взаимодействие между двумя клиентами в двух различ­ных подсетях. Однако согласно жестким требованиям документа RFC 1577, дан­ные, передаваемые между двумя устройствами в различных подсетях, должны проходить через маршрутизаторы, связывающие подсети.

Дополнительным обстоятельством, на которое важно обратить внимание, является процесс регистрации адресов. В настоящее время сервер ATMARP ис­пользует сообщение InATMARP для определения адресов клиента. Но, допус­тим, функции ATMARP-сервера выполняет маршрутизатор, обслуживающий множество клиентов, поддерживающих протоколы, отличные от IP (например, IPX или AppleTalk). По определению, сервер ATMARP посылает запрос InAT­MARP всем клиентам логической подсети, даже если они не поддерживают про­токол IP. Это приводит к нерациональному использованию ресурсов клиентов и маршрутизатора. Решением проблемы может быть упрощение процедуры регис­трации, при которой она будет выполняться при первом запросе ATMARP от клиента. Ожидается, что эти изменения будут внесены в следующую редакцию документа RFC 1577.

Кроме того, предполагается устранить ограничение, связанное с тем, что в логической подсети может быть только один сервер ATMARP. Такая схема может вызвать проблемы при выходе из строя этого сервера. Поддержка не­скольких серверов в логической подсети устранит это ограничение и повысит гибкость реализации описанной схемы. Синхронизация содержимого таблиц серве­ров может выполняться через виртуальные соединения с помощью специального протокола синхронизации (Server Cache Synchronization Protocol, SCSP), рабо­ты над которым ведутся.