RFC 2684 Multiprotocol Encapsulation over ATM Adaptation Layer 5

Network Working Group                                    D. Grossman
Request for Comments: 2684                            Motorola, Inc.
Obsoletes: 1483                                          J. Heinanen
Category: Standards Track                                      Telia
                                                      September 1999

 

Многопротокольная инкапсуляция с использованием AAL.5

Multiprotocol Encapsulation over ATM Adaptation Layer 5

PDF

Статус документа

Данный документ содержит спецификацию протокола, предложенного сообществу Internet, и служит запросом к дискуссии в целях развития протокола. Информацию о статусе данного протокола можно найти в текущей редакции документа “Internet Official Protocol Standards” (STD 1). Документ может распространяться свободно.

Авторские права

Copyright (C) The Internet Society (1999). Все права защищены.

Аннотация

Этот документ заменяет RFC 1483. Документ описывает два метода инкапсуляции при передаче межсетевого трафика с использованием AAL типа 5 по сети ATM. Первый метод позволяет мультиплексировать множество протоколов через одно виртуальное соединение ATM, а во втором методе предполагается наличие отдельного виртуального соединения ATM для каждого из протоколов.

Применимость

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

1. Введение

Глобальные, кампусные и локальные сети ATM используются для доставки дейтаграмм IP и другого трафика, не требующего организации соединений, между хостами, маршрутизаторами, мостами и другими сетевыми устройствами. В данном документе описываются два метода транспортировки протокольных модулей данных PDU, не требующих организации соединений и использующих маршрутизацию или мосты, через сети ATM. Метод инкапсуляции LLC (LLC Encapsulation) позволяет мультиплексировать множество протоколов через одно виртуальное соединение ATM (VC). Тип протокола для каждого PDU идентифицируется заголовком уровня управления логическим каналом – IEEE 802.2 LLC. При использовании метода мультиплексирования виртуальных соединений (VC Multiplexing) каждое из виртуальных соединений ATM VC служит для передачи PDU только одного протокола. При необходимости транспортировки множества протоколов для каждого из них организуется отдельное виртуальное соединение.

В сетях ATM для передачи данных используются блоки размером 53 октета, которые называют ячейками. Каждая ячейка содержит заголовок размером 5 октетов и 48 октетов информации (payload). PDU переменной длины (включая и описываемые в настоящем документе) должны быть сегментированы для размещения в 48-байтовых информационных полях ячеек ATM. На приемной стороне должна обеспечиваться обратная операция по сборке сегментированных пакетов. В данном документе описывается использование для решения этой задачи уровня адаптации AAL5 (ATM Adaptation Layer type 5) в соответствии с рекомендациями ITU-T (I.363.5 [2]). PDU переменной длины передаются в полях Payload ячеек подуровня AAL5 Common Part Convergence (CPCS).

Данный документ описывает только передачу PDU, требующих маршрутизации или организации мостов, непосредственно через AAL5 CPCS (т. е., подуровень SSCS¹ AAL5 отсутствует). Если поверх CPCS используется подуровень FR-SSCS (Frame Relay Service Specific Convergence Sublayer), описанный в рекомендациях ITU-T (I.365.1 [3]), PDU, требующие маршрутизации или организации мостов, передаются с использованием мультиплексирования NLPID, описанного в RFC 2427 [4]. Инкапсуляция RFC 2427 должна использоваться в тех случаях, когда применяется Frame Relay Network Interworking или Service Interworking в прозрачном режиме [9]; не рекомендуется использовать такую инкапсуляцию для других приложений. В Приложении A (исключительно с информационной целью) описан формат FR-SSCS-PDU для случаев инкапсуляции пакетов IP и CLNP в FR-SSCS в соответствии с RFC 2427.

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

Если вы хотите использовать возможности протокола PPP и существуют прямые (точка-точка) связи между системами одного уровня (peer systems), обратитесь к RFC 2364, где содержится информация, применимая к таким задачам.

2. Соглашения

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе должны интерпретироваться в соответствии с RFC 2119 [10].

3. Выбор метода мультиплексирования

Выбор метода инкапсуляции (LLC или мультиплексирование VC) зависит от реализации и системных требований. В общем случае инкапсуляция LLC применяется для снижения числа используемых VC. Мультиплексирование VC позволяет снизить объем передаваемых в результате фрагментации заголовков (например, при передаче дейтаграмм IPv4, содержащих пакеты управления TCP, заголовки IP и TCP не вписываются в одну ячейку).

