Network Working Group D. Katz
Request for Comments: 2113 cisco Systems
Category: Standards Track February 1997
Опция IP Router Alert
IP Router Alert Option
Статус документа
Этот документ содержит проект стандартного протокола для сообщества Internet и служит запросом для обсуждения в целях развития протокола. Информацию о текущем состоянии стандартизации протокола можно найти в документе InternetOfficialProtocolStandards (STD 1). Документ может распространяться свободно.
Аннотация
В этом документе описан новый тип опции IP, используемой для оповещения промежуточных маршрутизаторов о необходимости более тщательной проверки содержимого пакета IP. Это может быть полезно для новых протоколов, которым нужна промежуточная обработка пакетов на пути доставки к адресату. Возможны и иные применения опции.
1.0 Введение
Тенденции развития протоколов маршрутизации добавляют новые функции к традиционной индивидуальной (unicast) маршрутизации. Мотивы таких расширений просты — это позволяет расширить функциональность без изменения базовых функций протоколов маршрутизации, что существенно снижает уровень сложности разработки и реализации.
Недостатком такого подхода является то, что новая функциональность может опираться только на базовую для unicast-маршрутизации парадигму пересылки на следующий интервал (next hop) в направлении адресата. Невозможно принять какие-либо допущения о наличии более детальной информации (например, данных о состоянии каналов).
Желательно обеспечить возможность поэтапного внедрения новых технологий без возникновения необходимости обновления всех маршрутизаторов на пути между отправителем и получателем. Эта задача вступает в противоречие с текущей системой маршрутизации (только следующий интервал), поскольку маршрутизатор, не являющийся непосредственным соседом другого маршрутизатора, поддерживающего новый протокол, просто не имеет возможности определить местоположение других подобных маршрутизаторов (за исключением использования алгоритмов лавинной рассылки, которые не согласуются с требованиями простоты решения).
Обычным решением с использованием unicast-маршрутизации является поэтапная (hop-by-hop) пересылка пакетов нового протокола вдоль пути к конечному получателю. Каждая система, поддерживающая новый протокол, будет принимать ответственность за выбор на пути следующей системы, способной этот протокол понять. Однако, как было отмечено выше, получить информацию о реализации протокола в следующей системе трудно. Простым, вырожденным случаем является предположение о том, что все системы на пути поддерживают нужный протокол. Однако это будет служить препятствием для поэтапного развертывания протокола.
RSVP [1] решает эту проблему, указывая адрес конечного получателя в поле IP Destination Address и запрашивая у каждого маршрутизатора RSVP на пути доставки «внести незначительные изменения в … путь его пересылки», чтобы был определен конкретный тип пакета RSVP и все такие пакеты пересылались бы по отличному от основного пути с их локальной обработкой до дальнейшей пересылки. Это обеспечивает явное преимущество за счет обеспечения возможности туннелирования через маршрутизаторы, не понимающие RSVP, поскольку пакеты пойдут естественным путем в направлении конечного получателя. Однако потеря производительности, связанная с внесением изменений в путь пересылки может оказаться недопустимой, поскольку основной путь пересылки может быть очень точно «настроен» и даже добавление одной команды может снизить производительность на сотни пакетов в секунду.
2.0 Опция Router Alert
Целью является создание механизма, с помощью которого маршрутизаторы смогли бы изменять пакеты, не адресованные им непосредственно, без существенного снижения производительности. В этом документе определена новая опция IP (Router Alert) для решения такой задачи.
Смысл опции Router Alert заключается в том, что она говорит «маршрутизаторам следует более внимательно взглянуть на этот пакет». За счет включения опции Router Alert в заголовок IP своих сообщений протокол RSVP может заставить перехватывать сообщения без существенного снижения производительности пересылки обычных пакетов данных.
Маршрутизаторы, поддерживающие обработку опции на быстром пути, уже демультиплексируют пакеты на базе поля типа опции. Если на быстром пути все маршрутизаторы поддерживают все типы опций, добавление опции другого типа не должно повлиять на производительность. Если на быстром пути некоторые типы опций не поддерживаются, этот новый тип не будет распознан и вызовет перебрасывание пакетов с такой опцией на медленный путь, поэтому не возникает необходимости изменения быстрого пути и не происходит снижения производительности обработки для обычных пакетов данных.
Маршрутизаторы на быстром пути, которые не поддерживают обработку опции, будут пересылать пакеты по медленному пути, поэтому не возникает необходимости изменения быстрого пути и не теряется произвдительность обработки обычных пакетов данных.
2.1 Синтаксис
Формат (TLV) опции Router Alert показан на рисунке.
+--------+--------+--------+--------+
|10010100|00000100| 2 октета |
+--------+--------+--------+--------+
Type
Флаг копирования: 1 (опция должна включаться во все фрагменты).
Класс опции: 0 (управление)
Номер опции: 20 (десятичное значение)
Length=4
Value
Двухоктетный код, который может принимать значения:
0 — маршрутизатору следует проверить пакет;
1-65535 — резерв.
2.2 Семантика
Хостам следует игнорировать эту опцию. Маршрутизаторы, не понимающие этой опции, должны игнорировать ее. Маршрутизаторам, которые поддерживают данную опцию, следует более внимательно проверять пакет (например, поле IP Protocol), в заголовке которого имеется данная опция, для определения необходимости дополнительной обработки. Нераспознанные значения полей следует отбрасывать без уведомления.
Семантика других значения поля Value требует дополнительного изучения.
3.0 Влияние на другие протоколы
Для обеспечения эффективности этой опции ее использование должно стать обязательным в протоколах, которые ожидают от промежуточных маршрутизаторов существенной обработки пакетов, не адресованных данному маршрутизатору. В настоящее время к таким протоколам относятся RSVP [1] и IGMP [2].
4.0 Вопросы безопасности
Если опция Router Alert не установлена там, где ей следует быть, поведение протоколов, использующих оповещение маршрутизаторов (таких, как RSVP и IGMPv2), может быть изменено, поскольку работа таких протоколов основана на использовании опции Router Alert.
Если опция Router Alert установлена там, где ее не следует устанавливать, очевидно, что для потока будет снижаться производительность, поскольку пакеты с опцией Router Alert не будут направляться по быстрому пути, а маршрутизаторы будут тратить дополнительное время на обработку, связанную с присутствием данной опции.
5.0 Литература
[1] Braden, B. (ed.), L. Zhang, D. Estrin, S. Herzog, S. Jamin, “Resource ReSerVation Protocol (RSVP),” work in progress1, March 1996.
[2] Fenner, W., “Internet Group Management Protocol, Version 2 (IGMPv2),” work in progress2, October 1996.
Адрес автора
Dave Katz
cisco Systems
170 W. Tasman Dr.
San Jose, CA 95134-1706 USA
Phone: +1 408 526 8284
Email: dkatz@cisco.com
Перевод на русский язык
Николай Малых
