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

Разбить на страницы

Показывать лекцию целиком

Обзор LDP

Архитектура MPLS [RFC-3031] определяет протокол рассылки меток как набор процедур, с помощью которых один LSR (Label Switched Router) информирует другого о значении меток, используемых для переадресации трафика между ними и через них.

Архитектура MPLS не предполагает наличия одного протокола рассылки меток. В действительности, стандартизовано несколько различных протоколов. Некоторые существующие протоколы были расширены так, чтобы позволить рассылку меток. Сформулированы новые протоколы. Архитектура MPLS предполагает учет некоторых соображений при выборе протокола рассылки меток для конкретных MPLS-приложений, в частности, в случае управления трафиком [RFC-2702].

Протокол рассылки меток LDP (Label Distribution Protocol), определенный ниже (RFC-3036), является новым протоколом для рассылки меток, предлагающий расширенную функциональность. Это набор процедур и сообщений, с помощью которых LSR формирует сетевой LSP (Label Switched Path) путем установления соответствия между маршрутной информацией и каналами передачи данных. Эти LSP могут иметь оконечные точки непосредственно у партнера (сопоставимо с IP переадресацией шаг-за-шагом) или могут иметь оконечную точку в выходном узле сети, позволяя коммутацию через все промежуточные узлы.

LDP ставит в соответствие FEC (Forwarding Equivalence Class) [RFC-3031] каждому LSP, который он создает. FEC, ассоциированный с LSP, определяет, какие пакеты должны следовать по этому LSP. LSP прокладываются через сеть так, что каждый LSR обеспечивает стыковку входной метки для FEC с выходной меткой, соответствующей следующему шагу для данного FEC. Дополнительные данные о применении LDP можно найти в [RFC-3037].

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

LDP-партнеры

Два LSR, которые используют LDP для обмена информацией о соответствии метка-FEC, называются "LDP партнерами", между которыми реализуется LDP сессия. LDP-сессия позволяет каждому партнеру познакомиться с соответствием меток друг у друга; т.e., протокол является двунаправленным.

Обмен сообщениями LDP

Существует четыре категории сообщений LDP.

Сообщения выявления (Discovery) используются для объявления и поддержания присутствия LSR в сети.

Сообщения сессий используются для установления, поддержки и завершения сессий между LDP-партнерами.

Сообщения анонсирования (Advertisement) используются для формирования, изменения и ликвидации соответствия между меткой и FEC.

Сообщения уведомления (Notification) используются для предоставления рекомендаций и уведомления об ошибках.

Сообщения выявления предоставляют механизм, посредством которого LSR оповещает о своем присутствии в сети посредством периодической посылки сообщения Hello. Оно посылается в виде UDP-пакета на вход LDP-порта всем маршрутизаторам субсети через групповой мультикастинг-адрес. Когда LSR решает установить сессию с другим LSR, опознанным с помощью сообщения Hello, он применяет процедуру инициализации LDP с привлечением протокола TCP. При успешном завершении процедуры инициализации, два LSR становятся LDP-партнерами и могут обмениваться сообщениями анонсирования.

Момент запроса или анонсирования метки партнеру определяется локальными соображениями LSR. Вообще, LSR запрашивает метку у соседнего LSR, когда она ему нужна, и анонсирует метку соседнему LSR, когда хочет, чтобы сосед использовал эту метку. Корректная работа LDP требует надежной и упорядоченной доставки сообщений. Чтобы удовлетворить этим требованиям, LDP применяет в качестве транспортного протокола TCP для сообщений сессий, предупреждений и анонсирования; т.e., для любых обменов, кроме механизмов выявления, базирующихся на UDP.

Структура сообщения LDP

Все сообщения LDP имеют общую структуру, которая использует схему кодирования TLV (TypeLengthValue) тип-длина-значение. Значение является объектом, кодируемым по схеме TLV, и может содержать одно или более TLV.

Обработка ошибок LDP

Предупреждение партнеров об ошибках LDP и других событиях осуществляется с помощью сообщений уведомления. Существует два сорта сообщений уведомления.

Уведомления об ошибке применяются, чтобы предупредить о фатальных сбоях. Если LSR получает от партнера уведомление об ошибке для конкретной LDP сессии, он завершает эту сессию, закрывая транспортное TCP соединение и ликвидируя все ассоциации меток, полученные за время этой сессии.

Сообщения-рекомендации используются для передачи LSR-информации о LDP сессии или статусе некоторых полученных ранее сообщений.

Расширяемость LDP и будущая совместимость

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

Работа LDP. FEC

Необходимо точно определить, какие пакеты могут быть поставлены в соответствие каждому LSP. Это делается с помощью FEC-спецификации для каждого LSP. FEC идентифицирует набор пакетов, которые могут быть ассоциированы с данным LSP.

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

Ниже определяются типы элементов FEC. Если потребуется, может быть добавлен новый FEC.

Адресный префикс. Этот элемент является адресным префиксом произвольной длины от 0 до полного адреса включительно.

Адрес ЭВМ. Этот элемент является полным адресом ЭВМ.

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

Процедура установления соответствия конкретного пакета с заданным LSP использует следующие правила. Каждое правило применяется последовательно до тех пор, пока пакет не сможет быть отнесен к заданному LSP.

Если имеется только один LSP, который содержит FEC элемент адреса ЭВМ, идентичный адресу места назначения пакета, тогда пакет ассоциируется с данным LSP.

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

Если пакет в точности соответствует одному LSP, пакет ассоциируется с этим LSP.

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

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

Целесообразно отметить несколько следствий этих правил.

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

Пакет может соответствовать двум LSP: одному с FEC элементом адреса ЭВМ, а другому — с FEC элементом префикса адреса. В этом случае пакеты ассоциируются всегда со вторым из этих LSP.

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

Пространства меток, идентификаторы, сессии и транспорт. Пространства меток

Выражение "пространство меток" полезно для обсуждения присвоения и рассылки меток.

Пространство меток интерфейса. Входные метки, специфичные для интерфейса, применяются для интерфейсов, которые используют для меток ресурсы интерфейса. Примером такого интерфейса является АТМ-интерфейс (в качестве меток применяет VCI) или интерфейс Frame Relay (в качестве меток — DLCI).

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

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

Идентификаторы LDP

Идентификатор LDP представляет собой 6-октетный код, применяемый для идентификации пространства меток LSR. Первые четыре октета идентифицируют LSR и должны быть глобально уникальными, такими, как 32-битный идентификатор маршрутизатора, присвоенный LSR. Последние два октета идентифицируют специфическое пространство меток LSR. Последние два октета идентификаторов LDP для ориентированного на платформу пространства меток всегда равны нулю. В данном документе используется следующее представление идентификаторов LDP:

<LSR Id> : <label space id>

напр., lsr 171:0, lsr19:2.

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

Ситуация, где LSR требует анонсировать более одного пространства меток и, следовательно, использует более одного идентификатора LDP, реализуется, когда LSR имеет более одного АТМ-канала до партнера (и работает с пространством меток интерфейса). Другая ситуация возникает, когда LSR имеет два канала до партнера, один из которых работает через Ethernet (и использует пространство меток, ориентированное на эту платформу), а другой реализован через ATM.

Сессии LDP

LDP-сессии реализуются между LSR, чтобы поддержать обмен метками между ними. Когда LSR применяет LDP для анонсирования более чем одного пространства меток, он запускает разные LDP-сессии для разных пространств меток.

LDP транспорт

Для сессий LDP использует TCP как надежную транспортную среду. Когда нужно несколько LDP сессий между двумя LSR, реализуется по одной TCP-сессии для каждой LDP-сессии.

LDP-сессии между LSR, соединенными не напрямую

В некоторых ситуациях могут быть желательны сессии LDP между LSR, которые не связаны непосредственно на канальном уровне.

Например, рассмотрим приложение управления трафиком, где LSRa посылает трафик, отвечающий определенным критериям, через определенный LSP к LSRb, а не осуществляет традиционную маршрутизацию.

Путь между LSRa и LSRb может содержать один или более промежуточных LSR ( LSR1,...LSRn). LDP-сессия между LSRa и LSRb позволит LSRb пометить трафик, пребывающий в LSP из LSRa, путем предоставления LSRb средств анонсирования меток маршрутизатору LSRa.

В этой ситуации LSRa будет использовать две метки для коммутации трафика через LSP к LSRb: метка, полученная от LSR1, служит для переадресации трафика вдоль LSP от LSRa к LSRb; а метка, полученная от LSRb, позволяет LSRb помечать и коммутировать трафик, поступающий из LSP.

LSRa сначала добавляет метку, полученную во время LDP-сессии от LSRb, в стек меток пакета (либо путем замены метки на верху стека меток, если пакет пришел помеченным, либо путем выполнения операции push (занесение в стек), если пакет пришел непомеченным). Далее он заносит в стек метку для LSP, полученную от LSR1.

Выявление LDP (Discovery)

Выявление LDP (discovery) является механизмом, который позволяет LSR найти потенциальных партнеров LDP. Выявление делает ненужным явное конфигурирование LSR. Существует два механизма выявления.

Базовый механизм выявления используется для детектирования соседних LSR, которые непосредственно соединены на канальном уровне.

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

Базовый механизма выявления

Чтобы запустить базовый механизм выявления в LDP для заданного интерфейса LSR периодически посылает в канал LDP-сообщения. Канальные сообщения Hello передаются в виде UDP-пакетов, адресованных в стандартный порт выявления партнеров LDP, всем маршрутизаторам субсети методом мультикастинг-адресации.

Канальное сообщение LDP Hello, посланное LSR, содержит в себе идентификатор LDP для пространства меток, которое LSR намерен использовать для интерфейса, а также дополнительную информацию.

Отклик на канальное сообщение LDP Hello идентифицирует сопредельность (adjacency) с потенциальным LDP-партнером, достижимым на канальном уровне интерфейса, а также пространство меток, которое партнер намерен использовать для данного интерфейса.

Расширенный механизм выявления

Сессии LDP между несвязанными напрямую LSR поддерживаются расширенным механизмом выявления партнеров.

Чтобы запустить расширенный механизм выявления, LSR периодически посылает в LDP целевые сообщения Hello (Targeted Hello) по определенным адресам. Целевые сообщения Hello посылаются в виде UDР-пакетов, направленных в стандартный порт выявления по специфицированному адресу.

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

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

В отличие от базового выявления, которое является симметричным, расширенное — асимметрично.

Один LSR инициирует процесс расширенного выявления в отношении другого LSR, а адресуемый LSR решает, следует ли откликаться или игнорировать данное сообщение целевого Hello. Адресуемый LSR, который решил откликаться, реагирует периодической посылкой целевого Hello LSR-инициатору.

Отклик на адресное Hello идентифицирует сопредельность с потенциальным LDP-партнером, достижимым на сетевом уровне, и пространство меток, которое партнер намерен использовать.

Установление сессий LDP и управление ими. Установление сессии LDP

Обмен сообщениями выявления партнеров между двумя LSR запускает LDP-сессию. Сессия формируется в два этапа.

Установление транспортного соединения.

Инициализация сессии

Далее описывается установление LDP-сессии между LSR1 и LSR2 с точки зрения LSR1. Это предполагает обмен сообщениями Hello, специфицирующими пространство меток LSR1:a для LSR1 и пространство меток LSR2:b для LSR2.

Установление транспортного соединения

Результатом обмена сообщениями Hello является формирование Hello сопредельности для LSR1, которое определяет канал связи (L), и пространства меток LSR1:a и LSR2:b.

Если LSR1 не имеет LDP сессии обмена пространствами меток LSR1:a и LSR2:b, он пытается сформировать TCP-соединение для новой LDP сессии с LSR2.

LSR1 определяет транспортные адреса, которые следует использовать на конце (A1) и на конце LSR2 (A2) TCP-соединения. Адрес A1 определяется следующим образом:

если LSR1 задействует опционный объект в сообщениях Hello LSR2, он посылает транспортный адрес (TLV), чтобы анонсировать адрес. A1 является адресом, который анонсируется LSR1 через посредство опционного объекта;

если LSR1 не использует опционный объект транспортного адреса, A1 является адресом отправителя в сообщениях Hello, которые отправляет LSR2.

Аналогично, адрес A2 определяется так:

если LSR2 задействует опционный объект транспортного адреса, A2 является адресом, который LSR2 анонсирует через посредство опционного объекта;

если LSR2 не использует опционный объект транспортного адреса, A2 является адресом отправителя в сообщении Hello, полученном от LSR2.

LSR1 определяет, будет ли он играть активную или пассивную роль в сессии установления, посредством сравнения адресов A1 и A2 как целых чисел без знака. Если А1>A2, LSR1 играет активную роль; в противном случае — пассивную.

Процедура сравнения A1 и A2 осуществляется следующим образом:

если A1 и A2 принадлежат разным адресным семействам, они несравнимы, и сессия не может быть реализована;

пусть U1 является абстрактным целым числом без знака, полученным от A1 в виде последовательности байт, где байт, полученный первым, является наиболее значимым, а байт, полученный последним, является наименее значимым.

Пусть U2 является абстрактным целым числом без знака, полученным от A2 аналогичным образом.

сравниваем U1 с U2. Если U1 > U2, тогда A1 > A2; если U1 < U2, тогда A1 < A2.

Если LSR1 является активным, он пытается установить TCP-соединение через стандартный номер порта по адресу A2. Если LSR1 является пассивным, он ждет, пока LSR2 не установит TCP-соединение через стандартный номер порта.

Заметим, что когда LSR посылает сообщение Hello, он выбирает транспортный адрес конца соединения сессии и применяет Hello, чтобы анонсировать адрес — либо явно путем включения его в опционный TLV транспортного адреса, либо неявно, опуская TLV и используя его в качестве адреса отправителя в сообщении Hello.

Инициализация сессии

После того как LSR1 и LSR2 установят транспортное соединение, они согласуют параметры сессии путем обмена сообщениями инициализации LDP. Согласуемые параметры включают в себя версию протокола, метод рассылки меток, значения таймера, диапазоны VPI/VCI для управляемого метками ATM, диапазоны DLCI для управляемого метками Frame Relay и т.д..

Успешное согласование завершается установлением LDP-сессии между LSR1 и LSR2 для анонсирования пространств меток LSR1:a и LSR2:b.

После того, как соединение установлено, если LSR1 играет активную роль, он начинает согласование параметров сессии путем посылки LSR2 сообщения инициализации. Если LSR1 пассивен, он ждет, пока LSR2 не инициализирует согласование параметров.

Вообще, когда существует несколько каналов между LSR1 и LSR2 и несколько пространств меток, которые им нужно анонсировать, пассивный LSR не может знать, какое пространство меток следует анонсировать через вновь установленное TCP-соединение, до тех пор пока не получит сообщение инициализации. Сообщение инициализации содержит в себе идентификатор LDP для пространства меток отправителя (активный LSR) и идентификатор LDP для пространства меток получателя (пассивный LSR).

Ожидая сообщение инициализации от своего партнера, пассивный LSR может согласовать пространство меток, которое должно анонсироваться партнером (как это определено идентификатором LDP в заголовке PDU сообщения инициализации), с сопредельностью Hello, сформированной при обмене сообщениями Hello.

Когда LSR1 играет пассивную роль:

если LSR1 получает сообщение инициализации, он пытается согласовать идентификатор LDP, содержащийся в PDU сообщения, с сопредельностью Hello;

если подходящая Hello-сопредельность имеется, она характеризует локальное пространство меток для данной сессии.

Далее LSR1 проверяет, являются ли приемлемыми предложенные в сообщении параметры сессии. Если да, LSR1 откликается сообщением инициализации с параметрами, которые он намерен использовать, и сообщением KeepAlive, чтобы сообщить о приемлемости параметров LSR2. Если параметры не приемлемы, LSR1 откликается сообщением об ошибке Session Rejected/Parameters и закрывает TCP-соединение.

если LSR1 не может найти подходящую сопредельность Hello (Hello adjacency), он посылает сообщение об ошибке Session Rejected/No Hello Error и закрывает TCP-соединение;

если в ответ на сообщение инициализации LSR1 получает KeepAlive, сессия с точки зрения LSR1 является рабочей;

если LSR1 получает сообщение об ошибке, LSR2 отклоняет предложенную сессию и LSR1 закрывает TCP-соединение.

Когда LSR1 играет активную роль:

если LSR1 получает сообщение об ошибке, LSR2 отвергает предложенную сессию, а LSR1 закрывает TCP-соединение;

если LSR1 получает сообщение инициализации, он проверяет, приемлемы ли параметры сессии. Если да, то откликается сообщением KeepAlive. Если параметры сессии не приемлемы, LSR1 посылает сообщение об ошибке Session Rejected/Parameters и закрывает соединение;

если LSR1 получает сообщение KeepAlive, LSR2 воспринял предложенные им параметры сессии;

когда LSR1 получил и приемлемое сообщение инициализации, и сообщение KeepAlive, сессия с точки зрения LSR1 работоспособна.

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

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

Попытка установления сессии после отрицательного подтверждения сообщения инициализации должна производиться не ранее чем через 15 секунд, а последующие задержки должны расти до значения не менее 2 минут. Особой операцией по установлению сессии, которая должна быть задержана, является попытка открыть сессию транспортного соединения для LSR, играющим активную роль.

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

Из-за асимметричной природы установления сессии, реконфигурация пассивного LSR пройдет незаметно для активного LSR.

Инициализация машины состояний

Удобно описывать процедуру согласования сессии LDP в терминах машины конечных состояний (FSM). Мы определяем, что в FSM LDP имеется пять возможных состояний, а переходы между состояниями определяются таблицей 12.1, представленной ниже.

Переходы между состояниями при инициализации сессии
Состояние	Событие	новое состояние
NON EXISTENT	Сессия TCP-соединения установлена	INITIALIZED
INITIALIZED	Передача сообщения инициализации (Активная роль)	OPENSENT
	Получение приемлемого сообщения инициализации (Пассивная роль)	OPENREC
	Действие: Передача сообщения инициализации и KeepAlive
	Получение любого другого сообщения LDP	NON EXISTENT
	Действие: Передача сообщения об ошибке (NAK) и закрытие транспортного соединения
OPENREC	Получение сообщения KeepAlive	OPERATIONAL
	Получение любого другого сообщения LDP	NON EXISTENT
	Действие: Передача сообщения об ошибке (NAK) и закрытие транспортного соединения
OPENSENT	Получение приемлемого сообщения инициализации	OPENREC
	Действие: передача сообщения KeepAlive
	Получение любого другого сообщения LDP	NON EXISTENT
	Действие: передача сообщения об ошибке (NAK) и закрытие транспортного соединения
OPERATIONAL	Получение сообщения Shutdown	NON EXISTENT
	Действие: передача сообщения Shutdown и закрытие транспортного соединения
	Получение других сообщений LDP	OPERATIONAL
	Тайм-аут	NON EXISTENT
	Действие: передача сообщения завершения и закрытие транспортного соединения

Поддержка сопредельности Hello

Сессия с партнером LDP имеет одну или более сопредельностей Hello. Сессия LDP имеет несколько Hello-сопредельностей, когда пара LSR соединена несколькими каналами и совместно используют общее пространство меток, например, несколько PPP-соединений между парой маршрутизаторов. В этой ситуации сообщения Hello, которые посылает LSR по каждому из каналов, имеют один и тот же идентификатор LDP.

LDP имеет механизмы выявления необходимости LDP-сессии и ее Hello-сопредельностей.

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

Поддержка сессий LDP

LDP имеет механизмы мониторирования целостности LDP сессии. LDP использует получение регулярных LDP PDU откликов для контроля целостности сессии. LSR управляет таймером KeepAlive для каждой партнерской сессии. Таймер сбрасывается всякий раз при получении от партнера LDP PDU. Если время KeepAlive таймера истечет до получения от партнера LDP PDU, LSR считает, что транспортное соединение отказало или партнер вышел из строя, и завершает LDP сессию, разрывая транспортное соединение.

(рис 12.1) Диаграмма состояний при инициализации сессии

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

LSR может решить прервать LDP сессию с партнером в любой момент. Если LSR принял такое решение, ему следует проинформировать партнера об этом с помощью сообщения Shutdown.

Рассылка меток и управление

Архитектура MPLS [RFC-3031] позволяет LSR рассылать данные о соответствии FEC и метки в ответ на прямой запрос другого LSR. Это называется рассылкой меток вниз по течению по запросу (Downstream On Demand). Это также позволяет LSR рассылать метки LSR, которые не запрашивали этого явно. [RFC-3031] называет этот метод рассылки меток свободной рассылкой вниз по течению (Unsolicited Downstream); здесь этот метод называется Downstream Unsolicited.

Оба эти метода рассылки могут работать в одной и той же сети одновременно. Однако, для любой заданной LDP сессии каждый LSR должен знать о методе рассылки меток, используемом его партнером, для того чтобы избежать ситуации, когда партнер, применяющий рассылку меток посредством Downstream Unsolicited, предполагает, что и его партнер делает то же самое.

Режим управления рассылкой меток

Поведение исходной конфигурации LSP определяется тем, работает ли LSR в режиме независимого или упорядоченного управления LSP. LSR может поддерживать оба типа управления.

При независимом управлении LSP каждый LSR может анонсировать метки своим соседям в любое время, когда он этого захочет. Например, работая в независимом режиме Downstream on Demand, LSR может отвечать на запросы присвоения меток немедленно, не дожидаясь присвоения меток со стороны ближайшего узла. При работе в независимом режиме Downstream Unsolicited, LSR может анонсировать присвоение меток для FEC своим соседям всякий раз, когда он готов осуществлять коммутацию для заданного FEC.

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

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

FEC относится к самому LSR (включая один из непосредственно связанных с ним интерфейсов);

маршрутизатор следующего шага для FEC находится за пределами сети с коммутацией по меткам;

элементы FEC достижимы при пересечении границы маршрутного домена, такого, как другая область сети OSPF или другая внешняя автономная система для OSPF и маршруты BGP [RFC-2328] [RFC-1771].

Заметим: тот факт, что LSR является выходным для данного FEC, может измениться со временем в зависимости от состояния сети и конфигурации LSR.

Режим сохранения метки (Retention)

Архитектура MPLS [RFC-3031] вводит нотацию режима сохранения метки, которая специфицирует, поддерживает ли LSR соответствие меток для FEC, полученных от соседа, который не является следующим шагом для FEC.

В режиме Downstream Unsolicited, анонсирование меток всем маршрутизаторам может осуществляться всеми партнерами LSR. При использовании консервативного сохранения меток анонсированные метки сохраняются, только если они будут применены для переадресации пакетов (т.e., если они получены от корректного следующего узла маршрута). При работе в режиме Downstream on Demand LSR будет запрашивать метку только у LSR следующего шага согласно действующей маршрутизации. Так как режим Downstream on Demand в основном нужен, когда сохранение меток желательно (например, ATM-коммутатор с ограниченной зоной коммутаций), он обычно используется в режиме консервативного сохранения меток.

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

В режиме Downstream Unsolicited выделение меток для всех маршрутов может осуществляться всеми LDP-партнерами. При использовании свободного режима сохранения меток каждая метка, присвоенная партнером LSR, сохраняется вне зависимости от того, является ли LSR узлом следующего шага для анонсированного соответствия. При работе в режиме Downstream on Demand со свободным сохранением меток LSR может запросить выделения меток для всех известных префиксов от всех партнеров LSR. Заметим, однако, что режим Downstream on Demand обычно используется для таких устройств, как ATM-коммутаторы, для которых рекомендуется консервативный подход.

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

Режим анонсирования меток

Каждый интерфейс LSR сконфигурирован для работы в режиме анонсирования как Downstream Unsolicited, так и Downstream on Demand. LSR обмениваются данными о режимах анонсирования на фазе инициализации. Главное отличие между режимами Downstream Unsolicited и Downstream on Demand определяется тем, какой LSR берет на себя ответственность за инициализацию запросов выделения меток и их анонсирование.

Идентификаторы LDP и адреса следующего шага

LSR сохраняет полученные метки в информационной базе данных меток LIB (Label Information Base). При работе в режиме Downstream Unsolicited запись в LIB для адресного префикса ассоциирует набор пар (идентификатор LDP, метка) с префиксом, по одной записи для пары партнеров, анонсирующих метку для префикса.

Когда следующий шаг для префикса меняется, LSR должен извлечь соответствующую запись из LIB, чтобы выявить следующий шаг для переадресации. Чтобы получить метку, LSR должен быть способен установить соответствие между адресом следующего шага для префикса и идентификатором LDP.

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

Чтобы LSR мог установить соответствие между идентификаторами партнеров LDP и их адресами, LSR передают свои адреса, используя сообщения Address и Withdraw Address (отзыв адреса).

LSR посылает сообщение Address, чтобы предоставить свой адрес партнеру. LSR посылает сообщение Withdraw Address, чтобы отозвать адрес, присланный ранее партнеру.

Детектирование петель

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

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

TLV вектора пути содержит список LSR, через которые проходит сообщение, его содержащее. LSR идентифицируется в списке вектора с помощью уникальных Id LSR, которые являются первыми четырьмя октетами идентификатора его LDP. Когда LSR передает сообщение, содержащее TLV вектора пути, он добавляет в список вектора пути свой идентификатор (Id LSR). LSR, который получает сообщение с вектором пути, содержащим его Id, и регистрирует, что сообщение прошло по замкнутому пути (по петле). LDP поддерживает понятие максимально допустимой длины вектора пути. LSR, который детектирует, что вектор пути достиг максимальной длины, поступает так же, как в случае регистрации петлевого маршрута;

TLV числа шагов содержит число LSR, которые прошло сообщение, где он располагается. Когда LSR пересылает сообщение, содержащее TLV числа шагов, он увеличивает это число на 1. LSR, который регистрирует, что число шагов достигло заданного при конфигурации максимума, ведет себя так, как если бы была зарегистрирована петля. Согласно договоренности, число 0 интерпретируется как неизвестное число шагов. Инкрементирование такого значения сохраняет его величину ( unknown =0 ).

Заметим, что TLV числа шагов и его процедуры используются без TLV вектора пути в ситуации, когда детектирование петель не предусмотрено на уровне конфигурации (смотри [RFC-3035] и [RFC-3034]).

Сообщение запроса метки

Применение TLV вектора пути и числа шагов предотвращает зацикливание сообщений запросов метки в среде, которая содержит LSR, не поддерживающие объединение меток (nonmerge).

Правила, которые управляют использованием TLV числа шагов в сообщениях запроса метки, посланных LSR R (детектирование петель активировано), представлены ниже.

Сообщение запроса метки должно включать в себя TLV числа шагов.

Если R посылает запрос метки, из-за того, что он является входным, он должен включить в сообщение TLV числа шагов со значением, равным 1.

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

Правила, которые управляют использованием TLV вектора пути в сообщениях запроса метки, посылаемых LSR R (детектирование петель активировано), представлены ниже.

Если R посылает запрос метки, из-за того, что он является входным, тогда, если R не поддерживает объединение меток, он должен включить TLV вектора длины со значением 1, содержащее его собственный идентификатор LSR Id.

Если R посылает запрос метки как результат получения запроса метки от вышестоящего LSR, тогда, если полученный запрос содержит TLV вектора длины или если R не поддерживает объединение меток, то: R должен добавить к вектору пути собственный ID LSR и передать полученный вектор пути узлу следующего шага в сообщении запроса метки. Если запрос метки не содержит TLV вектора пути, R должен включить TLV вектора пути со значением 1 со своим идентификатором LSR ID.

Заметим, что если R получает сообщение запроса метки для конкретного FEC, а R уже послал ранее запрос метки для этого FEC своему партнеру следующего шага и не получил пока отклика, и, если R намерен объединить вновь полученный запрос метки с существующим незавершенным запросом, тогда R не пересылает этот запрос узлу следующего шага.

Если R получает сообщение запроса метки от узла следующего шага с TLV числа шагов, которое превышает сконфигурированный максимум, или с TLV вектора пути, содержащий его собственный ID или превышающий допустимый предел длины, тогда R считает, что запрос метки прошел через петлю.

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

Сообщение присвоения метки (Mapping)

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

Правила, которые управляют использованием TLV числа шагов в сообщениях выделения меток, посланных LSR R, когда активизировано детектирование петель, рассмотрены ниже.

R должен включать TLV числа шагов.

Если R является выходным, значение числа шагов должно быть равно 1.

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

если R входит в набор LSR домена, чьи LSR не выполняют декрементацию TTL (например, область ATM LSR или домен Frame Relay LSR), а партнер выше по течению находится в этой области, то R должен сделать число шагов равным 1, прежде чем пересылать сообщение дальше;

в противном случае, R должен инкрементировать число шагов, полученное от соседа, прежде чем пересылать сообщение дальше.

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

Любое сообщение присвоения меток может содержать TLV вектора пути. Правила, которые управляют обязательным использованием TLV вектора пути в сообщениях присвоения меток, посланных LSR R, когда активировано детектирование петель, изложены ниже.

Если R является выходным, сообщение выделения метки не обязано содержать TLV вектора пути.

Если R посылает сообщение выделения метки с целью дальнейшей рассылки метки, полученной от вышестоящего соседа, тогда:

если R может объединять метки и если R не посылал ранее сообщений присвоения метки партнеру выше по течению, тогда он должен включить TLV вектора маршрута;

если полученное сообщение содержит неизвестное число шагов, тогда R должен включить TLV вектора пути;

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

Если вышеприведенные правила требуют от R включить в сообщение присвоения метки TLV вектора пути, R вычисляет его следующим образом.

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

Если полученное сообщение не имеет вектора пути, то вектор пути, посланный вверх по течению, должен иметь длину, равную 1, и содержать идентификатор R ID.

Если сообщение присвоения метки не было послано для распространения вверх по течению, сообщение присвоения метки должно включать вектор пути с длиной 1 и идентификатор R ID.

Если R получает от узла сообщение присвоения метки либо с TLV числа шагов, которое превышает сконфигурированный максимум, либо с TLV вектора пути, содержащим свой собственный LSR ID или имеющим длину, превышающую максимально допустимое значение, тогда R считает, что соответствующий LSP содержит петлю.

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

Если желательно детектирование петель в домене MPLS, то оно должно быть активировано во всех LSR в пределах этой области MPLS, в противном случае детектирование петель не будет работать корректно и может привести к пропуску петель или к ложному детектированию петель.

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

Заметим, что в сети, где присутствуют только LSR без возможности объединения, векторы пути передаются вниз по течению от входа к выходу и не передаются вверх по течению. Даже когда объединение меток поддерживается, векторы пути не передаются вверх по течению вдоль LSP. Когда для LSR меняется узел следующего шага, необходимо передавать векторы пути вверх по течению, только если невозможно судить по числу шагов, что изменение следующего шага не приведет к образованию петли.

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

Аутентичность и целостность сообщений LDP

Механизм защиты от введения фальсифицированных TCP-сегментов в потоки соединений LDP-сессии базируется на применении опции подписи TCP MD5, описанной в [RFC-2385] для BGP.

Использование LDP опции подписи TCP MD5

LDP использует опцию подписи TCP MD5 следующим образом.

Применение подписи MD5 для TCP-соединений является конфигурируемой опцией LSR.

LSR, который задействует опцию подписи MD5, конфигурируется с привлечением пароля (совместно используемый секретный ключ) для каждого потенциального партнера LDP.

LSR применяет алгоритм MD5, как это специфицировано в [RFC-2385], чтобы вычислить дайджест MD5 для TCP-сегмента, посылаемого партнеру. При этом вычислении используется пароль партнера и сам TCP-сегмент.

Когда LSR получает TCP-сегмент с дайджестом MD5, он проверяет сегмент, вычисляя дайджест MD5 (используя свою запись пароля) и сравнивает вычисленный дайджест с полученным. Если сравнение неудачно, сегмент отбрасывается, а отклик отправителю не посылается.

LSR игнорирует сообщения LDP Hello от любого LSR, для которого не был сконфигурирован пароль. Это гарантирует, что LSR устанавливает TCP-соединение только с LSR, для которого пароль был задан.

Рассылка меток для LSP, маршрутизированных явно

Управление трафиком [RFC-2702] важно для MPLS-приложений. Протокол MPLS для управления трафиком поддерживает LSP, маршруты которых сформированы явно и которые не должны следовать традиционным маршрутам, формируемым по схеме шаг-за-шагом согласно маршрутным протоколам, базирующимся на адресе места назначения.

Спецификация протокола

Обмены сообщениями LDP осуществляются путем посылки протокольных данных LDP (PDU) через LDP-секцию TCP-соединений.

Каждый LDP PDU может содержать более одного LDP-сообщения. Заметим, что сообщения в LDP PDU не обязательно должны быть связанными. Например, один PDU может содержать сообщение анонсирования FEC-метки для нескольких FEC, другое сообщение может относиться к запросу меток для ряда других FEC, а третье может быть предупреждением, сигнализирующим о каком-то событии.

LDP PDU

Каждый LDP PDU представляет собой LDP-заголовок, за которым следует одно или более LDP-сообщений. LDP-заголовок имеет формат (рис. 12.2):

(рис 12.2)

Версия

Двухоктетное целое число без знака, содержащее код номера версии протокола. Здесь описывается версия протокола LDP 1.

Длина PDU

Двухоктетное целое число, специфицирующее общую длину PDU в октетах, исключая поля версии и длины PDU.

Максимально допустимая длина PDU согласуется, когда инициализируется сессия LDP. До завершения согласования максимально допустимая длина равна 4096 байтов.

Идентификатор LDP

Шестиоктетное поле, однозначно идентифицирующее пространство меток LSR-отправителя, для которого это PDU используется. Первые четыре октета идентифицируют LSR и должны быть глобально уникальными. Это должен быть 32-битовый Id маршрутизатора, присвоенный LSR и используемый также для идентификации при детектировании петель в векторах пути. Последние два октета идентифицируют пространство меток заданного LSR. Для пространства меток, ориентированного на платформу, эти два октета должны равняться нулю.

