Рис. 5. Потоки мультикаст-данных от двух отправителей для однонаправленного дерева

3.6. Инкапсулированные мультикастинг данные

Отправители однонаправленных совмещенных деревьев и отправители, не являющиеся узлами двунаправленных совмещенных деревьев, инкапсулируют данные на пути к корневому узлу. Данные затем декапсулируются в корневом узле. Инкапсуляция и декапсуляция мультикастных данных осуществляется на уровне L3.

Таким образом, в случае инкапсуляции/декапсуляции путь может вообще не совпадать с LSP: трафик не может быть ни переадресован на L2 через интерфейс Register DRsend (инкапсуляция), ни попасть в корневой узел на L2 (декапсуляция).

Замечания

1. Если LSR поддерживает смешанную L2/L3 переадресацию (раздел 4), трафик (S,G) в DRsend может переадресовываться на L2 через любой выходной интерфейс, отличный от Register.
2. Инкапсулированный трафик может выиграть от использования переключения по меткам.
3. Если корневой узел решает присоединиться к отправителю (чтобы избежать инкапсуляции/декапсуляции), может быть сформирован LSP точка-точка (S,G).

3.7. Отсутствие петель

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

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

3.8. Характеристики существующих протоколов

Выше перечисленные характеристики суммированы в таблице 1 для неполного списка существующих мультикастных протоколов маршрутизации: DVMRP [PUSA], MOSPF [MOY], CBT [BALL], PIM-DM [ADAM], PIM-SM [DEER], SSM [HOLB], SM [PERL].

Таблица 1. Систематика протоколов маршрутизации для IP-мультикастинга

Из таблицы 1 можно видеть, например, что DVMRP использует большое число меток, когда дерево Flood & Prune L3 проектируется на дерево L2. Более того, так как DVMRP использует деревья отправителя, он не сталкивается с проблемой объединения, когда используется коммутация по меткам. Таблица может быть интерпретирована аналогичным образом для других протоколов.

4. Смешанная переадресация L2/L3 в отдельном узле

Так как уникастный трафик имеет один входной и один выходной интерфейс, трафик переадресуется либо на уровне L2, либо на уровне L3 (Рис. 6). Так как мультикастный трафик может переадресовываться более чем через один выходной интерфейс, можно считать, что трафик в некоторых ветвях переадресуется на уровне L2, а в других на уровне L3 (Рис. 7).

Рис. 6. Уникастная переадресация на уровне L3 или L2

Рис. 7. Мультикастная переадресация на уровне L3, смешанном L2/L3 или L2

Узлы, которые поддерживают эту возможность смешанной переадресации L2/L3, позволяют расщеплять мультикастное дерево на ветви, с переадресацией L3 и L2.

Переадресация L3 должна заботится о том, чтобы трафик не переадресовывался в ветви, которые уже получили свой трафик L2. Это может быть осуществлено, например, добавлением специального бита в записи мультикастинг таблицы маршрутизации.

Хотя смешанная L2/L3-переадресация требует обработки трафика на уровне L3, нагрузка на устройство переадресации L3 обычно меньше, чем в случае узла исключительно уровня L3. Поддержка этой смешенной переадресации L2/L3 имеет следующие преимущества:

1. Пусть LSR A (Рис. 8) является оконечным узлом для ветви к LSR B и узлом ветвления для LSR C. Смешанная переадресация L2/L3 допускает, чтобы ветвь к C не загружалась проблемой возврата на уровень L3 в LSR A




Рис. 8. Смешанная L2/L3-переадресация в узле A

2. Допускает использование триггера, управляемого трафиком, с режимом рассылки меток Downstream Usolicited или Upstream on Demand, как это объяснено в разделе 5.3.1.

5. Систематика IP-мульткаст LSP триггеров

Формирование LSP для мультикаст-потоков может быть запущено различными событиями (триггерами), которые могут быть отнесены к следующим стандартным категориям запуск запросом, запуск топологией и запуск трафиком.

