Ненавязчивый сервис

Наиболее популярные протоколы состояния канала - это 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).

Таблица 1. Значения поля TOS для различных приложений

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

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

Что-то с памятью моей стало...

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

Протоколам маршрутизации традиционно не нравятся "облака" сетей X.25 и frame relay. Большое число медленных каналов, соответственно, требующих рассылки большого числа объявлений LSA, затрудняет работу. Рассылка объявлений производится по "веерному" методу, поэтому полносвязная (fully-meshed) топология сети нежелательна. Сети с частично связной (partial-meshed) топологией здесь более предпочтительны.

Несмотря на отсутствие строгого ограничения на максимальное количество узлов в сети, возможности протоколов все же не безграничны. Эксперименты с протоколом OSPF показали, что 50 маршрутизаторов на зону (area) - это верхний предел, превышение которого чревато неприятными "сюрпризами" со стороны сети. При большем количестве узлов лучший выход состоит в создании новой зоны.

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