Когда оконечные системы ATM хотят обмениваться PDU без организации соединений через ATM PVC², выбор метода мультиплексирования задается конфигурацией. При использовании коммутируемых виртуальных соединений ATM (SVC) для согласования метода инкапсуляции служат сигнальные процедуры управления соединениями ATM. Процедуры согласования описаны в документах [5] и [8].

4. Формат AAL5 PDU

Для обоих вариантов мультиплексирования PDU, требующие маршрутизации или организации мостов, должны инкапсулироваться в поля Payload пакетов AAL5 CPCS-PDU.

Рекомендации ITU-T I.363.5 [2] содержат полное определение формата AAL5 PDU и описание процедур приема и передачи. Должен использоваться сервис режима сообщений AAL5 (message mode service) без обеспечения гарантий (non-assured). Использование опции corrupted delivery (доставка при повреждении) является недопустимым. Может использоваться таймер сборки ячеек (reassembly timer). Ниже приведено описание формата AAL5 CPCS-PDU.

. . CPCS-PDU Payload до 216 – 1 октетов (65535) . .
PAD (заполнение) – 0 – 47 октетов
CPCS-UU – 1 октет	Трейлер CPCS-PDU
CPI – 1 октет
Длина – 2 октета
CRC – 4 октета

Поле Payload содержит пользовательскую информацию и может иметь размер до 2¹⁶ – 1 октетов.

Поле PAD (заполнение) служит для выравнивания CPCS-PDU по границе ячеек ATM так, чтобы последнее 48-октетное поле, создаваемое подуровнем SAR (фрагментация и сборка пакетов) совпадало с границей трейлера CPCS-PDU.

Поле CPCS-UU (индикация пользователь-пользователь) служит для прозрачной передачи информации CPCS между пользователями. Это поле не используется при мультипротокольной инкапсуляции ATM, описываемой в данном документе, и может иметь любое значение.

Поле CPI (Common Part Indicator – индикатор общей части) выравнивает трейлер CPCS-PDU по 64-битовой границе. Поле должно иметь значение 0x00.

Поле Length (длина) указывает размер поля Payload в октетах. Максимальное значение этого поля составляет 65535. Значение Length = 0x00 используется в качестве функции прерывания.

Поле CRC (контрольная сумма) служит для обнаружения ошибок в CPCS-PDU с помощью алгоритма CRC-32.

5. Инкапсуляция LLC

Инкапсуляция LLC нужна в тех случаях, когда требуется передача множества протоколов с использованием одного виртуального соединения (VC). Для того, чтобы на приемной стороне была возможность корректной обработки входящих AAL5 CPCS-PDU, поле Payload содержит информацию, обеспечивающую идентификацию протокола PDU, для которого нужна маршрутизация или организация моста. При инкапсуляции LLC эта информация должна содержаться в заголовке LLC, размещаемом в начале передаваемого пакета PDU.

Хотя в настоящем документе рассматриваются лишь протоколы, работающие поверх LLC типа 1 (режим без организации соединений и передачи подтверждений), такие же принципы инкапсуляции применимы и для протоколов, работающих поверх LLC типа 2 (с организацией соединений). В последнем случае формат и содержание заголовков LLC должно соответствовать требованиям стандартов IEEE 802.1 и IEEE 802.2.

5.1. LLC-инкапсуляция для маршрутизируемых протоколов

При использовании инкапсуляции LLC тип протоколов PDU, для которых нужна маршрутизация или организация мостов, должен указываться с помощью префиксов заголовка IEEE 802.2 LLC для каждого PDU. В некоторых случаях вслед за заголовком LLC должен размещаться заголовок IEEE 802.1a SNAP (SubNetwork Attachment Point). При работе с LLC типа 1 заголовок LLC должен содержать три 1-октетных поля:

DSAP

SSAP

Control

При инкапсуляции LLC для маршрутизируемых протоколов поле Control должно иметь значение 0x03, указывающее на UI (Unnumbered Information) Command PDU.

Значение заголовка LLC 0xFE-FE-03 должно использоваться для идентификации маршрутизируемых PDU в формате ISO NLPID (см. [6] и Приложение B). Для NLPID-форматируемых и маршрутизируемых PDU поле Payload в AAL5 CPCS-PDU должно иметь следующий формат:

LLC 0xFE-FE-03

NLPID (1 октет)

. PDU (до 216 – 4 октетов) .

Маршрутизируемые протоколы должны идентифицироваться 1-октетным полем NLPID, которое является частью протокольных данных (Protocol Data). Значения NLPID выделяются ISO и ITU-T. Текущие значения идентификаторов определены в документе ISO/IEC TR 9577 [6], некоторые из этих значений приведены в Приложении C.

