4. Интероперабельность с узлами, не поддерживающими DS
Определим узел, не поддерживающий дифференциацию услуг (non-DS-compliant), как любой узел, который не интерпретирует поле DS в соответствии с [RFC2474] и/или не поддерживает некоторые или все стандартизованные PHB (или PHB используемые в определенном домене DS). Такое поведение может быть результатом настройки узла или отсутствия поддержки соответствующих функций. Определим унаследованный узел, как специальный случай не поддерживающего DS узла, который реализует функции классификации и пересылки IPv4 Precedence в соответствии с [RFC791] и [RFC1812], но не соответствует DS. Значения предпочтений в октете IPv4 TOS осознанно сделаны совместимыми со значениями кодов селекторов класса, определенными в [RFC2474], а режим рассылки с использованием предпочтений, определенный в [RFC791] и [RFC1812], совместим с требованиями Class Selector PHB, определенными в [RFC2474]. Ключевым различием между унаследованным узлом и узлом, поддерживающим DS, является то, что унаследованный узел может интерпретировать или не интерпретировать биты 3-6 октета TOS (биты DTRC), как определено в [RFC1349]; на практике такой узел не будет интерпретировать эти биты в соответствии с [RFC2474]. Мы предполагаем, что использование маркировки TOS, определенной в [RFC1349], в настоящее время не принято. Узлы, не совместимые с DS и не относящиеся к категории унаследованных, могут вести себя непредсказуемо по отношению к пакетам с отличными от нуля кодами DS.
Дифференциация обслуживания зависит от механизмов распределения ресурсов, обеспечиваемых реализациями PHB на узлах. Параметры качества обслуживания или гарантии уровня сервиса могут нарушаться при прохождении трафика через узлы или домены, не поддерживающие DS.
Рассмотрим два случая. Первый относится к использованию не поддерживающих DS узлов в доменах DS. Отметим, что пересылка с использованием PHB полезна, прежде всего, для контролируемого распределения дефицитных ресурсов узла или каналов. На высокоскоростных, слабозагруженных каналах максимальная задержка, вариации задержки и уровень потери пакетов пренебрежимо малы и использование не поддерживающего DS узла на восходящем конце такого канала может и не приводить к деградации сервиса. В более реалистичных условиях отсутствие пересылки с использованием PHB на узле может приводить к невозможности обеспечения малых задержек, низкого уровня потерь или требуемой полосы для проходящих через узел путей. Однако использование унаследованного узла может быть приемлемым вариантом, если домен DS ограничивается использованием только кодов селекторов класса, определенных в [RFC2474], и предполагается, что конкретная реализация пересылки по предпочтениям на унаследованном узле обеспечивает режим пересылки, совместимый с услугами, предлагаемыми для проходящего через этот узел пути. Отметим, что важно ограничить использование кодов исключительно значениями 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 или правилами.