Опубликован: 28.09.2007 | Уровень: специалист | Доступ: платный
Лекция 12:

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

< Лекция 11 || Лекция 12: 123456789101112
Петли

Так как объект 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. Поле длина имени содержит длину этой строки.

< Лекция 11 || Лекция 12: 123456789101112
Наталья Шульга
Наталья Шульга

Курс "информационная безопасность" .

Можно ли на него записаться на ПЕРЕПОДГОТОВКУ по данному курсу? Выдается ли диплом в бумажном варианте и высылается ли он по почте?

Мария Архипова
Мария Архипова
алексей оглы
алексей оглы
Россия
рафич Салахиев
рафич Салахиев
Россия