IP и ARP через ATM

Данный документ содержит описание передачи сообщений протоколов IP и ARP через ATM, основанное на RFC 1577.

Автор RFC 1577: M. Laubach, Hewlett-Packard Laboratories. Дата RFC – январь 1994.

PDF

Содержание

От переводчика

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

Англоязычные названия параметров будут переводиться, но использоваться далее в тексте как правило в первоначальном виде. Это объясняется тем, что вероятность встретить русскоязычные обозначения при настройке какого-либо устройства достаточно мала.

Введение

Данный документ описывает механизм, обеспечивающий передачу данных протоколов IP и ARP через сети ATM. Данные передаются в пределах так называемой LIS (Logical IP Subnetwork – Логическая IP-подсеть). Термин LIS более подробно определен в третьем разделе данного документа. Для передачи данных между IP-подсетями (LIS в данном случае) необходим маршрутизатор, прошу прощения за напоминание. Данный документ не описывает передачу данных за пределами ATM-сети, т. е. не рассматривается передача данных через подключенные локальные сети, такие, как Ethernet или Token Ring. Сеть ATM рассматривается не более как канальный уровень передачи данных, обеспечивающий соответствующий сервис для протоколов IP и ARP, т. е. обсуждается передача данных в ATM и только в ATM. В IP через ATM в качестве протокола распознавания адреса используется ATMARP – ATM Address Resolution Protocol.

Необходимо помнить, что между ATM-сетями и обычными локальными сетями, такими, как Ethernet, существуют некоторые отличия:

Сеть ATM использует для передачи данных так называемые VC (Virtual connection – Виртуальные соединения). VC могут устанавливаться (конфигурироваться) вручную (PVC – Permanent Virtual Connection) или автоматически (SVC – Switched Virtual Connection).

Передаваемые через сеть ATM данные помещаются в 53-байтные ячейки (48 байт данных и 5 байт заголовка).

Функции инкапсуляции PDU сетевых протоколов в поток данных ATM-сети выполняет ATM Adaptation Layer (AAL) – самый верхний уровень ATM-модели. AAL бывают разных типов, в данном документе рассматривается только один из них – AAL5. При установке VC через сеть ATM с ним ассоциируется определенный тип AAL. После установки соединения стороны, в нем участвующие, сохраняют информацию о используемом типе AAL. Сами передаваемые ячейки информацию о типе AAL не содержат.
В случае PVC тип используемого AAL конфигурируется вручную. В случае SVC тип согласовывается устройствами автоматически с помощью процедур сигнализации (Q.93B). После того, как соединение установлено и началась передача данных через коммутаторы ATM последним абсолютно все равно, трафик какого типа AAL через них передается.
AAL5 формирует пакеты, которые могут содержать до (64КБ – 1) октетов пользовательских данных. Затем пакет AAL5 передается уровню SAR, который поделит его на 48-байтные ячейки. 48-байтные ячейки передаются в свою очередь уровню ATM (в данном случае это название одного из уровней общей ATM-модели), который добавит к ним 5-байтные заголовки. Кроме добавления заголовков уровень ATM выполняет еще некоторые функции, которые в данном документе не обсуждаются.
Ячейки, составляющие пакет AAL5, передаются последовательно друг за другом, от начала пакета до его конца. AAL5 не обеспечивает подтверждения получения информации, т. е. не гарантирует ее доставку. Подобные функции оставляются «на совесть» протоколов более высокого уровня.

Сигнализация, заданная Форумом ATM на момент создания RFC 1577, определяла установку VC следующих типов: точка – точка (point-to-point) и точка – много точек (point-to-multipoint). VC типа много точек – много точек (multipoint-multipoint) на момент создания RFC определены не были.

