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

         

Субобъект Метка


Рис. 9.

Тип0x03 Label (метка)ДлинаПоле длина содержит полную длину субобъекта в байтах, включая поля тип и длина.Флаги0x01 = Глобальная метка

Этот флаг указывает на то, что метка будет воспринята корректно любым интерфейсом C-типC-тип включенного объекта Label. Копируется из объекта Label Содержимое объекта LabelСодержимое объекта Label. Копируется из объекта Label

4.4.2. Применимость

Здесь определено использование только уникастных сессий. Существует три возможных применения RRO в RSVP. Первое, RRO может функционировать как механизм детектирования петель для выявления кольцевых маршрутов на уровне L3, или петель, сопряженных с явным маршрутом.

Второе, RRO собирает текущую маршрутную информацию шаг-за-шагом о сессиях RSVP, предоставляя ценные данные отправителю или получателю. При этом будут сообщаться любые изменения маршрута (в связи с изменением топологии сети).

Третье, синтаксис RRO сконструирован так, чтобы можно было с минимальными изменениями использовать весь объект в качестве входных данных для объекта EXPLICIT_ROUTE. Это полезно, если отправитель получает RRO от получателя в сообщении Resv, применяет его к объекту EXPLICIT_ROUTE в следующем сообщении Path, для того чтобы определить маршрут сессии.

4.4.3. Обработка RRO

Обычно, узел запускает сессию RSVP путем добавления RRO в сообщение Path. Исходное RRO содержит только один субобъект - IP-адреса отправителей. Если узел хочет также записывать метки, он устанавливает флаг Label_Recording в атрибуте SESSION_ATTRIBUTE.

Когда промежуточный маршрутизатор получает сообщение Path, содержащее RRO, он запоминает копию его блока состояния маршрута. RRO затем используется в следующем обновлении Path для форматирования сообщений 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.


4.4.4. Обнаружение циклических маршрутов

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

Сессия RSVP лишена циклов, если узлы ниже по течению получают сообщения Path или вышестоящие узлы получают сообщения Resv без маршрутных петель, обнаруженных в RRO.

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

Для сообщений Path, содержащих петли переадресации, маршрутизатор формирует и посылает PathErr сообщение "Routing problem", со значение ошибки "loop detected" (обнаружена петля), после чего выбрасывает сообщение Path. Пока петля не ликвидирована, эта сессия не пригодна для переадресации информационных пакетов.

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

4.4.5. Прямая совместимость

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

4.4.6. Отсутствие поддержки RRO

Объект RRO должен использоваться, только когда все маршрутизаторы вдоль пути поддерживают RSVP и объект RRO. Объекту RRO преписывается значение класса в форме 0bbbbbbb. Маршрутизаторы RSVP, которые не поддерживают объект будут откликаться сообщением об ошибке "Unknown Object Class" (неизвестный объект).


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