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

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

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

Интерфейс - соглашение, на основе которого производится взаимодействие между уровнями управления (семиуровневая эталонная модель взаимодействия открытых систем - ЭМВОС) одной системы. Он определяет структуру данных и способ (алгоритм) обмена ими между соседними уровнями.

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

Ретрансляция кадров (frame relay, FR) - это метод доставки сообщений в сетях передачи данных (СПД) с коммутацией пакетов (в отличие от СПД с коммутацией каналов и сообщений). Первоначально разработка стандарта FR ориентировалась на цифровые сети интегрированного обслуживания (ISDN - Integrated Services Digital Networks), однако позже стало ясно, что FR применим и в других СПД (здесь под данными понимается любое сообщение, представленное в цифровой форме). К числу достоинств метода прежде всего необходимо отнести малое время задержки, простой формат кадров, содержащих минимум управляющей информации, и независимость от протоколов верхних уровней ЭМВОС.

В настоящее время разработкой и исследованием стандартов FR занимаются три организации:

Любой международный стандарт имеет (и всегда будет иметь) множество прикладных реализаций, что зачастую приводит к несовместимости аппаратно-программных средств разных производителей. Международные организации неоднократно пытались решить данную проблему. Результатом одной из таких попыток (предпринятой FRF) стал проект стандарта, включающего в себя спецификации ANSI, которые обязательны для выполнения членами FRF. В январе 1992 г. этот проект был доработан Техническим комитетом FRF и утвержден собранием членов FRF.

Принятый FRF проект рассматривает только спецификации для постоянных виртуальных каналов (PVC) и интерфейса "пользователь-сеть" (UNI). В него не вошли стандарты для коммутируемых виртуальных каналов (SVC) и интерфейса межсетевого взаимодействия. Однако работа по этим направлениям продолжается и ее результаты найдут свое отражение в новых стандартах FR. Проект FRF не рассматривает и стандарты физических интерфейсов, поэтому при создании сетей FR допускаются различные физические интерфейсы, среди которых V.35, G.703, X.21 и др.

FR является бит-ориентированным синхронным протоколом и использует "кадр" в качестве основного информационного элемента - в этом смысле он очень похож на протокол HDLC (High Level Data Link Control). Однако FR обеспечивает не все функции протокола HDLC; многие из элементов кадра HDLC исключены из основного формата кадра FR (в последнем адресное поле и поле управления HDLC совмещены в единое адресное поле). Структура кадра FR (рис.1) включает в себя следующие элементы.

Рисунок 1.
Структура и формат кадра frame relay.

Флаг. Все кадры начинаются и заканчиваются комбинацией "флаг": "01111110". С целью предотвращения имитации комбинации "флаг" при передаче кадра проверяется все его содержание между двумя флагами и вставляется бит "0" после каждой последовательности, состоящей из пяти идущих подряд бит "1". Данная процедура (bit stuffing) обязательна при формировании любого кадра FR. На приемном конце биты "0" отбрасываются.

Заголовок:

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

Информационное поле содержит данные пользователя и состоит из целого числа октетов. Его максимальный размер определен стандартом FRF и составляет 1600 октетов (минимальный размер - 1 октет), но возможны и другие максимальные размеры (вплоть до 4096 октетов) Содержание информационного поля пользователя передается неизменным.

Проверочная последовательность кадра (Frame Check Sequence - FCS) используется для обнаружения возможных ошибок при его передаче и состоит из 2 октетов. Данная последовательность формируется аналогично циклическому коду HDLC.

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

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

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

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

Для FR характерно:

Управление доступом к сети FR возлагается на интерфейс локального управления (Local Management Interface - LMI). Именно LMI (он будет рассмотрен ниже) реализует интерфейс UNI. Доступ в сеть FR обеспечивают интерфейсы FR ("порты FR") и FR-адаптеры - сборщики/разборщики кадров FR (FR assembler/disassembler, FRAD).

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

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

Предварительные соглашения реализуются следующим образом.

1. Абонент выбирает (и оплачивает) пропускную способность порта и гарантированную скорость передачи данных для PVC.

2. Узел доступа к сети FR измеряет "реальную потребность абонента" в ресурсе пропускной способности канала связи.

