RFC 3035 — Применение MPLS-коммутации в сетях с асинхронным режимом доставки

Оглавление

• 1. Введние
• 2. Уровни требований
• 3. Терминология
• 4. Специализированные свойства ATM-коммутаторов
• 5. Модуль MPLS-управления для ATM-сетей
• 6. Гибридные коммутаторы
• 7. Использование VPI/VCI-идентификаторов
• 7.1. Прямые соединения
• 7.2. Соединения через виртуальные ATM-маршруты
• 7.3. Соединения через коммутируемые виртуальные ATM-соединения
• 8. Процедуры распределения и обработки маркеров
• 8.1. Функционирование граничного LSR-маршрутизатора
• 8.2. Стандартные ATM-коммутаторы (без функции объединения VC-соединений)
• 8.3. ATM-коммутаторы с функцией объединения VC-соединений
• 9. Процедуры вставки
• 10. Обработка TTL-значения
• 11. Функция обнаружения петелевых маршрутов: распределение маршрутных векторов
• 11.1. Когда передаётся нисходящий трафик с маршрутными векторами
• 11.2. Когда передаётся восходящий трафик с маршрутными векторами
• 12. Проблемы обеспечения безопасности
• Ссылки

1. Введние

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

2. Уровни требований

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

3. Терминология

• LSR-маршрутизатор (Label Switching Router)

  MPLS-узел, который обеспечивает обработку и доставку реальных IP-пакетов (сетевого уровня).

• 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-маршрутизатор, который транслирует между своими интерфейсами кадры канального уровня (это могут быть кадры протоколов канального уровня, например, PPP-протокол, HDLC-протокол и др.) без фрагментации («целиком»). Следует отметить, что такой 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).

4. Специализированные свойства ATM-коммутаторов

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

К некоторым основным свойствам ATM/LSR-коммутаторов, которые влияют на их функционирование, относятся:

• Функция замены маркеров потока реализуется в полях (VCI- и/или VPI-идентификаторы) заголовка ячейки. А это диктует размер и место размещения маркера(ов) в пакете.

• Сходящиеся (multipoint-to-point) и многоадресные (multipoint-to-multipoint) VC-соединения, как правило, не поддерживаются. Это означает, что большинство коммутаторов не могут реализовать функцию слияния VC-соединений, определённую выше.

• Как правило, коммутаторы не реализую функцию контроля TTL-времени (уменьшения «времени жизни пакета») в IP-заголовках, которая является обязательной для маршрутизаторов.

Далее рассматриваются способы применения MPLS-коммутации в ATM-коммутаторах, которые работают в условиях указанных ограничений.

5. Модуль MPLS-управления для ATM-сетей

Для реализации функции MPLS-коммутации ATM-коммутатор обязан иметь MPLS-модуль управления. В первую очередь, этот модуль реализует процедуры привязки, распределения и обработки маркеров и связанной с ними информации. Данные о привязке маркеров доставляются с помощью нескольких способов, в частности с помощью LDP-протокола. Данный стандарт предъявляет ряд требований к этому протоколу.

В дальнейшем рассматривается только один случай, когда MPLS-модуль управления использует данные, полученные непосредственно от протоколов маршрутизации сетевого уровня. Это предполагает, что коммутатор выступает в роли одной из взаимодействующих сторон при установлении соединений с помощью таких протоколов (например, OSPF, IS-IS и др.).

В отдельных случаях, LSR-маршрутизаторы напрямую используют другие протоколы (например, RSVP, PIM, BGP и др.) для распределения данных о привязках маркеров потока. В таких случаях, ATM/LSR-коммутатору может понадобиться участвовать в процедурах таких протоколов. Однако эти вопросы в дальнейшем не рассматриваются.

