1. Источник данных (компьютер с1 на рис. 20.3) посылает получателям по уни-

уникальному или групповому (как на рисунке) адресу специальное РАТН-сооб-

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

приема своего трафика: верхние и нижние границы пропускной способности,

задержки и вариации задержки. Эти параметры составляют спецификацию

трафика источника. РАТН-сообщение передается маршрутизаторами сети

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

качестве параметров трафика применяются параметры алгоритма ведра маркеров,

то есть средняя скорость и глубина ведра. Кроме того, дополнительно могут

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

пакетов потока.

2. Каждый маршрутизатор, поддерживающий протокол RSVP, получив РАТН-

сообщение, фиксирует «состояние пути», которое включает предыдущий ад-

адрес источника PATH-сообщения, то есть последний по времени шаг в обрат-

обратном направлении (ведущий к источнику). Это необходимо для того, чтобы

ответ приемника прошел по тому же пути, что и РАТН-сообщение.

3. После получения PATH-сообщения приемник отправляет в обратном на-

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

на резервирование ресурсов (RESerVation Request, RESV), то есть RESV-

сообщение. На рис. 20.3 показано два приемника, компьютеры С2 и СЗ. В до-

дополнение к спецификациям трафика источника С1 (которые содержат пара-

параметры для качественного приема его трафика: верхние и нижние границы

пропускной способности, задержки и вариации задержки) RESV-сообщение

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

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

спецификацию фильтра, которая определяет, к каким пакетам сеанса применять

данное резервирование (например, по типу транспортного протокола и номеру

порта). Вместе спецификации запроса и фильтра представляют собой деск-

дескриптор потока, для которого выполняется резервирование. Запрашиваемые

параметры QoS в спецификации запроса могут отличаться от указанных в

спецификации трафика. Например, если приемник решает принимать не все

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

спецификации фильтра), то ему нужна, соответственно, меньшая пропускная спо-

способность.

4. Каждый маршрутизатор, поддерживающий протокол rsvp вдоль восходящего

пути, получив RESV-сообщение, выполняет две проверки: во-первых, имеются

ли у маршрутизатора ресурсы, необходимые для поддержания запрашиваемого

уровня QoS, а во-вторых, имеет ли пользователь право на резервирование ре-

ресурсов. Если запрос не может быть удовлетворен (из-за недостатка ресурсов

или ошибки авторизации), маршрутизатор возвращает сообщение об ошибке

отправителю. Если запрос принимается, то маршрутизатор посылает RESV-

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

требуемом уровне QoS передаются механизмам маршрутизатора, ответствен-

ответственным за управлением трафиком.

5. Прием маршрутизатором запроса на резервирование ресурсов означает также

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

маршрутизатора. Конкретный способ обработки параметров QoS маршрутизатором в

протоколе RSVP не описывается, но обычно она заключается в том, что мар-

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

памяти для нового резервирования. При положительном результате проверки

маршрутизатор запоминает новые параметры резервирования и вычитает их

из счетчиков соответствующих свободных ресурсов.

6. Когда последний в обратном направлении маршрутизатор получает RESV-

сообщение и принимает запрос, то он посылает подтверждающее сообщение

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

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

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

сливаются RESV-сообщения от приемников С2 и СЗ. Если для всех резерви-

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

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

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

7. После установления состояния резервирования в сети источник начинает от-

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

(приемникам) с заданным качеством обслуживания.

Таблица 20.1. Таблица сообщений протокола резервирования ресурсов (RSVP)

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

в одном направлении. Для того чтобы в рамках пользовательского сеанса данные

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

направлении, нужно, чтобы приемник и источник поменялись местами и выполнили

RSVP-резервирование еще раз.

Для того чтобы параметры резервирования можно было применить затем к тра-

трафику данных, необходимо, чтобы RSVP-сообщения и пакеты данных следовали

через сеть одним и тем же маршрутом. Это можно обеспечить, если передавать

RSVP-сообщеиия на основе тех же записей таблиц маршрутизации, которые

применяются для пользовательского трафика.

ВНИМАНИЕ

Если для передачи RSVP-сообщений будет использоваться традиционная схема выбора

маршрута из таблиц маршрутизации, то при этом потеряется возможность полноценного

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

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

с некоторой метрикой протокола маршрутизации.

Резервирование можно отменить прямо или косвенно. Прямая отмена выполня-

выполняется по инициативе источника или приемника с помощью соответствующих со-

сообщений протокола RSVP. Неявная отмена происходит по тайм-ауту: состояние

резервирования имеет срок жизни, как, например, и динамические записи в таб-

таблицах маршрутизации, и приемник по протоколу RSVP должен периодически

