rfc3082.txt

RFC中文技术文档

对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:    [phone]
   EMail:    [e-mail]

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

   Phone: [phone]
   EMail: [e-mail]

版权声明
   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 [e-mail]
                                                                           
                                                                           
                                                                             
                     
                           
                               
                                    
                                        
                                              
                                                   
                                                        
                                                             
                                                                    
                                                                            
RFC3082——Notification and Subscription for SLP    服务定位协议（SLP）的预研报告
1

1
RFC文档中文翻译计划