RFC 3260 New Terminology and Clarifications for Diffserv

Network Working Group                                    D. Grossman
Request for Comments: 3260                            Motorola, Inc.
Updates: 2474, 2475, 2597                                 April 2002
Category: Informational

Новая терминология и разъяснения для Diffserv

New Terminology and Clarifications for Diffserv

PDF

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

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

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

Copyright (C) The Internet Society (2002). All Rights Reserved.

Аннотация

В этом документе собраны соглашения рабочей группы Diffserv, касающиеся новой и переработанной терминологии, а также обеспечивающие технические разъяснения. Задачей документа является обновление RFC 2474, RFC 2475 и RFC 2597. Предполагается, что при стандартизации RFC 2474 и RFC 2597, а также при обновлении RFC 2475 в новые документы будет включено содержимое данного документа, а сам он после этого утратит силу.

1. Введение

В процессе работы группы Diffserv стало ясно, что в некоторых случаях требуется ввести или уточнить термины и определения для проектов стандартов Diffserv. Кроме того, потребовались некоторые технические разъяснения. Этот документ был создан для публикации достигнутых группой соглашений по этим вопросам и не является попыткой пересмотра базовых RFC или повторного запуска процессов стандартизации. Документ частично обновляет RFC 2474, RFC 2475 и RFC 2597. RFC 2598 был отменен в RFC 3246 и достигнутые группой соглашения включены в новый документ.

2. Терминология, связанная с SLA

Архитектура Diffserv [2] использует термин SLA¹ для обозначения сервисных контрактов, которые задают условия пересылки пакетов пользователя. SLA может включать правила классификации трафика, которые (по крайней мере, частично) задают правила «кондиционирования» трафика (TCA²). TCA представляет собой соглашение, задающее правила классификации и соответствующие профили трафика, а также применимые правила метрики, маркировки, отбрасывания и/или «формования» (shaping) трафика.

В процессе работы группы Diffserv (а также в группе Policy [6]) стало понятно, что заключение «соглашения» означает рассмотрение такие аспектов, как цены, договоренности и иные вопросы бизнеса, а также некоторых сугубо технических аспектов. В таких соглашениях могут присутствовать другие технические параметры (например, доступность услуг), которые не являются предметом рассмотрения группы Diffserv. В результате было принято решение, что термины SLA и TCA будут использоваться для представления широкого контекста, а для описания элементов обслуживания и кондиционирования трафика, связанных с Diffserv, будет использоваться новая терминология.

• Спецификация уровня обслуживания (SLS³) представляет собой набор параметров и их значений, которые совместно определяют сервис, предлагаемый для потока трафика доменом DS⁴.
• Спецификация кондиционирования трафика (TCS⁵) представляет собой набор параметров и их значений, которые совместно задают набор правил классификации и профиль трафика. TCS является неотъемлемой частью SLS.

Отметим, что определение потока трафика не изменилось по сравнению с RFC 2475. Поток трафика может представлять собой отдельный микропоток или группу микропотоков (в домене DS отправителя или получателя), а также может быть BA⁶. Таким образом, SLS можно применять в домене DS отправителя или получателя для одного или группы микропотоков, а также для BA в любом домене DS.

Отметим также, что определение «политики предоставления услуг» (SPP⁷) не изменилось по сравнению с RFC 2475, где SPP были определены, как «политика, определяющая настройку кондиционеров трафика на граничных узлах DS о отображения потоков трафика на агрегаты поведения DS для обеспечения спектра услуг». Согласно определению, данному в RFC 3198 [6], политика представляет собой «набор правил для администрирования, управления и контроля доступа к сетевым ресурсам». Следовательно, связи между SLS и SPP заключается в том, что последняя является (отчасти) набором правил, выражающий параметры и диапазоны значений, которые могут использоваться первой.

Отметим, что это определение задает более жесткие ограничения по сравнению с определением в RFC 3198.

3. Использование групп PHB

RFC 2475 определяет группу PHB⁸ следующим образом:

«Набор из одного или множества PHB, которые могут выполняться только совместно вследствие общих ограничений, применяемых ко всем PHB данной группы (например, управления очередями). Группа PHB является базовым элементом архитектуры, позволяющим совместно реализовать несколько связанных режимов (например, четыре профиля отбрасывания пакетов). Одиночный PHB является частным случаем группы PHB».

