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

image_print
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@protocols.ru

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

Copyright (C) The Internet Society (2005).

This document is subject to the rights, licenses and restrictions contained in BCP 78 and at www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an «AS IS» basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Интеллектуальная собственность

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at 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.

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