подтверждать резервирование. Если же подтверждающие сообщения перестают

поступать, то резервирование отменяется по истечении его срока жизни. Такое

резервирование называется мягким.

Для протокола RSVP в настоящее время разработано большое количество рас-

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

архитектуры RSVP. Одними из наиболее важных являются расширения, относящие-

относящиеся к инжинирингу трафика. Эти расширения применяются в технологии MPLS,

рассматриваемой в части V.

Дифференцированное обслуживание

Дифференцированное обслуживание (DiffServ) опирается на ту же обобщенную

модель QoS, что и интегрированное обслуживание, однако в качестве объектов

обслуживания рассматриваются не отдельные потоки, а классы трафика.

Напомним, что классом трафика называется совокупность поступающих на обработку па-

пакетов, обладающих общими признаками, например все пакеты голосовых приложений или

все пакеты с MTU в определенных пределах.

В отличие от потока класс трафика не различает пакеты в зависимости от их

маршрута, и рис. 20.4 иллюстрирует это отличие. Так, маршрутизатор R1 отно-

относит все потоки, требующие приоритетного обслуживания и втекающие в его ин-

интерфейс il, к одному классу, независимо от их дальнейшего маршрута. Маршру-

Маршрутизатор R2 оперирует уже с другим составом приоритетного класса, так как в

него вошли не все потоки интерфейса il маршрутизатора R1.

Обычно в сети DiffServ поддерживается дифференцированное обслуживание

небольшого количество классов трафика, например двух (чувствительного к за-

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

требующий гарантированной доставки пактов с определенным минимумом скорости

трафика). Небольшое количество классов определяет масштабируемость этой

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

потока пользователя. Высокая степень масштабирумости DiffServ обеспечивается

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

как он должен обслуживать тот или иной класс трафика, не согласовывая свои

действия с другими маршрутизаторами. Такой подход назван независимым пове-

поведением маршрутизаторов (Per Hop Behavior, РНВ). Так как в модели DiffServ

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

протокол резервирования ресурсов, подобный RSVP модели IntServ. Вместо этого

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

каждого из поддерживаемых сетью классов.

Рис. 20.4. В модели DiffServ объектами обслуживания являются классы трафика,

а не потоки

В качестве признака принадлежности IP-пакета к определенному классу в DiffServ

используется метка, переносимая полем приоритета IP-пакета (ToS-байт), кото-

которое с появлением стандартов DiffServ было переопределено и названо DS-бай-

том. Как показано на рис. 20.5, DS-байт переопределяет значения битов ToS-бай-

та, как это было определено ранее в соответствующих спецификациях (RFC 791,

RFC 1122, RFC 1349).

В настоящее время используются только старшие 6 бит DS-байта, причем толь-

только старшие 3 из них требуются для определения класса графика (что дает не бо-

более 8 различных классов). Младший бит (из используемых шести) DS-байта

обычно переносит признак IN — индикатор того, что пакет «вышел» из профиля

трафика (аналогично признакам DE и технологии Frame Relay и CPL в техноло-

технологии ATM). Промежуточные два бита обычно описывают различные варианты

обслуживания пакетов внутри одного класса трафика.

Рис. 20.5. Соответствие битов DS-байта битам поля типа сервиса

Маршрутизатор, поддерживающий модель DiffServ, должен обеспечивать клас-

классификацию, маркирование, измерение и кондиционирование трафика, его обслу-

обслуживание в приоритетной или взвешенной очереди и сглаживание.

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

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

маркировка пакетов на границе сети, поддерживающей модель DiffServ и нахо-

находящейся под административным контролем одной организации. Такая сеть

называется DiffServ-доменом. При выходе пакетов за пределы DiffServ-доме-

на маркировка снимается, так что другой домен может назначить ее заново. По-,

фаничные маршрутизаторы DiffServ исполняют роль контрольно-пропускных

пунктов домена, проверяя входящий трафик и определяя, имеет ли он право на

дифференцированное обслуживание.

Модель DiffServ подразумевает существование соглашения об уровне обслужи-

обслуживания (SLA) между доменами с общей фаницей. Соглашение SLA определяет

критерии политики предоставления сервиса, профиль трафика, а также гаранти-

гарантируемые параметры QoS. Ожидается, что трафик будет формироваться и сглажи-

сглаживаться в выходных точках домена в соответствии с SLA, а во входной точке до-

домена будет кондиционироваться в соответствии с правилами политики. Любой

трафик «вне профиля» (например, выходящий за верхние фаницы полосы про-

пропускания, указанной в SLA) не получает гарантий обслуживания (или же опла-

оплачивается по повышенной стоимости в соответствии с SLA). Правила политики

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

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

