Сети и телекоммуникации

501

Если Ru имеет более мелкий уровень разделения по сравнению с Rd,то проблем не возникнет. Ru распределяет (доставляет) больше маркеров для дан-

ной совокупности FEC-классов, чем это делает Rd. Это означает следующее.

Если Ru необходимо доставить Rd помеченные IP-пакеты, относящиеся к ука-

занным FEC-классам, то ему может понадобиться провести процедуру отобра-

жения n маркеров в m маркеров, где n > m. Очевидно, что Ru может изъять (ан-

нулировать) распределѐнные им n маркеров, а затем распределить набор из m

маркеров, что соответствует уровню разделения Rd. Нет необходимости обеспе-

чения каких-либо гарантий корректности указанной операции, а вот еѐ резуль-

тат приведѐт к уменьшению числа маркеров, распределѐнных Ru, и сам Ru не получит каких-либо преимуществ от распределения большего числа маркеров.

Решение о проведении или не проведении такой операции принимается на ло-

кальном уровне.

Если Ru имеет более крупный уровень разделения по сравнению с Rd (т.е.

Rd распределил n маркеров для некоторой совокупности FEC-классов, а Ru рас-

пределил m маркеров, где n > m), то возникает дилемма:

можно адаптировать более мелкий уровень разделения у Rd. Это могло бы потребовать от него изъятия распределѐнных им m маркеров, и распреде-

ления n маркеров. Такой подход наиболее предпочтителен;

можно просто отобразить m маркеров в подмножество nмаркеров у Rd,

если, конечно, последний сможет определить, что такая процедура при-

ведѐт к одному и тому же маршруту. Например, предположим, что Ru ис-

пользует один маркер для всего трафика, который необходимо доставить через определѐнный выходной LSR-маршрутизатор, в то время как Rd

привязал несколько различных маркеров к этому же трафику, основыва-

ясь только на индивидуальных адресах получателей в IP-пакетах. Если Ru

знает адрес выходного маршрутизатора, и если Rd привязал маркер к FEC-

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

502

В любом случае, каждому LSR-маршрутизатору необходимо знать (с по-

мощью процедуры настойки), какой уровень разделения агрегированных FEC-

классов следует использовать по отношению к маркерам, которые он им при-

сваивает (к ним привязывает). Если используется регулируемое управление, то необходимо, чтобы каждый сетевой узел знал уровень разделения только для тех агрегированных FEC-классов, которые «покидают» MPLS-сеть в данном узле. При независимом управлении, наилучший результат может быть достиг-

нут только путѐм обеспечения гарантий того, что все LSR-маршрутизаторы на-

строены соответствующим образом и знают уровень разделения для каждого

FEC-класса. Тем не менее, во многих случаях этого можно достичь путѐм ис-

пользования «поэкземплярного» уровня разделения, который применяется ко всем FEC-классам (например, «один маркер на каждый префикс IP-адреса», или

«один маркер на каждый выходной узел»).

Выбор маршрута

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

маршрута в интересах определѐнного FEC-класса. MPLS-архитектура устанав-

ливает два варианта выбора маршрута:

1.«поузловая» маршрутизация (hop by hop routing);

2.«явная (точная)» маршрутизация (explicit routing).

Поузловая маршрутизация позволяет каждому сетевому узлу независимо

выбирать следующий РУ для каждого FEC-класса. На сегодня этот вариант маршрутизации является наиболее распространенным в существующих IP-

сетях. «LSP-маршрут на основе поузловой маршрутизации» (hop by hop routed LSP) представляет собой LSP-маршрут, который «прокладывается» с использо-

ванием поузловой маршрутизации.

В случае «LSP-маршрута на основе явной маршрутизации» (explicitly routed LSP) каждый LSR-маршрутизатор не может независимо выбирать сле-

дующий РУ. Как правило, одиночный LSR-маршрутизатор, обычно выходной

503

или выходной LSP-маршрута, определяет несколько или все LSR-маршрутиза-

торы на LSP-маршруте. Если одиночный LSR-маршрутизатор определяет весь

LSP-маршрут, то такой LSP-маршрут представляет собой «точно» (strictly) про-

ложенный маршрут на основе явной маршрутизации. Если одиночный LSR-

маршрутизатор определяет только часть некоторого LSP-маршрут, то такой

