4.3.4. Протокол Frame Relay

Семёнов Ю.А. (ГНЦ ИТЭФ), book.itep.ru

Протокол Frame Relay (I.122 ITU-t; ANSI T1S1.2; RFC-1490, -1315, -1604; cм. также www.frforum.com/frame-relay/5000/approved/frf.3/frf.3.1/frf3.f.0.html) является одним из новых телекоммуникационных протоколов (1993 г.), он обеспечивает большую скорость передачи данных (1,5Мбит/с), меньшие задержки, но и меньшую надежность доставки информации. Frame Relay предназначен для межсетевого общения, ориентирован на соединение и использует два протокольных уровня модели OSI. Остальные уровни должны реализоваться программно. Такая схема заметно удешевляет интерфейс. Протокол вводит понятие committed information rates (CIR - оговоренные скорости передачи), обеспечивая каждому приложению гарантированную полосу пропускания. Если приложение не использует полностью выделенную полосу, другие приложения могут поделить между собой свободный ресурс. Frame Relay гарантирует большее быстродействие, чем X.25. Стандарт предусматривает 2-х, 3-х и 4-х байтовые форматы заголовков (ANSI T1.618 и ITU-T Q.922) и синхронную передачу данных. Применение инкапсуляции гарантирует транспортировку пакетов других протоколов через сети Frame Relay. Пакет Frame Relay начинается и завершается разграничительным байтом 0x7e (что соответствует и стандарту Х.25). Максимальный размер кадра 1600 октетов. Формат пакета показан на рис. 4.3.4.1.

Рис. 4.3.4.1. Формат пакетов Frame Relay (цифры сверху - номера байт)

NLPID - идентификатор протокола сетевого уровня (network layer protocol ID).

FCS - двухбайтовая контрольная сумма кадра (frame control sum). Заполнитель является опционным и может отсутствовать.

Различные форматы заголовков кадров Frame Relay показаны на рисунках 4.3.4.2, 4.3.4.3 и 4.3.4.4. В верхней части рисунка приведена нумерация бит.

Рис. 4.3.4.2. 2-байтовый заголовок пакета Frame Relay (адрес)

C/R	бит command/response (Команда/Отклик).
E/A	бит extended address (Расширенный адрес) определяет, следует ли рассматривать следующий байт в качестве части адреса (E/A=0 заголовок продолжается в следующем октете).
DLCI	(data link control interface) адрес управляющего интерфейса информационного канала (имеет только локальный смысл). В двухбайтовой версии DLCI занимает в сумме 10 бит.
FECN	бит forward explicit congestion notification (указание на возможность реагирования на перегрузку при посылке пакетов). Сигнализирует отправителю о переполнении буферов на приеме.
BECN	бит backward explicit congestion notification (тоже для случая приема пакетов).
DE	бит discard eligibility (пометка пакета при перегрузке канала). Помеченный пакет может быть отброшен и потребуется его повторная пересылка.

При возникновении перегрузки DCE-узел отправляет устройствам-адресатам пакет с FECN=1, а узлам, шлющим ему информацию, пакет с битом BECN=1. Большое число пакетов с такими битами говорит о перегрузке и отправитель должен снизить частоту посылки пакетов или вовсе ее прекратить.

Рис. 4.3.4.3. 3-байтовый заголовок пакета Frame Relay

D/C - бит data/control (данные/управление) определяет, является ли последующее поле младшей частью DLCI или его следует интерпретировать как управляющую информацию DL-core.

Рис. 4.3.4.4. 4-байтовый заголовок пакета Frame Relay

Первым передается младший бит байта. Для управления сетью используется протокол snmp и база данных MIB. Формат кадра Frame Relay показан на рис. 4.3.4.4.

NLPID - (network layer protocol identifier) идентификатор протокола сетевого уровня. Это поле может содержать коды многих протоколов, включая IP, CCITT Q.933, ISO 8208, IEEE SNAP, CLNP (ISO 8473) и т.д. Это поле говорит получателю, какой тип протокола инкапсулирован. Коды nlpid стандартизованы документом ISO/IEC TR 9577. Некоторые допустимые коды этого поля приведены в таблице 4.3.4.1. Пользовательская информация располагается, начиная с поля управления, и содержит код 0x03 для случая пересылки без подтверждения (Q.922, UI). Для всех прочих видов обмена (кадры I- S-типов) подтверждение доставки является обязательным. Поле заполнитель предназначено для выравнивания границы полей на 2-байтовый уровень. Длина этого поля может быть равной нулю или одному байту. Поле адрес описано выше (см. рис. 4.3.4.1, 4.3.4.2, 4.3.4.3). Если за кодом NLPID следует 4 октета уровней 2 и 3, это указывает на то, что используется связь, ориентированная на соединение. Протокол Frame Relay предусматривает гибкую систему межсетевых соединения на основе мостов-шлюзов и маршрутизаторов. Все мосты и маршрутизаторы должны быть способны воспринимать и правильно интерпретировать как NLPID- так и SNAP-инкапсуляцию. Для обеспечения правильной интерпретации идентификатора протокола PID, предусмотрен 3-октетный уникальный идентификатор OUI (organizationally unique identifier). В пакетах для мостов и маршрутизатором в поле OUI предшествует двух-октетному полю PID.

Рис. 4.3.4.5. Формат маршрутизуемого кадра Frame Relay

Нетрудно видеть, что кадр Frame Relay имеет много общего с X.25 и ISDN. Здесь уже на протокольном уровне предусматривается мультикастинг.

Таблица 4.3.4.1. Коды поля NLPID (идентификатор протокола сетевого уровня)

Тип кадра	Название протокола	Код
I-кадр (ISO 8208)	N по модулю 8 N по модулю 128	0x01 0x10
UI-кадр	ip clnp q.933 snap q.922 802.2 Протокол, заданный пользователем (уровень 3)	0xcc 0x81 0x08 0x80 0x4e 0x4c 0x70

Код протокола SNAP используется и для протоколов 802.3, 802.4, 802.5, FDDI и 802.6. При вложении IP в кадры Frame Relay в поле управления записывается код 0x03, а в поле NLPID - 0xcc, начиная с байта 5 располагается тело IP-дейтограммы, за которой следует поле FCS. Формат маршрутизируемой IP-дейтограммы показан на рис. 4.3.4.5А.

Рис. 4.3.4.5А. Формат маршрутизируемой IP-дейтограммы

Аналогично осуществляется инкапсуляция пакетов протокола clnp, только здесь в поле NLPID записывается код 0x81. Для примера на рис. 4.3.4.6 и 4.3.4.7 показаны пакеты для мостов 802.3 и FDDI (см. “Multiprotocol Encapsulation over Frame Relay”).

Рис. 4.3.4.6 Формат мостового кадра Ethernet 802.3

Рис. 4.3.4.7 Формат мостового кадра FDDI

Весьма перспективным сетевым протоколом особенно для передачи мультимедийных данных является ATM. Его модификация может стать транспортным протоколом для цифрового кабельного телевидения.

Назад: 4.3.3. Интегрированные сети ISDN
Оглавление: Телекоммуникационные технологии
Вперёд: 4.3.5. Протоколы сетей ATM