RFC 2427 Multiprotocol Interconnect over Frame Relay

Network Working Group                                       C. Brown
Request for Comments: 2427                                Consultant
STD: 55                                                     A. Malis
Obsoletes: 1490, 1294                    Ascend Communications, Inc.
Category: Standards Track                             September 1998

Многопротокольные соединения через Frame Relay

Multiprotocol Interconnect over Frame Relay

PDF

Статус документа

Этот документ содержит спецификации стандарта 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 биты октета
+---+---+---+---+---+---+---+

+---------------------------+
|Флаг (7E шестнадцатеричное)|
+---------------------------+
|       Адрес 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 (название компании)

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 имеет форму:

+--------------------------------------------+
| Уникальный идентификатор                   |
+--                     +--------------------+
| организации           | Идентификатор      |
+-----------------------+--------------------+
| протокола             |
+-----------------------+

Трехоктетное поле 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-адреса получателей будут использоваться для инкапсуляции иных кадров, рассматриваемых в данном параграфе.

Значения 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

Комитет IEEE 802.1 зарезервировал для использования с Frame Relay следующие значения:

Кроме того, 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                           |
+-------------------------------+

Формат кадров 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                           |
+-------------------------------+

Формат кадров 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), определенные в приложении 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  |
+---------------+
| Формат 0x82   |
+---------------+
| Group ID 0x80 |
+---------------+
| Group Length  | (2 октета)
| 0x00-0E       |
+---------------+
| 0x05          | PI = Размер кадра (передача)
+---------------+
| 0x02          | PL = 2
+---------------+
| Максимальный  | (2 октета)
| размер кадра  |
+---------------+
| 0x06          | PI = Размер кадра (прием)
+---------------+
| 0x02          | PL = 2
+---------------+
| Максимальный  | (2 октета)
| размер кадра  |
+---------------+
| 0x07          | PI = Размер окна
+---------------+
| 0x01          | PL = 1
+---------------+
| 0x00          |
+---------------+
| 0x09          | PI = Таймер повторной передачи
+---------------+
| 0x01          | PL = 1
+---------------+
| 0x00          |
+---------------+
| FCS           | (2 октета)
|               |
+---------------+

6. Преобразование адресов для PVC

В данном документе вопросы преобразования адресов рассматриваются только для постоянных соединений PVC. Работа с коммутируемыми соединениями SVC будет рассмотрена в других документах.

В некоторых ситуациях станциям 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
+-----------------------+-----------------------+
| 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
                   ~~~~~~~~~~~~~~~~
                         80
                         |
                      +-----+
                      |     |
                      |  C  |
                      |     |
                      +-----+

Рисунок 1

Линии на рисунке 1 представляют виртуальные соединения (DLC), числа показывают локальные идентификаторы DLCI для каждого соединения.

Преобразование DLCI в адреса Q.922 для рисунка 1

DLCI (дес.)   адрес Q.922 (шестн.)
50            0x0C21
60            0x0CC1
70            0x1061
80            0x1401

Официальные сведения о соотношениях между DLCI и адресами Q.922 следует искать в спецификации Q.922 [1]. Здесь мы лишь напомним о том, что преобразование между DLCI и адресами Q.922 основано на 2-байтовой длине адреса с использованием формата кодирования 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 (запрос)
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, как указано в работе [19], рассматривается операторами Frame Relay. Отметим, что групповая адресация может оказаться полезной для передачи запросов ARP и других “широковещательных” сообщений.

По причине неэффективности эмуляции широковещания в среде Frame Relay, был разработан новый вариант преобразования адресов. Этот метод получил название Inverse ARP [11] (инверсное преобразование) и основан на определении протокольного адреса при известном аппаратном адресе. Для случая Frame Relay известным аппаратным адресом является идентификатор DLCI. Поддержка Inverse ARP не требуется для реализации данной спецификации, но она может оказаться весьма полезной для автоматической настройки конфигурационных параметров интерфейсов Frame Relay. Описание и примеры использования Inverse ARP для сетей Frame Relay приводятся в работе [11]

Станции должны быть способны отобразить несколько адресов IP из одной IP-подсети (префикс адреса CIDR) на один идентификатор DLCI интерфейса Frame Relay. Это требование порождается приложениями (типа систем удаленного доступа), в которых серверы должны функционировать как ARP-прокси для множества удаленных (dial-in) клиентов, каждый из которых использует собственный адрес IP при работе через одно соединение DLC. Динамическая природа таких приложений приводит к частым сменам адресных ассоциаций, которые не должны влиять на состояние DLC, сообщаемое системой сигнализации Frame Relay PVC Status Signaling.