LSP-маршрут представляет собой «неточно» (loosely) проложенный маршрут на основе явной маршрутизации.

Последовательность LSR-маршрутизаторов, составляющая LSP-маршрут на основе явной маршрутизации, может быть определена с помощью процеду-

ры настройки, или может быть выбрана одиночным сетевым узлом в динамиче-

ском режиме. Например, выходной сетевой узел может использовать топологи-

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

заканчивающемся в этом выходном сетевом узле.

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

при использовании политики маршрутизации или при регулировании трафика

(traffic engineering). В MPLS-системах явный маршрут должен быть определен в момент времени, когда устанавливаются маркеры потока, но, с другой сторо-

ны, явный маршрут не должен устанавливаться для каждого IP-пакета. Такой подход делает явную маршрутизацию в MPLS-системах гораздо более эффек-

тивной по сравнению с маршрутизацией от источника IP-пакета.

Процедуры выбора «точно» или «неточно» прокладываемого маршрута на основе явной маршрутизации в данном стандарте не рассматриваются.

Отсутствие исходящего маркера

Когда помеченный IP-пакет следует по LSP-маршруту, неожиданно мо-

жет возникнуть ситуация, при которой IP-пакет достиг LSR-маршрутизатора,

не выполняющего ILM-процедуру отображения входного маркера из этого IP-

пакета в NHLFE-запись, даже если входящий маркер является корректным. Та-

504

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

са, либо вследствие ошибки в LSR-маршрутизаторе, который должен быть на следующем РУ для IP-пакета.

В таких случаях весьма заманчивой становится процедура удаления на-

бор меток и попытка доставить IP-пакет дальше с помощью традиционной про-

цедуры ретрансляции, основываясь при этом только на заголовок сетевого уровня (IP-заголовок). Однако, такая процедура, в общем, не безопасна, так как:

если IP-пакет следует по LSP-маршруту на основе явной маршрутизации,

то в результате мог бы образоваться петлевой маршрут;

IP-заголовок может содержать не достаточно информации для его обра-

ботки соответствующим LSR-маршрутизатором, чтобы IP-пакет был ретранслирован корректно.

До тех пор, пока не определено, что делать в указанных ситуациях (а это

вданном документе не рассматривается), самым надѐжным и безопасным спо-

собом является удаление IP-пакета.

Время жизни IP-пакета (Time-to-Live, TTL)

При обычной ретрансляции IP-пакета, последний содержит в IP-заголовке поле «Time-To-Live» (время жизни) с некоторым значением. Всякий раз, когда

IP-пакет «проходит» через маршрутизатор, значение в TTL-поле IP-заголовка этого пакета уменьшается на единицу. Если TTL-поле обнулилось ещѐ до того,

как IP-пакет достиг своего получателя, то IP-пакет уничтожается.

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

вие медленной сходимости последнего. Иногда TTL-поле используется и в дру-

гих целях, например, в целях применения групповой IP-адресации и поддержки управляющей команды «traceroute» (трассировка (прокладка) маршрута). Из

505

этого следует, что существуют две проблемы, связанные с использованием

TTL-поля, которые необходимо решить в рамках MPLS-архитектуры:

i.TTL-поле используется для предотвращения петлевых маршрутов;

ii.TTL-поле используется для реализации других функций, например, огра-

ничение времени существования IP-пакета.

Когда IP-пакет «продвигается» по LSP-маршруту, тогда необходимо со-

хранять именно то значение в TTL-поле, которое могло быть в IP-заголовке, ес-

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

заторов, но без MPLS-коммутации. Если IP-пакет «продвигается» по иерархи-

ческой последовательности из LSP-маршрутов, то общее число промежуточных

(«встречающихся на маршруте») LSR-маршрутизаторов должно отражаться в

TTL-поле этого IP-пакета, когда первоначальное значение в этом TTL-поле бы-

ло выбрано на основе иерархической последовательности из LSP-маршрутов.

Способ контроля значения в TTL-поле может варьироваться в зависимо-

сти от того, каким образом доставляется значение MPLS-маркера, либо с по-

мощью специализированного подзаголовка (вставки) MPLS-коммутации

(«shim», RFC-3032), либо с помощью заголовка канального уровня (например,

ATM-заголовок, RFC-3035, или FR-заголовок, RFC-3034).

