Спецификация LDP, RSVPTE, GMPLS

Обобщенная метка

Обобщенная метка расширяет функциональность традиционной метки, допуская представление не только меток, которые транспортируются соответствующими информационными пакетами, но также меток, которые идентифицируют временные домены, длины волн или пространственное мультиплексирование по положению. Например, обобщенная метка может содержать данные, которые представляют (a) одно волокно из пучка, (b) один волновой диапазон в волокне, (c) одну длину волны из диапазона (или волокна) или (d) набор временных доменов для заданной длины волны (или волокна). Метка может также нести данные о базовой метке MPLS, метке Frame Relay или метке ATM (VCI/VPI).

Обобщенная метка не идентифицирует класс, к которому принадлежит метка. Это определяется возможностями мультиплексирования канала, где используется метка.

Обобщенная метка несет в себе лишь метку одного уровня, т.е. она не является неиерархическим объектом. Когда требуется несколько уровней меток (LSP внутри LSP), каждый LSP должен быть сформирован отдельно (смотри [MPLS-HIERARCHY]). Каждый TLV-объект обобщенной метки несет в себе параметр метки переменной длины.

Метка: переменная длина

Несет в себе данные метки. Интерпретация этого поля зависит от типа канала, где применяется метка.

Метки длины волны и порта

Некоторые конфигурации переключения волокон FSC и ?-переключение LSC используют несколько каналов/соединений, контролируемых одним управляющим каналом. В таких случаях метка ассоциируется с информационным каналом, используемым в LSP. Заметим, что этот случай не тождественен варианту применения [MPLS-BUNDLE]. Метка в случае работы с коммутацией портов и длин волн имеет длину 32 бита.

Метка:32 бит

Указывает на порт/волокно или длину волны, которые должны применяться, с точки зрения отправителя объекта TLV. Значения, используемые в этом поле, имеют значение только для соседей, и получатель может оказаться вынужден преобразовать полученное значение. Значения могут конфигурироваться или динамически определяться с помощью протокола [LMP].

Прочие метки

Базовые метки MPLS и Frame Relay кодируются с выравниванием по правому полю в 32 бита (4 октета). Метки ATM кодируются посредством VPI, выровненными по правому полю в битах 0-15, а VCI выравниваются по правому полю в битах 16-31.

Коммутация по длине волны

Специальным случаем ?-коммутации является переключение по диапазонам длин волн. Волновой диапазон представляет собой набор смежных длин волн, которые могут быть все вместе переключены на новый волновой диапазон. По причине оптимизации для оптического коммутатора может быть желательно переключать несколько длин волн одним блоком. Это может уменьшить искажение для индивидуальных длин волн и позволить более плотное их размещение. Метка волнового диапазона определена для поддержки этого специального случая.

Переключение волновых диапазонов вводит, естественно, другой уровень иерархии меток, и волновой диапазон как таковой рассматривается так же, как и все другие метки высокого уровня.

Поскольку это касается протоколов MPLS, нет большой разницы между меткой диапазона длин волн и меткой длины волны, за исключением того, что семантически диапазон длин волн может быть поделен между несколькими метками, ответственными за мультиплексирование, например, по времени.

Коммутация по диапазонам длин волн использует тот же формат, что и обобщенная метка. В контексте коммутации по диапазонам длин волн обобщенная метка имеет следующий формат (рис. 12.49.):

Рис. 12.49.

ID волнового диапазона: 32 бита.

Идентификатор диапазона длин волн. Значение выбирается отправителем и повторно используется во всех последующих сопряженных сообщениях.

Начальная метка: 32 бит

Указывает на идентификатор канала наинизшей длины волны, образующей диапазон, берется из TLV-объекта отправителя.

Конечная метка: 32 бит

Указывает на идентификатор канала наибольшей длины волны, образующей диапазон, берется из TLV-объекта отправителя.

Идентификаторы канала устанавливаются либо при конфигурации, либо протокольными средствами, такими, как LMP [LMP] (Link Management Protocol). Они обычно воспринимаются как параметр обобщенной метки PSC и LSC.

12.3.4. Предложенная метка

Предложенная метка используется, чтобы сообщить нижележащему узлу предпочтительную метку вышестоящего узла. Это позволяет вышестоящему узлу начать конфигурирование его оборудования с применением предложенной метки, прежде чем метка будет передана нижележащим узлом. Такое раннее конфигурирование ценно для систем, которые требуют нетривиального времени для установления меток в аппаратной части. Оно может уменьшить время осуществления процедуры установления и может быть важным для целей восстановления, где в случае отказа или сбоя альтернативные LSP могут требовать быстрого установления.

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