Как и другие интерфейсы, использующие протокол ARP, станции могут обучаться, определяя ассоциации между IP-адресами и DLCI путем обработки запросовARP, поступающих в соединение DLC. Если одна станция (возможно, терминальный сервер или сервер удаленного доступа) хочет проинформировать станцию того же уровня (peer) на другой стороне Frame Relay DLC о новой связи между адресом IP и постоянным соединением PVC, такая станция должна передать по своей инициативе запрос ARP с IP-адресом отправителя, который совпадает с IP-адресом получателя, после чего обе станции будут знать о том, что в данном DLC используется новый IP-адрес. Это позволяет станции «анонсировать» новое клиентское подключение для отдельного DLCI. Принимающая станция должна сохранить новую ассоциацию и удалить (при необходимости) ассоциации для этого адреса с любыми другими DLCI на данном интерфейсе.

7. Передача 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.

8. Передача других протоколов через 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                                   |
| .                                           |
+---------------------------------------------+

9. Модель мостов для Frame Relay

Модель организации мостов в сетях Frame Relay идентична модели удаленных мостов, описанной в стандарте IEEE P802.1g Remote MAC Bridging [13], и поддерживает концепцию виртуальных портов (Virtual Port). Удаленные мосты с портами ЛВС принимают и передают MAC-кадры для (от) локальных сетей, к которым эти порты подключены. Мосты могут также передавать кадры MAC через виртуальные порты другим удаленным мостам или принимать кадры от таких мостов. Виртуальный порт может представлять абстракцию точки доступа удаленного моста к одному или нескольким другим удаленным мостам.

Удаленные мосты с помощью системы сетевого управления статически задаются в качестве членов группы удаленного моста. Все члены группы удаленного моста подключены к одному или нескольким виртуальным портам. Множество удаленных мостов MAC-уровня в группе удаленного моста обеспечивает реальное или “потенциальное” соединение MAC-уровня между множеством ЛВС и другими группами удаленных мостов, с которыми удаленные мосты (данной группы) соединены.

В сети 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 достаточно для обнаружения петель.

Альтернативный вариант конфигурации будет иметь 3 отдельных виртуальных порта, соответствующих VC, которые связывают мосты A, B и C. Поскольку применение стандартного алгоритма Spanning Tree в этой конфигурации будет приводить к обнаружению петли, для сохранения активности всех виртуальных портов требуется использовать расширенный алгоритм Spanning Tree. Отметим, что вторая группа по-прежнему содержит один виртуальный порт и может использовать стандартный алгоритм Spanning Tree.

Используя тот же пример (см. рисунок), мы можем создать конфигурацию удаленных мостов с тремя группами. Это будет примером конфигурации point-to-point. В этом случае виртуальные соединения VC, связывающие A и B, VC между A и C, а также VC между A и D являются bridge-группами с одним виртуальным портом.

10. Вопросы безопасности

В этом документе определены механизмы идентификации для мультипротокольной инкапсуляции дейтаграмм в сетях Frame Relay. Во всех протоколах инкапсуляции обычно используется элемент доверия – получатель должен быть уверен, что отправитель корректно идентифицировал инкапсулируемый протокол. В общем случае приемная сторона не имеет механизма проверки корректности идентификации протокола передающей стороной.

В документе также рассматривается использование протоколов ARP и RARP в сетях Frame Relay, а эти протоколы имеет отношение к безопасности. Поскольку ARP не использует средств аутентификации, не возникает связанных с этим вопросов безопасности (например, возможность подмены хостов). При использовании протоколов ARP и RARP в сетях Frame Relay не применяется каких-либо дополнительных средств обеспечения безопасности.

11. Приложение A – NLPID и PID

Список наиболее часто используемых NLPID

0x00 Null Network Layer или Inactive Set (не используетсяс Frame Relay)
0x08 Q.933 [2]
0x80 SNAP
0x81 ISO CLNP
0x82 ISO ESIS
0x83 ISO ISIS
0xB0 FRF.9 Data Compression [14]
0xB1 FRF.12 Fragmentation [18]
0xCC IPv4
0xCF PPP in Frame Relay [17]

Список PID для OUI=00-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
0x00-0D Фрагменты
0x00-0E BPDU в соответствии с 802.1(d) или 802.1(g)[12]

12. Приложение B – Ориентированные на соединения процедуры

Это приложение содержит дополнительные сведения и рекомендации по использованию ITU Q.933 и других стандартов ITU для инкапсуляции данных в сетях Frame Relay. Содержащаяся здесь информация подобна (в некоторых случаях идентична) сведениям, содержащимся в приложении Annex E к стандарту ITU Q.933. Первичным источником является стандарт, а в настоящем документе эти сведения приведены только для удобства.