Одна из «стандартных» групп PHB определена в RFC 2597 [3], Assured Forwarding PHB Group. AF⁹ представляет собой вариант режима пересылки с некоторым выделенным уровнем ресурсов очередей и тремя уровнями предпочтения при отбрасывании. Группа AF PHB Group включает три PHB и использует три кода DSCP¹⁰.

RFC 2597 определяет 12 кодов DSCP, соответствующих четырем независимым классам AF – AF1x, AF2x, AF3x и AF4x (где x может принимать значения 1, 2 или 3 для задания предпочтений при отбрасывании). Каждый класс AF имеет свой экземпляр группы AF PHB.

Может возникать путаница, связанная с тем, что в RFC 2597 все 4 класса AF с тремя уровнями предпочтения в каждом отнесены к одной группе PHB. Однако, поскольку каждый класс работает независимо от других (и, следовательно, не возникает общего ограничения для классов AF, как это наблюдается для уровней предпочтения при отбрасывании в одном классе AF), такое использование не согласуется с RFC 2475. Несогласованность обусловлена историческими причинами и будет устранена в новом варианте спецификации AF. Сейчас следует просто принять, что AF является типом группы PHB, а каждый класс AF является экземпляром типа AF.

Авторам новых спецификаций PHB следует быть аккуратными и придерживаться определения группы PHB в RFC 2475. RFC 2475 не запрещает новым спецификациям PHB выделять достаточное число кодов DSCP для представления множества независимых экземпляров группы PHB. Однако такой набор кодов DSCP не должен указывать на одну группу PHB.

4. Определение поля DS

Diffserv использует шесть битов в заголовке IPV4 или IPV6 для передачи кодов DSCP, которые выбирают PHB. В RFC 2474 была предпринята попытка переименовать октет TOS¹¹ заголовка IPV4 и октет Traffic Class заголовка IPV6 в поле DS. Это поле имеет шесть битов кода DS и два неиспользуемых бита.

Отмечено, что эта попытка привела к несогласованности и неоднозначности. В частности неиспользуемые биты (CU¹²) поля DS не были выделены для Diffserv и после публикации RFC 2474 эти биты были выделены для явной индикации насыщения (ECN¹³), определенной в RFC 3168 [4]. В настоящем документе в зависимости от контекста DSCP обозначает коды, которые служат для выбора PHB или часть поля DS, которая содержит эти коды.

Данный текст также не согласуется с BCP 37 (IANA Allocation Guidelines for Values in the Internet Protocol and Related Headers) [5]. Поле типа обслуживания IPV4 (TOS) и поле класса трафика IPV6 были заменены 6-битовым полем DS и 2-битовым полем CU. Агентство IANA выделяет значения поля DS в соответствии с разделом «Согласование с IANA» в RFC 2474, как описано в разделе 8 данного документа.

По согласованному мнению рабочей группы DiffServ говорит, что BCP 37 корректно подтверждает структуру прежних поле TOS и класса трафика.

Следовательно, для использования в будущих документах, включая следующее обновление RFC 2474, нужно применять приведенные ниже определения:

• поле дифференцированного обслуживания (DS) занимает 6 старших битов (бывшего) октета IPV4 TOS и (бывшего) октета IPV6 Traffic Class;

• код дифференцированного обслуживания (DSCP) представляет собой значение, кодируемое в поле DS, и каждый узел DS должен использовать это значение для выбора PHB, применяемого для каждого пересылаемого пакета.

Два младших бита октетов IPV4 TOS и IPV6 Traffic Class не используются Diffserv.

При обновлении RFC 2474 следует обратить внимание на замену CU на ECN со ссылкой на RFC 3168 (или его новый вариант).

Следует также обновить упоминание BCP 37.

5. Упорядоченные агрегаты и классы планирования PHB

Работа по поддержке Diffserv в маршрутизаторах MPLS (LSR¹⁴) привела к реализации концепции, которая была нужна в Diffserv для получения представления набора BA с общими ограничениями по сохранению порядка. Это применяется к агрегатам поведения AF, поскольку узел DS может не менять порядок пакетов микропотока, если они относятся к одному классу AF. Это будет, к примеру, предотвращать в маршрутизаторах MPLS LSR, являющихся узлами DS, дискриминирование пакетов агрегата поведения AF на основе предпочтений при отбрасывании и пересылки пакетов одного класса AF с разными предпочтениями по отбрасыванию через разные LSP. Определены новые термины.

Класс планирования PHB (PHB Scheduling Class) – группа PHB, для которой общее ограничение состоит в том, что порядок должен сохраняться по крайней мере для пакетов одного микропотока.

