AAA

RFC 2475 — Архитектура дифференцированного обслуживания (Diffserv)

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

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

Тезисы

В этом документе определена архитектура для реализации масштабируемой дифференциации услуг в Internet. Эта архитектура обеспечивает масштабирование за счет агрегирования состояний классификации трафика, которые передаются путем маркировки пакетов IP с использованием поля DS [DSFIELD].

Пакеты классифицируются и маркируются для обеспечения определенной обработки на узлах каждого этапа на пути доставки пакета. Изощренные методы классификации, маркировки, реализации политики, формовки трафика требуются только на границах сетей или хостах.

Сетевые ресурсы выделяются для потоков трафика правилами предоставления услуг, которые определяют маркировку и кондиционирование трафика на входе в сеть с поддержкой дифференцированных услуг, а также пересылку трафика внутри такой сети. На основе этого можно построить широкий спектр сетевых услуг.

Оглавление

1. Введение

1.1 Обзор

В этом документе определена архитектура для реализации масштабируемой дифференциации услуг в Internet. «Услуга» определяет некоторые значимые характеристики передачи пакетов в одном направлении по одному или множеству путей внутри сети. Эти характеристики могут быть заданы количественно или статистически в части пропускной способности, задержки, вариаций задержки и/или потери пакетов или могут быть определены с форме некоторого относительного уровня приоритета доступа к сетевым ресурсам. Дифференциация услуг желательна для аккомодации разнородных требований приложений и ожиданий пользователей, а также позволяет дифференцировать стоимость услуг Internet.

Архитектура включает множество функциональных элементов, реализованных на узлах сети, включая небольшой набор аспектов пересылки на каждом этапе, функции классификации трафика и функции кондиционирования трафика, в том числе измерение, маркировку, формование и применение правил. Эта архитектура обеспечивает масштабируемость за счет реализации комплексных функций классификации и кондиционирования исключительно на граничных узлах сетей и выполнения определенных операций на каждом этапе пересылки применительно к агрегатам трафика, маркированным с использованием поля DS в заголовках IPv4 или IPv6 [DSFIELD]. Задается поведение на каждом этапе для того, чтобы обеспечить разумную гранулярность распределения буферов и полосы пропускания на каждом узле между конкурирующими потоками трафика. Потоки для каждого приложения и состояние пересылки для каждого заказчика не требуется поддерживать в ядре сети. Поддерживаются различия между:

Правила предоставления услуг и кондиционирования трафика отделены от пересылки внутри сети, чтобы обеспечить возможность реализации широкого набора вариантов поведения для услуг и пространство для его расширения.

Эта архитектура обеспечивает дифференциацию услуг только для одного направления потока трафика и, следовательно, является асимметричной. Разработка дополнительной симметричной архитектуры является предметом исследования и выходит за пределы данного документа. Более подробно о таких исследованиях можно узнать из работы [EXPLICIT].

В параграфе 1.2 определены основные термины, используемые в документе. В параграфе 1.3 перечислены требования, порождаемые этой архитектурой, а параграф 1.4 содержит краткое сравнение с другими моделями дифференциации услуг. В разделе 2 приводится детальное рассмотрение компонент архитектуры. Раздел 3 содержит рекомендации по спецификации поведения на каждом этапе. В разделе 4 обсуждаются вопросы интероперабельности с узлами и сетями, которые не реализуют дифференциации услуг в соответствии с этим документом и [DSFIELD]. В разделе 5 рассматриваются вопросы доставки групповых услуг, а раздел 6 посвящен вопросам безопасности и рассмотрению туннелей.

1.2 Терминология

В этом параграфе содержится концептуальный обзор терминов, используемых в документе. Некоторые из этих терминов более подробно рассмотрены в последующих разделах.

1.3 Требования

История Internet представляет собой постоянный рост числа хостов, появление новых приложений, рост емкости сетевой инфраструктуры. В обозримом будущем предполагается продолжение такого роста. Масштабируемая архитектура дифференциации обслуживания должна обеспечивать возможность адаптации к продолжающемуся росту.

Ниже перечислены идентифицированные требования, решаемые данной архитектурой:

1.4 Сравнение с другими моделями

Описываемая в этом документе архитектура дифференцированного обслуживания может противоречить другим моделям дифференциации услуг. Мы классифицируем эти альтернативные модели по нескольким категориям — маркировка относительного приоритета, маркировка сервиса, коммутация меток, интегрированные службы/RSVP и статическая классификация для каждого этапа пересылки.

Примерами маркировки относительного приоритета могут служить маркировка IPv4 Precedence [RFC791], 802.5 Token Ring [TR] и принятая по умолчанию интерпретация классов трафика 802.1p [802.1p]. В этой модели приложения, хосты или узлы-посредники выбирают относительный уровень приоритета или «предпочтения» для пакета (например, приоритет по задержке или отбрасыванию), а сетевые узлы на пути передачи применяют соответствующий значению приоритета в поле заголовка режим пересылки. Наша архитектура может задавать роль и важность граничных узлов и кондиционеров трафика, благодаря этому наша модель обеспечивает более общий подход к поэтапному режиму пересылки, нежели относительный приоритет для задержки или отбрасывания.

Примером модели маркировки услуг является IPv4 TOS в соответствии с определением [RFC1349]. В этом примере каждый пакет маркируется запросом «типа обслуживания», который принимать значения «минимизировать задержку», «максимизировать пропускную способность», «максимизировать надежность» или «минимизировать стоимость». Узлы сети могут выбирать путь маршрутизации или режим пересылки, который подходит для запрошенного типа обслуживания. Эта модель имеет тонкие отличия от нашей архитектуры. Отметим, что мы не описываем использование поля DS в качестве входной информации для выбора маршрута. Маркировка TOS, определенная в [RFC1349], является весьма общей и не охватывает весь диапазон возможной семантики обслуживания. Более того, с каждым пакетом связывается запрос на обслуживание, а семантика некоторых услуг может зависеть от агрегированного режима пересылки последовательности пакетов. Модель маркировки услуг достаточно сложно приспособить к будущему росту числа и диапазона услуг (поскольку пространство кодов достаточно мало) и эта модель включает настройку конфигурации ассоциаций «TOS->режим пересылки» на каждом узле ядра сети. Стандартизация маркировки услуг предполагает стандартизацию предложений услуг, которая выходит за пределы компетентности IETF. Отметим, что при распределении пространства кодов DS, часть кодов зарезервирована для обеспечения возможности локального управления кодами, позволяющего провайдерам поддерживать локальную семантику маркировки услуг [DSFIELD].

