
Основы организации сетей CISCO т.2 - Вито Амато
.pdf
Рис. 12 6. Два конечных устройства на разных концах соединения могут использовать раз- личные номера DLCI для обращения к одному и тому же соединению
Формат фрейма протокола Frame Relay
Формат фрейма протокола Frame Relay показан на рис. 12.7. Поля флагов указывают на на- чало и конец фрейма. За первым полем флага следуют два байта адресной информации; 10 би- тов из этих двух байтов представляют собой текущий ID канала (т е. DLCI).
Ниже описаны поля фрейма.
∙Флаг — указывает на начало и конец фрейма.
∙Адрес — указывает длину адресного поля. Хотя в настоящее время адреса протокола ретрансляции фреймов имеют длину 2 байта, адресные биты позволяют в будущем увеличить длину адреса. Восьмой бит каждого байта адресного поля используется для указания адреса. Адрес содержит следующую информацию
∙Значение DLCI — отображает значение DLCI и состоит из 10 битов адресного по- ля.
∙Контроль перегрузки — последние 3 бита адресного поля, управляющие механиз- мами уведомления о перегрузке в сети. Такими механизмами являются FECN, BECN и DE (биты допустимости отбрасывания).
∙Данные — поле переменной длины, содержащее инкапсулированные данные и прото- колов верхних уровней.
∙FCS — последовательность проверки фрейма (frame check sequence, FCS), ис- пользуемая для обеспечения целостности передаваемых данных.
Длина поля в |
|
|
Поле пере- |
|
|
байтах |
1 |
2 |
менной длины |
2 |
1 |
|
|
Адрес, |
|
|
|
|
Флаг |
включая |
Данные |
FCS |
Флаг |
|
DLCI, FECN, |
||||
|
|
BECN и биты |
|
|
|
|
|
DE |
|
|
|
Рис 12 7 Поля флагов задают начало и конец фрейма

Адресация протокола Frame Relay
На рис 12.8 изображены два воображаемых PVC, один между Атлантой и Лос-Анджелесом, другой — между Сан-Хосе и Питтсбургом Для ссылки на свой PVC с Атлантой Лос-Анджелес использует DLCI 22, в то время как Атланта использует для этой же цели DLCI 82. Аналогич- ным образом, Сан-Хосе использует DLCI 22 для ссылки на свой PVC с Питтсбургом. Сеть ис- пользует свои внутренние механизмы для того, чтобы эти два локальных идентификатора PVC имели разные значения.
Рис 12.8. Пример использования DLCI в сети протокола Frame Relay
Реализация протокола Frame Relay в маршрутизаторах
Cisco — LMI
В истории протокола ретрансляции фреймов важное значение имеет 1990 год, когда компа-
нии Cisco Systems, StrataCom, Northern Telecom и Digital Equipment Corporation создали группу с целью концентрации средств и усилий на развитии технологии протокола ретрансляции фрей- мов и на ускорении внедрения взаимосвязанных программных продуктов этого протокола. Эта группа создала спецификацию, соответствующую базисной версии протокола, но дополнила ее новыми возможностями для сложных сред совместного использования. Эти усовершенствова-
ния стали называть интерфейсом локального управления (Local Management Interface, LMI).
Функционирование LMI
Главными целями применения LMI являются:
∙определение оперативного состояния различных PVC, известных маршрутизатору;
∙передача пакетов об активности устройств, с целью удостовериться в том, что PVC продолжает функционировать, а не отключился в связи с простоем (рис. 12.9);
∙информирование маршрутизатора о доступных PVC;
∙три типа LMI могут быть активизированы следующими командами маршрутизатора ansi, Cisco и q933a.