Процедуры LDP

LDP определяет сообщения, TLV и процедуры в следующих областях:

выявление партнера;

управление сессией;

рассылка меток;

уведомление об ошибках и справочная информация.

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

Кодирование TLV (тип-длина-значение)

LDP использует для кодирования информации, транспортируемой в LDP-сообщениях, схему TLV ( TypeLengthValue = тип-длина-значение ).

LDP TLV кодируется как 2-октетное поле, которое использует 14 бит для спецификации типа и 2 бита для спецификации поведения, когда LSR не распознает поле тип; далее следуют 2 октета поля длины, поле значение имеет переменную длину (рис. 12.3).

(рис 12.3)

U бит

Бит неизвестного TLV. При получении неизвестного TLV, если U=0, отправителю сообщения следует послать предупреждение, а сообщение должно быть проигнорировано; если U=1, неизвестное TLV молча игнорируется, а остальное сообщение обрабатывается, как будто неизвестного TLV нет.

F бит

Бит переадресации неизвестного TLV. Этот бит используется лишь в случае, когда U=1 и сообщение LDP, содержащее неизвестный TLV, нужно переадресовать. Если F=0, неизвестный TLV не переадресуется вместе содержащим его сообщением; если F=1, неизвестный TLV переадресуется.

Тип

Определяет, как следует интерпретировать поле значение.

Длина

Специфицирует длину поля значение в октетах.

Значение

Строка октетов с длиной, определяемой полем длина, где закодирована информация согласно содержимому поля тип.

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

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

Некоторые TLV, определенные для LDP, аналогичны некоторым другим. Например, существует TLV общей метки, TLV метки ATM и TLV Frame Relay.

Кодирование TLV для универсальных параметров

Существует несколько параметров, используемых более чем одним LDP сообщением. Кодирование TLV для этих совместно используемых параметров специфицировано далее.

FEC TLV

Метки связаны с FEC (Forwarding Equivalence Class). FEC представляет собой список из одного или более элементов FEC. TLV FEC кодирует значения FEC. Формат представления FEC показан ниже (рис. 12.4):

(рис 12.4)

Элементы FEC от 1 до n

Существует несколько типов элементов FEC. Кодирование элементов FEC зависит от типа элемента.

Значение элемента FEC кодируется как однооктетное поле, которое специфицирует тип элемента, и поле переменной длины, которое представляет собой значение элемента, зависящее от типа. Заметим, что в то время как представление значения элемента FEC зависит от типа, представление самого элемента FEC является единственным, где стандартное кодирование LDP TLV не используется.

Значения элемента FEC кодируются следующим образом (таблица 12.2).

название элемента FeC	Тип	значение
Wildcard	0x01	Нет значения; т.e., 0 октетов значения; смотри ниже
Префикс	0x02	Смотри ниже
Адрес ЭВМ	0x03	Полный адрес ЭВМ; смотри ниже

Заметим, что эта версия LDP поддерживает использование нескольких элементов FEC на один FEC для сообщения присвоения метки.

Элемент Wildcard FEC

Предназначен для использования только в сообщениях присвоения и отзыва меток. Указывает, что отзыв/присвоение следует применить ко всем FEC, ассоциированным с меткой в пределах следующего TLV метки. Кодирование значений элементов префикса FEC представлено ниже на рис. 12.5:

(рис 12.5)

Семейство адресов

Двухоктетная величина, содержащая значение из списка кодов семейств адресов (смотри [RFC-1700]), которое характеризует семейство адресов для адресного префикса в поле префикс.

PreLen

Однооктетное целое без знака, содержащее длину в битах последующего адресного префикса. Длина, равная 0, говорит о том, что префикс соответствует всем адресам (адрес назначения по умолчанию); в этом случае сам префикс имеет нуль октетов.

Префикс

Адресный префикс, закодированный согласно полю семейство адресов, чья длина в битах была специфицирована в поле PreLen, дополненному до границы, кратной байту.

Элемент FEC адреса ЭВМ имеет формат, описанный ниже на рис. 12.6:

(рис 12.6)

Семейство адресов

Длина адреса ЭВМ

Длина адреса ЭВМ в октетах.

Адрес ЭВМ

Адрес, закодированный согласно полю семейство адресов.

Процедуры FEC

Если при декодировании FEC TLV LSR сталкивается с элементом FEC семейства адресов, который он не поддерживает, он должен прервать декодирование, прервать обработку сообщения, содержащего TLV, и послать LDP партнеру уведомление "Unsupported Address Family" (неподдерживаемое семейство адресов), сигнализирующее об ошибке.

Если он сталкивается с типом элемента FEC, который он не может декодировать, ему следует прервать декодирование FEC TLV, прервать обработку сообщения, содержащего TLV, и послать LDP партнеру уведомление "Unknown FEC" (неизвестный FEC), сигнализируя об ошибке.

TLV-метки

TLV-метки предназначены для кодирования меток. TLV-метки содержатся в сообщениях, используемых для анонсирования, запроса и отзыва меток.

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

TLV типовой метки

LSR использует TLV типовой метки для кодирования меток, предназначенных для использования в каналах, где значения меток не зависят от канальной технологии. Примерами таких каналов могут служить PPP и Ethernet. Формат представлен на рис. 12.7.

(рис 12.7)

Метка

Это 20-битовый код метки, как это специфицировано в [RFC-3032]. Размещается в 4-октетном поле.

TLV меток ATM

LSR применяет TLV ATM метки для кодирования меток, используемых в каналах ATM (рис. 12.8).

(рис 12.8)

Res

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

V-биты

Два бита переключаемых индикаторов. Если V -биты равны 00, используются как VPI, так и VCI. Если V -биты равны 01, только поле VPI имеет значение. Если V-биты = 10, значение имеет только VCI.

VPI

Идентификатор виртуального пути. Если VPI меньше 12-бит, он должен быть выровнен в поле по правому краю, а свободные левые биты следует заполнить нулями.

VCI

Идентификатор виртуального канала (Virtual Channel Identifier). Если VCI имеет менее 16 бит, его следует выровнять по правому краю, а свободные левые биты заполнить нулями. Если V -биты указывают на коммутацию виртуального пути, тогда это поле должно игнорироваться получателем и устанавливаться равным нулю отправителем.

TLV для меток в Frame Relay

LSR использует TLV метки Frame Relay, чтобы закодировать метки для каналов Frame Relay (рис. 12.9).

(рис 12.9)

Res

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

Len

Это поле специфицирует число бит DLCI. Поддерживаются следующие значения:

0 = 10 бит DLCI

2 = 23 бит DLCI

Значения Len 1 и 3 зарезервированы.

DLCI

Идентификатор соединения канала данных (Data Link Connection). По вопросам значения меток и их форматов отсылаем в [RFC-3034].

TLV списка адресов

TLV списка адресов встречаются в сообщениях адреса и отзыва адреса.

Семейство адресов

Двухоктетная величина, содержащая код семейства адресов, (смотри [RFC-1700]), которая определяет схему кодирования поля адреса.

Адреса

Список адресов из специфицированного семейства. Представление индивидуального адреса зависит от типа семейства адресов.

Следующие представления адресов определены данной версией протокола.

Семейство адресов	Кодирование адресов
IPv4	4 октета полного IPv4-адреса
IPv6	16 октетов полного IPv6-адреса

TLV числа шагов

TLV числа шагов является опционным полем в сообщениях, которые формируют LSP. Здесь на фазе формирования LSP LSR определяет число шагов (см. рис. 12.11).

Заметим, что процедуры формирования LSP, которые проходят через каналы ATM и Frame Relay, требуют использования TLV числа шагов (смотри [RFC-3035] и [RFC-3034]).

(рис 12.11)

Значение HC

1 октетное целое число без знака равное числу шагов.

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

Если LSR R пересылает сообщение присвоения метки для LSP вышестоящему партнеру или запрос метки партнеру вниз по течению, он должен определить число шагов, чтобы включить его в передаваемые сообщения.

Если это сообщение запроса метки, R должен инкрементировать полученное значение числа шагов.

Если это сообщение присвоения метки, R определяет число шагов следующим образом:

если R является одним из пограничных LSR домена, где не производится декрементация TTL, а вышестоящий партнер находится внутри домена, то R, прежде чем пересылать сообщение, должен сбросить счетчик числа шагов в 1;

в противном случае, R должен инкрементировать полученное число шагов.

Первый LSR в LSP (вход для сообщения запроса метки, выход для сообщения присвоения метки) должен устанавливать счетчик числа шагов равным 1.

По соглашению значение 0 говорит, что число шагов неизвестно. Результатом инкрементации неизвестного числа шагов остается значение 0.

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

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

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

TLV вектора пути

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

Один или более LSR Id

Список id маршрутизаторов, характеризующий путь, который прошло сообщение LSR. Каждый LSR Id представляет собой первые четыре октета ( id маршрутизатора) идентификатора LDP для соответствующего LSR. Это гарантирует уникальность идентификатора в пределах сети LSR.

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

Раздел "детектирование петель" специфицирует ситуации, когда LSR должен включить TLV вектора пути в сообщение запроса метки.

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

LSR должен:

послать сообщение уведомления LSR-отправителю, сигнализируя обнаружение петли;

не передавать дальше сообщение запроса метки.

Заметим, что сообщение запроса метки с TLV вектора пути переадресуется до тех пор, пока:

не будет найдена петля;

не будет достигнут конец LSP;

не будет достигнут верхний предел длины вектора пути или числа шагов. Это обрабатывается, как если бы была детектирована петля пути.

Вектор пути в случае присвоения метки

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

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

передать LSR-отправителю сообщение освобождения метки (Label Release), несущее в себе TLV статуса, сигнализируя о детектировании петли;

не передавать сообщение дальше;

проверить, относится ли сообщение присвоения метки к существующему LSP. Если это так, LSR должен разъединить любые метки выше по течению, которые объединены для области вниз по течению для заданного FEC.

Заметим, что сообщение присвоения метки с TLV вектора расстояния переадресуется до тех пор, пока:

не будет обнаружена петля;

не будет достигнуто начало LSP, или

достигнут максимум вектора пути или числа шагов.

TLV статуса

Сообщения уведомления несут в себе TLV статуса, чтобы специфицировать события, о которых уведомляется адресат. Кодирование TLV состояния показано ниже (рис. 12.13):

(рис 12.13)

U бит

Должно быть равно нулю, когда TLV статуса послано в сообщении уведомления. Должно быть равно 1, когда TLV статуса послано в другом сообщении.

F бит

Должен быть тем же самым, что и в поле кода статуса.

Код статуса

32-битовое целое без знака, характеризующее событие. Структура кода статуса представлена ниже на рис. 12.14:

E бит

Бит фатальной ошибки. Если E=1, это уведомление о фатальной ошибке. Если Е=0, это сообщение-рекомендация.

F бит

Бит переадресации. Если (рис 12.14)

Статусные данные

30битовое целое число без знака, которое специфицирует статусную информацию.

Эта спецификация определяет код статуса (32-битовое целое число без знака с представлением, описанным выше). Статусный код 0 сигнализирует об успехе.

ID сообщения

Если не равно нулю, 32-битовое значение, идентифицирущее сообщение партнера, к которому относится TLV статуса. Если нуль, то сообщение партнера не идентифицировано.

Тип сообщения

Если не равно нулю, то это тип сообщения партнера, к которому относится TLV статуса. Если нуль, то TLV статуса не относится ни к какому определенному сообщению партера.

Заметим, что использование TLV статуса не ограничивается сообщениями уведомления. Сообщение, отличное от уведомления, может содержать TLV статуса в качестве опционного параметра. Когда сообщение, отличное от уведомления, содержит TLV статуса, U-бит TLV статуса должен равняться 1, чтобы индицировать, что получателю следует молча отбросить TLV, если он не готов его обработать.

10.3.5. Сообщения LDP

Все сообщения LDP имеют следующий формат (рис. 12.15):

U бит

Бит неизвестного сообщения. При получении неизвестного сообщения, если U=0, в качестве отклика отправителю посылается уведомление; если U=1, неизвестное сообщение молча игнорируется.

Тип сообщения

Идентифицирует тип сообщения

Длина сообщения

Специфицирует суммарную длину в октетах полей идентификатора сообщения, обязательных и опционных параметров.

ID сообщения

(рис 12.15)

32-битовый код, применяемый для идентификации этого сообщения. Используется LSR-отправителем, чтобы облегчить идентификацию сообщений уведомления. LSR, отправляющий сообщение уведомления в ответ на это сообщение, должен включить этот Id в TLV статуса, транспортируемый данным сообщением.

Обязательные параметры

Набор необходимых параметров, имеющий переменную длину. Некоторые сообщения не имеют обязательных параметров.

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

Опционные параметры

Набор опционных параметров сообщения, имеющий переменную длину.

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

Имя сообщения	Заголовок секции
Уведомление	Сообщение уведомления
Hello	Сообщение `Hello`
Инициализация	Сообщение инициализации
KeepAlive	Сообщение `KeepAlive`
Адрес	Сообщение адреса
Отзыв адреса	Сообщение отзыва адреса
Присвоение метки	Сообщение присвоения метки
Запрос метки	Сообщение запроса метки
Запрос ликвидации метки	Сообщение запроса ликвидации метки
Отзыв метки	Сообщение отзыва метки
Освобождение метки	Сообщение освобождения метки

Сообщение уведомления

LSR посылает сообщение уведомления, чтобы проинформировать партнера LDP о важном событии. Сообщение уведомления сигнализирует о фатальной ошибке либо предоставляет рекомендации, сопряженные с состоянием сессии или результатом обработки сообщения LDP. Формат сообщений уведомления представлен ниже на рис. 12.16:

ID сообщения

(рис 12.16)

32-битовый код, используемый для идентификации этого сообщения.

TLV статуса

Индицирует сигнализируемое событие.

Опционные параметры

Это поле переменной длины содержит нуль или более параметров, каждый из которых представляется в виде TLV. Следующие опционные параметры являются общими и могут присутствовать в любом сообщении уведомления:

Опционный параметр	Тип	Длина	Значение
Расширенный статус	0x0301	4	Смотри ниже
Присланный PDU	0x0302	Переменная	Смотри ниже
Сообщение-отклик	0x0303	Переменная	Смотри ниже

Могут появиться и другие опционные параметры, специфичные для конкретного события.

Расширенный статус

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

Присылаемый PDU

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

Возвращаемое сообщение

LSR использует этот параметр, чтобы вернуть LSR часть сообщения LDP, которое он послал. Значение этого TLV равно полям типа сообщения, длины и части сообщения, которая необходима для объяснения условия, сигнализируемого в уведомлении.

Процедуры сообщения уведомления

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

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

Информирование о событиях с помощью сообщений уведомления

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

Некорректный PDU или сообщение

Некорректно сформатированные LDP PDU или сообщения, которые являются частью механизма выявления LDP, молча отбрасываются. LDP PDU, полученный через TCP-соединение для LDP-сессии, сформатировано некорректно, если:

идентификатор LDP в заголовке PDU неизвестен получателю или известен, но не ассоциирован получателем с партнером LDP для этой сессии. Это фатальная ошибка, сигнализируемая кодом состояния Bad LDP Identifier (некорректный идентификатор);

версия протокола LDP не поддерживается получателем или поддерживается, но это не та версия, которая согласована при установлении сессии. Это фатальная ошибка, сигнализируемая кодом статуса Bad Protocol Version (плохой код версии);

поле длины PDU слишком мало (< 14) или слишком велико (> максимальной длины PDU). Это фатальная ошибка, сигнализируемая кодом состояния Bad PDU Length (неверная длина PDU).

LDP-сообщение некорректно, если:

тип сообщения неизвестен.

Если тип сообщения < 0x8000 ( старший бит = 0 ) — это ошибка, сигнализируемая кодом статуса Unknown Message Type (неизвестный тип сообщения). Если тип сообщения >= 0x8000 ( старший бит = 1 ), оно молча отбрасывается.

длина сообщения слишком велика, то есть, индицирует, что сообщение занимает места больше, чем отведено в LDP PDU. Это фатальная ошибка, сигнализируемая кодом статуса Bad Message Length (неверная длина сообщения);

в сообщении нет одного или более обязательных параметров. Это не фатальная ошибка, сигнализируемая кодом статуса Missing Message Parameters (пропущены обязательные параметры).

Неизвестный или некорректный TLV

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

TLV, содержащееся в сообщении LDP, которое получено по TCP-соединению, имеет некорректный формат, если:

длина TLV слишком велика, то есть указывает, что TLV простирается за пределы содержащего его сообщения. Это фатальная ошибка, сигнализируемая кодом статуса Bad TLV Length (неверная длина TLV);

тип TLV не известен.

Если тип TLV < 0x8000 ( старший бит 0 ) — это ошибка, сигнализируемая кодом статуса Unknown TLV (неизвестный TLV).

Если тип TLV >= 0x8000 ( старший бит 1 ) — TLV молча игнорируется;

значение TLV некорректно. Это случается, когда получатель обрабатывает TLV, но не может декодировать значение TLV. Это интерпретируется LSR как ошибка при отправке или получении.Это фатальная ошибка, сигнализируемая кодом статуса Malformed TLV Value (некорректное значение TLV).

Истечение времени таймера KeepAlive сессии

Это фатальная ошибка, сигнализируемая кодом статуса KeepAlive Timer Expired (таймер KeepAlive истек).

Одностороннее прерывание сессии

Это фатальная ошибка, сигнализируемая кодом статуса Shutdown. Сообщение уведомления может опционно включать в себя TLV расширенного статуса, чтобы объяснить причину Shutdown. LSR-отправитель завершает сессию немедленно после отправки уведомления.

События сообщения инициализации

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

События, вызванные другими сообщениями

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

Внутренние ошибки

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

Сообщение Hello

Обмен сообщениями LDP Hello является частью механизма выявления LDP. Формат представления сообщений Hello отображен ниже на рис. 12.17:

(рис 12.17)

ID сообщения

32-битовый код, используемый для идентификации этого сообщения.

Общие параметры TLV Hello

Специфицирует параметры, общие для всех сообщений Hello. Формат представления TLV для общих параметров Hello отображен ниже (рис. 12.18):

(рис 12.18)

Время удержания (Hold Time).

Время удержания Hello в секундах. LSR сохраняет записи Hello, полученные от потенциальных партнеров. Время удержания Hello специфицирует время, в течение которого LSR-отправитель будет сохранять записи Hello от LSR-получателей, без получения других Hello.

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

Значение 0 означает использование значения по умолчанию, которое равно 15 секундам для канальных Hello и 45 секунд для целевых Hello. Значение 0xffff означает бесконечность.

T, целевое Hello

Значение 1 указывает на то, что это целевое Hello. Значение 0 означает, что данное сообщение является канальным Hello.

R, Посылка целевых Hello по запросу

Значение 1 требует от получателя периодической посылки отправителю сообщений целевого Hello. Значение 0 не предполагает никаких действий.

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

Зарезервировано

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

Опционные параметры (рис. 12.17)

Это поле переменной длины содержит нуль или более параметров, каждый из которых закодирован в формате TLV. Опционные параметры, определенные данной версией протокола, перечислены ниже (таблица 12.3).

Транспортный адрес IPv4

Специфицирует адрес IPv4, который следует использовать LSR, при открытии сессии LDP через TCP-соединение. Если этот опционный TLV отсутствует, следует использовать адрес отправителя IPv4 из UDP-пакетов, несущих сообщение Hello.

опционный параметр	Тип	Длина	значение
Транспортный адрес IPv4	0x0401	4	Смотри ниже
Последовательный номер конфигурации	0x0402	4	Смотри ниже
Транспортный адрес IPv6	0x0403	16	Смотри ниже

Последовательный номер конфигурации

Специфицирует 4-октетное число без знака, которое является последовательным номером конфигурации LSR-отправителя. Применяется принимающим LSR, чтобы определить изменения конфигурации LSR отправителя.

Транспортный адрес IPv6

Специфицирует адрес IPv6, который следует использовать LSR при открытии сессии LDP через TCP-соединение. Если этот опционный TLV отсутствует, следует задействовать адрес отправителя IPv6 из UDP-пакетов, несущих сообщение Hello.

Процедуры сообщения Hello

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

Мы рекомендуем, чтобы интервал между посылками Hello составлял не более одной трети от времени удержания Hello. LSR обрабатывает полученные LDP Hello следующим образом:

LSR проверяет, приемлемо ли сообщение Hello. Критерии определения приемлемости Hello зависят от конкретной реализации;

если Hello неприемлемо, LSR его игнорирует;

если Hello приемлемо, LSR проверяет, имеет ли он сопредельность для отправителя Hello. Если да, то он перезапускает таймер удержания. Если нет, то он формирует сопредельность для Hello отправителя и перезапускает таймер;

если Hello несет в себе какой-либо опционный TLV, LSR обрабатывает его;

наконец, если LSR не имеет сессий LDP для пространства меток, специфицированного идентификатором LDP в заголовке PDU сообщения Hello, он следует процедурам из раздела "Установление сессии LDP".

Ниже представлены критерии приемлемости для сообщений канального и целевого Hello:

Канальное Hello приемлемо, если интерфейс, через который оно получено, сконфигурирован для коммутации по меткам. Целевое Hello, поступившее от отправителя с адресом A приемлемо, если:

LSR был сконфигурирован для приема целевых Hello, или

LSR был сконфигурирован посылать целевые Hello по адресу A.

Далее описано, как LSR обрабатывает опционные TLV Hello.

Транспортный адрес

LSR ассоциирует специфицированные транспортные адреса с сопредельностью Hello.

Порядковый номер конфигурации

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

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

Сообщение инициализации

Обмен сообщениями инициализации LDP является частью процедуры установления сессии LDP. Формат сообщения инициализации представлен ниже (рис. 12.19):

(рис 12.19)

ID сообщения

32-битовый код, используемый для идентификации этого сообщения.

TLV общих параметров сессии

Специфицирует значения, предлагаемые LSR-отправителем для параметров, которые должны быть согласованы для каждой сессии LDP.

Кодирование TLV общих параметров сессии рассмотрено ниже (рис. 12.20):

(рис 12.20)

Версия протокола

Двухоктетное целое число без знака, содержащее номер версии протокола.

Время KeepAlive

Двухоктетное, не равное нулю целое число без знака, определяющее число секунд, которое LSR-отправитель предлагает в качестве значения времени KeepAlive. LSR-получатель должен вычислить значение для таймера KeepAlive, используя меньшее из предложенных значений KeepAlive. Выбранное значение для времени KeepAlive указывает максимальное число секунд, которое может пройти между получением последовательных PDU от партнера LDP через TCP-соединение. Таймер KeepAlive сбрасывается при каждом приходе PDU.

A, порядок анонсирования меток

Индицирует тип анонсирования меток. A=0 означает анонсирование Downstream Unsolicited; значение = 1 означает Downstream On Demand.

Когда один LSR предлагает Downstream Unsolicited, а другой предлагает Downstream on Demand, правила разрешения конфликта таковы:

если сессия сформирована для ATM или Frame Relay с коммутацией по меткам, то должен использоваться режим Downstream on Demand;

в противном случае применяется режим Downstream Unsolicited.

Если порядок анонсирования, определенный таким способом, для LSR не приемлем, он в ответ на сообщение инициализации должен послать сообщение уведомления о том, что режим анонсирования сессии отвергнут; сессия при этом не устанавливается.

D, детектирование петель

Индицирует, активизировано ли детектирование петель в векторе пути. Значение 0 означает, что детектирование петель заблокировано; значение 1 означает, что детектирование петель активизировано.

PVLim, ограничение вектора пути

Конфигурируемая максимальная длина вектора пути. Должна равняться 0, если детектирование петель блокировано ( D=0 ). Если процедуры детектирования петель потребуют от LSR посылки вектора пути, длина которого превышает это ограничение, LSR будет себя вести, как если бы для заданного FEC была детектирована петля.

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

Резерв

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

Макс. длина PDU

Двухоктетное целое без знака, которое предлагает максимально допустимую длину LDP PDU сессии. Значение 255 или меньше специфицирует максимальную длину по умолчанию — 4096 октетов.

LSR-приемник должен вычислить максимальную длину PDU для сессии, взяв минимальное из своего значения и предложения партнера. Значение по умолчанию для максимальной длины PDU, использованное до инициализации сессии, более не работает.

Если максимальная длина PDU, определенная таким путем, неприемлема для LSR, он должен послать в ответ на сообщение инициализации уведомление о конфликте со значением длины PDU (Session Rejected/Parameters Max PDU Length) и не устанавливать сессию.

Идентификатор LDP получателя

Идентифицирует пространство меток получателя. Этот идентификатор LDP, совместно с идентификатором отправителя в заголовке PDU, позволяет получателю согласовать сообщение инициализации с одной из его сопредельностей Hello.

Если приемлемых сопредельностей Hello нет, LSR должен послать в ответ на сообщение инициализации сообщение уведомления "Session Rejected/No Hello" и не устанавливать сессию.

Опционные параметры

Это поле переменной длины содержит нуль или более параметров, каждый из которых закодирован согласно формату TLV. Опционными параметрами являются (таблица 12.4).

опционный параметр	Тип	Длина	значение
Параметры сессии ATM	0x0501	переменная	Смотри ниже
Параметры сессии Frame Relay	0x0502	переменная	Смотри ниже

Параметры сессии ATM

Используется, когда сессия LDP управляет обменом меток в АТМ-канале, для задания специфических параметров ATM-сессии.

(рис 12.21)

M, возможности объединения в ATM

Специфицирует объединение возможностей коммутаторов ATM. В данной спецификации поддерживаются следующие значения (таблица 12.5)

величина	назначение
0	Объединение не поддерживается
1	Поддерживается объединение VP
2	Поддерживается объединение VC
3	Поддерживается объединение VP VC

Если объединяющие свойства LSR различны, то:

не объединяющие и VC-объединяющие LSR могут легко работать совместно;

совместная работа коммутаторов, допускающих объединение VP, с коммутаторами, не поддерживающими объединение VP, является объектом будущего изучения. Когда LSR отличаются по использованию объединения VP, сессия устанавливается, но объединение VP не используется;

заметим, что если объединение VP используется, входной узел несет ответственность за уникальность выбора VCI в домене LSR (смотри [ATM-VP]).

N, число компонент диапазона меток

Определяет число компонент диапазона меток ATM, включенных в TLV.

D, использование VC по направлениям

Значение 0 специфицирует двунаправленную способность VC, то есть способность LSR (в пределах данного VPI) поддерживать использование этого VCI в качестве метки для обмена через канал в обоих направлениях независимо. Значение 1 определяет однонаправленную способность VC, — возможность использования заданного VCI для переадресации по меткам только для одного направления канала. Когда один из или оба партнера специфицируют однонаправленную способность, оба LSR применяют однонаправленную технику коммутации по меткам. LSR сравнивают свои идентификаторы LDP как целые числа без знака. LSR с большим идентификатором LDP может присваивать только нечетные значения VCI в диапазоне меток VPI/VCI. Система с меньшим идентификатором LDP может присваивать только четные значения VCI в диапазоне меток VPI/VCI.

Зарезервировано

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

Один или более компонентов диапазона меток ATM

Список компонентов диапазона меток ATM, которые в совокупности специфицируют диапазон меток, поддерживаемый LSR-отправителем.

LSR-приемник должен вычислить пересечение между приемным диапазоном и своим поддерживаемым диапазоном меток. Пересечение представляет собой диапазон, в котором LSR может присваивать и воспринимать метки. LSR не должны устанавливать сессии с соседом, для которого область пересечения диапазонов равна нулю. В этом случае LSR должен в ответ на сообщение инициализации послать сообщение уведомления "Session Rejected/Parameters Label Range" и не устанавливать сессию. Формат представления компонента диапазона меток для ATM отображен ниже (рис. 12.22):

Res

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

Минимум VPI (12 бит)

Это 12-битное поле специфицирует нижнюю границу блока идентификаторов виртуального пути, который поддерживается на исходном коммутаторе.(рис 12.22) Если VPI меньше 12 бит, он должен быть выровнен по правому краю, освободившиеся левые биты заполняются нулями.

Минимум VCI (16 бит)

Это 16-битное поле специфицирует нижнюю границу блока идентификаторов виртуального пути, который поддерживается исходным коммутатором. Если VCI меньше 16 бит, он должен быть выровнен по правому краю, освободившиеся левые биты заполняются нулями.

Максимум VPI(12 бит)

Это 12 битное поле специфицирует верхнюю границу блока идентификаторов виртуального пути, который поддерживается на исходном коммутаторе.

Максимум VCI (16 бит)

Это 16-битовое поле специфицирует верхнюю границу блока идентификаторов виртуального соединения, который поддерживается исходным коммутатором.

Когда партнеры LSR не соединены непосредственно ATM VP, LSR-отправитель должен установить минимум и максимум поля VPI равным 0, а LSR-получатель должен игнорировать минимум и максимум полей VPI.

Сообщение KeepAlive

LSR посылает сообщения KeepAlive в качестве части механизма, который мониторирует целостность транспортного соединения LDP сессии. Кодирование сообщения KeepAlive представлено ниже (рис. 12.23):

(рис 12.23)

ID сообщения

32-битовое значение, используемое для идентификации этого сообщения.

Опционные параметры

Для сообщения KeepAlive не определено опционных параметров.

Процедуры сообщения KeepAlive

Механизм таймера KeepAlive, рассмотренный в разделе "Поддержка LDP сессий", сбрасывает таймер KeepAlive каждый раз, когда приходит LDP PDU через TCP-соединение сессии. Сообщение KeepAlive предназначено для сброса таймера KeepAlive в обстоятельствах, где LSR не имеет другой информации для обмена с LDP-партнером.

LSR должен позаботиться, чтобы партнер получал от него сообщение, по крайней мере, раз за период KeepAlive. Любое протокольное сообщение LDP годится. В обстоятельствах, когда никакие другие протокольные LDP сообщения не посылаются в течение этого периода, рекомендуется посылать сообщение KeepAlive.

Сообщение Address

LSR посылает сообщение Address партнеру LDP, чтобы анонсировать его адреса интерфейсов. Кодирование сообщения Address представлено ниже (рис. 12.24):

ID сообщения

(рис 12.24)

32-битовый код идентифицирующий это сообщение.

TLV списка адресов

Список адресов интерфейсов, анонсированных LSR-отправителем.

Опционные параметры

Для сообщения адреса опционные параметры не предусмотрены.

Процедуры сообщений Address

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

Когда инициализирована новая LDP сессия, перед тем как послать сообщение присвоения и запроса метки, LSR должен анонсировать адреса своих интерфейсов в одном или более сообщениях Address.

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

Всякий раз, когда LSR деактивирует ранее анонсированный адрес, ему следует отозвать адрес с помощью сообщения отзыва адреса (Address Withdraw).

Если LSR не поддерживает семью адресов, специфицированную в TLV списка адресов, он должен послать уведомление "Unsupported Address Family", сигнализируя об ошибке, и прервать обработку сообщения.

Сообщение отзыва адреса (Address Withdraw)

LSR посылает партнеру LDP сообщение отзыва адреса, чтобы отозвать ранее анонсированные адреса интерфейсов. Формат сообщения отзыва адреса представлен ниже на рис. 12.25:

(рис 12.25)

ID сообщения

32-битовый код, используемый для идентификации этого сообщения.

TLV списка адресов

Список адресов интерфейсов, подлежащих отзыву, для LSR-отправителя.

Опционные параметры

Для сообщения адреса опционные параметры пока не предусмотрены.

Сообщение присвоения метки (Label Mapping)

LSR посылает сообщение присвоения метки (Label Mapping) партнеру LDP, чтобы анонсировать ему ассоциацию FEC-метка. Формат сообщения присвоения метки представлен ниже на рис. 12.26:

(рис 12.26)

ID сообщения

32-битовый код, используемый для идентификации этого сообщения.

FEC TLV

Специфицирует FEC-компонент анонсируемого ансамбля FEC-метка.

TLV метки

Специфицирует компонент Label ассоциации FEC-метка.

Опционные параметры

Это поле переменной длины содержит 0 или более параметров, каждый из которых имеет формат TLV. Опционные параметры в таблице 12.6.

опционный параметр	Длина	значение
TLV ID сообщения запроса метки	4	Смотри ниже
TLV числа шагов	1	Смотри ниже
TLV вектора пути	переменная	Смотри ниже

ID сообщения запроса метки

Если это сообщение присвоения метки является откликом на сообщение запроса метки, оно должно включать опционный параметр Id.

Число шагов

Специфицирует полное число LSR-шагов вдоль LSP, установленное сообщением Label.

Вектор пути

Сообщает LSR список узлов LSP, сформированный сообщением Label.

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

LSR ответственен за взаимную согласованность распределения меток и за информирование партнеров об этом распределении.

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

Если LSR сконфигурирован для независимого управления, сообщения установления соответствия передается LSR при выполнении любого из следующих условий.

LSR распознает новый FEC с помощью маршрутной таблицы, и используется режим анонсирования меток Downstream Unsolicited.

LSR получает сообщение запроса от вышестоящего партнера для FEC, присутствующего в маршрутной таблице LSR .

Следующий шаг для FEC изменился, и активизировано детектирование петель.

Атрибуты соответствия изменились.

Получен отклик на присвоение метки от узла следующего шага вниз по течению и:

не было установления соответствия со стороны выше по течению, или

сконфигурировано детектирование петель, или

атрибуты соответствия изменились.

Если LSR осуществляет упорядоченное управление, сообщение установления соответствия передается нижерасположенным LSR при выполнении любого из следующих условий.

LSR распознает новый FEC из маршрутной таблицы, и он является выходным для этого FEC.

LSR получает сообщение запроса от вышестоящего партнера для FEC, присутствующего в маршрутной таблице LSR, и LSR является выходным для этого FEC или имеет установленное соответствие для зоны вниз по течению.

Следующий шаг для FEC изменился и активизировано детектирование петель.

Атрибуты соответствия изменились.