Примеры модели коммутации меток (или виртуальных устройств) включают Frame Relay, ATM и MPLS [FRELAY, ATM]. В этой модели поддерживается состояние пересылки и управления трафиком или QoS для потоков трафика на каждом интервале пути через сеть. Агрегаты трафика различной гранулярности ассоциируются с путем коммутации меток на входном узле, а пакеты/ячейки в каждом пути коммутации меток маркируются меткой пересылки, которая используется для поиска следующего интервала, а также режима пересылки и заменяется на каждом этапе пересылки. Эта модель обеспечивает тонкую гранулярность распределения ресурсов для потоков трафика, поскольку значения меток не имеют глобальной значимости и важны только для одного канала. Следовательно, можно резервировать ресурсы для агрегирования пакетов/ячеек, принятых на канале с определенной меткой, а семантика коммутации меток определяет выбор следующего интервала, позволяя передавать потоки трафика через специально созданные для них сетевые пути. Такое улучшение гранулярности связано с расходами на выполнение дополнительных требований по управлению и настройке для организации и поддержке путей коммутации меток. В дополнение к этому количество состояний пересылки, поддерживаемых на каждом узле, растет пропорционально числу краевых узлов сети в лучшем случае (в предположении путей коммутации меток multipoint-to-point) и пропорционально квадрату числа краевых узлов в худшем случае, когда обеспечиваются пути коммутации меток «от края до края» с гарантированными ресурсами.

Модель интегрированных услуг/RSVP основана на традиционной пересылке дейтаграмм по умолчанию, но позволяет отправителям и получателям обмениваться сигнальными сообщениями, которые позволяют организовать дополнительную классификацию пакетов и состояние пересылки на каждом узле между ними [RFC1633, RSVP]. В отсутствии агрегирования состояний их число на каждом узле растет пропорционально числу одновременных резервирований, которое для скоростных каналов может быть очень большим. Эта модель также требует от приложений поддержки протокола RSVP. Для агрегирования состояний интегрированных услуг/RSVP в ядре сети могут использоваться механизмы дифференциации обслуживания [Bernet].

Вариант модели интегрированных услуг/RSVP позволяет избавиться от требования поэтапной сигнализации за счет использования только «статической» классификации и политики пересылки, реализуемых на каждом узле пути через сеть. Политика изменяется административными методами, а не в ответ на изменение моментального состояния микропотоков в сети. Требования к состояниям для этого варианта потенциально жестче, нежели при использовании RSVP, особенно для магистральных узлов, поскольку число статических правил, которые могут применяться на узле в течение времени, может быть больше числа активных сеансов «отправитель-получатель», которые одновременно организуют резервирование состояния на узле. Хотя поддержка большого числа правил классификации и пересылки может может требовать вполне приемлемых вычислительных ресурсов, издержки на управление, связанные с организацией и поддержкой этих правил на каждом узле магистральной сети, через которую проходит трафик, могут быть достаточно велики.

Хотя мы противопоставили альтернативные модели и дифференциацию обслуживания, следует отметить, что эти методы могут использоваться для расширения режимов и семантики дифференцированного обслуживания в коммутируемой инфраструктуре канального уровня (например, ЛВС 802.1p, магистрали Frame Relay/ATM), соединяющей узлы DS, а также в том случае, когда в качестве внутридоменной технологии может использоваться MPLS. Ограничения, вносимые конкретной технологией канального уровня в отдельной зоне домена DS (или в сети, обеспечивающей доступ к доменам DS), могут загрублять дифференциацию обслуживания. В зависимости от отображения PHB на различные услуги канального уровня и способа распределения пакетов по ограниченному набору классов приоритета (или виртуальных устройств различных категорий и производительности), поддерживаться могут все или часть PHB (некоторые могут оказаться нежелательными).

2. Архитектурная модель дифференциации услуг

Архитектура дифференцированного обслуживания основана на простой модели, где трафик классифицируется на входе в сеть и, возможно, кондиционируется на границах сети; классифицированный трафик относится к тому или иному агрегату режима обработки. Каждый агрегат идентифицируется одним кодом DS. Внутри ядра сети пакеты пересылаются в соответствии с заданным для этапа режимом, связанным с кодом DS. В этом разделе обсуждаются компоненты зоны дифференцированного обслуживания, функции классификации и кондиционирования трафика, а также вопросы дифференцированного обслуживания, реализуемого через комбинацию кондиционирования трафика и пересылки на основе PHB.

2.1 Домен дифференцированных услуг

Домен DS представляет собой связное множество узлов DS, которые работают с общим набором правил предоставления услуг, и набором групп PHB, реализованных на каждом узле. Домен DS имеет хорошо определенные границы, состоящие из граничных узлов DS, которые классифицируют и, возможно, кондиционируют входящий трафик для обеспечения проходящим через домен пакетам корректной маркировки для выбора PHB из групп PHB, поддерживаемых в домене. Узлы в домене DS выбирают режим пересылки для пакетов на основе кода DS, отображая этот код на один из поддерживаемых режимов PHB с использованием рекомендованного отображения код->PHB или локально управляемого отображения [DSFIELD]. Включение не поддерживающих DS узлов в домен DS может приводить к непредсказуемому изменению производительности и осложнять возможность выполнения сервисных соглашений (SLA).

Домен DS состоит из одной или множества сетей с общим администрированием (например, внутренняя сеть организации или сеть ISP). Администрация домена отвечает за обеспечение достаточных ресурсов и/или их резервирование для обеспечения SLA, предлагаемых доменом.

2.1.1 Граничные и внутренние узлы DS

Домен DS состоит из граничных и внутренних узлов DS. Граничные узлы DS соединяют домен DS с другими доменами (DS или не-DS), тогда, как внутренние узлы DS соединяют между собой только внутренние или граничные узлы DS в одном домене DS.

Как граничные, так и внутренние узлы DS должны быть способны применять подходящий режим PHB к пакетам на основе кода DS; в противном случае поведение может стать непредсказуемым. В дополнение от граничных узлов DS может требоваться выполнение функций кондиционирования трафика в соответствии с соглашением о кондиционировании (TCA) между доменом DS и доменами-партнерами, с которыми он соединен (см. параграф 2.3.3).

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

Хост в сети, содержащей домен DS, может действовать как граничный узел DS для трафика приложений, работающих на этом хосте; мы говорим, следовательно, что этот хост находится в домене DS. Если хост не функционирует, как граничный узел, тогда топологически ближайший к хосту узел DS, действует, как граничный узел DS для трафика этого хоста.

2.1.2 Входные и выходные узлы DS

