Комбинации режимов запуска и рассылки меток
В таблице 2 приведены допустимые комбинации методов рассылки меток и запуска формирования LSP, которые были обсуждены в предыдущих разделах. (X) означает, что комбинация допустима, если LSR поддерживает смешанную переадресацию L2/L3.
Таблица 2. Допустимые комбинации методов запуска и рассылки меток
6. Перенос меток (Piggy-backing)
На рис. 9 (outgoing case) можно видеть, что вместо отправки двух отдельных сообщений, анонсирование метки может осуществляться посредством существующих управляющих сообщений. Для мультикастинга имеется два кандидата для транспортировки (piggy-back):
- Мультикастные маршрутные сообщения: протоколы, такие как PIM-SM и CBT, имеют сообщения Join, которые могут нести в себе мэппинг меток. Этот подход описан в [FARI]. Когда установлены различные протоколы для мультикастинг-маршрутизации, должны быть определены расширения для каждого из этих протоколов.
- Сообщения Resv RSVP: объект расширения мэппинга меток для RSVP, также применим в мультикастинге (предложено в [AWDU]).
За и против транспортировки меток с привлечением мультикаст маршрутных сообщений рассматриваются ниже. Такой вид транспортировки имеет следующие преимущества:
- Если анонсирование меток осуществляется мультикаст маршрутными сообщениями, тогда рассылка маршрутов и меток оказываются синхронизованными. Это исключает сложные ситуации типа "что я должен делать с меткой, если у меня пока нет подходящего рекорда в маршрутной таблице?". Это также минимизирует интервал между установлением мультикаст-маршрута и ассоциацией метки и маршрута.
- Число управляющих сообщений, необходимое для поддержания анонсирования меток, помимо используемых для осуществления мультикастной маршрутизации, равно нулю.
Можно отметить следующие недостатки такого типа транспортировки:
- В некоторых протоколах нет сообщений, с помощью которых можно доставлять сообщения о метках. Для таких протоколов предлагается [FARI] добавить периодически рассылаемые сообщения, которые сильно влияют на работу мультикастинг маршрутного протокола и сводят на нет выгоды совмещенной транспортировки (piggy-backing).
- Второе решение проблемы сосуществования состояний (смотри 3.4) не может быть применено в сочетании с совмещенной транспортировкой (с piggy-backing).
- Совмещенная транспортировка требует расширения мультикастного протокола маршрутизации, и следовательно становится менее привлекательной, если анонсирование меток требует поддержки нескольких мультикастных протоколов маршрутизации.
- Совмещенная транспортировка предполагает режим рассылки меток Downstream Unsolicited, это исключает несколько методов запуска процесса формирования LSP (смотри таблицу 2).
- LDP обычно работает поверх TCP, предполагая надежный обмен между узлами-партнерами. Совмещенная транспортировка сообщений о метках часто замещает надежный обмен на периодическую рассылку анонсирований меток. Из-за этого периодического анонсирования меток управляющий трафик (в байтах) увеличится.
- Если необходим механизм оповещения VCID [NAGA], он может быть реализован путем посылки сообщений LDP bind через вновь сформированный виртуальный канал VC. Для этого необходимо лишь одно сообщение. Такой метод не может комбинироваться с совмещенной транспортировкой, так как маршрутные сообщения посылаются до того как будет сформирован VC. Таким образом, необходим дополнительный диалоговый обмен, сокращающий выгоды совмещенной транспортировки.
Совмещенная транспортировка является лишь одним возможным компонентом мультикастного решения для.