Получен отклик на присвоение метки от узла следующего шага ниже по течению и:

не сформировано никакого соответствия узлом выше по течению, или

сконфигурировано детектирование петель, или

атрибуты соответствия изменились.

Анонсирование меток вниз по течению по запросу (Downstream on Demand)

Вообще, при работе в режиме Downstream on Demand (вниз по течению по запросу) вышестоящий LSR ответственен за организацию присвоения меток. Однако если не следовать определенным правилам, может так случиться, что LSR-соседи с разными режимами анонсирования попадут в ситуацию активного тупика, когда все функционирует нормально, но метки не рассылаются. Например, рассмотрим два LSR Ru и Rd, где Ru является вышестоящим LSR, а Rd — нижестоящим LSR для конкретного FEC. В этом примере Ru использует режим анонсирования Downstream Unsolicited, а Rd — режим Downstream on Demand. В этом случае Rd может предполагать, что Ru, запросит метку, когда он захочет, а Ru может предполагать, что Rd анонсирует метку, если захочет, чтобы Ru ее использовал. Если Rd и Ru работают, как это предполагается, никаких меток не будет посылаться от Rd к Ru.

Эта ситуация активного тупика может быть исключена, если следовать правилу: LSR, работающий в режиме Downstream on Demand, не должен посылать анонсирования установления добровольного соответствия меток (unsolicited mapping). Следовательно, если нижестоящий LSR работает в режиме Downstream on Demand, вышестоящий LSR ответственен за посылку запросов присвоения меток, как это требуется.

Анонсирование меток Downstream Unsolicited

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

Комбинация режима Downstream Unsolicited и консервативного удержания метки может вести к ситуации, когда LSR освобождает метку для заданного FEC, которая ему может быть нужна в будущем. Например, если LSR Rd анонсирует LSR Ru метку для FEC, для которого Ru не является следующим шагом, то Ru освободит метку. Если следующим шагом Ru для FEC позднее станет Rd, ему потребуется метка, которая была ранее освобождена.

Чтобы разрешить эту проблему, либо Ru может явно запросить метку, когда она ему нужна, либо Rd может периодически предлагать ее Ru. Во многих ситуациях Ru будет знать, когда ему нужна метка от Rd: например, когда его следующим шагом для FEC становится Rd. Однако могут возникать ситуации, когда Ru не имеет нужной информации: например, когда Rd может пытаться сформировать LSP с нестандартными свойствами. Необходимость для Ru в этой ситуации явно запросить метку потребует, чтобы он поддерживал состояния LSP с нестандартными свойствами.

В ситуациях, где Ru знает, что ему нужна метка, он ответственен за явный запрос метки посредством посылки сообщения Label Request. В ситуациях, где Ru не может знать, что ему нужна метка, Rd ответственен за периодическое анонсирование метки Ru.

Для этой версии LDP единственная ситуация, когда Ru знает, что ему нужна метка для FEC от Rd, — это когда Rd является следующим шагом для FEC, Ru не имеет метки от Rd и LSP для FEC является единственным.

Сообщение запроса метки

LSR посылает запрос метки (Label Request) партнеру LDP, чтобы установить соответствие (mapping) для FEC. Формат сообщения запроса метки представлен ниже (рис. 12.27):

(рис 12.27)

ID сообщения

32-битный код используется, чтобы идентифицировать это сообщение.

FEC TLV

FEC, для которого запрашивается метка.

Опционные параметры

Это поле переменной длины содержит 0 или более параметров, каждый из которых имеет формат TLV. Опционные параметры в таблице 12.7.

Число шагов

Специфицирует полное число LSR-шагов вдоль LSP, определяется в результате запроса метки.

Вектор пути

Специфицирует узлы вдоль LSP. Этот список сформирован посредством сообщения запроса метки.

опционный параметр	Длина	значение
TLV числа шагов	1	Смотри ниже
TLV вектора пути	переменная	Смотри ниже

Процедуры сообщения запроса метки

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

LSR из маршрутной таблицы узнает новый FEC, узлом следующего шага является партнер LDP, а LSR не имеет метки для заданного FEC.

Следующий шаг для FEC изменился, и LSR в сложившихся условиях не имеет метки для данного FEC.

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

LSR получает запрос метки для FEC от вышестоящего партнера, следующим шагом для FEC является партнер LDP, и LSR не имеет метки для следующего шага.

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

LSR-получатель должен реагировать на запрос метки сообщением присвоения метки (Label Mapping) или сообщением уведомления, объясняющим, почему он не может удовлетворить запрос.

Когда FEC, для которого запрошена метка, является префиксным FEC-элементом или FEC-элементом адреса ЭВМ, LSR-приемник использует свою маршрутную таблицу, чтобы сформировать отклик. Если его маршрутная таблица не содержит ни одного рекорда, в точности соответствующего запрошенному префиксу или адресу ЭВМ, LSR должен реагировать сообщением уведомления об отсутствии маршрута (No Route). ID сообщения запроса метки служит идентификатором для транзакции запроса метки. Когда LSR-получатель откликается присвоением метки (Label Mapping), сообщение должно включать опционный параметр TLV ID запроса/отклика, который содержит ID сообщения запроса метки. Заметим, что, так как LSR используют ID запроса метки в качестве идентификаторов транзакции, LSR не должен повторно использовать ID запроса метки до завершения соответствующей транзакции.

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

Нет маршрута

FEC, для которого запрошена метка, включает элемент, для которого LSR не имеет маршрута.

Нет ресурсов меток

LSR не может сформировать метку из-за ограниченности ресурсов. Когда ресурсов становится достаточно, LSR должен проинформировать запрашивающий LSR, послав ему уведомление со статусным кодом "Label Resources Available" (ресурсы для метки имеются). LSR, который получает отклик "No Label Resources" (ресурсов для метки нет), не должен отправлять запрос метки до тех пор, пока не получит сообщение уведомления со статусным кодом "Label Resources Available".

Детектирование петель

LSR детектировал зацикливание сообщения запроса метки.

Сообщение запроса аннулирования метки

Сообщение запроса ликвидации метки может использоваться, чтобы аннулировать определенный запрос метки. Формат сообщения запроса ликвидации метки представлен ниже на рис. 12.28:

(рис 12.28)

ID сообщения

32-битный код применяется, чтобы идентифицировать это сообщение.

TLV FEC

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

TLV сообщения запроса метки

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

Опционные параметры

Для сообщения Label Abort Req опционные параметры не предусмотрены.

Процедуры сообщения запроса ликвидации метки (Label Abort)

LSR Ru может послать сообщение запроса ликвидации метки, чтобы аннулировать определенный запрос метки для FEC, посланный в LSR Rd, при следующих обстоятельствах:

следующий шаг Ru для FEC изменился с LSR Rd на LSR X; или

Ru не поддерживает объединение, не является входным LSR и получил запрос ликвидации метки для FEC со стороны вышестоящего партнера Y;

Ru поддерживает объединение, не является входным LSR и получил запрос ликвидации метки для FEC со стороны вышестоящего партнера Y, а Y является единственным (последним) вышестоящим LSR, запрашивающим метку для данного FEC .

Могут быть другие ситуации, где LSR решит аннулировать определенный запрос метки, для того чтобы вернуть ресурсы, ассоциированные с LSP. Однако спецификация общей стратегии механизма ликвидации находится за пределами описания LDP.

Когда LSR получает сообщение запроса ликвидации метки, если он до этого не откликался на ликвидируемый запрос метки или какое-то другое сообщение уведомления, он должен подтвердить ликвидацию откликом Label Request Aborted (запрос метки ликвидирован). Уведомление должно включать TLV ID сообщения запроса метки, который несет ID ликвидированного сообщения запроса метки.

Если LSR получает сообщение запроса ликвидации метки после того, как он отреагировал на запрос метки сообщением присвоения или уведомления, он игнорирует запрос ликвидации.

Если LSR получает сообщение присвоения метки в ответ на сообщение запроса метки после того, как он послал сообщение запроса ликвидации метки, метка в сообщении присвоения (Label Mapping) корректна. LSR может решить использовать метку или освободить ее посредством сообщения Label Release.

LSR, аннулирующий запрос метки, может не посылать повторно ID-сообщения для запроса метки до тех пор, пока он не получит от своего партнера:

сообщения уведомления о выполнении ликвидации запроса метки, являющегося подтверждением ликвидации;

сообщения присвоения метки в качестве отклика на аннулированное сообщение запроса;

сообщения уведомления в ответ на аннулирование запроса метки (например, зарегистрирована петля, нет ресурсов для метки, и т.д.).

Чтобы защитить себя от медлительных или неисправных партнеров, реализации LSR могут ввести тайм-ауты для времени ожидания отклика. Время тайм-аута должно быть относительно большим (несколько минут). Если время тайм-аута истекает, а отклика от партнера не получено, LSR может повторно использовать ID-сообщения запроса метки. Если он это делает, он должен также аннулировать любую запись сообщений запроса и ликвидации метки.

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

Сообщение отзыва метки

LSR посылает сообщение отзыва метки партнеру LDP, чтобы сигнализировать о том, что партнер не может продолжать использовать ассоциацию FEC-метка, которую LSR ранее анонсировал. Это разрывает соответствие между FEC и метками. Формат сообщения отзыва метки представлен ниже на рис. 12.29:

(рис 12.29)

ID сообщения

32-битовый код, используемый для идентификации этого сообщения.

TLV FEC

Идентифицирует FEC, для которого отзывается ассоциация FEC-метка.

Опционные параметры

Это поле переменной длины содержит 0 или более параметров, каждый из которых имеет формат TLV. Опционные параметры в таблице 12.8.

опционный параметр	Длина	значение
TLV метки	переменная	Смотри ниже

Метка

Если присутствует, специфицирует отзываемую метку.

Процедуры сообщения отзыва метки (Label Withdraw)

LSR посылает сообщение отзыва метки в следующих случаях:

LSR не распознает более известный ранее FEC, для которого была анонсирована метка;

LSR односторонне решил (например, в результате конфигурации) не коммутировать пакеты для одного или более FEC с меткой, которая была отозвана.

TLV FEC специфицирует FEC, для которого следует отозвать метки. Если за FEC не следует никакого TLV метки, все метки, ассоциированные с FEC, должны быть отозваны; в противном случае следует отозвать только метку, специфицированную в опционном TLV метки.

TLV FEC может содержать элемент Wildcard FEC; если это так, он может не содержать других элементов FEC. В этом случае, если сообщение отзыва метки содержит опционный TLV метки, то метка должна быть отозвана для всех FEC, с которыми она ассоциирована. Если в сообщении отзыва метки нет опционного TLV метки, то LSR-отправитель отзывает все ассоциации меток, анонсированные ранее LSR-получателю.

LSR, который получает сообщение отзыва метки, должен откликнуться сообщением освобождения метки.

Сообщение освобождения метки (Label Release)

LSR посылает LDP-партеру сообщение освобождения метки, чтобы сигнализировать, что LSR не нуждается в специфической ассоциации FEC-метка, ранее запрошенной и/или анонсированной партнером. Формат сообщения освобождения метки представлен ниже (рис. 12.30):

ID сообщения

32-битовый код, используемый для идентификации этого сообщения.(рис 12.30)

TLV FEC

Идентифицирует FEC, для которого была освобождена ассоциация FEC-метка.

Опционные параметры

Это поле переменной длины содержит 0 или более параметров, каждый из которых соответствует формату TLV. Опционные параметры в таблице 12.9.

опционный параметр	Длина	значение
TLV метки	переменная	Смотри ниже

Метка

В случае присутствия означает, что метка освобождена.

Процедуры сообщения освобождения метки (Label Release)

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

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

LSR получает сообщение присвоения метки от LSR, который не является следующим шагом для заданного FEC, а LSR сконфигурирован для работы в консервативном режиме.

LSR получает сообщение отзыва метки.

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

TLV FEC специфицирует FEC, для которого следует освободить метки. Если за FEC не следует TLV метки, все метки, ассоциированные с FEC, должны быть освобождены, в противном случае должна быть освобождена только метка, специфицированная в опционном TLV метки.

TLV FEC может содержать элемент Wildcard FEC; если это так, оно может не содержать других элементов FEC. В этом случае, если сообщение освобождения метки содержит опционное TLV метки, тогда метка должна быть освобождена для всех FEC, с которыми ассоциирована. Если в сообщении освобождения метки нет опционного TLV метки, тогда LSR-отправитель освобождает все метки, ассоциации с которыми он получил от LSR-получателя.

Сообщения и TLV для расширяемости

Поддержка LDP включает правила работы с битами U и F, которые специфицируют то, как LSR должен обрабатывать неизвестные TLV и сообщения. В этом разделе специфицированы TLV и сообщения для частных применений производителя и экспериментальных целей.

Частные расширения LDP производителя

Частные сообщения и TLV производителя используются для обмена между LSR частной информацией производителя.

Частные TLV LDP производителя

Диапазон кодов типа 0x3E00 - 0x3EFF зарезервирован для частных TLV производителя. Формат частных TLV производителя представлен ниже на рис. 12.31:

(рис 12.31)

U бит

Бит неизвестного TLV. При получении неизвестного TLV, если U=0, отправителю сообщения должно быть прислано уведомление, а само сообщение проигнорировано; если U=1, неизвестное TLV молча игнорируется, а остальная часть сообщения обрабатывается так, как если бы неизвестного TLV не существовало.

Определение того, понятно ли частное сообщение производителя, зависит от типа и обязательного поля ID производителя.

F бит

Бит переадресации неизвестного TLV. Этот бит используется, только когда U=1, а сообщение LDP, содержащее неизвестное TLV, должно быть переадресовано. Если F=0, неизвестное TLV не переадресуется вместе с содержащим его сообщением; если F=1, неизвестное TLV переадресуется вместе с содержащим его сообщением.

Тип

Значение тип лежит в диапазоне 0x3E00 - 0x3EFF. Вместе с типом и Id производителя поле специфицирует, как следует интерпретировать поле данных.

Длина

Специфицирует суммарную длину в октетах идентификатора производителя и поля данных.

Id производителя

ID производителя 802, как это предписано IEEE.

Данные

Остальные октеты после ID производителя в поле значение являются опционными данными, зависящими от производителя.

Частные сообщения LDP производителя

Код типа в диапазоне 0x3E00 - 0x3EFF зарезервирован для частных сообщений производителя (рис. 12.32).

(рис 12.32)

U бит

Бит неизвестного сообщения. При подтверждении неизвестного сообщения, если U=0, отправителю сообщения возвращается уведомление; если U=1, неизвестное сообщение молча игнорируется.

Определение того, будет ли воспринято частное сообщение производителя, базируется на типе сообщения и параметре ID производителя.

Тип сообщения

Код типа сообщения лежит в диапазоне 0x3E00 - 0x3EFF. Вместе с типом сообщения и ID производителя специфицирует то, как будет интерпретироваться сообщение.

Длина сообщения

Специфицирует суммарную длину в октетах полей ID сообщения, ID производителя, остальных обязательных и опционных параметров.

ID сообщения

32-битовый код, используемый для идентификации этого сообщения. Используется LSR-отправителем, чтобы упростить идентификацию уведомлений, которые могут относиться к этому сообщению. LSR, посылающий уведомление в качестве отклика на это сообщение, будет включать этот Id в сообщение уведомления.

ID производителя

ID производителя 802, как это предписано IEEE.

Остальные обязательные параметры

Набор переменной длины остальных обязательных параметров.

Опционные параметры

Набор переменной длины опционных параметров сообщения.

Экспериментальные расширения LDP

LDP поддержка экспериментирования подобна поддержке частных расширений производителя со следующими отличиями:

диапазон кодов тип 0x3F00 0x3FFF зарезервирован для экспериментальных TLV;

диапазон кодов тип сообщения 0x3F00 - 0x3FFF зарезервирован для экспериментальных сообщений;

Кодирование экспериментальных TLV и сообщений подобно кодированию частных сообщений производителя со следующим отличием:

Экспериментальные TLV и сообщения используют поле экспериментального ID вместо поля ID производителя. Поле ID эксперимента используется с полем тип сообщения, чтобы специфицировать интерпретацию экспериментального TLV или сообщения. Администрирование экспериментальных ID находится в сфере ответственности экспериментаторов.

Перечень сообщений

Следующие сообщения LDP определены в данной версии протокола (таблице 12.10).

Имя сообщения	Тип	заголовок раздела
Notification	0x0001	Сообщение уведомления
Hello	0x0100	Сообщение Hello
Initialization	0x0200	Сообщение инициализации
KeepAlive	0x0201	Сообщение KeepAlive
Address	0x0300	Сообщение Address
Address Withdraw	0x0301	Сообщение отзыва адреса
Label Mapping	0x0400	Сообщение присвоения метки
Label Request	0x0401	Сообщение запроса метки
Label Withdraw	0x0402	Сообщение отзыва метки
Label Release	0x0403	Сообщение освобождения метки
Label Abort Request	0x0404	Сообщение запроса ликвидации метки
Vendor-Private	0x3E00-0x3EFF	Частные расширения LDP произ¬водителя
Experimental	0x3F00-0x3FFF	Экспериментальные расширения LDP

Сводка TLV

Следующие TLV определены в этой версии протокола (таблица 12.11).

Сводка кодов статуса

Ниже представлены статусные коды, определенные в данной версии протокола. В колонке "E" представлены значения Е-бита статусного кода, требующие установки; колонка "Статусные данные" содержит 30-битовое поле статусных данных в формате TLV. Заметим, что значение F-бита статусного кода остается на усмотрение LSR, формирующего TLV статуса (таблица 12.12.).

UDP-порт для LDP-сообщения Hello имеет номер 646. TCP-порт для установления LDP-сессии также имеет номер 646.

TLV	Тип	заголовок раздела
FEC	0x0100	TLV FEC
Address List	0x0101	TLV списка адресов
Hop Count	0x0103	TLV числа шагов
Path Vector	0x0104	TLV вектора пути
Generic Label	0x0200	TLV общей метки
ATM Label	0x0201	TLV метки ATM
Frame Relay Label	0x0202	TLV метки Frame Relay
Status	0x0300	TLV статуса
Extended Status	0x0301	Сообщение уведомления
Returned PDU	0x0302	Сообщение уведомления
Returned Message	0x0303	Сообщение уведомления
Common Hello	0x0400	Параметры сообщения Hello
IPv4 Transport Address	0x0401	Сообщение Hello
Configuration	0x0402	Порядковый номер сообщения Hello
IPv6 Transport Address	0x0403	Сообщение Hello
Common Session	0x0500	Параметры сообщения инициализации
ATM Session Parameters	0x0501	Сообщение инициализации
Frame Relay Session	0x0502	Параметры сообщения инициализации
Label Request	0x0600	ID сообщения присвоения метки
Vendor-Private	0x3E00-0x3EFF	Частные расширения LDP производителя
Experimental	x3F00-0x3FFF	Экспериментальные расширения LDP

Неявная метка NULL

Неявная метка NULL (смотри [RFC-3031]) представляется как TLV общей метки со значением поля метка, как это специфицировано в [RFC-3032].

LDP делит пространство имен для типов сообщений на три диапазона. Далее предлагаются соображения по распоряжению этими диапазонами.

Типы сообщений 0x0000 - 0x3DFF в этом диапазоне являются частью базового протокола LDP и выделяются в результате консенсуса IETF.

код статуса	E	Статусные данные	заголовок раздела
Успех	0	0x00000000	TLV статуса
Плохой идентификатор LDP	1	0x00000001	Events Signaled by ... (События, сигнализизируемые ...)
Плохая версия протокола	1	0x00000002	Events Signaled by ... (События, сигнализизируемые ...)
Неверная длина PDU	1	0x00000003	Events Signaled by ... (События, сигнализизируемые ...)
Неизвестный тип сообщения	0	0x00000004	Events Signaled by ... (События, сигнализизируемые ...)
Неверная длина сообщения	1	0x00000005	Events Signaled by ...
Неизвестное TLV	0	0x00000006	Events Signaled by ...
Неверная длина TLV	1	0x00000007	Events Signaled by ...
Неверный формат значения TLV	1	0x00000008	Events Signaled by ...
Истекло время удержания	1	0x00000009	Events Signaled by ...
Shutdown	1	0x0000000A	Events Signaled by ...
Обнаружена петля	0	0x0000000B	Обнаружение петли
Неизвестный FEC	0	0x0000000C	Процедуры FEC
Нет маршрута	0	0x0000000D	Label Request Mess ... (Со¬общение запроса метки)
Нет ресурсов для метки	0	0x0000000E	Label Request Mess ...
Ресурсы для метки/доступны	0	0x0000000F	Label Request Mess ...
Session Rejected/No Hello	1	0x00000010	Инициализация сессии
Session Rejected/Parameters Advertisement Mode	1	0x00000011	Инициализация сессии
Session Rejected/Parameters Max PDU Length	1	0x00000012	Инициализация сессии
Session Rejected/Parameters Label Range	1	0x00000013	Инициализация сессии
Истекло время таймера KeepAlive	1	0x00000014	Events Signaled by ...
Запрос метки аннулирован	0	0x00000015	Label Request Abort ... (Ликвидация запроса метки)
Отсутствуют параметры сообщения	0	0x00000016	Events Signaled by ...
Не поддерживаемое семейство адресов	0	0x00000017	Процедуры FEC Address Message Proc ...
Session Rejected/Bad KeepAlive Time	1	0x00000018	Инициализация сессии
Внутренняя ошибка	1	0x00000019	Events Signaled by ...

Типы сообщений 0x3E00 - 0x3EFF в этом диапазоне зарезервированы для частных расширений производителя и являются областью ответственности отдельных производителей. IANA не вмешивается в распределение пространства типов сообщений в этом диапазоне.

Типы сообщений 0x3F00 0x3FFF в этом диапазоне зарезервированы для экспериментальных расширений и являются областью ответственности отдельных экспериментаторов. IANA не вмешивается в распределение пространства типов сообщений в этом диапазоне; однако, IANA ответственна за распоряжение частью пространства экспериментальных ID.

LDP делит пространство имен для типов TLV на три диапазона. Далее предлагаются соображения по распоряжению этими диапазонами.

Типы TLV в диапазоне 0x0000 - 0x3DFF являются частью базового протокола LDP и выделяются в результате консенсуса IETF.

Типы TLV в диапазоне 0x3E00 - 0x3EFF зарезервированы для расширений производителей и являются областью ответственности отдельных производителей. IANA не вмешивается в распределение пространства типов TLV в этом диапазоне.

Типы TLV в диапазоне 0x3F00 - 0x3FFF зарезервированы для экспериментальных расширений и являются областью ответственности отдельных экспериментаторов. IANA не вмешивается в распределение пространства TLV в этом диапазоне; однако, IANA ответственна за распоряжение частью пространства экспериментальных ID имен.

Типы FEC в диапазоне 0 - 127 выделяются в результате консенсуса IETF, типы в диапазоне 128 - 191 выделяются по принципу первым_пришел_первым_обслужен, а типы в диапазоне 192 - 255 зарезервированы для частных применений.

Статусные коды в диапазоне 0x00000000 - 0x1FFFFFFF выделяются в результате консенсуса IETF, коды в диапазоне 0x20000000 - 0x3EFFFFFF выделяются по принципу первым_пришел_первым_обслужен, и коды в диапазоне 0x3F000000 - 0x3FFFFFFF зарезервированы для частного использования.

Экспериментальные Id в диапазоне 0x00000000 - 0xefffffff выделяются по принципу первым_пришел_первым_обслужен, а экспериментальные Id в диапазоне 0xf0000000 - 0xffffffff зарезервированы для частного использования.

12.1. RSVP-TE: расширение RSVP для LSP-туннелей

Введение

В описании архитектуры MPLS [2] протокол рассылки меток определен как набор процедур, с помощью которых один маршрутизатор LSR (Label Switched Router) информирует другие о значении меток, используемых для переадресации трафика между ними и через них. Архитектура MPLS не предполагает существования единственного протокола рассылки меток. Данная статья представляет собой спецификацию расширения протокола RSVP для формирования маршрутов (LSP) с коммутацией по меткам в MPLS-сетях (RFC-3209).

Несколько новых особенностей, описанных здесь, мотивировались требованиями управления трафиком в рамках MPLS (смотри [3]). В частности, расширенный протокол RSVP поддерживает реализацию явной прокладки LSP с или без резервирования ресурсов. Он также поддерживает плавное изменение маршрута LSP, установление приоритетов и обнаружение циклических путей.

LSP, сформированные RSVP, могут использоваться для транспортировки потоков трафика (Traffic Trunks), как это описано в [3]. Два LSP между отправителем и получателем могут образовывать единый поток трафика. Наоборот, несколько потоков трафика могли бы транспортироваться одним LSP, если бы, например, LSP могли предоставлять несколько классов услуг. Применимость этих расширений обсуждается в [10].

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

LSP-туннели допускают реализацию различных политик оптимизации работы сети. Например, LSP-туннели могут обходить автоматически или вручную точки отказов в сети, области перегрузок или узкие места. Более того, несколько параллельных LSP-туннелей могут быть проложено между двумя узлами и трафик между этими узлами может быть направлен через эти LSP-туннели согласно местной политике маршрутизации. Хотя предполагается, что управление трафиком (то есть, оптимизация рабочих характеристик сети) является важным приложением этой спецификации, расширенный протокол RSVP может быть использован в более широком контексте.

Предпосылки

ЭВМ и маршрутизаторы, которые поддерживают как RSVP [1], так и MPLS (MultiProtocol Label Switching) [2] могут ассоциировать метки с потоками RSVP. Когда комбинируются MPLS и RSVP, определение потока можно сделать более гибко. Когда маршрут с коммутацией по меткам (LSP) сформирован, трафик по этому пути определяется меткой, присвоенной ему входным узлом LSP. Установление соответствия между меткой и трафиком может быть выполнено с помощью нескольких различных критериев. Набор пакетов, которым присвоена определенным узлом одна и та же метка, относятся к одному классу переадресации FEC (forwarding equivalence class) ([2]) и эффективно определяет RSVP-поток. Когда трафик ассоциирован с маршрутом LSP, мы рассматриваем LSP как LSP-туннель. Когда метки ассоциированы с потоками трафика, для маршрутизатора становится возможным идентифицировать определенное состояние резервирования для пакета с помощью его метки.

Модель протокола управления использует рассылку меток по запросам из области внизу по течению. Запрос установления соответствия метки и определенного LSP-туннеля инициируется входным узлом с помощью сообщения RSVP Path. Для этой цели сообщение RSVP Path дополняется объектом LABEL_REQUEST. Метки формируются внизу по течению и рассылаются вверх с помощью сообщения RSVP Resv. Для этой цели сообщение RSVP Resv расширяется с помощью специального объекта LABEL.

Модель протокола управления поддерживает также возможность явной маршрутизации. Это осуществляется путем введения простого объекта EXPLICIT_ROUTE в сообщения RSVP Path. Объект EXPLICIT_ROUTE содержит в себе набор шагов, которые непосредственно характеризуют маршрут. Применяя этот объект, проходы, используемые RSVP-MPLS потоками, управляемыми метками, могут быть предопределены независимо от традиционной IP-маршрутизации. Явно сформированный маршрут может быть специфицирован административно или вычислен автоматически в соответствии с требованиями QoS и политики маршрутизации, принимая во внимание базовое состояние сети. Вообще, вычисление маршрута может управляться директивно или данными. Механизмы, процессы и алгоритмы, используемые для явного вычисления маршрутов, в данной статье не рассматриваются.

Одним полезным приложением явной маршрутизации является управление трафиком. Используя явно сформированные LSP, входной узел домена MPLS может управлять маршрутом, по которому проходит трафик сети MPLS. Явная маршрутизация может быть применена, чтобы оптимизировать использование сетевых ресурсов и улучшить рабочие характеристики сети, ориентированные на трафик.

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

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

Преимуществом использования RSVP для формирования LSP-туннелей является возможность выделения ресурсов вдоль всего маршрута. Например, полоса пропускания может быть выделена LSP-туннелю с привлечением стандартного RSVP-резервирование и классов интегрированных услуг [4].

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

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

Абстрактный узел

Группа узлов, чья исходная топология неизвестна входному узлу LSP. Абстрактный узел называется простым, если он содержит только один физический узел

LSP, маршрутизируемый явно

LSP, чей маршрут сформирован с помощью обычной IP-маршрутизации

Маршрут с коммутацией по меткам

Маршрут, сформированный путем объединения одного или более каналов с коммутацией по меткам, допускающий переадресацию пакетов одним MPLS-узлом другому. Подробности смотри в [2].

LSP

Маршрут с коммутацией по меткам (Label Switched Path)

LSP-туннель

LSP, который используется для туннелирования на уровне ниже, чем обычная IP-маршрутизация, и/или для реализации механизмов отбора

Туннель управления трафиком (TE Tunnel)

Набор из одного или более LSP-туннелей, которые транспортируют трафик

Транк для трафика

Набор потоков, объединенных в соответствии с их классом услуг и затем помещенных в LSP, или набор LSP, названный туннелем управления трафиком. Подробности смотри в [3]

Обзор. LSP туннели и туннели управления трафиком (TE)

Согласно [1], "RSVP определяет сессию, как поток данных с определенным местом назначения и протоколом транспортного уровня". Однако когда RSVP и MPLS используются совместно, поток или сессия могут быть определены с большей гибкостью и общностью. Входной узел LSP может задействовать разные средства, чтобы определить, каким пакетам следует присвоить определенную метку. После того как набору пакетов метка присвоена, она эффективно определяет поток через LSP. Мы называем такой LSP "LSP-туннелем", так как трафик через него непрозрачен для промежуточных узлов вдоль LSP.

Новые объекты RSVP SESSION, SENDER_TEMPLATE и FILTER_SPEC, названные LSP_TUNNEL_IPv4 и LSP_TUNNEL_IPv6, были определены для поддержки LSP-туннелей. В действительности, IPv4(v6), появляющейся в названии объекта, указывает только на то, что адрес места назначения является IPv4(v6) адресом.

В некоторых приложениях полезно ассоциировать наборы LSP-туннелей. Это может быть полезно при операциях изменения маршрута или при прокладке транка. В приложениях управления трафиком такой набор называется сформированным туннелем трафика (TE-туннелем). Чтобы сделать возможной идентификацию и ассоциацию таких LSP-туннелей, предусмотрены два идентификатора. ID-туннель является частью объекта SESSION. Объект SESSION однозначно определяет сформированный туннель трафика. Объекты SENDER_TEMPLATE и FILTER_SPEC содержат в себе LSP ID. Объект S ENDER_TEMPLATE (или FILTER_SPEC ) совместно с объектом SESSION однозначно идентифицируют LSP-туннель.

Работа LSP-туннелей

В данном разделе обобщаются некоторые возможности, поддерживаемые RSVP-ТЕ при работе с LSP туннелями. Сюда входит:

возможность формирования LSP-туннелей с требованиями QoS или без них;

возможность динамически изменять маршруты сформированных LSP-туннелей;

возможность отслеживать действительный маршрут, проходящий через сформированный LSP-туннель;

возможность идентифицировать и диагностировать LSP-туннели;

возможность устанавливать сформированный LSP-туннель под административный контроль; и

возможность осуществлять посылку запросов выделения меток, их рассылку и объединение.

Чтобы сформировать LSP туннель, первый узел MPLS — то есть, узел-отправитель — посылает сообщение RSVP Path с типом сессии LSP_TUNNEL_IPv4 или LSP_TUNNEL_IPv6 и вводит объект LABEL_REQUEST в сообщение Path. Объект LABEL_REQUEST указывает, что запрошена привязка метки к данному пути, а также определяет протокол сетевого уровня, который используется для этого маршрута. Причина в том, что нельзя сделать предположение о протоколе сетевого уровня, используемом в LSP; это не обязательно IP и это нельзя выяснить по заголовку уровня L2, который просто указывает на вышестоящий протокол — MPLS.

Если узел-отправитель знает, что маршрут с высокой вероятностью отвечает требованиям QoS туннеля, или что он эффективно использует сетевые ресурсы, или что он удовлетворяет некоторым критериям политики, то узел может решить использовать маршрут для некоторых или для всех его сессий. Чтобы сделать это, узел-отправитель добавляет объект EXPLICIT_ROUTE в сообщение RSVP Path. Объект EXPLICIT_ROUTE специфицирует маршрут в виде последовательности абстрактных узлов.

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

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

Наконец, объект SESSION_ATTRIBUTE может быть добавлен в сообщение Path, чтобы помочь диагностике и идентификации сессии. В этом объекте содержится также информация о конфигурации, приоритетах и ресурсах [3].

Маршрутизаторы вдоль маршрута могут использовать конфигурацию и приоритеты совместно с SENDER_TSPEC и любыми объектами POLICY_DATA, содержащимися в сообщениях Path. Например, в приложениях управления трафиком очень полезно задействовать сообщение Path в качестве средства проверки того, что имеется полоса при заданном приоритете вдоль всего пути, прежде чем перейти к более низкому уровню приоритета резервирования.

Когда присутствует объект EXPLICIT_ROUTE (ERO), сообщение Path переадресуется по месту назначения вдоль пути, указанному в ERO. Каждый узел вдоль пути записывает ERO в свой блок состояния пути. Узлы могут также модифицировать ERO до переадресации сообщения Path. В этом случае модифицированный ERO должен быть запомнен в блоке состояния пути в дополнение к полученному ERO.

Объект LABEL_REQUEST запрашивает промежуточные маршрутизаторы и узлы-получатели предоставить данные о метке для данной сессии. Если узел не способен предоставить такие данные, он посылает сообщение PathErr с кодом ошибки unknown object class (неизвестный класс объекта). Если объект LABEL_REQUEST на всем пути не поддерживается, узел-отправитель будет уведомлен первым узлом, который не может обеспечить такую поддержку.

Узел места назначения пути с коммутацией по меткам реагирует на LABEL_REQUEST путем включения объекта LABEL в свой отклик-сообщение RSVP Resv. Объект LABEL включается в список спецификации отбора, который следует непосредственно за основной спецификацией фильтра.

