RSVP over ATM Implementation Guidelines
RFC 2379 содержит рекомендации по реализации RSVP поверх коммутируемых виртуальных каналов ATM (SVC) для поддержки потоков QoS. Документ применяется к IP over ATM при использовании CLIP/ION, LANE 2.0 и MPOA. Реализациям СЛЕДУЕТ (SHOULD) по умолчанию передавать сообщения управления RSVP по пути данных Best Effort; допускается пользовательское переопределение этого поведения. Также СЛЕДУЕТ (SHOULD) использовать независимые VC для каждого резервирования RSVP и использовать для QoS тот же конечный узел, если для Best Effort уже установлен short-cut к тому же назначению или next-hop. Для многоадресных неоднородных сеансов реализации СЛЕДУЕТ (SHOULD) реализовать модель ограниченной неоднородности либо модифицированную однородную модель; им также СЛЕДУЕТ (SHOULD) поддерживать оба подхода и позволять выбрать фактически используемый метод, но это не является обязательным.
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].
Berger Best Current Practice [Page 1]
RFC 2379 RSVP over ATM Implementation Guidelines August 1998
В этом документе используются те же термины и допущения, которые
сформулированы в [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, используемый для переноса трафика данных
сеанса, то есть данных, которые одновременно принадлежат
многоадресной группе и соответствуют протоколу и порту сеанса.
Berger Best Current Practice [Page 2]
RFC 2379 RSVP over ATM Implementation Guidelines August 1998
Поток данных ==========>
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 следуют разными путями.
Berger Best Current Practice [Page 3]
RFC 2379 RSVP over ATM Implementation Guidelines August 1998
______
/ \
+-------- / 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. Обратите внимание, что
при этом
Berger Best Current Practice [Page 4]
RFC 2379 RSVP over ATM Implementation Guidelines August 1998
подходе, когда короткие пути 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, вероятно, будет желательна модифицированная однородная
модель.
Berger Best Current Practice [Page 5]
RFC 2379 RSVP over ATM Implementation Guidelines August 1998
Поскольку не существует одной модели, удовлетворяющей всем случаям,
реализации СЛЕДУЕТ (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
Berger Best Current Practice [Page 6]
RFC 2379 RSVP over ATM Implementation Guidelines August 1998
СПИСОК ЛИТЕРАТУРЫ
[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.
Berger Best Current Practice [Page 7]
RFC 2379 RSVP over ATM Implementation Guidelines August 1998
Полное заявление об авторских правах
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
ОТКАЗЫВАЮТСЯ ОТ ВСЕХ ЯВНЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ ГАРАНТИЙ, ВКЛЮЧАЯ, В ЧАСТНОСТИ,
ЛЮБУЮ ГАРАНТИЮ ТОГО, ЧТО ИСПОЛЬЗОВАНИЕ СОДЕРЖАЩЕЙСЯ ЗДЕСЬ ИНФОРМАЦИИ НЕ НАРУШИТ
КАКИХ-ЛИБО ПРАВ, А ТАКЖЕ ЛЮБЫЕ ПОДРАЗУМЕВАЕМЫЕ ГАРАНТИИ ТОВАРНОЙ ПРИГОДНОСТИ
ИЛИ ПРИГОДНОСТИ ДЛЯ ОПРЕДЕЛЁННОЙ ЦЕЛИ.
Berger Best Current Practice [Страница 8]
Network Working Group L. Berger
Request for Comments: 2379 FORE Systems
BCP: 24 August 1998
Category: Best Current Practice
RSVP over ATM Implementation Guidelines
Status of this Memo
This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for
improvements. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (1998). All Rights Reserved.
Abstract
This memo presents specific implementation guidelines for running
RSVP over ATM switched virtual circuits (SVCs). The general problem
is discussed in [6]. Implementation requirements are discussed in
[2]. Integrated Services to ATM service mappings are covered in [3].
The full set of documents present the background and information
needed to implement Integrated Services and RSVP over ATM.
1. Introduction
This memo discusses running IP over ATM in an environment where SVCs
are used to support QoS flows and RSVP is used as the internet level
QoS signaling protocol. It applies when using CLIP/ION, LANE2.0 and
MPOA methods for supporting IP over ATM. The general issues related
to running RSVP[4] over ATM have been covered in several papers
including [6] and other earlier work. This document is intended as a
companion to [6,2] and as a guide to implementers. The reader should
be familiar with both documents.
This document provides a recommended set of functionality for
implementations using ATM UNI3.x and 4.0, while allowing for more
sophisticated approaches. We expect some vendors to additionally
provide some of the more sophisticated approaches described in [6],
and some networks to only make use of such approaches. The
recommended set of functionality is defined to ensure predictability
and interoperability between different implementations. Requirements
for RSVP over ATM implementations are provided in [2].
Berger Best Current Practice [Page 1]
RFC 2379 RSVP over ATM Implementation Guidelines August 1998
This document uses the same terms and assumption stated in [2].
Additionally, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC
2119 [5].
2. Implementation Recommendations
This section provides implementation guidelines for implementation of
RSVP over ATM. Several recommendations are common for all, RSVP
sessions, both unicast and multicast. There are also recommendations
that are unique to unicast and multicast session types.
2.1 RSVP Message VC Usage
The general issues related to which VC should be used for RSVP
messages is covered in [6]. It discussed several implementation
options including: mixed control and data, single control VC per
session, single control VC multiplexed among sessions, and multiple
VCs multiplexed among sessions. QoS for control VCs was also
discussed. The general discussion is not repeated here and [6]
should be reviewed for detailed information.
RSVP over ATM implementations SHOULD send RSVP control (messages)
over the best effort data path, see figure 1. It is permissible to
allow a user to override this behavior. The stated approach
minimizes VC requirements since the best effort data path will need
to exist in order for RSVP sessions to be established and in order
for RSVP reservations to be initiated. The specific best effort
paths that will be used by RSVP are: for unicast, the same VC used to
reach the unicast destination; and for multicast, the same VC that is
used for best effort traffic destined to the IP multicast group.
Note that for multicast there may be another best effort VC that is
used to carry session data traffic, i.e., for data that is both in
the multicast group and matching a sessions protocol and port.
Berger Best Current Practice [Page 2]
RFC 2379 RSVP over ATM Implementation Guidelines August 1998
Data Flow ==========>
QoS VCs
+-----+ --------------> +----+
| | --------------> | |
| Src | | R1 |
| | Best Effort VC(s) | |
+-----+ <-----------------> +----+
/\
||
||
RSVP Control
Messages
Figure 1: RSVP Control Message VC Usage
The disadvantage of this approach is that best effort VCs may not
provide the reliability that RSVP needs. However the best effort
path is expected to satisfy RSVP reliability requirements in most
networks. Especially since RSVP allows for a certain amount of packet
loss without any loss of state synchronization.
2.2 Aggregation
As discussed in [6], data associated with multiple RSVP sessions can
be sent using the same shared VCs. Implementation of such
"aggregation" models is still a matter for research. Therefore, RSVP
over ATM implementations SHOULD use independent VCs for each RSVP
reservation.
2.3 Short-Cuts
Short-cuts allow ATM attached routers and hosts to directly establish
point-to-point VCs across LIS boundaries, i.e., the VC end-points are
on different IP subnets. Short-cut support for unicast traffic has
been defined in [7] and [1]. The ability for short-cuts and RSVP to
interoperate has been raised as a general question. The area of
concern is the ability to handle asymmetric short-cuts. Specifically
how RSVP can handle the case where a downstream short-cut may not
have a matching upstream short-cut. In this case, which is shown in
figure 2, PATH and RESV messages following different paths.
Berger Best Current Practice [Page 3]
RFC 2379 RSVP over ATM Implementation Guidelines August 1998
______
/ \
+-------- / Router \ <-------+
| \ / | <....... RESVs Follow
| \______/ | Hop-by-hop Path
| |
| |
V QoS VCs |
+-----+ ==============> +----+
| | ==============> | |
| Src | | R1 |
| | Best Effort VC(s) | |
+-----+ <=================> +----+
/\
:: Data Paths:
:: ----> Hop-by-hop (routed)
PATHs and Data ====> Short-cut
Follow Short-cut
Path
Figure 2: Asymmetric RSVP Message Forwarding With ATM Short-Cuts
Examination of RSVP shows that the protocol already includes
mechanisms that allows support of the asymmetric paths. The
mechanism is the same one used to support RESV messages arriving at
the wrong router and the wrong interface. RSVP messages are only
processed when they arrive at the proper interface. When messages
arrive on the wrong interface, they are forwarded by RSVP. The
proper interface is indicated in the NHOP object of the message. So,
existing RSVP mechanisms will support the asymmetric paths that can
occur when using short-cuts.
The short-cut model of VC establishment still poses several issues
when running with RSVP. The major issues are dealing with established
best effort short-cuts, when to establish short-cuts, and QoS only
short-cuts. These issues will need to be addressed by RSVP
implementations.
The key issue to be addressed by RSVP over ATM implementations is
when to establish a short-cut for a QoS data flow. RSVP over ATM
implementations SHOULD simply follow best effort traffic. When a
short-cut has been established for best effort traffic to a
destination or next-hop, that same end-point SHOULD be used when
setting up RSVP triggered VCs for QoS traffic to the same destination
or next-hop. This will happen naturally when PATH messages are
forwarded over the best effort short-cut. Note that in this
Berger Best Current Practice [Page 4]
RFC 2379 RSVP over ATM Implementation Guidelines August 1998
approach, when best effort short-cuts are never established, RSVP
triggered QoS short-cuts will also never be established.
2.4 Data VC Management for Heterogeneous Sessions
Heterogeneous sessions can only occur with multicast RSVP sessions.
The issues relating to data VC management of heterogeneous sessions
are covered in detail in [6] and are not repeated in this document.
In summary, heterogeneity occurs when receivers request different
levels of QoS within a single session and also when some receivers do
not request any QoS. Both types of heterogeneity are shown in figure
3.
+----+
+------> | R1 |
| +----+
|
| +----+
+-----+ -----+ +--> | R2 |
| | ---------+ +----+ Receiver Request Types:
| Src | ----> QoS 1 and QoS 2
| | .........+ +----+ ....> Best-Effort
+-----+ .....+ +..> | R3 |
: +----+
/\ :
|| : +----+
|| +......> | R4 |
|| +----+
Single
IP Mulicast
Group
Figure 3: Types of Multicast Receivers
[6] provides four models for dealing with heterogeneity: full
heterogeneity, limited heterogeneity, homogeneous, and modified
homogeneous models. The key issue to be addressed by an
implementation is providing requested QoS downstream. One of, or some
combination of, the discussed models [6] may be used to provide the
requested QoS. Unfortunately, none of the described models is the
right answer for all cases. For some networks, e.g. public WANs, it
is likely that the limited heterogeneous model or a hybrid limited-
full heterogeneous model will be desired. In other networks, e.g.
LANs, it is likely that a the modified homogeneous model will be
desired.
Berger Best Current Practice [Page 5]
RFC 2379 RSVP over ATM Implementation Guidelines August 1998
Since there is not one model that satisfies all cases,
implementations SHOULD implement one of either the limited
heterogeneity model or the modified homogeneous model.
Implementations SHOULD support both approaches and provide the
ability to select which method is actually used, but are not required
to do so.
3. Security Considerations
The same considerations stated in [4] and [8] apply to this document.
There are no additional security issues raised in this document.
4. Acknowledgments
This work is based on earlier drafts and comments from the ISSLL
working group. The author would like to acknowledge their
contribution, most notably Steve Berson who coauthored one of the
drafts.
5. Author's Address
Lou Berger
FORE Systems
1595 Spring Hill Road
5th Floor
Vienna, VA 22182
Phone: +1 703-245-4527
EMail: lberger@fore.com
Berger Best Current Practice [Page 6]
RFC 2379 RSVP over ATM Implementation Guidelines August 1998
REFERENCES
[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.
Berger Best Current Practice [Page 7]
RFC 2379 RSVP over ATM Implementation Guidelines August 1998
Full Copyright Statement
Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Berger Best Current Practice [Page 8]