RFC 1577 описывает использование «классического» IP в сетях ATM. Это означает, что в качестве канального уровня передачи данных используется только сеть ATM, т. е. в рабочих станциях установлены соответствующие сетевые адаптеры. Передача данных в другие сетевые технологии не рассматривается. Естественно, возможна ситуация, когда одно из устройств в такой сети будет передавать IP-трафик в сеть Ethernet, например, но функционирование такого устройства в RFC 1577 не регламентируется. Кроме того, «классичность» рассматриваемой модели подразумевает также следующее:

Внутри LIS всеми устройствами для передачи данных используется один и тот же размер MTU (maximum transmission unit – максимальный передаваемый элемент).

По умолчанию для IP-пакетов используется инкапсуляция LLC/SNAP.

Процессы IP-маршрутизации в ATM-сети не изменяются, т. е. остаются теми же, что и любой другой сети.

Установка соответствия IP адреса и ATM адреса устройства (распознавание адреса) производится с помощью ATMARP, который функционирует в пределах LIS. С точки зрения пользователя, ATMARP является аналогом протокола ARP, разработанным для ATM-сетей.

Для соединения каждых двух IP-устройств в сети ATM устанавливается отдельный VC.

Конфигурация подсетей IP

LIS – Logical IP Subnetwork – в сети ATM является аналогом IP-подсети в других сетях. Каждая LIS функционирует независимо от других LIS, даже если они находятся в той же сети ATM. Хосты могут передавать информацию друг другу путем установления VC только внутри LIS. Для пересылки информации хостам в других LIS необходимо использовать IP-маршрутизатор, подключенный к сети ATM. Соответственно, такой маршрутизатор будет участвовать более чем в одной LIS.

К хостам и маршрутизаторам, функционирующим в пределах LIS, предъявляются следующие требования:

Все члены LIS должны иметь IP-адреса, принадлежащие к одной IP-подсети, а также, естественно, одинаковую маску.

Все члены LIS должны быть непосредственно подключены к ATM-сети.

Передача информации за пределы LIS должна осуществляться через маршрутизатор.

Все члены LIS должны поддерживать механизм распознавания IP-адресов в ATM-адреса (ATMARP), а также обратный механизм (InATMARP) при использовании SVC. Далее, все члены LIS должны поддерживать механизм распознавания номеров VC в IP-адреса (InATMARP) при использовании PVC. Данные механизмы описан в разделе 6.

Каждый член LIS должен иметь возможность установить соединение (VC) с любым другим членом LIS.

Ниже приведен перечень параметров, которые должно поддерживать любое IP-устройство, подключаемое к сети ATM.

ATM hardware address (аппаратный адрес ATM). ATM-адрес конкретной IP-станции.

ATMARP Request Address (адрес ATMARP-запроса) – atm$arp-req. atm$arp-req является ATM-адресом сервера ATMARP. Каждая LIS имеет свой сервер ATMARP. В сети ATM с использованием SVC сервер ATMARP используется рабочими станциями для распознавания адресов сетевых протоколов в ATM-адреса. В том случае, если используются PVC, сервер ATMARP не нужен.

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

Формат пакета

При реализации передачи IP через ATM в соответствии с RFC 1577 обязательно должна поддерживаться инкапсуляция LLC/SNAP. Данная инкапсуляция используется при передаче данных по умолчанию. Могут использоваться и другие методы инкапсуляции, однако если не оговорено отдельно, в дальнейшем в настоящем документе будет подразумеваться использование инкапсуляции LLC/SNAP. В принципе метод инкапсуляции может согласовываться автоматически при установке соединения, однако в данном документе подобные вопросы – не обсуждаются.

Размер MTU

По умолчанию IP станциях, работающих через сеть ATM, должен использоваться размер MTU, равный 9180 октетов. Размер заголовка LLC/SNAP составляет 8 октетов, таким образом по умолчанию размер поля данных пакета AAL5 составляет 9188 октетов. В LIS может использоваться другой размер MTU, но только в том случае, если он будет одинаков для всех станций внутри LIS.

Размер MTU может согласовываться автоматически при установке соединения, однако в данном документе подобные вопросы – не обсуждаются.

