Методы инкапсуляции ATM

image_print

Для инкапсуляции протоколов ЛВС и WAN в сетях ATM разработано множество стандартов, позволяющих интегрировать ATM в существующие локальные и распределенные сети. В этой главе рассмотрены различные методы инкапсуляции. Информация, связанная с анализом и декодированием конкретных протоколов приведена в главах, посвященных соответствующим протоколам.

Для инкапсуляции и передачи трафика ЛВС/WAN через сети ATM используются следующие методы:

  • Инкапсуляция на основе VC. Предопределенные пользователем значения VPI/VCI используются для инкапсуляции тех или иных протоколов WAN/ЛВС.
  • Мультипротокольная инкапсуляция с использованием AAL5 (IETF RFC1483). Служит для инкапсуляции протоколов ЛВС в сетях ATM с использованием заголовков LLC.
  • Classical IP and ARP over ATM (IETF RFC1577). Инкапсуляция ARP/RARP.
  • Frame Relay over ATM. Описывает передачу трафика Frame Relay через ATM.
  • LAN Emulation. Эмуляция локальных сетей Ethernet и Token Ring.

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

При мультиплексировании на базе VC используется один виртуальный канал VC (пара VCI/VPI) для каждого протокола. В этом случае для передачи трафика непосредственно используются AAL5 PDU. Поскольку к протоколу не добавляется никакой дополнительной информации, этот способ иногда называют нулевой инкапсуляцией (null encapsulation).

Для маршрутизируемых протоколов (например, TCP/IP, IPX) протокольные модули данных PDU передаются в качестве полезного трафика (payload) AAL5 CPCS PDU. Для bridged-протоколов (например, Ethernet, Token Ring, FDDI) все поля после поля PID передаются в AAL5 CPCS PDU.

Многопротокольная инкапсуляция в ATM

IETF RFC 1483 http://www.cis.ohio-state.edu/htbin/rfc/rfc1483.html

Многопротокольная инкапсуляция обеспечивает передачу протоколов ЛВС через ATM с использованием инкапсуляции LLC в соответствии со стандартом IETF RFC1483. В данном случае заголовки LLC и SNAP пакетов AAL5 PDU служат для идентификации инкапсулированного протокола.

Стек данного протокола показан на рисунке.

 

Приложения вышележащих уровней.
Протоколы вышележащих уровней.

Ethernet или TCP/IP

SNAP

802.2 LLC

AAL5

ATM

Физический уровень.

 

Инкапсуляция трафика ЛВС в сетях ATM

При многопротокольной инкапсуляции PDU передаются в поле Payload CPCS PDU (Common Part Convergence Sublayer) AAL5. При использовании этого метода инкапсуляции заголовок LLC всегда имеет значение 0xAA-AA-03, показывающее, что после заголовка LLC всегда следует заголовок SNAP.

 

DSAP
AA

SSAP
AA

Ctrl
03

 

Заголовок LLC.

Формат заголовка SNAP показан на следующем рисунке.

 

Уникальный идентификатор OUI

Идентификатор протокола

3 байта

2 байта

 

Заголовок SNAP.

Модули данных PDU протоколов, отличных от ISO (например, TCP/IP, IPX), идентифицируются значением OUI = 0x00-00-00, за которым следует идентификатор PID, представляющий 2-байтовое поле EtherType. Например, значение EtherType = 0x08-00 идентифицирует IP PDU.

 

LLC 0xAA-AA-03

OUI 0x00-00-00

EtherType (2 байта)

Non-ISO PDU
(до 65527 байтов)

 

Формат полезного трафика для маршрутизируемых PDU, отличных от ISO.

Немаршрутизируемые протоколы мостов идентифицируются значением OUI = 0x00-80-C2, за которым следует 2-байтовый идентификатор PID, указывающий на протокол, следующий за ним. В приведенном ниже списке указаны некоторые из возможных значений поля PID.

PID Протокол
0x00-01/0x00-07 Ethernet/802.3
0x00-03/0x00-09 Token Ring/802.5
0x00-04/0x00-0A FDDI

На приведенном ниже рисунке показаны форматы дейтаграмм для Ethernet, Token Ring, FDDI и SMDS.

 

LLC 0xAA-AA-03

LLC 0xAA-AA-03

OUI 0x00-80-C2

OUI 0x00-80-C2

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

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

PAD 0x00-00

PAD 0x00-xx

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

Управление кадром (1 байт)

Остальная часть кадра MAC

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

Остальная часть кадра MAC

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

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

Формат информационной части для PDU Ethernet/802.3

Формат информационной части для PDU Token Ring/802.5

 

 

LLC 0xAA-AA-03

LLC 0xAA-AA-03

OUI 0x00-80-C2

OUI 0x00-80-C2

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

PID 0x00-0B

PAD 0x00-00

Зарезерв.

BEtag

Общий заголовок PDU

Управление кадром (1 байт)

BAsize

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

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

Остальная часть кадра MAC

Остальная часть кадра MAC

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

LAN FCS

Формат информационной части для PDU FDDI

Формат информационной части для PDU SNAP

На рисунке показан пример LLC с инкапсуляцией IP.

LLC

Декодирование LLC с инкапсуляцией IP.

IP-адресация в ATM

IETF RFC 1557 http://www.cis.ohio-state.edu/htbin/rfc/rfc1557.html

