AAA

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

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

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

Тезисы

Этот документ заменяет 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:

      AAL5 CPCS-PDU Format
+-------------------------------+
|             .                 |
|             .                 |
|        CPCS-PDU Payload       |
|     up to 2^16 - 1 octets)    |
|             .                 |
|             .                 |
+-------------------------------+
|      PAD ( 0 - 47 octets)     |
+-------------------------------+ -------
|       CPCS-UU (1 octet )      |
+-------------------------------+
|         CPI (1 octet )        |
+-------------------------------+CPCS-PDU Trailer
|        Length (2 octets)      |
+-------------------------------|
|         CRC (4 octets)        |
+-------------------------------+ -------

Поле Payload содержит пользовательскую информацию и может иметь размер до 2^16—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 | Ctrl |
+------+------+------+

При инкапсуляции 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 octet)           |
+-------------------------------+
|             .                 |
|            PDU                |
|     (up to 2^16 - 4 octets)   |
|             .                 |
+-------------------------------+

Маршрутизируемые протоколы должны идентифицироваться 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 octets)      |
+-------------------------------+
|             .                 |
|    Non-NLPID formatted PDU    |
|     (up to 2^16 - 9 octets)   |
|             .                 |
+-------------------------------+

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

+-------------------------------+
|       LLC  0xAA-AA-03         |
+-------------------------------+
|        OUI 0x00-00-00         |
+-------------------------------+
|       EtherType 0x08-00       |
+-------------------------------+
|             .                 |
|          IPv4 PDU             |
|     (up to 2^16 - 9 octets)   |
|             .                 |
+-------------------------------+

