В связи , полицейская трафик является процессом мониторинга сетевого трафика на соответствие с договором движения и принятием мер для обеспечения соблюдения этого контракта. Источники трафика, которые знают о контракте на трафик, могут применять формирование трафика, чтобы их выходные данные оставались в рамках контракта и, таким образом, не отбрасывались. Трафик, превышающий контракт на трафик, может быть немедленно отброшен, отмечен как несоответствующий или оставлен как есть, в зависимости от административной политики и характеристик избыточного трафика.
Эффекты
Получатель трафика, который был отслежен, будет наблюдать потерю пакетов, распределенную по периодам, когда входящий трафик превышает контракт. Если источник не ограничивает скорость отправки (например, с помощью механизма обратной связи ), это будет продолжаться и получателю может казаться, что ошибки связи или какое-либо другое нарушение вызывает случайную потерю пакетов. Полученный трафик, который подвергался контролю на маршруте, обычно соответствует условиям контракта, хотя джиттер может быть внесен элементами в сети, находящейся ниже по потоку от ограничителя.
С надежными протоколами, такими как TCP, а не UDP , отброшенные пакеты не будут подтверждены получателем и, следовательно, будут повторно отправлены отправителем, что приведет к увеличению трафика.
Воздействие на источники с контролируемой перегрузкой
Источники с механизмами управления перегрузкой на основе обратной связи (например, TCP ) обычно быстро адаптируются к статическому контролю, сходясь на скорости чуть ниже контролируемой постоянной скорости. [ необходима цитата ]
Совместные механизмы контроля, такие как отбрасывание на основе пакетов [1], способствуют более быстрой конвергенции, более высокой стабильности и более эффективному совместному использованию ресурсов. В результате конечным точкам может быть трудно отличить TCP-трафик, который просто контролируется, от TCP-трафика, который был сформирован .
Воздействие в случае банкомата
Если отбрасывание на уровне ячеек принудительно (в отличие от того, что достигается с помощью политик на основе пакетов), это особенно серьезно влияет на более длинные пакеты. Поскольку ячейки обычно намного короче максимального размера пакета, обычные ограничители отбрасывают ячейки, которые не соблюдают границы пакетов, и, следовательно, общий объем отброшенного трафика обычно будет распределяться по количеству пакетов. Почти все известные механизмы повторной сборки пакетов будут реагировать на отсутствующую ячейку, полностью отбрасывая пакет, и, следовательно, очень большое количество потерь пакетов может быть результатом умеренного превышения контролируемого контракта.
Процесс
RFC 2475 описывает такие элементы контроля трафика, как счетчик и дроппер . [2] Они также могут необязательно включать маркер . Счетчик измеряет трафик и определяет, превышает ли он контракт (например, GCRA ). Там, где это превышает контракт, некоторая политика определяет, будет ли отброшен какой-либо данный PDU или реализована ли маркировка, и как он должен быть отмечен. Маркировка может включать в себя установку флага перегрузки (например, флаг ECN TCP или бит CLP ATM ) или установку индикатора агрегирования трафика (например, IP-адрес кода дифференцированных услуг ).
В простых реализациях трафик подразделяется на две категории, или «цвета»: соответствующий (зеленый) и избыточный (красный). RFC 2697 предлагает более точную классификацию с тремя «цветами». [3] В этом документе контракт описывается с помощью трех параметров: согласованная скорость передачи информации (CIR), согласованный размер пакета (CBS) и избыточный размер пакета (EBS). Пакет является «зеленым», если он не превышает CBS, «желтым», если он превышает CBS, но не EBS, и «красным» в противном случае.
«Трехцветный маркер с одной скоростью», описанный в RFC 2697, допускает временные всплески. Всплески разрешены, если линия была недостаточно использована до того, как они появились. Более предсказуемый алгоритм описан в RFC 2698, который предлагает «трехцветный маркер с удвоенной скоростью». [4] RFC 2698 определяет новый параметр - пиковую информационную скорость (PIR). RFC 2859 описывает «трехцветный маркер скользящего окна», который измеряет поток трафика и маркирует пакеты на основе измеренной пропускной способности относительно двух указанных скоростей: согласованной целевой скорости (CTR) и максимальной целевой скорости (PTR). [5]
Реализации
На оборудовании Cisco и контроль трафика, и его формирование реализуются с помощью алгоритма token bucket . [6]
Контроль трафика в сетях ATM известен как контроль использования / параметров сети . [7] Сеть также может отбрасывать несоответствующий трафик в сети (используя управление приоритетом ). Справочник по контролю трафика и формированию трафика в ATM (данный ATM Forum и ITU-T ) - это общий алгоритм скорости передачи ячеек ( GCRA ), который описывается как версия алгоритма дырявого ведра . [8] [9]
Однако сравнение алгоритмов дырявого ведра и маркерного ведра показывает, что они являются просто зеркальными отображениями друг друга: один добавляет содержимое корзины, а другой убирает его, и убирает содержимое корзины там, где его добавляет. Следовательно, при заданных эквивалентных параметрах реализации обоих алгоритмов будут видеть точно такой же трафик как соответствующий и несоответствующий.
Контроль трафика требует ведения числовой статистики и показателей для каждого контролируемого потока трафика, но не требует реализации или управления значительными объемами буфера пакетов. Следовательно, реализовать его значительно проще, чем формирование трафика .
Контроль допуска подключений в качестве альтернативы
Сети с установлением соединения (например, системы ATM) могут выполнять контроль допуска соединения (CAC) на основе контрактов на трафик. В контексте передачи голоса по IP (VoIP) это также известно как контроль допуска вызовов (CAC). [10]
Приложение, которое хочет использовать сеть с установлением соединения для транспортировки трафика, должно сначала запросить соединение (через сигнализацию, например Q.2931 ), что включает в себя информирование сети о характеристиках трафика и требуемом качестве обслуживания (QoS). по приложению. [11] Эта информация сопоставляется с договором о трафике. Если запрос на соединение принят, приложению разрешается использовать сеть для транспортировки трафика.
Эта функция защищает сетевые ресурсы от злонамеренных подключений и обеспечивает соответствие каждого подключения согласованному договору о трафике.
Разница между CAC и политикой трафика заключается в том, что CAC - это априорная проверка (до передачи), а контроль трафика - это апостериорная проверка (во время передачи).
Смотрите также
Рекомендации
- ^ Дизайн и применение адаптеров ATM LAN / WAN. Bonjour, D .; De Hauteclocque, G .; Ле Моал, Дж. АТМ, 1998. ICATM-98., Международная конференция IEEE, 22-24 июня 1998 г. Страницы: 191–198 Идентификатор цифрового объекта 10.1109 / ICATM.1998.688177
- ^ IETF RFC 2475 «Архитектура для дифференцированных услуг», раздел 2.3.3 - определения счетчика, дроппера и маркера
- ^ IETF RFC 2697 «Трехцветный маркер с единой шкалой»
- ^ IETF RFC 2698 «Двухцветный трехцветный маркер»
- ^ IETF RFC 2859 «Трехцветный маркер скользящего окна во времени»
- ^ Что такое ведро токенов? в Cisco
- ^ Hiroshi Saito, телетрафик технология в сетях ATM, Artech House, 1993. ISBN 0-89006-622-1 .
- ↑ ATM Forum, Пользовательский сетевой интерфейс (UNI), v. 3.1, Prentice Hall PTR, 1995, ISBN 0-13-393828-X .
- ^ ITU-T, Управление трафиком и контроль перегрузки в B ISDN , Рекомендация I.371, Международный союз электросвязи, 2004 г., Приложение A, стр. 87.
- ^ Управление допуском вызовов VoIP в Cisco
- ^ Фергюсон П., Хьюстон Г., Качество обслуживания: обеспечение QoS в Интернете и корпоративных сетях, John Wiley & Sons, Inc., 1998. ISBN 0-471-24358-2 .