Значение NLPID = 0x00 определено в ISO/IEC TR 9577 как Null Network Layer или Inactive Set. Поскольку это значение не имеет смысла в контексте данной схемы инкапсуляции, использование NLPID = 0x00 недопустимо.

Хотя существует значение NLPID (0xCC) для индикации протокола IP, формат NLPID недопустимо использовать для IP. Вместо этого дейтаграммы IP должны указываться заголовком SNAP, описанным ниже.

Присутствие заголовка IEEE 802.1a SNAP обозначается заголовком LLC = 0xAA-AA-03. Заголовок SNAP имеет форму:

OUI

PID

Заголовок SNAP содержит 3-октетный идентификатор организации OUI (Organizationally Unique Identifier) и 2-октетный идентификатор протокола PID. Значения OUI выдаются IEEE и идентифицируют организацию, которая администрирует значения PID. Таким образом, заголовок SNAP обеспечивает уникальную идентификацию для протоколов маршрутизации и мостов. Значение OUI = 0x00-00-00 показывает, что поле PID содержит значение EtherType.

Формат поля Payload для AAL5 CPCS-PDU маршрутизируемых протоколов, не относящихся к NLPID, показан ниже.

LLC 0xAA-AA-03

OUI 0x00-00-00

EtherType (2 октета)

. PDU с отличным от NLPID форматом (до 216 – 9 октетов) .

Для частного случая IPv4 PDU значение Ethertype = 0x08-00 и поле Payload должно использовать формат:

LLC 0xAA-AA-03

OUI 0x00-00-00

EtherType 0x08-00

. IPv4 PDU (до 216 – 9 октетов) .

Этот формат согласуется с определением RFC 1042 [7].

5.2. Инкапсуляция LLC для Bridged-протоколов

При использовании инкапсуляции LLC PDU, требующие организации мостов, инкапсулируются путем идентификации bridged-среды в заголовке SNAP. Присутствие заголовка SNAP должно указываться с помощью заголовка LLC = 0xAA-AA-03. Значение OUI в заголовке SNAP должно быть кодом организации для 802.1 (0x00-80-C2). Тип bridged-среды должен задаваться 2-октетным значением PID. Поле PID должно также говорить о реальном присутствии контрольной суммы FCS (Frame Check Sequence) в передаваемом через мосты PDU. В Приложении B приведен список типов сред (значений PID), которые могут использоваться при ATM-инкапсуляции.

Поле Payload в AAL5 CPCS-PDU, служащее для переноса PDU, требующих организации мостов, должно использовать один из рассмотренных ниже форматов. После поля PID должны быть добавлены октеты заполнения для выравнивания полей Ethernet/802.3 LLC Data, 802.4 Data Unit, 802.5 Info, FDDI Info или 802.6 Info передаваемого через мосты PDU по 4-октетной границе. Порядок битов MAC-адреса должен быть такой же, какой используется в ЛВС или MAN (например, канонический для Ethernet/IEEE 802.3 PDU или 802.5/FDDI для 802.5 PDU).

Формат для пакетов Bridged Ethernet/802.3 PDU

LLC 0xAA-AA-03

OUI 0x00-80-C2

PID 0x00-01 или 0x00-07

PAD 0x00-00

MAC-адрес получателя

(остальная часть кадра MAC)

LAN FCS (если PID = 0x00-01)

Физический уровень Ethernet/802.3 требует заполнения кадров до минимального размера. Мост, который использует формат инкапсуляции Bridged Ethernet/802.3 с сохраненным полем LAN FCS, должен включать заполнение. Мост, который использует формат инкапсуляции Bridged Ethernet/802.3 без сохранения контрольной суммы LAN FCS может не включать битов заполнения. Когда мост принимает кадр в таком формате без контрольной суммы LAN FCS, он должен вставить требуемые биты заполнения (если их нет) до передачи кадра в подсеть Ethernet/802.3 .

Формат Payload для пакетов Bridged 802.4 PDU

LLC 0xAA-AA-03

OUI 0x00-80-C2

PID 0x00-02 или 0x00-08

PAD 0x00-00-00

Frame Control (1 октет)

MAC-адрес получателя

(остальная часть кадра MAC)

LAN FCS (если PID = 0x00-02)

Формат поля Payload для пакетов Bridged 802.5 PDU

LLC 0xAA-AA-03

OUI 0x00-80-C2

PID 0x00-03 или 0x00-09

PAD 0x00-00-XX

Frame Control (1 октет)

MAC-адрес получателя

(остальная часть кадра MAC)

LAN FCS (если PID = 0x00-03)

