Многоцелевое расширение почты Интернет

         

Объект запроса метки


Класс запроса метки равен 19. В настоящее время существует три возможных значения C_Types. Тип 1 относится к запросам метки без диапазона значений. Тип 2 является запросом метки с диапазоном ATM. Тип 3 является запросом метки с диапазоном Frame Relay. Объект LABEL_REQUEST имеет форматы показанные ниже.

4.2.1. Запрос метки без указания диапазона

Класс = 19, C_Type = 1

Рис. 1

ЗарезервированоЭто поле зарезервировано. Оно должно равняться нулю при передаче и игнорироваться при полученииL3PIDИдентификатор протокола слоя 3, используемого в этом проходе. Используются стандартные значения для Ethertype.

4.2.2. Запрос метки с диапазоном ATM

Класс = 19, C_Type = 2

Рис. 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-бит, оно должно быть выровнено по правому полю, а предшествующие биты должны равняться нулю.


4.2.3. Запрос метки с диапазоном Frame Relay

Класс = 19, C_Type = 3



Рис. 3.
Резерв Это поле зарезервировано. Оно должно равняться нулю при передаче и игнорироваться при полученииL3PIDИдентификатор протокола слоя 3, используемого в этом проходе. Используются стандартные значения для Ethertype.DLIИндикатор длины DLCI. Число бит в DLCI. Поддерживаются следующие значения:

Len бит в DLCI

0 10

2 23Минимум DLCIЭто 23-битное поле специфицирует нижнюю границу блока идентификаторов виртуальных каналов (DLCI), которая поддерживается исходным коммутатором. DLCI должно быть выровнено по правому полю, а неиспользуемые биты должны ровняться нулюMaximum DLCIЭто 23-битное поле специфицирует верхнюю границу блока идентификаторов виртуальных каналов (DLCI), которая поддерживается исходным коммутатором. DLCI должно быть выровнено по правому полю, а неиспользуемые биты должны ровняться нулю

4.2.4. Обработка 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.



4.2.5. Отсутствие поддержки объекта запроса метки

Маршрутизатор 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 non-RSVP capable router stands in the path" (оговорен протокол MPLS, но на пути стоит маршрутизатор без поддержки RSVP). То же самое сообщение следует послать, если маршрутизатор получает объект LABEL_REQUEST в сообщении от маршрутизатора без поддержки RSVP. О том, как маршрутизатор внизу по течению может обнаружить маршрутизатор без поддержки RSVP, смотри в [1].


Содержание раздела