rfc3082.txt

RFC中文技术文档

组织：中国互动出版网（http://www.china-pub.com/）
RFC文档中文翻译计划（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：[e-mail]
译者：lv_xinyang (lv_xinyang  [e-mail])
译文发布时间：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信息，这一信息中带有用于通知的多目传送地址。