Реализация функции MPLS-коммутации не требует от ATM-коммутатора, чтобы он включал ATM-модуль управления, определённый стандартами ITU-T и ATM-Форума (ATM Forum), например, UNI- и PNNI-интерфейсы (User-to-Network Interface — интерфейс «пользователь/ATM-сеть», и Private Network-to-Network Interface — интерфейс «частная ATM-сеть/частная ATM-сеть»). Дополнительно ATM/LSR-коммутатор может отвечать OAM-ячейки (Operations and Maintenance — технологические (служебные) ячейки, предназначенные для обслуживания и поддержания ATM-соединений, в частности для выхода из нештатных и сбойных ситуаций.).

6. Гибридные коммутаторы

Наличие MPLS-модуля управления в ATM-коммутаторе не препятствует возможности одновременного использования ATM-модуля управления, определённого стандартами ITU-T и ATM-Форума, на одном и том же коммутаторе и с одними и теми же интерфейсами. Эти два модуля управления могли бы функционировать независимо друг от друга.

Описание того, как эти модули функционируют, в данном документе не рассматриваются. Однако чтобы обеспечить совместимость этих двух модулей, необходим всего лишь небольшой объём информации, например, данные о разбиении VPI/VCI-диапазона на поддиапазоны, доступные для каждого из этих модулей.

7. Использование VPI/VCI-идентификаторов

MPLS-коммутация осуществляется с помощью привязки маркеров потока к FEC-классам, и использует значения маркеров для доставки IP-пакетов, включая определение значения величины любого замещающего маркера. При использовании ATM/LSR-коммутатора маркер размещается в VPI/VCI-поле, или, когда два ATM/LSR-коммутатора соединяются по виртуальному ATM-пути (ATM «Virtual Path»), маркер размещается в VCI-поле.

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

Кроме этого, если две стороны LDP-соединения взаимодействуют через LC/ATM-интерфейс, то должно быть доступно иное, не MPLS-соединение, по которому можно доставлять непомеченные IP-пакеты. Такое не MPLS-соединение используется для доставки LDP-пакетов между взаимодействующими сторонами, и оно может использоваться (но это не обязательно) для доставки иных непомеченных пакетов (например, пакета OSPF-протокола). В не MPLS-соединениях должна использоваться LLC/SNAP-вставка (RFC-2684).

Целесообразно иметь возможность настройки LC/ATM-интерфейса совместно с дополнительными VPI/VCI-идентификаторами, которые используются для доставки управляющей информации или непомеченных пакетов. В этом случае, VCI-идентификаторы не должны иметь значения в диапазоне 0…32. Они могут использовать, либо «пустую» вставку, либо LLC/SNAP-вставку^[?] (RFC-2684).

7.1. Прямые соединения

Говорят, что два LSR-маршрутизатора «соединены напрямую» через LC/ATM-интерфейс, если все ячейки, транслируемые через этот интерфейс одним LSR-маршрутизатором, будут достигать другой, и при этом между двумя LSR-маршрутизаторами нет ATM-коммутаторов.

Когда два LSR-маршрутизатора «соединены напрямую» через LC/ATM-интерфейс, они совместно управляют распределением VPI/VCI-идентификаторов на соединяющем их интерфейсе. Они могут согласовать использование VPI/VCI-поля в интересах кодирования одиночного маркера.

В режиме «по умолчанию» VPI/VCI-идентификаторы в интересах не MPLS-соединения будут иметь следующие значения: VPI-значение — «0», а VCI-значение — «32». Другие значения диапазона идентификаторов могут использоваться до тех пор, пока обе взаимодействующие стороны осознают сущность (смысл) настраиваемого значения.

Любой VPI/VCI-идентификатор, в котором VPI-значение имеет код в диапазоне от 0 до 32 (включительно), не должен использоваться для обозначения маркера.

За исключением указанных (зарезервированных) диапазонов, значения VPI/VCI-идентификаторов, используемых в обоих направлениях канала связи, могут рассматриваться как относящиеся к независимым пространствам.

Разрешённые значения VCI-идентификаторов устанавливаются с использованием процедуры информационного обмена, определяемой LDP-протоколом.

