Политика трафика (связь)

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

При использовании надёжных протоколов, таких как TCP (в отличие от UDP), отброшенные пакеты не подтверждаются получателем и, следовательно, отправителем будут переданы повторно, что приводит к дополнительному объёму трафика.

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

Кооперативные механизмы политики, такие как отброс пакетов на базе отдельных пакетов^[1], обеспечивают более быстрое сходимое поведение, повышают стабильность и эффективность использования ресурсов. Поэтому конечным точкам может быть сложно отличить трафик TCP, подвергнутый политике трафика, от трафика, прошедшего формирование трафика.

Если отбрасывание ячеек происходит на уровне ячеек (в отличие от политики на уровне пакетов), то влияние особенно существенно для более длинных пакетов. Поскольку ячейки обычно значительно короче максимального размера пакета, полисеры обычно отбрасывают ячейки, не соблюдая границы пакетов, поэтому общий объём отброшенного трафика распределяется между несколькими пакетами. Почти все известные механизмы пересборки пакетов для ATM Adaptation Layer 5 в случае потери хотя бы одной ячейки отбрасывают весь пакет, и вследствие этого даже умеренное превышение контракта может привести к значительной потере пакетов.

В RFC 2475 описаны элементы политики трафика, такие как измеритель и отбрасыватель^[2]. Также может присутствовать маркер (англ. marker). Измеритель измеряет объём трафика и определяет, превышает ли он условия контракта (например, с помощью алгоритма общего контроля скорости ячеек — GCRA). При превышении контракта некоторая политика определяет, должен ли данный протокольный блок данных (англ. PDU) быть отброшен или, если реализовано маркирование, как именно он должен быть промаркирован. Маркировка может включать установку битов перегрузки (например, флаг ECN у TCP или бит CLP у ATM) либо установку признака агрегированного трафика (например, DSCP в IP).

В простых реализациях трафик классифицируется по двум категориям («цветам»): соответствующий (зелёный) и превышающий (красный). RFC 2697 предлагает более точную классификацию: три «цвета»^[3]. В этом документе контракт описывается через три параметра: гарантированная информационная скорость (CIR), гарантированный размер всплеска (CBS) и допустимый размер всплеска (EBS). Пакет считается «зелёным», если он не превышает CBS, «жёлтым» — если превышает CBS, но не превышает EBS, и «красным» в остальных случаях.

Односкоростная трёхцветная маркировка, описанная в RFC 2697, допускает временные всплески трафика, если до этого пропускная способность канала не полностью использовалась. Более предсказуемый алгоритм описан в RFC 2698, где предложена двухскоростная трёхцветная маркировка^[4]. RFC 2698 определяет новый параметр — пиковой информационной скорости (PIR). RFC 2859 описывает маркер с трёхцветным скользящим по времени окном (Time Sliding Window Three Color Marker), который измеряет поток трафика и маркирует пакеты в зависимости от отношения пропускной способности к двум заданным скоростям: гарантированной целевой (CTR) и пиковой целевой (PTR)^[5].

На оборудовании Cisco как политика трафика, так и формирование трафика реализуются с помощью алгоритма токен-бакет^[6].

В ATM-сетях политика трафика известна как контроль пользовательских и сетевых параметров (англ. Usage/Network Parameter Control, UPC/NPC)^[7]. Сеть может также отбрасывать несоответствующий трафик посредством управления приоритетом (Priority Control). Эталонным алгоритмом для политики трафика и формирования трафика в ATM (определён ATM Forum и ITU-T) является алгоритм общего контроля скорости ячеек (англ. Generic Cell Rate Algorithm, GCRA), который рассматривается как вариант алгоритма «утекающего бака»^[8][9].

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

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

В сетях с установлением соединения (например, в ATM-системах) возможен контроль доступа при установлении соединения (англ. Connection Admission Control, CAC) на основе контракта трафика. В контексте IP-телефонии (VoIP) этот механизм часто называют также контролем допуска вызова (англ. Call Admission Control, CAC)^[10].

Приложение, желающее использовать сетевое соединение для передачи трафика, должно сначала инициировать запрос соединения (по сигнализации, например с помощью протокола Q.2931), при котором сети сообщаются характеристики трафика и требуемое качество обслуживания (QoS)^[11]. Эти параметры сопоставляются с установленным контрактом трафика. Если соединение разрешено, приложение получает разрешение использовать сеть для передачи пакетов.

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

Основное отличие между CAC и политикой трафика в том, что CAC — это априорная проверка (до передачи), а политика трафика — апостериорная (в процессе передачи).