Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:

Сети и телекоммуникации

.pdf
Скачиваний:
257
Добавлен:
05.06.2015
Размер:
13.44 Mб
Скачать

РАЗДЕЛ IV «СЕТИ С РЕТРАНСЛЯЦИЕЙ КАДРОВ»

Глава 29 Организация информационного обмена и характеристика интерфейса «пользователь-сеть»

Ретрансляция кадров (Frame Relay — FR) — метод синхронной доставки сообщений в сетях передачи данных с коммутацией пакетов. Первоначально разработка стандарта FR была ориентирована на цифровые сети интегрального обслуживания (ЦСИО; ISDN — Integrated Services Digital Networks), однако позже стало ясно, что FR применима в качестве коммуникационного стандарта и в других широкомасштабных СПД. К числу еѐ достоинств, прежде всего, не-

обходимо отнести: малое время задержки, простой формат кадров, содержащих минимум управляющей информации, независимость от протоколов верхних уровней ЭМВОС и др.

Разработкой и исследованием стандартов FR в настоящее время занима-

ются четыре международные организации: Форум Ретрансляции Кадров (FRF

— Frame Relay Forum, г. Фостер-Сити, штат Калифорния, США; этот междуна-

родный консорциум включает 17 компаний, среди которых 3Com, Northern

Telecom, Digital Equipment Corporation, Stratacom, Netrix Corporation, Timeplex,

Newbridge Networks, Zilog и др.), ANSI (American National Standards Institute -

Американский национальный институт по стандартизации), Международный союз электросвязи (ITU-T) и Группа Четырех — G4 (Digital Equipment Corporation, Northern Telecom, Stratacom и Cisco Systems). Оригинальный стандарт G4 (1990 г.), действительно положивший начало промышленному применению FR,

был основан на проекте стандартов ANSI и имел небольшие отличия от по-

следнего. Стандарты FRF и ITU-T, появившиеся несколько позже, идентичны стандартам ANSI.

Любой международный стандарт всегда имеет (и всегда будет иметь) ог-

ромный набор прикладных реализаций в различных СПД, что, как правило,

приводит к созданию многими фирмами-производителями программно-аппа-

392

ратных средств, которые зачастую несовместимы. Многими международными организациями предпринимались попытки преодоления такой ситуации. Ре-

зультатом одной такой попытки, предпринятой FRF, явился проект, согласовы-

вающий набор стандартов ANSI, обязательный для выполнения членами FRF и

реализации большинством фирм-производителей. В январе 1992 года это со-

глашение было доработано Техническим комитетом FRF и подтверждено соб-

ранием членов FRF.

Принятый FRF проект рассматривает только стандарты для постоянных виртуальных каналов (ПВК) и интерфейса «пользователь — сеть» (ИПС). В

этот проект не вошли стандарты для коммутируемых виртуальных каналов

(КВК) и интерфейса межсетевого взаимодействия. Однако работы по этим на-

правлениям продолжаются, и впоследствии их результаты найдут свое отраже-

ние в новых стандартах FR. Кроме того, проект FRF не рассматривает стандар-

ты физических интерфейсов, поэтому при создании FR-сетей допускаются раз-

личные физические интерфейсы, среди которых V.35, G.703, X.21 и др.

Логическая характеристика FR-протокола

FR является бит-ориентированным синхронным протоколом, исполь-

зующим «кадр» в качестве основного информационного элемента, и в этом смысле очень похож на протокол HDLC. Однако FR-протокол не обеспечивает все функции протокола HDLC, и поэтому многие из элементов кадра HDLC ис-

ключены из основного формата FR-кадра (в FR-кадре адресное поле и поле управления HDLC совмещены в одно адресное поле). Структура FR-кадра представлена на рис. 29.1 и включает:

Флаг. Все кадры начинаются и заканчиваются комбинацией флаг —

«01111110». Одна и та же комбинация флаг может использоваться как закры-

вающая один кадр и открывающая следующий. С целью предотвращения ими-

тации комбинации флаг при передаче кадра проверяется все его содержание между двумя флагами и вставляется «0»-й бит после всех последовательностей из пяти идущих подряд битов «1». На приѐмной стороне «0»-е биты отбрасы-

393

ваются. Данная процедура (bit-stuffing — «прозрачность») обязательна при формировании любого FR-кадра;

Адрес. Поле адреса в пределах FR-кадра состоит из 6 битов первого окте-

та и 4 битов второго октета (кодировка поля адреса представлена на рис. 29.2).

Эти 10 битов определяют абонентский адрес в FR-сети (идентификатор канала передачи данных: Data Link Connection Identifier — DLCI). Стандарты ANSI и