Механизм распознавания адресов.

В качестве механизма распознавания адресов в LIS должны использоваться протоколы ATMARP (ATM Address Resolution Protocol) и InATMARP (Inverse ATM Address Resolution Protocol). Протокол ATMARP практически есть ARP, приспособленный к работе в сетях ATM. В свою очередь, InATMARP является протоколом InARP, приспособленным к работе там же. IP станции в сетях ATM должны поддерживать оба этих протокола. Механизмы использования этих протоколов в сетях PVC и SVC отличаются друг от друга.

PVC

При использовании PVC IP-станция должна иметь механизм для определения того, какие PVC с кем/чем ее связывают, а также на каких PVC какие методы инкапсуляции используются.

При использовании PVC с инкапсуляцией LLC/SNAP IP-станция должна поддерживать на них протокол InATMARP. При получении InATMARP-запроса или InATMARP-ответа по какому-либо VC станция должна уметь ставить в соответствие номер VC и соответствующую адресную информацию.

Если при формировании InATMARP-пакета неизвестен ATM-адрес источника и/или получателя, поле длины соответствующего адреса должно быть установлено в ноль (0). Если соответствующий адрес известен, поле длины должно содержать значение длины адреса. Более детально формат пакета InATMARP рассмотрен позднее.

При получении InATMARP-ответа станция вносит полученную информацию в свою таблицу ATMARP. Информация, содержащаяся в таблице, с течением времени устаревает (aging). Обновление адресной информации является функцией самой IP-станции. Раздел 6.5 содержит описание механизма «устаревания».

SVC

ATM является сетью, не поддерживающей широковещательных сообщений. Это означает отсутствие механизма, позволяющего станции послать пакет/ячейку данных, которая будет получена всеми остальными станциями сети. Соответственно, необходим механизм, позволяющий в среде SVC работать с протоколом ATMARP. Отсюда мы делаем вывод, что для каждой LIS в сети ATM должен поддерживаться свой ATMARP-сервер. Данный сервер должен иметь возможность устанавливать соответствие ATM и IP адресов для каждой станции в LIS.

Сервер ATMARP

Сам по себе ATMARP-сервер (далее в данном разделе – сервер) не является инициатором установки соединений. Соединения с сервером должны устанавливать ATM-станции – участники LIS, т. е. каждая станция в LIS устанавливает с сервером соединение (VC) типа точка-точка. В ходе установки соединения оговаривается использование LLC/SNAP-инкапсуляции. После того, как соединение установлено, сервер посылает по этому соединению InATMARP-запрос в целях определения IP-адреса подключившейся станции. Станция посылает ответный пакет InATMARP, содержащий требуемую информацию. На основе полученных данных сервер строит адресную таблицу ATMARP.

Механизм поддержки ATMARP-сервера требует, чтобы каждый клиент LIS имел сконфигурированный на нем вручную адрес сервера ATMARP (atm$arp-req). В пределах LIS может функционировать один и только один ATMARP-сервер. Также рекомендуется, дабы этот сервер поддерживал IP-стек. Соответственно, получившаяся IP-станция в качестве ATMARP сервера должна будет использовать сама себя, что должно найти отражение в ее конфигурации – так же вручную.

Сервер может поддерживать одновременно несколько LIS. Для каждой поддерживаемой LIS сервер должен иметь соответствующий IP-адрес.

RFC 1577 не рассматривает вопросы резервирования ATMARP-серверов, хотя отмечает, что это было бы неплохо ;-).

Требования к функционированию сервера ATMARP