Сообщение Resv посылается назад вверх по течению в направлении отправителя, следуя состоянию пути, сформированному сообщением Path, в обратном порядке. Заметим, что если состояние пути было сформировано с использованием ERO, тогда в обратном направлении (согласно ERO) последует сообщение Resv.

Каждый узел, который получает сообщение Resv, содержащее объект LABEL, использует эту метку для исходящего трафика в соответствии с данным LSP-туннелем. Если узел не является отправителем, он формирует новую метку и помещает ее в соответствующий объект LABEL сообщения Resv, которое посылается вверх по течению к PHOP. Метка, посланная вверх по течению в объекте LABEL, является меткой, которую данный узел будет применять для идентификации входного трафика, сопряженного с этим LSP туннелем. Эта метка служит также в качестве характеристики спецификации отбора (Filter Spec). Узел может теперь обновить свою карту входных меток ILM (Incoming Label Map), которая используется для определения NHLFE (Next Hop Label Forwarding Entry) (смотри [2]). Когда сообщение Resv движется вверх по течению в направлении узла-отправителя, формируется маршрут с коммутацией по меткам.

Реализации должны поддерживать услугу контролируемой нагрузки (ControlledLoad service) [4] и нулевую услугу (Null Service) [16].

Стили резервирования

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

Некоторые стили резервирования, такие, как FF, соответствуют определенным резервированиям в конкретном узле отправителя. Другие стили резервирования, такие, как WF и SE, могут реализовать совместно резервирования в нескольких узлах-отправителях. Более подробное обсуждение стилей резервирования можно найти в [12.1].

Стиль FF (фиксированный фильтр)

Стиль резервирования FF (Fixed Filter) формирует определенное резервирование для трафика каждого отправителя, которое не используется совместно другими отправителями. Этот стиль является типичным для приложений, в которых трафик от каждого отправителя существует одновременно и совершенно независимо. Общее значение зарезервированной полосы пропускания для сессий, применяющих FF, равно сумме резервирований для индивидуальных отправителей.

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

Стиль WF (Wildcard Filter)

При стиле WF (Wildcard Filter) одно резервирование применяется совместно всеми отправителями сессии. Общее резервирование в канале остается неизменным вне зависимости от числа отправителей.

Один маршрут с коммутацией по меткам со схемой мультиточка-точка формируется для всех отправителей сессии. В каналах, используемых отправителями сессии одновременно, для сессии выделяется одна метка. Если имеется только один отправитель, LSP выглядит как обычное соединение точка-точка. Когда имеется несколько отправителей, формируется LSP со схемой мультиточка-точка (реверсированное дерево).

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

Кроме того, из-за правил объединения WF, объекты EXPLICIT_ROUTE не могут использоваться для резервирования WF.

Стиль SE (Shared Explicit)

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

Стиль резервирования SE может быть реализован при использовании схемы маршрутов с коммутацией по меткам мультиточка-точка или при отдельных LSP для каждого отправителя. LSP мультиточка-точка могут использоваться, когда сообщения path не содержат объект EXPLICIT_ROUTE или когда сообщения Path имеют идентичные объекты EXPLICIT_ROUTE. В любом из этих случаев может быть присвоена общая метка. Сообщения Path от различных отправителей могут содержать их собственные ERO, а пути, используемые отправителями, могут сходиться и расходиться в любой точке сети. Когда сообщения Path содержат разные объекты EXPLICIT_ROUTE, должны быть сформированы отдельные LSP для каждого объекта EXPLICIT_ROUTE.

Туннели управления переадресацией трафика

Одним из требований управления трафиком является возможность изменения маршрута сформированного TE-туннеля при определенных условиях, на основе административной политики. Например, в некоторых контекстах административная политика может требовать изменения маршрута TE-туннеля, когда оказывается доступен более "оптимальный" путь. Другим важным контекстом, когда TE-туннель должен быть заново маршрутизирован, является отказ в ресурсах для установленного TE-туннеля. При некоторых политиках может быть нужно возвратить TE-туннель к исходному маршруту, когда исчезнувший ресурс снова стал доступен.

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

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

Аналогичная ситуация может возникнуть, когда нужно увеличить полосу TE-туннеля. Новое резервирование будет сделано по максимуму, но в действительности нужно только приращение между новой и старой полосой. Если в промежуточных узлах политика контролирует сообщения PATH, то сообщения PATH, запрашивающие слишком много полосы, будут отбрасываться. В этой ситуации в зависимости от местной политики простой запрос увеличения полосы без изменения SENDER_TEMPLATE может привести к обрыву туннеля. Комбинация объекта LSP_TUNNEL SESSION и стиля резервирования SE естественным образом подходит для плавного изменения полосы и маршрута. Идея заключается в том, чтобы старый и новый LSP-туннели совместно использовали ресурсы в каналах, где они работают. Объект LSP_TUNNEL SESSION используется, чтобы сузить рабочую область сессии RSVP, в частности, TE-туннеля. Чтобы однозначно идентифицировать TE-туннель, мы используем комбинацию IP адреса места назначения (адрес узла в конце туннеля), ID туннеля и IP адрес узла начала туннеля, которые помещаются в поле расширенного ID-туннеля.

Во время изменения маршрута или увеличения полосы пропускания входные узлы туннеля выступают в RSVP-сессии как два разных отправителя. Это достигается путем включения "LSP ID", который несет в себе объекты SENDER_TEMPLATE и FILTER_SPEC. Так как семантика этих объектов изменилась, им присваивается новые C-типы.

Чтобы осуществить изменение маршрута, входной узел выбирает новый LSP ID и формирует новый SENDER_TEMPLATE. Затем входной узел, чтобы определить новый путь, создает новый ERO. После этого узел посылает новое сообщение Path, используя исходный объект SESSION и новые SENDER_TEMPLATE и ERO. Он продолжает использовать старый LSP и обновляет старое сообщение Path. Для каналов, которые не являются общими, новое сообщение Path обрабатывается как обычное конфигурирование нового LSP-туннеля. Для каналов, которые являются общими, объект SESSION и стиль SE позволяют сформировать LSP, разделяющий ресурсы со старым LSP. Как только входной узел получает сообщение Resv для нового LSP, он может передавать по нему трафик и аннулировать старый LSP.

Чтобы увеличить полосы, может использоваться новое сообщение Path с новым LSP_ID. Делается попытка осуществить резервирование большей полосы при сохранении резервирования для текущего LSP_ID так, чтобы при неудаче большего резервирования старое резервирование осталось в силе.

MTU пути

Стандарт RSVP [12.1] и Int-Serv [12.11] предоставляют отправителю RSVP минимальное значение MTU, доступное между отправителем и получателем. Эта возможность определения MTU пути предоставляется также и для LSP, созданных посредством RSVP.

Информация о MTU пути содержится в объектах Integrated Services или Null Service (в зависимости оттого, что имеется в наличии). Когда используются объекты Integrated Services, MTU пути получается на основе процедур, описанных в [12.11]. Определение MTU пути в случае использования объектов Null Service рассмотрено в [12.16].

В случае стандарта RSVP информация о MTU пути используется отправителем, чтобы проверить, какие IP-пакеты имеют размер больше MTU. Пакеты, которые превосходят MTU, отправитель фрагментирует либо, когда IP-дейтограмма имеет установленный бит "Don't Fragment", отправляет ICMP-сообщение о недостижимости адресата. Такое обслуживание MTU необходимо для LSP, установленных посредством RSVP.

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

Используя терминологию, определенную в [12.5], LSR должен выполнить следующий алгоритм.

Пусть N равно числу байт в стеке меток (т.e, числу рекордов в стеке, умноженному на 4), включая метки, добавляемые в данном узле.

Пусть M меньше чем максимальный исходный размер помеченной IP дейтограммы или (MTU пути — N ).

Когда размер дейтограммы IPv4 (без меток) превосходит значение M, если бит DF в IPv4 заголовке не установлен, тогда

дейтограмма должна быть фрагментирована, размер каждого фрагмента должен быть не больше чем M, и

каждый фрагмент должен быть помечен и затем переадресован.

Если в IPv4-заголовке установлен бит DF, тогда

дейтограмма не должна переадресовываться;

формируется сообщение ICMP о недостижимости адресата:

его поле Code устанавливается [12] равным "Fragmentation Required and DF Set",

поле MTU следующего шага устанавливается[13] равным M.

Если возможно, посылается отправителю ICMP сообщение о недостижимости адресата для отброшенной дейтограммы.

Когда размер дейтограммы IPv6 (без меток) превышает значение M,

дейтограмма не должна переадресоваться;

формируется ICMP-пакет сообщение слишком велико со значением MTU следующего шага [14], равным M ;

если возможно, посылается ICMP-пакет, уведомляющий отправителя отвергнутой дейтограммы, что сообщение слишком велико.

Форматы сообщений, связанные с LSP туннелями

Пять новых объектов определено в данном разделе:

Имя объекта	Применимые RSVP-сообщения
`LABEL_REQUEST`	`Path`
`LABEL`	`Resv`
`EXPLICIT_ROUTE`	`Path`
`RECORD_ROUTE`	`Path, Resv`
`SESSION_ATTRIBUTE`	`Path`

Новые C-типы присваиваются также объектам SESSION, SENDER_TEMPLATE и FILTER_SPEC.

Подробные описания новых объектов представлены в последующих разделах. Все новые объекты являются с точки зрения RSVP опционными. Реализация может выбрать поддержку некоторого субнабора объектов. Однако объекты LABEL_REQUEST и LABEL в рамках данного документа являются обязательными.

Объекты LABEL и RECORD_ROUTE являются специфическими для отправителя. В сообщениях Resv они должны появляться после FILTER_SPEC и до любой последующей спецификации FILTER_SPEC.

Относительное положение объектов EXPLICIT_ROUTE, LABEL_REQUEST и SESSION_ATTRIBUTE является лишь рекомендацией. Порядок размещения этих объектов не важно, так что программная реализация должна быть готова воспринимать объекты в любом порядке.

Сообщение Path

Сообщение Path имеет следующий формат:

<Сообщение Path> ::=  <Common Header> [ <INTEGRITY> ]
              <SESSION> <RSVP_HOP>
              <TIME_VALUES>
              [ <EXPLICIT_ROUTE> ]
              <LABEL_REQUEST>
              [ <SESSION_ATTRIBUTE> ]
              [ <POLICY_DATA> ... ]
              <sender descriptor>

<дескриптор         <SENDER_TEMPLATE> <SENDER_TSPEC>
отправителя> ::=   
              [ <ADSPEC> ]
              [ <RECORD_ROUTE> ]

Сообщение Resv

Сообщение Resv имеет следующий формат:

<Сообщение Resv> ::=   <Common Header> [ <INTEGRITY> ]
              <SESSION> <RSVP_HOP>
              <TIME_VALUES>
              [ <RESV_CONFIRM> ] [ <SCOPE> ]
              [ <POLICY_DATA> ... ]
              <STYLE> <flow descriptor list>
<список дескрипторов потока>::=  <FF flow descriptor list>
                    | <SE flow descriptor>
<список дескрипторов потока FF>::=  <FLOWSPEC> <FILTER_SPEC>
                      <LABEL> [ <RECORD_ROUTE> ]
                      | <FF flow descriptor list>
                      <FF flow descriptor>
<дескриптор потока FF>::=  [ <FLOWSPEC> ] 
                <FILTER_SPEC> <LABEL>
                [ <RECORD_ROUTE> ]
<дескриптор потока SE>::=  <FLOWSPEC> <SE filter spec list>
                <SE filter spec list> ::= <SE filter spec>
                | <SE filter spec list> <SE filter spec>
<спецификация фильтра SE>::=  <FILTER_SPEC> <LABEL> 
                  [ <RECORD_ROUTE> ]

Заметьте: LABEL и RECORD_ROUTE (если имеется), являются связанными с предыдущей спецификацией FILTER_SPEC. За каждой спецификацией FILTER_SPEC может следовать не более одного LABEL и/или RECORD_ROUTE.

Объекты, связанные с LSP-туннелем. Объект Label

Метки могут транспортироваться сообщениями Resv. В стилях FF и SE метка присваивается для каждого отправителя. За меткой отправителя в сообщении Resv должна непосредственно следовать FILTER_SPEC. Объект LABEL имеет следующий формат:

Класс LABEL = 16, C_Type = 1

Содержимое LABEL занимает 4 октета. Каждая метка MPLS является целым числом без знака в диапазоне от 0 до 1048575. Метки MPLS и FR представляют собой 4-х октетные коды, выровненные по правым разрядам. Метки ATM кодируются в битах 0-15 поля VPI, выровненными справа, и в битах 16-31 поля VCI.

Обработка объектов Label в сообщениях Resv

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

Метки, полученные в сообщениях Resv через разные интерфейсы, всегда считаются разными, даже если их значения идентичны.

Внизу по течению

Узел, размещенный внизу по течению, выбирает метку, которая будет представлять поток. Если в запросе специфицирован диапазон меток, метка должна лежать в этом диапазоне. Если свободных меток нет, узел посылает сообщение PathErr с кодом ошибки routing problem (проблема маршрутизации) и значением ошибки label allocation failure (отказ выделения метки).

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

В случае ATM применимо дополнительное условие. Некоторые ATM-узлы не способны объединять потоки. Эти узлы могут уведомлять об этом путем установления бита запроса метки равным нулю. M-бит в объекте LABEL_REQUEST C-тип 2 запроса метки в диапазоне меток ATM служит именно этой цели. M-бит должен быть установлен узлами, которые способны объединять потоки. Если для нескольких отправителей бит M не установлен, узел внизу по течению должен этим отправителям присвоить уникальные метки.

Когда метка присвоена, узел формирует новый объект LABEL и посылает его в качестве части сообщения Resv предшествующему узлу. Узел должен быть готов переадресовывать пакеты, содержащие присвоенные метки, до посылки сообщения Resv. Объект LABEL должен содержаться в блоке состояния резервирования.

Ожидается, что узел пошлет сообщение Resv, прежде чем перезапустит свой таймер, если содержимое объекта LABEL изменяется.

Вверху по течению

Узел применяет метку, содержащуюся в объекте LABEL, как выходную метку, ассоциированную с отправителем. Маршрутизатор присваивает новую метку и связывает ее с входным интерфейсом этой сессии/отправителя. Это тот же интерфейс, который маршрутизатор использует для переадресации сообщений Resv предшествующим узлам.

Несколько условий могут сделать метку неприемлемой.

Узел является коммутатором ATM, неспособным объединять потоки, но узел ниже по течению присвоил идентичные метки двум отправителям.

Присвоена метка нуль, но узел неспособен выполнить предпоследнее извлечение из стека для соответствующего L3PID

Присвоенная метка находится вне запрошенного диапазона меток.

В любом из этих случаев узел посылает сообщение ResvErr с кодом ошибки проблема маршрутизации и значением ошибки неприемлемое значение метки.

Отсутствие поддержки объекта Label

При нормальных обстоятельствах узел не должен получать объект LABEL в сообщении Resv, если только оно не содержит объект LABEL_REQUEST в соответствующем сообщении Path. Однако, маршрутизатор RSVP, который не распознает объект LABEL, посылает получателю ResvErr с кодом ошибки Unknown object class (неизвестный класс объекта), что приводит к аннулированию резервирования.

Объект запроса метки

Класс запроса метки равен 19. В настоящее время существует три возможных значения C_Types. Тип 1 относится к запросам метки без диапазона значений. Тип 2 является запросом метки с диапазоном ATM. Тип 3 является запросом метки с диапазоном Frame Relay. Объект LABEL_REQUEST имеет форматы, показанные ниже на рис. 12.33.

Запрос метки без указания диапазона

Класс = 19, C_Type = 1

(рис 12.33)

Зарезервировано	Это поле зарезервировано. Оно должно равняться нулю при передаче и игнорироваться при получении
L3PID	Идентификатор протокола слоя 3, используемого в этом проходе. Используются стандартные значения для `Ethertype`.

Запрос метки с диапазоном ATM

Класс = 19, C_Type = 2

Резерв	Это поле зарезервировано. Оно должно равняться нулю при передаче и игнорироваться при получении
L3PID	Идентификатор протокола слоя 3, используемого в этом проходе. Используются стандартные значения для `Ethertype`
M	Установка этого бита равным 1 указывает, что узел может объединять потоки
Минимум VPI (12 бит)	Это 12-битное поле специфицирует нижнюю границу блока идентификаторов виртуального пути, которая поддерживается исходным коммутатором. Если VPI меньше 12-бит, оно должно быть выровнено по правому полю, а предшествующие биты должны равняться нулю
Минимум VCI (16 бит)	Это 16-битное поле специфицирует нижнюю границу блока идентификаторов виртуального пути, которая поддерживается исходным коммутатором. Если VCI меньше 16 бит, оно должно быть выровнено по правому полю, а предшествующие биты должны равняться нулю
Максимум VPI (12 бит)	Это 12-битное поле специфицирует верхнюю границу блока идентификаторов виртуального пути, которая поддерживается исходным коммутатором. Если VPI меньше 12 бит оно должно быть выровнено по правому полю
Максимум VCI (16 бит)	Это 16-битное поле специфицирует верхнюю границу блока идентификаторов виртуального пути, которая поддерживается исходным коммутатором. Если VCI меньше 16 бит, оно должно быть выровнено по правому полю

Запрос метки с диапазоном Frame Relay

Класс = 19, C_Type = 3

(рис 12.35)

Резерв	Это поле зарезервировано. Оно должно равняться нулю при передаче и игнорироваться при получении
L3PID	Идентификатор протокола слоя 3, используемого в этом проходе. Используются стандартные значения для `Ethertype`.
DLI	Индикатор длины DLCI. Число бит в DLCI. Поддерживаются следующие значения: Len DLCI [бит] 0 10 2 23
Минимум DLCI	Это 23-битное поле специфицирует нижнюю границу блока идентификаторов виртуальных каналов (DLCI), которая поддерживается исходным коммутатором. DLCI должно быть выровнено по правому полю, а неиспользуемые биты должны ровняться нулю
Максимум DLCI	Это 23-битное поле специфицирует верхнюю границу блока идентификаторов виртуальных каналов (DLCI), которая поддерживается исходным коммутатором. DLCI должно быть выровнено по правому полю

Обработка LABEL_REQUEST

Чтобы сформировать LSP-туннель, отправитель посылает сообщение Path с объектом LABEL_REQUEST. Объект LABEL_REQUEST указывает, что запрашивается подключение метки к данному пути, и определяется сетевой протокол, который используется на этом пути. Это позволяет в LSP применять сетевые протоколы не-IP типа. Данная информация может быть также полезной при выделении метки, так как некоторые зарезервированные метки являются протокольно зависимыми [5].

LABEL_REQUEST должен быть записан в блоке состояния прохода, так что сообщения обновления Path будут также содержать объект LABEL_REQUEST. Когда сообщение Path приходит к получателю, присутствие объекта LABEL_REQUEST заставляет получателя присвоить метку и поместить ее в объект LABEL соответствующего сообщения Resv. Если был специфицирован диапазон меток, метка должна быть взята из данного диапазона. Получатель, который воспринимает объект LABEL_REQUEST, должен включать объект LABEL в сообщения Resv, сопряженные с сообщением Path. Если объект LABEL_REQUEST в сообщении Path отсутствовал, узел не должен включать объект LABEL в сообщение Resv, для сопряженной с сообщением Path сессии и PHOP.

Узел, который посылает объект LABEL_REQUEST, должен быть готов воспринять и корректно обработать объект LABEL в соответствующих сообщениях Resv.

Узел, который распознает объект LABEL_REQUEST, но не может его поддержать (возможно, из-за невозможности присвоить метку), должен послать PathErr с кодом ошибки Routing problem (проблема маршрутизации) и значением ошибки MPLS label allocation failure (отказ присвоения метки MPLS). Это включает в себя случай, когда специфицирован диапазон меток, а метка не может быть из этого диапазона выделена. Узел, который получает и переадресует сообщение Path с объектом LABEL_REQUEST, должен скопировать L3PID из полученного объекта LABEL_REQUEST в переадресуемый объект LABEL_REQUEST.

Если получатель не поддерживает протокол L3PID, ему следует послать PathErr с кодом ошибки Routing problem и значением ошибки Unsupported L3PID. Это вызовет прерывание сессии RSVP.

Отсутствие поддержки объекта запроса метки

Маршрутизатор RSVP, который не распознал объект LABEL_REQUEST, посылает отправителю PathErr с кодом ошибки Unknown object class. Маршрутизатор RSVP, который распознал объект LABEL_REQUEST, но не распознал C_Type, посылает отправителю PathErr с кодом ошибки Unknown object C_Type. Это приводит к прерыванию формирования маршрута. Отправитель должен уведомить руководство, что LSP не может быть установлен, и, возможно, предпринять действия по резервированию без LABEL_REQUEST.

RSVP сконструирован для успешной работы с маршрутизаторами, которые не поддерживают RSVP, размещенными на пути от отправителя к получателю. Однако, очевидно, маршрутизаторы без RSVP не могут транспортировать метки через RSVP. Это означает, что, если маршрутизатор имеет соседа без поддержки RSVP, он не должен анонсировать объект LABEL_REQUEST, посылая сообщения, которые проходят через маршрутизаторы без поддержки RSVP. Маршрутизатор должен послать отправителю PathErr с кодом ошибки Routing problem и значением ошибки MPLS being negotiated, but a nonRSVP capable router stands in the path (оговорен протокол MPLS, но на пути стоит маршрутизатор без поддержки RSVP). То же самое сообщение следует послать, если маршрутизатор получает объект LABEL_REQUEST в сообщении от маршрутизатора без поддержки RSVP. О том, как маршрутизатор ниже по течению может обнаружить маршрутизатор без поддержки RSVP, смотри в [1].

Объект Explicit Route

Явные маршруты (Explicit Route) специфицируются с помощью объекта EXPLICIT_ROUTE (ERO). Класс явных маршрутов имеет код 20. В настоящее время определен один C_Type = 1 — явный маршрут. Объект EXPLICIT_ROUTE имеет следующий формат:

Класс = 20, C_Type = 1

Содержимое объекта EXPLICIT_ROUTE представляет собой последовательность информационных записей переменной длины, называемых субобъектами.

Если сообщение Path содержит несколько объектов EXPLICIT_ROUTE, только первый объект имеет смысл. Последующие объекты EXPLICIT_ROUTE могут игнорироваться и не должны пересылаться далее.

Применимость

Объект EXPLICIT_ROUTE предназначен для использования только в уникастной среде. Приложения с явной маршрутизацией для мультикастинга являются предметом дальнейших исследований.

Объект EXPLICIT_ROUTE следует использовать, только когда все маршрутизаторы вдоль явного маршрута поддерживают RSVP и объект EXPLICIT_ROUTE. Объекту EXPLICIT_ROUTE присвоено значение класса в формате 0bbbbbbb. Маршрутизаторы RSVP, которые не поддерживают этот объект, будут откликаться сигналом ошибки Unknown Object Class.

Семантика объекта Explicit Route

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

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

Явный маршрут описывается последовательностью субобъектов, содержащихся в объекте EXPLICIT_ROUTE. Каждый субобъект идентифицирует группу узлов явного маршрута.

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

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

Субобъекты

Содержимое объекта EXPLICIT_ROUTE представляет собой последовательность записей переменной длины, называемых субобъектами. Каждый субобъект имеет формат, представленный ниже (рис. 12.36):

(рис 12.36)

`L`	Бит `L` является атрибутом субобъекта. Если бит `L=1`, то субобъект является свободным шагом в явном маршруте. Если бит `L=0`, субобъект является жестким шагом в явном маршруте.
Тип	Поле тип определяет тип содержимого субобъекта. В настоящее время определены следующие значения: 1 IPv4 префикс 2 IPv6 префикс 32 номер автономной системы
Длина	Поле длина содержит полную длину субобъекта в байтах, включая поля `L`, тип и длина. Значение поля длина должно быть кратно 4 и не менее 4

Строгие и свободные субобъекты

Бит L в субобъекте является однобитовым атрибутом. Если бит L =1, тогда значение атрибута соответствует значению 'свободный'. В противном случае, значение атрибута является 'строгим'. Для краткости, будем говорить, что, если значение атрибута субобъекта 'свободный', тогда это 'свободный субобъект'. В противном случае, это 'строгий субобъект'. Более того, мы говорим, что абстрактный узел строгого или свободного субобъекта является строгим или свободным узлом, соответственно.

(рис 12.37)

`L`	Бит `L` является атрибутом субобъекта. Если бит `L=1`, то субобъект является свободным шагом в явном маршруте. Если `L=0`, субобъект является жестким шагом в явном маршруте
Тип	0x01 IPv4 адрес
Длина	Поле длина содержит полную длину субобъекта в байтах, включая поля тип и длина. Значение поля всегда `=8`
IPv4 адрес	IPv4 адрес. Этот адрес рассматривается как префикс, базирующийся на значении длины префикса. Биты за пределами префикса игнорируются при приеме и должны равняться нулю при передаче
Длина префикса	Длина префикса IPv4 в битах
Заполнитель	Нуль при передаче. Игнорируется при приеме

Субобъект 1. IPv4 префикс

Содержимым префикса IPv4 субобъекта является 4-октета IPv4 адреса, 1-октет длины префикса и 1-октет заполнителя. Абстрактный узел, представляемый этим субобъектом, является набором узлов, которые имеют IP адрес в пределах этого префикса. Заметим, что длина префикса 32 указывает на один узел IPv4.

(рис 12.38)

`L`	Бит `L` является атрибутом субобъекта. `L-бит =1`, если субобъект представляет собой свободный шаг в явном маршруте. Если `L =0`, субобъект представляет собой строгий шаг в явном маршруте
Тип	0x02 IPv6 адрес
Длина	Поле длина содержит полную длину субобъекта в байтах, включая поля тип и длина. Значение поля длина всегда =20
IPv6 адрес	Адрес IPv6. Этот адрес обрабатывается как префикс на основе величины длины префикса. Биты за пределами префикса игнорируются при приеме и должны равняться нулю при передаче
Длина префикса	Длина префикса IPv6 в битах
Заполнитель	Нуль при передаче. Игнорируется при приеме

Субобъект 2. IPv6 префикс

Содержимым префикса IPv6 субобъекта является 16-октетный IPv6-адрес, 1-октет префикса длины и 1-октета заполнителя. Абстрактный узел, представляемый этим субобъектом, является набором узлов, которые имеют IP адреса в пределах этого префикса. Заметим, что длина префикса 128 указывает на один узел IPv6.

Субобъект 32: Номер автономной системы

Содержимым субобъекта номера автономной системы (AS) являются два октета номера AS. Абстрактный узел, представленный субобъектом, является набором узлов, принадлежащих автономной системе.

Обработка объекта Explicit Route. Выбор следующего шага

Узел, который получает сообщение Path, содержащее объект EXPLICIT_ROUTE, должен определить следующий шаг пути. Это необходимо из-за того, что следующий абстрактный узел вдоль явного маршрута может быть субсетью IP или автономной системой. Следовательно, выбор этого следующего шага может включать в себя выбор одной из возможных альтернатив. Критерии, используемые, чтобы выполнить выбор, зависят от конкретной реализации и могут зависеть от локальной политики. Однако предполагается, что каждый узел сделает все возможное, чтобы исключить кольцевые маршруты. Заметим, что так определенные пути могут быть отвергнуты локальной политикой. Чтобы определить следующий шаг пути, узел выполняет следующие операции.

Узел, получив сообщение RSVP, должен определить первый субобъект. Если узел не является частью абстрактного узла, описанного первым субобъектом, он получил сообщение с ошибкой и должен прислать сигнал ошибки Bad initial subobject. Если первого субобъекта вообще нет, сообщение ошибочно и система должна прислать сигнал ошибки Bad EXPLICIT_ROUTE object.

Если нет второго субобъекта, это указывает на конец явного маршрута. Объект EXPLICIT_ROUTE должен быть удален из сообщения Path. Этот узел может быть или не быть концом пути.

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

Абстрактный пограничный узел. Узел определяет, является ли он топологически смежным с абстрактным узлом, описанным во втором субобъекте. Если это так, узел выбирает конкретный следующий шаг, адресатом которого является один из членов абстрактного узла.

Случай внутреннего абстрактного узла: В противном случае узел выбирает следующий шаг в пределах абстрактного узла первого субобъекта (к которому данный узел принадлежит), то есть вдоль пути к абстрактному узлу второго субобъекта (который является следующим абстрактным узлом). Если такого пути нет, тогда возможны два варианта:

если второй субобъект является жестким, имеет место ошибка и узел должен прислать уведомление об ошибке Bad strict node;

в противном случае, если второй субобъект является свободным, узел выбирает любой следующий шаг вдоль пути к очередному абстрактному узлу. Если такого пути нет, имеет место ошибка, и узел должен прислать сигнал ошибки Bad loose node.

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

Добавление субобъектов в объект Explicit Route

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

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

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

Петли

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

Прямая совместимость

Ожидается, что со временем могут быть определены новые субобъекты. Узел, который столкнулся в процессе обработки ERO с нераспознанным субобъектом, посылает отправителю PathErr с кодом ошибки Routing Error и значением ошибки Bad Explicit Route Object. Присутствие нераспознанного субобъекта, который не встретился в ходе обработки ERO, следует игнорировать. Он передается далее вместе с остальной частью стека ERO.

Отсутствие поддержки объекта Explicit Route

Маршрутизатор RSVP, который не распознает объект EXPLICIT_ROUTE, посылает отправителю PathErr с кодом ошибки Unknown object class. Это вызывает отказ формирования пути. Отправитель должен уведомить руководство, что LSP не может быть сформирован и, возможно, предпримет действия по резервированию без EXPLICIT_ROUTE или с привлечением другого явного маршрута.

Объект Record Route

Маршруты могут записываться с помощью объекта RECORD_ROUTE (RRO). Опционно, могут записываться и метки. Код класса записи маршрута равен 21. В настоящее время определен только один код C_Type = 1 (запись маршрута). Объект RECORD_ROUTE имеет достаточно простой формат:

Класс = 21, C_Type = 1

Содержимое объекта RECORD_ROUTE представляет собой последовательность записей переменной длины, называемых субобъектами.

RRO может присутствовать как в сообщениях RSVP Path, так и Resv. Если сообщение Path содержит несколько RRO, только первое RRO имеет значение. Последующие RRO следует игнорировать и не передавать дальше. Аналогично, если в сообщении Resv имеется несколько RRO, следующих за FILTER_SPEC, только первое RRO имеет смысл. Последующие RRO следует игнорировать и не пересылать далее.

Субобъекты

Содержимое объекта RECORD_ROUTE представляет собой последовательность записей переменной длины, называемых субобъектами. Каждый субобъект имеет поле своей длины. Это поле содержит полную длину субобъекта в байтах, включая поля тип и длина. Значения кода длины должно быть кратно 4 и быть не менее 4.

Субобъекты образуют стек последним_вошел_первым_вышел (LIFO). Первый субобъект по отношению к началу RRO считается размещенным сверху. Последний субобъект считается помещенным на дно стека. Когда добавляется новый субобъект, он всегда помещается сверху.

Пустой RRO (без субобъектов) считается некорректным. В настоящее время определено три типа субобъектов.

(рис 12.39)

Тип	0x01 IPv4 адрес
Длина	Поле длина содержит полную длину субобъекта в байтах, включая поля тип и длина. Значение поля всегда `=8`
IPv4 адрес	32-битный уникастный, адрес ЭВМ. Здесь может быть указан любой достижимый сетевой интерфейс. Недопустимыми адресами могут считаться, например, адреса loopback, они не должны использоваться
Длина префикса	32
Флаги	0x01 имеется локальная защита. Указывает, что канал вниз по течению от этого узла защищен с помощью некоторого локального механизма восстановления. Этот флаг может `=1`, если только установлен флаг локальной защиты в объекте `SESSION_ATTRIBUTE` соответствующего сообщения Path. 0x02 используется локальная защита Указывает, что в данном туннеле используется локальный механизм восстановления

Субобъект 1. адрес IPv4

(рис 12.40)

Тип	0x02 IPv6 адрес
Длина	Поле длина содержит полную длину субобъекта в байтах, включая поля тип и длина. Значение поля всегда `=20`
IPv6 адрес	128-битовый уникастный адрес ЭВМ
Длина префикса	128
Флаги	0x01 доступна локальная защита. Указывает, что канал вниз по течению от этого узла защищен с помощью некоторого локального механизма восстановления. Этот флаг может `=1`, если только установлен флаг локальной защиты в объекте `SESSION_ATTRIBUTE` соответствующего сообщения Path. 0x02 используется локальная защита. Указывает, что в данном туннеле используется локальный механизм восстановления

Субобъект 2. IPv6 адрес

(рис 12.41)

Тип	0x03 Label (метка)
Длина	Поле длина содержит полную длину субобъекта в байтах, включая поля тип и длина.
Флаги	`0x01 = Глобальная метка`. Этот флаг указывает на то, что метка будет воспринята корректно любым интерфейсом
C-тип	C-тип включенного объекта Label. Копируется из объекта Label
Содержимое объекта Label	Содержимое объекта Label. Копируется из объекта Label

Субобъект 3. Метка. Применимость

Здесь определено использование только уникастных сессий. Существует три возможных применения RRO в RSVP. Первое: RRO может функционировать как механизм детектирования петель для выявления кольцевых маршрутов на уровне L3 или петель, сопряженных с явным маршрутом.

Второе: RRO собирает текущую маршрутную информацию шаг-за-шагом о сессиях RSVP, предоставляя ценные данные отправителю или получателю. При этом будут сообщаться любые изменения маршрута (в связи с изменением топологии сети).

