Процедуры распределения и обработки маркеров. В дальнейшем рассматривается случай (способ) распределения (доставки) маркеров 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-поле заголовка сетевого уровня.

 








Дата добавления: 2016-04-11; просмотров: 580;


Поиск по сайту:

При помощи поиска вы сможете найти нужную вам информацию.

Поделитесь с друзьями:

Если вам перенёс пользу информационный материал, или помог в учебе – поделитесь этим сайтом с друзьями и знакомыми.
helpiks.org - Хелпикс.Орг - 2014-2024 год. Материал сайта представляется для ознакомительного и учебного использования. | Поддержка
Генерация страницы за: 0.019 сек.