組織：中國互動出版網（http://www.china-pub.com/）
RFC文檔中文翻譯計劃（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：ouyang@china-pub.com
譯者：lv_xinyang (lv_xinyang  xylv@travelsky.com)
譯文發布時間：2001-5-8
版權：本中文翻譯文檔版權歸中國互動出版網所有。可以用于非商業用途自由轉載，但必須
保留本文檔的翻譯及版權信息。


Network Working Group                                           J. Kempf
Request for Comments: 3082                                J. Goldschmidt
Category: Experimental                                  Sun Microsystems
March 2001

服務定位協議（SLP）的預研報告
(RFC3082   Notification and Subscription for SLP)

本備忘錄的說明：
本備忘錄描述了一個基于因特網的實驗中的協議。此協議并不指定任何一種特定的因特網標
準，它還有待進一步的討論和建議加以完善。本備忘錄的發布不受任何限制。
版權聲明
Copyright (C) The Internet Society (2001).  All Rights Reserved.
摘要
    服務定位協議（SLP）能夠提供一些機制，通過這些機制服務代理客戶能夠發布通告，
而用戶代理客戶能夠查詢各種服務。此協議是按照需求驅動模式設計的，這樣當用戶代理對
服務信息發出特定請求時能夠獲得這些信息。此外，還存在另一類的用戶代理應用，即要求
通知某一新服務的開通或取消。在RFC 2608的設計中，上述應用是通過向網絡中發輪詢信
號來獲知改變的情況。而在此文中，我們描述的協議能夠實現當改變發生時不必發輪詢信號，
這些代理就能得到消息。

目錄
1.  簡介……………………………………………………………………………………………2
2.	詞匯約定解釋…………………………………………………………………………………2
3.	術語……………………………………………………………………………………………2
4.	設計考慮………………………………………………………………………………………2
5.	通知設計描述…………………………………………………………………………………3
    5.1 小網絡設計………………………………………………………………………………3
    5.2 大型網絡設計……………………………………………………………………………4
6.	預約擴展………………………………………………………………………………………4
7.	通知所在（NotifyAt）擴展…………………………………………………………………. 5
    7.1 在收到的SrvRply消息中的NotifyAt………………………………………………….6
    7.2 接收到的多目傳送DAAdvert消息中的NotifyAt……………………………………..6
    7.3 收到的SrvAck消息中的NotifyAt……………………………………………………...6
8.	多目傳送地址分配…………………………………………………………………………….7
9.	多目傳送發送算法…………………………………………………………………………….7
10.	DA失效的情況………………………………………………………………………………..7
11.	網絡管理考慮………………………………………………………………………………….8
12.	安全考慮……………………………………………………………………………………….8
13.	IANA 考慮…………………………………………………………………………………….9
14.	鳴謝…………………………………………………………………………………………….9
15.	參考資料……………………………………………………………………………………….9
16.	作者地址……………………………………………………………………………………...10
版權聲明……………………………………………………………………………………...10
致謝…………………………………………………………………………………………...11

1．	簡介
服務定位協議（SLP）[1] 提供一種機制，使得服務代理(SA)客戶發布網絡服務通知，而
使用戶代理(UA)客戶能夠得到這些通知。這一機制是需求驅動型的。UAs（用戶代理）
只能通過主動查詢方式獲得服務信息，否則無法獲得這些信息。盡管這種設計可以滿足
大部分的應用，但還有某些應用對時間要求更高，它們要求更及時的知道相關服務是否
存在。理想情況是，當某一新服務出現或一個服務取消時，能夠馬上使應用程序得到通
知。
如果按照RFC 2608 中描述的SLP 來處理的話，要想獲得這種信息，應用程序必須經常
向網絡發輪詢信號以周期性的刷新它們緩存中的可用服務紀錄。
舉一例說明這種客戶，比如一個圖形用戶界面的桌面機，它能夠顯示網絡中標識所有服
務的圖標，每當增加了新服務時，一個新的包含所有服務的圖標的畫面能夠馬上提供給
用戶。
由于發輪詢信號既效率低下又浪費網絡及處理機資源，我們想給這些應用程序一種機制，
使得他們能夠準確及時的得到改變的通知。
在此文中，我們描述了一種可升級的機制，能夠使UAs及時的得到關于服務可用性的改
變的通知。

2．	詞匯約定解釋
此文中下列詞匯的解釋見：RFC 2119 [2]
   "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL"

3．	術語
這部分，我們提出另外一些術語，它們超出了[1]和[3]所含的范圍。
Notification （通知） —— 指一條消息，它被發送給某個相關的代理通知某服務開通或取
                        消。
    Subscription （預約）—— 指一個請求，它要求得到關于某一特定的服務類型和范圍
的服務可用性的改變情況的信息。

4．	設計考慮

    對于SLP的通知協議，我們設計上主要考慮的是希望它能同底層SLP協議一樣，具有