Если значения маркеров потока закодированы и размещены в специали-

зированном MPLS-подзаголовке, находящемся между заголовками канального и сетевого уровней, то в MPLS-подзаголовке должно содержаться TTL-поле,

значение которого должно быть первоначально установлено путѐм копирова-

ния значения из TTL-поля заголовка сетевого уровня, должно уменьшаться на единицу при прохождении каждого ретрансляционного (промежуточного) LSR-

маршрутизатора, и должно копироваться в TTL-поле заголовка сетевого уровня,

когда IP-пакет «покидает» свой LSP-маршрут.

Если значения маркеров потока закодированы и размещены в заголовке канального уровня (например, в поле «VPI/VCI» ATM-заголовка адаптации, «AAL5»), и помеченные IP-пакеты транслируются коммутатором канального

506

уровня (например, АТМ-коммутатор), а модуль канального уровня (например,

АТМ-модуль) не предусматривает обработку TTL-поля, то исключается воз-

можность уменьшения значения в этом TTL-поле на единицу при прохождении каждого промежуточного LSR-маршрутизатора. Интервал LSP-маршрута,

включающий последовательность LSR-маршрутизаторов, которые не могут уменьшать значение в TTL-поле на единицу, будем называть «интервалом (сег-

ментом/участком) LSP-маршрута без обработки TTL-поля».

Когда IP-пакет покидает интервал LSP-маршрута без обработки TTL-поля,

тогда, тем не менее, целесообразно, чтобы TTL-поле присутствовало, а его зна-

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

чае однонаправленной адресации, это может быть обеспечено за счѐт распро-

странения протяжѐнности основного LSP-маршрута тем входным сетевым уз-

лам, которые позволяют снизить значение в TTL-поле еще до того, как транс-

лируемые IP-пакеты «попадут» в сегмент LSP-маршрута без обработки TTL-

поля.

Иногда указанное требование (число LSR-маршрутизаторов, пройденных

IP-пакетом) может быть обеспечено и после поступления IP-пакета в сегмент

LSP-маршрута без обработки TTL-поля, в котором значение TTL-поля истечѐт ещѐ до того, как IP-пакет достигнет выхода из этого сегмента. В таком случае,

LSR-маршрутизатор на входе участка LSP-маршрута без обработки TTL-поля обязан не осуществлять коммутацию IP-пакета на основе маркеров потока. Это означает, что должны быть разработаны специализированные процедуры для реализации функции трассировки маршрута, например, IP-пакеты для проклад-

ки маршрута могут доставляться с помощью традиционной поузловой комму-

тации и доставки.

Контроль возникновения петлевого маршрута

В пределах участка LSP-маршрута без обработки TTL-поля, по определе-

нию, TTL-поле не может использоваться для защиты от возникновения петле-

507

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

шрута может зависеть от соответствующего программно-аппаратного комплек-

сов (ПАК), используемых для реализации функций LSR-маршрутизаторов, и

расположенных на участке LSP-маршрута без обработки TTL-поля.

Предположим, например, что ПАК АТМ-коммутации используется для реализации функций MPLS-коммутации с одновременной доставкой маркеров потока в VPI/VCI-поле. Так как ПАК АТМ-коммутации не способен уменьшать значение в TTL-поле, соответственно не существует защиты от возникновения петлевых маршрутов. Если ПАК АТМ-коммутации способен обеспечить бес-

препятственный доступ к буферной памяти, используемой для хранения вхо-

дящих АТМ-ячеек, содержащих VPI/VCI-поля с различными значениями, то возникновение петлевых маршрутов не способно нанести какой-либо вред дру-

гому трафику. Если же ПАК АТМ-коммутации не способен обеспечить такой беспрепятственный доступ к буферной памяти, то, несмотря ни на что, даже быстро изменяющиеся петлевые маршруты могут стать причиной общего серь-

ѐзного ухудшения функционирования LSR-маршрутизаторов.

И даже если можно обеспечить беспрепятственный доступ к буферной памяти, то всѐ равно следует иметь определѐнные средства обнаружения петле-

вых маршрутов, которые «явно длиннее допустимых». Более того, даже если применение TTL-поля и/или соблюдение очерѐдности для каждого виртуально-

го соединения предоставляют средства обнаружения оставшихся циклических маршрутов, то по-прежнему такое обнаружение не возможно даже там, где спе-

