Бабич А.В. Оргранизация информационных сетей: Учебное пособие

Подождите немного. Документ загружается.

101

Relay представляет собой логическое соединение, которое создается

между двумя устройствами DTE в сети Frame Relay и используется

для передачи данных. В сети Frame Relay используется два типа

виртуальных каналов — коммутируемые (SVC) и постоянные

(PVC).

Коммутируемые виртуальные каналы представляют собой вре-

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

ного трафика между двумя устройствами DTE в сетях Frame Relay.

Процесс передачи данных с использованием SVC состоит из четырех

последовательных фаз:

Установление вызова (Call Setup) x . На этом этапе создается

виртуальное соединение между двумя DTE.

Передача данных (Data Transfer) x . Фаза непосредственной

передачи данных.

Ожидание (Idle) x . Виртуальное соединение еще существует, од-

нако передача данных через него уже не производится. В том

случае, если период ожидания превысит установленное значение

тайм-аута, соединение может быть завершено автоматически.

Завершение вызова (Call Termination) x . На этом этапе вы-

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

единения.

Несмотря на то, что использование SVC придает определенную

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

распространения в сетях Frame Relay.

PVC представляют собой постоянное соединение, которое обе-

спечивает информационный обмен между двумя DTE-устройствами

в сети Frame Relay. Процесс передачи данных по каналу PVC имеет

всего две фазы:

Передача данных x . Фаза непосредственной передачи данных.

Ожидание x . Виртуальное соединение существует, однако пере-

дача данных через него не производится. В отличие от SVC, по-

стоянный канал PVC не может быть автоматически разорван в

том случае, если он не используется для передачи данных.

§2. Идентификаторы виртуальных каналов

Для обозначения виртуальных каналов в сети Frame Relay ис-

пользуется аппарат DLCI (Data-Link Connection Identifier,

идентификатор соединения уровня канала). DLCI определяет

102

номер виртуального порта для процесса пользователя. Например, на

рисунке 20 устройство FRAD LAN1 использует виртуальный канал

DLCI 100 для организации обмена данными с сетью LAN 2 и вирту-

альный канал DLCI 101 для организации обмена данными с сетью

LAN 3. Для организации обмена данными с сетью LAN 1 устройство

FRAD LAN 2 использует виртуальный канал DLCI 200. Обычно

идентификатор DLCI имеет только локальное значение и не является

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

дого пользователя определяются провайдером сервиса Frame Relay.

Рис. 20. Пример использования DLCI

§3. Структура кадра Frame Relay

Кадр протокола Frame Relay содержит минимально необходимое

количество служебных полей (табл. 3).

Таблица 3

Структура кадра Frame Relay

Флаг Заголовок кадра Полезная нагрузка FCS Флаг

1 байт 2 байта 2 байта 1 байт

103

Поле FLAG. Данное поле выполняет функцию обрамления ка-

дра. Принцип формирования поля FLAG в кадре Frame Relay соот-

ветствует принципам формирования поля FLAG в кадре LAPB.

Поле HEADER. В поле заголовка кадра размещается информа-

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

ниями и процессами передачи данных в сети Frame Relay.

Структура первого байта поля заголовка (табл. 4):

Таблица 4

Структура первого байта заголовка

поле DLCI C/R EA

6 бит 1 бит 1 бит

Структура второго байта поля заголовка (табл. 5):

Таблица 5

Структура второго байта заголовка

поле DLCI FECN BECN DE EA

4 бит 1 бит 1 бит 1 бит 1 бит

Поле DLCI. Поле DLCI занимает 10 бит в заголовке кадра. В это

поле коммутатор FR помещает идентификатор, используя который

получатель кадра может правильно интерпретировать содержимое

поля полезной нагрузки.

Биты FECN и BECN. Биты FECN и BECN обеспечивают функ-

ционирование процедуры явного указания о возникновении пере-

грузки Explicit Congestion Notification. Эта процедура является од-

ним из двух механизмов, которые обеспечивают возможность

управления процессом передачи данных в сети Frame Relay. Ситуа-

ция перегрузки в сети Frame Relay может возникнуть в том случае,

когда один из компонентов (коммутатор FR) начинает получать

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

