Previous: 4.4.20 Требования для управления трафиком    UP: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
Down: 4.5 Процедуры Интернет
    Next: 4.5 Процедуры Интернет

Перевод RFC-3353
Аннотация

В данном документе формулируются принципы внедрения IP -мультикастинга в среду MPLS. Представлен обзор последствий внедрения технологии MPLS в IP-мультикастинг. Рассматриваются плюсы и минусы существующих IP-мультикастинговых протоколов маршрутизации в контексте и обсуждаются соотношения различных способов запуска процессов формирования виртуальных путей на основе использования меток. Перечислены последствия применения различных технологий уровня 2 (L2). Обсуждаются сетевые схемы точка-точка и сети с множественным доступом.

Таблица сокращений

1. Введение

В облаке MPLS маршруты определяются протоколом уровня L3. Чтобы улучшить рабочие характеристики сети эти маршруты могут быть преобразованы в пути уровня L2. Кроме этого, MPLS предлагает средства улучшения сетевых услуг, такие как QoS/CoS, управление трафиком и т.д.

Существующие уникастные протоколы маршрутизации формируют некоторый (оптимальный) кратчайший путь для определенной пары отправитель-получатель. Заметим, что уникастные протоколы могут работать по-разному в случае путей с эквивалентной метрикой. Для мультикастинга оптимальное решение (минимальная цена соединения N узлов) предполагает вычисление дерева Штайнера (Steiner). К сожалению, ни один современный мультикастный протокол маршрутизации не может сформировать такого дерева. Разные мультикастные протоколы формируют различные деревья.

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

2. Характеристики уровня 2

Хотя MPLS является мультипротокольным как для L3, так и L2, на практике IP рассматривается в качестве единственного протокола для L3. MPLS может работать поверх нескольких технологий L2 (PPP/Sonet, Ethernet, ATM, FR и т.д.).

Когда переключение на основе меток переносится на уровень L2 (например, в качестве метки используются поля VPI/VCI), внимание фокусируется в основном на ATM [DAVI]. ATM предлагает высокие переключающие возможности и доступность обеспечения QoS, но в контексте имеет ряд ограничений, которые описаны в [DAVI]. Аналогичные соображения представлены для случая Frame Relay на уровне L2 в [CONT]. Ограничения можно суммировать как:

• Ограниченное пространство меток: стандартизованное или реализованное число бит метки может быть мало (например, область VPI/VCI, пространство DLCI), ограничивая число LSP, которое может быть сформировано.
• Объединение: некоторые технологии или реализации L2 не поддерживают соединения многоточка-точка и/или многоточка-многоточка, блокируя объединение LSP.
• TTL: технологии L2 не поддерживают функцию TTL-декрементации.

Все три ограничения могут оказать сильное влияние на реализацию мультикастинга в MPLS.

Когда базовый MPLS будет разработан эти ограничения исчезнут. Более того, для каналов PPP и Ethernet может быть использована одна и та же метка для уникастного и мультикастного LSP, так как для уникастного и мультикастного определены разные коды EtherTypes [ROSE].

3. Систематика мултикастных IP протоколов маршрутизации в контексте MPLS

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

- Агрегатирование
- Широкая рассылка и отсекание ветвей (Flood &Prune)
- Деревья с общим отправителем
- Сосуществование деревьев отправителя и совмещенных деревьев
- Одно и двунаправленные совмещенные деревья
- Инкапсулированные мультикастинг-данные
- Отсутствие петель

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

3.1. Агрегатирование

В уникастинге различные адреса места назначения объединяются в одной записи маршрутной таблицы, предоставляя один FEC и один LSP.

Гранулярность мультикастинг потоков равна (*, G) для совмещенных деревьев и (S,G) для деревьев отправителя, где S - адрес отправителя, а G - мультикастинг адрес группы.

3.2. Широкая рассылка и отсекание ветвей

Чтобы сформировать мультикаст дерево протоколы маршрутизации (например, DVMRP, PIM-DM) широко рассылают мультикаст-данные. Отдельные ветви могут быть затем отсечены узлами, которые не хотят получать данные определенных мультикастинг-групп. Этот процесс периодически повторяется.