Третье: синтаксис RRO сконструирован так, чтобы можно было с минимальными изменениями использовать весь объект в качестве входных данных для объекта EXPLICIT_ROUTE. Это полезно, если отправитель получает RRO от получателя в сообщении Resv и применяет его к объекту EXPLICIT_ROUTE в следующем сообщении Path, чтобы определить маршрут сессии.

Обработка RRO

Узел обычно запускает сессию RSVP путем добавления RRO в сообщение Path. Исходное RRO содержит только один субобъект — IP-адреса отправителей. Если узел хочет также записывать метки, он устанавливает флаг Label_Recording в атрибуте SESSION_ATTRIBUTE.

Когда промежуточный маршрутизатор получает сообщение Path, содержащее RRO, он запоминает копию его блока состояния маршрута. RRO затем используется в следующем обновлении Path. Когда нужно послать новое сообщение Path, маршрутизатор добавляет новый субобъект в RRO и вставляет полученный RRO в сообщение Path перед передачей.

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

Когда флаг Label_Recording в объекте SESSION_ATTRIBUTE =1, узлы, осуществляющие запись маршрута, должны включать субобъект Label Record. Если узел использует глобальное пространство меток, тогда ему следует установить флаг Global Label.

Субобъект Label Record вводится в объект RECORD_ROUTE до введения туда IP-адреса узла. Узел не должен вводить субобъект Label Record, не вводя субобъекта IPv4 или IPv6.

Заметим, что при получении исходного сообщения Path, узел вряд ли имеет метку. Как только метка получена, узел должен включить ее в RRO при следующем обновлении Path.

Если вновь добавленный субобъект приводит к тому, что RRO оказывается слишком велико для сообщения Path (или Resv), объект RRO будет выброшен из сообщения, а обработка самого сообщения будет продолжена обычным образом. Должно быть послано отправителю (или получателю) сообщение PathErr (или ResvErr). Код ошибки будет Notify (внимание), а значение ошибки RRO too large for MTU. Если получатель получает такое ResvErr, ему следует послать сообщение PathErr с кодом ошибки Notify и значением ошибки RRO notification. Отправитель, получив любое из этих значений ошибок, должен удалить RRO из сообщения Path.

Узлы должны повторно посылать указанные выше сообщения PathErr или ResvErr каждые n секунд, где n более 15, и обновлять интервал для сопряженного сообщения Path или RESV. Узел может применить ограничения и/или таймеры задержки, чтобы уменьшить число посылаемых сообщений.

Маршрутизатор RSVP может решить послать сообщения Path до их времени обновления, если RRO в следующем сообщении Path отличается от предыдущего. Это может случиться, если содержимое RRO, полученное от маршрутизатора предыдущего шага, изменяется или если этот RRO вновь добавлен (или удален из) сообщения Path.

Когда узел назначения сессии RSVP получает сообщение Path с RRO, это указывает, что отправителю нужна запись маршрута. Узел назначения инициирует RRO процесс путем добавления RRO в сообщения Resv. Обработка отображает эти сообщения Path. Единственная разница заключается в том, что RRO в сообщении Resv записывает маршрутную информацию в обратном направлении.

Заметим, что каждый узел вдоль пути будет теперь иметь полный маршрут от отправителя до получателя. Path RRO будет иметь маршрут от отправителя до этого узла; Resv RRO — от этого узла до места назначения. Такая схема полезна для управления сетью.

Сообщение Path, полученное без RRO, указывает, что узел отправителя не хочет более записывать маршрут. Последующие сообщения Resv не будут содержать RRO.

Обнаружение циклических маршрутов

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

Сессия RSVP лишена циклов, если узлы ниже по течению получают сообщения Path или вышестоящие узлы получают сообщения Resv без маршрутных петель, обнаруженных в RRO.

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

Для сообщений Path, содержащих петли переадресации, маршрутизатор формирует и посылает PathErr сообщение Routing problem, со значение ошибки loop detected (обнаружена петля), после чего выбрасывает сообщение Path. Пока петля не ликвидирована, эта сессия не пригодна для переадресации информационных пакетов.

Для сообщений Resv, содержащего петлю переадресации, маршрутизатор просто отбрасывает сообщения. Сообщения Resv не должны зацикливаться, если сообщения Path не имеют петель.

Прямая совместимость

Для RRO могут быть определены новые субобъекты. Когда при обработке RRO не распознаны субобъекты, их следует игнорировать и передавать дальше. При обработке RRO на предмет выявления петель, узел должен обходить нераспознанные при разборе объекты. Детектирование петель происходит при обнаружении субобъектов, которые были введены самим узлом ранее. Это гарантирует, что субобъекты нужные для детектирования петель, всегда будут распознаны.

Отсутствие поддержки RRO

Объект RRO должен использоваться, только когда все маршрутизаторы вдоль пути поддерживают RSVP и объект RRO. Объекту RRO преписывается значение класса в форме 0bbbbbbb. Маршрутизаторы RSVP, которые не поддерживают объект, будут откликаться сообщением об ошибке Unknown Object Class (неизвестный класс объекта).

Коды ошибок для ERO и RRO

При обработке, описанной выше, определенные ошибки должны быть объявлены как Routing Problem или Notify (проблема маршрутизации или "внимание"). Значение кода ошибки Routing Problem равно 24; значение кода Notify равно 25. Определены следующие значения ошибок для кода ошибки Routing Problem:

Значение  Ошибка
1      Bad EXPLICIT_ROUTE object (плохой объект EXPLICIT_ROUTE)
2      Bad strict node (плохой жесткий узел)
3      Bad loose node (плохой свободный узел)
4      Bad initial subobject (плохой исходный субобъект)
5      No route available toward destination (нет пути до адресата)
6      Unacceptable label value (неприемлемое значение метки)
7      RRO indicated routing loops (RRO указывает на наличие петли)
8      MPLS being negotiated, but a nonRSVPcapable router stands 
             in the path (согласовывался MPLS, но на пути 
               стоит маршрутизатор без поддержки RSVP)
9      MPLS label allocation failure (ошибка присвоения MPLSметки)
10      Unsupported L3PID (не поддерживаемый L3PID)

Для кода ошибки Notify, 16 бит значения поля ошибки имеет вид:

ss00 cccc cccc cccc

Старшие биты определены при коде ошибки 1 [1]. Когда ss = 00, определены следующие субкоды:

1   RRO для MTU слишком велико 
2   RRO-уведомление
3   туннель локально восстановлен

Объекты сессии, шаблона отправителя и спецификации фильтра

Новые C-типы определены для объектов SESSION, SENDER_TEMPLATE и FILTER_SPEC. Объекты LSP_TUNNEL имеют следующий формат:

Объект Session

Объект сессии LSP_TUNNEL_IPv4

Класс = SESSION, LSP_TUNNEL_IPv4 C-тип = 7

Объект сессии LSP_TUNNEL_IPv6

(рис 12.42)

IPv4 адрес конца туннеля	IPv4 адрес оконечного узла туннеля
ID туннеля	16-битный идентификатор, используемый в сессии и сохраняемый на протяжении жизни туннеля
Расширенный ID туннеля	32-битный идентификатор, используемый в сессии и сохраняемый на протяжении жизни туннеля. Обычно устанавливается равным нулю. Входные узлы, которые хотят сузить область сессии до пары вход-выход, могут поместить сюда свой IPv4 адрес в качестве глобально уникального идентификатора

Класс = SESSION, LSP_TUNNEL_IPv6 C_тип = 8

Объект отправителя Template (шаблон)

(рис 12.43)

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

Объект шаблона отправителя LSP_TUNNEL_IPv4

Класс = SENDER_TEMPLATE, LSP_TUNNEL_IPv4 Cтип = 7

(рис 12.44)

IPv4-адрес отправителя для туннеля	IPv4 адрес узла отправителя
LSP ID	16-битовый идентификатор, используемый в `SENDER_TEMPLATE` и `FILTER_SPEC`, который может быть изменен, чтобы позволить отправителю совместное использование ресурсов

Объект шаблона отправителя LSP_TUNNEL_IPv6

Класс = SENDER_TEMPLATE, LSP_TUNNEL_IPv6 C_тип = 8

Объект спецификации фильтра

(рис 12.45)

IPv6 адрес отправителя туннеля	IPv6 адрес узла отправителя
LSP ID	16-битовый идентификатор, используемый в SENDER_TEMPLATE и FILTER_SPEC, который может быть изменен, чтобы позволить отправителю совместное использование ресурсов

Объект спецификации фильтра LSP_TUNNEL_IPv4

Класс = FILTER SPECIFICATION, LSP_TUNNEL_IPv4 C-тип = 7

Формат объекта LSP_TUNNEL_IPv4 FILTER_SPEC идентичен формату LSP_TUNNEL_IPv4 SENDER_TEMPLATE.

Объект спецификации фильтра LSP_TUNNEL_IPv6

Класс = FILTER SPECIFICATION, LSP_TUNNEL_IPv6 C_тип = 8

Формат объекта LSP_TUNNEL_IPv6 FILTER_SPEC идентичен формату LSP_TUNNEL_IPv6 SENDER_TEMPLATE.

Процедура изменения маршрута и увеличения полосы

Ниже описывается то, как формируется туннель, способный поддерживать резервирование ресурсов, когда меняется маршрут или когда делается попытка увеличить полосу. В исходном сообщении Path входной узел образует объект SESSION, присваивает Tunnel_ID и помещает его IPv4-адрес в Extended_Tunnel_ID. Он также формирует SENDER_TEMPLATE и присваивает LSP_ID. Конфигурация туннеля продолжается согласно обычной процедуре. При получении сообщения Path оконечный узел посылает входному узлу сообщение Resv со стилем Shared Explicit.

Когда входной узел с установленным проходом хочет изменить маршрут, он формирует новое сообщение Path следующим образом. Используется существующий объект SESSION. Входной узел, чтобы сформировать новый SENDER_TEMPLATE, берет новый LSP_ID. Для нового маршрута он создает объект EXPLICIT_ROUTE. Посылается новое сообщение Path. Входной узел обновляет старое и новое сообщения path. Выходной узел откликается сообщением Resv с дескриптором потока SE, сформированным следующим образом:

<FLOWSPEC><old_FILTER_SPEC><old_LABEL_OBJECT><new_FILTER_SPEC>
<new_LABEL_OBJECT>

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

11.4.7. Объект атрибута сессии

Атрибут класса сессии равен 207. Определены два C_типа, LSP_TUNNEL, C-тип = 7 и LSP_TUNNEL_RA, C-тип = 1. C-тип LSP_TUNNEL_RA включает в себя те же поля, что и LSP_TUNNEL C-тип. Используются следующие форматы.

Формат без привязки ресурсов

Класс SESSION_ATTRIBUTE = 207, LSP_TUNNEL C-тип = 7

(рис 12.46)

Приоритет Setup	Приоритет сессии с учетом используемых ресурсов, в диапазоне от 0 до 7. Значение нуль имеет высший приоритет. Приоритет Setup используется при решении того, может ли сессия идти вне очереди по отношению к другой сессии
Приоритет	Приоритет сессии по отношению к удерживаемым ресурсам, в диапазоне от 0 до 7. Значение нуль имеет высший приоритет. Приоритет владения используется при решении, может ли сессия идти вне очереди по отношению к другой сессии
Флаги	0x01. Желательна локальная защита. Этот флаг позволяет промежуточным маршрутизаторам использовать механизм локального восстановления, который может привести к порче объекта явный маршрут. Когда обнаружена ошибка в смежном канале вниз по течению или узле, промежуточный маршрутизатор может изменить путь трафика для быстрой службы восстановления. 0x02 нужна запись метки Этот флаг указывает, что при записи маршрута следует включить информацию о метке. 0x04 нужен стиль SE Этот флаг указывает, что входной узел туннеля может решить изменить маршрут без его ликвидации. Выходной узел туннеля должен использовать стиль SE, при реагировании на сообщение Resv
Длина имени	Длина отображаемой строки в байтах до заполнителя.
Имя сессии	Строка символов, дополненная нулем

Формат без привязки ресурса

Класс SESSION_ATTRIBUTE = 207, LSP_TUNNEL_RA C-тип = 1

(рис 12.47)

Исключить любой	32-битный вектор, представляет собой набор атрибутов фильтров, сопряженных с туннелем, каждый из которых может объявлять канал неприемлемым
Включить любой	32-битный вектор, представляет собой набор атрибутов фильтров, сопряженных с туннелем, каждый из которых может объявить канал приемлемым (с точки зрения данного теста). Нулевой набор (все биты равны нулю) автоматически проходит
Включить все	32-битный вектор, представляет собой набор атрибутов фильтров, сопряженных с туннелем, каждый из которых должен присутствовать, чтобы канал был приемлем (с точки зрения данного теста). Нулевой набор (все биты равны нулю) автоматически проходит
Приоритет Setup	Приоритет сессии с точки зрения захвата ресурсов в диапазоне от 0 до 7. Значение нуль имеет высший приоритет. Приоритет Setup используется при решении, может ли сессия идти вне очереди по отношению к другой сессии
Приоритет удержания	Приоритет сессии с точки зрения удержания ресурсов в диапазоне от 0 до 7. Значение нуль имеет высший приоритет. Приоритет удержания используется при решении, может ли сессия быть замещена другой сессией
Флаги	0x01 Желательна локальная защита. Этот флаг позволяет промежуточным маршрутизаторам использовать механизм локального восстановления, который может вызвать нарушение объекта явного маршрута. Когда детектирована ошибка в смежном канале вниз по течению или узле, транзитный маршрутизатор может переадресовать трафик для службы быстрого восстановления 0x02 Требуется запись меток. Этот флаг указывает, что при записи маршрута информация о метке должна быть включена. 0x04 Желателен стиль SE. Этот флаг индицирует то, что входной узел туннеля может решить изменить маршрут этого туннеля без его удаления. Узел конца туннеля, реагируя на сообщение Resv, должен использовать стиль SE
Длина имени	Длина отображаемой строки до заполнителя в байтах
Имя сессии	Строка символов дополненная нулем

Процедуры, применимые к обоим C-типам

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

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

Приоритет Setup является приоритетом получения ресурсов. Приоритет удержания является приоритетом удержания ресурса.

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

Приоритеты setup и удержания являются прямыми аналогами приоритетного прерывания обслуживания и защитного приоритета, как это определено в [9]. В то время как взаимодействие этих двух объектов является, в конце концов, вопросом политики, следующие взаимодействия рекомендуются по умолчанию.

Когда присутствуют оба объекта, используется элемент приоритетного прерывания обслуживания. Соответствие между этими приоритетами определено следующим образом. Атрибут приоритета сессии S соответствует приоритету прерывания обслуживания P согласно формуле P = 2^(14-2S). Таблица соответствия приоритетов представлена ниже.

Приоритетное прерывание обслуживания	Приоритет атрибута сессии
0 - 3	7
4 - 15	6
16 - 63	5
64 - 255	4
256 - 1023	3
1024 - 4095	2
4096 - 16383	1
16384 - 65535	0

Когда рассматривается новое сообщение Path с точки зрения приемлемости, запрашиваемая полоса сравнивается с возможной полосой в случае приоритета, заданного в Setup.

Если запрашиваемая полоса недоступна, посылается сообщение PathErr с кодом ошибки 01 (Admission Control Failure) и значением ошибки 0x0002. Первый 0 в значении ошибки указывает на глобально определенный субкод и не несет в себе конкретных данных. Код 002 указывает: запрошенная полоса недоступна.

Если запрашиваемая полоса меньше неиспользуемой, тогда обработка запроса завершена. Если запрашиваемая полоса доступна, но занята менее приоритетными сессиями, тогда эти сессии (начиная с самой низкоприоритетной) могут быть прерваны для получения требующейся полосы.

Когда поддерживается приоритетное прерывание обслуживания, каждое из таких приоритетных резервирований осуществляет запрос TC_Preempt() локальным клиентам, передавая субкод, который указывает на причину этого запроса. В этом случае следует послать нижестоящим получателям и вышестоящим отправителям ResvErr и/или PathErr с кодом Policy Control failure.

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

Запись субобъекта метка в объект ROUTE_RECORD управляется флагом записи метки в объекте SESSION_ATTRIBUTE. Так как субобъект метка не нужен всем приложениям, он не записывается автоматически. Флаг позволяет приложениям запрашивать это только в случае необходимости.

Содержимым поля имя сессии является строка отображаемых символов. Поле длина должно всегда быть кратным 4 и быть не меньше 8. Для объектов, длина которых не кратна 4, объект дополняется в конце символами NULL. Поле длина имени содержит длину этой строки.

Процедуры привязки ресурсов

Классы ресурсов и привязки классов ресурсов описаны в [3]. Классы ресурсов могут быть ассоциированы с каналами и объявляться в протоколах маршрутизации. Привязка класса ресурса используется RSVP двумя путями. Для того, чтобы канал был признан работающим, он должен пройти три теста. Если тест не прошел, следует послать PathErr с кодом ошибка управления политикой.

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

Чтобы точно описать тесты, используем определения объектов, представленные выше. Определяется также

Linkattr 32-битовый вектор, представляющий собой атрибуты, ассоциированные с каналом

Осуществляются три проверки.

Исключает любой

Эта проверка исключает канал из рассмотрения, если он характеризуется одним из атрибутов набора. (linkattr excludeany) == 0

Включает любой т тест воспринимает канал, если он характеризуется любым атрибутом из набора. (includeany == 0) | ((linkattr includeany) != 0)

Включает все т тест воспринимает канал, если только он характеризуется всеми атрибутами из набора. (includeall == 0) | (((linkattr includeall) ^ includeall) == 0)

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

Если сообщение Path содержит несколько объектов SESSION_ATTRIBUTE, только первый объект имеет смысл. Последующие объекты SESSION_ATTRIBUTE могут игнорироваться и не должны переадресовываться.

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

Расширение Hello

Расширение RSVP Hello позволяет узлам RSVP детектировать, когда соседний узел недоступен. Механизм предоставляет возможность поузлового детектирования отказа. Когда такой отказ детектирован, он обрабатывается так же, как и отказ канального уровня. Этот механизм предназначен для использования, когда нет уведомления об отказе канала и не применяются ненумерованные каналы или когда механизмы детектирования отказов, предоставляемые канальным уровнем, недостаточны для своевременного детектирования отказов узлов.

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

Расширение Hello состоит из сообщения Hello, объектов HELLO REQUEST и HELLO ACK. Обработка Hello двумя соседями поддерживает независимый выбор обычно конфигурируемых интервалов детектирования отказов. Каждый сосед может автономно формировать объекты HELLO REQUEST. Получение каждого запроса подтверждается. Сообщения Hello содержат также достаточно информации, так что один сосед может подавить посылку запросов Hello и все же выполнить детектирование отказа соседа. Сообщение Hello может быть включено в виде составной части в блочное сообщение.

Детектирование отказа соседа выполняется путем получения и запоминания атрибута соседа. Если зарегистрировано изменение значения или если сосед некорректно сообщает локально объявленное значение, тогда сосед предполагается отключенным. Когда обнаружено, что атрибут соседа изменился или связь с соседом потеряна, тогда значение атрибута говорит об изменении соседа. Объекты HELLO предоставляют механизм посылки запросов и предоставления значения атрибута. Запрос регистрации включает также значение атрибута отправителя. Это позволяет получателю регистрации опционно обрабатывать эти данные как неявный отклик на регистрацию. Такая опционная обработка является оптимизацией, которая может уменьшить полное число запросов и откликов, обработанных парами соседей. Во всех случаях, когда обе стороны поддерживают оптимизацию, результатом будет только набор запросов и откликов за интервал детектирования отказа. В зависимости от выбранных интервалов, можно получить выигрыш, даже когда только один сосед поддерживает оптимизацию.

Формат сообщения Hello

Сообщениями Hello всегда обмениваются только RSVP соседи. Адрес IP-отправителя равен IP-адресу узла-отправителя. IP-адрес места назначения равен IP-адресу соседнего узла.

Механизм HELLO предназначен для использования только непосредственными соседями. Когда обмен сообщениями HELLO осуществляют соседи, поле IP TTL всех исходящих сообщений HELLO следует устанавливать равным 1.

Сообщение Hello имеет тип Msg равный 20. Формат сообщения Hello показан ниже.

<Hello Message> ::=  <Common Header> [ <INTEGRITY> ]
              <HELLO>

Форматы объекта HELLO

Код класса HELLO = 22. Определено два C_типа.

Объект HELLO REQUEST

Класс = HELLO, C_тип = 1

Объект содержит атрибут отправителя (32 бита) и атрибут получателя (32 бита).

Объект HELLO ACK

Класс = HELLO, C_тип = 2

Объект HELLO ACK содержит 32-битный атрибут отправителя Src_Instance и 32-битный атрибут получателя Dst_Instance. Значение должно измениться, если отправитель отключился, когда узел перезагружается или когда связь с узлом-соседом оборвалась, в противном случае значение остается неизменным. Это поле не должно иметь значения нуль.

Значение атрибута Src_Instance равно атрибуту отправителя, полученному последним. Это поле должно равняться нулю, до тех пор, пока ничего от соседа не получено.

Использование сообщения Hello

Сообщение Hello является полностью опционным. Все сообщения могут игнорироваться узлами, которые не хотят участвовать в обработке сообщений Hello.

Узел периодически генерирует сообщение Hello, содержащее объект HELLO REQUEST, для каждого соседа, чей статус должен быть отслежен. Периодичность определяется значением hello_interval. Это значение может конфигурироваться для каждого соседа. Значение по умолчанию равно 5 мсек.

При генерации сообщения, содержащего объект HELLO REQUEST, отправитель заносит в поле Src_Instance значение его атрибута для каждого из соседей. Эта величина не должна изменяться в процессе обмена сообщениями Hello с соответствующими соседями. Отправитель заносит также в поле Dst_Instance значение Src_Instance, полученное от соседа последним. Для ссылки назовем эту переменную Neighbor_Src_Instance. Если от соседа ничего не получено или узел считает связь с соседом потерянной, значение Neighbor_Src_Instance устанавливается равным нулю (0). Генерация сообщения следует подавить, когда объект HELLO REQUEST был получен от узла адресата в пределах интервала hello_interval.

Получив сообщение, содержащее объект HELLO REQUEST, адресат должен сформировать сообщение Hello, содержащее объект HELLO ACK. Получателю также следует проверить, что сосед активен. Это делается путем сравнения значения поля атрибута отправителя Src_Instance со значением, полученным ранее. Если значение Neighbor_Src_Instance равно нулю, а поле Src_Instance не равно нулю, значение Neighbor_Src_Instance обновляется. Если значения отличаются или поле Src_Instance равно нулю, тогда узел должен считать связь с соседом разорванной.

Получатель объекта HELLO REQUEST должен также проверить, что сосед возвращает назад значение атрибута получателя. Это делается путем сравнения полученного значения поля Dst_Instance с Src_Instance, посланным соседу последним. Если сосед продолжает рассылать неверное ненулевое значение после заданного числа временных интервалов, тогда узел считает соседа отключенным.

Получив сообщение, содержащее объект HELLO ACK, адресат должен проверить, что сосед активен. Это делается путем сравнения значения поля отправителя Src_Instance со значением, полученным до этого. Если значение Neighbor_Src_Instance равно нулю, а Src_Instance не равно нулю, величина Neighbor_Src_Instance обновляется. Если значения отличаются или поле Src_Instance не равно нулю, тогда узел должен считать связь с соседом оборванной.

Получатель объекта HELLO ACK должен также проверить, что сосед возвращает назад значение атрибута получателя. Если сосед рассылает неверное значение в поле Dst_Instance, тогда узел должен считать связь с соседом оборванной.

Если не получено от соседа никакого значения атрибута, через посредство объектов REQUEST или ACK, за оговоренное число hello_intervals, тогда узел должен предположить, что он не может связаться с соседом. Значение по умолчанию для этого числа равно 3.5.

Когда канал разорван или предполагается, что разорван, как это описано выше, узел может заново послать HELLO. Если узел не выполнил повторную инициализацию, он должен использовать значение Src_Instance, отличное от предложенного в предыдущем сообщении HELLO. Это новое значение должно посылаться соответствующим соседям до тех пор, пока не случится сброс или повторная загрузка или пока не будет зарегистрирован новый отказ канала. Если новое значение атрибута от соседа не получено, тогда узел должен установить значение поля Dst_instance равным нулю.

Соображения по поводу многоканальности

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

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

12.2. Обобщенная мультипротокольная коммутация по меткам (GMPLS)

Введение

Архитектура протокола MPLS [RFC-3031] была определена для переадресации пакетов на основе меток. В этой архитектуре предполагалось, что маршрутизаторы LSR (Label Switching Router) могут:

распознавать границы пакетов или ячеек, и

обрабатывать заголовки пакетов (для LSR, способных распознавать границы пакетов) или заголовки ячеек (для LSR, способных распознавать границы ячеек).

Исходная архитектура теперь распространена на LSR, которые не могут распознавать ни границы пакетов, ни границы ячеек и, следовательно, не могут переадресовать данные на основе информации, содержащейся в заголовках пакетов или ячеек. Такие LSR, в частности, включают в себя устройства, где решение о переадресации принимается на основе временного домена, длины волны или номера физического порта. Рассмотренная ниже технология является следующим поколением средств телекоммуникаций (см. также RFC-4003, -4139, -4202, -4206, -4208, -4427, -4257, -4258, -4328, -4397, -4426, -4428, -4783).

Подобные LSR или, точнее, интерфейсы LSR могут быть отнесены к следующим классам.

Интерфейсы, которые распознают границы пакетов/ячеек и могут переадресовать данные с учетом содержимого заголовка пакета/ячейки. Примерами могут служить интерфейсы маршрутизаторов, которые переадресуют данные на основе содержимого промежуточных заголовков, или интерфейсы ATM-LSR, которые переадресуют данные на основе VPI/VCI (ATM). Такие интерфейсы считаются способными коммутировать пакеты (PSC PacketSwitch Capable).

Интерфейсы, которые переадресуют данные на основе циклических временных доменов. Примером такого интерфейса является соединение SONET/SDH. Такие интерфейсы считаются мультиплексирующими по времени (TDM).

Интерфейсы, переадресующие данные на основе длины волны, на которой данные получены. Примером такого интерфейса является оптические коммутаторы, которые работают на уровне длин волн. Такие интерфейсы считаются ?переключателями LSC (Lambda Switch Capable).

Интерфейсы, которые переадресуют данные на основе положения данных в реальном физическом пространстве. Примером такого интерфейса является оптическое подключение, которое работает на уровне одного (или нескольких) волокон. Такие интерфейсы считаются оптическими переключателями FSC (FiberSwitch Capable).

Использование концепции вложенных путей с коммутацией по меткам (LSP — Label Switching Path) позволяет системе масштабировать построение иерархии переадресаций (см. RFC-3471, L. Berger, январь 2003). На верху этой иерархии находятся интерфейсы FSC, далее следуют интерфейсы LSC, затем TDM, и, наконец, PSC. Таким образом, LSP, который имеет на входе и выходе интерфейс PSC, может образовывать цепи вложения с другими LSP, формируя LSP, который начинается и завершается интерфейсом TDM. Этот LSP, в свою очередь, может вкладываться (вместе с другими LSP) в LSP, который начинается и завершается интерфейсом LSC, который, в свою очередь, вкладывается совместно с другими путями в LSP, начинающийся и завершающийся интерфейсом FSC.

Установление LSP, который покрывает только первый класс интерфейсов, определено в RFC-3036, RFC-3212 и RFC-3209. Ниже предлагается функциональное описание расширений, которые необходимы для обобщения MPLS в направлении поддержки каждого из четырех классов интерфейсов. Форматы, специфические для протокола, определены в RFC-3473 и RFC-3472.

Обзор

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

В традиционном управлении трафиком MPLS (TE), каналы, через которые проходит LSP, могут содержать сегменты с разной кодировкой меток. Например, LSP может содержать каналы, соединяющие маршрутизаторы, каналы между маршрутизаторами и ATM-LSR, и каналы между ATM-LSR. Обобщенный MPLS осуществляет расширение функциональности путем включения каналов, где метка кодируется как временной домен, длина волны или позиция в физическом пространстве, например, номер волокна. Так же, как и в традиционном протоколе MPLS TE, где не все LSR могут распознавать границы IP-пакетов (например, ATM-LSR), обобщенный MPLS включает в себя поддержку LSR, которые не распознают границ IP-пакетов. В традиционном пути MPLS TE, который транспортирует IP, маршрут должен начинаться и завершаться в маршрутизаторе. Обобщенный MPLS требует, чтобы LSP начинался и завершался в LSR того же типа. Кроме того, в обобщенном протоколе MPLS тип данных, который транспортируется через LSP, может включать в себя SONET/SDH, GE или 10-Гбитный Ethernet. Эти изменения традиционного MPLS отражаются в механизме запроса и переноса меток.

Другим базовым отличием традиционного и не-PSC типа обобщенного LSP MPLS, является то, что полоса пропускания выделяется для LSP дискретными порциями. Заметим, что использование FA (Forwarding Adjacencies, смотри [MPLS-HIERARCHY]), предоставляет механизм, который может улучшить использование полосы пропускания, когда выделение полосы осуществляется дискретным образом, а также механизм агрегатирования состояния переадресации, что может сократить требуемое число меток.

Обобщенный MPLS допускает возможность предложения метки вышестоящим узлом. Это предложение может быть отвергнуто нижестоящим узлом, за счет увеличения времени установления LSP. Предлагаемая метка представляет ценность, когда LSP устанавливается через определенное оптическое оборудование, где конфигурирование системы коммутации может быть долгим. Например, микрозеркала могут быть подняты или удалены, и это физическое перемещение и последующее установление потребует времени. Если метки и, следовательно, оптическая система коммутации сконфигурированы в обратном порядке (что является нормой), может потребоваться задержать сообщение MAPPING/Resv на десятки миллисекунд на один шаг, чтобы установить маршрут переадресации. Предлагаемая метка может быть полезной также при восстановлении в случае отказа узла.

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

В то время как традиционный трафик, формируемый MPLS, является однонаправленным, обобщенный MPLS поддерживает установление двунаправленных LSP. Необходимость двунаправленных LSP вызвана не-PSC приложениями (PSC=PacketSwitch Capable). Существует много причин, почему нужны такие LSP, — в частности, конкуренция за ресурсы при формировании LSP с привлечением разных сигнальных сессий и упрощение процедур восстановления при ошибках в случае не-PSC. Двунаправленные LSP имеют также преимущества малой задержки установления канала и малого числа сообщений при реализации этого процесса.

Обобщенный MPLS поддерживает специфические метки для специальных интерфейсов. В документе RFC-3473 рассмотрены также специальные механизмы RSVP для быстрого уведомления об ошибках.

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

Форматы, относящиеся к меткам

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

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

Обобщенные запросы меток

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

Запрос обобщенной метки содержит параметр кодирования LSP, называемый типом кодирования LSP. Этот параметр указывает тип кодирования, скажем, SONET/SDH/GigE и т.д., который будет использоваться для данных, ассоциированных с LSP. Тип кодирования LSP характеризует природу LSP, а не природу каналов, через которые он проходит. Канал может поддерживать несколько форматов кодирования, где под поддержкой подразумевается то, что канал может транспортировать и коммутировать сигналы одного или более форматов кодирования в зависимости от доступных ресурсов и емкости канала. Например, рассмотрим LSP с управлением посредством ?кодирования. Ожидается, что такой LSP не поддерживает электронных преобразований, и ничего не известно о модуляции и быстродействии промежуточных узлов. Другие форматы обычно требуют знания структуры кадров и параметров полей.

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

Информация, транспортируемая в обобщенном запросе метки, имеет формат, показанный на рис. 12.48:

Тип кодирования LSP: 8 бит

Указывает на запрашиваемый тип кодирования LSP. Ниже представлена таблица возможных значений этого поля (табл. 12.13).

значение	Тип
1	Пакет
2	Ethernet
3	ANSI/ETSI PDH
4	Зарезервировано
5	SDH ITU-T G.707 / SONET ANSI T1.105
6	Зарезервировано
7	Цифровой конверт
8	Lambda (оптическое)
10	Зарезервировано
11	Fiber Channel

ANSI PDH и ETSI PDH обозначают соответствующие сетевые технологии. DS1 и DS3 являются примерами ANSI PDH LSP. E1 LSP будет ETSI PDH. Тип кодирования Lambda относится к LSP, которые охватывают все длины волн. Тип кодирования волокно (Fiber) относится к LSP, работающим с оптоволоконным портом.

Тип коммутации: 8 бит

Указывает на тип коммутации, которая должна осуществляться в заданном канале. Это поле необходимо для каналов, которые анонсируют более одного типа коммутации; его следует связать с одним из значений, анонсированных для соответствующих каналов в описателе возможностей маршрутной коммутации (Switching Capability Descriptor, смотри [GMPLS-RTG]). В настоящее время определены следующие значения (табл. 12.14)

значение	Тип
1	Packet-Switch Capable-1 (PSC-1)
2	Packet-Switch Capable-2 (PSC-2)
3	Packet-Switch Capable-3 (PSC-3)
4	Packet-Switch Capable-4 (PSC-4)
51	Layer-2 Switch Capable (L2SC)
100	Time-Division-Multiplex Capable (TDM)
150	Lambda-Switch Capable (LSC)
200	Fiber-Switch Capable (FSC)

Обобщенный PID (G-PID): 16 бит

(рис 12.48)

Идентификатор поля данных, транспортируемых через LSP, т.е., идентификатор уровня клиента данного LSP. Он применяется в конечных точках LSP и иногда предпоследним узлом. Стандартные значения Ethertype используются для пакета и Ethernet LSP; прочие значения перечислены в таблице 12.15.