циально запрещена настройка LSP-маршрутов, которые являются петлевыми.

Все LSR-маршрутизаторы, которые могут быть связаны с участком LSP-марш-

рута без обработки TTL-поля, всѐ равно будут запрашивать необходимую сис-

темную поддержку для обнаружения петлевых маршрутов. Тем не менее, при-

менение определѐнного способа выявления петлевых маршрутов является не обязательным (дополнительным). Такой способ представлен в стандартах RFC-

3035 и RFC-5036.

509

Следует отметить, что процедуры MPLS-доставки аналогичны тем суще-

ствующим коммутаторам, которые реализуют процедуры «смены маркеров»

(label swapping), например, АТМ-коммутаторы. Последние используют входной физический интерфейс и значение входного идентификатора VPI/VCI (иденти-

фикатор виртуального соединения/маршрута) в качестве индекса в таблице связности (cross-connect), по которой они определяют выходной физический интерфейс и значение выходного идентификатора VPI/VCI. Более того, если один или более маркеров могут быть непосредственно закодированы в полях заголовков протокольных сообщений, и которые будут доступны для обработки ныне существующими коммутаторами, то последние (с необходимым про-

граммным обеспечением) могут использоваться в качестве LSR-маршрутиза-

торов. В дальнейшем такие ПАК будут именоваться ATM/LSR-маршрутиза-

торы (ATM-LSR).

Существуют три очевидных способов кодирования маркеров в заголовке АТМ-ячейки (ATM cell header), полагая использование АТМ-уровня адаптации

«AAL5», а именно:

1.кодирование коммутируемого виртуального соединения (SVC encoding).

Этот способ предусматривает использование VPI/VCI-поля для кодиро-

вания маркера, который является самым верхним в наборе маркеров. Та-

кой способ может использоваться в любой сети. При использовании этого способа кодирования каждый LSP-маршрут представляет собой АТМ/SVC-соединение, а протоколом доставки (распределения) маркеров выступает протокол ATM-сигнализации (signaling). Если используется этот способ, то ATM/LSR-маршрутизаторы не могут реализовать функ-

ции «проталкивания» или «удаления» (выталкивания) набора маркеров;

2.кодирование коммутируемого виртуального маршрута (SVP encoding).

Этот способ предусматривает использование VPI-поля для кодирования маркера, который является самым верхним в наборе маркеров и VCI-поля для кодирования второго маркера из набора, если конечно он представлен.

510

Этот способ имеет ряд преимуществ по сравнению с первым, рассмот-

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

туального АТМ-маршрута. Т.е. LSP-маршруты настраиваются как комму-

тируемые виртуальные АТМ-маршруты на основе применения протокола доставки (распределения) маркеров, а именно протокола ATM-сигнали-

зации.

Тем не менее, этот способ нельзя использовать всегда. Если сеть включа-

ет виртуальный АТМ-маршрут, проходящий через АТМ-сеть, в которой отдельный сегмент этой сети не применяет MPLS-коммутацию, то VPI-

поле использовать для MPLS-коммутации бесполезно.

Если этот способ кодирования используется, то ATM/LSR-маршрутиза-

тор на выходе виртуального маршрута способен эффективно осуществ-

лять процедуру «удаления» (выталкивания) маркера;

3.многоузловое кодирование коммутируемого виртуального маршрута (SVP multipoint encoding). Этот способ предусматривает использование VPI-

поля для кодирования маркера, который является самым верхним в набо-

ре маркеров, VCI-поля для кодирования второго маркера из набора, если конечно он представлен, и оставшуюся часть VCI-поля для идентифика-

ции начала LSP-маршрута. Если используется данный способ, то стан-

дартные свойства коммутируемых виртуальных АТМ-маршрутов могут применяться для многоузловых виртуальных маршрутов. Ячейки, форми-

руемые на основе заголовков различных IP-пакетов, будут включать раз-

личные значения VCI-идентификаторов. Как мы увидим в дальнейшем,

такой подход позволяет осуществлять процедуру слияния маркеров АТМ-

коммутаторами (причѐм без каких-либо проблем, связанных с «чередова-

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

Данный способ зависит от наличия процедуры присвоения 16-битового значения VCI-идентификатора каждому АТМ-коммутатору, причѐм тако-