Berkrley Internet Name Domain. Иногда для этой цели выделяют специальную машину задача

Вид материалаЗадача

Содержание


2.29. Зачем нужно более одного протокола рассылки меток?
[mpls -rsvp-tunnels]
Подобный материал:
1   ...   46   47   48   49   50   51   52   53   ...   59
2.27.5.  Иерархия и партнерство в рассылке меток

Предположим, что пакет P транспортируется на уровне 1 LSP , и при транспортировке из R2 в R3 движется по LSP уровня 2 . С точки зрения LSP уровня 2, партером рассылки меток R2 является R21. С точки зрения LSP уровня 1, партерами рассылки меток R2 являются R1 и R3. Могут существовать партеры обмена метками на каждом уровне иерархии. В разделах 3.6 и 3.7 рассмотрены некоторые способы реализации этой иерархии. Заметим, что в этом примере R2 и R21 должны быть IGP-соседями, но R2 и R3 не обязательно ими являются.

Когда два LSR являются соседними IGP, мы называем их "локальными партнерам рассылки меток". Когда два LSR могут быть партнерами рассылки меток, но не являются соседними IGP, мы называем их "удаленными партнерами распределения меток". В выше приведенном примере R2 и R21 являются локальными партнерами рассылки меток, а R2 и R3 являются удаленными партнерами рассылки меток.

Архитектура MPLS поддерживает два способа рассылки меток на различных уровнях иерархии: явное и неявное партнерство (Peering).

Рассылка меток (пиринг) осуществляется путем обмена протокольными сообщениями, которые адресованы партнеру. Возможен обмен метками и с удаленным партнером. Это возможно одним из двух путей:

1. Явное партнерство

При явном партнерстве, метки пересылаются партнеру в протокольных сообщениях так же, как это делается при локальном обмене. Эта методика наиболее полезна, когда число удаленных партнеров мало, или число ассоциаций высокого уровня велико, или удаленные партнеры обмена метками размещены в удаленных областях или доменах. Конечно, может быть нужно знать, какие метки следует послать какому партнеру; это рассмотрено в разделе 3.1.2. Примеры использования явного партнерства представлены в разделе 3.2.1 и 3.6.

2. Неявное партнерство

При неявном партнерстве, протокольные сообщения рассылки меток, адресованные одному партнеру, не посылаются. Скорее, чтобы разослать метки высокого уровня удаленным партнерам, метка представляется в виде атрибута метки более низкого уровня, а затем производится рассылка метки низкого уровня вместе с этим атрибутом местным партнерам. Локальные партнеры обмена метками рассылают полученные данные дальше. Этот процесс продолжается до тех пор, пока информация не достигнет удаленных партнеров.

Эта техника наиболее полезна, когда число удаленных партнеров обмена метками велико. Неявное партнерство не требует сетки партнеров n-квадрат, чтобы разослать метки удаленным партнерам, так как имеется подстраховка за счет локального обмена информацией. Однако неявное партнерство требует, чтобы промежуточные узлы запоминали информацию, в которой они могут быть заинтересованы. Пример использования неявного партнерства можно найти в разделе 3.3.
2.28.  Транспортировка протокольных сообщений рассылки меток

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

Одним из способов достижения цели является использование TCP в качестве базового транспортного протокола, как это делается в [MPLS-LDP] и [MPLS-BGP].
2.29. Зачем нужно более одного протокола рассылки меток?

Эта архитектура не устанавливает жестких правил для выбора того, какой протокол рассылки меток следует использовать при конкретных обстоятельствах. Однако имеется возможность указать некоторые соображения.
2.29.1. BGP и LDP

Во многих сценариях, желательно установить связь между метками и FEC, который может быть сопряжен с маршрутами и адресными префиксами (смотри раздел 3.1).

Протокол BGP рассылает маршруты, и, если BGP-отправителю нужно разослать метки своим BGP-партнерам, использование BGP для целей распределения меток (смотри [MPLS-BGP]) имеет ряд преимуществ. В частности, это позволяет BGP рефлекторам маршрутов рассылать метки, таким образом обеспечивая существенную масштабируемость по сравнению с использованием LDP для пересылки меток между BGP партнерами.
2.29.2.  Метки для RSVP Flowspecs

Когда используется RSVP при резервировании ресурсов для конкретных потоков, может быть желательно, помечать пакеты в этих потоках, так что не нужно будет использовать RSVP filterspec в каждом из узлов. Можно обосновать, что осуществление рассылки меток в рамках RSVP в качестве части процесса формирования пути, и резервирования ресурсов является наиболее эффективным методом решения проблемы.
2.29.3.  Метки для явно маршрутизируемых LSP

В некоторых приложениях MPLS, в частности сопряженных с управлением трафиком (ТЕ), желательно формировать пути, маршрутизированные явно от точки входа до точки выхода. Хотелось бы также осуществлять резервирование ресурсов вдоль всего пути. Можно представить два подхода:

-  Начать с существующего протокола, который используется при установлении резервирования, и расширить его в направлении поддержки явной маршрутизации и рассылки меток.

-  Начать с существующего протокола, который используется для рассылки меток, и расширить его в сторону явной маршрутизации и резервирования ресурсов.

Первый подход реализован в протоколе, описанном в [MPLS -RSVP-TUNNELS], второй – специфицирован в [MPLS-CR-LDP].