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

Предположим, что LSR-маршру­тиза­тор привязал к соответствующему FEC-классу несколько входящих маркеров. При доставке IP-пакетов, принадлежащих одному FEC-классу, последний мог бы иметь один исходящий маркер, который применялся бы ко всем таким IP-пакетам. Факт получения двух разных IP-пакетов, относящихся к одному FEC-классу, с различными входными маркерами вообще не рассматривается, он просто неуместен. Желательно, чтобы такие IP-пакеты доставлялись с одним и тем же исходящим маркером. Процедура, обеспечивающая сказанное выше, называется «слиянием (объединением) маркеров» (label merging).

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

Будем говорить, что LSR-маршру­тиза­тор не способен реализовывать про­цедуру слияния маркеров, если им были получены любые два IP-пакета из разных входных интерфейсов или с различными маркерами, то он должен отправить их по разным интерфейсам или с различными маркерами. ATM/LSR-маршру­тиза­торы, использующие кодирование коммутируемых виртуальных соединений или маршрутов, не способны осуществить процедуру слияния маркеров.

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

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

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

LSR-маршру­тиза­торы с функцией и без функции слияния маркеров

MPLS-процедуры доставки очень похожи на процедуры доставки, которые реализуются в АТМ- и FR-сетях. Т.е., при поступлении протокольного элемента данных осуществляется поиск маркера (VPI/VCI- или DLCI-идентифи­­катора) в таблице связности («cross-connect table»), по итогам такого поиска выбирается выходной интерфейс и перезаписывается значение маркера. Фактически, такие способы доставки данных можно использовать в MPLS-системах. А LDP-протокол можно использовать в качестве протокола сигнализации (signaling protocol) в процедуре настройки таблиц связности.

К сожалению, эти способы делают не нужной процедуру слияния маркеров. Если в АТМ-сетях попытаться осуществить слияние маркеров, то в результате может последовать чередование ячеек с различными IP-пакетами. А если ячейки с различными IP-пакетами стали чередоваться, то в такой ситуации просто невозможно осуществить повторную сборку IP-пакетов. НекоторыеFR-коммутаторы совмещают FR- и АТМ-коммутацию (коммутацию ячеек) на основе своих объединённых плат (задних панелей, backplane). Такие коммутаторы могут быть также не способны реализовывать процедуру слияния маркеров, причём по той же самой причине — чередование ячеек с различными IP-пакета­ми и отсутствие, в таких условиях, способа повторной сборки IP-пакетов.

Предлагается два решения данной проблемы. Во-первых, MPLS-система будет реализовывать процедуры, которые позволяют использовать LSR-марш­ру­­тиза­торы без функции слияния маркеров. Во-вторых, MPLS-система будет реализовывать процедуры, которые позволяют использовать определённые АТМ-коммутаторы, функционирующие как LSR-марш­ру­­тиза­торы.

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

Маркеры для LSR-маршру­тиза­торов с функцией и без функции

слияния маркеров

LSR_ВП с функцией слияния маркеров требует, чтобы ему был передан всего лишь один маркер для одного FEC-класса. Соседний LSR_ВП без функции слияния маркеров требует, чтобы ему был передано несколько маркеров для одного FEC-класса. Однако не существует способа предварительного определения числа маркеров, которые ему необходимы. Это зависит от числа LSR-марш­ру­­тиза­торов, являющихся LSR_ВП, которые обрабатывают трафик соответствующего FEC-класса.

MPLS-архитектура устанавливает, что если некоторый соседний LSR_ВПне реализует процедуру слияния маркеров, то ему не будут передаваться какие-либо маркеры соответствующего FEC-класса до тех пор, пока он недвусмысленно запросит маркер для этого FEC-класса. Соседний LSR_ВП может направить несколько таких запросов, и при этом каждый раз получать новый маркер. Когда соседний LSR_НП получает такой запрос от LSR_ВП, и при этом соседний LSR_НП не обладает функцией, то он должен в свою очередь запросить свой соседний LSR_НП относительно другого маркера для соответствующего FEC-клас­са.

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

Является ли процедура слияния маркеров применимой к LSP-марш­руту на основе явной маршрутизации? Этот вопрос требует дальнейшего исследования.

Процедура слияния маркеров в АТМ-сетях

Методы предотвращения чередования ячеек. Существует несколько методов решения проблемы чередования ячеек в АТМ-системах, которые позволяют АТМ-коммутаторам реализовать процедуру слияния маркеров:

1. слияние маркеров в рамках виртуального маршрута с использованием кодирования коммутируемого виртуального маршрута с групповой адресацией. Если используется слияние маркеров в рамках виртуального маршрута, то несколько виртуальных объединяются в один виртуальный маршрут, но при этом IP-пакеты из различных источников распознаются на основе проверки различных значений VCI-идентификаторов в пределах конкретного виртуального маршрута;

2. слияние маркеров виртуальных соединений. Если используется слияние маркеров виртуальных соединений, то необходимы маршрутизаторы, которые накапливают ячейки для одного IP-пакета, причём до тех пор, пока не будет получен весь IP-пакет (это можно определить, используя процедуру поиска индикатора окончания кадра на AAL5-уровне адаптации).

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

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

Функциональная совместимость: реализуется процедура слияния маркеров, либо в рамках виртуального маршрута, либо виртуальных соединений, или процедура не реализуется. Функциональная совместимость при использовании различных процедур слияния маркеров в АТМ-сети определяется весьма просто, во-первых, путём определения совместимости режима использования процедуры слияния маркеров виртуальных соединений с режимом отсутствия такой процедуры.

Если сетевые узлы, использующие и не использующие процедуру слияния маркеров виртуальных соединений, взаимосвязаны, то во всех случаях доставка АТМ-ячеек основана организации виртуальных соединений (т.е. VPI- и VCI-идентификаторы используются в режиме «сцепления», concatenation). Для каждого сетевого узла, если соседний АТМ/LSR_ВП реализует процедуру слияния маркеров виртуальных соединений, то данный «сосед» запрашивает только одиночную пару VPI/VCI-идентификаторов для соответствующего потока (т.е. по аналогии с запросом одиночного маркера потока в случае FR-сети). Если же соседний АТМ/LSR_ВП не реализует процедуру слияния маркеров, то он запрашивает только одну пару VPI/VCI-идентификаторов для каждого потока в собственных интересах, и дополнительно — необходимое число VPI/VCI-иден­тификаторов для передачи своим соседним АТМ/LSR_ВП. Требуемое число VPI/VCI-идентификаторов будет определяться количеством АТМ/LSR_ВП, которым разрешено запрашивать дополнительные VPI/VCI-идентификаторы от своих соседних АТМ/LSR_НП (т.е. опять аналогично методу, используемому при слиянии маркеров в FR-сетях).

Аналогичный метод может использоваться и сетевыми узлами, которые реализуют процедуру слияния маркеров в рамках виртуального маршрута. В этом случае сетевой узел, реализующий процедуру слияния маркеров в рамках виртуального маршрута, скорее всего, затребует одиночный виртуальный маршрут (определяемый своим VPI-идентификатором) вместо нескольких VCI-идентификаторов в рамках виртуального маршрута, и не будет запрашивать одиночный или несколько VPI/VCI-идентификаторов от своих соседних АТМ/LSR_НП. Более того, предположим, что сетевой узел, не реализующий процедуру слияния маркеров, является нисходящим узлом относительно двух разных узлов, реализующих процедуру слияния маркеров в рамках виртуального маршрута. Такому сетевому узлу может понадобиться запросить один VPI/VCI-идентификатор (для трафика, отправляемого им самим) и два VPI-иден­ти­фи­ка­то­ра (по одному для каждого АТМ/LSR_ВП), каждый из которых связан с определённым набором VCI-идентификаторов (так как запрашиваются АТМ/LSR_ВП).

Для того, что бы обеспечить одновременное функционирование всех режимов работы (слияние маркеров в рамках виртуального маршрута, виртуальных соединений и без слияния маркеров), дополнительно следует разрешить АТМ/LSR_ВП запрашивать совокупность (от нуля и более) VCI-идентификаторов (состоящих из VPI/VCI-идентификаторов), совокупность (от нуля и более) виртуальных маршрутов (определяемых VPI-идентификаторами), причём каждый будет включать определённое число виртуальных соединений (определяемых совокупностью VCI-идентификаторов, которые, в свою очередь, указывают на виртуальный маршрут). Более того, сетевые узлы, реализующие процедуру слияния маркеров в рамках виртуального маршрута, могли бы запросить один виртуальный маршрут, содержащий VCI-идентификатор, по которому транслируется трафик (если необходимо), а также VCI-идентификатор для каждого виртуального соединения, запрошенных «сверху» (не обращая внимания на то, является или не является виртуальное соединение частью виртуального маршрута). Сетевой узел, реализующий процедуру слияния маркеров виртуальных соединений, мог бы запросить только один VPI/VCI-иден­тифи­ка­тор (так как такие узлы могут реализовать процедуру слияния маркеров всего восходящего трафика в одно виртуальное соединение). Сетевые узлы, не реализующие процедуру слияния маркеров, могли бы направить любые запросы, которые они получат «сверху», а также запрос VPI/VCI-иден­тифи­ка­тора трафика, который они ретранслируют (если необходимо).