значение	Тип	Технология
0	Не определено	Все
1	Зарезервировано
2	Зарезервировано
3	Зарезервировано
4	Зарезервировано
5	Asynchronous mapping of E4	SDH
6	Asynchronous mapping of DS3/T3	SDH
7	Asynchronous mapping of E3	SDH
8	Bit synchronous mapping of E3	SDH
9	Byte synchronous mapping of E3	SDH
10	Asynchronous mapping of DS2/T2	SDH
11	Bit synchronous mapping of DS2/T2	SDH
12	Зарезервировано
13	Asynchronous mapping of E1	SDH
14	Byte synchronous mapping of E1	SDH
15	Byte synchronous mapping of 31 * DS0	SDH
16	Asynchronous mapping of DS1/T1	SDH
17	Bit synchronous mapping of DS1/T1	SDH
18	Byte synchronous mapping of DS1/T1	SDH
19	VC-11 в VC-12	SDH
20	Зарезервировано
21	Зарезервировано
22	DS1 SF Asynchronous	SONET
23	DS1 ESF Asynchronous	SONET
24	DS3 M23 Asynchronous	SONET
25	DS3 C-Bit Parity Asynchronous	SONET
26	VT/LOVC	SDH
27	STS SPE/HOVC	SDH
28	POS — No Scrambling, 16 bit CRC	SDH
29	POS — No Scrambling, 32 bit CRC	SDH
30	POS — Scrambling, 16 bit CRC	SDH
31	POS — Scrambling, 32 bit CRC	SDH
32	ATM mapping	SDH
33	Ethernet	SDH, $$\lambda$$, волокно
34	SONET/SDH	$$\lambda$$, волокно
35	Зарезервировано	$$\lambda$$, волокно
36	Цифровой конверт	$$\lambda$$, волокно
37	Lambda	Fiber
38	ANSI/ETSI PDH	SDH
39	Зарезервировано	SDH
40	Протокол доступа к каналу SDH LAPS –(X.85 и X.86)	SDH
41	FDDI	SDH, $$\lambda$$, волокно
42	DQDB (ETSI ETS 300 216)	FiberChannel
43	FiberChannel-3 (услуги)	FiberChannel+
44	HDLC	SDH
45	Ethernet V2/DIX (only)	SDH, $$\lambda$$, волокно
46	Ethernet 802.3 (only)	SDH, $$\lambda$$, волокно

Кодирование полосы пропускания

Кодирование полосы пропускания осуществляется 32-битовым числом в формате IEEE для чисел с плавающей запятой (измеряется в байтах/сек). Для беспакетных LSP полезно определить дискретные величины, чтобы идентифицировать полосу LSP. Некоторые типичные значения для запрошенной полосы перечислены ниже. Дополнительные значения будут определяться по мере необходимости. Значения кодов полосы ассоциируются с протоколами, смотри в таблице 12.16 ([RFC-3473] и RFC-3472).

Тип сигнала	Скорость обмена	значение (байт/сек) (Ieee плавающий формат)
DS0	0.064 Mbps (Мбит/с)	0x45FA0000
DS1	1.544 Mbps	0x483C7A00
E1	2.048 Mbps	0x487A0000
DS2	6.312 Mbps	0x4940A080
E2	8.448 Mbps	0x4980E800
Ethernet	10.00 Mbps	0x49989680
E3	34.368 Mbps	0x4A831A80
DS3	44.736 Mbps	0x4AAAA780
STS-1	51.84 Mbps	0x4AC5C100
Fast Ethernet	100.00 Mbps	0x4B3EBC20
E4	139.264 Mbps	0x4B84D000
FC-0 133M		0x4B7DAD68
OC-3 FC-0/STM-1	155.52 Mbps	0x4B9450C0
FC-0 266M		0x4BFDAD68
FC-0 531M		0x4C7D3356
OC-12/STM-4	622.08 Mbps	0x4C9450C0
GigE	1000.00 Mbps	0x4CEE6B28
FC-0 1062M		0x4CFD3356
OC-48/STM-16	2488.32 Mbps	0x4D9450C0
OC-192/STM-64	9953.28 Mbps	0x4E9450C0
10GigE-LAN	10000.00 Mbps	0x4E9502F9
OC-768/STM-256	39813.12 Mbps	0x4F9450C0

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

Обобщенная метка расширяет функциональность традиционной метки, допуская представление не только меток, которые транспортируются соответствующими информационными пакетами, но также меток, которые идентифицируют временные домены, длины волн или пространственное мультиплексирование по положению. Например, обобщенная метка может содержать данные, которые представляют (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.52) Конфликт меток(рис 12.51) Разрешение конфликта меток без ограничений ресурсов(рис 12.53) Разрешение конфликта меток посредством ограничений ресурсовЭто допускает включение определенных узлов/интерфейсов и завершение LSP в конкретном выходном интерфейсе выходного LSR.

Бывают случаи, когда существующая явная семантика маршрута не предоставляет достаточно информации для управления 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):

Тип	Длина	Формат	описание
1	8	IPv4 Addr.	IPv4
2	20	IPv6 Addr.	IPv6
3	12	см. ниже	IF_INDEX (индекс интерфейса)
4	12	см. ниже	COMPONENT_IF_DOWNSTREAM (состав¬ной интерфейс)
5	12	см. ниже	COMPONENT_IF_UPSTREAM (составной интерфейс)

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

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

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

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

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

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

(рис 12.56)

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

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

(рис 12.57)

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

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

12.3. Расширения протокола управления резервированием (RSVP-TE) при обобщенной многопротокольной коммутации по меткам (GMPLS)

Введение

Протокол обобщенного MPLS раздвигает его применимость с поддержки пакетных интерфейсов (PSC) и коммутации до поддержки трех новых классов интерфейсов и коммутации: TDM (TimeDivision Multiplex — мультиплексирование по времени), ?коммутатор (LSC) и волоконный коммутатор (FSC). Функциональное описание расширений MPLS, необходимых для поддержки новых классов интерфейсов и коммутации, сделано в [RFC-3471]. Ниже рассматриваются специфические форматы RSVP-TE и механизмы, необходимые для поддержки всех четырех классов интерфейсов (RFC-3473, L. Berger, January 2003).

RFC-3471 следует рассматривать как составную часть этого документа. Здесь определены также возможности RSVP-TE для поддержки быстрого уведомления об отказах.

Форматы, относящиеся к меткам. Объект запроса обобщенной метки

Сообщение Path, которое запоминают состояние пути в каждом узле вдоль маршрута и транспортирует запрос метки, должно содержать специфический тип кодирования LSP (Label Switched Path — путь с коммутацией по меткам), чтобы гарантировать максимальную гибкость коммутации в транзитных LSR (Label Switching Router). Объект запроса обобщенной метки устанавливается входным узлом, передается без изменений транзитными узлами, и используется узлом адресатом. Поле тип коммутации может изменяться от шага к шагу. Формат объекта запроса обобщенной метки показан ниже (рис. 12.58).

(рис 12.58)

Описание параметров смотри в [RFC-3471].

Узел, который обрабатывает сообщение Path, содержащее запрос обобщенной метки, должен проверить, что запрошенные параметры отвечают возможностям самого узла и интерфейса, через который передается трафик и которому приходящая метка должна быть присвоена. Узел может непосредственно поддерживать LSP или использовать туннель (FA), т.е. другой класс коммутации. В любом случае, должен проверяться каждый параметр. Заметим, что локальная политика узла определяет то, когда могут применяться туннели и когда они могут создаваться. Локальная политика допускает динамическое создание туннелей или динамическое управление. Более подробную информацию о туннелях и обработке ER-шагов при использовании туннелей можно найти в [MPLS_HIERARCHY].

Транзитные и оконечный узел должны проверять, что сам узел и, где необходимо, интерфейс или туннель, куда предается трафик, поддерживают запрошенный тип кодирования LSP. Если кодирование не поддерживается, узел должен генерировать сообщение PathErr с указанием "Routing problem/Unsupported Encoding" (проблема маршрутизации/неподдерживаемое кодирование).

Узлы должны проверять, что тип, указанный в параметре тип коммутации (Switching Type), поддерживается соответствующим входным интерфейсом. Если тип не поддерживается, узел должен сформировать сообщение PathErr с индикацией "Routing problem/Switching Type" (проблема маршрутизации/тип коммутации).

Параметр G-PID контролируется только на выходе. Если указанный G-PID не поддерживается, тогда выходной узел должен сформировать сообщение PathErr с указанием "Routing problem/Unsupported L3PID" (проблема маршрутизации/неподдерживаемый L3PID). В этом случае PSC и, когда запрашивается выдача предпоследнего узла (PHP), предпоследний узел также проверяет (запоминает) G-PID при обработке сообщения Resv. При этом, если G-PID не поддерживается, тогда предпоследний узел должен сформировать сообщение ResvErr с указанием "Routing problem/Unacceptable label value" (проблема маршрутизации/неприемлемое значение метки). Сформированное сообщение ResvErr может содержать набор приемлемых меток.

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

Кодирование полосы

Кодирование частотного диапазона выполняется в объектах SENDER_TSPEC и FLOWSPEC. Определения значений, используемых для специальных сигнальных типов, смотри в [RFC-3471]. Эти величины устанавливаются в поле Peak Data Rate (пиковая скорость передачи данных) объектов In t-Serv.

Объект обобщенной метки

Ниже представлен формат объекта обобщенной метки (рис. 12.59):

(рис 12.59)

Описание параметров и кодирования меток смотри выше и в [RFC-3471].

Обобщенные метки передаются вышестоящим LSR сообщениями Resv. Присутствие объектов обобщенной и нормальной метки в сообщении Resv является протокольной ошибкой и должно обрабатываться получателем как некорректное сообщение.

Получатель сообщения Resv, содержащего обобщенную метку, проверяет приемлемость полученных параметров. Если метка неприемлема, тогда получатель должен сформировать сообщение ResvErr с указанием "Routing problem/MPLS label allocation failure" (проблема маршрутизации/ошибка присвоения обобщенной метки MPLS).

Объект коммутируемого интервала длин волн

Коммутация частотных диапазонов использует тот же формат, что и обобщенная метка. Метка полосы частот использует C-тип (3).

В контексте коммутации частотных диапазонов обобщенная метка имеет следующий формат (рис. 12.60).

(рис 12.60)

Описание параметров смотри в [RFC-3471].

Рассматриваемые процедуры работают при коммутации диапазонов длин волн. Если какое-либо поле метки не распознано или имеет неприемлемое значение, генерируется сообщение ResvErr с указанием "Routing problem/MPLS label allocation failure" (проблема маршрутизации/ошибка присвоения обобщенной метки MPLS).

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

Эта операция должна быть выполнена для обоих направлений, если для диапазона длин волн используется двунаправленный туннель.

Объект предлагаемой метки

Формат объекта Suggested_Label аналогичен описанному для обобщенной метки. Он применяется в сообщениях Path. Объект Suggested_Label использует номер класса 129 (в форме 10bbbbbb ) и C-тип предлагаемой метки.

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

Согласно [RFC-3471], если в нижерасположенный узел приходит метка, которая отличается от предложенной сверху, вышестоящий LSR должен либо реконфигурироваться, либо отравлять сообщение ResvErr с указанием "Routing problem/Unacceptable label value" (проблема маршрутизации/неприемлемое значение метки). Кроме того, входной узел не должен передавать данные, используя предложенную метку, до тех пор, пока нижерасположенный узел не пришлет соответствующую метку вверх.

Объект набора меток

Объект Label_Set использует номер класса 36 (в форме 0bbbbbbb ) и C-тип 1. Он применяется в сообщениях Path. Label_Set имеет следующий формат (рис. 12.61).

(рис 12.61)

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

Указывает на тип и формат меток, содержащихся в объекте. Значения соответствуют C-типу объекта RSVP_LABEL. В этом поле используются только младшие 8 бит. Описания других параметров смотри выше в разделе 12 и в [RFC-3471].

Набор меток определяется одним или более объектами Label_Set. Специфические метки/субканалы могут быть добавлены или удалены из набора меток посредством объектов операций нуль (0) и один (1), соответственно. Диапазоны меток/субканалов могут дополняться или удаляться из набора меток посредством операций два (2) и три (3) объектов, соответственно. Когда объекты Label_Set только перечисляют метки/субканалы, подлежащие удалению, это подразумевает, что остальные метки приемлемы. Отсутствие любого объекта Label_Set подразумевает, что все метки приемлемы. Набор меток (Label Set) включается, когда узел желает ограничить перечень меток, которые могут использоваться ниже по течению.

По получении сообщения Path принимающий узел ограничит выбор меток одной из (Label Set). Узлы, способные осуществлять преобразования меток, могут также удалять набор меток, прежде чем переадресовать сообщение Path. Если узел не может извлечь метку из набора или если возникает проблема с анализом объектов Label_Set, тогда реализация запроса завершается и формируется сообщение PathErr с указанием "Routing problem/Label Set" (проблема маршрутизации/набор меток).

После получения сообщения Path список меток сравнивается с набором доступных меток для выходного интерфейса и список перекрытия пересылается в сообщении Path. Когда результирующий набор меток пуст, маршрут разрывается и посылается сообщение PathErr с указанием "Routing problem/Label Set" (проблема маршрутизации/набор меток).

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

При обработке сообщения Resv в промежуточном узле, метка, передаваемая наверх, должна входить в перечень меток (Label Set).

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

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

Установление двунаправленного LSP отмечается наличием вышестоящей метки (Upstream Label) в сообщении Path. Объект Upstream_Label имеет тот же формат, что и обобщенная метка. Объект Upstream_Label использует номер класса 35 (в форме 0bbbbbbb ) и C-тип метки.

Процедуры

Процесс установления двунаправленного LSP реализуется так же, как и для однонаправленного LSP с некоторыми дополнениями. Для поддержки двунаправленных LSP в сообщение Path добавляется объект Upstream_Label. Объект Upstream_Label должен определять метку, которая пригодна для переадресации в момент отправки сообщения Path.

Когда получено сообщение Path, содержащее объект Upstream_Label, получатель сначала проверяет, что вышестоящая метка приемлема. Если метка неприемлема, получатель должен послать сообщение PathErr с указанием "Routing problem/Unacceptable label value" (проблема маршрутизации/неприемлемое значение метки). Сформированное сообщение PathErr может содержать набор приемлемых меток.

Промежуточный узел должен присвоить метку для исходящего интерфейса и установить внутренние проходы для данных перед записью исходящей метки и отправкой сообщения Path. Если промежуточный узел не может присвоить метку или выделить внутренние ресурсы, то он должен послать сообщение PathErr с указанием "Routing problem/MPLS label allocation failure" (проблема маршрутизации/отказ выделения метки MPLS). Оконечные узлы обрабатывают сообщения Path как обычно, за исключением того, что вышестоящая метка может быть использована немедленно для передачи трафика данных, ассоциированных с LSP в направлении узла-инициатора.

Когда удаляется двунаправленный LSP, upstream (вышестоящая) и downstream (нижестоящая) метки аннулируются, после чего они становятся непригодными для пересылки данных.

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

Существует два потенциальных конфликта, которые следует рассматривать при формировании двунаправленного LSP с поддержкой RSVP-TE. Первый связан с тем, что в RSVP ID узла равно IP-адресу, используемому в объекте RSVP_HOP. Второй связан с тем, что ID узла соседа может быть неизвестен при посылке исходного сообщения Path. Когда это происходит, узел должен выбрать метку случайным образом из доступного набора.

Уведомление

Ниже рассмотрено несколько типов расширений, связанных с уведомлениями. Первое расширение определяет объект набора приемлемых меток (Acceptable Label Set) для поддержки уведомлений в случае ошибок с метками и других событий в узлах, ответственных за восстановление разрушенных LSP. Второе расширение, объект запроса уведомления (Notify Request), определяет ситуацию, при которой следует посылать уведомление. Третье расширение, сообщение Notify, предоставляет уведомление об общих событиях. Последнее расширение, относящееся к уведомлениям, позволяет удалять состояние Path при обработке сообщений PathErr.

Объект набора приемлемых меток

Объекты Acceptable_Label_Set используют номер класса 130 (в форме 10bbbbbb ). Остальное содержимое объекта, включая C-тип, имеет идентичный формат с объектом Label_Set.

Объекты Acceptable_Label_Set могут транспортироваться в сообщениях PathErr и ResvErr. Процедуры определения приемлемого списка меток (Acceptable Label Set) следуют за процедурами определения набора меток (Label Set). В частности, приемлемый набор меток определяется из одного или нескольких объектов Acceptable_Label_Set. С помощью объектов операций нуль (0) и один (1), соответственно, могут быть добавлены или исключены специфические метки/субканалы из перечня приемлемых меток. С помощью объектов операций (2) и (3), соответственно, могут быть добавлены или исключены диапазоны меток/субканалов. Когда объекты Acceptable_Label_Set просто перечисляют метки/субканалы, подлежащие удалению, это подразумевает, что все остальные метки являются приемлемыми.

Включение объектов Acceptable_Label_Set является опционным. Если такой объект включен, сообщение PathErr или ResvErr должно содержать указание на "Routing problem/Unacceptable label value" (проблема маршрутизации/неприемлемое значение метки). Отсутствие объекта Acceptable_Label_Set не имеет никакого специального значения.

Объекты запросов уведомления

Уведомления могут посылаться с помощью сообщений Notify, определенных ниже. Объект запроса уведомления используется для запроса генерации уведомления. Уведомление, т.е., посылка сообщения Notify, может быть запрошено как сверху, так и снизу LSP.

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

Объект запроса уведомления может транспортироваться в сообщениях Path или Resv. Номер класса Notify_Request равен 195 (в форме 11bbbbbb). Запрос уведомления имеет следующий формат (рис. 12.62):

(рис 12.62)

Объект запроса уведомления IPv4

Адрес узла уведомления IPv4: 32 бита

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

Объект запроса уведомления IPv6 (рис. 12.63)

Адрес узла уведомления IPv6: 16 байт

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

(рис 12.63)

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

Объект запроса уведомления (Notify Request) может быть введен в сообщение Path или Resv, чтобы указать адрес узла, который должен быть уведомлен об отказе LSP. Как было замечено выше, могут посылаться запросы уведомления как вверх, так и вниз по течению. Уведомления, направленные вверх, отмечаются включением объекта запроса уведомления (Notify Request Object) в соответствующее сообщение Path. Уведомления, направленные вниз, отмечаются включением объекта запроса уведомления в соответствующее сообщение Resv. Узел, получающий сообщение, которое содержит объект запроса уведомления, должен запомнить адрес узла уведомления (Notify Node Address) в соответствующем блоке состояний. Если узел является транзитным, он также должен включить объект запроса уведомления в исходящее сообщение Path или Resv. Исходящий адрес узла уведомления может корректироваться на основе местной политики.

Заметим, что включение объекта запроса Notify не гарантирует того, что сообщение Notify будет сформировано.

Сообщение уведомления

Сообщение Notify предоставляет механизм информирования несмежных узлов LSP о событиях. Сообщения Notify обычно генерируются только после получения объекта запроса уведомления. Сообщения Notify отличается от определенных ранее сообщений об ошибках (т.е., сообщения PathErr и ResvErr) тем, что они могут быть адресованы узлу, отличному от ближайшего соседа сверху или снизу. Сообщение Notify не заменяет существующие сообщения об ошибках. Оно может быть послано либо (a) в нормальной ситуации, когда транзитные узлы переадресуют сообщения Notify узлу-адресату, подобно обработке ResvConf в [RFC-2205]; либо (b) путем инкапсуляции в новый IP заголовок, чье место назначения соответствует IP-адресу места назначения. Вне зависимости от механизма передачи, узлы, получающие сообщение Notify, не адресованное им, просто передают его дальше без модификации.

Чтобы обеспечить надежную доставку сообщения Notify, используется сообщение Ack [RFC-2961] для подтверждения получения сообщения. Подробности надежной доставки сообщений RSVP смотри в [RFC-2961].

Сообщение уведомления Notify является обобщенным сообщением уведомления. IP-адрес места назначения устанавливается равным адресу запросившего получателя. Сообщение Notify посылается без аварийной опции маршрутизатора. Одно сообщение Notify может содержать несколько уведомлений.

Объект ERROR_SPEC специфицирует ошибку и включает в себя IP-адрес узла, детектировавшего ошибку, или отказавшего канала. Определение ERROR_SPEC смотри в [RFC-2205]. MESSAGE_ID и сопряженные с ним объекты определены в [RFC-2961].

Сообщения Notify чаще всего генерируются узлами, зарегистрировавшими ошибку, которая запустила процесс формирования сообщения PathErr или ResvErr. Если нужно сформировать сообщение PathErr и получен объект запроса уведомления в соответствующем сообщении Path, тогда должно быть сформировано сообщение Notify, адресованное указанному узлу. Если должно быть сформировано сообщение ResvErr и в соответствующем сообщении Resv получен объект запроса уведомления, тогда должно быть сформировано сообщение Notify, адресованное указанному узлу. Как ранее упоминалось, одна ошибка может вызвать сообщения Notify, направленные вверх и вниз по течению. Заметим, что сообщение Notify не должно генерироваться, если только не получен соответствующий объект запроса уведомления.

Когда генерируются сообщения Notify, узел должен попытаться объединить уведомления, адресованные одному и тому же узлу, и использовать в сообщении Notify одну и ту же общую ERROR_SPEC. Средства, с помощью которых узел определяет, какую информацию можно объединить, зависят от конкретной реализации. Если для этой цели применяется таймер, реализация должна позволять пользователю конфигурировать интервал, в течение которого уведомления объединяются; длительность интервала уведомлений в этом случае по умолчанию равна 1 мсек. Сообщения Notify должны доставляться с использованием механизма надежной доставки, описанного в [RFC-2961].

После получения сообщения уведомления узел должен послать соответствующие сообщение Ack.

Удаление состояния с помощью сообщения PathErr

Сообщение PathErr, как это определено в [RFC-2205], посылается от узла к узлу отправителю соответствующего сообщения Path. Промежуточные узлы могут инспектировать это сообщение, но не должны ничего предпринимать. В среде, где сообщения Path маршрутизируются согласно IGP, а маршруты могут изменяться динамически, такое поведение является позитивным.

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

Ситуация может существенно улучшиться, если разрешить промежуточным узлам при определенных ошибках удалять состояния. Чтобы облегчить эту процедуру, в объекте ERROR_SPEC определен новый флаг. Два описанных в настоящее время объекта ERROR_SPEC (объекты спецификации ошибки IPv4 и IPv6) содержат однобайтное поле флага. В этом поле определены два флага. Данная спецификация определяет третий флаг, 0x04, Path_State_Removed.

Семантика флага Path_State_Removed означает, что узел, переадресующий сообщение ошибки, удалил состояние Path, ассоциированное с PathErr. По умолчанию, флаг Path_State_Removed всегда равен нулю при генерации или при переадресации сообщения PathErr. Узел, который сталкивается с ошибкой, может установить этот флаг, если ошибка вызывает ликвидацию состояния, заданного в Path. Если узел, устанавливающий флаг, не является местом назначения, он должен сформировать соответствующее сообщение PathTear. Узел, получающий сообщение PathErr, которое содержит объект ERROR_SPEC с установленным флагом Path_State_Removed, может также удалить соответствующее состояние Path. Если состояние Path удалено, в исходящем сообщении PathErr следует установить флаг Path_State_Removed. Узел, который не удаляет ассоциированное состояние Path, не должен устанавливать флаг Path_State_Removed. Узел, который получает сигнал ошибки с флагом Path_State_Removed, равным нулю, не должен устанавливать этот флаг, если только он не генерирует соответствующее сообщение PathTear. Заметим, что использование этого флага не вызывает каких-либо проблем совместимости.

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

Метки ERO (Explicit Route Object) и субобъекты RRO (Record Route Object) определены для поддержки явного управления метками. Заметим, что субобъект RRO метки определен в [RFC-3209] и расширен для поддержки двунаправленных LSP.

Субобъект ERO метки

Субобъект ERO метки определен следующим образом (рис. 12.64):

(рис 12.64)

Описание L, U и параметров метки смотри в [RFC-3471].

Тип = 3 (метка)

Длина

Поле длина содержит общую длину субобъекта в байтах, включая поля тип и длина. Длина должна быть кратной 4.

C-тип

C-тип включенного объекта метка. Копируется из объекта метка.

Субобъект метки следует за субобъектом, содержащим IP-адрес или идентификатор интерфейса [RFC-3477], ассоциированные с каналом, где его планируется использовать. Могут присутствовать до двух субобъектов метки, один для метки вниз и один для метки вверх по течению. В следующих ситуациях вырабатывается сигнал ошибки "Bad EXPLICIT_ROUTE object" (плохой объект явного маршрута):

если субобъекту, содержащему IP-адрес, не предшествует первый субобъект метки или идентификатор интерфейса [RFC-3477], ассоциированные с исходящим каналом;

для субобъекта метки, следующего за субобъектом с установленным битом L;

при установке однонаправленного LSP, если должен быть субобъект метки с установленным битом U ;

если имеются два субобъекта метки с идентичными значениями бита U.

Чтобы поддерживать субобъект метки, узел должен проверять, является ли субобъект, следующий за его ассоциированным адресом/интерфейсом, субобъектом метки. Если это так, один субобъект просматривается для однонаправленных LSP и два — для двунаправленных. Если бит U субобъекта равен нулю, тогда значение метки копируется в новый объект Label_Set. Этот объект Label_Set должен быть включен в соответствующее исходящее сообщение Path.

Если U -бит рассматриваемого субобъекта равен 1, то метка относится к восходящему потоку (для двунаправленного LSP). Если эта метка неприемлема, должно формироваться сообщение ошибки "Bad EXPLICIT_ROUTE object" (плохой объект явного маршрута). Если метка приемлема, она копируется в новый объект Upstream_Label. Этот объект Upstream_Label должен быть включен в соответствующее исходящее сообщение Path. После обработки субобъекты метки удаляются из ERO.

Из рассмотрения описанных процедур следует вывод, что субобъекты метки никогда не могут быть первыми субобъектами во вновь полученном сообщении. Если субобъект метки является первым субобъектом в полученном ERO, тогда ситуация должна рассматриваться как ошибка "Bad strict node".

Субобъект RRO метки

Субобъект RRO метки имеет следующий формат (рис. 12.65):

(рис 12.65)

Описания параметров U и метки смотри в [RFC-3471].

Тип 3 (метка)

Длина. Описание смотри в [RFC-3209].

Флаги. Описание смотри в [RFC-3209].

C-тип. C-тип включенного объекта метки. Копируется из объекта метки.

Субобъекты RRO метки включаются в RRO, как это описано в [RFC-3209]. Единственное отличие в использовании и обработке по сравнению с [RFC-3209] заключается в том, что для меток двунаправленных LSP должны быть добавлены субобъекты для обоих направлений.

Объект защиты

Использование объекта защиты является опционным. Объект включается для описания специфических атрибутов защиты LSP. Объект защиты использует номер класса 37 (в форме 0bbbbbbb ). Объект защиты имеет формат (рис. 12.66):

(рис 12.66)

Процедуры

Транзитные узлы, обрабатывающие сообщение Path, которое содержит объект защиты (Protection Object), должны проверять, можно ли реализовать запрашиваемую защиту в выходном интерфейсе или туннеле (FA). Если это невозможно, узел должен сформировать сообщение PathErr, со значением "Routing problem/Unsupported Link Protection" (проблема маршрутизации/неподдерживаемая защита канала).

Административная информация состояний

Административная статусная информация содержится в объекте Admin_Status. Объект предоставляет информацию, относящуюся к административному состоянию конкретного LSP. Информация используется двумя способами. В первом — объект содержится в сообщениях Path и Resv для указания административного состояния LSP. Во втором — объект транспортируется в сообщении уведомления для запроса к входному узлу изменить административное состояние LSP.

Объект административного статуса

Использование объекта Admin_Status является опционным. Он использует номер класса (ClassNumber) 196 (в виде 11bbbbbb ). Формат объекта Admin_Status имеет вид (рис. 12.67):

(рис 12.67)

Описания параметров смотри выше и в [RFC-3471].

Процедуры для сообщений Path и Resv

Объект Admin_Status используется для уведомления каждого узла вдоль пути о состоянии LSP. Статусная информация обрабатывается всеми узлами, основываясь на местной политике, и затем передается соответствующими сообщениями. Объект может быть вставлен в сообщение Path для входного узла или Resv — для выходного. Отсутствие объекта эквивалентно получению объекта, со всеми значениями, равными нулю. Транзитные узлы, получая сообщения nonrefresh Path или Resv, содержащие объект Admin_Status, обновляют свое локальное состояние, выполняют какую-то локальную операцию в соответствии со статусом и затем передают полученный объект Admin_Status посредством исходящего сообщения Path или Resv. Если значения объекта Admin_Status, полученного в сообщении Resv, отличаются от значений, полученных в сообщении Path, тогда, с одним исключением, никаких локальных действий не должно быть предпринято, но значения должны быть переданы дальше. Единственная ситуация, когда с получ енными в Resv значениями следует осуществить некоторые локальные действия, — это случай получения R и D битов равными 1.

Краевые узлы, которые получают сообщение nonrefresh Path или Resv, содержащее объект Admin_Status, также обновляют свои состояния и выполняют соответствующие локальные операции с учетом текущего состояния. Когда поступил объект административного состояния с битом R =1, получивший краевой узел должен перенести полученные значения в соответствующее исходящее сообщение. В частности, если выходной узел получает сообщение Path с битом R Admin_Status =1, а узел ранее послал сообщение Resv, соответствующее сообщению Path, узел должен послать обновленное сообщение Resv, содержащее объект Admin_Status с тем же набором значений, за исключением бита R. Более того, выходной узел должен гарантировать, что последующие сообщения Resv, посланные узлом, содержат тот же самый объект административного состояния.

Кроме того, если входной узел получает сообщение Resv с установленным битом R в объекте Admin_Status, узел должен послать обновленное сообщение Path, содержащее объект Admin_Status со значениями, полученными в сообщении Resv, за исключением R -бита. Кроме того, входной узел должен также гарантировать, что последующие сообщения Path, посланные этим узлом, содержат объект административного статуса (Admin Status Object).

Процедура аннулирования

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

Входной узел предваряет ликвидацию LSP введением объекта административного статуса в сообщение Path и установкой битов R (Reflect) и D (Delete).

Транзитные и выходной узлы обрабатывают объект административного статуса, как это было описано выше.

По получении объекта административного статуса с битом D (Delete) =1 в сообщении Resv, входной узел посылает сообщение PathTear вниз по течению, чтобы ликвидировать LSP, при этом выполняется обычная обработка RSVP.

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

Выходной узел индицирует свое желание аннулирования путем введения объекта своего административного состояния в сообщение Resv и установки битов R (Reflect) и D (Delete).

Транзитные узлы обрабатывают объект административного состояния, как это описано выше.

После получения в сообщении Resv объекта Admin Status с битом D (Delete) =1, входной узел посылает сообщение PathTear вниз по течению, чтобы ликвидировать LSP.

Совместимость и процедуры обработки ошибок

Возможно, что некоторые узлы вдоль LSP не будут поддерживать объект административного статуса. В случае не поддерживающего транзитного узла объект будет передан через узел без модификации и обычная обработка продолжится. В случае не поддерживающего выходного узла объект административного состояния не будет передан назад в сообщении Resv. Чтобы поддержать вариант не поддерживающего выходного узла входной узел должен только ждать оговоренное время. Когда период ожидания истек, входной узел посылает сообщение PathTear. По умолчанию этот период должен равняться 30 секундам.

Процедуры сообщения уведомления

Промежуточный и оконечный узлы могут запустить процесс установления административного статуса посредством использования сообщений Notify. Чтобы выполнить это, промежуточный или оконечный узел генерирует сообщение уведомления (Notify) с соответствующей информацией сессии в направлении вверх по течению. Объект административного состояния должен включаться в данные сессии. Бит R (Reflect) не должен быть установлен. Сообщение Notify может быть, если требуется, инкапсулировано.

Входной узел, получив сообщение уведомления, содержащее объект административного состояния с битом D (Delete) =1, должен инициировать процедуру аннулирования, описанную в предыдущем разделе. Другие биты должны передаваться в исходящем сообщении Path обычным образом.

Совместимость и процедуры обработки ошибок

Для того, чтобы решить проблему в случае узлов, не поддерживающих объект административного состояния, необходима специальная обработка и другие условия формирования сигнала ошибки. В частности, узел, который посылает сообщение уведомления, содержащее объект административного состояния с битом D (Down) =1, должен проверять, получил ли он соответствующее сообщение Path с битом D (Down) =1 за определенный период, заданный при конфигурации. По умолчанию этот период должен равняться 30 секундам. Если узел не получает такого сообщения, он должен послать сообщение PathTear вниз по течению и сообщение ResvTear или PathErr с флагом Path_State_Removed =1 — вверх.

Отделение канала управления. Идентификация интерфейса

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

Объекты IF_ID RSVP_HOP

Формат объекта IPv4 IF_ID RSVP_HOP (рис. 12.68):

(рис 12.68)

Формат объекта IPv6 IF_ID RSVP_HOP (рис. 12.69):

(рис 12.69)

Описания адресов узлов и полей указателя смотри в [RFC-2205]. Описания параметров и кодирование TLV содержится в [RFC-3471].

Объект IF_ID RSVP_HOP используется вместо определенных выше объектов RSVP_HOP. Он применяется в соединениях, где нет однозначных ассоциаций между каналами управления и данных (смотри [RFC-3471]). Поля Hop Address (адрес шага) и указатель логического интерфейса используются в соответствии со стандартом RSVP [RFC-2205].

TLV применяются для идентификации каналов данных, ассоциированных с LSP. Для однонаправленных LSP должен быть указан нисходящий канал данных. Для двунаправленных LSP указывается общий нисходящий и восходящий информационный канал. В специальном случае, когда двунаправленный LSP проходит через многоканальное (объединенное) соединение, можно специфицировать нисходящий информационный канал, отличающийся от восходящего канала. Информационные каналы специфицируются с точки зрения отправителя сообщения Path. Объект IF_ID RSVP_HOP не должен использоваться, когда TLV не нужны.

Узел, получающий один или более TLV в сообщении Path, сохраняет их величины и возвращает в объектах HOP последующих сообщений Resv, посылаемых узлу, откуда пришли TLV.