1. Запуск запросом: перехватывает отправку или получение управляющих сообщений (например, мультикастные маршрутные сообщения, сообщения резервирования ресурсов).
2. Запуск топологией: устанавливает соответствие между деревом уровня L3, которое имеется в мультикастной таблице маршрутизации, и деревом L2. Установление соответствия осуществляется даже при отсутствии трафика.
3. Запуск трафиком: устанавливается соответствие между деревом L3 и деревом L2 тогда , когда поступают данные.

5.1. Управление запросами
5.1.1. Общая часть

Установление LSP может быть запущено путем перехвата исходящих (метка должна быть затребована нижестоящим LSR) или входящих (метка должна быть затребована вышестоящим LSR) управляющих сообщений. На рис. 9 проиллюстрированы эти два случая.

Рис. 9. Запуск по запросу (перехват resp. входящих и исходящих управляющих сообщений)

Нижестоящий LSR (LSR-Dn) посылает управляющее сообщение вышестоящему LSR (LSR-Up). В случае, когда входные управляющие сообщения перехватываются и модуль в LSR-Up решает установить LSP, он пошлет LSR-Dn команду LDP bind (режим Upstream nsolicited) или запрос LDP bind (режим Downstream on Demand).

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

5.1.2. Сообщения мультикаст-маршрутизации

В принципе этот механизм может быть использован только мультикастинг протоколами маршрутизации, в которых применяется прямая сигнализация: например, сообщения Join в PIM-SM или CBT. Заметим, что DVMRP и PIM-DM могут быть адаптированы для поддержки этого типа запуска [FARI], однако ценой модификации самого протокола мультикаст-маршрутизации!

IP-сообщения мультикаст-маршрутизации могут формировать как жесткие состояния (например, CBT Join + CBT Join-Ack) так и “мягкие состояния” (например, периодически посылаются сообщения PIM-SM Join). Последние генерируют больше управляющего трафика для поддержания дерева и таким образом требуют больше обработки в модуле.

Запуски формирования маршрута, базирующиеся на сообщениях мультикастинг-протоколов маршрутизации, имеют недостаток, который заключается в том, что вычисление мультикастинг таблицы маршрутизации, выполняемые мультикастным маршрутным демоном, повторяются модулем. Первый определяет дерево, которое будет использоваться на уровне L3, последний вычисляет идентичное дерево, которое будет использоваться на уровне L2. Так как одна и та же задача решается дважды, лучше сформировать мультикастный LSP на основе информации, извлеченной из самой мультикастинг таблицы маршрутизации (смотри раздел 5.2 и 5.3). Вычисление маршрута становится более сложным для протоколов, которые поддерживают переключение от дерева (*, G) к дереву (S, G), так как нужно интерпретировать больше сообщений.

Когда ЭВМ имеет соединение с первым маршрутизатором по схеме точка-точка, может быть сформированы LSP до конечных пользователей путем перехвата не только маршрутных мультикастинг-сообщений, но и сообщений IGMP Join/Prune ([FENN]).

5.1.3. Сообщения резервирования ресурсов

В случае уникаста для запуска процесса формирования маршрута LSP могут использоваться сообщения RSVP Resv. Отправитель мультикастной группы пошлет вниз по дереву сообщение RSVP Path, получатели могут затем откликнуться сообщением RSVP Resv. RSVP хорошо адаптируется и для мультикастинга

1. Сообщения RSVP Resv могут быть совмещены.
2. Сообщения RSVP посылаются только первой ветви, которая выполнила нужное резервирование.

5.2. Управление топологией

Мультикастинг таблица маршрутизации (MRT) поддерживается демоном протокола мультикастинг маршрутизации. Модуль устанавливает соответствие (мэпинг) этих топологических данных дерева L3 и маршрутов LSP L2 p2mp.

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

5.3. Управление трафиком
5.3.1. Общая часть

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

Если смешанная переадресация L2/3 не поддерживается (смотри раздел 4), запуск формирования LSP от трафика требует установления режима рассылки меток, в котором метки запрашиваются LSR-Up (режим Downstream on Demand или Upstream Unsolicite). На рис. 10 предполагается, что для определенной группы существует LSP до LSR-Dn1, а другой LSR-Dn2 хочет присоединиться к дереву. Для того чтобы LSR-Dn2 инициировал формирование прохода, он должен уже получать трафик от этого дерева. Это может быть реализовано на L2 или L3. Первый вариант представляет собой проблему цыпленок-яйцо. В последнем случае для добавления ветви L3 необходима поддержка смешанной переадресации L2/L3 в LSR-Up.

