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

Процедурная и логическая характеристики LDP-протокола представлены в RFC-3031 и RFC-5036. Рассматриваемый ниже способ распределения и обра­ботки маркера «нисходящий поток по требованию» (downstream-on-demand) дол­жен использоваться FR/LSR-коммутаторами, которые не поддерживают функ­цию слияния (объединения) VC-соединений (этот способ используется для доставки трафика с поузловой маршрутизацией).

Функционирование граничного LSR-маршрутизатора

Рассмотрим функционирование граничного LSR-маршрутизатора из группы граничных LSR-маршрутизаторов, входящих в сетевой FR/LSR-сегмент. Предположим, что в результате его маршрутных вычислений он выбрал FR/LSR-коммутатор в качестве следующего РУ некото­рого маршрута (FEC-класс), и что следующий РУ подключён через LC/FR-интерфейс. Будем считать, что на противополож­ной стороне следующего РУ расположен FR/LSR-коммута­тор, который является участником (одной из сторон) информационного взаимодействия по LDP-протоколу (LDP-peer). Граничный LSR-маршрутизатор отправляет LDP-запрос (request) LSR_НП для привязки маркера к следующему РУ. Когда этот граничный LSR-маршрутизатор полу­чает ответ от LSR_НП (LDP-сообщение «отображение», mapping), в котором содер­жится информация о привязке маркера, он сохраняет маркер в соответствую­щей БД (Label Information Base, LIB) в качестве выходного мар­кера для данного FEC-класса. Принятое LDP-сообщение «отображение» может включать поле «счётчик РУ», содержащее число РУ, на которое следует уменьшить TTL-значение по­сле прохождения IP-пакетом сетевого FR/LSR-сегмента до выходного FR/LSR-коммутатора при использовании данного маркера. Такая информация может хра­ниться для последующих расчётов TTL-значений. После того, как всё это будет выполнено, LSR-маршрутизатор может использовать MPLS-коммутацию для трансляции IP-пакетов данного FEC-класса.

Когда граничный LSR-маршрутизатор из группы граничных LSR-маршрутиза­торов, входящих в сетевой FR/LSR-сегмент, получает LDP-запрос от FR/LSR-коммутатора в интересах определённого FEC-класса, это означает, что данный граничный LSR-маршрутизатор является выходным FR/LSR-ком­мутатором. По получении LDP-запроса, он формирует и сохраняет маркер, т.е. делает новую запись в своей LIB-базе и помещает в неё (в специальное поле «вхо­дящий маркер») этот маркер. После этого, данный LSR-маршрутизатор отправ­ляет ответное LDP-со­общение («отображение»), содержащее сформирован­ный маркер, назад по направлению восходящего потока противопо­ложной стороне сквозного LDP-соединения, передавшей запрос. Ответ­ное LDP-сообще­ние («отображение») содержит поле «счётчик РУ» со значением «1».

Когда в результате маршрутизационных вычислений граничному LSR-мар­шрутизатору необходимо изменить следующий РУ маршрута, а предыдущий РУ находился в сетевом FR/LSR-сегменте, граничный LSR-маршрутизатор должен оповестить противопо­ложную сторону предыдущего РУ (с помо­щью LDP-сообщения «разъединение», release), что данные о привязке маркера, относительно данного маршрута, больше не нужны.

Когда FR/LSR-коммутатор получает LDP-запрос (сообщение «запрос») в инте­ресах определённого маршрута (FEC-класса) от противоположной стороны LDP-соединения, установленного с этим FR/LSR-коммутатором через LC/FR-интерфейс, тогда FR/LSR-коммутатор выполняет следующие действия:

- формирует и сохраняет маркер, т.е. делает новую запись в своей LIB-базе и помещает в неё (в специальное поле «входящий маркер») этот маркер;

- направляет LDP-сообщение «запрос» LSR-маршрутизатору, расположен­ному на противоположной стороне следующего РУ, по направлению нисходящего потока для данного маршрута (FEC-класса).