Туннели и иерархия

Иногда маршрутизатор R_u выполняет вполне конкретную процедуру по определению, какой IP-пакет должен быть доставлен на другой маршрутизатор R_d, даже если R_u и R_d не являются следующими друг за другом маршрутизаторами на поузловом маршруте доставки этого IP-пакета, а R_d не является конечным пунктом назначения этого IP-пакета. Например, это можно сделать путём вставки транслируемого пакета в IP-пакет сетевого уровня, у которого адрес по­лучателя является IP-адресом этого маршрутизатора R_d. Такая процедура формирует «туннель» (tunnel) от R_u до R_d. В дальнейшем любой пакет, прошедший такую процедуру обработки, именуется «туннелированным» (tunneled packet).

Туннель с поузловой (последовательной) маршрутизацией

Если туннелированный пакет (ТП) следует по поузловому маршруту от R_u до R_d, то такой маршрут называется «туннелем с поузловой (последовательной) маршрутизацией» (hop-by-hop routed tunnel), в котором R_u — «крайняя точка передачи» (transmit endpoint), а R_d — «крайняя точка приёма» (receive endpoint).

Туннель с точной (явной) маршрутизацией

Если ТП следует по маршруту от R_u до R_d, но отличному от поузлового маршрута, то такой маршрут называется «туннелем с точной маршрутизацией» (explicitly routed tunnel), в котором R_u — «крайняя точка передачи» (transmit endpoint), а R_d — «крайняя точка приёма» (receive endpoint). Пакет сетевого уровня можно передать по туннелю с точной маршрутизацией путём его размещения (вставки) в пакет, который был передан источником.

Туннели на основе LSP-маршрутов

Туннель можно представить как LSP-маршрут, и лучше всего использовать MPLS-коммутацию, чем размещать IP-пакет в кадре канального уровня и, таким образом, транслировать его по туннелю. Пусть туннелем будет LSP-маршрут < R₁, ..., R_n >, в котором R₁,— крайняя точка передачи в туннеле, а R_n — крайняя точка приёма в туннеле. Такой маршрут называется «LSP-туннель» (рис. 33.6).

Совокупность IP-пакетов, которая транслируется по LSP-туннелю, образует FEC-клас­с, а каждый LSR-марш­ру­­тиза­тор в туннеле обязан присваивать маркер такому FEC-клас­су (т.е. обязан присваивать маркер к туннелю). Выбор критерия, по которому соответствующий IP-пакет «закрепляется» за LSP-тун­­нелем, определяется локально в крайней точке передачи туннеля. Для того чтобы доставить IP-пакет по LSP-туннелю, в крайней точке передачи в набор маркеров вставляется маркер туннеля, а затем помеченный IP-пакет доставляется по следующему РУ туннеля.

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

нее, набор маркеров может быть полностью удалён предпоследним LSR-марш­ру­­тиза­тором в туннеле.

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

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

Иерархия: LSP-туннели в рамках LSP-маршрутов

Пусть имеет место LSP-маршрут < R₁, R₂, R₃, R₄ >. Теперь предположим, что R₁ принял непомеченный IP-пакет P и поместил в его набор маркеров свой маркер, чтобы направить его по данному маршруту. Фактически, такой маршрут является поузловым. Однако в дальнейшем полагаем, что R₂ и R₃ не имеют прямого соединения между собой, но считаются «соседями» в силу того, что являются оконечными (крайними) точками LSP-туннеля. Таким образом, реальной последовательностью LSR-марш­ру­­тиза­торов, по которым доставляется IP-пакет P, является < R₁, R₂, R₂₁, R₂₂, R₂₃, R₃, R₄ > (рис. 33.6).

Когда P следует по маршруту от R₁ до R₂, он имеет глубину набора маркеров равную 1. R₂, осуществляющий коммутацию по маркеру, определяет, что P должен следовать далее по туннелю. R₂ первым заменяет входящий маркер на маркер, который является значимым для R₃. Затем он «заталкивает» новый маркер. Этот маркер второго уровня имеет значение, которое является значимым для R₂₁. Далее коммутация осуществляется R₂₁, R₂₂ и R₂₃, с использованием маркера второго уровня. R₂₃, который является предпоследним коммутатором в туннеле R₂cR₃, перед тем, как отправить IP-пакет R₃, выталкивает набор маркеров. Когда R₃ проанализирует IP-пакет P, он установит, что в P содержится только один маркер первого уровня, что указывает на выход из туннеля. Так как R₃ является предпоследним коммутатором в LSP-маршруте первого уровня при доставке IP-пакет P, он выталкивает набор маркеров, а R₄ принимает P непомеченным.

