RFC 2474 · декабрь 1998
Определение поля дифференцированных услуг (поля DS) в заголовках IPv4 и IPv6
Авторы: K. Nichols, S. Blake, F. Baker, D. Black. Категория: процесс стандартизации. Декабрь 1998. Заменяет RFC 1455 и RFC 1349.
Статус документа
Этот документ определяет протокол процесса стандартизации Интернета для интернет-сообщества и приглашает к обсуждению и предложениям по улучшению. Состояние стандартизации и статус протокола приведены в текущем издании «Официальных стандартов протоколов Интернета» (STD 1). Распространение документа не ограничено.
Уведомление об авторских правах
Copyright (C) The Internet Society (1998). Все права защищены.
Аннотация
Расширения интернет-протокола для дифференцированных услуг предназначены для масштабируемого различения обслуживания в Интернете без необходимости хранить состояние каждого потока и передавать сигнальную информацию на каждом узле. Разнообразные услуги можно построить из небольшого, чётко определённого набора компонентов, развёртываемых в сетевых узлах. Услуги могут быть как сквозными, так и внутридоменными; они включают услуги, удовлетворяющие количественным требованиям к производительности, например пиковой пропускной способности, и услуги, основанные на относительных показателях, например различении «классов». Услуги можно построить сочетанием следующих действий:
— установки битов в поле заголовка IP на границах сети: границах автономных систем, внутренних административных границах или на хостах; — использования этих битов узлами внутри сети для определения порядка пересылки пакетов; — обработки помеченных пакетов на границах сети в соответствии с требованиями или правилами каждой услуги.
Требования или правила каждой услуги должны задаваться механизмами административной политики, которые выходят за рамки документа. Сетевой узел, соответствующий архитектуре дифференцированных услуг, включает классификатор, выбирающий пакеты по значению поля DS, а также механизмы управления буферами и планирования пакетов, способные обеспечить конкретный способ пересылки, указанный значением поля DS. Устанавливать поле DS и обрабатывать временные характеристики помеченных пакетов необходимо только на границах сети; сложность этих операций может различаться.
Настоящий документ определяет поле заголовка IP, называемое полем DS — differentiated services. Для IPv4 определяется структура октета TOS; для IPv6 — октета Traffic Class. Кроме того, определяется базовый набор способов пересылки пакетов, или типов поведения на отдельном узле (per-hop behavior, PHB).
Для более полного понимания дифференцированных услуг см. также архитектуру дифференцированных услуг [ARCH].
1. Введение
Дифференцированные услуги предназначены для создания основы и компонентов, позволяющих развернуть масштабируемое различение обслуживания в Интернете. Подход к дифференцированным услугам направлен на ускорение внедрения путём разделения архитектуры на два основных компонента: один достаточно хорошо изучен, другой только начинают понимать. При этом мы руководствуемся первоначальным устройством Интернета, в котором было принято решение разделить функции пересылки и маршрутизации. Пересылка пакетов — относительно простая задача, которую необходимо выполнять для каждого пакета как можно быстрее. При пересылке по заголовку пакета находится запись в таблице маршрутизации, определяющая выходной интерфейс пакета. Маршрутизация устанавливает записи в этой таблице и может учитывать разнообразные транзитные и другие политики, а также отслеживать отказы маршрутов. Таблицы маршрутизации поддерживаются фоновым процессом относительно задачи пересылки. Кроме того, маршрутизация — более сложная задача, которая продолжала развиваться на протяжении последних 20 лет.
Аналогично архитектура дифференцированных услуг содержит два основных компонента. Первый — достаточно хорошо изученное поведение на пути пересылки; второй — более сложный и всё ещё формирующийся фоновый компонент политики и распределения, который настраивает параметры, используемые на пути пересылки. Поведение на пути пересылки включает дифференцированную обработку отдельного пакета, реализуемую дисциплинами обслуживания очередей и/или управления ими. Эти типы поведения на узле полезны и необходимы сетевым узлам для дифференцированной обработки пакетов независимо от способа построения сквозных или внутридоменных услуг. Мы сосредоточены на общей семантике поведения, а не на конкретных механизмах его реализации, поскольку поведение будет изменяться медленнее механизмов.
Типы поведения на узле и механизмы их выбора для каждого пакета уже сегодня могут быть развёрнуты в сетевых узлах; именно этот аспект архитектуры дифференцированных услуг рассматривается первым. Кроме того, для обеспечения требований к «специальной» обработке на пути пересылки может потребоваться контроль, ограничение и сглаживание соответствующего сетевого трафика. Механизмы такой обработки трафика тоже достаточно хорошо изучены. Их широкое внедрение важно для создания услуг, хотя практическое применение при их построении может со временем меняться.
Гораздо хуже изучено, как настраивать сетевые элементы: какие пакеты должны получать специальную обработку и какие правила применять к использованию ресурсов. Тем не менее полезные дифференцированные услуги можно внедрить в сетях с помощью простых политик и статических конфигураций. Как описано в [ARCH], существует ряд способов комбинировать типы поведения на узле и средства обработки трафика для создания услуг. При этом приобретается дополнительный опыт, который позволит выработать более сложные политики и способы распределения ресурсов. По мере развития этого компонента архитектуры основные типы поведения на пути пересылки могут оставаться прежними. Опыт создания таких услуг будет накапливаться ещё некоторое время, поэтому стандартизировать этот процесс преждевременно. Кроме того, многие детали построения услуг регулируются юридическими соглашениями между различными хозяйствующими субъектами и выходят далеко за рамки деятельности IETF.
Документ посвящён компоненту пути пересылки. При пересылке пакета дифференцированные услуги реализуются сопоставлением кодового значения, содержащегося в поле заголовка IP-пакета, с конкретным способом пересылки, или поведением на узле (PHB), в каждом сетевом узле на его пути. Кодовые значения можно выбирать из набора обязательных значений, определённых далее в документе, набора рекомендуемых значений, которые будут определены в будущих документах, либо они могут иметь исключительно локальное значение. Предполагается, что PHB реализуются с помощью различных дисциплин обслуживания очередей и/или управления ими в очереди выходного интерфейса сетевого узла, например взвешенного циклического обслуживания очередей (WRR) или управления очередью с предпочтительным отбрасыванием.
Маркировка выполняется средствами обработки трафика на границах сети, включая крайние точки сети — маршрутизатор первого перехода или хост-источник — и административные границы. Средства обработки трафика могут включать базовые функции маркировки, измерения, контроля соответствия и сглаживания; эти механизмы описаны в [ARCH]. Услуги реализуются сочетанием конкретных механизмов классификации пакетов и обработки трафика на границах с последовательностью типов поведения на узлах вдоль пути прохождения трафика. Одна из целей архитектуры дифференцированных услуг — определить эти компоненты так, чтобы в будущем можно было расширять как число и типы компонентов, так и создаваемые из них услуги.
Термины документа определены в разделе 2. Поле дифференцированных услуг, или поле DS, определяется в разделе 3. В разделе 4 рассматривается необходимость частичной обратной совместимости с текущим использованием поля IPv4 Precedence. В качестве решения вводятся кодовые значения селектора класса и соответствующие селектору класса типы поведения PHB. Раздел 5 содержит рекомендации по стандартизации поведения на узле, раздел 6 — рекомендации по распределению кодовых значений, раздел 7 — вопросы безопасности.
Этот документ кратко описывает поле DS и его применение. Он предназначен для чтения вместе с архитектурой дифференцированных услуг [ARCH].
Ключевые слова MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY и OPTIONAL следует толковать согласно [RFC2119].
2. Термины, используемые в документе
Агрегат поведения (Behavior Aggregate): совокупность пакетов с одинаковым кодовым значением, пересекающих канал в определённом направлении. В документе термины «агрегат» и «агрегат поведения» взаимозаменяемы.
Классификатор (Classifier): элемент, выбирающий пакеты по содержимому их заголовков согласно заданным правилам.
Кодовое значение селектора класса (Class Selector Codepoint): любое из восьми кодовых значений вида xxx000, где x может быть равно 0 или 1. Они рассматриваются в разделе 4.2.2.
PHB, соответствующее селектору класса (Class Selector Compliant PHB): поведение на узле, удовлетворяющее требованиям к PHB селектора класса из раздела 4.2.2.2.
Кодовое значение (Codepoint): конкретное значение части DSCP поля DS. Рекомендуемые кодовые значения СЛЕДУЕТ (SHOULD) сопоставлять с определёнными стандартизованными PHB. Несколько кодовых значений МОГУТ (MAY) соответствовать одному PHB.
Граница дифференцированных услуг (Differentiated Services Boundary): граница домена DS, на которой обычно развёртываются классификаторы и средства обработки трафика. Её можно разделить на входные и выходные узлы; для заданного направления трафика входной узел расположен ниже по потоку относительно граничного канала, а выходной — выше. Такая граница обычно находится на входе в первый маршрутизатор или сетевой узел с поддержкой дифференцированных услуг на пути пакетов хоста либо на выходе из последнего такого маршрутизатора или узла перед хостом. Иногда это называется границей на листовом маршрутизаторе. Граница дифференцированных услуг может находиться на самом хосте согласно локальной политике. Также называется границей DS.
Соответствующий дифференцированным услугам (Differentiated Services-Compliant): отвечающий требованиям настоящего документа. Также используется выражение «соответствующий DS».
Домен дифференцированных услуг (Differentiated Services Domain): непрерывная часть Интернета, в пределах которой согласованно применяется единый набор политик дифференцированных услуг. Домен может представлять разные административные домены или автономные системы, области доверия, сетевые технологии — например, ячейки или кадры, — хосты и маршрутизаторы и т. д. Также называется доменом DS.
Поле дифференцированных услуг (Differentiated Services Field): октет TOS заголовка IPv4 или октет Traffic Class заголовка IPv6, интерпретируемый согласно определению настоящего документа. Также называется полем DS.
Механизм (Mechanism): реализация одного или нескольких типов поведения на узле согласно определённому алгоритму.
Микропоток (Microflow): отдельный экземпляр потока пакетов между приложениями, идентифицируемый адресами источника и назначения, идентификатором протокола и, где применимо, портами источника и назначения.
Поведение на узле (Per-hop Behavior, PHB): описание наблюдаемой извне обработки при пересылке, которую соответствующий дифференцированным услугам узел применяет к агрегату поведения. Описание PHB СЛЕДУЕТ (SHOULD) делать достаточно подробным для построения предсказуемых услуг, как описано в [ARCH].
Группа типов поведения на узле (Per-hop Behavior Group): набор одного или нескольких PHB, которые имеет смысл определять и реализовывать только одновременно из-за общего ограничения для всех PHB набора, например политики обслуживания очереди или управления ею. Также называется группой PHB.
Обработка трафика (Traffic Conditioning): функции управления, применимые к агрегату поведения, потоку приложения или другому практически значимому подмножеству трафика, например обновлениям маршрутов. Они МОГУТ (MAY) включать измерение, контроль соответствия, сглаживание и маркировку пакетов. Обработка трафика применяется для соблюдения соглашений между доменами и подготовки трафика к дифференцированному обслуживанию внутри домена: пакеты помечаются соответствующим кодовым значением в поле DS, а временные характеристики агрегата при необходимости отслеживаются и изменяются. См. [ARCH].
Средство обработки трафика (Traffic Conditioner): элемент, выполняющий функции обработки трафика; он МОЖЕТ (MAY) содержать средства измерения, контроля соответствия, сглаживания и маркировки. Обычно эти средства развёртываются на граничных узлах DS, а не на внутренних узлах домена DS.
Услуга (Service): описание общей обработки трафика клиента или его части в определённом домене, наборе взаимосвязанных доменов DS либо на всём пути от источника до получателя. Описания услуг регулируются административной политикой. Услуги строятся путём обработки трафика с созданием агрегатов поведения, к которым на каждом узле домена DS применяется известное PHB. Одно поведение на узле в сочетании с различными средствами обработки трафика может обеспечивать несколько услуг.
Таким образом, классификаторы и средства обработки трафика определяют, какие пакеты включать в агрегаты поведения. В домене DS агрегаты получают дифференцированную обработку, а средства обработки трафика МОГУТ (MAY) изменять их временные характеристики в соответствии с определёнными требованиями. Поле DS пакета обозначает его агрегат поведения и затем используется для определения обработки при пересылке. Во все сетевые узлы домена DS СЛЕДУЕТ (SHOULD) включать классификатор агрегатов поведения, способный выбирать PHB, например дисциплину дифференцированного обслуживания выходной очереди, на основе кодового значения поля DS. Классификаторы и средства обработки трафика на границах DS настраиваются согласно некоторой спецификации услуги; это вопрос административной политики и выходит за рамки документа.
Дополнительные определения дифференцированных услуг приведены в [ARCH].
3. Определение поля дифференцированных услуг
Определяется заменяющее поле заголовка, называемое полем DS. Оно предназначено для замены существующих определений октета TOS в IPv4 [RFC791] и октета Traffic Class в IPv6 [IPv6].
Шесть битов поля DS используются как кодовое значение (DSCP) для выбора PHB, применяемого к пакету на каждом узле. Двухбитовое поле CU, не используемое в настоящее время, зарезервировано; его определение и интерпретация выходят за рамки документа. Соответствующие дифференцированным услугам узлы игнорируют значение битов CU при определении поведения на узле для принятого пакета.
Структура поля DS:
0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | DSCP | CU | +---+---+---+---+---+---+---+---+
DSCP — кодовое значение дифференцированных услуг; CU — в настоящее время не используется.
В используемой здесь записи значения DSCP xxxxxx, где каждый x может быть равен 0 или 1, крайний левый бит обозначает бит 0 поля DS, как показано выше, а крайний правый — бит 5.
Разработчикам следует учитывать, что поле DSCP имеет ширину шесть битов. Узлы, соответствующие DS, ОБЯЗАНЫ (MUST) выбирать PHB путём сопоставления со всем шестибитовым полем DSCP, например используя его значение как индекс таблицы для выбора конкретного механизма обработки пакетов, реализованного в устройстве. При выборе PHB значение поля CU ОБЯЗАТЕЛЬНО (MUST) игнорируется. Поле DSCP определено как неструктурированное, чтобы облегчить определение будущих типов поведения на узле.
За некоторыми указанными ниже исключениями, сопоставление кодовых значений с PHB ОБЯЗАТЕЛЬНО (MUST) должно быть настраиваемым. Узел, соответствующий DS, ОБЯЗАН (MUST) поддерживать логический эквивалент настраиваемой таблицы соответствий между кодовыми значениями и PHB. Спецификации PHB ОБЯЗАНЫ (MUST) включать рекомендуемое кодовое значение по умолчанию; для кодовых значений в стандартном пространстве оно ОБЯЗАНО (MUST) быть уникальным (см. раздел 6). Реализациям следует поддерживать рекомендуемые соответствия в конфигурации по умолчанию. Операторы могут выбрать для PHB другие кодовые значения — в дополнение к рекомендуемому либо вместо него. При таком выборе на административных границах может потребоваться повторная маркировка полей DS, даже если по обе стороны границы реализованы одинаковые PHB.
Дополнительное обсуждение повторной маркировки приведено в [ARCH]. Исключения из общего требования настраиваемости относятся к кодовым значениям xxx000 и описаны в разделах 4.2.2 и 4.3.
Пакеты с нераспознанным кодовым значением СЛЕДУЕТ (SHOULD) пересылать так, как если бы они были помечены для поведения по умолчанию (см. раздел 4), и их кодовые значения не следует изменять. Такие пакеты НЕ ДОЛЖНЫ (MUST NOT) приводить к сбою сетевого узла.
Показанная выше структура поля DS несовместима с существующим определением октета TOS IPv4 в [RFC791]. Предполагается, что домены DS защищают себя, развёртывая граничные узлы с повторной маркировкой, как и сети, использующие обозначения Precedence из RFC 791. Надлежащему порядку эксплуатации СЛЕДУЕТ (SHOULD) соответствовать [RFC791], где сказано: «Если фактическое использование этих обозначений приоритета важно для определённой сети, эта сеть сама отвечает за контроль доступа к обозначениям приоритета и их использования». В любом случае разумно проверять значение поля DS на границах DS, поскольку узел выше по потоку может легко установить в нём произвольное значение. Домены DS, не изолированные надлежащим образом настроенными граничными узлами, могут предоставлять непредсказуемое обслуживание.
Узлы МОГУТ (MAY) при необходимости переписывать поле DS для предоставления требуемой локальной или сквозной услуги. Спецификации преобразования поля DS на границах DS являются предметом соглашений об уровне услуг между поставщиками и пользователями и выходят за рамки документа. Стандартизованные PHB позволяют поставщикам строить услуги из известного набора способов пересылки пакетов, которые, предположительно, имеются в оборудовании многих производителей.
4. Исторические определения кодовых значений и требования к PHB
Как описано в этом разделе, поле DS будет иметь ограниченную обратную совместимость с существующей практикой. Она обеспечивается двумя способами. Во-первых, уже широко используются некоторые типы поведения на узле, например удовлетворяющие требованиям к организации очередей IPv4 Precedence из [RFC1812]; желательно сохранить их использование в соответствующих DS узлах. Кроме того, некоторые кодовые значения соответствуют историческому использованию поля IP Precedence. Они резервируются для сопоставления с PHB, удовлетворяющими общим требованиям раздела 4.2.2.2, хотя соответствующие им конкретные PHB дифференцированных услуг МОГУТ (MAY) иметь дополнительные спецификации.
Сохранять обратную совместимость с битами DTR или TOS октета TOS IPv4, определёнными в [RFC791], не предполагается.
4.1. PHB по умолчанию
В узле, соответствующем DS, ОБЯЗАТЕЛЬНО (MUST) должно быть доступно PHB «по умолчанию». Это обычное поведение пересылки по принципу наилучших усилий (best effort), доступное в существующих маршрутизаторах и стандартизованное в [RFC1812]. При отсутствии других соглашений предполагается, что пакеты принадлежат этому агрегату. Такие пакеты МОГУТ (MAY) отправляться в сеть без соблюдения каких-либо особых правил; сеть доставит как можно больше этих пакетов как можно быстрее с учётом других ограничений политики использования ресурсов. Разумной реализацией PHB была бы дисциплина организации очередей, отправляющая пакеты этого агрегата, когда выходной канал не требуется для обслуживания другого PHB. Разумная политика построения услуг обеспечивала бы отсутствие «голодания» этого агрегата. Это можно обеспечить механизмом на каждом узле, резервирующим минимальные ресурсы, например буферы и пропускную способность, для агрегатов с поведением по умолчанию. Так отправители, не поддерживающие дифференцированные услуги, смогут продолжать пользоваться сетью прежним образом. Влияние внедрения дифференцированных услуг в домене на ожидания клиентов и взаимодействующих с ним сетей — сложный вопрос, связанный с решениями домена о политике и выходящий за рамки документа. РЕКОМЕНДУЕМОЕ (RECOMMENDED) кодовое значение для PHB по умолчанию — битовый шаблон 000000; значение 000000 ОБЯЗАТЕЛЬНО (MUST) сопоставляется с PHB, отвечающим этим требованиям. Выбранное кодовое значение совместимо с существующей практикой [RFC791]. Если кодовому значению не сопоставлено стандартизованное или локальное PHB, его СЛЕДУЕТ (SHOULD) сопоставить с PHB по умолчанию.
Пакет, первоначально помеченный для поведения по умолчанию, МОЖЕТ (MAY) быть перемаркирован другим кодовым значением при пересечении границы домена DS, чтобы внутри этого домена он пересылался с использованием другого PHB, возможно, на условиях согласованного соглашения между взаимодействующими доменами.
4.2. Использование поля IP Precedence в прошлом и будущем
Желательно сохранить определённую обратную совместимость с нынешним использованием поля IP Precedence — битов 0–2 октета IPv4 TOS. Существуют маршрутизаторы, использующие поле IP Precedence для выбора различных способов пересылки на узле, аналогично предлагаемому здесь использованию поля DSCP. Поэтому простой прототип архитектуры дифференцированных услуг можно быстро развернуть, соответствующим образом настроив эти маршрутизаторы. Кроме того, существующие IP-системы знают расположение поля IP Precedence. Если при внедрении оборудования, соответствующего DS, эти биты используются аналогичным образом, значительные сбои на ранних этапах внедрения маловероятны. Иными словами, строгое соответствие DS не обязательно должно быть всеобщим даже внутри сети одного поставщика услуг, если биты 0–2 поля DSCP используются сходным образом или охватывают существующие способы использования поля IP Precedence.
4.2.1. Краткая история и развитие IP Precedence
Поле IP Precedence в некотором смысле предшествовало полю DS. IP Precedence и его поле впервые были определены в [RFC791]. Значения трёхбитового поля IP Precedence назначались для различных применений, включая сетевой управляющий трафик, трафик маршрутизации и различные уровни привилегий. Наименьший уровень обозначался как «обычный трафик». В [RFC791] понятие Precedence было определено широко: «независимая мера важности этой дейтаграммы». Не предполагалось, что все значения поля IP Precedence сохраняют смысл при пересечении границ; например: «Обозначение приоритета Network Control предназначено только для использования внутри сети. Фактическое использование этого обозначения и контроль над ним определяются каждой сетью» [RFC791].
Хотя ранние BBN IMP реализовывали функцию Precedence, ранние коммерческие маршрутизаторы и код пересылки IP в UNIX обычно её не реализовывали. По мере усложнения сетей и роста требований клиентов поставщики коммерческих маршрутизаторов разработали способы предоставления различных видов обслуживания очередей, включая приоритетные очереди. Обычно они основывались на политиках, закодированных в фильтрах маршрутизаторов, которые проверяли IP-адреса, номера IP-протоколов, порты TCP или UDP и другие поля заголовков. IP Precedence было и остаётся одним из параметров, проверяемых такими фильтрами.
Таким образом, IP Precedence широко развёрнут и используется, хотя и не всегда именно так, как предполагалось в [RFC791]. Это признано в [RFC1122], где сказано, что использование поля IP Precedence допустимо, но конкретное назначение приоритетов в [RFC791] является лишь историческим.
4.2.2. Включение IP Precedence в кодовые значения селектора класса
Спецификация обработки при пересылке пакетов, выбираемой сегодня полем IP Precedence, должна была бы быть весьма общей и, вероятно, недостаточно конкретной для построения предсказуемых услуг в рамках дифференцированных услуг. Чтобы сохранить частичную обратную совместимость с известными текущими способами использования IP Precedence, не жертвуя будущей гибкостью, выбрано описание минимальных требований к набору PHB, совместимых с большинством развёрнутых способов пересылки, выбираемых полем IP Precedence. Кроме того, приводится набор кодовых значений, которые ОБЯЗАТЕЛЬНО (MUST) должны сопоставляться с PHB, удовлетворяющими этим минимальным требованиям. Сопоставленные с этими значениями PHB МОГУТ (MAY) иметь более подробные спецификации в дополнение к обязательным требованиям, указанным здесь. Другие кодовые значения МОГУТ (MAY) сопоставляться с теми же PHB. Этот набор называется кодовыми значениями селектора класса, а минимальные требования к PHB, с которыми они могут быть сопоставлены, — требованиями к PHB селектора класса.
4.2.2.1. Кодовые значения селектора класса
Значения поля DS вида xxx000|xx, то есть DSCP = xxx000 при неопределённом подполе CU, зарезервированы как набор кодовых значений селектора класса. PHB, сопоставленные с этими кодовыми значениями, ОБЯЗАНЫ (MUST) удовлетворять требованиям к PHB селектора класса и сохранять требование к PHB по умолчанию для кодового значения 000000 (раздел 4.1).
4.2.2.2. Требования к PHB селектора класса
Кодовое значение селектора класса с большим числовым значением называется имеющим более высокий относительный порядок, а значение с меньшим числовым значением — более низкий. Набор PHB, сопоставленных восьми кодовым значениям селектора класса, ОБЯЗАН (MUST) обеспечивать не менее двух независимо пересылаемых классов трафика. PHB, выбранные кодовым значением селектора класса, при разумных условиях эксплуатации и нагрузке на трафик СЛЕДУЕТ (SHOULD) обеспечивать пакетам вероятность своевременной пересылки не ниже, чем для пакетов, помеченных значением селектора класса с более низким относительным порядком. Отброшенный пакет считается крайним случаем несвоевременной пересылки. Кроме того, PHB, выбранные кодовыми значениями 11x000, ОБЯЗАНЫ (MUST) обеспечивать пакетам преимущественную пересылку по сравнению с PHB, выбранным значением 000000, чтобы сохранить распространённое использование значений IP Precedence 110 и 111 для трафика маршрутизации.
Кроме того, PHB, выбранные разными кодовыми значениями селектора класса, СЛЕДУЕТ (SHOULD) пересылать независимо; то есть пакеты с разными кодовыми значениями селектора класса МОГУТ (MAY) менять взаимный порядок. Сетевой узел МОЖЕТ (MAY) ограничивать количество своих ресурсов, доступных каждому из этих PHB.
Группы PHB, спецификации которых удовлетворяют этим требованиям, называются PHB, соответствующими селектору класса. Требования к PHB селектора класса для значения 000000 совместимы с требованиями к PHB по умолчанию из раздела 4.1.
4.2.2.3. Использование требований к PHB селектора класса для совместимости с IP Precedence
Соответствующий DS сетевой узел можно развернуть с одной или несколькими группами PHB, соответствующих селектору класса. Настоящий документ устанавливает, что набор кодовых значений xxx000 ОБЯЗАТЕЛЬНО (MUST) сопоставляется с таким набором PHB. Поскольку несколько кодовых значений можно сопоставить с одним PHB, производитель или сетевой администратор МОЖЕТ (MAY) настроить сопоставление на узле независимо от битов 3–5 поля DSCP, получив сеть, совместимую с историческим использованием IP Precedence. Так, кодовое значение 011010 будет сопоставлено с тем же PHB, что и 011000.
4.2.2.4. Примеры механизмов реализации групп PHB, соответствующих селектору класса
Такие PHB можно реализовать различными механизмами, включая очереди со строгим приоритетом, взвешенные справедливые очереди (WFQ), WRR или их варианты [RPS, HPFQA, DRR], а также организацию очередей по классам (CBQ) [CBQ]. Различие между PHB и механизмами подробнее описано в разделе 5.
Важно отметить, что эти механизмы могут предоставляться другими PHB — стандартизованными или нет, — доступными в оборудовании конкретного производителя. Например, будущие документы могут стандартизовать группу PHB со строгими приоритетными очередями для набора рекомендуемых кодовых значений. Сетевой администратор может настроить маршрутизаторы так, чтобы кодовые значения xxx000 выбирали эти PHB согласно требованиям документа.
В другом примере производитель может использовать в своих маршрутизаторах механизм CBQ. Его можно применить для реализации как PHB со строгими приоритетными очередями, так и набора PHB, соответствующих селектору класса, с более широкими возможностями, чем у набора PHB, лишь удовлетворяющего минимальным требованиям к селектору класса.
4.3. Итоги
Документ определяет кодовые значения xxx000 как значения селектора класса; выбранные ими PHB ОБЯЗАНЫ (MUST) удовлетворять требованиям раздела 4.2.2.2. Это позволяет сохранить полезную степень обратной совместимости с текущим использованием поля IP Precedence в Интернете без чрезмерного ограничения будущей гибкости. Кроме того, значение 000000 используется для PHB по умолчанию в Интернете и потому не настраивается. Остальные семь ненулевых значений селектора класса настраиваются лишь в той мере, в какой они сопоставляются с PHB, удовлетворяющими требованиям раздела 4.2.2.2.
5. Рекомендации по стандартизации поведения на узле
Стандартизоваться должны характеристики поведения PHB, а не конкретные алгоритмы или механизмы его реализации. Узел может иметь, возможно большой, набор параметров управления планированием отправки пакетов на выходной интерфейс: например, N отдельных очередей с настраиваемыми приоритетами, длинами, весами циклического обслуживания, алгоритмом отбрасывания, весами и порогами предпочтительного отбрасывания и т. д. В качестве иллюстрации различия между PHB и механизмом заметим, что PHB, соответствующие селектору класса, можно реализовать разными механизмами, включая строгие приоритетные очереди, WFQ, WRR или их варианты [HPFQA, RPS, DRR] либо CBQ [CBQ], отдельно или в сочетании.
PHB могут специфицироваться по отдельности или группой; один PHB — частный случай группы PHB. Группа обычно состоит из двух или более PHB, которые имеет смысл определить и реализовать только одновременно из-за общего ограничения, применимого к каждому PHB группы, например политики обслуживания очереди или управления ею. Спецификации группы PHB СЛЕДУЕТ (SHOULD) описывать условия, при которых пакет может быть перемаркирован для выбора другого PHB внутри группы. РЕКОМЕНДУЕТСЯ (RECOMMENDED), чтобы реализации PHB не изменяли порядок пакетов внутри микропотока. Спецификации группы PHB ОБЯЗАНЫ (MUST) указывать любые возможные последствия для порядка пакетов как для каждого отдельного PHB, так и в случае, когда разные пакеты одного микропотока помечены для разных PHB группы.
Стандартизовать СЛЕДУЕТ (SHOULD) только те типы поведения на узле, которые не описаны существующим стандартом PHB, реализованы, развёрнуты и показали свою полезность. Поскольку текущий опыт использования дифференцированных услуг весьма ограничен, предполагать точные спецификации этих типов поведения преждевременно.
Каждое стандартизованное PHB ОБЯЗАНО (MUST) иметь связанное с ним РЕКОМЕНДУЕМОЕ (RECOMMENDED) кодовое значение, выделенное из пространства в 32 значения (см. раздел 6). В пространстве кодовых значений оставлен запас для развития, поэтому определённое пространство xxx000 намеренно разрежено.
Производители сетевого оборудования вправе предоставлять любые параметры и возможности, которые они считают полезными или востребованными на рынке. Реализуя конкретное стандартизованное PHB на узле, производитель МОЖЕТ (MAY) использовать любой алгоритм, удовлетворяющий стандартному определению PHB. Возможности узла и его конкретная конфигурация определяют различные способы обработки пакетов.
Поставщики услуг не обязаны использовать одинаковые механизмы или конфигурации узлов для дифференциации услуг в своих сетях и вправе настраивать параметры узлов в соответствии с предлагаемыми услугами и целями управления трафиком. Со временем, вероятно, сформируются некоторые общие типы поведения на узле, особенно полезные для реализации сквозных услуг; их МОЖНО (MAY) связать с конкретными кодовыми значениями PHB для экспериментов или локального использования (EXP/LU) в поле DS, что позволит применять их между доменами (см. раздел 6). Такие PHB являются кандидатами на будущую стандартизацию.
РЕКОМЕНДУЕТСЯ (RECOMMENDED) определять стандартизованные PHB согласно рекомендациям [ARCH].
6. Вопросы IANA
Поле DSCP в составе поля DS способно передавать 64 различных кодовых значения. Для назначения и управления пространство значений разделено на три пула: пул из 32 РЕКОМЕНДУЕМЫХ (RECOMMENDED) значений (пул 1), назначаемых посредством Standards Action согласно [CONS]; пул из 16 значений (пул 2), зарезервированных для экспериментального или локального использования (EXP/LU) согласно [CONS]; и пул из 16 значений (пул 3), первоначально доступных для экспериментального или локального использования, но подлежащих преимущественному использованию для стандартизованных назначений, если пул 1 когда-либо исчерпается.
Пулы определены в следующей таблице; x означает 0 или 1:
Пул Пространство значений Политика назначения 1 xxxxx0 Standards Action 2 xxxx11 EXP/LU 3 xxxx01 EXP/LU (*)
(*) При необходимости может использоваться для будущих назначений Standards Action.
Документ назначает восемь РЕКОМЕНДУЕМЫХ (RECOMMENDED) кодовых значений xxx000 из пула 1. Эти значения ОБЯЗАТЕЛЬНО (MUST) сопоставляются не с конкретными PHB, а с PHB, удовлетворяющими как минимум требованиям раздела 4.2.2.2, чтобы обеспечить минимальный уровень обратной совместимости с IP Precedence, определённым в [RFC791] и реализованным в части существующего оборудования.
7. Вопросы безопасности
В этом разделе рассматриваются вопросы безопасности, возникающие при внедрении дифференцированных услуг, прежде всего возможность атак типа «отказ в обслуживании» и связанная с ней возможность несанкционированного получения услуг посторонним трафиком (раздел 7.1). Раздел 7.2 посвящён работе дифференцированных услуг при использовании IPsec, включая взаимодействие с туннельным режимом IPsec и другими протоколами туннелирования. Более полное рассмотрение вопросов безопасности архитектуры дифференцированных услуг в целом приведено в [ARCH].
7.1. Несанкционированное получение услуг и отказ в обслуживании
Основная цель дифференцированных услуг — предоставить возможность обслуживания потоков трафика на разных уровнях в общей сетевой инфраструктуре. Для этого можно использовать различные методы, но в конечном счёте некоторые пакеты будут получать обслуживание, отличающееся от других, например лучшее. Сопоставление сетевого трафика с конкретным поведением, обеспечивающим различное, например лучшее или худшее, обслуживание, определяется прежде всего кодовым значением DS. Поэтому злоумышленник может получить лучшее обслуживание, изменив кодовое значение на обозначающее поведение для улучшенной услуги либо внедрив пакеты с такими кодовыми значениями. В предельном случае такое несанкционированное получение услуг становится атакой типа «отказ в обслуживании», когда изменённый или внедрённый трафик исчерпывает ресурсы, доступные для его пересылки и пересылки других потоков.
Защита от этого класса атак сочетает обработку трафика на границах домена DS с обеспечением безопасности и целостности сетевой инфраструктуры внутри домена. Граничные узлы домена DS ОБЯЗАНЫ (MUST) обеспечивать маркировку всего входящего трафика кодовыми значениями, соответствующими трафику и домену, при необходимости перемаркируя его новыми значениями. Эти узлы — основная линия защиты от атак, основанных на изменении кодовых значений: успех такой атаки указывает, что значения атакующего трафика были неподходящими. Важный частный случай граничного узла — любой узел внутри домена DS, создающий трафик: для этого трафика он является начальным граничным узлом. Внутренние узлы домена DS используют кодовые значения для сопоставления трафика с PHB пересылки и НЕ ОБЯЗАНЫ (NOT REQUIRED) проверять значения перед использованием. Поэтому предотвращение поступления трафика с неподходящими кодовыми значениями или превышающего выделенные уровни и нарушающего работу домена зависит от правильной работы граничных узлов.
7.2. Взаимодействие с IPsec и туннелированием
Протокол IPsec, определённый в [ESP, AH], не включает поле DS IP-заголовка в свои криптографические вычисления; в туннельном режиме не включается поле DS внешнего IP-заголовка. Поэтому изменение поля DS сетевым узлом не влияет на сквозную безопасность IPsec: оно не может привести к ошибке проверки целостности IPsec. Следовательно, IPsec не защищает от изменения поля DS злоумышленником, то есть от атаки посредника, поскольку такое изменение также не влияет на сквозную безопасность IPsec.
Туннельный режим IPsec защищает поле DS инкапсулированного IP-заголовка. Пакет IPsec в туннельном режиме содержит два IP-заголовка: внешний, предоставленный входным узлом туннеля, и инкапсулированный внутренний, предоставленный первоначальным источником пакета. Если туннель IPsec полностью или частично проходит по сети с дифференцированными услугами, промежуточные сетевые узлы работают с полем DS внешнего заголовка. На выходном узле туннеля обработка IPsec включает удаление внешнего заголовка и, при необходимости, пересылку пакета с использованием внутреннего заголовка. Протокол IPsec ТРЕБУЕТ (REQUIRES), чтобы обработка декапсуляции не изменяла поле DS внутреннего заголовка: это предотвращает использование изменений поля DS для атак с несанкционированным получением услуг или отказом в обслуживании через конечную точку туннеля IPsec. Настоящий документ не изменяет это требование. Если внутренний IP-заголовок не был обработан граничным узлом DS для домена выходного узла туннеля, выходной узел является граничным для выходящего из туннеля трафика и потому ОБЯЗАН (MUST) обеспечить наличие в полученном трафике подходящих кодовых значений DS.
Когда декапсуляция на выходе туннеля IPsec включает достаточно сильную криптографическую проверку целостности инкапсулированного пакета — достаточность определяется локальной политикой безопасности, — выходной узел может обоснованно считать, что поле DS внутреннего заголовка имеет то же значение, что и на входе туннеля. Важное следствие: незащищённые иным образом каналы внутри домена DS можно защитить достаточно сильным туннелем IPsec. Этот анализ и его следствия относятся к любому протоколу туннелирования, выполняющему проверки целостности, но степень уверенности в поле DS внутреннего заголовка зависит от силы используемой проверки. Если для туннеля, который может проходить через узлы вне текущего домена DS или уязвим иным образом, достаточная уверенность отсутствует, инкапсулированный пакет ОБЯЗАТЕЛЬНО (MUST) обрабатывается как поступивший на границу извне домена DS.
8. Благодарности
Авторы благодарят рабочую группу Differentiated Services за обсуждения, которые помогли сформировать документ.
9. Ссылки
[AH] Kent, S. and R. Atkinson, "IP Authentication Header",
RFC 2402, November 1998.
[ARCH] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.
and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, December 1998.
[CBQ] S. Floyd and V. Jacobson, "Link-sharing and Resource
Management Models for Packet Networks", IEEE/ACM
Transactions on Networking, Vol. 3 no. 4, pp. 365-386,
August 1995.
[CONS] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 2434, October
1998.
[DRR] M. Shreedhar and G. Varghese, Efficient Fair Queueing
using Deficit Round Robin", Proc. ACM SIGCOMM 95, 1995.
[ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998.
[HPFQA] J. Bennett and Hui Zhang, "Hierarchical Packet Fair
Queueing Algorithms", Proc. ACM SIGCOMM 96, August 1996.
[IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC791] Postel, J., Editor, "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC1122] Braden, R., "Requirements for Internet hosts -
communication layers", STD 3, RFC 1122, October 1989.
[RFC1812] Baker, F., Editor, "Requirements for IP Version 4
Routers", RFC 1812, June 1995.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RPS] D. Stiliadis and A. Varma, "Rate-Proportional Servers: A
Design Methodology for Fair Queueing Algorithms", IEEE/
ACM Trans. on Networking, April 1998.
Адреса авторов
Kathleen Nichols Cisco Systems 170 West Tasman Drive San Jose, CA 95134-1706
Phone: +1-408-525-4857 EMail: kmn@cisco.com
Steven Blake Torrent Networking Technologies 3000 Aerial Center, Suite 140 Morrisville, NC 27560
Phone: +1-919-468-8466 x232 EMail: slblake@torrentnet.com
Fred Baker Cisco Systems 519 Lado Drive Santa Barbara, CA 93111
Phone: +1-408-526-4257 EMail: fred@cisco.com
David L. Black EMC Corporation 35 Parkwood Drive Hopkinton, MA 01748
Phone: +1-508-435-1000 x76140 EMail: black_david@emc.com
Полное заявление об авторских правах
Copyright (C) The Internet Society (1998). Все права защищены.
Этот документ и его переводы можно копировать и передавать другим лицам; производные работы, комментирующие или иным образом разъясняющие его либо помогающие в его реализации, можно создавать, копировать, публиковать и распространять полностью или частично без каких-либо ограничений при условии включения приведённого выше уведомления об авторских правах и настоящего абзаца во все такие копии и производные работы. Однако сам документ нельзя изменять каким-либо образом, например удалять уведомление об авторских правах или ссылки на Internet Society либо другие интернет-организации, кроме случаев, необходимых для разработки стандартов Интернета с соблюдением процедур авторского права процесса стандартизации Интернета, или необходимых для перевода на языки, отличные от английского.
Предоставленные выше ограниченные разрешения являются бессрочными и не будут отозваны Internet Society, её правопреемниками или цессионариями.
Этот документ и содержащаяся в нём информация предоставляются «КАК ЕСТЬ»; INTERNET SOCIETY И INTERNET ENGINEERING TASK FORCE ОТКАЗЫВАЮТСЯ ОТ ВСЕХ ГАРАНТИЙ, ЯВНЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ, ВКЛЮЧАЯ, ПОМИМО ПРОЧЕГО, ЛЮБЫЕ ГАРАНТИИ ТОГО, ЧТО ИСПОЛЬЗОВАНИЕ СОДЕРЖАЩЕЙСЯ ЗДЕСЬ ИНФОРМАЦИИ НЕ НАРУШАЕТ ЧЬИХ-ЛИБО ПРАВ, А ТАКЖЕ ЛЮБЫЕ ПОДРАЗУМЕВАЕМЫЕ ГАРАНТИИ КОММЕРЧЕСКОЙ ПРИГОДНОСТИ ИЛИ ПРИГОДНОСТИ ДЛЯ КОНКРЕТНОЙ ЦЕЛИ.
Перевод: RFCNET · rfcnet.ru
Original copyright notice
Copyright Notice
Copyright (C) The Internet Society (1998). All Rights Reserved.
Abstract
Differentiated services enhancements to the Internet protocol are
intended to enable scalable service discrimination in the Internet
without the need for per-flow state and signaling at every hop. A
variety of services may be built from a small, well-defined set of
building blocks which are deployed in network nodes. The services
may be either end-to-end or intra-domain; they include both those
that can satisfy quantitative performance requirements (e.g., peak
bandwidth) and those based on relative performance (e.g., "class"
differentiation). Services can be constructed by a combination of:
- setting bits in an IP header field at network boundaries
(autonomous system boundaries, internal administrative boundaries,
or hosts),
- using those bits to determine how packets are forwarded by the
nodes inside the network, and
- conditioning the marked packets at network boundaries in accordance
with the requirements or rules of each service.
Nichols, et. al. Standards Track [Page 1]
RFC 2474 Differentiated Services Field December 1998
The requirements or rules of each service must be set through
administrative policy mechanisms which are outside the scope of this
document. A differentiated services-compliant network node includes
a classifier that selects packets based on the value of the DS field,
along with buffer management and packet scheduling mechanisms capable
of delivering the specific packet forwarding treatment indicated by
the DS field value. Setting of the DS field and conditioning of the
temporal behavior of marked packets need only be performed at network
boundaries and may vary in complexity.
This document defines the IP header field, called the DS (for
differentiated services) field. In IPv4, it defines the layout of
the TOS octet; in IPv6, the Traffic Class octet. In addition, a base
set of packet forwarding treatments, or per-hop behaviors, is
defined.
For a more complete understanding of differentiated services, see
also the differentiated services architecture [ARCH].
Неофициальный перевод. При расхождениях см. оригинал.