В режиме «регулируемого управления LSP-маршрутом» (RFC-3031) FR/LSR-комму­татор будет ожидать команду на отправку своего «запроса», на который он в последствие получит ответ от LSR_НП, содержащий сообщение «ото­бражение», прежде чем отправит ответное сообщение «отображение» LSR_ВП на запрос последнего. В данном случае FR/LSR-комму­татор уменьшит на единицу число РУ, полученное от LSR_НП, и будет использовать это значение в ответных сообщениях «отображение», направляе­мых LSR_ВП.

В качестве альтернативы, FR/LSR-комму­татор может направить LSR_ВП дан­ные о привязке маркера, не дожидаясь получения данных о привязке мар­кера от LSR_НП (режим «управления LSP-маршрутом»). В этом случае, FR/LSR-комму­татор использует зарезервированное значение числа РУ в отправляемом сообщении «отображение», указывая в последнем, что это число ему не известно. Корректное значение числа РУ будет отправлено позднее, как это определено ниже.

Так как оба режима управления LSP-маршрутом (регулируемое и независи­мое) имеют свои преимущества и недостатки, то право выбор режима остаётся за конкретной реализацией системы или субъектом настройки парамет­ров системы.

После того, как FR/LSR-комму­татор получит от противоположной сто­роны следующего РУ ответное LDP-сообще­ние («отобра­жение»), он размещает маркер потока в специальном поле «исходящий маркер» LIB-записи.

Следует заметить, что FR/LSR-комму­татор или граничный LSR-маршру­тиза­тор из группы граничных LSR-маршрутизаторов, входящих в сете­вой FR/LSR-сегмент, может получить несколько запросов на данные о привязке для одного и того же маршрута (FEC-класса) от одного и того же FR/LSR-ком­му­татора. Тогда он должен сформировать новое ответное сообщение «отображе­ние» с маркером потока для каждого запроса (полагая, что для этого достаточно ресурсов) и сохранить любой(ые) существующей(ие) маркер(ы) по­тока. Также целесообразно, чтобы FR/LSR-ком­му­татор для каждого получен­ного запроса сформировал новый запрос на данные о привязке к следующему РУ маршрута (FEC-класса).

Когда в результате маршрутизационных вычислений FR/LSR-ком­му­та­тору необходимо изменить следующий РУ маршрута (FEC-класса), FR/LSR-коммутатор должен оповестить противоположную сто­рону предыдущего РУ (с помощью LDP-сообщения «разъе­динение»), что данные о привязке маркера, относительно данного мар­шрута, больше не нужны.

Когда LSR-маршрутизатор получает извещение о том, что соответствую­щие данные о привязке маркера больше не нужны, он может открепить маркер от FEC-класса, а саму привязку уничтожить. Этот режим называется «консерватив­ным режимом сохранения маркера потока» (RFC-3031). Там, где LSR-маршрутизатор получает извещение и уничтожает привязку, ему целесообразно оповестить противоположную сто­рону следующего РУ, что данные о привязке маркера больше не нужны. Если же LSR-маршрутизатор не уничтожает привязку мар­кера потока (FR/LSR-коммутатор функционирует в «свободном режиме сохране­ния маркера потока»), то он может повторно использовать эту привязку, но только тогда, когда он получит запрос относи­тельно одного и того же маршрута и с одним и тем же значением счётчика РУ, как если бы он получил запрос от противополож­ной стороны РУ на формирование привязки маркера потока.

При изменении маршрута, привязки маркеров потока должны повторно фор­мироваться, причём с той точки, в которой «уклонился» от предыдущего маршрута. LSR_ВП в такой точке «не обращает внимание» на произошедшее измене­ние (за одним исключением, рассмотренным ниже). Всякий раз, когда LSR-маршрутизатор изменяет свой следующий РУ соответ­ствующего маршрута, и если на его противоположной стороне разме­щён FR/LSR-коммутатор или граничный LSR-маршрутизатор из группы гранич­ных LSR-маршрутизаторов, подключённый через LC/FR-интерфейс, то для каждой своей LIB-записи, относящейся к маршруту, LSR-маршрутизатор должен отправить запрос (используя LDP-соединение) на получение данных о привязке от противоположной стороны нового РУ.