Граничные узлы DS действуют как входные и выходные узлы DS для различных направлений трафика. Трафик входит в домен DS через входной узел DS и покидает домен DS через выходной узел DS. Входной узел DS отвечает за то, что входящий в DS трафик соответствует всем TCA между данным доменом и другими доменами, к которым подключен входной узел. Выходной узел DS может выполнять функции кондиционирования для трафика, пересылаемого в непосредственно подключенные партнерские домены в зависимости от условий TCA между двумя доменами. Отметим, что граничный узел DS может функционировать как внутренний узел DS для некоторого множества интерфейсов.

2.2 Зона дифференцированного обслуживания

Зона дифференцированного обслуживания (DS Region) представляет собой набор из одного или множества доменов DS. Зоны DS способны поддерживать дифференциацию обслуживания на пути, проходящем через домены зоны.

Домены DS в зоне DS могут поддерживать различные группы PHB внутри себя и разные отображения код->PHB. Однако для того, чтобы разрешить услуги, которые могут предоставляться через несколько доменов, партнерские домены DS должны организовать партнерские SLA, которые определяют (явно или неявно) TCA, задающие кондиционирование трафика из одного домена DS в другой на границе между двумя доменами DS.

Возможно, что несколько доменов DS внутри зоны DS будут использовать общий набор правил обслуживания и поддерживать общий набор групп PHB и отображений кодов — это избавляет от необходимости кондиционирования трафика между этими доменами DS.

2.3 Классификация и кондиционирование трафика

Дифференцированные услуги предоставляются через границу домена DS путем организации SLA между восходящей (upstream) сетью и нисходящим (downstream) доменом DS. SLA может задавать правила классификации и перемаркировки трафика, а также профили трафика и действия для потоков трафика, который относится или не относится к профилю (см. параграф 2.3.2). TCA между доменами организуется (явно или неявно) на основе таких SLA.

Правила классификации трафика задают подмножество трафика, для которого может предоставляться дифференцированное обслуживание путем кондиционирования и/или повторного отображения (путем перемаркировки кодов DS) на один или множество агрегатов поведения внутри домена DS.

Кондиционирование трафика включает измерение, формование, применение политики и/или перемаркировку для того, чтобы входящий в домен DS трафик соответствовал правилам, заданным в TCA, согласно политике предоставления услуг этого домена. Кондиционирование трафика требуется в зависимости от предлагаемых услуг и может представлять собой набор операций от простой перемаркировки кодов до выполнения сложных операций формовки и исполнения политики. Детали кондиционирования трафика согласуются между сетями и выходят за пределы этого документа.

2.3.1 Классификаторы

Классификаторы пакетов выбирают пакеты в потоке трафика на основе значений некоторых полей заголовков. Мы определяем два типа классификаторов. Классификатор BA (Behavior Aggregate — агрегат поведения) разделяет пакеты исключительно на основе кода DS. Классификатор MF (Multi-Field — по множеству полей) выделяет пакеты на основе комбинации полей заголовка, включая такие поля, как адреса отправителя и получателя, поле DS, идентификатор протокола, номера портов отправителя и получателя, а также других параметров (например, входной интерфейс).

Классификаторы служат для «направления» пакетов, соответствующих определенному правилу, элементу кондиционирования трафика для последующей обработки. Классификаторы должны настраиваться с помощью той или иной процедуры управления в соответствии с подходящим TCA.

Классификаторам следует проверять подлинность информации, используемой для выбора пакетов (см. раздел 6).

Отметим, что при фрагментации «восходящего» пакета, классификаторы MF, которые проверяют содержимое заголовков транспортного уровня, могут некорректно классифицировать фрагменты, следующие за первым. Возможным решением этой проблемы служит поддержка информации о состоянии фрагментации. Однако такое решение не является достаточно общим, поскольку в восходящем потоке может меняться порядок доставки и даже пути маршрутизации. Правила обработки фрагментов выходят за пределы этого документа.

2.3.2 Профили трафика

Профиль трафика задает временные параметры потока трафика, выбранного классификатором. Это обеспечивает правила для определения соответствия конкретного пакета данному профилю. Например, профиль на основе token bucket может иметь вид:

codepoint=X, use token-bucket r, b

Такой профиль показывает, что все пакеты с кодом DS = X, следует сравнивать с уровнем потока r и размером выбросов трафика b. В этом примере профилю не соответствуют пакеты из потока трафика, принимаемые в те моменты, когда в корзине не остается маркеров. Концепцию можно расширить, используя более двух уровней. Например, можно определить и реализовать профиль с множеством уровней маркирования.

К пакетам, соответствующим и не соответствующим профилю, могут применяться различные операции или включаться те или иные механизмы учета. Соответствующим профилю пакетам может разрешаться вход в домен DS без дальнейшего кондиционирования или, наоборот, их код DS может быть изменен. Последнее происходит в тех случаях, когда для DS изначально установлено отличное от принятого по умолчанию значение [DSFIELD], или пакеты входят в домен DS, использующий другую группу PHB или иное отображение код->PHB для этого потока трафика. Пакеты, не соответствующие профилю, могут помещаться в очередь, пока они не войдут в профиль (формовка), отбрасываться (политика), маркироваться новым кодом (перемаркировка) или пересылаться без изменений, но с включением некой процедуры учета. Не соответствующие профилю пакеты могут отображаться в один или несколько агрегатов поведения, которые являются «подчиненными» в плане скорости пересылки по отношению к BA, куда отображаются соответствующие профилю пакеты.

Отметим, что профиль трафика является необязательной частью TCA и его использование зависит от специфики предоставляемого сервиса и политики предоставления услуг в домене.

2.3.3 Кондиционеры трафика

Кондиционеры трафика могут включать измерители, маркировщики, формовщики и отбрасыватели пакетов. Поток трафика выбирается классификатором, который направляет пакеты логическому экземпляру кондиционера пакетов. Измеритель используется (когда это применимо) для сравнения потока трафика с профилем. Состояние измерителя по отношению к конкретному пакету (например, соответствие или несоответствие профилю) может использоваться для маркировки, отбрасывания или формовки.

Когда пакеты выходят из кондиционера трафика граничного узла DS, для кода DS в каждом пакете должно быть установлено подходящее значение.

Рисунок 1 показывает блок-схему классификатора и кондиционера трафика. Отметим, что кондиционер трафика может не включать все 4 элемента. Например, в тех случаях, когда профили трафика не используются, пакеты могут проходить только через классификатор и измеритель.

                          +------------+
                          |            |-------------------+
                   +----->| Измеритель |                   |
                   |      |            |--+                |
                   |      +------------+  |                |
                   |                      V                V
             +---------------+        +--------+      +----------+
             |               |        |        |      |  Формов./|