Широкая рассылка и отсекание ветвей протоколов мультикастинг-маршрутизации имеет некоторые характеристики, которые значительно отличаются от параметров уникастных маршрутных протоколов:

1. Изменчивость. Из-за особенностей протокола Flood & Prune, генерируются деревья с разными структурами. Решения о соответствии динамических деревьев L3 p2mp и L2 p2mp LSP должны быть эффективными с точки зрения сигнальных издержек и времени установления LSP. Варьируемые L2 LSP потребуют большого числа меток, что является недостатком при ограниченном их многообразии.
2. Управление трафиком. Маршрутизатор лишь определяет состояние для определенной группы, когда для нее поступают данные. Маршрутизаторы также независимо принимают решение об удалении состояния, когда истекает время таймера пассивности.

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

- Так как формирование и ликвидация маршрута L3 в каждом узле запускается самим трафиком, это предполагает, что LSP, ассоциированный с маршрутом, формировался и уничтожался также процедурой, управляемой трафиком.

- Если LSR не поддерживает переадресацию L3, технология управления трафиком требует, чтобы вышестоящий LSR брал на себя инициативу формирования LSP (анонсирование меток Upstream Unsolicited или Downstream on Demand).

3.3.  Деревья с общим отправителем

Мультикастные IP протоколы маршрутизации формируют либо деревья отправителя (S,G), т.е. по дереву для каждого отправителя (S) и для группы (G), или деревья с совмещением (*, G), т.е. одно дерево для каждой мультикаст-группы (Рис. 1).

Рис. 1. Дерево с совмещением и деревья отправителя

Преимуществом использования деревьев с совмещением, в случае применения переключения по меткам, является то, что деревья с совмещением требуют меньше меток, чем деревья отправителя (1 метка на группу против одной метки на отправителя и на группу). Однако проецирование деревьев с совмещением на уровень L2 подразумевает формирование LSP мультиточка-мультиточка (mp2mp).

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

3.4. Сосуществование деревьев с совмещением и деревьев отправителя

Некоторые протоколы поддерживают как деревья отправителя, так и деревья с совмещением (например, PIM-SM) и один маршрутизатор может содержать (*, G) и (S,G) состояния для одной и той же группы G. Два случая сосуществования описаны ниже. Рассмотрим топологии с отправителями Si и получателями Ri. RP является точкой встречи (Rendezvous Point). Ni представляют собой LSR. Числа являются номерами интерфейсов, "Reg" - интерфейс Register. Все сообщения IGMP и PIM Join/Prune показаны на рисунках. Индицируется состояние бита RPT для состояния (S,G).

1) На рис. 2 показан переход от совмещенного дерева к дереву отправителя. Предположим, что кратчайший путь от R1 к RP пролегает через N1-N2-N5. N1, выделенный маршрутизатор получателя (Designated Router) R1, (DRrecv) решает инициализировать дерево отправителя для S1. После получения данных через дерево отправителя в N2, N2 пошлет команду отсечения в N5 для отправителя S1. Состояние сосуществования реализуется в узле, где начинается перекрытие деревьев с совмещением и отправителя (N2), и в узле, где S1 не нуждается более в переадресации на дерево с совмещением (N5).

IJ=Igmp Join; PJ=Pim Join (*,G); PJS=Pim Join (S1,G); PPS=Pim Prune (S1,G)

Рис. 2

Ниже перечислены состояния, которые формируются в мультикастинг таблице маршрутизации (MRT):

в RP: (*,G):Reg->1 (т.е. входящее itf=Reg; исходящее itf=1)
в N1: (*,G):2->1
в N2: (*,G):3->1
   (S1,G):2->1
в N3: (S1,G):2->Reg,1
в N4: (*,G):2->1
в N5: (*,G):2->1,3
  (S1,G)RPT-бит:2->1

