Компьютерные сети

Рекомендуемые параметры для качественного приема своего трафика: верхние и нижние границы пропускной способности, задержки и вариации задержки, параметры алгоритма ведра маркеров, то есть среднюю скорость и глубину ведра, дополнительно могут быть заданы максимально допустимая скорость и предельные размеры пакетов потока
Спецификация фильтра
Определяет, к каким пакетам сеанса применять данное резервирование (например, по типу транспортного протокола и номеру порта)
Спецификация запроса приемника

Требуемые приемнику параметры качества обслуживания
Дескриптор потока
Спецификация фильтра плюс спецификация запроса приемника
RESV-сообщение — запрос на резервирование ресурсов
Спецификация трафика источника плюс дескриптор потока

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

Для того чтобы параметры резервирования можно было применить затем к трафику данных, необходимо, чтобы RSVP-сообщения и пакеты данных следовали через сеть одним и тем же маршрутом. Это можно обеспечить, если передавать RSVP-сообщения на основе тех же записей таблиц маршрутизации, которые применяются для пользовательского трафика.
ВНИМАНИЕ-

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

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

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

Дифференцированное обслуживание (DiffServ) опирается на ту же обобщенную модель QoS, что и интегрированное обслуживание, однако в качестве объектов обслуживания рассматриваются не отдельные потоки, а классы трафика.

В отличие от потока в классах трафика пакеты не различаются в зависимости от их маршрутов; это отличие иллюстрирует рис. 18.4. Так, маршрутизатор R1 относит все потоки, требующие приоритетного обслуживания и втекающие в его интерфейс il, к одному классу, независимо от их дальнейшего маршрута. Маршрутизатор R2 оперирует уже другим составом приоритетного класса, так как в него вошли не все потоки интерфейса il маршрутизатора R1.

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

действия с другими маршрутизаторами. Такой подход назван независимым поведением маршрутизаторов (Per Hop Behavior, РНВ). Так как в модели DiffServ маршруты пакетов не отслеживаются, то здесь не используется сигнальный протокол резервирования ресурсов, подобный протоколу RSVP в модели IntServ. Вместо этого маршрутизаторы сети выполняют статическое резервирование ресурсов для каждого из поддерживаемых сетью классов.

Рис. 18.4. В модели DiffServ объектами обслуживания являются классы трафика, а не потоки
В качестве признака принадлежности IP-пакета к определенному классу в DiffServ используется метка, переносимая в поле приоритета IP-пакета (ToS-байт), которое с появлением стандартов DiffServ было переопределено и названо DS-байтом. Как показано на рис. 18.5, DS-байт переопределяет значения битов ToS-байта, определенных ранее в соответствующих спецификациях (RFC 791, RFC 1122, RFC 1349).
Биты: 0

Биты: 0 1 2 3 4 5 6 7
• ТипПриоритет;
оврв|Са
RFC 1122 RFC 1349
Рис. 18.5. Соответствие битов DS-байта битам поля типа сервиса
2 3 4 5 6 7
К
ZZXJ
“нН
Этот бит должен быть нулевым
Код класса дифференцированного Поле типа сервиса (TOS)
обслуживания RFC 791
RFC 2474

В настоящее время используются только старшие 6 битов DS-байта, причем только старшие три из них требуются для определения класса трафика (что дает не более 8-ми различных классов). Младший бит (из используемых шести) DS-байта обычно переносит признак IN - индикатор того, что пакет «вышел» из профиля трафика (аналогично признакам DE в технологии Frame Relay и CPL в технологии АТМ). Промежуточные два бита обычно описывают различные варианты обслуживания пакетов внутри одного класса трафика. Маршрутизатор, поддерживающий модель DiffServ, должен обеспечивать классификацию, маркирование, измерение и кондиционирование трафика, его обслуживание в приоритетной или взвешенной очереди и сглаживание.

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

Модель DiffServ подразумевает существование соглашения об уровне обслуживания (SLA) между доменами с общей границей. Это соглашение определяет критерии политики предоставления сервиса, профиль трафика, а также гарантируемые параметры QoS. Ожидается, что трафик будет формироваться и сглаживаться в выходных точках домена в соответствии с SLA, а во входной точке домена будет кондиционироваться в соответствии с правилами политики. Любой трафик «вне профиля» (например, выходящий за верхние границы полосы пропускания, указанной в SLA) не получает гарантий обслуживания (или же оплачивается по повышенной стоимости в соответствии с SLA). Правила политики предоставления сервиса могут включать время дня, адреса источника и приемника, транспортный протокол, номера портов. В том случае, когда соблюдаются правила политики и трафик удовлетворяет оговоренному профилю, DiffServ-домен должен обеспечить при обслуживании этого трафика параметры QoS, зафиксированные в SLA.