пакеты =====>| Классификатор |=======>| Маркер |=====>| Отбрасыв.|=====>
             |               |        |        |      |          |
             +---------------+        +--------+      +----------+


Рисунок 1: Логическое представление классификатора пакетов и кондиционера трафика

2.3.3.1 Измерители

Измерители трафика сравнивают временные параметры потока пакетов, выбранных классификатором, с профилем трафика, заданным в TCA. Измеритель передает информацию о состоянии другим функциям кондиционирования для включения соответствующих операций по отношению к пакетам, которые соответствуют и не соответствуют профилю.

2.3.3.2 Маркировщики

Маркировщики пакетов устанавливают значения поля DS в заголовках пакетов, добавляя маркированные пакеты к соответствующему агрегату поведения DS. Маркировщик можно настроить на маркирование всех пакетов одним значением кода или маркировку каждого пакета с использованием одного из множества кодов, служащих для выбора PHB в группе PHB в зависимости от результата измерения. Изменение кода маркировщиком называют перемаркировкой.

2.3.3.3 Формовщики

Формовщики задерживают некоторые или все пакеты в потоке трафика для приведения этого потока в соответствие с профилем трафика. Формовщик обычно использует буфер конечного размера и пакеты могут отбрасываться после исчерпания буферной емкости.

2.3.3.4 Отбрасыватели

Отбрасыватели сбрасывают все или часть пакетов в потоке трафика для приведения потока в соответствие с профилем трафика. Этот процесс называют применением политики к потоку. Отметим, что отбрасыватель может быть реализован, как частный случай формовщика, путем установки нулевого (или достаточно малого) значения для размера буфера задержки.

2.3.4 Расположение кондиционеров трафика и классификаторов MF

Кондиционеры трафика обычно размещаются в DS на входных и выходных граничных узлах, но могут также размещаться на узлах внутри домена DS или в доменах, не поддерживающих DS.

2.3.4.1 Внутри исходного домена

Определим исходный домен, как домен, содержащий узел (или узлы), порождающий трафик, получаемый определенной службой. Источники трафика и промежуточные узлы внутри исходного домена моугут выполнять функции классификации и кондиционирования. Трафик, проходящий из исходного домена через границу, может быть промаркирован непосредственными источниками или промежуточными узлами до того, как пакеты покинут исходный домен. Эта операция называется предварительной маркировкой.

Рассмотрим пример компании, в соответствии с политикой которой, пакетам от CEO (Chief Executive Officer — исполнительный директор) следует присваивать высший приоритет. Хост CEO может маркировать поле DS всех исходящих пакетов значением DS, показывающим «высший приоритет». Кроме того, первый маршрутизатор, с которым соединен хост CEO, может классифицировать трафик и маркировать пакеты CEO корректным кодом DS. Такой трафик с высоким приоритетом также может быть кондиционирован неподалеку от источника так, чтобы ограничить уровень трафика с высшим приоритетом, пересылаемого от конкретного источника.

Маркировка пакетов вблизи источника трафика обеспечивает некоторые преимущества. Во-первых, источник трафика может принимать во внимание предпочтения приложений при решении вопроса о том, какие пакеты должны обрабатываться в первую очередь. Кроме того, классификация пакетов выполняется значительно проще, пока эти пакеты не были агрегированы с пакетами из других источников, поскольку число правил классификации, которые требуется использовать, в таких случаях существенно меньше.

Поскольку маркировка пакетов может осуществляться на множестве узлов, исходный домен DS отвечает за то, что агрегированный трафик в направлении домена DS его провайдера соответствует TCA. Дополнительные механизмы распределения ресурсов типа брокеров полосы или RSVP могут использоваться для динамического выпределения ресурсов отдельному агрегату поведения DS в сети провайдера [2BIT, Bernet]. Граничному узлу исходного домена следует также осуществлять мониторинг соответствия TCA, этот узел может при необходимости выполнять перемаркировку и формовку или применять для пакетов правила политики.

2.3.4.2 На границе домена DS

Потоки трафика могут классифицироваться, маркироваться или кондиционироваться иными способами на конце граничного соединения (выходной узел DS восходящего домена или входной узел DS нисходящего домена). В SLA между доменами следует указывать, какой из доменов отвечает за отображение потоков трафика на агрегаты поведения DS и кондиционирование таких агрегатов в соответствии с подходящим TCA. Однако входной узел DS должен предполагать, что входящий трафик может не соответствовать TCA, и должен быть готов к понуждению исполнения TCA в соответствии с локальной политикой.

Когда пакеты маркируются заранее и кондиционируются в восходящем домене, потенциально снижается число правил классификации и кондиционирования трафика в нисходящем домене DS. В таких обстоятельствах от нисходящего домена DS может потребоваться только перемаркировка или исполнение правил для входящих агрегатов поведения с целью исполнения TCA. Однако более изощренные типы сервиса, которые зависят от пути или источника, могут требовать классификации MF на входных узлах нисходящего домена DS.

Если входной узел DS подключен к восходящему домену, который не поддерживает DS, этот узел должен быть способен выполнить для входящего трафика все функции кондиционирования трафика.

2.3.4.3 В доменах, не поддерживающих DS

Источники трафика или промежуточные узлы в доменах, не поддерживающих DS, могут реализовать кондиционирование заранее помеченного трафика до того, как он попадет на вход нисходящего домена DS. Таким способом может быть скрыта локальная политика для классификации и маркировки.

2.3.4.4 На внутренних узлах DS

Хотя базовая архитектура предполагает, что комплексные функции классификации и кондиционирования трафика локализованы только на входных и выходных граничных узлах, реализация этих функций внутри сети не запрещается. Например, на трансокеанских каналах могут быть реализованы более жесткие правила доступа, требующие классификации MF, и кондиционирование на восходящем узле канала. Такое решение может ограничивать масштабирование по причине потенциально большого числа правил классификации и кондиционирования, которые нужно поддерживать.

2.4 Поведение на этапе