Упорядоченный агрегат (OA¹⁵) – набор BA с общими ограничениями по сохранению порядка. Набор PHB, которые применяются к этому набору BA, определеяет класс планирования PHB.

6. Неизвестные/некорректно отображенные DSCP

Несколько разработчиков отметили неоднозначности и конфликты в Diffserv RFC, касающиеся поведения узлов DS при получении пакетов с непонятным значением DSCP.

В RFC 2475 указано:

«Входные узлы должны кондиционировать весь остальной входящий трафик для обеспечения приемлемости кодов DS; пакеты с неприемлемыми кодами должны отбрасываться или значение кода DS должно меняться на приемлемое до пересылки пакета. Например, входной узел, получая трафик от домена, для которого нет соглашения об улучшенном обслуживании, может сбрасывать код DS в значение, принятое для Default PHB [DSFIELD].»

С другой стороны, в 2474 указано:

«Пакеты, полученные с неизвестным кодом, следует пересылать, как будто они помечены для принятого по умолчанию поведения (см. раздел 4), не меняя в них кода.»

RFC 2474 имеет дело в основном с внутренними узлами DS. Однако такой режим может также применяться на внутренних узлах DS после кондиционирования трафика, требуемого RFC 2475 (в этом случае нераспознаваемые DSCP могут появляться только в следствие некорректной конфигурации). Если приходит пакет со значением DSCP, которое явно не отображается на определенный PHB, это следует трактовать, как пакет, маркированный для принятой по умолчанию обработки. Альтернативой является выделение другого PHB, что может приводить к ошибочному выделению предоставляемых ресурсов или отбрасыванию пакета. Других вариантов в схеме RFC 2474 не возникает. Ни один из этих вариантов не представляется подходящим. Рассматривался вопрос PHB, получающего обслуживание хуже принятого по умолчанию – это может оказаться лучшим вариантом.

RFC 2475 явно посвящен входным узлам DS (точнее, функциям кондиционирования трафика на входных узлах). Это другой контекст, в котором употребление термина «следует» в RFC 2474 обеспечивает гибкость, для которой группа предназначена. Столь жесткое прочтение нежелательно.

Следовательно, утверждение в RFC 2474 разъясняется, чтобы показать, что оно не предназначено для применения к функции кондиционирования на входном узле DS и сослаться для этого случая на RFC 2475.

Аналогичный вопрос возникает при декларировании себя в качестве первой инкарнации EF¹⁶. В RFC 2598 указано:

«Для защиты себя от атак на отказ служб (DoS¹⁷) периметр домена DS должен строго проверять для всех пакетов с маркировкой EF соответствие скорости согласованному со смежным восходящим доменом значению (скорость должна быть не больше значения, заданного для EF PHB). Пакеты, вызывающие превышение согласованной скорости должны отбрасываться. Если смежные домены не согласовали скорость EF, нисходящий домен должен использовать нулевое значение скорости (т. е., отбрасывать все пакеты с маркировкой EF).»

Проблема возникает при некорректной конфигурации или в связи с проблемами маршрутизации. Выходной узел DS на краю домена DS пересылает пакеты входному узлу DS на краю другого домена DS. Эти пакеты маркируются значением DSCP, которое в понимании выходного узла отображается на EF, но входной узел не распознает. Утверждение RFC 2475 представляется применимым для этого случая. В RFC 3246 [7] содержатся разъяснения этого вопроса.

7. Несовместимость с RFC 1349

По крайней мере один разработчик обратил внимание на несоответствие поля DS, определенного в RFC 2474, использованию битов TOS, описанному в RFC 1349. Применение RFC 1349 было вызвано взаимодействием с расширениями OSPF из RFC 1247. Оно не получило широкого распространения и было исключено из процесса стандартизации при публикации STD 54, RFC 2328. Обработка битов TOS описана, как требования в RFC 1812 [8], RFC 1122 [9] и RFC 1123 [10]. В RFC 2474 указано:

«Здесь не предпринимается попыток обеспечить совместимость с DTR или битами TOS октета IPv4 TOS, определенного в [RFC791].»

Кроме того, RFC 2474 отменяет действие RFC 1349 по решению IESG. Для полноты при обновлении RFC 2474 приведенный выше фрагмент следует выразить иначе:

«Здесь не предпринимается попыток обеспечить совместимость с DTR/MBZ или битами TOS октета IPv4 TOS, как определено в [RFC791] и [RFC1349]. Это означает, что обработка битов TOS, описанная в [RFC1812], [RFC1122] и [RFC1123] также отменяется этим документом. См. также [RFC2780].»