Заметим, что узел, создающий объект IF_ID, должен гарантировать, что выбранный выходной интерфейс, как это определено в объекте IF_ID, согласуется с ERO. Узел, который получает объект IF_ID, должен проверить, является ли информация, содержащаяся в объекте, совместимой с данными, полученными в ERO, и, если это не так, должен послать отправителю сообщение PathErr с кодом ошибки "Routing Error" (ошибка маршрутизации) и значением ошибки "Bad Explicit Route Object" (плохой объект маршрута, заданного явно). Эта проверка не может быть выполнена, когда исходный субобъект ERO не является входным интерфейсом.

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

Существуют случаи, когда полезно указать интерфейс, ответственный за ошибку. Для решения этой проблемы определен объект IF_ID ERROR_SPEC.

Объекты IF_ID ERROR_SPEC

Формат объекта IPv4 IF_ID ERROR_SPEC имеет вид (рис. 12.70):

(рис 12.70)

Формат объекта IPv6 IF_ID ERROR_SPEC имеет вид (рис. 12.71):

(рис 12.71)

Описание адресов, флагов, кодов ошибок и значений поля ошибка можно найти в [RFC-2205]. Описание параметров и кодирования TLV имеется в [RFC-3471].

Узлы, желающие указать, какая ошибка относится к какому интерфейсу, должны использовать соответствующий объект IF_ID ERROR_SPEC в сообщениях PathErr или ResvErr. Объекты IF_ID ERROR_SPEC должны генерироваться и обрабатываться так же, как и другие объекты ERROR_SPEC, смотри [RFC-2205].

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

Обработка двух типов отказов в системе управления рассмотрены ниже. Первый связан с отказами узлов, и относится к случаю, когда узел теряет свое состояние управления (например, после повторного старта), но не теряет своего состояния переадресации данных. Второй связан с отказом в канале управления и относится к случаю, когда между узлами потеряно управляющее соединение. Обработка обоих отказов поддерживается объектом Restart_Cap, определенным ниже и требующим использования сообщений Hello. Заметим, что, объект Restart_Cap не должен посылаться, когда нет механизма разделения отказов каналов данных и управления.

Объект Restart_Cap

Объект Restart_Cap транспортируется в сообщении Hello. Объект Restart_Cap имеет формат (рис. 12.72):

(рис 12.72)

Время перезагрузки: 32 бита

Время перезагрузки (повторного старта) измеряется в миллисекундах. Оно должно быть установлено равным сумме времени, необходимого отправителю объекта для перезапуска его компонента RSVP-TE (до точки, где он может обмениваться сообщениями RSVP Hello со своими соседями) и коммуникационного канала, который используется для RSVP коммуникаций. Значение 0xffffffff указывает, что рестарт управляющей функции отправителя может произойти через неопределенное время и что работа его информационной части не нарушена отказом в системе управления.

Время восстановления: 32 бит

Период времени, в миллисекундах, спустя которое отправитель хотел бы заново синхронизовать с получателем состояния переадресации RSVP и MPLS после восстановления синхронизации Hello. Значение нуль указывает на то, что состояние переадресации MPLS не было сохранено при перезагрузке системы.

Обработка объекта Restart_Cap

Узлы, поддерживающие восстановление состояния, анонсируют эту способность, транспортируя объект Restart_Cap в сообщениях Hello. Такие узлы должны включать объекты Restart_Cap во все сообщения Hello. (Заметим, что это касается сообщений Hello, содержащих объекты ACK.) Когда узел получает сообщение Hello с объектом Restart_Cap, он должен записать значения полученных параметров.

Модификация обработки сообщения Hello для поддержки восстановления состояния

Когда узел определяет, что RSVP связь с соседом потеряна, а узел по прошлому опыту знает, что сосед поддерживает восстановление состояния, он должен подождать, по крайней мере, некоторое время, указанное в параметре Restart Time (время повторного запуска) соседа, прежде чем включать процедуры, сопряженные с потерей соединения. Узел может ждать разное время, в зависимости от местной политики или конфигурации.

Во время этого периода ожидания все сообщения Hello должны посылаться со значением Dst_Instance, равным нулю, а Src_Instance должен оставаться неизменным. Во время ожидания узел должен также сохранять состояние переадресации RSVP и MPLS для уже установленного LSP, который проходит между данным узлом и соседом. В известном смысле, с точки зрения сформированного LSP узел ведет себя так, как если бы он получал периодически от соседа сообщения обновления RSVP. Узел может сбросить состояния RSVP и переадресации для LSP, которые находятся в процессе установления, в случае тайм-аута их обновления. Обновление состояний Resv и Path на период ожидания должно быть подавлено.

Во время этого периода ожидания узел может проинформировать вышестоящие узлы о потере связи посредством сообщения PathErr и/или сообщения уведомления с указанием "Control Channel Degraded State" (канал управления не работает). Если такое уведомление послано, тогда по восстановлении канала управления узел должен информировать другие узлы о восстановлении посредством сообщений PathErr и/или уведомления Notify с индикацией "Control Channel Active State" (управляющий канал в активном состоянии).

Когда от соседа приходит новое сообщение Hello, узел должен определить, произошел ли отказ в канале управления или это выход из строя узла. Этот анализ основывается на полученном от соседа Src_Instance. Если значение отличается от полученного от соседа до отказа, тогда соседа следует считать рестартующим. В противном случае, отказ ограничен каналом управления. Процедуры обработки для каждого из случаев описаны ниже.

Отказы канала управления

В случае отказа канала управления узел должен обновить все состояния, которые являются общими с соседом. Следует применять совокупность процедур восстановления [RFC-2961] с флагом ACK_Desired =1 (если они поддерживаются).

Отказы узлов

Восстановление при отказе узла использует один новый объект и другие существующие протокольные сообщения и объекты.

Метка восстановления

Объект Recovery_Label задействуется в процессе восстановления узла после отказа. Формат объекта Recovery_Label идентичен формату обобщенной метки. Объект Recovery_Label использует номер класса 34 (в форме 0bbbbbbb ) и C-тип предлагаемой метки.

Процедуры для перезапускаемого узла

После того как узел перезапускает свои функции управления, узел, который поддерживает состояние восстановления, должен проверить, способен ли он сохранить свое состояние переадресации MPLS. Если никакого состояния переадресации не сохранено, тогда в сообщении Hello, посланном своим соседям, узел должен установить время восстановления равным 0.

Если состояние переадресации сохранено, тогда узел инициирует процесс восстановления. Период, в течение которого узел поддерживает процесс восстановления, называется периодом восстановления (Recovery Period). Полная длительность периода восстановления анонсируется восстанавливающимся узлом в параметре Recovery Time (время восстановления) объекта Restart_Cap. Время восстановления должно быть установлено равным длительности периода восстановления во всех сообщениях Hello, посланных за время периода восстановления. Состояние, которое не синхронизовано в период восстановления, должно быть удалено в конце этого периода.

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

Когда узел получает сообщение Path за время периода восстановления, узел сначала проверяет, имеется ли состояние RSVP, ассоциированное с сообщением. Если состояние найдено, тогда узел обрабатывает это сообщение согласно определенным ранее процедурам.

Если состояние RSVP не найдено и сообщение не содержит в себе объект Recovery_Label, узел рассматривает это как сигнал к установлению нового LSP и обрабатывает его согласно определенным ранее процедурам.

Если состояние RSVP не найдено, а сообщение несет в себе объект Recovery_Label, узел ищет в его маршрутной таблице MPLS (которая восстановлена при перезапуске) рекорд, чей входной интерфейс согласуется с сообщением Path и чья входная метка равна метке, содержащейся в объекте Recovery_Label.

Если запись таблицы переадресации MPLS не найдена, узел рассматривает это как сигнал к установлению нового LSP.

Если рекорд маршрутной таблицы MPLS найден, формируется состояние RSVP, рекорд связывается с LSP, ассоциированным с сообщением, а состояние переадресации обрабатывается как корректное и обновленное. Должна быть произведена также обработка обычного сообщения Path. При отправке соответствующего исходящего сообщения Path узел должен включить в него объект Suggested_Label со значением метки, согласованным с рекордом восстановленной таблицы маршрутизации. Выходной интерфейс должен выбираться также с учетом рекорда маршрутной таблицы. В особом случае, где перезапускаемый узел имеет также перезапускаемого нижерасположенного соседа, вместо объекта Suggested_Label следует использовать объект Recovery_Label.

Кроме того, для двунаправленных LSP узел извлекает метку из объекта UPSTREAM_LABEL, содержащегося в полученном сообщении Path, и просматривает таблицу маршрутизации MPLS на предмет поиска рекорда, чья выходная метка равна метке, содержащейся в объекте (в случае многоканальности связи это может также включать идентификацию соответствующего входного компонента соединения).

Если рекорд таблицы маршрутизации MPLS не найден, узел рассматривает это как сигнал к установлению нового LSP и обрабатывает его согласно определенным ранее процедурам.

Если рекорд таблицы маршрутизации MPLS найден, рекорд связывается с LSP, ассоциированным с сообщением Path, и рекорд рассматривается как ресинхронизированный. Кроме того, если узел не является окончанием LSP, посылаются соответствующие сообщения Path с входной меткой, которая содержится в объекте UPSTREAM_LABEL рекорда.

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

Процедуры для соседа перезапускаемого узла

Узел определяет (используя процедуры, определенные в [RFC-3209]), какую систему управления соседа следует перезапустить и сохранил ли сосед состояние переадресации при перезапуске. Заметим, что значение времени перезапуска 0xffffffff означает бесконечный временной интервал.

После детектирования рестарта соседа, который поддерживает восстановление состояния, узел должен обновить все состояния Path, используемые совместно с соседом. Исходящие сообщения Path должны включать объект Recovery_Label, содержащий значение метки, которое соответствует метке, полученной в последнем сообщении Resv. Все состояния Path должны быть обновлены в пределах примерно 1/2 от времени восстановления, объявленного рестартующим соседом. Если имеется несколько LSP, проходящих через рестартующий узел, соседний узел должен избегать посылки сообщений Path в пределах ограниченного временного интервала, чтобы не перегружать ЦПУ соседа. Вместо этого ему следует распределить сообщения в пределах 1/2 времени восстановления. После детектирования рестарта соседа, который поддерживает восстановление состояния, все состояния Resv, используемые совместно с рестартующим узлом, не должны обновляться до тех пор, пока не будет получено соответствующее сообщение Path. Это требует подавления обычной обра ботки Resv и обновлений на время восстановления, объявленного рестартующим соседом. Как только приходит соответствующее сообщение Path, должно быть послано сообщение Resv и разрешена обычная обработка состояния.

RSVP сконструирован так, чтобы работать с динамическими изменениями маршрута и с узлами, не поддерживающими RSVP. С этой целью сообщения Path, PathTear и ResvConf несут в себе адрес места назначения сессии в IP-заголовке. Узлы, которые не могут присваивать метки, не могут существовать в LSP. Другим отличием от традиционного RSVP является то, что временами сообщение RSVP может транспортироваться за пределами информационного канала LSP.

Страницы:

Обзор LDP

LDP-партнеры

Обмен сообщениями LDP

Существует четыре категории сообщений LDP.

Сообщения выявления (Discovery) используются для объявления и поддержания присутствия LSR в сети.

Сообщения сессий используются для установления, поддержки и завершения сессий между LDP-партнерами.

Сообщения уведомления (Notification) используются для предоставления рекомендаций и уведомления об ошибках.

Структура сообщения LDP

Обработка ошибок LDP

Расширяемость LDP и будущая совместимость

Работа LDP. FEC

Ниже определяются типы элементов FEC. Если потребуется, может быть добавлен новый FEC.

Адрес ЭВМ. Этот элемент является полным адресом ЭВМ.

Если пакет в точности соответствует одному LSP, пакет ассоциируется с этим LSP.

Целесообразно отметить несколько следствий этих правил.

Пространства меток, идентификаторы, сессии и транспорт. Пространства меток

Выражение "пространство меток" полезно для обсуждения присвоения и рассылки меток.

Идентификаторы LDP

<LSR Id> : <label space id>

напр., lsr 171:0, lsr19:2.

Сессии LDP

LDP транспорт

LDP-сессии между LSR, соединенными не напрямую

Выявление LDP (Discovery)

Базовый механизма выявления

Расширенный механизм выявления

Сессии LDP между несвязанными напрямую LSR поддерживаются расширенным механизмом выявления партнеров.

В отличие от базового выявления, которое является симметричным, расширенное — асимметрично.

Установление сессий LDP и управление ими. Установление сессии LDP

Обмен сообщениями выявления партнеров между двумя LSR запускает LDP-сессию. Сессия формируется в два этапа.

Установление транспортного соединения.

Инициализация сессии

Установление транспортного соединения

Аналогично, адрес A2 определяется так:

Процедура сравнения A1 и A2 осуществляется следующим образом:

если A1 и A2 принадлежат разным адресным семействам, они несравнимы, и сессия не может быть реализована;

Пусть U2 является абстрактным целым числом без знака, полученным от A2 аналогичным образом.

сравниваем U1 с U2. Если U1 > U2, тогда A1 > A2; если U1 < U2, тогда A1 < A2.

Инициализация сессии

Когда LSR1 играет пассивную роль:

если в ответ на сообщение инициализации LSR1 получает KeepAlive, сессия с точки зрения LSR1 является рабочей;

если LSR1 получает сообщение об ошибке, LSR2 отклоняет предложенную сессию и LSR1 закрывает TCP-соединение.

Когда LSR1 играет активную роль:

если LSR1 получает сообщение об ошибке, LSR2 отвергает предложенную сессию, а LSR1 закрывает TCP-соединение;

если LSR1 получает сообщение KeepAlive, LSR2 воспринял предложенные им параметры сессии;

Инициализация машины состояний

Переходы между состояниями при инициализации сессии
Состояние	Событие	новое состояние
NON EXISTENT	Сессия TCP-соединения установлена	INITIALIZED
INITIALIZED	Передача сообщения инициализации (Активная роль)	OPENSENT
	Получение приемлемого сообщения инициализации (Пассивная роль)	OPENREC
	Действие: Передача сообщения инициализации и KeepAlive
	Получение любого другого сообщения LDP	NON EXISTENT
	Действие: Передача сообщения об ошибке (NAK) и закрытие транспортного соединения
OPENREC	Получение сообщения KeepAlive	OPERATIONAL
	Получение любого другого сообщения LDP	NON EXISTENT
	Действие: Передача сообщения об ошибке (NAK) и закрытие транспортного соединения
OPENSENT	Получение приемлемого сообщения инициализации	OPENREC
	Действие: передача сообщения KeepAlive
	Получение любого другого сообщения LDP	NON EXISTENT
	Действие: передача сообщения об ошибке (NAK) и закрытие транспортного соединения
OPERATIONAL	Получение сообщения Shutdown	NON EXISTENT
	Действие: передача сообщения Shutdown и закрытие транспортного соединения
	Получение других сообщений LDP	OPERATIONAL
	Тайм-аут	NON EXISTENT
	Действие: передача сообщения завершения и закрытие транспортного соединения

Поддержка сопредельности Hello

LDP имеет механизмы выявления необходимости LDP-сессии и ее Hello-сопредельностей.

Поддержка сессий LDP

(рис 12.1) Диаграмма состояний при инициализации сессии

Рассылка меток и управление

Режим управления рассылкой меток

FEC относится к самому LSR (включая один из непосредственно связанных с ним интерфейсов);

маршрутизатор следующего шага для FEC находится за пределами сети с коммутацией по меткам;

Режим сохранения метки (Retention)

Режим анонсирования меток

Идентификаторы LDP и адреса следующего шага

Детектирование петель

Сообщение запроса метки

Сообщение запроса метки должно включать в себя TLV числа шагов.

Сообщение присвоения метки (Mapping)

R должен включать TLV числа шагов.

Если R является выходным, значение числа шагов должно быть равно 1.

Если R является выходным, сообщение выделения метки не обязано содержать TLV вектора пути.

если полученное сообщение содержит неизвестное число шагов, тогда R должен включить TLV вектора пути;

Аутентичность и целостность сообщений LDP

Использование LDP опции подписи TCP MD5

LDP использует опцию подписи TCP MD5 следующим образом.

Применение подписи MD5 для TCP-соединений является конфигурируемой опцией LSR.

Рассылка меток для LSP, маршрутизированных явно

Спецификация протокола

Обмены сообщениями LDP осуществляются путем посылки протокольных данных LDP (PDU) через LDP-секцию TCP-соединений.

LDP PDU

(рис 12.2)

Версия

Длина PDU

Двухоктетное целое число, специфицирующее общую длину PDU в октетах, исключая поля версии и длины PDU.

Идентификатор LDP

Процедуры LDP

LDP определяет сообщения, TLV и процедуры в следующих областях:

выявление партнера;

управление сессией;

рассылка меток;

уведомление об ошибках и справочная информация.

Кодирование TLV (тип-длина-значение)

(рис 12.3)

U бит

F бит

Тип

Определяет, как следует интерпретировать поле значение.

Длина

Специфицирует длину поля значение в октетах.

Значение

Кодирование TLV для универсальных параметров

FEC TLV

(рис 12.4)

Элементы FEC от 1 до n

Существует несколько типов элементов FEC. Кодирование элементов FEC зависит от типа элемента.

Значения элемента FEC кодируются следующим образом (таблица 12.2).

название элемента FeC	Тип	значение
Wildcard	0x01	Нет значения; т.e., 0 октетов значения; смотри ниже
Префикс	0x02	Смотри ниже
Адрес ЭВМ	0x03	Полный адрес ЭВМ; смотри ниже

Элемент Wildcard FEC

(рис 12.5)

Семейство адресов

PreLen

Префикс

Элемент FEC адреса ЭВМ имеет формат, описанный ниже на рис. 12.6:

(рис 12.6)

Семейство адресов

Длина адреса ЭВМ

Длина адреса ЭВМ в октетах.

Адрес ЭВМ

Адрес, закодированный согласно полю семейство адресов.

Процедуры FEC

TLV-метки

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

TLV типовой метки

(рис 12.7)

Метка

Это 20-битовый код метки, как это специфицировано в [RFC-3032]. Размещается в 4-октетном поле.

TLV меток ATM

LSR применяет TLV ATM метки для кодирования меток, используемых в каналах ATM (рис. 12.8).

(рис 12.8)

Res

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

V-биты

VPI

VCI

TLV для меток в Frame Relay

LSR использует TLV метки Frame Relay, чтобы закодировать метки для каналов Frame Relay (рис. 12.9).

(рис 12.9)

Res

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

Len

Это поле специфицирует число бит DLCI. Поддерживаются следующие значения:

0 = 10 бит DLCI

2 = 23 бит DLCI

Значения Len 1 и 3 зарезервированы.

DLCI

TLV списка адресов

TLV списка адресов встречаются в сообщениях адреса и отзыва адреса.

Семейство адресов

Адреса

Следующие представления адресов определены данной версией протокола.

Семейство адресов	Кодирование адресов
IPv4	4 октета полного IPv4-адреса
IPv6	16 октетов полного IPv6-адреса

TLV числа шагов

(рис 12.11)

Значение HC

1 октетное целое число без знака равное числу шагов.

Если это сообщение запроса метки, R должен инкрементировать полученное значение числа шагов.

Если это сообщение присвоения метки, R определяет число шагов следующим образом:

в противном случае, R должен инкрементировать полученное число шагов.

TLV вектора пути

Один или более LSR Id

LSR должен:

послать сообщение уведомления LSR-отправителю, сигнализируя обнаружение петли;

не передавать дальше сообщение запроса метки.

Заметим, что сообщение запроса метки с TLV вектора пути переадресуется до тех пор, пока:

не будет найдена петля;

не будет достигнут конец LSP;

Вектор пути в случае присвоения метки

не передавать сообщение дальше;

Заметим, что сообщение присвоения метки с TLV вектора расстояния переадресуется до тех пор, пока:

не будет обнаружена петля;

не будет достигнуто начало LSP, или

достигнут максимум вектора пути или числа шагов.

TLV статуса

(рис 12.13)

U бит

F бит

Должен быть тем же самым, что и в поле кода статуса.

Код статуса

32-битовое целое без знака, характеризующее событие. Структура кода статуса представлена ниже на рис. 12.14:

E бит

Бит фатальной ошибки. Если E=1, это уведомление о фатальной ошибке. Если Е=0, это сообщение-рекомендация.

F бит

Бит переадресации. Если (рис 12.14)

Статусные данные

30битовое целое число без знака, которое специфицирует статусную информацию.

ID сообщения

Тип сообщения

10.3.5. Сообщения LDP

Все сообщения LDP имеют следующий формат (рис. 12.15):

U бит

Тип сообщения

Идентифицирует тип сообщения

Длина сообщения

ID сообщения

(рис 12.15)

Обязательные параметры

Опционные параметры

Набор опционных параметров сообщения, имеющий переменную длину.

Имя сообщения	Заголовок секции
Уведомление	Сообщение уведомления
Hello	Сообщение `Hello`
Инициализация	Сообщение инициализации
KeepAlive	Сообщение `KeepAlive`
Адрес	Сообщение адреса
Отзыв адреса	Сообщение отзыва адреса
Присвоение метки	Сообщение присвоения метки
Запрос метки	Сообщение запроса метки
Запрос ликвидации метки	Сообщение запроса ликвидации метки
Отзыв метки	Сообщение отзыва метки
Освобождение метки	Сообщение освобождения метки

Сообщение уведомления

ID сообщения

(рис 12.16)

32-битовый код, используемый для идентификации этого сообщения.

TLV статуса

Индицирует сигнализируемое событие.

Опционные параметры

Опционный параметр	Тип	Длина	Значение
Расширенный статус	0x0301	4	Смотри ниже
Присланный PDU	0x0302	Переменная	Смотри ниже
Сообщение-отклик	0x0303	Переменная	Смотри ниже

Могут появиться и другие опционные параметры, специфичные для конкретного события.

Расширенный статус

Присылаемый PDU

Возвращаемое сообщение

Процедуры сообщения уведомления

Информирование о событиях с помощью сообщений уведомления

Некорректный PDU или сообщение

LDP-сообщение некорректно, если:

тип сообщения неизвестен.

Неизвестный или некорректный TLV

TLV, содержащееся в сообщении LDP, которое получено по TCP-соединению, имеет некорректный формат, если:

тип TLV не известен.

Если тип TLV < 0x8000 ( старший бит 0 ) — это ошибка, сигнализируемая кодом статуса Unknown TLV (неизвестный TLV).

Если тип TLV >= 0x8000 ( старший бит 1 ) — TLV молча игнорируется;

Истечение времени таймера KeepAlive сессии

Это фатальная ошибка, сигнализируемая кодом статуса KeepAlive Timer Expired (таймер KeepAlive истек).

Одностороннее прерывание сессии

События сообщения инициализации

События, вызванные другими сообщениями

Внутренние ошибки

Сообщение Hello

(рис 12.17)

ID сообщения

32-битовый код, используемый для идентификации этого сообщения.

Общие параметры TLV Hello

(рис 12.18)

Время удержания (Hold Time).

T, целевое Hello

R, Посылка целевых Hello по запросу

Зарезервировано

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

Опционные параметры (рис. 12.17)

Транспортный адрес IPv4

опционный параметр	Тип	Длина	значение
Транспортный адрес IPv4	0x0401	4	Смотри ниже
Последовательный номер конфигурации	0x0402	4	Смотри ниже
Транспортный адрес IPv6	0x0403	16	Смотри ниже

Последовательный номер конфигурации

Транспортный адрес IPv6

Процедуры сообщения Hello

если Hello неприемлемо, LSR его игнорирует;

если Hello несет в себе какой-либо опционный TLV, LSR обрабатывает его;

Ниже представлены критерии приемлемости для сообщений канального и целевого Hello:

LSR был сконфигурирован для приема целевых Hello, или

LSR был сконфигурирован посылать целевые Hello по адресу A.

Далее описано, как LSR обрабатывает опционные TLV Hello.

Транспортный адрес

LSR ассоциирует специфицированные транспортные адреса с сопредельностью Hello.

Порядковый номер конфигурации

Сообщение инициализации

(рис 12.19)

ID сообщения

32-битовый код, используемый для идентификации этого сообщения.

TLV общих параметров сессии

Кодирование TLV общих параметров сессии рассмотрено ниже (рис. 12.20):

(рис 12.20)

Версия протокола

Двухоктетное целое число без знака, содержащее номер версии протокола.

Время KeepAlive

A, порядок анонсирования меток

Индицирует тип анонсирования меток. A=0 означает анонсирование Downstream Unsolicited; значение = 1 означает Downstream On Demand.

Когда один LSR предлагает Downstream Unsolicited, а другой предлагает Downstream on Demand, правила разрешения конфликта таковы:

в противном случае применяется режим Downstream Unsolicited.

D, детектирование петель

PVLim, ограничение вектора пути

Резерв

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

Макс. длина PDU

Идентификатор LDP получателя

Опционные параметры

опционный параметр	Тип	Длина	значение
Параметры сессии ATM	0x0501	переменная	Смотри ниже
Параметры сессии Frame Relay	0x0502	переменная	Смотри ниже

Параметры сессии ATM

(рис 12.21)

M, возможности объединения в ATM

величина	назначение
0	Объединение не поддерживается
1	Поддерживается объединение VP
2	Поддерживается объединение VC
3	Поддерживается объединение VP VC

Если объединяющие свойства LSR различны, то:

не объединяющие и VC-объединяющие LSR могут легко работать совместно;

N, число компонент диапазона меток

Определяет число компонент диапазона меток ATM, включенных в TLV.

D, использование VC по направлениям

Зарезервировано

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

Один или более компонентов диапазона меток ATM

Res

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

Минимум VPI (12 бит)

Минимум VCI (16 бит)

Максимум VPI(12 бит)

Максимум VCI (16 бит)

Сообщение KeepAlive

(рис 12.23)

ID сообщения

32-битовое значение, используемое для идентификации этого сообщения.

Опционные параметры

Для сообщения KeepAlive не определено опционных параметров.

Процедуры сообщения KeepAlive

Сообщение Address

ID сообщения

(рис 12.24)

32-битовый код идентифицирующий это сообщение.

TLV списка адресов

Список адресов интерфейсов, анонсированных LSR-отправителем.

Опционные параметры

Для сообщения адреса опционные параметры не предусмотрены.

Процедуры сообщений Address

Сообщение отзыва адреса (Address Withdraw)

(рис 12.25)

ID сообщения

32-битовый код, используемый для идентификации этого сообщения.

TLV списка адресов

Список адресов интерфейсов, подлежащих отзыву, для LSR-отправителя.

Опционные параметры

Для сообщения адреса опционные параметры пока не предусмотрены.

Сообщение присвоения метки (Label Mapping)

(рис 12.26)

ID сообщения

32-битовый код, используемый для идентификации этого сообщения.

FEC TLV

Специфицирует FEC-компонент анонсируемого ансамбля FEC-метка.

TLV метки

Специфицирует компонент Label ассоциации FEC-метка.

Опционные параметры

опционный параметр	Длина	значение
TLV ID сообщения запроса метки	4	Смотри ниже
TLV числа шагов	1	Смотри ниже
TLV вектора пути	переменная	Смотри ниже

ID сообщения запроса метки

Число шагов

Специфицирует полное число LSR-шагов вдоль LSP, установленное сообщением Label.

Вектор пути

Сообщает LSR список узлов LSP, сформированный сообщением Label.

LSR распознает новый FEC с помощью маршрутной таблицы, и используется режим анонсирования меток Downstream Unsolicited.

LSR получает сообщение запроса от вышестоящего партнера для FEC, присутствующего в маршрутной таблице LSR .

Следующий шаг для FEC изменился, и активизировано детектирование петель.

Атрибуты соответствия изменились.

Получен отклик на присвоение метки от узла следующего шага вниз по течению и:

не было установления соответствия со стороны выше по течению, или

сконфигурировано детектирование петель, или

атрибуты соответствия изменились.

LSR распознает новый FEC из маршрутной таблицы, и он является выходным для этого FEC.

Следующий шаг для FEC изменился и активизировано детектирование петель.

Атрибуты соответствия изменились.

Получен отклик на присвоение метки от узла следующего шага ниже по течению и:

не сформировано никакого соответствия узлом выше по течению, или

сконфигурировано детектирование петель, или

атрибуты соответствия изменились.

Анонсирование меток вниз по течению по запросу (Downstream on Demand)

Анонсирование меток Downstream Unsolicited

Сообщение запроса метки

(рис 12.27)

ID сообщения

32-битный код используется, чтобы идентифицировать это сообщение.

FEC TLV

FEC, для которого запрашивается метка.

Опционные параметры

Число шагов

Специфицирует полное число LSR-шагов вдоль LSP, определяется в результате запроса метки.

Вектор пути

Специфицирует узлы вдоль LSP. Этот список сформирован посредством сообщения запроса метки.

опционный параметр	Длина	значение
TLV числа шагов	1	Смотри ниже
TLV вектора пути	переменная	Смотри ниже

Процедуры сообщения запроса метки

Следующий шаг для FEC изменился, и LSR в сложившихся условиях не имеет метки для данного FEC.

Нет маршрута

FEC, для которого запрошена метка, включает элемент, для которого LSR не имеет маршрута.

Нет ресурсов меток

Детектирование петель

LSR детектировал зацикливание сообщения запроса метки.

Сообщение запроса аннулирования метки

(рис 12.28)

ID сообщения

32-битный код применяется, чтобы идентифицировать это сообщение.

TLV FEC

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

TLV сообщения запроса метки

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

Опционные параметры

Для сообщения Label Abort Req опционные параметры не предусмотрены.

Процедуры сообщения запроса ликвидации метки (Label Abort)

следующий шаг Ru для FEC изменился с LSR Rd на LSR X; или

сообщения уведомления о выполнении ликвидации запроса метки, являющегося подтверждением ликвидации;

сообщения присвоения метки в качестве отклика на аннулированное сообщение запроса;

Сообщение отзыва метки

(рис 12.29)

ID сообщения

32-битовый код, используемый для идентификации этого сообщения.

TLV FEC

Идентифицирует FEC, для которого отзывается ассоциация FEC-метка.

Опционные параметры

опционный параметр	Длина	значение
TLV метки	переменная	Смотри ниже

Метка

Если присутствует, специфицирует отзываемую метку.

Процедуры сообщения отзыва метки (Label Withdraw)

LSR посылает сообщение отзыва метки в следующих случаях:

LSR не распознает более известный ранее FEC, для которого была анонсирована метка;

LSR, который получает сообщение отзыва метки, должен откликнуться сообщением освобождения метки.

Сообщение освобождения метки (Label Release)

ID сообщения

32-битовый код, используемый для идентификации этого сообщения.(рис 12.30)

TLV FEC

Идентифицирует FEC, для которого была освобождена ассоциация FEC-метка.

Опционные параметры

опционный параметр	Длина	значение
TLV метки	переменная	Смотри ниже

Метка

В случае присутствия означает, что метка освобождена.

Процедуры сообщения освобождения метки (Label Release)

LSR получает сообщение отзыва метки.

Сообщения и TLV для расширяемости

Частные расширения LDP производителя

Частные сообщения и TLV производителя используются для обмена между LSR частной информацией производителя.

Частные TLV LDP производителя

(рис 12.31)

U бит

F бит

Тип

Длина

Специфицирует суммарную длину в октетах идентификатора производителя и поля данных.

Id производителя

ID производителя 802, как это предписано IEEE.

Данные

Частные сообщения LDP производителя

Код типа в диапазоне 0x3E00 - 0x3EFF зарезервирован для частных сообщений производителя (рис. 12.32).

(рис 12.32)

U бит

Тип сообщения

Длина сообщения

ID сообщения

ID производителя

ID производителя 802, как это предписано IEEE.

Остальные обязательные параметры

Набор переменной длины остальных обязательных параметров.

Опционные параметры

Набор переменной длины опционных параметров сообщения.

Экспериментальные расширения LDP

диапазон кодов тип 0x3F00 0x3FFF зарезервирован для экспериментальных TLV;

диапазон кодов тип сообщения 0x3F00 - 0x3FFF зарезервирован для экспериментальных сообщений;

Перечень сообщений

Следующие сообщения LDP определены в данной версии протокола (таблице 12.10).

Имя сообщения	Тип	заголовок раздела
Notification	0x0001	Сообщение уведомления
Hello	0x0100	Сообщение Hello
Initialization	0x0200	Сообщение инициализации
KeepAlive	0x0201	Сообщение KeepAlive
Address	0x0300	Сообщение Address
Address Withdraw	0x0301	Сообщение отзыва адреса
Label Mapping	0x0400	Сообщение присвоения метки
Label Request	0x0401	Сообщение запроса метки
Label Withdraw	0x0402	Сообщение отзыва метки
Label Release	0x0403	Сообщение освобождения метки
Label Abort Request	0x0404	Сообщение запроса ликвидации метки
Vendor-Private	0x3E00-0x3EFF	Частные расширения LDP произ¬водителя
Experimental	0x3F00-0x3FFF	Экспериментальные расширения LDP

Сводка TLV

Следующие TLV определены в этой версии протокола (таблица 12.11).

Сводка кодов статуса

UDP-порт для LDP-сообщения Hello имеет номер 646. TCP-порт для установления LDP-сессии также имеет номер 646.

