本備忘錄的狀態
該文檔具體說明了Internet團體的標準協議，和需要為改進而進行的備忘錄的分類是無約束的。尚需要用于改進的進一步的討論和建議這份備忘錄定義了一個應用于Internet業界的通用的慣例，尚需要得到用于改進的進一步的討論和建議。本備忘錄的分發是沒有限制的。
版權聲明
Copyright(C)TheInternetSociety(1998)。所有權被保留。
摘要
該備忘錄具體介紹了RSVP通過ATM執行的交換虛擬電路的執行向導。概括的問題在[6]中討論。執行要求在[2]中討論.對ATM服務計劃的綜合服務在[3]中闡述。整個文檔提供了需要執行綜合服務的背景和信息及基于ATM的RSVP。
1.緒論
該備忘錄論述了運行通過ATM（異步傳輸模式）的ip的一個環境，該環境中SVC被用于支持QoS流程、RSVP被用于interent水平QoS信號協議。它適用于用CLIP/ION,LANE2.0和MPOA方法來支持通過ATM執行的IP。通常的出版物敘述的運行RSVP[4]通過ATM已經被很多論文論述過，包括[6]和其他早期的作品。該文檔可作為[6,2]的一個伙伴或一個對執行者的向導。讀者應該熟悉這兩種文檔。
該文檔提供了一套推薦用ATMUNI3.x或4.0來執行的功能，同時答應用更多的詭辯的方法。我們期待一些賣主會提供一些更詭辯的方法，可描述在[6]中和一些僅使用這樣方法的網絡中。這種被推薦的功能要確保在不同執行時刻，具有可預言性和互用性。RSVP通過ATM執行的需要在[2]中執行。
該文檔應用在[2]中陳述的相同的術語和設想。同時，在該文檔要害詞“MUST”、“MUSTNOT”、“REQUIRED”、“SHALL”、“SHALLNOT”、“SHOULD”、“SHOULDNOT”、“RECOMMENDED”、“MAY”和“OPTIONAL”將和在RFC2119[5]中被描述過的一樣。
2.執行建議
這部分提供了通過ATM執行RSVP的執行向導，對全部的單點傳送和多點傳送的回復時間來說，很多建議是公用的。當然，也有對單點傳送和多點傳送的回復時間類型的獨特建議。
2.1RSVP信息VC（電路）用法
一般講述對于VC應該用于RSVP信息的出版物在[6]中提到。它討論了許多執行選項，包括：混合控制和數據，單一控制VC（電路）每一回復時間，單一控制電路(VC)多元的回復時間，和多元控制電路(VC)多元的回復時間。為控制VC的QoS也被討論。概括性的討論不在這里重復，在[6]中會回顧細節的信息。
RSVP通過ATM執行應該通過最優的數據線，來發送RSVP控制信息，如圖1。
DataFlow==========>

QoSVCs
+-----+-------------->+----+
-------------->
SrcR1
BestEffortVC(s)
+-----+<----------------->+----+
//


RSVPControl
Messages

圖1:RSVP控制信息的VC用法
它答應使用者不考慮這一行為。為了確定RSVP對話時期和發起RSVP預約，需要存在最好的數據線，因此，也就需要有特定的方法使VC（電路）最小化。被用于RSVP的特定最佳的方法是：對單點傳送來說，相同的VC用于到達單點傳送目的地；對多點傳送來說，相同的VC用于為去往IP的最大交通量的多點傳送組。為了信息的多點傳送，還有其他用于通信對話期間傳送數據的好的VC。比如，為多點傳送組及協議和端口匹配對話期間的數據。
這種方法的缺點在于最優的VC可能不會提供RSVP所需的可靠性。然而，被期望的最好方法是在許多網上能滿足RSVP的可靠性需求。尤其是RSVP答應遺失一定數量信息包，去無任何同步狀態遺失。
2.2集合
正如[6]中討論的，數據聯系多重RSVP處理時間能夠用同一個共享VC。執行這樣的“集合體”模型仍然一項待研究的問題。因此，通過ATM執行RSVP應該用為每個RSVP保留的獨立的VC。
2.3短切口
短切口答應ATM附上路由器和主機通過LIS邊界來直接安置點對點的VC。例如，VC末端有不同的IP子網。短切口支持已在[7]和[1]中具體說明過的單點傳輸。短切口的功能和RSVP相互運行已經上升為一個通用的問題。所關心的范圍是用于處理不均勻的短接口的能力。尤其是RSVP如何處理下位機短接口不能跟上位機短接口匹配的問題。在這種情況下，正如圖2中所示，PATH和RESV信息有各自不同的路徑。
______
//
+--------/Router/<-------+
//<.......RESVsFollow
/______/Hop-by-hopPath


VQoSVCs
+-----+==============>+----+
==============>
SrcR1
BestEffortVC(s)
+-----+<=================>+----+

//
::DataPaths:
::---->Hop-by-hop(routed)
PATHsandData====>Short-cut
FollowShort-cut
Path