Поскольку поле управления доступом 802.5 AC не имеет значения за пределами локальной подсети 802.5, это поле трактуется при данном способе инкапсуляции как последний октет 3-октетного поля заполнения PAD. Это поле может иметь любое значение (устанавливает передающий мост), а принимающий мост должен просто игнорировать значение данного поля.

Формат поля Payload для пакетов Bridged FDDI PDU

LLC 0xAA-AA-03

OUI 0x00-80-C2

PID 0x00-04 или 0x00-0A

PAD 0x00-00-00

Frame Control (1 октет)

MAC-адрес получателя

(остальная часть кадра MAC)

LAN FCS (если PID = 0x00-04)

Формат поля Payload для пакетов Bridged 802.6 PDU

LLC 0xAA-AA-03
OUI 0x00-80-C2
PID 0x00-0B
Резервное поле	BEtag	Общий заголовок PDU
BAsize
MAC-адрес получателя
(остальная часть кадра MAC)
Общий трейлер PDU

В передаваемых с использованием мостов пакетов 802.6 PDU присутствие поля CRC-32 указывается битом CIB в заголовке кадра MAC. Следовательно, во всех случаях используется одно значение PID (независимо от присутствия контрольной суммы CRC-32 в PDU).

Заголовок и трейлер Common PDU передаются для того, чтобы обеспечить возможность организации конвейерной обработки (pipelining) на мосту, являющемся выходом в подсеть 802.6. В частности, заголовок Common PDU содержит поле BAsize, в котором указан размер PDU. Если это поле недоступно выходному мосту 802.6, этот мост не сможет начать передачу сегментированного PDU до тех пор, пока PDU не будет принят полностью, рассчитан его размер и значение размера не будет помещено в поле BAsize. Если данное поле доступно, выходной мост 802.6 может определить размер пакета из поля BAsize в заголовке Common PDU, вставить это значение в соответствующее поле первого сегмента и незамедлительно начать передачу сегмента в подсеть 802.6. Таким образом, мост может начать передачу пакета 802.6 PDU до того, как будет завершен прием всего PDU.

Отметим, что заголовок и трейлер Common PDU Header инкапсулируемого кадра не должны просто копироваться в выходную (outgoing) подсеть 802.6, поскольку инкапсулированное значение BEtag может конфликтовать с предыдущим значением Betag, переданным этим мостом.

Входной мост 802.6 может прервать пакет AAL5 CPCS-PDU, установив Length=0. Если выходной мост уже начал передачу сегментов этого PDU в подсеть 802.6, этому мосту передается уведомление о том, что передача AAL5 CPCS-PDU прервана – в результате может быть незамедлительно сгенерирована ячейка EOM, приводящая к отказу от 802.6 PDU на принимающем мосту. Такая ячейка EOM может, к примеру, содержать некорректное значение поля Length в трейлере Common PDU .

Формат поля Payload для пакетов BPDU

LLC 0xAA-AA-03

OUI 0x00-80-C2

PID 0x00-0E

6. Мультиплексирование VC

При мультиплексировании виртуальных соединений VC организуются ассоциации между ATM VC и типом сетевого протокола, передаваемого с помощью этого VC. Таким образом, в данной ситуации не нужно передавать информацию для идентификации протокола в информационном поле каждого AAL5 CPCS-PDU. Это снижает объем служебной информации (overhead) и упрощает обработку пакетов. Мультиплексирование VC может повысить эффективность передачи пакетов за счет снижения числа ячеек, требуемых для передачи PDU определенной длины.

Для ATM PVC тип протокола, передаваемого через каждое постоянное соединение (PVC), должен задаваться конфигурацией. Для коммутируемых соединений ATM SVC должно использоваться согласование на основе RFC 1755 [5].

6.1. VC-мультиплексирование для маршрутизируемых протоколов

PDU маршрутизируемых протоколов должны передаваться только как содержимое информационных полей (Payload) пакетов AAL5 CPCS-PDU. Формат поля Payload пакетов AAL5 CPCS-PDU рассмотрен ниже.

Формат поля Payload для маршрутизируемых PDU

. Передаваемый пакет PDU (до 216 – 1 октетов) .

6.2. VC-мультиплексирование для Bridged-протоколов

PDU для протоколов, использующих мосты, должны передаваться в поле Payload пакетов AAL5 CPCS-PDU в точности так же, как было описано в параграфе 5.2. Единственным отличием является то, что после PID должно включаться только одно поле. Поля Payload для пакетов AAL5 CPCS-PDU при передаче трафика с использованием мостов должны, следовательно, использовать приведенные ниже форматы.

Формат поля Payload для пакетов Bridged Ethernet/802.3 PDU

PAD 0x00-00

MAC-адрес получателя

(остальная часть кадра MAC)