很強的可升級性及健壯性。此協議必須能夠工作良好，不論是在只有幾個SAs的小網絡中，
還是在包含成百上千的SAs和DAs的大型企業網中。
小型網絡不必為了能夠獲得通知而配置DAs。同樣我們也希望能夠保證在大型網絡中，
通知不會給任何的SLP代理帶來巨大的系統開銷。這就要求通知任務能夠分布式的處理而
不是集中處理，以避免出現讓某一個代理進行所有通知的任務。
最終，我們希望通知被設計得如同基本SLP的設計一樣，即使在DA失效的情況下，
也有足夠的健壯性。本協議設計上的一個重要的考慮之處是UA 客戶能及時的得到SA的通
知。
如果某一個UA預約了某個特定服務類型的通知，那么不管介入的DA的狀態如何，
UA一定能收到這個通知。SLP對支持某一特定的范圍的DAs是透明的；也就是說，一個
UA可以在一個特定的范圍使用任一DA并能夠得到同樣的服務通知。這些通知在屬性上應
該完全相同。一個UA能否收到一條通知并不依賴于它所連接的DA。這樣就保證了DAs
的身份保密。
另一個目標是通知消息包含了足夠的關于觸發事件的信息，這些觸發事件是指UA能夠
不通過改變另一個SLP要求的優先權而知道在大量的突發情況中哪些是它需要處理的。當
然，UA由于類似原因可以提交一個SLP請求，但它必須保證這個請求不能攜帶足以在大多
數情況下觸發通知的事件。這就減少了與事件相關的網絡擁塞。
為簡化起見，網絡不論大小，我們對消息的設計采用了類似的機制。當然，機制不是
完全相同的，但是我們希望這些機制不會是截然不同，那將導致需要完全不同的安裝方法。
一個最低目標是在任何地方能夠充分利用現有的SLP消息類型和機制。這就減少了需
要改動通知機制的代碼的數量，因為許多代碼可以在基本SLP和通知機制之間重復利用。
特別是，我們希望能夠充分利用SLP擴展機制于某些支持預約的情況下。

5. 通知設計描述
為了支持可升級性，我們把設計分成兩部分。一個是小型網絡設計，其中沒有DAs。
另一個是包含DAs在網絡中的大網絡設計。
下面分別描述了這兩種設計：
5.1 小網絡設計
在沒有DAs的網絡中，當SA 出現或消失時UAs都能得到通知。這就使UAs能夠知道
SA支持的服務類型。
在小型網絡中，對新出現的SAs沒有集中處理代理來執行預約。這就排除了任何種類
的預約設計，在那樣的設計中某個UA對特定興趣范圍的特定服務的通知進行預約，因為當
不存在一個集中處理代理時，新出現的SA無法區分是否有預約。因此，只要SAs能夠執行
通知，那么不管他們的范圍或服務類型如何，當他們上線或優先于關閉狀態時都會執行通知。
這就意味著某個UA能收到全部的范圍和服務類型的所有類型的改變信息的通知，接著它還
能夠濾掉那些與它無關的改變信息（其他范圍，其他服務類型）。
這一設計要求SAs通過進行IP多目發送（在IPv4中如果不支持多目發送則用廣播）SLP 
SrvReg 或 SrvDereg 消息來執行通知，多目發送算法描述見 9.0章。

用于通知的端口號不是默認的SLP端口，這個端口只對某些操作系統的特權用戶開放。IANA
規定用端口1847作為通知的端口號。
在IPv4中，SA通過SLP多目傳送地址（239.255.255.253, default TTL 255）進行多目
傳送，并與SLP有相同的執行范圍[4]。需要通知服務的 IPv4 UAs加入到多目組
239.255.255.253中并在端口1847監聽。
    在IPv6中，多目傳送由用于服務類型廣播的范圍內的IPv6地址集實現，詳細情況參考
[8]。  
SA 向它所支持的最大的多目傳送范圍的全部地址發布消息。需要通知服務的IPv6 UAs
遵從多目傳送范圍和與其相關的服務類型而加入廣播組，并在端口1847進行監聽。
例如：某個具有站點局部范圍接入權限的 IPv6 UA 對某項散列值為42的服務類型有需
求，他按照[8]中的算法計算之后，加入從FF01:0:0:0:0:0:10042到FF05:0:0:0:0:0:10042的組
中。
5.2 大型網絡設計
    
    在有DAs的大型網絡中，某個支持特定范圍的DA能夠作為執行UA預約的中介。一
個預約包含了一項服務類型及一組范圍。需要得到某一特定類型服務改變通知的UA 將預
約擴展部分附加在一個SrvRqst（服務請求） 消息中發送給DA。這里通知是基于8.0節描
述的算法得到的，而DA獲取用來發布通知的那些多目傳送組地址并把它們加入到SrvRply
（服務回應）所包含的通知擴展部分中。
UA監聽用于回應通知的那些組地址。當一個新預約產生時，現有的 SAs使用下述方
法得到預約的通知。DA對新預約和舊預約的服務類型和范圍進行比較。如果出現舊有預約
所沒有的新的類型和范圍，DA 必須使用多目發送算法（9.0節有述）多目發送一個
DAAdvert，并且必須包括帶有用于通知的多目傳送組地址的服務擴展。如果現有的預約已
經含有與新預約相同的服務類型和范圍，DA不會多目發送一個DAAdvert。
某個DA在其被界定的任何范圍內，它不僅要跟蹤它所處理的預約，也要跟蹤此范圍的
其他的DA處理的預約。為了避免多目發送多重的NotifyAt（通知所在）消息，DA在多目
發送帶有NotifyAt消息的DAAdvert前必須等待一段時間，這一時間規定為0—3秒內的均
勻分布的一個隨機數。在這一時間段內，DA必須監聽是否有匹配新預約的NotifyAt消息。
如果偵測到匹配的NotifyAt消息，DA不會進行多目發送。
當一個新的SA與一個有預約的DA發生關聯時，這個SA得到通知，它應該按照下述
步驟執行。如果新SA的SrvReg消息所包含的服務類型和范圍與已有的某個預約相匹配的
話，那么SrvAck一定會包含一個NotifyAt信息，這一信息中帶有用于通知的多目傳送地址。