Network Working Group W. Zhao
Request for Comments: 3528 H. Schulzrinne
Category: Experimental Columbia University
E. Guttman
Sun Microsystems
April 2003
Mesh-enhanced Service Location Protocol (mSLP)
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.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
Abstract
抽象
This document describes the Mesh-enhanced Service Location Protocol (mSLP). mSLP enhances the Service Location Protocol (SLP) with a scope-based fully-meshed peering Directory Agent (DA) architecture. Peer DAs exchange new service registrations in shared scopes via anti-entropy and direct forwarding. mSLP improves the reliability and consistency of SLP DA services, and simplifies Service Agent (SA) registrations in systems with multiple DAs. mSLP is backward compatible with SLPv2 and can be deployed incrementally.
この文書では、メッシュが強化されたサービスロケーションプロトコル（MSLP）について説明します。 MSLPはスコープベースのフルメッシュピアリングディレクトリエージェント（DA）アーキテクチャとサービスロケーションプロトコル（SLP）を強化します。ピアダスは、抗エントロピーとの直接転送を介して共有スコープの新サービス登録を交換します。 MSLPは、SLP DAサービスの信頼性と一貫性を向上させ、複数のDAを持つシステムでサービスエージェント（SA）の登録を簡素化します。 MSLPはSLPv2のと下位互換性があり、漸進的に展開することができます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Notation Conventions . . . . . . . . . . . . . . . . . . 2
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Compatibility . . . . . . . . . . . . . . . . . . . . . 3
2. Scope-based Fully-meshed Peering DA Architecture . . . . . . . 4
3. Peer Relationship Management . . . . . . . . . . . . . . . . . 6
3.1. Learning about New Peers . . . . . . . . . . . . . . . . 6
3.2. Establishing a Peering Connection . . . . . . . . . . . 6
3.3. Exchanging Information about Existing Peers . . . . . . 6
3.4. Maintaining a Peer Relationship . . . . . . . . . . . . 7
3.5. Tearing Down a Peer Relationship . . . . . . . . . . . . 7
4. Registration Propagation Control . . . . . . . . . . . . . . . 7
4.1. Accept ID and Propagation Order . . . . . . . . . . . . 7
4.2. Version Timestamp and Registration Version Resolution . 8
4.3. Mesh Forwarding Extension . . . . . . . . . . . . . . . 8
4.4. Summary Vector . . . . . . . . . . . . . . . . . . . . . 9
4.5. Service Deregistration . . . . . . . . . . . . . . . . . 10
4.6. Anti-entropy Request Message . . . . . . . . . . . . . . 10
4.7. Anti-entropy . . . . . . . . . . . . . . . . . . . . . . 11
4.8. Direct Forwarding . . . . . . . . . . . . . . . . . . . 11
4.9. SrvAck Message . . . . . . . . . . . . . . . . . . . . . 12
4.10. Control Information . . . . . . . . . . . . . . . . . . 12
5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6. Protocol Timing Defaults . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . 14
11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
12. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 15
In the Service Location Protocol (SLPv2 [RFC2608]), Directory Agents (DAs) accept service registrations from Service Agents (SAs) and answer queries from User Agents (UAs); they enhance the performance and scalability of SLPv2. The use of scopes in SLPv2 further improves its scalability. In general, a DA can serve multiple scopes, and a scope can be served by multiple DAs. When multiple DAs are present for a scope, how should they interact with each other? This document describes the Mesh-enhanced Service Location Protocol (mSLP), addressing this open issue in SLPv2.
サービスロケーションプロトコル（SLPv2の[RFC2608]）では、ディレクトリエージェント（DAS）サービスエージェント（SA）をからサービス登録を受け入れ、ユーザエージェント（UAS）からの問合せに答えます。彼らはSLPv2ののパフォーマンスとスケーラビリティを向上させます。 SLPv2の中のスコープを使用すると、さらにそのスケーラビリティが向上します。一般的に、DAは、複数のスコープを提供することができ、および範囲は、複数のDAがサービスを提供することができます。複数のDASはスコープのために存在する場合、どのように彼らが互いに対話する必要がありますか？この文書では、SLPv2の中で、このオープンな問題に対処する、メッシュが強化されたサービスロケーションプロトコル（MSLP）について説明します。
mSLP defines a scope-based fully-meshed peering DA architecture: for each scope, all DAs serving the scope form a fully-meshed peer relationship (similar to IBGP [RFC1771]). Peer DAs exchange new service registrations in shared scopes via anti-entropy [EPID-ALGO,UPDA-PROP] and direct forwarding. mSLP improves the reliability and consistency of SLP DA services, and simplifies SA registrations in systems with multiple DAs.
MSLPスコープベースのフルメッシュのピアリングDAアーキテクチャを定義：各スコープのスコープにサービスを提供するすべてのDAは（IBGP [RFC1771]と同様に）フルメッシュピア関係を形成します。ピアダス抗エントロピー[EPID-ALGO、UPDA-PROP]と直接転送を介して共有スコープに新しいサービス登録を交換します。 MSLPは、SLP DAサービスの信頼性と一貫性を向上させ、複数のDAを持つシステムでSAの登録を簡素化します。
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 BCP 14, RFC 2119 [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119 [RFC2119]に記載されているように解釈されます。
Peer DAs (or Peers) DAs that share one or multiple scopes are peers.
一つまたは複数のスコープを共有するピアダス（またはピア）DAがピアです。
Peering Connection A persistent connection (e.g., TCP) that provides reliable and ordered transfers between two peers. The closing of a peering connection terminates the peer relationship.
接続を2つのピア間で信頼性の順序付き転送を提供する永続的な接続（例えば、TCP）をピアリング。ピアリング接続の閉鎖は、ピア関係を終了します。
Mesh-enhanced DA (MDA) An MDA carries the "mesh-enhanced" attribute keyword in its DA Advertisement (DAAdvert) message, maintains peering connections to all peers, and properly interacts with peers.
DA（MDA）MDAメッシュが強化されたそのDA広告（DAAdvert）メッセージで「メッシュ強化」属性キーワードを運び、すべてのピアへのピアリングの接続を維持し、適切に仲間と対話します。
Mesh-enhanced SA (MSA) An MSA uses the Mesh Forwarding extension (Section 4.3) when it registers with MDAs.
それはのMDAを登録する際にメッシュが強化されたSA（MSA）アンMSAは、メッシュフォワーディング拡張（4.3節）を使用しています。
Registration Update A registration update refers to a Service Registration (SrvReg) or Service Deregistration (SrvDeReg) message.
登録は、登録更新は、サービス登録（のSrvReg）またはサービス登録解除（SrvDeReg）メッセージを指す更新します。
Registration State A registration state refers to an entry in the registration database.
登録状態登録状態は、登録データベース内のエントリを参照します。
Accept DA When a DA accepts a registration update from an SA, the DA is the accept DA for the update.
DAは、SAからの登録更新を受け付けるとDAを受け入れ、DAは、更新のためにDAを受け入れています。
Accept Timestamp The arrival timestamp of a registration update at its accept DA is the accept timestamp of the update. All accept timestamps assigned by the same DA MUST be monotonically increasing.
更新のタイムスタンプを受け入れているタイムスタンプにその受け入れDAに登録更新の到着タイムスタンプを受け入れます。すべてが同じDA単調に増加しなければならないことにより、割り当てられたタイムスタンプを受け入れます。
Version Timestamp When an MSA sends a registration update to an MDA, the MSA assigns a version timestamp to the update. All version timestamps assigned by the same MSA MUST be monotonically increasing.
MSAは、MDAに登録更新を送るバージョンタイムスタンプは、MSAは、更新にバージョンタイムスタンプを割り当てます。同じMSAによって割り当てられたすべてのバージョンのタイムスタンプは単調に増加しなければなりません。
mSLP is designed as a lightweight enhancement to SLPv2. It is backward compatible with SLPv2. mSLP defines two enhanced entities: MDAs and MSAs. They can be deployed incrementally. An enhanced entity supports extended operations without affecting its original functionality as defined in RFC 2608 [RFC2608]. For simplicity and
MSLPはSLPv2のに軽量の拡張として設計されています。それはSLPv2のとの下位互換性があります。 MDAとのMSA：MSLPは2つの強化のエンティティを定義します。彼らは、インクリメンタルに展開することができます。強化されたエンティティは、RFC 2608 [RFC2608]で定義されるように、元の機能に影響を与えることなく、拡張操作をサポートしています。簡略化のためにと
compatibility, an enhanced entity works as a non-enhanced entity to interact with non-enhanced entities. Table 1 summarizes all interactions involving an MDA or MSA.
互換性は、強化されたエンティティは、非強化エンティティと対話する非強化エンティティとして動作します。表1は、MDAまたはMSAを含むすべての相互作用をまとめました。
Interaction Equivalent To Defined In
----------------------------------------------
MDA <--> MDA mSLP
MDA <--> MSA mSLP
MDA <--> DA DA <--> DA RFC 2608
MDA <--> SA DA <--> SA RFC 2608
MDA <--> UA DA <--> UA RFC 2608
MSA <--> DA SA <--> DA RFC 2608
MSA <--> UA SA <--> UA RFC 2608
Table 1. Interactions involving an MDA or MSA
MDAまたはMSAを含む表1の相互作用
(x,y)
+--------------------------------------------------+
| +------------+ |
| | MDA4 (z) | |
| +------------+ |
| | (z) |
+------------+ (y) +------------+ (y) +------------+
| MDA1 (x,y) | ---------- | MDA3 (y,z) | ---------- | MDA2 (x,y) |
+------------+ +------------+ +------------+
Figure 1. A scope-based fully-meshed peering DA architecture
図1スコープ・ベースのフルメッシュのピアリングDAアーキテクチャ
mSLP employs a scope-based fully-meshed peering DA architecture. For each scope, all MDAs that serve the scope form a fully-meshed peer relationship. Figure 1 shows an example for four MDAs and three scopes (x, y, and z). Note that a single peering connection is needed between two peers for exchanging all service registrations in their shared scopes.
MSLPスコープベースのフルメッシュのピアリングDAアーキテクチャを採用しています。各スコープのため、スコープを提供すべてのMDAは、フルメッシュピア関係を形成します。図1は、4個のMDAと3つのスコープ（x、y及びz）のための例を示しています。単一ピアリング接続は、共有スコープ内のすべてのサービス登録を交換するために2つのピア間で必要とされていることに注意してください。
This architecture enhances SLP DA services. First, it improves the consistency among peer DAs by automatically reconciling inconsistent states among them. Second, it enables newly booted and rebooted MDAs to catch up on all new registrations at once from their peers, purely through DA interaction, without involving SAs.
このアーキテクチャは、SLP DAサービスを強化します。まず、それは自動的にそれらの間で一貫性のない状態を両立することにより、ピアDAの間の整合性を向上させます。第二に、それは新たにブート可能とSAを介さず、純粋にDAの相互作用を通じて、仲間から一度にすべての新規登録に追いつくためのMDAを再起動しました。
This architecture also simplifies SA registrations. In SLPv2, an SA needs to discover and register with all existing DAs in its scopes, and re-register when new DAs are discovered or old DAs are found to have rebooted. In mSLP, for all MDAs, an MSA only needs to discover and register with a sufficient number of them, such that the union of their scopes covers its scopes; the registrations will then be propagated automatically to other MDAs in the registration scopes. For example, in Figure 2, MSA1 only needs to discover and register with MDA2, or with both MDA1 and MDA3.
このアーキテクチャはまた、SAの登録を簡素化します。 SLPv2のでは、SAが発見し、そのスコープ内のすべての既存DAに登録し、新しいDAのが発見されているか、古いDAのが再起動しているが発見された場合、再登録する必要があります。 MSLPでは、すべてのMDAのために、MSAはそのスコープの労働組合は、そのスコープを覆うように、発見し、それらの十分な数に登録する必要があります。登録は、登録のスコープ内の他のMDAに自動的に伝播されます。例えば、図2において、MSA1のみMDA2と、又はMDA1とMDA3の両方で発見および登録する必要があります。
(option2) +------------+ (option2)
+----------------- | MSA1 (x,y) | -----------------+
| +------------+ |
| | (option1) |
V V V
+----------+ +------------+ +----------+
| MDA1 (x) | ----------- | MDA2 (x,y) | ----------- | MDA3 (y) |
+----------+ +------------+ +----------+
Figure 2. Options for registering with MDAs
MDAを登録するための図2.オプション
Furthermore, this architecture provides scaling advantages. Consider a scope that has N SAs and M DAs, and assume N > M >= 2. Although mSLP and SLPv2 need the same number of SLP messages to distribute registrations from N SAs to M DAs, mSLP can reduce the number of agents needed for taking care of registration distribution, and reduce the number of TCP connections needed if each SA uses TCP for its registrations. More specifically, the agents that need to take care of registration distribution are all N SAs in SLPv2, but only M DAs in mSLP. Also, the number of needed TCP connections is N*M in SLPv2 as each SA has to connect with each DA and register, but only N+M*(M-1)/2 in mSLP as each SA only needs to connect to one contacting DA of a full mesh of M node and register, then registrations are propagated through the DA mesh. For N=100 and M=10, SLPv2 needs 1000 TCP connections, but mSLP only needs 145 such connections.
さらに、このアーキテクチャはスケーリングの利点を提供します。 MSLPとSLPv2のは、M DAのにNのSAからの登録を配布するためにSLPメッセージの同じ番号が必要ですが、> M> = 2 N SASおよびM DAを持っている範囲を考えると、Nを想定し、MSLPはのために必要なエージェントの数を減らすことができます登録分布の世話をし、各SAは、その登録にTCPを使用する場合に必要なTCP接続の数を減らします。具体的には、登録分布の世話をする必要がある薬はSLPv2の中のすべてのNのSAですが、MSLPで唯一のM DAを。各SAは一つだけに接続する必要があるように、各SAはMSLPに各DAと接続し、登録しなければならないが、唯一のN + M *（M-1）/ 2としても、必要なTCP接続の数は、SLPv2の中にN * MでありますMノードのフルメッシュのDAに連絡して登録し、登録はDAメッシュを介して伝播されています。 N = 100、M = 10のため、SLPv2の1000のTCP接続を必要とするが、MSLPは、145このような接続を必要とします。
Note that as mSLP employs full-mesh topology, which is mainly for simplicity and reliability, it cannot scale to a large number of MDAs in a single mesh. In general, mSLP can be applied if the number of MDAs in a mesh is on the order of tens or below. One way to avoid having a large number of MDAs in a mesh is to split the scope into several finer scopes. For example, if we have N MDAs for scope "x", and N is too large, then we can split "x" into two finer scopes: "x-1" and "x-2", with N1 MDAs for "x-1" only, N2 MDAs for "x-2" only, N3 MDAs for both "x-1" and "x-2", and N1+N2+N3=N. Thus, instead of having a large full mesh of size N, we now have two smaller full meshes of size N1+N3 and N2+N3, respectively. Accordingly, a service registration that previously targets for scope "x", now needs to be registered under both "x-1" and "x-2".
MSLPは簡潔性と信頼性のために主にフルメッシュトポロジーを採用として、それは1つのメッシュ中のMDAの多数に拡張することができないことに留意されたいです。メッシュ内のMDAの数は、以下の数十又は程度である場合、一般に、MSLPを適用することができます。メッシュ内のMDAの数が多い回避する1つの方法は、いくつかの細かいスコープにスコープを分割することです。私たちはスコープのためのNのMDA「x」を持っている、とNが大きすぎる場合、例えば、我々は2つの細かいスコープに「x」を分割することができます：「X-1」と「X-2」、N1のMDAとX」のために-1" のみのためN2のMDA "X-2" のみ、N3のMDAの両方のための "X-1"、 "X-2"、及びN1 + N2 + N3 = N。したがって、代わりにサイズNの大規模なフルメッシュを有するので、私たちは今、それぞれ、サイズN1 + N3とN2 + N3の2つの小さなフルメッシュを持っています。したがって、以前に「X」範囲のために標的とサービス登録は、今や両方の「X-1」、「X-2」の下で登録される必要があります。
An MDA can learn about new peers via static configuration, DHCP [RFC2610], and DAAdvert multicast and unicast. In any case, an MDA MUST get a peer's DAAdvert before establishing a peer relationship to the peer.
MDAは静的設定、DHCP [RFC2610]、およびDAAdvertマルチキャストおよびユニキャストを介した新しいピアについて学ぶことができます。いずれにせよ、MDAは、ピア・ツー・ピア関係を確立する前に、ピアのDAAdvertを取得する必要があります。
After getting a new peer's DAAdvert, an MDA establishes a peering connection (if such a connection does not exist yet) to the peer, and sends its DAAdvert via the connection (Figure 3). An MDA can identify a peering connection initiated by a peer by receiving the peer's DAAdvert from the connection. Normally, a single peering connection is set up between two peers, but there is a small possibility that a pair of peering connections might be created between two peers if they try to initiate a connection to each other at almost the same time. Thus, when an MDA identifies a new peering connection initiated by a peer, it SHOULD check whether it has initiated another peering connection to the peer. If this is the case, and it has a lower-numbered IP address than the peer, then the MDA SHOULD terminate the connection it has initiated.
新たなピアのDAAdvertを取得した後、MDAは、ピアに（そのような接続がまだ存在しない場合）ピアリング接続を確立し、接続（図3）を介してそのDAAdvertを送信します。 MDAは、接続からピアのDAAdvertを受信することによって、ピアによって開始さピアリング接続を識別することができます。通常、単一ピアリング接続が2つのピア間で設定するが、彼らはほぼ同時に互いにへの接続を開始しようとすると、ピアリング接続のペアは2つのピア間に作成されるかもしれないという可能性は少ないです。 MDAは、ピアによって開始された新たなピアリング接続を識別する場合したがって、それはピアへの別のピアリング接続を開始したかどうかを確認する必要があります。これが事実である、そしてそれは、ピアよりも小さい番号のIPアドレスを持っている場合、MDAは、それが開始した接続を終了する必要があります。
+------+ (1) MDA2's DAAdvert | +------+
| | <----------------------+ | |
| MDA1 | (2) Create a Peering Connection | MDA2 |
| | ---------------------------------------> | |
+------+ (3) MDA1's DAAdvert +------+
Figure 3. Establishing a peering connection
図3.ピアリング接続の確立
After establishing a peering connection, two peers (say, MDA1 and MDA2) exchange information about their existing peers by forwarding peers' DAAdverts via the peering connection (Figure 4). MDA1 will forward the DAAdvert of a peer (say, MDA3) to MDA2 if:
ピアリング接続を確立した後ピアリング接続（図4）を介して、ピアのDAAdvertsを転送することによって、既存のピアに関する二つのピア（例えば、MDA1及びMDA2）情報を交換します。 MDA1はMDA2場合にピアのDAAdvert（たとえば、MDA3）を転送します。
(1) MDA3 shares scopes with MDA2, and (2) MDA3 is an active peer of MDA1 (i.e., there is a peering connection between MDA3 and MDA1) or an accept DA for registrations currently maintained by MDA1 (i.e., MDA1 has registrations originally accepted by MDA3).
（1）MDA3株はMDA2とスコープ、および（2）MDA3はMDA1のアクティブピアである（すなわち、MDA3とMDA1間のピアリング接続がある）、または（すなわち、MDA1が本来登録を有する現在MDA1によって維持登録するためのDAを受け入れますMDA3で）受け入れました。
MDA2 operates similarly. Note that all DAAdverts can be sent as one TCP stream for efficiency. Exchanging information about existing peers enables an MDA to learn about new peers incrementally.
MDA2は同様に動作します。すべてDAAdvertsは、効率化のため、1つのTCPストリームとして送信することができることに注意してください。既存のピアに関する情報を交換することMDAは、増分新しい仲間について学ぶことができます。
+------+ DAAdverts of MDA1's existing peers +------+
| | ------------------------------------------> | |
| MDA1 | (Peering Connection) | MDA2 |
| | <------------------------------------------ | |
+------+ DAAdverts of MDA2's existing peers +------+
Figure 4. Exchanging information about existing peers
図4.既存のピアに関する情報を交換します
+------+ MDA1's DAAdvert +------+
| | ---------------------------------------> | |
| MDA1 | (Peering Connection) | MDA2 |
| | <--------------------------------------- | |
+------+ MDA2's DAAdvert +------+
Figure 5. Maintaining a peer relationship
図5ピア関係を維持
To detect failures (network partitions and peer crashes), mSLP uses a heart-beat mechanism. An MDA sends its DAAdvert to peers (Figure 5) every CONFIG_DA_KEEPALIVE seconds. The timeout value for this message is CONFIG_DA_TIMEOUT seconds (Section 6).
障害（ネットワークパーティションとピア・クラッシュ）を検出するために、MSLPは、ハートビートメカニズムを使用しています。 MDAは、ピアへのDAAdvert（図5）すべてのCONFIG_DA_KEEPALIVE秒を送信します。このメッセージのタイムアウト値はCONFIG_DA_TIMEOUT秒（第6節）です。
An MDA SHOULD tear down a peer relationship when it finds that the peer has closed the peering connection, when it receives a DAAdvert multicast from the peer with a DA stateless boot timestamp set to 0 (meaning that the peer is going to shutdown), or when it has not received the peer's DAAdvert for more than CONFIG_DA_TIMEOUT seconds.
MDAは、それが0に設定DAステートレスブートタイムスタンプを持つピアからのDAAdvertマルチキャストを受信したとき、ピアは、ピアリング接続を閉鎖したと認めるときは（ピアがシャットダウンしようとしていることを意味する）ピア関係を取り壊すか、すべきですそれはCONFIG_DA_TIMEOUT秒以上の間、ピアのDAAdvertを受信していないとき。
When an MDA accepts a registration update from an MSA, the MDA assigns a unique accept ID to the update. An accept ID has two components: an accept DA URL and an accept timestamp. The accept timestamp is a 64-bit integer representing elapsed microseconds since 00:00 Coordinated Universal Time (UTC), January 1, 1900. Figure 6 shows the format for an accept ID entry. A registration state has the same accept ID as that of the latest update applied to it.
MDAは、MSAから登録更新を受け付けると、MDAは、更新にIDを受け入れるユニークを割り当てます。受け入れDA URLと受け入れタイムスタンプ：受け入れるIDは、2つのコンポーネントがあります。受け入れるタイムスタンプ00:00協定世界時（UTC）からの経過ミリ秒を表す64ビットの整数であり、1月1日、1900図6は、IDの入力を受け付けるためのフォーマットを示します。登録状態は、それに適用される最新のアップデートと同じ受け入れIDを持っています。
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Accept Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Accept Timestamp, cont'd. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length of Accept DA URL | Accept DA URL \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |タイムスタンプを受け入れます| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |タイムスタンプ、続きを受け入れます。| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | DAのURLを受け入れるの長さ| DAのURLを受け入れ\ + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
Figure 6. Accept ID entry
図6. IDエントリを受け入れます
An MDA MUST propagate registrations in the increasing order of their accept IDs, i.e., registrations having the same accept DA MUST be propagated in the increasing order of their accept timestamps. Note that registrations having different accept DAs MAY be propagated in any order.
MDAは、それら受け入れるIDの昇順に登録を伝搬しなければならない、すなわち、それを備えた登録はDAが、その受け入れるタイムスタンプの昇順に伝播されなければならない受け入れます。登録は任意の順序で増殖させることができる別の受け入れDAを持つことに注意してください。
When registrations are propagated among MDAs, their arrival timestamps at MDAs cannot be used for version resolution. For example, assume that MSA1 sends a registration (R1) to MDA1 first, and a new version of the same registration (R2) to MDA2 later. When R1 and R2 are propagated, the arrival timestamp of R1 at MDA2 is later than that of R2, but R1 SHOULD NOT overwrite R2 at MDA2 as R2 is a newer version.
登録はのMDAの間で伝播された場合、のMDAに到着タイムスタンプは、バージョンの解決のために使用することはできません。例えば、MSA1は最初MDA1に登録（R1）を送信し、以降MDA2する同じ登録（R2）の新しいバージョンと仮定する。 R1とR2が伝播される場合は、MDA2でR1の到着タイムスタンプは、後にR2よりもですが、R2は新しいバージョンであるとして、R1はMDA2でR2を上書きすべきではありません。
mSLP resolves registration versions using version timestamps. When an MSA sends a registration update to an MDA, the MSA assigns a version timestamp to the update. The version timestamp is a 64-bit integer representing elapsed microseconds since 00:00 UTC, January 1, 1900. mSLP assumes that each registration is updated only by one SA, thus an MDA does not need to compare version timestamps from different MSAs. An MDA installs a registration update if the update has a newer version timestamp (from an MSA), or the update does not have the Mesh Forwarding extension (from a non-MSA).
MSLPは、バージョンのタイムスタンプを使用して、登録のバージョンを解決します。 MSAはMDAに登録更新を送信する場合、MSAは、更新のバージョンのタイムスタンプを割り当てます。バージョンのタイムスタンプ00:00 UTC年1月1日からの経過ミリ秒を表す64ビットの整数である、1900 MSLPがそれぞれ登録一SAによってのみ更新されることを前提とし、このようにMDAは、別のMSAからバージョンタイムスタンプを比較する必要はありません。更新は、（MSA）から新しいバージョンのタイムスタンプを有する場合MDAは、登録更新をインストールし、または更新が（非MSAから）メッシュ転送拡張機能を有していません。
The Mesh Forwarding (MeshFwd) extension carries a version timestamp and an accept ID entry. Figure 7 shows its format and two defined Forwarding IDs (Fwd-IDs).
メッシュ転送（MeshFwd）拡張バージョンのタイムスタンプを搬送し、IDの入力を受け付けます。図7は、そのフォーマット及び2つの定義された転送のID（FWD-ID）を示します。
The MeshFwd extension is used with a Srv(De)Reg message, but it can only be used with a fresh SrvReg, or a complete SrvDeReg.
MeshFwd拡張はSRV（DE）レッグメッセージで使用され、それだけで、新鮮なのSrvReg、または完全SrvDeRegと共に使用することができます。
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MeshFwd Extension ID = 0x0006 | Next Extension Offset (NEO) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NEO, cont'd. | Fwd-ID | Version Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version Timestamp, cont'd. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version Timestamp, cont'd. | Accept ID Entry \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | MeshFwd拡張ID = 0x0006 |次の拡張オフセット（NEO）| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | NEO、続き。| FWD-ID |バージョンタイムスタンプ| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |バージョンタイムスタンプ、続き。| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |バージョンタイムスタンプ、続き。| IDエントリを受け入れる\ + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
Fwd-ID Abbreviation
1 RqstFwd
2 Fwded
Figure 7. MeshFwd extension and its Fwd-IDs
図7. MeshFwd拡張とそのFWD-IDの
An MSA uses the RqstFwd MeshFwd extension (Fwd-ID = RqstFwd, accept timestamp = 0) in a Srv(De)Reg to explicitly request an MDA (the accept DA) to forward the message.
MSAは、明示的にメッセージを転送するMDA（DAを受け入れる）を要求するSRV（DE）のRegに（FWD-ID = RqstFwd、= 0タイムスタンプを受け入れる）RqstFwd MeshFwd拡張子を使用します。
An MDA uses the Fwded MeshFwd extension (Fwd-ID = Fwded, accept timestamp != 0) in each Srv(De)Reg sent from it to another MDA, either forwarding a Srv(De)Reg received from an MSA (if the message has the RqstFwd MeshFwd extension), or propagating a registration state in its database.
MDAはFwded MeshFwd拡張使用（FWD-ID = Fwdedを、タイムスタンプを受け入れる！= 0）各SRV（DE）のReg別のMDAにから送信された、いずれかのSRV（DE）レッグを転送するメッセージ場合MSA（から受信RqstFwd MeshFwd拡張）、またはそのデータベース内の登録状態を伝播を有します。
An MDA uses a summary vector to represent its received Srv(De)Reg(s) that have a MeshFwd extension. This summary vector records the latest accept timestamp for each accept DA that appears in the MeshFwd extension. For example, consider n MDAs for a scope, if MDAi has a summary vector as ((MDA1, T1), (MDA2, T2), ..., (MDAn, Tn)), then MDAi has received all registrations originally accepted by MDAj up to timestamp Tj, where 1<=i,j<=n.
MDAはMeshFwd拡張子を持つその受信SRV（DE）レッグ（複数可）を表すために要約ベクトルを使用します。この要約ベクトルは、各MeshFwd拡張に表示されてDAを受け入れるための最新の受け入れのタイムスタンプを記録します。例えば、MDAiは（（MDA1、T1）、（MDA2、T2）、...、（MDAN、TN））として要約ベクトルを有する場合、次いでMDAiは、もともとによって受け入れられるすべての登録を受けた、スコープのn個のMDAを検討MDAj 1 <= I、J <= N Tjのを、タイムスタンプにアップ。
An MDA updates its summary vector when it receives a Srv(De)Reg that has a MeshFwd extension. The MDA adds a new accept ID to its summary vector if the Srv(De)Reg has a new accept DA; the MDA updates the accept timestamp of an existing accept ID in its summary vector if the Srv(De)Reg has an existing accept DA.
それはMeshFwd拡張子がSRV（DE）レッグを受信したときにMDAは、その要約ベクトルを更新します。 SRV（デ）REGを新たに受け入れるDAを持っている場合MDAは、その要約ベクトルに新しい受け入れIDを追加します。 MDAは、SRV（DE）REGを既存のDAを受け入れるを持っている場合、既存の要約ベクトルにIDを受け入れるの受け入れタイムスタンプを更新します。
When an MDA receives a SrvDeReg that has a MeshFwd extension, it SHOULD retain the corresponding registration in the database, and mark it as deleted. This way, the registration will not appear in any query reply, and an earlier SrvReg will not mistakenly cause the registration to reappear in the database. A registration state will be purged from the database when it expires.
MDAはMeshFwd拡張子がSrvDeRegを受信すると、それはデータベース内の対応する登録を保持しなければならず、削除されたとしてマーク。この方法では、登録は任意のクエリ応答には表示されませんし、それ以前のSrvRegが誤って登録がデータベースに再表示することはありません。それが期限切れになったときに、登録状態がデータベースから削除されます。
The Anti-entropy Request (AntiEtrpRqst) message carries an anti-entropy type ID and a list of accept ID entries. Figure 8 shows its format and two defined anti-entropy type IDs.
アンチエントロピー要求（AntiEtrpRqst）メッセージは、抗エントロピー型IDと受け入れるIDエントリのリストを運びます。図8は、そのフォーマット及び2つの定義されたアンチエントロピータイプIDを示します。
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Location Header (AntiEtrpRqst Function-ID = 12) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Anti-Entropy Type ID | Number of Accept ID Entries | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Accept ID Entry 1 . . . Accept ID Entry k \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |サービスロケーションヘッダー（AntiEtrpRqst機能-ID = 12）| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |アンチエントロピータイプID |受け入れIDエントリの数| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | IDエントリ1を受け入れます。 。 。 IDエントリのkを受け入れる\ + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
Anti-Entropy Type Type ID
selective 1
complete 2
Figure 8. AntiEtrpRqst message and anti-entropy types
図8 AntiEtrpRqstメッセージおよび抗エントロピタイプ
The AntiEtrpRqst message is used by an MDA to request new registration states from a peer. The anti-entropy type is either selective or complete. If the anti-entropy type is selective, only registration states that have an accept ID greater than any specified accept ID in the message are requested. If the anti-entropy type is complete, all registration states that have an accept ID greater than any specified accept ID in the message or have an accept DA not specified in the message are requested.
AntiEtrpRqstメッセージがピアから新規登録の状態を要求するためにMDAによって使用されます。抗エントロピータイプは、選択的または完全のいずれかです。抗エントロピータイプが選択された場合、任意のメッセージでIDを受け入れ、指定よりも大きいIDを受け入れてきただけの登録状態が要求されています。抗エントロピータイプが完了している場合は、任意のメッセージでIDを受け入れるか、メッセージに指定されていないDAを受け入れている指定されたよりも大きいIDを受け入れてきたすべての登録状態が要求されています。
For example, consider three MDAs (MDA1, MDA2, and MDA3) for a scope. MDA2 has registration states originally accepted by MDA1, MDA2, and MDA3. If MDA1 sends a selective AntiEtrpRqst to MDA2 using an accept ID list as ((MDA2, T2)), then MDA1 only requests registration states that are originally accepted by MDA2, and have an accept timestamp greater than T2. If MDA1 sends a complete AntiEtrpRqst to MDA2 using an accept ID list as ((MDA2, T2)), then MDA1 requests all registration states originally accepted by MDA1 and MDA3, plus those originally accepted by MDA2 and having an accept timestamp greater than T2.
たとえば、スコープのための3つのMDA（MDA1、MDA2、及びMDA3）を考えます。 MDA2はもともとMDA1、MDA2、およびMDA3によって承認された登録状態を有します。 MDA1は（（MDA2、T2））などのIDリストを受け入れるを使用してMDA2に選択AntiEtrpRqstを送信した場合、その後、MDA1はもともとMDA2によって受け入れられた登録状態を要求し、T2よりも大きいタイムスタンプを受け入れています。 MDA1は（（MDA2、T2））などのIDリストを受け入れるを使用してMDA2に完全AntiEtrpRqstを送信した場合、その後、MDA1は、すべての登録はもともとMDA1とMDA3に受け入れられ、プラスもともとMDA2によって受け入れられたものとT2よりも大きいタイムスタンプを受け入れた状態要求します。
Anti-entropy is used for exchanging initial registration states when two peers recognize each other for the first time, and for updating new registration states after failures.
アンチエントロピーは、2つのピアが初めてお互いを認識したときに、初期登録状態を交換すると失敗した後、新規登録の状態を更新するために使用されます。
When an MDA receives an AntiEtrpRqst from a peer, it sends the requested new registration states in the increasing order of their accept IDs. At last a Service Acknowledgment (SrvAck) message is sent to indicate that the processing of a corresponding AntiEtrpRqst has been completed (Figure 9). A new registration state is sent as a fresh SrvReg with its remaining lifetime. A newly deregistered state is propagated as a SrvDeReg. Note that multiple Srv(De)Reg(s) can be sent as one TCP stream for efficiency.
MDAは、ピアからAntiEtrpRqstを受信すると、それは彼らの受け入れIDの昇順に要求された新たな登録の状態を送信します。最後にサービス承認（SrvAck）メッセージ（図9）に対応するAntiEtrpRqstの処理が完了したことを示すために送信されます。新規登録の状態は、その残りの寿命と新鮮なのSrvRegとして送信されます。新しく登録解除状態がSrvDeRegとして伝播されます。複数のSRV（DE）のReg（s）は、効率のために1つのTCPストリームとして送信することができることに留意されたいです。
+------+ AntiEtrpRqst +------+
| | -------------------------------------------> | |
| MDA1 | (Peering Connection) | MDA2 |
| | <------------------------------------------- | |
+------+ New States via Srv(De)Reg(s) + SrvAck +------+
Figure 9. Anti-entropy via AntiEtrpRqst, Srv(De)Reg(s) and SrvAck
AntiEtrpRqstを介して図9アンチエントロピー、SRV（DE）のReg（S）とSrvAck
+------+ RqstFwd Srv(De)Reg +------+ Fwded Srv(De)Reg +------+
| | ---------------------> | | --------------------> | |
| MSA1 | | MDA1 | | MDA2 |
| | <--------------------- | | | |
+------+ SrvAck +------+ +------+
Figure 10. Direct forwarding of a Srv(De)Reg
SRV（DE）レッグの図10.直接転送
After sending all new registration states accepted by itself to a peer (via anti-entropy), an MDA directly forwards newly received registration updates from MSAs to the peer until a failure occurs.
障害が発生するまで（アンチエントロピーを介して）ピアにそれ自体によって受け入れすべての新規登録の状態を送信した後、MDAは、直接のMSAからピアに新たに受信した登録更新を転送します。
In Figure 10, when a Srv(De)Reg is directly forwarded from MDA1 to MDA2, its Fwd-ID is set to Fwded, and its accept timestamp is set to its arrival timestamp at MDA1. Note that a direct forwarding is performed asynchronously: MDA1 can send a SrvAck to MSA1 before it forwards the Srv(De)Reg to MDA2. Also note that the direct forwarding of a Srv(De)Reg goes only one-hop from its accept DA (say, MDA1) to all MDA1's peers that are in the registration scopes.
SRV（DE）のReg直接MDA2にMDA1から転送され、図10では、そのFWD-IDはFwdedに設定され、その受け入れるタイムスタンプはMDA1におけるその到着タイムスタンプに設定されています。直接転送が非同期で実行されることに注意してください：それはMDA2にSRV（デ）レッグを転送する前に、MDA1はMSA1にSrvAckを送ることができます。また、SRV（デ）のRegの直接転送は、登録のスコープ内にあるすべてのMDA1のピアにそのDAを受け入れる（たとえば、MDA1）から一つだけホップを行くことに注意してください。
According to [RFC2608], a DA MUST reply with a SrvAck to a Srv(De)Reg when the message is received from an SA. However, an MDA SHOULD NOT reply with a SrvAck to a Srv(De)Reg if the message is received from a peer. This is for efficiency because peers exchange Srv(De)Reg messages via reliable peering connections. Note that an MDA MUST reply with a SrvAck to an AntiEtrpRqst.
[RFC2608]によれば、DAは、メッセージがSAから受信されるSRV（DE）レッグにSrvAckで応答しなければなりません。メッセージがピアから受信された場合は、MDAは、SRV（DE）レッグにSrvAckで応答すべきではありません。ピアが信頼できるピアリング接続を介してSRV（デ）のRegのメッセージを交換するので、これは効率のためです。 MDAはAntiEtrpRqstにSrvAckで返答しなければならないことに注意してください。
For each registration entry, an MDA maintains the following control information: an accept ID (for registration propagation), a version timestamp (for registration version resolution - rejecting previous updates), and a deletion flag (deregistered or not).
- 、および削除フラグ（登録解除またはしない）（登録伝播の）IDを受け入れ、（以前の更新を拒否する登録バージョン解像度用）バージョンのタイムスタンプ：各登録エントリに対して、MDAは、以下のような制御情報を保持します。
For all registration entries, an MDA maintains a summary vector to reflect its received registrations so far.
すべての登録エントリの場合、MDAは、これまでの受信登録を反映する要約ベクトルを維持しています。
mSLP extends SLPv2 with three new definitions: a new attribute - "mesh-enhanced" for DAAdvert, a new message extension - MeshFwd, and a new message type - AntiEtrpRqst.
- 「メッシュ強化」DAAdvertため、新しいメッセージ拡張 - MeshFwd、および新しいメッセージタイプ - AntiEtrpRqst新しい属性：MSLP 3つの新しい定義でSLPv2のを拡張します。
A UA MAY prefer an MDA to a non-MDA since an MDA is more likely to reliably contain the complete set of current service registrations for the UA's scopes.
MDAは確実にUAのスコープの現在のサービス登録の完全なセットが含まれている可能性が高いので、UAは非MDAにMDAを好むかもしれません。
A non-MSA needs to discover and register with all DAs in its scopes. It does not use the MeshFwd extension.
非MSAは、発見とそのスコープ内のすべてのDAに登録する必要があります。それはMeshFwd拡張子を使用しません。
A non-MDA accepts Srv(De)Reg(s) from SAs. It does not forward them.
非MDAは、SASからSRV（DE）レッグ（複数可）を受け付けます。これは、それらを転送しません。
For all MDAs, an MSA only needs to discover and register with sufficient number of them, such that they cover its scopes. It uses the MeshFwd extension when it registers with MDAs.
すべてのMDAのために、MSAは、彼らがそのスコープをカバーするように、それらの十分な数を発見し、登録する必要があります。それはのMDAに登録するときにはMeshFwd拡張子を使用しています。
An MDA carries the "mesh-enhanced" attribute keyword in its DAAdvert. It maintains a peer relationship to each peer. It accepts registrations from SAs and peers, propagates registrations via anti-entropy and direct forwarding to peers.
MDAは、そのDAAdvertの「メッシュ強化」属性キーワードを運びます。これは、各ピアにピア関係を維持しています。これは、SASおよびピアから登録を受け付けるアンチエントロピー及びピアへの直接転送を介して登録を伝播します。
Interval Name Default Value Defined in
------------------- ------------- -----------
CONFIG_DA_KEEPALIVE 200 seconds Section 3.4
CONFIG_DA_TIMEOUT 300 seconds Section 3.4
The Mesh Forwarding (MeshFwd) extension ID, 0x0006, described in Section 4.3, has been assigned by IANA out of the SLP extension space (RFC 2608, Section 9.1) reserved for "optional to implement" extensions (i.e., the 0x0000-0x3FFF range).
4.3節で説明したメッシュフォワーディング（MeshFwd）拡張ID、0x0006は、SLPの拡張スペース（RFC 2608、セクション9.1）のうち、IANAによって割り当てられている「実装するために、オプションの」拡張（すなわち、0x0000-0x3FFF範囲のために予約）。
The function-ID of the Anti-entropy Request (AntiEtrpRqst) message type, 12, described in Section 4.6, has been assigned by IANA (RFC 2608, Section 15).
セクション4.6に記載の抗エントロピ要求（AntiEtrpRqst）メッセージタイプ、12の機能-IDは、IANA（RFC 2608、セクション15）によって割り当てられています。
mSLP uses standard SLPv2 authentication. First, an MDA SHOULD authenticate other MDAs before setting up a peer relationship with them so as to prevent any malicious MDA from joining the DA mesh. Second, as a successful attack at an MDA may affect all MDAs in the DA mesh, an MDA SHOULD authenticate MSAs before accepting and forwarding their Srv(De)Reg messages to prevent illegitimate modification or elimination of service registrations. Third, as an MSA depends on the MDA with which it registers to forward its Srv(De)Reg messages, it SHOULD authenticate the MDA to avoid using a malicious MDA.
MSLPは標準SLPv2の認証を使用しています。 DAメッシュに参加する任意の悪意のあるMDAを防止するためにまず、MDAは、彼らと対等の関係を設定する前に他のMDAを認証する必要があります。第二に、DAメッシュ内のすべてのMDAに影響を与える可能性がMDAで成功した攻撃として、MDAは受け入れ、違法な変更またはサービス登録の排除を防ぐために、彼らのSRV（デ）のRegメッセージを転送する前のMSAを認証する必要があります。 MSAは、それはそのSRV（デ）のRegメッセージを転送するために登録するとMDAに依存する第三に、それは悪質なMDAを使用しないようにMDAを認証する必要があります。
Thomas Narten, James Kempf, Mike Day, Mikael Pahmp, Ira McDonald, Qiaobing Xie and Xingang Guo provided valuable comments for this document.
トーマスNarten氏、ジェームズ・ケンプ、マイク・デイ、ミカエルPahmp、アイラマクドナルド、Qiaobing謝と新港郭はこのドキュメントのための貴重なコメントを提供しました。
[RFC2608] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service Location Protocol, Version 2", RFC 2608, June 1999.
[RFC2608]ガットマン、E.、パーキンス、C.、Veizades、J.とM.日、 "サービスロケーションプロトコル、バージョン2"、RFC 2608、1999年6月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC1771] Rekhter, R. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.
[RFC1771] Rekhter、R.、およびT.李、 "ボーダーゲートウェイプロトコル4（BGP-4）"、RFC 1771、1995年3月。
[RFC2610] Perkins, C. and E. Guttman, "DHCP Options for Service Location Protocol", RFC 2610, June, 1999.
[RFC2610]パーキンス、C.およびE.グットマン、 "サービスロケーションプロトコル用のDHCPオプション"、RFC 2610、1999年6月。
[EPID-ALGO] A. Demers, D. Greene, C. Hauser, W. Irish, J. Larson, S. Shenker, H. Sturgis, D. Swinehart and D. Terry, "Epidemic algorithms for replicated database maintenance", the sixth ACM symposium on principles of distributed computing, Vancouver, Canada, 1987.
[EPID-ALGO] A.デマーズ、D.グリーン、C.ハウザー、W.アイルランド、J.ラーソン、S. Shenker、H.スタージス、D. Swinehart及びD.テリー、 "複製データベースメンテナンスのための流行アルゴリズム"、分散コンピューティングの原理に第ACMシンポジウム、バンクーバー、カナダ、1987。
[UPDA-PROP] K. Petersen, M. Spreizer, D. Terry, M. Theimer and A. Demers, "Flexible update propagation for weakly consistent replication", the sixteenth ACM symposium on operating systems principles, Saint Malo, France, 1997.
[UPDA-PROP] K.ピーターセン、M. Spreizer、D.テリー、M. TheimerおよびA.デマーズ、 "弱一貫性のレプリケーションのための柔軟な更新伝播"、オペレーティングシステムの原理で第十六ACMシンポジウム、サン・マロ、フランス、1997 。
Weibin Zhao Department of Computer Science Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 10027-7003
コンピュータサイエンスコロンビア大学のWeibin趙省1214アムステルダムアベニュー、MC 0401ニューヨーク、NY 10027から7003
EMail: zwb@cs.columbia.edu
メールアドレス：zwb@cs.columbia.edu
Henning Schulzrinne Department of Computer Science Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 10027-7003
コンピュータサイエンスコロンビア大学のヘニングSchulzrinneと学科1214アムステルダムアベニュー、MC 0401ニューヨーク、NY 10027から7003
EMail: hgs@cs.columbia.edu
メールアドレス：hgs@cs.columbia.edu
Erik Guttman Sun Microsystems Eichhoelzelstr. 7 74915 Waibstadt Germany
エリック・グットマンSun MicrosystemsのEichhoelzelstr。 7 74915ヴァイプシュタットドイツ
EMail: Erik.Guttman@sun.com
メールアドレス：Erik.Guttman@sun.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
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 Editor機能のための基金は現在、インターネット協会によって提供されます。