Когда FR/LSR-коммутатор получает данные о привязке маркера от сосед­него LSR_НП, он возможно уже имеет подготовленный соответствующий маркер для данного маршрута до соседнего LSR_ВП. Это может быть следствием, либо того, что FR/LSR-коммутатор функционирует в режиме независимого управле­ния LSP-маршрутом, либо того, что данные о новой привязке маркера, получен­ные от LSR_НП, являются результатом изменения маршрута. В таком случае, целесо­образно извлечь из данных о новой привязке маркера значение счётчика РУ и увеличить его на единицу. Если новое значение счётчика РУ отличается от того, которое было ранее отправлено соседнему LSR_ВП (включая случай, когда соседний LSR_ВП получил значение «не известно»), FR/LSR-коммутатор обязан сообщить об этом измене­нии соседнему LSR_ВП. Каждый FR/LSR-коммутатор в последовательности LSP-маршрута увеличивает значение счётчика РУ и отправ­ляет его LSR_ВП, причём до тех пор, пока оно не достигнет входного гранич­ного LSR-маршрутизатора.

Всякий раз, когда FR/LSR-коммутатор направляет запрос на данные о при­вязке маркера LSR-маршрутизатора на противоположной стороне следую­щего РУ, вследствие приёма запроса на данные о при­вязке маркера от другого LSR_ВП, и этот отправленный LSR-маршрутизатору на противоположной стороне следующего РУ не был удовле­творён, FR/LSR-коммутатор, в ответ на принятый запрос, должен уничто­жить сформированную привязку и проинформировать об этом запрашиваю­щую сторону, используя для этого LDP-сообщение «изъятие» (with­draw).

Когда LSR-маршрутизатор установит, что LDP-соединение с другим LSR-маршрутизатором прервано, он выполняет следующие действия:

§ обязан уничтожить любые данные о привязке, полученные по этому соедине­нию;

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

Эффективное использование диапазона маркеров — функция

слияния, реализуемая FR/LSR-коммутаторами

Ранее предполагалось, что граничный LSR-мар­шрути­за­тор будет запрашивать по одному маркеру потока для каждого пре­фикса из своей маршрутной таблицы, который отображает следующий РУ в сетевом FR/LSR-сегменте. Фактически, имеется возможность существенно уменьшить необходимое число маркеров за счёт исполь­зования одного маркера для нескольких маршрутов вместо запроса гранич­ного LSR-мар­шрутиза­тора. Использование сходящихся (many-to-one) отобра­жений между маршрутами (префиксы IP-адресов) и маркерами на основе FEC-классов позволяет (представляет собой способ) уменьшить/сохранить число используе­мых маркеров.

Следует заметить, что уменьшение диапазона маркеров (объединение VC-соединений) может быть ограничено в том случае, когда последователь­ность кадров (трафик) требует FR-фрагментации. Проблема в том, что FR-фраг­менты должны передаваться последовательно, т.е. фрагменты разных кадров не должны быть перемежающимися. Если FR/LSR-коммутатор, реализующий функ­цию фрагментации, гарантирует, что передача последовательности всех фрагментов кадра будет осуществляться без перемежения с фрагментами дру­гих кадров, то можно говорить об уменьшении (сохранении) числа маркеров (объединение VC-соединений).

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

В случае уменьшения (сохранения) числа маркеров, и если изменения в мар­шрутной таблице «вынуждают» FR/LSR-коммутатор выбрать новый РУ для одного из своих FEC-классов, то он может удалить при­вязку этого маршрута от «старого» РУ. Если же FR/LSR-коммутатор ещё не имеет данных о соответствующей привязке для но­вого РУ, то он обязан их запросить (необходимо заме­тить, что выбор нового РУ зависит от режима сохране­ния маркера потока, RFC-3031).

Если данные о новой привязке получены, и они включают значение счёт­чика РУ, отличающееся от значения в старых данных о привязке, то FR/LSR-коммутатор обязан выполнить следующие действия:

· увеличить это значение на единицу, если оно не является «неизвестным»;

· уведомить о новом значении счётчика РУ сосед­ние LSR_ВП, которые имеют привязки маркеров для этого FEC-класса.