LAN FCS (зависит от VC)

Формат поля Payload для пакетов Bridged 802.4/802.5/FDDI PDU

PAD 0x00-00-00 или 0x00-00-XX

Frame Control (1 октет)

MAC-адрес получателя

(остальная часть кадра MAC)

LAN FCS (зависит от VC)

Отметим, что поле 802.5 AC (Access Control – управление доступом) не имеет смысла за пределами локальной подсети 802.5. Это касается последнего октета 3-байтового поля PAD, которое для кадров 802.5 может принимать любое значение (XX).

Формат поля Payload для пакетов Bridged 802.6 PDU

Резервное поле	BEtag	Общий заголовок PDU
BAsize
MAC-адрес получателя
(остальная часть кадра MAC)
Общий трейлер PDU

Формат поля Payload для пакетов BPDU

BPDU в соответствии с 802.1(d) или 802.1(g)

Для пакетов Ethernet, 802.3, 802.4, 802.5 и FDDI наличие или отсутствие завершающего поля LAN FCS должно явно указываться VC, поскольку поле PID не включается. Пакеты PDU с LAN FCS и PDU без LAN FCS рассматриваются как относящиеся к различным протоколам, даже если тип сред, для которых организуется мост, совпадает.

7. Организация мостов в сетях ATM

Мост с интерфейсом ATM, служащий в качестве канала связи с одним или несколькими мостами, должен быть способен фильтровать, пересылать и распространять всем (flood) пакеты PDU, пересылаемые через мост.

Лавинная маршрутизация (Flooding) выполняется путем передачи PDU по всем возможным и приемлемым адресам. В среде ATM это означает, что PDU будет передаваться через все, относящиеся к делу VC. Это может выполняться путем явного копирования пакета в каждое соединение VC или за счет организации виртуальных соединений “один со многими” (point-to-multipoint VC).

Для пересылки PDU мост должен быть способен связать MAC-адрес получателя с VC. Неразумно (а в некоторых случаях – невозможно) требовать статической настройки мостов для создания ассоциаций между всеми возможными MAC-адресами получателей и VC. Следовательно, мосты ATM должны предоставлять достаточную информацию для того, чтобы интерфейс ATM мог динамически определять такие ассоциации.

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

8. Идентификация VPN

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

Механизм глобальной идентификации многопротокольных VPN описан в документе [11]. Семиоктетное поле VPN-Id содержит 3-октетный идентификатор OUI (IEEE 802-1990 Organizationally Unique Identifier), связанный с VPN, за которым следует 4-октетный индекс VPN, связанный с владельцем VPN-related OUI. Обычно значения VPN-related OUI предоставляются поставщикам услуг VPN, которые выделяют индексы VPN своим заказчикам.

8.1 Заголовок инкапсуляции VPN

Форматы заголовков VPN-инкапсуляции рассмотрены ниже:

Заголовок инкапсуляции VPN

LLC 0xAA-AA-03

OUI 0x00-00-5E

PID 0x00-08

PAD 0x00

VPN related OUI (3 октета)

VPN Index (4 октета)

(остальная часть PDU)

При использовании заголовка инкапсуляции остальная часть PDU должна быть структурирована в соответствии с приемлемым форматом из числа описанных в параграфах 5 и 6 (т.е. заголовок инкапсуляции VPN предшествует PDU в пакете AAL5 CPCS SDU).

8.2 Маршрутизация и мосты для PDU с LLC-инкапсуляцией в VPN

Когда пакеты с LLC-инкапсуляцией передаются с использованием маршрутизации или мостов внутри VPN, использующей ATM поверх AAL5, заголовок инкапсуляции VPN должен предшествовать заголовку соответствующего формата PDU для маршрутизации или мостов (см. параграф 5.1 и 5.2).

8.3 Мультиплексирование VC для PDU внутри VPN

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

Если VPN указывается с использованием сигнализации управления соединениями ATM, все PDU, передаваемые с помощью ATM VC, связываются с одной VPN. В этом случае формат информационных полей для PDU с использованием маршрутизации или мостов должен определяться в соответствии с параграфами 6.1 и 6.2. Если PDU принимается с заголовком инкапсуляции VPN, при идентификации VPN с помощью сигнализации ATM приемник может отбрасывать такие пакеты и/или выполнять по отношению с ним иные действия (в зависимости от реализации). Описание использования механизмов сигнализации контроля соединений ATM для передачи идентификаторов VPN выходит за пределы данного документа.

