Процедуры распределения и обработки маркеров. В дальнейшем рассматривается случай (способ) распределения (доставки) маркеров ATM/LSR-коммутаторами

В дальнейшем рассматривается случай (способ) распределения (доставки) маркеров ATM/LSR-коммутаторами, именуемый как «нисходящий поток по требованию» (downstream-on-demand). Связанные с этим способом процедуры распределения маркеров должны использоваться ATM/LSR-коммутаторами, которые не обеспечивают объединение VC-соединений, и могут использоваться ATM/LSR-коммутаторами, которые обеспечивают объединение VC-соедине­ний. Однако эти процедуры имеют некоторое отличие. Далее поочередно будут рассмотрены оба сценария. Вначале рассматривается функционирование LSR-маршру­тиза­торов, являющихся граничными в рамках сетевого ATM/LSR-сег­мента. Такие LSR-маршру­тиза­торы сами по себе не являются ATM/LSR-ком­мутаторами, а их функционирование аналогично, вне зависимости, содержит ли сетевой сегмент LSR-маршру­тиза­торы, способные обеспечить объединение VC-соединений, или нет.

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

Рассмотрим функционирование граничного LSR-маршрутизатора из группы граничных LSR-маршрутизаторов, входящих в сетевой ATM/LSR-сег­мент. Предположим, что в результате его маршрутных вычислений он выбрал ATM/LSR-коммутатор в качестве следующего РУ некото­рого маршрута (FEC-класс), и что следующий РУ подключён через LC/ATM-интерфейс. Граничный LSR-маршрутизатор использует LDP-протокол для запроса данных о привязки маркера к следующему РУ относительно опре­делённого FEC-класса. Поле «счётчик РУ» в запросе содержит значение «1». После того, как граничный LSR-маршрутизатор получит данные о привязке маркера, он может использовать процедуры MPLS-коммутации для доставки IP-пакетов определённого FEC-класса, используя для этого некоторый маркер в качестве исходящего маркера потока. (Или используя VPI/VCI-идентификатор, который соответствует определённому VCID-идентификатору, в качестве исхо­дящего маркера, если используется VCID-метод, представленный в стандарте RFC-3038.)

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

Данные о привязке маркера, полученные граничным LSR-маршрутизато­ром, могут включать поле «счётчик РУ», содержащее значение числа РУ, кото­рое будет пройдено IP-паке­том до пересечения границы сетевого ATM/LSR-сегмента при использовании этого маркера. Если счётчик РУ связан с привяз­кой маркера, то ATM/LSR-коммутатор перед тем как отправить IP-пакет дол­жен прибавить значение этого счётчика к уже имеющемуся значению в TTL-поле заголовка данного IP-пакета. В любом случае, ATM/LSR-коммутатор, пе­ред тем как отправить IP-пакет, обязан прибавить, по крайней мере, «1» к имеющемуся значению в TTL-поле заголовка этого IP-пакета.

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

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

Стандартные ATM-коммутаторы (без функции объединения

VC-соединений)

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

¨ выбирает (или формирует) маркер;

¨ запрашивает (с использованием LDP-протоко­ла) данные о привязке мар­кера относительно этого FEC-класса у противоположной стороны сле­дующего РУ;

¨ отправляет ответное сообщение (с использованием LDP-протоко­ла), содер­жащее данные о привязке, включая выбранный (сформированный) входящий маркер потока, противоположной стороне, являющейся отпра­вителем запроса.

Введём параметр — «максимальное число РУ» MAXHOP. В режиме «по умолчанию» MAXHOP имеет значение 255., но может иметь и другие настраи­ваемые значения.

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

В противном случае, как только ATM/LSR-коммутатор получает данные о привязке маркера от противоположной стороны следующего РУ, он начинает использовать этот маркер.

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

