Сети и телекоммуникации
.pdfРАЗДЕЛ 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 — для управления канальным уровнем (используется в кадрах, ко-
торые «переносят» сквозные сообщения управления интерфейсом, связы-
вающим протоколы вышележащих уровней).
400
Таким образом, для оконечного устройства пользователя в любом интер-
фейсе FR отводится только 976 DLCI-идентификаторов.
Общая характеристика LMI
FR-протокол обеспечивает в первую очередь высокоскоростную транс-
портировку данных и в соответствии с этим предоставляет абоненту требуемый ресурс пропускной способности сети (каналов и линий связи). Так как FR-
протокол разработан только для ПВК, то нет необходимости в процедурах ус-
тановления и разъединения соединений. Вместе с тем он не предусматривает процедур управления потоком и исправления ошибок. Таким образом, FR-
протокол представляет собой базовый способ передачи данных.
Однако FR-протокол не предусматривает и никакого способа локального управления и контроля состояния связи. По этой причине был разработан стан-
дарт интерфейса локального уп-
равления (LMI), который предна-
значен в первую очередь для пре-
доставления пользователю инфор-
мации о состоянии и конфигура-
ции (настройках) ПВК. LMI при-
меняется только в оконечном про-
граммно-аппаратном оборудовании пользователя (рис. 29.6) и выполняет сле-
дующие функции:
уведомление абонента о проключении, наличии и отключении ПВК;
уведомление абонента о готовности заранее сконфигурированного ПВК;
последовательный опрос FR-сети в целях поддержания соединения в те-
чение длительного времени.
Интерфейс LMI является необязательной частью стандарта FR. Однако при разработке новых стандартов FR интерфейс локального управления являет-
ся неотъемлемой их частью, и поэтому международные организации и фирмы-