Если идентификаторы VPN административно выделяются для интерфейса ATM, все PDU, передаваемые через любые ATM VC на одном интерфейсе, оказываются связанными с одной VPN. В этом случае формат информационных полей PDU с использованием маршрутизации или мостов должен соответствовать описаниям, приведенным в параграфах 6.1 и 6.2. Если принимаемый PDU содержит заголовок инкапсуляции VPN при административном распределении идентификаторов VPN, принимающая сторона может отбросить такие пакеты и/или выполнить по отношению к ним иные действия (в зависимости от реализации). Рассмотрение механизмов (таких как MIB) распределения идентификаторов VPN на интерфейсах ATM выходит за пределы настоящего документа.

Если идентификатор VPN указывается с использованием заголовка инкапсуляции, заголовок инкапсуляции VPN должен предшествовать PDU для маршрутизации или мостов с соответствующим форматом (см. параграфы 6.1 и 6.2).

9. Вопросы безопасности

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

На безопасность системы могут оказывать влияние и свойства нижележащих уровней ATM. ATM Forum публикует материалы по безопасности, в которых можно найти информацию, связанную с инкапсуляцией ([12], [13]).

Благодарности

Этот документ заменяет RFC 1483, разработанный группой IP over ATM и подготовленный Juha Heinanen (в то время Telecom Finland, сейчас – Telia). Данный документ был создан в рабочей группе IP-over-NBMA (ION) и Dan Grossman (Motorola) – один из авторов – принимал участие и в разработке RFC 1483.

В данном документе содержатся переработанные материалы из других RFC ([1] и [4]). Спасибо авторам этих документов – Terry Bradley, Caralyn Brown, Andy Malis, Dave Piscitello и C. Lawrence. Важный вклад в работу внесли Carpenter (CERN), Rao Cherukuri (IBM), Joel Halpern (в тот момент Network Systems), Bob Hinden (Sun Microsystems, сейчас – Nokia) и Gary Kessler (MAN Technology).

Материалы, связанные с VPN, подготовили Barbara Fox (Lucent) и Bernhard Petri (Siemens).

Литература

[1] Piscitello, D. и C. Lawrence, “The Transmission of IP Datagrams over the SMDS Service”, RFC 1209, март 1991.

[2] ITU-T Recommendation I.363.5, “B-ISDN ATM Adaptation Layer (AAL) Type 5 Specification”, август 1996.

[3] ITU-T Recommendation I.365.1, “Frame Relaying Service Specific Convergence Sublayer (SSCS), ноябрь 1993.

[4] Brown, C. и A. Malis, “Multiprotocol Interconnect over Frame Relay”, RFC 2427, сентябрь 1998.

[5] Perez M., Liaw, F., Mankin, E., Grossman, D. и A. Malis, “ATM Signalling Support for IP over ATM”, RFC 1755, февраль 1995.

[6] Information technology – Telecommunications and Information Exchange Between Systems, “Protocol Identification in the Network Layer”. ISO/IEC TR 9577, октябрь 1990.

[7] Postel, J. и J. Reynolds, “A Standard for the Transmission of IP Datagrams over IEEE 802 Networks”, STD 43, RFC 1042, февраль 1988.

[8] Maher, M., “IP over ATM Signalling – SIG 4.0 Update”, RFC 2331, апрель 1998.

[9] ITU-T Recommendation I.555, “Frame Relay Bearer Service Interworking”, сентябрь 1997.

[10] Bradner, S. “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, март 1997.

[11] Fox, B. and B. Gleeson, “Virtual Private Networks Identifier”, RFC 2685, сентябрь 1999.

[12] The ATM Forum, “ATM Security Framework Version 1.0”, af-sec-0096.000, февраль 1998.

[13] The ATM Forum, “ATM Security Specification v1.0”, af-sec-0100.001, февраль 1999.

Приложение A. Многопротокольная инкапсуляция поверх FR-SSCS

Рекомендации ITU-T I.365.1 определяют связанный с коммутацией кадров подуровень конвергенции FR-SSCS (Frame Relaying Specific Convergence Sublayer) для использования поверх общей части подуровня конвергенции CPCS (Common Part Convergence Sublayer) AAL типа 5 для межсетевого взаимодействия Frame Relay/ATM. Сервис, предоставляемый FR-SSCS, соответствует Core-сервису для коммутации кадров (Frame Relaying), описанной в I.233.

