Network Working Group L. Berger
Request for Comments: 2379 FORE Systems
BCP: 24 August 1998
Category: Best Current Practice
Рекомендации по реализации RSVP поверх ATM
Статус этого меморандума
Этот документ определяет Best Current Practices Интернета для
интернет-сообщества и запрашивает обсуждение и предложения по
улучшениям. Распространение этого меморандума не ограничено.
Уведомление об авторских правах
Copyright (C) The Internet Society (1998). All Rights Reserved.
Аннотация
Этот меморандум представляет конкретные рекомендации по реализации
RSVP поверх коммутируемых виртуальных каналов (SVC) ATM. Общая
проблема рассматривается в [6]. Требования к реализации обсуждаются
в [2]. Отображения интегрированных служб на службы ATM охватываются
в [3]. Полный набор документов представляет предпосылки и сведения,
необходимые для реализации Integrated Services и RSVP поверх ATM.
1. Введение
Этот меморандум рассматривает работу IP поверх ATM в среде, где SVC
используются для поддержки потоков QoS, а RSVP используется как
протокол сигнализации QoS уровня интернета. Он применяется при
использовании методов CLIP/ION, LANE2.0 и MPOA для поддержки IP
поверх ATM. Общие вопросы, связанные с работой RSVP[4] поверх ATM,
были рассмотрены в нескольких статьях, включая [6] и другие более
ранние работы. Этот документ предназначен в качестве дополнения к
[6,2] и руководства для разработчиков реализаций. Читателю следует
быть знакомым с обоими документами.
Этот документ предоставляет рекомендуемый набор функциональности
для реализаций, использующих ATM UNI3.x и 4.0, допуская при этом
более сложные подходы. Мы ожидаем, что некоторые поставщики также
предоставят некоторые из более сложных подходов, описанных в [6], и
что некоторые сети будут использовать только такие подходы.
Рекомендуемый набор функциональности определён для обеспечения
предсказуемости и совместимости между различными реализациями.
Требования к реализациям RSVP поверх ATM приведены в [2].
В этом документе используются те же термины и допущения, которые
сформулированы в [2]. Кроме того, ключевые слова "MUST", "MUST NOT",
"REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "MAY" и "OPTIONAL" в этом документе должны
интерпретироваться так, как описано в RFC 2119 [5].
2. Рекомендации по реализации
В этом разделе приведены рекомендации по реализации RSVP поверх ATM.
Несколько рекомендаций являются общими для всех сеансов RSVP — как
одноадресных, так и многоадресных. Также имеются рекомендации,
специфичные для типов одноадресных и многоадресных сеансов.
2.1 Использование VC для сообщений RSVP
Общие вопросы, связанные с тем, какой VC следует использовать для
сообщений RSVP, рассмотрены в [6]. В нём обсуждалось несколько
вариантов реализации, включая: смешанные управление и данные, один
управляющий VC на сеанс, один управляющий VC, мультиплексированный
между сеансами, и несколько VC, мультиплексированных между сеансами.
Также обсуждалось QoS для управляющих VC. Общее обсуждение здесь не
повторяется; для подробных сведений следует ознакомиться с [6].
Реализации RSVP поверх ATM СЛЕДУЕТ (SHOULD) отправлять управляющие
сообщения RSVP по тракту данных с обслуживанием best effort; см.
рисунок 1. Допускается разрешить пользователю переопределять это
поведение. Указанный подход минимизирует требования к VC, поскольку
тракт данных с обслуживанием best effort должен существовать, чтобы
сеансы RSVP могли быть установлены и чтобы могли быть инициированы
резервирования RSVP. Конкретные тракты best effort, которые будут
использоваться RSVP: для одноадресной передачи — тот же VC, который
используется для достижения одноадресного адреса назначения; для
многоадресной передачи — тот же VC, который используется для трафика
best effort, направленного IP-группе многоадресной передачи.
Обратите внимание, что для многоадресной передачи может существовать
другой VC best effort, используемый для переноса трафика данных
сеанса, то есть данных, которые одновременно принадлежат
многоадресной группе и соответствуют протоколу и порту сеанса.
Поток данных ==========>
QoS VCs
+-----+ --------------> +----+
| | --------------> | |
| Src | | R1 |
| | Best Effort VC(s) | |
+-----+ <-----------------> +----+
/\
||
||
Управляющие сообщения
RSVP
Рисунок 1: Использование VC для управляющих сообщений RSVP
Недостаток этого подхода состоит в том, что VC best effort могут не
обеспечивать надёжность, необходимую RSVP. Однако ожидается, что
тракт best effort будет удовлетворять требованиям RSVP к надёжности
в большинстве сетей. Особенно поскольку RSVP допускает определённую
потерю пакетов без какой-либо потери синхронизации состояния.
2.2 Агрегирование
Как обсуждалось в [6], данные, связанные с несколькими сеансами RSVP,
могут отправляться с использованием одних и тех же совместно
используемых VC. Реализация таких моделей «агрегирования» всё ещё
является предметом исследований. Поэтому реализации RSVP поверх ATM
СЛЕДУЕТ (SHOULD) использовать независимые VC для каждого
резервирования RSVP.
2.3 Короткие пути
Короткие пути позволяют маршрутизаторам и хостам, подключённым к ATM,
напрямую устанавливать двухточечные VC через границы LIS, то есть
конечные точки VC находятся в разных IP-подсетях. Поддержка коротких
путей для одноадресного трафика определена в [7] и [1]. Возможность
взаимодействия коротких путей и RSVP была поставлена как общий
вопрос. Область озабоченности — способность обрабатывать
асимметричные короткие пути. В частности, как RSVP может обработать
случай, когда короткому пути вниз по потоку может не соответствовать
короткий путь вверх по потоку. В этом случае, показанном на рисунке
2, сообщения PATH и RESV следуют разными путями.
______
/ \
+-------- / Router \ <-------+
| \ / | <....... RESV следуют
| \______/ | пошаговому пути
| |
| |
V QoS VCs |
+-----+ ==============> +----+
| | ==============> | |
| Src | | R1 |
| | Best Effort VC(s) | |
+-----+ <=================> +----+
/\
:: Пути данных:
:: ----> Пошаговый (маршрутизируемый)
PATH и данные ====> Короткий путь
следуют по короткому
пути
Рисунок 2: Асимметричная пересылка сообщений RSVP с короткими путями ATM
Изучение RSVP показывает, что протокол уже включает механизмы,
допускающие поддержку асимметричных путей. Этот механизм — тот же,
который используется для поддержки сообщений RESV, прибывающих не к
тому маршрутизатору и не на тот интерфейс. Сообщения RSVP
обрабатываются только тогда, когда они прибывают на надлежащий
интерфейс. Когда сообщения прибывают на неправильный интерфейс, они
пересылаются RSVP. Надлежащий интерфейс указывается в объекте NHOP
сообщения. Таким образом, существующие механизмы RSVP будут
поддерживать асимметричные пути, которые могут возникать при
использовании коротких путей.
Модель установления VC с короткими путями всё ещё создаёт несколько
вопросов при работе с RSVP. Основные вопросы — обработка
установленных коротких путей best effort, момент установления
коротких путей и короткие пути только для QoS. Эти вопросы должны
быть решены реализациями RSVP.
Ключевой вопрос, который должны решить реализации RSVP поверх ATM,
— когда устанавливать короткий путь для потока данных QoS. Реализации
RSVP поверх ATM СЛЕДУЕТ (SHOULD) просто следовать за трафиком best
effort. Когда для трафика best effort к адресу назначения или
следующему узлу был установлен короткий путь, ту же конечную точку
СЛЕДУЕТ (SHOULD) использовать при настройке инициированных RSVP VC
для трафика QoS к тому же адресу назначения или следующему узлу. Это
будет происходить естественным образом, когда сообщения PATH
пересылаются по короткому пути best effort. Обратите внимание, что
при этом
подходе, когда короткие пути best effort никогда не устанавливаются,
короткие пути QoS, инициированные RSVP, также никогда не будут
устанавливаться.
2.4 Управление VC данных для неоднородных сеансов
Неоднородные сеансы могут возникать только при многоадресных сеансах
RSVP. Вопросы, относящиеся к управлению VC данных неоднородных
сеансов, подробно рассмотрены в [6] и не повторяются в этом
документе. Вкратце, неоднородность возникает, когда получатели
запрашивают разные уровни QoS в рамках одного сеанса, а также когда
некоторые получатели не запрашивают никакого QoS. Оба типа
неоднородности показаны на рисунке 3.
+----+
+------> | R1 |
| +----+
|
| +----+
+-----+ -----+ +--> | R2 |
| | ---------+ +----+ Типы запросов получателей:
| Src | ----> QoS 1 и QoS 2
| | .........+ +----+ ....> Best-Effort
+-----+ .....+ +..> | R3 |
: +----+
/\ :
|| : +----+
|| +......> | R4 |
|| +----+
Одна
IP-группа
многоадресной передачи
Рисунок 3: Типы многоадресных получателей
В [6] приведены четыре модели работы с неоднородностью: полная
неоднородность, ограниченная неоднородность, однородная и
модифицированная однородная модели. Ключевой вопрос, который должна
решить реализация, — предоставление запрошенного QoS вниз по потоку.
Для предоставления запрошенного QoS может использоваться одна из
обсуждаемых моделей [6] или их некоторое сочетание. К сожалению, ни
одна из описанных моделей не является правильным ответом для всех
случаев. Для некоторых сетей, например общедоступных WAN, вероятно,
будет желательна модель ограниченной неоднородности или гибридная
модель ограниченной и полной неоднородности. В других сетях,
например LAN, вероятно, будет желательна модифицированная однородная
модель.
Поскольку не существует одной модели, удовлетворяющей всем случаям,
реализации СЛЕДУЕТ (SHOULD) реализовать либо модель ограниченной
неоднородности, либо модифицированную однородную модель. Реализации
СЛЕДУЕТ (SHOULD) поддерживать оба подхода и предоставлять возможность
выбирать фактически используемый метод, но не обязаны это делать.
3. Аспекты безопасности
К этому документу применимы те же соображения, которые изложены в
[4] и [8]. Этот документ не поднимает дополнительных вопросов
безопасности.
4. Благодарности
Эта работа основана на более ранних черновиках и комментариях рабочей
группы ISSLL. Автор хотел бы выразить признательность за их вклад,
особенно Steve Berson, который был соавтором одного из черновиков.
5. Адрес автора
Lou Berger
FORE Systems
1595 Spring Hill Road
5th Floor
Vienna, VA 22182
Phone: +1 703-245-4527
EMail: lberger@fore.com
СПИСОК ЛИТЕРАТУРЫ
[1] The ATM Forum, "MPOA Baseline Version 1", May 1997.
[2] Berger, L., "RSVP over ATM Implementation Requirements",
RFC 2380, August 1998.
[3] Borden, M., and M. Garrett, "Interoperation of Controlled-Load
and Guaranteed-Service with ATM", RFC 2381, August 1998.
[4] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin,
"Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
Specification", RFC 2205, September 1997.
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[6] Crawley, E., Berger, L., Berson, S., Baker, F., Borden, M., and
J. Krawczyk, "A Framework for Integrated Services and RSVP over
ATM", RFC 2382, August 1998.
[7] Luciani, J., Katz, D., Piscitello, D., and B. Cole, "NBMA Next
Hop Resolution Protocol (NHRP)", RFC 2332, April 1998.
[8] Perez, M., Liaw, F., Grossman, D., Mankin, A., Hoffman, E., and
A. Malis, "ATM Signalling Support for IP over ATM", RFC 1755,
February 1995.
Полное заявление об авторских правах
Copyright (C) The Internet Society (1998). All Rights Reserved.
Данный документ и его переводы могут копироваться и предоставляться
другим лицам, а производные работы, содержащие комментарии к нему, иным
образом разъясняющие его или содействующие его реализации, могут
подготавливаться, копироваться, публиковаться и распространяться полностью
или частично без каких-либо ограничений при условии, что приведённое выше
уведомление об авторских правах и данный абзац включаются во все такие копии
и производные работы. Однако сам этот документ не может изменяться каким бы
то ни было образом, например путём удаления уведомления об авторских правах
или ссылок на Internet Society либо другие организации Internet, за
исключением изменений, необходимых для разработки стандартов Internet, в
каковом случае должны соблюдаться процедуры в отношении авторских прав,
определённые процессом Internet Standards, либо изменений, требуемых для
перевода документа на языки, отличные от английского.
Предоставленные выше ограниченные разрешения действуют бессрочно и не будут
отозваны Internet Society или её правопреемниками либо цессионариями.
Данный документ и содержащаяся в нём информация предоставляются по принципу
«КАК ЕСТЬ» ("AS IS"), И INTERNET SOCIETY И INTERNET ENGINEERING TASK FORCE
ОТКАЗЫВАЮТСЯ ОТ ВСЕХ ЯВНЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ ГАРАНТИЙ, ВКЛЮЧАЯ, В ЧАСТНОСТИ,
ЛЮБУЮ ГАРАНТИЮ ТОГО, ЧТО ИСПОЛЬЗОВАНИЕ СОДЕРЖАЩЕЙСЯ ЗДЕСЬ ИНФОРМАЦИИ НЕ НАРУШИТ
КАКИХ-ЛИБО ПРАВ, А ТАКЖЕ ЛЮБЫЕ ПОДРАЗУМЕВАЕМЫЕ ГАРАНТИИ ТОВАРНОЙ ПРИГОДНОСТИ
ИЛИ ПРИГОДНОСТИ ДЛЯ ОПРЕДЕЛЁННОЙ ЦЕЛИ.