Информация в предлагаемой метке идентична содержащейся в обобщенной метке.

Набор меток

Набор меток используется, чтобы ограничить выбор меток для узла ниже по течению до приемлемого списка. Это ограничение реализуется для каждого шага независимо.

Здесь описывается четыре варианта, когда набор меток полезен для оптической области применений. Первый вариант реализуется, когда оконечное оборудование способно передавать ограниченный набор длин волн/диапазонов. Второй вариант нужен, когда последовательность интерфейсов не поддерживает преобразование длин волн и требует использования одной длины волны на всем пути. Третий вариант возникает, когда желательно ограничить число преобразований длин волн, чтобы уменьшить искажения оптических сигналов. Последний случай представляет собой вариант, когда разные концы канала поддерживают различные наборы длин волн.

Набор меток используется, чтобы ограничить диапазон меток, который может быть применен для конкретного LSP между двумя партнерами. Получатель набора меток должен ограничить свой выбор одной меткой из оговоренного набора. Аналогично метке, набор меток может относиться к нескольким шагам маршрута. В этом случае каждый узел генерирует свой собственный исходящий набор меток, возможно, базирующийся на входном наборе меток и возможностях узлового оборудования. Этот вариант является обычным для узлов с интерфейсами, неспособными преобразовывать длины волн.

Использование набора меток является опционным, — если его нет, можно задействовать все метки из допустимого диапазона. Концептуально отсутствие набора меток предполагает применение набора меток {U}, к которому относятся все допустимые метки.

Необходимая информация

Набор меток состоит из одного или более объектов Label_Set/TLV. Каждый объект/TLV содержит один или более элементов набора меток. Каждый элемент воспринимается как идентификатор субканала и имеет тот же формат, что и обобщенная метка. Информация в наборе меток имеет формат (рис. 12.50):

Рис. 12.50.

Действие:8 бит

0 — включающий список

Указывает, что объект/TLV содержит один или более субканальных элементов, которые включены в набор меток.

1 — исключающий список

Указывает, что объект/TLV содержит один или более субканальных элементов, которые исключены из набора меток.

2 — включающий диапазон

Указывает, что объект/TLV содержит диапазон меток. Объект/TLV содержит два субканальных элемента. Первый элемент указывает на начало диапазона, второй — на конец диапазона. Значение нуль говорит о том, что соответствующая часть диапазона не имеет ограничения.

3 — исключающий диапазон

Указывает, что объект/TLV содержит диапазон меток, которые исключены из набора меток. Объект/TLV содержит два субканальных элемента. Первый элемент указывает на начало диапазона, второй — на конец диапазона. Значение нуль говорит о том, что соответствующая часть диапазона не имеет ограничения.

Зарезервировано:10 бит

Это поле зарезервировано. Оно должно быть установлено равным нулю при передаче и игнорироваться при приеме.

Тип метки: 14 бит

Указывает тип и формат меток, содержащийся в объекте/TLV. Значения зависят от сигнального протокола.

Субканал:

Субканал представляет метку (длина волны, волокно...), которая может быть присвоена.

Двунаправленные LSP

В этом разделе определены двунаправленные LSP. Поддержка определена для LSP, которые имеют те же требования управления трафиком, включая долю совмещения, защиту и восстановление, LSR, и ресурсные требования (например, задержка и разброс) для каждого из направлений. В дальнейшем под "инициатором" подразумевается узел, который начинает формирование LSP, а под "терминатором" — узел, который является конечным пунктом LSP.

Заметим, что для полнодуплексных LSP имеется только один инициатор и один терминатор.

В нормальной ситуации для установления двунаправленного LSP при использовании [RFC-3209] или RFC-3212 должны быть независимо сформированы два однонаправленных маршрута. Этот подход имеет следующие недостатки.