Сервер ATMARP не устанавливает соединения со станциями – участниками LIS. Инициаторами установки соединения являются сами рабочие станции. Если установленный VC поддерживает LLC/SNAP-инкапсуляцию, сервер посылает по этому VC InATMARP-запрос в целях определения IP-адреса подключившейся станции (InARP_REQUEST). Если сервер поддерживает несколько IP-подсетей, запрос посылается для каждой. После получения ответного пакета (InARP_REPLY) сервер проверяет полученные данные, а затем помещает их в свою ATMARP-таблицу, или обновляет счетчик времени в том случае, если полученная информация уже в таблице содержится. ATMARP-таблица содержит пары ATM-адрес – IP-адрес плюс счетчик (таймер), показывающий, насколько давно эта информация получена или обновлена. Если сервер получает InARP_REPLY с IP-адресом, уже содержащимся в его таблице, но при этом полученный ATM-адрес не соответствует табличной информации, и VC, соответствующий записи в таблице, открыт (функционирует), пакет InARP_REPLY будет игнорирован. Иными словами, у нас есть запись в ATMARP-таблице, т. е. пара ATM-адрес – IP-адрес какой-либо станции, а также установленный с ней VC. Если мы получаем информацию о том, что кто-то другой в сети имеет такой же IP-адрес, то мы такую информацию игнорируем.

Теперь собственно о том, зачем ATMARP-сервер нужен. Какая-либо станция желает передать IP-данные другой станции, но еще не установила с ней соединения, и не знает ее ATM-адреса. Такая станция сначала должна запросить у ATMARP-сервера, какой ATM-адрес соответствует такому-то IP-адресу. Станция посылает ATMARP-запрос – ARP_REQUEST. Если сервер имеет требуемую информацию в своей ATMARP-таблице, то он отвечает пакетом ARP_REPLY, содержащим требуемую информацию. Если требуемых данных у него нет, сервер отвечает пакетом ARP_NAK – «отрицательный» ARP-ответ. Использование пакета ARP_NAK является расширением протокола ATMARP. В случае использования такого типа пакета запрашивающая станция в состоянии определить, отсутствует ли необходимая ей адресная информация, или сервер «упал». Пакет ARP_NAK имеет тот же формат, что и полученный сервером ARP_REQUEST, но код операции изменен на «ARP_NAK».

Обновляется информация в ATMARP-таблице следующим образом: если сервер получает ATMARP-запрос с VC, которому соответствует пара ATM/IP-адрес, уже содержащиеся в таблице, то запись обновляется (сбрасывается таймер). Данный алгоритм является частью механизма устаревания (aging).

Протокол ATMARP имеет дополнительный механизм, «резервирующий» процесс выучивания новых адресов: при получении сервером ARP_REQUEST на каком-либо VC он проверяет в пакете информацию о источнике. Ежели тому VC, на котором получен пакет, не соответствует IP-адрес, а также IP-адрес источника в полученном пакете не соответствует ни одному из содержащихся в ATMARP-таблице, то информация, полученная в пакете ARP_REQUEST, помещается в ATMARP-таблицу.

Требования к функционированию клиента ATMARP

Рабочая станция, использующая ATMARP, должна сама инициировать установку соединения с сервером ATMARP. Кроме того, рабочая станция должна сама формировать и обновлять свою ATNARP-таблицу. Для всего этого на рабочей станции должен быть сконфигурирован ATM-адрес ATMARP-сервера. ATMARP-клиент должен поддерживать следующие функции:

Инициализация установки VC к ATMARP-серверу для передачи и получения пакетов ATMARP и InATMARP.

Ответ на получаемые пакеты ARP_REQUEST и InARP_REQUEST.

Генерировать и посылать пакеты ARP_REQUEST серверу ATMARP и обрабатывать получаемые пакеты ARP_REPLY и ARP_NAK. На основе получаемой информации формировать/обновлять свою ATMARP-таблицу.

При необходимости генерировать и посылать пакеты InARP_REQUEST, а также обрабатывать пакеты InARP_REPLY. Информация, содержащаяся в пакетах InARP_REPLY, должна использоваться для формирования/обновления ATMARP-таблицы.

Обеспечивать aging, позволяющий удалять из ATMARP-таблицы устаревшие записи.