правила политики и фафик удовлетворяет оговоренному профилю, домен DiffServ

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

зафиксированные в SLA.

На сегодняшний день IETF разработаны два стандарта пошагового продвижения па-

пакетов для схемы РНВ, которые представляют два разных варианта обслуживания.

? Быстрое продвижение (Expedited Forwarding, EF) характеризуется одним зна-

значением кода A0111) и представляет собой высший уровень качества обслужи-

вания, обеспечивая минимум задержек и вариаций задержек. Любой трафик,

интенсивность которого превышает указанную в профиле, отбрасывается.

? Гарантированная доставка (Assured Forwarding, AF). Имеется четыре класса

трафика и три уровня отбрасывания пакетов в каждом классе — всего 12 раз-

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

минимум пропускной способности и размер буфера для хранения его оче-

очереди. Трафик, параметры которого превышают указанные в профиле, достав-

доставляется с меньшей степенью вероятности, чем трафик, удовлетворяющий

условиям профиля. Это означает, что качество его обслуживания может быть

понижено, но он не обязательно будет отброшен.

На основе этих пошаговых спецификаций и соответствующих соглашениях SLA

могут быть построены сервисы для конечных пользователей «из конца в конец» —

это EF-сервис и AF-сервис соответственно.

Основное назначение EF-сервиса — предоставление качества обслуживания, со-

сопоставимого с качеством обслуживания выделенных каналов, поэтому этот сер-

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

Поскольку EF-сервис допускает полное вытеснение другого трафика (например,

при его реализации с помощью приоритетной очереди), то его реализация должна

включать некоторые средства ограничения влияния EF-трафика на другие классы

трафика, например, с путем ограничения скорости EF-трафика на входе маршрути-

маршрутизатора по алгоритму ведра маркеров. Максимальная скорость EF-трафика и, воз-

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

Четыре класса AF-сервиса ориентированы на гарантированную доставку, но без

минимизации уровня задержек пакетов, как это оговорено для EF-сервиса. Га-

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

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

способности. Реализация классов AF-трафика хорошо сочетается с EF-сервисом —

EF-трафик может обслуживаться по приоритетной схеме, но с ограничением ин-

интенсивности входного потока. Оставшаяся пропускная способность распределя-

распределяется между классами AF-трафика в соответствии с алгоритмом взвешенного об-

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

не минимизацию задержек. Реализация AF-сервиса предполагает (но не требует)

взвешенного обслуживания для каждого класса с резервированной полосой про-

пропускания, а также применения обратной связи (в форме RED).

Относительная простота определяет недостатки дифференцированного обслужива-

обслуживания. Главным недостатком является сложность предоставления количественных га-

гарантий пользователям. Поясним это на примере сети, изображенной на рис. 20.6.

Обслуживание классов трафика подразумевает, что пограничные маршрутизато-

маршрутизаторы выполняют профилирование трафика без учета адреса назначения пакетов.

Обычно для входных интерфейсов пограничных маршрутизаторов задается не-

некоторый порог допустимой нагрузки для трафика каждого класса. Например,

пусть наша сеть поддерживает трафик двух классов, реализуя особое обслужи-

обслуживание и обслуживание с максимальными усилиями, причем порог для трафика

с особым обслуживанием установлен в 20 % пропускной способности для каж-

каждого входного интерфейса каждого пограничного маршрутизатора. Кроме того,

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

маршрутизаторов сети имеют одинаковую пропускную способность.

Рис. 20.6. Неопределенность уровня обслуживания в модели DiffServ

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

маршрутизаторов сети оказываются под воздействием разной нагрузки. На рис. 20.6 для упро-

упрощения ситуации показаны только потоки, требующие особого обслуживания. Так,

выходной интерфейс ill маршрутизатора R1 обслуживает два таких потока и на-

нагружен на 40 %, в то время как выходной интерфейс i21 маршрутизатора R2 —

только один из них, так как второй поток уходит через другой выходной интер-

интерфейс. Выходной же интерфейс i31 маршрутизатора R3 перегружен, обслуживая

три таких потока, так что его коэффициент использования равен 60 %. Учитывая

факторы, влияющие на образование очередей (см. главу 7), мы знаем, что коэф-

коэффициент использования является наиболее существенным фактором и значения

в районе 50 % являются критическими. Поэтому в интерфейсе 131 возникают

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

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

вариациям, а также потерям пакетов. Кроме того, страдает трафик класса обслужи-

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

ему достается только 40 % пропускной способности интерфейса.

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

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

коэффициент использования оказывается ниже, чем сумма коэффициентов исполь-

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

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

маршрутизаторов и выходных интерфейсов пограничных маршрутизаторов, можно также