Поведение на этапе (PHB — Per-hop behavior) представляет собой описание наблюдаемого извне режима пересылки узла DS, применяемое к конкретному агрегату поведения DS. «Режим пересылки» представляет собой базовую концепцию в этом контексте. Например, в ситуации, когда только один агрегат поведения занимает канал, наблюдаемый режим пересылки (т. е., потери, задержки и их вариации) будет зачастую зависеть только от относительной загрузки канала (в предположении, что режим основан на снижающей объем работы дисциплине планирования). Существенные различия в поведении наблюдаются для тех случаев, когда множество агрегатов поведения полностью используют ресурсы буферизации и полосы на узле. PHB представляет собой способ, посредством которого узел выделяет ресурсы для агрегатов поведения, и располагается поверх базовых поэтапных механизмов распределения ресурсов, которые могут быть полезны для поддержки дифференцированного обслуживания.

Примером наиболее простого PHB является тот случай, когда гарантируется выделение минимальной полосы X% от суммарной полосы канала (в течение некого разумного интервала) для агрегата поведения. Этот PHB можно достаточно просто измерить в широком диапазоне условий конкуренции трафика. Несколько более сложный вариант PHB будет гарантировать минимальное выделение X% от полосы канала с пропорциональным беспристрастным распределением любой избыточной полосы. В общем случае PHB может зависеть от некоторых ограничений на характеристики трафика связанного агрегата поведения или характеристик других агрегатов поведения.

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

PHB реализуются на узлах посредством тех или иных механизмов управления буферизацией и планирования очередей пакетов. PHB определяются в терминах характеристик поведения, относящихся к правилам обслуживания, а не в терминах конкретных механизмов реализации. В общем случае для реализации конкретной группы PHB может подходить широкий спектр механизмов реализации. Более того, очевидно, что на узле может быть реализовано более одной группы PHB, используемой в домене. Группы PHB следует определять так, чтобы было возможно подходящее распределение ресурсов между группами; могут реализоваться встроенные механизмы одновременной поддержки двух и более групп. Определение группы PHB должно показывать возможные конфликты с документированными ранее группами PHB, которые могут помешать одновременной работе.

Как описано в документе [DSFIELD], PHB выбирается на узле путем отображения кода DS в принятом пакете. Стандартизованные PHB имеют рекомендованные значения кода. Однако общее пространство кодов больше, нежели пространство, доступное для рекомендованных значений стандартизованных PHB и [DSFIELD] оставляет возможность для локально настраиваемых отображений. Таблица отображений код->PHB может содержать отображения как 1->1, так и N->1. Все коды должны быть отображены на тот или иной PHB; в отсутствии какой-либо локальной политики коды, которые не отображаются на стандартизованные PHB, в соответствии со спецификацией PHB следует отображать на Default PHB.

2.5 Распределение сетевых ресурсов

При реализации, настройке, работе и администрировании поддерживаемых групп PHB на узлах домена DS следует эффективно разделять ресурсы этих узлов и межузловых каналов между агрегатами поведения в соответствии с политикой обслуживания в этом домене. Кондиционеры трафика могут дополнительно контролировать использование этих ресурсов с помощью исполнения TCA и, возможно, с использованием обратной связи с узлами и кондиционерами трафика в домене. Хотя широкий спектр функций может быть развернут без использования сложных средств кондиционирования (например, на основе только статических правил маркировки), такие функции, как исполнение правил, формовка и динамическая перемаркировка определяют поддержку услуг, обеспечивающих количественные метрики производительности.

Настройка взаимодействия между кондиционерами трафика и внутренними узлами должна осуществляться под административным контролем и может требовать операционного контроля с помощью протоколов и объектов управления. Существует множество возможных моделей такого контроля.

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

3. Рекомендации по заданию поведения на этапе

Базовые требования по спецификации поведения на этапах приведены в [DSFIELD]. В этом разделе требования детализируются путем описания дополнительных рекомендаций относительно спецификаций для PHB и групп. Это сделано, прежде всего, для обечпечения согласованности реализаций. Прежде, чем группа PHB будет предложена для стандартизации, следует выполнить эти рекомендации подобающим образом, что обеспечит целостность архитектуры.

4. Интероперабельность с узлами, не поддерживающими DS

Определим узел, не поддерживающий дифференциацию услуг (non-DS-compliant), как любой узел, который не интерпретирует поле DS в соответствии с [DSFIELD] и/или не поддерживает некоторые или все стандартизованные PHB (или PHB используемые в определенном домене DS). Такое поведение может быть результатом настройки узла или отсутствия поддержки соответствующих функций. Определим унаследованный узел, как специальный случай не поддерживающего DS узла, который реализует функции классификации и пересылки IPv4 Precedence в соответствии с [RFC791, RFC1812], но не соответствует DS. Значения предпочтений в октете IPv4 TOS осознанно сделаны совместимыми со значениями кодов селекторов класса, определенными в [DSFIELD], а режим рассылки с использованием предпочтений, определенный в [RFC791, RFC1812], совместим с требованиями Class Selector PHB, определенными в [DSFIELD]. Ключевым различием между унаследованным узлом и узлом, поддерживающим DS, является то, что унаследованный узел может интерпретировать или не интерпретировать биты 3-6 октета TOS (биты DTRC), как определено в [RFC1349]; на практике такой узел не будет интерпретировать эти биты в соответствии с [DSFIELD]. Мы предполагаем, что использование маркировки TOS, определенной в [RFC1349], в настоящее время не принято. Узлы, не совместимые с DS и не относящиеся к категории унаследованных, могут вести себя непредсказуемо по отношению к пакетам с отличными от нуля кодами DS.

Дифференциация обслуживания зависит от механизмов распределения ресурсов, обеспечиваемых реализациями PHB на узлах. Параметры качества обслуживания или гарантии уровня сервиса могут нарушаться при прохождении трафика через узлы или домены, не поддерживающие DS.

Рассмотрим два случая. Первый относится к использованию не поддерживающих DS узлов в доменах DS. Отметим, что пересылка с использованием PHB полезна, прежде всего, для контролируемого распределения дефицитных ресурсов узла или каналов. На высокоскоростных, слабозагруженных каналах максимальная задержка, вариации задержки и уровень потери пакетов пренебрежимо малы и использование не поддерживающего DS узла на восходящем конце такого канала может и не приводить к деградации сервиса. В более реалистичных условиях отсутствие пересылки с использованием PHB на узле может приводить к невозможности обеспечения малых задержек, низкого уровня потерь или требуемой полосы для проходящих через узел путей. Однако использование унаследованного узла может быть приемлемым вариантом, если домен DS ограничивается использованием только кодов селекторов класса, определенных в [DSFIELD], и предполагается, что конкретная реализация пересылки по предпочтениям на унаследованном узле обеспечивает режим пересылки, совместимый с услугами, предлагаемыми для проходящего через этот узел пути. Отметим, что важно ограничить использование кодов исключительно значениями Class Selector, поскольку унаследованный узел не обязан интерпретировать биты 3-5 в соответствии с [RFC1349], а это может вести к непредсказуемому поведению.