Рис. 10. LSR-Up должен запросить метку.

5.3.2. Пример реализации

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

Современные реализации на Unix-платформах мультикастинг протоколов маршрутизации (DVMRP, PIM) имеют MFC (Multicast Forwarding Cache). MFC является кэшированной копией мультикастинг таблицы маршрутизации. MFC запрашивает рекорд для определенной мультикаст-группы, когда обнаруживает отсутствие нужной информации в кэше для входящего пакета. Недостающая маршрутная информация предоставляется мультикаст-демоном. Если позднее ситуация с маршрутами изменится (добавлен или удален выходной интерфейс), мультикаст-демон обновит MFC.

MFC реализован как общая часть (ядра), которая делает этот вид запуска привлекательным, так как он может быть прозрачно использован для любого мультикастного протокола маршрутизации.

Рекорды в MFC удаляются, когда нет трафика для этого рекорда в течение определенного периода времени. Когда используется коммутация по меткам для определенного рекорда MFC, уровень L3 вообще не будет видеть приходящих пакетов. Чтобы поддержать нормальную работу MFC, счетчики L3 MFC должны быть скорректированы с учетом измерений на уровне L2.

5.4. Комбинации режимов запуска и рассылки меток

В таблице 2 приведены допустимые комбинации методов рассылки меток и запуска формирования LSP, которые были обсуждены в предыдущих разделах. (X) означает, что комбинация допустима, если LSR поддерживает смешанную переадресацию L2/L3.

Таблица 2. Допустимые комбинации методов запуска и рассылки меток

6. Перенос меток (Piggy-backing)

На рис. 9 (outgoing case) можно видеть, что вместо отправки двух отдельных сообщений, анонсирование метки может осуществляться посредством существующих управляющих сообщений. Для мультикастинга имеется два кандидата для транспортировки (piggy-back):

1. Мультикастные маршрутные сообщения: протоколы, такие как PIM-SM и CBT, имеют сообщения Join, которые могут нести в себе мэппинг меток. Этот подход описан в [FARI]. Когда установлены различные протоколы для мультикастинг-маршрутизации, должны быть определены расширения для каждого из этих протоколов.
2. Сообщения Resv RSVP: объект расширения мэппинга меток для RSVP, также применим в мультикастинге (предложено в [AWDU]).

За и против транспортировки меток с привлечением мультикаст маршрутных сообщений рассматриваются ниже. Такой вид транспортировки имеет следующие преимущества:

1. Если анонсирование меток осуществляется мультикаст маршрутными сообщениями, тогда рассылка маршрутов и меток оказываются синхронизованными. Это исключает сложные ситуации типа "что я должен делать с меткой, если у меня пока нет подходящего рекорда в маршрутной таблице?". Это также минимизирует интервал между установлением мультикаст-маршрута и ассоциацией метки и маршрута.
2. Число управляющих сообщений, необходимое для поддержания анонсирования меток, помимо используемых для осуществления мультикастной маршрутизации, равно нулю.

Можно отметить следующие недостатки такого типа транспортировки:

1. В некоторых протоколах нет сообщений, с помощью которых можно доставлять сообщения о метках. Для таких протоколов предлагается [FARI] добавить периодически рассылаемые сообщения, которые сильно влияют на работу мультикастинг маршрутного протокола и сводят на нет выгоды совмещенной транспортировки (piggy-backing).
2. Второе решение проблемы сосуществования состояний (смотри 3.4) не может быть применено в сочетании с совмещенной транспортировкой (с piggy-backing).
3. Совмещенная транспортировка требует расширения мультикастного протокола маршрутизации, и следовательно становится менее привлекательной, если анонсирование меток требует поддержки нескольких мультикастных протоколов маршрутизации.
4. Совмещенная транспортировка предполагает режим рассылки меток Downstream Unsolicited, это исключает несколько методов запуска процесса формирования LSP (смотри таблицу 2).
5. LDP обычно работает поверх TCP, предполагая надежный обмен между узлами-партнерами. Совмещенная транспортировка сообщений о метках часто замещает надежный обмен на периодическую рассылку анонсирований меток. Из-за этого периодического анонсирования меток управляющий трафик (в байтах) увеличится.
6. Если необходим механизм оповещения VCID [NAGA], он может быть реализован путем посылки сообщений LDP bind через вновь сформированный виртуальный канал VC. Для этого необходимо лишь одно сообщение. Такой метод не может комбинироваться с совмещенной транспортировкой, так как маршрутные сообщения посылаются до того как будет сформирован VC. Таким образом, необходим дополнительный диалоговый обмен, сокращающий выгоды совмещенной транспортировки.

Совмещенная транспортировка является лишь одним возможным компонентом мультикастного решения для.

7. Непосредственная маршрутизация

Явная маршрутизация для уникастинга сопряжена с переписыванием уникастной маршрутной таблицы, с использованием LSP. " Мультикастная явная маршрутизация" может быть определена как перепись дерева, сформированного мультикастным протоколом маршрутизации, с привлечением другого дерева LSP (например, дерева Штайнера, вычисленного где-то off-line). В этой интерпретации современный мультикастинг протокол маршрутизации 'кратчайшего пути' становится устаревшим и может быть заменен сообщениями рассылки меток, которые следуют явным маршрутом (например, ветвь дерева Штайнера).

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

8. QoS/CoS
8.1. DiffServ

Концепция дифференцированных услуг может быть применена и к мультикастингу. Это приводит к более тонкой гранулированности потоков (DSCP в качестве дополнительного средства разделения потоков). Отправитель может сформировать одно или более деревьев с разными DSCP.

Эти деревья (S,G, DSCP) или (*, G, DSCP) могут быть легко спроектированы на LSP, если используется механизм формирования пути, запускаемый трафиком. В этом случае можно сформировать LSP с разными атрибутами для разных DSCP. Заметим, однако, что эти LSP используют тот же маршрут, так как механизм формирования дерева не использовал значения DSCP.

8.2. IntServ и RSVP

RSVP может использоваться для формирования мультикастных деревьев с заданным QoS. Важным следствием использования мультикастинга является проблема, как связать парадигму 'гетерогенных получателей' с уровнем L2 (заметим, что эта задача не решена и в IP). Этот предмет серьезно обсуждается в [CRAW]. Прагматическими подходами являются модель ограниченной гетерогенности, которая допускает уровень услуг “максимальных усилий” (best effort) и один уровень QoS (например, QoS, предложенный отправителем в сообщении RSVP Path) и гомогенная модель, которая допускает только один уровень QoS.

Первый поход приводит к формированию полных деревьев для каждого класса услуг. Отправитель должен послать свой трафик в сеть дважды (например, 1 в дерево “максимальных усилий” и 1 - в дерево QoS). В обоих деревьях может использоваться коммутация по меткам.

При втором подходе конструируется одно дерево и пользователи услуги “максимальных усилий” подключаются к дереву QoS. Если ветви, созданные для пользователей “максимальных усилий” не используют коммутацию по меткам, (таким образом, следуя шаг-за-шагом вдоль LSP), мультикастный QoS-трафик должен следовать этим LSP по умолчанию. Эта функция может быть предоставлена системой смешанной переадресации L2/L3, описанной в разделе 4. Если она недоступна, объединение необходимо, чтобы избежать возврата на L3 в QoS LSP.

9. Сети с множественным доступом

Мультикастный в сетях с множественным доступом представляет собой определенную проблему. LSR, который хочет присоединиться к группе, должен всегда быть готов воспринять метку, которая уже приписана группе LSP. Это может быть достигнуто тремя путями:

1. Каждый LSR канала с множественным доступом запоминает все анонсированные метки канала, даже если он не получил сигнал join для соответствующей группы. Если LSR добавлен к каналу с множественным доступом, он должен получить эту информацию от другого LSR канала или в случае soft state анонсирования меток, он может ждать некоторое время, прежде чем сам сможет сформировать метку. Если LSR формируют метки в один и тот же момент, LSR с более высоким кодом IP-адреса может ее сохранить, в то время как другой LSR отзывает свою метку.
2. Каждый LSR получает свой собственный диапазон меток. Механизм распределения меток описан в [FARI]. Если LSR добавляется к каналу с множественным доступом, диапазон меток должен быть согласован снова и, возможно, некоторые существующие каналы LSP разрываются и восстанавливаются с другими метками.
3. В каждом канале с множественным доступом один LSR может быть выбран ответственным за выделение меток. Когда LSR нужна метка, он может запросить ее у этого LSR, осуществляющим присвоение меток.

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

1. [FARI] предлагает рассылать анонсирования меток мультикастно всем LSR, подключенным к общему каналу. Так как мультикастинг не является надежным, это требует периодического анонсирования меток, что приведет повторным оповещениям об одних и тех же метках.
2. Другой подход заключается в том, что LSR рассылает анонсирования меток уникастно с привлечением, например, протокола TCP всем другим (или всем заинтересованным) LSR, подключенным к общему каналу.

Так как LSP оправданы, если они живут долго, и так как число LSR в используемом совместно канале ограничено, второй подход представляется предпочтительным.

Другой момент, связанный с мультикастингом в сетях с множественным доступом, сопряжен с тем, следует ли использовать для присвоения меток вышестоящий или нижестоящий LSR. Для мультикастного трафика, использование вышестоящего LSR проще, так как там может быть только один вышестоящий узел, принадлежащий данному мультикастному дереву. Этот (вышестоящий) узел может присвоить уникальную метку для заданного FEC. Рассылка меток “вниз по течению” должна учитывать тот факт, что может быть много нижестоящих узлов в заданном дереве для канала с множественным доступом; каждый узел может предложить свою метку для FEC, что потребует некоторого разбирательства, чтобы каждому мультикастному FEC была присвоена лишь одна метка.

Раз метка присвоена, может возникнуть ситуация, когда инициатор возникновения данной метки покинет данное дерево. В случае присвоения меток “вниз по течению”, это может случиться, когда инициатор присвоения покинет группу. В случае присвоения меток “вверх по течению” это может случиться, когда в вышестоящем LSR происходят изменения, сопряженные с вариацией топологии рассылки уникастных сообщений.

10. Дополнительные выводы
10.1. Поле TTL

Поле TTL в IP-заголовке обычно используется для детектирования петель. В IP мультикастинге оно также используется для ограничения области распространения пакетов. Таким образом, в LSR, которые не поддерживают функция декрементации TTL (например, ATM LSR), функция ограничения области действия пострадает. Предположим, что можно вычислить заранее число шагов для заданного LSP. В уникастном LSP значение TTL может декрементироваться на входе или выходе из узла. В случае мультикаста все ветви дерева могут иметь разную длину, так что TTL может декрементироваться только на выходе, потенциально растрачивая полосу пропускания, если TTL окажется меньше или равным нулю.

10.2. Независимое управление рассылкой меток против упорядоченного

Существующая терминология для рассылки меток определена лишь для уникастного случая. Далее рассматривается, какой смысл эти термины могут иметь в случае мультикастинга.

При независимом управлении ([ANDE]) каждый LSR может взять на себя инициативу присвоения меток. При упорядоченном управлении ([ANDE]) LSR ассоциирует метку, когда он уже получил ее от последующего узла.

Все описанные выше методы запуска процесса формирования дерева (раздел 5) имеют отношение к независимому управлению. Заметим, что если используется подход с запуском по запросу при независимом управлении, рассылка меток осуществляется, как если бы применялось упорядоченное управление: управляющие сообщения направляются от выходного узла “вверх по течению”, реализуя ту же последовательность анонсирования меток.

