RFC 4115 A Differentiated Service Two-Rate, Three-Color Marker with Efficient Handling of in-Profile Traffic

Network Working Group                                      O. Aboul-Magd
Request for Comments: 4115                                      S. Rabie
Category: Informational                                  Nortel Networks
                                                               July 2005

A Differentiated Service Two-Rate, Three-Color Marker with Efficient Handling of in-Profile Traffic

Дифференцированное обслуживание с 3-цветной маркировкой по 2 скоростям и эффективной обработкой трафика по профилю

PDF

Статус документа

Документ содержит информацию, адресованную сообществу Internet. В документе не содержится каких-либо стандартов Internet. Допускается свободное распространение документа.

Авторские права

Copyright (C) The Internet Society (2005).

Замечание IESG

В этом RFC не представлен какой-либо стандарт Internet. IETF не дает каких-либо сведений о пригодности этого RFC для каких-либо целей и, в частности, отмечает, что решение о публикации принималось не на основе рецензии IETF в части таких аспектов, как безопасность, контроль перегрузок и неподобающее взаимодействие с развернутыми протоколами. Редактор RFC самостоятельно принимал решение о публикации документа. Читателям следует соблюдать осторожность при оценке пригодности документа для реализации или развертывания. Дополнительная информация об этом представлена в RFC 3932.

Аннотация

Этот документ описывает 3-цветную маркировку по 2 скоростям, которую можно применять для услуг передачи данных, включая Frame Relay. Маркеры могут служить для измерения трафика на уровне потока в расширяющихся услугах IP и L2 VPN. Определенный здесь маркер отличается от предложенных ранее в части обработки трафика по профилю (in-profile). Кроме того, маркер не задает требований к пиковой скорости для абонентских краевых устройств (CE1).

1. Введение

Для дифференцированных услуг определена архитектура QoS2 в сети Internet [RFC2475], двумя компонентами которой являются измерение и маркировка. В этом документе описан алгоритм измерения и маркировки с 3 цветами по 2 скоростям, который подходит для дифференцированных услуг, таких как IP и L2 VPN. Этот алгоритм применяется в службах передачи данных, включая Frame Relay.

Определенные здесь измерение и маркировка отличаются от предложенных в [RFC2697] и [RFC2698]. Отличие от [RFC2697] заключается в использовании маркера по 2 скоростям с 3 цветами (в [RFC2697] одна скорость), а от [RFC2698] — в способе задания параметров, который позволяет улучшить обработку по профилю для преобладающих сценариев обслуживания в более широком диапазоне параметров трафика.

Кроме того, описанный алгоритм избавляет устройства CE от формовать трафик в соответствии определенной пиковой скоростью (PIR3), как может потребоваться для маркеров [RFC2698], когда значение пикового размера всплесков (PBS4) меньше их согласованного размера (CBS5).

Описанный здесь маркер подходит для режимов color-blind (слепой) и color-aware, определенных в [RFC2698].

2. Настройка конфигурации

Работа маркера описывается двумя значениями скорости — согласованной (CIR6) и избыточной (EIR7), которые определяют скорость генерации маркеров (token) в корзине (token bucket), размер которых задают согласованная (CBS) и избыточная (EBS) величина всплесков, соответственно.

CBS и EBS измеряются в байтах и должны настраиваться так, чтобы быть больше ожидаемого максимального размера входящих PDU. CIR и EIR измеряются в бит/с и могут устанавливаться независимо одна от другой. Можно также связать CIR и EIR, задавая параметр продолжительности пиков T=CBS/CIR=EBS/EIR.

3. Измерение и маркировка

Поведение измерителя определяется его режимом и двумя корзинами маркеров C и E со скоростями CIR и EIR, соответственно, и размером CBS и EBS.

Корзины C и E исходно (время 0) полны, т. е. счетчики маркеров имеют значения Tc(0) = CBS и Te(0) = EBS. После этого счетчик Tc инкрементируется на 1 CIR раз в секунду (до CBS), а Te — EIR раз в секунду (до EBS).

В режиме color-aware предполагается, что алгоритм способен распознать цвет входящего пакета (green, yellow, red). Измерение в режиме color-aware описано ниже.

При поступлении зеленого пакета (green) размером B в момент t:

  • если Tc(t) — B > 0, пакет считается зеленым, а Tc(t) уменьшается на B;

  • если Te(t) — B > 0, пакет считается желтым (yellow), а Te(t) уменьшается на B;

  • пакет считается красным (red).

При поступлении желтого пакета (yellow) размером B в момент t:

  • если Te(t) — B > 0, пакет считается желтым (yellow), а Te(t) уменьшается на B;

  • пакет считается красным (red).

Входящие красные пакеты не проверяются и остаются красными.

В слепом (color-blind) режиме измеритель считает входящие пакеты зелеными и работа измерителя похожа на работу распознающего цвета измерителя для зеленых пакетов.

Отличительной особенностью алгоритма является то, что трафик в рамках заданного значения CIR маркируется зеленым напрямую без дополнительной проверки. Это является основным отличием от [RFC2698], где трафик маркируется зеленым после двух проверок (PIR и CIR). В любой из режимов color-blind или color-aware нужны 2 проверки соответствия, которые могут приводить к отбрасыванию пакета в корзине маркера PIR даже если он находится в рамках своего значения CIR (соответствующий профилю трафик). Кроме того, в режиме color-aware необходимость двух проверок может приводить к тому, что желтый трафик будет «истощать» входящие в рамках профиля зеленые пакеты.

