Network Working Group                                                                                    D. Grossman
Request for Comments: 2684                                                                   Motorola, Inc.
Obsoletes: 1483                                                                                                 J. Heinanen
Category: Standards Track                                                                                         Telia
September 1999
Multiprotocol Encapsulation over ATM Adaptation Layer 5 Многопротокольная инкапсуляция с использованием AAL.5 Статус документа
Данный документ содержит стандарт протоколов для сообщества Internet и открыт для обсуждения и предложений в целях развития. Информацию о статусе данного протокола можно найти в текущей редакции документа "Internet Official Protocol Standards" (STD 1). Документ может свободно распространяться.
Авторские права
Copyright (C) The Internet Society (1999). All Rights Reserved.
Тезисы
Этот документ заменяет 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 (Service Specific Convergence Sublayer) 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 or или Service Interworking в прозрачном режиме [9]; не рекомендуется использовать такую инкапсуляцию для других приложений. В Приложении A (исключительно с информационной целью) приведен формат FR-SSCS-PDU для случаев инкапсуляции пакетов IP и CLNP в FR-SSCS в соответствии с RFC 2427.
Данный документ описывает также инкапсуляцию для использования с VPN, работающих на базе подсети ATM.
Если вы хотите использовать возможности протокола PPP (Point-to-Point Protocol) и существуют прямые (точка-точка) связи между системами одного уровня (peer systems), обратитесь к RFC 2364, где содержится информация, применимая к таким задачам.
2. Соглашения
Ключевые слова должны, не должны, требуется, следует, не следует, всегда, никогда, рекомендуется, не рекомендуется, возможно и необязательно, когда они выделены в документе жирным шрифтом, следует трактовать в соответствии с 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 октет
CPI - 1 октет                             Трейлер
Длина - 2 октета                        CPCS-PDU
CRC - 4 октета Поле Payload содержит пользовательскую информацию и может иметь размер до 216 - 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
BAsize
MAC-адрес получателя
Общий заголовок PDU
(остальная часть кадра 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 (Virtual Private Network)
Определенная в этом параграфе инкапсуляция применима только к виртуальным частным сетям (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 может быть указан a priori с использованием сигнализации управления соединениями
ATM или административного присваивания для интерфейса ATM; можно указывать идентификатор VPN b c bcgользованием заголовка инкапсуляции.
Если 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).
Сссылки на другие документы
[I]   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.
[II] 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 (2 или 4 октета)
Заголовок FR-SSCS-PDU Информация FR-SSCS-PDU
Информационное поле Q.922
Трейлер 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 0x00-0D 0x00-0E
802.6
Фрагменты
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
Juha Heinanen
Telia Finland Myyrmaentie 2 01600 Vantaa, Finland
Полная декларация авторских прав
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Благодарности
Автор благодарит за исполнение функций RFC Editor (редактор RFC), обеспечиваемое Сообществом Internet (Internet Society).
э
Ультрасовременная глушилка сотовых телефонов эффективного подавления. . Компания Forex mmsis grup всё начинается с безобидного открытия счёта у обычного брокера. . вступить в СРО . аренда мебели для мероприятий в предлагаем прокат мебели. . металлические шкафы для одежды, подставки.