本備忘錄的狀態：
本備忘錄提供關于Internet社區的信息。它不指定任何一種形式的標準。本備忘錄的
發布不受任何限制。

摘要

本文檔描述RSVP、相應的綜合服務協議及其他資源預留組件的適用性，提供現時配置
資源預留的指導。本文檔和第一次提交的RSVP和綜合服務規范一起加入RSVP標準軌跡
中。

目錄
1.介紹 2
2.影響RSVP配置的問題 3
2.1.可擴展性 3
2.2.安全考慮 3
2.3.策略控制 4
3.建議 4
4.參考 4
5.作者地址 5

1.介紹
RSVP[RFC2205]是一個單播和多播的信令協議，被設計來安裝和維護在數據流路徑
上的每個路由器的預留聲明信息。RSVP對這些聲明的處理被定義在由綜合服務工作組
（WG）指定的[RFC2211]和[RFC2212]的服務中。這些服務和RSVP同時被引入IETF
的標準軌跡中。從現在起，縮略語RSVP被用作信令協議和與之合并在一起的綜合服務
規范的簡稱。

RSVP必須與幾個附加組件聯合使用，如下表所示：
表1資源預留的附加組件

1. 用于期望服務的信息格式的參數能被表示。[RFC2210]中列出了這些格式的一
個推薦標準集。
2. 用來實現一或兩個[RFC2211]和[RFC2212]模式的路由器和主機機制（如分
組分類和調度，接入控制算法）也被加進標準軌跡中。
3. 用于接入期望的控制和資源使用的信息格式的參數能被表示。RSVP工作組憲章
中有一個這些格式的用于標準軌跡的小公共子集。RSVP協議規范的策略對象僅
在這時是可選的。
4.實現期望的接入控制策略功能的各種定位機制，包括授權和其他安全機制。

在表1中描述的每個組件的一些格式中，支持RSVP的應用可以通過ip網絡獲得區
分服務質量。網絡化的多媒體應用，大多需要（或受益于）一個可猜測的終端用戶經
驗，將會是RSVP信令服務的首批用戶。
因為RSVP和綜合服務及表1所列的其他部件標志了IP網絡服務模式的一個極大變
革，所以RSVP受到了很大的關注，并促使它以一個標準軌跡RFC而被發布。目前，很
多操作系統和路由器供給商把RSVP和綜合服務集成在他們的產品中，以備即將到來的
應用。本適用性聲明的目的是描述當前已知可行的RSVP規范的使用，并標識限制范圍
及正在進行的工作提出的某些限制。

2.影響RSVP配置的問題
因為還存在大量明顯會影響配置成功的問題，因此大范圍的配置RSVP必須小心。

2.1.可擴展性
在一個路由器上運行RSVP所要求的資源需求（處理和存儲）根據單獨的會話的數
量而按比例增長（如，RSVP預留）。因此，在一個高帶寬鏈路上支持大量小的預留會
很輕易使路由器過載，這樣作是不策略的。而且，當前一些路由產品或它們的某些高
速接口（如OC－3或以上）很難具有實現分組分類和調度的能力，這些能力被用來提
供預留流的區分服務。
這些問題表明在目前的高帶寬骨干網上配置RSVP一般是不合適的。在將來，這些
骨干網的營運商將不會選擇天真地為每個單獨的流實現RSVP。另外，在骨干網的“邊
緣”匯聚那些需要非凡處理的流的技術正在發展。在骨干網內部，作為一種滿足單個
流的端到端需求的一種方法，大量花費較少的途徑因此而被用來為一個整體的匯聚流
留出資源。
在近期內，大量供給商將用多種不同的方法來匯聚預留。這不是IETF目前在此領
域標準開發中正在進行的工作。BOF，區分服務的未來方向，在1997年7月，Memphis
IETF考慮IETF關于在這和其他問題上如何進行下一步工作。鼓勵關于匯聚技術和經念
的文檔的公開。

2.2.安全考慮
RSVP工作組（WG）提交的推薦標準中包括兩個與安全相關的文檔[Baker96,RFC
2207]。[Baker96]提出了拒絕服務攻擊和偷竊服務攻擊。[RFC2207]介紹了本身使
用了IPSEC的數據流的RSVP機制。
第一個文檔被推薦用來防止對RSVP路由器的欺騙性預留請求；這些請求可能被用
來獲得沒有授權的服務或者用拒絕服務攻擊來鎖住網絡資源。修改或欺騙預留請求被
相鄰路由器之間的每一跳md5校檢和（在一個Integrity對象中）檢查。
如前所述，RSVP的每一跳認證確保用于路由器的密鑰治理和分配得以解決和配置。在
找到一個有效的密鑰架構前，將使用手工加密的會話整體。另外，[Baker96]
可能被RFC2085修改。
在路由器間所需要的密鑰架構不僅僅是RSVP獨有的：普遍認為在路由架構中存在
大量拒絕服務攻擊（與RSVP根本無關），這只能通過配置一個密鑰架構來解決。
偷竊服務攻擊風險要求用戶小心配置。一個基本的預防措施是在支持RSVP的架構
中對新的和改變的過慮器規范設定治理日志，如[RFC2206]的新流陷入。
[Baker96]中定義的Integrity對象在策略控制中也可能會起作用，這將在2.3中
進行描敘。
第二個與安全相關的文檔提供一種用于傳輸和用戶字節已加密的載流機制。盡管
某些應用極大的受益于這種加密，但這與RSVP或預留的安全功能無關。
下面關于策略控制的章節補充了對RSVP授權安全的討論。

