Сети и телекоммуникации
.pdf581
фейс, даже если соединение между ними проходит через «ATM-облако» (ATM-
сеть) по коммутируемым виртуальным ATM-соединениям.
Процедуры распределения и обработки маркеров
В дальнейшем рассматривается случай (способ) распределения (доставки)
маркеров 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-пакетов определѐнного
582
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».
583
Когда в результате маршрутизационных вычислений граничному 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, то запрос не должен передаваться на следующий РУ, а
584
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-коммутатор устанавливает нулевое зна-
чение счѐтчика РУ в сообщении с данными о привязке маркера, указывая, та-
ким образом, что реальное значение счѐтчика неизвестно. Правильное значение счѐтчика РУ будет передано позднее.
585
(Примечание. 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-класса и с одним и тем же значением счѐтчика РУ, как и в запросе, кото-
рый был первоначальной причиной формирования привязки маркера.
При изменении маршрута, привязки маркеров переформируются с той точки маршрута, в которой последний отличается от предшествующего мар-
586
шрута. 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-маршрутизатору, находящемуся на противоположной стороне
587
следующего РУ, остаѐтся без удовлетворения, 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).
588
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-маршрутизатором восходящего по-
589
тока, как значение счѐтчика, относящееся к новой привязке маркера. Однако
существуют два исключения:
значение счѐтчика РУ, равное нулю, должно передаваться 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-соединений), это позволяет доставлять
590
новое значение счѐтчика РУ обратно на вход сетевого ATM/LSR-сегмента. Ес-
ли в какой-либо точке LSP-маршрута значение счѐтчика РУ превысит MAXHOP,
то все привязки маркеров для этого 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