RFC1477 日本語訳
1477 IDPR as a Proposed Standard. M. Steenstrup. July 1993. (Format: TXT=32238 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group M. Steenstrup Request for Comments: 1477 BBN Systems and Technologies July 1993
コメントを求めるワーキンググループM.ステーンストルプの要求をネットワークでつないでください: 1477台のBBNシステムと技術1993年7月
IDPR as a Proposed Standard
提案された標準としてのIDPR
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはインターネット標準を指定しません。 このメモの分配は無制限です。
1. Introduction
1. 序論
This document contains a discussion of inter-domain policy routing (IDPR), including an overview of functionality and a discussion of experiments. The objective of IDPR is to construct and maintain routes between source and destination administrative domains, that provide user traffic with the services requested within the constraints stipulated for the domains transited.
このドキュメントは機能性の概要と実験の議論を含む相互ドメイン方針ルーティング(IDPR)の議論を含んでいます。 IDPRの目的がソースと目的地の管理ドメインの間のルートを構成して、維持することであり、それは通過されたドメインに規定された規制の中で要求されたサービスをユーザトラフィックに提供します。
Four documents describe IDPR in detail:
4通のドキュメントが詳細にIDPRについて説明します:
M. Steenstrup. An architecture for inter-domain policy routing. RFC 1478. July 1993.
M.ステーンストルプ。 相互ドメイン方針ルーティングのためのアーキテクチャ。 RFC1478。 1993年7月。
M. Steenstrup. Inter-domain policy routing protocol specification: version 1. RFC 1479. July 1993.
M.ステーンストルプ。 相互ドメイン方針ルーティングプロトコル仕様: バージョン1。 RFC1479。 1993年7月。
H. Bowns and M. Steenstrup. Inter-domain policy routing configuration and usage. Work in Progress. July 1991.
H.BownsとM.ステーンストルプ。 相互ドメイン方針ルーティング設定と用法。 進行中で、働いてください。 1991年7月。
R. Woodburn. Definitions of managed objects for inter-domain policy routing (version 1). Work in Progress. March 1993.
R.Woodburn。 相互ドメイン方針ルーティング(バージョン1)のための管理オブジェクトの定義。 進行中で、働いてください。 1993年3月。
This is a product of the Inter-Domain Policy Routing Working Group of the Internet Engineering Task Force (IETF).
これはInter-ドメインPolicyルート設定インターネット・エンジニアリング・タスク・フォース作業部会(IETF)の製品です。
2. The Internet Environment
2. インターネット環境
As data communications technologies evolve and user populations grow, the demand for internetworking increases. The Internet currently comprises over 7000 operational networks and over 10,000 registered networks. In fact, for the last several years, the number of constituent networks has approximately doubled annually. Although we do not expect the Internet to sustain this growth rate, we must prepare for the Internet of five to ten years in the future.
データ通信技術が発展して、ユーザ人口が増加しているのに従って、インターネットワーキングの需要は増加します。 インターネットは現在、7000以上の操作上のネットワークと1万以上の登録されたネットワークを包括します。 事実上、ここ数年間、構成しているネットワークの数は周囲で毎年倍増しています。 この成長率を支えるためにインターネットを予想しませんが、私たちは将来、5〜10年のインターネットの用意をしなければなりません。
Steenstrup [Page 1] RFC 1477 IDPR July 1993
ステーンストルプ[1ページ]RFC1477IDPR1993年7月
Internet connectivity has increased along with the number of component networks. Internetworks proliferate through interconnection of autonomous, heterogeneous networks administered by separate authorities. We use the term "administrative domain" (AD) to refer to any collection of contiguous networks, gateways, links, and hosts governed by a single administrative authority that selects the intra-domain routing procedures and addressing schemes, specifies service restrictions for transit traffic, and defines service requirements for locally-generated traffic.
インターネットの接続性はコンポーネントネットワークの数と共に増加しました。 インターネットワークは別々の当局によって管理された自治の、そして、種々雑多なネットワークのインタコネクトを通して増殖します。 私たちは、イントラドメインルーティング手順とアドレシング体系を選択して、トランジットトラフィックにサービス制限を指定して、局所的に発生しているトラフィックのためにサービス要件を定義するただ一つの職務権限によって支配された隣接のネットワーク、ゲートウェイ、リンク、およびホストのどんな収集も参照するのに用語「管理ドメイン」(AD)を使用します。
In the early 1980s, the Internet was purely hierarchical, with the ARPANET as the single backbone. The current Internet possesses a semblance of a hierarchy in the collection of backbone, regional, metropolitan, and campus domains that compose it. However, technological, economical, and political incentives have prompted the introduction of inter-domain links outside of those in the strict hierarchy. Hence, the Internet has the properties of both hierarchical and mesh connectivity.
インターネットは1980年代前半にただ一つのバックボーンとしてアルパネットで純粋に階層的でした。 現在のインターネットには、地方の、そして、首都のバックボーン、およびそれを構成するキャンパスドメインの収集における、階層構造の類似があります。 しかしながら、技術的で、経済的で、政治上の誘因はそれらの外で厳しい階層構造で相互ドメインリンクの導入をうながしました。 したがって、インターネットには、ともに階層的、そして、メッシュ接続性の特性があります。
We expect that, over the next five years, the Internet will grow to contain O(10) backbone domains, most providing connectivity between many source and destination domains and offering a wide range of qualities of service, for a fee. Most domains will connect directly or indirectly to at least one Internet backbone domain, in order to communicate with other domains. In addition, some domains may install direct links to their most favored destinations. Domains at the lower levels of the hierarchy will provide some transit service, limited to traffic between selected sources and destinations. However, the majority of Internet domains will be "stubs", that is, domains that do not provide any transit service for any other domains but that connect directly to one or more transit domains.
私たちは、インターネットが次の5年間O(10)バックボーンドメインを含むようになると予想します、ソースと目的地ドメインを多くの間の接続性に最も提供して、さまざまなサービスの品質を提供して、有料で。 ほとんどのドメインが直接か間接的に少なくとも1つのインターネットの基幹ドメインに接続するでしょう、他のドメインで交信するために。 さらに、いくつかのドメインがそれらの最も好評な目的地に直リンクをインストールするかもしれません。 階層構造の下のレベルにおけるドメインは選択されたソースと目的地の間のトラフィックに制限された何らかのトランジットサービスを提供するでしょう。 しかしながら、インターネットドメインの大部分が「スタッブ」でしょう、すなわち、少しのトランジットサービスもいかなる他のドメインにも提供しませんが、直接1つ以上のトランジットドメインに接続するドメイン。
The bulk of Internet traffic will be generated by hosts in the stub domains, and thus, the applications running in these hosts will determine the traffic service requirements. We expect application diversity encompassing electronic mail, desktop videoconferencing, scientific visualization, and distributed simulation, for example. Many of these applications have strict requirements on loss, delay, and throughput.
インターネットトラフィックの大半がスタッブドメインのホストによって生成されるでしょう、そして、その結果、これらのホストへ駆け込むアプリケーションはトラフィックサービス要件を決定するでしょう。 私たちは例えば電子メールを取り囲むアプリケーションの多様性、デスクトップテレビ会議、サイエンティフィック・ビジュアライゼーション、および分配されたシミュレーションを予想します。 これらのアプリケーションの多くには、損失、遅れ、およびスループットに関する厳しい要件があります。
In such a large and heterogeneous Internet, the routing procedures must be capable of ensuring that traffic is forwarded along routes that offer the required services without violating domain usage restrictions. We believe that IDPR meets this goal; it has been designed to accommodate an Internet comprising O(10,000) administrative domains with diverse service offerings and requirements.
そのような大きくて異種のインターネットでは、ルーティング手順は、トラフィックがドメイン使用制限に違反しないで必要なサービスを提供するルートに沿って進められるのを確実にすることができなければなりません。 私たちは、IDPRがこの目標を達成すると信じています。 それは、さまざまのサービス提供と要件でO(10,000)の管理ドメインを包括するインターネットを収容するように設計されています。
Steenstrup [Page 2] RFC 1477 IDPR July 1993
ステーンストルプ[2ページ]RFC1477IDPR1993年7月
3. An Overview of IDPR
3. IDPRの概要
IDPR generates, establishes, and maintains "policy routes" that satisfy the service requirements of the users and respect the service restrictions of the transit domains. Policy routes are constructed using information about the services offered by and the connectivity between administrative domains and information about the services requested by the users.
IDPRは、ユーザのサービス要件を満たす「方針ルート」と敬意がトランジットドメインのサービス制限であることを生成して、確証して、支持します。 方針ルートは、提供されたサービスと管理ドメインの間の接続性の情報とユーザによって要求されたサービスの情報を使用することで構成されます。
3.1 Policies
3.1の方針
With IDPR, each domain administrator sets "transit policies" that dictate how and by whom the resources in its domain should be used. Transit policies are usually public, and they specify offered services comprising:
IDPRと共に、それぞれのドメイン管理者はその方法を書き取って、ドメインのリソースが使用されるべきである「運送保険証券」を設定します。 通常、運送保険証券は公共です、そして、それらは以下を包括する提供サービスを指定します。
- Access restrictions: e.g., applied to traffic to or from certain domains or classes of users.
- 制限にアクセスしてください: 例えば、ユーザかある一定のドメインかクラスのユーザからトラフィックに適用されています。
- Quality: e.g., delay, throughput, or error characteristics.
- 品質: 例えば、遅れ、スループット、または誤りの特性。
- Monetary cost: e.g., charge per byte, message, or session time.
- 貨幣原価: 例えば、1バイトあたりの充電、メッセージ、またはセッション時間。
Each domain administrator also sets "source policies" for traffic originating in its domain. Source policies are usually private, and they specify requested services comprising:
また、それぞれのドメイン管理者は「ソース方針」をドメインで起こるトラフィックに設定します。 通常、ソース方針は個人的です、そして、それらは以下を包括する要求されたサービスを指定します。
- Access: e.g., domains to favor or avoid in routes.
- アクセス: 例えばルートで支持するか、または避けるドメイン。
- Quality: e.g., acceptable delay, throughput, and reliability.
- 品質: 例えば、許容できる遅れ、スループット、および信頼性。
- Monetary cost: e.g., acceptable cost per byte, message, or session time.
- 貨幣原価: 例えば、1バイトあたりの許容できる費用、メッセージ、またはセッション時間。
3.2 Functions
3.2 機能
The basic IDPR functions include:
基本的なIDPR機能は:
- Collecting and distributing routing information, i.e., domain transit policy and connectivity information. IDPR uses link state routing information distribution, so that each source domain may obtain routing information about all other domains.
- 収集、ルーティング情報、すなわち、ドメイン運送保険証券を分配して、および接続性情報。 IDPRは、各ソースドメインが他のすべてのドメインのルーティング情報を得ることができるように、リンク州のルーティング情報流通を使用します。
- Generating and selecting policy routes based on the routing information distributed and on source policy information. IDPR gives each source domain complete control over the routes it generates.
- 情報が分配したルーティングに基づいたソース方針情報の上の方針ルートを生成して、選択します。 IDPRはそれが生成するルートのそれぞれのソースドメインの完全な支配力を与えます。
Steenstrup [Page 3] RFC 1477 IDPR July 1993
ステーンストルプ[3ページ]RFC1477IDPR1993年7月
- Setting up paths across the Internet, using the policy routes generated.
- ルートが生成した方針を使用して、インターネットの向こう側に経路をセットアップします。
- Forwarding messages across and between administrative domains along the established paths. IDPR uses source-specified message forwarding, giving each source domain complete control over the paths traversed by its hosts' inter-domain traffic.
- ドメインの向こう側に確立した経路に沿った管理ドメインの間にメッセージを転送します。 ホストの相互ドメイントラフィックによって横断された経路のそれぞれのソースドメインの完全な支配力を与えて、IDPRはソースによって指定されたメッセージ推進を使用します。
- Maintaining databases of routing information, inter-domain policy routes, forwarding information, and configuration information.
- ルーティング情報に関するデータベース、相互ドメイン方針ルート、推進情報、および設定情報を保守します。
3.3 Entities
3.3 実体
Several different entities are responsible for performing the IDPR functions:
いくつかの異なった実体がIDPR機能を実行するのに原因となります:
- "Policy gateways", the only IDPR-recognized connecting points between adjacent domains, collect and distribute routing information, participate in path setup, maintain forwarding information databases, and forward data messages along established paths.
- 「方針ゲートウェイ」(隣接しているドメインの間の唯一のIDPRによって認識された接続ポイント)は、ルーティング情報を集めて、分配して、経路セットアップに参加して、推進情報データベースを維持して、確立した経路に沿ってデータメッセージを転送します。
- "Path agents", resident within policy gateways, act on behalf of hosts to select policy routes, to set up and manage paths, and to maintain forwarding information databases. Any Internet host can reap the benefits of IDPR, as long as there exists a path agent willing to act on its behalf and a means by which the host's messages can reach that path agent.
- 方針ゲートウェイの中で居住している「経路エージェント」は、方針ルートを選択して、経路をセットアップして、管理して、推進情報データベースを維持するためにホストを代表して行動します。 どんなインターネット・ホストもIDPRの利益を獲得できます、利益に影響しても構わないと思っている経路エージェントとホストのメッセージがその経路エージェントに届くことができる手段がいる限り。
- Special-purpose servers maintain all other IDPR databases as follows:
- 専用サーバは他のすべてのIDPRデータベースを以下の通りに維持します:
o Each "route server" is responsible for both its database of routing information, including domain connectivity and transit policy information, and its database of policy routes. Also, each route server generates policy routes on behalf of its domain, using entries from its routing information database and using source policy information supplied through configuration or obtained directly from the path agents. A route server may reside within a policy gateway, or it may exist as an autonomous entity. Separating the route server functions from the policy gateways frees the policy gateways from both the memory intensive task of routing information database and route database maintenance and the computationally intensive task of route generation.
o それぞれの「ルートサーバ」はドメインの接続性と運送保険証券情報を含むルーティング情報に関するデータベースとその方針ルートに関するデータベースの両方に責任があります。 また、それぞれのルートサーバはドメインを代表して方針ルートを生成します、ルーティング情報データベースからエントリーを使用して、構成を通して提供するか、または直接経路エージェントから得るソース方針情報を使用して。 ルートサーバが方針ゲートウェイの中にあるかもしれませんか、またはそれは自治の実体として存在するかもしれません。 方針ゲートウェイとルートサーバ機能を切り離すと、方針ゲートウェイはルーティング情報データベースとルートデータベースメインテナンスのメモリの徹底的なタスクとルート世代の計算上徹底的なタスクの両方から解放されます。
o Each "mapping server" is responsible for its database of mappings that resolve Internet names and addresses to
o それぞれの「マッピングサーバ」はそれがインターネット名とアドレスを決議するマッピングに関するデータベースに責任があります。
Steenstrup [Page 4] RFC 1477 IDPR July 1993
ステーンストルプ[4ページ]RFC1477IDPR1993年7月
administrative domains. The mapping server function can be easily integrated into an existing name service such as the DNS.
管理ドメイン。 容易にDNSなどの既存の名前サービスとマッピングサーバ機能を統合できます。
o Each "configuration server" is responsible for its database of configured information that applies to policy gateways, path agents, and route servers in the given administrative domain. Configuration information for a given domain includes source and transit policies and mappings between local IDPR entities and their addresses. The configuration server function can be easily integrated into a domain's existing network management system.
o それぞれの「構成サーバ」は与えられた管理ドメインで方針ゲートウェイ、経路エージェント、およびルートサーバに適用される構成された情報に関するデータベースに責任があります。 与えられたドメインのための設定情報は地方のIDPR実体とそれらのアドレスの間にソース、運送保険証券、およびマッピングを含んでいます。 容易に構成サーバ機能をドメインの既存のネットワーク管理システムと統合できます。
3.4 Message Handling
3.4 メッセージハンドリング
There are two kinds of IDPR messages:
2種類のIDPRメッセージがあります:
- "Data messages" containing user data generated by hosts.
- ホストによって生成された利用者データを含む「データメッセージ。」
- "Control messages" containing IDPR protocol-related control information generated by policy gateways and route servers.
- IDPRのプロトコル関連の制御情報を含む「コントロールメッセージ」は、ゲートウェイとルートがサーバであると方針で生成しました。
Within the Internet, only policy gateways and route servers must be able to generate, recognize, and process IDPR messages. Mapping servers and configuration servers perform necessary but ancillary functions for IDPR, and they are not required to execute IDPR protocols. The existence of IDPR is invisible to all other gateways and hosts. Using encapsulation across each domain, an IDPR message tunnels from source to destination across the Internet through domains that may employ disparate intra-domain addressing schemes and routing procedures.
インターネットの中では、方針ゲートウェイとルートサーバだけが、IDPRメッセージを生成して、認識して、処理できなければなりません。 マッピングサーバと構成サーバはIDPRのために必要な、しかし、付属の機能を実行します、そして、それらはIDPRプロトコルを実行する必要はありません。 他のすべてのゲートウェイとホストにとって、IDPRの存在は目に見えません。 各ドメインの向こう側にカプセル化を使用して、IDPRメッセージは異種のイントラドメインアドレシング体系とルーティング手順を使うかもしれないドメインを通してインターネットの向こう側にソースから目的地までトンネルを堀ります。
4. Security
4. セキュリティ
IDPR contains mechanisms for verifying message integrity and source authenticity and for protecting against certain types of denial of service attacks. It is particularly important to keep IDPR control messages intact, because they carry control information critical to the construction and use of viable policy routes between domains.
IDPRはメッセージの保全とソースの信憑性について確かめて、あるタイプのサービス不能攻撃から守るためのメカニズムを含んでいます。 IDPRコントロールメッセージを完全に保つのは特に重要です、ドメインの間の実行可能な方針ルートの工事と使用に重要な制御情報を運ぶので。
4.1 Integrity and Authenticity
4.1 保全と信憑性
All IDPR messages carry a single piece of information, referred to in the IDPR documentation as the "integrity/authentication value", which may be used not only to detect message corruption but also to verify the authenticity of the message's source IDPR entity. The Internet Assigned Numbers Authority (IANA) specifies the set of valid algorithms which may be used to compute the integrity/authentication
すべてのIDPRメッセージが単にメッセージ不正を検出するのではなく、メッセージのソースIDPR実体の信憑性について確かめもするのに使用されるかもしれないIDPRドキュメンテーションに「保全/認証値」と呼ばれた1片の情報を運びます。 インターネットAssigned民数記Authority(IANA)は保全/認証を計算するのに使用されるかもしれない有効なアルゴリズムのセットを指定します。
Steenstrup [Page 5] RFC 1477 IDPR July 1993
ステーンストルプ[5ページ]RFC1477IDPR1993年7月
values. This set may include algorithms that perform only message integrity checks such as n-bit cyclic redundancy checksums (CRCs), as well as algorithms that perform both message integrity and source authentication checks such as signed hash functions of message contents.
値。 このセットはn-ビットの周期的な冗長チェックサム(CRCs)などのメッセージの保全チェックだけを実行するアルゴリズムを含むかもしれません、メッセージ内容のハッシュ関数であると署名されるようにメッセージの保全とソース認証チェックの両方を実行するアルゴリズムと同様に。
Each domain administrator is free to select any integrity/authentication algorithm, from the set specified by the IANA, for computing the integrity/authentication values contained in its domain's messages. However, we recommend that IDPR entities in each domain be capable of executing all of the valid algorithms so that an IDPR message originating at an entity in one domain can be properly checked by an entity in another domain.
それぞれのドメイン管理者はIANAによって指定されたセットからどんな保全/認証アルゴリズムも自由に選択できます、ドメインのメッセージに含まれた保全/認証値を計算するために。 しかしながら、私たちは、各ドメインのIDPR実体が別のドメインで実体で適切に1つのドメインの実体で起因するIDPRメッセージはチェックできるように有効なアルゴリズムのすべてを実行できることを勧めます。
IDPR control messages must carry a non-null integrity/authentication value. We recommend that control message integrity/authentication be based on a digital signature algorithm applied to a one-way hash function, such as RSA applied to MD5, which simultaneously verifies message integrity and source authenticity. The digital signature may be based on either public key or private key cryptography. However, we do not require that IDPR data messages carry a non-null integrity/authentication value. In fact, we recommend that a higher layer (end-to-end) procedure assume responsibility for checking the integrity and authenticity of data messages, because of the amount of computation involved.
IDPRコントロールメッセージは非ヌル保全/認証値を運ばなければなりません。 私たちは、コントロールメッセージの保全/認証が一方向ハッシュ関数に適用されたデジタル署名アルゴリズムに基づくことを勧めます、MD5に適用されたRSAなどのように。MD5は同時に、メッセージの保全とソースの信憑性について確かめます。 デジタル署名は公開鍵か秘密鍵暗号のどちらかに基づくかもしれません。 しかしながら、私たちは、IDPRデータメッセージが非ヌル保全/認証値を運ぶのを必要としません。 事実上、私たちは、より高い層(終わるには、終わる)の手順が、保全をチェックすることへの責任と計算の量によるデータメッセージの信憑性にかかわると仮定することを勧めます。
4.2 Timestamps
4.2 タイムスタンプ
Each IDPR message carries a timestamp (expressed in seconds elapsed since 1 January 1970 0:00 GMT) supplied by the source IDPR entity, which serves to indicate the age of the message. IDPR entities use the absolute value of a timestamp to confirm that the message is current and use the relative difference between timestamps to determine which message contains the most recent information. All IDPR entities must possess internal clocks that are synchronized to some degree, in order for the absolute value of a message timestamp to be meaningful. The synchronization granularity required by IDPR is on the order of minutes and can be achieved manually.
それぞれのIDPRメッセージはソースIDPR実体によって提供されたタイムスタンプ(言い表されて、1970年1月1日のグリニッジ標準時0時0分は以来、秒に、経過していた)を運びます。実体はメッセージの時代を示すのに役立ちます。 IDPR実体は、どのメッセージが最新の情報を含むかを決定するのにメッセージがよく見られると確認して、タイムスタンプの相対的な違いを使用するのにタイムスタンプの絶対値を使用します。 すべてのIDPR実体がある程度連動する内部クロックを所有しなければなりません、メッセージタイムスタンプの絶対値が重要であるように。 IDPRによって必要とされた同期粒状は、数分の注文にはあって、手動で達成できます。
Each IDPR recipient of an IDPR control message must check that the message's timestamp is in the acceptable range. A message whose timestamp lies outside of the acceptable range may contain stale or corrupted information or may have been issued by a source whose clock has lost synchronization with the message recipient. Such messages must therefore be discarded, to prevent propagation of incorrect IDPR control information. We do not require IDPR entities to perform a timestamp acceptability test for IDPR data messages, but instead leave the choice to the individual domain administrators.
IDPRコントロールメッセージのそれぞれのIDPR受取人は、メッセージのタイムスタンプが許容できる範囲にあるのをチェックしなければなりません。 タイムスタンプが許容できる範囲の外にあるメッセージは、聞き古した崩壊した情報を含んでいるか、または時計がメッセージ受取人との同期を失ったソースによって発行されたかもしれません。 したがって、不正確なIDPR制御情報の伝播を防ぐためにそのようなメッセージを捨てなければなりません。 私たちはIDPRデータメッセージのためのタイムスタンプ受容性テストを実行するためにIDPR実体を必要としませんが、代わりに個々のドメイン管理者に選択を任せてください。
Steenstrup [Page 6] RFC 1477 IDPR July 1993
ステーンストルプ[6ページ]RFC1477IDPR1993年7月
5. Size Considerations
5. サイズ問題
IDPR provides policy routing among administrative domains and has been designed to accommodate an Internet containing tens of thousands of domains, supporting diverse source and transit policies.
IDPRは方針ルーティングを管理ドメインに提供して、何万ものドメインを含むインターネットを収容するように設計されています、さまざまのソースとトランジットが方針であるとサポートして。
In order to construct policy routes, route servers require routing information at the domain level only; no intra-domain details need be included in IDPR routing information. Thus, the size of the routing information database maintained by a route server depends on the number of domains and transit policies and not on the number hosts, gateways, or networks in the Internet.
方針ルートを構成するために、ルートサーバは、ドメインレベルだけで情報を発送するのを必要とします。 イントラドメインの詳細は全くIDPRルーティング情報に含まれる必要はありません。 したがって、ルートサーバによって維持されたルーティング情報データベースのサイズはインターネットで数のホスト、ゲートウェイ、またはネットワークではなく、ドメインと運送保険証券の数に依存します。
We expect that, within a domain, a pair of IDPR entities will normally be connected such that when the primary intra-domain route fails, the intra-domain routing procedure will be able to use an alternate route. In this case, a temporary intra-domain failure is invisible at the inter-domain level. Thus, we expect that most intra-domain routing changes will be unlikely to force inter-domain routing changes.
私たちは、プライマリイントラドメインルートが失敗するとき、イントラドメインルーティング手順が代替経路を使用できるように、通常、1組のIDPR実体がドメインの中で接続されると予想します。 この場合、一時的なイントラドメイン失敗は相互ドメインレベルで目に見えません。 したがって、私たちは、ほとんどのイントラドメインルーティング変化が相互ドメインルーティング変化を強制しそうにないと予想します。
Policy gateways distribute routing information when detectable inter-domain changes occur but may also elect to distribute routing information periodically as a backup. Thus, policy gateways do not often need to generate and distribute routing information messages, and the frequency of distribution of these messages depends only weakly on intra-domain routing changes.
方針ゲートウェイは、検出可能な相互ドメイン変化がいつ起こるかというルーティング情報を分配しますが、また、バックアップとして定期的にルーティング情報を分配するのを選ぶかもしれません。 したがって、方針ゲートウェイは、しばしばルーティング情報メッセージを生成して、分配する必要があるというわけではありません、そして、これらのメッセージの分配の頻度はイントラドメインルーティング変化に弱々しくだけ依存します。
IDPR entities rely on intra-domain routing procedures operating within domains to transport inter-domain messages across domains. Hence, IDPR messages must appear well-formed according to the intra- domain routing procedures and addressing schemes in each domain traversed; this requires appropriate header encapsulation of IDPR messages at domain boundaries. Only policy gateways and route servers must be capable of handling IDPR-specific messages; other gateways and hosts simply treat the encapsulated IDPR messages like any other. Thus, for the Internet to support IDPR, only a small proportion of Internet entities require special IDPR software.
IDPR実体はドメインの向こう側に相互ドメインメッセージを輸送するためにドメインの中で作動するイントラドメインルーティング手順を当てにします。 したがって、IDPRメッセージは各ドメインのルーティング手順とアドレシング体系が横断したイントラドメインに従って整形式に見えなければなりません。 これはドメイン境界でIDPRメッセージの適切なヘッダーカプセル化を必要とします。 方針ゲートウェイとルートサーバだけがIDPR特有のメッセージを扱うことができなければなりません。 他のゲートウェイとホストはいかなる他の、なようにも単にカプセル化されたIDPRメッセージを扱います。 したがって、インターネットがIDPR、わずかな割合のインターネット実体だけをサポートするには、特別なIDPRソフトウェアを必要としてください。
With domain-level routes, many different traffic flows may use not only the same policy route but also the same path, as long their source domains, destination domains, and requested services are identical. Thus, the size of the forwarding information database maintained by a policy gateway depends on the number of domains and source policies and not on the number of hosts in the Internet. Moreover, memory associated with failed, expired, or disused paths can be reclaimed for new paths, and thus forwarding information for many paths can be accommodated.
同じ方針ルートにもかかわらず、同じ経路だけではなくも、ドメインレベルルート、長いとしての流れが使用するかもしれない多くの異なったトラフィックと、それらのソースドメイン、目的地ドメイン、および要求されたサービスは同じです。 したがって、方針ゲートウェイによって維持された推進情報データベースのサイズはインターネットのホストの数ではなく、ドメインとソース方針の数に依存します。 そのうえ、失敗したか、満期の、または、不要の経路に関連しているメモリを新しい経路に取り戻すことができます、そして、その結果、多くの経路のための推進情報に対応できます。
Steenstrup [Page 7] RFC 1477 IDPR July 1993
ステーンストルプ[7ページ]RFC1477IDPR1993年7月
6. Interactions with Other Inter-Domain Routing Procedures
6. 他の相互ドメインルート設定手順との相互作用
We believe that many Internet domains will benefit from the introduction of IDPR. However, the decision to support IDPR in a given domain is an individual one, left to the domain administrator; not all domains must support IDPR.
私たちは、多くのインターネットドメインがIDPRの導入の利益を得ると信じています。 しかしながら、与えられたドメインでIDPRをサポートするという決定はドメイン管理者に任せる個々のものです。 すべてのドメインがIDPRをサポートしなければならないというわけではありません。
Within a domain that supports IDPR, other inter-domain routing procedures, such as BGP and EGP, can comfortably coexist. Each inter-domain routing procedure is independent of the others. The domain administrator determines the relationship among the inter- domain routing procedures by deciding which of its traffic flows should use which inter-domain routing procedures and by configuring this information for use by the policy gateways.
IDPRをサポートするドメインの中では、BGPやEGPなどの他の相互ドメインルーティング手順はゆったり共存できます。 それぞれの相互ドメインルーティング手順は他のものから独立しています。 ドメイン管理者は、相互ドメインルーティング手順の中で交通の流れのどれがどの相互ドメインルーティング手順を用いるべきであるかを決めて、方針ゲートウェイのそばで使用のためのこの情報を構成することによって、関係を決定します。
Hosts in stub domains may have strict service requirements and hence will benefit from the policy routing provided by IDPR. However, the stub domain itself need not support IDPR in order for its traffic flows to use IDPR routes. Instead, a "proxy domain" may perform IDPR functions on behalf of the stub. The proxy domain must be reachable from the stub domain according to an inter-domain routing procedure independent of IDPR. Administrators of the stub and potential proxy domains mutually negotiate the relationship. Once an agreement is reached, the administrator of the stub domain should provide the proxy domain with its hosts' service requirements.
スタッブドメインのホストは、厳しいサービス要件を持っているかもしれなくて、したがって、IDPRによって提供された方針ルーティングの利益を得るでしょう。 しかしながら、交通の流れがIDPRルートを使用するように、スタッブドメイン自体はIDPRをサポートする必要はありません。 代わりに、「プロキシドメイン」はスタッブを代表してIDPR機能を実行するかもしれません。 相互ドメインルーティング手順によると、プロキシドメインはIDPRの如何にかかわらずスタッブドメインから届いているに違いありません。 スタッブと潜在的プロキシドメインの管理者は互いに関係を交渉します。 いったん合意に達していると、スタッブドメインの管理者はホストのサービス要件をプロキシドメインに提供するべきです。
IDPR policy routes must traverse a contiguous set of IDPR domains. Hence, the degree of IDPR deployment in transit domains will determine the availability of IDPR policy routes for Internet users. For a given traffic flow, if there exists no contiguous set of IDPR domains between the source and destination, the traffic flow relies on an alternate inter-domain routing procedure to provide a route. However, if there does exist a contiguous set of IDPR domains between the source and destination, the traffic flow may take advantage of policy routes provided by IDPR.
IDPR方針ルートは隣接のセットのIDPRドメインを横断しなければなりません。 したがって、トランジットドメインのIDPR展開の度合いはインターネットユーザのためにIDPR方針ルートの有用性を決定するでしょう。 与えられた交通の流れに関しては、IDPRドメインのどんな隣接のセットもソースと目的地の間に存在していないなら、交通の流れは、ルートを提供するために代替の相互ドメインルーティング手順を当てにします。 しかしながら、隣接のセットのIDPRドメインがソースと目的地の間に存在しているなら、交通の流れはIDPRによって提供された方針ルートを利用するかもしれません。
7. Implementation Experience
7. 実装経験
To date, there exist two implementations of IDPR: one an independent prototype and the other an integral part of the gated UNIX process. We describe each of these implementations and our experience with them in the following sections.
これまで、IDPRの2つの実装が存在します: 独立しているプロトタイプあたり1つと外出を禁止されたUNIXの不可欠の部分が処理するもう片方。 私たちは以下のセクションでそれらがあるそれぞれのこれらの実装と経験について説明します。
7.1 The Prototype
7.1 プロトタイプ
During the summer of 1990, the IDPR development group consisting of participants from USC, SAIC, and BBN began work on a UNIX-based software prototype of IDPR, designed for implementation in Sun
1990年夏の間、USC、SAIC、およびBBNからの関係者から成るIDPR開発グループはSunにおける実装のために設計されたIDPRのUNIXベースのソフトウェアプロトタイプに対する仕事を始めました。
Steenstrup [Page 8] RFC 1477 IDPR July 1993
ステーンストルプ[8ページ]RFC1477IDPR1993年7月
workstations. This prototype consisted of multiple user-level processes to provide the basic IDPR functions together with kernel modifications to speed up IDPR data message forwarding.
ワークステーション。 このプロトタイプは、IDPRデータメッセージ推進を早くするためにカーネル変更と共に基本的なIDPR機能を提供するために複数のユーザレベルプロセスから成りました。
Most, but not all, of the IDPR functionality was captured in the prototype. In the interests of producing working software as quickly as possible, we intentionally left out of the IDPR prototype support for source policies and for multiple policy gateways connecting two domains. This simplified configuration and route generation without compromising the basic functionality of IDPR.
IDPRの機能性のすべてではなく、大部分がプロトタイプでキャプチャされました。 できるだけはやく働くソフトウェアを作り出すことのために、私たちは故意にソース方針と複数の方針のプロトタイプサポートをIDPRから2つのドメインをつなげるゲートウェイに外しました。 IDPRに関する基本機能に感染しないで、これは構成とルート世代を簡素化しました。
The IDPR prototype software was extensively instrumented to provide detailed information for monitoring its behavior. The instrumentation allowed us to detect events including but not limited to:
IDPRプロトタイプソフトウェアは、振舞いをモニターするための詳細な情報を提供するために手広く器具を取り付けられました。 計装で、私たちは他を含むイベントを検出できました:
- Change in policy gateway connectivity to adjacent domains.
- 方針ゲートウェイの接続性では、隣接しているドメインに変化してください。
- Change in transit policies configured for a domain.
- ドメインに構成された運送保険証券で、変化してください。
- Transmission and reception of link state routing information.
- リンクのトランスミッションとレセプションはルーティング情報を述べます。
- Generation of policy routes, providing a description of the actual route.
- 実際のルートの記述を提供する方針ルートの世代。
- Transmission and reception of path control information.
- 経路のトランスミッションとレセプションは情報を制御します。
- Change of path state, such as path setup or teardown.
- 経路セットアップか分解などの経路州の変化。
With the extensive behavioral information available, we were able to track most events occurring in our test networks and hence determine whether the prototype software provided the expected functionality.
大規模な挙動情報が利用可能な状態で、私たちは、私たちのテストネットワークで起こるほとんどのイベントを追跡して、したがって、プロトタイプソフトウェアが予想された機能性を提供したかどうか決定できました。
7.1.1 Test Networks
7.1.1 テストネットワーク
In February 1991, the IDPR development group began experimenting with the completed IDPR prototype software. Each IDPR development site had its own testing environment, consisting of a set of interconnected Sun workstations, each workstation performing the functions of a policy gateway and route server:
1991年2月に、IDPR開発グループは完成したIDPRプロトタイプソフトウェアを実験し始めました。 それぞれのIDPR開発地域には、それ自身のテスト環境がありました、1セットのインタコネクトされたSunワークステーションから成って、各ワークステーションが方針ゲートウェイとルートサーバの機能を実行して:
- USC used a laboratory test network consisting of SPARC1+ workstations, each pair of workstations connected by an Ethernet segment. The topology of the test network could be arbitrarily configured.
- USCはSPARC1+ワークステーションから成る実験室試験ネットワークを使用して、それぞれの組のワークステーションはイーサネットセグメントで接続しました。 任意にテストネットワークのトポロジーを構成できました。
- SAIC used Sun3 workstations in networks at Sparta and at MITRE. These two sites were connected through Alternet using a 9.6kb SLIP
- SAICはスパルタにおいてMITREでネットワークにSun3ワークステーションを使用しました。 これらの2つのサイトが、Alternetを通して9.6kb SLIPを使用することでつなげられました。
Steenstrup [Page 9] RFC 1477 IDPR July 1993
ステーンストルプ[9ページ]RFC1477IDPR1993年7月
link and through an X.25 path across the DCA EDN testbed.
DCA EDNテストベッドの向こう側にリンクして、X.25経路を通して。
- BBN used SPARC1+ workstations at BBN and ISI connected over both DARTnet and TWBnet.
- BBNはBBNでSPARC1+ワークステーションを使用しました、そして、ISIはDARTnetとTWBnetの両方の上で接続しました。
7.1.2 Experiments
7.1.2 実験
The principal goal of our experiments with the IDPR prototype software was to provide a proof of concept. In particular, we set out to verify tha t the IDPR prototype software was able to:
IDPRプロトタイプソフトウェアによる私たちの実験の主な目的は概念の証拠を提供することでした。 特に、私たちは、IDPRプロトタイプソフトウェアができたtha tについて確かめ始めます:
- Monitor connectivity across and between domains.
- ドメインとドメインの間の接続性をモニターしてください。
- Update routing information when inter-domain connectivity changed or when new transit policies were configured.
- 相互ドメインの接続性がいつ変化したか、そして、または新しい運送保険証券がいつ構成されたかというルーティング情報をアップデートしてください。
- Distribute routing information to all domains.
- すべてのドメインにルーティング情報を分配してください。
- Generate acceptable policy routes based on current link state routing information.
- 現在のリンク州のルーティング情報に基づく許容できる方針ルートを生成してください。
- Set up and maintain paths for these policy routes.
- これらの方針ルートに経路をセットアップして、維持してください。
- Tear down paths that contained failed components, supported stale policies, or attained their maximum age.
- 失敗したコンポーネントを含んだか、聞き古した方針をサポートしたか、または彼らの最大の時代に達した経路を取りこわしてください。
Furthermore, we wanted to verify that the IDPR prototype software quickly detected and adapted to those events that directly affected policy routes.
その上、私たちは、IDPRプロトタイプソフトウェアがすぐに直接方針ルートに影響したそれらのイベントに検出して、順応したことを確かめたかったです。
The internetwork topology on which we based most of our experiments consisted of four distinct administrative domains connected in a ring. Two of the four domains served as host traffic source and destination, AD S and AD D respectively, while the two intervening domains provided transit service for the host traffic, AD T1 and AD T2. AD S and AD D each contained a single policy gateway that connected to two other policy gateways, one in each transit domain. AD T1 and AD T2 each contained at most two policy gateways, each policy gateway connected to the other and to a policy gateway in the source or destination domain. This internetwork topology provided two distinct inter-domain routes between AD S and AD D, allowing us to experiment with various component failure and transit policy reconfiguration scenarios in the transit domains.
私たちが私たちの実験の大部分を基礎づけたインターネットワークトポロジーはリングでつなげられた4つの異なった管理ドメインから成りました。 4つのドメインのうち2はホストトラフィックソース、目的地、AD S、およびAD Dとしてそれぞれ機能しました、2つの介入しているドメインがホストトラフィック、AD T1、およびAD T2にトランジットサービスを供給しましたが。 AD SとAD Dはそれぞれ他の2方針門に接続した1方針門を含んで、あるコネがそれぞれのトランジットドメインです。 AD T1とほとんどの2方針門にそれぞれ含まれたAD T2、それぞれの方針ゲートウェイはソースか目的地ドメインでもう片方と、そして、方針ゲートウェイに接続しました。 このインターネットワークトポロジーはAD SとAD Dの間のルートを2の異なった相互ドメインに提供しました、私たちがトランジットドメインで様々なコンポーネント故障と運送保険証券再構成シナリオを実験するのを許容して。
For the first set of experiments, we configured transit policies for AD T1 and AD T2 that were devoid of access restrictions. We then initialized each policy gateway in our internetwork, loading in the domain-specific configurations and starting up the IDPR processes.
実験の第一セットに関しては、私たちはアクセス制限に欠けているAD T1とAD T2のために運送保険証券を構成しました。 そして、ドメイン特有の構成でロードして、IDPRプロセスを立ち上げて、私たちはインターネットワークでそれぞれの方針ゲートウェイを初期化しました。
Steenstrup [Page 10] RFC 1477 IDPR July 1993
ステーンストルプ[10ページ]RFC1477IDPR1993年7月
In our experiments, we did not use mapping servers; instead, we configured address/domain mapping tables in each policy gateway.
実験では、私たちはマッピングサーバを使用しませんでした。 代わりに、私たちはそれぞれの方針ゲートウェイでテーブルを写像するアドレス/ドメインを構成しました。
After policy gateway initialization, we observed that each policy gateway immediately determined the connectivity to policy gateways in its own domain and in the adjacent domains. The representative policy gateway in each domain then generated a routing information message that was received by all other policy gateways in the internetwork.
方針ゲートウェイ初期化の後に、私たちは、それぞれの方針ゲートウェイがすぐにそれ自身のドメインと隣接しているドメインの方針ゲートウェイに接続性を決定したのを観測しました。 そして、各ドメインの代表している方針ゲートウェイは、ルーティングが他のすべての方針ゲートウェイによってインターネットワークで受け取られた情報メッセージであると生成しました。
To test the route generation and path setup functionality of the IDPR prototype software, we began a telnet session between a host in AD S and a host in AD D. We observed that the telnet traffic prompted the path agent resident in the policy gateway in AD S to request a policy route from its route server. The route server then generated a policy route and returned it to the path agent. Using the policy route supplied by the route server, the path agent initiated path setup, and the telnet session was established immediately.
IDPRプロトタイプソフトウェアのルート世代と経路セットアップの機能性をテストするために、私たちはAD D.のときにAD Sのホストとホストとのtelnetセッションを始めました。Weは、telnetトラフィックが、AD Sの方針ゲートウェイの経路エージェントの居住者がルートサーバから方針ルートを要求するようにうながしたのを観測しました。ルートサーバは、次に、方針ルートを生成して、経路エージェントにそれを返しました。 ルートサーバによって供給された方針ルートを使用して、経路エージェントは経路セットアップに着手しました、そして、telnetセッションはすぐに、確立されました。
Having confirmed that the prototype software satisfactorily performed the basic IDPR functions, we proceeded to test the software under changing network conditions. The first of these tests showed that the IDPR prototype software was able to deal successfully with a component failure along a path. To simulate a path component failure, we terminated the IDPR processes on a policy gateway in the transit domain, AD T1, traversed by the current path. The policy gateways on either side of the failed policy gateway immediately detected the failure. Next, these two policy gateways, representing two different domains, each issued a routing information message indicating the connectivity change and each initiated path teardown for its remaining path section.
プロトタイプソフトウェアが満足に基本的なIDPR機能を実行したと確認したので、ネットワーク状態を変える下で私たちはソフトウェアを検査しかけました。 これらのテストの1番目は、IDPRプロトタイプソフトウェアが経路に沿って首尾よくコンポーネント故障に対処できるのを示しました。 経路コンポーネント故障をシミュレートするために、私たちはトランジットドメインの方針ゲートウェイの上のプロセス(AD T1)が現在の経路で横断したIDPRを終えました。 失敗した方針ゲートウェイのどちらかの側面の方針ゲートウェイはすぐに、失敗を検出しました。 次に、2つの異なったドメインを表して、これらの2方針門はそれぞれ接続性変化を示す情報メッセージを発送している、それぞれ開始している経路分解を残っている経路部に発行しました。
Once the path was torn down, the path agent agent in AD S requested a new route from its route server, to carry the existing telnet traffic. The route server, having received the new routing information messages, proceeded to generate a policy route through the other transit domain, AD T2. Then, the path agent in AD S set up a path for the new route supplied by the route server. Throughout the component failure and traffic rerouting, the telnet session remained intact.
いったん経路を取りこわすと、AD Sの経路エージェントのエージェントは、既存のtelnetトラフィックを運ぶためにルートサーバから新しいルートを要求しました。 ルートサーバは、新しいルーティング情報メッセージを受け取ったので、もう片方のトランジットドメイン(AD T2)を通して方針ルートを生成しかけました。 次に、AD Sの経路エージェントはルートサーバによって供給された新しいルートに経路をセットアップしました。コンポーネント故障とトラフィックのコースを変更するの間中、telnetセッションは元の状態のままになりました。
At this point, we restored the failed policy gateway in AD T1 to the functional state, by restarting its IDPR processes. The restored policy gateway connectivity prompted the generation and distribution of routing information messages indicating the change in domain connectivity.
ここに、私たちはAD T1で失敗した方針ゲートウェイを機能的な状態に修復しました、IDPRプロセスを再開することによって。 回復している方針ゲートウェイの接続性はドメインの接続性における変化を示すルーティング情報メッセージの生成と分配をうながしました。
Steenstrup [Page 11] RFC 1477 IDPR July 1993
ステーンストルプ[11ページ]RFC1477IDPR1993年7月
Having returned the internetwork topology to its initial configuration, we proceeded to test that the IDPR prototype software was able to deal successfully with transit policy reconfiguration. The current policy route carrying the telnet traffic traversed AD T2. We then reconfigured the transit policy for AD T2 to preclude access of traffic travelling from AD S to AD D. The transit policy reconfiguration prompted both the distribution of routing information advertising the new transit policy for AD T2 and the initiation of path teardown.
インターネットワークトポロジーを初期の構成に返したので、私たちはIDPRプロトタイプソフトウェアが首尾よく運送保険証券再構成を取扱うことができたテストに続きました。 telnetトラフィックを運ぶ通貨政策ルートはAD T2を横断しました。 そして、私たちは、AD T2がAD SからAD D.まで運送保険証券再構成を旅行するトラフィックのアクセスを排除する運送保険証券がAD T2のために新しい運送保険証券の広告を出すルーティング情報の分配と経路分解の開始の両方をうながしたのを再構成しました。
Once the path was torn down, the path agent in AD S requested a new route from its route server, to carry the existing telnet traffic. The route server, having received the new routing information message, proceeded to generate a policy route through the original transit domain, AD T1. Then, the path agent in AD S set up a path for the new route supplied by the route server. Throughout the policy reconfiguration and rerouting, the telnet session remained intact.
いったん経路を取りこわすと、AD Sの経路エージェントは、既存のtelnetトラフィックを運ぶためにルートサーバから新しいルートを要求しました。 ルートサーバは、新しいルーティング情報メッセージを受け取ったので、元のトランジットドメイン(AD T1)を通して方針ルートを生成しかけました。 次に、AD Sの経路エージェントはルートサーバによって供給された新しいルートに経路をセットアップしました。方針再構成とコースを変更するの間中、telnetセッションは元の状態のままになりました。
This set of experiments, although simple, tested all of the major functionality of the IDPR prototype software and demonstrated that the prototype software could quickly and accurately adapt to changes in the internetwork.
このセットの実験は、簡単ですが、IDPRプロトタイプソフトウェアの主要な機能性のすべてをテストして、プロトタイプソフトウェアがすぐに、正確にインターネットワークにおける変化に順応できるのを示しました。
7.1.3 Performance Analysis
7.1.3 機能解析
We (USC and SAIC members of the IDPR development group) evaluated the performance of the path setup and message forwarding portions of the IDPR prototype software. For path setup, we measured the amount of processing required at the source path agent and at intermediate policy gateways during path setup. For message forwarding, we compared the processing required at each policy gateway when using IDPR forwarding with IP encapsulation and when using only IP forwarding. We also compared the processing required when no integrity/authentication value was calculated for the message and when the RSA/MD4 algorithms were employed.
私たち(IDPR開発のメンバーが分類するUSCとSAIC)はIDPRプロトタイプソフトウェアの経路セットアップとメッセージ推進一部の性能を評価しました。 経路セットアップのために、私たちは経路セットアップの間、ソースの経路エージェントにおいて中間的方針ゲートウェイで必要である処理の量を測定しました。 メッセージ推進のために、私たちはIPと共にIP推進だけを使用することでカプセル化といつを進めるかながらIDPRを使用するときそれぞれの方針ゲートウェイで必要である処理を比較しました。 また、私たちは保全/認証値が全くメッセージのために計算されないで、RSA/MD4アルゴリズムが使われたとき必要である処理を比較しました。
Our performance measurements were encouraging, but we have not listed them here. We emphasize that although we tried to produce efficient software for the IDPR prototype, we were not able to devote much effort to optimizing this software. Hence, the performance measurements for the IDPR prototype software should not be blindly extrapolated to other implementations of IDPR. To obtain a copy of the performance measurements for path setup and message forwarding in the IDPR prototype software, contact Robert Woodburn (woody@sparta.com) and Deborah Estrin (estrin@usc.edu).
私たちの性能測定は奨励していましたが、私たちはここにそれらを記載していません。 私たちは、IDPRプロトタイプのための効率的なソフトウェアを作り出そうとしましたが、私たちがこのソフトウェアを最適化するのに多くの取り組みをささげることができなかったと強調します。 したがって、盲目的にIDPRプロトタイプソフトウェアのための性能測定をIDPRの他の実装に推定するべきではありません。 IDPRプロトタイプソフトウェアにおける経路セットアップとメッセージ推進のための性能測定のコピーを入手するには、ロバートWoodburn( woody@sparta.com )とデボラEstrin( estrin@usc.edu )に連絡してください。
Steenstrup [Page 12] RFC 1477 IDPR July 1993
ステーンストルプ[12ページ]RFC1477IDPR1993年7月
7.2 The Gated Version
7.2 外出を禁止されたバージョン
In 1992, SRI joined the IDPR development group, and together SRI, SAIC, and BBN completed the task of integrating IDPR into the gated UNIX process. As a result, IDPR is now available as part of gated. The gated version of IDPR contains the full functionality of IDPR together with a simple yet versatile user interface for IDPR configuration. As a single process, the gated version of IDPR performs more efficiently than the multiple-process prototype version.
1992年に、SRIはIDPR開発グループに加わりました、そして、SRI、SAIC、およびBBNは外出を禁止されたUNIXプロセスとIDPRを統合するタスクを一緒に、完成しました。 その結果、IDPRは現在、外出を禁止されることの一部として利用可能です。 IDPRの外出を禁止されたバージョンはIDPR構成のための簡単な、しかし、多能なユーザーインタフェースと共にIDPRの完全な機能性を含んでいます。 単一のプロセスとして、IDPRの外出を禁止されたバージョンは複数のプロセスプロトタイプバージョンより効率的に働きます。
The gated version of IDPR is freely available to the Internet community. Hence, anyone with a UNIX-based machine can experiment with IDPR, without investing any money or implementation effort. By making IDPR widely accessible, we can gain Internet experience by introducing IDPR into operational networks with real usage constraints and transporting host traffic with real service requirements. Currently, a pilot deployment and demonstration of IDPR is under way in selected locations in the Internet.
IDPRの外出を禁止されたバージョンは自由にインターネットコミュニティに利用可能です。 したがって、どんなお金や実装取り組みも注ぎ込まないで、UNIXベースのマシンをもっているだれでもIDPRを実験できます。 IDPRを広くアクセスしやすくすることによって、私たちは本当の用法規制で操作上のネットワークにIDPRを取り入れて、本当のサービス要件でホストトラフィックを輸送することによって、インターネット経験ができます。 現在、IDPRのパイロット展開とデモンストレーションはインターネットの選択された位置で進行中です。
8. Security Considerations
8. セキュリティ問題
Refer to section 4 for details on security in IDPR.
IDPRのセキュリティに関する詳細についてセクション4を参照してください。
9. Author's Address
9. 作者のアドレス
Martha Steenstrup BBN Systems and Technologies 10 Moulton Street Cambridge, MA 02138
マーサステーンストルプBBN Systemsと技術10モールトン・通りケンブリッジ、MA 02138
Phone: (617) 873-3192 Email: msteenst@bbn.com
以下に電話をしてください。 (617) 873-3192 メールしてください: msteenst@bbn.com
Steenstrup [Page 13]
ステーンストルプ[13ページ]
一覧
スポンサーリンク