7.2. Соединения через виртуальные ATM-маршруты

Иногда может быть полезно, рассматривать два LSR-маршрутизатора как смежные (на некотором LSP-маршруте), соединённые через LC/ATM-интерфейс, даже если соединение между ними проходит через «ATM-облако» (ATM-сеть) по виртуальному ATM-маршруту. В таком случае, VPI-поле не приемлемо для MPLS-коммутации, а маркер должен кодироваться целиком в границах VCI-поля.

В рассмотренном случае, в режиме «по умолчанию» VCI-идентификатор в интересах не MPLS-соединения между LSR-маршрутизаторами будет иметь значение «32». ». Другие значения диапазона идентификаторов могут использоваться до тех пор, пока обе взаимодействующие стороны осознают сущность (смысл) настраиваемого значения. VPI-идентификатор должен принимать то значение, которое необходимо для использования виртуального маршрута.

Любой VPI/VCI-идентификатор, в котором VPI-значение имеет код в диапазоне от 0 до 32 (включительно), не должен использоваться для обозначения маркера.

За исключением указанных (зарезервированных) диапазонов, значения VPI/VCI-идентификаторов, используемых в обоих направлениях канала связи, могут рассматриваться как относящиеся к независимым пространствам.

Разрешённые значения VPI/VCI-идентификаторов устанавливаются с использованием процедуры информационного обмена, определяемой LDP-протоколом. Если для MPLS-коммутации используется более одного VPI-идентификатора, то разрешённые диапазоны значений VCI-идентификаторов могут быть различны для каждого VPI-идентификатора, а каждый диапазон устанавливаются с использованием LDP-протокола.

7.3. Соединения через коммутируемые виртуальные ATM-соединения

Иногда может быть полезно, рассматривать два LSR-маршрутизатора как смежные (на некотором LSP-маршруте), соединённые через LC/ATM-интерфейс, даже если соединение между ними проходит через «ATM-облако» (ATM-сеть) по коммутируемым виртуальным ATM-соединениям. Настоящий документ не рассматривает процедуры управления в таких случаях.

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

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

8.1. Функционирование граничного 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-класса, больше не нужны.

8.2. Стандартные 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).

8.3. 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-маршрута значение счётчика РУ превысит MAXHOP, то все привязки маркеров для этого LSP-маршрута, которые были ранее направлены всем соседним LSR_ВП по их соответствующим запросам, должны быть аннулированы. Последнее гарантирует, что любые петлевые маршруты, вызванные маршрутизационными изменениями, будут выявлены и блокированы.

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

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

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