3. Если этот ресурс (выраженный реальной скоростью передачи информации) не превышает CIR, то кадры передаются без изменений. Если требуемая скорость превышает CIR, но соответствует пропускной способности порта, то бит DE устанавливается в "1", что дает возможность удалять эти кадры при возникновении перегрузок (абонент также имеет право решать, какие кадры для него менее важны). Наконец, если превышена пропускная способность порта, кадры уничтожаются вне зависимости от каких-либо условий.

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

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

В связи с тем, что DLCI носит локальный характер, АКД обязана обладать способностью определения принадлежности проходящего кадра конкретному PVC. Внутри сети FR могут использоваться различные сетевые адреса. Для разных интерфейсов одно и то же значение DLCI может применяться многократно. На рис. 3 приведен пример повторного использования DLCI (78) ООД абонентов А и В.

Рисунок 3.
Применение DLCI.

Стандарты FR (ANSI, ITU-T) распределяют двухоктетные адреса DLCI между пользователями и сетью следующим образом:

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

Протокол FR обеспечивает высокоскоростную транспортировку данных и, соответственно, предоставляет абоненту требуемый ресурс пропускной способности сети (линий и каналов связи). Поскольку этот протокол стандартизирован только для PVC, то пока отсутствуют стандарты для процедур установления и разъединения соединений. Кроме того, не рассматриваются процедуры управления потоком и исправления ошибок. Таким образом, протокол FR определяет лишь базовый механизм передачи данных и не предполагает никакого механизма локального управления и контроля за состоянием связи.

Интерфейс локального управления (LMI) был разработан, в первую очередь, с целью предоставления пользователю информации о состоянии и конфигурации PVC. LMI применяется только в оконечном аппаратно-программном обеспечении пользователя и выполняет следующие функции:

При разработке новых стандартов FR интерфейс LMI входит в них неотъемлемой частью, поэтому международные организации, занимающиеся стандартизацией FR, и фирмы-производители проводят активную работу по скорейшему принятию единого стандарта LMI. Такой стандарт окажется особенно актуальным при переходе сетей FR на SVC.

Интерфейс LMI соответствует логической и процедурной характеристикам базового стандарта FR. Различие состоит в расширении заголовка кадра FR с целью размещения дополнительных полей стандарта LMI, поэтому в дальнейшем расширенный кадр FR мы будем называть кадром LMI. Его базовый формат представлен на рис. 4 и включает в себя (кроме флагов и проверочной последовательности) следующие элементы.

Рисунок 4.
Базовый формат кадра LMI.

Заголовок. Им служит стандартный заголовок FR, в котором адрес DLCI всегда имеет значение "0", показывающее, что это - кадр LMI.

Индикатор ненумерованного кадра. Данное поле всегда кодируют как "00000011", чтобы обеспечить процедурную и логическую совместимость с ISDN.

Определитель протокола. Этот октет всегда устанавливается в "00001000", чем обеспечивается процедурная и логическая совместимость с ISDN.

Вызываемый номер. Октет зарезервирован для организации SVC. При создании PVC он кодируется "00000000".

Тип сообщения. Данный октет предназначен для идентификации типа управляющего сообщения, передаваемого через интерфейс LMI. В настоящее время стандартизированы три типа управляющих сообщений - "Запрос установления соединения", "Запрос разъединения" и "Смешанное сообщение". Первые два типа относятся к SVC, а последний - к PVC. В этом октете восьмой бит всегда устанавливается в "0", а биты 7...5 - "111", что указывает на смешанное сообщение. Как кодируются остальные биты, показано на рис. 5.

Рисунок 5.
Кодирование поля "Тип сообщения" кадра LMI для смешанных сообщений.

Информационные элементы. На них отводятся один или несколько октетов в пределах кадра LMI, т. е. информационные элементы имеют переменную длину.

LMI предусматривает три стратегии локального управления:

Синхронное симплексное управление. Для осуществления ССУ используются два типа сообщений: "Запрос состояния" (STATUS ENQUIRY) и "Состояние" (STATUS). С помощью этих сообщений LMI проверяет целостность соединения, уведомляет о включении или выключении, а также о готовности PVC.

Процедура ССУ (рис. 6) заключается в следующем. ООД периодически запрашивает через интерфейс LMI (процедура "биения") состояние сети. Через определенный временной интервал ООД посылает в сеть сообщение "Запрос состояния" (международное обозначение интервала опроса - T391) с целью подтверждения целостности соединения, на что сеть отвечает сообщением "Состояние", содержащим требуемый элемент информации о целостности соединения.

Рисунок 6.
Процедура перидического опроса (ССУ).