Пакеты FR-SSCS-PDU содержат поле адреса Q.922, за которым следует информационное поде Q.922. Флаги Q.922 и FCS не используются, поскольку соответствующие функции обеспечиваются AAL. Ниже показан формат FR-SSCS-PDU, вложенных в поле Payload пакетов AAL5 CPCS-PDU.

             FR-SSCS-PDU в поле Payload пакетов AAL5 CPCS-PDU
            +-------------------------------+ -------
            |      Поле адреса Q.922        | Заголовок FR-SSCS-PDU 
            |         (2-4 octets)          |
            +-------------------------------+ -------
            |             .                 |
            |             .                 |
            |    Информационное поле Q.922  | Данные FR-SSCS-PDU 
            |             .                 |
            |             .                 |
            +-------------------------------+ -------
            |      Трейлер AAL5 CPCS-PDU    |
            +-------------------------------+

PDU, использующие маршрутизацию или мосты, инкапсулируются в FR-SSCS-PDU в соответствии с RFC 2427. Информационное поле Q.922 начинается с поля Q.922 Control, за которым следует необязательный октет заполнения, используемый для выравнивания остальной части кадра по приемлемой для отправителя границе. Протокол передаваемых PDU указывается с помощью предшествующих PDU идентификаторов протокола сетевого уровня ISO/IEC TR 9577 NLPID.

В частном случае IP PDU идентификатор NLPID = 0xCC и пакет FR-SSCS-PDU имеет следующий формат:

Формат FR-SSCS-PDU для маршрутизируемых IP PDU

Поле адреса Q.922 (2 или 4 октета)

0x03 (Q.922 Control)

NLPID 0xCC

. IP PD (до 216 – 5 октетов) .

Отметим, что согласно RFC 2427, адрес Q.922 должен содержать 2 или 4 октета, т.е. 3-октетные адреса использовать недопустимо.

Для частного случая CLNP PDU идентификатор NLPID = 0x81 и формат FR-SSCS-PDU приведен ниже:

Формат FR-SSCS-PDU для маршрутизируемых CLNP PDU

Поле адреса Q.922 (2 или 4 октета)

0x03 (Q.922 Control)

NLPID 0x81

. Остальная часть CLNP PD .

Отметим, что для протоколов ISO поле NLPID формирует первый октет PDU и не должно повторяться.

Описанная выше инкапсуляция применима только к тем из маршрутизируемых протоколов, которые имеют уникальный идентификатор NLPID. Для остальных маршрутизируемых протоколов (и для протоколов, использующих мосты) требуется обеспечить иной механизм простой идентификации протокола. Для решения этой задачи можно использовать значение NLPID = 0x80, чтобы указать следующий далее заголовок IEEE 802.1a SNAP.

Детальное описание многопротокольной инкапсуляции поверх FRCS приведено в RFC 2427.

Приложение B. Список локально распределяемых OUI 00-80-C2

С сохранением FCS	Без сохранения FCS	Среда
0x00-01	0x00-07	802.3/Ethernet
0x00-02	0x00-08	802,4
0x00-03	0x00-09	802,5
0x00-04	0x00-0A	FDDI
0x00-05	0x00-0B	802,6
	0x00-0D	Фрагменты
	0x00-0E	BPDU

Приложение C. Частичный список NLPID

0x00    Null Network Layer или Inactive Set (не используется с ATM)
0x80    SNAP
0x81    ISO CLNP
0x82    ISO ESIS
0x83    ISO ISIS
0xCC    Internet IP

Приложение D. Применение многопротокольной инкапсуляции

Мультипротокольная инкапсуляция необходима (но, в общем случае, недостаточна) для маршрутизации и организации мостов через сети ATM. С момента публикации RFC 1483 (предшественник данного документа) IETF и ATM Forum подготовили несколько спецификаций по различным аспектам маршрутизации и организации мостов. В этом приложении содержится краткий список таких спецификаций.

1. Point-to-point connection between routers and bridges – многопротокольная инкапсуляция поверх ATM PVC используется для организации простых каналов “точка-точка” между мостами и маршрутизаторами через сеть ATM. Для этого сценария требуется выполнять некоторое количество настроек вручную (например, INARP).

2. Classical IP over ATM – RFC 2225⁵ (первоначальный вариант – RFC 1577) обеспечивает среду, где сеть ATM выступает в качестве логической подсети IP (LIS). Поддерживаются ATM PVC с преобразованием адресов на основе INARP. Для ATM SVC используется ATMARP (новая форма ARP), обеспечивающая взаимодействие через сеть ATM между хостом (или маршрутизатором) и сервером ATMARP. При использовании репликации сервера для повышения надежности и производительности применяется протокол SCSP (Server Synchronization Cache Protocol – протокол синхронизации серверных кэшей), определенный в RFC 2335. Classical IP over ATM по умолчанию использует инкапсуляцию LLC/SNAP.