Для обеспечения гарантированного обнаружения петлевых маршрутов, в слу­чае, когда новое значение счётчика РУ превысило «максимальное» значение, соответствующие маркеры для данного FEC-класса должны быть отозваны у всех соседних LSR_ВП, которым ранее высылались дан­ные о привязке этих маркеров.

LDP-сообщения для FR-сетей

LDP-сообщения, которыми обмениваются два FR/LSR-коммутатора, являю­щиеся взаимодействующими сторонами LDP-соединения, могут содер­жать специализированную информацию в интересах FR-сетей. К такой информа­ции относится:

1. диапазон FR-маркеров (Frame Relay Label Range). На рис. 35.8 представлен фор­мат блока данных «диапазон FR-маркеров», который включает следую­щие поля:

§ «зарезервировано». Эти поля являются резервными. Они должны запол­няться нулями при передаче и игнорироваться при приёме;

§ «длина». Это поле определяет число бит DLCI-идентификатора. Оно мо­жет принимать следующие значения:

a. «0» — 10-битовый DLCI-идентификатор;

b. «2» — 23-битовый DLCI-идентификатор;

c. «1» и «3» — зарезервированы для будущего использования;

§ «минимальное значение DLCI-идентификатора» (Minimum DLCI). Это 23-битовое поле содержит двоичное значение нижней границы диапа зона DLCI-идентификаторов, которое поддерживается FR/LSR-комму­тато­ром. Минимальное значение DLCI-идентификатора должно пра­вильно размещаться в этом поле, а все предшествующие биты должны быть нулевыми;

§ «максимальное значение DLCI-идентификатора» (Maximum DLCI). Это 23-битовое поле содержит двоичное значение верхней границы диапа­зона DLCI-идентификаторов, которое поддерживается FR/LSR-комму­татором. Максимальное значение DLCI-идентификатора должно пра­вильно размещаться в этом поле, а все предшествующие биты должны быть нулевыми;

Рис. 35.8. Формат блока данных «диапазон FR-маркеров»

2. объединение VC-соединений в FR-сети (Frame Relay Merge). Данная информа­ция необходима для определения функциональности FR/LSR-ком­му­татора: способен ли он объединять VC-соединения или нет. На рис. 35.9 представлен формат блока данных «объединение VC-соединений в FR-сети», который включает следующие поля:

§ «зарезервировано». Это поле является резервными. Оно должно запол­няться нулями при передаче и игнорироваться при приёме;

§ «объединение VC-соединений» («М»). Это 1-битовое поле определяет функ­циональность FR/LSR-ком­му­татора. Оно может принимать следую­щие значения:

a. «0» — FR/LSR-ком­му­татор не способен объединять VC-соединения;

b. «1» — FR/LSR-ком­му­татор способен объединять VC-соединения;

FR-LSR-коммутатор, который способен объединять VC-соединения, обя­зан гарантировать, что фрагментируемые кадры с входящими DLCI-идентифи­каторами не будут перемежаться на выходе с фрагментами кад­ров, имеющих иные исходящие DLCI-идентификаторы;

3. маркер в FR-сети (Frame Relay Label). На рис. 35.10 представлен формат блока данных «маркер в FR-сети», который включает следующие поля:

§ «зарезервировано». Это поле является резервными. Оно должно запол­няться нулями при передаче и игнорироваться при приёме;

§ «длина». Это поле определяет число бит DLCI-идентификатора. Оно мо­жет принимать следующие значения:

a. «0» — 10-битовый DLCI-идентификатор;

b. «2» — 23-битовый DLCI-идентификатор;

c. «1» и «3» — зарезервированы для будущего использования;

§ «DLCI-идентификатор». Это двоичная величина FR-маркера. Соответст­вующее число бит (10 или 23) значения маркера отображают DLCI-идентификатор, который является часть заголовка FR-кадра каналь­ного уровня.

Рис. 35.9. Формат блока данных «объединение VC-соединений в FR-сети»

Рис. 35.10. Формат блока данных «объединение VC-соединений в FR-сети»