Интерфейс LMI ведет подсчет числа опросов. По достижении какого-то числа переданных сообщений "Запрос состояния" (т. е. через некоторый временной интервал, который имеет международное обозначение N391) ООД запрашивает у сети информацию о так называемом полном состоянии, также используя сообщение "Запрос состояния". АКД отвечает на него сообщением "Состояние", в котором присутствуют информационные элементы для каждого PVC (если ООД имеет несколько портов). Отсутствие в этом ответе информационного элемента для какого-либо PVC воспринимается терминалом пользователя как отсутствие PVC в интерфейсе "пользователь-сеть". Формат сообщения "Запрос состояния" представлен на рис. 7 (версия ITU-T); в нем всегда содержатся два элемента:

	8	7	6	5	4	3	2	1	Назначение
1	0	1	1	1	1	1	1	0	Флаг
2	0	0	0	0	0	0	0	0	Заголовок: DCLCI=0, CR=0
3	0	0	0	0	0	0	0	1	DE=0, FECN=0, DECN=0
4	0	0	0	0	0	0	1	1	Индикатор ненумерованного кадра
5	0	0	0	0	1	0	0	0	Определитель протокола
6	0	0	0	0	0	0	0	0	Вызываемый номер (только для SVC)
7	0	1	1	1	0	1	0	1	Cообщение "Запрос состояния"
8	0	1	0	1	0	0	0	1	Информационный элемент о типе сообщения
9	1
10	Тип сообщения
11	0	1	0	1	0	0	1	1	Информационный элемент о целостности связи
12	2
13	Номер передаваемого кадра
14	Номер принятого кадра
15									Проверочная последовательность
16
17	0	1	1	1	1	1	1	0	Флаг

Рисунок 7.
Формат кадра LMI "Запрос состояния".

Первый из информационных элементов указывает, какой тип сообщения запрашивается у сети (всего их может быть три). "Запрос о полном состоянии" посылается для получения информации о всех PVC, сконфигурированных с помощью интерфейса. "Запрос о целостности соединения" предназначен для промежуточного определения порядка следования кадров, "проходящих" через интерфейс, с целью контроля за возможными потерями кадров. "Запрос о состоянии отдельного асинхронного PVC" служит для получения информации об отдельном PVC.

Проверка целостности соединения призвана гарантировать стабильность и надежность физической и логической связи между ООД и АКД. Процедура состоит в генерации последовательности специальных пронумерованных кадров и проверке корректности ее передачи. ООД с определенной периодичностью посылает сообщение "Запрос состояния" (рис. 8), в котором указываются: порядковый номер передаваемого кадра (он увеличивается на единицу при передаче каждого последующего кадра); порядковый номер последнего кадра, полученного от АКД (в первом сообщении "Запрос состояния" имеет значение "0").

Рисунок 8.
Формат информационного элемента о целостности связи.

В ответ на полученное сообщение "Запрос состояния" АКД передает ООД сообщение "Состояние", в котором указываются: порядковый номер передаваемого кадра (увеличивается на единицу при каждой передаче); порядковый номер последнего кадра, полученного от пользователя.

Порядковые номера кадров могут принимать значения от 1 до 255 (в двоичной форме). "0" используется только для обозначения начального порядкового номера принятого кадра в начальном сообщении "Запрос состояния".

Признак нового PVC еще не дает ООД разрешения начать передачу сообщения в данном PVC. "Сигналом" начала передачи является бит "активный PVC", определенный сетью как "1". Он устанавливается АКД только тогда, когда последняя "непосредственно убедилась" в том, что найден путь для доставки сообщения к месту назначения (другими словами, когда PVC полностью проключен). Время включения PVC зависит от конкретной сети и реализации протокола.

Оповещение пользователя о состоянии PVC осуществляется не в масштабе реального времени, т.е. ООД не мгновенно "узнает" об изменениях в сети. Поэтому некорректный выбор временного интервала, через который посылаются запросы на информацию о полном состоянии PVC, может привести к возникновению проблем. Во-первых, уведомление о том, что PVC стал доступным, может получить только один из участников информационного обмена. Тогда ООД начинает передавать другому участнику кадры данных прежде, чем на место назначения поступит сообщение "Состояние", в котором бит "активный PVC" установлен АКД в "1". Во-вторых, не зная о том, что PVC стал недоступным, ООД будет по-прежнему передавать через него данные в сеть.

