Глава 2. RSVP

Разности

MPLS

• label 0 - implicit null
• label 3 - explicit null

Принцип работы протокола

LDP - автоматом строит full mesh туннели до соседей. RSVP - не просто строит туннели, а использует для построения TE + используются механизмы зачиты трафика: FastRerote, LinkProtection... RSVP - протокол signaling. RSVP инкапсулируется сразу в ip. RSVP пакет стоит из объектов. Объект имеет тип, и поле данных.

Для работы RSVP нужно:

1. Включить протокол RSVP
2. Конфигурируем туннель только на ingress.

Ingress -> Egress: При построении туннеля на Ingress (A) создается ip-пакет pathMessage, который состоит из:

• 1.dst: ip dst (192.168.0.4), по метриками внутреннего протокола узнает где конечный роутер.
• 2.session ID - идентификатор rsvp сессии на уровне control plane. Все rsvp роутеры, через которые строится туннель - ассоциируют все сообщения для туннеля по session ID. Генерируется ingress роутером, состоит из router ID + какое-то число.
• 3.label request: определяет поведение транзитных маршрутизаторов, заставляет резервировать метки для туннеля.

Transit router 1 (B): 1.Видит label request, выделяет (запоминает, но никуда не записывает) для туннеля метки из свободных, ассоциирует ее с session ID.

Transit router 2 (C): 1.Видит label request, выделяет (запоминает, но никуда не записывает) для туннеля метки из свободных, ассоциирует ее с session ID.

Egress router (D): 1.dst addres = его loopback => он последний. Резервирует метку 3 (по дефлоту).

Формирует ResvPath - основная его суть - проанонсировать зарезервированные метку предыдущему роутеру.

Egress -> Ingress: resvPath: session ID из PathMessage, label: (то, что он зарезервировал) 3.

Transit 2 (C):

• 1. По session ID определяет какую метку он зарезервировал (30).
• 2.Смотрит в label, видит 3. Понимает, что он должен передавать к egress пакет с меткой 3.
• 3.mpls.0: 30 swap 3 = pop 30

Transit 1 (B):

• 1.По session ID определяет какую метку он зарезервировал (20).
• 2.Смотрит в label, видит 30. Понимает, что он должен передавать к egress пакет с меткой 30.
• 3.mpls.0: 20 swap 30

Ingress (A): 1.inet.0: 192.168.0.4: -> BGP, push 30

Туннель - это просто метки.

При падении линка между роутерами: Генерируются pathTear (в сторону ingress) и resvTear (в сторону egress), чтобы все транзитные роутеры освободили метки, а ingress понял, что этого туннеля больше нет.

В это время IGP пересчитало топологию, ingress router увидел next-hop для egress роутера и rsvp заново начал строить туннель.

Keepalive: Ingress роутер 1 в 30 сек (по дефолту) обновляет состояние с помощью посылки pathMessage.

resvMessage должен пройти по тому же пути, что и pathMessage. Но маршрутизация может быть не симметричной. отличие resv и path: dst add - не loopback конечных роутеров, а адрес предыдущего роутера из ERO (также предотвращает зацикливание).

Туннель может устанавливаться с требованиями к полосе. Задается в bandwith - передается в объекте TSpec.

Если RSVP не может установить туннель, то на проблемном участке генерируется patheErr - сообщение с кодом ошибки. Bandwith - только для сигнализации, реально полосу не ограничивает.

Если нужно провести траблшутинг, лучше делать тут:

set protocol rsvp traceoptions file RSVP-trouble flag all detail

RSVP поддерживает mtu discovery и fragmentstion на ingress роутере.

RSVP поддерживает аутентификацию (MD5)

RSPV может использовать Gracefull restart.

RSVP может работать как point-to-multipoint => можно исключить из ядра всякие multicast протоколы.