Рис. 12.9. LMI обеспечивают управление соединениями в сети
Дополнительные возможности интерфейса локального управления (LMI)
В дополнение к основным функциям протокола ретрансляции фреймов по передаче данных LMI-спецификация этого протокола включает в себя дополнительные возможности, которые облегчают поддержку больших и сложных сетей совместного использования. Некоторые из этих дополнительных возможностей называются общими (common) и могут быть использованы лю- бым устройством, удовлетворяющим требованиям спецификации. Другие функции LMI рас- сматриваются как необязательные (optional). Приведем полный список дополнительных воз- можностей, предоставляемых LMI.
∙Сообщения о состоянии виртуального канала — они обеспечивают связь и синхрони- зацию между сетевыми устройствами и устройствами пользователя, периодически сообщая о появлении новых PVC и удалении существовавших, а также информируя о работе сети в целом. Эти сообщения избавляют от ненужной рассылки данных по уже несуществующим каналам.
∙Рассылка данных одновременно нескольким получателям (многоадресная рассылка, multicast). Такая рассылка позволяет отправить один фрейм, а сеть обеспечивает его доставку сразу нескольким адресатам. Она является эффективным средством переда- чи сообщений протокола маршрутизации и протоколов преобразования адресов, ко- торые обычно требуется рассылать одновременно в несколько пунктов назначения.
∙Глобальная адресация (необязательная) придает локальному идентификатору соеди- нения глобальный характер, после чего он может быть использован для идентифика- ции конкретного интерфейса во всей сети протокола Frame Relay. Глобальная адреса- ция делает сеть протокола Frame Relay в вопросе адресации похожей на локальную сеть; протоколы преобразования адресов работают в этих двух типах сетей одинако- во.
∙Простой контроль потока (необязательный) — предоставляет механизм управления потоком типа XON/XOFF, который применяется ко всему интерфейсу. Предназначен для устройств, верхние уровни которых не могут использовать биты уведомления о переполнении и требуют определенного уровня контроля потока данных.
Формат LMI-фрейма
Спецификация протокола Frame Relay также включает в себя процедуры рассылки LMI. Со- общения LMI рассылаются во фреймах, отличающихся друг от друга индивидуальными LMI- идентификаторами (DLCI), определенными в спецификации консорциума как DLCI=1023. Фор- мат фрейма протокола ретрансляции фреймов показан на рис. 12.10.
Длина поля в байтах |
|
|
|
|
|
|
|
|
1 |
2 |
1 |
1 |
1 |
1 |
Переменное |
2 |
1 |
|
|
|
|
|
|
|
|
|
Флаг |
Идентификатор |
Индикатор не- |
Дискриминатор |
Ссылка |
Тип сооб- |
Информа- |
FCS |
Флаг |
LMI |
нумерованной |
протокола |
на вызов |
щения |
ционные |
|||
|
информации |
элементы |
|
|
||||
|
|
|
|
|
|
|
Рис. 12.10. В LMI-фреймах базовый протокольный заголовок такой же, как и у обычного фрейма протокола Frame Relay
После поля флага и поля LMI фрейм содержит 4 обязательных байта. Первый из этих обяза-
тельных байтов (индикатор ненумерованный информации, unnumbered information indicator)
имеет такой же формат, как и LAPB-индикатор фрейма ненумерованной информации (unnumbered information, UI), в котором последний (poll/final) бит установлен в ноль. Следующий байт, называемый дискриминатором протокола (protocol discriminator), содержит значение, опреде- ляющее LMI. Третий обязательный байт (ссылка на вызов, call reference) всегда заполнен нуля- ми.
Последний обязательный байт представляет собой поле типа сообщения (message type). Оп- ределены два типа сообщений: сообщения запросов о состоянии и сообщения о текущем со- стоянии. Сообщения о текущем статусе являются ответами на сообщения-запросы. Сообщения об активности (keepalive) (сообщения, посылаемые в оба конца соединения для подтверждения того, что обе стороны продолжают рассматривать соединение как активное) и сообщения о ста- тусе PVC представляют собой примеры таких сообщений. Они являются типичными для LMI, и, как правило, присутствуют в любой реализации сети, соответствующей спецификации протоко-
ла Frame Relay.
Вместе взятые, запросы о статусе и ответы на них (сообщения о статусе) помогают прове- рить целостность логического и физического каналов. Эта информация имеет критически важ- ное значение для маршрутизации, поскольку протоколы маршрутизации принимают решения, основанные на предположении о целостности сети.
Далее следует поле информационного элемента (information element, IE), содержащее пере- менное количество байтов. За полем типа сообщения находится некоторое количество IE. Каж- дый информационный элемент состоит из однобайтного идентификатора IE, поля длины IE и одного или более байтов, содержащих конкретные данные.
Глобальная адресация
Кроме общих возможностей LMI имеется несколько необязательных, которые, однако, ока- зываются исключительно полезными при совместном использовании среды. Первой такой воз- можностью является опция глобальной адресации (global addressing). При ее использовании зна- чения, вводимые в DLCI-поле фрейма становятся глобально значимыми адресами индивидуаль- ных устройств конечного пользователя (например, маршрутизаторов). Пример такой адресации приведен на рис. 12.8.
Как уже отмечалось ранее, базовая (нерасширенная) спецификация протокола Frame Relay поддерживает только такие значения поля DLCI, которые имеют локальный характер. В этом случае отсутствуют адреса, идентифицирующие сетевые интерфейсы или узлы, подсоединенные