ITU-T допускают размер заголовка кадра до 4 октетов;

HDLC

Флаг

Адрес

Управление

Информация

Проверка

Флаг

 

 

 

 

 

 

FR

Флаг

 

Адрес

 

Информация

 

 

Проверка

Флаг

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Адрес

 

CR

 

EA

Адрес

FECN

BECN

DE

EA

8...3

 

2

 

1

8...5

4

3

2

1

 

 

 

 

 

―0‖

 

 

 

 

 

―1‖

 

 

 

 

 

 

 

 

 

 

 

 

Рис. 29.1. Структура и формат FR-кадра (отличие от кадра HDLC)

Октеты поля «адреса»

8

7

6

5

4

3

2

1

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Первый

29

28

27

26

25

24

 

 

Второй

23

22

21

20

 

 

 

 

 

 

 

 

 

 

 

 

 

Рис. 29.2. Кодировка 10-битового DLCI в поле ―адрес‖ FR-кадра

Бит «опрос/финал» (Command/Response — CR). Этот бит FR-протоколом не используется, но может применяться в пользовательских приложениях и

«прозрачно пропускается» аппаратно-программными средствами FR-сети;

Бит расширения адреса (Extended Address — EA). DLCI-идентификатор содержится в 10 битах, входящих в два октета поля адреса. Однако возможно расширение адресного поля (заголовка) на целое число дополнительных окте-

тов с целью указания адреса, состоящего из более чем 10 битов. Бит EA уста-

394

навливается в конце каждого октета заголовка, и, если он имеет значение «1»,

то это означает, что данный октет в заголовке последний. Стандарт FRF реко-

мендует использовать заголовок, состоящий из двух октетов. В этом случае бит

EA в первом октете будет установлен в «0», а во втором — в «1»;

Бит уведомления (сигнализации) приемника о явной перегрузке (Forward Explicit Congestion Notification — FECN). Этот бит устанавливается в «1» АКД сети для уведомления получателя сообщения о том, что произошла перегрузка в направлении передачи кадра, содержащего этот признак. Бит FECN устанав-

ливается АКД FR-сети (а не передающим ООД пользователя) и не обязателен

для терминалов абонентов (рис. 29.3).

Бит уведомления (сигнализации) источника о явной перегрузке (Backward Explicit Congestion Notification — BECN). Этот бит устанавливается в «1» АКД сети для уведомления источника сообщения о том, что произошла перегрузка в обратном направлении относительно направления передачи кадра, содержаще-

го этот признак. Бит BECN устанавливается АКД FR-сети (а не передающим

ООД пользователя) и не обязателен для терминалов абонентов (рис. 29.3);

Бит разрешения сброса (Discard Eligibility — DE). Этот бит устанавлива-

ется в «1» в случае явной перегрузки входного трафика и указывает на то, что

 

 

 

Направление

 

данный кадр может быть уничтожен

 

Аппаратура

 

 

 

 

 

перегрузки

 

в первую очередь по отношению к

 

доступа

 

 

 

 

 

 

 

 

 

 

другим кадрам, не имеющим данно-

 

 

 

 

 

 

 

 

BECN

FECN

 

го признака. Бит DE может быть ус-

 

 

 

 

 

 

 

 

 

 

 

 

 

 

FR-сеть

 

тановлен в «1» либо АКД FR-сети,

 

 

 

 

 

 

 

 

 

 

 

 

либо ООД пользователя (т.е. пользо-

 

 

 

 

 

 

 

 

 

 

 

Аппаратура

 

вателю предоставлено право выби-

 

 

 

 

доступа

 

 

 

 

 

 

 

 

 

 

 

 

 

рать, какими кадрами «он может по-

 

 

 

 

 

 

 

Рис. 29.3. Установка битов перегрузки

 

 

 

 

 

 

 

 

 

 

жертвовать»), при этом повторная

установка не допускается. Это предусмотрено для того, чтобы узлы коммута-

ции FR-сети могли уничтожать при перегрузках не только кадры с установлен-

ным битом DE (рис. 29.4);

395

Информационное поле. Информационное поле содержит данные пользо-

вателя и состоит из целого числа октетов. Максимальный размер для этого поля определен стандартом FRF и составляет 1600 октетов (минимальный размер —

1 октет). Содержание информационного поля пользователя передается неиз-

менным через FR-сети и прозрачно для FR-протокола;

Проверочная последовательность кадра (Frame Check Sequence — FCS).

Проверочная последовательность кадра используется для обнаружения воз-

можных ошибок при его передаче и состоит из двух октетов. Данная последо-