2.3.策略控制
策略控制提出了在一個預留協議可被用來設置不平衡服務時誰可以，或誰不可以
獲得預留的問題。
目前RSVP規范為與預留一起的傳輸控制信息定義了一種機制。然而，該規范并沒
有定義策略本身。現在供給商已聲明他們將使用RSVP定義的機制來實現專有策略。
RSVP工作組正在為即將使用Integrity對象的會話指定一個簡單的標準化策略對
象和完全的簡單機制。本適用性聲明在完成工作組憲章時會作修正。
在作出配置RSVP的任何決定前，確保供給商提供的有效策略控制適合于應用目標是明
智的。除了缺乏在任何策略領域（如接入控制、授權和計費）的文檔化策略機制外，
社區對限制Internet服務的描述，設置和控制策略也沒有經驗。
因此供給商的解決方案很可能會經常修改，非凡是在IETF還沒有開發出任何策略
規范前。

3.建議
在RSVP規范的當前形式下，在一個intranet運行的多媒體應用將會是首先的
益者。SNA/DLSW被認為是另一個受益的“應用”。
在一個單一的或相應治理域數目小的intranet內，擴展性、安全性和接入策略都
比在全球Internet上更輕易治理。在一個單一的Internet服務提供商那里使用用于小
數目流的RSVP和支持組件，跟在一個intranet上使用相似。
目前關于RSVP的經驗僅來自限制試驗和intranet配置上運行的測試。我們建議在
不需解決第二節中所述的那些問題時還有可觀的益處的話，人們可以開始在intranet
或ISP環境下（如上所述）使用RSVP。

下面是引自RFC2026的關于推薦標準技術的使用：

實現者應視推薦標準為不成熟的規范。實現它們以獲得經驗和驗證、測試、闡明
規范是可以考慮的。然而，假如發現了問題或確定了更好的解決方案，推薦標準的內
容將會作更改，因此建議在一個布滿爭議的環境下不要配置這些標準的實現。
第二節中列出的擴展性、安全和策略控制的一般問題都是正在研究和發展的主
題，如第三方的預留或區分服務的設置，大多不在本適用性聲明內。

4.參考
[Baker96]Baker,F.,"RSVPCryptographicAuthentication",Workin
PRogress.

[RFC2206],Baker,F.andJ.Krawczyk,"RSVPManagementInformation
Base",RFC2206,September1997.

[RFC2207]Berger,L.andT.O'Malley,"RSVPExtensionsforIPSEC
DataFlows",RFC2207,September1997.

[RFC2211]Wroclawski,J.,"SpecificationofControlled-Load
NetworkElementService",RFC2211,September1997.

[RFC2212]Shenker,S.,C.PartridgeandR.Guerin,"Specification
ofGuaranteedQualityofService",RFC2212,September1997.

[RFC2205]Braden,R.Ed.etal,"ResourceReserVationProtocol
--Version1FunctionalSpecification",RFC2205,
September1997.

[RFC2210]Wroclawski,J.,"TheUSEOfRSVPwithIETFIntegrated
Services",RFC2210,September1997.

5.作者地址
FredBakerAbelWeinrib
CiscoSystemsIntelCorporation
Phone:408-526-4257Phone:503-264-8972
EMail:fred@cisco.comEMail:aweinrib@ibeam.intel.com
BobBraden
USC/ISILixiaZhang
4676AdmiraltyWayUCLAComputerScienceDepartment
MarinaDelRey,CA902924531GBoelterHall
Phone:310-822-1511LosAngeles,CA90095-1596USA
EMail:braden@isi.eduPhone:310-825-2695
EMail:lixia@cs.ucla.edu
ScottBradnerAllynRomanow
HarvardUniversitySunMicrosystems
Phone:617-495-3864Phone:415-786-5179
EMail:sob@harvard.eduEMail:allyn@eng.sun.com
MichaelO'Dell AllisonMankin
UUNETTechnologies mankin@east.isi.edu
Phone:703-206-5471
EMail:mo@uu.net