Пять правил помогут решить проблемы

Развитие Internet привело к необходимости создания более гибкого и эффективного протокола маршрутизации для обслуживания крупных сетей. По замыслу создателей, протоколы состояния канала должны были решить характерные для протоколов вектора расстояний проблемы. Однако, в отличие от протоколов вектора расстояния, протоколы состояния канала сложны и требовательны к ресурсам маршрутизаторов. Основу протоколов состояния канала составляет алгоритм предпочтения кратчайшего пути, созданный в 1978 году.

Формальное описание протоколов состояния канала достаточно запутанно и может занять не один десяток страниц. В упрощенной форме принципы работы маршрутизаторов в соответствии с этим протоколом можно сформулировать в виде пяти несложных правил. Итак, каждый маршрутизатор в сети должен:

при включении в сеть получить информацию о своих соседях;

узнать стоимость пути до каждого из соседей (т. е. узнать о состоянии каналов);

подготовить пакет-объявление, содержащий полученную информацию;

разослать этот пакет всем соседям;

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

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

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

HELLO! КТО ЗДЕСЬ?

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

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

Задержку канала можно определить, послав специальный ECHO-пакет, который принимающая сторона должна немедленно отправить обратно. Разделив время отклика пополам, маршрутизатор вычисляет приблизительную величину задержки канала.

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

Хороший протокол должен уметь распределять нагрузку по нескольким каналам. Современные протоколы маршрутизации успешно справляются с этой задачей.

Рисунок 4. Обмен пакетами с объявлениями о состоянии каналов.

Шаг номер три в программе маршрутизатора состоит в сообщении полученных знаний остальным. Информация о каналах должна быть разослана соседям. Однако пакеты с объявлениями о состоянии каналов (Link State Advertisement, LSA) могут затеряться при транспортировке или прибыть в ином порядке. Для того чтобы получатель мог разобраться в пришедшей информации, каждый пакет с объявлением о состоянии каналов снабжается полями source (адрес отправителя), sequence number (номер пакета в последовательности отправленных сообщений) и age (возраст) (см. Рисунок 4).

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

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

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

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

Получив пакет LSA, маршрутизатор проверяет пару (source, sequence), что позволяет отбросить устаревшие и дублированные объявления. Поле age задает время, по истечении которого не приславший новых объявлений узел считается недоступным.

В конкретных протоколах данные поля могут носить другие названия, в протоколе OSPF, например, поля age и sequence носят названия DeadInt и DD Sequence, а протокол IS-IS даже использует специальный тип пакета - порядковый пакет. Однако, независимо от протокола, наличие подобной информации обязательно для надежной работы алгоритма предпочтения кратчайшего пути.

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

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

Рисунок 5. Сеть и ее предствление в виде графа.

НЕНАВЯЗЧИВЫЙ СЕРВИС

Наиболее популярные протоколы состояния канала - это IS-IS и OSPF. Протокол IS-IS изначально создавался для сетей OSI, но впоследствии был адаптирован и к другим протоколам сетевого уровня, в частности к IP. Например, сеть NSFNet широко использует IS-IS в своей работе. К основным достоинствам IS-IS принято относить его "врожденную" способность взаимодействовать с самыми различными протоколами сетевого уровня, что делает его особенно полезным в крупных многопротокольных сетях. В сетях TCP/IP, все же, более популярен протокол OSPF. Протоколы IS-IS и OSPF имеют очень много общего (OSPF, по сути, является улучшенной версией IS-IS). Все сказанное ранее о протоколах состояния канала в равной степе-ни справедливо и для IS-IS, и для OSPF.

Протоколом OSPF предусмотрена полезная возможность вычисления отдельного набора маршрутов для каждого значения поля "тип сервиса" (Type-Of-Service, TOS) в заголовке протокола IP. До создания OSPF ни один протокол не использовал значение этого поля.

Поле "тип сервиса" позволяет запрашивать для трафика определенный уровень сервиса. Длина поля - четыре бита, из которых значимым может быть только один. Таким образом, мы имеем всего четыре возможных варианта: минимальная задержка, максимальная пропускная способность, максимальная надежность, минимальная стоимость (в смысле оплаты). Каждое приложение по-разному устанавливает значение поля TOS. Значения битов данного поля для некоторых приложений приведены ниже (см. Таблица 1).

Как видно из таблицы, протоколам FTP и SMTP требуется передавать команды с минимальной задержкой, а для передачи данных им необходима большая пропускная способность. Если запрос DNS передается по протоколу UDP, то очевидно, что программа-resolver, пославшая этот запрос, желает получить ответ как можно скорее, так как дейтаграммы UDP не требуют посылки подтверждений. Настроив протокол OSPF для определения маршрутов либо с минимальной задержкой, либо с максимальной пропускной способностью, в зависимости от TOS, мы можем еще больше ускорить работу DNS, так же как FTP и SMTP.

Однако не стоит забывать, что протоколы состояния канала очень требовательны к памяти. Злоупотребление богатыми возможностями OSPF быстро приведет к переполнению памяти маршрутизатора и сбоям при вычислениях маршрутов. В итоге весь трафик окажется в состоянии хаоса, и никакого заявленного типа сервиса он не получит.