Эволюция Traffic Engineering-2. От основ PCEP к новому взгляду на РСЕСС

Traffic Engineering помогает нам решать проблемы оценки и оптимизации производительности IP‑сетей, но при этом требует недюжинного понимания сетевых технологий и протоколов, которые используются в больших сетях. В прошлый раз мы остановились на магии работы PCE‑контроллера и затронули Stateless и Stateful PCE. Как здесь не вспомнить комикс от Go Chronicles, посвящённый Stateful:

Конечно, на самом деле PCE‑контроллер общается не так, а с использованием PCEP — Path Computation Element Communication Protocol, который описан в RFC 5440. Так что самое время начать с него вторую часть нашей истории про Traffic Engineering.

Заодно напомню полное содержание этой энциклопедии Traffic Engineering:

1. Основы, распределённый и централизованный расчёт туннелей, магия РСЕ

2. Основы РСЕР и Stateful PCE, Междоменный RSVP‑TE, новый взгляд на РСЕСС

3. Жизнь после MPLS (TBD)

Пройдёмся по основам РСЕР 

1. Это протокол клиент‑серверного взаимодействия (запрос‑ответ).

2. Он работает поверх ТСР (порт 4189), на который возлагаются вопросы надёжной доставки сообщений, а также безопасности.

3. Это сессионный протокол:

4. Сначала были определены только 7 сообщений:

   • Open

   • Keepalive

   • Path Computation Request (запрос на расчёт между узлами и ограничения)

   • Path Computation Reply (рассчитанный путь в виде ERO, метрики пути либо отказ)

   • Notification

   • Error

   • Close

5. Отдельно отмечу, что сообщение Keepalive было специально внедрено как механизм отслеживания состояния сессии (не требует ответа).

6. Каждое сообщение состоит из определённого набора объектов: OPEN, RP (request Parameters), END‑POINTS, BANDWIDTH, METRIC, ERO, RRO, LSPA (LSP Attributes), NOTIFICATION, PCEP‑ERROR и т. д. Форматы этих объектов описаны в секции 7 RFC 5440.

7. Объект, как правило, состоит из заголовка, флагов и набора опциональных 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:

BitCapability

‑-‑--‑--‑--‑--‑--‑--‑--‑-

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 и ограничения, но обязательно должен присутствовать

Для сигнализации режима 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 с оборудования разных вендоров.

[~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                 SentReceived     Open           5           5                     Keepalive              7       7                 Path computation request0       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    IndexHop 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 

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,

  Для определения поддержки РСЕСС в РСЕР ввели новую 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 лишь вкратце, и вернуться к этой теме стоит уже в следующий раз.