Значения идентификаторов протокола сетевого уровня NLPID (Network Level Protocol ID) распределяются ISO и ITU. Список содержит идентификаторы для множества протоколов, включая IP, CLNP (ISO 8473) ITU Q.933, ISO 8208. На рисунке показаны общие методы инкапсуляции при передаче данных через сети Frame Relay. Гибкость приведенной схемы заключается в идентификации различных вариантов обозначения протоколов, используемых

  • системами сквозной передачи (end-to-end system)
  • мостами или маршрутизаторами, соединяющими ЛВС
  • или комбинированными системами

для передачи трафика через сети Frame Relay.

                          Q.922 control
                               |
                               |
          --------------------------------------------
          |                                          |
         UI                                       I Frame
          |                                          |
    ---------------------------------         --------------
    | 0x08    | 0x81      |0xCC     | 0x80    |..01....    |..10....
    |         |           |         |         |            |
   Q.933     CLNP        IP        SNAP     ISO 8208    ISO 8208
    |                               |       Modulo 8    Modulo 128
    |                               |
    --------------------           OUI
    |                  |            |
   L2 ID              L3 ID      -------
    |               User         |     |
    |               Specified    |     |
    |               0x70        802.3 802.6
    |
    ---------------------------
    |0x51 |0x4E |     |0x4C   |0x50
    |     |     |     |       |
   7776  Q.922 Others 802.2  User
                             Specified

Для тех протоколов, не имеющих идентификатора NLPID или не поддерживающих SNAP-инкапсулцию, следует использовать значение NLPID=0x08, указывающее на необходимость применять рекомендации ITU Q.933. 4 октета после поля NLPID включают идентификацию протоколов канального (2) и сетевого (3) уровня. Коды для большинства протоколов определены информационными элементами совместимости на нижних уровнях в стандарте ITU Q.933. Пользовательские коды (User Specified) описаны в стандарте in Frame Relay Forum FRF.3.1 [15]. Этот же стандарт содержит варианты для определения нестандартных протоколов.

Формат заголовка для других протоколов с использованием Q.933 NLPID

+-------------------------------+
| Адрес Q.922                   |
+---------------+---------------+
|Control 0x03   | NLPID 0x08    |
+---------------+---------------+
| L2 Protocol ID                |
| октет 1       | октет 2       |
+-------------------------------+
| L3 Protocol ID                |
| октет 2       | октет 2       |
+-------------------------------+
| Протокольные данные           |
+-------------------------------+
| FCS                           |
+-------------------------------+

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. Приложение C – Отличия от RFC 1490

Документ RFC 1490 получил широкое распространение, многократно реализован и учтен в стандартах Frame Relay Forum FRF.3.1 [15] и ITU Q.933 [2]. В этом разделе рассмотрены отличия настоящего документа от RFC 1490, внесенные в результате практического использования спецификации и накопленного опыта взаимодействия систем.

В RFC 1490 были внесены некоторые стилистические изменения. Ни одно из этих изменений не затрагивает технических аспектов документа – целью этих изменений было сохранение приведенных в документе схем и более четкое изложение материала. Ниже перечислены наиболее существенные изменения.

  1. Требование поддержки протоколов со SNAP-инкапсуляцией для протоколов, имеющих NLPID, было снято. В RFC 1490 сказано, что для протоколов, имеющих идентификатор NLPID (например, IP), должна использоваться NLPID-инкапсуляция. Ниже в том же документе было указано, что станции должны воспринимать эти протоколы и со SNAP-инкапсуляцией. Непоследовательность такого подхода очевидна. Станции должны передавать и воспринимать инкапсуляцию NLPID для таких протоколов и могут (но не обязаны) воспринимать также SNAP-инкапсуляцию.
  2. Удален раздел, посвященный фрагментации. К настоящему времени отсутствует взаимодействие для алгоритма фрагментации, предложенного в RFC 1490. Кроме того, некоторые элементы предложенного механизма фрагментации делают его неприемлемым для отдельных приложений Frame Relay. В результате рассмотрение вопросов фрагментации было исключено из данного документа и предлагается использовать фрагментацию в соответствии со стандартом FRF.12 [18].
  3. Механизм преобразования адресов, предложенный в RFC 1490, подходит только для постоянных соединений PVC и не может быть использован в средах с коммутируемыми соединениями SVC. Поэтому название раздела в данном документе было соответствующим образом изменено. Вопросы преобразования адресов в средах с коммутируемыми соединениями SVC рассматриваются рабочей группой ION.
  4. В данном документе дополнительно рассмотрена инкапсуляция Source Routing BPDU и соответствующее добавление было сделано в Приложении A.
  5. Более четко изложены вопросы использования канонических и неканонических MAC-адресов получателей.
  6. Описание протокола Inverse ARP было опущено в связи с выпуском спецификации Inverse ARP [11].
  7. Добавлен раздел, посвященный вопросам безопасности.

14. Литература

