|
|
|
|
|||||
|
|
|||||||
|
|
|||||||
|
|
|||||||
|
Network Working Group Request for Comments: 1490 Obsoletes: 1294
|
T. Bradley Wellfleet Communications, Inc.
C. Brown Wellfleet Communications, Inc.
A. Malis
Ascom Timeplex, Inc.
July 1993
|
||||||
|
|
|||||||
|
Multiprotocol Interconnect over Frame Relay Статус документа
В этом RFC содержится спецификация стандарта IAB для сообщества Internet и запрос на дальнейшее обсуждение темы в целях развития стандарта. Статус данного протокола1 можно найти в текущей редакции документа IAB Official Protocol Standards. Документ может распространяться без ограничений.
Тезисы
В этом документе описаны методы инкапсуляции для передачи межсетевого трафика через магистрали Frame Relay. В документе рассмотрены вопросы маршрутизации и организации мостов (Bridging). Кроме того, описана простая процедура фрагментации для передачи больших кадров через сети Frame Relay, для которых значение MTU меньше размера кадров.
Системы, способные поддерживать оба описанных в документе метода инкапсуляции, а также иные методы, должны знать a-priori для каких виртуальных устройств используется тот или иной метод инкапсуляции. Инкапсуляция определенного типа может использоваться только для тех виртуальных устройств, которые настроены на такое использование.
Благодарности
В этом документе содержатся результаты работы множества людей. Особо отметим вклад Ray Samora (Proteon), Ken Rehbehn (Netrix Corporation), Fred Baker, Charles Carvalho (Advanced Computer Communications) и Mostafa Sherif (AT&T). Отметим также вклад Dory Leifer (University of Michigan) в рассмотрение вопросов фрагментации, а также Floyd Backes (DEC) и Laura Bridge (Timeplex) - вопросы поддержки мостов. Документ никогда бы не удалось завершить без использования опыта рабочей группы IETF IP over Large Public Data Networks.
1. Терминология и сокращения
Ниже приведено толкование некоторых терминов в контексте документа:
У Требуется, должно, обязательно - используется для обозначения абсолютно необходимых требований спецификации.
•S Следует, рекомендуется - в общем случае это требование должно выполняться, но возможны исключения.
V'Возможно, необязательно - решение вопроса о выполнении таких требований отдается на откуп разработчикам.
На схемах в документе биты выводятся слева направо по старшинству (младший бит слева).
0 1 2 3 4 5 6 7 биты октета +---+---+---+---+---+---+---+
+------------------------------+
1 Флаг (7Е шестнадцатеричное)|
|
|||||||
|
|
|||||||
|
|
| Адрес Q.922 | +-- --+
| |
+ --------------------------- +
: :
: :
+ --------------------------- +
|
|
|||||
|
Для больших диаграмм в одной строке может размещаться изображение двух октетов. На некоторых рисунках старший бит показан слева (такие случаи указаны явно).
|--- октет 1 ---|--- октет 2 ---|
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|
|||||||
|
|
|||||||
|
| Уникальный идентификатор
|
|||||||
|
|
|||||||
|
| организации
+ -------------
| протокола
|
| Идентификатор
|
||||||
|
I
|
|||||||
|
|
|||||||
|
Ниже приведен список основных сокращений, использованных в документе.
BECN Backward Explicit Congestion Notification - обратное уведомление о насыщении
BPDU Bridge Protocol Data Unit - единица данных протокола моста
|
|||||||
|
|
|||||||
|
1 В настоящее время документ RFC-1490 утратил силу и в качестве текущего стандарта для инкапсуляции в сетях Frame Relay служит RFC-2427. Перевод RFC-2427 на русский язык можно найти на сайте rfc.com.ru. Прим. перев.
|
|||||||
|
|
|||||||
|
|
|||||||
|
|
|||
|
|
Перевод RFC-1490
|
||
|
|
|||
|
C/R Command/Response bit - бит команда/отклик
DCE Data Communication Equipment - коммуникационное оборудование
DE Discard Eligibility bit - бит возможности отбрасывания
DTE Data Terminal Equipment - терминальное оборудование
FECN Forward Explicit Congestion Notification - прямое уведомление о насыщении
PDU Protocol Data Unit - единица данных протокола
PTT Postal Telephone & Telegraph (название компании)
SNAP Subnetwork Access Protocol - протокол доступа в подсеть
2. Введение
Рассмотренные ниже вопросы относятся к устройствам, функционирующим в качестве конечных станций (end station, DTE) частных или публичных сетей Frame Relay. Поведение станций, являющихся частью сети Frame Relay (DCE), рассматриваться не будет, за исключением тех случаев, в которых от этого поведения зависит реакция устройств DTE.
Сеть Frame обеспечивает множество виртуальных устройств (virtual circuit), создающих основу для организации соединений между станциями, подключенными к одной сети Frame Relay. Набор соединенных между собой устройств формирует частную группу Frame Relay, члены которой могут быть соединены со всеми остальными (многосвязная сеть с использованием всех возможных соединений) или только с частью других станций. В любом случае каждое виртуальное устройство уникально идентифицируется на каждом интерфейсе Frame Relay с помощью DLCI (Data Link Connection Identifier - идентификатор соединения на канальном уровне). В большинстве случаев значения DLCI имеют локальную значимость в масштабах каждого интерфейса Frame Relay. Рассматриваемые в этом документе спецификации применимы как к коммутируемым (switched), так и к постоянным (permanent) виртуальным устройствам.
3. Формат кадров
Все протоколы должны инкапсулировать свои пакеты в кадры Q.922 Annex A [1,2]. Кроме того, рекомендуется включать в кадры информацию, позволяющую идентифицировать протокол, передаваемый в PDU - это дает возможность приемнику корректно обрабатывать входящие пакеты. Формат пакетов показан ниже:
+ --------------------------- +
|Флаг (7E шестнадцатеричн.) |
+ --------------------------- +
| Адрес Q.922 |
+-- --+
| |
+ --------------------------- +
| Control (UI = 0x03) |
+ --------------------------- +
| Заполнение (0x00) |
+ --------------------------- +
| NLPID |
+ --------------------------- +
| . |
| . |
| . |
| Данные |
| . |
| . |
+ --------------------------- +
| Контрольная сумма FCS |
+-- . --+
| (2 октета) |
+ --------------------------- +
|Флаг (7E шестнадцатеричн.) |
+ --------------------------- +
Адреса Q.922 в соответствии с действующим стандартом являются 2-октетными и содержат 10-битовые идентификаторы DLCI. В
некоторых сетях адреса Q.922 могут быть увеличены до 3 или 4 октетов.
Поле Control представляет собой поле управления Q.922. Если явно не оговорено иное, в качестве значения этого поля
используется UI (0x03). Допустимо использование значения XID (0xAF или 0xBF), рассмотренного ниже.
Необязательное поле заполнения используется для выравнивания оставшейся части кадра по 2-октетной границе. Поле заполнения
может содержать один или два октета; значение октетов заполнения должно быть нулевым.
Значения поля идентификатора протокола сетевого уровня NLPID (Network Level Protocol ID) распределяются ISO и CCITT.
Предусмотрены идентификаторы для множества распространенных протоколов, включая IP, CLNP и IEEE Subnetwork Access
Protocol (SNAP) [10]. Это поле говорит принимающему устройству об используемом методе инкапсуляции и передаваемом
протоколе. Возможные значения поля определены стандартом ISO/IEC TR 9577 [3]. Значение NLPID=0x00 определено в ISO/IEC
TR 9577 как Null Network Layer или Inactive Set. Поскольку это значение невозможно отличить от заполнения, а в данной схеме
инкапсуляции это значение просто не имеет смысла, при рассмотрении инкапсуляции Frame Relay значение NLPID=0x00 считается
некорректным. В приложении A содержится список наиболее распространенных значений NLPID.
Для сетей Frame Relay не существует общепринятого нижнего порога для максимального размера кадров. Реальные сети, однако,
должны поддерживать кадры размером, по крайней мере, 262 октета. В общем случае максимальный размер кадра больше или
равен 1600 октетов, но каждый оператор Frame Relay может выбрать для своей сети наиболее подходящее значение. Устройства
DTE в сетях Frame Relay, следовательно, должны обеспечивать возможность настройки значений максимального размера кадров.
Минимальный размер кадров Frame Relay требует наличия не менее 5 октетов между стартовым и закрывающим флагами с учетом
2-октетного поля адреса Q.922. Это значение возрастает до 6 октетов для 3-октетного адреса Q.922 и до 7 октетов в случае
использования 4-октетного формата для адресов Q.922.
4. Межсетевые соединения
Существует два основных типа пакетов, передаваемых через сети Frame Relay - маршрутизируемые пакеты и пакеты, пересылаемые с использованием мостов (bridged). Для этих пакетов используются различные форматы и, следовательно, должен обеспечиваться способ идентификации, позволяющий получателю корректно интерпретировать содержимое кадра. Индикатор типа помещается в поле NLPID и заголовок SNAP.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Перевод RFC-1490
|
|
||
|
|
|||
|
Для тех протоколов, которые еще не получили идентификатора NLPID, требуется обеспечить механизм простой идентификации протокола. Существует значение NLPID, показывающее присутствие заголовка SNAP. Заголовок SNAP имеет форму:
+ -------------------------------------------- +
| Уникальный идентификатор |
+-- + -------------------- +
| организации | Идентификатор |
+ ----------------------- + -------------------- +
| протокола |
|
|||
|
|
|||
|
Все станции должны воспринимать и корректно интерпретировать инкапсуляцию с использованием NLPID и заголовков SNAP для маршрутизируемых пакетов.
Трехоктетное поле OUI (Organizationally Unique Identifier) указывает организацию, ответственную за администрирование последующего идентификатора протокола (PID). Значения OUI и PID совместно позволяют однозначно идентифицировать протокол. Отметим, что значение OUI=0x00-00-00 указывает, что поле PID имеет значение Ethertype.
4.1. Маршрутизируемые кадры
С некоторыми протоколами связаны значения NLPID, но ограниченность пространства номеров NLPID не позволяет выделить такие идентификаторы для всех протоколов. Когда пакеты протоколов, не имеющих идентификатора, маршрутизируются через сети Frame Relay, для таких пакетов используется значение NLPID=0x80 (оно говорит о наличии SNAP), за которым следует заголовок SNAP. Если для протокола выделено значение Ethertype, поле OUI имеет значение 0x00-00-00 (это значение говорит о наличии поля Ethertype) и поле PID принимает значение Ethertype для используемого протокола. В таких случаях может использоваться 1-октетное поле заполнения для выравнивания по 2-октетной границе, как показано ниже.
Формат маршрутизируемых кадров с Ethertype
|
|||
|
|
|||
|
| Адрес Q.922 |
+ --------------- + --------------- +
|Control 0x03 | pad 0x00 |
+ --------------- + --------------- +
| NLPID 0x80 | OUI 0x00 |
+ --------------- + --+
| OUI 0x00-00 |
+ ------------------------------- +
| Ethertype |
+ ------------------------------- +
| Протокольные данные |
+ ------------------------------- +
| FCS |
+ ------------------------------- +
В некоторых случаях при наличии NLPID (см. приложение A) можно сохранить 48 битов за счет использования показанного ниже формата:
Формат маршрутизируемых кадров с NLPID
+ ------------------------------- +
| Адрес Q.922 |
+ --------------- + --------------- +
|Control 0x03 | NLPID |
+ --------------- + --------------- +
| Протокольные данные |
+ ------------------------------- +
| FCS |
+ ------------------------------- +
Инкапсуляция NLPID не требует использовать заполнение, поэтому данное поле отсутствует в заголовке.
Для некоторых протоколов ISO значение NLPID рассматривается как первый октет данных протокола. В таких случаях нет необходимости дублировать поле NLPID. Один октет используется для демультиплексирования и в качестве данных протокола (см. параграф "Инкапсуляция других протоколов"). Другие протоколы (такие, как IP) имеют значение NLPID (для IP - 0xCC), но это значение не является частью протокольных данных.
Формат маршрутизируемой дейтаграммы IP
+ ------------------------------- +
| Адрес Q.922 |
|
|||
|
|
|||
|
I Control 0x03 | NLPID OxCC | +----------------+----------------+
| Дейтаграмма IP |
+----------------------------------+
| FCS |
+----------------------------------+
|
|||
|
|
|||
|
4.2. Кадры, передаваемые через мосты
Вторым типом трафика Frame Relay являются пакеты, передаваемые с использованием мостов (bridged packet). Такие пакеты инкапсулируются с использованием NLPID=0x80 (указывает наличие SNAP). Как и с другими протоколами, использующими SNAP-инкапсулцию, может добавляться один октет заполнения для выравнивания границы данных инкапсулированного кадра. Заголовок SNAP, который следует после NLPID, идентифицирует формат пакета, передаваемого с использованием мостов. Значение OUI, используемое для такой инкапсуляции, является кодом комитета IEEE 802.1 и имеет значение 0x00-80-C2. PID-часть заголовка SNAP (два байта вслед за OUI) указывает формат заголовка MAC, который следует сразу после заголовка SNAP. Кроме того, PID показывает наличие исходной контрольной суммы FCS в bridged-кадре. Комитет IEEE 802.1 зарезервировал для использования с Frame Relay следующие значения: Значения PID для OUI 0x00-80-C2
С сохранен. FCS без сохран. FCS Среда
------------------ ----------------- ----------------
0x00-01 0x00-07 802.3/Ethernet
|
|||
|
|
|||
|
|
|||
|
|
Перевод RFC-1490
|
||
|
|
|||
|
0x00-02 0x00-08 802.4
0x00-03 0x00-09 802.5
0x00-04 0x00-0A FDDI
0x00-0B 802.6
Кроме того, PID=0x00-0E при OUI=0x00-80-C2 указывает на модуль данных BPDU (Bridge Protocol Data Unit), определенный стандартом 802.1d или 802.1g [12].
Пакеты, передаваемые с использованием мостов через сеть Frame Relay, будут, следовательно, иметь один из следующих форматов:
Формат кадров Bridged Ethernet/802.3
+ ------------------------------- +
| Адрес Q.922 |
|
|||
|
|
|||
|
|Control 0x03 | pad 0x00 |
+ --------------- + --------------- +
| NLPID 0x80 | OUI 0x00 |
+ --------------- + --+
| OUI 0x80-C2 |
+ ------------------------------- +
| PID 0x00-01 или 0x00-07 |
+ ------------------------------- +
| MAC-адрес получателя | : :
| |
+ ------------------------------- +
| (остаток кадра MAC) |
+ ------------------------------- +
| LAN FCS (если PID=0x00-01) |
+ ------------------------------- +
| FCS |
+ ------------------------------- +
Формат кадров Bridged 802.4
+ ------------------------------- +
| Адрес Q.922 |
|
|||
|
|
|||
|
|Control 0x03 | pad 0x00 |
+ --------------- + --------------- +
| NLPID 0x80 | OUI 0x00 |
+ --------------- + --+
| OUI 0x80-C2 |
+ ------------------------------- +
| PID 0x00-02 или 0x00-08 |
+ --------------- + --------------- +
| pad 0x00 | Frame Control |
+ --------------- + --------------- +
| MAC-адрес получателя | : :
| |
+ ------------------------------- +
| (остаток кадра MAC) |
+ ------------------------------- +
| LAN FCS (если PID=0x00-02) |
+ ------------------------------- +
| FCS |
+ ------------------------------- +
Формат кадров Bridged 802.5
+ ------------------------------- +
| Адрес Q.922 |
|
|||
|
|
|||
|
|Control 0x03 | pad 0x00 |
+ --------------- + --------------- +
| NLPID 0x80 | OUI 0x00 |
+ --------------- + --+
| OUI 0x80-C2 |
+ ------------------------------- +
| PID 0x00-03 или 0x00-09 |
+ --------------- + --------------- +
| pad 0x00 | Frame Control |
+ --------------- + --------------- +
| MAC-адрес получателя | : :
| |
+ ------------------------------- +
| (остаток кадра MAC) |
+ ------------------------------- +
| LAN FCS (если PID=0x00-03) | | |
+ ------------------------------- +
| FCS |
+ ------------------------------- +
Формат кадров Bridged FDDI
+ ------------------------------- +
| Адрес Q.922 |
|
|||
|
|
|||
|
|Control 0x03 | pad 0x00 |
+ --------------- + --------------- +
| NLPID 0x80 | OUI 0x00 |
+ --------------- + --+
| OUI 0x80-C2 |
+ ------------------------------- +
| PID 0x00-04 или 0x00-0A |
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Перевод RFC-1490
|
|
||
|
|
|||
|
| pad 0x00 | Frame Control |
+ --------------- + --------------- +
| MAC-адрес получателя | : :
| |
+ ------------------------------- +
| (остаток кадра MAC) |
+ ------------------------------- +
| LAN FCS (если PID=0x00-04) | | |
+ ------------------------------- +
| FCS |
+ ------------------------------- +
Формат кадров Bridged 802.6
+ ------------------------------- +
| Адрес Q.922 |
|
|||
|
|
|||
|
| Control 0x03 | pad 0x00 |
+ --------------- + --------------- +
| NLPID 0x80 | OUI 0x00 |
+ --------------- + --+
| OUI 0x80-C2 |
+ ------------------------------- +
| PID 0x00-0B |
+ --------------- + --------------- + -------
| Резерв | BEtag |Заголовок
+ --------------- + --------------- +Common
| BAsize |PDU
+ ------------------------------- + -------
| MAC-адрес получателя |
: :
| |
+ ------------------------------- +
| (остаток кадра MAC) |
+ ------------------------------- +
| |
+- Трейлер Common PDU -+
| |
+ ------------------------------- +
| FCS |
+ ------------------------------- +
Отметим, что для PDU мостов 802.6 возможно только одно значение PID, поскольку наличие контрольной суммы CRC-32 указывается битом CIB в заголовке кадра MAC.
Заголовок и трейлер общего модуля данных протокола CPDU (Common Protocol Data Unit) перемещаются для того, чтобы разрешить конвейерную обработку на выходном мосту в подсеть 802.6. В частности, заголовок CPDU содержит поле BAsize, указывающее длину PDU. Если это поле недоступно для выходного моста 802.6, этот мост не сможет начать передачу сегментированного PDU до тех пор, пока не будет получен PDU целиком, рассчитан размер и значение размера помещено в поле BAsize. Если это поле доступно, выходной мост 802.6 может определить размер по значению поля BAsize в заголовке Common PDU, вставить это значение в соответствующее поле первого сегмента и незамедлительно передать пакет в подсеть 802.6. Таким образом, мост может начать передачу 802.6 PDU до того, как PDU будет принят полностью.
Однако, следует отметить, что заголовок и трейлер Common PDU инкапсулированного кадра не должны просто копироваться в адресуемую подсеть 802.6, поскольку инкапсулированное значение BEtag может конфликтовать с предыдущим значением BEtag, переданным этим мостом.
Формат кадров BPDU
+ ------------------------------- +
| Адрес Q.922 |
|
|||
|
|
|||
|
| Control 0x03 |
+ ------------------------------- +
| PAD 0x00 |
+ ------------------------------- +
| NLPID 0x80 |
+ ------------------------------- +
| OUI 0x00-80-C2 |
+ ------------------------------- +
| PID 0x00-0E |
+ ------------------------------- +
|
| BPDU в соответствии с
| 802.1d или 802.1g[12]
| |
+ ------------------------------- +
|
|||
|
|
|||
|
5. Согласование параметров канального уровня
Станции Frame Relay могут по своему выбору поддерживать идентификаторы обмена XID (Exchange Identification), определенные в в приложении Appendix III к стандарту Q.922 [1]. Обмен идентификаторами XID позволяет согласовать ряд параметров при инициализации устройства (виртуального соединения) Frame Relay - максимальный размер кадра N201, таймер повторной передачи T200 и максимальное число отложенных информационных (I) кадров K (окно).
Станция может обозначить свое нежелание поддерживать режим мультикадрового окна с подтверждением, установив нулевое значение для максимального размера окна K.
Если такой обмен не используется, перечисленные параметры должны быть заданы статически при настройке для станции параметров соединения на канальном уровне DLC (Data Link Connection) или следует использовать принятые по умолчанию значения в соответствии с разделом 5.9 спецификации Q.922: N201: 260 октетов
K: 3 для каналов 16 кбит/с, 7 для каналов 64 кбит/с,
|
|||
|
|
|||
|
|
|||||||||
|
|
Перевод RFC-1490
|
||||||||
|
|
|||||||||
|
32 для каналов 384 кбит/с,
40 для каналов 1.536 и более кбит/с T200: 1.5 сек [см. Q.922] Если станция, поддерживающая XID, получает кадр XID, она должна передать XID-отклик. Если при обработке XID обнаруживается, что на удаленной станции размер окна меньше локального значения, локальная станция должна уменьшить размер окна для данного соединения DLC в соответствии с заданным для удаленной станции размером окна. Отметим, что такое изменение размера должно быть выполнено до генерации отклика XID. На рисунке показан процесс использования XID для отказа от использования мультикадрового окна с подтверждением.
Отказ от использования мультикадрового окна
|
|||||||||
|
|
|||||||||
|
I
|
Адрес
|
I
|
(2,3 или 4 октета)
|
||||||
|
|
|||||||||
|
+ --------------- +
| Control 0xAF |
+ --------------- +
| Формат 0x82 |
+ --------------- +
| Group ID 0x80 |
+ --------------- +
| Group Length | | 0x00-0E |
+ --------------- +
| 0x05 |
+ --------------- +
| 0x02 |
+ --------------- +
| Максимальный | | размер кадра |
+ --------------- +
| 0x06 |
+ --------------- +
| 0x02 |
+ --------------- +
| Максимальный | | размер кадра |
+ --------------- +
| 0x07 |
+ --------------- +
| 0x01 |
+ --------------- +
| 0x00 |
+ --------------- +
| 0x09 |
+ --------------- +
| 0x01 |
+ --------------- +
| 0x00 |
+ --------------- +
| FCS | | |
+ --------------- +
|
(2 октета)
PI = Размер кадра (передача)
PL = 2
(2 октета)
PI = Размер кадра (прием)
PL = 2
(2 октета)
PI = Размер окна PL = 1
|
||||||||
|
PI
|
Таймер повторной передачи
|
||||||||
|
PL = 1
|
|||||||||
|
(2 октета)
|
|||||||||
|
|
|||||||||
|
6. Вопросы фрагментации
|
|||||||||
|
Фрагментация обеспечивает возможность обмена пакетами, размер которых превышает максимальное значение размера кадра в
транспортной (underlying) сети. В сетях Frame Relay максимальный размер кадра может быть ограничен значением 262 октета.
Поскольку это значение достаточно мало, рекомендуется (но не требуется) поддерживать процедуры фрагментации и сборки
пакетов.
В отличие от процедур фрагментации IP в сетях Frame Relay процедура фрагментации ограничена устройствами DTE (граница сети
Frame Relay).
Общий формат фрагментированных пакетов не отличается от форматов фрагментированных пакетов при инкапсуляции в других
протоколах. Существенное различие заключается в том, что фрагментированный пакет содержит заголовок инкапсуляции. Это
означает, что пакет сначала инкапсулируется (за исключением полей адреса и управления) в соответствии с приведенным выше
описанием. После инкапсуляции большие пакеты делятся на кадры приемлемого для данной сети Frame Relay размера и
инкапсулируются с использованием формата фрагментации Frame Relay. В этом случае станция, принимающая пакет, может
собрать его и передать собранный пакет по тому же пути, который используется для нефрагментированных пакетов.
Во фрагментах Frame Relay применяется инкапсуляция с использованием формата SNAP (OUI=0x00-80-C2 и PID=0x00-0D).
Отдельные фрагменты, следовательно, будут иметь формат:
+ --------------- + --------------- +
| Адрес Q.922 |
+ --------------- + --------------- +
| Control 0x03 | pad 0x00 |
+ --------------- + --------------- +
| NLPID 0x80 | OUI 0x00 |
+ --------------- + --------------- +
| OUI 0x80-C2 |
+ --------------- + --------------- +
| PID 0x00-0D |
+ --------------- + --------------- +
| порядковый номер |
|
|||||||||
|
|
|||||||||
|
|F| RSVD |смещение
|
|
|
||||||||
|
|
|||||||||
|
|
|
"фрагмент данных"
|
||||||||
|
|
|||||||||
|
6
|
|||||||||
|
|
|||||||||
|
|
||||
|
Перевод RFC-1490
|
|
|||
|
|
||||
|
| . |
| . |
| . |
+ --------------- + --------------- +
| FCS |
+ --------------- + --------------- +
Порядковый номер представляет собой 2-октетное поле, значение которого увеличивается на 1 при фрагментации каждого нового
пакета. Это поле позволяет обнаруживать потерю пакетов. При инициализации для порядкового номера используется случайное
значение.
Резервное поле имеет размер 4 бита, в настоящее врем не используется и должно иметь нулевое значение.
Последнее поле является 1-битовым флагом, который имеет значение 1 для последнего фрагмента и 0 - для остальных фрагментов
пакета.
Поле смещения представляет собой 11-значение, которое указывает логическое смещение данного фрагмента (в байтах),
поделенное на 32. Смещение для первого фрагмента должно быть нулевым.
На приведенном ниже рисунке показано фрагментирование больших дейтаграмм IP при передаче через сеть Frame Relay.
Дейтаграмма в этом примере делится между двумя кадрами Frame Relay.
Пример фрагментации Frame Relay
+ ----------- + ----------- +
| Адрес Q.922 |
+ ----------- + ----------- +
| Ctrl 0x03 | pad 0x00 |
+ ----------- + ----------- +
|NLPID 0x80 | OUI 0x00 |
+ ----------- + ----------- +
| OUI 0x80-C2 |
+ ----------- + ----------- + + ----------- + ----------- +
|ctrl 0x03 |NLPID 0xCC | | PID 0x00-0D |
+ ----------- + ----------- + + ----------- + ----------- +
| | | порядковый номер n |
| | +-+ ------ +--+ ----------- +
| | |0| RSVD |смещение (0) |
| | +-+ ------ +--+ ----------- +
| | | ctrl 0x03 |NLPID 0xCC |
| | + ----------- + ----------- +
| | | первые m байтов |
|большая дейтаграмма IP | ... | дейтаграммы IP | | | | |
| | + ----------- + ----------- +
| | | FCS |
| | + ----------- + ----------- +
| |
| | + ----------- + ----------- +
| | | Адрес Q.922 |
| | + ----------- + ----------- +
| | | Ctrl 0x03 | pad 0x00 |
+ ----------- + ----------- + + ----------- + ----------- +
|NLPID 0x80 | OUI 0x00 |
+ ----------- + ----------- +
| OUI 0x80-C2 |
+ ----------- + ----------- +
| PID 0x00-0D |
+ ----------- + ----------- +
| порядковый номер n |
+-+ ------ +--+ ----------- +
|1| RSVD | смещ. (m/32) |
+-+ ------ +--+ ----------- +
| остаток дейтаграммы | | IP |
+ ----------- + ----------- +
| FCS |
+ ----------- + ----------- +
Фрагменты должны передаваться по порядку, начина с нулевого смещения и до конца пакета. Фрагменты не должны перемешиваться с другими пакетами или иной информацией, предназначенной для этого же DLC. Конечная станция должна обеспечивать возможность сборки до 2K октетов и рекомендуется обеспечивать сборку до 8K октетов. Если в процессе сборки фрагментов обнаруживается повреждение или отсутствие того или иного фрагмента, пакет должен отбрасываться целиком. В этом случае за организацию повторной передачи пакета должен отвечать протокол вышележащего уровня. Отметим, что при сборке фрагментов не используется (и не нужен) таймер, поскольку сервис Frame Relay обеспечивает доставку фрагментов с сохранением их порядка.
Этот алгоритм фрагментации не предназначен для обработки всех возможных случаев возникновения сбоев. Как и для случая фрагментации IP существует некоторая вероятность возникновения ошибки при сборке или доставки пакета с ошибками. Проверка контрольных сумм на вышележащих уровнях существенно снижает вероятность риска в результате таких ошибок.
7. Преобразование адресов
В некоторых ситуациях станциям Frame Relay может потребоваться динамическое преобразование протокольных адресов. Преобразование адресов может быть выполнено с помощью стандартного протокола ARP (Address Resolution Protocol) [6], инкапсулированного в пакетах Frame Relay со SNAP-кодированием:
+ ----------------------- + ----------------------- +
| Адрес Q.922 |
+ ----------------------- + ----------------------- +
| Control (UI) 0x03 | pad 0x00 |
+ ----------------------- + ----------------------- +
| NLPID = 0x80 | | Заголовок SNAP
+ ----------------------- + OUI = 0x00-00-00 + показывающий
| | ARP
+ ----------------------- + ----------------------- +
|
||||
|
|
||||
|
7
|
||||
|
|
||||
|
|
|||||||||
|
|
Перевод RFC-1490
|
||||||||
|
|
|||||||||
|
PID
|
0x0806
|
||||||||
|
|
|||||||||
|
| Пакет ARP |
| . |
| . |
| . |
+ ----------------------- + ----------------------- +
Пакет ARP использует следующие форматы и значения:
Данные:
ar$hrd 16 битов тип оборудования (Hardware type)
ar$pro 16 битов тип протокола (Protocol type)
ar$hln 8 битов размер аппаратного адреса в октетах (n)
ar$pln 8 битов размер протокольного адреса в октетах (m)
ar$op 16 битов код операции (запрос или отклик)
ar$sha n октетов аппаратный адрес отправителя
ar$spa m октетов протокольный адрес отправителя
ar$tha n октетов аппаратный адрес получателя
ar$tpa m октетов протокольный адрес получателя
|
|||||||||
|
|
|||||||||
|
ar$hrd - для Frame Relay используется десятичное значение 15 (0x000F) [7].
ar$pro - см. номер протокола ID для использования ARP (0x0800).
ar$hln - размер адресного поля в байтах (2, 3 или 4)
ar$pln - размер протокольного адреса зависит от протокола (ar$pro); для IP ar$pln=4.
ar$op - 1 для запросов, 2 для откликов.
ar$sha - аппаратный адрес Q.922 для отправителя с C/R, FECN, BECN и DE, равными 0.
ar$tha - аппаратный адрес Q.922 для получателя с C/R, FECN, BECN и DE, равными 0.
Поскольку идентификаторы DLCI в большинстве сетей Frame Relay имеют лишь локальное значение, конечные станции не имеют
в результате собственных (уникальных) идентификаторов DLCI. Следовательно, такие станции не имеют адреса, который можно
было бы включить в запрос или отклик ARP. К счастью, в сетях Frame Relay существует способ получения корректных значений
DLCI. Предложенное ниже решение для сетей Frame Relay с локальной адресацией будет также хорошо работать в сетях, где
идентификаторы DLCI имеют глобальную значимость.
Значения DLCI, содержащиеся в заголовках Frame Relay, изменяются при передаче кадров через сеть. Когда пакет приходит к
получателю, идентификатор DLCI может не совпадать со значением, установленным передавшей пакет станцией. Например, когда
станция A (рисунок 1) передает сообщение станции B, она будет устанавливать в заголовке Frame Relay значение DLCI=50. Когда
станция B получит это сообщение, значение DLCI будет изменено сетью (в приведенном примере DLCI=70).
|
|||||||||
|
|
|||||||||
|
|
|||||||||
|
|
|||||||||
|
( )
+ ----- + ( ) + ----- +
| |-50 ------ ( -------------------- ) --------- 70-| |
| A | ( ) | B |
| |-60 ----- ( --------- + ) | |
+ ----- + ( | ) + ----- +
( | )
( | ) <--- сеть Frame Relay
|
|||||||||
|
|
|
|
|||||||
|
|
|||||||||
|
Линии на рисунке 1
|
80
|
+ ----- +
| | | C | | | + ----- +
Рисунок 1
представляют виртуальные соединения (DLC),
|
числа показывают локальные
|
идентификаторы DLCI для
|
||||||
|
каждого соединения.
Преобразование DLCI в адреса Q.922 для рисунка 1
|
|||||||||
|
DLCI (дес.) 50 60
70 0x1061
80 0x1401
|
естн.)
|
||||||||
|
Если вы имеете представление о технологии Frame Relay, вам должно быть понятно соотношение между DLCI и Напомним просто, что преобразование между DLCI и адресами Q.922 основано на 2-байтовой длине адреса с
|
адресами Q.922. использованием
|
||||||||
|
формата кодирования Q.922, показанного ниже.
8 7 6 5 4 3 2 1
+ ------------------------ +---+--+
| DLCI (старшие биты) |c/r|ea|
+ -------------- +----+----+---+--+
| DLCI (младш.)|FECN|BECN|DE |EA|
+ -------------- +----+----+---+--+
Для ARP и вариантов этого протокола значения битовых полей FECN, BECN, C/R и DE предполагаются нулевыми.
Когда сообщение ARP приходит к адресату, все аппаратные адреса в нем являются некорректными. Однако, адреса, определенные
из заголовков кадров, остаются верными. Хотя это и нарушает чистоту деления по уровням, Frame Relay может использовать
адреса из заголовков в качестве аппаратных адресов отправителей. Следует отметить, что аппаратные адреса получателей в
запросах и откликах ARP также являются некорректными. Это не должно вызывать сложностей, поскольку ARP не использует эти
поля и, фактически, для них можно задавать нулевые значения или просто игнорировать.
В качестве примера работы схемы замены адресов снова рассмотрим рисунок 1. Если станция A (протокольный адрес pA) хочет
преобразовать адрес станции B (протокольный адрес pB), она должна сформировать запрос ARP со следующими значениями:
Запрос ARP от станции A
ar$op 1 (запрос)
|
|||||||||
|
|
|||||||||
|
8
|
|||||||||
|
|
|||||||||
|
|
|||
|
Перевод RFC-1490
|
|
||
|
|
|||
|
ar$sha неизвестен
ar$spa pA
ar$tha не определен
ar$tpa pB Поскольку станция A не имеет связанного с ней адреса отправителя, поле аппаратного адреса отправителя является некорректным. Следовательно, при получении запроса ARP корректный аппаратный адрес должен быть определен из заголовка Frame Relay и помещен в поле аппаратного адреса отправителя. В результате этого запрос ARP принимает форму:
Запрос ARP от станции A после изменения станцией B
ar$op 1 (запрос)
ar$sha 0x1061 (DLCI 70) из заголовка Frame Relay
ar$spa pA
ar$tha не определен
ar$tpa pB Протокол ARP на станции B может сейчас корректно сохранить протокольный адрес станции A и ее адрес Q.922 в таблице ARP. После этого станция B будет формировать отклик. Многие разработчики просто помещают адрес отправителя из запроса ARP в поле адреса получателя, а в поле адреса отправителя указывают свой адрес. В этом случае отклик ARP будет иметь вид:
Отклик ARP от станции B
ar$op 2 (отклик)
ar$sha неизвестен
ar$spa pB
ar$tha 0x1061 (DLCI 70)
ar$tpa pA Аппаратный адрес отправителя по-прежнему остается неизвестным и при получении отклика станция A должна получить адрес из заголовка Frame Relay и поместить его в поле аппаратного адреса отправителя. После этой операции отклик имеет форму:
Отклик ARP от станции B после изменения его станцией A
ar$op 2 (отклик) ar$sha 0x0C21 (DLCI 50) ar$spa pB
ar$tha 0x1061 (DLCI 70) ar$tpa pA Станция A сейчас может корректно распознавать станцию B по ее протокольному адресу pB, связанному с адресом Q.922 - 0x0C21 (DLCI 50).
Обратное преобразование адресов (RARP) [8] будет выполняться по аналогии с прямым. Возвращаясь к рисунку 1, предположим, что станция C является сервером адресов. В этом случае произойдет следующий обмен пакетами RARP:
RARP-запрос от A Запрос RARP после изменения станцией C
ar$op 3 (RARP-запрос) ar$op 3 (RARP-запрос) ar$sha неизвестен ar$sha 0x1401 (DLCI 80)
ar$spa не определен ar$spa не определен
ar$tha 0x0CC1 (DLCI 60) ar$tha 0x0CC1 (DLCI 60) ar$tpa pC ar$tpa pC
Станция C будет искать протокольный адрес, соответствующий адресу Q.922 0x1401 (DLCI 80), и передавать отклик RARP. RARP-отклик от C Отклик RARP после изменения станцией A
ar$op 4 (отклик RARP) ar$op 4 (отклик RARP) ar$sha неизвестен ar$sha 0x0CC1 (DLCI 60)
ar$spa pC ar$spa pC
ar$tha 0x1401 (DLCI 80) ar$tha 0x1401 (DLCI 80) ar$tpa pA ar$tpa pA
Это означает, что интерфейс Frame Relay должен включаться только в обработку входящих пакетов.
При отсутствии подходящего механизма групповой адресации (multicast) процедуру ARP все равно можно реализовать. Для решения этой задачи конечная станция просто должна передать копию запроса ARP с использованием всех имеющих отношение к делу DLC (это имитирует широковещательную рассылку).
Вопрос использования групповых адресов в среде Frame Relay рассматривается операторами Frame Relay. После принятия положительного решения групповая адресация может оказаться полезной для передачи запросов ARP и других "широковещательных" сообщений.
По причине неэффективности эмуляции широковещания в среде Frame Relay, был разработан новый вариант преобразования адресов. Этот метод получил название Inverse ARP [11] (инверсное преобразование) и основан на определении протокольного адреса при известном аппаратном адресе. Для случая Frame Relay известным аппаратным адресом является идентификатор DLCI. Использование Inverse ARP для сред Frame Relay практически не отличается от схем использования ARP и RARP (т. е. аппаратный адрес отправителя определяется приемной станцией).
В нашем примере станция A может использовать Inverse ARP для определения протокольного адреса станции, связанной с DLCI 50. Запрос Inverse ARP будет иметь вид:
InARP-запрос от станции A (DLCI 50)
ar$op 8 (InARP-запрос)
ar$sha неизвестен
ar$spa pA
ar$tha 0x0C21 (DLCI 50)
ar$tpa неизвестен Когда станция B получит этот пакет, она заменит значение аппаратного адреса отправителя адресом Q.922 из заголовка Frame Relay. Таким образом запрос InARP примет форму:
ar$op 8 (запрос InARP)
ar$sha 0x1061
ar$spa pA
ar$tha 0x0C21
ar$tpa неизвестен. Станция B будет формировать отклик Inverse ARP и передавать его станции A, как это делается для всех сообщений ARP.
|
|||
|
|
|||
|
|
|||
|
|
Перевод RFC-1490
|
||
|
|
|||
|
8. Передача IP через Frame Relay
|
|||
|
Дейтаграммы IP [9] (IP) передаются через сеть Frame Relay с использованием описанной выше инкапсуляции. В этом контексте может использоваться два варианта инкапсуляции IP.
1. Значение NLPID указывает на IP
+ ----------------------- + ----------------------- +
| Адрес Q.922 |
|
|||
|
|
|||
|
| Control (UI) 0x03 | NLPID = 0xCC |
+ ----------------------- + ----------------------- +
| IP-пакет . |
| . |
| . |
+ ----------------------- + ----------------------- +
2. Значение NLPID указывает на SNAP
+ ----------------------- + ----------------------- +
| Адрес Q.922 |
+ ----------------------- + ----------------------- +
| Control (UI) 0x03 | pad 0x00 |
+ ----------------------- + ----------------------- +
| NLPID = 0x80 | | Заголовок SNAP,
+ ----------------------- + OUI = 0x00-00-00 + указывающий
| | IP
+ ----------------------- + ----------------------- +
| PID = 0x0800 |
+ ----------------------- + ----------------------- +
| IP-пакет |
| . |
| . |
| . |
+ ----------------------- + ----------------------- +
Хотя оба варианта поддерживаются описанной схемой инкапсуляции, лучше выбрать для инкапсуляции данных IP единственный метод. Следовательно, данные IP должны инкапсулироваться с использованием значения NLPID=0xCC, указывающего протокол IP (вариант 1). Этот вариант инкапсуляции обеспечивает большую эффективность (заголовок уменьшается на 48 битов) и согласуется с инкапсуляцией IP в сетях X.25.
9. Передача других протоколов через Frame Relay
Как и в случае инкапсуляции IP существуют альтернативные способы передачи разных протоколов в рамках настоящего
определения. Во избежание конфликтов SNAP-инкапсулция используется только в тех случаях, когда для протокола не определено
значение NLPID.
В качестве примера рассмотрим протокол ISO CLNP, для которого определено NLPID=0x81.
Следовательно, поле NLPID будет указывать на протокол ISO CLNP и данные из пакета могут помещаться вслед за NLPID. Кадр
будет иметь следующий формат:
+ --------------------------------------------- +
| Адрес Q.922 |
|
|||
|
|
|||
|
| Control (0x03) | NLPID - 0x81 (CLNP) |
+ ---------------------- + ---------------------- +
| остаток пакета CLNP |
| . |
| . |
+ --------------------------------------------- +
В этом примере значение NLPID служит для идентификации принадлежности пакета протоколу CLNP. Это поле рассматривается так же в качестве части пакета CLNP и, таким образом, поле NLPID не должно удаляться перед отправкой пакета для обработки протоколу вышележащего уровня. Значение поля NLPID не дублируется в пакетах.
Некоторые протоколы (например, IPX) не имеют значения NLPID. В соответствии со сказанным выше, протокол IPX должен инкапсулироваться с использованием заголовка SNAP. В этом случае кадр будет иметь формат:
+ --------------------------------------------- +
| Адрес Q.922 |
|
|||
|
|
|||
|
| Control 0x03 | pad 0x00 |
+ ---------------------- + ---------------------- +
| NLPID - 0x80 (SNAP) | OUI - 0x00 00 00 |
+ ---------------------- + |
| |
+ --------------------------------------------- +
| PID = 0x8137 |
+ --------------------------------------------- +
| пакет IPX |
| . |
| . |
+ --------------------------------------------- +
|
|||
|
|
|||
|
10. Модель мостов для Frame Relay
Модель организации мостов в сетях Frame Relay идентична модели удаленных мостов, описанной в стандарте IEEE P802.1g Remote MAC Bridging [13], и поддерживает концепцию виртуальных портов (Virtual Port). Удаленные мосты с портами ЛВС принимают и передают MAC-кадры для (от) локальных сетей, к которым эти порты подключены. Мосты могут также передавать кадры MAC через виртуальные порты другим удаленным мостам или принимать кадры от таких мостов. Виртуальный порт может представлять абстракцию точки доступа удаленного моста к одному или нескольким другим удаленным мостам.
Удаленные мосты с помощью системы сетевого управления статически задаются в качестве членов группы удаленного моста. Все члены группы удаленного моста подключены к одному или нескольким виртуальным портам. Множество удаленных мостов MAC-уровня в группе удаленного моста обеспечивает реальное или "потенциальное" соединение MAC-уровн между множеством ЛВС и другими группами удаленных мостов, с которыми удаленные мосты (данной группы) соединены.
|
|||
|
|
|||
|
|
|||
|
Перевод RFC-1490
|
|
||
|
|
|||
|
В сети Frame Relay должна присутствовать полносвязная (full mesh - каждый с каждым) сеть виртуальных соединений Frame Relay (VC) между мостами и группой удаленного моста. Если сеть Frame Relay не обеспечивает полной связности, сеть на базе мостов (bridge network) должна быть поделена на множество групп удаленных мостов (remote bridge group).
Виртуальные соединения Frame Relay, связывающие мосты из группы удаленного моста, могут комбинироваться или использоваться индивидуально для формирования одного или нескольких виртуальных портов моста. Это позволяет трактовать интерфейс Frame Relay как один виртуальный порт моста со всеми VC в группе или как множество портов моста (с индивидуальными или групповыми VC).
Когда один виртуальный порт моста обеспечивает соединения для всех мостов в данной группе удаленного моста (т. е. все VC объединены в один виртуальный порт), можно использовать стандартный алгоритм Spanning Tree для определения состояния виртуального порта. Если в данной группе удаленного моста определены несколько виртуальных портов, требуется использовать расширенный алгоритм Spanning Tree (это расширение определено в стандарте IEEE 802.1g [13]). Этот алгоритм работает так, что данный виртуальный порт переводится в резервное состояние (backup) только при наличии петель во внешней по отношению к группе удаленного моста сети.
Простейшей конфигурацией для моста в сети Frame Relay является вариант ЛВС (LAN view), при котором все VC объединены в один виртуальный порт. Кадры (такие, как BPDU), которые передаются в ЛВС как широковещательные, должны пересылаться (flood) в каждое виртуальное соединение VC (или должна использоваться групповая адресация, если она поддерживается для сервиса Frame Relay). Лавинная маршрутизация (Flooding) реализуется путем передачи пакета для каждого, имеющего отношение к делу DLC, связанного с интерфейсом Frame Relay. Виртуальные соединения VC в такой среде в общем случае невидимы для моста, т. е. мост передает кадр с лавинной маршрутизацией интерфейсу Frame Relay и "не видит", что кадр передается индивидуально в каждое виртуальное соединение (VC). Если все участвующие в этом процессе мосты соединены "каждый с каждым" (full mesh), для такой конфигурации достаточно стандартного алгоритма Spanning Tree.
Обычно мосты ЛВС определяют достижимость интерфейса конкретной конечной станции, связывая MAC-адрес с портом моста. В сети Frame Relay, настроенной на работу с одним bridge-портом типа моста ЛВС (или любым набором VC, объединенных для формирования одного bridge-порта), мост должен ассоциироваться не только с MAC-адресом bridge-порта, но и с идентификатором соединения. Для сетей Frame Relay в качестве идентификаторов соединений используются значения DLCI. Неразумно, а возможно и нереально, требовать статической настройки мостов для создания ассоциаций между всеми возможными MAC-адресами получателей и DLC. Следовательно, мосты в сетях Frame Relay, действующие по типу мостов ЛВС, должны обеспечивать механизм, позволяющий bridge-портам Frame Relay динамически создавать такие ассоциации. Для реализации автоматического обучения передаваемый с использованием мостов пакет должен соответствовать требованиям к инкапсуляции, описанным в разделе 4.2. В этом случае приемный интерфейс Frame Relay будет знать, как работать с пакетом, полученным через мост, для сбора требуемой информации.
Другое приближение для мостов Frame Relay (point-to-point view) трактует каждое виртуальное соединение Frame Relay VC как отдельный порт моста. В этом варианте лавинная маршрутизация и пересылка пакетов существенно упрощаются, поскольку каждый порт моста связан с единственным адресатом (destination). Нет необходимости организовывать искусственную лавинную маршрутизацию (flooding) или связывать DLCI с MAC-адресами получателей. В зависимости от топологии соединений (VC) может потребоваться использование расширенного алгоритма Spanning Tree для того, чтобы сохранялась активность всех портов, пока не возникает петель во внешней по отношению к группе удаленного моста.
Возможно также использовать комбинированную (LAN и point-to-point) модель для одного интерфейса Frame Relay. Для реализации такого подхода некоторые VC объединяются для формирования одного виртуального bridge-порта, а остальные VC образуют независимые порты мостов. На рисунке показаны различные варианты конфигурации мостов (пунктирные линии задают виртуальные соединения).
+ ------- +
------------------- | B |
/ ------- | |
/ / + ------- +
/ |
+ ------- +/ \ + ------- +
| A | ------- | C |
| | ----------------------- | |
+ ------- +\ + ------- +
\
\ + ------- +
\ | D |
------------------- | |
+ ------- +
Поскольку в приведенном примере отсутствует полная связность (VC между каждой парой мостов), сеть должна быть разделена на
несколько групп remote bridge. Разумно объединить мосты A, B и C в одну группу, а мосты A и D - в другую.
Конфигурация первой группы объединяет VC, соединяющие три моста (A, B, C) в один виртуальный порт. Это является примером
LAN-конфигурации. Вторая группа также содержит один виртуальный порт, который просто соединяет мосты A и D. В этой
конфигурации стандартного алгоритма Spanning Tree достаточно для обнаружения петель.
Альтернативный вариант конфигурации будет иметь три отдельных виртуальных порта, соответствующих VC, которые связывают
мосты A, B и C. Поскольку применение стандартного алгоритма Spanning Tree в этой конфигурации будет приводить к
обнаружению петли, для сохранения активности всех виртуальных портов требуется использовать расширенный алгоритм Spanning
Tree. Отметим, что вторая группа по-прежнему содержит один виртуальный порт и может использовать стандартный алгоритм
Spanning Tree.
Используя тот же пример (см. рисунок), мы можем создать конфигурацию удаленных мостов с тремя группами. Это будет
примером конфигурации point-to-point. В этом случае виртуальные соединения VC, связывающие A и B, VC между A и C, а также
VC между A и D являются bridge-группами с одним виртуальным портом.
11. Приложение A
Список часто используемых значений NLPID
0x00 Null Network Layer или Inactive Set (не используется с Frame Relay)
0x80 SNAP
0x81 ISO CLNP
0x82 ISO ESIS
0x83 ISO ISIS
0xCC Internet IP
|
|||
|
|
|||
|
|
||||||||||||||||
|
|
Перевод RFC-1490
|
|||||||||||||||
|
|
||||||||||||||||
|
Список PID для OUI=00-80-C2
С сохраненной
|
FCS
|
без сохраненной FCS Среда
|
||||||||||||||
|
|
--------------
802.3/Ethernet
802.4
802.5
FDDI
802.6
Фрагменты
BPDU в соотв. с
|
802.1d или 802.1g[12].
|
||||||||||||||
|
0x00-01 0x00-02 0x00-03 0x00-04
|
|
|||||||||||||||
|
0x00-07 0x00-08 0x00-09 0x00-0A 0x00-OB 0x00-OD 0x00-OE
|
||||||||||||||||
|
|
||||||||||||||||
|
12. Приложение B - Ориентированные на соединения процедуры
Это приложение содержит дополнительные сведения и рекомендации по использованию CCITT Q.933 и других стандартов CCITT для инкапсуляции данных в сетях Frame Relay. Содержащаяся здесь информация подобна (в некоторых случаях идентична) сведениям, содержащимся в приложении Annex F к стандарту ANSI T1.617 (Rao Cherukuri, корпорация IBM). Первичным источником является Annex F, а в настоящем документе эти сведения приведены только для удобства.
Значения идентификаторов протокола сетевого уровня NLPID (Network Level Protocol ID) распределяются ISO и CCITT. Список содержит идентификаторы для множества протоколов, включая IP, CLNP (ISO 8473) CCITT Q.933, ISO 8208. На рисунке показаны общие методы инкапсуляции при передаче данных через сети Frame Relay. Гибкость приведенной схемы заключается в идентификации различных вариантов обозначения протоколов, используемых
- системами сквозной передачи (end-to-end system)
- мостами или маршрутизаторами, соединяющими ЛВС
- или комбинированными системами для передачи трафика через сети Frame Relay.
Q.922 control |
|
||||||||||||||||
|
|
||||||||||||||||
|
|
||||||||||||||||
|
|
||||||||||||||||
|
|
|
|
|
|
|
|||||||||||||
|
I Frame
|
||||||||||||||||
|
UI
|
||||||||||||||||
|
|
|
|
|
|
|
|||||||||||||
|
|
||||||||||||||||
|
|
|
|||||||||||||||
|
|
||||||||||||||||
|
I 0x08 I 0x81
|
I OxCC
|
I 0x80 I ..01.... I ..10....
|
||||||||||||||
|
|
||||||||||||||||
|
| Q.933
|
CLNP
|
IP
|
SNAP
|
ISO 8208 Modulo 8
|
ISO 8208 Modulo 128
|
|||||||||||
|
|
||||||||||||||||
|
|
OUI
|
|||||||||||||||
|
|
||||||||||||||||
|
L2 ID
|
L3 ID User
specified 0x70
|
|
|
||||||||||||||
|
|
||||||||||||||||
|
I I | | 802.3 802.6
|
||||||||||||||||
|
|
||||||||||||||||
|
|
||||||||||||||||
|
|
||||||||||||||||
|
|
||||||||||||||||
|
|0x51 |0x4E |
|
I 0x4C
|
|||||||||||||||
|
|
||||||||||||||||
|
| | | | 7776 Q.922 Прочие 802.2 Для тех протоколов, не имеющих идентификатора NLPID или не поддерживающих SNAP-инкапсулцию, следует использовать значение NLPID=0x08, указывающее на необходимость применять рекомендации CCITT Q.933. 4 октета после поля NLPID включают идентификацию протоколов канального (2) и сетевого (3) уровня. Коды для большинства протоколов определены информационными элементами совместимости на нижних уровнях в стандарте ANSI T1.617. Этот же стандарт содержит варианты для определения нестандартных протоколов.
Формат заголовка для других протоколов с использованием Q.933 NLPID
|
||||||||||||||||
|
|
||||||||||||||||
|
|
|
Адрес Q.922
|
|
|
||||||||||||||
|
|
||||||||||||||||
|
|Control 0x03 | NLPID 0x08 |
+ --------------- + --------------- +
| L2 Protocol ID |
| октет 1 | октет 2 |
|
||||||||||||||||
|
|
||||||||||||||||
|
| октет 2
|
L3 Protocol ID | октет 2
|
|||||||||||||||
|
+ -------------------------
| Протокольные данные
|
||||||||||||||||
|
|
||||||||||||||||
|
I
|
Адрес Q.922
|
|
|
||||||||||||||
|
|
||||||||||||||||
|
|Control 0x03 | NLPID 0x08 |
+ --------------- + --------------- +
| L2 Protocol ID |
| октет 1 | октет 2 |
+ ------------------------------- +
| L3 Protocol ID |
| октет 2 | октет 2 |
+ ------------------------------- +
| Протокольные данные |
+ ------------------------------- +
| FCS |
+ ------------------------------- +
|
||||||||||||||||
|
|
||||||||||||||||
|
12
|
||||||||||||||||
|
|
||||||||||||||||
|
|
|||
|
Перевод RFC-1490
|
|
||
|
|
|||
|
ISO 8802/2 с заданным пользователем уровнем 3
+ ------------------------------- +
| Адрес Q.922 |
+ --------------- + --------------- +
|Control 0x03 | NLPID 0x08 |
+ --------------- + --------------- +
| 802/2 0x4C | 0x80 |
+ ------------------------------- +
|User Spec. 0x70| Примечание 1 |
|
|||
|
|
|||
|
| DSAP | SSAP |
+ ------------------------------- +
| Control (Примечание 2) |
+ ------------------------------- +
| Остаток PDU |
+ ------------------------------- +
| FCS |
+ ------------------------------- +
Примечание 1: Показывает код заданного пользователем протокола сетевого уровня. Примечание 2: Поле Control содержит два октета для кадров формата I и S (см. 88002/2)
Инкапсуляция с использованием I-кадра (уровень 2)
I-кадры Q.922 I используются для поддержки протоколов сетевого уровня, которые требуют подтверждений от канального уровня (например, ISO 8208). Бит C/R (адрес T1.618) будет использоваться для индикации команд и откликов.
Формат кадра ISO 8208 с модулем 8
|
|||
|
|
|||
|
| Адрес Q.922 |
+ --------------- + --------------- +
| ....Control I frame |
+ --------------- + --------------- +
| Пакет 8208 (modulo 8) Прим. 3 | | |
+ ------------------------------- +
| FCS |
+ ------------------------------- +
Примечание 3: Первый октет пакетов 8208 также идентифицирует NLPID (..01....).
Формат кадра ISO 8208 с модулем 128
|
|||
|
|
|||
|
| Адрес Q.922 |
+ --------------- + --------------- +
| ....Control I frame |
+ --------------- + --------------- +
| Пакет 8208 (modulo 128) | | Примечание 4 |
+ ------------------------------- +
| FCS |
+ ------------------------------- +
Примечание 4: Первый октет пакетов 8208 также идентифицирует NLPID (..10....).
|
|||
|
|
|||
|
13. Литература
|
|||
|
[1] International Telegraph and Telephone Consultative Committee, "ISDN Data Link Layer Specification for Frame Mode Bearer Services", CCITT Recommendation Q.922, 19 April 1991.
[2] American National Standard For Telecommunications - Integrated Services Digital Network - Core Aspects of Frame Protocol for Use with Frame Relay Bearer Service, ANSI T1.618-1991, 18 June 1991.
[3] Information technology - Telecommunications and Information Exchange between systems - Protocol Identification in the Network Layer, ISO/IEC TR 9577: 1990 (E) 1990-10-15.
[4] Baker, F., Editor, "Point to Point Protocol Extensions for Bridging", RFC 1220, ACC, April 1991.
[5] International Standard, Information Processing Systems - Local Area Networks - Logical Link Control, ISO 8802-2: 1989 (E), IEEE Std 802.2-1989, 1989-12-31.
[6] Plummer, D., "An Ethernet Address Resolution Protocol - or - Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware", STD 37, RFC 826, MIT, November 1982.
[7] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1340, USC/Information Sciences Institute, July 1992.
[8] Finlayson, R., Mann, R., Mogul, J., and M. Theimer, "A Reverse Address Resolution Protocol", STD 38, RFC 903, Stanford University, June 1984.
[9] Postel, J. and Reynolds, J., "A Standard for the Transmission of IP Datagrams over IEEE 802 Networks", RFC 1042, USC/Information Sciences Institute, February 1988.
[10] IEEE, "IEEE Standard for Local and Metropolitan Area Networks: Overview and architecture", IEEE Standards 802-1990.
[11] Bradley, T., and C. Brown, "Inverse Address Resolution Protocol", RFC 1293, Wellfleet Communications, Inc., January 1992.
[12] IEEE, "IEEE Standard for Local and Metropolitan Networks: Media Access Control (MAC) Bridges", IEEE Standard 802.1D-1990.
[13] PROJECT 802 - LOCAL AND METROPOLITAN AREA NETWORKS, Draft Standard 802.1G: Remote MAC Bridging, Draft 6, October 12, 1992.
14. Вопросы безопасности
В данном документе вопросы безопасности не рассматриваются.
|
|||
|
|
|||
|
|
|||
|
|
||||
|
|
Перевод RFC-1490
|
|||
|
|
||||
|
15. Адреса авторов
Terry Bradley
Wellfleet Communications, Inc.
15 Crosby Drive
Bedford, MA 01730
Phone: (617) 280-2401
Email: tbradley@wellfleet.com
Caralyn Brown
Wellfleet Communications, Inc.
15 Crosby Drive
Bedford, MA 01730
Phone: (617) 280-2335
Email: cbrown@wellfleet.com
Andrew G. Malis Ascom Timeplex, Inc. Advanced Products Business Unit 289 Great Road Suite 205 Acton, MA 01720 Phone: (508) 266-4500 Email: malis_a@timeplex.com
Перевод на русский язык
Николай Малых
BiLiM Systems Ltd.
194354, Санкт-Петербург, К-354, а/я 153
тел. (812) 325-2068
Email: nmalykh@bilim.com
|
||||
|
|
||||
|
14
|
||||
|
prostitutka-krasnoyarsk Проститутки Красноярска.
|
||||