Network Working Group J. Kempf
Request for Comments: 3082 J. Goldschmidt
Category: Experimental Sun Microsystems
March 2001
Network Working Group J. Kempf
Request for Comments: 3082 J. Goldschmidt
Category: Experimental Sun Microsystems
March 2001
Notification and Subscription for SLP
SLP的通知和订阅
Status of this Memo
本备忘录的状况
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
这份备忘录为互联网社区定义了一个实验性协议。它没有规定任何类型的互联网标准。要求进行讨论并提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
Abstract
摘要
The Service Location Protocol (SLP) provides mechanisms whereby service agent clients can advertise and user agent clients can query for services. The design is very much demand-driven, so that user agents only obtain service information when they specifically ask for it. There exists another class of user agent applications, however, that requires notification when a new service appears or disappears. In the RFC 2608 design, these applications are forced to poll the network to catch changes. In this document, we describe a protocol for allowing such clients to be notified when a change occurs, removing the need for polling.
服务位置协议（SLP）提供了服务代理客户端可以播发和用户代理客户端可以查询服务的机制。该设计非常受需求驱动，因此用户代理仅在特别要求时才能获取服务信息。但是，存在另一类用户代理应用程序，当新服务出现或消失时需要通知。在RFC2608设计中，这些应用程序被迫轮询网络以捕获更改。在本文档中，我们描述了一种协议，允许在发生更改时通知此类客户机，从而消除了轮询的需要。
The Service Location Protocol (SLP) [1] provides a mechanism for service agent (SA) clients to advertise network services and for user agent (UA) clients to find them. The mechanism is demand-driven. UAs obtain service information by actively querying for it, and do not obtain any information unless they do so. While this design satisfies the requirements for most applications, there are some applications that require more timely information about the appearance or disappearance in the services of interest.
服务位置协议（SLP）[1]为服务代理（SA）客户端提供了一种公布网络服务的机制，并为用户代理（UA）客户端提供了查找网络服务的机制。这一机制是由需求驱动的。UAs通过主动查询服务信息来获取服务信息，除非他们这样做，否则不会获取任何信息。虽然此设计满足大多数应用程序的要求，但有些应用程序需要更及时地了解感兴趣的服务中出现或消失的信息。
Ideally, these applications would like to be notified when a new service comes up or when a service disappears. In order to obtain this information with SLP as described in RFC 2608, such applications must poll the network to periodically refresh their local cache of available service advertisements.
理想情况下，这些应用程序希望在出现新服务或服务消失时收到通知。如RFC 2608所述，为了通过SLP获得此信息，此类应用程序必须轮询网络以定期刷新其可用服务广告的本地缓存。
An example of such a client is a desktop GUI that wants to display network service icons as soon as they appear to provide users with an accurate picture of all services available to them.
这种客户端的一个例子是桌面GUI，它希望在网络服务图标出现时立即显示这些图标，以便向用户提供所有可用服务的准确图片。
Because polling is inefficient and wasteful of network and processor resources, we would like to provide these applications a mechanism whereby they can be explicitly notified of changes. In this document, we describe a scalable mechanism allowing UAs to be notified of changes in service availability.
由于轮询效率低下且浪费网络和处理器资源，因此我们希望为这些应用程序提供一种机制，使它们能够明确地收到更改通知。在本文档中，我们描述了一种可扩展的机制，该机制允许向UAs通知服务可用性的变化。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[2]中所述进行解释。
In this section, we present some additional terminology beyond that in [1] and [3].
在本节中，除了[1]和[3]中的术语外，我们还介绍了一些其他术语。
Notification - A message sent to an interested agent informing that agent that a service has appeared or disappeared.
通知-发送给感兴趣的代理的消息，通知该代理某项服务已出现或消失。
Subscription - A request to be informed about changes in service availability for a particular service type and scopes.
订阅-请求通知特定服务类型和范围的服务可用性的更改。
The primary design consideration in a notification protocol for SLP is that we would like it to exhibit the same high degree of scalability and robustness that the base SLP protocol exhibits. Notification should work in small networks with only a few SAs, as well as large enterprise networks with thousands of SAs and hundreds of DAs. Small networks should not be required to deploy DAs in order to receive the benefits of notification. We also want to assure that notification in large networks does not cause heavy processing loads to fall on any one particular SLP agent. This requires that the task of notification be distributed rather than centralized, to avoid loading down one agent with doing all the notification work. Finally, we would like the notification scheme to be robust in the face of DA failures, just as the base SLP design is.
SLP通知协议的主要设计考虑因素是，我们希望它表现出与基本SLP协议相同的高度可伸缩性和健壮性。通知应适用于只有少量SA的小型网络，以及具有数千个SA和数百个DA的大型企业网络。不应要求小型网络部署DAs以获得通知的好处。我们还希望确保大型网络中的通知不会导致任何特定SLP代理承担繁重的处理负载。这要求通知任务是分布式的，而不是集中式的，以避免在执行所有通知工作时加载一个代理。最后，我们希望通知方案在DA失败时具有健壮性，就像基本SLP设计一样。
An important consideration is that the UA clients obtain notifications of SA events in a timely fashion. If a UA has subscribed to notification for a particular service type, the UA should receive such notification regardless of the state of intervening DAs. SLP is transparent with respect to DAs supporting a
一个重要的考虑因素是UA客户端及时获得SA事件的通知。如果UA已订阅特定服务类型的通知，则UA应收到此类通知，而不管介入DAs的状态如何。SLP对于支持a的DAs是透明的
particular scope; that is, a UA can use any DA with a particular scope and expect to get the same service advertisements. Notifications should exhibit the same property. Whether or not a UA receives a notification should not depend on the DA to which they happen to connect. This preserves the DAs' identity as a pure cache.
特定范围；也就是说，UA可以使用具有特定范围的任何DA，并期望获得相同的服务广告。通知应显示相同的属性。UA是否收到通知不应取决于其连接的DA。这将保留DAs作为纯缓存的身份。
Another goal is that the notification messages contain enough information about the triggering event that the UA can determine whether or not it is of interest in the large majority of cases without having to issue another SLP request a priori. The UA may, of course, issue an SLP request for related reasons, but it should not have to issue a request to obtain more information on the event that triggered the notification in most cases. This reduces the amount of network traffic related to the event.
另一个目标是，通知消息包含关于触发事件的足够信息，UA可以确定它在大多数情况下是否感兴趣，而无需事先发出另一个SLP请求。当然，UA可能会出于相关原因发出SLP请求，但在大多数情况下，不必发出请求以获取触发通知的事件的更多信息。这会减少与事件相关的网络通信量。
In order to simplify implementation, we would like to use similar mechanisms for notification in large and small networks. The mechanisms are not identical, obviously, but we want to avoid having radically different mechanisms that require completely separate implementations. Having similar mechanisms reduces the amount of code in UA and SA clients.
为了简化实现，我们希望在大型和小型网络中使用类似的通知机制。显然，这些机制并不完全相同，但我们希望避免使用完全不同的机制，这些机制需要完全独立的实现。拥有类似的机制可以减少UA和SA客户端中的代码量。
A minor goal is to make use of existing SLP message types and mechanisms wherever possible. This reduces the amount of code necessary to implement the notification mechanism, because much code can be reused between the base SLP and the notification mechanism. In particular, we expect to make use of the SLP extension mechanism in certain cases to support subscription.
次要目标是尽可能利用现有的SLP消息类型和机制。这减少了实现通知机制所需的代码量，因为许多代码可以在基本SLP和通知机制之间重用。特别是，我们希望在某些情况下使用SLP扩展机制来支持订阅。
In order to support scalability, we split the design into two parts. A small network design is used when no DAs are present in the network. A large network design is used in networks with DAs. The following subsections describe the two designs.
为了支持可伸缩性，我们将设计分为两部分。当网络中不存在DAs时，使用小型网络设计。在带有DAs的网络中使用大型网络设计。以下小节描述了这两种设计。
In networks without DAs, UAs are notified by an SA when the SA initially appears, and when the SA disappears. This allows UAs to know about the list of service types the SA supports. In small networks, there is no centralized agent available to administer subscriptions for newly appearing SAs. This rules out any kind of subscription design in which a UA subscribes to notifications for a particular service type in particular scopes of interest, because a newly appearing SA can't tell whether or not there are any subscriptions without a centralizing agent to tell it.
在没有DAs的网络中，SA在SA最初出现和SA消失时会通知UAs。这允许UAs了解SA支持的服务类型列表。在小型网络中，没有可用于管理新出现的SA订阅的集中式代理。这排除了UA订阅特定感兴趣范围内特定服务类型的通知的任何订阅设计，因为新出现的SA在没有集中代理通知的情况下无法判断是否存在任何订阅。
As a result, SAs perform notification when they come on line and prior to shutting down regardless of their scope or service type, if they are capable of performing notification. This means that a UA receives notification of all types of changes for all scopes and service types, and consequently must be prepared to filter out those changes in which it is not interested (other scopes, other service types).
因此，如果SA能够执行通知，则无论其作用域或服务类型如何，SA在上线时和关机前都会执行通知。这意味着UA收到所有范围和服务类型的所有类型更改的通知，因此必须准备好过滤掉它不感兴趣的更改（其他范围、其他服务类型）。
The design requires SAs to perform notification by IP multicasting (or broadcasting in IPv4 if multicast is not available) SLP SrvReg or SrvDereg messages using the multicast transmit algorithm described in Section 9.0. The port number for notifications is not the default SLP port, because that port is only accessible to privileged users on some operating systems, but rather the port 1847, as assigned by IANA.
该设计要求SAs使用第9.0节中描述的多播传输算法，通过IP多播（或在IPv4中广播，如果多播不可用）SLP SrvReg或SrvDereg消息执行通知。通知的端口号不是默认的SLP端口，因为只有某些操作系统上的特权用户才能访问该端口，而是IANA分配的端口1847。
In IPv4, the SA performs multicast on the SLP multicast address (239.255.255.253, default TTL 255) and is administratively scoped in the same manner as SLP [4]. IPv4 UAs interested in notification join the multicast group 239.255.255.253 and listen on port 1847. In IPv6, the multicast is performed to the scoped IPv6 addresses for the service type advertised, as described in [8]. The SA advertises on all addresses up to and including the largest multicast scope that it supports. IPv6 UAs interested in notification join the multicast groups corresponding to the multicast scopes and service type in which they are interested and listen on port 1847. For example, an IPv6 UA that has access to site local scope and is interested in a service type whose hash is 42, calculated according to the algorithm in [8], joins the groups FF01:0:0:0:0:0:10042 through FF05:0:0:0:0:0:10042.
在IPv4中，SA在SLP多播地址（239.255.255.253，默认TTL 255）上执行多播，并以与SLP相同的方式管理范围[4]。对通知感兴趣的IPv4 UAs加入多播组239.255.255.253并在端口1847上侦听。在IPv6中，对播发的服务类型的作用域IPv6地址执行多播，如[8]中所述。SA在其支持的最大多播范围内的所有地址上发布广告。对通知感兴趣的IPv6 UA加入与其感兴趣的多播作用域和服务类型对应的多播组，并在端口1847上侦听。例如，可以访问站点本地作用域并对哈希为42的服务类型感兴趣（根据[8]中的算法计算）的IPv6 UA加入组FF01:0:0:0:0:10042到FF05:0:0:0:0:0:0:10042。
In networks with DAs, a DA supporting a particular scope can act as an intermediary for administering UA subscriptions. A subscription consists of a service type and a collection of scopes. A UA interested in being notified about changes in a particular service type attaches the Subscribe extension to a SrvRqst message sent to the DA. The DA obtains multicast group addresses for notification based on the algorithm described in Section 8.0 and puts them into a NotifyAt extension which it attaches to the SrvRply. The UA listens on the group addresses in the reply for notifications.
在具有DAs的网络中，支持特定作用域的DA可以充当管理UA订阅的中介。订阅由服务类型和作用域集合组成。对特定服务类型的更改感兴趣的UA将订阅扩展附加到发送给DA的SrvRqst消息。DA根据第8.0节中描述的算法获取用于通知的多播组地址，并将其放入NotifyAt扩展中，该扩展连接到SrvRply。UA监听应答中的组地址以获取通知。
When a new subscription comes in, existing SAs are informed about the subscription using the following procedure. The DA compares the service type and scopes in the new subscription against a list of existing subscriptions. If no previous subscription has the same service type and scopes, the DA MUST multicast a DAAdvert, using the
当收到新订阅时，将使用以下过程通知现有SA有关订阅的信息。DA将新订阅中的服务类型和作用域与现有订阅列表进行比较。如果以前没有订阅具有相同的服务类型和作用域，DA必须使用
multicast transmit algorithm described in Section 9.0, and MUST include the NotifyAt extension with the multicast group addresses for notification. If an existing subscription covers the same service type and scopes as the new subscription, the DA MUST NOT multicast a DAAdvert.
第9.0节中描述的多播传输算法，必须包括NotifyAt扩展和多播组地址，以便进行通知。如果现有订阅包含与新订阅相同的服务类型和作用域，DA不得多播DAAD。
A DA MUST keep track of subscriptions it has arranged as well as subscriptions arranged by other DAs in any scopes with which the DA is configured. To avoid multiple multicast NotifyAt messages, a DA MUST wait a random amount of time, uniformly distributed between 0 and 3 seconds before sending the multicast DAAdvert with NotifyAt. During this period, the DA MUST listen for NotifyAt messages that match the one from the new subscription. If a matching NotifyAt is detected, the DA MUST not multicast.
DA必须跟踪其已安排的订阅以及其他DA在配置DA的任何作用域中安排的订阅。为了避免多个多播NotifyAt消息，DA必须等待一段随机时间（均匀分布在0到3秒之间），然后才能使用NotifyAt发送多播DAAD。在此期间，DA必须侦听与新订阅中的NotifyAt消息匹配的NotifyAt消息。如果检测到匹配的NotifyAt，DA不得多播。
When a new SA registers with a DA that has existing subscriptions, the new SA is informed of notifications it should perform using the following procedure. If the service type and scopes in the new SA's SrvReg messages match an existing subscription, a NotifyAt containing the multicast addresses for notification MUST be included in the SrvAck. If the SA doesn't support notification, it simply ignores the extension. If the service type and scopes in the new SA's SrvReg do not match any existing subscriptions, the DA MUST NOT include a NotifyAt.
当新SA向具有现有订阅的DA注册时，将使用以下过程通知新SA其应执行的通知。如果新SA的SrvReg消息中的服务类型和作用域与现有订阅匹配，则必须在SrvAck中包含包含多播通知地址的NotifyAt。如果SA不支持通知，它将忽略扩展。如果新SA的SrvReg中的服务类型和作用域与任何现有订阅不匹配，DA不得包含NotifyAt。
The DA itself MUST also perform notification, according to the multicast transmit algorithm, when a service advertisement times out. Time-out of a service advertisement results in the DA multicasting a SrvDereg for the deregistered URL. This allows interested UAs to be informed of the service advertisement's demise even if the SA has disappeared without deregistering. A DA MUST NOT perform notification when it receives a SrvReg from an SA, however, that is the job of the SA.
当服务广告超时时，DA本身还必须根据多播传输算法执行通知。服务广告超时会导致DA为注销的URL多播SrvDereg。这样，即使SA在未注销的情况下消失，也可以将服务广告的终止通知有兴趣的UAs。DA从SA收到SrvReg时不得执行通知，但这是SA的工作。
As in small networks, notification is performed primarily by SAs. If an SA receives a DAAdvert or SrvAck with a NotifyAt extension and the following conditions are met:
在小型网络中，通知主要由SAs执行。如果SA接收到带有NotifyAt扩展名的DAAD或SrvAck，并且满足以下条件：
1. The SA supports notification.
1. SA支持通知。
2. The SA's service type matches the service type in the NotifyAt extension.
2. SA的服务类型与NotifyAt扩展中的服务类型匹配。
3. The SA's scopes match one of the scopes of the NotifyAt extension.
3. SA的作用域与NotifyAt扩展的一个作用域匹配。
then the SA saves the multicast addresses that correspond to the scopes and service types it supports. The SA MUST perform notification immediately after the SA has performed the SrvReg or SrvDereg with the DA. An SA that has detected a DA in its scopes MUST NOT multicast any notifications unless it receives a NotifyAt extension in a SrvAck with service type and scopes matching the SA's service type and scopes.
然后SA保存与其支持的作用域和服务类型相对应的多播地址。SA必须在SA与DA执行SrvReg或SrvDereg后立即执行通知。在其作用域中检测到DA的SA不得多播任何通知，除非它在SrvAck中接收到服务类型和作用域与SA的服务类型和作用域匹配的NotifyAt扩展。
The Subscribe extension has the following format:
订阅扩展具有以下格式：
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. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The scope list and service type of the extension are taken from the accompanying SrvRqst. The abstract type flag indicates whether the UA is interested in hearing from all SAs advertising concrete instances of an abstract type [3], and is only of interest if the service type in the SrvRqst is a concrete type. If the flag is 1, the UA is interested in hearing from all SAs advertising concrete types having the same abstract type as the type of the SrvRqst. If the flag is 0, the UA is only interested in hearing from SAs supporting the particular concrete type in the SrvRqst. If the service type in the accompanying SrvRqst is not a concrete type, the flag is ignored.
扩展的范围列表和服务类型取自随附的SrvRqst。abstract type（抽象类型）标志表示UA是否有兴趣听取所有SA广告抽象类型的具体实例[3]，并且仅当SrvRqst中的服务类型是具体类型时才有兴趣。如果标志为1，UA希望听到所有SA广告的具体类型与SrvRqst类型具有相同的抽象类型。如果标志为0，UA只感兴趣听取支持SrvRqst中特定混凝土类型的SA的意见。如果附带的SrvRqst中的服务类型不是具体类型，则忽略该标志。
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 \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The service type name is in the same format as in the SrvRqst. The scope/group list is a list of scope names and multicast group addresses. The following ABNF [5] syntax describes the list:
服务类型名称的格式与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
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
An example of a scope/group list for IPv4 is:
IPv4的作用域/组列表示例如下：
eng:239.255.255.42,corp:239.255.255.43
英语：239.255.255.42，公司：239.255.255.43
An example of a scope/group listfor IPv6 is:
IPv6的作用域/组列表示例如下：
eng:FF02:0:0:0:0:0:1:1042,corp:FF03:0:0:0:0:0:1:1042
eng:FF02:0:0:0:0:0:1:1042,corp:FF03:0:0:0:0:0:1:1042
The scope/group list gives the multicast addresses to use for notifications involving the service type for the given scopes.
作用域/组列表提供用于通知的多播地址，这些通知涉及给定作用域的服务类型。
The service type name can be a simple type name, an abstract type name, or a concrete type name. If the name is an abstract type name, all SAs advertising the abstract type MUST notify. If the name is a concrete or simple type name, ONLY those SAs advertising the simple or concrete type MUST notify, others MUST NOT notify. A DA that receives a subscription for a concrete type with the abstract type flag set, MUST include the abstract type name in all the NotifyAt messages it sends. If the DA receives a subscription for a concrete type with the abstract type flag not set, the DA MUST NOT include the abstract type, but rather MUST include the concrete type name.
服务类型名称可以是简单类型名称、抽象类型名称或具体类型名称。如果名称是抽象类型名称，则所有宣传该抽象类型的SA都必须通知。如果名称是具体或简单类型名称，则只有宣传简单或具体类型的SA必须通知，其他SA不得通知。接收设置了抽象类型标志的具体类型订阅的DA必须在其发送的所有NotifyAt消息中包含抽象类型名称。如果DA收到未设置抽象类型标志的具体类型订阅，DA不得包含抽象类型，而必须包含具体类型名称。
There are three cases in which an agent may receive a NotifyAt extension: in a SrvRply returned to a UA, in a multicast DAAdvert, and in a SrvAck returned to an SA. The three subsections below describe the response in each of these cases.
有三种情况下，代理可以接收NotifyAt扩展：在返回给UA的SrvRply中，在多播DAAD中，以及在返回给SA的SrvAck中。以下三个小节描述了每种情况下的响应。
When a UA sends a SrvRqst with a Subscribe extension, the DA responds with a SrvRply including a NotifyAt. The DA MUST NOT unicast a NotifyAt to a UA with any other message and MUST NOT send a NotifyAt unless a SrvRqst with a Subscribe extension was received.
当UA发送带有Subscribe扩展名的SrvRqst时，DA将使用包含NotifyAt的SrvRply进行响应。DA不得将NotifyAt与任何其他消息单播给UA，并且不得发送NotifyAt，除非收到具有Subscribe扩展名的SrvRqst。
The UA responds by setting up a multicast listener to the group addresses included in the extension on the SLP notification port 1847. The UA MAY also want to note the expiration lifetime of the
UA通过在SLP通知端口1847上的扩展中包括的组地址设置多播侦听器来响应。UA可能还需要注意
subscription assigned by the DA, and reissue a subscription before the lifetime expires.
由DA分配的订阅，并在生存期到期之前重新发布订阅。
The DA multicasts a NotifyAt with a DAAdvert using the multicast transmit algorithm when a UA has requested notification and the scopes and service type in the subscription were not previously seen. This message informs existing SAs having the service type and scopes in the announcement that they should multicast notifications when they shut down.
当UA已请求通知且订阅中的作用域和服务类型之前未被看到时，DA使用多播传输算法将NotifyAt与DAAD多播。此消息通知在公告中具有服务类型和作用域的现有SA，它们应该在关闭时多播通知。
A receiving SA participating in notification responds by noting the multicast address if the service type and scopes match. When the SA is about to go down, the SA MUST first unicast a SrvDereg without attribute tag list to its DAs (as per standard SLP), then it MUST multicast the same SrvDereg message according to the multicast transmit algorithm. The SA MUST cease performing notification when the subscription lifetime expires, unless a subsequent NotifyAt is received prolonging the subscription.
如果服务类型和作用域匹配，则参与通知的接收SA通过记录多播地址进行响应。当SA即将下降时，SA必须首先单播一个没有属性标记列表的SrvDereg到其DAs（根据标准SLP），然后必须根据多播传输算法多播相同的SrvDereg消息。SA必须在订阅生存期到期时停止执行通知，除非收到延长订阅的后续NotifyAt。
A UA that is performing passive DA detection will naturally also receive the extension, but the UA SHOULD ignore the extension.
执行被动DA检测的UA自然也会接收扩展，但UA应忽略扩展。
An SA can receive a NotifyAt with a SrvAck when it first comes up and registers itself with a DA. If the DA has any subscriptions from UAs for the service type and scopes represented by the SA, it MUST return a NotifyAt with the SrvAck.
SA可以在第一次出现时使用SrvAck接收NotifyAt并向DA注册。如果DA对SA表示的服务类型和作用域有任何来自UAs的订阅，它必须返回带有SrvAck的NotifyAt。
The SA upon receiving the NotifyAt immediately multicasts the same SrvReg it sent to the DA, according to the multicast transmit algorithm. The SA MUST only perform the multicast algorithm once, even if it registers with more than one DA and receives the NotifyAt in reply from more than one. Prior to its demise and after deregistering with a DA, the SA MUST notify with the same SrvDereg, as described in Section 7.2.
SA在收到NotifyAt后立即根据多播传输算法多播其发送给DA的相同SrvReg。SA必须只执行一次多播算法，即使它向多个DA注册并从多个DA接收NotifyAt作为应答。如第7.2节所述，在其终止之前和在DA注销后，SA必须通知相同的SrvDereg。
Enterprise networks that allow SLP notification SHOULD deploy the Multicast Address Allocation Architecture (MAAA) including administratively scoped multicast and Multicast Address Dynamic Client Allocation Protocol (MADCAP) [6].
允许SLP通知的企业网络应部署多播地址分配体系结构（MAAA），包括管理范围的多播和多播地址动态客户端分配协议（MADCAP）[6]。
If it is not possible to obtain a multicast address for use in SLP notifications, the SLP multicast address is used.
如果无法获取用于SLP通知的多播地址，则使用SLP多播地址。
If the MAAA infrastructure is deployed, DAs and SAs obtain their scope configuration from MADCAP, because the SLP scopes are the same as the MADCAP scopes. Each SLP scope MUST correspond to a multicast scope name, in the sense of [6]. In such a case, a DA allocates, using MADCAP, a new multicast group address for each new service type/scope pair to which a UA subscribes. The allocation is made by MADCAP from the multicast address range for the scope. In this way, only those UAs interested in the service type and scopes in the subscription receive the multicast notification. The DA sets up the lease on the multicast address to correspond with the duration of the subscription. If the MADCAP server runs out of addresses, the SLP multicast group is used as a last resort.
如果部署了MAAA基础设施，DAs和SAs将从MADCAP获取其作用域配置，因为SLP作用域与MADCAP作用域相同。从[6]的意义上讲，每个SLP作用域必须对应于一个多播作用域名称。在这种情况下，DA使用MADCAP为UA订阅的每个新服务类型/作用域对分配新的多播组地址。MADCAP从作用域的多播地址范围进行分配。这样，只有那些对订阅中的服务类型和作用域感兴趣的ua才会收到多播通知。DA在多播地址上设置租约，以与订阅的持续时间相对应。如果MADCAP服务器的地址不足，将使用SLP多播组作为最后手段。
For example, if the multicast scope has an address range of 239.1.0.0 through 239.1.255.255, the notification group address for service type X in scope A could be 239.1.0.42 and for service type Y in scope B could be 239.1.42.42.
例如，如果多播作用域的地址范围为239.1.0.0到239.1.255.255，则作用域A中服务类型X的通知组地址可以是239.1.0.42，而作用域B中服务类型Y的通知组地址可以是239.1.42.42。
The DA and SAs use a multicast transmit algorithm similar to that used for discovering services in SLP, described in RFC 2608 [1], except the agent performing the notification doesn't wait for replies. The agent performing the notification transmits a notification message repeatedly over a period of 15 seconds, backing off exponentially on the duration of the time interval between the multicasts. The rationale for this algorithm is to limit the duration and scope of the multicast announcement while still repeating the announcement enough times to increase the probability that one message gets through.
DA和SAs使用的多播传输算法与RFC 2608[1]中描述的SLP中用于发现服务的算法类似，只是执行通知的代理不等待答复。执行通知的代理在15秒内重复发送通知消息，并在多播之间的时间间隔内呈指数级后退。该算法的基本原理是限制多播公告的持续时间和范围，同时仍然重复公告足够的次数，以增加一条消息通过的概率。
For an SA, a notification message is either a SrvReg or a SrvDereg message, depending on whether the SA is registering a new service or deregistering a service. When a new service is registered, the SrvReg message MUST have the fresh bit set in the SLP header. The entire list of attributes for the service SHOULD be included. The SrvDereg message MUST NOT include an attribute tag list. Notifications MUST NOT be transmitted at any other time, to minimize multicast traffic.
对于SA，通知消息是SrvReg或SrvDereg消息，具体取决于SA是注册新服务还是注销服务。注册新服务时，SrvReg消息必须在SLP标头中设置新位。应该包括服务的整个属性列表。SrvDereg消息不得包含属性标记列表。通知不得在任何其他时间传输，以最小化多播流量。
Since a SrvReg could contain attribute lists of arbitrary length, the message could potentially overflow the packet MTU for UDP. If an attribute list causes a packet MTU overflow, the SA MUST set the overflow bit in the SLP header. The attribute list in the notification message MUST be formatted so that a UA can use the attributes even if an overflow occurs. If a UA needs more attributes than are transmitted in the notification message, it can contact the SA (if no DA is present) or the DA for the attributes it needs.
由于SrvReg可能包含任意长度的属性列表，因此消息可能会溢出UDP的数据包MTU。如果属性列表导致数据包MTU溢出，SA必须在SLP头中设置溢出位。通知消息中的属性列表必须格式化，以便UA即使发生溢出也可以使用这些属性。如果UA需要的属性多于通知消息中传输的属性，它可以联系SA（如果不存在DA）或DA以获取所需的属性。
A DA multicasts a DAAdvert when a subscription comes in containing a service type and scopes that do not match any on the DA's list of known subscriptions. The same algorithm MUST be used. If the combination of the DA attributes and the NotifyAt message cause the DAAdvert to overflow a UDP packet, DA attributes MUST be truncated to allow the NotifyAt to fit and the overflow bit MUST be set in the header. An SA knows that the purpose of the message is to inform it of a new subscription rather than for passive advertisement, because of the extension, and it can therefore ignore the DA attribute list field if the overflow bit is set in the header. A DA also transmits a SrvDereg message when a service advertisement is deregistered due to timeout, following the same rules as for an SA.
当订阅包含与DA的已知订阅列表中的任何服务类型和作用域不匹配的服务类型和作用域时，DA将多播DAAD。必须使用相同的算法。如果DA属性和NotifyAt消息的组合导致DAAD溢出UDP数据包，则必须截断DA属性以允许NotifyAt适合，并且必须在报头中设置溢出位。SA知道，由于扩展，消息的目的是通知其新订阅，而不是被动播发，因此，如果在报头中设置了溢出位，则SA可以忽略DA属性列表字段。当服务广告由于超时而取消注册时，DA也会按照与SA相同的规则发送SrvDereg消息。
Robustness to DA failure is an important goal of the design. When a DA disappears due to unforeseen circumstances, subscription information from UAs is lost. UAs continue to get notifications from existing SAs. However, new SAs will not be informed of the subscription unless other DAs also have the subscription information. Because a UA may not discover a new DA until it tries to perform an active request, the UA could potentially miss the appearance of new services. For this reason, UAs that are concerned about receiving notification of absolutely every service that appears SHOULD issue subscriptions to every newly discovered DA that supports the scopes it supports. Similarly, if a DA disappears through controlled shutdown, a UA performing passive discovery can detect the shutdown and reissue the subscription to an alternate DA.
对DA故障的鲁棒性是设计的一个重要目标。当DA因不可预见的情况而消失时，来自UAs的订阅信息将丢失。UAs继续从现有SA获取通知。但是，除非其他DA也有订阅信息，否则不会通知新SA订阅。由于UA在尝试执行活动请求之前可能不会发现新的DA，因此UA可能会错过新服务的出现。出于这个原因，关心接收出现的每个服务的通知的UAs应该向每个新发现的支持其支持的作用域的DA发出订阅。类似地，如果DA通过受控关机而消失，则执行被动发现的UA可以检测到关机并重新发布对备用DA的订阅。
On the SA side, when a DA goes down, existing SAs continue to notify until the subscription expires. Before ceasing to notify, an SA MUST determine whether the DA is still active and, if not, verify with another DA whether the subscription has been extended. If no other DA is available, the SA MUST ignore the subscription expiration time and continue notifying until a new DA is discovered. When a new DA is discovered the SA must send a new SrvReg to the DA, according to RFC 2608 [1]. The replying SrvAck contains a NotifyAt extension if the UA has renewed its subscription with the DA. If the SrvAck does not contain a NotifyAt message the SA MUST continue to notify until the subscription expires. If a UA is interested in continuing the notification, it renews the subscription with the new DA prior to the expiration of the old one, and so the SA is informed to continue notifying.
在SA端，当DA关闭时，现有SA将继续通知，直到订阅过期。在停止通知之前，SA必须确定DA是否仍处于活动状态，如果不是，则与另一DA核实订阅是否已延长。如果没有其他DA可用，SA必须忽略订阅过期时间并继续通知，直到发现新DA为止。根据RFC 2608[1]，当发现新的DA时，SA必须向DA发送新的SrvReg。如果UA已向DA续订，则应答SrvAck包含NotifyAt扩展。如果SrvAck不包含NotifyAt消息，SA必须继续通知，直到订阅到期。如果UA有兴趣继续通知，它会在旧DA到期之前使用新DA续订，因此通知SA继续通知。
Note that this procedure still does not inform SAs that come up between the time a newly booted DA comes up and the time the UA has renewed its subscription with the newly booted DA. If this situation is of concern, multiple DAs can be used to assure that all subscriptions are covered when a DA goes down.
请注意，此过程仍然不会通知SAs在新启动的DA出现和UA使用新启动的DA更新其订阅之间出现的时间。如果这种情况值得关注，可以使用多个DA来确保在DA关闭时覆盖所有订阅。
In SLP networks with DAs as described in RFC 2608, the only multicast is the SrvRqst for DAAdverts performed during active DA discovery, and unsolicited DAAdverts sent periodically by the DA for passive discovery. There is no multicast involved in UA queries or SA registrations. This allows network administrators to set up DAs for a particular collection of IP subnets and confine all service discovery traffic to unicast between the SA and UA clients and the DA. Administratively scoped multicast can additionally be used to limit the extent of active DA discovery and passive DA advertising. The amount of multicast involved is not high and DHCP DA and scope configuration can be used to limit which DAs a particular UA or SA client sees, or to inhibit multicast entirely so that UAs and SAs only use configured DAs.
如RFC 2608所述，在具有DAs的SLP网络中，唯一的多播是在主动DA发现期间执行的用于DAAD的SrvRqst，以及由DA定期发送用于被动发现的未经请求的DAAD。UA查询或SA注册中不涉及多播。这允许网络管理员为特定的IP子网集合设置DAs，并将所有服务发现流量限制为SA和UA客户端与DA之间的单播。管理范围的多播还可用于限制主动DA发现和被动DA广告的范围。所涉及的多播量不高，DHCP DA和作用域配置可用于限制特定UA或SA客户端看到的DAs，或完全禁止多播，以便UAs和SA仅使用已配置的DAs。
With notification, however, multicast traffic involving events in SAs becomes available. Because DAs request multicast addresses based on scope and service type, the multicast associated with particular events should only propagate to those subnets in which UAs and SAs of the same scope are interacting. Routers should be configured with administrative multicast scoping to limit multicast. If DAs are not deployed (or the MAAA is not deployed), however, the amount of multicast on the SLP multicast address when notifications are being used could quickly become very large. Therefore, it is crucial that DAs supporting notification be deployed in large networks where UA clients are interested in notification.
然而，通过通知，涉及SAs中事件的多播通信变得可用。由于DAs基于作用域和服务类型请求多播地址，因此与特定事件相关联的多播应该只传播到那些同一作用域的UAs和SA正在交互的子网。路由器应配置管理多播作用域以限制多播。但是，如果未部署DAs（或未部署MAAA），则使用通知时SLP多播地址上的多播量可能会很快变得非常大。因此，在UA客户端对通知感兴趣的大型网络中部署支持通知的DAs是至关重要的。
The SrvReg and SrvDereg messages contain authentication blocks for all SLP SPIs supported by the DAs with which the SA registers. Since these SPIs are necessarily the same as those that UAs can verify, a UA receiving a multicast notification is in a position to verify the notification. It does so by selecting the authentication block or blocks that it can verify. If authentication fails, either due to lack of an authentication block, or lack of the proper SPI, the UA simply discards the notification. In a network without DAs, the SPIs of the UA and SA must also match.
SrvReg和SrvDereg消息包含SA注册的DAs支持的所有SLP SPI的身份验证块。由于这些SPI必须与UAs可以验证的SPI相同，因此接收多播通知的UA能够验证该通知。它通过选择可验证的一个或多个验证块来实现。如果由于缺少身份验证块或缺少适当的SPI而导致身份验证失败，UA只会丢弃通知。在没有DAs的网络中，UA和SA的SPI也必须匹配。
The SLP Notification services use the IANA-assigned port number of 1847. The SLP extension identifiers assigned by IANA are 0x0004 for Subscribe and 0x0005 for NotifyAt.
SLP通知服务使用IANA分配的端口号1847。IANA分配的SLP扩展标识符对于Subscribe为0x0004，对于NotifyAt为0x0005。
The authors would like to thank Charles Perkins, of Nokia, and Erik Guttman and Jonathan Wood, of Sun Microsystems, for their stimulating discussion and suggestions during the initial phases of the subscription/notification design. We would also like to thank Erik for his intense scrutiny of the specification during the later phases. His comments were instrumental in refining the design. Shivaun Albright, of HP, motivated simplification of the protocol to focus on initial registration and deregistration only. Vaishali Mithbaokar implemented the simplified protocol.
作者要感谢诺基亚的Charles Perkins和Sun Microsystems的Erik Guttman和Jonathan Wood，感谢他们在订阅/通知设计的初始阶段进行的富有启发性的讨论和提出的建议。我们还要感谢Erik在后期阶段对规范的严格审查。他的评论有助于改进设计。惠普的Shivaun Albright推动简化协议，只关注初始注册和注销。Vaishali Mithbaokar实现了简化协议。
[1] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service Location Protocol", RFC 2608, July 1999.
[1] Guttman，E.，Perkins，C.，Veizades，J.和M.Day，“服务位置协议”，RFC 26081999年7月。
[2] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[3] Guttman, E., Perkins, C. and J. Kempf, "Service Templates and service: Schemes", RFC 2609, July 1999.
[3] Guttman，E.，Perkins，C.和J.Kempf，“服务模板和服务：方案”，RFC 26091999年7月。
[4] Meyer, D., "Administratively Scoped IP Multicast", RFC 2365, July 1998.
[4] Meyer，D.，“管理范围的IP多播”，RFC 2365，1998年7月。
[5] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[5] Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 2234，1997年11月。
[6] Hanna, S., Patel,B. and M. Shah, "Multicast Address Dynamic Client Allocation Protocol (MADCAP)", RFC 2730, December 1999.
[6] Hanna，S.，Patel，B.和M.Shah，“多播地址动态客户端分配协议（MADCAP）”，RFC2730，1999年12月。
[7] http://www.isi.edu/in-notes/iana/assignments/multicast-addresses
[7] http://www.isi.edu/in-notes/iana/assignments/multicast-addresses
[8] Guttman, E., "Service Location Protocol Modifications for IPv6", Work in Progress.
[8] Guttman，E.，“IPv6的服务位置协议修改”，正在进行中。
[9] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2375, July 1997.
[9] Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 23751997年7月。
James Kempf Sun Microsystems UMPK15-214 901 San Antonio Rd. Palo Alto, CA 94040 USA
James Kempf Sun Microsystems UMPK15-214 901美国加利福尼亚州帕洛阿尔托圣安东尼奥路94040号
Phone: +1 650 786 5890
EMail: james.kempf@sun.com
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
美国加利福尼亚州帕洛阿尔托圣安东尼奥路901号杰森·戈德施密特太阳微系统公司UMPK17-202 94040
Phone: +1 650 786 3502
EMail: jason.goldschmidt@sun.com
Phone: +1 650 786 3502
EMail: jason.goldschmidt@sun.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。