вательность FCS формируется аналогично циклическому коду HDLC;

Все указанные выше поля должны присутствовать в каждом FR-кадре,

который передается между двумя оконечными пользовательскими системами.

FR-протокол не предусматривает передачу сигнальных сообщений: нет командных (или супервизорных) кадров, как в HDLC. Для передачи служебной информации используется специально выделенный канал сигнализации (ОКС),

внутри которого передаются супервизорные кадры.

Кадры, которые могут быть

Гарантированная скорость

уничтожены

передачи информации

FR-кадр

Время

Временной интервал

Рис. 29.4. Гарантированная скорость передачи информации и кадры, которые могут быть уничтожены

Другое важное различие между FR и HDLC — отсутствие любой нумера-

ции последовательности передаваемых (принимаемых) кадров. Это является результатом того, что FR-протокол не имеет никаких способов для подтвер-

ждения правильно принятых кадров.

396

Процедурная характеристика FR-протокола

FR-протокол весьма прост по сравнению с HDLC и включает небольшой свод правил и процедур организации информационного обмена. Основной про-

цедурой протокола является то, что если кадр получен без искажений, то дол-

жен быть направлен далее по назначению соответствующим маршрутом. Если возникают проблемы, связанные с перегрузкой в пределах сети, то узлам FR-

сети разрешается отказаться от каких-либо кадров, чтобы снизить остроту про-

блемы.

Узлу связи FR-сети разрешено уничтожать искаженные кадры, не уве-

домляя при этом ООД пользователя. Искаженным считается кадр, у которого:

нет корректного ограничения флагами;

в составе менее чем пять октетов между флагами;

в составе нет целого числа октетов после удаления битов прозрачности;

ошибка FCS ;

поле адреса искажено;

содержит не существующий DLCI;

превышен допустимый максимальный размер.

Однако в некоторых вариантах стандартов FR возможна принудительная

обработка кадров, которые превышают допустимый максимальный размер.

Обязательные процедуры FR:

«межкадровое заполнение» флагами в моменты отсутствия данных для передачи;

резервирование одного DLCI для интерфейса локального управления и сигнализации (Local Management Interface — LMI);

содержание поля данных пользователя в любом кадре не должно подвер-

гаться какой-либо обработке со стороны FR-сети, за исключением данных

LMI.

Управление доступом и защита от перегрузок

397

Управление доступом к FR-сети возлагается на интерфейс локального управления. Именно LMI реализует ИПС. В качестве программно-аппаратных средств (рис. 29.5), обеспечивающих доступ в FR-сеть, используются FR-

адаптеры (сборщик/разборщик FR-кадров: FR assembler/disassembler — FRAD).

В FR-сетях для высокой эффективности использования пропускной спо-

собности физических линий и каналов связи и исключения перегрузки узлов связи и всей FR-сети используется метод статистического мультиплексирова-

ния кадров, который заключается в постоянном «наблюдении» (со стороны FR-

сети) за потоком заявок от пользователей на передачу сообщений, текущим со-

стоянием загрузки сети (линий, каналов и узлов связи), «перераспределении» свободного (и высвобождающегося) ресурса пропускной способности между реальными потребностями в ней абонентов и предоставлении последним кана-

лов информационного обмена в соответствии с требуемыми параметрами. Дан-

ный метод обеспечивает синхронный ввод сообщений пользователей в высоко-

скоростной канал связи на основе предварительных соглашений между ООД пользователя и АКД FR-сети, включающих:

Гарантированная доставка сообщений

Много-

 

 

Много-

протокольный

FRAD

FRAD

протокольный

доступ

 

 

доступ

 

FR

FR

 

Рис. 29.5. Организация доступа к FR-сети с помощью FRAD

максимальный размер поля информации в FR-кадре (в октетах);

пропускную способность интерфейса, посредством которого ООД або-

нента подключается к FR-сети (port speed);

гарантированную скорость передачи данных (Committed Information Rate

— CIR), обеспечиваемая FR-сетью абоненту постоянно и с требуемым качеством;

398

гарантированный объем переданной информации (Committed Burst Size Bс), обеспечивается FR-сетью с требуемым качеством. С использованием первых трех согласованных параметров может быть вычислено гаранти-

рованное время передачи информации с требуемым качеством (Committed Rate Measurement Interval Tс);

дополнительный объем переданной информации (Excess Burst Size Bе),

может обеспечиваться FR-сетью, но с худшим качеством.

Использование предварительных соглашений происходит следующим

образом:

1.во-первых, абонент выбирает (и оплачивает) пропускную способность порта и гарантированную скорость передачи данных для ПВК;

