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


           

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


Рис. 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.



Содержание  Назад  Вперед