Стандарт IETF RFC1577 описывает версии протоколов ARP и InARP в применении к сетям ATM. В соответствии с этим стандартом заголовки LLC и SNAP идентифицируют инкапсулируемый протокол как описано в предшествующем параграфе (Многопротокольная инкапсуляция в ATM) Заголовок LLC имеет значение 0xAA-AA-03, показывающее, что вслед за заголовком LLC располагается заголовок SNAP. Значение поля OUI для протокола ARP равно 0x00-00-00, а после него следует поле EtherType со значением 0x08-06 (IP).

Адреса Internet выделяются независимо от адресов ATM. Каждый хост должен знать свой адрес IP и ATM и соответствующим образом отвечать на запросы преобразования адресов. IP-устройства должны также использовать протоколы ATMARP и InATMARP для преобразования адресов IP в адреса ATM при возникновении такой необходимости.

Формат ATMARP PDU показан на следующем рисунке.

 

8

16

24

32

биты

Тип оборудования

Тип протокола

Тип и длина ATM-номера отправителя

Тип и длина ATM-субадреса отправителя

Операция

Длина протокольного адреса отправителя

Тип и длина ATM-номера получателя

Тип и длина ATM-субадреса получателя

Длина протокольного адреса получателя

ATM-номер отправителя (q байтов)

ATM-субадрес отправителя (r байтов)

Протокольный адрес отправителя (s байтов) (IP – 4 байта)

ATM-номер получателя (x байтов)

ATM-субадрес получателя (y байтов)

Протокольный адрес получателя (z байтов) (IP – 4 байта)

 

Формат ATMARP PDU

Протоколы ATMARP и InATMARP используют такие же значения типа оборудования, типа протокола и кода операции, какие используются протоколами ARP и InARP. Расположение этих полей в пакетах ATMARP совпадает с их расположением в пакетах ARP и InARP. Для пакетов ATMARP были выделены уникальные значения поля типа оборудования.

Frame Relay over ATM

Многопротокольная инкапсуляция

При многопротокольной инкапсуляции используется подуровень FR-SSCS (Frame Relaying Service Specific Convergence Sublayer) в верхней части уровня CPCS (Common Part Convergence Sublayer) AAL5 для взаимодействия сетей Frame Relay и ATM. Сервис, обеспечиваемый FR-SSCS, соответствует Core-сервису для Frame Relay в соответствии со стандартом I.233.

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

 

Адресное поле Q.922 (2 – 4 байта)

Заголовок FR-SSCS PDU

Информационное поле Q.922

Информационная часть FR-SSCS PDU

Трейлер AAL CPCS PDU

 

FR-SSCS PDU в информационном поле AAL CPCS PDU.

PDU сетевого (routed) и канального (bridged) уровня инкапсулируются в FR-SSCS PDU в соответствии с IETF RFC1294. Информационное поле Q.922 начинается с поля Q.922 Control (управление), за которым следует необязательный октет Pad, служащий для выравнивания размера. Протокол, передаваемый с помощью PDU идентифицируется предшествующим PDU в соответствии с ISO/CCITT NLPID (Network Layer Protocol ID).

В случае IP PDU значение NLPID равно 0xCC. Согласно IETF RFC1294 адресное поле Q.922 должно иметь размер 2 или 4 октета, т.е. 3-байтовые адреса не поддерживаются. В случае протоколов ISO поле NLPID формирует первый октет PDU и не должно повторяться.

 

Адресное поле Q.922
(2 или 4 байта)

0x03 (управление Q.922)

NLPID (0xCC)

IP PDU
(до 216 -5 байтов)

 

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

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

Взаимодействие сетей Frame Relay/ATM

Отображение между ATM PDU и Frame Relay PDU требует проверки заголовков информационной части (payload) ATM AAL5 CPCS PDU или Frame Relay Q.922 PDU в принимаемых пакетах для определения типа и замены соответствующих полей в исходящих пакетах.

На приведенном ниже рисунке показана трансляция заголовков информационной части Frame Relay Q.922 PDU в заголовки информационной части ATM AAL5 CPCS PDU.

 

Управление 0x03

PAD 0x00

LLC 0xAA-AA

NLPID 0x80

OUI 0x00

0x03

OUI 0x00

0x00-80-C2

0x00-80-C2

PID

PAD 0x00-xx

Остальная часть кадра MAC

PID

Остальная часть кадра MAC

Формат заголовка информационной части Frame Relay

Формат заголовка информационной части для ATM AAL5 CPCS PDU.

 

Детальная информация об управлении трафиком при трансляции ATM — Frame Relay содержится в спецификации Frame Relay Forum FRF.8.

Эмуляция ЛВС

Протокол эмуляции ЛВС использует управляющие сообщения для организации ЛВС. LAN Emulation поддерживает два формата пакетов данных — Ethernet и Token Ring.

Кадры данных при эмуляции ЛВС сохраняют информацию, содержащуюся в исходных кадрах 802.3 или 802.5, но в них добавляются 2-байтовые идентификаторы LEC ID (идентификатор отправителя), уникальные для каждой из эмулируемых ЛВС (LEC).

Дополнительная информация содержится в главе 22 (Эмуляция ЛВС).

Please follow and like us:
error
Запись опубликована в рубрике Мир протоколов. Добавьте в закладки постоянную ссылку.

Добавить комментарий