Traffic Engineering помогает нам решать проблемы оценки и оптимизации производительности IP‑сетей, но при этом требует недюжинного понимания сетевых технологий и протоколов, которые используются в больших сетях. В прошлый раз мы остановились на магии работы PCE‑контроллера и затронули Stateless и Stateful PCE. Как здесь не вспомнить комикс от Go Chronicles, посвящённый Stateful:
Конечно, на самом деле PCE‑контроллер общается не так, а с использованием PCEP — Path Computation Element Communication Protocol, который описан в RFC 5440. Так что самое время начать с него вторую часть нашей истории про Traffic Engineering.
Заодно напомню полное содержание этой энциклопедии Traffic Engineering:
Основы, распределённый и централизованный расчёт туннелей, магия РСЕ
Основы РСЕР и Stateful PCE, Междоменный RSVP‑TE, новый взгляд на РСЕСС
Жизнь после MPLS (TBD)
Пройдёмся по основам РСЕР
Это протокол клиент‑серверного взаимодействия (запрос‑ответ).
Он работает поверх ТСР (порт 4189), на который возлагаются вопросы надёжной доставки сообщений, а также безопасности.
Это сессионный протокол: PCE/PCC открывают сессию, узнают поддерживаемые параметры (capabilities), все сообщения привязаны к конкретной сессии.
-
Сначала были определены только 7 сообщений:
Open
Keepalive
Path Computation Request (запрос на расчёт между узлами и ограничения)
Path Computation Reply (рассчитанный путь в виде ERO, метрики пути либо отказ)
Notification
Error
Close
Отдельно отмечу, что сообщение Keepalive было специально внедрено как механизм отслеживания состояния сессии (не требует ответа).
Каждое сообщение состоит из определённого набора объектов: OPEN, RP (request Parameters), END‑POINTS, BANDWIDTH, METRIC, ERO, RRO, LSPA (LSP Attributes), NOTIFICATION, PCEP‑ERROR и т. д. Форматы этих объектов описаны в секции 7 RFC 5440.
Объект, как правило, состоит из заголовка, флагов и набора опциональных TLV.
Добавлю, что все эти сообщения используются в Stateless PCE: в нём контроль за состоянием LSP остается за РСС. А для Stateful PCE протокол PCEP был существенно дополнен новыми сообщениями и объектами.
Stateful РСЕ
Итак, из основ РСЕР становится понятно, что первоначального набора сообщений и объектов совершенно недостаточно для Stateful‑режима работы РСЕ, где требуется помнить состояние уже рассчитанных LSP и иметь возможность модифицировать их (синхронизация LSP). Например, мы не можем делать открытие уже открытой ранее сессии, чтобы её модифицировать.
Прежде чем погружаться в глубины Stateful PCE, обратимся к первоисточникам, которые дают базовые уточнения по организации его работы. Во‑первых, помимо TED необходим дополнительный конструкт, в котором будут храниться параметры для всех рассчитанных и активных LSP (атрибуты, такие как путь, используемые ресурсы, ограничения), — он называется LSP State Database, или LSP‑DB. Если сформулировать иначе, то в LSP‑DB РСЕ хранит состояние активных LSP. Эта информация даёт возможность РСЕ учитывать зависимости между существующими LSP и новыми. Но это еще не всё, Stateful РСЕ может быть нескольких вариантов:
Stateful PCE — здесь всё соответствует уже созданному нами описанию, это просто РСЕ, хранящий состояние сети.
Passive Stateful PCE — использует информацию о состоянии LSP для расчёта, но при этом не участвует в модификации параметров LSP на РСС. На практике используется крайне редко.
Active Stateful PCE — использует информацию о состоянии LSP для расчёта, модифицирует параметры LSP на РСС. Это основной вариант использования.
Операция, которая разрешает РСЕ модифицировать параметры LSP на РСС, называется делегация (delegation). Перефразируя, LSP делегируются РСЕ. Обратная операция называется отзывом (revocation).
Если подразумевается, что LSP делегированы РСЕ по умолчанию, то РСЕ может сразу приступать к их модификации, и такая операция называется РСЕ‑инициация (PCE Initiation). В RFC 8051 также описываются сценарии, в которых Stateful PCE может принести пользу.
Теперь обратимся теперь к базису, который позволит реализовать виды Stateful PCE, — к необходимым модификациям РСЕР.
Для модели Stateful PCE добавили следующие сообщения:
Path Computation State Report (PCRpt) — посылается РСС к РСЕ для отчёта о статусе LSP (путь, полоса, статус…).
Path Computation Update Request (PCUpd) — посылается от РСЕ к РСС, для модификации параметров одного или нескольких LSP.
Я уже говорил, что клиенты (PCC) могут находить РСЕ благодаря специальным анонсам в IGP. Для Stateful PCE в них добавили новое sub‑TLV:
Bit Capability
‑- ‑--‑--‑--‑--‑--‑--‑--‑-
11 Active stateful PCE capability
12 Passive stateful PCE capability
Анонс Stateful PCE capability в IGP
Вот ещё пара диаграмм из RFC 8231 для иллюстрации принципов работы Stateful PCE и лучшего их понимания.
Мы видим, что ключевым моментом для сигнализации делегирования либо явного отзыва LSP является флаг Delegate.
RFC 8231 даёт очень важные указания насчёт обеспечения отказоустойчивости в случае нескольких РСЕ:
In order to allow the backup to operate in a hot‑standby mode and avoid the need for State Synchronization in case the primary fails, the backup receives all LSP State Reports from a PCC.
Т.е. резервный РСЕ должен также принимать LSP State Reports от всех РСС (маршрутизаторов), чтобы в случае выхода из строя основного РСЕ быстро начать работу без фазы синхронизации состояния.
Что будет происходить с делегированием LSP в случае сбоя РСЕ? RFC 8231 также описывает соответствующий алгоритм:
Если с активным РСЕ происходит сбой, но РСЕ восстанавливается в течение Redelegation Timeout (по умолчанию это 30 сек), то статус делегирования и состояние LSP остаются неизменными. Проще говоря, считаем, что всё нормально.
Если с активным РСЕ происходит сбой, но РСЕ НЕ восстанавливается в течение Redelegation Timeout, делегирование возвращается к РСС. Если РСС может ре‑делегировать LSP другому РСЕ и тот его примет, то состояние LSP не меняется (снова считаем — всё нормально).
А вот если РСС не сможет его ре‑делегировать другому РСЕ в течение State Timeout Interval (по умолчанию 60 сек), то состояние LSP изменится, он станет неактивным.И наконец, если есть резервный РСЕ, то Redelegation Timeout может быть установлен в 0, что значит немедленное ре‑делегирование, которое будет произведено в течение State Timeout Interval. Соответственно, состояние LSP не будет меняться (считаем — всё нормально).
Как видно из примера, ключевым сообщением для модификации параметров LSP является Path Computation Update Request (PCUpd). В нём содержатся разные объекты, описывающие атрибуты LSP и ограничения, но обязательно должен присутствовать SRP-объект с SRP‑ID, то есть уникальным идентификатором. Список остальных РСЕР‑объектов и их описание приведены в RFC 8231, секции 7 и 8.
РСС после получения PCUpd начинает инсталлировать его в forwarding plane, о чём может сообщить РСЕ сообщением PCRpt со статусом Going-up, либо посылкой PCRpt со статусом Up, когда LSP станет активным. Если же инсталляция не окончилась успехом, то РСС шлет РСЕ сообщение об ошибке PCErr с соответствующим кодом.
На практике, в случае использования РСЕ весьма распространённым является использование т. н. PCE‑Initiated LSP, которые описаны в RFC 8281. РСЕ сразу сообщает РСС атрибуты LSP в сообщении PCInitiate безо всякого предварительного делегирования:
Для сигнализации режима PCE‑Initiated используется новый флаг I (LSP‑INSTANTIATION‑CAPABILITY) в STATEFUL‑PCE‑CAPABILITY TLV (объект Open). PCE может инициировать такие LSP только тем PCC, которые продекларировали их поддержку через установку этого флага I. Модифицированное TLV:
РСС после инициализации LSP шлёт РСЕ подтверждение в виде сообщения PCRpt с установленным флагом делегирования (D==1). РСС не имеет права отзывать у РСЕ такие LSP, т.к. только РСЕ обладает полным контролем над ними. В RFC 8281 описаны два случая, когда контроль над таким LSP всё‑таки может вернуться к РСС. В секции 5.4 также прописана процедура удаления такого LSP, но для краткости изложения я её пропущу.
Надеюсь, эти примеры хорошо иллюстрируют принципы работы Stateful PCE. Stateful PCE поддерживается всеми известными вендорами для RSVP‑TE. А вот для ТЕ с использованием Segment Routing (SR Policy) — ситуация на текущий момент несколько иная.
Для стойких духом сетевых инженеров приложу несколько РСЕР‑дампов, собранных во время тестирования Сусанина. Они как раз сделаны c SR Policy — механизмом организации ТЕ в сетях с Segment Routing. Мы сознательно приняли решение не делать в Сусанине поддержки RSVP‑TE на текущий момент, но это принципиально не меняет логику работы РСЕР. Разница только в некоторых объектах и TLV.
Обмен РСЕР-сообщениями между Active Stateful PCE (172.16.5.6) и РСС одного вендора:
РСЕР-сообщение Open c одноимённым объектом:
РСЕР-сообщение Open, подробнее показаны опции PATH-SETUP-TYPE:
РСЕР-сообщение PCInitiate (от Active Stateful PCE к РСС) c необходимыми объектами:
SRP-объект с обязательным SRP-ID в сообщении PCInitiate (от Active Stateful PCE к РСС):
LSP-объект с PSLP-ID в сообщении PCInitiate (от Active Stateful PCE к РСС), обратите внимание на флаги:
End-Point-объект в сообщении PCInitiate (от Active Stateful PCE к РСС):
ERO-объект в сообщении PCInitiate (от Active Stateful PCE к РСС) для SR-MPLS, видны используемые SID:
ASSOCIATION-объект в сообщении PCInitiate (от Active Stateful PCE к РСС) для SR Policy в SR-MPLS:
Набор объектов в сообщении PCRpt (от РСС к Active Stateful PCE). Обратите внимание, что для каждого LSP свой PCRpt:
Ну и на закуску приведу несколько примеров выводов команд, связанных с PCE/PCEP с оборудования разных вендоров.
Вывод команд о состоянии РСЕР-сессии и статистики на оборудовании Huawei
[~lab2]dis pce protocol session verbose
Session IP : 10.255.2.231
Session ID : 225
State : UP
Keepalive Timer : 30s
Hold Timer : 120s
Peer Keepalive Timer : 30s
Peer Hold Timer : 120s
Session Capability : Stateful PCE-Init Segment-Routing
Session Preference : 0(NO)
Session Active Time : 2024-01-18 11:28:52
Last session down reason : Socket Close/Error Message Received
Notification Status : Normal
Maximum Segment Depth : 10
Dscp Value : 6
PCC Multipath Number : 64
PCE Multipath Number : 0
Delegate Timer Remain : -
State Timer Remain : -
Remaining Overload Time : -
[SNIP]
[~lab2]dis pce protocol statistics
Remote IP : 10.255.2.231
Session ID : 225
Message statistics
Sent Received
Open 5 5
Keepalive 7 7
Path computation request 0 0
Path computation response 0 0
LSP update 0 5
LSP report 5 0
PCE Initiate 0 5
Notification 0 0
Error 0 0
Close 0 0
Label update 0 0
Label report 0 0
StartTLS 0 0
Total 17 22
[~lab2]dis pce protocol sr-te policy
Endpoint : 192.168.226.155
Color : 1
Candidate-path Preference : 100
Path State : ACTIVE Protocol-Origin : PCEP
Discriminator : 1 Originator : 4200000002, ::FFFF: 10.255.2.231
PLSP-ID : 14223 Binding SID : 156713
Symbolic Path Name : to_somewhere
Policy Name : : to_somewhere
Candidate-path Name : : to_somewhere
Segment-List Count : 1
Segment-List Information
PathID : 1966937
Weight : 1
Operation State : ACTIVE
Hop Information
Index Hop Address Label
1 - 200532
2 - 41071
3 - 200321
[~lab2]dis sr-te policy binding-sid 156713
PolicyName : to_somewhere
Endpoint : 192.168.226.155 Color : 1
TunnelId : 1433656 TunnelType : SR-TE Policy
Binding SID : 156713 MTU : -
Policy State : Up State Change Time : 2023-11-30 06:21:14
Admin State : Up Traffic Statistics : Enable
BFD : SBFD Enable Backup Hot-Standby : Disable
DiffServ-Mode : -
Active IGP Metric : -
Candidate-path Count : 1
Candidate-path Preference: 100
Policy Name : to_somewhere
Candidate-path Name : to_somewhere
Path State : Active
Path Type : Primary
Protocol-Origin : PCEP(10)
Originator : 64086.59906, ::FFFF: 10.255.2.231
Discriminator : 1
Binding SID : 156713
GroupId : 213048
Compute Source : -
Template ID : -
CT0 Bandwidth : -
Active IGP Metric : -
Metric :
IGP Metric : -
TE Metric : -
Delay Metric : -
Hop Counts : -
Segment-List Count : 1
Segment-List :
Segment-List ID : 1966937
XcIndex : 2795481
List State : Up
BFD State : Up
EXP : 0
TTL : 250
DeleteTimerRemain : -
Weight : 1
Metric :
IGP Metric : -
TE Metric : -
Delay Metric : -
Hop Counts : -
Label : 200532, 41071, 200321 Вывод команд о состоянии РСЕР-сессии и статистики на оборудовании Juniper
lab> show path-computation-client active-pce detail
PCE 1
--------------------------------------------
General
PCE IP address
: 10.255.2.231
Local IP address
:192.168.228.153
Priority : 1
PCE status
: PCE_STATE_UP Session type
: PCE_TYPE_STATEFULACTIVE
LSP provisioning allowed : On
LSP cleanup timer : 300 [s]
Pcupdate empty ero action: routing-decision
P2MP LSP report allowed : Off
P2MP LSP update allowed : Off
P2MP LSP init allowed : Off
Session SRv6 Capable : No
PCE-mastership : main
PCE Traffic Steering : Off
Max unknown messages : 5
Keepalives received 1552
: Keepalives sent : 1552
Dead timer : 91 [s]
Elapsed as main current : 296888 [s]
Elapsed as main total 296888 [s]
:
Unknown msgs/min rate : 0
Session failures : 2
Corrupted messages : 0
Delegation timeout set : 30
Delegation timeout in : 0 [s]
Delegation failures : 0
Connection active : 46589 [s]
Counters
PCReqs Total: 0 last 5min: 0 last hour: 0
PCReps Total: 0 last 5min: 0 last hour: 0
PCRpts Total: 298 last 5min: 0 last hour: 0
PCUpdates Total: 0 last 5min: 0 last hour: 0
PCCreates Total: 0 last 5min: 0 last hour: 0
Timers
Local Keepalive timer: 30 [s] Dead timer: 120 [s] LSP cleanup timer: 300 [s]
Remote Keepalive timer: 30 [s] Dead timer: 120 [s] LSP cleanup timer: 0 [s]
Errors
PCErr-recv
PCErr-sent
PCE-PCC-NTFS
PCC-PCE-NTFS
Pcupdate empty ero action counters
Send-err : 0
Tear down path : 0
Routing decision : 0
Routing decision failed: 0
lab> show spring-traffic-engineering lsp destination 192.168.228.128 det
Name: to_somewhere-1
Tunnel-source: Path computation element protocol(PCEP)
Tunnel Forward Type: SRMPLS
Tunnel-template: to_somewhere-1
To: 192.168.228.128-10<c>
State: Up
Telemetry statistics:
Sensor-name: 192.168.228.128-a, Id: 3758096414
Path Status: NA
Outgoing interface: NA
Auto-translate status: Disabled Auto-translate result: N/A
BFD status: Up BFD name: V4-srte_bfd_session-30
Segment ID : 128
ERO Valid: true
SR-ERO hop count: 3
Hop 1 (Strict):
NAI: None
SID type: 20-bit label, Value: 200912
Hop 2 (Strict):
NAI: None
SID type: 20-bit label, Value: 41084
Hop 3 (Strict):
NAI: None
SID type: 20-bit label, Value: 200125
Total displayed LSPs: 1 (Up: 1, Down: 0)
lab> show route table inetcolor.0
192168.228.128-10<c>/64
*[SPRING-TE/7] 13:13:32, metric 1, metric2 2108
> to 172.16.16.167 via ae101.0, Push 200125, Push 41084, Push 200912(top)
to 172.16.11.213 via ae102.0, Push 200125, Push 41084, Push 200912(top) Настройки РСЕР на оборудовании Juniper:
lab> show configuration protocols pcep
pce-group TEST {
pce-type active stateful;
lsp-provisioning;
lsp-cleanup-timer 300;
spring-capability;
max-sid-depth 3;
}
pce 1 {
local-address 192.168.228.153;
destination-ipv4-address 10.255.2.231;
destination-port 4189;
delegation-priority 1;
pce-group TEST;
}
lab> show configuration protocols mpls
lsp-external-controller pccd;
[SNIP] Настройки РСЕР на оборудовании Huawei:
[~lab2 | begin pce
pce-client
capability initiated-lsp
capability segment-routing
association-type enable
timer state-timeout 300
connect-server 10.255.2.231
preference 7
source-interface LoopBack20 Теперь мы разобрались, в чём отличия Stateless PCE от Stateful PCE, какие сообщения есть в РСЕР и какие объекты они используют. Ну и как РСС может узнать о присутствии РСЕ.
В заключение этой части я бы хотел добавить несколько слов про важнейший компонент любого РСЕ‑контроллера, а именно про алгоритм расчёта путей (туннелей, LSP). Именно от него зависит, насколько оптимально будут использоваться ресурсы сети, какую отдачу вы получите от централизованного ТЕ на базе РСЕ.
Алгоритм, который мы сейчас используем в модуле расчёта путей Сусанина очень кратко описан в моём докладе на слайде 10.
Хороший обзор алгоритмов для ТЕ по состоянию на 2011 год сделан в книге Н.В.Булдыриной «Оптимизация сетей с многопротокольной коммутацией по меткам».
Также крайне интересен алгоритм BEST2COP.
Междоменный RSVP-TE
Необходимость иметь MPLS‑связность между различными доменами сети очевидна: организациям часто необходимо иметь их в силу экономических причин, либо предоставлять в роли операторов E2E‑сервисы (вспомним Inter‑AS VPN). Такие туннели/LSP часто называются interarea TE или Inter‑AS TE.
Полагаю, вы уже догадываетесь о сути проблемы — TED ограничена одним доменом… Соответственно, в случае распределённого ТЕ headend не может знать детали пути в других доменах и сформировать нужный ERO.
Первый подход к построению такого пути основан на использовании т. н. соединительных узлов (Stitching point). Иначе говоря, междоменный LSP строится из нескольких LSP, каждый из которых принадлежит своему домену. Соединительные узлы осуществляют 1:1-склейку этих LSP. Соответственно, количество soft или forwarding state на этих узлах пропорционально количеству LSP.
RFC 5150 описывает подробности и целевую схему:
В сообщении Path устанавливается флаг LSP Stitching Desired (LSP объект). Если исходящий маршрутизатор домена (маршрутизатор В на рисунке) готов сделать «склейку» LSP, он отвечает флагом LSP stitching ready в RRO объекте в Resv.
Второй подход построения междоменного LSP называется LSP nesting, когда в транзитном домене строится LSP, являющийся контейнером для E2E LSP из одного домена в другой. Отсюда и термин nest — это своеобразное гнездо, в котором лежат «яйца» — другие LSP. Один вендор также называет такой LSP forwarding adjacency. Этот вариант существенно легче с точки зрения требований по масштабируемости, т.к. в нём поддерживается 1: N forwarding state на транзитных маршрутизаторах. Однако при этом возникают побочные эффекты в виде трудностей в резервировании полосы пропускания (в силу 1: N LSP). Больше информации про этот вариант можно найти в RFC 4206 и RFC 4276.
Однако основная проблема для таких междоменных LSP для случая распределённого ТЕ заключается в вопросе: а как посчитать оптимальный путь в другом домене? Например, можно считать отдельно для каждого домена и получить на выходе неоптимальность для E2E LSP.
Альтернативный подход заключается в использовании т. н. crankback: если какой‑то маршрутизатор в домене не может посчитать требуемый путь, то он сигнализирует эту информацию об ошибке предыдущему маршрутизатору, и тот пытается просчитать альтернативный путь (см. RFC 4920).
Задача расчёта и построения междоменного LSP существенно облегчается в случае использования централизованного ТЕ с РСЕ. В этом случае РСЕ могут располагаться в каждом домене и связываться горизонтально (синхронизировать TED), либо объединяться посредством иерархического РСЕ (H‑PCE).
Области применения RSVP-TE
ТЕ на основе RSVP‑TE по сей день имеет широкое применение, особенно в операторских сетях с MPLS. Он решает множество задач, про которые я писал в первой части. Отдельно нужно отметить широкие возможности RSVP‑TE по организации различных вариантов защиты от сбоев:
Защита пути «из конца в конец», называемая также Hot Standby (HSB).
Защита линка.
Защита узла.
Поведение RSVP и работа механизмов защиты очень подробно расписаны в книгах MPLS Fundamentals и MPLS‑Enabled Applications, поэтому не буду останавливаться на этом детально.
Новый взгляд на SDN-архитектуру: PCE as Central Controller (PCECC)
В середине 2010-х группа инженеров задумалась о дальнейшем развитии и упрощении сетей. Как раз в это время появилась и стала активно обсуждаться технология SDN. Коллегам пришла идея о том, что РСЕ и SDN весьма хорошо совмещаются в общей архитектуре — так и появился концепт РСЕСС.
Основные идеи РСЕСС:
упрощение распределённой control plane за счет применения SDN;
централизованный расчёт и провижионинг LSP на маршрутизаторы (РСС) с существенным отличием от обычного провижионинга с РСЕ;
использование РСЕР как SBI‑интерфейса к РСС;
PCECC‑архитектура универсальна в отношении того, какой forwarding plane использовать: MPLS (RSVP‑TE), SR‑MPLS, SRv6.
Расширения РСЕР для РСЕСС
В чём же отличия в провижионинге LSP, для которого потребовалось расширение протокола РСЕР, от обычного варианта с РСЕ?
Они заключаются в том, что РСЕ наделяется дополнительными функциями:
Управление и контроль за пространством меток (label space для MPLS, SRGB для SR).
Провижионинг на маршрутизатор (РСС) label mapping (label forwarding state) с РСЕ, его модификации и удаление.
Для этого были определены новые функции (Function) для РСЕР:
Для определения поддержки РСЕСС в РСЕР ввели новую PCECC capability в PATH‑SETUP‑TYPE‑CAPABILITY TLV.
Для провижионинга появился новый объект в РСЕР: Central Controller Instruction (CCI), в котором записывается SID для создания label forwarding state на маршрутизаторе.
Последний рисунок достаточно наглядно показывает логику работы РСЕСС с провижионингом LSP на три маршрутизатора (РСС): мы видим загрузку меток через CCI‑объекты на РСС. Видно, что LSP имеет одинаковый идентификатор PLSP‑ID на всех РСС, однако идентификаторы CC‑ID для разных сессий с РСС — разные, что позволяет различать метки, отправляемые разным РСС. Каждый РСС после получения своего CCI и инсталляции его в forwarding plane отвечает подтверждением в виде PCRpt. Таким образом, РСЕСС отслеживает корректность создания LSP на разных РСС.
Другие возможные варианты работы также описаны в RFC 9050.
Немного забегая вперед, замечу, что для технологии Segment Routing (SR‑MPLS и SRv6) были также сделаны отдельные расширения в РСЕР, аналогичным образом они были модифицированы для РСЕСС.
Варианты применения РСЕСС весьма обширны и подробно описаны в юз‑кейсах от IETF. Более того, вместе с коллегами из China Telecom на основе РСЕСС нам в рабочей группе удалось придумать интересный вариант архитектуры по его использованию для IP‑сетей: Central Control Dynamic Routing (CCDR).
Основная идея CCDR заключается в провижионинге информации о разных BGP‑сессиях (с разных loopback) и их достижимости через разные физические линки (subinterfaces), с разным QoS через РСЕСС‑расширения РСЕР: CCI‑объект и новый объект BPI.
Но в этот раз мы коснулись Segment Routing лишь вкратце, и вернуться к этой теме стоит уже в следующий раз.