rfc3082.txt

RFC中文技术文档

如果这个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。