RFC3105 日本語訳
3105 Finding an RSIP Server with SLP. J. Kempf, G. Montenegro. October 2001. (Format: TXT=21427 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Kempf
Request for Comments: 3105 NTT DoCoMo USA Labs
Category: Experimental G. Montenegro
Sun Microsystems
October 2001
コメントを求めるワーキンググループJ.ケンフの要求をネットワークでつないでください: 3105年のNTTドコモ米国研究室カテゴリ: 実験的なG.モンテネグロサン・マイクロシステムズ2001年10月
Finding an RSIP Server with SLP
SLPと共にRSIPサーバを見つけます。
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。
IESG Note
IESG注意
The IESG notes that the set of documents describing the RSIP technology imply significant host and gateway changes for a complete implementation. In addition, the floating of port numbers can cause problems for some applications, preventing an RSIP-enabled host from interoperating transparently with existing applications in some cases (e.g., IPsec). Finally, there may be significant operational complexities associated with using RSIP. Some of these and other complications are outlined in section 6 of the RFC 3102, as well as in the Appendices of RFC 3104. Accordingly, the costs and benefits of using RSIP should be carefully weighed against other means of relieving address shortage.
IESGは、RSIP技術を説明するドキュメントのセットが完全な実装のために重要なホストとゲートウェイ変化を含意することに注意します。 さらに、ポートナンバーの浮動はいくつかのアプリケーションのために問題を起こすことができます、いくつかの場合(例えば、IPsec)、RSIPによって可能にされたホストが透過的に既存のアプリケーションで共同利用するのを防いで。 最終的に、RSIPを使用すると関連している重要な操作上の複雑さがあるかもしれません。 これらと他のいくつかの複雑さがRFC3102のセクション6、およびRFC3104のAppendicesに概説されています。 それに従って、RSIPを使用するコストと利益は慎重にアドレス不足を救う他の手段に比較考量されるべきです。
Abstract
要約
This document contains an SLP service type template that describes the advertisements made by RSIP servers for their services. Service Location Protocol (SLP) is an IETF standards track protocol specifically designed to allow clients to find servers offering particular services. Since RSIP (Realm Specific IP) clients require a mechanism to discover RSIP servers, SLP is a natural match for a solution. The service type template is the basis for an Internet Assigned Numbers Authority (IANA) standard definition of the advertisements offered by RSIP servers, an important step toward interoperability.
このドキュメントは彼らのサービスのためのRSIPサーバによってされた広告について説明するSLPサービスタイプテンプレートを含んでいます。 サービスLocationプロトコル(SLP)はクライアントが、サーバが特定のサービスを提供しているのがわかるのを許容するように明確に設計されたIETF標準化過程プロトコルです。 RSIP(分野Specific IP)クライアントがRSIPサーバを発見するためにメカニズムを必要とするので、SLPはソリューションのための自然なマッチです。 サービスタイプテンプレートはRSIPサーバ(相互運用性に向かった重要なステップ)によって提供された広告のインターネットAssigned民数記Authority(IANA)標準定義の基礎です。
Kempf & Montenegro Experimental [Page 1] RFC 3105 Finding an RSIP Server with SLP October 2001
2001年10月にSLPと共にRSIPサーバを見つけるケンフとモンテネグロの実験的な[1ページ]RFC3105
Table of Contents
目次
1. Introduction ............................................... 2 2. Notation Conventions ....................................... 2 3. Terminology ................................................ 2 4. Using SLP for RSIP Service Discovery ....................... 3 5. Using Scopes for Server Provisioning ....................... 4 6. Load Balancing ............................................. 6 7. The RSIP Service Type Template ............................. 7 8. Security Considerations .................................... 9 9. Summary .................................................... 9 References ..................................................... 9 Authors' Addresses ............................................. 10 Full Copyright Statement ....................................... 11
1. 序論… 2 2. 記法コンベンション… 2 3. 用語… 2 4. RSIPにSLPを使用して、発見を修理してください… 3 5. 使用はサーバの食糧を供給するのに関して見られます… 4 6. ロードバランシング… 6 7. RSIPはタイプテンプレートを調整します… 7 8. セキュリティ問題… 9 9. 概要… 9つの参照箇所… 9人の作者のアドレス… 10 完全な著作権宣言文… 11
1. Introduction
1. 序論
Realm Specific IP (RSIP) [7] enables an RSIP client in one realm to borrow addresses and other resources from another realm. It does so by engaging in an RSIP protocol [1] exchange with an RSIP server. The RSIP protocol requires the RSIP server to have a permanent presence on both realms.
分野Specific IP(RSIP)[7]は、1つの分野のRSIPクライアントが別の分野からアドレスと他のリソースを借りるのを可能にします。 それは、RSIPサーバによるRSIPプロトコル[1]交換に従事していることによって、そうします。RSIPプロトコルは、RSIPサーバが両方の分野に永久的な存在を持っているのを必要とします。
There are a variety of traditional ways an RSIP client could go about locating the appropriate RSIP server. However, Service Location Protocol (SLP) [2][11] is an IETF standards track protocol specifically designed to facilitate location of services and their servers by clients. SLP provides a number of features that simplify locating RSIP servers. In this document, we describe how RSIP clients can use SLP to discover RSIP servers.
RSIPクライアントが適切なRSIPサーバの場所を見つけながら動き回ることができたさまざまな伝統的な方法があります。しかしながら、Service Locationプロトコル(SLP)[2][11]はクライアントでサービスとそれらのサーバの位置を容易にするように明確に設計されたIETF標準化過程プロトコルです。 SLPは場所を見つけることを簡素化する多くの特徴にRSIPサーバを提供します。 本書では、私たちはRSIPクライアントがRSIPサーバを発見するのにどうSLPを使用できるかを説明します。
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 [4].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[4]で説明されるように本書では解釈されることであるべきですか?
3. Terminology
3. 用語
We reproduce here some SLP terminology from [2] for readers unfamiliar with SLP.
私たちはここでSLPになじみのない読者のための[2]から何らかのSLP用語を再生させます。
User Agent (UA)
ユーザエージェント(Ua)
A process working on the user's behalf to establish contact with
some service. The UA retrieves service information from the
Service Agents or Directory Agents.
何らかのサービスで接触するようにユーザの代理に取り組むプロセス。 UAはServiceエージェントかディレクトリエージェントからのサービス情報を検索します。
Kempf & Montenegro Experimental [Page 2] RFC 3105 Finding an RSIP Server with SLP October 2001
2001年10月にSLPと共にRSIPサーバを見つけるケンフとモンテネグロの実験的な[2ページ]RFC3105
Service Agent (SA)
サービスエージェント(SA)
A process working on behalf of one or more services to advertise
the services and their capabilities.
サービスと彼らの能力の広告を出すために1つ以上のサービスを代表して働いているプロセス。
Directory Agent (DA)
ディレクトリエージェント(DA)
A process which collects service advertisements. There can only
be one DA present per given host.
サービス広告を集めるプロセス。 与えられたホストあたりの現在の1DAしかあることができません。
Scope
範囲
A set of services, typically making up a logical administrative
group.
論理的な管理グループを通常構成している1セットのサービス。
Service Advertisement
サービス広告
A URL, attributes, and a lifetime (indicating how long the
advertisement is valid), providing service access information and
capabilities description for a particular service.
サービスを提供するURL、属性、および寿命(広告がどれくらい長い間有効であるかを示す)は特定のサービスのための情報と能力記述にアクセスします。
4. Using SLP for RSIP Service Discovery
4. RSIPサービス発見にSLPを使用します。
SLP provides the framework in which RSIP clients and servers make contact. Here is a description of how an RSIP server and client find each other using SLP:
SLPはRSIPクライアントとサーバが接触を作るフレームワークを提供します。 ここに、RSIPサーバとクライアントがSLPを使用することでどう互いを見つけるかに関する記述があります:
1. The RSIP server implements a SLP SA while the RSIP client
implements an SLP UA.
1. RSIPクライアントはSLP UAを実装しますが、RSIPサーバはSLP SAを実装します。
2. The RSIP SA constructs a service advertisement consisting of a
service URL, attributes and a lifetime. The URL has service type
"service:rsip", and attributes defined according to the template
in Section 7.
2. RSIP SAはサービスURL、属性、および生涯から成るサービス広告を構成します。 URLで、サービスは「サービス: rsip」、およびテンプレートに従ってセクション7で定義された属性をタイプします。
3. If an SLP DA is found, the SA contacts the DA and registers the
advertisement. If no DA is found, the SA maintains the
advertisement itself, answering multicast UA queries directly.
3. SLP DAが見つけられるなら、SAはDAに連絡して、広告を登録します。 DAが全く見つけられないなら、直接マルチキャストUA質問に答えて、SAは広告自体を維持します。
4. When the RSIP client requires contact information for an RSIP
server, the UA either contacts the DA using unicast or the SA
using multicast. The UA includes a query based on the attributes
to indicate the characteristics of the server it requires.
4. RSIPクライアントがRSIPサーバのための問い合わせ先を必要とするとき、マルチキャストを使用することでユニキャストかSAを使用することでUAはDAに連絡します。 UAはそれが必要とするサーバの特性を示すために属性に基づく質問を含んでいます。
5. Once the UA has the host name or address of the RSIP server as
well as the port number, it can begin negotiation using the RSIP
protocol.
5. UAにポートナンバーと同様にRSIPサーバのホスト名かアドレスがいったんあると、それは、RSIPプロトコルを使用することで交渉を始めることができます。
Kempf & Montenegro Experimental [Page 3] RFC 3105 Finding an RSIP Server with SLP October 2001
2001年10月にSLPと共にRSIPサーバを見つけるケンフとモンテネグロの実験的な[3ページ]RFC3105
This procedure is exactly the same for any client/server pair implementing SLP and is not specific to RSIP.
この手順は、まさにSLPを実装するどんなクライアント/サーバ組にも同じであり、RSIPに特定ではありません。
Many protocols use a variety of traditional methods for service discovery. These methods include static configuration, purpose-build protocols for discovery, special features in the protocol itself, DNS SRV RRs [5], or DHCP [6]. SLP provides a number of advantages over these traditional methods:
多くのプロトコルがサービス発見にさまざまな伝統的方法を使用します。 これらのメソッドは静的な構成、発見のための目的で建てているプロトコルを含んでいます、プロトコル自体における特徴、DNS SRV RRs[5]、またはDHCP[6]。 SLPはこれらの伝統的方法より多くの利点を提供します:
1. Discovery of services using SLP is dynamic, whereas many of the
traditional methods only allow static or weakly dynamic (i.e.,
difficult to update) discovery. Clients only discover services
that are actually active with SLP. Furthermore, if subsequent to
initial discovery a server goes down, the client can reissue an
SLP query and obtain a new server. On the server side, no
databases must be updated to provide dynamic discovery, the
servers advertise themselves.
1. SLPを使用するサービスの発見はダイナミックですが、伝統的方法の多くが静的であるか弱々しくダイナミックな(すなわち、アップデートする難しい)発見を許すだけです。 クライアントは実際にSLPと共に活発なサービスを発見するだけです。 その上、サーバが落ちるという発見に頭文字をつけるためにその後なら、クライアントは、SLP質問を再発行して、新しいサーバを得ることができます。サーバ側では、ダイナミックな発見を提供するためにデータベースを全くアップデートしてはいけなくて、サーバは自分を売り込みます。
2. SLP requires no third party configuration. Only the server
offering the service and the client seeking it are required to
know the details for the particular service type.
2. SLPは第三者構成を全く必要としません。 サービスを提供するサーバとそれを探しているクライアントだけが特定のサービスタイプで詳細を知らなければなりません。
3. SLP allows clients to specify the attributes describing the
desired server. A client discovers servers that meet a set of
specific requirements. This reduces the amount of network traffic
involved in selecting a server when many possible choices are
available.
3. SLPはクライアントに必要なサーバについて説明する属性を指定させます。クライアントは1セットの決められた一定の要求を満たすサーバを発見します。 これは多くの可能な選択が利用可能であるときにサーバを選択するのにかかわるネットワークトラフィックの量を減少させます。
4. SLP contains a number of scaling mechanisms (DAs, scopes,
multicast convergence algorithm), that facilitate deployment in
large enterprise networks as well as in smaller networks.
4. SLPは多くのスケーリングメカニズム(DAs、範囲、マルチキャスト集合アルゴリズム)を含んでいて、それは大きい企業網と、より小さいネットワークで展開を容易にします。
5. Using Scopes for Server Provisioning
5. サーバの食糧を供給するのに範囲を使用します。
One particular design feature of SLP that is useful for RSIP is scopes. Scopes in SLP are a mechanism for provisioning access to particular service advertisements. An administrator assigns UAs and SAs to particular scopes to assure that UAs only find SAs in those scopes. Scopes are not an access control mechanism for the service itself, however. UAs from outside the scope can still access services in a particular scope (unless the service itself provides for access control), they just won't be able to find the services using SLP.
RSIPの役に立つSLPの1つの特定の設計上の特徴が範囲です。 SLPの範囲は、特定のサービス広告へのアクセスに食糧を供給するためのメカニズムです。 管理者は、UAsがそれらの範囲でSAsを見つけるだけであることを保証するためにUAsとSAsを特定の範囲に割り当てます。 しかしながら、範囲はサービス自体のためのアクセス管理機構ではありません。範囲の外からのUAsは特定の範囲でまだサービスにアクセスできます(サービス自体がアクセスコントロールに備えない場合)、と彼らはSLPを使用するサービスをただわかることができないでしょう。
Scopes are useful for RSIP service advertisement provisioning because they allow a system administrator to tie particular RSIP clients to specific RSIP servers. For example, consider the network architecture described in Section 4.2.1 of [7]. RSIP clients are
それらがシステム管理者に特定のRSIPクライアントを特定のRSIPサーバに結ばせるので、範囲はRSIPサービス広告の食糧を供給することの役に立ちます。 例えば、[7]についてセクション4.2.1で説明されたネットワークアーキテクチャを考えてください。 RSIPクライアントはそうです。
Kempf & Montenegro Experimental [Page 4] RFC 3105 Finding an RSIP Server with SLP October 2001
2001年10月にSLPと共にRSIPサーバを見つけるケンフとモンテネグロの実験的な[4ページ]RFC3105
recommended to find "the nearest" RSIP server, but exactly how that should be arranged is left unspecified. SLP provides a way for system administrators to precisely specify which realm an RSIP client resides in, by tying the realm to an SLP scope. The diagram from Section 14.1 is reproduced here, with SLP scopes included to illustrate how clients could be directed to the right RSIP servers.
“the nearest" RSIPがサーバであることがわかるために、それがちょうどどうアレンジされるだけであるべきであるかが不特定のままにされることを勧めました。 SLPはシステム管理者が、RSIPクライアントがどの分野で住んでいるかを正確に指定する方法を提供します、SLP範囲に分野をつなぐことによって。 セクション14.1からのダイヤグラムはここで複製されます、SLP範囲がどう正しいRSIPサーバにクライアントを向けることができたかを例証するために含まれている状態で。
+-----------+
| |
| RSIP |
| server +---- 10.0.0.0/8
| B | SLP Scope: B
| |
+-----+-----+
|
| 10.0.1.0/24
+-----------+ | (149.112.240.0/25)
| | |
149.112.240.0/24| RSIP +--+
----------------+ server | SLP Scope: A
| A +--+
| | |
+-----------+ | 10.0.2.0/24
| (149.112.240.128/25)
|
+-----+-----+
| |
| RSIP |
| server +---- 10.0.0.0/8
| C | SLP Scope: C
| |
+-----------+
+-----------+ | | | RSIP| | サーバ+---- 10.0.0.0/8 | B| SLP範囲: B| | +-----+-----+ | | 10.0.1.0/24 +-----------+ | (149.112.240.0/25) | | | 149.112.240.0/24| RSIP+--+----------------+ サーバ| SLP範囲: A| +--+| | | +-----------+ | 10.0.2.0/24 | (149.112.240.128/25) | +-----+-----+ | | | RSIP| | サーバ+---- 10.0.0.0/8 | C| SLP範囲: C| | +-----------+
Clients on the upper 10.0.0.0/8 network are configured to use SLP scope B, while clients on the lower 10.0.0.0/8 network are configured to use SLP scope C. RSIP servers B and C (as clients of server A) use SLP to locate RSIP server A, as do other RSIP clients on the 10.0.1.0/24 and 10.0.2.0/24 subnets. Within these two subnets, all clients have their scopes configured to be A.
上側の10.0.0.0/8ネットワークのクライアントはSLP範囲Bを使用するために構成されます、低い10.0.0.0/8ネットワークのクライアントがSLP範囲C. RSIPサーバBを使用するために構成されます、そして、C(サーバAのクライアントとしての)はRSIPサーバAの場所を見つけるのにSLPを使用しますが、.2.0/24の.1 24と.0/10.0サブネットを10.0の他のRSIPクライアントにするとき。 これらの2の中では、サブネットであり、すべてのクライアントが、Aになるように彼らの範囲を構成させます。
Note that specifying a particular SLP scope for RSIP clients does not restrict the SLP scope for other services advertised by SLP. SLP UAs can be configured for multiple scopes, so the scope configured for printing may be different from the scope configured for RSIP service.
特定のSLP範囲をRSIPクライアントに指定するのがSLPによって広告に掲載された他のサービスのためのSLP範囲を制限しないことに注意してください。 複数の範囲にSLP UAsを構成できるので、印刷のために構成された範囲はRSIPサービスのために構成された範囲と異なっているかもしれません。
Since SLP scopes are configured through a DHCP option [8], along with the IP address, system administrators can easily switch a cluster of machines from one realm to another by simply changing the scope and
そしてSLP範囲がDHCPオプション[8]で構成されるので、IPアドレスと共に、システム管理者が1つの分野から別のものにマシンのクラスタを単に範囲を変えることによって容易に切り換えることができる。
Kempf & Montenegro Experimental [Page 5] RFC 3105 Finding an RSIP Server with SLP October 2001
2001年10月にSLPと共にRSIPサーバを見つけるケンフとモンテネグロの実験的な[5ページ]RFC3105
IP address assignments on the DHCP server. For example, in the above architecture, suppose a system administrator wanted to remove RSIP server B so that clients on the upper 10.0.0.0/8 subnet were directly on subnet 10.0.1.0/24. These clients now communicate with RSIP server A. By simply changing the address assignments and scope configuration of these clients on the DHCP server, the realm can be effectively switched.
IPはDHCPサーバで課題を扱います。そのように、例えば、上側の10.0のそのクライアント、RSIPサーバBを取り除いて欲しくて、上のアーキテクチャシステム管理者であるなら.0.0/8サブネットが直接サブネット10.0.1に.0/24にあります。 これらのクライアントは今、RSIPサーバA.とコミュニケートします。事実上、単にアドレス課題とDHCPサーバのこれらのクライアントの範囲構成、分野を変えるByは切り換えることができます。
6. Load Balancing
6. ロードバランシング
While SLP itself contains no specific provision for load balancing, load balancing can easily be implemented using SLP. The only requirement is that the service type template specify an attribute indicating server load. In the case of RSIP, the service type template in Section 7 contains such an attribute. The attribute indicates the number of RSIP client sessions currently being supported by the server.
SLP自身がロードバランシングへのどんな特定の支給も含んでいない間、SLPを使用することで容易にロードバランシングを実装することができます。 唯一の要件はサービスタイプテンプレートがサーバ負荷を示す属性を指定するということです。 RSIPの場合では、セクション7におけるサービスタイプテンプレートはそのような属性を含んでいます。 属性は現在サーバで後押しされているRSIPクライアントセッションの数を示します。
In order to perform load balancing, the RSIP server must update its service advertisement periodically as new connections are accepted. An RSIP client seeking to find the server having the lightest load performs the following series of SLP operations.
ロードバランシングを実行するために、新しい接続を受け入れるとき、RSIPサーバは定期的にサービス広告をアップデートしなければなりません。 サーバには最も軽い負荷があるのがわかろうとしているRSIPクライアントは以下のシリーズのSLP操作を実行します。
1. As in Section 4, the client issues an SLP service request and
collects all the returned service URLs.
1. セクション4のように、クライアントは、SLPサービスのリクエストを発行して、すべての返されたサービスURLを集めます。
2. For each service URL, the client performs an SLP attribute request
for the attribute LOAD. The integer load figures are returned.
2. それぞれのサービスURLのために、クライアントは属性LOADを求めるSLP属性要求を実行します。 整数負荷数値を返します。
3. The client sorts through the returned load figures and selects the
URL having the least number of connections. The client
establishes its RSIP session with that server.
3. クライアントは、返された負荷の数字を分類して、最少のポートの数を持っているURLを選択します。 クライアントはそのサーバとのRSIPセッションを確立します。
Because of network delays, this procedure does not guarantee that a client will always obtain a connection with the lightest loaded server, but it does provide a high probability that the selected server is more lightly loaded.
ネットワーク遅延のために、この手順は、クライアントがいつも最も軽いロードされたサーバとの関係を得るのを保証しませんが、選択されたサーバが、より軽くロードされるのは高い確率に提供されます。
A similar procedure is used in [9] to load balance access to TN3270E telnet servers.
同様の手順は、TN3270E telnetサーバへのバランスアクセスをロードするのに[9]で用いられます。
Kempf & Montenegro Experimental [Page 6] RFC 3105 Finding an RSIP Server with SLP October 2001
2001年10月にSLPと共にRSIPサーバを見つけるケンフとモンテネグロの実験的な[6ページ]RFC3105
7. The RSIP Service Type Template
7. RSIPサービスタイプテンプレート
Name of submitters: James Kempf <james@docomolabs-usa.com>
Gabriel Montenegro <gab@sun.com>
submittersの名前: ジェームス Kempf <james@docomolabs-usa.com 、gt;、ガブリエル Montenegro <gab@sun.com 、gt。
Language of service template: en
サービステンプレートの言語: アン
Security Considerations:
RSIP clients can use Service Location Protocol to find RSIP
servers having particular security characteristics. If secure
access to such information is required, SLP security should be
used.
セキュリティ問題: RSIPクライアントは、RSIPサーバには特定のセキュリティの特性があるのがわかるのにService Locationプロトコルを使用できます。 そのような情報への安全なアクセスが必要であるなら、SLPセキュリティは使用されるべきです。
Kempf & Montenegro Experimental [Page 7] RFC 3105 Finding an RSIP Server with SLP October 2001
2001年10月にSLPと共にRSIPサーバを見つけるケンフとモンテネグロの実験的な[7ページ]RFC3105
Template text: ----------------------template begins here ------------------------- template-type = rsip
テンプレートテキスト: ----------------------テンプレートはここで始まります。------------------------- テンプレートタイプはrsipと等しいです。
template-version = 0.0
テンプレートバージョン=0.0
template-description= The service:rsip type provides advertisements for clients seeing realm-specific IP (RSIP) servers. RSIP servers use the Realm Specific IP protocol to manage addresses and other resources from one realm on behalf of a client in another realm.
テンプレート記述はサービスと等しいです: rsipタイプは分野特有のIP(RSIP)サーバを見るクライアントに広告を提供します。 RSIPサーバは、別の分野のクライアントを代表して1つの分野からのアドレスと他のリソースを管理するのにRealm Specific IPプロトコルを使用します。
template-url-syntax= ;No additional URL path information required. An example service ;URL for an RSIP server is: service:rsip://gateway.mydomain:4455
テンプレート-url構文=; どんな追加URL経路情報も必要ではありません。 例のサービス; RSIPサーバのためのURLは以下の通りです。 サービス: rsip://gateway.mydomain: 4455
ipsec-support = BOOLEAN O #True if the server supports IPSEC as per [10]
に従ってサーバがIPSECをサポートするならipsec-サポートがブールO#Trueと等しい。[10]
ike-support = BOOLEAN O #True if the server supports IKE as per [10]
に従ってサーバがIKEをサポートするならike-サポートがブールO#Trueと等しい。[10]
tunnel-type = STRING L M O IP-IP #The tunneling methods supported by the RSIP server. Clients #should include this attribute in a query so that they obtain a #server offering a tunneling method for which they have #support. Default is IP-IP. The values are currently #restricted to IP-IP, L2TP, GRE and NONE. A server can support #multiple tunnel types. IP-IP,L2TP,GRE,NONE
トンネルタイプはトンネリングメソッドがRSIPサーバでサポートしたSTRING L M O IP-IP#、と等しいです。クライアント#が質問でこの属性を入れるべきであるので、彼らは彼らが#サポートを持っているトンネリングメソッドを提供しながら、#サーバを得ます。 デフォルトはIP-IPです。 現在、値はIP-IP、L2TP、GRE、およびNONEに制限された#です。 サーバは、#、が複数のトンネルタイプであるとサポートすることができます。 IP-IP、L2TP、なにものGRE
transport = STRING L M O TCP #Transport used by the RSIP protocol itself. TCP,UDP
輸送はRSIPプロトコル自体によって使用されるSTRING L M O TCP#Transportと等しいです。 TCP、UDP
load = INTEGER O #If the server supports load balancing, this attribute should be #set to an integer from 0 to 100. 0 is the lowest indication of #load and 100 the highest. Clients can query for this attribute #and obtain load information, from which they can make an #intelligent decision about which server to use. ----------------------template ends here ---------------------------
サーバがロードバランシングをサポートする負荷=INTEGER O#If、この属性は0〜100まで整数に設定された#、べきです。 0は最も高く#負荷と100の最も低いしるしです。 クライアントは、この属性のために#、について質問して、負荷情報を得ることができます。(彼らはそれからどのサーバを使用したらよいかに関する#知的な決定をすることができます)。 ----------------------ここのテンプレートエンド---------------------------
Kempf & Montenegro Experimental [Page 8] RFC 3105 Finding an RSIP Server with SLP October 2001
2001年10月にSLPと共にRSIPサーバを見つけるケンフとモンテネグロの実験的な[8ページ]RFC3105
8. Security Considerations
8. セキュリティ問題
Service type templates provide information that is used to interpret information obtained by clients through SLP. If the RSIP template is modified or if a false template is distributed, RSIP servers may not correctly register themselves, or RSIP clients may not be able to interpret service information.
サービスタイプテンプレートはSLPを通してクライアントによって得られた情報を解釈するのに使用される情報を提供します。 RSIPテンプレートが変更されているか、または偽のテンプレートが分配されているなら、RSIPサーバは正しく自分たちを登録しないことができないかもしれませんか、RSIPクライアントがサービス情報を解釈できないかもしれません。
SLP provides an authentication mechanism for UAs to assure that service advertisements only come from trusted SAs [2]. If trust is an issue, particularly with respect to the information sought by the client about IPSEC and IKE support, then SLP authentication should be enabled in the network.
UAsが、サービス広告が信じられたSAs[2]から来るだけであることを保証するように、SLPは認証機構を提供します。 信頼が問題であるなら、特にIPSECとIKEサポートに関してクライアントによって求められた情報に関して当時のSLP認証はネットワークで可能にされるべきです。
9. Summary
9. 概要
This document describes how SLP can be used by RSIP clients to find RSIP servers. A service type template for an RSIP SLP service type is presented. In addition, a few techniques for provisioning access to service advertisements for particular gateway servers, and for load balancing using SLP were provided. The result should allow RSIP service provisioning that is considerably more dynamic and robust than when traditional service discovery mechanisms are used.
このドキュメントはRSIPクライアントがRSIPにサーバを見つけるのにどうSLPを使用できるかを説明します。 RSIP SLPサービスタイプのためのサービスタイプテンプレートを贈ります。 さらに、食糧を供給するいくつかのテクニックが特定のゲートウェイサーバ、およびSLPを使用するのが提供されたロードバランシングのために広告にサービスにアクセスします。 結果は伝統的なサービス発見メカニズムが使用されている時よりかなりダイナミックで強健なRSIPサービスの食糧を供給することを許すべきです。
References
参照
[1] Borella, M., Grabelsky, D., Lo, J. and K. Taniguchi, "Realm
Specific IP: Protocol Specification", RFC 3103, April 2001.
[1]Borella、M.、Grabelsky、D.、最低気温、J.、およびK.谷口、「分野の特定のIP:」 「プロトコル仕様」、RFC3103、2001年4月。
[2] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service
Location Protocol, version 2", RFC 2608, July 1999.
[2] Guttman(E.、パーキンス、C.、Veizades、J.、およびM.デー)は「1999年7月にRFC2608をLocationプロトコル、バージョン2インチ調整します」。
[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] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[4] ブラドナー、S.、「使用のための要件レベルを示すRFCsのキーワード」、BCP14、RFC2119、1997年3月。
[5] Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying the
location of services (DNS SRV)", RFC 2052, October 1996.
[5]GulbrandsenとA.とP.Vixie、「サービス(DNS SRV)の位置を指定するためのDNS RR」、RFC2052、1996年10月。
[6] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997.
[6]Droms、R.、「ダイナミックなホスト構成プロトコル」、RFC2131、1997年3月。
[7] Borella, M., Lo, J., Grabelsky, D. and G. Montenegro, "Realm
Specific IP: Framework", RFC 3102, October 2001.
[7]Borella、M.、最低気温、J.、Grabelsky、D.、およびG.モンテネグロ、「分野の特定のIP:」 「フレームワーク」、RFC3102、2001年10月。
Kempf & Montenegro Experimental [Page 9] RFC 3105 Finding an RSIP Server with SLP October 2001
2001年10月にSLPと共にRSIPサーバを見つけるケンフとモンテネグロの実験的な[9ページ]RFC3105
[8] Perkins, C. and E. Guttman, "DHCP Options for Service Location
Protocol", RFC 2610, July 1999.
[8] パーキンスとC.とE.Guttman、「サービス位置のプロトコルのためのDHCPオプション」、RFC2610、1999年7月。
[9] Naugle, J., Kasthurirangan, K. and G. Ledford, "TN3270E Service
Location and Session Balancing", RFC 3049, January 2001.
[9]NaugleとJ.とKasthuriranganとK.とG.Ledford、「TN3270Eは位置とセッションバランスをとることを修理する」RFC3049、2001年1月。
[10] Montenegro, G. and M. Borella, "RSIP Support for End-to-end
IPSEC", RFC 3104, October 2001.
[10] モンテネグロとG.とM.Borella、「終わりから終わりへのIPSECのRSIPサポート」、RFC3104、2001年10月。
[11] E. Guttman, "Service Location Protocol: Automatic Discovery of
IP Network Services," IEEE Internet Computing, July/August 1999.
Available at: http://computer.org/internet/ic1999/w4toc.htm
[11] E.Guttman、「位置のプロトコルを修理してください」 「IPネットワーク・サービスの自動発見」、1999年7月/8月に計算されるIEEEインターネット。 利用可能: http://computer.org/internet/ic1999/w4toc.htm
Authors' Addresses
作者のアドレス
Questions about this document may be directed to:
このドキュメントに関する質問による以下のことよう指示されるかもしれません。
James Kempf NTT DoCoMo USA Labs 181 Metro Drive, Suite 300 San Jose, CA 95110
サンノゼ、Suite300カリフォルニア ジェームスケンフNTTドコモ米国研究室181地下鉄ドライブ、95110
Phone: 408-451-4711 Email: james@docomolabs-usa.com
以下に電話をしてください。 408-451-4711 メールしてください: james@docomolabs-usa.com
Gabriel E. Montenegro Sun Microsystems Laboratories, Europe 29, chemin du Vieux Chene 38240 Meylan FRANCE
ガブリエルE.モンテネグロサン・マイクロシステムズ研究所、ヨーロッパ29、chemin du Vieux Chene38240メラン・フランス
Phone: +33 476 18 80 45 EMail: gab@sun.com
以下に電話をしてください。 +33 476 18 80 45はメールされます: gab@sun.com
Kempf & Montenegro Experimental [Page 10] RFC 3105 Finding an RSIP Server with SLP October 2001
2001年10月にSLPと共にRSIPサーバを見つけるケンフとモンテネグロの実験的な[10ページ]RFC3105
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 & Montenegro Experimental [Page 11]
ケンフとモンテネグロ実験的です。[11ページ]
一覧
スポンサーリンク