Замечание Если рабочая станция не поддерживает с ATMARP-сервером постоянно установленный VC, то как минимум каждые 20 минут она должна обновлять свою адресную информацию на сервере (орать «я жива»). Это делается установкой соответствующего VC и обменом начальными пакетами InATMARP.

Устаревание данных ATMARP-таблицы (aging)

Клиент и сервер ATMARP должны иметь представление о всех установленных ими VC (PVC или SVC), т. е. для каждого VC должна иметься соответствующая запись в ATMARP-таблице. Запись также должна показывать, используется ли LLC/SNAP-инкапсуляция на VC.

Записи в ATMARP-таблице клиента должны храниться 15 минут.

Записи в ATMARP-таблице сервера должны храниться 20 минут.

Сервер

Перед тем, как декларировать запись как устаревшую, ATMARP-сервер должен сгенерировать InARP_REQUEST на VC, соответствующем данной записи. Если на канале получен после этого InARP_REPLY, запись обновляется (сбрасывается таймер) и не уничтожается. Если отсутствуют установленные VC, соответствующие устаревшей записи, она уничтожается.

Клиент

Клиент работает несколько по другому. Если запись в ATMARP таблице устаревает, т. е. проходит стандартный таймаут в 15 минут, то такая запись декларируется как «негодная» (к употреблению) – invalidate. Если «негодной» записи не соответствует открытый VC, то такая запись удаляется. Если же такой VC имеется, то клиент должен послать по нему какие-либо данные. В случае использования PVC это посылка InARP_REQUEST. При получении соответствующего InARP_REPLY запись в ATMARP-таблице обновляется. В среде SVC клиент посылает ARP_REQUEST серверу ATMARP и обновляет запись в таблице при получении соответствующего ARP_REPLY.

Формат пакетов ATMARP и InATMARP

Назначение устройству IP и ATM адресов производится независимо друг от друга. Поэтому каждый хост должен знать свои IP и ATM адреса и выдавать их при ответе на соответствующий запрос протоколов распознавания адресов – ATMARP и InATMARP.

Протоколы ATMARP и InATMARP используют тот же формат полей тип аппаратного обеспечения (ar$hrd); тип протокола (ar$pro) и код операции (ar$op), что и протоколы ARP и InARP. Данные поля располагаются в пакете ATMARP там же, где и в протоколах ARP и InARP.

Протоколу ATMARP было присвоено собственное значение для поля hardware type (тип аппаратного обеспечения), кроме того, ATMARP использует отдельный код операции для ATM_NAK.

Оставшаяся часть ATMARP/InATMARP пакетов отличается от той, которая определяется форматом пакетов ARP/InARP.

Ниже приведены поля, используемые протоколами ATMARP/InATMARP, а также их формат и описание.

Обозначение	Размер	Обознач. размера	Описание	Значение
ar$hrd	16 бит		Тип аппаратного обеспечения	Назначен семейству адресов Форума ATM. Равен 19, или 0x0013
ar$pro	16 бит		Тип протокола	Тип, присвоенный используемому протоколу. Например для IP – 0x0800
ar$shtl	8 бит	q	Тип и длина ATM-номера источника
ar$sstl	8 бит	r	Тип и длина ATM-подадреса источника
ar$op	16 бит		Код операции (запрос, ответ или NAK)	Десятичные: ARP_REQUEST 1 ARP_REPLY 2 InARP_REQUEST 8 InARP_REPLY 9 ARP_NAK 10
ar$spln	8 бит	s	Длина адреса протокола источника	Длина адреса протокола в октетах. Для IP равен 4.
ar$thtl	8 бит	x	Тип и длина ATM-номера назначения
ar$tstl	8 бит	y	Тип и длина ATM-подадреса назначения
ar$tpln	8 бит	z	Длина протокольного адреса назначения	Длина протокольного адреса назначения в октетах. Для IP равен 4.
ar$sha	q октетов		ATM-номер источника	Формат E.164 или Форум ATM NSAPA
ar$ssa	r октетов		ATM-подадрес источника	Форум ATM NSAPA
ar$spa	s октетов		Протокольный адрес источника
ar$tha	x октетов		ATM-номер назначения	Формат E.164 или Форум ATM NSAPA
ar$tsa	y октетов		ATM-подадрес назначения	Форум ATM NSAPA
ar$tpa	z октетов		Протокольный адрес назначения

