Рабочая группа по сетям K. Kompella
Запрос комментариев: 3936 Juniper Networks
Обновляет: 3209, 2205 J. Lang
BCP: 96 Rincon Networks
Категория: Лучшая современная практика Октябрь 2004
Процедуры изменения Resource reSerVation Protocol (RSVP)
Статус настоящего документа
Настоящий документ определяет Лучшую современную практику Интернета для
интернет-сообщества и запрашивает обсуждение и предложения по
улучшениям. Распространение настоящего документа не ограничено.
Уведомление об авторских правах
Copyright (C) The Internet Society (2004).
Аннотация
Настоящий документ определяет процедуры изменения Resource reSerVation
Protocol (RSVP). Настоящий документ также устанавливает новые правила
назначения для пространств номеров сообщений RSVP, классов объектов,
типов классов и подобъектов.
1. Введение
Настоящий документ определяет процедуры изменения Resource reSerVation
Protocol (RSVP) [RSVP], включая (но не ограничиваясь) добавление,
обновление, расширение или отмену актуальности: сообщений, форматов и
процедур сообщений, классов объектов и типов классов, форматов и
процедур объектов; форматов заголовков, кодов и подкодов ошибок и их
семантики, а также процедур отправки, приёма и адресации сообщений RSVP.
IANA признаёт следующие пространства имён RSVP: типы сообщений, имена
классов, номера классов, типы классов и подобъекты, виртуальные порты
назначения, а также коды ошибок и значения (подкодов) (все они далее в
настоящем документе совместно именуются сущностями RSVP). Настоящий
документ определяет диапазоны для каждого пространства имён и политики
назначения для каждого диапазона. Новые пространства имён RSVP должны
быть определены в RFC категории Standards Track, включающем правила для
назначений IANA в новых пространствах имён.
Используемые в настоящем документе политики назначения: Standards Action
(как определено в [IANA]), Expert Review и Organization/Vendor Private
(проще — «Vendor Private»); последние две определены в настоящем
документе. Цель этих политик назначения состоит в том, чтобы обеспечить
надлежащую проверку расширений RSVP до назначения кодовых точек, не
будучи при этом чрезмерно жёсткими. Таким образом, если расширение
широко принято и его последствия хорошо понятны, оно может получить
назначение из пространства Standards Action; однако если расширение
носит экспериментальный характер, оно получает назначение из
пространства Expert Review и по мере зрелости может перейти в Standards
Track. Назначения из пространства Vendor Private не проверяются, однако
предусмотрены механизмы, обеспечивающие возможность сосуществования
этих кодовых точек в сети без вреда.
Орган по стандартизации, отличный от IETF, который желает получить
назначение для сущности RSVP, должен решить, из какого типа пространства
имён/номеров он желает получить своё назначение, а затем представить
соответствующую документацию. Например, если назначение должно быть
произведено из пространства номеров, обозначенного как Standards Action,
в поддержку запроса на назначение ДОЛЖЕН (MUST) быть представлен RFC
категории Standards Track.
Настоящий документ обновляет раздел «Соображения IANA» (раздел 7)
документа [RSVP-TE], заменяя изложенные там политики назначения.
Соглашения, используемые в настоящем документе
Ключевые слова «ДОЛЖЕН (MUST)», «НЕ ДОЛЖЕН (MUST NOT)», «ОБЯЗАТЕЛЬНО
(REQUIRED)», «ДОЛЖЕН (SHALL)», «НЕ ДОЛЖЕН (SHALL NOT)», «СЛЕДУЕТ
(SHOULD)», «НЕ СЛЕДУЕТ (SHOULD NOT)», «РЕКОМЕНДУЕТСЯ (RECOMMENDED)»,
«МОЖЕТ (MAY)» и «НЕОБЯЗАТЕЛЬНО (OPTIONAL)» в настоящем документе
должны интерпретироваться так, как описано в BCP 14, RFC 2119
[KEYWORDS].
2. Политики назначения для сущностей RSVP
Для каждого из пространств имён RSVP, определённых IANA, пространство
разделено на диапазоны назначения; для описания процедур, посредством
которых IANA назначает значения, используются следующие термины:
«Standards Action» (как определено в [IANA]), «Expert Review» и
«Organization/Vendor Private», определённый ниже.
Диапазоны «Expert Review» относятся к значениям, которые подлежат
рассмотрению экспертом, назначенным IESG. Кодовые точки из этих
диапазонов обычно используются для экспериментальных расширений; такие
назначения ДОЛЖНЫ (MUST) запрашиваться RFC категории Experimental,
документирующими их использование и обработку, а фактические назначения
производятся в ходе действий IANA для этого документа. Значения из
диапазонов «Expert Review» ДОЛЖНЫ (MUST) быть зарегистрированы в IANA.
Диапазоны «Organization/Vendor Private» относятся к значениям,
специфичным для предприятия; они НЕ ДОЛЖНЫ (MUST NOT) регистрироваться
в IANA. Для значений Vendor Private первое 4-октетное слово поля данных
ДОЛЖНО (MUST) быть кодом предприятия [ENT], зарегистрированным в SMI
Network Management Private Enterprise Codes IANA, а оставшаяся после
этого часть данных предназначена для частного использования
зарегистрированного предприятия. (Для каждой сущности RSVP, имеющей
диапазон Vendor Private, должно быть указано, где именно начинается поле
данных; примеры приведены ниже.) Таким образом разные предприятия,
поставщики или организации разработки стандартов (SDO) могут
использовать одну и ту же кодовую точку без опасения коллизии.
2.1. Типы сообщений
Тип сообщения — это 8-битное число, идентифицирующее функцию сообщения
RSVP. Значения от 0 до 239 назначаются посредством Standards Action.
Значения от 240 до 255 назначаются посредством Expert Review.
2.2. Имена и номера классов
Каждый класс объектов данных в сообщении RSVP идентифицируется именем
класса, полностью записанным прописными буквами, и 8-битным номером
класса (также известным как Class-Num или C-Num). Номера классов в целом
разделены на три диапазона (0-127, 128-191 и 192-255), определяемые двумя
старшими битами объекта Class-Num (буква «b» ниже обозначает бит).
Примечание: первое 32-битное слово объекта, чей Class-Num или Class-
Type относится к диапазону Vendor Private, ДОЛЖНО (MUST) быть SMI-кодом
предприятия этого поставщика в сетевом порядке октетов (эти коды
предприятий можно получить у IANA и зарегистрировать в IANA). Реализация,
встретившая объект Vendor Private с нераспознаваемым ею SMI-кодом
предприятия, ДОЛЖНА (MUST) обрабатывать этот объект (и содержащее его
сообщение) на основе Class-Num, как указано в разделе 3.10 документа
[RSVP].
o Class-Num = 0bbbbbbb
Номера классов от 0 до 119 назначаются посредством Standards
Action. Номера классов от 120 до 123 назначаются посредством
Expert Review. Номера классов от 124 до 127 зарезервированы для
использования Vendor Private.
o Class-Num = 10bbbbbb
Номера классов от 128 до 183 назначаются посредством Standards
Action. Номера классов от 184 до 187 назначаются посредством
Expert Review. Номера классов от 188 до 191 зарезервированы для
использования Vendor Private.
o Class-Num = 11bbbbbb
Номера классов от 192 до 247 назначаются посредством Standards
Action. Номера классов от 248 до 251 назначаются посредством
Expert Review. Номера классов от 252 до 255 зарезервированы для
использования Vendor Private.
2.3. Типы классов
Внутри каждого класса объектов имеется 8-битный тип класса (также
известный как C-Type). Область действия типов классов ограничена номером
класса. В общем случае уместность разрешения назначений типов классов
посредством Expert Review или Vendor Private зависит от семантики самого
номера класса. Поэтому любое новое определение номера класса должно
указывать подходящую политику «Соображений IANA» для назначения
дополнительных значений типа класса.
Для номеров классов, предшествующих настоящему документу (а именно 0, 1,
3-25, 30-37, 42-45, 64, 65, 128-131, 161-165, 192-196 и 207), политикой
назначения по умолчанию для новых типов классов является Standards
Action, если только RFC категории Standards Track или Best Current
Practice не заменяет это правило.
2.3.1. Подобъекты
Внутри объекта могут определяться подобъекты, как правило, в виде тройки
Type-Length-Value. Настоящий документ определяет политики назначения для
подобъектов EXPLICIT_ROUTE и RECORD_ROUTE. RFC, определяющий новые
подобъекты, ДОЛЖЕН (MUST) указывать, каким образом IANA назначает типы
подобъектов.
Объект EXPLICIT_ROUTE [RSVP-TE] содержит подобъект переменной длины,
идентифицируемый 7-битным полем Type. Типы от 0 до 119 назначаются
посредством Standards Action. Типы от 120 до 123 назначаются посредством
Expert Review. Типы от 124 до 127 резервируются для использования Vendor
Private.
Объект RECORD_ROUTE [RSVP-TE] содержит подобъект переменной длины,
идентифицируемый 8-битным полем Type. Типы от 0 до 191 назначаются
посредством Standards Action. Типы от 192 до 251 назначаются посредством
Expert Review. Типы от 252 до 255 резервируются для использования Vendor
Private.
Первые четыре октета содержимого подобъекта Vendor Private объекта
EXPLICIT_ROUTE или RECORD_ROUTE ДОЛЖНЫ (MUST) быть SMI-кодом предприятия
этого поставщика в сетевом порядке октетов.
2.4. Виртуальные порты назначения
Виртуальные порты назначения описаны в [RSVP-IPSEC], который также
определяет, каким образом должны производиться назначения IANA.
2.5. Коды и значения ошибок
Код ошибки — это 8-битная величина, появляющаяся в объекте ERROR_SPEC
для общего определения условия ошибки. С каждым кодом ошибки может быть
связано 16-битное значение ошибки, дополнительно определяющее причину
ошибки. Значение ошибки может быть определено глобально; в таком случае
компонент подкода назначается IANA.
Значения кода ошибки от 0 до 239 назначаются посредством Standards
Action. Значения от 240 до 251 назначаются посредством Expert Review.
Значения от 252 до 255 зарезервированы для использования Vendor Private.
Если код ошибки предназначен для использования Vendor Private, первые
четыре октета после значения ошибки ДОЛЖНЫ (MUST) быть SMI-кодом
предприятия поставщика в сетевом порядке октетов.
Глобально определённые значения ошибок назначаются посредством Standards
Action.
3. Изменение процедур RSVP
С сущностями RSVP связаны процедуры, описывающие, когда и как они должны
отправляться, приниматься, обрабатываться и как на них следует отвечать.
Изменение процедуры, влияющее на обработку сущности RSVP, принадлежащей
диапазону, обозначенному «Standards Action», ДОЛЖНО (MUST) быть
документировано в RFC категории Standards Track. Изменение процедуры,
влияющее на обработку сущности RSVP, принадлежащей диапазону,
обозначенному «Expert Review», ДОЛЖНО (MUST) быть документировано в RFC
категории Experimental.
4. Благодарности
Большая благодарность Скотту Брэднеру, который поощрил этот проект и
сделал несколько полезных замечаний и предложений.
5. Соображения безопасности
Ожидается, что процедуры, изложенные в настоящем документе, обеспечат
более тщательное рассмотрение изменений RSVP и тем самым их большую
архитектурную обоснованность, повышая безопасность как протокола, так и
сетей, в которых он развёрнут.
6. Соображения IANA
См. раздел 2.
7. Ссылки
7.1. Нормативные ссылки
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RSVP] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and
S. Jamin, "Resource ReSerVation Protocol (RSVP) --
Version 1 Functional Specification", RFC 2205, September
1997.
[RSVP-TE] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
7.2. Справочные ссылки
[ENT] IANA PRIVATE ENTERPRISE NUMBERS,
http://www.iana.org/assignments/enterprise-numbers
[IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RSVP-IPSEC] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC
Data Flows", RFC 2207, September 1997.
8. Адреса авторов
Kireeti Kompella
Juniper Networks
1194 N. Mathilda Ave
Sunnyvale, CA 94089 USA
EMail: kireeti@juniper.net
Jonathan P. Lang
Rincon Networks
EMail: jplang@ieee.org
9. Полное заявление об авторских правах
Copyright (C) The Internet Society (2004).
Настоящий документ подпадает под действие прав, лицензий и ограничений,
содержащихся в BCP 78, и, за исключением предусмотренного в нём, авторы
сохраняют все свои права.
Настоящий документ и содержащаяся в нём информация предоставляются на
условиях «КАК ЕСТЬ», И УЧАСТНИК, ОРГАНИЗАЦИЯ, КОТОРУЮ ОН/ОНА
ПРЕДСТАВЛЯЕТ ИЛИ КОТОРОЙ СПОНСИРУЕТСЯ (ЕСЛИ ТАКОВАЯ ИМЕЕТСЯ), INTERNET
SOCIETY И INTERNET ENGINEERING TASK FORCE ОТКАЗЫВАЮТСЯ ОТ ВСЕХ ГАРАНТИЙ,
ЯВНЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ, ВКЛЮЧАЯ, В ЧАСТНОСТИ, ЛЮБУЮ ГАРАНТИЮ ТОГО,
ЧТО ИСПОЛЬЗОВАНИЕ СОДЕРЖАЩЕЙСЯ ЗДЕСЬ ИНФОРМАЦИИ НЕ НАРУШИТ КАКИХ-ЛИБО
ПРАВ, А ТАКЖЕ ЛЮБЫЕ ПОДРАЗУМЕВАЕМЫЕ ГАРАНТИИ ТОВАРНОЙ ПРИГОДНОСТИ ИЛИ
ПРИГОДНОСТИ ДЛЯ ОПРЕДЕЛЁННОЙ ЦЕЛИ.
Интеллектуальная собственность
IETF не занимает какой-либо позиции относительно действительности или
объёма любых Прав интеллектуальной собственности либо иных прав, которые
могут заявляться как относящиеся к реализации или использованию технологии,
описанной в настоящем документе, или относительно того, в какой мере какая-
либо лицензия в отношении таких прав может быть или не быть доступной; IETF
также не заявляет, что предприняла какие-либо независимые усилия для
выявления любых таких прав. Информацию о процедурах IETF в отношении прав в
Документах IETF можно найти в BCP 78 и BCP 79.
Копии раскрытий IPR, представленных в Секретариат IETF, и любые заверения о
лицензиях, которые будут предоставлены, либо результаты попытки получить
общую лицензию или разрешение на использование таких имущественных прав
разработчиками или пользователями данной спецификации можно получить в
онлайновом репозитории IPR IETF по адресу
http://www.ietf.org/ipr.
IETF приглашает любую заинтересованную сторону довести до её сведения
информацию о любых авторских правах, патентах или заявках на патенты либо
иных имущественных правах, которые могут охватывать технологию, которая
может потребоваться для реализации данного стандарта. Просим направлять
информацию в IETF по адресу ietf-ipr@ietf.org.
Благодарность
Финансирование функции RFC Editor в настоящее время предоставляется
Internet Society.