• Время установления двунаправленного LSP равно одному RTT плюс одна задержка переходного процесса инициатор-адресат. Это время не только покрывает время установления для случая успешного формирования LSP, но распространяется на худший случай обнаружения недоступного LSP, что в два раза больше переходного процесса инициатор-адресат. Эти задержки особенно существенны для LSP, которые формируются для целей восстановления.
• Избыточность управления в два раза больше, чем в случае однонаправленных LSP. Причина в том, что нужно генерировать отдельные управляющие сообщения (например, Path и Resv) для обоих сегментов двунаправленного LSP.
• Из-за ресурсов, занятых в отдельных сегментах, выбор маршрута оказывается осложненным. Можно ожидать дополнительной конкуренции при выделении ресурсов, которая может уменьшить вероятность успешного формирования двунаправленного соединения.
• Труднее предоставить хороший интерфейс для оборудования SONET/SDH, которое может базироваться на двунаправленных пошаговых маршрутах.
• Двунаправленные оптические LSP (или световоды) рассматриваются в качестве базового требования большинством сетевых сервис-провайдеров.

В случае двунаправленных LSP пути данных вниз и вверх по течению, т.е., от инициатора до адресата и от адресата к инициатору, устанавливаются с использованием одного набора сигнальных сообщений. Это уменьшает время установления до одного RTT между инициатором и адресатом плюс время обработки, и ограничивает избыточность управления до уровня числа сообщений однонаправленного LSP.

Необходимая информация

Для двунаправленных LSP надо выделить две метки. Установление двунаправленного LSP отмечается наличием объекта/TLV метки для маршрута вверх по течению в соответствующем сигнальном сообщении. Вышестоящая метка имеет тот же формат, что и обобщенная метка.

Разрешение конфликтов

Конфликты для меток могут происходить между двумя запросами установления двунаправленных LSP, которые направлены в противоположных направлениях. Этот конфликт происходит, когда обе стороны выделяют одни и те же ресурсы (метки) в одно и то же время. Если нет ограничений на использование меток в двунаправленных LSP и если ресурсы являются альтернативными, тогда оба узла передадут разные метки вверх по течению и конфликта не будет. Однако если имеется ограничение на метки, которые могут быть использованы для двунаправленных LSP (например, если они должны быть физически связаны с одной и той же интерфейсной I/O картой), или если нет более доступных ресурсов, тогда конфликт должен разрешаться другими средствами. Чтобы разрешить конфликт, узел с более высоким значением ID выиграет соревнование и должен послать сообщение PathErr/NOTIFICATION с указанием "Routing problem/Label allocation failure" (проблема с маршрутизацией/отказ присвоения метки). После получения такого сигнала ошибки узел должен попытаться выделить другую метку для сегмента выше по течению (и другую предлагаемую метку, если таковая используется) в двунаправленном маршруте. Однако если других ресурсов нет, узел должен начать стандартную процедуру обработки ошибки.

Чтобы уменьшить вероятность конфликта, можно ввести правило, когда узел с более низким ID никогда не предлагает меток для сегмента ниже по течению и всегда воспринимает предлагаемую метку от вышестоящего узла с более высоким значением ID. Кроме того, так как метки пересылаются посредством LMP, может использоваться альтернативное правило: узел с более высоким номером может присваивать метки, начиная с верхнего края диапазона меток, в то время как узел с меньшим номером использует метки нижнего конца диапазона меток. Этот механизм усилит любой алгоритм кластеризации, который может быть применен для оптимизации полосы частот (или длин волн). Особым случаем, на который следует обратить внимание при использовании RSVP и поддержке этого подхода, является то, что ID соседнего узла может быть неизвестно при посылке исходного сообщения Path. Когда такое происходит, узлу следует предложить метку, выбранную из доступного пространства меток случайным образом.

Пример конфликта между двумя узлами (PXC 1 и PXC 2) показан на рис. 12.51. В этом примере PXC 1 присваивает метку для сегмента выше по течению для канала, соответствующего локальному BCId=2 (локальный BCId=7 для PXC 2), и посылает предлагаемую метку для канала, соответствующего локальному BCId=1 (локальный BCId=6 для PXC 2). Одновременно PXC 2 присваивает метку для сегмента выше по течению для канала, соответствующего его локальному BCId=6 (локальный BCId=1 для PXC 1), и посылает предлагаемую метку для канала, соответствующего его локальному BCId=7 (локальный BCId=2 для PXC 1). Если нет ограничения на метки, которые можно использовать для двунаправленных LSP, и если имеются альтернативные ресурсы, тогда PXC 1 и PXC 2 передадут разные метки вверх по течению и конфликт разрешится естественным образом (смотри 12.51). Однако если и меются ограничения для меток, используемых в двунаправленных LSP (например, если они должны быть физически подключены к одной I/O карте), тогда конфликт должен быть разрешен с привлечением ID—узла (смотри рис. 12.51).