2) На рис. 3 показано, что состояние сосуществования может иметь место даже без переключения. Мультикастный трафик от отправителя сформирует состояние (S, G) в выделенном маршрутизаторе отправителя (DRsend; N3 на рис. 3 является DRsend отправителя S). Каждый узел совмещенного дерева имеет состояние (*,G). Таким образом Rsend имеет состояния (*, G) и (S,G). Если DRsend находится на дереве, он пошлет команду отсечения (prune) для S в направлении RP, формируя состояние (S,G) во всех узлах вплоть до первого маршрутизатора, который имеет ответвление (N1 и N2 на рис. 3).

Рис. 3

Состояния, формируемые при мультикастинг-маршрутизации в MRT, представлены ниже:

в RP (*,G):Reg->1 (т.е. входящее itf=Reg; исходящее itf=1)
в N1: (*,G):1->2,3
  (S,G)RPT-бит:1->2
в N2: (*,G):1->2
  (S,G)RPT-бит:1->none
в N3: (*,G):1->3
  (S,G):2->Reg,3
в N4: (*,G):1->2
в N5: (*,G):1->2

В данных примерах можно видеть, что могут иметь место два типа сосуществования:

1. (S,G) с нулевым RPT-битом (N2 на рис. 2, N3 на рис. 3). Состояния (*,G) и (S,G) имеют разные входные интерфейсы, но некоторые выходные интерфейсы являются общими. Возможно, что трафик S приходит через интерфейсы (*, G) и (S,G). При обычной переадресации L3 (S,G) SPT-бит запрещает переадресацию трафика из S, приходящего через входной интерфейс (*,G). Трафик S может только временно приходить через входные интерфейсы как (*, G), так и (S,G) (вплоть до N5 на рис. 2 и N1 на рис. 3 обработали сообщения prune). Чтобы избежать временной переадресации дубликатов пакетов L3, переадресация может быть применена к этому типу узлов. Если не предполагается временной переадресации дубликатов пакетов, может быть применена переадресация на уровне L2. В этом случае потоки (*, G) и (S,G) должны быть совмещены в (*, G) LSP выходного интерфейса.
2. (S,G) с RPT-битом =1 (N5 на рис. 2, N1 и рис. 3). Состояние (*,G) и (S,G) имеет тот же входной интерфейс. Трафик (S,G) должен извлекаться из потока (*,G). В MPLS это состояние сосуществования может обрабатываться разными способами. Будет рассмотрено четыре подхода к решению этой проблемы:

1. Первый метод обработки этого состояния сосуществования заключается в завершении LSP и переадресация всего трафика этой группы на L3. Однако можно избежать возврата на L3 в случае (S,G), когда к MRT не добавляется исходящий интерфейс (N2 на рис. 3). Этот вход будет принимать трафик только временно. В этом конкретном случае можно игнорировать состояние (S,G) и поддерживать существующий (*, G) LSP. Недостатком этого варианта является дублирование трафика в течение короткого времени.
2. Вторым подходом является присвоение отправителю специфических меток для узлов, принадлежащих совмещенным деревьям. Одному набору (*, G) будет присвоено несколько меток, по одной на каждый активный источник пакетов. Так как узлы знают только, какие отправители активны, когда получают от них трафик, LSP не могут быть сформированы заранее и нужны быстрые способы установления LSP.
3. Третий способ заключается в том, что только деревья отправителя используются для коммутации по меткам, а трафик в совмещенных деревьях всегда переадресуется на уровне L3. Это предполагает, что используются только совмещенные деревья, как средство для получателей выяснить, кто является отправителем. Конфигурируя порог переключения для низких скоростей передачи, можно гарантировать, что получатели переключаются на дерево отправителя достаточно быстро.
4. В четвертом подходе LSR, который имеет состояние (S,G) RPT-бит с ненулевым oif, анонсирует метку для (S,G) вышестоящему LSR и это анонсирование распространяется затем каждым вышестоящим LSR в направлении RP. Таким способом выделенный LSP формируется для трафика (S,G) от RP к LSR с состоянием (S,G) RPT-бит. В последнем LSR, (S,G) LSP объединяется в (*,G) LSP для соответствующих выходных интерфейсов. Это гарантирует, что пакеты (S,G), движущиеся вдоль совмещенного дерева, не пройдут через LSR, которые отсечены от S.