圖2:AsymmetricRSVPMessageForwardingWithATMShort-Cuts
RSVP的檢查顯示：協議已經包括答應支持不均勻路徑的機械裝置。該機械裝置同樣用于支持RSVP信息到達錯誤的路由器或錯誤的接口。RSVP信息只有到達正確的接口才被處理。當信息到達錯誤的接口時，將會被RSVP轉寄。正確的接口會在NHOP信息中顯示。所以，現有的RSVP機械裝置將會支持當用短接口時能夠運行的不均勻路徑。
但用RSVP運行時，VC設施的短接口模型仍會造成很多的問題。主要問題是處理已設置的最佳短接口。一旦設置短接口，QoS只是短接口。這些問題需要通過RSVP執行來尋址。
RSVP通過ATM執行的尋址的要害問題是為QoS數據流設置一個短接口。RSVP通過ATM執行SHOULD完全跟隨最佳的通信量。當一個短接口被設置為到一個目的文件或下一個目的地的最佳通信量時，應該應用同樣的終端，來設置RSVP觸發的VC，使QoS通信量到同樣的目的文件或下一個目的地。當路徑信息被通過最佳短接口轉寄時，這些將自動的進行。在這種方法中，若最佳短接口從未設置，RSVP觸發的QoS短接口將同樣不會被設置。
2.4不均勻性處理時間的數據VC處理
不均勻性處理時間只是在處理通過多點傳送時需要考慮。這一觀點與數據不均勻性處理時間的VC治理相關聯，這些在[6]中具體介紹過了，本文檔中就不再重復。總之，當接收器要求具有不同水平的單一時間的QoS或當一些接收器不需要任何QoS時，將發生不同成分。兩種不同成分如圖3中所示。

+----+
+------>R1
+----+

+----+
+-----+-----++-->R2
---------++----+ReceiverRequestTypes:
Src---->QoS1andQoS2
.........++----+....>Best-Effort
+-----+.....++..>R3
:+----+
//:
:+----+
+......>R4
+----+
Single
IPMulicast
Group

圖3:多播接收器的類型
[6]提供四種處理不均勻性的模式：完全不均勻模式、有限不均勻模式、均勻的和改進的均勻模式。要害的問題是從事通過一次執行提供被請求的下位機QoS。其中之一，或一些組合，討論模式[6]可能用于提供被請求的QoS。不幸的是，上述描述模式并不是對所有的案例的正確回答。對一些網絡，例如，公眾廣域網，可能很需要有限不均勻模式或混合的有限-完全不均勻模式。對于其它網絡，比如局域網，可能很需要改進的均勻模式。
既然沒有一種模式使所有的案例滿足，執行應該貫徹有限不均勻模式改進的均勻模式。執行應該支持方法和提供能力來選擇事實上應該被使用，但卻沒要求這樣做的那種方法。
3.安全考慮
同樣的事項在應用于該文檔的[4]和[8]中被陳述過，在該文檔中沒有提出追加保證金的問題。
4.鳴謝
該作品是基于ISSLL工作組早期的草案和注釋而作的，作者真心感謝他們的貢獻，非凡是SteveBerson，他參與著作了這些草案的部分工作。
5.作者地址
LouBerger
FORESystems
1595SPRingHillRoad
5thFloor
Vienna,VA22182
Phone:+1703-245-4527
EMail:lberger@fore.com
參考書目
[1]TheATMForum，“MPOABaselineVersion1”，May1997。
[2]Berger，L.，“RSVPoverATMImplementationRequirements”，RFC2380，August1998。
[3]Borden，M.，和M.Garrett，“InterOperationofControlled-LoadandGuaranteed-ServicewithATM”，RFC2381，August1998。
[4]Braden，R.，Zhang，L.，Berson，S.，Herzog，S.和S.Jamin，“ResourceReSerVationProtocol(RSVP)--Version1FunctionalSpecification”，RFC2205，September1997。
[5]Bradner，S.，“KeyWordsforuseinRFCstoIndicateRequirementLevels”，BCP14，RFC2119，March1997。
[6]Crawley，E.，Berger，L.，Berson，S.，Baker,F.,Borden,M.,andJ.Krawczyk,“AFrameworkforIntegratedServicesandRSVPoverATM”，RFC2382，August1998。
[7]LUCiani，J.,Katz，D.，Piscitello，D.和B.Cole，“NBMANextHopResolutionProtocol(NHRP)”，RFC2332，April1998。
[8]Perez，M.，Liaw，F.，Grossman，D.，Mankin，A.，Hoffman，E.和A.Malis，“ATMSignallingSupportforIPoverATM”，RFC1755，February1995。
完整的版權聲明
Copyright(C)TheInternetSociety(2000)。版權所有。
本文檔及其譯文可以拷貝和提供給他人，且其衍生物，如評論、解釋或幫助實施的作品可以全部或部分地定制、拷貝、出版和發布，對此我們不加任何限制，前提是上述版權聲明，及本段內容包含在所有的拷貝和派生作品中。然而，本文檔本身不答應以任何方式修改，例如刪除Internet社團或其他Internet組織的版權聲明或參考，除非是為了開發Internet標準的需要。即便在這種情況下，也需要添加Internet標準中定義的版權聲明，或者根據需要把他翻譯成英語以外的其他語言。
上述準許的有限許可是永久性的，無論是Internet社團以及其繼續者或代理者都將不會廢止這些許可。
本文檔及其中包含的信息基于“ASIS”提供，而且INTERNET社團和IETF拒絕所有授權、表達或影射，包括但不限于任何這里使用的消息的授權將不會違反任何版權或者隱含的商業性授權或對特定的合理目的。
致謝
目前，RFC編者活動的基金由Internet社團提供。