Сети и телекоммуникации
.pdf561
Обработка маркеров потока выходными FR/LSR-коммутаторами
Когда FR-кадр достигает конечной точки LSP-маршрута, FR/LSR-комму-
татор удаляет набор маркеров. Если удалѐнный маркер был последним марке-
ром, то необходимо определить соответствующий протокол сетевого уровня,
пакет которого транслировался по LSP-маршруту. Набор маркеров не содержит информации в явной форме, по которой можно определить протокол сетевого уровня. Это должно следовать из значения маркера, который удаляется из на-
бора маркеров.
Если удалѐнный маркер не был последним маркером, то предыдущее
TTL-значение верхнего уровня набора MPLS-маркеров отображается в новой верхней записи этого набора.
Если FR/LSR-коммутатор является выходом сетевого FR-сегмента гиб-
ридного LSP-маршрута, и в тоже время конечная точка сетевого FR-сегмента не является конечной точкой LSP-маршрута, то MPLS-пакет будет обработан на основе NHLFE-записи (Next Hop Label Forwarding Entry) с целью его дальней-
шей доставки по следующему РУ LSP-маршрута (RFC-3031). Значение выход-
ного маркера также извлекается из NHLFE-записи, а TTL-значение MPLS-
системы уменьшается на соответствующую величину, зависящую от выходного интерфейса или типа ретрансляционной процедуры. Далее MPLS-пакет достав-
ляется в соответствие с MPLS-требованиями для конкретного канала связи сле-
дующего РУ (сетевого сегмента) LSP-маршрута.
Для IP-пакетов с однонаправленными адресами, TTL-значение в MPLS-
системах должно уменьшаться на единицу, если выходной интерфейс является универсальным MPLS-интерфейсом, или на число РУ следующего сетевого
ATM-сегмента неоднородного LSP-маршрута, если выходной интерфейс явля-
ется ATM-интерфейсом, не контролирующим TTL-поле (non-TTL).
Для IP-пакетов с групповой адресацией, TTL-значение в MPLS-системах должно уменьшаться на число РУ сетевого FR-сегмента, являющегося выход-
ным. Программный LDP-модуль, отвечающий за формирование LSP-маршрута,
562
обязан направлять выходному FR/LSR-коммутатору всю необходимую инфор-
мацию, касающуюся числа РУ сетевого FR-сегмента, не контролирующего
TTL-поле.
Модуль MPLS-управления для FR-сетей
Для обеспечения MPLS-коммутации FR-коммутатор обязан иметь встро-
енный модуль управления MPLS-коммутацией, который, в первую очередь, ре-
ализует процедуры распределения (размещения) и обработки маркеров потока.
Информация о привязке маркера может быть доставлена несколькими способа-
ми, одним из которых является LDP-протокол распределения маркеров потока
(RFC-5036).
Так как модуль управления MPLS-коммутацией использует информацию,
которая напрямую поступает от программных модулей маршрутизации сете-
вого уровня, это предполагает, что коммутатор выступает одной из сторон при информационном взаимодействии в соответствие с такими протоколами (на-
пример, OSPF, IS-IS).
В отдельных случаях LSR-маршрутизаторы могут использовать и другие протоколы (например, RSVP, PIM, BGP) для распространения данных о привяз-
ках маркеров. В таких случаях FR/LSR-коммутатор должен участвовать в про-
цедурах информационного взаимодействия, реализуемых в соответствие с та-
кими протоколами.
В случае, когда FR-соединения формируются с помощью, либо LDP-про-
токола, либо RSVP-протокола, либо иного протокола, без использования обыч-
ных FR-способов, предполагается, что согласуемая информация при формиро-
вании соединения (например, максимальный размер входного/выходного кадра,
запрашиваемое/подтверждаемое значение входной/выходной пропускной спо-
собности, доступное значение входной/выходной пропускной способности,
входное/выходное значение фрагментации, входная/выходная скорость переда-
чи кадров), используемая в последующем при передаче, и данные для управле-
563
ния перегрузками могут доставляться FR/LSR-коммутаторам с помощью про-
цедур информационного обмена, реализуемых в соответствие с RSVP-протоко-
лом. С учѐтом сказанного выше, считается, что FR-соединения могут формиро-
ваться и в статическом режиме. Также предполагается, что управление пере-
грузками и маркирование заголовка кадра, как результат перегрузки, могло бы осуществляться FR/LSR-коммутаторами в таком же режиме, как и при обычных
FR-соединениях. С целью имитации наилучшего функционирования маршрути-
затора в режиме «по умолчанию», т.е. параметров виртуального соединения в режиме «по умолчанию», при отсутствии LDP- и RSVP-модулей, либо иных средств, участвующих в настройке необходимых параметров, целесообразно,
чтобы значение «CIR» было нулевым, вследствие чего входной модуль управ-
ления будет устанавливать бит «DE» в значение «1» в принимаемых кадрах, но не уничтожать эти кадры.
Данные управления и о состоянии соединений, основанных на MPLS-
коммутации, могут доставляться с помощью LDP-протокола.
Обеспечение MPLS-коммутации FR-коммутатором требует согласования только кадровой синхронизации, процедуры бит-стаффинга, формата заголов-
ков, алгоритма вычисления и длины поля проверочной суммы, исключая проце-
дуры сигнализации по управлению PVC-соединением и настройку LMI-
интерфейса локального управления и сигнализации. Система сигнализации, оп-
ределяемая Рекомендацией ITU-T Q.933, для PVC- и/или SVC-соединений так-
же не требуется. Система сигнализации для PVC- и/или SVC-соединений может использоваться для PVC- и/или SVC-соединений, не предназначенных для
MPLS-коммутации (стандартная FR-коммутация), когда обе системы реализо-
ваны на одном и том же MPLS-интерфейсе.
Гибридные коммутаторы
Наличие в FR-коммутаторе модуля MPLS-управления не устраняет воз-
можности применения модуля FR-управления, описание которого представлено
564
в международных стандартах ITU-T и FRF (Frame Relay Forum). Два модуля
MPLS- и FR-управления могут функционировать независимо.
Однако чтобы обеспечить совместимость этих двух модулей, необходим всего лишь небольшой объѐм информации, например, данные о разбиении
DLCI-диапазона на поддиапазоны, доступные для каждого из этих модулей.
Процедуры распределения и обработки маркеров
Процедурная и логическая характеристики 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-сообщение «отображение» может включать поле «счѐтчик РУ», содержа-
565
щее число РУ, на которое следует уменьшить 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-базе и помещает в неѐ (в специальное поле «входящий маркер») этот маркер;
566
направляет 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-комму-
татора. Тогда он должен сформировать новое ответное сообщение «отображе-
567
ние» с маркером потока для каждого запроса (полагая, что для этого достаточно ресурсов) и сохранить любой(ые) существующей(ие) маркер(ы) потока. Также целесообразно, чтобы FR/LSR-коммутатор для каждого полученного запроса сформировал новый запрос на данные о привязке к следующему РУ маршрута
(FEC-класса).
Когда в результате маршрутизационных вычислений FR/LSR-коммута-
тору необходимо изменить следующий РУ маршрута (FEC-класса), FR/LSR-
коммутатор должен оповестить противоположную сторону предыдущего РУ (с
помощью LDP-сообщения «разъединение»), что данные о привязке маркера,
относительно данного маршрута, больше не нужны.
Когда LSR-маршрутизатор получает извещение о том, что соответствую-
щие данные о привязке маркера больше не нужны, он может открепить маркер от FEC-класса, а саму привязку уничтожить. Этот режим называется «консер-
вативным режимом сохранения маркера потока» (RFC-3031). Там, где LSR-
маршрутизатор получает извещение и уничтожает привязку, ему целесообразно оповестить противоположную сторону следующего РУ, что данные о привязке маркера больше не нужны. Если же LSR-маршрутизатор не уничтожает привяз-
ку маркера потока (FR/LSR-коммутатор функционирует в «свободном режиме сохранения маркера потока»), то он может повторно использовать эту привязку,
но только тогда, когда он получит запрос относительно одного и того же мар-
шрута и с одним и тем же значением счѐтчика РУ, как если бы он получил за-
прос от противоположной стороны РУ на формирование привязки маркера по-
тока.
При изменении маршрута, привязки маркеров потока должны повторно формироваться, причѐм с той точки, в которой «уклонился» от предыдущего маршрута. LSRВП в такой точке «не обращает внимание» на произошедшее из-
менение (за одним исключением, рассмотренным ниже). Всякий раз, когда
LSR-маршрутизатор изменяет свой следующий РУ соответствующего маршру-
та, и если на его противоположной стороне размещѐн FR/LSR-коммутатор или
568
граничный 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-сообщение
«изъятие» (withdraw).
Когда LSR-маршрутизатор установит, что LDP-соединение с другим LSR-
маршрутизатором прервано, он выполняет следующие действия:
569
обязан уничтожить любые данные о привязке, полученные по этому со-
единению;
любые данные о привязках маркеров, которые были сформированы в ре-
зультате приѐма запросов на данные о привязках маркеров от противопо-
ложной стороны соединения, могут быть уничтожены LSR-маршрутиза-
тором (последний также может открепить маркеры от FEC-классов, свя-
занные с этими привязками).
Эффективное использование диапазона маркеров — функция слияния, реализуемая FR/LSR-коммутаторами
Ранее предполагалось, что граничный LSR-маршрутизатор будет запра-
шивать по одному маркеру потока для каждого префикса из своей маршрутной таблицы, который отображает следующий РУ в сетевом FR/LSR-сегменте. Фак-
тически, имеется возможность существенно уменьшить необходимое число маркеров за счѐт использования одного маркера для нескольких маршрутов вместо запроса граничного LSR-маршрутизатора. Использование сходящихся
(many-to-one) отображений между маршрутами (префиксы IP-адресов) и марке-
рами на основе FEC-классов позволяет (представляет собой способ) умень-
шить/сохранить число используемых маркеров.
Следует заметить, что уменьшение диапазона маркеров (объединение
VC-соединений) может быть ограничено в том случае, когда последователь-
ность кадров (трафик) требует FR-фрагментации. Проблема в том, что FR-фраг-
менты должны передаваться последовательно, т.е. фрагменты разных кадров не должны быть перемежающимися. Если FR/LSR-коммутатор, реализующий функцию фрагментации, гарантирует, что передача последовательности всех фрагментов кадра будет осуществляться без перемежения с фрагментами дру-
гих кадров, то можно говорить об уменьшении (сохранении) числа маркеров
(объединение VC-соединений).
570
Если реализуется способ уменьшения (сохранения) числа маркеров, и ес-
ли 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-коммутатор ещѐ не имеет данных о соответст-
вующей привязке для нового РУ, то он обязан их запросить (необходимо заме-
тить, что выбор нового РУ зависит от режима сохранения маркера потока, RFC3031).
Если данные о новой привязке получены, и они включают значение счѐт-
чика РУ, отличающееся от значения в старых данных о привязке, то FR/LSR-
коммутатор обязан выполнить следующие действия:
увеличить это значение на единицу, если оно не является «неизвестным»;