|
Мультипротокольная инкапсуляция через AAL5
|
||
|
|
||
|
Данный документ содержит описание мультипротокольной инкапсуляции через AAL5, основанное на RFC 1483.
Автор RFC 1483: Juha Heinanen, Telecom Finland. Дата - July 1993.
Перевод С. Кедрова (ksu@protocols.ru)
Содержание
4.1 LLC-ИНКАПСУЛЯЦИЯ ДЛЯ МАРШРУТИЗИРУЕМЫХ ПРОТОКОЛОВ. . ............................................................................ 6
4.2 LLC-ИНКАПСУЛЯЦИЯ ДЛЯ КОММУТИРУЕМЫХ ПРОТОКОЛОВ.. .................................................................................. 7
5.1 VC-ИНКАПСУЛЯЦИЯ МАРШРУТИЗИРУЕМЫХ ПРОТОКОЛОВ ...................................................................................... 11
|
||
|
|
||
|
|
||
|
|
||
|
2 < Мультипротокольная инкапсуляция через AAL5
|
||
|
|
||
|
От переводчика
Данный документ не является попыткой изложить описание механизма инкапсуляции в удобоваримом виде, т. е. таким образом, чтобы его было удобно читать и понимать неспециалисту. Такая обработка не проводилась. Документ является, если так можно выразиться, литературным переводом первоисточника. Последовательность изложения материала и терминология по возможности сохранены. В то же время некоторые организационные данные (не относящиеся к собственно описанию) не включены в данный документ. Желающие получить эти данные могут обратиться к оригиналу.
Англоязычные названия параметров будут переводиться, но использоваться далее в тексте как правило в первоначальном виде. Это объясняется тем, что вероятность встретить русскоязычные обозначения при настройке какого-либо устройства достаточно мала.
В данном документе термины «коммутация» и «бриджевание» (bridging) будут использоваться как взаимозаменяемые.
Также в данном документе будет использоваться термин PDU: protocol data unit – элемент данных протокола.
|
||
|
|
||
|
2000, RFC 2338 Kedrov Sergey http://rfc.com.ru
|
||
|
|
||
|
|
||
|
Введение > 3
|
||
|
|
||
|
1 Введение
Данный документ содержит описание двух методов, которые применяются при передаче через сети ATM данных коммутируемых и маршрутизируемых протоколов. Поддерживается передача данных протоколов, работающих без установления соединения (connectionless).
Первый метод поддерживает мультиплексирование данных различных протоколов в одном виртуальном канале (virtual circuit) ATM. Протокол, данные которого содержатся в передаваемом PDU, идентифицируется заголовком LLC IEEE 802.2 (Logical Link Control). Далее данный метод будет называться «LLC-инкапсуляция» (или LLC-мультиплексирование).
Второй метод состоит в передаче данных разных протоколов по разным виртуальным каналам ATM. Далее этот метод будет называться «VC-инкапсуляция» (или VC-мультиплексирование).
В ATM данные передаются при помощи ячеек фиксированной длины. Следовательно, при передаче пакетов переменной длины, формируемых различными протоколами, необходимо сегментировать/восстанавливать данные пакеты в/из ячеек. В ATM этим занимается уровень SAR (segmentation and reassembly). Так вот, RFC 1483 не описывает новой методики, применяемой уровнем SAR. Вместо этого PDU сетевых протоколов инкапсулируются в поле Payload (содержимое) CPCS-пакета (Common Part Convergence Sublayer) уровня AAL пятого типа – AAL5.
RFC 1483 описывает инкапсуляцию данных протоколов непосредственно через уровень CPCS, что подразумевает отсутствие в данном случае уровня SSCS (Service Specific Convergence Sublayer). При использовании, например, Frame Relay Service Specific Convergence Sublayer (FR-SSCS) при передаче PDU различных протоколов используется метод мультиплексирования с использованием NLPID (см. RFC 1294). Формат FR-SSCS-PDU, а также инкапсуляцию IP и CLNP через FR-SSCS в соответствии с RFC 1294 вкратце обсуждается в Приложении A.
|
||
|
|
||
|
2000, RFC 1483 Kedrov Sergey http://rfc.com.ru
|
||
|
|
||
|
|
||
|
4 < Мультипротокольная инкапсуляция через AAL5
|
||
|
|
||
|
2 Выбор метода инкапсуляции
Выбор метода VC-инкапсуляции оправдан в тех случаях, когда установка ATM VC происходит быстро и экономично (в отношении ATM-коммутаторов). Такова ситуация, например, во многих сравнительно небольших сетях. LLC-инкапсуляция будет предпочтительной в том случае, когда установка VC для каждого отдельного протокола является нежелательной. Это могут быть сети, использующие PVC (permanent virtual circuit) или сети, в которых установка новых VC по многим причинам нерентабельна.
В том случае, если две ATM-станции хотят установить между собой соединение, предназначенное для передачи данных сетевых протоколов, выбор метода мультиплексирования производится или вручную (PVC), или автоматически с использованием B-ISDN сигнализации (SVC). Некоторые детали B-ISDN на момент создания RFC 1483 находились еще в разработке. Однако принимается, что сигнальные сообщения B-ISDN содержат информационный элемент “Low layer compatibility” (совместимость на низком уровне), который используется для согласования метода мультиплексирования протоколов.
|
||
|
|
||
|
2000, RFC 2338 Kedrov Sergey http://rfc.com.ru
|
||
|
|
||
|
|
||
|
Формат фрейма AAL5 > 5
|
||
|
|
||
|
3 Формат фрейма AAL5
Вне зависимости от того, какой метод мультиплексирования используется, PDU коммутируемых и маршрутизируемых протоколов инкапсулируются в Payload AAL5 CPCS-PDU. Ниже показан формат AAL5 CPCS-PDU:
|
||
|
|
||
|
Payload.
Размер данного поля может составлять до 216 – 1 октетов
PAD
CPCS-UU – 1 октет
CPI – 1 октет
Длина – 2 октета
CRC – 4 октета
Формат AAL5 CPCS-PDU
Payload
Поле Payload содержит информацию пользователя и имеет размер до 216 – 1 октетов.
PAD
Поле PAD (выравнивание) используется для выравнивания размера CPCS-PDU на 48-октетную границу (т. е. при делении общей длины пакета на 48 не должно оставаться остатка). Пакет AAL5 CPCS-PDU будет затем передаваться уровню SAR, который поделит его на 48-байтные ячейки.
CPCS-UU
Поле CPCS-UU (User-to-User indication – Индикация пользователь-пользователь) может использоваться для прозрачной передачи пользовательской информации. Значение этого поля не регламентируется RFC 1483 и может быть установлено в любое произвольное значение.
CPI
Поле CPI (Common Part Indicator – Индикатор общей части) используется для выравнивания окончания CPCS-PDU на 64-битную границу. Поле может нести дополнительные функции, которые позднее могут быть определены CCITT. В том случае, если это поле используется только для выравнивания на 64-битную границу, оно должно содержать значение 0x00.
Длина
Данное поле указывает длину Payload в октетах. Максимальное значение этого поля – 65535. Для функции завершения (abort function) используется значение длины, равное 0x00.
CRC
Поле контрольной суммы используется для проверки на наличие ошибок в пакете. Значение самого поля CRC при расчете не учитывается.
|
||
|
|
||
|
2000, RFC 1483 Kedrov Sergey http://rfc.com.ru
|
||
|
|
||
|
|
|||||||||||||||||||
|
6 < Мультипротокольная инкапсуляция через AAL5
|
|||||||||||||||||||
|
|
|||||||||||||||||||
|
4 LLC-инкапсуляция
|
|||||||||||||||||||
|
|
|||||||||||||||||||
|
LLC-инкапсуляция используется в том случае, если данные нескольких протоколов необходимо передавать через один виртуальный канал (VC – virtual circuit). Для того, чтобы принимающая сторона могла правильно обработать содержимое поля Payload, данное поле должно содержать информацию о том, данные какого (маршрутизируемого или коммутируемого) протокола в нем содержаться. При использовании описываемого метода такая информация содержится в LLC-заголовке, помещаемом в начале поля Payload.
RFC 1483 описывает LLC-инкапсуляцию с использованием LLC Type 1 (режим работы без установления соединения и без подтверждения приема пакетов). Тем не менее отмечается, что при использовании LLC Type 2 (режим с установлением соединения) принципы инкапсуляции остаются теми же. Однако при использовании LLC Type 2 формат и содержимое LLC-заголовка могут отличаться от показанных ниже.
|
|||||||||||||||||||
|
|
|||||||||||||||||||
|
4.1
|
LLC-инкапсуляция для маршрутизируемых протоколов.
|
||||||||||||||||||
|
|
|||||||||||||||||||
|
В случае использования LLC-инкапсуляции протокол, данные которого содержаться в поле Payload, идентифицируется с помощью LLC-заголовка IEEE 802.2. За LLC-заголовком может следовать SNAP-заголовок IEEE 802.1a (SNAP – SubNetwork Attachment Point). LLC-заголовок при использовании LLC Type 1 выглядит следующим образом:
|
|||||||||||||||||||
|
|
|||||||||||||||||||
|
|||||||||||||||||||
|
|
|||||||||||||||||||
|
В LLC-инкапсуляции для маршрутизируемых протоколов значение поля Ctrl (Control – управление) всегда имеет значение 0x03.
Если за LLC-заголовком следует маршрутизируемый ISO PDU (см. Приложение B), то он содержит значение 0xFE-FE-03. Формат поля Payload в таком случае будет выглядеть следующим образом:
|
|||||||||||||||||||
|
|
|||||||||||||||||||
|
LLC 0xFE-FE-03
|
|||||||||||||||||||
|
|
|||||||||||||||||||
|
Размер данного поля может составлять до 216 – 4 октетов
|
|||||||||||||||||||
|
|
|||||||||||||||||||
|
Формат поля Payload для маршрутизируемых ISO PDU
Маршрутизируемые протоколы ISO идентифицируются однооктетным полем NLPID. Данное поле является частью поля данных протокола. Значения поля NLPID администрируется организациями ISO и CCITT. Данные значения определены в документе ISO/IEC TR 9577. Некоторые из используемых значений приведены в Приложении C.
Значение 0x00 поля NLPID определяется ISO/IEC TR 9577 как Нулевой сетевой уровень (Null Network Layer) или Неактивная установка (Inactive Set). В ATM-инкапсуляции нулевое значение поля 0x00 рассматривается как ошибочное.
Инкапсуляция ISO может использоваться для передачи IP-трафика. Несмотря на то, что IP не является протоколом ISO, для него существует определенное значение NLPID, равное 0xCC. Однако при передаче через сети ATM такой формат передачи данных использоваться не должен. Данные протокола IP должны передаваться так же, как и данные других не-ISO протоколов.
Не-ISO протоколы идентифицируются с помощью SNAP-заголовка, который следует сразу за LLC-заголовком. Наличие SNAP-заголовка идентифицируется LLC-заголовком со значением 0xAA-AA-03. Формат SNAP-заголовка:
|
|||||||||||||||||||
|
|
|||||||||||||||||||
|
|||||||||||||||||||
|
|
|||||||||||||||||||
|
3 байта
|
2 байта
|
||||||||||||||||||
|
|
|||||||||||||||||||
|
Поле OUI (Organizationally Unique Identifier – Идентификатор Организации) указывает организацию, отвечающую за администрирование значения поля PID (Protocol Identifier – Идентификатор протокола).
|
|||||||||||||||||||
|
|
|||||||||||||||||||
|
2000, RFC 2338 Kedrov Sergey http://rfc.com.ru
|
|||||||||||||||||||
|
|
|||||||||||||||||||
|
|
||
|
LLC-инкапсуляция > 7
|
||
|
|
||
|
Совместно поля OUI и PID идентифицируют маршрутизируемый или коммутируемый протокол. Значение поля OUI, равное 0x00-00-00, указывает, что в качестве значения поля PID используется EtherType.
|
||
|
|
||
|
LLC 0xAA-AA-03
|
||
|
|
||
|
OUI 0x00-00-00
|
||
|
|
||
|
EtherType (2 октета)
|
||
|
|
||
|
Не-ISO PDU
Размер данного поля может составлять до 216 – 9 октетов
|
||
|
|
||
|
Формат поля Payload для маршрутизируемых Не-ISO PDU
При использовании протокола IP значение поля EtherType равно 0x80-00 и поле Payload выглядит следующим образом:
|
||
|
|
||
|
LLC 0xAA-AA-03
|
||
|
|
||
|
OUI 0x00-00-00
|
||
|
|
||
|
EtherType 0x08-00
|
||
|
|
||
|
IP PDU
Размер данного поля может составлять до 216 – 9 октетов
|
||
|
|
||
|
Формат поля Payload для маршрутизируемого IP PDU
RFC 1483 отмечает, что данный формат передачи является совместимым с RFC 1042 (Postel, J. and Reynolds, J., "A Standard for the Transmission of IP Datagrams over IEEE 802 Networks". RFC 1042, ISI, February, 1988). Любые изменения в формате заголовка, специфицируемые в RFC 1042, должны отражаться и в RFC 1483 (понятно, что при этом это будут уже более поздние версии RFC).
4.2 LLC-инкапсуляция для коммутируемых протоколов.
При LLC-инкапсуляции тип коммутируемого протокола идентифицируется с помощью SNAP-заголовка. При передаче маршрутизируемых не-ISO протоколов наличие SNAP-заголовка идентифицируется значением LLC-заголовка, равным 0xAA-AA-03. При передаче данных коммутируемых протоколов значение поля OUI в SNAP-заголовке равно 0x00-80-C2. Идентификатор коммутируемого протокола содержится в поле PID. Дополнительной функцией поля PID является указание на то, содержит ли PDU коммутируемого протокола поле FCS - контрольная сумма - или нет. (В данном случае имеется FCS, высчитываемая отправителем пакета, например, сетевым адаптером рабочей станции в сети Ethernet). Перечень значений PID, которые могут использоваться в ATM-инкапсуляции, приведен в Приложении B.
При передаче данных коммутируемых протоколов поле Payload AAL5 CPCS-PDU должно иметь один из нижеприведенных форматов. Байты выравнивания добавляются при необходимости после поля PID для выравнивания информационного поля на 4-октетную границу.
|
||
|
|
||
|
2000, RFC 1483 Kedrov Sergey http://rfc.com.ru
|
||
|
|
||
|
|
||
|
8 < Мультипротокольная инкапсуляция через AAL5
|
||
|
|
||
|
LLC ОхАА-АА-03
|
||
|
|
||
|
OUI 0x00-80-С2
|
||
|
|
||
|
PID 0x00-01 или 0x00-07
|
||
|
|
||
|
PAD 0x00-00 (выравнивание)
|
||
|
|
||
|
MAC-фрейм
|
||
|
|
||
|
LAN FCS (если PID равен 0x00-01)
|
||
|
|
||
|
Формат поля Payload для коммутируемого Ethernet/802.3 PDU
|
||
|
|
||
|
LLC ОхАА-АА-03
|
||
|
|
||
|
OUI 0x00-80-С2
|
||
|
|
||
|
PID 0x00-02 или 0x00-08
|
||
|
|
||
|
PAD 0x00-00-00 (выравнивание)
|
||
|
|
||
|
Frame Control (1 октет)
|
||
|
|
||
|
MAC-адрес назначения
|
||
|
|
||
|
MAC-фрейм
|
||
|
|
||
|
LAN FCS (если PID равен 0x00-02)
|
||
|
|
||
|
Формат поля Payload для коммутируемого 802.4 PDU
|
||
|
|
||
|
LLC ОхАА-АА-03
|
||
|
|
||
|
OUI 0x00-80-С2
|
||
|
|
||
|
PID 0x00-03 или 0x00-09
|
||
|
|
||
|
PAD 0x00-00-XX (выравнивание)
|
||
|
|
||
|
Frame Control (1 октет)
|
||
|
|
||
|
MAC-адрес назначения
|
||
|
|
||
|
MAC-фрейм
|
||
|
|
||
|
LAN FCS (если PID равен 0x00-03)
|
||
|
|
||
|
Формат поля Payload для коммутируемого 802.5 PDU
Замечание Поле 802.5 AC (Access Control – Контроль доступа) не имеет значения за пределами
локальной сети 802.5. В принципе оно может передаваться в последнем октете поля PAD. Данный октет может быть установлен в любое произвольное значение (XX на рисунке).
|
||
|
|
||
|
2000, RFC 2338 Kedrov Sergey http://rfc.com.ru
|
||
|
|
||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
LLC-инкапсуляция > 9
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
LLC 0xAA-AA-03
OUI 0x00-80-С2
PID 0x00-04 или 0x00-0A
PAD 0x00-00-00 (выравнивание)
Frame Control (1 октет)
MAC-адрес назначения
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
MAC-фрейм
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
LAN FCS (если PID равен 0x00-04) Формат поля Payload для коммутируемого FDDI PDU
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Формат поля Payload для коммутируемого 802.6 PDU
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
В 802.6 для поля PID используется только одно значение, в отличие от остальных типов PDU. Наличие или отсутствие контрольной суммы индицируется битом CB в заголовке MAC-фрейма.
Передача полей заголовок и окончание PDU 802.6 через сети ATM поддерживается в целях обеспечения режима pipelining (конвейерный режим). Заголовок PDU содержит поле BAsize, указывающее длину PDU. Если 802.6-бридж не имеет возможности работать с этим полем (т. е. его не получает), следовательно данный бридж не может передавать сегментированный PDU (исключая те случаи, когда PDU получен целиком), а также не имеет возможности рассчитывать длину и вставлять ее значение в поле BAsize. Если поле может быть использовано, то 802.6-бридж может получить полную длину PDU, вставить ее в соответствующее поле первого сегмента и сразу же отправить полученный сегмент в сеть 802.6. Таким образом, бридж может начать передачу 802.6 PDU до получения всего PDU.
Замечание: Заголовок и окончание инкапсулированного фрейма не могут быть просто скопированы при передаче информации в сеть 802.6. BEtag, содержащийся в инкапсулированном фрейме может конфликтовать с предыдущим значением BEtag, переданным бриджом.
802.6 бридж может «убить» полученный AAL5 CPCS-PDU установкой значения поля длины в 0. Если посылающий информацию бридж уже начал передачу сегментов PDU в сеть 802.6 и затем был информирован о сбросе AAL5 CPCS-PDU, он немедленно может сгенерировать ячейку EOM, что вызовет сброс 802.6 PDU на принимающем бридже. Таким образом ячейка EOM может содержать неправильное значение поля длины в окончании PDU.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
2000, RFC 1483 Kedrov Sergey http://rfc.com.ru
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||
|
10 < Мультипротокольная инкапсуляция через AAL5
|
||
|
|
||
|
LLC 0xAA-AA-03
OUI 0x00-80-С2
PID 0x00-0E
BPDU, структура которого определена в
802.1 (d) или 802.1 (g)
|
||
|
|
||
|
2000, RFC 2338 Kedrov Sergey http://rfc.com.ru
|
||
|
|
||
|
|
||
|
VC-инкапсуляция > 11
|
||
|
|
||
|
5 VC-инкапсуляция
При VC-инкапсуляции, или VC-мультиплексировании протокол, данные которого передаются через сеть ATM, идентифицируется с помощью VC, т. е. каждый протокол использует отдельный VC. Таким образом отпадает необходимость в помещении дополнительной информации мультиплексирования в поле Payload AAL5-CPCS-PDU, что приводит к уменьшению используемой полосы пропускания и загрузки процессора коммутаторов.
Параметр «идентификатор передаваемого протокола» может быть сконфигурирован вручную или согласован автоматически в ходе процесса установки соединения с помощью процедур сигнализации. Детали сигнализации будут определены потом. В более поздних RFC.
5.1 VC-инкапсуляция маршрутизируемых протоколов.
PDU маршрутизируемых протоколов должны помещаться в поле Payload AAL5 CPCS-PDU. Формат поля Payload приведен ниже:
|
||
|
|
||
|
Передаваемый PDU
Размер данного поля может составлять до 216 – 1 октетов
|
||
|
|
||
|
Формат поля Payload для маршрутизируемого PDU
|
||
|
|
||
|
5.2 VC-инкапсуляция бриджуемых протоколов.
PDU коммутируемых протоколов должны помещаться в поле Payload AAL5 CPCS-PDU точно так же, как это описано в секции 4.2, за исключением того, что включаются только поля, следующие за PID. При передаче данных коммутируемых протоколов поле Payload AAL5 CPCS-PDU должно иметь один из нижеприведенных форматов.
|
||
|
|
||
|
PAD 0x00-00
|
||
|
|
||
|
MAC-адрес назначения
|
||
|
|
||
|
MAC-фрейм
|
||
|
|
||
|
LAN FCS (в зависимости от VC)
|
||
|
|
||
|
Формат поля Payload для коммутируемого Ethernet/802.3 PDU
|
||
|
|
||
|
PAD 0x00-00-00 или 0x00-00-XX
|
||
|
|
||
|
Frame Control
|
||
|
|
||
|
MAC-адрес назначения
|
||
|
|
||
|
MAC-фрейм
|
||
|
|
||
|
LAN FCS (в зависимости от VC)
|
||
|
|
||
|
Формат поля Payload для коммутируемого 802.4/802.5/FDDI PDU
|
||
|
|
||
|
2000, RFC 1483 Kedrov Sergey http://rfc.com.ru
|
||
|
|
||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||
|
12 < Мультипротокольная инкапсуляция через AAL5
|
|||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||
|
Замечание Поле 802.5 AC (Access Control – Контроль доступа) не имеет значения за пределами
локальной сети 802.5. В принципе оно может передаваться в последнем октете поля PAD. Данный октет может быть установлен в любое произвольное значение (XX на рисунке).
|
|||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||
|
Формат поля Payload для коммутируемого 802.6 PDU
|
|||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||
|
BPDU, структура которого определена в 802.1 (d) или 802.1 (g)
Формат поля Payload для BPDU
В случае Ethernet, 802.3, 802.4, 802.5 и FDDI наличие или отсутствие поля FCS (контрольная сумма) идентифицируется используемым VC, т. е. при установке VC вручную или автоматически согласовывается, будет использоваться контрольная сумма, или нет. PDU, содержащие контрольную сумму, и PDU, оную не содержащие, рассматриваются как принадлежащие к разным протоколам, даже если принадлежат к одному и тому же коммутируемому протоколу.
|
|||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||
|
2000, RFC 2338 Kedrov Sergey http://rfc.com.ru
|
|||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||
|
|
||
|
Коммутация в сети ATM > 13
|
||
|
|
||
|
6 Коммутация в сети AT M
Коммутатор (или любое иное устройство) ATM, работающее с инкапсуляцией сетевых протоколов, должен поддерживать выполнение соответствующих функций: flooding (фладинг), forwarding (пересылка) и filter (фильтрация) коммутируемых PDU.
Flooding
Flooding есть посылка PDU по всем возможным направлениям, исключая то, по которому PDU был получен. В среде ATM это означает посылку PDU во все те VC, в которые PDU может быть послан. В практической реализации это может означать посылку по отдельной копии PDU в каждый VC, или использование мультикастового (multicast) VC.
Forwarding
Для пересылки полученного PDU коммутатор должен быть в состоянии устанавливать соответствие MAC-адреса назначения и VC, через который должен быть послан фрейм с таким адресом назначения. Естественно, установка соответствия MAC-адреса и VC вручную лишена, мягко говоря, смысла. Соответственно, коммутатор должен уметь сам «выучивать» адресную информацию. Подразумевается, что получаемые PDU соответствуют форматам, приведенным в разделе 4, что позволяет коммутатору адекватно определять MAC-адрес.
|
||
|
|
||
|
2000, RFC 1483 Kedrov Sergey http://rfc.com.ru
|
||
|
|
||
|
|
||
|
14 < Мультипротокольная инкапсуляция через AAL5
|
||
|
|
||
|
7 На будущее
Поскольку многие механизмы в ATM на момент создания RFC 1483, да и на настоящий момент не определены полностью, детали процесса согласования метода мультиплексирования (инкапсуляции), а также механизма работы с адресами оставлены на совесть будущих RFC.
Удачи всем, кто пытается постигнуть мир стандартов ATM!
|
||
|
|
||
|
2000, RFC 2338 Kedrov Sergey http://rfc.com.ru
|
||
|
|
||
|
|
||||||||||||||||||||||
|
Приложение A Мультипротокольная инкапсуляция через FR-SSCS > 15
|
||||||||||||||||||||||
|
|
||||||||||||||||||||||
|
8 Приложение A
Мультипротокольная инкапсуляция через FR-SSCS
Если рассматривать уровневую модель ATM, то FR-SSCS (Frame Relaying Specific Convergence Sublayer) будет находиться в верхней части подуровня CPCS (Common Part Convergence Sublayer) уровня AAL5. Функции, поддерживаемые FR-SSCS, соответствуют функциям Core Service для Frame Relay (как описано в документе I.233).
FR-SSCS-PDU содержит поле адреса (в соответствии с Q.922), за которым следует информационное поле. Флаги Q.922 и контрольная сумма не включаются, поскольку соответствующие функции обеспечиваются через AAL. Ниже показан FR-SSCS-PDU, инкапсулированный в поле Payload AAL5 CPCS-PDU.
|
||||||||||||||||||||||
|
|
||||||||||||||||||||||
|
||||||||||||||||||||||
|
|
||||||||||||||||||||||
|
FR-SSCS-PDU, инкапсулированный в поле Payload AAL5 CPCS-PDU
|
||||||||||||||||||||||
|
|
||||||||||||||||||||||
|
PDU маршрутизируемых и коммутируемыхпротоколов инкапсулируются в FR-SSCS-PDU в соответствии с RFC 1294. Информационное поле Q.922 содержит поле управления Q.922 (поле Control), за которым может следовать поле выравнивания. Протокол, данные которого содержится в информационном поле, идентифицируется с помощью поля NLPID (ISO/CCITT Network Layer Protocol ID), которое предшествует данным протокола.
Например, если передаются данные протокола IP, NLPID содержит значение 0xCC и FR-SSCS-PDU выглядит следующим образом:
|
||||||||||||||||||||||
|
|
||||||||||||||||||||||
|
Q.922-адрес (2-4 октета)
|
||||||||||||||||||||||
|
|
||||||||||||||||||||||
|
0x03 (Управление Q.922)
|
||||||||||||||||||||||
|
|
||||||||||||||||||||||
|
NLPID 0xCC
IP PDU
Размер данного поля может составлять до 216 – 5 октетов
|
||||||||||||||||||||||
|
|
||||||||||||||||||||||
|
FR-SSCS-PDU, содержащий IP PDU
Обратите внимание, что в соответствии с RFC 1294 адрес Q.922 может иметь размер 2 или 4 октета, т. е. 3-октетный адрес не поддерживается.
Рассмотрим, как будет выглядеть FR-SSCS-PDU в случае передачи данных протокола CLNP:
|
||||||||||||||||||||||
|
|
||||||||||||||||||||||
|
2000, RFC 1483 Kedrov Sergey http://rfc.com.ru
|
||||||||||||||||||||||
|
|
||||||||||||||||||||||
|
|
||
|
16 < Мультипротокольная инкапсуляция через AAL5
|
||
|
|
||
|
Q.922-адрес (2-4 октета)
|
||
|
|
||
|
0x03 (Управление(контроль) Q.922)
|
||
|
|
||
|
NLPID 0x81
|
||
|
|
||
|
CLNP PDU
Размер данного поля может составлять до 216 – 5 октетов
|
||
|
|
||
|
FR-SSCS-PDU, содержащий CLNP PDU
В случае протоколов ISO поле NLPID содержится в первом октете самого PDU. Соответственно, дублировать его не обязательно.
Вышеописанная методика инкапсуляции применима только к тем маршрутизируемым протоколам, которые имеют определенное значение для поля NLPID. Для протоколов, для которых это значение не определено, а также для бриджуемых протоколов должен использоваться иной механизм идентификации протокола. Таким механизмом может быть использование заголовка SNAP, помещаемого после поля NLPID. Значение NLPID в этом случае должно быть равно 0x80.
Более подробно мультипротокольная инкапсуляция через FRCS рассматривается в RFC 1294. Точнее, именно там она и рассматривается.
|
||
|
|
||
|
2000, RFC 2338 Kedrov Sergey http://rfc.com.ru
|
||
|
|
||
|
|
|||||||||||||||||||||||||||||||||||||||||||
|
Приложение В Перечень используемых значений для поля PID при OUI 0х00-80-С2 > 17
|
|||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||
|
9 Приложение B
Перечень используемых значений для поля PID при OUI 0x00-80-C2
|
|||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||
|
Сетевая технология
|
||||||||||||||||||||||||||||||||||||||||||
|
802.3/Ethernet
802.4
802.5
FDDI
802.6
Фрагменты
BPDU
|
|||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||
|
2000, RFC 1483 Kedrov Sergey http://rfc.com.ru
|
|||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||
|
18 < Мультипротокольная инкапсуляция через AAL5
|
||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||
|
10 Приложение C
Перечень значений поля NLPID (не полный)
|
||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||
|
2000, RFC 2338 Kedrov Sergey http://rfc.com.ru
|
||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||