8. Согласование с IANA

В агентство IANA передан запрос на разъяснение RFC 2474 в части регистрации значений DSCP, предназначенных для экспериментов и локального применения. При пересмотре RFC 2474 в раздел 6 следует добавить приведенный ниже текст:

«У агентства IANA запрашивается поддержка реестра рекомендуемых значений DSCP, распределяемых путем стандартизации. Значения EXP/LU¹⁸ не регистрируются.»

9. Список ожидаемых изменений

Ниже приведен список RFC (проекты стандартов и информационные), которые следует обновить с учетом приведенных в этом документе соображений. Изменения следует внести, когда RFC с проектами стандартов будут переводиться в статус предварительных стандартов (Draft Standard) или при ином обновлении, если документы сохранят статус предложенного стандарта (Proposed). Предполагается, что RFC 2475 будет обновлен одновременно с RFC 2474. Внесение изменений приведет к утрате силы настоящим документом¹⁹.

RFC 2474 – пересмотр определения поля DS. Разъяснение того, что предложенная пересылка по умолчанию для нераспознанных значений DSCP не применима к входному кондиционированию на входных узлах DS. Разъяснение влияния на RFC 1349 и RFC 1812. Разъяснение того, что IANA регистрирует только рекомендуемые значения DSCP, распределяемые путем стандартизации.

RFC 2475 – пересмотр определения поля DS. Добавление определений SLS и TCS. Обновление текста по использованию SLS и TCS. Добавление определений класса планирования PHB и упорядоченного агрегата.

RFC 2497 – пересмотр с учетом того, что классы AF являются экземплярами группы AF PHB, а не представляют коллективно группу PHB.

Кроме того, в RFC 3246 [7] была добавлена ссылка на RFC 2475 (раздел «Вопросы безопасности») для случая, когда выходной узел DS получает нераспознанное значение DSCP, которое отображается на EF во входном узле DS.

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

Вопросы безопасности не рассматриваются в RFC 2475.

Благодарности

В этом документе используются результаты рабочей группы Diffserv. Множество людей приняло участие в дискуссиях рассылки Diffserv и на встречах. Руководителями группы Diffserv были Brian Carpenter и Kathie Nichols. Среди активных участников обсуждения были Lloyd Wood, Juha Heinanen, Grenville Armitage, Scott Brim, Sharam Davari, David Black, Gerard Gastaud, Joel Halpern, John Schnizlein, Francois Le Faucheur и Fred Baker. Mike Ayers, Mike Heard и Andrea Westerinen внесли существенные редакторские правки.

Нормативные документы

[1] Nichols, K., Blake, S., Baker, F. and D. Black, “Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers”, RFC 2474, December 1998.

[2] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, “An Architecture for Differentiated Services”, RFC 2475, December 1998.

[3] Heinanen, J., Baker, F., Weiss, W. and J. Wrocklawski, “Assured Forwarding PHB Group”, RFC 2597, June 1999.

[4] Ramakrishnan, K., Floyd, S. and D. Black “The Addition of Explicit Congestion Notification (ECN) to IP”, RFC 3168, September 2001.

[5] Bradner, S. and V. Paxon, “IANA Allocation Guidelines for Values in the Internet Protocol and Related Headers”, BCP 37, RFC2780, March 2000.

[6] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J. and S. Waldbusser, “Terminology for Policy-Based Management”, RFC 3198, November 2001.

[7] Davie, B., Charny, A., Baker, F., Bennett, J.C.R., Benson, K., Le Boudec, J., Chiu, A., Courtney, W., Cavari, S., Firoiu, V., Kalmanek, C., Ramakrishnam, K. and D. Stiliadis, “An Expedited Forwarding PHB (Per-Hop Behavior)”, RFC 3246, March 2002.

[8] Baker, F., “Requirements for IP Version 4 Routers”, RFC 1812, June 1995.

[9] Braden, R., “Requirements for Internet Hosts — Communications Layers”, STD 3, RFC 1122, October 1989.

[10] Braden, R., “Requirements for Internet Hosts — Application and Support”, STD 3, RFC 1123, October 1989.

Адрес автора

Dan Grossman

Motorola, Inc.

20 Cabot Blvd.

Mansfield, MA 02048

EMail: dan@dma.isg.mot.com

---

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

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

nmalykh@protokols.ru

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

Copyright (C) The Internet Society (2002). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an “AS IS” basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.

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

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