Кратко

  • Поле TOS в IPv4 выражало желаемый приоритет и характеристики, не гарантируя ресурсов. DiffServ отвёл шесть бит под выбор поведения на каждом узле, а сложные решения о классификации, измерении, ограничении и перемаркировке вынес на границы.
  • AF и EF задают проверяемые строительные блоки, а не сквозное обещание. Принимающий домен вправе признать внешнюю метку, перевести её, сбросить в Default или отклонить согласно собственным ресурсам и договорённостям.

На границе пакет потерял не метку, а презумпцию

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

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

Таким образом, DiffServ позволил переносить краткое заявление, но не право распоряжаться чужими буферами.

TOS сообщал пожелание с 1981 года

В RFC 791 заголовок IPv4 получил октет Type of Service. Три бита задавали precedence, другие указывали предпочтение низкой задержки, высокой пропускной способности или надёжности. Приложение могло описать желаемое качество абстрактно, не зная технологии каждой транзитной сети.

Но даже Network Control precedence предназначался для применения внутри сети. Фактическое использование и контроль оставались обязанностью этой сети. Если уровень представлял ценность, оператор должен был ограничить доступ к нему. Возможность записать значение не доказывала полномочие.

RFC 1349 в 1992 году назвал TOS строго рекомендательным механизмом, непригодным для запроса гарантий. У некоторых сетей не было иного маршрута, а поле не выражало требуемое число мегабит в секунду. Намерение могло подсказать выбор; оно не создавало недостающую полосу.

Масштаб появился благодаря агрегатам

Хранить в каждом магистральном маршрутизаторе состояние каждого приложения и клиента было трудно масштабировать. RFC 2474 и RFC 2475, опубликованные в декабре 1998 года, построили Differentiated Services вокруг агрегатов трафика.

Шесть старших бит бывшего октета TOS и поля Traffic Class в IPv6 стали полем DS. Значение DSCP выбирает на узле Per-Hop Behavior. Два младших бита позднее отошли ECN и не расширяют приказ DiffServ.

Кодовая точка не равна самому поведению. Несколько DSCP могут выбирать один PHB, а часть значений имеет чисто локальный смысл. PHB описывает наблюдаемую обработку агрегата на одном узле — планирование очереди, выделение буфера, правила потерь. Это деталь, из которой можно собрать услугу, а не готовая услуга от отправителя до получателя.

Сложность сосредоточилась там, где меняется доверие

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

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

Шесть бит остаются компактными именно потому, что личность клиента, квота, цена, ответственность и установленная ёмкость хранятся в классификаторах, конфигурации и соглашениях.

AF не определил объём «гарантии»

RFC 2597 в 1999 году описал Assured Forwarding: четыре класса, в каждом три уровня приоритета отбрасывания. При перегрузке пакет с более высоким drop precedence внутри класса должен теряться вероятнее. Пакеты одного микропотока нельзя переставлять только из-за различий этого уровня.

Названия AF похожи на всемирную линейку тарифов, однако RFC не назначает классам доли полосы или памяти. Фактическая уверенность зависит от выделенных ресурсов, нагрузки и профиля на входе. Узел может соответствовать DiffServ и вовсе не реализовывать AF.

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

EF обещает только поведение одного узла

RFC 3246 в 2002 году заново сформулировал Expedited Forwarding. Если узел заявляет EF, он должен обслуживать агрегат не ниже настроенной скорости и позволять оценить поведение при ограниченных условиях.

Документ тут же проводит границу: он определяет один узел. Поведение их совокупности находится вне его области, а реализация EF не обязательна для совместимости с DiffServ. Низкая задержка на маршруте требует ресурсов и контролируемого входного потока на каждом участке. Добросовестный первый маршрутизатор не способен выделить очередь на втором.

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

Коммерческое обязательство осталось вне заголовка

RFC 2475 говорил о SLA и Traffic Conditioning Agreement. RFC 3260 позднее пояснил: договор может включать цену, доступность и другие деловые условия, которые не определяет DiffServ. Для технических параметров были выделены более узкие SLS и TCS.

IETF мог стандартизировать поле и соответствующее поведение узла, но не решить, какой клиент купил услугу и сколько мощности установят соседние компании. Если соглашения об улучшенном обслуживании нет, входной домен может сбросить DSCP в Default. Неприемлемое значение можно изменить или отклонить; неизвестное после входного контроля обычно должно получить обычное поведение, а не случайную привилегию.

Подделываемая метка требует проверки

DSCP не удостоверяет отправителя. Конечная система может поставить привилегированный код сама, а злоумышленник — изменить незащищённый внешний заголовок. RFC рассматривают кражу услуги как угрозу: если ложный привилегированный поток исчерпывает зарезервированные ресурсы, он превращается в отказ в обслуживании.

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

При переходе к Wi-Fi значение пришлось переводить

RFC 7657 в 2015 году отметил, что конечная система не может знать, какой PHB выбирает Class Selector в конкретной сети, тем более по всему маршруту. CS1 может означать Lower Effort, Default, более высокий уровень, перемаркировку или отбрасывание.

RFC 8325 в 2018 году показал границу между IP и IEEE 802.11. DSCP и User Priority принадлежат разным пространствам кодов. Точка доступа выполняет отображение, а при отсутствии соответствующей услуги может выбрать Default. Скопировать число — ещё не значит перенести обязательство.

Общий слой остался достаточно тонким

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

Пакет мог попросить. Работающий узел мог ответить. Заголовок не получил права приказывать следующему домену — и именно поэтому система могла масштабироваться.

Источники и пределы доказательств

RFC 791 и RFC 1349 описывают TOS; RFC 2474 и RFC 2475 — поле и архитектуру; RFC 2597 и RFC 3246 — AF и EF; RFC 3260, RFC 7657 и RFC 8325 — последующие уточнения. Они не доказывают современные настройки операторов, права клиента, частные договоры, распространённость или измеренную сквозную производительность.