уменьшить допустимый порог нагрузки входных интерфейсов трафиком особого

обслуживания, например, до 5 %.

Однако все эти меры не дают гарантии, что все интерфейсы всех маршрутизато-

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

использования, а следовательно, обеспечивать заданное качество обслуживания. Для

того чтобы дать такие гарантии, необходимо «улучшить» модель DiffServ и при-

применять методы инжиниринга трафика, то есть контролировать не классы, а пото-

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

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

сеть. Эта общая часть не обязательно включает полный путь, от входного интер-

интерфейса одного из пограничных маршрутизаторов до выходного интерфейса дру-

другого пограничного маршрутизатора. Достаточно, чтобы пакеты проходили хотя

бы два общих интерфейса, чтобы считать их агрегированным потоком, как, на-

например, в случае потока, проходящего через интерфейсы ill и i22 (см. рис. 20.6).

Затем, зная путь прохождения каждого агрегированного потока через сеть, мож-

можно проверить, имеются ли достаточные ресурсы вдоль пути для каждого потока,

например, не превышают ли коэффициенты использования интерфейсов задан-

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

назначения пакетов. Однако реализация такого подхода в IP-сетях сталкивается с

несколькими трудностями. Во-первых, в технологии DiffServ не предусмотрен

сигнальный протокол, такой как, например, RSVP в технологии IntServ. Это оз-

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

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

помощью какого-то специального программного обеспечения. Во-вторых, для

проведения таких расчетов нужно знать пути потоков через сеть. Такие пути оп-

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

маршрутизации, например RIP или OSPF (либо их комбинацией, если в сети использу-

используются несколько протоколов маршрутизации IGP-класса), или вручную. Поэтому

для ручного или автоматизированного расчетов нужно знать таблицы маршру-

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

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

перестройке таблиц. Нужно также учитывать, что маршрутизаторы могут применять

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

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

«Улучшенная» версия DiffServ, обеспечивающая учет адресов назначения, повы-

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

метода, в основе которого лежит идея независимого обслуживания классов трафика

каждым маршрутизатором сети.

Трансляция сетевых адресов

Ключевые слова: безопасность, дефицит адресов, трансляция сетевых адресов,

частные адреса, традиционная технология NAT, NAT-устройство, базовая

трансляция сетевых адресов, трансляция сетевых адресов и портов,

маршрутные объявления, исходящие и входящие сеансы связи.

Маршрутизация в составной сети осуществляется на основе тех адресов назначе-

назначения, которые помещены в заголовки пакетов. Как правило, эти адреса остаются

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

поступления на узел получателя. Однако из этого правила есть исключения. Например,

в широко применяемой сегодня технологии трансляции сетевых адресов (Net-

(Network Address Translation, NAT) предполагается продвижение пакета во внешней

сети (в Интернете) на основании адресов, отличающихся от тех, которые исполь-

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

Причины подмены адресов

Одной из наиболее популярных причин использования технологии NAT являет-

является дефицит IP-адресов. Если по каким-либо причинам предприятию, у которого

имеется потребность подключения к Интернету, не удается получить у постав-

поставщика услуг необходимого количества глобальных IP-адресов, то оно может при-

прибегнуть к технологии NAT. В этом случае для адресации внутренних узлов ис-

используются специально зарезервированные для этих целей частные адреса. Мы

уже рассказывали о них в главе 17.

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

Интернет или с узлами, имеющими глобальные адреса, необходимо использо-

использовать технологию NAT.

Технология NAT также оказывается полезной, когда предприятие из соображений

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

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

корпоративной сети, а также о структуре и интенсивности исходящего и входящего трафиков.

Традиционная технология NAT

Технология трансляции сетевых адресов имеет несколько разновидностей, наи-

наиболее популярная из которых — традиционная технология NAT - позволяет уз-

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

узлам внешних сетей. Подчеркнем, что в данном варианте NAT решается про-

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

Направление сеанса в данном случае определяется положением инициатора:

если обмен данными инициируется приложением, работающем на узле внутрен-

внутренней сети, то сеанс называется исходящим, несмотря на то, что в его рамках в сеть

могут поступать данные извне1.

Идея технологии NAT состоит в следующем. Пусть сеть предприятия образует

тупиковый домен, узлам которого присвоены частные адреса (рис. 20.7). На мар-

маршрутизаторе, связывающем сеть предприятия с внешней сетью, установлено

программное обеспечение NAT. Это NAT-устройство динамически отображает

набор частных адресов {IP*} на набор глобальных адресов {IP}, полученных

предприятием от поставщика услуг и присвоенных внешнему интерфейсу мар-

маршрутизатора предприятия.