На сегодняшний день в IETF разработано два стандарта пошагового продвижения пакетов для схемы РЫВ, которые представляют два разных варианта обслуживания.
□ Быстрое продвижение (Expedited Forwarding, EF) характеризуется значением кода 10111 и представляет собой высший уровень качества обслуживания, обеспечивая минимум задержек и вариаций задержек. Любой трафик, интенсивность которого превышает указанную в профиле, отбрасывается.

□ Гарантированная доставка (Assured Forwarding, AF) характеризуется четырьмя классами трафика и тремя уровнями отбрасывания пакетов в каждом классе — всего получается 12 различных типов трафика. Каждому классу трафика выделяются определенные минимум пропускной способности и размер буфера для хранения его очереди. Трафик, параметры которого превышают указанные в профиле, доставляется с меньшей степенью вероятности, чем трафик, удовлетворяющий условиям профиля. Это означает, что качество его обслуживания может быть понижено, но он не обязательно будет отброшен.

На основе этих пошаговых спецификаций и соответствующих соглашений об уровне обслуживания (SLA) могут быть построены сервисы для конечных пользователей «из конца вконец» — это EF-сервис и AF-сервис соответственно.
Основное назначение EF-сервиса — обеспечение качества обслуживания, сопоставимого с качеством обслуживания выделенных каналов, поэтому этот сервис называется также сервисом виртуальных выделенных каналов.

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

Четыре класса AF-сервиса ориентированы на гарантированную доставку, но без минимизации уровня задержек пакетов, как это оговорено для EF-сервиса. Гарантированная доставка выполняется в том случае, когда входная скорость трафика не превышает отведенной данному классу минимальной пропускной способности. Реализация классов AF-трафика хорошо сочетается с EF-сервисом — EF-трафик может обслуживаться по приоритетной схеме, но с ограничением интенсивности входного потока. Оставшаяся пропускная способность распределяется между классами AF-трафика в соответствии с алгоритмом взвешенного обслуживания, который обеспечивает необходимую пропускную способность, но не минимизацию задержек. Реализация AF-сервиса предполагает (но не требует) взвешенного обслуживания для каждого класса с резервированной полосой пропускания, а также применения обратной связи (в форме RED).

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

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

Несмотря на такое достаточно жесткое ограничение, интерфейсы маршрутизаторов сети оказываются под воздействием разной нагрузки. На рис. 18.6 для упрощения ситуации показаны только потоки, требующие особого обслуживания. Так, выходной интерфейс ill маршрутизатора R1 обслуживает два таких потока и нагружен на 40 %, в то время как выходной интерфейс i21 маршрутизатора R2 — только один из них, так как второй поток уходит через другой выходной интерфейс. Выходной же интерфейс i31 маршрутизатора $3 перегружен, обслуживая три таких потока, так что его коэффициент использования равен 60 %. Учитывая факторы, влияющие на образование очередей (см. главу 7), мы знаем, что коэффициент использования является наиболее существенным фактором и значения в районе 50 % являются критическими. Поэтому в интерфейсе i31 возникают длинные очереди пакетов класса особого обслуживания, которые снижают качество такого обслуживания, так как приводят к длительным задержкам и их вариациям, а также потерям пакетов. Кроме того, страдает трафик класса обслуживания с максимальными усилиями, проходящий через этот интерфейс, так как ему достается только 40 % пропускной способности интерфейса.

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

Однако все эти меры не дают гарантии, что все интерфейсы всех маршрутизаторов сети будут работать в нужном диапазоне значений коэффициента использования, а следовательно, обеспечивать заданное качество обслуживания. Для того чтобы дать такие гарантии, необходимо «улучшить» модель DiffServ и применять методы инжиниринга трафика, то есть контролировать не классы, а потоки трафика, в данном случае агрегированные. Под агрегированным понимается поток, состоящий из пакетов одного класса, имеющих общую часть пути через сеть. Эта общая часть не обязательно включает полный путь от входного интерфейса одного из пограничных маршрутизаторов до выходного интерфейса другого пограничного маршрутизатора. Достаточно, чтобы пакеты проходили хотя бы два общих интерфейса, чтобы считать их агрегированным потоком, как, например, в случае потока, проходящего через интерфейсы ill и i22 (см. рис. 18.6).