вращения дальнейшего усугубления такого положения коммутатор

формирует в кадрах, которые он передает в направлении основного

источника входящих кадров, признак BECN (Backward Explicit

Congestion Notification). Предполагается, что в ответ на получение

этого признака источник должен уменьшить поток формируемых ка-

дров в данном направлении. В кадрах, которые передаются в направ-

104

лении получателя пакетов, коммутатор формирует признак FECN

(Forward Explicit Congestion Notification). Этот признак предупре-

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

рийной ситуации в текущем процессе передачи данных.

Бит DE. Бит DE (Discard Eligibility) используется для обеспече-

ния функционирования второго механизма управления потоком дан-

ных в сетях Frame Relay. Описание этого механизма будет приведе-

но ниже. Битом DE помечаются кадры, которые при возникновении

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

в первую очередь.

Поле полезной нагрузки. Поле полезной нагрузки в кадре

Frame Relay имеет переменную длину и предназначено для пере-

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

Поле FCS. Содержит 16-разрядную контрольную сумму всех по-

лей кадра Frame Relay за исключением поля «флаг».

§4. Параметры качества обслуживания Frame Relay

В качестве таких параметров в сети Frame Relay используются

(рис. 21):

Согласованное значение информационной скорости (Committed 1.

Information Rate — CIR).

Гарантируемый объем передаваемых данных (committed burst 2.

size Bc).

Не гарантируемый объем передаваемых данных (excess burst size 3.

Be).

Согласованная информационная скорость. Значение CIR

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

мационная скорость — это максимальная скорость, с которой поль-

зователь может обеспечивать информационный обмен по отдельно-

му каналу PVC. Сумма значений CIR всех PVC пользователя не

должна превышать 75-80% пропускной способности физического

канала провайдера.

Гарантированный объем и интервал неравномерности тра-

фика. Данный параметр услуги предназначен для определения вре-

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

теля Tc в соответствии с формулой:

Тс = Bc/CIR.

105

Таким образом, значение Bc определяет максимальный объем

данных пользователя, который может быть передан без потерь за

период Тс.

Не гарантированный объем передаваемых данных. Значе-

ние Be определяет величину предельного увеличения трафика поль-

зователя для конкретного виртуального канала PVC. Кадрам пользо-

вателя, которые образовали добавку Be к согласованному значению

Bc, присваивается признак DE, что означает их удаление при воз-

никновении перегрузок в сети.

Рис. 21. Параметры качества обслуживания Frame Relay

§5. Сигнализация и управление вызовами

в сетях Frame Relay

Использование технологии Frame Relay в качестве универсаль-

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

нительных спецификаций, которые обеспечивали более гибкое управ-

ление ресурсами PVC и SVC в сети Frame Relay. Одной из первых

таких спецификаций была спецификация LMI.

Спецификация LMI (Local Management Interface) была разрабо-

тана в 1990 г. инициативной группой, в которую вошли компании

106

Cisco Systems, StrataCom, Northen Telecom и DEC. Возникновение

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

по развитию технологии Frame Relay — форума Frame Relay. Спец-

ификация LMI позволила использовать следующие виды сервиса:

Использование значений DLCI для глобальной адресации хостов x

в сети Frame Relay.

Механизм автоматического определения текущего статуса PVC. x

Использование многоадресных сообщений. x

Использование процедур определения адреса канального уровня. x

Сообщения LMI передаются в информационной части кадра

Frame Relay и обеспечивают передачу управляющей информации в

направлении FRAD — сеть и обратно. Для передачи управляю-

щих сообщений LMI используется специальный PVC № 1023.

Спецификации ANSI и ITU-T.

При создании спецификаций ANSI и ITU-T широко использова-

лись материалы, которые были подготовлены специалистами FRF.

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

но и допускают совместную реализацию. В частности, сигнализация

в сетях Frame Relay определена в спецификациях:

ITU-T Q.933 x

ANSI T.617 x

Эти спецификации отличаются от LMI тем, что обеспечивают

взаимодействие однотипных устройств при управлении параметрами

PVC (Network — Network Interface NNI). Другим отличием является

использование DLCI № 0 (а не 1023) для передачи управляющих