TLV	Тип	заголовок раздела
FEC	0x0100	TLV FEC
Address List	0x0101	TLV списка адресов
Hop Count	0x0103	TLV числа шагов
Path Vector	0x0104	TLV вектора пути
Generic Label	0x0200	TLV общей метки
ATM Label	0x0201	TLV метки ATM
Frame Relay Label	0x0202	TLV метки Frame Relay
Status	0x0300	TLV статуса
Extended Status	0x0301	Сообщение уведомления
Returned PDU	0x0302	Сообщение уведомления
Returned Message	0x0303	Сообщение уведомления
Common Hello	0x0400	Параметры сообщения Hello
IPv4 Transport Address	0x0401	Сообщение Hello
Configuration	0x0402	Порядковый номер сообщения Hello
IPv6 Transport Address	0x0403	Сообщение Hello
Common Session	0x0500	Параметры сообщения инициализации
ATM Session Parameters	0x0501	Сообщение инициализации
Frame Relay Session	0x0502	Параметры сообщения инициализации
Label Request	0x0600	ID сообщения присвоения метки
Vendor-Private	0x3E00-0x3EFF	Частные расширения LDP производителя
Experimental	x3F00-0x3FFF	Экспериментальные расширения LDP

Неявная метка NULL

код статуса	E	Статусные данные	заголовок раздела
Успех	0	0x00000000	TLV статуса
Плохой идентификатор LDP	1	0x00000001	Events Signaled by ... (События, сигнализизируемые ...)
Плохая версия протокола	1	0x00000002	Events Signaled by ... (События, сигнализизируемые ...)
Неверная длина PDU	1	0x00000003	Events Signaled by ... (События, сигнализизируемые ...)
Неизвестный тип сообщения	0	0x00000004	Events Signaled by ... (События, сигнализизируемые ...)
Неверная длина сообщения	1	0x00000005	Events Signaled by ...
Неизвестное TLV	0	0x00000006	Events Signaled by ...
Неверная длина TLV	1	0x00000007	Events Signaled by ...
Неверный формат значения TLV	1	0x00000008	Events Signaled by ...
Истекло время удержания	1	0x00000009	Events Signaled by ...
Shutdown	1	0x0000000A	Events Signaled by ...
Обнаружена петля	0	0x0000000B	Обнаружение петли
Неизвестный FEC	0	0x0000000C	Процедуры FEC
Нет маршрута	0	0x0000000D	Label Request Mess ... (Со¬общение запроса метки)
Нет ресурсов для метки	0	0x0000000E	Label Request Mess ...
Ресурсы для метки/доступны	0	0x0000000F	Label Request Mess ...
Session Rejected/No Hello	1	0x00000010	Инициализация сессии
Session Rejected/Parameters Advertisement Mode	1	0x00000011	Инициализация сессии
Session Rejected/Parameters Max PDU Length	1	0x00000012	Инициализация сессии
Session Rejected/Parameters Label Range	1	0x00000013	Инициализация сессии
Истекло время таймера KeepAlive	1	0x00000014	Events Signaled by ...
Запрос метки аннулирован	0	0x00000015	Label Request Abort ... (Ликвидация запроса метки)
Отсутствуют параметры сообщения	0	0x00000016	Events Signaled by ...
Не поддерживаемое семейство адресов	0	0x00000017	Процедуры FEC Address Message Proc ...
Session Rejected/Bad KeepAlive Time	1	0x00000018	Инициализация сессии
Внутренняя ошибка	1	0x00000019	Events Signaled by ...

Типы TLV в диапазоне 0x0000 - 0x3DFF являются частью базового протокола LDP и выделяются в результате консенсуса IETF.

12.1. RSVP-TE: расширение RSVP для LSP-туннелей

Введение

Предпосылки

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

Абстрактный узел

LSP, маршрутизируемый явно

LSP, чей маршрут сформирован с помощью обычной IP-маршрутизации

Маршрут с коммутацией по меткам

LSP

Маршрут с коммутацией по меткам (Label Switched Path)

LSP-туннель

Туннель управления трафиком (TE Tunnel)

Набор из одного или более LSP-туннелей, которые транспортируют трафик

Транк для трафика

Обзор. LSP туннели и туннели управления трафиком (TE)

Работа LSP-туннелей

возможность формирования LSP-туннелей с требованиями QoS или без них;

возможность динамически изменять маршруты сформированных LSP-туннелей;

возможность отслеживать действительный маршрут, проходящий через сформированный LSP-туннель;

возможность идентифицировать и диагностировать LSP-туннели;

возможность устанавливать сформированный LSP-туннель под административный контроль; и

возможность осуществлять посылку запросов выделения меток, их рассылку и объединение.

Реализации должны поддерживать услугу контролируемой нагрузки (ControlledLoad service) [4] и нулевую услугу (Null Service) [16].

Стили резервирования

Стиль FF (фиксированный фильтр)

Стиль WF (Wildcard Filter)

Кроме того, из-за правил объединения WF, объекты EXPLICIT_ROUTE не могут использоваться для резервирования WF.

Стиль SE (Shared Explicit)

Туннели управления переадресацией трафика

MTU пути

Используя терминологию, определенную в [12.5], LSR должен выполнить следующий алгоритм.

Пусть M меньше чем максимальный исходный размер помеченной IP дейтограммы или (MTU пути — N ).

дейтограмма должна быть фрагментирована, размер каждого фрагмента должен быть не больше чем M, и

каждый фрагмент должен быть помечен и затем переадресован.

Если в IPv4-заголовке установлен бит DF, тогда

дейтограмма не должна переадресовываться;

формируется сообщение ICMP о недостижимости адресата:

его поле Code устанавливается [12] равным "Fragmentation Required and DF Set",

поле MTU следующего шага устанавливается[13] равным M.

Если возможно, посылается отправителю ICMP сообщение о недостижимости адресата для отброшенной дейтограммы.

Когда размер дейтограммы IPv6 (без меток) превышает значение M,

дейтограмма не должна переадресоваться;

формируется ICMP-пакет сообщение слишком велико со значением MTU следующего шага [14], равным M ;

Форматы сообщений, связанные с LSP туннелями

Пять новых объектов определено в данном разделе:

Имя объекта	Применимые RSVP-сообщения
`LABEL_REQUEST`	`Path`
`LABEL`	`Resv`
`EXPLICIT_ROUTE`	`Path`
`RECORD_ROUTE`	`Path, Resv`
`SESSION_ATTRIBUTE`	`Path`

Новые C-типы присваиваются также объектам SESSION, SENDER_TEMPLATE и FILTER_SPEC.

Сообщение Path

Сообщение Path имеет следующий формат:

<Сообщение Path> ::=  <Common Header> [ <INTEGRITY> ]
              <SESSION> <RSVP_HOP>
              <TIME_VALUES>
              [ <EXPLICIT_ROUTE> ]
              <LABEL_REQUEST>
              [ <SESSION_ATTRIBUTE> ]
              [ <POLICY_DATA> ... ]
              <sender descriptor>

<дескриптор         <SENDER_TEMPLATE> <SENDER_TSPEC>
отправителя> ::=   
              [ <ADSPEC> ]
              [ <RECORD_ROUTE> ]

Сообщение Resv

Сообщение Resv имеет следующий формат:

<Сообщение Resv> ::=   <Common Header> [ <INTEGRITY> ]
              <SESSION> <RSVP_HOP>
              <TIME_VALUES>
              [ <RESV_CONFIRM> ] [ <SCOPE> ]
              [ <POLICY_DATA> ... ]
              <STYLE> <flow descriptor list>
<список дескрипторов потока>::=  <FF flow descriptor list>
                    | <SE flow descriptor>
<список дескрипторов потока FF>::=  <FLOWSPEC> <FILTER_SPEC>
                      <LABEL> [ <RECORD_ROUTE> ]
                      | <FF flow descriptor list>
                      <FF flow descriptor>
<дескриптор потока FF>::=  [ <FLOWSPEC> ] 
                <FILTER_SPEC> <LABEL>
                [ <RECORD_ROUTE> ]
<дескриптор потока SE>::=  <FLOWSPEC> <SE filter spec list>
                <SE filter spec list> ::= <SE filter spec>
                | <SE filter spec list> <SE filter spec>
<спецификация фильтра SE>::=  <FILTER_SPEC> <LABEL> 
                  [ <RECORD_ROUTE> ]

Объекты, связанные с LSP-туннелем. Объект Label

Класс LABEL = 16, C_Type = 1

Обработка объектов Label в сообщениях Resv

Внизу по течению

Вверху по течению

Несколько условий могут сделать метку неприемлемой.

Присвоенная метка находится вне запрошенного диапазона меток.

Отсутствие поддержки объекта Label

Объект запроса метки

Запрос метки без указания диапазона

Класс = 19, C_Type = 1

(рис 12.33)

Зарезервировано	Это поле зарезервировано. Оно должно равняться нулю при передаче и игнорироваться при получении
L3PID	Идентификатор протокола слоя 3, используемого в этом проходе. Используются стандартные значения для `Ethertype`.

Запрос метки с диапазоном ATM

Класс = 19, C_Type = 2

Резерв	Это поле зарезервировано. Оно должно равняться нулю при передаче и игнорироваться при получении
L3PID	Идентификатор протокола слоя 3, используемого в этом проходе. Используются стандартные значения для `Ethertype`
M	Установка этого бита равным 1 указывает, что узел может объединять потоки
Минимум VPI (12 бит)	Это 12-битное поле специфицирует нижнюю границу блока идентификаторов виртуального пути, которая поддерживается исходным коммутатором. Если VPI меньше 12-бит, оно должно быть выровнено по правому полю, а предшествующие биты должны равняться нулю
Минимум VCI (16 бит)	Это 16-битное поле специфицирует нижнюю границу блока идентификаторов виртуального пути, которая поддерживается исходным коммутатором. Если VCI меньше 16 бит, оно должно быть выровнено по правому полю, а предшествующие биты должны равняться нулю
Максимум VPI (12 бит)	Это 12-битное поле специфицирует верхнюю границу блока идентификаторов виртуального пути, которая поддерживается исходным коммутатором. Если VPI меньше 12 бит оно должно быть выровнено по правому полю
Максимум VCI (16 бит)	Это 16-битное поле специфицирует верхнюю границу блока идентификаторов виртуального пути, которая поддерживается исходным коммутатором. Если VCI меньше 16 бит, оно должно быть выровнено по правому полю

Запрос метки с диапазоном Frame Relay

Класс = 19, C_Type = 3

(рис 12.35)

Резерв	Это поле зарезервировано. Оно должно равняться нулю при передаче и игнорироваться при получении
L3PID	Идентификатор протокола слоя 3, используемого в этом проходе. Используются стандартные значения для `Ethertype`.
DLI	Индикатор длины DLCI. Число бит в DLCI. Поддерживаются следующие значения: Len DLCI [бит] 0 10 2 23
Минимум DLCI	Это 23-битное поле специфицирует нижнюю границу блока идентификаторов виртуальных каналов (DLCI), которая поддерживается исходным коммутатором. DLCI должно быть выровнено по правому полю, а неиспользуемые биты должны ровняться нулю
Максимум DLCI	Это 23-битное поле специфицирует верхнюю границу блока идентификаторов виртуальных каналов (DLCI), которая поддерживается исходным коммутатором. DLCI должно быть выровнено по правому полю

Обработка LABEL_REQUEST

Отсутствие поддержки объекта запроса метки

Объект Explicit Route

Класс = 20, C_Type = 1

Применимость

Семантика объекта Explicit Route

Субобъекты

(рис 12.36)

`L`	Бит `L` является атрибутом субобъекта. Если бит `L=1`, то субобъект является свободным шагом в явном маршруте. Если бит `L=0`, субобъект является жестким шагом в явном маршруте.
Тип	Поле тип определяет тип содержимого субобъекта. В настоящее время определены следующие значения: 1 IPv4 префикс 2 IPv6 префикс 32 номер автономной системы
Длина	Поле длина содержит полную длину субобъекта в байтах, включая поля `L`, тип и длина. Значение поля длина должно быть кратно 4 и не менее 4

Строгие и свободные субобъекты

(рис 12.37)

`L`	Бит `L` является атрибутом субобъекта. Если бит `L=1`, то субобъект является свободным шагом в явном маршруте. Если `L=0`, субобъект является жестким шагом в явном маршруте
Тип	0x01 IPv4 адрес
Длина	Поле длина содержит полную длину субобъекта в байтах, включая поля тип и длина. Значение поля всегда `=8`
IPv4 адрес	IPv4 адрес. Этот адрес рассматривается как префикс, базирующийся на значении длины префикса. Биты за пределами префикса игнорируются при приеме и должны равняться нулю при передаче
Длина префикса	Длина префикса IPv4 в битах
Заполнитель	Нуль при передаче. Игнорируется при приеме

Субобъект 1. IPv4 префикс

(рис 12.38)

`L`	Бит `L` является атрибутом субобъекта. `L-бит =1`, если субобъект представляет собой свободный шаг в явном маршруте. Если `L =0`, субобъект представляет собой строгий шаг в явном маршруте
Тип	0x02 IPv6 адрес
Длина	Поле длина содержит полную длину субобъекта в байтах, включая поля тип и длина. Значение поля длина всегда =20
IPv6 адрес	Адрес IPv6. Этот адрес обрабатывается как префикс на основе величины длины префикса. Биты за пределами префикса игнорируются при приеме и должны равняться нулю при передаче
Длина префикса	Длина префикса IPv6 в битах
Заполнитель	Нуль при передаче. Игнорируется при приеме

Субобъект 2. IPv6 префикс

Субобъект 32: Номер автономной системы

Обработка объекта Explicit Route. Выбор следующего шага

Добавление субобъектов в объект Explicit Route

Петли

Прямая совместимость

Отсутствие поддержки объекта Explicit Route

Объект Record Route

Класс = 21, C_Type = 1

Субобъекты

Пустой RRO (без субобъектов) считается некорректным. В настоящее время определено три типа субобъектов.

(рис 12.39)

Тип	0x01 IPv4 адрес
Длина	Поле длина содержит полную длину субобъекта в байтах, включая поля тип и длина. Значение поля всегда `=8`
IPv4 адрес	32-битный уникастный, адрес ЭВМ. Здесь может быть указан любой достижимый сетевой интерфейс. Недопустимыми адресами могут считаться, например, адреса loopback, они не должны использоваться
Длина префикса	32
Флаги	0x01 имеется локальная защита. Указывает, что канал вниз по течению от этого узла защищен с помощью некоторого локального механизма восстановления. Этот флаг может `=1`, если только установлен флаг локальной защиты в объекте `SESSION_ATTRIBUTE` соответствующего сообщения Path. 0x02 используется локальная защита Указывает, что в данном туннеле используется локальный механизм восстановления

Субобъект 1. адрес IPv4

(рис 12.40)

Тип	0x02 IPv6 адрес
Длина	Поле длина содержит полную длину субобъекта в байтах, включая поля тип и длина. Значение поля всегда `=20`
IPv6 адрес	128-битовый уникастный адрес ЭВМ
Длина префикса	128
Флаги	0x01 доступна локальная защита. Указывает, что канал вниз по течению от этого узла защищен с помощью некоторого локального механизма восстановления. Этот флаг может `=1`, если только установлен флаг локальной защиты в объекте `SESSION_ATTRIBUTE` соответствующего сообщения Path. 0x02 используется локальная защита. Указывает, что в данном туннеле используется локальный механизм восстановления

Субобъект 2. IPv6 адрес

(рис 12.41)

Тип	0x03 Label (метка)
Длина	Поле длина содержит полную длину субобъекта в байтах, включая поля тип и длина.
Флаги	`0x01 = Глобальная метка`. Этот флаг указывает на то, что метка будет воспринята корректно любым интерфейсом
C-тип	C-тип включенного объекта Label. Копируется из объекта Label
Содержимое объекта Label	Содержимое объекта Label. Копируется из объекта Label

Субобъект 3. Метка. Применимость

Обработка RRO

Обнаружение циклических маршрутов

Прямая совместимость

Отсутствие поддержки RRO

Коды ошибок для ERO и RRO

Значение  Ошибка
1      Bad EXPLICIT_ROUTE object (плохой объект EXPLICIT_ROUTE)
2      Bad strict node (плохой жесткий узел)
3      Bad loose node (плохой свободный узел)
4      Bad initial subobject (плохой исходный субобъект)
5      No route available toward destination (нет пути до адресата)
6      Unacceptable label value (неприемлемое значение метки)
7      RRO indicated routing loops (RRO указывает на наличие петли)
8      MPLS being negotiated, but a nonRSVPcapable router stands 
             in the path (согласовывался MPLS, но на пути 
               стоит маршрутизатор без поддержки RSVP)
9      MPLS label allocation failure (ошибка присвоения MPLSметки)
10      Unsupported L3PID (не поддерживаемый L3PID)

Для кода ошибки Notify, 16 бит значения поля ошибки имеет вид:

ss00 cccc cccc cccc

Старшие биты определены при коде ошибки 1 [1]. Когда ss = 00, определены следующие субкоды:

1   RRO для MTU слишком велико 
2   RRO-уведомление
3   туннель локально восстановлен

Объекты сессии, шаблона отправителя и спецификации фильтра

Новые C-типы определены для объектов SESSION, SENDER_TEMPLATE и FILTER_SPEC. Объекты LSP_TUNNEL имеют следующий формат:

Объект Session

Объект сессии LSP_TUNNEL_IPv4

Класс = SESSION, LSP_TUNNEL_IPv4 C-тип = 7

Объект сессии LSP_TUNNEL_IPv6

(рис 12.42)

IPv4 адрес конца туннеля	IPv4 адрес оконечного узла туннеля
ID туннеля	16-битный идентификатор, используемый в сессии и сохраняемый на протяжении жизни туннеля
Расширенный ID туннеля	32-битный идентификатор, используемый в сессии и сохраняемый на протяжении жизни туннеля. Обычно устанавливается равным нулю. Входные узлы, которые хотят сузить область сессии до пары вход-выход, могут поместить сюда свой IPv4 адрес в качестве глобально уникального идентификатора

Класс = SESSION, LSP_TUNNEL_IPv6 C_тип = 8

Объект отправителя Template (шаблон)

(рис 12.43)

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

Объект шаблона отправителя LSP_TUNNEL_IPv4

Класс = SENDER_TEMPLATE, LSP_TUNNEL_IPv4 Cтип = 7

(рис 12.44)

IPv4-адрес отправителя для туннеля	IPv4 адрес узла отправителя
LSP ID	16-битовый идентификатор, используемый в `SENDER_TEMPLATE` и `FILTER_SPEC`, который может быть изменен, чтобы позволить отправителю совместное использование ресурсов

Объект шаблона отправителя LSP_TUNNEL_IPv6

Класс = SENDER_TEMPLATE, LSP_TUNNEL_IPv6 C_тип = 8

Объект спецификации фильтра

(рис 12.45)

IPv6 адрес отправителя туннеля	IPv6 адрес узла отправителя
LSP ID	16-битовый идентификатор, используемый в SENDER_TEMPLATE и FILTER_SPEC, который может быть изменен, чтобы позволить отправителю совместное использование ресурсов

Объект спецификации фильтра LSP_TUNNEL_IPv4

Класс = FILTER SPECIFICATION, LSP_TUNNEL_IPv4 C-тип = 7

Формат объекта LSP_TUNNEL_IPv4 FILTER_SPEC идентичен формату LSP_TUNNEL_IPv4 SENDER_TEMPLATE.

Объект спецификации фильтра LSP_TUNNEL_IPv6

Класс = FILTER SPECIFICATION, LSP_TUNNEL_IPv6 C_тип = 8

Формат объекта LSP_TUNNEL_IPv6 FILTER_SPEC идентичен формату LSP_TUNNEL_IPv6 SENDER_TEMPLATE.

Процедура изменения маршрута и увеличения полосы

<FLOWSPEC><old_FILTER_SPEC><old_LABEL_OBJECT><new_FILTER_SPEC>
<new_LABEL_OBJECT>

11.4.7. Объект атрибута сессии

Формат без привязки ресурсов

Класс SESSION_ATTRIBUTE = 207, LSP_TUNNEL C-тип = 7

(рис 12.46)

Приоритет Setup	Приоритет сессии с учетом используемых ресурсов, в диапазоне от 0 до 7. Значение нуль имеет высший приоритет. Приоритет Setup используется при решении того, может ли сессия идти вне очереди по отношению к другой сессии
Приоритет	Приоритет сессии по отношению к удерживаемым ресурсам, в диапазоне от 0 до 7. Значение нуль имеет высший приоритет. Приоритет владения используется при решении, может ли сессия идти вне очереди по отношению к другой сессии
Флаги	0x01. Желательна локальная защита. Этот флаг позволяет промежуточным маршрутизаторам использовать механизм локального восстановления, который может привести к порче объекта явный маршрут. Когда обнаружена ошибка в смежном канале вниз по течению или узле, промежуточный маршрутизатор может изменить путь трафика для быстрой службы восстановления. 0x02 нужна запись метки Этот флаг указывает, что при записи маршрута следует включить информацию о метке. 0x04 нужен стиль SE Этот флаг указывает, что входной узел туннеля может решить изменить маршрут без его ликвидации. Выходной узел туннеля должен использовать стиль SE, при реагировании на сообщение Resv
Длина имени	Длина отображаемой строки в байтах до заполнителя.
Имя сессии	Строка символов, дополненная нулем

Формат без привязки ресурса

Класс SESSION_ATTRIBUTE = 207, LSP_TUNNEL_RA C-тип = 1

(рис 12.47)

Исключить любой	32-битный вектор, представляет собой набор атрибутов фильтров, сопряженных с туннелем, каждый из которых может объявлять канал неприемлемым
Включить любой	32-битный вектор, представляет собой набор атрибутов фильтров, сопряженных с туннелем, каждый из которых может объявить канал приемлемым (с точки зрения данного теста). Нулевой набор (все биты равны нулю) автоматически проходит
Включить все	32-битный вектор, представляет собой набор атрибутов фильтров, сопряженных с туннелем, каждый из которых должен присутствовать, чтобы канал был приемлем (с точки зрения данного теста). Нулевой набор (все биты равны нулю) автоматически проходит
Приоритет Setup	Приоритет сессии с точки зрения захвата ресурсов в диапазоне от 0 до 7. Значение нуль имеет высший приоритет. Приоритет Setup используется при решении, может ли сессия идти вне очереди по отношению к другой сессии
Приоритет удержания	Приоритет сессии с точки зрения удержания ресурсов в диапазоне от 0 до 7. Значение нуль имеет высший приоритет. Приоритет удержания используется при решении, может ли сессия быть замещена другой сессией
Флаги	0x01 Желательна локальная защита. Этот флаг позволяет промежуточным маршрутизаторам использовать механизм локального восстановления, который может вызвать нарушение объекта явного маршрута. Когда детектирована ошибка в смежном канале вниз по течению или узле, транзитный маршрутизатор может переадресовать трафик для службы быстрого восстановления 0x02 Требуется запись меток. Этот флаг указывает, что при записи маршрута информация о метке должна быть включена. 0x04 Желателен стиль SE. Этот флаг индицирует то, что входной узел туннеля может решить изменить маршрут этого туннеля без его удаления. Узел конца туннеля, реагируя на сообщение Resv, должен использовать стиль SE
Длина имени	Длина отображаемой строки до заполнителя в байтах
Имя сессии	Строка символов дополненная нулем

Процедуры, применимые к обоим C-типам

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

Приоритетное прерывание обслуживания	Приоритет атрибута сессии
0 - 3	7
4 - 15	6
16 - 63	5
64 - 255	4
256 - 1023	3
1024 - 4095	2
4096 - 16383	1
16384 - 65535	0

Процедуры привязки ресурсов

Чтобы точно описать тесты, используем определения объектов, представленные выше. Определяется также

Linkattr 32-битовый вектор, представляющий собой атрибуты, ассоциированные с каналом

Осуществляются три проверки.

Исключает любой

Расширение Hello

Формат сообщения Hello

Сообщение Hello имеет тип Msg равный 20. Формат сообщения Hello показан ниже.

<Hello Message> ::=  <Common Header> [ <INTEGRITY> ]
              <HELLO>

Форматы объекта HELLO

Код класса HELLO = 22. Определено два C_типа.

Объект HELLO REQUEST

Класс = HELLO, C_тип = 1

Объект содержит атрибут отправителя (32 бита) и атрибут получателя (32 бита).

Объект HELLO ACK

Класс = HELLO, C_тип = 2

Использование сообщения Hello

Соображения по поводу многоканальности

12.2. Обобщенная мультипротокольная коммутация по меткам (GMPLS)

Введение

распознавать границы пакетов или ячеек, и

Подобные LSR или, точнее, интерфейсы LSR могут быть отнесены к следующим классам.

Обзор

Форматы, относящиеся к меткам

Обобщенные запросы меток

Информация, транспортируемая в обобщенном запросе метки, имеет формат, показанный на рис. 12.48:

Тип кодирования LSP: 8 бит

значение	Тип
1	Пакет
2	Ethernet
3	ANSI/ETSI PDH
4	Зарезервировано
5	SDH ITU-T G.707 / SONET ANSI T1.105
6	Зарезервировано
7	Цифровой конверт
8	Lambda (оптическое)
10	Зарезервировано
11	Fiber Channel

Тип коммутации: 8 бит

значение	Тип
1	Packet-Switch Capable-1 (PSC-1)
2	Packet-Switch Capable-2 (PSC-2)
3	Packet-Switch Capable-3 (PSC-3)
4	Packet-Switch Capable-4 (PSC-4)
51	Layer-2 Switch Capable (L2SC)
100	Time-Division-Multiplex Capable (TDM)
150	Lambda-Switch Capable (LSC)
200	Fiber-Switch Capable (FSC)

Обобщенный PID (G-PID): 16 бит

(рис 12.48)

значение	Тип	Технология
0	Не определено	Все
1	Зарезервировано
2	Зарезервировано
3	Зарезервировано
4	Зарезервировано
5	Asynchronous mapping of E4	SDH
6	Asynchronous mapping of DS3/T3	SDH
7	Asynchronous mapping of E3	SDH
8	Bit synchronous mapping of E3	SDH
9	Byte synchronous mapping of E3	SDH
10	Asynchronous mapping of DS2/T2	SDH
11	Bit synchronous mapping of DS2/T2	SDH
12	Зарезервировано
13	Asynchronous mapping of E1	SDH
14	Byte synchronous mapping of E1	SDH
15	Byte synchronous mapping of 31 * DS0	SDH
16	Asynchronous mapping of DS1/T1	SDH
17	Bit synchronous mapping of DS1/T1	SDH
18	Byte synchronous mapping of DS1/T1	SDH
19	VC-11 в VC-12	SDH
20	Зарезервировано
21	Зарезервировано
22	DS1 SF Asynchronous	SONET
23	DS1 ESF Asynchronous	SONET
24	DS3 M23 Asynchronous	SONET
25	DS3 C-Bit Parity Asynchronous	SONET
26	VT/LOVC	SDH
27	STS SPE/HOVC	SDH
28	POS — No Scrambling, 16 bit CRC	SDH
29	POS — No Scrambling, 32 bit CRC	SDH
30	POS — Scrambling, 16 bit CRC	SDH
31	POS — Scrambling, 32 bit CRC	SDH
32	ATM mapping	SDH
33	Ethernet	SDH, $$\lambda$$, волокно
34	SONET/SDH	$$\lambda$$, волокно
35	Зарезервировано	$$\lambda$$, волокно
36	Цифровой конверт	$$\lambda$$, волокно
37	Lambda	Fiber
38	ANSI/ETSI PDH	SDH
39	Зарезервировано	SDH
40	Протокол доступа к каналу SDH LAPS –(X.85 и X.86)	SDH
41	FDDI	SDH, $$\lambda$$, волокно
42	DQDB (ETSI ETS 300 216)	FiberChannel
43	FiberChannel-3 (услуги)	FiberChannel+
44	HDLC	SDH
45	Ethernet V2/DIX (only)	SDH, $$\lambda$$, волокно
46	Ethernet 802.3 (only)	SDH, $$\lambda$$, волокно

Кодирование полосы пропускания

Тип сигнала	Скорость обмена	значение (байт/сек) (Ieee плавающий формат)
DS0	0.064 Mbps (Мбит/с)	0x45FA0000
DS1	1.544 Mbps	0x483C7A00
E1	2.048 Mbps	0x487A0000
DS2	6.312 Mbps	0x4940A080
E2	8.448 Mbps	0x4980E800
Ethernet	10.00 Mbps	0x49989680
E3	34.368 Mbps	0x4A831A80
DS3	44.736 Mbps	0x4AAAA780
STS-1	51.84 Mbps	0x4AC5C100
Fast Ethernet	100.00 Mbps	0x4B3EBC20
E4	139.264 Mbps	0x4B84D000
FC-0 133M		0x4B7DAD68
OC-3 FC-0/STM-1	155.52 Mbps	0x4B9450C0
FC-0 266M		0x4BFDAD68
FC-0 531M		0x4C7D3356
OC-12/STM-4	622.08 Mbps	0x4C9450C0
GigE	1000.00 Mbps	0x4CEE6B28
FC-0 1062M		0x4CFD3356
OC-48/STM-16	2488.32 Mbps	0x4D9450C0
OC-192/STM-64	9953.28 Mbps	0x4E9450C0
10GigE-LAN	10000.00 Mbps	0x4E9502F9
OC-768/STM-256	39813.12 Mbps	0x4F9450C0

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

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

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

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

Метка:32 бит

Прочие метки

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

(рис 12.49)

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

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

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

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

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

Набор меток

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

(рис 12.50)

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

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

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

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

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

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

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

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

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

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

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

Субканал:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(рис 12.54)

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

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

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

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

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

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

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

(рис 12.55)

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

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

Длина: 16 бит

Тип:16 бит

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

Тип	Длина	Формат	описание
1	8	IPv4 Addr.	IPv4
2	20	IPv6 Addr.	IPv6
3	12	см. ниже	IF_INDEX (индекс интерфейса)
4	12	см. ниже	COMPONENT_IF_DOWNSTREAM (состав¬ной интерфейс)
5	12	см. ниже	COMPONENT_IF_UPSTREAM (составной интерфейс)

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

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

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

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

(рис 12.56)

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

(рис 12.57)

12.3. Расширения протокола управления резервированием (RSVP-TE) при обобщенной многопротокольной коммутации по меткам (GMPLS)

Введение

Форматы, относящиеся к меткам. Объект запроса обобщенной метки

(рис 12.58)

Описание параметров смотри в [RFC-3471].

Кодирование полосы

Объект обобщенной метки

Ниже представлен формат объекта обобщенной метки (рис. 12.59):

(рис 12.59)

Описание параметров и кодирования меток смотри выше и в [RFC-3471].

Объект коммутируемого интервала длин волн

В контексте коммутации частотных диапазонов обобщенная метка имеет следующий формат (рис. 12.60).

(рис 12.60)

Описание параметров смотри в [RFC-3471].

Объект предлагаемой метки

Объект набора меток

(рис 12.61)

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

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

Процедуры

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

Уведомление

Объект набора приемлемых меток

Объекты запросов уведомления

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

(рис 12.62)

Объект запроса уведомления IPv4

Адрес узла уведомления IPv4: 32 бита

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

Объект запроса уведомления IPv6 (рис. 12.63)

Адрес узла уведомления IPv6: 16 байт

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

(рис 12.63)

Заметим, что включение объекта запроса Notify не гарантирует того, что сообщение Notify будет сформировано.

Сообщение уведомления

После получения сообщения уведомления узел должен послать соответствующие сообщение Ack.

Удаление состояния с помощью сообщения PathErr

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

Субобъект ERO метки

Субобъект ERO метки определен следующим образом (рис. 12.64):

(рис 12.64)

Описание L, U и параметров метки смотри в [RFC-3471].

Тип = 3 (метка)

Длина

Поле длина содержит общую длину субобъекта в байтах, включая поля тип и длина. Длина должна быть кратной 4.

C-тип

C-тип включенного объекта метка. Копируется из объекта метка.

для субобъекта метки, следующего за субобъектом с установленным битом L;

при установке однонаправленного LSP, если должен быть субобъект метки с установленным битом U ;

если имеются два субобъекта метки с идентичными значениями бита U.

Субобъект RRO метки

Субобъект RRO метки имеет следующий формат (рис. 12.65):

(рис 12.65)

Описания параметров U и метки смотри в [RFC-3471].

Тип 3 (метка)

Длина. Описание смотри в [RFC-3209].

Флаги. Описание смотри в [RFC-3209].

C-тип. C-тип включенного объекта метки. Копируется из объекта метки.

Объект защиты

(рис 12.66)

Процедуры

Административная информация состояний

Объект административного статуса

(рис 12.67)

Описания параметров смотри выше и в [RFC-3471].

Процедуры для сообщений Path и Resv

Процедура аннулирования

Транзитные и выходной узлы обрабатывают объект административного статуса, как это было описано выше.

Транзитные узлы обрабатывают объект административного состояния, как это описано выше.

Совместимость и процедуры обработки ошибок

Процедуры сообщения уведомления

Совместимость и процедуры обработки ошибок

Отделение канала управления. Идентификация интерфейса

Объекты IF_ID RSVP_HOP

Формат объекта IPv4 IF_ID RSVP_HOP (рис. 12.68):

(рис 12.68)

Формат объекта IPv6 IF_ID RSVP_HOP (рис. 12.69):

(рис 12.69)

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

Объекты IF_ID ERROR_SPEC

Формат объекта IPv4 IF_ID ERROR_SPEC имеет вид (рис. 12.70):

(рис 12.70)

Формат объекта IPv6 IF_ID ERROR_SPEC имеет вид (рис. 12.71):

(рис 12.71)

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

Объект Restart_Cap

Объект Restart_Cap транспортируется в сообщении Hello. Объект Restart_Cap имеет формат (рис. 12.72):

(рис 12.72)

Время перезагрузки: 32 бита

Время восстановления: 32 бит

Обработка объекта Restart_Cap

Модификация обработки сообщения Hello для поддержки восстановления состояния

Отказы канала управления

Отказы узлов

Метка восстановления

Процедуры для перезапускаемого узла

Если запись таблицы переадресации MPLS не найдена, узел рассматривает это как сигнал к установлению нового LSP.

Процедуры для соседа перезапускаемого узла

Занятие пройдено

Предыдущее занятие Занятие пройдено Следующее занятие

Вернуться к учебному плану