Использование набора маркеров позволяет формировать LSP-туннели любой глубины.

Информационный обмен при доставке маркеров и иерархия

Предположим, что IP-пакет P доставляется по LSP-маршруту первого уровня < R₁, R₂, R₃, R₄ >, а когда он будет доставляться от R₂ до R₃, то будет следовать по LSP-маршруту второго уровня < R₂, R₂₁, R₂₂, R₃ >. С точки зрения LSP-маршрута второго уровня, противоположной стороной доставки (распределения) маркеров для R₂ является R₂₁. С точки зрения LSP-маршрута первого уровня, противоположными сторонами доставки (распределения) маркеров для R₂ являются R₁ и R₃. R₂ может проводить процедуры распределения маркеров с соседними коммутаторами на любом уровне иерархии. В дальнейшем будут рассмотрены некоторые способы использования такой иерархии. Следует заметить, что в представленном выше примере коммутаторы R₂ и R₂₁ должны быть соседями с точки зрения IGP-протокола, в то время как для коммутаторов R₂ и R₃ такое требование не обязательно.

Когда два LSR-марш­ру­­тиза­тора являются соседями с точки зрения IGP-протокола, то говорят, что они являются «взаимодействующими сторонами локальной процедуры распределения маркеров» (local label distribution peers). Когда два LSR-марш­ру­­тиза­тора не являются соседями с точки зрения IGP-про­токола, то говорят, что они являются «взаимодействующими сторонами при проведении удалённой процедуры распределения маркеров» (remote label distribution peers). В рассмотренном ранее примере коммутаторы R₂ и R₂₁ являются взаимодействующими сторонами локальной процедуры распределения маркеров, а коммутаторы R₂ и R₃ — взаимодействующими сторонами удалённой процедуры распределения маркеров.

MPLS-архитектура рассматривает два способа распределения (доставки) маркеров на различных уровнях иерархии: явная (точная) процедура доставки маркеров (explicit peering) и неявная процедура доставки маркеров (implicit peering).

Коммутатор (сетевой узел) проводит процедуру распределения (доставки) маркеров с другой взаимодействующей стороной (другим коммутатором, сетевым узлом) путём передачи сообщений LDP-про­то­ко­ла, которые адресованы этой стороне. Коммутатор (сетевой узел) может организовать распределение (доставку) маркеров с удалённой взаимодействующей стороной (другим коммутатором, сетевым узлом) одним из следующих двух способов:

1. явная (точная) процедура доставки маркеров. При реализации этой процедуры коммутатор (сетевой узел) доставляет маркеры взаимодействующей с ним стороне путём передачи сообщений LDP-про­то­ко­ла, которые адресованы данной стороне, причём точно так же, как если бы они были сторонами локального обмена маркерами (local label distribution peers). Этот способ наиболее приемлем там, где число удаленных сторон, которые обмениваются маркерами, — мало, или тогда, когда число привязок маркеров верхнего уровня — большое, или тогда, когда удаленные стороны, которые обмениваются маркерами, расположены в определённых маршрутизационных областях или сегментах. Естественно, коммутатору необходимо знать, какие маркеры и каким сторонам следует доставлять;

2. неявная процедура доставки маркеров. При реализации этой процедуры коммутатор (сетевой узел) не передаёт взаимодействующей с ним стороне сообщения LDP-про­то­ко­ла, которые адресованы данной стороне. Вероятнее всего, для доставки маркеров верхнего уровня другим удалённым сторонам обмена маркерами, коммутатор (сетевой узел) кодирует маркер верхнего уровня как атрибут маркера нижнего уровня, и затем транслирует маркер нижнего уровня, вместе с атрибутом, другим взаимодействующим с ним локальным сторонам обмена маркерами. После этого, локальные стороны (коммутаторы и/или сетевые узлы) обмена маркерами распространяют информацию о своих локальных сторонах обмена маркерами. Этот процесс продолжается до тех пор, пока информация не достигнет удалённой стороны обмена маркерами.

Этот способ наиболее приемлем там, где число удалённых сторон обмена маркерами очень велико. Неявная доставка маркеров не требует n-связ­ной сети информационного обмена для доставки маркеров удалённым сторонам обмена маркерами, так как информация распространяется в дуплексном режиме с помощью локальных процедур обмена маркерами. Однако неявная доставка маркеров требует наличия промежуточных сетевых узлов для хранения информации, в которой они напрямую могут быть не заинтересованы.