Geum.ru

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

Вид материалаЗадача
Подобный материал:
1   ...   41   42   43   44   45   46   47   48   ...   59
2.17.  LSP следующего шага

LSP Next Hop для определенного помеченного пакета в конкретном LSR является LSR, который представляет следующий шаг пути, как это выбрано записью NHLFE, использованной для переадресации пакета. LSP Next Hop для определенного FEC является следующим шагом пути, как это выбрано записью NHLFE, индексированной меткой, которая соответствует этому FEC.

Заметим, что LSP следующего шага может отличаться от того, который был бы выбран алгоритмом маршрутизации сетевого уровня. Мы будем использовать термин "следующий шаг L3", когда будем иметь в виду такой маршрут.
2.18.  Неверные входные метки

Что должен сделать LSR, если он получает помеченный пакет с определенной входной меткой, но не имеет ассоциации для этой метки? Соблазнительно думать, что можно просто удалить метки и пакеты будут переадресовываться как непомеченные IP. Однако в некоторых случаях, реализация этого приведет к зацикливанию пакетов. Если вышестоящий LSR полагает, что метка сопряжена с определенным маршрутом, а нижестоящий LSR не считает метку, связанной с чем бы то ни было, и если маршрутизация шаг-за-шагом непомеченных IP-пакетов приведет пакет назад к вышестоящему LSR, тогда образуется петля.

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

Следовательно, когда получен помеченный пакет с неверной входной меткой, он должен быть отброшен, если только он не определен каким-то способом, так что его переадресация не может вызвать никакого вреда.
2.19.  LSP управление: Ordered против Independent

Некоторые FEC соответствуют адресным префиксам, которые рассылаются алгоритмом динамической маршрутизации. Начальная установка LSP для этих FEC может быть выполнена двумя способами: независимым управлением LSP (Independent LSP Control) или упорядоченным управлением LSP (Ordered LSP Control).

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

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

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

Эта архитектура позволяет сделать выбор между независимым и упорядоченным управлением исключительно местной проблемой. Так как взаимодействуют два метода, данный LSR должен поддерживать один или другой метод. Вообще говоря, выбор независимого или упорядоченного управления не оказывает какого-либо эффекта на механизмы коммутации пакетов, базирующиеся на метках.
2.20.  Агрегатирование

Одним из путей распределения трафика в 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-префикс таблицы переадресации" или "одна метка на выходной узел").