Упорядоченное управление не применимо для запуска, управляемого трафиком в случае, когда узел не поддерживает смешенную L2/L3 переадресацию. Согласно таблице 2, этот случай предполагает, что метки запрашиваются вышестоящим LSR. Предположим, что на рис. 11 имеется LSP от S до R1 и нужно проложить новую вервь до R2. B будет воспринимать метки канала A - B только если они уже ассоциированы с каналом B-C. Однако для того чтобы определить метку для канала B-C, B должен уже получать трафик со стороны канала A-B.

Рис. 11.

10.3. Режимы консервативного и либерального удержания меток

В консервативном режиме ([ANDE]) только метки, которые используются для переадресации (если следующим шагом для FEC является LSR, который анонсировал метку), присваиваются и поддерживаются. В либеральном режиме метки анонсируются и поддерживаются для всех соседей. Либеральный режим не чувствителен к мультикастингу. Для этого имеется две причины:

1. Все LSR имеют маршрут для каждого уникастного FEC. Это не верно для мультикастных FEC.
2. Для мультикастинга LSR всегда знает, какому соседу следует посылать запросы метки или сообщения о присвоении. Например, в уникастном режиме Downstream Unsolicited (смотри ниже) LSR не знает, куда посылать ассоциацию метки, и в результате должен посылать ее всем своим соседям. В этом случае при поддержке либерального режима лишние сообщения не посылаются (необходима дополнительная статусная информация и некоторое пространство меток) и таким образом порог поддержки либерального режима следует рассмотреть ниже.

В таблице 3 показаны случаи, когда LSR знает, куда посылать запрос на метку.

Таблица 3. Знает ли LSR, куда посылать запросы меток?

Для уникастного потока, LSR могут определить LSR следующего шага, которому следует послать запрос в случае режима работы Upstream Unsolicited или Downstream on Demand. LSR, однако, не может определить маршрутизатор предшествующего шага. Предыдущий шаг необязательно является следующим шагом в направлении отправителя, так как путь от A к B не обязательно совпадает с путем от B к A. Такая ситуация может случиться в результате асимметричных метрик в канале или в случае, когда имеется несколько маршрутов с идентичной метрикой [PAXS].

В случае мультикастинга, LSR знает как следующий шаг, так и предыдущий. Так как мультикастные деревья формируются реверсивным методом кратчайших путей, предшествующим шагом всегда является следующий узел по направлению к отправителю или корню дерева.

10.4. Выделение меток “вверх и вниз по течению”

Метка может быть выделена либо нижестоящим LSR (режимы Downstream on Demand, Downstream Unsolicited) или вышестоящим LSR (режимы Upstream on Demand, Upstream Unsolicited, неявный). Преимущества выделения меток “вниз по течению” перечислены ниже:

1. Это тот же самый режим, что и в случае уникастного LDP, таким образом исключается необходимость разработки процедур рассылки меток “вверх по течению”.
2. Можно использовать ту же метку, когда меняется вышестоящий LSR из-за изменения маршрута, что является преимуществом для сетей с множественным доступом (смотри раздел 9).
3. Совместимо с piggy-backing (особенно для режима рассылки “вниз по течению”).

Преимущество присвоения меток вышестоящим объектом заключаются в следующем:

1. Проще выделение меток для сетей с множественным доступом (смотри раздел 9).
2. Может использоваться та же метка, когда нижестоящий LSR (который мог быть инициатором выделения метки в режиме “вниз по течению” в сети с множественным доступом) покидает группу (смотри раздел 9).
3. Режимы рассылки “вверх по течению” и неявный допускают более быстрое установление LSP, когда осуществляется запуск LSP трафиком.

10.5. Явная и неявная рассылки меток

Помимо режимов явной рассылки меток (которые используют сигнальный протокол), [ACHA] предлагается метод неявной рассылки меток, использующий неизвестные метки. Этот метод имеет все преимущества выделения меток “вверх по течению” и является, вероятно, самым быстродействующим способом анонсирования меток для запуска формирования LSP трафиком.

Неявная рассылка меток не применима, если ассоциация FEC-метка была анонсирована до прихода трафика, например, явная маршрутизация (т.е. если в пакете нет всей необходимой информации, чтобы идентифицировать FEC). Явная рассылка меток допускает предварительное установление LSP (до прихода данных) по топологии или по запросу.

Ссылки