MPLS сигнализация. RSVP-TE FRR

Пришло время написать о втором протоколе сигнализации MPLS - RSVP-TE.

В отличии от LDP, RSVP-TE протокол наделен изначально большей "силой". И почти вся эта "сила" заключается в алгоритме CSPF, который считает для RSVP-TE кратчайший путь по заданным условиям. Об этом я кратко писал в посте про MPLS overwiev.

Сейчас речь фактически пойдет о такой вещи как Fast Reroute. Штука которая возносит отказоустойчивость  IP/MPLS сети до невиданных высот (в купе с прямыми руками, и нормальным дизайном, разумеется).

Процесс распространения меток уже был обозначен, поэтому сейчас не буду его подробно расписывать. Как я упоминал, в MPLS есть механизм Secondary LSP, который вместе с MBB(make-before-break) позволяет создать несколько резервных туннелей для одного primary туннеля. И это довольно круто. Но, у этого метода обеспечения отказоустойчивости есть две, как мне кажется, основные проблемы. Во-первых, дополнительные LSP нужно конфигурировать руками, что вообще не круто. Во-вторых, когда по пути происходит какая-либо авария, информация о ней сначала должна дойти до Head-End маршрутизатора (тот, на котором инициализируется туннель), а тот уже будет принимать решение о переводе трафика на дополнительный путь. Это что-то вроде Topology Changed (TC) в STP. 

Было бы здорово, если бы все было автоматом и не тратилось бы время на оповещение Head-End... Конечно, все уже давно придумано...

Все посты про MPLS VPN можно посмотреть по тегу MPLS или в обобщающем посте.

Fast Reroute (FRR)

FRR позволяет идентифицировать проблему и решить её в месте, которое находится как можно ближе к аварии. А уже потом можно и Head-End оповестить об этом. После чего Head-End может спокойно пытаться перевести трафик на запасной маршрут (в случае hot-stanby secondary LSP) или начать сигнализировать другой туннель (cold-stanby secondary LSP). Время-то есть, драгоценный абонентский трафик уже бегает по запасному маршруту. Маршрут этот может быть далеко не оптимальный, но все же.

Когда Head-End сигнализирует MPLS туннель с помощью RSVP-TE он в сообщении Path отправляет специальную дополнительную "просьбу". Эта просьба проходит по всем маршрутизаторам до самого последнего Tail-узла. Просьба эта звучит примерно так: "Подумай, пожалуйста, заранее, что ты будешь делать, когда случиться авария около тебя. Построй обходной путь сразу же. Если вдруг отказ произойдет, сразу переводи трафик на обходной и оповести меня об этом".

В FRR есть две роли маршрутизаторов: 

Point of Local Repair (PLR) - маршрутизатор который увидел проблему, почуял неладное и перевел трафик на запасной путь.

Merge Point (MP) - маршрутизатор, к которому ведет обходной путь, и который как бы объединяет (merge) обходной путь с основным.

При сигнализации туннеля Head-End маршрутизатор может так же попросить ноды по пути защититься от аварии на линке или от отказа ноды целиком. Отсюда, два типа FRR:

Link Protection - каждый маршрутизатор по пути прикидывает на себя роль PLR и представляет что он будет делать, если упадут линки от него до соседних нод.

Node Protection - каждый маршрутизатор прикидывает на себя роль PLR и пытается построить обходные пути минуя соседние ноды.

Ниже я как смог изобразил два этих подхода. Попутно обратите внимание на PLR и  MP.

Это ещё не все, что можно специфицировать при инициализации туннеля с Head-End. Представьте, что через MPLS-маршрутизатор в ядре может идти огромное количество RSVP-TE туннелей (LSP). Как мы знаем, у каждого LSP может быть несколько LSP-Path. Представьте количество построенных  обходных путей, если через PLR проходит пусть 100 LSP по 2 LSP-Path в каждом и у этого маршрутизатора 2 линка, которые могут упасть. 100 х 2 х 2 = 400. Такое количество туннелей может построить единственная нода по пути туннеля. Конечно же, придумали способ оптимизировать и это.

Вообще существует две схемы построения защитных путей:

One-to-One Backup - для каждого LSP-Path будет создан отдельный обходной путь (detour LSP). В этом случае, когда произойдет авария, ближайший маршрутизатор переключит трафик определенного LSP-Path на резервный. Обычно one-to-one backup использует Far-MP подход, т.

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

