Агрегатирование
В уникастинге различные адреса места назначения объединяются в одной записи маршрутной таблицы, предоставляя один FEC и один LSP.
Гранулярность мультикастинг потоков равна (*, G) для совмещенных деревьев и (S,G) для деревьев отправителя, где S - адрес отправителя, а G - мультикастинг адрес группы.
Одним из путей распределения трафика в FEC является создание отдельного FEC для каждого адресного префикса, появляющегося в маршрутной таблице. Однако в пределах области MPLS, это может вызвать определенные последствия для набора FEC, в частности, все потоки в этих FEC будут следовать одним и тем же маршрутом. Например, набор различных адресных префиксов может иметь один и тот же выходной узел, а обмен меток может быть использован только для доставки трафика до выходного узла. В этом случае, в пределах домена MPLS, объединение таких FEC само является классом FEC. Это предлагает выбор: следует ли ассоциировать отдельные метки с каждым компонентом FEC, или следует ли ассоциировать отдельную метку с объединением, а метку использовать для всего трафика в объединении? Процедура ассоциации отдельной метки с объединением FEC, который сам является FEC (внутри некоторого домена), и применения меток для трафика в объединении, называется "агрегатированием". Архитектура MPLS допускает агрегатирование. Агрегатирование может уменьшить число меток, с которыми нужно иметь дело заданному набору пакетов, и может сократить объем управляющего трафика.
Данный набор FEC, который является "агрегатируемым" в одном FEC, допускается (a) агрегатировать их в один FEC, (b) агрегатировать их в набор FEC, или (c) не агрегатировать их совсем. Таким образом, мы можем говорить о "гранулярности" агрегатирования, начиная с (a) "грубой гранулярности", кончая (c) "тонкой гранулярностью".
Когда используется упорядоченное управление, каждый LSR должен адаптировать для данного набора FEC гранулярность, используемую на следующем шагу для этих FEC.
Когда используется независимое управление, допускается, чтобы имелись два смежных LSR, Ru и Rd, которые агрегатируют некоторый набор FEC по-разному.
Если Ru имеет более тонкую гранулярность, чем Rd, это не создает проблем. Это означает, что, когда Ru нужно переадресовать помеченные пакеты для этих FEC в Rd, может потребоваться установить соответствие между n и m метками, где n > m. В качестве опции Ru может отозвать набор из n меток, который он разослал, и затем разослать набор из m меток, соответствующих уровню гранулярности Rd. Совсем не нужно гарантировать корректность операции, но это вызовет сокращение числа меток, разосланных Ru, Ru не получает какого-либо преимущества при рассылке большего числа меток. Решение делать это или нет, является исключительно локальным.
Если Ru имеет более грубую гранулярность, чем Rd (т.e., Rd разослал n меток для набора FEC, в то время как Ru разослал m, где n > m), имеется два варианта:
- Можно принять более тонкий уровень гранулярности для Rd. Это бы потребовало отзыва разосланных m, и рассылки n меток. Это предпочтительная опция.
- Можно просто установить соответствие между m метками и субнабором Rd из n меток, если он может определить, что это не изменит маршрутизацию. Например, предположим, что Ru использует одну метку для всех потоков, которые должны пройти определенный выходной LSR, тогда как Rd привязывает к такому трафику некоторое число разных меток, в зависимости от места назначения пакетов. Если Ru знает адрес выходного маршрутизатора, и, если Rd связал метку с FEC, который идентифицирован этим адресом, тогда Ru может просто использовать эту метку.
В любом случае, каждый LSR должен знать (при конфигурации) какую гранулярность использовать для формируемых меток. Когда используется упорядоченное управление, требуется чтобы каждый узел знал гранулярность только для FEC, который покидает сеть MPLS в этом узле. Для независимого управления, наилучший результат может быть получен, путем конфигурации всех LSR так, чтобы они знали гранулярность каждого FEC. Однако во многих случаях это может быть сделано путем использования одной метки с гранулярностью, которая реализует все FEC (такой как "одна метка на IP-префикс таблицы переадресации" или "одна метка на выходной узел").