[1] International Telecommunication Union, “ISDN Data Link Layer Specification for Frame Mode Bearer Services”, ITU-T Recommendation Q.922, 1992.

[2] International Telecommunication Union, “Signalling Specifications for Frame Mode Switched and Permanent Virtual Connection Control and Status Monitoring”, ITU-T Recommendation Q.933, 1995.

[3] Information technology – Telecommunications and Information Exchange between systems – Protocol Identification in the Network Layer, ISO/IEC TR 9577: 1992.

[4] Baker, F., and R. Bowen, “PPP Bridging Control Protocol (BCP)”, RFC 16381, June 1994.

[5] International Standard, Information Processing Systems – Local Area Networks – Logical Link Control, ISO 8802-22, ANSI/IEEE, Second Edition, 1994-12-30.

[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, November 1982.

[7] Reynolds, J., and J. Postel, “Assigned Numbers”, STD 2, RFC 17004, October 1994. См. также: http://www.iana.org/numbers.html

[8] Finlayson, R., Mann, R., Mogul, J., and M. Theimer, “A Reverse Address Resolution Protocol”, STD 38, RFC 903, June 1984.

[9] Postel, J., and J. Reynolds, “A Standard for the Transmission of IP Datagrams over IEEE 802 Networks”, RFC 1042, February 1988.

[10] IEEE, “IEEE Standard for Local and Metropolitan Area Networks: Overview and architecture”, IEEE Standard 802-19902.

[11] Bradley, T., Brown, C., and A. Malis, “Inverse Address Resolution Protocol”, RFC 2390, September 1998.

[12] IEEE, “IEEE Standard for Local and Metropolitan Networks: Media Access Control (MAC) Bridges”, IEEE Standard 802.1D-19902.

[13] ISO/IEC 15802-5 : 1998 (IEEE Standard 802.1G), Remote Media Access Control (MAC) Bridging, March 12, 19972.

[14] Frame Relay Forum, “Data Compression Over Frame Relay Implementation Agreement”, FRF.95, January 22, 1996.

[15] Frame Relay Forum, “Multiprotocol Encapsulation Implementation Agreement”, FRF.3.15, June 22, 1995.

[16] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997.

[17] Simpson, W., “PPP in Frame Relay”, RFC 1973, June 1996.

[18] Frame Relay Forum, “Frame Relay Fragmentation Implementation Agreement”, FRF.125, December 1997.

[19] Frame Relay Forum, “Frame Relay PVC Multicast Service and Protocol Implementation Agreement”, FRF.75, October 21, 1994.

15. Адреса авторов

Caralyn Brown

Consultant

EMail: cbrown@juno.com

Andrew Malis

Ascend Communications, Inc.

1 Robbins Road

Westford, MA 01886

Phone: (978) 952-7414

EMail: malis@ascend.com


Перевод на русский язык

Николай Малых

nmalykh@gmail.com

16. Полное заявление авторских прав

Copyright (C) The Internet Society (1998). Все права защищены.

Этот документ и его переводы могут копироваться и предоставляться другим лицам, а производные работы, комментирующие или иначе разъясняющие документ или помогающие в его реализации, могут подготавливаться, копироваться, публиковаться и распространяться целиком или частично без каких-либо ограничений при условии сохранения указанного выше уведомления об авторских правах и этого параграфа в копии или производной работе. Однако сам документ не может быть изменён каким-либо способом, таким как удаление уведомления об авторских правах или ссылок на Internet Society или иные организации Internet, за исключением случаев, когда это необходимо для разработки стандартов Internet (в этом случае нужно следовать процедурам для авторских прав, заданных процессом Internet Standards), а также при переводе документа на другие языки.

Предоставленные выше ограниченные права являются бессрочными и не могут быть отозваны Internet Society или правопреемниками.

Этот документ и содержащаяся в нем информация представлены “как есть” и автор, организация, которую он/она представляет или которая выступает спонсором (если таковой имеется), Internet Society и IETF отказываются от каких-либо гарантий (явных или подразумеваемых), включая (но не ограничиваясь) любые гарантии того, что использование представленной здесь информации не будет нарушать чьих-либо прав, и любые предполагаемые гарантии коммерческого использования или применимости для тех или иных задач.


1Этот документ в настоящее время утратил силу и заменен RFC 2878. Прим. перев.

2Стандарты IEEE 802 доступны на сайте http://standards.ieee.org/getieee802. Прим. перев.

4В соответствии с RFC 3232 документ RFC 1700 утратил силу STD 2. Выделенные значения доступны в базе данных, указанной ссылкой. Прим. перев.

5Стандарты Frame Relay Forum доступны для загрузки с сайта http://www.mplsforum.com/frame/Approved/. Прим. перев.

Запись опубликована в рубрике RFC. Добавьте в закладки постоянную ссылку.