С другой стороны, ATM/LSR-коммутатор может отправить LSR_ВП ответ­ное сообщение с данными о привязке маркера, не дожидаясь ответного сооб­щения с данными о привязке маркера от LSR_НП (независимый контроль LSP-маршрута). В таком случае, ATM/LSR-коммутатор устанавливает нулевое зна­чение счётчика РУ в сообщении с данными о привязке маркера, указывая, та­ким образом, что реальное значение счётчика неизвестно. Правильное значение счётчика РУ будет передано позднее.

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

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

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

При изменении маршрута, привязки маркеров переформируются с той точки маршрута, в которой последний отличается от предшествующего мар­шрута. LSR_ВП в этой точке маршрута (за одним исключением, рассмотренным ниже) «не обращают внимание» на это изменение.

Всякий раз, когда LSR-маршрутиза­тор изменяет свой следующий РУдля некоторого FEC-класса, и если новый следующий РУ достижим через LC/ATM-интерфейс, то для каждого маркера, который привязан к этому FEC-классу и доставляется LSR_ВП, LSR-маршрутиза­тор обязан запросить данные о новой привязке маркера от противоположной стороны нового следующего РУ.

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

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

Если ATM/LSR-коммутатор получает сообщение о привязке маркера, в котором значение счётчика РУ превышает MAXHOP, то ATM/LSR-коммутатор обязан не формировать привязку маркер, и должен отправить запрашивающей стороне сообщение об ошибке.

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

§ любая информация о привязках маркеров, полученная с помощью этого LDP-соединения, должна быть уничтожена;

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

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

Предполагается, что ATM/LSR-коммутаторы (без функции объединения VC-соединений) могли бы, в большинстве случаев, функционировать в «кон­сервативном режиме сохранения маркера потока» (conservative label retention mode).

ATM-коммутаторы с функцией объединения VC-соединений

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

Когда ATM/LSR-коммута­тор с функцией объединения VC-соединений получает запрос на данные о привязке маркера к конкретному FEC-классу от LSR_ВП, и к этому моменту он не имеет данных о привязке исходящего маркера к этому FEC-классу (или запрос на такие данные ожидается), он должен отпра­вить запрос на данные о привязке противоположной стороне своего следую­щего РУ (как это он мог бы сделать, если бы не обладал фун­кцией объединения VC-соединений). Тем не менее, если он имеет данные о привязке исходящего маркера к некоторому FEC-классу, то ему не нужно отправлять запрос на такие данные LSR_НП. Вместо этого, он может просто выделить (назначить) входящий маркер и вернуть этот маркер в ответном сообщении с данными о привязке за­прашивающему LSR_ВП. Когда IP-пакеты с этим маркером (являющимся верх­ним в наборе маркеров) поступают от запрашивающей стороны, значение верх­него маркера будет замещаться значением существующего исходящего мар­кера, соответствующего одному и тому же FEC-классу.

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

Когда передаётся маркер, привязанный к восходящему потоку, значение счётчика РУ, относящееся к соответствующей привязке и переданное LSR-маршрутизатором нисходящего потока, должно увеличиваться на единицу, а результирующее значение передаётся LSR-маршрутизато­ром восходящего по­тока, как значение счётчика, относящееся к новой привязке маркера. Однако существуют два исключения:

- значение счётчика РУ, равное нулю, должно передаваться LSR-маршру­тиза­тору восходящего потока без изменений;

- если значение счётчика РУ уже равно MAXHOP, то ATM/LSR-коммута­тор обязан не отправлять данные о привязке LSR_ВП, но вместо этого он обязан отправить LSR_ВП сообщение об ошибке.

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

Когда изменение в маршрутной таблице ATM/LSR-коммута­тора с функ­цией объединения VC-соединений вынуждает его выбрать новый следующий РУ в интересах одного из обслуживаемых им FEC-классов, он, дополнительно, может аннулировать привязку к этому маршруту от бывшего следующего РУ. Если же он ещё не имеет соответствующую привязку к новому следующему РУ, то он обязан её запросить.