Синхронное дуплексное управление. При использовании ССУ ответственность за генерацию сообщения "Запрос состояния" лежит полностью на ООД, а за генерацию сообщения "Состояние" - на АКД. Такая процедура приемлема для многих приложений, однако предпочтительнее, чтобы каждая из сторон интерфейса LMI могла обеспечивать требуемые для противоположной стороны параметры и коэффициент готовности.

СДУ - необязательная часть стандарта FR, которая может использоваться только при заключении соглашения между сторонами (абонент-сеть). СДУ отличается от ССУ только одним: сообщения "Запрос состояния" и "Состояние" имеют право передавать обе стороны интерфейса (рис. 9). При СДУ обе стороны интерфейса FR передают сообщение "Запрос состояния" через определенный временной интервал (T391), "требуют" ответа - сообщения "Состояние" (T392), а также запрашивают информацию о полном состоянии (N391). При использовании этих процедур любая из сторон может запрашивать различные параметры и вести учет номеров принимаемых и передаваемых кадров для каждого направления (рис. 10).

Рисунок 9.
Процедура синхронного дуплексного управления.

Рисунок 10.
Распределение нумерации кадра при СДУ.

Асинхронное управление. Главным недостатком ССУ и СДУ является потенциальная задержка информирования ООД (или АКД) об изменениях сетевых PVC. Например, при задержке, равной 60 с, и CIR 64 кбит/с пользователь направит в сеть приблизительно 3,5 Mбит данных, прежде чем получит информацию о состоянии PVC.

Стратегия АУ позволяет при изменении состояния PVC сети FR сразу передавать стандартные сообщения "Запрос состояния" и "Состояние". Эти сообщения содержат информацию только об отдельных PVC, которые изменили свое состояние. Проверка целостности соединения также основана на генерации последовательности специальных пронумерованных кадров и проверке корректности ее передачи. АУ может осуществляться совместно с ССУ и СДУ, однако если в сети FR применяются одновременно SVC и PVC, то рекомендуется использовать только АУ.

Процедуры управления LMI при возникновении ошибок. LMI предназначен для передачи минимального количества управляющей информации, позволяющей гарантировать нормальное функционирование интерфейса FR. Но существуют и специальные процедуры управления, которые реализуются при возникновении следующих возможных ошибок в интерфейсе FR, обнаруживаемых АКД:

В этих случаях АКД устанавливает в сообщении "Состояние" бит "активный PVC" в "0", указывая на временную неготовность канала. Когда ошибка устранена, АКД устанавливает бит "активный PVC" в "1". Однако данные действия осуществляются не сразу при возникновении ошибок, а только при превышении установленного "порога" (максимально допустимое число ошибок имеет международное обозначение N392), который определяется используемым протоколом FR. АКД подсчитывает ошибки, возникающие в пределах установленного периода (его международное обозначение - N393). Если в течение интервала N393 порог N392 будет превышен, сеть переведет PVC в неактивное состояние. Выход из него осуществляется при получении сетью безошибочного сообщения "Запрос состояния".

ООД может обнаруживать следующие ошибки:

Действия ООД пользователя аналогичны предпринимаемым АКД; их основой является тот же самый пороговый принцип: ООД прекращает передачу, когда в течение интервала N393 превышен порог N392. Выход из неактивного состояния PVC осуществляется при передаче от ООД сообщения "Запрос состояния". Однако стандарт FR не устанавливает процедуры, позволяющие однозначно определить, что ошибка устранена и ООД может передать сообщения "Запрос состояния". Об устранении ошибки свидетельствует лишь то, что N392 событий прошли без ошибки. Необходимо также отметить, что невозможно обнаружить ошибки в пределах отдельного PVC интерфейса FR, т. е. ошибки затронут все сконфигурированные PVC.

Окончанием ситуаций, которые связаны с возникновением ошибок и могут произойти в LMI, являются:

Возникновение ошибок может быть связано с тем, что сообщения о состоянии LMI были потеряны на линии связи или инициализация PVC осуществлялась некорректно. В этих случаях ООД должно отмечать в кадрах LMI, что PVC "активен" или "недоступен" соответственно.

Параметры для синхронизации процедур управления LMI. Для нормального осуществления процедур управления LMI используется ряд специальных счетчиков событий и времени, назначение которых - синхронизация последовательностей кадров управляющей информации, проходящих через интерфейс (рис. 11 и 12).