Затем, зная путь прохождения каждого агрегированного потока через сеть, можно проверить, имеются ли достаточные ресурсы вдоль пути следования каждого потока, например, не превышают ли коэффициенты использования интерфейсов заданного порога. Для этого нужно провести профилирование с учетом адресов назначения пакетов. Однако реализация такого подхода в IP-сетях сталкивается с несколькими трудностями. Во-первых, в технологии Diffserv не предусмотрен сигнальный протокол, такой как, например, RSVP в технологии IntServ. Это означает, что все проверки наличия ресурсов у маршрутизаторов для каждого агрегированного потока нужно выполнять в автономном режиме, вручную или с помощью какого-то специального программного обеспечения. Во-вторых, для проведения таких расчетов нужно знать пути потоков через сеть. Такие пути определяются таблицами маршрутизации, которые строятся протоколом маршрутизации, например RIP или OSPF (либо их комбинацией, если в сети используются несколько протоколов маршрутизации класса IGP), или вручную. Поэтому для ручного или автоматизированного расчета нужно знать таблицы маршрутизации всех маршрутизаторов сети и следить за их изменениями, а это непросто, учитывая, что отказы линий связи или маршрутизаторов приводят к перестройке таблиц. Нужно также учитывать, что маршрутизаторы могут применять методы балансировки нагрузки, разделяя агрегированный поток на несколько подпотоков, что также усложняет расчеты.

«Улучшенная» версия DiffServ, обеспечивающая учет адресов назначения, повышает качество услуг оператора связи, но вместе с тем усложняет саму идею метода, в основе которого лежит идея независимого обслуживания классов трафика каждым маршрутизатором сети.
Трансляция сетевых адресов

Маршрутизация в составной сети осуществляется на основе тех адресов назначения, которые помещены в заголовки пакетов. Как правило, эти адреса остаются неизменными с момента их формирования отправителем до момента поступления на узел получателя. Однако из этого правила есть исключения. Например, в широко применяемой сегодня технологии трансляции сетевых адресов (Network Address Translation, NAT) предполагается продвижение пакета во внешней сети (в Интернете) на основании адресов, отличающихся от тех, которые используются для маршрутизации пакета во внутренней (корпоративной) сети.

Причины подмены адресов
Одной из наиболее популярных причин использования технологии NAT является дефицит IP-адресов. Если по каким-либо причинам предприятию, у которого имеется потребность подключиться к Интернету, не удается получить у поставщика услуг необходимого количества глобальных IP-адресов, то оно может прибегнуть к технологии NAT. В этом случае для адресации внутренних узлов служат специально зарезервированные для этих целей частные адреса. Мы уже рассказывали о них в главе 15.

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

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

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

63
.
Идея технологии NAT состоит в следующем. Пусть сеть предприятия образует тупиковый домен, узлам которого присвоены частные адреса (рис. 18.7). На маршрутизаторе, связывающем сеть предприятия с внешней сетью, установлено программное обеспечение NAT. Это NAT-устройство динамически отображает набор частных адресов {IP*} на набор глобальных адресов {IP}, полученных предприятием от поставщика услуг и присвоенных внешнему интерфейсу маршрутизатора предприятия.
Внутренняя сеть

Важным для работы NAT-устройства является правило распространения маршрутных объявлений через границы частных сетей. Объявления протоколов маршрутизации о внешних сетях «пропускаются» пограничными маршрутизаторами во внутренние сети и обрабатываются внутренними маршрутизаторами. Обратное утверждение неверно — маршрутизаторы внешних сетей не получают объявлений о внутренних сетях, объявления о них отфильтровываются при передаче на внешние интерфейсы. Поэтому внутренние маршрутизаторы «знают» маршруты ко всем внешним сетям, а внешним маршрутизаторам ничего не известно о существовании частных сетей.

Традиционная технология NAT подразделяется на технологии базовой трансляции сетевых адресов (Basic Network Address Translation, Basic NAT) и трансляции сетевых адресов и портов (Network Address Port Translation, NAPT). В технологии Basic NAT для отображения используются только IP-адреса, а в технологии NAPT — еще и так называемые транспортные идентификаторы, в качестве которых чаще всего выступают TCP- и UDP-порты.
Базовая трансляция сетевых адресов

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

Внутренняя сеть А
181.230.25.1181.230.25.2181.230.25.3
Сеть 10.0.2.0/24
Внутренняя сеть В
Таблица NAT-отображения
Частныеадреса
Глобальныеадреса
10.0.1.4
181.230.25.1
10.0.2.15
181.230.25.2
10.0.2.3
181.230.25.3
10.0.1.2 \185.127.125.2185.127.125.3185.127.125.4
Сеть 10.0.1.0/24
Таблица NAT-отображения
Частныеадреса
Глобальныеадреса
10.0.1.1
185.127.125.2
10.0.1.2
185.127.125.3
10.0.1.4
185.127.125.4
Рис. 18.8. Базовая трансляция сетевых адресов для исходящих сеансов

Все материалы, размещенные в боте и канале, получены из открытых источников сети Интернет, либо присланы пользователями  бота. 
Все права на тексты книг принадлежат их авторам и владельцам. Тексты книг предоставлены исключительно для ознакомления. Администрация бота не несет ответственности за материалы, расположенные здесь