Кратко

  • RFC 5160 строит межоператорские гарантии из обязательств за одну доменную область и допускает, что MQC-плоскость имеет разрывы; наличие IP-связности не подтверждает наличие требуемого QoS-маршрута.
  • Оператору, продающему конечную услугу, нужен отдельный журнал перехода между QoS и best effort, фактических маршрутов в обе стороны, локальных измерений, допуска нагрузки и ответственности за восстановление.

Самый опасный отказ не всегда выглядит как отказ. Пакеты продолжают доходить, монитор доступности зелёный, а поток уже покинул плоскость качества обслуживания и идёт как обычный best effort.

Почему RFC сохраняет достижимость

В исходных требованиях RFC 5160 best effort остаётся главным сервисом. Если пути с запрошенным качеством до назначения нет, назначение не должно становиться недоступным. Это разумная защита связности и важная граница для доказательств.

Успешный ping или установленная сессия показывают достижимость. Они не показывают, что все домены пути используют совместимые локальные классы, что нагрузка допущена в пределах согласованной ёмкости или что суммарные задержка, вариация и потери отвечают запросу приложения.

MQC-плоскость в документе может иметь дыры и изолированные домены. Частичное связное покрытие уже даёт пользу и может расширяться. Но присоединение нового домена или исчезновение связи в плоскости меняет состав услуги, даже если обычная маршрутизация быстро нашла обход.

Однодоменная ответственность не следует за обходом автоматически

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

Кроме того, локальная смена соглашения затрагивала бы множество удалённых обещаний. Поставщик не мог бы свободно расторгнуть или изменить собственный договор — ловушка SP chain привела бы к «замораживанию» инфраструктуры.

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

Общая MQC не закрывает пробел

Локальная QoS-класс l-QC описывается односторонней задержкой, её вариацией и долей потерь. Соседи связывают свои классы, если они соответствуют одной Meta-QoS-Class. Решение принимается по знанию своей и соседской сети; сведения дальше одного домена не нужны.

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

Даже если домены распространяют свои числовые вклады и входной оператор складывает их, расчёт принадлежит конкретной последовательности и времени. Новый маршрут не наследует старую сумму. Обратный путь может идти через другие сети; межоператорские договорённости в модели однонаправленные.

Выбор наилучшего объявленного пути тоже способен ухудшить его. Если все граничные маршрутизаторы направят трафик в один вариант, возникнет описанный QA-rush. Значит, объявление, выбор, установленный маршрут и измеренный результат — четыре разных свидетельства.

Как отличить деградацию от потери класса сервиса

Запись должна содержать запрос клиента, момент перехода, причину выбора best effort или MQC-пути, фактические маршруты туда и обратно, версии двусторонних соглашений, граничные отображения l-QC, согласованную ёмкость и допущенную нагрузку, локальные окна измерения, итог на концах и план восстановления.

Такая запись позволяет честно сказать: связь сохранилась, но гарантия временно не подтверждена. Она также отделяет локальное нарушение от решения собрать путь, где каждый домен соответствует своей границе, а общий предел приложения всё равно превышен.

Источники