Рисунок 11.
Счетчики событий, используемые для синхронизации процессов управления LMI.

Рисунок 12.
Счетчики времени, используемые для синхронизации процессов управления LMI.

При ССУ счетчик кадров (N391) ведет подсчет переданных ООД кадров LMI ("Запросов состояния") с информацией о целостности соединения. После того, как переданы N391 сообщений "Запрос состояния", ООД с помощью кадра LMI ("Запрос состояния") запрашивает информацию о полном состоянии PVC. При СДУ АКД также может использовать счетчик кадров (N391) для запроса информации о полном состоянии.

Максимально допустимое число (порог) ошибок (N392) используется при подсчете числа ошибок в интерфейсе и должно быть меньше (или равняться) интервала N393. В пределах этого интервала анализу подвергаются следующие события:

Если за интервал N393 число ошибок превысило порог N392, это интерпретируется как состояние ошибки. В практических реализациях интервал N393 устанавливается ненамного меньшим, чем N391, поскольку иначе при изменении состояния PVC не произойдет своевременное уведомление ООД.

При осуществлении ССУ счетчик времени (T391) используется для определения начала передачи сообщения "Запрос состояния" (запрос о целостности связи) со стороны ООД, а при СДУ - со стороны АКД. Величины T391, устанавливаемые ООД и АКД, могут быть различными.

При ССУ величиной тайм-аута (T392) пользуется лишь АКД. Если сообщение "Запрос состояния", которое передается ООД, не поступает в сеть до истечения срока T392, то АКД повторно передает ООД сообщение "Состояние" (с номером последнего корректно принятого кадра LMI); при этом число ошибочных событий (N392) увеличивается на единицу. T392 всегда должен быть больше, чем T391. При СДУ таймер T392 применяется также ООД. Величины T392, устанавливаемые ООД и АКД, могут быть различными.

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

На первый взгляд, ретрансляция кадров является достаточно простым механизмом информационного обмена, но при более глубоком анализе оказывается чрезвычайно сложной. FR присущи практически все проблемы, связанные с обеспечением надежности и качества передачи сигналов (физический уровень ЭМВОС). При ее осуществлении необходимо обеспечивать синхронизацию и защиту от ошибок, которые, несмотря на высокое качество линий и каналов связи (это одно из основных условий применения FR), могут возникать в случае сбоев в работе аппаратно-программных средств связи.

В данной статье были охвачены только те вопросы, которые нашли свое отражение в рекомендациях ITU-T. Однако за ее рамками осталось множество проблем стандартизации FR, связанных с различными воззрениями на этот метод международных организаций по стандартизации и производителей. К требующим первоочередного разрешения проблемам можно отнести следующие:

(В дальнейшем автор намерен посвятить этим проблемам несколько публикаций.)

Потенциальным потребителям услуг сетей FR и организациям, желающим создать свои ведомственные (корпоративные) сети FR с помощью так называемых сетевых интеграторов можно дать несколько рекомендаций.

1. Создание и обслуживание сети FR - "удовольствие дорогое", поэтому сначала необходимо соизмерить свои возможности с реальными потребностями.

2. Нужно провести тщательную проверку (в том числе на предмет профессионализма сотрудников) потенциального поставщика услуг, чтобы выяснить: а) не является ли эта фирма "дутой" (она может продать вам ООД или создать сеть FR, а потом "лопнуть"; тогда вы останетесь с "грудой железа", которое невозможно либо очень дорого адаптировать к другим сетям); б) обеспечивается ли информационная безопасность приобретенного ООД или созданной сети, т. е. нет ли возможности "постороннего воздействия" (прямого и/или косвенного) на конфиденциальную информацию, циркулирующую в вашей сети.

3. Заключая договор c оператором на подключение к сети FR (покупая у него ООД) или с сетевым интегратором на создание корпоративной сети FR, необходимо предусмотреть в договоре пункт, в котором будут оговариваться условия эксплуатации и обслуживания вашего ООД или АКД. Они должны предусматривать: во-первых, бесплатную (либо за минимальную цену) замену или модернизацию аппаратно-программных средств при переходе на новые (усовершенствованные) стандарты FR; во-вторых, предоставление пользователям данной сети FR доступа к пользователям других сетей FR, применяющим ООД других стандартов FR, или обеспечение интеграции ведомственной сети (с помощью соответствующих "шлюзов") с другими сетями FR, также функционирующими на основе других стандартов FR.