4 курс (заочка) / Лекции / 3, 4, 5 лекции МИС (SIP, RTP)

Надежность связана с потерями и повреждениями данных. Может быть указана вероятность потерь и метод борьбы с ошибочными данными.

Также необходимо для каждого источника математически описать характеристики трафика. Например, каждый источник может описать характеристики своего транспортного потока с использованием дескриптора трафика, который содержит пиковую скорость, среднюю скорость и максимальный объем передаваемой информации [8].

2.4.2. Управление доступом

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

Модуль контроля доступа (см. рис. 2.2) принимает в качестве входных данных дескриптор трафика и требования QoS, а на его выходе формируется решение о принятии потока (в соответствии с требованиями QoS) или его отклонении, если требования QoS не выполняются [17]. Для этого он обращается к модулю критериев приема, содержащему правила, по которым схема управления доступом принимает или отклоняет поток.

Рис. 2.2. Компоненты управления доступом

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

21

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

Другим полезным компонентом управления доступом является модуль измерения процесса (measurement process module). Если источник информации строго соответствует заданным значениям дескриптора потока, модуль управления доступом может просто использовать эти значения. Однако при передаче в реальном времени строго задать эти параметры не удается. Когда реальный трафик становится пульсирующим (bursty traffic), использования сети может быть очень низким, если управление доступом производится исключительно на основе параметров, заданных в начале сеанса.

2.4.3. Управление трафиком

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

Для управления трафиком почти всегда используется алгоритм дырявого ведра (Token Bucket алгоритм) [18]. Задача алгоритма – принять решение: передать пакет или отбросить. Параметрами алгоритма являются скорость поступления пакетов в «ведро» (бит/c) и объём «ведра». Когда ведро переполняется, дополнительные пакеты будут потеряны. Этот алгоритм используется для систем управления трафиком, в которых избыточный трафик отбрасывается.

2.4.4. Классификация пакетов

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

22

2.4.5. Планирование пакетов

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

2.4.6. Потеря пакетов

При перегрузке сети некоторые пакеты должны быть удалены маршрутизаторами. Раньше это делалось случайно, что приводило к неэффективной производительности при передаче мультимедийного трафика. Например, кодированный MPEG поток пакет содержит I, P и B кадры. Кадры I сжимаются без использования временной избыточности между кадрами, а Р и В кадры формируются с использованием векторов движения от кадра I (или Р). Таким образом, пакеты, содержащие кадры I, являются более важными, чем те, которые содержат кадры P или B. Когда дело доходит до потерь пакетов в сети, приоритетное внимание должно уделяться кадрам I. Обзор различных схем потерь пакетов можно найти в [19].

2.4.7. Маршрутизация на основе QoS

Интернет с негарантированной доставкой использует протоколы маршрутизации Open Shortest Path First (OSPF), Routing Information Protocol (RIP) и Border Gateway Protocol (BGP) [20]. Эти протоколы называются протоколами негарантированной маршрутизации и обычно используют одноцелевые алгоритмы оптимизации, которые рассматривают только один показатель (число транзитных участков или стоимость линии) и сводят его к минимуму, чтобы найти кратчайший путь от источника к месту назначения. Таким образом, весь трафик направляется по кратчайшему пути, что приводит к перегрузке в некоторых узлах и недогрузке в других. Кроме того, если перегрузка используется для определения стоимости линии, то сильно перегруженные узлы имеют более высокую стоимость, и такие алгоритмы могут вызывать колебания в сети, где трафик непрерывно переключается от сильно пе-

23

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

При маршрутизации на основе QoS пути для разных потоков определяются с учетом некоторой информации о доступности ресурсов сети. Например, на рис. 2.3 предполагается, что поток от хоста X до хоста Y требует пропускной способности 4Mbps. Следовательно, хотя путь A-B- C короче (всего два транзитных участка), он не будет выбран, так как не имеет достаточной пропускной способности. Вместо него будет выбран путь A-E-D-C.

Рис. 2.3. Маршрутизация на основе QoS

Кроме маршрутизации на основе QoS, есть еще маршрутизации на основе политик и маршрутизация на основе ограничений. Маршрутизации на основе политик [21] обычно означает, что решения о маршрутизации основана не на знании топологии сети и ее метрик, а на некоторых политиках администрирования. Например, политика может запретить транспортный поток по конкретному пути из соображений безопасности, даже если путь удовлетворяет всем ограничениям QoS. Маршрутизация на основе ограничений [22] – еще одна новая концепция, которая происходит от маршрутизации на основе QoS, но имеет более широкий смысл. В ней маршруты вычисляются на основе нескольких ограничений, в том числе и ограничений QoS и политик. Оба этих способа маршрутизации можно рассматривать как частные случаи маршрутизации на основе ограничений.

2.5. Интегрированные сервисы

Для поддержки мультимедийного трафика через Интернет рабочая группа Integrated Services в Internet Engineering Task Force (IETF) разра-

24