В этом примере PXC 1 присваивает метку для сегмента выше по течению, используя BCId=2 ( BCId=7 для PXC 2), и рекомендуемую метку, используя BCId=1 ( BCId=6 для PXC 2). Одновременно PXC 2 присваивает метку для сегмента выше по течению, используя BCId=6 ( BCId=1 для PXC 1) и рекомендуемую метку, используя BCId=7 ( BCId=2 для PXC 1).

В этом примере нет ограничения на метки, которые можно применять двусторонним соединениям, и здесь нет конфликта.

В этом примере метки 1,2 и 3,4 для PXC 1 (метки 6,7 и 8,9 для PXC 2, соответственно) должны выбираться одним и тем же двусторонним соединением. Так как PXC 2 имеет больший ID узла, он выигрывает соревнование и PXC 1 должен использовать другой набор меток.

Уведомление об ошибках в метках

Существуют случаи в традиционном MPLS и в GMPLS, которые вызывают сообщения об ошибке, содержащие уведомление "Unacceptable label value" (неприемлемое значение метки, смотри [RFC-3209], [RFC-3472] и [RFC-3473]). Когда такое происходит, для узла, генерирующего сообщение ошибки, может быть полезно указать, какие метки могут быть приемлемы. Для этого случая GMPLS вводит возможность передачи такой информации с помощью Acceptable Label Set (приемлемый набор меток). Приемлемый набор меток транспортируется в соответствующем специальном протокольном сообщении об ошибке (смотри [RFC-3472] и [RFC-3473]).

Прямое управление по меткам

В традиционном MPLS интерфейсы, используемые LSP, могут управляться через явное задание маршрута, т.е., ERO или ER-Hop (explicit route).

Рис. 12.51. Конфликт меток

Рис. 12.52. Разрешение конфликта меток без ограничений ресурсов

Рис. 12.53. Разрешение конфликта меток посредством ограничений ресурсов

Бывают случаи, когда существующая явная семантика маршрута не предоставляет достаточно информации для управления LSP на желательном уровне. Это происходит в случае, когда LSP-инициатор хочет выбрать метку, используемую каналом. Точнее, проблема заключается в том, что ERO и ER-Hop не поддерживают явных субобъектов меток. Примером, где желателен такой механизм, является случай, где имеется два LSP, которые должны быть связаны друг с другом, т.е., где конец первого LSP нужно связать с началом второго LSP. Этот последний вариант, вероятно, следует применять в не-PSC классах каналов. Чтобы покрыть этот случай, введен Label ERO subobject/ER Hop.

Защитная информация

Защитная информация транспортируется в новом объекте/TLV. Она нужна для описания атрибутов защиты канала, запрошенного LSP. Использование информации защиты для конкретного LSP является опционным. Защитная информация указывает на желательный тип защиты канала LSP. Если запрошен конкретный тип защиты, т.е., 1+1, или 1:N, тогда запрос соединения обрабатывается, только если запрашиваемый тип защиты может быть реализован. Заметим, что возможности защиты канала могут анонсироваться в ходе маршрутизации (смотри [GMPLS-RTG]). Алгоритмы расчета маршрута могут учитывать эту информацию при формировании LSP.

Защитная информация указывает также, является ли данный LSP первичным или вторичным. Вторичный LSP является резервным по отношению к первичному LSP. Ресурсы вторичного LSP не используются до тех пор, пока работает первичный LSP. Ресурсы, выделенные для вторичного LSP, могут использоваться другими LSP до тех пор, пока первичный LSP не откажет. В такой ситуации любой LSP, который задействует ресурсы вторичного LSP, должен быть переключен.

Следующие данные содержатся в полях защитной информации:

Вторичный (S):1 бит

Когда этот бит равен 1, запрошенный LSP является вторичным.

Зарезервировано:25 бит

Это поле зарезервировано. Оно должно быть равно нулю при передаче и игнорироваться при приеме. Эти биты должны передаваться транзитными узлами без модификации.

Флаги канала:6 бит

Отмечает желательный тип защиты канала. Как ранее упоминалось, возможности защиты канала могут анонсироваться при маршрутизации. Значение 0 подразумевает, что может применяться любая защита канала либо таковая может отсутствовать. Можно использовать более одного бита для указания нескольких приемлемых типов защиты. Когда установлено несколько бит и доступны несколько типов защиты, выбор типа защиты определяется локально.

Информация административного состояния