На картинке ниже, после аварии на линке, PLR принимает решение передавать трафик по запасному маршруту. Он отправляет в сторону Head End маршрутизатора сообщение о том, что он собирается сделать. Для каждого LSP-Path он заблаговременно создал три других LSP-Path. Делал он это средствами RSVP-TE, т.е. роутер PLR на схеме является ещё и ТЕ для запасного тунеля, а MP - Tail. Короче говоря, когда трафик от НЕ приходит на PLR с меткой 30, тот меняет метку на метку 70 которая была анонсирована со стороны R1. В случае нормальной работы сети, он бы поменял метку на 20. Далее трафик отправляется в сторону R1. R1 так же меняет метку c 70  на 60 и отправляет трафик в сторону R2. Трафик достигает MP, тот знает, что он должен объединить protected и protection пути. Он делает это просто меняя метку 50 на метку 10 и отправляет трафик к Tail маршрутизатору. Для каждого пути будет свой набор меток и, соответсвтенно, свой LSP-Path.

Facility Backup - PLR создает bypass tunnel, который будет использоваться для резервирования нескольких LSP-Path. В таком случае, это именно туннель. Для того чтобы отправить нуждающийся в защите трафик обходным путем, PLR сигнализирует дополнительный RSVP-TE LSP с MP. В facility backup используется подход Near-MP, т.е. туннель строится к маршрутизатору, который находится как можно ближе к PLR. При таком подходе, bypass туннель имеет шанс быть использованным как можно более большим числом LSP-Path. Для того чтобы передать в такой туннель трафик, PLR будет вещать ещё одну метку на кадры, а MP по этой метке будет понимать, с каким LSP-Path нужно объединить трафик.

Поведение довольно сильно отличается от one-to-one схемы. На картинке ниже, трафик от HE попадет на PLR. Если бы аварии не было, он бы поменял метку c 30 на 20 и отправли бы трафик дальше, но линк между PLR и  MP неожиданно упал. PLR так же извещает HE роутер об аварии, чтобы тот начал тоже шевелиться на эту тему. В жонглировании метками в Facility backup есть несколько особенностей. Одна из них изображена ниже. Когда линк оборвется, PLR все равно сменит метку в кадре на 20. Сделает он этого для того, чтобы по этой метке MP смог вычислить куда стоит направить трафик. Потом PLR добавит ещё одну метку в стек, это будет метка 70. Об этой метке они договорились с MP. Далее по пути кадждый маршрутизатор (R1 и R2) будут осуществлять коммутацию только на основе этих последних меток. Когда трафик придет на MP, он как Tail маршрутизатор для запасного туннеля, отбросит одну метку и увидет под ней метку 20. А он то знает, что все что пришло с меткой 20 должно быть отправлено в сторону Tail маршрутизатора с меткой 10. Эти манипуляции он и производит. В этой схеме все пути защищаются только одним туннелем.

Трафик внутри MPLS ядра как правило идет уже с двумя-тремя метками, а тут к нему добавляется ещё одна. 

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

Был выпущен отдельный RFC 4090, в котором протокол RSVP-TE получил доработки связанные именно с FRR. В нем описаны механизмы, которые позволяют задать дополнительные параметры для FRR на Head-End маршрутизаторе в момент создания туннеля. Вот некоторые из них.

1. Hop Limit.

2. Bandwidth

3. Protection method (One-to-One, Facility)

4. Link Coloring (include/exclude)

5. Detour list (список нод, которые нужно избегать или включать в detour LSP)

Как видим, простор для творчества просто бескрайний. Можно и линки красить, и число нод указывать. Кстати, для того чтобы функционировал FRR конечно же нужен TE протокол маршрутизации и CSPF. 

Для того чтобы сократить количество detour/bypass туннелей, в facility backup подходе, трафик должен вернуться в оригинальный путь как можно ближе к точке отказа. Это уменьшает общее количество туннелей, потому что много LSP-Path могут использовать этот путь для защиты. В one-to-one backup, придумали объединять несколько путей в один. Когда несколько detour LSP проходят через одну и ту же ноду, эта нода (Detour Merge Point) для сокращения общего числа путей, объединяет все эти пути в один.

Как мог, я нарисовал этот случай. R1 построил one-to-one туннель через DMP, сам DMP построил такой же тунель. Собсвтенно DMP в этом случае просто объединяет два этих тунеля в один для экономии ресурсов.

Конечно, каждый термин в этом посте заслуживает отдельного поста. Возможно, в будущем я так и поступлю. Но сейчас движемся в ритме "галопом по Европам". Вперед к LDPoRSVP!