| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
4.4.18 Архитектура мультипротокольной коммутации пакетов по меткам (MPLS) Семенов Ю.А. (ГНЦ ИТЭФ) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
(E. Rosen. Multiprotocol Label Switching Architecture, RFC-3031.) 1. Введение в MPLS В данном документе специфицирована архитектура многопротокольной коммутации меток (MPLS). 1.1. Обзор Поскольку пакеты в случае протокола сетевого уровня без установления соединения переносятся от одного маршрутизатора к другому, каждый из них совершенно независим в принятии решения переадресации. То есть, каждый маршрутизатор анализирует заголовок пакета и каждый маршрутизатор реализует алгоритм маршрутизации сетевого уровня. Маршрутизатор независимо выбирает следующий шаг для пакета, основываясь на результатах анализа его заголовка и результата работы маршрутного алгоритма. Заголовки пакета содержат значительно больше информации, чем нужно для выбора следующего шага. Выбирая следующий шаг можно, следовательно, выполнять две процедуры. Первая делит весь набор пакетов на классы FEC (Forwarding Equivalence Classes). Вторая ставит в соответствие каждому FEC следующий шаг маршрута. В той части, которая касается переадресации, разные пакеты, поставленные в соответствие определенному FEC, не различимы. Все пакеты, которые принадлежат определенному FEC, и которые отправлены из конкретного узла будут следовать одним и тем же путем (или в случае многомаршрутного протокола, они будут следовать через один и тот же набор путей, ассоциированный с FEC). При обычной IP переадресации, маршрутизатор рассматривает два пакета принадлежащими к одному FEC, если существует адресный префикс X в таблицах маршрутизации маршрутизатора, такой что Х, соответствует каждому адресу места назначения. Когда пакет проходит через сеть, на каждом шагу пакет последовательно просматривается и ему присваивается FEC. В MPLS присвоение пакету определенного FEC делается только раз, когда пакет входит в сеть. FEC, к которому приписан пакет, кодируется, как код фиксированной длины, называемый меткой. Когда пакет переадресуется на следующем шагу, метка посылается вместе с ним, так что пакеты оказываются помечены, до того, как будут переадресованы. При последующих шагах не производится никакого анализа заголовков пакетов сетевого уровня. Здесь для индексации следующего шага и новой метки используется присвоенная ему на входе метка. Старая метка замещается новой и пакет переадресуется в следующий узел. В парадигме переадресации MPLS, поскольку пакет приписан определенному FEC, никакого последующего анализа заголовков в маршрутизаторах по пути следования не производится, а переадресация управляется исключительно на основе меток. Это имеет много преимуществ перед традиционной маршрутизацией на сетевом уровне. - MPLS-переадресация может быть выполнена переключателями, которые способны осуществлять просмотр меток и их замещение, но не могут анализировать заголовки сетевого уровня (во всяком случае с достаточной скоростью). - Так как пакет поставлен в соответствие определенному FEC, когда он входит в сеть, входной маршрутизатор может использовать при определении соответствия любую информацию, которую он имеет о пакете, даже если такая информация не может быть извлечена из заголовка сетевого уровня. Например, пакеты, приходящие через разные порты, могут быть связаны с разными FEC. Традиционная переадресация может рассматривать только информацию, которая транспортируется внутри пакета в его заголовке. - Пакет, который входит в сеть через определенный маршрутизатор, может быть помечен иначе, чем такой же пакет, вошедший в сеть через другой маршрутизатор, и в результате решение о переадресации зависит от входного маршрутизатора и может быть легко осуществлено. Это не может быть сделано традиционной переадресацией, так как идентичность входного маршрутизатора не путешествует вместе с пакетом. - Соображения, которые определяют то, как пакету ставится в соответствие FEC, могут становиться даже более сложными, без каких-либо последствий для маршрутизаторов, которые просто переадресуют помеченные пакеты. - Иногда желательно заставить пакеты следовать определенным маршрутом, который выбран перед входом или во время входа пакета в сеть, вместо следования нормальному динамическому протоколу маршрутизации. Это может быть сделано в соответствии с разной политикой, или с привлечением техники управления трафиком. При традиционной переадресации это требует, чтобы пакет нес в себе информацию о маршруте, по которому он должен двигаться (маршрутизация отправителя). В MPLS, метка может использоваться для представления маршрута, так что идентичность маршрута не переносится вместе с пакетом. Некоторые маршрутизаторы анализируют заголовок пакета сетевого уровня не только с целью выбора следующего шага, но и для определения приоритета и класса услуг. Они могут затем применить различные пороги отсева или графика обслуживания пакетов. MPLS допускает (но не требует) приоритетность или класс обслуживания, зависящие полностью или частично от метки. В этом случае, можно сказать, что метка представляет собой комбинацию FEC, приоритета или класса обслуживания. В MPLS "Multiprotocol" означает многопротокольный, так как его техника применима к любому протоколу сетевого уровня. В данном документе, однако, внимание сконцентрировано на использовании IP в качестве протокола сетевого уровня. Маршрутизатор, который поддерживает MPLS, называется "Label Switching Router", или LSR (маршрутизатором с коммутацией по меткам). 1.2. Терминология
1.3. Акронимы и аббревиатуры ATM Asynchronous Transfer Mode – асинхронный режим передачи BGP Border Gateway Protocol – протокол внешней маршрутизации DLCI Data Link Circuit Identifier – идентификатор канала передачи данных FEC Forwarding Equivalence Class – класс переадресации FTN FEC to NHLFE Map – соответствие FEC и NHLFE IGP Interior Gateway Protocol – внутренний протокол маршрутизации ILM Incoming Label Map – таблица соответствия входящих меток IP Internet Protocol – протокол Интернет LDP Label Distribution Protocol – протокол пересылки меток L2 Layer 2 – уровень 2 L3 Layer 3 – уровень 3 LSP Label Switched Path – путь с коммутацией меток LSR Label Switching Router – маршрутизатор c коммутацией меток MPLS MultiProtocol Label Switching – многопротокольная коммутация меток NHLFE Next Hop Label Forwarding Entry – запись, содержащая адрес следующего шага при коммутации меток SVC Switched Virtual Circuit – переключаемая виртуальная схема SVP Switched Virtual Path – переключаемый виртуальный путь TTL Time-To-Live – время жизни VC Virtual Circuit – виртуальная схема VCI Virtual Circuit Identifier – идентификатор виртуальной схемы VP Virtual Path – виртуальный путь VPI Virtual Path Identifier – идентификатор виртуального пути. 2. Основы MPLS В этом разделе, вводятся некоторые базовые концепции MPLS, и описывается используемый общий подход. 2.1. Метки Метка является коротким идентификатором фиксированной длины, который используется для идентификации FEC. Метка, которая вложена в определенный пакет, представляет класс переадресации FEC (Forwarding Equivalence Class), к которому данный пакет приписан. Обобщая, можно сказать, что пакет приписан FEC, базирующемуся частично или целиком на его адресе места назначения сетевого уровня. Однако кодировка метки никогда не совпадает c этим адресом. Если Ru и Rd являются LSR, они могут договориться о том, что когда Ru передает пакет Rd, Ru снабжает пакет меткой с кодом L, если и только если пакет принадлежит определенному классу FEC F. То есть, они могут согласовать соответствие между меткой L и F для пакетов, транспортируемых от Ru к Rd. В результате такого соглашения L становится выходной меткой Ru, представляющей FEC F, а L становится входной меткой Rd. Заметим, что L не обязательно представляет FEC F для любого пакета, посланного не Ru и адресованного не Rd. L имеет произвольное значение, чья связь F с Ru и Rd является локальной. Когда говорится, что пакеты посланы из Ru в Rd, это не означает, что пакеты сформированы в Ru или, что местом назначения является Rd. Скорее, мы подразумеваем, что пересылаемые пакеты поступают в один или оба LSR. Иногда может оказаться трудно или даже невозможно для Rd сообщить о прибывающих пакетах с меткой L, помещенной в пакет Ru, а не каким-то другим LSR. (Это обычно происходит, когда Ru и Rd не являются соседями). В таких случаях Rd должен убедиться, что имеет место соответствие межу меткой и FEC. То есть, Rd не должен соглашаться на ассоциацию L и FEC F1, в то время как с другим LSR Ru2 согласовано соответствие L с другим FEC F2, если только Rd не может при получении пакетов с меткой L всегда оповещать, вложена ли в пакет метка Ru1 или Ru2. Гарантия однозначной интерпретации меток находится в зоне ответственности LSR. 2.2. Вышестоящие и нижестоящие LSR Предположим, что Ru и Rd договорились о соответствии метки L и FEC F, для пакетов, посланных из Ru в Rd. Тогда с учетом этого соответствия, Ru является "вышестоящим LSR", а Rd является "нижестоящим LSR". Узел является вышестоящим, а другой нижестоящим с учетом того, что в данной ассоциации (метки и класса) метка представляет определенный FEC для пакетов, транспортируемых от вышестоящего узла к нижестоящему. Это, вообще говоря, не означает, что пакеты в этом FEC будут действительно маршрутизированы от вышестоящего узла нижестоящему. 2.3. Помеченные пакеты Помеченным пакетом является пакет, в заголовке которого имеется метка. В некоторых случаях, метка размещается в заголовке инкапсуляции, который введен специально для этой цели. В других случаях, метка может помещаться в структуре, описывающий информационный канал или в существующем заголовке сетевого уровня, если имеется поле, предназначенное для этой цели. Метод кодирования метки должен быть согласован субъектом, ее формирующим и субъектом адресатом. 2.4. Присвоение меток и рассылка В архитектуре MPLS, решение об установлении соответствия конкретной метки L и класса FEC F принимается LSR, который является нижестоящим по отношению к этой ассоциации. Нижестоящий LSR информирует вышестоящий LSR об установлении этой ассоциации. Таким образом, метки присваиваются нижестоящим объектом и рассылаются "снизу-вверх". Если LSR сконструирован так, чтобы анализировать метки и проверять их принадлежность определенному числовому диапазону, тогда нужно лишь позаботиться, чтобы значения меток действительно лежали в этом диапазоне. 2.5. Атрибуты ассоциации меток (Label Binding) Конкретная ассоциация метки L и класса FEC F, анонсируемая Rd для Ru, может иметь соответствующие атрибуты. Если Ru работает как нижестоящий LSR, и анонсирует ассоциацию метки и класса FEC F, тогда при определенных обстоятельствах, может оказаться нужно разослать соответствующий атрибут, полученный от Rd. 2.6. Протоколы рассылки меток Протокол рассылки меток представляет собой набор процедур, с помощью которых один LSR информирует другие об ассоциациях метка/FEC, которые он сформировал. Два LSR, которые используют протокол рассылки меток для обмена данными об ассоциациях метка/FEC, называются "партнерами рассылки меток". Если два LSR являются партнерами по рассылки меток, мы будем говорить о смежности рассылки меток между ними. Протокол рассылки меток включает в себя также любые согласования, при которых партнеры изучают MPLS возможности друг друга. Архитектура не предполагает, что должен существовать только один протокол рассылки меток. В действительности, стандартизовано несколько протоколов рассылки меток. Существующие протоколы расширены так, чтобы рассылка меток можно было совместить друг с другом (смотри, например, [MPLS-BGP], [MPLS-RSVP-TUNNELS]). Определены новые протоколы специально для целей рассылки меток (смотри, например, [MPLS-LDP], [MPLS-CR-LDP]). В данном документе, мы пытаемся использовать акроним "LDP" для ссылок на протокол, определенный в [MPLS-DP]. 2.7. Unsolicited Downstream против Downstream-on-Demand Архитектура MPLS позволяет LSR непосредственно посылать запросы узлу следующего шага относительно конкретного FEC, и ассоциации метка-FEC. Это называется рассылкой меток по схеме "запрос нижележащего" (downstream-on-demand). Архитектура MPLS позволяет также LSR посылать ассоциации другим LSR, которые напрямую эти данные не запрашивали. Такой обмен называется рассылкой меток нижележащим без запроса (unsolicited downstream). Ожидается, что некоторые реализации MPLS будут осуществлять рассылку меток только в режиме downstream-on-demand, другие – только в режиме unsolicited downstream, а некоторые - в обоих режимах. Какой из режимов будет реализован, зависит от характеристик интерфейсов, которые поддерживает конкретная реализация. Однако обе эти схемы рассылки меток могут использоваться в некоторых сетях одновременно. В любом конкретном случае вышестоящий и нижестоящий LSR должны согласовать, какая из схем рассылки будет применена. 2.8. Режим удержания меток (Retention Mode) LSR Ru может получить (или уже получил) от LSR Rd ассоциацию метка-FEC, даже несмотря на то, что Rd не является следующим шагом для Ru (для данного FEC). Ru теперь имеет выбор следует ли ему отслеживать такие ассоциации или отбрасывать их. Если Ru отслеживает такие ассоциации, тогда он может немедленно начать использование этой ассоциации, если Rd в конце концов, становится его следующим шагом для заданного FEC. Если Ru игнорирует такие ассоциации, тогда если Rd позднее станет следующим шагом, ассоциация должна быть воспринята снова. Если LSR поддерживает "свободный режим удержания меток" (Liberal label retention mode), он поддерживает ассоциации между меткой и FEC, который получен от LSR, не являющегося следующим шагом для этого FEC. Если LSR поддерживает "консервативный режим удержания меток" (Conservative label retention mode), он отбрасывает такие ассоциации. Свободный режим удержания меток допускает быструю адаптацию к маршрутным изменениям, а консервативный режим сохранения меток требует от LSR поддержки много меньшего числа меток. 2.9. Стек меток До сих пор мы обсуждали проблему, как если бы помеченные пакеты несли в себе только одну метку. Как мы увидим, полезно иметь более обобщенную модель, в которой помеченные пакеты несут в себе несколько меток, уложенных в порядке “последний_вошел-первым_вышел”. Мы будем называть это стеком меток. Хотя, как это мы увидим, MPLS поддерживает иерархию, обработка помеченных пакетов совершенно не зависит от уровня иерархии. Обработка всегда базируется на верхней метке, без учета того, что некоторое число других меток лежало поверх данной в прошлом, или того, что какое-то их число лежит под ней сейчас. Непомеченный пакет может рассматриваться как пакет, чей стек меток пуст (т.e., глубина стека которого равна 0). Если стек пакетных меток имеет глубину m, мы считаем, что метка на дне стека размещена на уровне 1, метка над ней (если таковая имеется) имеет уровень 2, а метка наверху стека имеет уровень m. 2.10. Запись Next Hop Label Forwarding (NHLFE) "Next Hop Label Forwarding Entry" (NHLFE) используется при переадресации помеченных пакетов. Здесь содержится следующая информация: 1. Следующий шаг пакета 2. Операция, которая должна быть произведена над стеком меток. Это одна из следующих операций: a) заместить метку на верху стека специфицированной новой меткой b) извлечь метку из стека c) заместить метку на верху стека специфицированной новой меткой, и затем ввести в стек одну или более специфицированных меток. Она может содержать: d) инкапсуляцию канальных данных, которая будет использована при пересылке пакета e) метод кодирования стека меток, при пересылке пакета f) другую информацию, необходимую для того чтобы корректно отобразить пакет. Заметим, что для данного LSR, следующим шагом пакета может стать сам LSR. В этом случае, LSR должен будет извлечь метку из стека, и затем переадресовать полученный пакет самому себе. Затем он примет следующее решение переадресации, базирующееся на полученном состоянии стека меток. Это подразумевает, что в некоторых случаях LSR будет должен работать с IP-заголовком, для того чтобы переадресовать пакет. Если следующим шагом пакета является текущий LSR, тогда операцией над стеком меток должна быть "pop". 2.11. Установление соответствия для входных меток ILM (Incoming Label Map) "Incoming Label Map" (ILM) устанавливает соответствие каждой входящей метки с набором NHLFE. Эта операция используется, когда переадресуемые пакеты являются помеченными. Если ILM связывает определенную метку с набором NHLFE, который содержит более одного элемента, только один элемент должен быть выбран из набора, прежде чем пакет будет переадресован. Процедуры выбора элемента из набора находятся за пределами рассмотрения данного документа. Используя технику установления соответствия ILM, можно работать с набором, содержащим более одного NHLFE, что может оказаться желательно, например, при необходимости сбалансировать трафик между несколькими путями, имеющими равные метрики. 2.12. Установление соответствия между FEC и NHLFE (FTN) Методика "FEC-to-NHLFE" (FTN) устанавливает соответствие между каждым FEC и набором NHLFE. Она используется при переадресации непомеченных пакетов, при необходимости их пометки до переадресации. Если FTN устанавливает соответствие между конкретной меткой и набором NHLFE, который содержит более одного элемента, только один из них должен быть выбран, прежде чем пакет будет переадресован. Процедуры выбора элемента из набора находятся за пределами рассмотрения данного документа. 2.13. Замена меток Замена меток (Label swapping) представляет собой использование следующих процедур для переадресации пакетов. Для того чтобы переадресовать помеченный пакет, LSR рассматривает метку на верху стека. Он использует ILM для установления соответствия этой метки набору NHLFE. Используя информацию из NHLFE, он определяет, куда переадресовать пакет, и выполняет некоторую операцию над стеком меток пакета, затем записывает новую метку в стек пакета и переадресует его. Для того чтобы переадресовать непомеченный пакет, LSR анализирует заголовок сетевого уровня, чтобы определить FEC пакета. Затем он использует FTN, для того чтобы установить соответствие с NHLFE. Используя информацию NHLFE, он определяет, куда переадресовать пакет, и выполняет некоторую операцию над стеком меток пакета. (Извлечение метки из стека в этом случае будет нелегальным). Важно заметить, что когда используется коммутация меток, следующий шаг всегда берется из NHLFE. Это отличается в некоторых случаях от выбора следующего шага, когда не используется MPLS. 2.14. Область действия и уникальность меток Данный LSR Rd может связать метку L1 с FEC F, и переправить эту ассоциацию партнеру Ru1. Rd может также связать метку L2 с FEC F, и переправить эту ассоциацию партнеру Ru2. Является ли L1 == L2 не определяется архитектурой, это вопрос исключительно локальный. Данный LSR Rd может связать метку L с FEC F1, и переправить эту ассоциацию партнеру Ru1. Rd может также связать метку L с FEC F2, и переправить эту ассоциацию партнеру Ru2. Если и только если Rd может сообщить, когда он получает пакет с меткой на верху стека равной L, занесена ли она в стек RU1 или RU2, архитектура не требует равенства F1 == F2. В таких случаях, мы можем сказать, что Rd использует другое пространство для меток, которые он пересылает Ru1, чем для меток, посылаемых Ru2. Вообще, Rd может лишь сообщить, Ru1 или Ru2 положил данную метку со значением L на верх стека, если выполнены следующие условия: - Ru1 и Ru2 являются партнерами, обменивающимися метками, и которым Rd пересылает значение метки L, и - Ru1 и Ru2 оба соединены с Rd непосредственно через интерфейс точка-точка. Когда эти условия выполнены, LSR может использовать метки, имеющие область действия "per interface", т.e., которые являются уникальными для каждого интерфейса. Можно сказать, что LSR использует "пространство меток интерфейса". Когда эти условия не выполнены, метки должны быть уникальными для LSR, который их присвоил, и мы можем сказать, что LSR использует "пространство меток платформы". Если конкретный LSR Rd связан с некоторым LSR Ru через два интерфейса по схеме точка-точка, тогда Rd может пересылать Ru ассоциацию метки L с FEC F1, также как ассоциацию метки L с FEC F2, F1 != F2, если и только если каждая ассоциация корректна для пакетов, которые Ru посылает Rd через один из интерфейсов. Во всех других случаях, Rd не должен посылать ассоциации Ru, сопрягающие одну и ту же метку с двумя разными FEC. Этот запрет сохраняется, даже если ассоциации относятся к различным уровням иерархии. В MPLS, не существует понятия разных пространств меток для различных уровней иерархии, когда метка интерпретируется, уровень метки значения не имеет. Возникает вопрос, может ли LSR использовать мультиплатформные пространства меток, или использовать много пространств меток интерфейса для одного и того же интерфейсного устройства. Это не запрещено архитектурой. Однако в таких случаях LSR должен иметь некоторые средства, не специфицированные архитектурой, определения для заданной входной метки, какому пространству принадлежит данная метка. Например, [MPLS-SHIM] специфицирует, что различные пространства меток используются для уникастных и мультикастных пакетов, а для разделения этих пространств используется код канального уровня. 2.15. Маршрут с коммутацией меток (LSP), входной и выходной LSP "Маршрут с коммутацией меток (LSP) уровня m" для определенного пакета P является последовательностью маршрутизаторов <R1, ..., Rn> со следующими свойствами: 1. R1, "вход LSP", является LSR, который вносит метку в стек пакета P, в результате формируется стек глубиной m; 2. Для всех i, 1<i<n, P (когда он приходит в LSR Ri) имеет стек меток глубиной m; 3. Никогда за время передачи P от R1 к R[n-1] глубина стека не будет меньше m; 4. Для всех i, 1<i<n: Ri передает P в R[i+1] посредством MPLS, т.e., путем использования метки в верхней позиции стека (метка уровня m) в качестве индекса в ILM; 5. Для всех i, 1<i<n: если система S получает и переадресует P, после того как P передан Ri, но до того как P получен R[i+1] (например, Ri и R[i+1] могут быть соединены через коммутируемую субсеть, и S может быть одним из переключателей информационного канала), далее решение переадресации S не базируется на метке уровня m, или на основе заголовка сетевого уровня. Это может быть, так как: a) решение не основано на содержимом стека или заголовка сетевого уровня; b) решение основано на содержимом стека, куда положены другие метки (т.e., на метке уровня m+k, где k>0). Другими словами, мы можем описать уровень m LSP для пакета P, как последовательность маршрутизаторов: 1. Которая начинается с LSR ("вход LSP "), заносящий метку на уровень m. 2. Все маршрутизаторы, чьи промежуточные LSR, принимают решение о переадресации согласно метке на уровне m. 3. Которая завершается (в "выходном LSP"), когда решение переадресации делается на основе коммутации меток на уровне m-k, где k>0, или когда решение переадресации делается "традиционно", посредством не-MPLS процедур. Следствием (или, пожалуй, предпосылкой) этого является то, что, когда бы LSR ни занес метку в стек уже помеченного пакета, он должен быть уверен, что новая метка соответствует FEC, чьим выходом LSP служит LSR, который сформировал метку, которая сейчас является второй в стеке. Мы будем называть последовательность LSR "LSP для определенного FEC F", если он является LSP уровня m для заданного пакета P, когда уровень метки P соответствует FEC F. Рассмотрим набор узлов, которые могут быть входными LSP-узлами для FEC F. Тогда существует LSP для FEC F, который начинается с каждого из этих узлов. Если некоторое число этих LSP имеет идентичный выходной LSP, тогда можно рассматривать набор таких LSP как дерево, чьим корнем является выходной LSP. (Так как данные переносятся вдоль этого дерева по направлению к корню, эта структура может быть названа деревом мультиточка-точка). Мы можем, таким образом, говорить о "дереве LSP" для определенного FEC F. 2.16. Извлечение предпоследнего шага Заметим, что согласно определениям из раздела 2.15, если <R1, ..., Rn> является LSP уровня m для пакета P, P может быть передан от R[n-1] к Rn с глубиной стека меток m-1. То есть, может быть выполнена операция pop для стека меток в предпоследнем LSR LSP, а не в выходном LSP. С архитектурной точки зрения это вполне приемлемо. Целью метки уровня m является доставка пакета в Rn. Раз R[n-1] решил послать пакет Rn, метка не имеет более значения и не должна далее транспортироваться. Имеется также практическое преимущество извлечения данных о предпоследнем шаге. Если так не сделать, тогда при получении пакета выходным LSP, он сначала просматривает верхнюю метку из стека, и определяет, что это действительно выходной LSP. Затем он должен извлечь из стека метку, и проверить, что осталось в стеке пакета. Если в стеке имеется другая метка, выходное устройство анализирует метку и осуществляет пересылку пакета на основе этого анализа. (В этом случае, выходное устройство для пакетов уровня m LSP является промежуточным узлом для его уровня m-1 LSP). Если в стеке нет других меток, тогда пакет переадресуется согласно его адресу места назначения сетевого уровня. Заметим, что это потребует от выходного устройства двух просмотров, либо просмотра двух меток, либо просмотра метки с последующим анализом адреса. Если, с другой стороны, используется извлечение предпоследнего шага из стека, тогда предпоследний узел просматривает метку и определяет: - это предпоследний шаг, и - какой узел является следующим. Предпоследний узел далее извлекает метку из стека и переадресует пакет на основе информации, полученной при просмотре метки, которая была до этого на верху стека. Когда выходной LSP получает пакет, метка, которая находится на верху стека, будет меткой, необходимой для просмотра, чтобы осуществить его собственное решение о переадресации. Или, если пакет нес в себе только одну метку, выход LSP просто просмотрит заголовок пакета сетевого уровня, который является как раз тем, что ему нужно просмотреть, чтобы принять решение о переадресации. Эта методика позволяет выходному шлюзу выполнить один просмотр, а также требует одного просмотра предпоследнему узлу. Создание в программе коммутации меток "fastpath" может существенно помочь, если известно, что требуется лишь один просмотр метки: ·
код может быть упрощен, если можно предположить, что ожидается только один просмотр В действительности, когда предпоследний шаг извлечен из стека, конец LSP не должен быть обязательно LSR. Однако некоторые аппаратные переключатели не могут извлекать метки из стека, поэтому это не может быть универсальным требованием. Могут также встретиться ситуации, в которых извлечение из стека предпоследнего шага нежелательно. Следовательно, предпоследний узел извлекает метку из стека, только если это запрашивается выходным узлом, ИЛИ если следующий узел в LSP не поддерживает MPLS. LSR, который способен работать с метками, должен извлекать из стека метку предпоследнего шага, когда это затребовано его нижестоящим партнером. Начальное согласование протокола рассылки меток должно позволять каждому LSR определить, способны ли соседние LSR извлекать метки из стека. LSR НЕ ДОЛЖЕН запрашивать своего партнера по обмену метками извлекать метку из стека, если только он не способен делать это. Возможен запрос, может ли выходной узел корректно интерпретировать верхнюю метку в стеке приходящего пакета, если использована операция pop предпоследнего шага. Поскольку правила уникальности и области действия из раздела 2.14 выполняются, всегда возможно правильно интерпретировать верхнюю метку стека приходящего пакета. 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-префикс таблицы переадресации" или "одна метка на выходной узел"). 2.21. Выбор маршрута Выбор маршрута сопряжен с методом, используемым при выборе LSP для определенного FEC. Предлагаемая архитектура протокола MPLS поддерживает две опции выбора маршрута: (1) маршрутизация шаг-за-шагом и (2) явная маршрутизация. Маршрутизация шаг-за-шагом позволяет каждому узлу независимо выбрать следующий шаг для каждого FEC. Это обычный режим существующих сегодня IP-сетей. "маршрутизируемый шаг-за-шагом LSP" является LSP, чей маршрут выбирается по схеме шаг-за-шагом. В LSP при явной маршрутизации, каждый LSR не выбирает следующий шаг независимо; скорее один LSR, обычно вход LSP или выход LSP, специфицирует несколько (или все) LSR в LSP. Если один LSR специфицирует весь LSP, LSP является явно маршрутизированным. Если один LSR специфицирует только некоторые LSP, LSP является "неточно" маршрутизированным. Последовательность LSR, за которой следует явно маршрутизированные LSP, могут быть выбраны при конфигурации, или могут быть выбраны динамически одним узлом (например, выходной узел может использовать топологическую информацию, полученную из базы данных состояния канала, для того чтобы вычислить весь путь для дерева с корнем в выходном узле). Явная маршрутизация может быть полезной для ряда целей, таких как политика маршрутизации или управление трафиком (TE). В MPLS, явный маршрут должен быть специфицирован в момент формирования метки, но явный маршрут не должен быть специфицирован для каждого IP-пакета. Это делает явную маршрутизацию MPLS более эффективной, чем альтернативная IP-маршрутизация отправителя. Процедуры формирования явных маршрутов, точных или неточных, находятся за пределами данного документа. 2.22. Отсутствие выходной метки Когда помеченный пакет транспортируется вдоль LSP, может так случится, что он достигнет LSR, в котором ILM не устанавливает соответствия между меткой входящего пакета и NHLFE, даже при условии, что сам пакет корректен. Это может случиться из-за переходных обстоятельств или по причине ошибки в LSR, который должен быть следующим шагом пакета. Может показаться привлекательным в таких случаях, ликвидировать стек меток и попытаться переадресовать пакеты далее методами традиционной маршрутизации, базирующимися на содержимом заголовка сетевого уровня. Однако вообще это небезопасная процедура: - Если пакет попадает в LSP маршрутизируемый явно, это может привести к образованию петель. - Заголовок пакета сетевого уровня не может содержать достаточно информации, чтобы позволить данному конкретному LSR переадресовать пакет корректно. Если нельзя определить, что ни одна из этих ситуаций не реализована, единственно безопасной процедурой может стать отбрасывания пакета. 2.23. Время жизни (TTL) При традиционной IP переадресации, каждый пакет имеет в заголовке значение поля "Time To Live" (TTL). Когда бы пакет ни проходил через маршрутизатор, его TTL уменьшается на 1. Если TTL достигает 0, прежде чем пакет достигнет места назначения, он отбрасывается. Это обеспечивает некоторый уровень защиты против петлевых маршрутов, которые могут существовать из-за ошибок конфигурации, или по причине ошибки или медленной сходимости алгоритма маршрутизации. TTL иногда используется для других функций, таких как определение зоны действия мультикастинга, и поддержка команды "traceroute". Это означает, что имеется две проблемы, связанные с TTL, которые MPLS должен решить: (i) TTL как способ подавления зацикливания; (ii) TTL как метод реализации других функций, таких как ограничение области распространения пакета. Когда пакет движется по LSP, он должен появляться с тем же значением TTL, которое он бы имел, если бы он проходил через ту же последовательность маршрутизаторов, без коммутации меток. Если пакет проходит через иерархию LSP, полное число пройденных шагов-LSR должно быть отражено в его значении TTL. Способ, которым обрабатывается поле TTL, может варьироваться в зависимости от того, размещены ли значения меток MPLS в прослойке между заголовками [MPLS-SHIM], или метки MPLS транспортируются в заголовке L2, таком как заголовок ATM [MPLS-ATM] или заголовок frame relay [MPLS-FRMRLY]. Если значения меток вставлены в "прослойку", которая размещается между канальным и сетевым заголовками, тогда эта прослойка должна иметь поле TTL, которое должно заполняться также, как аналогичное поле заголовка сетевого уровня, декрементироваться при каждом шаге LSR, и копироваться в TTL-поле заголовка сетевого уровня, когда пакет выходит из его LSP. Если значения меток записаны в заголовке канального уровня (например, поле VPI/VCI в заголовке AAL5 ATM), а помеченные пакеты переадресуются переключателем уровня L2 (например, ATM-переключателем), а канальный уровень сам не имеет поля TTL, тогда будет невозможно декрементировать TTL при каждом шаге LSR. Сегмент LSP, который состоит из последовательности LSR, которые не способны декрементировать TTL пакетов, будет называться сегментом "non-TTL LSP". Когда пакет выходит из сегмента non-TTL LSP, он должен, однако получить TTL, отвечающее числу шагов LSR, которые он проходит. В уникастном случае, это может быть достигнуто путем транспортировки длины LSP входным узлам, позволяя входным устройствам декрементировать значение TTL, прежде чем переадресовывать пакеты в non-TTL LSP сегмент. Иногда это может быть определено на входе сегмента non-TTL LSP так, что соответствующее значение TTL пакета достигнет нуля, прежде чем пакет дойдет выхода сегмента non-TTL LSP. В этом случае, LSR на входе non-TTL LSP сегмента коммутировать пакеты по меткам. Это означает, что должны быть разработаны специальные процедуры для поддержки функциональности traceroute, например, пакеты traceroute могут переадресовываться по стандартной схеме шаг-за-шагом. 2.24. Контроль петель В non-TTL LSP сегменте, по определению, TTL не может использоваться для предотвращения петель маршрута. Важность контроля циклических путей зависит от конкретного оборудования, используемого для реализации LSR-функций в пределах non-TTL LSP сегмента. Предположим, например, что для коммутационных целей в MPLS используются ATM-переключатели, с метками, транспортируемыми в поле VPI/VCI. Так как ATM коммутаторы не могут декрементировать TTL, здесь нет защиты против появления циклических маршрутов. Если оборудование ATM способно обеспечить хороший доступ к буферному пулу для входящих ячеек, имеющих разные значения полей VPI/VCI, петли не могут иметь негативного эффекта на остальной трафик. Если оборудование ATM не может обеспечить хороший доступ к буферам, тогда переходные петли могут вызвать серьезную деградацию эксплуатационных характеристик LSR. Даже если может быть обеспечен хороший доступ к буферу, целесообразно иметь некоторые средства детектирования петель, которые имеют длину больше определенной. Кроме того, даже когда TTL и/или справедливая организация очередей в виртуальных каналах предоставляет возможности для сохранения петель, может быть желательно, где возможно избегать установления LSP с петлями. Все LSR, которые могут быть связаны с сегментами non-TTL LSP будут должны поддерживать общую методику детектирования петель; однако, использование детектирования петель является опционным. Методика детектирования петель специфицирована в [MPLS-ATM] и [MPLS-LDP]. 2.25. Кодирование меток Для того чтобы передавать стек меток вместе с пакетом, необходимо определить его конкретную структуру. Архитектура поддерживает несколько различных структур. Выбор структуры стека зависит от конкретного типа оборудования, используемого для переадресации пакетов. 2.25.1. MPLS-специфичное оборудование и/или программное обеспечение Если для переадресации помеченных пакетов используется MPLS-специфичное оборудование и/или программы, наиболее очевидным способом представления стека меток является определение нового протокола, который будет использоваться в пределах прослойки между заголовками канального и сетевого уровней. Эта прокладка могла бы реально быть инкапсуляцией пакетов сетевого уровня. Она является протокольно независимой, такой, чтобы использоваться для инкапсуляции любого сетевого уровня. Следовательно, мы будем называть это как "общая MPLS-инкапсуляция". MPLS-инкапсуляция будет в свою очередь инкапсулирована с привлечением протокола канального уровня. Общая MPLS-инкапсуляция специфицирована в [MPLS-SHIM]. 2.25.2. ATM-коммутаторы в качестве LSR Процедуры переадресации MPLS подобны тем, что используются в ATM-коммутаторах. ATM-коммутаторы используют входной порт и значение поля VPI/VCI входящего пакета в качестве индекса в таблице коммутации (cross-connect), из которой они получают номер выходного порта и выходного значения VPI/VCI. Следовательно, если одна или более меток могут быть занесены непосредственно в поля заголовков, которые доступны коммутаторам, тогда коммутаторы после модификации программ смогут быть использованы в качестве LSR. Мы будем называть такие устройства "ATM-LSR". Имеется три способа представления меток в заголовках ячеек ATM (предпочтительно использовать AAL5): 1. SVC кодирование Используется поле VPI/VCI для записи метки, размещенной на верху стека. Эта методика может использоваться в любой сети. Посредством этой методики LSP реализуется как ATM SVC, а протокол рассылки меток становится сигнальным протоколом ATM. ATM-LSR не может выполнять команды "push" или "pop" для стека меток. 2. SVP кодирование Используется поле VPI для записи метки, размещенной на верху стека, а поле VCI для записи второй метки стека, если такая существует. Эта методика имеет некоторые преимущества по отношению к предыдущей, здесь возможно переключение виртуальных каналов с помощью ATM "VP-switching". То есть, LSP реализуются как ATM SVP. Однако эта методика не может использоваться всегда. Если сеть включает виртуальный маршрут ATM через ATM-сеть, не поддерживающую MPLS, тогда поле VPI необязательно доступно для использования в MPLS. Когда используется этот метод представления, ATM-LSR на выходе виртуального канала VP эффективно реализует операцию "pop". 3. Многоточечное кодирование SVP Для размещения метки на вершине стека используется поле VPI, а для размещения второй метки стека, если таковая имеется, используется часть поля VCI, остальная часть поля VCI служит для идентификации входного LSP. Если применяется эта технология, традиционные возможности ATM VP-коммутации могут использоваться для построения виртуальных маршрутов мультиточка-точка. Ячейки от разных пакетов будут нести тогда разные значения VCI. Как это будет показано в разделе 2.26, это позволяет нам осуществлять объединение меток, не получая проблем перекрытия ячеек, для ATM-коммутаторов, реализующих виртуальные маршруты мультиточка-точка, но которые не имеют возможностей объединения VC. Эта методика зависит от наличия возможности присвоения 16-битовых значений VCI каждому ATM-коммутатору, так что ни одно значение VCI не будет соответствовать двум разным коммутаторам. Если имеется больше меток в стеке, чем места в заголовке ATM, тогда ATM представление должно комбинироваться с общей инкапсуляцией. 2.25.3. Совместимость методов кодирования Если <R1, R2, R3> является сегментом LSP, возможно, что R1 будет использовать одно представление стека меток при передачи пакета P в R2, но R2 будет использовать другое представление при передаче пакета P в R3. Вообще, архитектура MPLS поддерживает LSP с разным представлением стека меток на разных шагах маршрута. Следовательно, когда мы обсуждаем процедуры обработки помеченных пакетов, мы делаем это в терминологии взаимодействия со стеком меток. Когда приходит помеченный пакет, LSR должен декодировать его для определения текущего значения метки в стеке, затем должен преобразовать стек, чтобы определить новое значение метки перед отправкой пакета в следующий узел маршрута. К сожалению, ATM-коммутаторы не имеют возможности осуществлять преобразование из одного представления стека меток в другое. Архитектура MPLS, следовательно, требует чтобы, когда два ATM-коммутатора оказываются последовательными LSR на уровне m LSP для определенных пакетов, эти два ATM-коммутатора используют одно и то же представление стека меток. Естественно будут существовать MPLS сети, которые содержат комбинацию ATM-коммутаторов, работающих в качестве LSR, и других LSR, использующих MPLS заголовок-прокладку. В таких сетях могут быть некоторые LSR, имеющие ATM-интерфейсы а также интерфейсы "MPLS Shim" (прослойки). Это лишь один пример LSR с различным представлением стека меток. Такие LSR могут осуществлять подмену структур стека меток из представления ATM на входном интерфейсе в MPLS формат стека на выходном. 2.26. Объединение меток Предположим, что LSR связал несколько входящих меток с конкретным FEC. При переадресации пакетов в этом FEC, хотелось бы иметь одну выходную метку, которая используется всеми такими пакетами. Тот факт, что два разных пакета класса FEC приходят с разными входными метками является нерелевантным. Хотелось бы переадресовывать их с одной и той же выходной меткой. Реализация этого называется "объединением меток". Будем говорить, что LSR способен объединять метки, если он может получать два пакета от разных входных интерфейсов, и/или с разными метками, а посылать оба пакета с одной и той же выходной меткой. Раз пакеты переданы, информация о том, что они пришли от разных интерфейсов и/или с разными входными метками теряется. Будем считать, что LSR не способен объединять метки, если для любых двух пакетов, которые приходят из разных интерфейсов, или с разными метками, пакеты должны быть либо переданы через разные интерфейсы, или должны иметь разные выходные метки. ATM-LSR, использующие SVC или SVP представления, не могут реализовывать объединение меток. Если некоторый LSR не может выполнить объединение меток, тогда, если два пакета в одном и том же FEC приходят с разными входными метками, они должны быть переадресованы с разными выходными метками. При объединении меток, число выходных меток на один FEC должно быть равно 1. Без объединения меток, число выходных меток на один FEC может равняться числу узлов в сети. При объединении меток число входящих меток на FEC, которое необходимо конкретному LSR, никогда не превосходит числа смежных дистрибьюторов. В отсутствии объединения меток, число входящих меток на один FEC, которое необходимо конкретному LSR, достигает числа вышестоящих узлов, которые переадресуют трафик FEC данному LSR. В действительности, для LSR трудно даже определить, сколько входящих меток он должен поддерживать для конкретного FEC. Архитектура MPLS приспосабливает как объединяющие, так не объединяющие LSR, но допускает также возможность того, что имеются LSR, не поддерживающие коммутацию меток. 2.26.1. Необъединяющие LSR Процедура переадресации MPLS очень схожа с используемой в ATM и Frame Relay. То есть, приходит блок данных, ищется метка в коммутационной таблице (VPI/VCI или DLCI), на основе результата поиска выбирается выходной порт, а значение метки переписывается. В действительности, можно использовать такие технологии для переадресации MPLS. Протокол рассылки меток может быть использован в качестве сигнального протокола для формирования коммутационных таблиц. К сожалению, эти технологии необязательно поддерживают возможности объединения меток. В ATM, если попытаться осуществить объединение меток, в результате можно получить перекрытие ячеек от различных пакетов. Если ячейки от разных пакетов оказываются перекрытыми, невозможно осуществить сборку пакетов. Некоторые коммутаторы Frame Relay используют коммутацию ячеек на своих внутренних шинах (backplane). Эти коммутаторы могут также быть неспособными поддерживать объединение меток, по той же причине – ячейки разных пакетов могут перекрываться, и сборка исходных пакетов станет невозможной. Мы предлагаем поддержать два решения этой проблемы. Первое, MPLS будет поддерживать процедуры, которые позволяют определенным ATM-коммутаторам функционировать как LSR, способные объединять метки. Так как MPLS поддерживает объединяющие и необъединяющие LSR, MPLS содержит также процедуры, которые гарантируют корректное взаимодействие такого оборудования и программ. 2.26.2. Метки для объединяющих и необъединяющих LSR Вышестоящий LSR, который поддерживает объединение меток, должен посылать только одну метку на FEC. Вышестоящий сосед, который не поддерживает объединение меток, должен посылать несколько меток на один FEC. Однако не существует метода узнать заранее, сколько нужно меток. Это будет зависеть оттого, сколько имеется вышестоящих LSR для оговоренного FEC. В архитектуре MPLS, если определенный вышестоящий сосед не поддерживает объединение меток, ему не посылаются какие-либо метки для заданного FEC, если только он напрямую не запрашивает метку для данного FEC. Вышестоящий сосед может сделать несколько таких запросов, и получать каждый раз новую метку. Когда нижестоящий сосед получает такой запрос “сверху”, а сам он не поддерживает объединения меток, тогда он должен в свою очередь запросить у своего нижестоящего соседа новую метку для заданного FEC. Возможно, что существуют какие-то узлы, которые поддерживают объединение меток, но могут объединить лишь ограниченное число входящих меток в одну исходящую. Предположим, например, что из-за некоторых аппаратных ограничений узел может объединить четыре входящие метки в одну исходящую. Предположим, что этот конкретный узел получил шесть меток, пришедших для данного FEC. В этом случае этот узел может объединить их в две исходящие метки. 2.26.3. Объединение потоков в ATM Существует несколько методов исключения проблемы перекрытия ячеек в ATM, таким образом, позволяющих ATM-коммутатором поддерживать объединение потоков данных: 1. Объединение VP, использующее мультиточечное представление SVP Когда используется объединение VP, несколько виртуальных путей объединяются в один путь, но пакеты от разных отправителей отличаются разными VCI в пределах данного VP. 2. Объединение VC Когда используется объединение VC, коммутаторы должны буферизовать ячейки от пакетов до тех пор, пока не будет принят весь пакет (это может быть определено путем просмотра индикатора конца кадра для AAL5). Объединение VP имеет преимущество в том, что оно совместимо с подавляющим числом реализаций ATM-коммутаторов. Это делает более вероятным то, что объединение VP может использоваться в существующих сетях. В отличие от объединения VC, объединение VP не приводит к каким-либо задержкам в точках объединения, а также не накладывает никаких требований на буферы. Однако это имеет недостаток, так как требует координации пространства VCI в пределах VP. Существует несколько способов реализации этого. Этот компромисс между совместимостью с существующим оборудованием, сложностью протокола и масштабируемостью предполагает, что желательна поддержка протоколом MPLS объединения как VP, так и VC. Для того чтобы реализовать это каждый ATM-коммутатор, участвующий в MPLS, должен знать, могут ли ближайшие ATM соседи осуществлять объединение VP или VC. 2.26.3.2. Взаимодействие: объединение VC, объединение VP, и отсутствие объединения Взаимодействие различных форм объединения в ATM наиболее просто описать на примере взаимодействия систем с объединением VC и без. В случае, когда соединены узлы, поддерживающие и не поддерживающие объединение VC, переадресация ячеек базируется во всех вариантах на VC (т.e., на соединении VPI и VCI). Для каждого вышестоящего узла, осуществляющего объединение VC, нужен только один набор VPI/VCI (это сходно с требованиями для одиночной метки в случае работы в среде кадров (frame media)). Если вышестоящий сосед не может осуществлять объединение, тогда он будет требовать одного VPI/VCI на поток для себя, плюс достаточное число VPI/VCI, чтобы осуществить передачу вышестоящему соседу. Необходимое число будет определено путем разрешения вышестоящим узлам посылать запросы дополнительных VPI/VCI от своих нижестоящих соседей (это аналогично методике объединения, используемой для кадров). Аналогично можно поддержать узлы, которые выполняют объединение VP. В этом случае объединяющий VP узел, вместо посылки запроса одного или нескольких VPI/VCI от нижестоящего соседа, может запросить один VP (идентифицируемого посредством VPI), но несколько VCI в пределах VP. Кроме того, предположим, что узел, не поддерживающий объединение ниже расположен по отношению к двум другим узлам, объединяющим VP. Этот узел может нуждаться в запросе одного VPI/VCI (для трафика, исходящего именно из этого узла) плюс два VP (по одному для каждого вышестоящего узла), ассоциированные со специфицированными наборами VCI (в соответствии с запросом от вышестоящего узла). Для того чтобы поддерживать узлы, объединяющие и не объединяющие VP и VC, необходимо разрешить вышестоящим узлам запрашивать комбинацию из нуля или более идентификаторов VC (состоящих из VPI/VCI), плюс нуль или более VP (идентифицируемых VPI), каждый из которых содержит специфицированное число VC (идентифицированное набором VCI, которые работают в пределах VP). Узлы, объединяющие VP, затребовали бы один VP, содержащий VCI для исходящего трафика (если таковой имеется) плюс VCI для каждого VC, запрошенного свыше (вне зависимости оттого, является или нет VC частью, содержащей VP). Узлы, объединяющие VC, затребовали бы только один VPI/VCI (так как они могут объединить весь трафик от вышестоящих узлов в один VC). Узлы, не поддерживающие объединение, передали бы любые запросы, полученные сверху, плюс запрос VPI/VCI для трафика, генерируемого ими самими (если таковой имеется). 2.27. Туннели и иерархия Иногда маршрутизатор Ru предпринимает действия, чтобы доставить определенный пакет другому маршрутизатору Rd, даже если Ru и Rd не являются смежными углами на пути пакета, а Rd не является местом назначения пакета. Это может быть сделано, например, путем инкапсуляции пакета в пакет сетевого уровня, местом назначения которого является Rd. Это создает туннель от Ru к Rd . 2.27.1. Туннель, маршрутизированный шаг-за-шагом Если туннелированный пакет следует маршрутом шаг-за-шагом от Ru к Rd , мы говорим, что это "туннель, маршрутизированный шаг-за-шагом", чье начало находится в Ru и чей конец в Rd. 2.27.2. Туннель, маршрутизированный явно Если туннелированный пакет транспортируется из Ru в Rd по пути, отличному от маршрута шаг-за-шагом, мы говорим, что это "Туннель, маршрутизированный явно" с начальной точкой в Ru и конечной - в Rd. Например, мы можем послать пакет через туннель, маршрутизированный явно путем инкапсуляции его в пакет, маршрутизируемый отправителем. 2.27.3. Туннели LSP Имеется возможность реализовать туннель в виде LSP и использовать коммутацию меток, а не инкапсуляцию сетевого уровня, чтобы заставить пакет идти через туннель. Туннель будет иметь вид LSP <R1, ..., Rn >, где R1 является началом туннеля, а Rn – концом туннеля. Это называется " LSP-туннелем". Набор пакетов, которые посланы через LSP-туннель, представляет собой FEC, а каждый LSR в туннеле должен установить ассоциацию между меткой и FEC (т.e., нужно присвоить туннелю определенную метку). Критерий установления соответствия пакета LSP-туннелю является внутренним вопросом начальной точки туннеля. Чтобы направить пакет в LSP-туннель, передающий конец туннеля вводит метку туннеля в стек и посылает помеченный пакет узлу следующего шага туннеля. Если для конечной точки туннеля не нужно определять, какой пакет получен через туннель, как это обсуждалось выше, стек меток может быть очищен на предпоследнем LSR туннеля. " LSP-туннель, маршрутизированный шаг-за-шагом" представляет собой туннель, который реализован в виде LSP-туннеля, маршрутизированного по схеме шаг-за-шагом. "LSP-туннелем, маршрутизированным явно" является LSP-туннель, который представляет собой также LSP, маршрутизированный явно. 2.27.4. Иерархия: LSP туннели в LSP Рассмотрим LSP <R1, R2, R3, R4>. Предположим, что R1 получил непомеченный пакет P, и заносит метку в его стек, чтобы пакет следовал заданным путем (путь шаг-за-шагом). Предположим далее, что R2 и R3 не являются непосредственно связанными, но они являются виртуальными соседями, так как представляют собой конечные точки LSP-туннеля. Итак, действительная последовательность LSR, через которые проходит P, соответствует <R1, R2, R21, R22, R23, R3, R4>. Когда P транспортируется из R1 в R2, он имеет глубину стека равную 1. R2, коммутирующий метки, определяет, что P должен войти в туннель. R2 сначала замещает входную метку меткой, имеющей смысл для R3. Затем он заносит метку в стек. Эта метка второго уровня имеет значение, понятное R21. Коммутация осуществляется для метки на уровне 2 устройствами R21, R22, R23. R23, который является предпоследним узлом в туннеле R2-R3, удаляет метку из стека до того, как будет выполнена переадресация пакета в R3. Когда R3 видит пакет P, P имеет только метку уровня 1, и покидает туннель. Так как R3 является предпоследним шагом P в LSP, он удаляет метку из стека, а R4 получает P непомеченным. Механизм стека меток допускает любую глубину вложения LSP-туннелей. 2.27.5. Иерархия и партнерство в рассылке меток Предположим, что пакет P транспортируется на уровне 1 LSP <R1, R 2, R3, R4>, и при транспортировке из R2 в R3 движется по LSP уровня 2 <R2, R21, R22, R3>. С точки зрения LSP уровня 2, партером рассылки меток R2 является R21. С точки зрения LSP уровня 1, партерами рассылки меток R2 являются R1 и R3. Могут существовать партеры обмена метками на каждом уровне иерархии. В разделах 3.6 и 3.7 рассмотрены некоторые способы реализации этой иерархии. Заметим, что в этом примере R2 и R21 должны быть IGP-соседями, но R2 и R3 не обязательно ими являются. Когда два LSR являются соседними IGP, мы называем их "локальными партнерам рассылки меток". Когда два LSR могут быть партнерами рассылки меток, но не являются соседними IGP, мы называем их "удаленными партнерами распределения меток". В выше приведенном примере R2 и R21 являются локальными партнерами рассылки меток, а R2 и R3 являются удаленными партнерами рассылки меток. Архитектура MPLS поддерживает два способа рассылки меток на различных уровнях иерархии: явное и неявное партнерство (Peering). Рассылка меток (пиринг) осуществляется путем обмена протокольными сообщениями, которые адресованы партнеру. Возможен обмен метками и с удаленным партнером. Это возможно одним из двух путей: 1. Явное партнерство При явном партнерстве, метки пересылаются партнеру в протокольных сообщениях так же, как это делается при локальном обмене. Эта методика наиболее полезна, когда число удаленных партнеров мало, или число ассоциаций высокого уровня велико, или удаленные партнеры обмена метками размещены в удаленных областях или доменах. Конечно, может быть нужно знать, какие метки следует послать какому партнеру; это рассмотрено в разделе 3.1.2. Примеры использования явного партнерства представлены в разделе 3.2.1 и 3.6. 2. Неявное партнерство При неявном партнерстве, протокольные сообщения рассылки меток, адресованные одному партнеру, не посылаются. Скорее, чтобы разослать метки высокого уровня удаленным партнерам, метка представляется в виде атрибута метки более низкого уровня, а затем производится рассылка метки низкого уровня вместе с этим атрибутом местным партнерам. Локальные партнеры обмена метками рассылают полученные данные дальше. Этот процесс продолжается до тех пор, пока информация не достигнет удаленных партнеров. Эта техника наиболее полезна, когда число удаленных партнеров обмена метками велико. Неявное партнерство не требует сетки партнеров n-квадрат, чтобы разослать метки удаленным партнерам, так как имеется подстраховка за счет локального обмена информацией. Однако неявное партнерство требует, чтобы промежуточные узлы запоминали информацию, в которой они могут быть заинтересованы. Пример использования неявного партнерства можно найти в разделе 3.3. 2.28. Транспортировка протокольных сообщений рассылки меток Протокол рассылки меток используется между узлами в сети MPLS для установления и поддержания привязки меток. Для того чтобы MPLS работал корректно, информация, сопряженная с рассылкой меток, должна рассылаться совершенно надежно, а протокольные сообщения рассылки меток, имеющие отношение к определенному FEC, должны посылаться в определенном порядке. Управление потоком также желательно, так как имеется возможность транспортировки нескольких сообщений с метками в одной дейтограмме. Одним из способов достижения цели является использование TCP в качестве базового транспортного протокола, как это делается в [MPLS-LDP] и [MPLS-BGP]. 2.29. Зачем нужно более одного протокола рассылки меток? Эта архитектура не устанавливает жестких правил для выбора того, какой протокол рассылки меток следует использовать при конкретных обстоятельствах. Однако имеется возможность указать некоторые соображения. 2.29.1. BGP и LDP Во многих сценариях, желательно установить связь между метками и FEC, который может быть сопряжен с маршрутами и адресными префиксами (смотри раздел 3.1). Протокол BGP рассылает маршруты, и, если BGP-отправителю нужно разослать метки своим BGP-партнерам, использование BGP для целей распределения меток (смотри [MPLS-BGP]) имеет ряд преимуществ. В частности, это позволяет BGP рефлекторам маршрутов рассылать метки, таким образом обеспечивая существенную масштабируемость по сравнению с использованием LDP для пересылки меток между BGP партнерами. 2.29.2. Метки для RSVP Flowspecs Когда используется RSVP при резервировании ресурсов для конкретных потоков, может быть желательно, помечать пакеты в этих потоках, так что не нужно будет использовать RSVP filterspec в каждом из узлов. Можно обосновать, что осуществление рассылки меток в рамках RSVP в качестве части процесса формирования пути, и резервирования ресурсов является наиболее эффективным методом решения проблемы. 2.29.3. Метки для явно маршрутизируемых LSP В некоторых приложениях MPLS, в частности сопряженных с управлением трафиком (ТЕ), желательно формировать пути, маршрутизированные явно от точки входа до точки выхода. Хотелось бы также осуществлять резервирование ресурсов вдоль всего пути. Можно представить два подхода: - Начать с существующего протокола, который используется при установлении резервирования, и расширить его в направлении поддержки явной маршрутизации и рассылки меток. - Начать с существующего протокола, который используется для рассылки меток, и расширить его в сторону явной маршрутизации и резервирования ресурсов. Первый подход реализован в протоколе, описанном в [MPLS -RSVP-TUNNELS], второй – специфицирован в [MPLS-CR-LDP]. 3. Некоторые применения MPLS 3.1. MPLS и трафик, маршрутизируемый шаг-за-шагом Ряд приложений MPLS требуют, чтобы пакеты с определенной меткой направлялись одним и тем же путем, маршрутизированным шаг-за-шагом. Этот путь будет использоваться для пакетов с адресом, который специфицирован в соответствующем поле заголовка сетевого уровня. 3.1.1. Метки для адресных префиксов Вообще, маршрутизатор R определяет следующий шаг для пакета P путем нахождения подходящего адресного префикса X в своей маршрутной таблице. То есть, пакеты в данном FEC – это пакеты, которые соответствуют заданному адресному префиксу в маршрутной таблице R. В этом случае, FEC может быть идентифицирован адресным префиксом. Заметим, что пакет P может быть приписан к FEC F, а FEC F может быть идентифицирован адресным префиксом X, даже если адрес места назначения P не согласуется с X. 3.1.2. Рассылка меток для адресных префиксов 3.1.2.1. Партнеры рассылки меток для адресного префикса LSR R1 и R2 считаются партнерами рассылки меток для адресного префикса X, если и только если выполнено одно из следующих условий: 1. Маршрут R1 к X является маршрутом, который прислан определенным IGP, а R2 является соседом R1 по данным IGP. 2. Маршрут R1 к X является маршрутом, который прислан в какой-то момент в результате работы алгоритма маршрутизации A1, и этот маршрут рассылается алгоритмом маршрутизации A2, а R2 является соседом R1 согласно A2. 3. R1 является выходной точкой LSP-туннеля, который находится внутри другого LSP, а R2 является входной точкой этого туннеля, R1 и R2 являются клиентами IGP, и находятся в той же области IGP (если данный IGP имеет области), а маршрут от R1 к X был получен через IGP, или в результате рассылки R1 данному IGP. 4. Маршрут R1 к X является маршрутом, который прислан BGP, а R2 является BGP-партнером R1. Вообще, эти правила гарантируют то, что, если маршрут до определенного адресного префикса рассылается через IGP, партнеры рассылки меток для данного адресного префикса являются IGP-соседями. Если маршрут определенного адресного префикса рассылается через BGP, партнеры рассылки меток для данного адресного префикса являются BGP партнерами. В других случаях LSP-туннелирования конечные точки туннеля являются партнерами по рассылке меток. 3.1.2.2. Рассылаемые метки Для того чтобы использовать MPLS для переадресации пакетов согласно маршруту шаг-за-шагом, соответствующему какому-либо адресному префиксу, каждый LSR должен: 1. Связать один или более меток с каждым адресным префиксом, который обнаружен в маршрутной таблице. 2. Для каждого такого адресного префикса X, использовать протокол рассылки меток для уведомления партнеров (в рамках Х) о существовании ассоциации метки с данным префиксом. Существует также обстоятельство, при котором LSR должен рассылать ассоциации меток для адресного префикса, даже если он не является LSR, который установил связь между меткой и префиксом: 3. Если R1 использует BGP для рассылки маршрута до X, называя некоторый другой LSR R2 в качестве следующего BGP шага к X, и если R1 знает, что R2 присвоена метка L, тогда R1 должен разослать уведомление об ассоциации L и X всем BGP-партнерам, которым он рассылает это маршрут. Эти правила гарантируют, что метки, ассоциированные с адресным префиксам, которые соответствуют маршрутам BGP, рассылаются IGP-соседям, если и только если BGP-маршруты разосланы IGP. Другими словами, метки, привязанные к BGP-маршрутам, рассылаются только другим BGP-агентам. Эти правила имею целью указать, какие ассоциации меток должны рассылаться данным LSR другим LSR. 3.1.3. Использование маршрутов шаг-за-шагом в качестве LSP Если путь шаг-за-шагом, которому пакет P должен следовать, характеризуется <R1, ..., Rn >, тогда < R1, ..., Rn> может быть LSP до тех пор пока: 1. Существует один адресный префикс X , такой, что для всех i, 1<=i<n , X является наилучшим соответствием в маршрутной таблице Ri для адреса места назначения P ; 2. Для всех i, 1<i <n, Ri установил соответствие метки и X и разослал эту метку всем R[i-1]. Заметим, что LSP пакета может простираться только до ближайшего маршрутизатора, чья маршрутная таблица содержит запись с префиксом, имеющим наилучшее соответствие для адреса места назначения пакета. В этой точке LSP должен завершиться, а алгоритм поиска наилучшего соответствия должен быть запущен заново. Предположим, например, что пакет P, с адресом места назначения 10.2.153.178 должен двигаться от R1 к R2 и далее к R3. Предположим также, что R2 анонсирует адресный префикс 10.2/16 для R1, но R3 анонсирует 10.2.153/23, 10.2.154/23 и 10.2/16 до R2. То есть, R2 анонсирует "агрегатный маршрут" для R1. В этой ситуации, пакет P может быть коммутируемым по метке до тех пор, пока он не достигнет R2, но так как R2 осуществил агрегатирование маршрутов, он должен запустит алгоритм поиска наилучшего соответствия, чтобы найти FEC для P. 3.1.4. Конец LSP и прокси конец LSP LSR R считается конечным LSR LSP для адресного префикса X, если и только если выполнено одно из следующих условий: 1. R имеет адрес Y, такой что X является адресным префиксом в маршрутной таблице R, который наилучшим образом соответствует Y, или 2. R содержит в своей маршрутной таблице один или более адресных префиксов Y, таких что X является подходящей начальной субстрокой Y, но "предыдущие шаги LSP" R для X не содержат никакого адресного префикса Y. То есть, R является "точкой ликвидации агрегатирования" для адресного префикса X . LSR R1 считается "прокси концом LSP" LSR для адресного префикса X, если и только если: 1. Следующим шагом R1 для X служит R 2, а R1 и R2 не являются партнерами по рассылке меток с точки зрения X (возможно потому, что R2 не поддерживает MPLS), или 2. R1 был сконфигурирован, чтобы работать в качестве прокси конца LSP для X Определение LSP позволяет концу LSP быть узлом, который не поддерживает MPLS. В этом случае предпоследний узел в LSP является прокси выходным. 3.1.5. Неявная метка NULL Неявная метка NULL представляет собой метку со специальной семантикой, которую LSR может связать с адресным префиксом. Если LSR Ru после получения справки в ILM видит, что помеченный пакет P должен быть переадресован следующему Rd, но что Rd разослал ассоциацию неявной метки NULL с соответствующим адресным префиксом, тогда вместо того, чтобы заменить значение метки на вершине стека, Ru опустошает стек меток, а затем переадресует полученный пакет в Rd. LSR Rd рассылает ассоциацию неявной метки NULL и адресного префикса X в LSR Ru, если и только если: 1. Правила раздела 3.1.2 указывают, что Rd посылает Ru ассоциацию метки для X, и 2. Rd знает, что Ru может поддерживать неявные метки NULL (т.e., что он может очистить стек меток), и 3. Rd является концом LSP (а не прокси концом) для X. Это заставляет предпоследний LSR на LSP очистить стек меток. Это вполне приемлемо, если конец LSP является концом MPLS для X, далее если предпоследний LSR не очистит стек меток, конечный узел LSP будет должен просмотреть метку, извлечь метку из стека, и затем посмотреть следующую метку (или просмотреть адрес L3, если меток больше нет). При выполнении предпоследним LSR команды pop для стека меток, конец LSP избавляется от необходимости просмотра двух меток, для того чтобы принять свое решение переадресации. Однако если предпоследним LSR является ATM-коммутатор, он может не иметь возможности выполнить команду pop для стека меток. Следовательно, может быть послана ассоциация неявной метки в LSR, который может поддерживать эту функцию. Если предпоследний LSR в LSP для адресного префикса X является прокси концом LSP, он действует, как если бы конец LSP разослал ассоциацию неявной метки NULL для X. 3.1.6. Опция: присвоение метки Egress Targeted Существуют ситуации, в которых начало LSP Ri, знает, что пакеты нескольких разных FEC должны следовать одним и тем же LSP, завершающимся, скажем, конечным Re. В этом случае, корректная маршрутизация может быть реализована использованием одной метки для всех таких FEC, необязательно иметь отличающиеся метки для каждого FEC. Если и только если выполняются следующие условия: 1. Адрес LSR Re сам находится в маршрутной таблице (host route), и 2. Существует некоторый способ для Ri определить, что Re является концом LSP для всех пакетов в конкретном наборе FEC. Затем Ri может связать одну метку со всеми элементами набора FEC. Это называется "Egress-Targeted Label Assignment". Как может LSR Ri определить, что LSR Re является концом LSP для всех пакетов в конкретном FEC? Существует несколько возможных путей: - Если сеть реализует алгоритм маршрутизации состояния канала, а все узлы в области поддерживают MPLS, тогда алгоритм маршрутизации предоставляет Ri достаточно информации, чтобы определить маршрутизаторы, через которые пакеты в данном FEC должны покинуть домен маршрутизации или область. - Если сеть реализует BGP, Ri может определить, какие пакеты в заданном FEC должны покинуть сеть через некоторый конкретный маршрутизатор, который является "BGP Next Hop" для этого FEC. - Можно использовать протокол рассылки меток, чтобы передать информацию о том, какие адресные префиксы подключены к какому концевому LSR. Этот метод имеет преимущество отсутствия зависимости от наличия маршрутизации по состоянию канала. Если используется присвоение меток egress-targeted, число меток, которые необходимо поддерживать во всей сети может быть сокращено. Это может быть важно, если используется аппаратные переключатели для реализации MPLS, а коммутирующее оборудование может поддерживать ограниченное число меток. Возможным подходом могло бы быть конфигурирование сети для использования присвоения меток egress-targeted по умолчанию, но при конфигурации конкретных LSR не использовать присвоения меток egress-targeted для одного или более адресных префиксов, для которых он является концом LSP. Мы вводим следующее правило: - Если какой-то LSR не является концом LSP для некоторого набора адресных префиксов, тогда он должен присваивать метки адресным префиксам так же, как это делается узлом следующего шага LSP для этих адресных префиксов. То есть, предположим, Rd является маршрутизатором следующего шага (Ru) LSP для адресного префикса X1 и X2. Если Rd приписывает ту же метку X1 и X2, Ru должен сделать то же самое. Если Rd присваивает разные метки X1 и X2, тогда и Ru должен это сделать. Например, предположим, что хочется осуществить присвоение метки egress-targeted по умолчанию, но присвоить разные метки тем адресным префиксам, для которых существует несколько возможных концов LSP (т.e., для тех адресных префиксов, которые являются multi-homed). Можно сконфигурировать все LSR для использования присвоения меток egress-targeted, и затем конфигурировать LSR, чтобы приписать разные метки тем адресным префиксам, которые являются multi-homed. Для конкретного адресного префикса multi-homed X, было бы нужно сконфигурировать LSR, которые являются либо концами LSP, либо прокси концами LSP для X. Важно заметить, что если Ru и Rd являются смежными LSR в LSP для X1 и X2, переадресация будет выполнена корректно, если Ru присваивает разные метки X1 и X2, в то время как Rd присваивает одну метку для них обоих. Это лишь означает, что R1 будет устанавливать соответствие между разными входными метками и одной выходной. Аналогично, если Rd присваивает разные метки X1 и X2, но Ru присваивает им обоим метку, соответствующую адресу их конца LSP или прокси конца, переадресация будет, тем не менее, осуществляться корректно. Ru будет лишь устанавливать соответствие между входной меткой и меткой, которую сформировал Rd для адреса конца LSP . 3.2. MPLS и LSP, маршрутизируемые явно Существует несколько причин, почему желательно использовать явную маршрутизацию, а не схему шаг-за-шагом. Например, это позволяет маршрутам основываться на административной политике, допускать маршруты, которые формируют LSP согласно соображения управления трафиком [MPLS-TRFENG]. 3.2.1. LSP-туннели, маршрутизируемые явно В некоторых ситуациях сетевые администраторы могут захотеть переадресовывать определенные классы трафика по определенным специфицированным заранее маршрутам, где эти пути отличаются от маршрутов шаг-за-шагом, по которым шел трафик первоначально. Это может быть сделано для поддержки политики маршрутизации, или для управления трафиком (ТЕ). Явный маршрут может быть сконфигурирован, или он может быть определен динамически посредством, например, маршрутизации на основе ограничений. MPLS позволяет выполнить это легко посредством LSP–туннелей, маршрутизированных явно. Для этого необходимо: 1. Средства отбора
пакетов, которые должны быть посланы в LSP-туннель, маршрутизированный явно;
Если передающий конец туннеля хочет поместить помеченный пакет в туннель, он должен сначала заменить метку на вершине стека меткой, присланной принимающей стороной туннеля. Затем он должен ввести в стек метку, которая соответствует самому туннелю и прислана маршрутизатором следующего шага в туннеле. Чтобы разрешить это, концы туннеля должны быть явными партнерами по обмену метками. Ассоциации меток, которыми они должны обменяться не представляют интереса для LSR в туннеле. 3.3. Стеки меток и неявное партнерство Предположим конкретный LSR Re является прокси концом LSP для 10 адресных префиксов, и он имеет доступ к каждому адресному префиксу через отдельный интерфейс. Можно было бы присвоить одну метку всем 10 адресным префиксам. Тогда Re будет концом LSP для всех этих префиксов. Это гарантирует, что пакеты для всех 10 адресных префиксов будут доставлены Re. Однако Re был бы должен просматривать сетевой адрес каждого такого пакета, для того чтобы правильно выбрать интерфейс, через который его следует послать. В качестве альтернативы, можно было бы присвоить разные метки для каждого из интерфейсов. Тогда Re будет прокси концом LSP для 10 адресных префиксов. Это исключает необходимость для Re просматривать сетевые адреса пакетов, чтобы переадресовывать пакеты. Однако это может привести к использованию слишком большого числа меток. Альтернативой может быть объединение всех 10 адресных префиксов вокруг одной общей метки уровня 1 (которая ассоциирована также с адресом самого LSR), после чего можно связать каждый адресный префикс с отдельной меткой уровня 2. Метка уровня 2 будет рассматриваться как атрибут ассоциации метки уровня 1, который мы будем называть "атрибутом стека". Мы вводим следующие правила: - Когда LSR Ru помечает ранее непомеченные пакеты, если наилучшим соответствием адресу места назначения пакета равно X, а следующим шагом Ru LSP для X является Rd, и Rd послал Ru ассоциацию метки L1 и X, наряду с атрибутом стека L2, тогда 1. Ru должен занести в стек меток L2, а затем L1, а после этого переадресовать пакет Rd; 2. Когда Ru посылает ассоциацию метки для X своим партнерам по рассылке меток, он должен включить L2 в качестве атрибута стека. 3. Когда бы атрибут стека изменился (возможно в результате изменения следующего шага Ru LSP для X), Ru должен разослать новый атрибут стека. Заметим, что хотя значение метки, связанное с X, может отличаться для последовательных шагов в LSP , значение атрибута стека передается без изменений, оно устанавливается узлом прокси конца LSP. Таким образом, прокси конец LSP для X становится "неявным партнером" каждого прочего LSR в области или домене маршрутизации. В этом случае, явное партнерство было бы слишком тяжеловесным, так как число партнеров стало бы слишком большим. 3.4. MPLS и маршрутизация при нескольких путях Если LSR поддерживает много путей для заданного потока, тогда он может приписать потоку много меток, по одной для каждого маршрута. Таким образом, получение второй ассоциации метки от определенного соседа для заданного адресного префикса должно интерпретироваться так, что любая из меток может представлять данный адресный префикс. Если специфицировано несколько ассоциаций меток для заданного адресного префикса, они могут иметь разные атрибуты. 3.5. Деревья LSP как объекты мультиточка-точка Рассмотрим случай, когда пакеты P1 и P2 имеют адреса места назначения в префиксе Х. Предположим, что маршрут шаг-за-шагом для P1 представляет собой <R1, R2, R3>, а путем шаг-за-шагом для P2 является <R4, R2, R3>. Давайте предположим, что R3 связывает метку L3 с X, и отсылает эту ассоциацию R2. R2 связывает метку L2 с X, и посылает эту ассоциацию в R1 и R4. Когда R2 получает пакет P1, его входная метка будет также L2. R2 заменит L2 на L3, и пошлет P1 в R3. Когда R2 получает пакет P2, его входная метка будет также L2. R2 снова заменит L2 на L3, и пошлет P2 в R3. Заметим далее, что когда P1 и P2 двигаются от R2 к R3, они несут одну и ту же метку, и с точки зрения MPLS, они не различимы. Таким образом, вместо того чтобы говорить о двух разных LSP, <R1, R2, R3> и <R4, R2, R3>, мы можем говорить об одном дереве LSP мультиточка-точка (Multipoint-to-Point LSP Tree), которое мы можем обозначить как <{ R1, R4}, R2, R3>. Это создает трудности, когда мы пытаемся использовать обычные ATM-коммутаторы в качестве LSR. Так как обычные ATM-коммутаторы не поддерживают соединения мультиточка-точка, должны существовать процедуры, гарантирующие, чтобы каждый LSP реализовал VC по схеме точка-точка. Однако если используются ATM-коммутаторы, которые поддерживают VC мультиточка-точка, тогда LSP может быть реализован эффективно по такой схеме. Альтернативой может служить ситуация, когда можно использовать многоточечное представление SVP (раздел 2.25.2), LSP может быть реализован как SVP мультиточка-точка. 3.6. LSP-туннелирование между пограничными BGP маршрутизаторами Рассмотрим случай автономной системы A, которая пропускает трафик между другими автономными системами. Автономная система A будет иметь несколько пограничных маршрутизаторов BGP, и сеть BGP соединений между ними, через которые пересылаются BGP маршруты. Во многих таких случаях желательно избежать рассылки BGP-маршрутов маршрутизаторам, которые не являются пограничными. Если этого можно избежать, нагрузка по рассылке маршрутов этих маршрутизаторов существенно сокращается. Однако должны быть некоторые средства, гарантирующие, что транзитный трафик будет доставляться от одного BGP-маршрутизатора к другому с помощью внутренних маршрутизаторов. Это может быть легко сделано с помощью туннелей LSP. Предположим, что BGP маршруты рассылаются только пограничным BGP-маршрутизаторам, а не внутренними маршрутизаторами, которые расположены по пути. LSP-туннели могут использоваться следующим образом: 1. Каждый пограничный маршрутизатор BGP посылает каждому другому пограничному маршрутизатору BGP в пределах автономной системы метку для каждого адресного префикса, которую он пересылает в рамках протокола BGP. 2. IGP для автономной системы поддерживает маршрут для каждого BGP-маршрутизатора. Каждый внутренний маршрутизатор рассылает свои метки для этих маршрутов каждому своему IGP-соседу. 3. Предположим, что: a) Пограничный маршрутизатор BGP B1 получает непомеченный пакет P. b) Адресный префикс X в маршрутной таблице B1 является наилучшим соответствием для адреса места назначения пакета P. c) Маршрут до X является маршрутом BGP. d) Следующим шагом BGP для X является B2. e) B2 имеет ассоциацию метки L1 и X, и посылает эту ассоциацию в B1. f) Следующий шаг IGP для адреса B2 является I1. g) Адрес B2 содержится в маршрутных таблицах B1 и I1 IGP, а h) I1 связывает метку L2 с адресом B2 и посылает эту ассоциацию B1. Далее прежде чем послать пакет P в I1, B 1 должен сформировать стек меток для P, затем заносит туда метку L1, а на верх стека записывает L2. 4. Предположим, что пограничный BGP маршрутизатор B1 получает помеченный пакет P, где на верху стека размещена метка, соответствующая адресному префиксу X маршрута, и что условия 3b, 3c, 3d и 3e все выполнены. Тогда прежде чем посылать пакет P в I1, B1 должен заменить метку на верху стека на метку L1, и затем записать в стек метку L2. Эти процедуры эффективно формируют LSP-туннель, маршрутизированный шаг-за-шагом, между пограничными маршрутизаторами BGP. Так как пограничные BGP-маршрутизаторы обмениваются ассоциациями меток для адресных префиксов, которые неизвестны IGP, маршрутизаторы BGP должны стать партнерами по явному обмену метками. Иногда можно сформировать LSP-туннель, маршрутизированный шаг-за-шагом, между двумя пограничными маршрутизаторами BGP, даже если они не принадлежат общей автономной системе. Предположим, например, что B1 и B2 находятся в AS1. Предположим также, что B3 является EBGP-соседом B2, и находится в AS2. Наконец, предположим, что B2 и B3 находятся в некоторой сети, которая является общей для обеих автономных систем ("демилитаризованная зона"). В этом случае LSP-туннель может быть сформирован непосредственно между B1 и B3 следующим образом: · B3 посылает маршруты B2 (используя EBGP), опционно присваивая метки адресным префиксам; · B2 перераспределяет маршруты к B1 (используя IBGP), указывая, что следующим шагом BGP для каждого такого маршрута является B3. Если B3 присвоил метки адресным префиксам, B2 передает эти метки далее без изменений вплоть до B1. · IGP автономной системы AS1 имеет host route для B3. 3.7. Другие применения LSP-туннелей, маршрутизированных шаг-за-шагом Использование LSP-туннелей, маршрутизированных шаг-за-шагом не ограничено туннелями между узлами BGP. Любая ситуация, в которой мог бы использоваться туннель с инкапсуляцией, является приемлемой для применения LSP-туннеля, маршрутизируемого шаг-за-шагом. Вместо инкапсуляции пакета с новым заголовком, чей адрес места назначения является адресом приемной точки туннеля, производится занесение в стек метки, соответствующей адресному префиксу, который ассоциируется с адресом конечной точки туннеля. Пакет, посланный в туннель, может быть помеченным или нет. Если начальный узел туннеля намеревается направить помеченный пакет в туннель, он должен сначала заменить значение метки в стеке на значение, полученное от узла конца туннеля. Затем он должен занести в стек метку, которая соответствует самому туннелю. Чтобы разрешить это, конечные точки туннеля должны быть явными партнерами обмена метками. Ассоциации меток, которыми они должны обмениваться не играют никакой роли для LSR в пределах туннеля. 3.8. MPLS и мультикастинг Мультикастная маршрутизация осуществляется путем формирования мультикаст-деревьев. Дерево, вдоль которого должен переадресовываться конкретный мультикаст пакет, зависит от адресов отправителя и получателя пакета. Когда конкретный LSR является узлом некоторого мультикаст-дерева, он связывает метку с этим деревом. Он рассылает эту ассоциацию вдоль данного дерева. Если рассматриваемый узел принадлежит локальной сети, и имеет партнеров в этой сети, он должен также рассылать указанные ассоциации своим партнерам. Это позволяет вышестоящим узлам использовать одну метку, когда осуществляется мультикатинг для всех нижестоящих объектов LAN. Когда приходит помеченный мультикастный пакет, NHLFE , соответствующий метке, указывает на набор выходных интерфейсов для данного пакета, а также на выходную метку. Если используется один и тот же формат представления метки для всех выходных интерфейсов, один и тот же пакет может быть послан всем нижестоящим объектам. 4. Процедуры пересылки меток (Hop-by-Hop) В этом разделе, мы рассматриваем только ассоциации меток, которые используются для трафика, который коммутируется по меткам в пределах пути, маршрутизованного по схеме шаг-за-шагом. В этих случаях, метка будет соответствовать адресному префиксу в маршрутной таблице. 4.1. Процедуры анонсирования и использования меток Существует некоторое число различных процедур, которые могут использоваться для рассылки ассоциаций меток. Некоторые исполняются нижестоящим LSR, а некоторые вышестоящим LSR. Нижестоящий LSR должен выполнить: - Процедуру рассылки и Вышестоящий LSR должен выполнить:
Архитектура MPLS поддерживает несколько разных вариантов каждой процедуры. Однако архитектура MPLS не поддерживает все комбинации возможных вариантов. Набор поддерживаемых комбинаций будет обсужден в разделе 4.2, где рассматривается совместимость различных комбинаций. 4.1.1. Нижестоящий LSR: Процедура рассылки Процедура рассылки используется нижестоящим LSR, чтобы определить, когда он должен разослать своим партнерам ассоциации меток для конкретного адресного префикса. Архитектура поддерживает четыре разные процедуры рассылки. Вне зависимости от используемой процедуры рассылки, если ассоциация метки для заданного адресного префикса была послана нижестоящим LSR Rd вышестоящему LSR Ru, и, если в какой-то момент атрибуты ассоциации (как это определено выше) изменились, тогда Rd должен проинформировать Ru о новых атрибутах. Если LSR поддерживает несколько маршрутов для заданного адресного префикса, то будет ли LSR ассоциировать несколько меток данному адресному префиксу (один на маршрут), и, следовательно, рассылать несколько ассоциаций, является исключительно локальной проблемой 4.1.1.1. PushUnconditional Пусть Rd является LSR. Предположим, что: 1. X является адресным префиксом в маршрутной таблице Rd 2. Ru является партнером по рассылке меток Rd с точки зрения X Когда бы эти условия ни выполнялись, Rd должен связать метку с X и послать эту ассоциацию Ru. Отслеживание ассоциаций, которые посылаются Ru, и контроль того, что Ru всегда имеет эти ассоциации, является областью ответственности Rd. Эта процедура должна использоваться LSR, которые выполняют не затребованное присвоение меток в независимом режиме управления LSP. 4.1.1.2. PushConditional Пусть Rd является LSR. Предположим, что: 1. X является адресным префиксом в маршрутной таблице Rd 2. Ru является партнером Rd по рассылке меток с учетом X 3. Rd является либо концом LSP, либо прокси концом LSP для X , или следующим шагом Rd L3 для X является Rn, где Rn отличается от Ru, и Rn связал метку с X и послал эту ассоциацию Rd. Затем, как только все эти условия оказались выполнены, Rd должен связать метку с X и послать эту ассоциацию Ru. Поскольку PushUnconditional вызывает рассылку ассоциаций меток всем адресным префиксам маршрутной таблицы, PushConditional вызывает рассылку ассоциаций меток только тем адресным префиксам, для которых получены ассоциации от одного следующего шага LSP, или для которых не существует следующего шага с поддержкой MPLS L3. Эта процедуру следует использовать LSR, которые выполняют не затребованное присвоение меток в упорядоченном режиме управления LSP. 4.1.1.3. PulledUnconditional Пусть Rd является LSR. Предположим, что:
1. X является адресным префиксом в маршрутной таблице Rd
3. Ru явно запросил Rd связать метку с X и послать эту ассоциацию Ru Затем Rd должен связать метку с X и послать эту ассоциацию Ru. Заметим, что если X отсутствует в маршрутной таблице Rd, или если Rd не является партнером Ru по рассылке меток с учетом X, тогда Rd должен проинформировать Ru о том, что в данный момент не может предоставить ассоциацию. Если Rd уже переслал Ru ассоциацию метки для адресного префикса X, и получил новый запрос от Ru ассоциации для адресного префикса X, он свяжет вторую метку, и пошлет новую ассоциацию Ru . Первая ассоциация метки остается в силе. Эта процедура будет использоваться LSR, выполняющими рассылку меток downstream-on-demand, используя независимый режим управления LSP. 4.1.1.4. PulledConditional Пусть Rd является LSR. Предположим, что: 1. X является адресным префиксом в маршрутной таблице Rd
Затем, как только все эти условия оказались выполнены, Rd должен связать метку с X и послать эту ассоциацию Ru . Заметим, что если X отсутствует в маршрутной таблице Rd, а получить ассоциацию для X через следующий шаг Rd для X невозможно, или если Rd не является партнером Ru по пересылке меток с учетом X, тогда Rd должен проинформировать Ru, что не может в данный момент предоставить ему необходимую ассоциацию. Однако, если хотя бы одно условие не выполнено, Rn не выдает метку Rd, а Rd должен отложить отклик для Ru до тех пор, пока Rn не пришлет ассоциацию метки. Если Rd послал Ru ассоциацию метки для адресного префикса X, а спустя какое-то время любой из атрибутов ассоциации метки изменился, Rd должен заново послать Ru ассоциацию с новым значением атрибута. Он должен сделать это даже если Ru не послал нового запроса. Эту процедуру следует использовать LSR, которые осуществляют ассоциацию меток downstream-on-demand в упорядоченном режиме управления LSP. В разделе 4.2, мы обсудим то, как выбрать конкретную процедуру, которую следует использовать в конкретной ситуации, и как гарантировать совместимость работы LSR, выбравших разные процедуры. 4.1.2. Вышестоящий LSR: процедура запроса Процедура запроса используется вышестоящим LSR для адресного префикса, чтобы определить, когда следует запросить нижестоящий LSR связать метку с адресным префиксом и разослать эту ассоциацию. Существует три процедуры, которые могут быть использованы. 4.1.2.1. RequestNever Никогда не делай запросов. Эта процедура полезна, если нижестоящий LSR использует процедуры PushConditional или PushUnconditional, но она бесполезна, если нижестоящий LSR использует процедуры PulledUnconditional или PulledConditional. Эта процедура будет использоваться LSR, когда применена не запрошенная рассылка меток и свободный режим удержания меток. 4.1.2.2. RequestWhenNeeded Осуществляет запрос всякий раз, когда меняется соотношение между следующим шагом L3 и адресным префиксом, или когда прислан новый адресный префикс, и нет уже ассоциации метки от следующего шага для заданного адресного префикса. Эту процедуру следует использовать LSR, когда применен консервативный режим удержания меток. 4.1.2.3. RequestOnRequest Процедура посылает запрос всякий раз, когда приходит запрос в дополнение к необходимым протокольным запросам (как это описано в разделе 3.1.2.2). Если Ru не способен быть входом LSP, он может выдать запрос, только когда получает запрос сверху. Если Rd получает такой запрос от Ru, для адресного префикса, для которого Rd уже послал метку Ru, Rd присвоит новую метку, ассоциирует ее с X, и разошлет эту ассоциацию. Может ли Rd послать эту ассоциацию Ru немедленно или нет, зависит от используемой процедуры рассылки. Эту процедуру следует использовать LSR, которые осуществляют рассылку меток downstream-on-demand, но не выполняют объединения меток, например, ATM-LSR, которые не способны объединять VC. 4.1.3. Вышестоящий LSR: процедура NotAvailable Если Ru и Rd являются соответственно вышестоящим и нижестоящим партнерами рассылки меток для адресного префикса X, Rd является следующим шагом Ru L3 для X, Ru запрашивает ассоциацию для X от Rd, но Rd отвечает, что не может предоставить ассоциацию в это время, так как он не имеет следующего шага для X. Далее процедура NotAvailable определяет, как должен реагировать Ru. Существует две возможные процедуры, управляющие поведением Ru: 4.1.3.1. RequestRetry Ru должен выдать запрос снова спустя некоторое время. То есть, источник запроса ответственен за попытку получить необходимую ассоциацию позднее. Эту процедуру следует использовать, когда применена рассылка меток downstream-on-demand. 4.1.3.2. RequestNoRetry Ru никогда не должен посылать запрос повторно, предполагая, что Rd предоставит необходимую ассоциацию автоматически, когда она станет доступной. Это полезно, если Rd использует процедуру PushUnconditional или PushConditional, т.e., если применена не запрошенная рассылка меток нижестоящим объектам. Заметим, что если Rd отвечает, что он не может предоставить ассоциацию Ru, из-за тех же условий ошибки, а не по причине того, что Rd не имеет следующего шага, поведение Ru будет управляться условиями восстановления после ошибки протокола рассылки меток, а не процедурой NotAvailable. 4.1.4. Вышестоящий LSR: процедура Release Предположим, что Rd является LSR, который связывает метку с адресным префиксом X, и который послал эту ассоциацию LSR Ru. Если Rd не оказался следующим шагом Ru L3 для адресного префикса X, или перестал быть следующим шагом Ru L3 для адресного префикса X, Ru перестанет использовать метку. Процедура Release определяет то, как Ru работает в этом случае. Существует две возможные процедуры, управляющие поведением Ru: 4.1.4.1. ReleaseOnChange Ru должен ликвидировать ассоциацию и информировать Rd об этом. Эту процедуру следует использовать в консервативном режиме удержания меток (Label Retention Mode). 4.1.4.2. NoReleaseOnChange Ru должен поддерживать ассоциацию, так что он сможет использовать ее немедленно, если Rd станет позднее следующим шагом Ru L3 для X . Эту процедуру следует использовать для реализации свободного режима удержания меток ( Liberal Label Retention Mode). 4.1.5. Вышестоящий LSR: процедура labelUse Предположим, что Ru является LSR, который получил ассоциацию метки L для адресного префикса X от LSR Rd. Ru является вышестоящим по отношению к Rd с учетом X , и в действительности Rd является следующим шагом Ru L3 для X. Ru воспользуется ассоциацией, если Rd является следующим шагом Ru L3 для X. Если в момент получения ассоциации Ru, Rd не является следующим шагом Ru L3 для X , Ru не будет использовать эту ассоциацию. Ru может однако начать использовать ассоциацию позже, если Rd станет следующим шагом Ru L3 для X. Процедура labelUse определяет, как Ru использует ассоциацию Rd. Существует две процедуры, которые может использовать Ru: 4.1.5.1. UseImmediate Ru может начать использовать ассоциацию немедленно. В любое время, когда Ru получил ассоциацию для X от Rd , а Rd является следующим шагом Ru L3 для X, Rd будет также следующим шагом Ru LSP для X . Эта процедура применяется, когда не используется детектирование петель. 4.1.5.2. UseIfLoopNotDetected Эта процедура аналогична UseImmediate, если только Ru не детектировал петлю в LSP. Если детектирована петля, Ru прекратит использовать метку L для переадресации пакетов в Rd. Эта процедура используется, когда работает детектирование петель маршрутов. Это будет продолжаться до тех пор, пока не изменится следующий шаг для X, или пока не будет ликвидирован петлевой маршрут. 4.1.6. Нижестоящий LSR: процедура отзыва В этом случае существует только одна процедура. Когда LSR Rd решает разорвать ассоциацию между меткой L и адресным префиксом X, тогда это решение должно быть доведено до сведения всех LSR, которым эта ассоциация была прислана. Требуется, чтобы уведомление о разрыве ассоциации между L и X было послано Rd в LSR Ru, прежде чем Rd пришлет Ru какие-либо иные ассоциации L с какими-либо префиксами Y, где X != Y. Если Ru узнал о новой ассоциации L и Y, до того как получил данные о разрыве ассоциации L и X, и если пакеты, соответствующие префиксам X и Y, переадресуются из Ru в Rd, тогда в течение некоторого времени Ru будет помечать пакеты, относящиеся к X и к Y меткой L. Рассылка и отзыв ассоциаций меток осуществляется через протокол рассылки меток. Все протоколы рассылки меток требуют, чтобы был установлен контакт между партнерами рассылки меток (за исключением неявных партнеров). Если LSR R1 установил контакт по рассылке меток с LSR R2, и получил ассоциации меток от LSR R2 через это соединение, тогда если соединение будет разорвано одним из партнеров (либо в результате поломки, либо обычной работы), все ассоциации, полученные через это соединение, должны рассматриваться как отозванные. Пока эффективное соединение по обмену метками остается в силе, отзыв ассоциаций меток должен производиться явно. Если вторая метка ассоциирована с адресным префиксом, первая метка при этом не отзывается, будут существовать обе ассоциации. Это необходимо, чтобы поддерживать маршрутизации с несколькими маршрутами. Если второй адресный префикс ассоциирован с меткой, ассоциация с первым префиксом при этом не отзывается, метка будет использоваться для обоих адресных префиксов. 4.2. Схемы MPLS: поддерживаемые комбинации процедур Рассмотрим два LSR, Ru и Rd, которые являются партнерами рассылки меток для некоторого набора адресных префиксов, где Ru является вышестоящим партнером, а Rd – нижестоящим. Схема MPLS, которая управляет взаимодействием Ru и Rd может быть описана с помощью пяти процедур: <Distribution Procedure, Request Procedure, NotAvailable Procedure, Release Procedure, labelUse Procedure>. Так как существует только одна процедура отзыва, она здесь не упоминается. Появление "*" в одной из позиций в качестве подмены, означает, что в данной категории возможна любая процедура; появление "N/A" в некоторой позиции указывает, что не нужна никакая процедура данной категории. Только схемы MPLS, которые специфицированы ниже, поддерживаются архитектурой MPLS. Другие схемы могут быть добавлены в будущем, если их необходимость будет доказана. 4.2.1. Схемы для LSR, которые поддерживают объединение меток Если Ru и Rd являются партнерами по рассылке меток, и оба поддерживают объединение меток, должна использоваться одна из следующих схем: 1. <PushUnconditional, RequestNever, N/A, NoReleaseOnChange, UseImmediate > Это не затребованная рассылка меток “вниз по течению” с независимым управлением, свободным режимом удержания меток и без детектирования маршрутных петель. 2. <PushUnconditional, RequestNever, N/A, NoReleaseOnChange, UseIfLoopNotDetected> Это не затребованная рассылка меток “вниз по течению” с независимым управлением, свободным режимом удержания меток и детектированием петель. 3. <PushConditional, RequestWhenNeeded, RequestNoRetry, ReleaseOnChange,*> Это не затребованная рассылка меток “вниз по течению” с упорядоченным управлением (со стороны конца) и консервативным режимом удержанием меток. Детектирование петель опционно. 4. <PushConditional, RequestNever, N/A, NoReleaseOnChange, *> Это не затребованная рассылка меток “вниз по течению” с упорядоченным управлением (со стороны конца) и свободным режимом удержанием меток. Детектирование петель опционно. 5. <PulledConditional, RequestWhenNeeded, RequestRetry, ReleaseOnChange, *> Это рассылка меток “вниз по течению по запросу” (downstream-on-demand) с упорядоченным управлением (инициируемым со стороны входа), консервативным режимом удержания меток и опционным детектированием петель. 6. <PulledUnconditional, RequestWhenNeeded, N/A, ReleaseOnChange, UseImmediate> Это рассылка меток “вниз по течению по запросу” с независимым управлением, консервативным режимом удержания меток и без детектирования петель. 7. <PulledUnconditional, RequestWhenNeeded, N/A, ReleaseOnChange, UseIfLoopNotDetected> Это рассылка меток “вниз по течению по запросу” с независимым управлением, консервативным режимом удержания меток и детектированием петель. 4.2.2. Схемы для LSR, которые не поддерживают объединение меток Предположим, что R1, R2, R3 и R4 являются ATM-коммутаторами, которые не поддерживают объединение меток, но используются в качестве LSR. Предположим далее, что маршрут L3 шаг-за-шагом для адресного префикса X имеет вид <R1, R2, R 3, R4>, и что пакеты, адресованные X, могут войти в сеть через любой из этих LSR. Так как здесь нет возможности реализовать схему мультиточка-точка, LSP должны быть реализованы как VC точка-точка, что означает необходимость трех таких VC для адресного префикса X: <R1, R2, R3, R4>, <R2, R3, R4> и <R3, R4>. Следовательно, если R1 и R2 являются MPLS-партнерами, и любой из них является LSR, который реализован с использованием обычного коммутирующего оборудования ATM (т.e., без подавления перекрытия ячеек), или по какой то иной причине не способен осуществлять объединение меток, используемая схема MPLS между R1 и R 2 должна быть одной из следующих: 1. <PulledConditional, RequestOnRequest, RequestRetry, ReleaseOnChange, *> Это рассылка меток “вниз по течению по запросу” с упорядоченным управлением (инициируемым со стороны входа), консервативным режимом удержания меток и опционным детектированием маршрутных петель. Использование процедуры RequestOnRequest вынудит R4 послать R3 три метки для X; R3 пошлет R22 метки для X, а R2 пошлет одну метку R1 для X. 2. <PulledUnconditional, RequestOnRequest, N/A, ReleaseOnChange, UseImmediate> Это рассылка меток “вниз по течению по запросу” с независимым управлением, консервативным режимом удержания меток и без детектирования петель. 3. <PulledUnconditional, RequestOnRequest, N/A, ReleaseOnChange, UseIfLoopNotDetected> Это рассылка меток “вниз по течению по запросу” с независимым управлением, консервативным режимом удержания меток и с детектированием петель. 4.2.3. Соображения совместимости Легко видеть, что некоторые пятерки не образуют жизнеспособных схем MPLS. Например: - <PulledUnconditional, RequestNever, *, *, *> <PulledConditional, RequestNever, *, *, *> В этих схемах MPLS, нижестоящий LSR Rd пересылает ассоциации меток вышестоящему LSR Ru только по запросу от Ru, но Ru никогда не делает таких запросов. Очевидно, эти схемы нежизнеспособны, так как они не способны осуществлять корректную рассылку ассоциаций меток. - <*, RequestNever, *, *, ReleaseOnChange> В этих схемах MPLS, Rd аннулирует ассоциации, если он их не использует, но он никогда не запрашивает их снова, даже если они ему позднее понадобятся. Эти схемы, таким образом, не гарантируют того, что ассоциации меток будут разосланы корректно. В этом разделе специфицируются правила предотвращения того, чтобы партнеры по рассылке меток выбирали процедуры, которые ведут к недопустимым схемам MPLS. Эти правила требуют либо обмена информацией между партнерами по рассылке меток во время инициализации системы, либо априорного знания (полученного каким-то методом, который находится за пределами рассмотрения данного документа). 1. Каждый субъект должен объявить, поддерживает ли он объединение меток. 2. Если Rd не поддерживает объединение меток, Rd должен выбрать либо процедуру PulledUnconditional, либо PulledConditional. Если Rd выбирает PulledConditional, Ru вынужден использовать процедуру RequestRetry. То есть, если нижестоящий LSR не поддерживает объединения меток, его предпочтения имеют приоритет, при выборе схем MPLS. 3. Если Ru не поддерживает объединение меток, а Rd поддерживает, Ru должен выбрать процедуру RequestRetry или RequestNoRetry. Это вынуждает Rd использовать соответственно процедуру PulledConditional или PulledUnConditional. То есть, если только один из LSR не поддерживает объединение меток, его предпочтения имеют приоритет, при выборе схем MPLS. 4. Если как Ru, так и Rd поддерживают объединение меток, тогда выбор между свободным и консервативным режимами удержания меток остается за Ru. То есть, Ru предоставляется выбрать либо использование RequestWhenNeeded/ReleaseOnChange (консервативный), или использовать RequestNever/NoReleaseOnChange (свободный). Однако, выбор push либо pull и "условный" либо "безусловный" принадлежит Rd. Если Ru выбирает свободный режим удержания меток, Rd может выбрать либо PushUnconditional, либо PushConditional. Если Ru выбирает консервативный режим удержания меток, Rd может выбрать PushConditional, PulledConditional или PulledUnconditional. Такой выбор определяет использование схемы MPLS . 5. Соображения безопасности Некоторые маршрутизаторы могут реализовать безопасные процедуры, которые зависят от заголовка сетевого уровня, положение которого фиксировано по отношению к заголовку канального уровня. Базовая инкапсуляция MPLS подразумевает введение прослойки между заголовком канального и сетевого уровня. Это может вызвать отказ в работе некоторых процедур безопасности. Метка MPLS имеет свое значение благодаря соглашению между LSR, который записывает метку в стек (источник метки), и LSR, который интерпретирует метку (получатель метки). Если помеченный пакет получен от непроверенного отправителя, или если некоторая метка получена от LSR, которому она не посылалась, тогда пакеты могут маршрутизоваться некорректным образом. 6. Ссылки [MPLS-ATM] Davie, B., Lawrence, J., McCloghrie, K., Rekhter, Y., Rosen, E., Swallow, G. and P. Doolan, "MPLS using LDP and ATM VC Switching", RFC 3035, January 2001. [MPLS-BGP] "Carrying Label Information in BGP-4", Rekhter, Rosen, Work in Progress. [MPLS-CR-LDP] "Constraint-Based LSP Setup using LDP", Jamoussi, Editor, Work in Progress. [MPLS-FRMRLY] Conta, A., Doolan, P. and A. Malis, "Use of Label Switching on Frame Relay Networks Specification", RFC 3034, January 2001. [MPLS-LDP] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and B. Thomas, "LDP Specification", RFC 3036, January 2001. [MPLS-RSVP-TUNNELS] "Extensions to RSVP for LSP Tunnels", Awduche, Berger, Gan, Li, Swallow, Srinvasan, Work in Progress. [MPLS-SHIM] Rosen, E., Rekhter, Y., Tappan, D., Fedorkow, G., Farinacci, D. and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001. [MPLS-TRFENG] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M. and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999.  |