Административная статусная информация транспортируется в новом объекте/TLV. Эта информация используется в настоящее время двумя способами. В первом информация характеризует административное состояние, сопряженное с определенным LSP. В таком применении административная статусная информация отображает состояние LSP. Индикация состояния включает в себя up или down, если система находится в режиме тестирования и если маршрут ликвидируется. Действия, предпринимаемые узлом, базируются на локальных статусных характеристиках. Примером действия, которое может быть предпринято, является запрет уведомления о сигнале тревоги, когда LSP находится в состоянии down или в тестовом режиме, а также сообщение уведомления о тревоге, связанное с соединением, имеющем приоритет, равный или меньший, чем "Non service affecting" (не влияет на обслуживание).

Рис. 12.54.

Во втором способе использование административной статусной информации может означать запрос установления состояния LSP. Эта информация всегда относится к входному узлу, который обрабатывает запрос. Подробности смотри в [RFC-3473] и [RFC-3472]. Применение административной статусной информации для конкретного LSP является опционным. Следующие данные содержатся в полях административной информации статуса (рис. 12.55):

Отражение (R):1 бит

Когда бит равен 1, это указывает, что крайний узел должен вернуть объект/TLV назад в соответствующем сообщении. Этот бит не должен устанавливаться в случае запроса изменения состояния, т.е. в сообщениях уведомления.

Зарезервировано:28 бит

Это поле зарезервировано. Оно должно быть равно нулю при передаче и игнорироваться при приеме. Эти биты должны передаваться транзитными узлами без модификации.

Тестирование (T):1 бит

Когда бит равен 1, это указывает, что локальные действия относятся к режиму тестирования.

Административно выключено (A): 1 бит

Когда бит равен 1, это указывает, что локальные действия относятся к состоянию "выключено административно".

Аннулирование в процессе (D): 1 бит

Когда бит равен 1, это указывает, что локальные действия, относящиеся к LSP, следует аннулировать. Крайние узлы могут использовать этот флаг для аннулирования управляющего соединения.

Рис. 12.55.

Разделение каналов управления

Концепция канала управления отличается от концепции канала данных, введенной MPLS в связи с объединением каналов (смотри [MPLS-BUNDLE]). В GMPLS разделение каналов данных и управления может быть связано с несколькими факторами. Сюда относится объединение каналов и другие случаи, такие, как информационные каналы, которые не могут транспортировать управляющие данные.

Идентификация интерфейса

В традиционном MPLS имеется неявная ассоциация каналов управления и данных. Когда существует такая ассоциация, не требуется никакой дополнительной или специальной информации, чтобы связать формирование определенного LSP с заданным каналом данных.

В случаях, где нет явной ассоциации каналов данных и управления, необходимо передавать дополнительную информацию, чтобы идентифицировать определенный канал данных, который требует управления. GMPLS поддерживает явную идентификацию канала данных, предоставляя ID интерфейса. GMPLS допускает использование нескольких схем идентификации интерфейсов, включая адреса IPv4 или IPv6, индексы интерфейсов (смотри [MPLS-UNNUM]) и составные интерфейсы (установленные посредством конфигурирования или протокола, такого, как [LMP]). Во всех случаях выбор информационного интерфейса индицируется вышестоящим узлом с помощью адресов и идентификаторов. В Interface_ID содержатся TLV, которые имеют следующий формат:

Длина: 16 бит

Указывает полную длину TLV, т.е., 4 + длина поля значения в октетах. Поле значение, чья длина не кратна четырем, должно дополняться нулями так, чтобы длина TLV стала кратной четырем октетам.

Тип:16 бит

Указывает тип идентифицируемого интерфейса. Определены следующие значения (табл. 12.17):

Для типов 3, 4 и 5 поле значение имеет формат:

IP-адрес: 32 бита

Поле IP-адрес может включать IP-адрес канала или IP-адрес соответствующего маршрутизатора, содержащийся в TLV адреса маршрутизатора.

ID интерфейса:32 бита

Для 3-го типа применения (см. табл. 12.5) ID интерфейса несет в себе идентификатор интерфейса.

Для типов 4 и 5 ID интерфейса указывает на составной канал. Специальное значение 0xFFFFFFFF может быть использовано для обозначения того, что одна и та же метка служит для всех компонентов канала.

Рис. 12.56.

Обработка отказов

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

Рис. 12.57.

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

Заметим, что эти случаи применимы, когда имеются механизмы детектирования отказов канала данных независимо от отказов канала управления.