ботала усовершенствованную модель Интернет под названием интегрированный сервис (IntServ) [23]. Эта модель характеризуется резервированием ресурсов. Она требует от приложений знания их требований к трафику и требований QoS, а также передачи промежуточным маршрутизаторам информации для резервирования ресурсов, таких как пропускная способность и размер буферов. Соответственно, если маршрутизаторы зарезервировали их и отправили обратно положительное подтверждение, можно начать передачу данных. Если, с другой стороны, достаточные ресурсы не доступны в любом маршрутизаторе пути, попытка повторяется через некоторое время. Эта модель также требует использования пакета классификаторов для определения потоков, которые должны получить определенный уровень сервиса, а также пакет планировщиков для обработки пересылки различных пакетов в порядке, обеспечивающем выполнения требований QoS.

Сущность Intserv почти исключительно связана с контролем компонент задержки очередей пакетов. Таким образом, задержка пакета – центральный момент, на основе которого принимаются решения.

Intserv вводит три класса обслуживания для поддержки RTI, RTT и гибких мультимедийных приложений. К ним относятся: гарантиро-

ванный сервис (Guaranteed service), сервис контроля нагрузки (Controlled Load service) и сервис негарантированной доставки (besteffort service). Для описания передачи и требований QoS используется поток дескрипторов [1]. Поток дескриптора состоит из двух частей:

спецификации фильтра (filterspec) и спецификации потока

(flowspec). Filterspec предоставляет информацию, необходимую классификатору пакетов для определения пакетов, которые принадлежат к этому потоку. Flowspec состоит из спецификации трафика (Tspec) и

спецификации запроса на обслуживание (RSpec). Tspec описывает поведение трафика в потоке через маркер параметров ведра (b,r), в то время как RSpec содержит требования QoS с точки зрения пропускной способности, задержки, нестабильности передачи и потери пакетов.

Поскольку все узлы сети на пути от источника к месту назначения должны быть проинформированы о запрашиваемых ресурсах, протоколов сигнализации не требуется. Для этой цели используется протокол резервирования ресурсов (RSVP) [24]. Процесс сигнализации показан на рис. 2.4. Отправитель посылает сообщение PATH для приемника с указанием характеристик трафика. Каждый промежуточный маршрутизатор на пути сообщения PATH для следующего шага определяется протоколом маршрутизации. Приемник, получив сообщение PATH, реагирует сообщением RESV запроса ресурсов для потока. Каждый промежуточный маршрутизатор на пути может отклонить или удовлетворить

25

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

Рис. 2.4. Сигнализация RSVP

RSVP может быть использован для различных сервисов управления QoS. Спецификация RSVP не определяет внутренний формат полей или объектов протокола RSVP и рассматривает их как непрозрачные, имея дело только с установкой механизма. RSVP был разработан для поддержки как одноадресных, так и многоадресных приложений. RSVP поддерживает гетерогенные QoS, что означает: для различных приемников в одной группе многоадресной рассылки можно запросить различные QoS. Такое разнообразие позволяет некоторым приемникам иметь резерв на то время, когда другие получают тот же трафик, используя сервис негарантированной доставки. Перейдем теперь к обсуждению классов сервисов, предлагаемых IntServ.

2.5.1. Классы гарантированного обслуживания

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

Используя спецификацию трафика (TSpec), сеть может вычислить различные параметры, описывающие, как она будет обрабатывать поток, и путем комбинирования параметров может вычислить максималь-

26

ную длину очередей и задержки маршрутизации пакета. При использовании модели потока жидкости, задержка в очереди выражается функцией двух параметров: 'b' – маркер размера ведра, и "r" – скорость передачи данных, запрашиваемая приложением.

2.5.2. Сервис управления загрузкой

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

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

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

2.5.3. Сервис негарантированной доставки

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

2.5.4. Недостатки модели Intserv для Интернета

Intserv использует RSVP, чтобы резервировать на маршрутизаторах сетевой путь для каждого потока. Хотя это позволяет сети предоставлять гарантии сервиса на уровне потока, возникает проблемы масштаба. Маршрутизаторы должны поддерживать заданное состояние потока для каждого потока, проходящего через маршрутизатор, что может привести к перегрузке сети. Более того, RSVP является программным прото-

27

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

2.6. Дифферецированный сервис

Дифферецированный сервис (Differentiated Services – Diffserv)