Этот формат согласуется с определением 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 or 0x00-07     |
+-------------------------------+
|         PAD 0x00-00           |
+-------------------------------+
|    MAC destination address    |
+-------------------------------+
|                               |
|   (remainder of MAC frame)    |
|                               |
+-------------------------------+
|  LAN FCS (if PID is 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 or 0x00-08     |
+-------------------------------+
|        PAD 0x00-00-00         |
+-------------------------------+
|    Frame Control (1 octet)    |
+-------------------------------+
|    MAC destination address    |
+-------------------------------+
|                               |
|   (remainder of MAC frame)    |
|                               |
+-------------------------------+
|  LAN FCS (if PID is 0x00-02)  |
+-------------------------------+

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

+-------------------------------+
|       LLC  0xAA-AA-03         |
+-------------------------------+
|        OUI 0x00-80-C2         |
+-------------------------------+
|    PID 0x00-03 or 0x00-09     |
+-------------------------------+
|        PAD 0x00-00-XX         |
+-------------------------------+
|    Frame Control (1 octet)    |
+-------------------------------+
|    MAC destination address    |
+-------------------------------+
|                               |
|   (remainder of MAC frame)    |
|                               |
+-------------------------------+
|  LAN FCS (if PID is 0x00-03)  |
+-------------------------------+

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

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

+-------------------------------+
|       LLC  0xAA-AA-03         |
+-------------------------------+
|        OUI 0x00-80-C2         |
+-------------------------------+
|    PID 0x00-04 or 0x00-0A     |
+-------------------------------+
|        PAD 0x00-00-00         |
+-------------------------------+
|    Frame Control (1 octet)    |
+-------------------------------+
|    MAC destination address    |
+-------------------------------+
|                               |
|   (remainder of MAC frame)    |
|                               |
+-------------------------------+
|  LAN FCS (if PID is 0x00-04)  |
+-------------------------------+

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

+-------------------------------+
|       LLC  0xAA-AA-03         |
+-------------------------------+
|        OUI 0x00-80-C2         |
+-------------------------------+
|         PID 0x00-0B           |
+---------------+---------------+ ------
|   Reserved    |     BEtag     |  Common
+---------------+---------------+  PDU
|            BAsize             |  Header
+-------------------------------+ -------
|    MAC destination address    |
+-------------------------------+
|                               |
|   (remainder of MAC frame)    |
|                               |
+-------------------------------+
|                               |
|      Common PDU Trailer       |
|                               |
+-------------------------------+

В передаваемых с использованием мостов пакетов 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           |
+-------------------------------+
|                               |
|      BPDU as defined by       |
|     802.1(d) or 802.1(g)      |
|                               |
+-------------------------------+

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:

+-------------------------------+
|             .                 |
|         Carried PDU           |
|    (up to 2^16 - 1 octets)    |
|             .                 |
|             .                 |
+-------------------------------+

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 destination address    |
+-------------------------------+
|                               |
|   (remainder of MAC frame)    |
|                               |
+-------------------------------+
| LAN FCS (VC dependent option) |
+-------------------------------+

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

+-------------------------------+
| PAD 0x00-00-00 or 0x00-00-XX  |
+-------------------------------+
|    Frame Control (1 octet)    |
+-------------------------------+
|    MAC destination address    |
+-------------------------------+
|                               |
|   (remainder of MAC frame)    |
|                               |
+-------------------------------+
| LAN FCS (VC dependent option) |
+-------------------------------+

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

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

+---------------+---------------+ -------
|   Reserved    |     BEtag     |  Common
+---------------+---------------+  PDU
|            BAsize             |  Header
+-------------------------------+ -------
|    MAC destination address    |
+-------------------------------+
|                               |
|   (remainder of MAC frame)    |
|                               |
+-------------------------------+
|                               |
|     Common PDU Trailer        |
|                               |

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

+-------------------------------+
|                               |
|      BPDU as defined by       |
|     802.1(d) or 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-инкапсуляции рассмотрены ниже:

+-------------------------------+
|       LLC  0xAA-AA-03         |
+-------------------------------+
|        OUI 0x00-00-5E         |
+-------------------------------+
|        PID 0x00-08            |
+-------------------------------+
|          PAD 0x00             |
+-------------------------------+
|   VPN related OUI (3 octets)  |
+-------------------------------+
|    VPN Index (4 octets)       |
+-------------------------------+
|                               |
|     (remainder of 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 и 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:

 FR-SSCS-PDU in Payload of AAL5 CPCS-PDU
+-------------------------------+ -------
|      Q.922 Address Field      | FR-SSCS-PDU Header
|         (2-4 octets)          |
+-------------------------------+ -------
|             .                 |
|             .                 |
|    Q.922 Information field    | FR-SSCS-PDU Payload
|             .                 |
|             .                 |
+-------------------------------+ -------
|      AAL5 CPCS-PDU Trailer    |
+-------------------------------+

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 имеет следующий формат:

+-------------------------------+
|       Q.922 Addr Field        |
|       (2 or 4 octets)         |
+-------------------------------+
|     0x03 (Q.922 Control)      |
+-------------------------------+
|          NLPID  0xCC          |
+-------------------------------+
|             .                 |
|           IP PDU              |
|    (up to 2^16 - 5 octets)    |
|             .                 |
+-------------------------------+

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

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

+-------------------------------+
|       Q.922 Addr Field        |
|       (2 or 4 octets)         |
+-------------------------------+
|     0x03 (Q.922 Control)      |
+-------------------------------+
|         NLPID  0x81           |
+-------------------------------+
|              .                |
|       Rest of CLNP PDU        |
|    (up to 2^16 - 5 octets)    |
|              .                |
+-------------------------------+

Отметим, что для протоколов 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               Fragments
                      0x00-0E               BPDUs

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

0x00    Null Network Layer or Inactive Set (not used with ATM)
0x80    SNAP
0x81    ISO CLNP
0x82    ISO ESIS
0x83    ISO ISIS
0xCC    Internet IP

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

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

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

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

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

Dan Grossman
Motorola, Inc
20 Cabot Blvd Mansfield, MA 02048
EMail: moc.tom.gsi.amd@nad

Juha Heinanen
Telia Finland
Myyrmaentie 2 01600 Vantaa, Finland
EMail: if.ailet@hj

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

Николай Малых, moc.milib@hkylamn