Функция обнаружения петлевых маршрутов: распределение маршрутных

Векторов

Каждый ATM/LSR-коммута­тор должен обладать, в качестве дополни­те­льной, функцией обнаружения петлевых маршрутов доставки. Сама же функ­циональная процедура именуется как «обнаружение петлевого маршрута с по­мощью маршрутных векторов» (Loop Detection via Path Vectors, LDPV). Эта процедура не предотвращает формирование петлевых маршрутов доставки, но гарантирует, что любые подобные маршруты будут обнаружены. Если эта до­полнительная функция не реализована, то петлевые маршруты выявляются с помощью способа, основанного на подсчёте числа РУ, рассмотренного ранее. Если же эта функция реализована, то петлевые маршруты выявляются намного быстрее, но с более существенными затратами.

Когда передаётся нисходящий трафик с маршрутными векторами

Предположим, что LSR-маршру­тизатор R передаёт противоположной сто­роне своего следующего РУ запрос на данные о привязке маркера к опреде­лённому LSP-маршруту. Тогда, если R не реализует функцию объединения VC-соединений, но R способен осуществлять LDPV-процедуру:

§ если R передаёт запрос потому, что является входным узлом данного LSP-маршрута, или потому, что он установил новый следующий РУ, то R обязан включить данные о маршрутном векторе в запрос, а сами данные о маршрутном векторе должны содержать только собственный IP-адрес R;

§ если R передаёт запрос в результате получения запроса от LSR_ВП, то:

« если полученный запрос содержит данные о маршрутном векторе, то R обязан добавить свой собственный IP-адрес в принятые данные о мар­шрутном векторе, и затем обязан отправить противоположной стороне своего следующего РУ результирующие данные о маршрутном векторе вместе с запросом на данные о привязке маркера;

« если полученный запрос не содержит данные о маршрутном векторе, то R обязан добавить данные о маршрутном векторе и передать их вместе с запросом, а данные о маршрутном векторе должны включать только собственный IP-адрес R.

Целесообразно, чтобы LSR-маршру­тизатор, который реализует функцию объединения VC-соединений, не включал данные о маршрутном векторе в свои запросы, передаваемые им противоположной стороне своего следующего РУ.

Если LSR-маршру­тизатор получил запрос на данные о привязке, в кото­рых содержатся данные о маршрутном векторе, включающие IP-адрес этого се­тевого узла, то LSR-маршру­тизатор принимает решение, что запросы на данные о привязке маркера были доставлены по петлевому маршруту. В таком случае, LSR-маршру­тизатор обязан поступить также, как и в случае, когда значение счётчика РУ превысило MAXHOP.

Рассмотренная процедура позволяет обнаружить петлевые маршруты, ко­гда сообщения/запросы транслируются через последовательность ATM/LSR-коммута­тор, не реализующих функцию объединения VC-соединений.

Когда передаётся восходящий трафик с маршрутными векторами

Могут возникнуть ситуации, при которых LSR-маршру­тизатор R должен информировать свои соседние LSR_ВП об изменении значения счётчика РУ соот­ветствующих определённому LSP-маршруту (с использованием ответного со­общения с данными о привязке маркера). Если выполнены все следующие ус­ловия:

o R настроен на выполнение LDPV-процедуры;

o R реализует функцию объединения VC-соединений;

o R не является выходом данного LSP-маршрута;

o R не информирует своих соседей об уменьшении значения счётчика РУ,

то R обязан включить данные о маршрутном векторе в ответное сообщение.

Если изменение значения счётчика РУ явилось следствием информирова­ния R LSR-маршру­тизатором S, расположенном на противоположной стороне следующего РУ, об изменении значения счётчика РУ, а сообщение отправлен­ное S LSR-маршру­тизатору R содержит данные о маршрутном векторе, то, если все указанные выше условия выполнены, R обязан добавить себя в эти данные и отправить результирующее сообщение LSR_ВП. В противном случае, если все указанные выше условия выполнены, R обязан сформировать новые данные только со своим собственным IP-адресом.

Если R настроен на выполнение LDPV-процедуры, и R реализует функ­цию объединения VC-соединений, то он может включить данные о маршрут­ном векторе в любое ответное сообщение, содержащее данные о привязке мар­кера, которое он передаёт LSR_ВП. Соответственно, в любой момент времени, когда R принял от противоположной стороны следующего РУ ответное сооб­щение с данными о привязке маркера, и если это ответное сообщение включает маршрутный вектор, то R может (если он настроен на выполнение LDPV-про­цедуры) отправить своим соседним LSR_ВП ответ, содержащий данные о мар­шрутном векторе, сформированные путём добавления своего собственного IP-адреса в полученный маршрутный вектор.

Если R не реализует функцию объединения VC-соединений, то ему не це­лесообразно передавать LSR_ВП данные о маршрутном векторе.

Если R принял от противоположной стороны следующего РУ сообщение, в котором данные о маршрутном векторе включают его собственный IP-адрес, то LSR-маршру­тизатор обязан действовать так, как если бы он принял сообще­ние со значением счётчика РУ, равным MAXHOP.

LSR-маршру­тизаторы, которые настроены на выполнение LDPV-проце­дуры, не должны хранить маршрутный вектор, после того как соответствующие данные о маршрутном векторе были переданы.

(Примечание. Если сетевой ATM/LSR-сегмент включает только лишь ATM/LSR-коммута­торы, не реализующие функцию объединения VC-соедине­ний, то нет необходимости всегда передавать LSR_ВП маршрутные векторы, так как лю­бые петлевые маршруты будут выявляться с посредством маршрутных векторов, доставляемых в составе нисходящих потоков.)

Если не транслировать маршрутные векторы до тех пор, пока счётчик РУ возрастает, то во многих ситуациях, когда нет петлевого маршрута, LSR-мар­шру­тизатор старается их не передавать. Издержки появляются в тех ситуациях, в которых существует петлевой маршрут, а время выявления петлевого мар­шрута может увеличиться.

[1] Дословно «клин» или «прокладка»

[2] Эта функция обязывает маршрутизатор проанализировать IP-пакет, если, конечно, он способен распознавать эту функцию, в противном случае он должен её проигнорировать. IP-узлы должны игнорировать эту функцию.

[3] MPLS using LDP and ATM VC switching. Стандарт, устанавливающий правила использования

ATM-коммутаторов в качестве LSR-мар­ш­­ру­тизатора.

[4] Этот бит расположен в поле «Индикатор «Ещё данные» заголовка IPv4-пакета (RFC-791), которое включает три бита (первый бит всегда нулевой; второй бит: 0 — «можно фрагментировать», 1 — «не фрагментировать»; третий бит: 0 — далее нет фрагментов, 1 — далее следует фрагмент).

* Это могут быть кадры протоколов канального уровня, например, PPP-протокол, HDLC-протокол и др.

· User-to-Network Interface (интерфейс «пользователь/ATM-сеть») и Private Network-to-Network Interface

(интерфейс «частная ATM-сеть/частная ATM-сеть»).

° Operations and maintenance. Технологические (служебные) ячейки, предназначенные для обслуживания и

поддержания ATM-соединений, в частности для выхода из нештатных и сбойных ситуаций.

¨ Специализированный заголовок управления логическим каналом (Logical Link Control) введён стандартом

IEEE 802.2и используется для идентификации протокола сетевого уровня. За LLC-заголовком должен

следовать SNAP-заголовок (SubNetwork Attachment Point — точка присоединения подсети, IEEE 802.1a).