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

Петли

Так как объект 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.

Субобъект 1. адрес IPv4

Рис. 12.40.

Субобъект 2. IPv6 адрес

Рис. 12.41.

Субобъект 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.

Класс = SESSION, LSP_TUNNEL_IPv6 C_тип = 8

Объект отправителя Template (шаблон)

Рис. 12.43.

Объект шаблона отправителя LSP_TUNNEL_IPv4

Класс = SENDER_TEMPLATE, LSP_TUNNEL_IPv4 Cтип = 7

Рис. 12.44.

Объект шаблона отправителя LSP_TUNNEL_IPv6

Класс = SENDER_TEMPLATE, LSP_TUNNEL_IPv6 C_тип = 8

Объект спецификации фильтра

Рис. 12.45.

Объект спецификации фильтра 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.

Формат без привязки ресурса

Класс SESSION_ATTRIBUTE = 207, LSP_TUNNEL_RA C-тип = 1

Рис. 12.47.

Процедуры, применимые к обоим C-типам

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

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

Приоритет Setup является приоритетом получения ресурсов. Приоритет удержания является приоритетом удержания ресурса.

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

Приоритеты setup и удержания являются прямыми аналогами приоритетного прерывания обслуживания и защитного приоритета, как это определено в [9]. В то время как взаимодействие этих двух объектов является, в конце концов, вопросом политики, следующие взаимодействия рекомендуются по умолчанию.

Когда присутствуют оба объекта, используется элемент приоритетного прерывания обслуживания. Соответствие между этими приоритетами определено следующим образом. Атрибут приоритета сессии S соответствует приоритету прерывания обслуживания P согласно формуле P = 2^(14-2S). Таблица соответствия приоритетов представлена ниже.

Когда рассматривается новое сообщение 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. Поле длина имени содержит длину этой строки.