MPLS-архитектура описывает способ применения ATM-коммутаторов в качестве LSR-маршрутизаторов. ATM-коммута­торы реализуют алгоритмы мар­шрутизации сетевого уровня (например, OSPF, IS-IS и др.), и по результатам выполнения этих алгоритмов они транслируют поступившие в них данные. Нет необходимости в использовании какой-либо специализированной ATM-систе­мы маршрутизации или адресации. ATM-ком­мута­торы, используемые таким образом, именуются ATM/LSR-коммута­торами.

В дальнейшем используются следующие термины и определения.

LC/ATM-интерфейс (label switching controlled ATM interface) — ATM-ин­терфейс, управляемый программным MPLS-модулем. IP-пакет, доставляе­мый через LC/ATM-интерфейс, интерпретируется как помеченный пакет. Верхний маркер набора маркеров в IP-пакете извлекается, либо из содержания VCI-поля (VC-идентификатор), либо из совместного содержания VPI- (VPI-идентифика­тор) и VCI-полей (Virtual Path, виртуальный маршрут). Две любые стороны, взаимодействующие по LDP-соединению через LC/ATM-интерфейс, будут ис­пользовать LDP-процедуры для согласования и определения, какой из этих двух вариантов извлечении маркера потока применим для данного интерфейса.

ATM/LSR-коммутатор (ATM-LSR) — LSR-маршру­тиза­тор, имеющий один или более LC/ATM-интерфейсов, и который транслирует ATM-ячейки между двумя такими же интер­фейсами, используя для этого маркеры потока, расположенные в VPI/VCI-полях, и без повторной сборки ATM-ячеек в кадры перед отправкой.

LSR/frame-коммутатор (frame-based LSR) — LSR-маршру­тиза­тор, кото­рый транслирует между своими интерфейсами кадры канального уровня* без фрагментации («целиком»). Следует отметить, что такой LSR-маршру­тиза­тор не иметь и иметь один или более LC/ATM-интерфейсов.

Иногда сетевой программно-аппаратный модуль может функционировать как ATM/LSR-коммута­тор, что касается некоторых пар интерфейсов, но может функционировать и как LSR/frame-коммутатор, что касается других пар интер­фейсов. Например, ATM-коммутатор с интерфейсом Ethernet-сети может функ­ционировать как ATM/LSR-коммута­тор при доставке ячеек между своими LC/ATM-интерфейса­ми, но может функционировать и как LSR/frame-коммута­тор при доставке кадров канального уровня между его Ethernet- интерфейсом и одним или несколькими LC/ATM-интерфейса­ми. В таких случаях, можно счи­тать, что в одном сетевом модуле реализованы две функции (ATM/LSR- и LSR/frame-коммута­торы).

Предполагается, что LC/ATM-интерфейс используется для соединения, либо двух ATM/LSR-коммута­торов, либо ATM/LSR-коммута­тора с LSR/frame-коммута­тором. Использование LC/ATM-интерфейса для соединения двух LSR/frame-коммута­торов в данном стандарте не рассматривается.

Сетевой ATM/LSR-сегмент (ATM-LSR domain) — совокупность ATM/LSR-коммутаторов, которые взаимодействуют между собой через LC/ATM-интерфейсы.

Граничные LSR/frame-коммута­торы сетевого ATM/LSR-сегмента (edge set of ATM-LSR domain) — совокупность LSR/frame-коммута­торов, которые со­единены с сетевым ATM/LSR-сегментом через LC/ATM-интерфейсы. LSR/frame-коммута­тор, который входит в совокупность граничных LSR/frame-коммута­торов сетевого ATM/LSR-сегмента может именоваться граничным LSR-маршру­тиза­тором.

Слияние VC-соединений (VC-merge) — процесс (процедура), с помощью которого коммутатор принимает ячейки по нескольким входным интерфейсам с определёнными VCI-идентификаторами и транслирует их через один выходной интерфейс с определённым VCI-идентификатором, не допуская при этом пере­межения ячеек, сформированных из блоков данных различных протоколов на AAL5-уровне адаптации (ATM Adaptation Layer 5).