|
|
|
|
|||||||
|
|
|||||||||
|
|
|||||||||
|
|
|||||||||
|
Network Working Group Request for Comments: 2427 STD: 55
Obsoletes: 1490, 1294 Category: Standards Track
|
C. Brown
Consultant
A. Malis
Ascend Communications, Inc.
September 1998
|
||||||||
|
|
|||||||||
|
Multiprotocol Interconnect over Frame Relay Статус документа
Этот документ содержит спецификации стандарта Internet для сообщества Internet и приглашает к обсуждению вопроса для дальнейшего развития стандарта. Статус документа вы можете найти в текущей редакции Internet Official Protocol Standards (STD 1). Допускается свободное распространение документа.
Авторские права
Copyright (C) The Internet Society (1998). All Rights Reserved.
|
|||||||||
|
|
|||||||||
|
Тезисы
|
|||||||||
|
В этом документе описаны методы инкапсуляции для передачи межсетевого трафика через магистрали Frame Relay.
|
В документе
|
||||||||
|
рассмотрены вопросы маршрутизации и организации мостов (Bridging).
Системы, способные поддерживать оба описанных в документе метода инкапсуляции, а также иные методы, должны знать a-priori для каких виртуальных устройств используется тот или иной метод инкапсуляции. Инкапсуляция определенного типа может использоваться только для тех виртуальных устройств, которые настроены на такое использование.
|
|||||||||
|
|
|||||||||
|
Благодарности
|
|||||||||
|
Этот документ не был бы завершен без поддержки Terry Bradley из компании Avici Systems, Inc.. В документе содержатся результаты работы множества людей. Особо отметим вклад Ray Samora (Proteon), Ken Rehbehn (Visual Networks), Fred Baker и Charles Carvalho (Cisco Systems), Mostafa Sherif (AT&T). Отдельная благодарность выражается Dory Leifer (University of Michigan) за вклад в рассмотрение вопросов фрагментации (несмотря на то, что этот раздел был удален из окончательной версии документа), а также Floyd Backes и Laura Bridge (3Com) за их вклад в рассмотрение вопросов, связанных с мостами. Документ никогда бы не удалось завершить без использования опыта рабочих групп IETF "IP over Large Public Data Networks" и "IP over NBMA".
|
|||||||||
|
|
|||||||||
|
1. Терминология и
|
сокращения
|
||||||||
|
Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует(SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе должны интерпретироваться в соответствии с документом [16]. На схемах в документе биты выводятся слева направо по старшинству (младший бит слева) 0 1 2 3 4 5 6 7 биты октета
|
|||||||||
|
|
|||||||||
|
+------------------------------+
I Флаг (7Е шестнадцатеричное)|
|
|||||||||
|
|
|||||||||
|
I
|
Адрес Q.922
|
|
|||||||
|
|
|||||||||
|
+-- --+
| |
+ --------------------------- +
: :
: :
+ --------------------------- +
Для больших диаграмм в одной строке может размещаться изображение двух октетов. На некоторых рисунках старший бит показан слева (такие случаи указаны явно).
|--- октет 1 ---|--- октет 2 ---| 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|
|||||||||
|
|
|||||||||
|
| Уникальный идентификатор
+-- + ---------------
| организации | Идентификатор
+ ----------------------- + ---------------
| протокола |
|
|||||||||
|
|
|||||||||
|
Ниже приведен список основных сокращений, использованных в документе.
BECN Backward Explicit Congestion Notification - обратное уведомление о насыщении
BPDU Bridge Protocol Data Unit - единица данных протокола моста
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 (название компании)
|
|||||||||
|
|
|||||||||
|
|
||||
|
|
Перевод RFC-2427
|
|||
|
|
||||
|
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]. Кроме того, рекомендуется включать в кадры информацию, позволяющую идентифицировать протокол, передаваемый в 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), рассмотренного ниже.
Необязательное поле pad используется для выравнивания оставшейся части кадра по 2-октетной границе. Поле pad может
содержать один или два октета; значение октетов заполнения должно быть нулевым. Далее будут приведены явные рекомендации
по использованию пол заполнения.
Значения пол идентификатора протокола сетевого уровня NLPID (Network Level Protocol ID) распределяются ISO и ITU.
Предусмотрены идентификаторы для множества распространенных протоколов, включая 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.
Для тех протоколов, которые еще не получили идентификатора NLPID, требуется обеспечить механизм простой идентификации
протокола. Существует значение NLPID, показывающее присутствие заголовка SNAP.
Заголовок SNAP имеет форму:
|
||||
|
|
||||
|
2
|
||||
|
|
||||
| |
|||
| Перевод
RFC-2427
|
|||
| |
|||
| |
Уникальный идентификатор
|
+--
+ -------------------- +
|
организации
| Идентификатор |
+
----------------------- + -------------------- +
|
протокола |
+
----------------------- +
Трехоктетное
поле 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 для используемого протокола.
При
наличии упомянутого выше заголовка SNAP используется один октет заполнения
для выравнивания протокольных данных по 2-октетной границе, как показано
ниже
Формат
маршрутизируемых кадров с заголовком SNAP
|
|||
| |
|||
| |
Адрес Q.922
|
+
--------------- + --------------- +
|Control
0x03 | pad 0x00 |
+
--------------- + --------------- +
|
NLPID 0x80 | OUI
|
+
--------------- +
--+
|
OUI
|
+
------------------------------- +
|
Идентификатор протокола (PID) |
+
------------------------------- +
|
|
|
Протокольные данные |
|
|
+
------------------------------- +
|
FCS
|
+
------------------------------- +
В
тех случаях, когда протокол имеет идентификатор NLPID (см. Приложение
A), можно сократить заголовок на 48 битов за счет использования показанного
ниже формата:
Формат
маршрутизируемых кадров при наличии NLPID для протокола
|
|||
| |
|||
| |
Адрес Q.922
|
+
--------------- + --------------- +
|Control
0x03 | NLPID |
+
--------------- + --------------- +
|
Протокольные данные |
+
------------------------------- +
|
FCS
|
+
------------------------------- +
Инкапсуляция
NLPID не требует использовать заполнение, поэтому данное поле отсутствует
в заголовке.
Для
некоторых протоколов ISO значение NLPID рассматривается как первый октет
данных протокола. В таких случаях нет необходимости дублировать поле
NLPID. Один октет используется для демультиплексирования и в качестве
данных протокола (см. параграф "Инкапсуляция других протоколов").
Другие протоколы (такие, как IP) имеют значение NLPID (для IP - 0xCC),
но это значение не является частью протокольных данных.
Формат
маршрутизируемой дейтаграммы IP
|
|||
| |
|||
| |
Адрес Q.922
|
+
--------------- + --------------- +
|Control
0x03 | NLPID 0xCC |
+
--------------- + --------------- +
|
Дейтаграмма 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-кадре.
Следуя
практике RFC 1638 [4], будем использовать неканонические MAC-адреса
получателей для инкапсуляции кадров IEEE 802.5
и
FDDI; канонические MAC-адреса получателей будут использоваться для инкапсуляции
иных кадров, рассматриваемых в данном
параграфе.
Комитет
IEEE 802.1 зарезервировал для использования с Frame Relay следующие
значения:
|
|||
| |
|||
| |
|||
|
|
|||
|
|
Перевод RFC-2427
|
||
|
|
|||
|
Значения PID для OUI 0x00-80-C2 С сохранен. FCS без сохран. FCS Среда
|
|||
|
|
|||
|
|
|||
|
|
|||
|
0x00-01 0x00-07 802.3/Ethernet
0x00-02 0x00-08 802.4
0x00-03 0x00-09 802.5
0x00-04 0x00-0A FDDI
0x00-0B 802.6
Кроме того, PID=0x00-0E при OUI=0x00-80-C2 указывает на модуль данных BPDU (Bridge Protocol Data Unit), как определено в стандарте 802.1d или 802.1g [12], а значение PID=0x00-0F идентифицирует Source Routing BPDU.
Пакеты, передаваемые с использованием мостов через сеть 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 |
+ ------------------------------- +
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Перевод RFC-2427
|
|
||
|
|
|||
|
Формат кадров Bridged FDDI
+ ------------------------------- +
| Адрес Q.922 |
+ --------------- + --------------- +
|Control 0x03 | pad 0x00 |
+ --------------- + --------------- +
| NLPID 0x80 | OUI 0x00 |
+ --------------- + --+
| OUI 0x80-C2 |
+ ------------------------------- +
| PID 0x00-04 или 0x00-0A |
|
|||
|
|
|||
|
| 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]
| |
+ ------------------------------- +
| FCS |
+ ------------------------------- +
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
Перевод RFC-2427
|
||
|
|
|||
|
Формат кадров Source Routing BPDU
+ ------------------------------- +
| Адрес Q.922 |
|
|||
|
|
|||
|
| Control 0x03 |
+ ------------------------------- +
| PAD 0x00 |
+ ------------------------------- +
| NLPID 0x80 |
+ ------------------------------- +
| OUI 0x00-80-C2 |
+ ------------------------------- +
| PID 0x00-0F |
+ ------------------------------- +
| |
| Source Routing BPDU | | |
| |
+ ------------------------------- +
| FCS |
+ ------------------------------- +
|
|||
|
|
|||
|
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 кбит/с,
32 для каналов 384 кбит/с,
40 для каналов 1.536 и более кбит/с T200: 1.5 сек [см. Q.922] Если станция, поддерживающая XID, получает кадр XID, она должна передать XID-отклик. Если при обработке XID обнаруживается, что на удаленной станции размер окна меньше локального значения, локальная станция должна уменьшить размер окна для данного соединения DLC в соответствии с заданным для удаленной станции размером окна. Отметим, что такое изменение размера должно быть выполнено до генерации отклика XID. На рисунке показан процесс использования XID для отказа от использования мультикадрового окна с подтверждением.
Отказ от использования мультикадрового окна
+ --------------- +
| Адрес | (2,3 или 4 октета) | |
+ --------------- +
| Control 0xAF |
|
|||
|
|
|||