Работа алгоритма проиллюстрирована на рисунке.

          +---------------------------------+
          |        Каждые T секунд          |
          | Tc(t+)=MIN(CBS, Tc(t-)+CIR*T)   |
          | Te(t+)=MIN(EBS, Te(t-)+EIR*T)   |
          +---------------------------------+

 Прибытие пакета
 размером B      /----------------\
---------------->|   color-blind  |
                 |       ИЛИ      |Да   +---------------+
                 |  green-пакет   |---->|  green-пакет  |
                 |        И       |     |Tc(t+)=Tc(t-)-B|
                 |    B <= Tc(t-) |     +---------------+
                 \----------------/
                         |
                         | Нет
                         v
                 /----------------\
                 |   color-blind  |
                 |       ИЛИ      |Да   +----------------+
                 |  НЕ red-пакет  |---->|  yellow-пакет  |
                 |        И       |     |Te(t+)=Te(t-)-B |
                 |    B <= Te(t-) |     +----------------+
                 \----------------/
                         |
                         | Нет
                         v
                 +---------------+
                 |   red-пакет   |
                 +---------------+

Рисунок 1. Алгоритм измерения и маркировки трафика.

На рисунке 1 X(t-) и X(t+) указывают значение параметра X до и после момента t.

4. Сценарий обслуживания

Описанный маркер можно применять для «окрашивания» потока пакетов IP в услугах, где зеленым, желтым и красным пакетам предоставляются убывающие гарантии (абсолютные или относительные). Например, служба может отбрасывать все красные пакеты, поскольку они выходят за пределы скорости обслуживания, пересылать желтые пакеты по возможности (best effort) и обеспечивать низкую вероятность потерь для зеленых. Маркировка может также применяться для измерения в службах L2 VPN, таких как доставка кадров Ethernet через сети IP.

5. Вопросы безопасности

Вопросы безопасности, связанные с этим документом, аналогичны рассмотренным в [RFC2697] и [RFC2698].

6. Литература

[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, «An Architecture for Differentiated Service», RFC 2475, December 1998.

[RFC2697] Heinanen, J. and R. Guerin, «A Single Rate Three Color Marker», RFC 2697, September 1999.

[RFC2698] Heinanen, J. and R. Guerin, «A Two Rate Three Color Marker», RFC 2698, September 1999.

[RFC3932] Alvestrand, H., «The IESG and RFC Editor Documents: Procedures», BCP 92, RFC 3932, October 2004.


Адреса авторов

Osama Aboul-Magd

Nortel Networks

3500 Carling Ave

Ottawa, ON K2H8E9

EMail: osama@nortel.com

Sameh Rabie

Nortel Networks

3500 Carling Ave

Ottawa, ON K2H8E9

EMail: rabie@nortel.com


Перевод на русский язык

Николай Малых

nmalykh@protokols.ru

Полное заявление авторских прав

Copyright (C) The Internet Society (2005).
К этому документу применимы права, лицензии и ограничения, указанные в BCP 78, и, за исключением указанного там, авторы сохраняют свои права.
Этот документ и содержащаяся в нем информация представлены «как есть» и автор, организация, которую он/она представляет или которая выступает спонсором (если таковой имеется), Internet Society и IETF отказываются от каких-либо гарантий (явных или подразумеваемых), включая (но не ограничиваясь) любые гарантии того, что использование представленной здесь информации не будет нарушать чьих-либо прав, и любые предполагаемые гарантии коммерческого использования или применимости для тех или иных задач.
Интеллектуальная собственность
IETF не принимает какой-либо позиции в отношении действительности или объема каких-либо прав интеллектуальной собственности (Intellectual Property Rights или IPR) или иных прав, которые, как может быть заявлено, относятся к реализации или использованию описанной в этом документе технологии, или степени, в которой любая лицензия, по которой права могут или не могут быть доступны, не заявляется также применение каких-либо усилий для определения таких прав. Сведения о процедурах IETF в отношении прав в документах RFC можно найти в BCP 78 и BCP 79.
Копии раскрытия IPR, предоставленные секретариату IETF, и любые гарантии доступности лицензий, а также результаты попыток получить общую лицензию или право на использование таких прав собственности разработчиками или пользователями этой спецификации, можно получить из сетевого репозитория IETF IPR по ссылке http://www.ietf.org/ipr.
IETF предлагает любой заинтересованной стороне обратить внимание на авторские права, патенты или использование патентов, а также иные права собственности, которые могут потребоваться для реализации этого стандарта. Информацию следует направлять в IETF по адресу ietf-ipr@ietf.org.

Подтверждение

Финансирование функций RFC Editor обеспечено Internet Society.


1Customer edge.

2Quality-of-service — качество обслуживания.

3Peak information rate.

4Peak burst size.

5Committed burst size — согласованный размер всплесков (пиков) трафика.

6Committed information rate.

7Excess information rate.

Запись опубликована в рубрике RFC. Добавьте в закладки постоянную ссылку.