За исключением рассматриваемых далее случаев, при передаче помеченного IP-пакета через LC/ATM-интерфейс, который интерпретирует VPI/VCI-идентификатор (или VCID) как верхний маркер в наборе маркеров, этот IP-пакет должен содержать универсальную MPLS-вставку (shim header, 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-поле заголовка сетевого уровня.

10. Обработка TTL-значения

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

Процедура настройки значения в TTL-поле следующая. Если IP-пакет, принятый граничным LSR-маршрутизатором, является не помеченным, то «входящее TTL-значение» извлекается из поступившего IP-заголовка. Если же IP-пакет, принятый граничным LSR-маршрутизатором, является помеченным, то используется MPLS-вставка (RFC-3032), и «входящее TTL-значение» извлекается из верхней записи в наборе маркеров.

Если значение счётчика РУ было связано с привязкой маркера, которая использовалась при доставке IP-пакета, то «исходящее TTL-значение» будет:

1. либо больше нуля:
2. либо составлять разницу между входящим TTL-значением и значением счётчика РУ.

Если значение счётчика РУ не было связано с привязкой маркера, которая использовалась при доставке IP-пакета, то «исходящее TTL-значение» будет:

1. либо больше нуля:
2. либо на единицу меньше входящего TTL-значения.

Если в результате рассмотренных манипуляций с входным TTL-значением выходное TTL-значение становится нулевым, то IP-пакет не должен передаваться как помеченный IP-пакет, использующий специализированный маркер. В результате анализа IP-пакета могут быть предприняты следующие действия:

• Он может рассматриваться как IP-пакет с просроченным «временем жизни». И в этой связи можно отправить ICMP-сообщение.

• IP-пакет может быть доставлен как непомеченный, в котором TTL-значение на единицу меньше входящего TTL-значения. В данном случае, такая доставка могла бы понадобиться при установлении виртуального соединения без использования MPLS-коммутации.

Конечно, если входное TTL-значение равно единице, то реализуется только первая из рассмотренных выше функций.

Если IP-пакет доставляется как помеченный, то исходящее TTL-значение транслируется, как это описано в предыдущем разделе.

Когда граничный LSR-маршрутизатор получает помеченный IP-пакет через LC/ATM-интерфейс, он извлекает входящее TTL-значение из верхней записи набора маркеров, являющегося универсальной MPLS-вставкой, или, если такая вставка отсутствует — из IP-заголовка.

Если на следующем РУ IP-пакета расположен ATM/LSR-коммутатор, то исходящее TTL-значение формируется с использованием рассмотренных ранее процедур. В противном случае, исходящее TTL-значение формируется с использованием процедур, рассмотренных в стандарте RFC-3032.

Процедуры, рассмотренные в данном разделе, предназначены только для IP-пакетов с однонаправленными (unicast) адресами.

11. Функция обнаружения петелевых маршрутов: распределение маршрутных векторов

Каждый ATM/LSR-коммутатор должен обладать, в качестве дополнительной, функцией обнаружения петлевых маршрутов доставки. Сама же функциональная процедура именуется как «обнаружение петлевого маршрута с помощью маршрутных векторов» (Loop Detection via Path Vectors, LDPV). Эта процедура не предотвращает формирование петлевых маршрутов доставки, но гарантирует, что любые подобные маршруты будут обнаружены. Если эта дополнительная функция не реализована, то петлевые маршруты выявляются с помощью способа, основанного на подсчёте числа РУ, рассмотренного ранее. Если же эта функция реализована, то петлевые маршруты выявляются намного быстрее, но с более существенными затратами.

11.1. Когда передаётся нисходящий трафик с маршрутными векторами

Предположим, что LSR-маршрутизатор R передаёт противоположной стороне своего следующего РУ запрос на данные о привязке маркера к определённому LSP-маршруту. Тогда, если R не реализует функцию объединения VC-соединений, но R способен осуществлять LDPV-процедуру:

• Если R передаёт запрос потому, что является входным узлом данного LSP-маршрута, или потому, что он установил новый следующий РУ, то R обязан включить данные о маршрутном векторе в запрос, а сами данные о маршрутном векторе должны содержать только собственный IP-адрес R .

• Если R передаёт запрос в результате получения запроса от LSR_ВП , то:

  • Если полученный запрос содержит данные о маршрутном векторе, то R обязан добавить свой собственный IP-адрес в принятые данные о маршрутном векторе, и затем обязан отправить противоположной стороне своего следующего РУ результирующие данные о маршрутном векторе вместе с запросом на данные о привязке маркера.

  • Если полученный запрос не содержит данные о маршрутном векторе, то R обязан добавить данные о маршрутном векторе и передать их вместе с запросом, а данные о маршрутном векторе должны включать только собственный IP-адрес R .

Целесообразно, чтобы LSR-маршрутизатор, который реализует функцию объединения VC-соединений, не включал данные о маршрутном векторе в свои запросы, передаваемые им противоположной стороне своего следующего РУ.

Если LSR-маршрутизатор получил запрос на данные о привязке, в которых содержатся данные о маршрутном векторе, включающие IP-адрес этого сетевого узла, то LSR-маршрутизатор принимает решение, что запросы на данные о привязке маркера были доставлены по петлевому маршруту. В таком случае, LSR-маршрутизатор обязан поступить также, как и в случае, когда значение счётчика РУ превысило MAXHOP (параграф 8.2).

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

11.2. Когда передаётся восходящий трафик с маршрутными векторами

Могут возникнуть ситуации, при которых LSR-маршрутизатор R должен информировать свои соседние LSR_ВП об изменении значения счётчика РУ соответствующих определённому LSP-маршруту (с использованием ответного сообщения с данными о привязке маркера). Если выполнены все следующие условия:

• R настроен на выполнение LDPV-процедуры;
• R реализует функцию объединения VC-соединений;
• R не является выходом данного LSP-маршрута;
• R не информирует своих соседей об уменьшении значения счётчика РУ, то R обязан включить данные о маршрутном векторе в ответное сообщение.

Если изменение значения счётчика РУ явилось следствием информирования R LSR-маршрутизатором S , расположенном на противоположной стороне следующего РУ, об изменении значения счётчика РУ, а сообщение отправленное S LSR-маршрутизатору R содержит данные о маршрутном векторе, то, если все указанные выше условия выполнены, R обязан добавить себя в эти данные и отправить результирующее сообщение LSR_ВП . В противном случае, если все указанные выше условия выполнены, R обязан сформировать новые данные только со своим собственным IP-адресом.

Если R настроен на выполнение LDPV-процедуры, и R реализует функцию объединения VC-соединений, то он может включить данные о маршрутном векторе в любое ответное сообщение, содержащее данные о привязке маркера, которое он передаёт LSR_ВП . Соответственно, в любой момент времени, когда R принял от противоположной стороны следующего РУ ответное сообщение с данными о привязке маркера, и если это ответное сообщение включает маршрутный вектор, то R может (если он настроен на выполнение LDPV-процедуры) отправить своим соседним LSR_ВП ответ, содержащий данные о маршрутном векторе, сформированные путём добавления своего собственного IP-адреса в полученный маршрутный вектор.

Если R не реализует функцию объединения VC-соединений, то ему не целесообразно передавать LSR_ВП данные о маршрутном векторе.

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

LSR-маршрутизаторы, которые настроены на выполнение LDPV-процедуры, не должны хранить маршрутный вектор, после того как соответствующие данные о маршрутном векторе были переданы.

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

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

12. Проблемы обеспечения безопасности

Представленные в данном стандарте процедуры, включая MPLS-вставку, не затрагивают каким-либо образом системы аутентификации и/или шифрования пакетов сетевого уровня (например, IPsec-архитектура, RFC-4301).

Кроме того, рассмотренные процедуры не защищают MPLS-маркеры от модификации (случайной и противоправной), которая может привести ложной доставке (ложному маршруту).

Эти же процедуры не предусматривают какой-либо аутентификации объектов (например, принимающий LSR-маршрутизатор не аутентифицирует передающий LSR-маршрутизатор).

В стандарте RFC-3036 (RFC-5036) рассматриваются способы защиты LDP-процедур доставки маркеров и защиты самих маркеров.

Ссылки

[1]	Rosen, E., Viswanathan, A. и R. Callon «Архитектура многопротокольной коммутации на основе маркеров потока (MPLS)», RFC 3031, Январь 2001.
[2]	Andersson L., Doolan P., Feldman N., Fredette A. и R. Thomas, «LDP Specification», RFC 3036, Январь 2001.
[3]	Rosen, E., Rekhter, Y., Tappan, D., Farinacci, D., Fedorkow, G., Li, T. и A. Conta, «RFC 3032 — Кодирование набора маркеров в MPLS-системах», RFC 3032, Январь 2001.
[4]	Nagami, K., Demizu N., Esaki H. и P. Doolan, «VCID Notification over ATM Link for LDP», RFC 3038, Январь 2001.
[5]	Grossman, D., Heinanen, J., «Многопротокольная инкапсуляция с использованием AAL 5», RFC 2684, Сентябрь 1999.