Второй случай относится к поведению сервиса, проходящего через домен, который не поддерживает DS. Для простоты аргументации предполагается, что не поддерживающий DS домен, не реализует функций кондиционирования трафика на граничных узлах. Следовательно, даже при условии присутствия внутри домена унаследованных узлов или узлов, поддерживающих DS, отсутствие правил, применяемых к трафику на границе домена, будет ограничивать возможности предоставления некоторых типов обслуживания через такой домен. Домен DS и домен, не поддерживающий DS, могут согласовать условия маркировки трафика, выходящего из домена DS, до входа в домен, который не поддерживает DS. Мониторинг выполнения заключенного соглашения может осуществляться путем выборки трафика взамен жесткого его кондиционирования. Когда известно о том, что не поддерживающий DS домен состоит из унаследованных узлов, восходящий домен DS может перемаркировать трафик дифференцированного обслуживания с использованием одного или нескольких кодов Class Selector. Когда информации о возможностях управления трафиком в нисходящем домене нет и отсутствует соглашение, выходной узел домена DS может принять решение о перемаркировке кодов DS с использованием нулевого значения в предположении, что не поддерживающий DS домен будет пытаться обеспечить однородное обслуживание пакетов с использованием доступных возможностей (best-effort).

Если не поддерживающий DS домен является партнером домена DS, трафик из домена, не поддерживающего DS, следует кондиционировать на входном узле домена DS в соответствии с подходящим SLA или правилами.

5. Вопросы групповой адресации

Использование дифференцированного обслуживания для трафика с групповой адресацией порождает множество вопросов. Во-первых, пакеты с групповой адресацией, которые входят в домен DS, могут на входном узле распределяться по множеству путей через некоторые сегменты домена в результате репликации пакетов с групповыми адресами. В таких случаях может потребляться больше сетевых ресурсов, нежели при обработке индивидуальных пакетов. Когда группы multicast являются динамическими, сложно заранее предсказать объем потребных сетевых ресурсов для обслуживания группового трафика из восходящей сети в ту или иную группу. В результате такой неопределенности может осложняться обеспечение гарантий обслуживания для отправителей группового трафика. Более того, может потребоваться резервирование кодов и PHB для исключительного использования с групповым трафиком, чтобы обеспечить изоляцию ресурсов от группового трафика.

Второй проблемой является выбор кода DS для групповых пакетов, прибывающих на входной узел DS. Поскольку такие пакеты могут выходить из домена DS через множество выходных узлов DS, являющихся партнерами разных нисходящих доменов, выбор используемого кода DS не следует осуществлять на основании запросов от нижестоящего домена DS, нарушающих партнерские SLA. При организации состояния классификации и кондиционирования на входном узле DS для принимаемого агрегата трафика с дифференцированным обслуживанием, который проходит через выходную границу домена, идентификация смежного нисходящего транзитного домена и специфика соответствующего партнерского SLA должны приниматься во внимание при выборе конфигурации (вопрос политики маршрутизации и стабильности инфраструктуры маршрутизации). В этом случае партнерские SLA с нисходящими доменами DS могут быть частично исполнены на входной границе восходящего домена, что позволит снизить нагрузку, связанную с классификацией и кондиционированием трафика на выходном узле восходящего домена. Это не совсем просто для группового трафика по причине динамической принадлежности к группам. Результатом может явиться воздействие на гарантии сервиса для индивидуального трафика. Одним из способов решения этой проблемы является заключение отдельного партнерского SLA для группового трафика и использование для групповых пакетов отдельного набора кодов или реализация требуемой классификации и кондиционирования трафика на выходных узлах DS для обеспечения предпочтительного выделения ресурсов индивидуальному трафику в соответствии с партнерским SLA для нисходящего домена.

6. Вопросы безопасности и туннелирования

В этом разделе рассматриваются вопросы безопасности, возникающие в связи с введением дифференцированного обслуживания, прежде всего, потенциальные атаки на службы (DoS) и потенциальные возможности несанкционированного обслуживания трафика (параграф 6.1). В дополнение к этому рассматривается дифференцированное обслуживание в присутствии IPsec (параграф 6.2) и требования к аудиту (параграф 6.3). Рассматриваются вопросы, связанные с использованием туннелей (как IPsec, так и иных).

6.1 Несанкционированное обслуживание и атаки на службы

Основной задачей дифференциации обслуживания является обеспечение возможности предоставления потокам трафика разного уровня сервиса в одной сетевой инфраструктуре. Для достижения результата могут использоваться различные методы управления ресурсами, но конечный результат должен заключаться в том, что обслуживание одних пакетов будет отличаться от обслуживания других (например, будет лучше). Отображение сетевого трафика на соответствующий режим, приводящий к иному (лучше или хуже) обслуживанию, задается, прежде всего, значением поля DS и, следовательно, злоумышленник может добиться улучшения обслуживания путем изменения поля DS для отображения трафика на режим, используемый для обеспечения лучшего обслуживания, или вставки пакетов с соответствующим значением поля DS. С учетом ограниченности ресурсов такой обман может служить для организации атак на службы, когда изменение или вставка пакетов ведет к исчерпанию ресурсов, доступных для пересылки других потоков трафика. Защита от таких «краж» и DoS-атак включает средства кондиционирования трафика на граничных узлах DS в сочетании с обеспечением защиты и целостности сетевой инфраструктуры домена DS.

Как описано в разделе 2, входные узлы DS должны кондиционировать весь трафик, входящий в домен DS, для обеспечения приемлемости имеющихся в пакетах кодов DS. Это означает, что коды должны соответствовать применимым TCA и принятой в домене политике обслуживания. Следовательно, входные узлы являются первой линией защиты от атак на службы, основанных на изменении кодов DS, поскольку успех такой атаки ведет к нарушению соответствующих TCA и принятой в домене политики обслуживания. Важно понимать, что любой, генерирующий трафик, узел домена DS является входным узлом для этого трафика и узел должен гарантировать допустимость всех кодов DS в порожденном этим узлом трафике.

Как политика обслуживания в домене, так и TCA могут требовать смены на входных узлах кода DS для некоторых пакетов (например, входной маршрутизатор может устанавливать для пользовательского трафика код DS в соответствии с подходящим SLA). Входные узлы должны кондиционировать весь остальной входящий трафик для обеспечения приемлемости кодов DS; пакеты с неприемлемыми кодами должны отбрасываться или значение кода DS должно меняться на приемлемое до пересылки пакета. Например, входной узел, получая трафик от домена, для которого нет соглашения об улучшенном обслуживании, может сбрасывать код DS в значение, принятое для Default PHB [DSFIELD]. Для разрешения использования некоторых кодов DS (например, соответствующих улучшенному обслуживанию) может потребоваться идентификация трафика, которая может быть выполнена техническими (например, IPsec) и/или иными (например, подключение входного канала к единственному заказчику) средствами.