сообщений. Указанные спецификации определяют также процедуры

управления виртуальными вызовами и алгоритмы управления SVC.

§6. Настройка Frame Relay

Интерфейс Frame Relay является интерфейсом второго уровня, к

которому подключаются несколько логических каналов (PVC). Каж-

дый PVC связывает данный маршрутизатор с каким-то одним дру-

гим маршрутизатором. Каждый PVC идентифицируется номером

DLCI.

При конфигурации FR DTE решаются две основные задачи:

группировка существующих PVC в одну или несколько IP-сетей x

(определение числа IP-интерфейсов маршрутизатора, привязан-

107

ных к FR-интерфейсу, и распределение PVC между IP-интер-

фейсами);

определение соответствия между DLCI и IP-адресом маршрути- x

затора, находящегося на другом конце данного PVC.

Ниже рассмотрены типичные способы решения этих задач.

Основной интерфейс

Наиболее простой способ организации IP на интерфейсе FR изо-

бражен на рисунке 22 слева.

Рис. 22. Протокол IP на основном FR-интерфейсе

В этом случае все PVC терминируются на одном IP-интерфейсе,

который совпадает с интерфейсом FR. В этом случае говорят, что

протокол IP используется на «основном интерфейсе» (major

interface).

Граф сети с точки зрения протокола IP показан на рис. 22 спра-

ва: все узлы подключены к общей IP-сети. Для этой сети, как и для

любой другой IP-сети, выделяется диапазон адресов и каждому

основному интерфейсу назначается IP-адрес из этого диапазона.

Примечание. По определению IP-сети, каждый узел в ней может

связаться с каждым без помощи промежуточного маршрутизатора.

Фактически, полную связность можно реализовать только при полно-

связной структуре PVC, где каждый маршрутизатор соединен с каж-

дым. В данном примере маршрутизаторы B, C, D не смогут связать-

ся друг с другом непосредственно.

Минимальная конфигурация интерфейса маршрутизатора выгля-

дит следующим образом:

108

CLI Router(config-if)encapsulation frame-relay [ietf]

Router(config-if)ip address адрес маска

По умолчанию используется инкапсуляция данных в кадрах FR

по стандарту Cisco, альтернативный вариант — инкапсуляция со-

гласно RFC 2427 (ему соответствует параметр ietf).

Тип LMI маршрутизатор определяет автоматически, анализируя

сообщения, поступающие от устройства DCE (FR-коммутатора). При

необходимости жестко задать тип LMI используется команда:

CLI Router(config-if) frame-relay lmi-type cisco | ansi | q933a 

Поскольку в рассматриваемой конфигурации интрефейса не ука-

заны DLCI и соответствующие им IP-адреса, то маршрутизатор авто-

матически:

получает номера DLCI от утройства DCE по протоколу LMI и x

таким образом определяет подключенные к интерфейсу PVC;

использует протокол InARP для опроса удаленных концов под- x

ключенных PVC на предмет их IP-адресов.

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

ко тех PVC, которые непосредственно подключены к маршрутизато-

ру, то маршрутизаторы, например, В и С не смогут связаться друг с

другом, поскольку между ними нет PVC.

Другой способ указания номеров DLCI и IP-адресов, доступных

через указанные DLCI, состоит в ручном конфигурировании этих

параметров:

CLI Router(config-if) frame-relay map ip IP-адрес DLCI

При ручном указании frame-relay map протокол InARP на соот-

ветствующем PVC автоматически отключается. Таким образом, либо

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

ступные через данный DLCI. На PVC, чей DLCI не упомянут в ко-

мандах frame-relay map, InARP продолжает работу.

ВНИМАНИЕ! Необходимо понимать, что под «всеми IP-

адресами» понимаются адреса IP-сети, состоящей из PVC, подклю-

ченных к данному интерфейсу. Достижимость других IP-адресов

определяется по таблице маршрутов.

Рассмотрим пример. Пусть адрес сети FR на рисунке 22 —

1.0.0.0/24. Интерфейсы маршрутизаторов А и В имеют адреса 1.0.0.1

и 1.0.0.2. Маршрутизатор В получает дейтаграмму, адресованную в

