1.4 Сравнение с другими моделями
Описываемая в этом документе архитектура дифференцированного обслуживания может противоречить другим моделям дифференциации услуг. Мы классифицируем эти альтернативные модели по нескольким категориям — маркировка относительного приоритета, маркировка сервиса, коммутация меток, интегрированные службы/RSVP и статическая классификация для каждого этапа пересылки.
Примерами маркировки относительного приоритета могут служить маркировка IPv4 Precedence [RFC791], 802.5 Token Ring [TR] и принятая по умолчанию интерпретация классов трафика 802.1p [802.1p]. В этой модели приложения, хосты или узлы-посредники выбирают относительный уровень приоритета или «предпочтения» для пакета (например, приоритет по задержке или отбрасыванию), а сетевые узлы на пути передачи применяют соответствующий значению приоритета в поле заголовка режим пересылки. Наша архитектура может задавать роль и важность граничных узлов и кондиционеров трафика, благодаря этому наша модель обеспечивает более общий подход к поэтапному режиму пересылки, нежели относительный приоритет для задержки или отбрасывания.
Примером модели маркировки услуг является IPv4 TOS в соответствии с определением [RFC1349]. В этом примере каждый пакет маркируется запросом «типа обслуживания», который принимать значения «минимизировать задержку», «максимизировать пропускную способность», «максимизировать надежность» или «минимизировать стоимость». Узлы сети могут выбирать путь маршрутизации или режим пересылки, который подходит для запрошенного типа обслуживания. Эта модель имеет тонкие отличия от нашей архитектуры. Отметим, что мы не описываем использование поля DS в качестве входной информации для выбора маршрута. Маркировка TOS, определенная в [RFC1349], является весьма общей и не охватывает весь диапазон возможной семантики обслуживания. Более того, с каждым пакетом связывается запрос на обслуживание, а семантика некоторых услуг может зависеть от агрегированного режима пересылки последовательности пакетов. Модель маркировки услуг достаточно сложно приспособить к будущему росту числа и диапазона услуг (поскольку пространство кодов достаточно мало) и эта модель включает настройку конфигурации ассоциаций «TOS->режим пересылки» на каждом узле ядра сети. Стандартизация маркировки услуг предполагает стандартизацию предложений услуг, которая выходит за пределы компетентности IETF. Отметим, что при распределении пространства кодов DS, часть кодов зарезервирована для обеспечения возможности локального управления кодами, позволяющего провайдерам поддерживать локальную семантику маркировки услуг [RFC2474].
Примеры модели коммутации меток (или виртуальных устройств) включают Frame Relay, ATM и MPLS [FRELAY, ATM]. В этой модели поддерживается состояние пересылки и управления трафиком или QoS для потоков трафика на каждом интервале пути через сеть. Агрегаты трафика различной гранулярности ассоциируются с путем коммутации меток на входном узле, а пакеты/ячейки в каждом пути коммутации меток маркируются меткой пересылки, которая используется для поиска следующего интервала, а также режима пересылки и заменяется на каждом этапе пересылки. Эта модель обеспечивает тонкую гранулярность распределения ресурсов для потоков трафика, поскольку значения меток не имеют глобальной значимости и важны только для одного канала. Следовательно, можно резервировать ресурсы для агрегирования пакетов/ячеек, принятых на канале с определенной меткой, а семантика коммутации меток определяет выбор следующего интервала, позволяя передавать потоки трафика через специально созданные для них сетевые пути. Такое улучшение гранулярности связано с расходами на выполнение дополнительных требований по управлению и настройке для организации и поддержке путей коммутации меток. В дополнение к этому количество состояний пересылки, поддерживаемых на каждом узле, растет пропорционально числу краевых узлов сети в лучшем случае (в предположении путей коммутации меток multipoint-to-point) и пропорционально квадрату числа краевых узлов в худшем случае, когда обеспечиваются пути коммутации меток «от края до края» с гарантированными ресурсами.
Модель интегрированных услуг/RSVP основана на традиционной пересылке дейтаграмм по умолчанию, но позволяет отправителям и получателям обмениваться сигнальными сообщениями, которые позволяют организовать дополнительную классификацию пакетов и состояние пересылки на каждом узле между ними [RFC1633], [RSVP]. В отсутствии агрегирования состояний их число на каждом узле растет пропорционально числу одновременных резервирований, которое для скоростных каналов может быть очень большим. Эта модель также требует от приложений поддержки протокола RSVP. Для агрегирования состояний интегрированных услуг/RSVP в ядре сети могут использоваться механизмы дифференциации обслуживания [RFC2998].
Вариант модели интегрированных услуг/RSVP позволяет избавиться от требования поэтапной сигнализации за счет использования только «статической» классификации и политики пересылки, реализуемых на каждом узле пути через сеть. Политика изменяется административными методами, а не в ответ на изменение моментального состояния микропотоков в сети. Требования к состояниям для этого варианта потенциально жестче, нежели при использовании RSVP, особенно для магистральных узлов, поскольку число статических правил, которые могут применяться на узле в течение времени, может быть больше числа активных сеансов «отправитель-получатель», которые одновременно организуют резервирование состояния на узле. Хотя поддержка большого числа правил классификации и пересылки может может требовать вполне приемлемых вычислительных ресурсов, издержки на управление, связанные с организацией и поддержкой этих правил на каждом узле магистральной сети, через которую проходит трафик, могут быть достаточно велики.
Хотя мы противопоставили альтернативные модели и дифференциацию обслуживания, следует отметить, что эти методы могут использоваться для расширения режимов и семантики дифференцированного обслуживания в коммутируемой инфраструктуре канального уровня (например, ЛВС 802.1p, магистрали Frame Relay/ATM), соединяющей узлы DS, а также в том случае, когда в качестве внутридоменной технологии может использоваться MPLS. Ограничения, вносимые конкретной технологией канального уровня в отдельной зоне домена DS (или в сети, обеспечивающей доступ к доменам DS), могут загрублять дифференциацию обслуживания. В зависимости от отображения PHB на различные услуги канального уровня и способа распределения пакетов по ограниченному набору классов приоритета (или виртуальных устройств различных категорий и производительности), поддерживаться могут все или часть PHB (некоторые могут оказаться нежелательными).