Междоменное соглашение может снижать или сводить к нулю требования по кондиционированию входящего трафика, частично или полностью перенеся ответственность за приемлемые значения кодов DS во входящем трафике на нисходящий домен. В таких случаях входной узел домена может сохранять (избыточную) проверку кондиционирования для снижения зависимости от восходящего домена (например, такая проверка может предотвращать распространение DoS-атак, связанных с дифференцированным обслуживанием через границу домена). Если при такой проверке наблюдается нарушение условий со стороны восходящего домена, результат проверки следует записывать в системный журнал с указанием даты и времени приема пакета, IP-адресов отправителя и получателя, а также кода DS. На практике следует учитывать ограниченность такого контроля и затрату ресурсов на его реализацию.

Внутренние узлы домена DS могут опираться на значение поля DS для связывания трафика с дифференцированным обслуживанием и режимов, используемых для реализации улучшенного сервиса. Любой узел, выполняющий такое связывание, зависит от корректности работы домена DS по предотвращению приема трафика с неприемлемыми кодами DS. В соответствии с требованиями жизнеспособности получение пакетов с недопустимыми кодами DS не должно вызывать отказов (сбоев в работе) на узлах сети. Внутренние узлы не несут ответственности за исполнение политики обслуживания (или отдельных SLA) и, следовательно, от них не требуется проверять коды DS перед их использованием. Внутренние узлы могут выполнять некоторые проверки кондиционирования трафика по кодам DS (например, проверку кодов DS, которые никогда не используются на заданном канале) для повышения уровня безопасности и отказоустойчивости (например, устойчивость к атакам, связанным с изменением кодов DS, — краже услуг). При отрицательном результате проверки следует генерировать запись в системном журнале в указанием даты и времени, IP-адресов отправителя и получателя, а также кода DS. На практике следует учитывать ограниченность такого контроля и затрату ресурсов на его реализацию.

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

6.2 Взаимодействие с IPsec и туннелями

Протокол IPsec, как указано в [ESP, AH], не включает операций с полем DS заголовков IP в криптографические преобразования (в туннельном режиме поле DS внешнего заголовка IP IP IP не шифруется). Следовательно, изменение поля DS в сети не оказывает влияния на сквозную защиту IPsec, поскольку такое изменение не способно дать отрицательный результат при проверке целостности IPsec. В результате IPsec не обеспечивает какой-либо защиты от злонамеренного изменения поля DS (т. е., перехвата и изменения с участием человека — MITM), поскольку такое иземенение не оказывает влияния на уровень сквозной защиты IPsec. В некоторых средах возможность изменения поля DS без влияния на целостность данных IPsec может позволить создание скрытого канала; если требуется предотвратить создание таких каналов или снизить их полосу, домены DS следует настраивать так, чтобы требуемая обработка (например, установка одного значения для всех полей DS в чувствительном трафике) могла выполняться на выходных узлах DS, где трафик выходит из защищенных доменов.

Туннельный режим IPsec обеспечивает защиту для полей DS инкапсулированных заголовков IP. Пакет IPsec в туннельном режиме включает два заголовка IP — внешний заголовок, подставляемый на входе туннеля, и внутренний (инкапсулированный) заголовок от инициатора пакета. Когда туннель IPsec проходит (полностью или частично) через сети с дифференциацией услуг, промежуточные узлы оперируют с полем DS внешнего заголовка. На выходе из туннеля IPsec внешние заголовки удаляются и пакет пересылается (если нужно) с использованием внутреннего заголовка. Если внутренний заголовок IP не обрабатывается входным узлом DS при выходе из туннеля в домен DS, выходной узел туннеля является входным узлом DS для выходящего из туннеля трафика и, следовательно, для него должно осуществляться соответствующее кондиционирование (см. параграф 6.1). Если обработка IPsec включает достаточно строгую криптографическую проверку целостности инкапсулированного пакета (достаточность определяется локальной политикой безопасности), выходной узел туннеля может без опасений предполагать, что поле DS во внутреннем заголовке не изменилось по сравнению со значением на входе в туннель. Это позволяет выходному узлу туннеля, находящемуся в одном домене DS со входным узлом туннеля, без опасений относиться к пакетам, прошедшим такую проверку целостности, как к пакетам, полученным от узла в том же домене DS, избавляя входной узел домена DS от необходимости кондиционирования трафика, которое требуется в противном случае. Важным следствием этого является то, что незащищенные каналы, являющиеся внутренними по отношению к домену DS, могут быть защищены с помощью достаточно надежного туннеля IPsec.

Этот анализ и сделанные выводы применимы ко всем протоколам туннелирования, которые обеспечивают контроль целостности, но уровень защищенности поля DS во внутреннем заголовке зависит от строгости контроля целостности, обеспечиваемого протоколом туннелирования. При отсутствии достаточных гарантий для туннеля, транзитные узлы которого могут находиться за пределами домена DS (иначе говоря, уязвимы), инкапсулированные пакеты должны трактоваться, как на входном узле DS при доставке пакетов из-за пределов домена.

Протокол IPsec в настоящее время требует, чтобы поле DS внутреннего заголовка не изменялось при декапсуляции IPsec на выходном узле туннеля. Это предотвращает возможность использования измененых значений поля DS внешнего заголовка для организации утечки или атаки на службы через оконечную точку туннеля IPsec, поскольку все изменения полей внешнего заголовка отбрасываются на выходе из туннеля. Данный документ не меняет указанного требования IPsec.

Если спецификация IPsec в будущем разрешит выходным узлам туннелей менять поле DS во внутреннем заголовке IP в соответствии со значением поля DS во внешнем заголовке (т. е., полностью или частично копировать внешнее поле DS в одноименное поле внутреннего заголовка), потребуется дополнительное рассмотрение этого вопроса. Для туннелей, расположенных полностью в одном домене DS и обеспечивающих адекватную защиту от изменения внешнего поля DS, ограничивать изменение внутреннего поля DS будет только политика обслуживания в домене. В противном случае выходной узел домена, выполняющий такие изменения, будет действовать, как входной узел DS для выходящего из туннеля трафика и должен передавать входному узлу ответственность за кондиционирование трафика, включая защиту от утечки и атак на службы (см. параграф 6.1). Если туннель входит в домен DS на узле, который не совпадает с выходным узлом туннеля, тогда выходной узел туннеля может зависеть от того, насколько входной узел DS восходящего направления обеспечивает приемлемость внешнего поля DS. Даже в этом случае существуют способы проверки, которые доступны выходному узлу туннеля (например, проверка согласованности внутреннего и внешнего кода DS для шифрованного туннеля). Любые негативные результаты таких проверок должны фиксироваться системой аудита с генерацией записи в журнал аудита, включающей дату и время получения пакета, адреса отправителя и получателя, а также недопустимое значение кода DS.