109

2.2.2.2. По своей таблице маршрутов он определяет, что подобные

дейтаграммы следует отправлять через узел 1.0.0.1. Далее маршрути-

затор В замечает, что он имеет IP-интерфейс (предположим, serial0),

подключенный в ту же IP-сеть, что и узел 1.0.0.1, следовательно, по-

иск по таблице маршрутов закончен и следующий маршрутизатор

найден.

На втором этапе процесса обслуживания дейтаграммы маршру-

тизатор В должен определить, по какому из нескольких подключен-

ных к интерфейсу serial0 виртуальных каналов PVC эта дейтаграм-

ма должна быть отправлена. Если бы на месте FR был Ethernet, то

маршрутизатор обратился бы к ARP-таблице и нашел бы MAC-адрес

узла 1.0.0.1. В случае FR аналогичную роль играет карта (map), ко-

торая ставит в соответствие IP-адреса сети 1.0.0.0/24 и PVC (DLCI),

подключенные к интерфейсу serial0. Карта заполняется протоколом

InARP и (или) вручную командами frame-relay map.

Продолжим пример. Маршрутизатор С в сети FR имеет адрес

1.0.0.3. Маршрутизатор В получает дейтаграмму, адресованную в

3.3.3.3. По своей таблице маршрутов он определяет, что подобные

дейтаграммы следует отправлять через узел 1.0.0.3. Маршрутизатор

В замечает, что он имеет IP-интерфейс serial0, подключенный в ту

же IP-сеть, что и узел 1.0.0.3, следовательно, поиск по таблице марш-

рутов закончен и следующий маршрутизатор найден.

Далее маршрутизатор В обращается к карте FR для определения

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

строится протоколом InARP, то, поскольку между В и С нет PVC,

карта не содержит информации об IP-адресе 1.0.0.3 и дейтаграмма

уничтожается. Для того, чтобы сделать возможной доставку дейта-

граммы, нужно реализовать один из следующих вариантов:

(решение на уровне 3) в таблице маршрутов В направить марш- x

рут к 3.3.3.3 через 1.0.0.1, а в таблице маршрутов А направить

маршрут к 3.3.3.3 через 1.0.0.3;

(решение на уровне 2) указать в карте маршрутизатора В, что x

адрес 1.0.0.3 доступен через PVC A-B (после этого протокол

InARP на этом PVC отключится, следовательно, необходимо так-

же указать, что через тот же PVC доступен и адрес 1.0.0.1).

IP-интерфейсы, подключенные к сетям FR, делятся на 2 типа:

точка-точка (point-to-point) и точка-много точек (point-to-multipoint).

Интерфейс point-to-point позволяет обмениваться пакетами только с

110

одним узлом, а point-to-multipoint — с несколькими. Очевидно, что

основной интерфейс (на примере маршрутизатора А) имеет тип

point-to-multipoint.

Подинтерфейсы «точка-точка»

На рисунке 23 слева изображена организация сетевого уровня на

FR-интерфейсе с использованием подинтерфейсов типа point-to-point.

Рис. 23. Протокол IP на подинтерфейсах «точка-точка»

В этом случае каждый PVC терминируется на собственном IP-

интерфейсе. Эти логические IP-интерфейсы называются подинтер-

фейсами основного интерфейса. На подинтерфейсах типа point-to-

point может терминироваться, очевидно, только один PVC. Такой

подинтерфейс с точки зрения протокола IP ничем не отличается от

обычного последовательного интерфейса; каждому из подинтерфей-

сов присваивается собственный IP-адрес. Поэтому (рис. 23 справа)

граф IP-сетей представлен тремя разными IP-сетями.

В данном случае нет смысла задействовать InARP или вручную

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

IP-интерфейс, должны находиться на другом конце единственного

PVC, подключенного к подинтерфейсу. Но так как к основному ин-

терфейсу могут быть подключены несколько PVC, то в конфигура-

ции каждого подинтерфейса типа «точка-точка» необходимо указать,

какой именно PVC подключен к данному подинтерфейсу (путем

спецификации номера DLCI).

Следующая последовательность команд решает задачи конфигу-

рации, показанной на рис. 23.