был предложен рабочей группой Diffserv из IETF как модель сервиса Интернет, устраняющую некоторые проблемы архитектуры Intserv [25]. DiffServ делит сеть на отдельные регионы, называемые DS доменами, где каждый домен управляется как отдельный объект. Одним из важных результатов является обеспечение гарантированного сервиса в рамках одного DS домена. Но если даже один транзитный участок находится за пределами домена, то гарантии уже не даются. Архитектура DiffServ может быть распространена на несколько доменов с использованием соглашений по уровню сервиса (Service Level Agreement's – SLA) между ними. SLA определяет правила разметки трафика, действия по обработке лишнего трафика и т.д.

Каждая вершина в домене DS может быть:

Граничной вершиной. Граничные вершины являются воротами домена DS. Граничная вершина является первой (или последней) вершиной, через которую проходит пакет при входе (или выходе) в (из) домен(а) DS. В ней выполняются специфичные граничные действия, такие как контроль доступа, классификация пакетов и обеспечение условий прохождения трафика. Алгоритм контроля доступа ограничивает число потоков внутри домена DS. Например, в простейшем случае, алгоритм контроля доступа может создать центральную структуру данных, содержащую текущий статус всех связей в домене DS. Когда поток проверяется на доступ, соответствующая граничная вершина должна просто проверить структуру данных на удовлетворение путей потока требованиям QoS. Каждый пакет, принадлежащий принятому потоку, по прибытии в домен DS классифицируется и маркируется как принадлежащий одному из классов сервиса, называемых “Behavior Aggregates” в терминах Diffserv. Каждому такому классу соответствует 8-битовое кодовое слово, называемое точкой кода (DS code-point). Маркировка пакетов проводится добавлением в поле TOS IP-заголовка пакета значения точки кода. Граничные вершины также обеспечивают

соглашения по трафику (Traffic Conditioning Agreements – TCA)

между собственным доменом DS и другими доменами, если это необходимо.

Внутренней вершиной. Внутренняя вершина расположена полностью внутри домена DS и соединяется с другими внутренними

28

вершинами или граничными вершинами этого же домена DS. Внутренние вершины занимаются только пересылкой пакетов. Когда пакет со своей точкой входа поступает в такую вершину, он пересылается на один транзитный участок дальше в соответствии с некоторыми заранее определенными правилами для этого класса пакетов. Такие правила называют Per-Hop Behaviors (PHB) и более детально будут рассмотрены ниже.

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

2.6.1. Per Hop Behavior (PHB)

PHB является набором заранее определенных правил, определяющих, каким образом буферы маршрутизатора и пропускная способность сети будет разделяться между конкурирующими потоками. PHB могут быть определены или в терминах ресурсов маршрутизатора (буферы и пропускная способность), или в терминах приоритетов относительно других PHB, или в терминах свойств трафика (задержки и потери). Несколько PHB могут быть объединены в группу. Группа может действовать на несколько путей, так как она определена в терминах характеристик поведения и не зависит от специфики приложений. PHB могут рассматриваться как базовые блоки при создании сервисов. Для пакета PHB выбирается в первой вершине на основе точки кода. Соответствие между точкой кода и PHB может быть 1 к 1 или N к 1. Примером параметров поведения при пересылке может быть определение для потока выделенной пропускной способности (Weighted Fair Queuing – WFQ) и приоритеты при потере (Random Early Detect – RED). IETF определены два общих PHB:

Assured Forwarding (AF) PHB. Делит входящий трафик на 4

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

Expedited Forwarding (EF) PHB. EF PHB определяет, что скорость отправки трафика из любого маршрутизатора должна быть больше или равна предусмотренной в конфигурации. Так для класса трафика, принадлежащего к EF PHB, в любой интервал времени гарантируется скорость отправки из любого маршрутизатора большая или равная его суммарной скорости получения пакетов. Это гарантирует

29

минимальную задержку пакетов в очередях, ограниченную только пропускной способностью сети. EF PHB используется для обеспечения сервиса класса «премиум» (Premium Service) без задержек и нестабильности передачи. Однако EF PHB требует очень жесткого механизма контроля доступа. Он должен обеспечивать скорость прибытия трафика меньше скорости его отправки, заданной в конфигурации EF PHB. Правильное функционирование EF PHB требует еще и жестких политик. Если пакеты нарушают установленные правила, они могут быть либо отброшены, либо переведены в более низкий класс трафика.

2.7. Мультипротокольная коммутация по меткам

Когда пакет IP прибывает на маршрутизатор, следующий транзитный участок (hop) для этого пакета определяется алгоритмом маршрутизации с использованием метода «совпадения длиннейшего префикса» (“longest prefix match”), т.е. совпадения самого длинного префикса в IPадресе пункта назначения со входами в таблице маршрутизации при выборе подходящего выходного маршрута [26]. Этот процесс добавляет некоторую задержку, так как таблицы маршрутизации достаточно велики и их просмотр требует времени. Также этот процесс приходится повторять независимо для каждого входящего пакета, даже если все пакеты принадлежат одному потоку и следуют в одном направлении. Этот недостаток может быть устранен использованием IP-коммутаторов, в которых небольшая метка прикрепляется к пакету и обновляется после каждого транзитного участка. Когда такой модифицированный пакет поступает на коммутатор (маршрутизатор в предыдущих терминах), эта метка используется для индексирования в короткой коммутационной таблице для определения дальнейшего маршрута и обновления метки. Все это легко реализуемо на уровне оборудования, поэтому выполняется с высокой скоростью. Этот подход раньше использовался в ATM для сотовых коммутаторов, которые работали с полем VPI/VCI пакета как с меткой. MPLS использует этот подход в сетях IP. Он называется мультипротокольным, так как эта технология также может быть использована на любом уровне сети, а не только на уровне IP.

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

Подобно Diffserv, сеть MPLS также делится на домены с граничными вершинами, называемыми ‘Label Edge Routers’ (LER), и внутренними вершинами, называемыми ‘Label Switching Routers’ (LSR). Пакетам, входящие в домен MPLS, назначаются метки, по которым и проис-

30