Ниже приведен формат полей, которые используются для передачи информации одновременно о типе и длине (ar$shtl, ar$sstl, ar$thtl и ar$tstl).

8	7	6	5	4	3	2	1
0	1/0	Октеты длины адреса

 

Бит 8	резерв	0
Бит 7	тип	01	Формат ATM Форума NSAPAФормат E.164
Биты 6-1	длина	6 битов беззнакового значения длины.

Адреса ATM, в соответствии с Q.93B (как определено Форумом ATM в спецификации UNI 3.0) включают “Calling Party Information Element” и “Calling Party Subaddress Information Element” (Информационный элемент – вызывающая сторона и Информационный элемент – подадрес вызывающей стороны). Эти IE (Information Element – Информационный элемент) должны соответственно отображаться в ATMARP/InATMARP в номер и подадрес источника. Далее, Форум ATM определяет “Called Party Information Element” и “Called Party Subaddress Information Element” (Информационный элемент – вызываемая сторона и Информационный элемент – подадрес вызываемой стороны). Эти IE должны соответственно отображаться в ATMARP/InATMARP в номер и подадрес назначения.

Форум ATM определяет три возможны структуры комбинаций номера и подадреса в ATM-адресе:

 

	Номер	Подадрес
Структура 1	ATM Форум NSAPA	ничего
Структура 2	E.164	ничего
Структура 3	E.164	ATM Форум NSAPA

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

При использовании Структуры 1 ATMARP/InATMARP запросы/ответы должны индицировать использование нулевого ATM-подадреса, т. е. ar$sstl.type = 1(тип), ar$sstl.length = 0 (длина), ar$tstl.type = 1 (тип) и ar$tstl.length = 0 (длина). В том случае, если значения полей ar$sstl.length и ar$tstl.length равны нулю, то поля ar$tsa и ar$ssa в пакете не представлены.

Инкапсуляция пакетов ATMARP/InATMARP

Пакеты ATMARP/InATMARP помещаются в PDU AAL5 с использованием LLC/SNAP-инкапсуляции. Формат поля Payload AAL5 CPCS-SDU в этом случае выглядит следующим образом.

LLC 0xAA-AA-03

OUI 0x00-00-00

Ethertype 0x08-06

Пакет ATMARP/InATMARP

Формат поля Payload для ATMARP/InATMARP PDU

Значение заголовка LLC, равное 0xAA-AA-03, указывает на наличие в пакете заголовка SNAP непосредственно сразу же за заголовком LLC.

Значение поля OUI, равное 0x00-00-00 указывает, что непосредственно за этим полем следует двухбайтное поле Ethertype. Значение 0x08-06 поля Ethertype указывает на использование ARP.

Общий размер LLC/SNAP заголовка является величиной фиксированной и составляет 8 октетов. LLC/SNAP-инкапсуляция, рассматриваемая в данном документе, соответствует описанной в RFC 1483 (Мультипротокольная инкапсуляция через ATM). Формат ATMARP пакетов соответствует определенному для сетей IEEE 802.

Широковещательный IP-адрес

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

Групповой IP-адрес (multicast)

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

Ограничение доступа

На момент создания RFC 1577 механизмы ограничения доступа, относящиеся к IP через ATM, определены не были. Декларируется, что неплохо бы определить механизмы ограничения доступа, работающие при поднятии соединения и при передаче данных, шифровать передаваемые данные. Однако это в будущем.

---

Перевод на русский язык

Сергей Кедров