к этим интерфейсам. Ввиду отсутствия таких адресов они не могут быть найдены обычными ме- тодами обнаружения и преобразования адресов. Это означает, что при обычной адресации про- токола ретрансляции фреймов необходимо создавать карты статической разметки, которые бу- дут указывать маршрутизаторам, какие DLCI следует использовать для нахождения удаленных устройств и ассоциированных с ними адресов.
Следует обратить внимание на то, что каждый интерфейс на рис. 12.8 имеет собственный идентификатор. Предположим, что Питтсбург должен отправить фрейм в Сан-Хосе. Идентифи- катором Сан-Хосе является 22, поэтому Питтсбург помещает значение 22 в поле DLCI и посы- лает фрейм в сеть протокола Frame Relay. В точке выхода сеть меняет содержимое поля DLCI на 62 для указания на узел, являющийся источником фрейма. Каждому интерфейсу маршрутизато- ра в качестве идентификатора узла присвоено уникальное значение, поэтому отдельные устрой- ства без труда различаются. Это позволяет выполнять маршрутизацию в сложных средах. В больших разветвленных средах глобальная адресация предоставляет значительные преимущест- ва. В результате сеть протокола Frame Relay выглядит для периферийного маршрутизатора как обычная локальная сеть.
Многоадресная передача
Еще одной ценной особенностью LMI является одновременная передача одного и того же пакета данных нескольким пользователям. Группы многоадресной рассылки задаются последо- вательностью из четырех зарезервированных значений DLCI (от 1019 до 1022). Фреймы, от- правленные устройством, использующим один из этих четырех DLCI, дублируются сетью и рас- сылаются по всем выходным точкам, указанным в наборе. В многоадресном расширении опре- делены также сообщения LMI, которые уведомляют устройства пользователя о добавлении, удалении и наличии многоадресных групп. В сетях, использующих динамическую маршрутиза- цию, многие маршрутизаторы должны обмениваться между собой информацией о маршрутах. Сообщения о состоянии сети могут эффективно рассылаться путем использования многоадрес- ных идентификаторов DLCI. Это также позволяет рассылать сообщения отдельным группам пользователей.
Инверсный протокол ARP
Механизм инверсного протокола ARP позволяет маршрутизатору автоматически строить карту отображения протокола Frame Relay, как показано на рис. 12.11. Маршрутизатор узнает используемые DLCI от коммутатора при первоначальном обмене LMI. После этого маршрутиза- тор посылает запрос инверсного ARP каждому DLCI оля каждого протокола, сконфигурирован- ного и поддерживаемого этим интерфейсом. Возвращаемая инверсным ARP информация ис- пользуется для построения карты отображения протокола ретрансляции фреймов.

Рис. 12.11. Маршрутизатор узнает используемые DLCI от коммутатора протокола ретрансляции фреймов и посылает запрос инверсного ARP каждому DLCI
Отображение в протоколе ретрансляции фреймов
Адрес маршрутизатора следующего перехода, найденный в таблице маршрутизации, должен быть преобразован в DLCI протокола ретрансляции фреймов, как показано на рис. 12.12. Это преобразование осуществляется через структуру данных, называемую картой отображения протокола Frame Relay (Frame Relay map). После этого таблица маршрутизации используется для определения адреса следующего перехода или DLCI для выходного потока данных. Эта структура данных может быть статически сконфигурирована на маршрутизаторе или автомати- чески установлена путем использования возможностей инверсного протокола ARP.
Таблицы коммутации протокола Frame Relay
Таблица коммутации протокола Frame Relay состоит из четырех элементов: два — для вход- ного порта и входного DLCI и два — для выходного порта и выходного DLCI, как показано на рис. 12.13. Таким образом, при прохождении каждого коммутатора значение DLCI может быть отображено заново. Поскольку" ссылка на порт может измениться, значения DLCI остаются по- стоянными.

Коммутатор протокола
передачи фреймов
P1 DLCI200
Рис. 12.13. Маршрутизаторы используют инверсный протокол АКР для нахождения уда- ленных IP-адресов и создания карты отображения локальных DLCI и ассоциированных с ними
IP-адресов
____________________________________________________________________________________
Инженерный журнал: общее описание функционирования протокола Frame Relay
После изучения описанных выше операций протокола ретрансляции фреймов можно выполнить следующие действия по реализации этого протокола в сети:

