RFC3082 日本語訳
3082 Notification and Subscription for SLP. J. Kempf, J. Goldschmidt. March 2001. (Format: TXT=33410 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Kempf Request for Comments: 3082 J. Goldschmidt Category: Experimental Sun Microsystems March 2001
コメントを求めるワーキンググループJ.ケンフの要求をネットワークでつないでください: 3082年のJ.ゴールドシュミットカテゴリ: 2001年の実験的なサン・マイクロシステムズ行進
Notification and Subscription for SLP
SLPのための通知と購読
Status of this Memo
この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.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 それはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
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.
Service Locationプロトコル(SLP)はサービスエージェントのクライアントが広告を出すことができるメカニズムとクライアントがサービスのために質問できるユーザエージェントを提供します。 デザインがたいへん需要主導であるので、ユーザエージェントは彼らがいつ明確に自ら災難を招くかというサービス情報を得るだけです。 もう1人のクラスのユーザエージェント利用は存在していて、新しいサービスが現れるか、または見えなくなると、しかしながら、それは通知を必要とします。 RFC2608デザインでは、これらのアプリケーションは、変化を捕らえるためにやむを得ずネットワークに投票します。 本書では、私たちは変化が起こるときそのようなクライアントが通知されるのを許容するためにプロトコルについて説明します、世論調査の必要性を取り除いて。
1. Introduction
1. 序論
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.
サービスエージェント(SA)のクライアントがネットワーク・サービスの広告を出して、ユーザエージェント(UA)のクライアントが彼らを見つけるように、Service Locationプロトコル(SLP)[1]はメカニズムを提供します。 メカニズムは需要主導です。 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.
新しいサービスが来るか、またはサービスが見えなくなるとき、理想的に、これらのアプリケーションは通知されたいです。 SLPと共にRFC2608で説明されるようにこの情報を得て、そのようなアプリケーションは、定期的に利用可能なサービス広告の地元のキャッシュをリフレッシュするためにネットワークに投票しなければなりません。
Kempf & Goldschmidt Experimental [Page 1] RFC 3082 Notification and Subscription for SLP March 2001
SLP行進2001年のケンフ、ゴールドシュミット実験的な[1ページ]RFC3082Notification、および購読
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がサービスの有用性における変化について通知されるのを許容するスケーラブルなメカニズムについて説明します。
2. Notation Conventions
2. 記法コンベンション
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].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[2]で説明されるように本書では解釈されることであるべきですか?
3. Terminology
3. 用語
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.
購読--特定のサービスタイプへのサービスの有用性における変化と範囲に関して知識があるという要求。
4. Design Considerations
4. デザイン問題
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プロトコルが示す同じ高度のスケーラビリティと丈夫さを示して欲しいと思うということです。 通知はほんのいくつかのSAsと共に小さいネットワークで働くべきです、何千SAsとの大企業ネットワークと何百DAsと同様に。 小さいネットワークは通知の恩恵を受けるためにDAsを配備するのが必要であるべきではありません。 また、重い処理負荷が大きいネットワークにおける通知でどんな特定のSLPエージェントも責任とならないことを保証したいと思います。 これは、通知に関するタスクがすべての通知仕事をするのに1人のエージェントをどっさり積むのを避けるために集結されるよりむしろ分配されるのを必要とします。 最終的に、通知計画は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に関して透明です。
Kempf & Goldschmidt Experimental [Page 2] RFC 3082 Notification and Subscription for SLP March 2001
SLP行進2001年のケンフ、ゴールドシュミット実験的な[2ページ]RFC3082Notification、および購読
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拡大メカニズムを利用すると予想します。
5. Notification Design Description
5. 通知設計説明書
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.
スケーラビリティを支持するために、私たちはデザインを2つの部品に分けました。 どんなDAsもネットワークで存在していないとき、小さいネットワークデザインは使用されています。 大きいネットワークデザインはDAsと共にネットワークに使用されます。 以下の小区分は2つのデザインについて説明します。
5.1 Small Network Design
5.1 小さいネットワークデザイン
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.
SAが初めは現れて、SAが見えなくなるとき、DAsのないネットワークで、UAsはSAによって通知されます。 これで、UAsはSAが支持するサービスタイプのリストに関して知ることができます。 小さいネットワークには、新たに現れているSAsのために購読を管理できる集結されたエージェントが全くいません。 これはUAが興味がある特定の範囲の特定のサービスタイプのために通知に加入するどんな種類の購読デザインも除外します、新たに現れているSAが、それを言うために何か購読が集中しているエージェントなしであるかどうかわからないので。
Kempf & Goldschmidt Experimental [Page 3] RFC 3082 Notification and Subscription for SLP March 2001
SLP行進2001年のケンフ、ゴールドシュミット実験的な[3ページ]RFC3082Notification、および購読
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).
彼らが稼働中と彼らの範囲かサービスタイプにかかわらず停止する前に来るとき、その結果、SAsは通知を実行します、彼らが通知を実行できるなら。 これが、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がIPマルチキャスティング(マルチキャストが利用可能でないならIPv4で放送して)SLP SrvRegによる通知を実行するのを必要とするか、またはマルチキャストを使用するSrvDeregメッセージがセクション9.0で説明されたアルゴリズムを伝えます。 通知のためのポートナンバーはそのポートがいくつかのオペレーティングシステムで特権ユーザにとって開かれているだけであるのでSLPが移植するデフォルトではなく、むしろポート1847です、IANAによって割り当てられるように。
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、デフォルトTTL255)、SLP[4]と同じ方法で行政上見られます。 通知に興味を持っているIPv4 UAsはマルチキャストグループ239.255.255.253を接合して、ポート1847の上で聴きます。 IPv6では、マルチキャストは[8]で説明されるように広告に掲載されたサービスタイプのために見られたIPv6アドレスに実行されます。 SAはすべてのアドレスに支える中で最も大きいマルチキャスト範囲を含めて広告を出します。 通知に興味を持っているIPv6 UAsはマルチキャスト範囲に対応するマルチキャストグループとそれらが興味を持っているサービスタイプに加わって、ポート1847の上で聴きます。 例えば、サイトローカル範囲に近づく手段を持っていて、細切れ肉料理が42であるサービスタイプに興味を持っているアルゴリズムによると、[8]で計算されたIPv6 UAはグループFF01を接合します:、0:0:0、:、0:0:10042、FF05を通して:、0:0:0、:、0:0:10042
5.2 Large Network Design
5.2 大きいネットワークデザイン
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が付く、登録、SrvRqstメッセージへの拡大はDAに発信しました。 DAはセクション8.0で説明されたアルゴリズムに基づく通知としてマルチキャストグループアドレスを得て、それがSrvRplyに付けるNotifyAt拡張子にそれらを入れます。 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
新規申込みが入るとき、既存のSAsは、購読に関して以下の手順を用いることで知識があります。 既存の購読のリストに対して、DAはサービスタイプを比較して、新規申込みで見ます。 どんな前の購読にも、同じサービスタイプと範囲、DA MUSTマルチキャストa DAAdvert、使用がありません。
Kempf & Goldschmidt Experimental [Page 4] RFC 3082 Notification and Subscription for SLP March 2001
SLP行進2001年のケンフ、ゴールドシュミット実験的な[4ページ]RFC3082Notification、および購読
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 MUST NOTマルチキャストをDAAdvertを見るなら。
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 MUSTはそれが他のDAsによってアレンジされた購読と同様にDAが構成されるどんな範囲にも配置した購読の動向をおさえます。 複数のマルチキャストNotifyAtメッセージ、DA MUSTを避けるには、NotifyAtと共にマルチキャストDAAdvertを送る一様に分散している0〜3秒前の無作為の時間を待ってください。 この期間、DA MUSTは新規申込みからものに合っているNotifyAtメッセージの聞こうとします。 合っているNotifyAtが検出されるなら、マルチキャストではなく、DA MUSTです。
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 MUST NOTは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自身は通知を実行しなければならなくて、マルチキャストに従って、aサービス広告回数であるときにはアルゴリズムを外に伝えてください。 サービス広告のタイムアウトは反登録されたURLのためのDAマルチキャスティングa SrvDeregをもたらします。 SAが反登録しないで見えなくなったとしても、これは、関心があるUAsがサービス広告の終焉において知識があるのを許容します。 SAからSrvRegを受けるとき、DA MUST NOTは通知を実行して、しかしながら、それは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と共にDAAdvertか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拡張子の範囲の1つに合っています。
Kempf & Goldschmidt Experimental [Page 5] RFC 3082 Notification and Subscription for SLP March 2001
SLP行進2001年のケンフ、ゴールドシュミット実験的な[5ページ]RFC3082Notification、および購読
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がDAと共にSrvRegかSrvDeregを実行した直後SA MUSTは通知を実行します。 範囲にDAを検出したSAがそうしてはいけない、マルチキャスト、SAのものを合わせながらSrvAckにサービスタイプと範囲でNotifyAt拡張子を受け取らない場合、どんな通知もタイプと範囲にサービスを提供します。
6. Subscribe Extension
6. 拡大を申し込んでください。
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 拡大タイプ=0x0004| 拡大の長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 例えば レン。 (ct) | 腹筋。 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から拡大の範囲リストとサービスタイプを取ります。 抽象型旗はUAは抽象型[3]の具体的な例の広告を出すすべてのSAsから連絡をいただくのに興味を持っていて、SrvRqstのサービスタイプが具体的なタイプである場合にだけ興味があるかどうかを示します。 旗が1であるなら、UAは、すべてのSAsから広告コンクリートがSrvRqstのタイプと同じ抽象型を持ちながらタイプされると聞きたがっています。 旗が0であるなら、UAはSrvRqstで特定の具体的なタイプを支持するSAsから連絡をいただくだけでありたいです。 付随のSrvRqstのサービスタイプがそんな具体的な人間でないなら、旗は無視されます。
7. NotifyAt Extension
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 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 拡大タイプ=0x0005| 拡大の長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ext。 レン(ct)| 購読生涯|SGLはレンを記載します。 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |SGL L.レン(ct)| 範囲/グループリスト\+++++++++++++++++++++++++++++++++| 勤続年数型名| サービスタイプは+++++++++++++++++++++++++++++++++と\を命名します。
Kempf & Goldschmidt Experimental [Page 6] RFC 3082 Notification and Subscription for SLP March 2001
SLP行進2001年のケンフ、ゴールドシュミット実験的な[6ページ]RFC3082Notification、および購読
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=名、」、:、」 ip-addr ip-addrはipv4-数と等しいです。| ipv6-数の範囲名の=。 範囲名ipv4-数の形式のためのRFC2608が1*3DIGIT3と等しいのを見てください、(「. 」 1*3DIGIT) ipv6-数の=; RFC2373[9]部2.2を見てください。
An example of a scope/group list for IPv4 is:
IPv4のための範囲/グループリストに関する例は以下の通りです。
eng:239.255.255.42,corp:239.255.255.43
eng: 239.255 .255 .42、corp:、239.255、.255、.43
An example of a scope/group listfor IPv6 is:
範囲/グループlistfor 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.
サービス型名は、簡単な型名、抽象型名、または具体的な型名であるかもしれません。 名前が抽象型名であるなら、抽象型の広告を出すすべてのSAsが通知しなければなりません。 他のものは、簡単であるか具体的なタイプの広告を出すそれらのSAsだけが名前がコンクリートか簡単な型名であるなら、通知しなければならないように通知してはいけません。 具体的なタイプのために抽象型旗で購読を受けるDAはセットして、それが送るすべてのNotifyAtメッセージに抽象型名を含まなければなりません。 抽象型旗がセットしていなくDAが具体的なタイプのために購読を受けるなら、DA MUST NOTは抽象型を含んでいますが、むしろ具体的な型名を含まなければなりません。
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拡張子を受け取るかもしれない3つの場合があります: UAに返されたSrvRply、SAへのDAAdvertであって、SrvAckで返されたマルチキャストで。 以下の3つの小区分がそれぞれのこれらの場合における応答について説明します。
7.1 NotifyAt received with SrvRply
7.1 SrvRplyと共に受け取られたNotifyAt
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.
SrvRplyがNotifyAtを含んでいて、UAがいつ拡大、DAを登録があるSrvRqstに送るかは応じます。 いかなる他のUAへのDA MUST NOTユニキャストa NotifyAtもNotifyAtを通信して、送ってはいけない、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 MAYは満了生涯に注意したがっています。
Kempf & Goldschmidt Experimental [Page 7] RFC 3082 Notification and Subscription for SLP March 2001
SLP行進2001年のケンフ、ゴールドシュミット実験的な[7ページ]RFC3082Notification、および購読
subscription assigned by the DA, and reissue a subscription before the lifetime expires.
寿命が期限が切れる前に購読はDA、および再発行による購読を割り当てました。
7.2 NotifyAt received with Multicast DAAdvert
7.2 Multicast DAAdvertと共に受け取られたNotifyAt
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.
DAAdvertがマルチキャストを使用しているNotifyAtが伝えるDAマルチキャストは以前に、購読で見られませんでしたUAが通知を要求したアルゴリズム、範囲、およびサービスが、タイプする。 このメッセージは、サービスタイプがある既存のSAsに知らせて、発表で彼らは停止するときのマルチキャスト通知がそうするべきであるのを見ます。
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は、サービスタイプと範囲が合っているならマルチキャストアドレスに注意することによって、応じます。 属性タグのないSrvDeregがDAs(標準のSLPに従って)に記載するSA MUST最初のユニキャスト、SAが落ちようとしているなら、次に、それは落ちなければなりません。マルチキャストに従って同じSrvDeregが通信させるマルチキャストはアルゴリズムを伝えます。 SA MUSTは、購読寿命が期限が切れて、その後の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 SHOULDは拡大を無視します。
7.3 NotifyAt received with SrvAck
7.3 SrvAckと共に受け取られたNotifyAt
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.
最初にDAにそれ自体を来て、登録するとき、SAはSrvAckと共にNotifyAtを受けることができます。 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 MUSTは一度マルチキャストアルゴリズムを実行するだけです、1DAとともに記名し、1以上から回答でNotifyAtを受けても。 終焉の前とDAと共に反登録した後に、SA MUSTは同じSrvDeregと共に通知します、セクション7.2で説明されるように。
8. Multicast Address Allocation
8. マルチキャストアドレス配分
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].
行政上見られたマルチキャストとMulticast Address Dynamic Client Allocationプロトコル(MADCAP)[6]を含んでいて、SLP通知SHOULDを許容する企業網がMulticast Address Allocation Architecture(MAAA)を配備します。
If it is not possible to obtain a multicast address for use in SLP notifications, the SLP multicast address is used.
SLP通知における使用のためのマルチキャストアドレスを得るのが可能でないなら、SLPマルチキャストアドレスは使用されています。
Kempf & Goldschmidt Experimental [Page 8] RFC 3082 Notification and Subscription for SLP March 2001
SLP行進2001年のケンフ、ゴールドシュミット実験的な[8ページ]RFC3082Notification、および購読
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が見るのと同じであるので。 それぞれのSLP範囲は[6]の意味におけるマルチキャスト範囲名に対応しなければなりません。 このような場合には、MADCAPを使用して、DAはUAが寄付するそれぞれの新しいサービスタイプ/範囲組のために新しいマルチキャストグループアドレスを割り当てます。 配分はMADCAPによってマルチキャストアドレスの範囲から範囲に作られます。 このように、サービスに興味を持っているそれらのUAsだけがタイプします、そして、購読における範囲はマルチキャスト通知を受け取ります。 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、通知グループが239.1が.0であったかもしれないならサービスタイプのために範囲AにXを記述する、.42、中のサービスタイプYは239.1が.42であったかもしれないなら.42にBを見ます。
9. Multicast Transmit Algorithm
9. マルチキャストはアルゴリズムを伝えます。
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.
SLPでサービスを発見するのに使用されるそれと同様のアルゴリズムを伝えて、RFC2608[1]で説明されて、DAとSAsはマルチキャストを使用して、エージェント実行以外に、通知は回答を待っていません。 通知を実行しているエージェントは15秒の期間にわたって繰り返して通知メッセージを伝えます、マルチキャストの時間間隔の持続時間で指数関数的に引き返して。 このアルゴリズムのための原理が確率を増加させることができるくらいの回まだ発表を繰り返している間のマルチキャスト発表の持続時間と範囲を制限することであるので、1つのメッセージが通ります。
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ヘッダーに新鮮なビットを設定しなければなりません。 含まれていて、全体がサービスSHOULDのために属性について記載します。 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 MUSTはSLPヘッダーにオーバーフロービットをはめ込みます。 オーバーフローが起こってもUAが属性を使用できるように、通知メッセージの属性リストをフォーマットしなければなりません。 UAが通知メッセージで伝えられるより多くの属性を必要とするなら、それは必要とする属性のためにSA(どんなDAも存在していないなら)かDAに連絡できます。
Kempf & Goldschmidt Experimental [Page 9] RFC 3082 Notification and Subscription for SLP March 2001
SLP行進2001年のケンフ、ゴールドシュミット実験的な[9ページ]RFC3082Notification、および購読
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マルチキャストa DAAdvertはDAの知られている購読のリストのいずれにも合っていません。 同じアルゴリズムを使用しなければなりません。 DAAdvertをDA属性の組み合わせとNotifyAtメッセージでUDPパケットからはみ出させるなら、NotifyAtが合うのを許容するためにDA属性に先端を切らせなければなりません、そして、ヘッダーにオーバーフロービットを設定しなければなりません。 SAは、メッセージの目的が拡大のために受け身の広告のためにというよりむしろ新規申込みについてそれを知らせることであることを知っています、そして、したがって、オーバーフロービットがヘッダーに設定されるなら、それはDA属性リスト分野を無視できます。 また、サービス広告がタイムアウトのため反登録されると、DAはSrvDeregメッセージを送ります、SAのように同じ規則に従って。
10.0 DA Disappearance
10.0 DA消滅
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は、既存のSAsから通知を得続けています。 しかしながら、また、他のDAsに購読情報がないなら、新しいSAsは購読で知識があるようにならないでしょう。 それが活発な要求を実行しようとするまでUAが新しいDAを発見しないかもしれないので、UAは潜在的に新種業務の外観を逃すことができました。 この理由で、絶対にあらゆるサービスの通知を受け取ることに関してそれがSHOULDに現れることを心配している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.
DAが落ちるとき、SA側では、既存のSAsが、購読が期限が切れるまで通知し続けています。 DAがまだアクティブであるかどうか決定して、そうでなければ、以前、通知するやむSA MUSTは、別のDAと共に購読を広げてあるかどうか確かめます。 他のどんなDAも利用可能でないなら、SA MUSTは、購読満了時間を無視して、新しいDAが発見されるまで通知し続けています。 新しいDAが発見されるとき、SAは新しいSrvRegをDAに送らなければなりません、RFC2608[1]によると。 UAがDAと共に購読を継続したなら、返答しているSrvAckはNotifyAt拡張子を含んでいます。 SrvAckがNotifyAtメッセージを含んでいないなら、SA MUSTは、購読が期限が切れるまで通知し続けています。 UAが通知を続けたいなら、古い方の満了の前の新しいDAとの購読を更新するので、SAは通知し続けるために知らされます。
Kempf & Goldschmidt Experimental [Page 10] RFC 3082 Notification and Subscription for SLP March 2001
SLP行進2001年のケンフ、ゴールドシュミット実験的な[10ページ]RFC3082Notification、および購読
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.
この手順がまだ新たに起動させられたDAが来る時、時の間でUAを上って来るSAsに知らせていないというメモは新たに起動させられたDAと共に購読を継続しました。 この状況が重要であるなら、DAが落ちるとき、すべての購読がカバーされていることを保証するのに複数のDAsを使用できます。
11. Network Administration Considerations
11. ネットワーク管理問題
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.
RFC2608で説明されるDAsとのSLPネットワークでは、唯一のマルチキャストが活発なDA発見の間に実行されたDAAdvertsのためのSrvRqstです、そして、求められていないDAAdvertsは受け身の発見のために定期的にDAで発信しました。 UA質問かSA登録証明書にかかわるマルチキャストが全くありません。 これで、ネットワーク管理者は、IPサブネットの特定の収集のためにDAsをセットアップして、SAと、UAクライアントとDAの間ですべてのサービス発見交通をユニキャストに制限します。 活発なDA発見と受け身のDA広告の範囲を制限するのにさらに、行政上見られたマルチキャストは使用できます。 かかわるマルチキャストの量は高くはありません、そして、DHCP DAと範囲構成はどのDAsを制限するかに使用されて、特定のUAかSAクライアントが見るか、またはしたがって、マルチキャストを完全に禁止するのに、そのUAsとSAsが構成された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とSAsが相互作用しているそれらのサブネットに伝播されるだけであるべきです。 ルータは管理マルチキャストの見ることによって構成されて、マルチキャストを制限するべきです。 しかしながら、DAsが配備されないなら(MAAAは配備されません)、通知が使用されているとき、SLPマルチキャストアドレスに関するマルチキャストの量は急速に非常に大きくなるかもしれません。 したがって、通知を支持するDAsがUAクライアントが通知に興味を持っている大きいネットワークで配備されるのは、重要です。
12. Security Considerations
12. セキュリティ問題
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 SPIsのための認証ブロックを含んでいます。 これらのSPIsが必ずUAsが確かめることができるものと同じであるので、マルチキャスト通知を受け取るUAが通知について確かめる立場にあります。 それは確かめることができる認証ブロックを選択するか、何ブロックもそうします。 認証が1つの認証ブロックの不足、または適切なSPIの不足のため失敗するなら、UAは単に通知を捨てます。 また、DAsのないネットワークでは、UAとSAのSPIsは合わなければなりません。
Kempf & Goldschmidt Experimental [Page 11] RFC 3082 Notification and Subscription for SLP March 2001
SLP行進2001年のケンフ、ゴールドシュミット実験的な[11ページ]RFC3082Notification、および購読
13. IANA Considerations
13. IANA問題
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 Notificationサービスは1847年のIANAによって割り当てられたポートナンバーを使用します。 IANAによって割り当てられたSLP拡大識別子が0×0004である、登録、そして、NotifyAtのための0×0005。
14. Acknowledgements
14. 承認
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.
作者はサン・マイクロシステムズのノキアのチャールズ・パーキンス、エリックGuttman、およびジョナサンWoodに感謝したがっています、購読/通知デザインの初期位相の間の彼らの刺激的な議論と提案のために。 また、後期の間、彼の仕様の激しい精査についてエリックに感謝申し上げます。 彼のコメントはデザインを洗練する際に手段になっていました。 Shivaunオルブライトは、新規登録と反登録だけに焦点を合わせるためにHPについてプロトコルの簡素化を動機づけました。 Vaishali Mithbaokarは簡易型のプロトコルを実行しました。
15. References
15. 参照
[1] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service Location Protocol", RFC 2608, July 1999.
[1]GuttmanとE.とパーキンスとC.とVeizadesとJ.とM.日、「サービス位置のプロトコル」、RFC2608、1999年7月。
[2] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] ブラドナー、S.、「使用のための要件レベルを示すRFCsのキーワード」、BCP14、RFC2119、1997年3月。
[3] Guttman, E., Perkins, C. and J. Kempf, "Service Templates and service: Schemes", RFC 2609, July 1999.
[3] Guttman(E.、パーキンス、C.、およびJ.ケンフ)は「Templatesを調整して、以下を修理します」。 「計画」、RFC2609、1999年7月。
[4] Meyer, D., "Administratively Scoped IP Multicast", RFC 2365, July 1998.
[4] マイヤー、D.、「行政上見られたIPマルチキャスト」、RFC2365、1998年7月。
[5] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[5] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、1997年11月のRFC2234。
[6] Hanna, S., Patel,B. and M. Shah, "Multicast Address Dynamic Client Allocation Protocol (MADCAP)", RFC 2730, December 1999.
[6] ハンナとS.とパテルとB.とM.シャー、「マルチキャストのアドレスのダイナミックなクライアント配分プロトコル(向こう見ず)」、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.デアリング、「IPバージョン6アドレッシング体系」、RFC2375、1997年7月。
Kempf & Goldschmidt Experimental [Page 12] RFC 3082 Notification and Subscription for SLP March 2001
SLP行進2001年のケンフ、ゴールドシュミット実験的な[12ページ]RFC3082Notification、および購読
16. Author's Addresses
16. 作者のアドレス
James Kempf Sun Microsystems UMPK15-214 901 San Antonio Rd. Palo Alto, CA 94040 USA
ジェームスケンフサン・マイクロシステムズUMPK15-214 901サンアントニオ通り パロアルト、カリフォルニア94040米国
Phone: +1 650 786 5890 EMail: james.kempf@sun.com
以下に電話をしてください。 +1 5890年の650 786メール: james.kempf@sun.com
Jason Goldschmidt Sun Microsystems UMPK17-202 901 San Antonio Rd. Palo Alto, CA 94040 USA
ジェイソンゴールドシュミットサン・マイクロシステムズUMPK17-202 901サンアントニオ通り パロアルト、カリフォルニア94040米国
Phone: +1 650 786 3502 EMail: jason.goldschmidt@sun.com
以下に電話をしてください。 +1 3502年の650 786メール: jason.goldschmidt@sun.com
Kempf & Goldschmidt Experimental [Page 13] RFC 3082 Notification and Subscription for SLP March 2001
SLP行進2001年のケンフ、ゴールドシュミット実験的な[13ページ]RFC3082Notification、および購読
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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 Editor機能のための基金は現在、インターネット協会によって提供されます。
Kempf & Goldschmidt Experimental [Page 14]
ケンフとゴールドシュミットExperimentalです。[14ページ]
一覧
スポンサーリンク