RFC3082 服务定位协议(SLP)的预研报告

发表于 4年以前  | 总阅读数:2019 次
组织:中国互动出版网(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信息,这一信息中带有用于通知的多目传送地址。
如果这个SA不支持通知的话,它就会忽略掉这个扩展特性。如果在新SA的SrvReg中的
服务类型和范围与任何现有的预约都不匹配的话, DA不会包含一条NotifyAt消息。
当一项服务通告超时,DA自己也必须发布通知,按照多目传送算法执行。服务通告超
时导致DA要为撤销登记的URL多目传送一条SrvDereg消息。这就使得相关的UAs能够
得到服务通告已经取消的通知,即使SA没有正常注销登记而撤销。然而,当DA收到SA
发来的一条SrvReg消息时,它就不会发出通知了,因为这个工作本就是SA的。
和小型网络情况一样,通知的发布主要是由SAs执行的。如果一个SA 收到一个
DAAdvert 或带有一个NotifyAt扩展的 SrvAck并满足以下三个条件时,SA就根据它所支
持的范围和服务类型保存多目传送地址。三个条件是:
1,	SA支持通知;
2,	SA的服务类型与NotifyAt扩展中的服务类型匹配;
3,	SA的范围与NotifyAt扩展中的范围匹配。
在SA对DA发布了SrvReg 或SrvDereg消息之后,必须马上发布通知。当SA侦测到在它
的范围内的一个DA,那么它不会多目传送任何通知,除非它在一个SrvAck中收到一条
NotifyAt扩展,并且这一扩展部分的服务类型和范围与此SA的服务类型和范围匹配。
6.  预约扩展
    预约扩展格式如下:
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Extension Type = 0x0004    |        Extension Length       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Ex. Len. (ct) | Abs. Type Fl. |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    
    扩展的范围和服务类型从附带的SrvRqst中获得。抽象类型标记指示出特定UA是否关
心得到来自所有SAs的抽象类型的具体例子[3],而且仅当在SrvRqst中的服务类型是一个
具体类型时才有效。如果标志为1,UA关心来自所有 SAs通告具体类型这些类型与SrvRqst
有相同的抽象类型。如果标志为0,UA仅仅关心接收支持SrvRqst中的特定具体类型的SAs
的消息。如果在附带的SrvRqst中服务类型不是一个具体类型,此标记被忽略。

7.通知所在(NotifyAt)扩展
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Extension Type = 0x0005    |        Extension Length       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Ext. Len (ct) |  Subscription Lifetime        |SGL List Len.  \
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |SGL L. Len (ct)|       Scope/Group List                        \
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Length of Service Type Name  |        Service Type Name      \
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
服务类型名与SrvRqst中的有相同的格式。范围/组 列表是一组范围名和多目传送组地
址的列表。下列ABNF [5]缩略词描述了这个表:
        sglist          = sgitem / sgitem "," sglist
        sgitem          = scope-name ":" ip-addr
        ip-addr         = ipv4-number | ipv6-number
        scope-name      =  ; See RFC 2608 for the format of scope names.
        ipv4-number     =  1*3DIGIT 3("." 1*3DIGIT)
        ipv6-number     = ;See RFC 2373 [9] Section 2.2

IPv4中的一个范围/组列表的例子:

        eng:239.255.255.42,corp:239.255.255.43    

IPv6中的一个范围/组列表的例子:

        eng:FF02:0:0:0:0:0:1:1042,corp:FF03:0:0:0:0:0:1:1042

此列表给出了用来发布通知的多目传送地址信息,这里的通知是指包括给定范围的服务类型
的通知。

服务类型名可以是一个简单类型名,一个抽象类型名,或者一个具体类型名。
如果是一个抽象类型名,所有的发布抽象类型的SAs必须发布通知。如果是一个具体或简
单类型名,只有那些发布简单或具体类型的SAs必须发布通知,其它的不发。当某个DA收
到一个用于一个带有抽象类型标记位的具体类型的预约时,它必须在它所发出的所有
NotifyAt消息中加入抽象类型名。如果DA收到的用于具体类型的预约没有带抽象类型标记,
那它就不会在发出消息中加入抽象类型名,但它还是必须得加入此具体类型名。
出现下列三种情况时,一个代理会收到一个NotifyAt 扩展信息:
1.	在一个返回给某UA的SrvRply消息中;
2.	在一个多目传送的DAAdvert消息中;
3.	在一个返回给某SA的SrvAck消息中。

下面三小节介绍了每种情况下处理的情况:

7.1 在收到的SrvRply消息中的NotifyAt

当某个UA发出带一个预约扩展的SrvRqst消息后,DA回应一个带有NotifyAt的
SrvRply 。这种情况下,除了NotifyAt ,DA不会发送其它任何信息。另外,如果SrvRqst
消息没有带预约扩展,DA也不会发送NotifyAt消息。
UA通过设立一个多路传送监听器来回应,此监听器用来监测来自SLP通知端口1847
的扩展中的组地址。UA也可能希望记录下通过DA提交的预约的失效期,以便在失效期到
来之前重发一个预约。

7.2 接收到的多目传送DAAdvert消息中的NotifyAt 

当某个UA发出请求通知消息,而预约中存在新的范围和服务类型时,DA就利用多
目传送算法发出一条带有NotifyAt的DAAdvert消息。这个消息通知给那些没关闭的
SAs,要求他们在关闭前多目传送通知。
    如果某个参与通知的SA的服务类型和范围匹配,它会响应上面的通知并记录多目
传送地址。在它下线前,它会首先按此地址发出一个SrvDereg消息而不必先向它的DAs中
加入标签(虽然这样才符合标准SLP),此外,它还必须按照多目传送发送算法将此消息多
目传送出去。一旦预约失效期来到,SA必须停止发布通知,除非收到一条附加于预约的
NotifyAt消息,它延长了预约的失效期。
当然,某个执行被动DA侦测的UA也会收到此扩展信息,它会将其忽略。

7.3 收到的SrvAck消息中的NotifyAt

当某个SA刚刚上线并于一个DA注册时,它会收到一个带有NotifyAt的SrvAck消息。
如果DA所得到的来自UAs的预约中有由此SA提供的服务类型和范围,它必须在SrvAck
消息中带一个NotifyAt消息。

SA收到此NotifyAt消息后,它会马上按照多目传送发送算法,多目传送它回应此DA
的SrvReg消息。SA必须执行此算法而且只能执行一次,即使它注册的DA不止一个并且从
其它的DA也收到此NotifyAt消息。在此SA关闭或在某DA注销前,它必须发出SrvDereg
进行通知,详见7.2节所述。

8. 多目传送地址分配

支持SLP通知的企业网络应配置多目传送地址分配结构(MAAA),它包括管理范围内
的多目传送和多目传送地址动态客户端分配协议(MADCAP)[6]。
只要能获得一个用于SLP通知的多目传送地址,SLP多目传送地址就会被使用。
如果配置了MAAA平台,DAs和SAs就从MADCAP获得它们的范围配置,因为SLP
范围与MADCAP范围一致。每个SLP范围必须对应一个多目传送范围名,[6]中有说明。
在这种情况下,DA使用MADCAP分配地址,它按照UA预约的服务类型和范围,为每对
新的服务类型/范围分配新的多目传送组地址。针对范围的分配是由MADCAP按多目传送
地址表执行的。这样,只有那些在其提交的预约中要求此种特定服务类型和范围的UAs才
会收到这个多目传送通知。DA对多目传送地址建立租用以符合预约保持时间的要求。如果
MADCAP服务器用光了地址,SLP多目传送组就作为备份使用。
例如:如果多目传送范围的地址组是从239.1.0.0 到 239.1.255.255,那么用于表示A范围内
的服务类型X的通知组地址可以是239.1.0.42,而用于表示B范围内的服务类型Y的通知
组地址可以是239.1.42.42。

9. 多目传送发送算法

    DA 和 SA使用的多目传送发送算法类似于SLP中的发现服务使用的算法,这在RFC 
2608 [1]中有详细说明,不同之处是执行通知的代理不用等待回复。执行通知的代理每15秒
发出一条通知,在发送的时间间隔期内进行幂次补偿。这一算法的原理是限制多目传送声明
的持续时间和范围但还能保证重复传送声明多次以增加消息成功到达的几率。

    对SA来说,一条通知消息或者是SrvReg 消息,或者是SrvDereg消息,这取决于SA
是注册一个新服务还是注销一项服务。当新服务注册后,SrvReg消息必须在SLP头段设置
新位来标识。此项服务的整个属性值表要包括进来。SrvDereg 消息不会包含属性表。为了
减少多目传送阻塞,通知不是随时都可发送。
由于一个SrvReg消息可以包含任意长度的属性表,那消息可能会使UDP方式传输的
MTU包溢出。如果某个属性表能导致MTU包溢出,SA必须在SLP头里设置溢出位。通知
消息中的属性表必须符合格式,这样即使溢出发生了,UA仍可使用这些属性。如果传送给
UA的通知信息中缺少UA想要的属性,它会向DA或SA(如果此时无DA可用)申请发
送这些属性。
当DA收到一条预约,它发现其中所含服务类型和范围无法与已知的预约中的任何一个
匹配,它就多目传送一条DAAdvert消息。一定要使用相同的算法。如果DA的属性和NotifyAt
消息的组合使得DAAdvert溢出UDP包的范围,DA属性值必须截短以满足的NotifyAt需要,
同时头中的溢出位要进行设置。由于NotifyAt扩展的存在,SA知道此消息的目的是通知它
有一个新预约而不仅仅是一个被动的通告,这样它就可以根据设在头中的溢出位来忽略DA
的属性列表域。当一项服务通告由于超时而被注销时,DA也要发送一条SrvDereg消息,同
SA规则一样。

10	DA失效的情况

本设计的一个重要目标是要保证在DA失效时的健壮性。当DA由于不可预料的情况失
效时,来自UA的预约消息丢失。UAs 继续从现有的SAs 获得通知。然而,除非其它DAs
还有这个预约消息,新的SAs不会得到此预约。因为一个UA可能无法发现一个新DA,除
非它发出主动请求,因此UA可能会错过得到新服务的通知。解决方法时,关心收到所有已
有服务的通知的UAs要向每一个新出现的DA提交预约,当然要求此DA支持的范围与这
些UA一致。类似地,如果某个DA由于正常关闭而消失,UA会通过其被动发现机制侦测
到并重新提交预约给另一个DA。

对SA来说,当某个DA离线时,现有的SAs继续发出通知直到预约过期失效。在停止
通知前,SA必须判断DA是否还可用,如果不可用了,将与另一个DA校验预约是否已经
被延时了。如此时没有DA,SA必须忽略预约失效时间而继续发送通知直到出现新的DA。
当新DA出现时,SA必须按RFC 2608 [1],给DA发送一个新SrvReg消息。如果UA通过
DA已经更新了它的预约,则回应的SrvAck包含了一个NotifyAt扩展。如果SrvAck没有包
含一个NotifyAt扩展,SA必须继续发通知直到预约过期失效。如果UA希望继续获得通知,
它就在原有预约超时前通过新DA更新预约,这样SA就得到通知,会继续发通知。
    
请注意这一步骤中还存在一段时间间隔使得SAs不能得到消息,就是在新DA启动过
程的时间与UA通过此新DA已经更新的预约时间的间隔中。考虑到这种情况,冗余
DAs就是非常必要的,以保证当一个DA离线时所有的预约还在控制范围内。

11.  网络管理考虑

在RFC 2608中对使用DAs的SLP网络规定,唯一的多目传送是SrvRqst,它用来指示
在主动发现DA方式下执行的DAAdverts消息,对于被动发现方式而言,DA周期性的发送
主动提供的DAAdverts消息。在UA提交查询或SA注册时不涉及多目传送。这就允许网络
管理员设立一些DAs用于一组特定的IP子网,并且可以限制所有的服务发现流量在SA和
UA客户端以及DA之间传送。
管理范围内的多目传送还能够用来限制主动发现DA方式以及被动DA通告的范围。多
目传送消息的数量受到限制,不会过高,而DHCP DA和范围配置可用来限制某个特定的
UA或SA客户端可见的DAs数量,也可用来限制整个多目传送,以使得UAs和SAs只能
使用配置好的DAs。
然而通知也会带来大量的与SAs的事件相关的多目传送流量。因为DAs要求的多目传
送地址是基于范围和服务类型,与特定事件相关的多目传送事件应该被限制为只能发送给有
相同范围的UAs和SAs的子网中。因此应该配置相应的用于多目传送范围管理的路由器以
限制多目传送流量。如果没配置DAs(或没配置MAAA),那么当通知接收并被使用时按
SLP多目传送地址进行的多目传送的数量就非常大了。

12. 安全考虑

    SrvReg 和 SrvDereg 消息包含了用于所有由DAs支持的SLP SPIs的认证块,SA是通
过这些SPIs在DAs上注册的。由于这些SPIs与UAs能校验的SPIs相同,UA就必须在接
收一个多目传送通知时进行校验。方法是UA辨认出认证块或者它能够校验的块以进行校
验。如果由于缺少认证块,或缺少正确的SPI导致认证失败,UA就扔掉这条通知。在没有
DAs的网络中,UA和SA的SPI也要匹配。

13. IANA 考虑
     
SLP 通知服务使用IANA分配的端口号:1847。IANA分配的SLP扩展的标识符是:
0x0004 用于预约, 0x0005 用于 NotifyAt。

14. 鸣谢

首先感谢Nokia 公司的Charles Perkins以及 Sun Microsystems 公司的Erik Guttman and 
Jonathan Wood, 感谢他们在预约/通知模型设计的初期阶段的积极参与和建议。
还要感谢Erik,在规范制订的后期,它进行了周密的审核工作。它的建议在设计的改进
中具有重要的指导意义。还有HP公司的Shivaun Albright, 对简化协议使之仅仅集中关注于
初始化注册及注销作了重要工作。Vaishali Mithbaokar 实现了简化后的协议。

15. 参考资料

   [1] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service
       Location Protocol", RFC 2608, July 1999.

   [2] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement
       Levels", BCP 14, RFC 2119, March 1997.

   [3] Guttman, E., Perkins, C. and J. Kempf, "Service Templates and
       service: Schemes", RFC 2609, July 1999.

   [4] Meyer, D., "Administratively Scoped IP Multicast", RFC 2365, July
       1998.

   [5] Crocker, D. and P. Overell, "Augmented BNF for Syntax
       Specifications: ABNF", RFC 2234, November 1997.

   [6] Hanna, S., Patel,B. and M. Shah, "Multicast Address Dynamic
       Client Allocation Protocol (MADCAP)", RFC 2730, December 1999.

   [7] http://www.isi.edu/in-notes/iana/assignments/multicast-addresses

   
   [8] Guttman, E., "Service Location Protocol Modifications for IPv6",
       Work in Progress.

   [9] Hinden, R. and S. Deering, "IP Version 6 Addressing
       Architecture", RFC 2375, July 1997.

16. 作者地址

   James Kempf
   Sun Microsystems
   UMPK15-214
   901 San Antonio Rd.
   Palo Alto, CA 94040
   USA

   Phone:    +1 650 786 5890
   EMail:    james.kempf@sun.com

   Jason Goldschmidt
   Sun Microsystems
   UMPK17-202
   901 San Antonio Rd.
   Palo Alto, CA 94040
   USA

   Phone: +1 650 786 3502
   EMail: jason.goldschmidt@sun.com

版权声明
   Copyright (C) The Internet Society (2001).  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.

致谢

   感谢Internet Society 近来对RFC编辑提供的资助.




[ Index | Search | What's New | Comments | Help ] 
Comments/Questions about this archive ? Send mail to rfc-admin@faqs.org
                                                                           
                                                                           
                                                                             
                     
                           
                               
                                    
                                        
                                              
                                                   
                                                        
                                                             
                                                                    
                                                                            
RFC3082――Notification and Subscription for SLP    服务定位协议(SLP)的预研报告
1

1
RFC文档中文翻译计划
 相关推荐

刘强东夫妇:“移民美国”传言被驳斥

京东创始人刘强东和其妻子章泽天最近成为了互联网舆论关注的焦点。有关他们“移民美国”和在美国购买豪宅的传言在互联网上广泛传播。然而,京东官方通过微博发言人发布的消息澄清了这些传言,称这些言论纯属虚假信息和蓄意捏造。

发布于:6月以前  |  808次阅读  |  详细内容 »

博主曝三大运营商,将集体采购百万台华为Mate60系列

日前,据博主“@超能数码君老周”爆料,国内三大运营商中国移动、中国电信和中国联通预计将集体采购百万台规模的华为Mate60系列手机。

发布于:6月以前  |  770次阅读  |  详细内容 »

ASML CEO警告:出口管制不是可行做法,不要“逼迫中国大陆创新”

据报道,荷兰半导体设备公司ASML正看到美国对华遏制政策的负面影响。阿斯麦(ASML)CEO彼得·温宁克在一档电视节目中分享了他对中国大陆问题以及该公司面临的出口管制和保护主义的看法。彼得曾在多个场合表达了他对出口管制以及中荷经济关系的担忧。

发布于:6月以前  |  756次阅读  |  详细内容 »

抖音中长视频App青桃更名抖音精选,字节再发力对抗B站

今年早些时候,抖音悄然上线了一款名为“青桃”的 App,Slogan 为“看见你的热爱”,根据应用介绍可知,“青桃”是一个属于年轻人的兴趣知识视频平台,由抖音官方出品的中长视频关联版本,整体风格有些类似B站。

发布于:6月以前  |  648次阅读  |  详细内容 »

威马CDO:中国每百户家庭仅17户有车

日前,威马汽车首席数据官梅松林转发了一份“世界各国地区拥车率排行榜”,同时,他发文表示:中国汽车普及率低于非洲国家尼日利亚,每百户家庭仅17户有车。意大利世界排名第一,每十户中九户有车。

发布于:6月以前  |  589次阅读  |  详细内容 »

研究发现维生素 C 等抗氧化剂会刺激癌症生长和转移

近日,一项新的研究发现,维生素 C 和 E 等抗氧化剂会激活一种机制,刺激癌症肿瘤中新血管的生长,帮助它们生长和扩散。

发布于:6月以前  |  449次阅读  |  详细内容 »

苹果据称正引入3D打印技术,用以生产智能手表的钢质底盘

据媒体援引消息人士报道,苹果公司正在测试使用3D打印技术来生产其智能手表的钢质底盘。消息传出后,3D系统一度大涨超10%,不过截至周三收盘,该股涨幅回落至2%以内。

发布于:7月以前  |  446次阅读  |  详细内容 »

千万级抖音网红秀才账号被封禁

9月2日,坐拥千万粉丝的网红主播“秀才”账号被封禁,在社交媒体平台上引发热议。平台相关负责人表示,“秀才”账号违反平台相关规定,已封禁。据知情人士透露,秀才近期被举报存在违法行为,这可能是他被封禁的部分原因。据悉,“秀才”年龄39岁,是安徽省亳州市蒙城县人,抖音网红,粉丝数量超1200万。他曾被称为“中老年...

发布于:6月以前  |  445次阅读  |  详细内容 »

亚马逊股东起诉公司和贝索斯,称其在购买卫星发射服务时忽视了 SpaceX

9月3日消息,亚马逊的一些股东,包括持有该公司股票的一家养老基金,日前对亚马逊、其创始人贝索斯和其董事会提起诉讼,指控他们在为 Project Kuiper 卫星星座项目购买发射服务时“违反了信义义务”。

发布于:6月以前  |  444次阅读  |  详细内容 »

苹果上线AppsbyApple网站,以推广自家应用程序

据消息,为推广自家应用,苹果现推出了一个名为“Apps by Apple”的网站,展示了苹果为旗下产品(如 iPhone、iPad、Apple Watch、Mac 和 Apple TV)开发的各种应用程序。

发布于:6月以前  |  442次阅读  |  详细内容 »

特斯拉美国降价引发投资者不满:“这是短期麻醉剂”

特斯拉本周在美国大幅下调Model S和X售价,引发了该公司一些最坚定支持者的不满。知名特斯拉多头、未来基金(Future Fund)管理合伙人加里·布莱克发帖称,降价是一种“短期麻醉剂”,会让潜在客户等待进一步降价。

发布于:6月以前  |  441次阅读  |  详细内容 »

光刻机巨头阿斯麦:拿到许可,继续对华出口

据外媒9月2日报道,荷兰半导体设备制造商阿斯麦称,尽管荷兰政府颁布的半导体设备出口管制新规9月正式生效,但该公司已获得在2023年底以前向中国运送受限制芯片制造机器的许可。

发布于:6月以前  |  437次阅读  |  详细内容 »

马斯克与库克首次隔空合作:为苹果提供卫星服务

近日,根据美国证券交易委员会的文件显示,苹果卫星服务提供商 Globalstar 近期向马斯克旗下的 SpaceX 支付 6400 万美元(约 4.65 亿元人民币)。用于在 2023-2025 年期间,发射卫星,进一步扩展苹果 iPhone 系列的 SOS 卫星服务。

发布于:6月以前  |  430次阅读  |  详细内容 »

𝕏(推特)调整隐私政策,可拿用户发布的信息训练 AI 模型

据报道,马斯克旗下社交平台𝕏(推特)日前调整了隐私政策,允许 𝕏 使用用户发布的信息来训练其人工智能(AI)模型。新的隐私政策将于 9 月 29 日生效。新政策规定,𝕏可能会使用所收集到的平台信息和公开可用的信息,来帮助训练 𝕏 的机器学习或人工智能模型。

发布于:6月以前  |  428次阅读  |  详细内容 »

荣耀CEO谈华为手机回归:替老同事们高兴,对行业也是好事

9月2日,荣耀CEO赵明在采访中谈及华为手机回归时表示,替老同事们高兴,觉得手机行业,由于华为的回归,让竞争充满了更多的可能性和更多的魅力,对行业来说也是件好事。

发布于:6月以前  |  423次阅读  |  详细内容 »

AI操控无人机能力超越人类冠军

《自然》30日发表的一篇论文报道了一个名为Swift的人工智能(AI)系统,该系统驾驶无人机的能力可在真实世界中一对一冠军赛里战胜人类对手。

发布于:7月以前  |  423次阅读  |  详细内容 »

AI生成的蘑菇科普书存在可致命错误

近日,非营利组织纽约真菌学会(NYMS)发出警告,表示亚马逊为代表的电商平台上,充斥着各种AI生成的蘑菇觅食科普书籍,其中存在诸多错误。

发布于:7月以前  |  420次阅读  |  详细内容 »

社交媒体平台𝕏计划收集用户生物识别数据与工作教育经历

社交媒体平台𝕏(原推特)新隐私政策提到:“在您同意的情况下,我们可能出于安全、安保和身份识别目的收集和使用您的生物识别信息。”

发布于:7月以前  |  411次阅读  |  详细内容 »

国产扫地机器人热销欧洲,国产割草机器人抢占欧洲草坪

2023年德国柏林消费电子展上,各大企业都带来了最新的理念和产品,而高端化、本土化的中国产品正在不断吸引欧洲等国际市场的目光。

发布于:6月以前  |  406次阅读  |  详细内容 »

罗永浩吐槽iPhone15和14不会有区别,除了序列号变了

罗永浩日前在直播中吐槽苹果即将推出的 iPhone 新品,具体内容为:“以我对我‘子公司’的了解,我认为 iPhone 15 跟 iPhone 14 不会有什么区别的,除了序(列)号变了,这个‘不要脸’的东西,这个‘臭厨子’。

发布于:6月以前  |  398次阅读  |  详细内容 »