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 скоростям и эффективной обработкой трафика по профилю
Статус документа
Документ содержит информацию, адресованную сообществу 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
Перевод на русский язык
Николай Малых
Полное заявление авторских прав
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.