3. LAN Emulation – Спецификация эмуляции ЛВС ATM Forum обеспечивает среду, где возможности ATM расширяются за счет использования серверов LAN Emulation, работающих как локальные сети на основе мостов (bridged LAN). Станции получают конфигурационные параметры и регистрируются на сервере LECS (LAN Emulation Configuration Server); MAC-адреса преобразуются в адреса ATM с помощью служб сервера эмуляции ЛВС и станции могут передавать пакеты с широковещательными (broadcast) и групповыми (multicast) адресами, а также пакеты для индивидуальных адресов (unicast), не связанных явно с VC, специальному серверу широковещания (Broadcast and Unicast Server). LANE использует мультиплексирование VC для инкапсуляции кадров Bridged Etherent/802.3 (без LAN FCS) или Bridged 802.5 (без LAN FCS) для Data Direct, LE Multicast Send и Multicast Forward VCCS. Однако, изначальное поле заполнения PAD, описанное в данном документе, используется как заголовок LE и не должно состоять из одних нулей.

4. Next Hop Resolution Protocol (NHRP) – В некоторых случаях ограничения Classical IP over ATM (поддержка единственного LIS) ведут к снижению производительности. Протокол NHRP, описанный в RFC 2332, расширяет возможности Classical IP over ATM, позволяя работать с несколькими LIS.

5. Multiprotocol over ATM (MPOA) – Спецификация ATM Forum MPOA объединяет возможности LANE и NHRP для обеспечения базовой среды с поддержкой маршрутизации и мостов.

6. IP Multicast – RFC 2022 расширяет возможности Classical IP за счет поддержки IP multicast (групповая адресация). Сервер преобразования групповых адресов MARS может использоваться совместно с multicast-сервером для рассылки по групповым адресам IP через сеть ATM с использованием виртуальных соединений point-to-multipoint и/или point to point.

7. PPP over ATM – RFC 2364 расширяет возможности многопротокольной инкапсуляции поверх ATM для использования протокола PPP. В этом расширении используется как мультиплексирование VC, так и инкапсуляция LLC/SNAP. Это расширение обычно используется в сетях ATM с соединениями “точка-точка” для поддержки протокола PPP.

Приложение E. Отличия от RFC 1483

Этот документ заменяет RFC 1483. Документ избавлен от анахронизмов, устраняет неоднозначности, обнаруженные в ранних реализациях и расширяет возможности протокола с учетом стандартов IETF. Было сделано также множество редакторских правок с учетом соглашений RFC 2119 [10]. Ниже перечислены основные изменения, внесенные в документ. Ни одно из этих изменений не должно противоречить реализациям RFC 1483:

• использование инкапсуляции NLPID описано с учетом соглашений RFC 2119;
• добавлена ссылка на RFC 2364 (PPP over ATM);
• включены ссылки на RFC 1755 и RFC 2331, описывающие согласование инкапсуляции взамен давно устаревших рабочих документов CCITT (не ITU-T);
• использование AAL5 описано на основе ITU-T I.363.5 (эта опция AAL5 была создана после публикации RFC 1483);
• внесена ясность в форматирование маршрутизируемых NLPID PDU (routed ISO PDU в RFC 1483);
• внесена ясность в использование заполнения для PID и MAC-адресов получателей для PDU с использованием мостов, а также порядок битов для MAC-адресов;
• внесена ясность в использование заполнения для кадров Ethernet/802.3;
• добавлена инкапсуляция для VPN;
• добавлено рассмотрение вопросов безопасности;

• в новом приложении D приведено резюме использования многопротокольной инкапсуляции поверх ATM.

Адреса авторов

Dan Grossman
Motorola, Inc.
20 Cabot Blvd.
Mansfield, MA 02048

EMail: dan@dma.isg.mot.com

Juha Heinanen
Telia Finland
Myyrmaentie 2
01600 Vantaa, Finland

EMail: jh@telia.fi

---

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

Николай Малых

nmalykh@protokols.ru

Полное заявление авторских прав

Copyright (C) The Internet Society (1999). Все права защищены.

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

Предоставленные выше ограниченные права являются бессрочными и не могут быть отозваны Internet Society или правопреемниками.

Этот документ и содержащаяся в нем информация представлены “как есть” и автор, организация, которую он/она представляет или которая выступает спонсором (если таковой имеется), Internet Society и IETF отказываются от каких-либо гарантий (явных или подразумеваемых), включая (но не ограничиваясь) любые гарантии того, что использование представленной здесь информации не будет нарушать чьих-либо прав, и любые предполагаемые гарантии коммерческого использования или применимости для тех или иных задач.

Подтверждение

Финансирование функций RFC Editor обеспечивалось Internet Society.

5Эта спецификация обновлена в RFC 5494. Прим. перев.