2.во-вторых, узел доступа к FR-сети (FRAD) измеряет «реальный потреб-

ляемый абонентом» ресурс пропускной способности канала связи;

3.в-третьих, если этот ресурс, пересчитанный в реальную скорость переда-

чи информации, не превышает CIR, то кадры передаются без изменений;

если превышает, но не более чем пропускная способность интерфейса, то в кадрах FRAD бит DE устанавливается в «1», который разрешает их уда-

лять при возникновении перегрузки (это право имеет и абонент, который сам решает, какие кадры для него наименее важны); если превышает про-

пускную способность интерфейса, то кадры уничтожаются независимо от каких-либо условий.

(Примечание. Предварительные соглашения могут быть использованы абонентом следующим оригинальным способом. Некоторые администраторы сетей (поставщики услуг) предлагают абонентам значительные скидки при передаче кадров с битом DE, установленным в «1». Поэтому при наличии в сети значительного запаса пропускной способности абонент может сэкономить свои средства за счет установки CIR = «0». В этом случае во всех передаваемых кадрах бит DE устанавливается в «1».)

399

Биты уведомления о явной перегрузке используются для передачи ин-

формации пользователям о состоянии сети и возникшей перегрузке. Бит FECN

устанавливается в тех кадрах, которые передаются в направлении перегрузки.

Когда ООД абонента получает FECN, это указывает на то, что кадр получен из области перегрузки в пределах сети. Бит BECN используется в обратном на-

правлении от перегрузки (рис. 29.3).

Адресация в FR-сетях

Адреса (DLCI-идентификаторы) в FR-кадре предназначены только для идентификации логических каналов между пользователями и сетью, другими словами, они имеют только локальное значение и не касаются какой-либо об-

щесетевой адресации. Любые информационные кадры, передаваемые через конкретный логический канал, имеют одинаковый DLCI-идентификатор неза-

висимо от направления: от абонента или к абоненту.

В связи с тем, что DLCI-идентификатор носит исключительно локальный характер, FR-сеть обязана точно интерпретировать межабонентское соединение и при этом может использовать различные сетевые адреса внутри FR-сети. Для различных интерфейсов значение DLCI-идентификатора может пользоваться многократно.

Стандарт FR (ANSI, ITU-T) распределяет DLCI-идентификаторы (двухок-

тетные) между пользователями и сетью следующим образом:

0 — для канала локального управления (LMI);

1...15 — зарезервировано для дальнейшего использования;

16...991 — используются абонентами для нумерации ПВК и КВК;

992...1007 — используются сетевой транспортной службой для внутрисе-

тевых соединений;

1008...1022 — зарезервировано для дальнейшего использования;

1023 — для управления канальным уровнем (используется в кадрах, ко-

торые «переносят» сквозные сообщения управления интерфейсом, связы-

вающим протоколы вышележащих уровней).

Рис. 29.6. Применение интерфейса локального управления (LMI)
LMI
LMI
Абонент
«В»
Интерфейс FR
Абонент
«А»
Интерфейс FR
Сетевая служба

400

Таким образом, для оконечного устройства пользователя в любом интер-

фейсе FR отводится только 976 DLCI-идентификаторов.

Общая характеристика LMI

FR-протокол обеспечивает в первую очередь высокоскоростную транс-

портировку данных и в соответствии с этим предоставляет абоненту требуемый ресурс пропускной способности сети (каналов и линий связи). Так как FR-

протокол разработан только для ПВК, то нет необходимости в процедурах ус-

тановления и разъединения соединений. Вместе с тем он не предусматривает процедур управления потоком и исправления ошибок. Таким образом, FR-

протокол представляет собой базовый способ передачи данных.

Однако FR-протокол не предусматривает и никакого способа локального управления и контроля состояния связи. По этой причине был разработан стан-

дарт интерфейса локального уп-

равления (LMI), который предна-

значен в первую очередь для пре-

доставления пользователю инфор-

мации о состоянии и конфигура-

ции (настройках) ПВК. LMI при-

меняется только в оконечном про-

граммно-аппаратном оборудовании пользователя (рис. 29.6) и выполняет сле-

дующие функции:

уведомление абонента о проключении, наличии и отключении ПВК;

уведомление абонента о готовности заранее сконфигурированного ПВК;

последовательный опрос FR-сети в целях поддержания соединения в те-

чение длительного времени.

Интерфейс LMI является необязательной частью стандарта FR. Однако при разработке новых стандартов FR интерфейс локального управления являет-

ся неотъемлемой их частью, и поэтому международные организации и фирмы-