Если данные о новой привязке приняты, и они содержат значение счёт­чика РУ, отличающееся от принятого в данных о старой привязке, то ATM/LSR-коммута­тор обязан определить новое значение счётчика РУ, путём прибавления единицы к принятому значению, и оповестить о новом значении счётчика РУ все соседние LSR_ВП, которые имеют привязки маркеров к соответ­ствующему FEC-классу. Так же как и в случае со стандартными ATM-коммута­торами (без функции объединения VC-соединений), это позволяет доставлять новое значение счётчика РУ обратно на вход сетевого ATM/LSR-сегмента. Если в какой-либо точке LSP-маршрута значение счётчика РУ превысит MAX­HOP, то все привязки маркеров для этого LSP-маршрута, которые были ранее направлены всем соседним LSR_ВП по их соответствующим запросам, должны быть аннулированы. Последнее гарантирует, что любые петлевые маршруты, вызванные маршрутизационными изменениями, будут выявлены и блокиро­ваны.

Процедуры вставки

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

Помеченные IP-пакеты должны транслироваться с использованием пус­той (null) вставки (RFC-2684).

За исключением рассматриваемых далее случаев, при передаче помечен­ного IP-пакета через LC/ATM-интерфейс, который интерпретирует VPI/VCI-идентификатор (или VCID) как верхний маркер в наборе маркеров, этот IP-па­кет должен содержать универсальную MPLS-вставку (RFC-3032).

Если IP-пакет содержит набор маркеров с n записями, то он обязан «пере­носить» универсальную MPLS-вставку с n записями. Реальное значение верх­него маркера размещается в VPI/VCI-поле. Значение маркера в верхней записи универсальной MPLS-вставки (которая является только «пустой» (placeholder) строкой, предназначенной для заполнения) должно быть установлено в нулевое значение при передаче, и должно игнорироваться при приёме. Исходящее TTL-значение для IP-пакета, а также значение «Категория обслуживания», трансли­руются в соответствующих полях верхней записи набора маркеров универсаль­ной MPLS-вставки.

(Примечание. Если IP-пакет содержит набор маркеров только с одной за­писью, это требует наличия одиночной записи в универсальной MPLS-вставки (4 байта), даже если реальное значение маркера размещается в VPI/VCI-поле. Это делается для того, чтобы гарантировать постоянное присутствие универсальной MPLS-вставки в IP-пакете. В противном случае, не было бы возможности опреде­лить, содержит IP-пакет вставку или нет, т.е. невозможно определить наличие дополнительных записей в наборе маркеров.)

Существуют только два способа для удаления этого дополнительного поля с универсальной MPLS-вставкой, а именно:

· априорное знание того, IP-пакеты содержат только одиночный маркер (на­пример, возможно сеть поддерживает только один уровень маркеров);

· использование двух VC-соединений для одного FEC-класса, т.е. одного — для тех IP-пакетов, которые содержат только одиночный маркер, а другого — для тех IP-пакетов, которые содержат более одного маркера.

Второй способ может потребовать, чтобы имело место некоторое сред­ство сигнализации на основе LDP-протокола, которое бы оповещало, что VC-соединение предназначено только для доставки IP-пакетов с одиночным марке­ром, и не предназначено для доставки универсальной MPLS-вставки. Когда реализуется функция объединения VC-соединений, тогда можно было бы не объединять VC-соединение, по которому не доставляются IP-пакеты с универ­сальной MPLS-вставкой, с VC-соединением, по которому такие IP-пакеты дос­тавляются, или наоборот.

Несмотря на то, что оба способа разрешены, весьма сомнительно, что они имеют какое-либо практическое применение. Следует заметить, что если уни­версальная MPLS-вставка отсутствует, то исходящее TTL-значение транслиру­ется в TTL-поле заголовка сетевого уровня.