Auto-bandwidth и admission control

Теоретические основы и архитектура

Реальный трафик меняется в течение суток: пик может быть многократно выше ночного уровня. Статическое резервирование RSVP-TE ведёт к избыточному или недостаточному учёту полосы. Auto-Bandwidth подстраивает резервирование под нагрузку. Головной узел с заданным интервалом измеряет трафик туннеля (sampling interval, по умолчанию 300 с на Cisco и Junos) и за окно adjust-interval (по умолчанию 24 часа на обеих платформах) выбирает максимум усреднённых измерений. Если он отличается от текущего резервирования больше порога (threshold) и укладывается в min/max, туннель перестраивается по make-before-break: новый LSP сигнализируется с тем же SESSION и новым LSP ID, трафик переключается и только потом снимается старый LSP. MBB снижает потери при переключении, но не гарантирует их отсутствия. DS-TE делит ёмкость линка на Class-Type (например, CT1 для голоса, CT0 для остального) и позволяет резервировать полосу отдельно по классам.

Резервация не равна нагрузке

Полоса в RSVP-TE - это учётная величина в плоскости управления: она вычитается из unreserved bandwidth в TED, но ничего не ограничивает в плоскости данных. LSP с резервацией 50 Мбит/с может пропустить 400 Мбит/с, и маршрутизатор не сбросит ни одного пакета на этом основании; узким местом станет только очередь интерфейса. Поэтому резервация имеет смысл лишь в двух случаях: когда она отражает реальную нагрузку и когда все туннели честно её заявляют. Вручную поддерживать такое соответствие невозможно: нагрузка меняется в течение суток в разы. Это и решает Auto-Bandwidth.

Как работает Auto-Bandwidth

Головная точка периодически замеряет объём трафика, попадающего в туннель (счётчики туннельного интерфейса или LSP), и по ним корректирует резервацию. Два интервала не надо путать:

• Интервал замера (sampling): как часто снимается счётчик. Cisco задаёт mpls traffic-eng auto-bw timers frequency (по умолчанию 300 с), Junos - statistics interval (по умолчанию 300 с), статистика должна быть включена и для auto-bandwidth.
• Интервал подстройки (adjust interval): окно, за которое выбирается максимум среди усреднённых замеров. Cisco - auto-bw frequency на туннеле, Junos - adjust-interval; значение по умолчанию на обеих платформах 24 часа (86400 с), типичные боевые значения - от десятков минут до нескольких часов.

В конце окна голова сравнивает максимальную усреднённую нагрузку с текущей резервацией. Если разница превышает порог (Cisco adjustment-threshold, Junos adjust-threshold, в процентах) и новое значение укладывается в диапазон минимум-максимум (min-bw/max-bw, minimum-bandwidth/maximum-bandwidth), запускается перестроение. Для быстрой реакции на резкий рост используется счётчик переполнений: если несколько замеров подряд (overflow limit) превышают порог, подстройка происходит досрочно, не дожидаясь конца окна. То же работает на понижение (underflow limit в Junos).

Режим только сбора (collect-bw на Cisco, monitor-bandwidth на Junos) подсчитывает статистику, не меняя резервацию: полезно, чтобы подобрать пороги до включения.

Make-before-break и учёт полосы

Изменение резервации выполняется без обрыва трафика: головная точка сигнализирует новый LSP с тем же SESSION и новым LSP ID, получает Resv, переключает трафик и только затем делает PathTear старого. Стиль SE позволяет новому и старому LSP на общих линках делить одну резервацию, поэтому полоса считается как максимум, а не сумма: расширение с 100 до 180 Мбит/с требует на общих линках 180, а не 280 Мбит/с. Если же новый путь не пересекается со старым, полоса нового занимается дополнительно на время перехода.

Если резервации не хватает, подстройка не удаётся: старый LSP продолжает работать с прежней полосой, а голова повторяет попытку в следующем интервале. Реальная нагрузка при этом уже выше резервации, и остальные туннели по TED видят занятую только часть линка. Это основной риск Auto-Bandwidth: без мониторинга отказов подстройки получается недоучёт и перегрузка. Мониторьте события неуспешного resize (syslog, SNMP) наряду с загрузкой интерфейсов.

Побочные эффекты: каждая подстройка - это сигнализация (Path/Resv и PathTear) и флудинг TE LSA; при тысячах туннелей и короткой частоте возникает шторм обновлений. Одинаковый интервал на всех туннелях синхронизирует подстройки; на практике вносят случайность через разные значения таймеров или отложенный запуск. Неуспешный resize не должен вести к "пинг-понгу" путей: порог (adjust-threshold) и минимальная дельта нужны для гистерезиса.

DS-TE: резервирование по классам

Обычная резервация делит один пул на всех: CT0. DS-TE (RFC 3564 - требования, RFC 4124 - протокол) вводит Class-Type (CT0-CT7): отдельные пулы, чтобы голосовой трафик не конкурировал за ту же полосу с данными. Каждая пара (CT, priority) называется TE-class, их до 8; соответствие задаёт администратор, и оно должно быть одинаковым во всём домене.

Ограничения по классам выражаются Bandwidth Constraints (BC0-BC7) и моделями их взаимодействия:

Пример для линка 800 Мбит/с: RDM, BC0 = 800 (CT0 + CT1 вместе), BC1 = 200 (CT1 отдельно). Голос (CT1) может занять до 200, остальное - данные; когда голоса 150, для данных остаётся 650. При MAM, например, BC0 = 600, BC1 = 200: голос не займёт больше 200, но и данные не получат больше 600, даже если голоса нет.

IGP передаёт BC в sub-TLV Bandwidth Constraints, а unreserved bandwidth - 8 значений, интерпретируемых как TE-class. RSVP получает объект CLASSTYPE (Class-Num 66): значение CT 1-7 в Path; отсутствие объекта означает CT0, поэтому DS-TE-узлы совместимы с обычными. Admission control проверяет не только общую свободную полосу, но и BC своего класса на нужном приоритете.