Туннель IPsec с точки зрения архитектуры можно представлять по крайней мере в двух видах. Если туннель рассматривается как виртуальный провод с одним интервалом пересылки, действия промежуточных узлов по пересылке туннелируемого трафика не следует делать видимыми за пределами оконечных узлов туннеля и, следовательно, поле DS не следует менять в процессе декапсуляции. . И напротив, при рассмотрении туннеля, как многоэтапной системы пересылки трафика, изменение поля DS при декапсуляции может оказаться желательным. Примером второго варианта является ситуация, когда туннель завершается на внутреннем узле домена DS, для которого администратор не хочет использовать логику кондиционирования трафика (т. е., желает упростить управление трафиком). Это может быть реализовано путем использования кода DS из внешнего заголовка IP, который устанавливается при кондициоировании трафика на входном узле туннеля, в качестве значения кода DS внутреннего заголовка IP, что позволяет перенести ответственность за кондиционирование трафика с выходного узла туннеля IPsec на соответствующий входной узел DS (который должен выполнять эту функцию для трафика до инкапсуляции).

6.3 Аудит

Не все системы, поддерживающие дифференцированное обслуживание, будут реализовать аудит. Однако, если поддержка дифференцированного обслуживания встроена в систему, поддерживающую аудит, реализации дифференцированного обслужвания также следует поддерживать аудит. Если такая поддержка присутствует, реализация должна позволять администратору системы включать или отключать аудит для дифференцированного обслуживания в целом и может поддерживать такое управление на уровне отдельных частей.

В большинстве случаев гранулярность аудита определяется локальными требованиями. Однако некоторые события упомянуты в этом документе, как протоколируемые и для каждого из таких событий определен минимальный набор информации, которую следует помещать в журнал аудита. Допускается также включение в журнал дополнительной информации (например, сведений о пакетах, связанных с теми, которые вызвали запись в журнал аудита). Кроме того, записи в журнал аудита могут быть связаны с другими событиями, не упомянутыми явно в этом документе. Не задается требований, заставляющих получателя передавать какие-либо сообщения соответствующему отправителю при обнаружении заносимого в журнал аудита события, поскольку введение такого требования создавало бы потенциальную угрозу атак на отказ служб (DoS).

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

Этот документ основан на ранних работах Steven Blake, David Clark, Ed Ellesson, Paul Ferguson, Juha Heinanen, Van Jacobson, Kalevi Kilkki, Kathleen Nichols, Walter Weiss, John Wroclawski и Lixia Zhang.

Авторы выражают свою признательность за полезные комментарии и предложения Kathleen Nichols, Brian Carpenter, Konstantinos Dovrolis, Shivkumar Kalyana, Wu-chang Feng, Marty Borden, Yoram Bernet, Ronald Bonica, James Binder, Borje Ohlman, Alessio Casati, Scott Brim, Curtis Villamizar, Hamid Ould-Brahi, Andrew Smith, John Renwick, Werner Almesberger, Alan O'Neill, James Fu и Bob Braden.

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

  1. [AH] S. Kent, «IP Authentication Header», RFC 4302, December 2005
  2. [ATM] ATM Traffic Management Specification Version 4.0 <af-tm-0056.000>, ATM Forum, April 1996.
  3. [Bernet] Y. Bernet, P. Ford, R. Yavatkar, F. Baker, L. Zhang, M. Speer, R. Braden, B. Davie, J. Wroclawski, E. Felstaine, «A Framework for Use of RSVP with Diff-serv Networks», RFC 2998, November 2000
  4. [DSFIELD] K. Nichols, S. Blake, F. Baker, D. Black, «Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers», RFC 2474, December 1998.
  5. [EXPLICIT] D. Clark, W. Fang, «Explicit Allocation of Best Effort Packet Delivery Service», IEEE/ACM Trans. on Networking, vol. 6, no. 4, August 1998, pp. 362-373.
  6. [ESP] S. Kent, «IP Encapsulating Security Payload (ESP)», RFC 4303, December 2005
  7. [FRELAY] ANSI T1S1, «DSSI Core Aspects of Frame Rely», March 1990.
  8. [RFC791] J. Postel, «Internet Protocol», STD 5, RFC 791, September 1981
  9. [RFC1349] P. Almquist, «Type of Service in the Internet Protocol Suite», RFC 1349, July 1992.
  10. [RFC1633] R. Braden, Clark, D. and S. Shenker, «Integrated Services in the Internet Architecture: An Overview», RFC 1633, July 1994.
  11. [RFC1812] F. Baker, «Requirements for IP Version 4 Routers», RFC 1812, June 1995.
  12. [RSVP] B. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin, «Resource ReSerVation Protocol (RSVP) — Version 1 Functional Specification», RFC 2205, September 1997.

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

Steven Blake
Torrent Networking Technologies
3000 Aerial Center, Suite 140
Morrisville, NC 27560
Phone: +1-919-468-8466 x232
EMail: moc.tentnerrot@ekalbls

David L. Black
EMC Corporation
35 Parkwood Drive
Hopkinton, MA 01748
Phone: +1-508-435-1000 x76140
EMail: moc.cme@divad_kcalb

Mark A. Carlson
Sun Microsystems, Inc.
2990 Center Green Court South
Boulder, CO 80301
Phone: +1-303-448-0048 x115
EMail: moc.nus@noslrac.kram

Elwyn Davies
Nortel UK
London Road
Harlow, Essex CM17 9NA, UK
Phone: +44-1279-405498
EMail: ku.oc.letron@dnywle

Zheng Wang
Bell Labs Lucent Technologies
101 Crawfords Corner Road
Holmdel, NJ 07733
EMail: moc.sbal-lleb@gnawhz

Walter Weiss
Lucent Technologies
300 Baker Avenue, Suite 100
Concord, MA 01742-2168
EMail: moc.tnecul@ssieww

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

Николай Малых, moc.milib@hkylamn