Для инкапсуляции протоколов ЛВС и 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 |
SSAP |
Ctrl |
Заголовок 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 |
Формат полезного трафика для маршрутизируемых 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 с инкапсуляцией 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 |
0x03 (управление Q.922) |
NLPID (0xCC) |
IP PDU |
Формат 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 (Эмуляция ЛВС).