3.5. Одно и двунаправленные деревья с совмещением

Двунаправленные деревья с совмещением (например, CBT [BALL]) имеют недостаток, который связан с формированием большого числа точек смежности (M) в узлах (N) совмещенного дерева. На рис. 4 показаны эти точки, полученные при двух отправителях S1 и S2 двунаправленного дерева.

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

На рис. 5 показана та же ситуация для однонаправленных деревьев. В этом случае данные отправителя направляются через туннель к корневому узлу R, формируя всего одну точку смежности (сам корень дерева).

Рис. 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 имеет следующие преимущества:

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

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

b) Допускает использование триггера, управляемого трафиком, с режимом рассылки меток 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 хорошо адаптируется и для мультикастинга

a) Сообщения RSVP Resv могут быть совмещены.
b) Сообщения 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 (до прихода данных) по топологии или по запросу.

Ссылки

[ACHA]     A. Acharya, R. Dighe и F. Ansari, "IP Switching Over Fast ATM Cell Transport (IPSOFACTO) : Switching Multicast flows", IEEE Globecom '97.

[ADAM]     A. Adams, J. Nicholas, W. Siadak, Protocol Independent Multicast Version 2 Dense Mode Specification", Work In Progress.

[ANDE]     Andersson, L., Doolan, P., Feldman, N., Fredette, A. и R. Thomas, "LDP Specification", RFC 3036, January 2001.

[AWDU]    Awduche, D., Berger, L., Gan, D., Li, T., Swallow, G. yes">  и V. Srinivasan, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.

[BALL]      Ballardie, A., "Core Based Trees (CBT) Multicast Routing Architecture", RFC 2201, September 1997.

[CONT]      Conta, D., Doolan, P. и A. Malis, "Use of Label Switching on Frame Relay Networks", RFC 3034, January 2001.

[CRAW]     Crawley, E., Berger, L., Berson, S., Baker, F., Borden, M. и J. Krawczyk, "A Framework for Integrated Services и RSVP over ATM", RFC 2382, August 1998.

[DAVI]       Davie, B., Lawrence, J., McCloghrie, K., Rekhter, Y., Rosen, E., Swallow, G. и P. Doolan, "MPLS using LDP и ATM VC switching", RFC 3035, January 2001.

[DEER]      Deering, S., Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Handley, M., Jacobson, V., Liu, C., Sharma, P. и L Wei, "Protocol Independent Multicast-Sparse Mode (PIM-SM):   Protocol Specification", RFC 2362, June 1998.

[FARI]       D. Farinacci, Y. Rekhter, E. Rosen и T. Qian, "Using PIM to Distribute MPLS Labels for Multicast Routes", Work In Progress.

[FENN]      Fenner, W., "Internet Group Management Protocol, IGMP, Version 2", RFC 2236, November 1997.

[GARR]     Garrett, M. и M. Borden, "Interoperation of Controlled-Load Service и Guaranteed Service with ATM", RFC 2381, August 1998.

[HOLB]      H. Holbrook, B. Cain, "Source-Specific Multicast for IP", Work In Progress.

[MOY]       Moy, J., "Multicast Extensions to OSPF", RFC 1584, March 1994.

[NAGA]     Nagami, K., Demizu, N., Esaki, H., Katsube, Y. и P. Doolan, "VCID Notification over ATM link for LDP", RFC 3038, January 2001.

[PERL]       R. Perlman, C-Y. Lee, A. Ballardie, J. Crowcroft, Z. Wang, T. Maufer, "Simple Multicast", Work In Progress.

[PUSA]      T. Pusateri, "Distance Vector Multicast Routing Protocol", Work In Progress.

[PAXS]      V. Paxson, "End-to-End Routing Behavior in the Internet", IEEE/ACM Transactions on Networking 5(5), pp. 601-615.

[ROSE]      Rosen, E., Rekhter, Y., Tappan, D., Farinacci, D., Fedorkow, G., Li, T. и A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.

Previous: 4.4.20 Требования для управления трафиком    UP: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
Down: 4.5 Процедуры Интернет    Next: 4.5 Процедуры Интернет