Рис. 12.15. Маршрутизатор изменяет статус каждого DLCI, основываясь на ответе ком-
мутатора протокола ретрансляции фреймов
Этап 1. Следует заказать службу протокола Frame Relay у провайдера или создать собственную среду действия этого протокола.
Этап 2. Подсоединить каждый маршрутизатор, непосредственно или посредством CSU/DSU (модуль канальной службы/модуль цифровой службы) к комму- татору протокола Frame Relay.
Этап 3. Когда маршрутизатор СРЕ начинает функционировать, он посылает со-
общение-запрос о статусе коммутатору протокола Frame Relay. Это со- общение уведомляет коммутатор о статусе этого маршрутизатора и за-
прашивает у коммутатора информацию о статусе связи других удаленных маршрутизаторов.
Этап 4. После получения коммутатором этого запроса он отвечает сообщением о
состоянии, содержащим DLCI всех удаленных маршрутизаторов, которым данный локальный маршрутизатор может посылать данные.
Этап 5. Каждый маршрутизатор рассылает каждому DLCI пакет запроса инверсного ARP, представляя себя и предлагая каждому удаленному маршрутизатору сделать то же, сообщив свой адрес сетевого уровня.
Этап 6. Для каждого DLCI, о котором маршрутизатор получает сообщение ин- версного ARP, создается элемент в таблице отображения протокола
ретрансляции фреймов, содержащий локальный DLCI и адрес сетевого уровня удаленного маршрутизатора, а также информацию о состоянии ка-
нала связи. Отметим, что этот DLCI является локально сконфигуриро- ванным, а не тем, который используется удаленным маршрутизатором. В таблице отображения протокола ретрансляции фреймов могут быть за-
фиксированы три вида состояния канала связи.
∙Активное состояние — указывает на то, что канал активен и маршрути- заторы могут обмениваться данными.
∙Неактивное состояние — указывает на то, что локальная связь с комму- татором протокола ретрансляции фреймов существует, а связь удален- ного маршрутизатора с эти коммутатором отсутствует;

∙Отключенное состояние — указывает на то, что от коммутатора не по- ступило LMI или отсутствует служба между маршрутизатором СРЕ и коммутатором протокола Frame Relay.
Этап 7. Каждые 60 секунд маршрутизаторы обмениваются сообщениями инверсного протокола ARP.
Этап 8. Каждые 10 секунд (этот интервал устанавливается в параметрах конфи- гурации) маршрутизатор СРЕ посылает коммутатору Frame Relay со- общение об активности. Цель рассылки таких сообщений состоит в про-
верке работоспособности этого коммутатора.
Подынтерфейсы протокола Frame Relay
Для того, чтобы привести в действие механизм рассылки полных сообщений об изменениях маршрутизации в сети протокола Frame Relay необходимо сконфигурировать на маршрутизато- ре логически назначаемые интерфейсы, называемые подынтерфейсами (субинтерфейсами). По- дынтерфейсы являются логическими разделами одного физического интерфейса. В конфигура- ции, использующей Подынтерфейсы, каждый постоянный виртуальный канал может быть сконфигурирован как соединение "точка-точка". Это позволяет подынтерфейсу функциониро- вать аналогично выделенной линии, как показано на рис. 12.16.
Рис. 12.16. Сообщения об изменениях маршрутной информации могут рассылаться через Подынтерфейсы так, как если бы они исходили от различных физических интерфейсов
Прежние реализации протокола ретрансляции фреймов требовали, чтобы маршрутизатор (т.е. устройство DTE) имел последовательный интерфейс в распределенной сети для каждого PVC, как показано на рис. 12.17.
Рис. 12.П. Увеличение количества интерфейсов центрального маршрутизатора эффектив- но, но значительно увеличивает стоимость сети

Интерфейс Serial 0.1 Сеть 7777
Логическое разделение одного физического последовательного интерфейса распределенной сети на несколько виртуальных подынтерфейсов позволяет существенно уменьшить общую стоимость сети протокола Frame Relay, как показано на рис. 12.18.
Среды с расщеплением горизонта
В средах маршрутизации с расщеплением горизонта маршруты, найденные на одном подын- терфейсе, могут быть сообщены другому подынтерфейсу. Вследствие этого маршрутизация с расщеплением горизонта уменьшает количество петель маршрутизации, не позволяя сообщени- ям об изменениях в сети, полученных на одном физическом интерфейсе, передаваться через тот же самый физический интерфейс (рис. 12.19). Благодаря этому в ситуации когда удаленный маршрутизатор посылает сообщение об изменении на центральный маршрутизатор, который соединяет несколько виртуальных каналов (PVC) в один физический интерфейс, последний не
может передавать этот маршрут другим удаленным маршрутизаторам через тот же физический интерфейс (рис. 12.20).