RFC1125 日本語訳

Network Working Group                                          D. Estrin
Request for Comments:  1125              USC Computer Science Department
                                                           November 1989

Estrinがコメントのために要求するワーキンググループD.をネットワークでつないでください: 1125 USCコンピュータサイエンス部の1989年11月

      POLICY REQUIREMENTS FOR INTER ADMINISTRATIVE DOMAIN ROUTING

間の管理ドメインルーティングのための方針要件

1  STATUS OF THIS MEMO

1 このメモの状態

   The purpose of this memo is to focus discussion on particular
   problems in the Internet and possible methods of solution.  No
   proposed solutions in this document are intended as standards for the
   Internet.  Rather, it is hoped that a general consensus will emerge
   as to the appropriate solution to such problems, leading eventually
   to the development and adoption of standards.  Distribution of this
   memo is unlimited.

このメモの目的はインターネットの特定の問題とソリューションの可能なメソッドに議論の焦点を合わせることです。 提案されたソリューションは全くインターネットの規格として本書では意図しません。 むしろ、全体的な合意が適切なソリューションに関してそのような問題に現れることが望まれています、結局規格の開発と採用に通じて。 このメモの分配は無制限です。

2  ABSTRACT

2要約

   Efforts are now underway to develop a new generation of routing
   protocol that will allow each Administrative Domain (AD) in the
   growing Internet (and internets in general) to independently express
   and enforce policies regarding the flow of packets to, from, and
   through its resources. (FOOTNOTE 1: The material presented here
   incorporates discussions held with members of the IAB Autonomous
   Networks Research Group and the Open Routing Working Group.)  This
   document articulates the requirements for policy based routing and
   should be used as input to the functional specification and
   evaluation of proposed protocols.

取り組みは、現在、増加しているインターネット(そして、一般に、インターネット)の各Administrative Domain(AD)が独自にリソースとリソースと、そのリソースを通したパケットの流れに関する方針を言い表して、実施するルーティング・プロトコルの新しい世代を発展させるように進行中です。 (FOOTNOTE1: ここで寄贈された材料はIAB Autonomous Networks Research Groupとオープンルート設定作業部会のメンバーと共に行われる議論を取り入れます。) このドキュメントは、方針に基づいているルーティングのための要件について明確に話して、提案されたプロトコルの機能的な仕様と評価に入力されるように使用されるべきです。

   Two critical assumptions will shape the type of routing mechanism
   that is devised: (1) the topological organization of ADs, and (2) the
   type and variability of policies expressed by ADs.  After justifying
   our assumptions regarding AD topology we present a taxonomy, and
   specific examples, of policies that must be supported by a PR
   protocol.  We conclude with a brief discussion of policy routing
   mechanisms proposed in previous RFCs (827, 1102, 1104, 1105).  Future
   RFCs will elaborate on the architecture and protocols needed to
   support the requirements presented here.

重要な仮定が工夫されるメカニズムを発送しながらタイプを形成する2: (1) 方針のタイプと可変性がADsで急送したADs、および(2)の位相的な組織。 ADトポロジーに関する私たちの仮定を正当化した後に、私たちはPRプロトコルでサポートしなければならない方針の分類学、および特定の例を提示します。 私たちは前のRFCs(827、1102、1104、1105)で提案された方針ルーティングメカニズムの簡潔な議論で締めくくります。 将来のRFCsはここに提示された要件をサポートするのに必要であるアーキテクチャとプロトコルについて詳しく説明するでしょう。

3  BACKGROUND

3 バックグラウンド

   The Research Internet has evolved from a single backbone wide area
   network with many connected campus networks, to an internet with
   multiple cross-country backbones, regional access networks, and a
   profusion of campus networks. (FOOTNOTE 2: The term Research Internet
   refers to a collection of government, university, and some private
   company, networks that are used by researchers to access shared

Researchインターネットは多くの接続キャンパスネットワークと共にただ一つのバックボーン広域ネットワークから発展しました、複数のクロスカントリーのバックボーンがあるインターネット、地方のアクセスネットワーク、およびキャンパスネットワークの大量に。 (FOOTNOTE2: 用語Researchインターネットは政府、大学、およびある民間企業の収集を参照して、アクセスする研究者によって使用されるネットワークは共有されました。

Estrin                                                          [Page 1]

RFC 1125                  Policy Requirements              November 1989

Estrin[1ページ]RFC1125方針要件1989年11月

   computing resources (e.g., supercomputers), and for research related
   information exchange (e.g., distribution of software, technical
   documents, and email). The networks that make up the Research
   Internet run the DOD Internet Protocol [1].)  At times during its
   development the Research Internet topology appeared somewhat chaotic.
   Overlapping facilities and lateral (as opposed to hierarchical)
   connections seemed to be the rule rather than the exception.  Today
   the Research Internet topology is becoming more regular through
   coordination of agency investment and adoption of a hierarchy similar
   to that of the telephone networks'.  The result is several
   overlapping wide area backbones connected to regional networks, which
   in turn connect to campus networks at universities, research
   laboratories, and private companies. However, the telephone network
   has lateral connections only at the highest level, i.e., between long
   haul carriers.  In the Research Internet there exist lateral
   connections at each level of the hierarchy, i.e., between campus (and
   regional) networks as well.

リソース(例えば、スーパーコンピュータ)を計算して、研究関連情報交換(例えば、ソフトウェア、技術文献、およびメールの分配)のために。 Researchインターネットを作るネットワークはDODインターネットプロトコル[1]を実行します。) 時には、開発の間、Researchインターネットトポロジーはいくらか混沌と見えました。 施設と側部(階層的と対照的に)の接続を重ね合わせるのは例外よりむしろ規則であるように思えました。 今日、Researchインターネットトポロジーは政府機関投資のコーディネートとそれと同様の階層構造の採用で、より通常に電話網のものをならせています。 結果は大学、研究所、および民間企業で順番にキャンパスネットワークに接続する地域ネットワークに関連づけられたいくつかの重なっている広い領域バックボーンです。 しかしながら、電話網には、すなわち、上層部によって、そして、長期キャリヤーだけの間の側部の接続があります。 Researchインターネットでは、階層構造の各レベルにおける側部の接続は存在しています、すなわち、また、キャンパスの、そして、(地方)のネットワークの間で。

   Additional complexity is introduced in the Research Internet by
   virtue of connections to private networks. Many private companies are
   connected to the Research Internet for purposes of research or
   support activities. These private companies connect in the same
   manner as campuses, via a regional network or via lateral links to
   other campuses. However, many companies have their own private wide
   area networks which physically overlap with backbone and/or regional
   networks in the research internet, i.e., private vertical bypass
   links.

私設のネットワークとの接続によってResearchインターネットで追加複雑さを導入します。 多くの民間企業が研究かサポート活動の目的のためにResearchインターネットに接続されます。 これらの民間企業はキャンパスか地域ネットワークを通した、または、他のキャンパスへの側部のリンクを通した同じ方法で接続します。 しかしながら、多くの会社には、研究インターネット(すなわち、個人的な垂直な迂回リンク)で物理的にバックボーン、そして/または、地域ネットワークに重なるそれら自身の個人的な広域ネットワークがあります。

   Implicit in this complex topology are organizational boundaries.
   These boundaries define Administrative Domains (ADs) which preclude
   the imposition of a single, centralized set of policies on all
   resources.  The subject of this paper is the policy requirements for
   resource usage control in the Research Internet.

この複雑なトポロジーで暗黙であることは、組織境界です。 これらの境界は単一の、そして、集結されたセットの方針のすべてのリソースへの賦課を排除するAdministrative Domains(ADs)を定義します。 この紙の対象はResearchインターネットでのリソース用法コントロールのための方針要件です。

   In the remainder of this section we describe the policy routing
   problem in very general terms. Section 4 examines the constraints and
   requirements that makes the problem challenging, and leads us to
   conclude that a new generation of routing and resource control
   protocols are needed. Section 5 provides more detail on our
   assumptions as to the future topology and configuration of
   interconnected ADs. We return to the subject of policy requirements
   in Section 7 and categorize the different types of policies that ADs
   in the research internet may want to enforce.  Included in this
   section are examples of FRICC policy statements.  (FOOTNOTE 3: The
   Federal Research Internet Coordinating Committee (FRICC) is made up
   of representatives of each of the major agencies that are involved in
   networking. They have been very effective in coordinating their
   efforts to eliminate inefficient redundancy and have proposed a plan

このセクションの残りでは、私たちは非常に一般的な用語で方針ルーティング問題について説明します。セクション4は、それが挑戦することにおける問題をする規制と要件を調べて、私たちが、ルーティングと資源管理では、プロトコルが新しい世代、必要であると結論を下すように導きます。 セクション5はインタコネクトされたADsの将来のトポロジーと構成に関して私たちの前提に関するその他の詳細を提供します。 私たちは、セクション7の方針要件の対象に戻って、研究インターネットにおけるADsが実施したがっているかもしれない異なったタイプの方針を分類します。 このセクションに含まれているのは、FRICC施政方針に関する例です。 FOOTNOTE3: 連邦政府のResearchインターネットCoordinating Committee(FRICC)はネットワークにかかわるそれぞれの主要な政府機関の代表で作られます。(それらは、効率の悪い冗長を排除するためにそれらの取り組みを調整するのにおいて非常に効果的であり、プランを提案しました。

Estrin                                                          [Page 2]

RFC 1125                  Policy Requirements              November 1989

Estrin[2ページ]RFC1125方針要件1989年11月

   for the next 10 years of internetworking for the government,
   scientific, and education community [2].)  Section 7 identifies types
   of policy statements that are problematic to enforce due to their
   dynamics, granularity, or performance implications. Several proposed
   mechanisms for supporting PR (including RFCs 827, 1102, 1104, 1105)
   are discussed briefly in Section 8. Future RFCs will elaborate on the
   architecture and protocols needed to support the requirements
   presented here.

政府のための次の10年間のインターネットワーキング、科学的、そして、教育共同体[2]に。) セクション7はそれらの力学、粒状、または性能のため含意を実施するために問題が多い施政方針のタイプを特定します。 セクション8で簡潔にPR(RFCs827、1102、1104、1105を含んでいる)をサポートするための数個の提案されたメカニズムについて議論します。 将来のRFCsはここに提示された要件をサポートするのに必要であるアーキテクチャとプロトコルについて詳しく説明するでしょう。

3.1  POLICY ROUTING

3.1 方針ルーティング

   Previous protocols such as the Exterior Gateway Protocol (EGP)[3]
   embodied a limited notion of policy and ADs. In particular,
   autonomous system boundaries constrained the flow of routing database
   information, and only indirectly affected the flow of packets
   themselves.  We consider an Administrative Domain (AD) to be a set of
   hosts and network resources (gateways, links, etc.) that is governed
   by common policies.  In large internets that cross organization
   boundaries, e.g., the Research Internet, inter-AD routes must be
   selected according to policy-related parameters such as cost and
   access rights, in addition to the traditional parameters of
   connectivity and congestion. In other words, Policy Routing (PR) is
   needed to navigate through the complex web of policy boundaries
   created by numerous interconnected ADs. Moreover, each AD has its own
   privileges and perspective and therefore must make its own evaluation
   of legal and preferred routes.  Efforts are now underway to develop a
   new generation of routing protocol that will allow each AD to
   independently express and enforce policies regarding the flow of
   packets to, from, and through its resources [4].  (FOOTNOTE 4:  These
   issues are under investigation by the IAB Autonomous Networks
   Research Group and the IAB Open Routing Working Group. For further
   information contact the author.)

Exteriorゲートウェイプロトコル(EGP)[3]などの前のプロトコルは方針とADsの限られた概念を具体化しました。 自律システム境界は、特に、ルーティングデータベース情報の流れを抑制して、間接的にパケット自体の流れに影響しただけです。 私たちは、Administrative Domain(AD)が共通政策で治められる1セットのホストとネットワーク資源(ゲートウェイ、リンクなど)であると考えます。 組織境界、例えばResearchインターネットに交差する大きいインターネットでは、接続性と混雑の伝統的なパラメタに加えた費用やアクセス権などの方針関連のパラメタによると、相互ADルートを選択しなければなりません。 言い換えれば、Policyルート設定(PR)が、多数のインタコネクトされたADsによって作成された方針限界の複雑なウェブを通してナビゲートするのに必要です。 そのうえ、各ADはそれ自身の特権と見解を持って、したがって、それ自身の法的で都合のよいルートの評価をしなければなりません。 取り組みは、現在、独自にリソースとリソースと、そのリソース[4]を通したパケットの流れに関する方針を言い表して、実施するために各ADを許容するルーティング・プロトコルの新しい世代を発展させるように進行中です。 (脚注4: これらの問題はIAB Autonomous Networks Research GroupとIABオープンルート設定作業部会による調査中です。 詳細に関しては、作者に連絡してください。)

   The purpose of this paper is to articulate the requirements for such
   policy based routing. Two critical assumptions will shape the type of
   routing mechanism that is devised:

この紙の目的はそのような方針に基づいているルーティングのための要件について明確に話すことです。 重要な仮定が工夫されるメカニズムを発送しながらタイプを形成する2:

   * The topological organization of ADs, and
   * The type and variability of policies expressed by ADs.

* ADsの位相的な組織、および方針のタイプと可変性がADsで言い表した*。

   We make use of the policies expressed by owners of current Research
   Internet resources and private networks connected to the Research
   Internet to generalize types of policies that must be supported. This
   top down effort must be done with attention to the technical
   implications of the policy statements if the result is to be useful
   in guiding technical development. For example, some ADs express the
   desire to enforce local constraints over how packets travel to their
   destination. Other ADs are only concerned with preventing use of

私たちはサポートしなければならない方針のタイプを広めるためにResearchインターネットに接続された現在のResearchインターネット資料と私設のネットワークの所有者によって言い表された方針を利用します。 結果が誘導している技術的な開発で役に立つことであるなら施政方針の技術的な含意に関する注意でこのトップダウン取り組みをしなければなりません。 例えば、いくつかのADsがパケットがどうそれらの目的地に移動するかの上の地方の規制を実施する願望を述べます。 防ぐADsが使用を当該であるだけであるもう一方

Estrin                                                          [Page 3]

RFC 1125                  Policy Requirements              November 1989

Estrin[3ページ]RFC1125方針要件1989年11月

   their own network resources by restricting transit.  Still other ADs
   are concerned primarily with recovering the expense of carrying
   traffic and providing feedback to users so that users will limit
   their own data flows; in other words they are concerned with
   charging.  We refer to ADs whose primary concern is communication to
   and from hosts within their AD as stub and to ADs whose primary
   concern is carrying packets to and from other ADs as transit}.  If we
   address control of transit alone, for example, the resulting
   mechanisms will not necessarily allow an AD to control the flow of
   its packets from source to destination, or to implement flexible
   charging schemes.  (FOOTNOTE 5: Gene Tsudik uses the analogy of
   international travel to express the need for source and transit
   controls. Each country expresses its own policies about travel to and
   through its land.  Travel through one country enroute to another is
   analogous to transit traffic in the network world. A traveler
   collects policy information from each of the countries of interest
   and plans an itinerary that conforms to those policies as well as the
   preferences of the traveler and his/her home nation.  Thus there is
   both source and transit region control of routing.)  Our purpose is
   to articulate a comprehensive set of requirements for PR as input to
   the functional specification, and evaluation, of proposed protocols.

トランジットを制限するのによるそれら自身のネットワーク資源。 データが流れることを主としてユーザがそれら自身のを制限するように、トラフィックを運んで、フィードバックをユーザに提供する費用を取り戻すのにまだ他のADsを心配させます。 言い換えれば、それらは充電に関係があります。 私たちは彼らのAD中にホストとホストからプライマリ関心がコミュニケーションであるADsをスタッブとプライマリ関心がトランジットとしてADsと他のADsからパケットを運ぶADsと呼びます。 私たちが単独でトランジットのコントロールを扱うと、結果として起こるメカニズムは、ADをパケットのソースから目的地までの流れを制御するというわけではありませんし、また例えば、必ずフレキシブルな請求が体系であると実装するというわけではないでしょう。 (脚注5: 遺伝子Tsudikは、ソースとトランジットコントロールの必要性を述べるのに海外旅行の類推を使用します。 各国は陸とその陸を通る旅行に関するそれ自身の方針を言い表します。 別のものへの途中1つの国を通る旅行はネットワーク世界のトランジットトラフィックに類似しています。 旅行者は、それぞれの興味がある国から方針情報を集めて、旅行者とその人のホーム国の好みと同様にそれらの方針に従う旅程を計画しています。 したがって、ソースとルーティングのトランジット領域コントロールの両方があります。) 私たちの目的は機能的な仕様に入力されるPRのための包括的なセットの要件、および提案されたプロトコルの評価について明確に話すことです。

4  WHY THE PROBLEM IS DIFFICULT

4 問題が難しい理由

   Before proceeding with our description of topology and policy
   requirements this section outlines several assumptions and
   constraints, namely: the lack of global authority, the need to
   support network resource sharing as well as network interconnection,
   the complex and dynamic mapping of users to ADs and privileges, and
   the need for accountability across ADs.  These assumptions limit the
   solution space and raise challenging technical issues.

私たちのトポロジーと方針要件の記述でこのセクションを続かせると以前いくつかの仮定と規制が概説される、すなわち: グローバルな権威(ADsの向こう側にネットワーク資源が責任のネットワーク相互接続と同様に共有して、ADsと特権へのユーザの複雑でダイナミックなマッピングと、必要性であるとサポートする必要性)の不足。 これらの仮定は、ソリューションスペースを制限して、やりがいがある専門的な問題を提起します。

   The purpose of policy based routing is to allow ADs to interconnect
   and share computer and network resources in a controlled manner.
   Unlike many other problems of resource control, there is no global
   authority. Each AD defines its own policies with respect to its own
   traffic and resources. However, while we assume no global authority,
   and no global policies, we recognize that complete autonomy implies
   no dependence and therefore no communication.  The multi-organization
   internets addressed here have inherent regions of autonomy, as well
   as requirements for interdependence. Our mechanisms should allow ADs
   to design their boundaries, instead of requiring that the boundaries
   be either impenetrable or eliminated.

方針に基づいているルーティングの目的はADsが制御方法でコンピュータとネットワーク資源とインタコネクトして、共有するのを許容することです。 資源管理の他の多くの問題と異なって、どんなグローバルな権威もありません。 各ADはそれ自身のトラフィックとリソースに関してそれ自身の方針を定義します。 しかしながら、グローバルな権限がなく、およびどんなグローバルな方針も得ていない間、私たちは、完全な自治が依存を全く含意しないで、またその結果コミュニケーションを全く含意しないと認めます。 ここで扱われたマルチ組織インターネットは自治の固有の範囲、および相互依存のための要件を持っています。 ADsは私たちのメカニズムで境界が突き通せないか排除されているのが必要であることの代わりに彼らの境界を設計するはずであることができます。

   One of the most problematic aspects of the policy routing
   requirements identified here is the need to support both network
   resource sharing and interconnection across ADs. An example of
   resource sharing is two ADs (e.g., agencies, divisions, companies)

ここで特定された方針ルーティング要件の最も問題の多い局面の1つはADsの向こう側にネットワーク資源共有とインタコネクトの両方をサポートする必要性です。 リソース・シェアリングに関する例は2ADsです。(例えば、政府機関、部門、会社)

Estrin                                                          [Page 4]

RFC 1125                  Policy Requirements              November 1989

Estrin[4ページ]RFC1125方針要件1989年11月

   sharing network resources (e.g., links, or gateways and links) to
   take advantage of economies of scale.  Providing transit services to
   external ADs is another example of network resource sharing.
   Interconnection is the more common example of ADs interconnecting
   their independently used network resources to achieve connectivity
   across the ADs, i.e., to allow a user in one AD to communicate with
   users in another AD. In some respects, network resource control is
   simpler than network interconnection control since the potential
   dangers are fewer (i.e., denial of service and loss of revenue as
   compared with a wide range of attacks on end systems through network
   interconnection). However, controlled network resource sharing is
   more difficult to support.  In an internet a packet may travel
   through a number of transit ADs on its way to the destination.
   Consequently, policies from all transit ADs must be considered when a
   packet is being sent, whereas for stub-AD control only the policies
   of the two end point ADs have to be considered. In other words,
   controlled network resource sharing and transit require that policy
   enforcement be integrated into the routing protocols themselves and
   can not be left to network control mechanisms at the end points.
   (FOOTNOTE 6&7: Another difference is that in the interconnect case,
   traffic traveling over AD A's network resources always has a member
   of AD A as its source or destination (or both).  Under resource
   sharing arrangements members of both AD A and B are connected to the
   same resources and consequently intra-AD traffic (i.e., packets
   sourced and destined for members of the same AD) travels over the
   resources. This distinction is relevant to the writing of policies in
   terms of principal affiliation.  Economies of scale is one motivation
   for resource sharing. For example, instead of interconnecting
   separately to several independent agency networks, a campus network
   may interconnect to a shared backbone facility.  Today,
   interconnection is achieved through a combination of AD specific and
   shared arrangements. We expect this mixed situation to persist for
   "well-connected" campuses for reasons of politics, economics, and
   functionality (e.g., different characteristics of the different
   agency-networks). See Section 5 for more discussion.)

規模の経済を利用するために、ネットワーク資源(例えば、リンクか、ゲートウェイとリンク)を共有します。 外部のADsに対するトランジットサービスを提供するのは、ネットワーク資源共有に関する別の例です。 インタコネクトはすなわち、西暦1年のユーザが別のADのときにユーザとコミュニケートするのを許容するためにADsの向こう側に接続性を達成するために彼らの独自に使用されたネットワーク資源とインタコネクトするADsの、より一般的な例です。 ある点で、潜在的危険が、より少ないので(すなわち、ネットワーク相互接続を通したエンドシステムに対するさまざまな攻撃によるサービスの否定と比較されるとしての収入の損失)、ネットワーク資源制御装置はネットワーク相互接続コントロールより簡単です。 しかしながら、制御ネットワーク資源共有はサポートするのが、より難しいです。 インターネットでは、パケットは目的地への途中に多くのトランジットADsで移動するかもしれません。 その結果、パケットを送りますが、スタッブADコントロールだけにおいて2エンドポイントADsの方針を考えなければならないと、すべてのトランジットADsからの方針は考えなければなりません。 言い換えれば、制御ネットワーク資源共有とトランジットは、方針実施をルーティング・プロトコル自体と統合して、エンドポイントで制御機構をネットワークでつなぐのを残すことができないのを必要とします。 ( 6と7に脚注をつけてください; 別の違いは内部連絡場合には、AD Aのネットワーク資源の上に移動するトラフィックにそのソースか目的地(ともに)としてAD Aのメンバーがいつもいるということです。リソース・シェアリングアレンジメントで、AD AとBの両方のメンバーはリソースの上の同じリソースとその結果イントラADトラフィック(すなわち、同じADのメンバーのために出典を明示されて、運命づけられたパケット)旅行に接続されます。この区別は主要な提携で方針の書くことに関連しています; スケールの経済はリソース・シェアリングに関する1つの動機です。例えば、別々にいくつかの独立機関ネットワークに内部連絡することの代わりにキャンパスネットワークは共有されたバックボーン施設に内部連絡されるかもしれません。今日、インタコネクトはADの特定の、そして、共有されたアレンジメントの組み合わせで達成されます; 私たちは、この複雑な状況が政治、経済学、および機能性(例えば、異なった代理店網の異なった特性)の理由で「うまくつながいでいる」キャンパスへ持続すると予想します。より多くの議論に関してセクション5を見てください; )

   Complications also result from the fact that legitimate users of an
   AD's resources are not all located in that AD. Many users (and their
   computers) who are funded by, or are affiliated with, a particular
   agency's program reside within the AD of the user's university or
   research laboratory.  They reside in a campus AD along with users who
   are legitimate users of other AD resources.  Moreover, any one person
   may be a legitimate user of multiple AR resources under varying
   conditions and constraints (see examples in Section 6). In addition,
   users can move from one AD to another. In other words, a user's
   rights can not be determined solely based on the AD from which the
   user's communications originate.  Consequently, PR must not only
   identify resources, it must identify principals and associate

また、複雑さはAD'sのリソースの正統のユーザが皆、そのADのときに見つけられていないという事実から生じます。 資金を供給するか、または合併する多くのユーザ(そして、彼らのコンピュータ)、特定の政府機関のプログラムはユーザの大学か研究所のAD中にあります。 彼らはキャンパスに住んでいます。他のADリソースの正統のユーザであるユーザに伴う西暦。 そのうえ、どんな人も異なった状態と規制での複数のARリソースの正統のユーザであるかもしれません(セクション6で例を見てください)。 さらに、ユーザは西暦1年から別のものに移行できます。 言い換えれば、ユーザの権利は唯一ユーザのコミュニケーションが起因するADに基づいて決定できません。 その結果、PRがリソースを特定するだけでよくなくて、それは、主体を特定して、交際しなければなりません。

Estrin                                                          [Page 5]

RFC 1125                  Policy Requirements              November 1989

Estrin[5ページ]RFC1125方針要件1989年11月

   different capabilities and rights with different principals.  (The
   term principal is taken from the computer security community[7].)

異なった主体がある異なった能力と権利。 (コンピュータセキュリティ共同体[7]から用語主体を取ります。)

   One way of reducing the compromise of autonomy associated with
   interconnection is to implement mechanisms that assure
   accountability} for resources used. Accountability may be enforced a
   priori, e.g., access control mechanisms applied before resource usage
   is permitted.  Alternatively, accountability may be enforced after
   the fact, e.g., record keeping or metering that supports detection
   and provides evidence to third parties (i.e., non-repudiation).
   Accountability mechanisms can also be used to provide feedback to
   users as to consumption of resources. Internally an AD often decides
   to do away with such feedback under the premise that communication is
   a global good and should not be inhibited. There is not necessarily a
   "global good" across AD boundaries. Therefore, it becomes more
   appropriate to have resource usage visible to users, whether or not
   actual charging for usage takes place.  Another motivation that
   drives the need for accountability across AD boundaries is the
   greater variability in implementations. Different implementations of
   a single network protocol can vary greatly as to their efficiency
   [8].  We can not assume control over implementation across AD
   boundaries.  Feedback mechanisms such as metering (and charging in
   some cases) would introduce a concrete incentive for ADs to employ
   efficient and correct implementations.  PR should allow an AD to
   advertise and apply such accounting measures to inter-AD traffic.

インタコネクトに関連している自治の感染が責任を保証するメカニズムを実装することになっている減少における一方通行、運用資金のために。 責任は先験的に励行されるかもしれません、例えば、リソース用法が受入れられる前にアクセス管理機構が適用されました。 あるいはまた、責任が事実の後に励行されるかもしれなくて、例えば、キープを記録してくださいか、それを計量すると、検出がサポートされて、証拠は第三者に提供されます(非拒否しているすなわち、)。 また、リソースの消費に関してフィードバックをユーザに提供するのに責任メカニズムを使用できます。 内面的に、ADは、しばしばコミュニケーションをグローバルな利益であり、禁止するべきでないという前提の下にそのようなフィードバックを片づけると決めます。 必ずない、「グローバルな利益」がAD境界のむこうにあります。 したがって、ユーザにとって、目に見えるリソース用法を持っているのは、より適切になります、用法のための実際の充電が行われるか否かに関係なく。 AD境界の向こう側に責任の必要性を追い立てる別の動機は実装で、よりすばらしい可変性です。 ただ一つのネットワーク・プロトコルの異なった実装はそれらの効率[8]に関して大いに異なることができます。 私たちはAD境界の向こう側に実装のコントロールを仮定できません。 計量などなどの(いくつかの場合、充電して)フィードバック・メカニズムはADsが効率的で正しい実装を使う具体的な誘因を導入するでしょう。 PRは、そのような会計測定を相互ADトラフィックに広告を出して、適用するためにADを許容するべきです。

   In summary, the lack of global authority, the need to support network
   resource sharing as well as network interconnection, the complex and
   dynamic mapping of users to ADs and rights, and the need for
   accountability across ADs, are characteristics of inter-AD
   communications which must be taken into account in the design of both
   policies and supporting technical mechanisms.

概要では、グローバルな権威の不足(ADsの向こう側にネットワーク資源が責任のネットワーク相互接続と同様に共有して、ADsへのユーザの複雑でダイナミックなマッピングと、権利と、必要性であるとサポートする必要性)は、両方の方針のデザインで考慮に入れなければならない相互ADコミュニケーションの特性であり、技術的機構をサポートしています。

5  TOPOLOGY MODEL OF INTERNET

インターネットの5トポロジーモデル

   Before discussing policies per se, we outline our model of inter-AD
   topology and how it influences the type of policy support required.
   Most members of the Internet community agree that the future Internet
   will connect on the order of 150,000,000 termination points and
   100,000 ADs. However, there are conflicting opinions as to the AD
   topology for which we must design PR mechanisms.  The informal
   argument is described here.

そういうものとして政策を論じる前に、私たちは相互ADトポロジーのモデルについて概説します、そして、それがどう方針サポートのタイプに影響を及ぼすかが必要です。 インターネットコミュニティのほとんどのメンバーが、将来のインターネットが1億5000万終了ポイントと10万ADsの注文のときに接続するのに同意します。 しかしながら、私たちがPRメカニズムを設計しなければならないADトポロジーに関して対立意見があります。非公式の議論はここで説明されます。

   SIMPLE AD TOPOLOGY AND POLICY MODEL Some members of the Internet
   community believe that the current complex topology of interconnected
   ADs is a transient artifact resulting from the evolutionary nature of
   the Research Internet's history.  (FOOTNOTE 9: David Cheriton of
   Stanford University articulated this side of the argument at an

インターネットコミュニティのSIMPLE AD TOPOLOGY AND POLICY MODEL Someメンバーは、インタコネクトされたADsの現在の複雑なトポロジーがResearchインターネットの歴史の進化論の本質から生じる一時的な人工物であると信じています。 (FOOTNOTE9: スタンフォード大学のデヴィッドCheritonは議論の手前について明確に話しました。

Estrin                                                          [Page 6]

RFC 1125                  Policy Requirements              November 1989

Estrin[6ページ]RFC1125方針要件1989年11月

   Internet workshop in Santa Clara, January, 1989). The critical points
   of this argument relate to topology and policy. They contend that in
   the long term the following three conditions will prevail:

サンタクララのインターネットワークショップ、1989)年1月。 この議論の臨界点はトポロジーと方針に関連します。 彼らは、長期で以下の3つの条件が広がると主張します:

   * The public carriers will provide pervasive, competitively
     priced, high speed data services.

* パブリックキャリアは普及していて、競争的に値を付けられた高速データサービスを提供するでしょう。

   * The resulting topology of ADs will  be
     stub (not transit) ADs connected to regional
     backbones, which in turn interconnect via multiple,
     overlapping long haul backbones, i.e., a  hierarchy with
     no lateral connections between stub-ADs or regionals,
     and no vertical bypass links.

* ADsの結果として起こるトポロジーは順番に複数を通して内部連絡される地方のバックボーンに接続されたスタッブ(トランジットでない)ADsになるでしょう、長期バックボーン(すなわち、スタッブ-ADsか地方版にもかかわらず、垂直な迂回リンクの間の側部の接続のない階層構造)を重ね合わせて

   * The policy requirements of the backbone and stub-ADs
     will be based only on charging for resource usage at the
     stub-AD to backbone-AD boundary, and to settling accounts
     between neighboring backbone providers (regional to long haul,
     and long haul to long haul).

* バックボーンとスタッブ-ADsの方針要件はスタッブADのときにバックボーンAD境界と、そして、隣接しているバックボーンプロバイダーの間で勘定を清算することにリソース用法に課金するだけに基づくでしょう(長期、および長期への長期までの地方の)。

   Under these assumptions, the primary requirement for general AD
   interconnect is a metering and charging protocol. The routing
   decision can be modeled as a simple least cost path with the metric
   in dollars and cents. In other words, restrictions on access to
   transit services will be minimal and the functionality provided by
   the routing protocol need not be changed significantly from current
   day approaches.

これらの仮定で、一般的なAD内部連絡のためのプライマリ要件は、計量と充電プロトコルです。 簡単な最小費用経路としてドルとセントによるメートル法でルーティング決定をモデル化できます。 言い換えれば、トランジットサービスへのアクセスの制限は最小量になるでしょう、そして、現在の日のアプローチからルーティング・プロトコルによって提供された機能性をかなり変える必要はありません。

   COMPLEX AD TOPOLOGY AND POLICY MODEL The counter argument is that a
   more complex AD topology will persist. (FOOTNOTE 10:  Much of the
   remainder of this paper attempts to justify and provide evidence for
   this statement.) The different assumptions about AD topology lead to
   the significantly different assumptions about AD policies.

反対の議論のCOMPLEX AD TOPOLOGY AND POLICY MODELによる、より複雑なADトポロジーが固執するということです。 (FOOTNOTE10: この紙の残りの多くが、この声明に関する証拠を正当化して、提供するのを試みます。) ADトポロジーに関する異なった仮定はAD方針に関するかなり異なった仮定につながります。

   This model assumes that the topology of ADs will in many respects
   agree with the previous model of increased commercial carrier
   participation and resulting hierarchical structure. However, we
   anticipate unavoidable and persistent exceptions to the hierarchy.
   We assume that there will be a relatively small number of long haul
   transit ADs (on the order of 100), but that there may be tens of
   thousands of regional ADs and hundreds of thousands of stub ADs
   (e.g., campuses, laboratories, and private companies).  The competing
   long haul offerings will differ, both in the services provided and in
   their packaging and pricing.  Regional networks will overlap less and
   will connect campus and private company networks. However, many
   stub-ADs will retain some private lateral links for political,
   technical, and reliability reasons.  For example, political
   incentives cause organizations to invest in bypass links that are not

このモデルは、ADsのトポロジーがあらゆる点で増強された商業運送業者参加と結果として起こる階層構造の従来モデルに同意すると仮定します。 しかしながら、私たちは階層構造への避けられなくて永続的な例外を予期します。 私たちは、長期トランジットADs(100の注文での)の比較的少ない数がありますが、数万の地方のADsと何十万のスタッブADs(例えば、キャンパス、実験室、および民間企業)があるかもしれないと思います。 競争している長期提供は彼らの提供してパッケージと価格設定におけるサービスにおいて両方の、異なるでしょう。 地域ネットワークは、それほど重ならないで、キャンパスと民間企業ネットワークをつなげるでしょう。 しかしながら、多くのスタッブ-ADsが技術政治犯のためのいくつかの個人的な側部のリンクを保有するでしょう、そして、信頼性は推論します。 例えば、政治上の誘因で、組織はそうしない迂回リンクに投資されます。

Estrin                                                          [Page 7]

RFC 1125                  Policy Requirements              November 1989

Estrin[7ページ]RFC1125方針要件1989年11月

   always justifiable on a strict cost comparison basis; specialized
   technical requirements cause organizations to invest in links that
   have characteristics (e.g., data rate, delay, error, security) not
   available from public carriers at a competitive rate; and critical
   requirements cause organizations to invest in redundant back up links
   for reliability reasons.  These exceptions to the otherwise regular
   topology are not dispensible. They will persist and must be
   accommodated, perhaps at the expense of optimality; see Section 5 for
   more detail.  In addition, many private companies will retain their
   own private long haul network facilities. (FOOTNOTE 11:  While
   private voice networks also exist, private data networks are more
   common.  Voice requirements are more standardized because voice
   applications are more uniform than are data applications, and
   therefore the commercial services more often have what the voice
   customer wants at a price that is competitive with the private
   network option. Data communication requirements are still more
   specialized and dynamic.  Thus, there is less opportunity for economy
   of scale in service offerings and it is harder to keep up to date
   with customer demand. For this reason we expect private data networks
   to persist for the near future. As the telephone companies begin to
   introduce the next generation of high speed packet switched services,
   the scenario should change. However, we maintain that the result will
   be a predominance, but not complete dominance, of public carrier use
   for long haul communication.  Therefore, private data networks will
   persist and the routing architecture must accommodate controlled
   interconnection.)  Critical differences between the two models follow
   from the difference in assumptions regarding AD topology. In the
   complex case, lateral connections must be supported, along with the
   means to control the use of such connections in the routing
   protocols.

厳しい原価比較ベースでいつも正当。 専門化している技術的要求事項で、組織はパブリックキャリアから競争料金で利用可能でない特性(例えば、データ信号速度、遅れ、誤り、セキュリティ)を持っているリンクに投資されます。 そして、重要な要件で、組織は信頼性の理由のための余分な逆アップリンクに投資されます。 そうでなければ、通常のトポロジーへのこれらの例外はdispensibleではありません。 それらは固執して、恐らく最適を犠牲にして設備しなければなりません。 その他の詳細に関してセクション5を見てください。 さらに、多くの民間企業がそれら自身の個人的な長期ネットワーク施設を保有するでしょう。 (脚注11: また、私設の声のネットワークは存在していますが、個人的なデータ網は、より一般的です。 音声アプリケーションがデータアプリケーションより一定であるので、声の要件はさらに標準化されます、そして、したがって、商業サービスには、声の顧客が個人的なネットワークオプションで他社にひけをとらない価格で欲しいものが、よりしばしばあります。 データ通信要件は、まして専門化していてダイナミックです。 したがって、規模の経済の使用中の提供の、より少ない機会があります、そして、それは顧客要求でより時代について行かせにくいです。 この理由で、私たちは、個人的なデータ網がもうしばらくの間は持続すると予想します。 電話会社が高速パケットの切り換えられたサービスの次世代を導入し始めるのに従って、シナリオは変化するべきです。 しかしながら、私たちは、結果が完全優勢ではなく、長期コミュニケーションのパブリックキャリア使用の優位になるのを支持します。 したがって、個人的なデータ網は持続するでしょう、そして、ルーティングアーキテクチャは制御インタコネクトを収容しなければなりません。) 2つのモデルのきわどい違いはADトポロジーに関する仮定の違いから続きます。 複雑な場合では、側部の接続をサポートしなければなりません、ルーティング・プロトコルにおけるそのような接続の使用を制御する手段と共に。

   The different topologies imply different policy requirements.  The
   first model assumes that all policies can be expressed and enforced
   in terms of dollars and cents and distributed charging schemes. The
   second model assumes that ADs want more varied control over their
   resources, control that can not be captured in a dollars and cents
   metric alone. We describe the types of policies to be supported and
   provide examples in the following section, Section 6. In brief, given
   private lateral links, ADs must be able to express access and
   charging related restrictions and privileges that discriminate on an
   AD basis.  These policies will be diverse, dynamic, and new
   requirements will emerge over time, consequently support must be
   extensible.  For example, the packaging and charging schemes of any
   single long haul service will vary over time and may be relatively
   elaborate (e.g., many tiers of service, special package deals, to
   achieve price discrimination).

異なったtopologiesは異なった方針要件を含意します。 第1代モデルはドル、セント、および分配された充電体系ですべての方針を言い表して、励行できると仮定します。 第2代モデルは、ADsが彼らのリソース(ドルとセントでメートル法で単独で得ることができないコントロール)の、より様々なコントロールが欲しいと仮定します。 私たちは、サポートされる方針のタイプについて説明して、以下のセクション、セクション6の例を提供します。 個人的な側部のリンクを考えて、要するに、ADsはアクセスを言い表すことができなければなりません、そして、充電はADベースで差別する制限と特権を関係づけました。 これらの方針がさまざまになる、ダイナミックで、新しい要件は時間がたつにつれて現れて、その結果、サポートは広げることができなければなりません。 例えば、パッケージとただ一つにどんな長期サービスの体系も請求するのは、時間がたつにつれて、異なって、比較的入念であるかもしれません(例えば、多くのサービスの層、価格差別を達成する特別な一括取引)。

   Note that these assumptions about complexity do not preclude some

複雑さに関するこれらの仮定がいくつかを排除しないことに注意してください。

Estrin                                                          [Page 8]

RFC 1125                  Policy Requirements              November 1989

Estrin[8ページ]RFC1125方針要件1989年11月

   collection of ADs from "negotiating away" their policy differences,
   i.e., forming a federation, and coordinating a simplified inter-AD
   configuration in order to reduce the requirements for inter-AD
   mechanisms.  However, we maintain that there will persist collections
   of ADs that will not and can not behave as a single federation; both
   in the research community and, even more predominantly, in the
   broader commercial arena.  Moreover, when it comes to interconnecting
   across these federations, non-negotiable differences will arise
   eventually.  It is our goal to develop mechanisms that are applicable
   in the broader arena.

すなわち、彼らの方針差の連合体を結成して、aを調整しながら「譲歩」であるのからのADsの収集は、相互ADメカニズムのための要件を減らすために相互AD構成を簡素化しました。しかしながら、私たちは、振る舞わないで、単一の連邦として振る舞うことができないADsの収集が持続すると主張します。 研究団体とさらに支配的にコネにおける、より広い商業アリーナ。 そのうえ、これらの連邦の向こう側に内部連絡することとなると、譲渡禁止の違いは結局、起こるでしょう。 より広いアリーナで適切なメカニズムを開発するのは、私たちの目標です。

   The Internet community developed its original protocol suite with
   only minimal provision for resource control [9].  This was
   appropriate at the time of development based on the assumed community
   (i.e., researchers) and the ground breaking nature of the technology.
   The next generation of network technology is now being designed to
   take advantage of high speed media and to support high demand traffic
   generated by more powerful computers and their applications [10].  As
   with TCP/IP we hope that the technology being developed will find
   itself applied outside of the research community. This time it would
   be inexcusable to ignore resource control requirements and not to pay
   careful attention to their specification.

インターネットコミュニティは資源管理[9]への最小量の支給だけで元のプロトコル群を開発しました。 これは想定された共同体(すなわち、研究者)に基づく開発と地面時点で技術の壊れている本質を当てることでした。 ネットワーク技術の次世代は、今、高速メディアを利用して、高需要が、より強力なコンピュータと彼らのアプリケーション[10]で生成されたトラフィックであるとサポートするように設計されています。 TCP/IPのように、気付くと開発された技術によって研究団体の外に適用されていることを願っています。 今回、資源管理要件を無視して、それらの仕様に関する慎重な注意を向けないのは許しがたいでしょう。

   Finally, we look forward to the Internet structure taking advantage
   of economies of scale offered by enhanced commercial services.
   However, in many respects the problem that stub-ADs may thus avoid,
   will be faced by the multiple regional and long haul carriers
   providing the services. The carriers' charging and resource control
   policies will be complex enough to require routing mechanisms similar
   to ones being proposed for the complex AD topology case described
   here.  Whether the network structure is based on private or
   commercial services, the goal is to construct policy sensitive
   mechanisms that will be transparent to end users (i.e., the
   mechanisms are part of the routing infrastructure at the network
   level, and not an end to end concern).

最終的に、高められた商業サービスで提供された規模の経済を利用するインターネット構造を楽しみにしています。 しかしながらあらゆる点でサービスを提供することにおけるその結果スタッブ-ADsが顔の倍数による地方と長期がキャリヤーであるつもりであったなら避けるかもしれない問題。 キャリヤーの充電と資源管理方針はここで説明された複雑なADトポロジーケースのために提案されるものと同様のメカニズムを発送するのが必要であるほど複雑になるでしょう。 ネットワーク構造が個人的であるか商業のサービスに基づいているか否かに関係なく、目標はエンドユーザにとって、見え透いた方針敏感なメカニズムを構成する(すなわち、メカニズムは関心を終わらせる終わりではなく、ネットワークレベルにおけるルーティングインフラストラクチャの一部です)ことです。

6  POLICY TYPES

6 方針タイプ

   This section outlines a taxonomy of internet policies for inter-AD
   topologies that allow lateral and bypass links.  The taxonomy is
   intended to cover a wide range of ADs and internets. Any particular
   PR architecture we design should support a significant subset of
   these policy types but may not support all of them due to technical
   complexity and performance considerations.  The general taxonomy is
   important input to a functional specification for PR. Moreover, it
   can be used to evaluate and compare the suitability and completeness
   of existing routing architectures and protocols for PR; see Section
   8.

このセクションは側部と迂回リンクを許容する相互AD topologiesのためにインターネット方針の分類学について概説します。 分類学がさまざまなADsとインターネットを含んでいることを意図します。 私たちが設計するどんな特定のPRアーキテクチャも、これらの方針タイプの重要な部分集合をサポートするべきですが、技術的な複雑さと性能問題のため彼らを皆、サポートしないかもしれません。 一般的な分類学はPRのための機能的な仕様への重要な入力です。 そのうえ、PRのために既存のルーティングアーキテクチャとプロトコルの適合と完全性を評価して、比較するのにそれを使用できます。 セクション8を見てください。

Estrin                                                          [Page 9]

RFC 1125                  Policy Requirements              November 1989

Estrin[9ページ]RFC1125方針要件1989年11月

   We provide examples from the Research Internet of the different
   policy types in the form of resource usage policy statements. These
   statements were collected through interviews with agency
   representatives, but they do not represent official policy. These
   sample policy statements should not} be interpreted as agency policy,
   they are provided here only as examples.

私たちは例を異なった方針タイプのResearchインターネットからリソース用法施政方針の形に供給します。 これらの声明は政府機関代表とのインタビューで集められましたが、彼らは公式方針を表しません。 これらのサンプル施政方針が提供するべきでない、政府機関方針として解釈してください、そして、単に例としてそれらをここに提供します。

   Internet policies fall into two classes, access and charging.  Access
   policies specify who can use resources and under what conditions.
   Charging policies specify the metering, accounting, and billing
   implemented by a particular AD.

インターネット方針は2つのクラス、アクセス、および充電になります。 アクセス方針は、だれがリソースを使用できるかを指定して、どんな状態の下でそうするか。 充電方針は特定のADまでに実装された計量、会計、および支払いを指定します。

6.1  TAXONOMY OF ACCESS POLICIES

6.1 アクセス方針の分類学

   We have identified the following types of access policies that ADs
   may wish to enforce. Charging policies are described in the
   subsequent section. Section 6.3 provides more specific examples of
   both access and charging policies using FRICC policy statements.

私たちはADsが実施したがっているかもしれない以下のタイプのアクセス方針を特定しました。 充電方針はその後のセクションで説明されます。 セクション6.3は、FRICC施政方針を使用することでアクセスと充電方針の両方の、より特定の例を提供します。

   Access policies typically are expressed in the form: principals of
   type x can have access to resources of type y under the following
   conditions, z. The policies are categorized below according to the
   definition of y and z.  In any particular instance, each of the
   policy types would be further qualified by definition of legitimate
   principals, , x, i.e., what characteristics x must have in order to
   access the resource in question.

アクセス方針はフォームで通常言い表されます: タイプxの主体は以下の条件、zの下でタイプyに関するリソースに近づく手段を持つことができます。 yとzの定義に従って、方針は以下で分類されます。 どんな特定のインスタンスでも、定義上正統の主体についてさらに方針タイプ各人に資格があって、xにはx、すなわち、どんな特性が問題のリソースにアクセスするためになければならないかをそうされます。

   We refer to access policies described by stub and transit ADs.  The
   two roles imply different motivations for resource control, however
   the types of policies expressed are similar; we expect the supporting
   mechanisms to be common as well.

私たちはアクセスのスタッブによって説明された方針とトランジットADsについて言及します。 しかしながら、2つの役割が資源管理に関する異なった動機を含意して、言い表された方針のタイプは同様です。 私たちは、また、サポートメカニズムも一般的であると予想します。

   Stub and transit access policies may specify any of the following
   parameters:

スタッブとトランジットアクセス方針は以下のパラメタのどれかを指定するかもしれません:

   * SOURCE/DESTINATION
   Source/Destination policies prevent or restrict communication
   originated by or destined for particular ADs (or hosts or user
   classes within an AD).

* SOURCE/DESTINATION Source/目的地方針は、特定のADs(または、AD以内のホストかユーザ・クラス)のために溯源されたコミュニケーションを防いだか、制限した、または運命づけました。

   * PATH
   Path sensitive policies specify which ADs may or may not be passed
   through en route to a destination. The most general path sensitive
   policies allow stub and transit ADs to express policies that depend
   on any component in the AD path. In other words, a stub AD could
   reject a route based on any AD (or combination of ADs) in the route.
   Similarly, a transit AD could express a packet forwarding policy that
   behaves differently depending upon which ADs a packet has passed

* PATH Pathの敏感な方針は、どのADsが目的地への途中で通り抜けるかもしれないかを指定します。 最も一般的な経路敏感な方針で、スタッブとトランジットADsはAD経路のどんなコンポーネントにもよる方針を言い表すことができます。 言い換えれば、aはADを引き抜きます。ルートによるどんなAD(または、ADsの組み合わせ)も基づくルートは拒絶できました。 同様に、ADs aパケットが持っているADがそれが異なってよりながら振る舞わせるパケット推進方針を言い表すことができたトランジットは終わりました。

Estrin                                                         [Page 10]

RFC 1125                  Policy Requirements              November 1989

Estrin[10ページ]RFC1125方針要件1989年11月

   through, and is going to pass through, en route to the destination.
   Less ambitious (and perhaps more reasonable) path sensitive policies
   might only discriminate according to the immediate neighbor ADs
   through which the packet is traveling (i.e., a stub network could
   reject a route based on the first transit AD in the route, and a
   transit AD could express a packet forwarding policy that depends upon
   the previous, and the subsequent, transit ADs in the route.)

通じて、目的地への途中通り抜ける行くことであること。 パケットが移動しているすぐ隣の人ADsによると、それほど野心満々でなくて(恐らくより妥当)の経路敏感な方針は差別するだけであるかもしれません。ルートが1日に基礎づけた廃棄物はADを通過するかもしれません。(すなわち、スタッブネットワーク、ADが急送できたルート、およびトランジットでは、それを方針に送るパケットが前、およびその後(ルートによるトランジットADs)による、)

   * QUALITY/TYPE OF SERVICE(QOS OR TOS)
   This type of policy restricts access to special resources or
   services.  For example, a special high throughput, low delay link may
   be made available on a selective basis.

* これがタイプする方針のQUALITY/TYPE OF SERVICE(QOS OR TOS)は特別なリソースかサービスへのアクセスを制限します。 例えば、特別な高生産性に、低い遅れリンクを当期実績主義で利用可能にするかもしれません。

   * RESOURCE GUARANTEE
   These policies provide a guaranteed percentage of a resource on a
   selective, as needed basis.  In other words, the resource can be used
   by others if the preferred-AD's offered load is below the guaranteed
   level of service.  The guarantee may be to always carry intra-AD
   traffic or to always carry inter-AD traffic for a specific AD.

* RESOURCE GUARANTEE These方針は必要な基礎として選択しているaに関するリソースの保証された割合を提供します。 言い換えれば、都合のよいAD'sの提供された負荷が保証されたレベルのサービスの下にあるなら、他のものはリソースを使用できます。 保証は、いつもイントラADトラフィックを運ぶか、またはいつも相互ADトラフィックを特定のADまで運ぶことであるかもしれません。

   *  TEMPORAL
   Temporal policies restrict usage based on the time of day or other
   time related parameters.

* TEMPORAL Temporal方針は時刻に基づく用法か他の時間関係パラメータを制限します。

   *  HIGH LEVEL PROTOCOL
   Usage may be restricted to a specific high level protocol such as
   mail or file transfer. (Alternatively, such policies can be
   implemented as source/destination policies by configuring a host(s)
   within an AD as an application relay and composing policy terms that
   allow inter-AD access to only that host.)

* HIGH LEVEL PROTOCOL Usageはメールかファイル転送などの特定の高い平らなプロトコルに制限されるかもしれません。 (あるいはまた、ソース/目的地方針としてAD以内にアプリケーションリレーとしてホストを構成して、そのホストだけへの相互ADアクセスを許す方針用語を構成することによって、そのような政策を実施されることができます。)

   *  RESOURCE LIMIT
   There may be a limit on the amount of traffic load a source may
   generate during a particular time interval, e.g., so many packets in
   a day, hour, or minute.

* RESOURCE LIMIT Thereは日、時間、または1分間ソースが特定の時間間隔、例えば、とても多くのパケットの間に生成するかもしれないトラヒック負荷の量における限界であるかもしれません。

   *  AUTHENTICATION REQUIREMENTS
   Conditions may be specified regarding the authenticability of
   principal identifying information. Some ADs might require some form
   of cryptographic proof as to the identity and affiliations of the
   principal before providing access to critical resources.

* AUTHENTICATION REQUIREMENTS Conditionsは主要な身元が分かる情報のauthenticabilityに関して指定されるかもしれません。 重要な資源へのアクセスを提供する前に、いくつかのADsが主体のアイデンティティと提携に関して何らかのフォームの暗号の証拠を必要とするかもしれません。

   The above policy types usually exist in combination for a particular
   AD, i.e., an AD's policies might express a combination of transit,
   source/destination, and QOS restrictions. This taxonomy will evolve
   as PR is applied to other domains.

特定のADの間、通常、上の方針タイプは組み合わせで存在しています、すなわち、AD'sの方針がトランジットの組み合わせ、ソース/目的地、およびQOS制限を表すかもしれません。 PRが他のドメインに適用されるとき、この分類学は発展するでしょう。

   As will be seen in Section 6.3 an AD can express its charging and

そしてADが目にふれているコネがセクション6.3であるつもりであったなら充電を言い表すことができる。

Estrin                                                         [Page 11]

RFC 1125                  Policy Requirements              November 1989

Estrin[11ページ]RFC1125方針要件1989年11月

   access policies in a single syntax. Moreover, both stub and transit
   policies can co-exist. This is important since some ADs operate as
   both stub and transit facilities and require such hybrid control.

ただ一つの構文で方針にアクセスしてください。 そのうえ、スタッブと運送保険証券の両方が共存できます。 いくつかのADsがスタッブと交通の便の両方として作動して、そのようなハイブリッドコントロールを必要とするので、これは重要です。

6.2 TAXONOMY OF CHARGING POLICIES

6.2 充電方針の分類学

   Stub and transit charging policies  may specify the following
   parameters:

方針を請求するスタッブとトランジットは以下のパラメタを指定するかもしれません:

   *  UNIT OF ACCOUNTING (e.g., dollars or credits).
   *  BASIS FOR CHARGING (e.g., per Kbyte or per Kpkt).
   *  ACTUAL CHARGES (e.g., actual numbers such as $.50/Mbyte).
   *  WHO IS CHARGED OR PAID (e.g., originator of packet,
      immediate neighbor from whom packet was received, destination
      of packet, a third party collection agent).
   *  WHOSE PACKET COUNT is used (e.g., source, destination, the
      transit AD's own count, the count of some upstream or
      downstream AD).
   *  BOUND ON CHARGES (e.g., to limit the  amount that a stub
      AD is willing to spend, or the amount that a transit AD is
      willing to carry.)

* UNIT OF ACCOUNTING(例えば、ドルかクレジット)。 * 充電する(例えば、キロバイトかKpkt単位で)基礎。 * ACTUAL CHARGES(例えば、.50ドル/メガバイトなどの実数)。 * WHO IS CHARGED OR PAID、(例えば、パケットの生成元、パケットが受け取られたすぐ隣の人、パケットの目的地、第三者収集エージェント) * WHOSE PACKET COUNTは使用されています(例えば、ソース、目的地、西暦のものが所有しているトランジットが重要であり、いくつかの上流か川下のカウントはADです)。 * 充電のときに、バウンドしてください。例えば量を制限するために、aがADを引き抜くのは、費やす望み、または量です。(aがADを通過するのが運んでも構わないと思っている、)

   The enforcement of these policies may be carried out during route
   synthesis or route selection [4].

これらの方針の実施がルート統合かルート選択[4]の間、行われるかもしれません。

6.3  EXAMPLE POLICY STATEMENTS

6.3 例の施政方針

   The following policy statements were collected in the fall of 1988
   through interviews with representatives of the federal agencies most
   involved in supporting internetworking. Once again we emphasize that
   these are not official policy statements. They are presented here to
   provide concrete examples of the sort of policies that agencies would
   like to enforce.

以下の施政方針はインターネットワーキングをサポートするのに最もかかわる連邦機関の代表とのインタビューによる1988年秋に集められました。 もう一度、私たちは、これらが公式方針声明でないと強調します。 それらは、政府機関が実施したがっている方針の種類に関する具体的な実例を提供するためにここに提示されます。

   Expressing policies as Policy Terms (PTs)

Policy Termsとして方針を言い表します。(Pt)

   Each policy is described in English and then expressed in a policy
   term (PT) notation suggested by Dave Clark in [4].  Each PT
   represents a distinct policy of the AD that synthesized it.  The
   format of a PT is:

各方針は[4]でデーブ・クラークによって提案されたイギリスの、そして、次に、方針用語で言い表された(太平洋標準時の)記法で説明されます。 各PTはそれを統合したADの異なった方針を表します。 太平洋標準時の1時の形式は以下の通りです。

    [(H{src},AD{src},AD{ent}),(H{dst},AD{dst},AD{exit}),UCI, Cg,Cb]

(H src、AD src、AD ent)、(H dst、AD dst、AD出口)、UCI、Cg、Cb]

   Hsrc stands for source host, ADsrc for source AD, ADent for entering
   AD (i.e., neighboring AD from which traffic is arriving directly),
   Hdst for destination host, ADdst for destination AD, ADexit for exit
   AD (i.e.,neighboring AD to which traffic is going directly), UCI for
   user class identifier, and Cg and Cb for global and bilateral

Hsrcが送信元ホスト、ADsrcのために立つ、ADの出典を明示してください、AD(すなわち、トラフィックが直接到着しているADを近所付き合いさせる)に入るためのADent、あて先ホストのためのHdst、ADdst、目的地、AD、出口のAD(すなわち、トラフィックが直接行くADを近所付き合いさせる)、ユーザ・クラス識別子のためのUCI、Cg、およびCbへのADexit、グローバルで双方

Estrin                                                         [Page 12]

RFC 1125                  Policy Requirements              November 1989

Estrin[12ページ]RFC1125方針要件1989年11月

   conditions, respectively. The purpose of a PT is to specify that
   packets from some host, H{src}, (or a group of hosts) in a source AD,
   AD{src}, are allowed to enter the AD in question via some directly
   connected AD, AD{ent}, and exit through another directly connected
   AD, AD{exit}, on its way to a host, H{dst}, (or a group of hosts) in
   some destination AD, AD{dst}.  User Class Identifier (UCI) allows for
   distinguishing between various user classes, e.g., Government,
   Research, Commercial, Contract, etc.  Global Conditions (Cg)
   represent billing and other variables.  Bilateral Conditions (Cb)
   relate to agreements between neighboring ADs, e.g., related to
   metering or charging.  In the example policy terms provided below we
   make use of the following abbreviations: Fricc for
   {DOE,NASA,DCA,NSF}, F for Federal Agency, Re for Regional, U for
   University, Co for Commercial Corporation, and Cc for Commercial
   Carrier. A hyphen, -, means no applicable matches.

それぞれ状態。 太平洋標準時の1時の目的は中でホスト(H src)からのそのパケット(または、ホストのグループ)を指定することです。aがADの出典を明示して、ADはsrcして、いつかの直接接続されたADを通して問題のADに入ることができます、AD ent、そして、別のものを通した出口は直接AD、AD出口をホストへの途中につなげました、H dst、(または、ホストのグループ)コネ、いくつかの目的地、AD、AD dst。 ユーザClass Identifier(UCI)は、様々なユーザ・クラス、例えば、政府、Research、Commercial、Contractなどを見分けると考慮します。 グローバルなConditions(Cg)は支払いと他の変数を表します。 (Cb)が例えばADsを近所付き合いさせることの間の協定に関係づける双方のConditionsは計量か充電に関連しました。 以下に提供された例の方針用語で、私たちは以下の略語を利用します: ドウ、NASA、DCA、NSFのためのFricc、連邦政府関係機関のためのF、地方版のためのre、大学のためのU、共同、営利会社、および商業運送業者のためのcc。 -ハイフンであり、適切でない手段は合っています。

   By examining a PT we can identify the type of policy represented, as
   per the taxonomy presented earlier.

太平洋標準時の1時を調べることによって、私たちは、より早く提示された分類学に従って表された方針のタイプを特定できます。

   *  If an AD specifies a policy term that has a null (-) entry for
      the ADexit, then it is disallowing transit for some group of users,
      and it is a transit policy.

* ADがヌル(-)エントリーを持っている方針用語をADexitに指定するなら、何らかのユーザー層のためのトランジットを禁じています、そして、運送保険証券です。

   *  If an AD specifies a  policy term that lists itself
      explicitly as ADsrc or ADdst, it is expressing restrictions on who
      can access particular resources within its boundaries, or on who inside
      can obtain external access. In other words the AD is expressing a
      source/destination policy.

* ADがADsrcかADdstとして明らかにそれ自体を記載する方針用語を指定するなら、それは内部が外部のアクセサリーを得ることができるというだれが境界以内かだれに関して特定のリソースにアクセスできるかに関する制限を表しています。 言い換えれば、ADはソース/目的地方針を言い表しています。

   *  If ADexit or ADentr is specified then the policy expressed is an
      exit/entrance path policy.

* ADexitかADentrが指定されるなら、言い表された方針は出口/入り口の経路方針です。

   *  If the global conditions include charging, QOS, resource
      guarantee,  time of day, higher level application, resource limit, or
      authentication related information it is obviously a charging, QOS,
      resource guarantee, temporal, higher level application, resource
      limit, or authentication policy, respectively.

* グローバルな状態が、充電するのを含んでいるか、そして、QOS、リソース保証、時刻、より高い平らなアプリケーション、リソース限界、または認証がそれぞれそれが明らかに充電であるという情報、QOS、リソース保証、時の、そして、より高い平らなアプリケーション、リソース限界、または認証方針を話しました。

   As seen below, any one PT typically incorporates a combination of
   policy types.

以下が見られるように、太平洋標準時の1つどんな時も方針タイプの組み合わせを通常取り入れます。

6.3.1  THE FRICC

6.3.1 FRICC

   In the following examples all policies (and PTs) are symmetrical
   under the assumption that communication is symmetrical.

以下の例では、すべての方針(そして、PTs)がコミュニケーションが対称であるという仮定で対称です。

Estrin                                                         [Page 13]

RFC 1125                  Policy Requirements              November 1989

Estrin[13ページ]RFC1125方針要件1989年11月

NATIONAL SCIENCE FOUNDATION (NSF)

科学基金(NSF)

   1.  NSF will carry traffic for any host connected to a F/Re network
   talking to any other host connected to a F/Re via any F/Re entry and
   exit network, so long as there is it is being used for research or
   support. There is no authentication of the UCI and no per packet
   charging.  NSFnet is a backbone and so does not connect directly to
   universities or companies...thus the indication of {F/Re} instead of
   {F/Re/U/Co} as ADent and ADexit.

1. NSFはどんなF/reエントリーと出口ネットワークを通してもF/reに接続されたいかなる他のホストとも話すF/reネットワークに接続されたどんなホストのためにもトラフィックを運ぶでしょう、非常に長いので、あって、それは研究かサポートに使用されています。 UCIの認証が全くありません、そして、パケット充電あたりいいえ。 NSFnetはバックボーンであるので直接大学か会社に接続しません…の代わりにする、その結果、F/reのしるし、F/re/u/、共同、ADentとADexitとして。

   [NSF1:  (*, {F/Re}, {F/Re})(*, {F/Re}, {F/Re}){research,support}
   {unauthenticated UCI,no-per-pkt charge}{}]

[NSF1: 研究、(*、F/re、F/re)(*、F/re、F/re)サポート、unauthenticated UCI、いいえ、1pktあたり充電、]

   2.  NSF will carry traffic to user and expert services hosts in NSF
   AD to/from any F/Re AD, via any F/Re AD. These are the only things
   that directly connect to NSFnet.

2. NSFはNSF ADでどんなF/re ADからの/までもユーザと専門のサービスホストへのトラフィックを運ぶでしょう、どんなF/re ADを通しても。 これらは直接NSFnetに接続する唯一のものです。

   [NSF2: ({User svcs, Expert Svcs},{NSF},{F/Re})(*,{F/Re},{-}){}{}{}]

[NSF2: (ユーザsvcs、Expert Svcs、NSF、F/re) (*、F/re、-、)、]

DEPARTMENT OF ENERGY (DOE)

エネルギー省(ドウ)

   1.  DOE will carry traffic to and from any host directly connected to
   DOE so long as it is used for research or support. There is no
   authentication of the UCI and no per packet charging.

1. それが研究かサポートに使用される限り、DOEはホストと、そして、直接接されたどんなホストからDOEまでトラフィックを運ぶでしょう。 UCIの認証が全くありません、そして、パケット充電あたりいいえ。

   [DOE1: (*,DOE,-)(*,*,*){research,support}
   {unauthenticated UCI,no-per-packet charge}{}]

[DOE1: (*、DOE、-、)、研究、(*、*、*)サポート、unauthenticated UCI、いいえ、1パケットあたり充電、]

   2.  DOE will carry traffic for any host connected to a F/Re network
   talking to any other host connected to a F/Re via any F/Re entry and
   exit network without regard to the UCI. There is no authentication of
   the UCI and no per packet charging. (in other words DOE is more
   restrictive with its own traffic than with traffic it is carrying as
   part of a resource sharing arrangement.)

2. DOEはどんなF/reエントリーと出口ネットワークを通しても関係なしでF/reに接続されたいかなる他のホストとも話すF/reネットワークに接続されたどんなホストのためにもUCIまでトラフィックを運ぶでしょう。 UCIの認証が全くありません、そして、パケット充電あたりいいえ。 (言い換えれば、DOEはリソース・シェアリングアレンジメントの一部としてトラフィックで運ぶ予定であるよりそれ自身のトラフィックで制限しています。)

   [DOE2: (*,{F/Re},{F/Re})(*,{F/Re},{F/Re}){}
   {unauthenticated UCI, no-per-pkt charge}{}]

[DOE2: (*、F/re、F/re)(*、F/re、F/re)、unauthenticated UCI、いいえ、1pktあたり充電、]

NATIONAL AERONAUTICS AND SPACE ADMINISTRATION (NASA)

米国航空宇宙局(NASA)

   1.  Nasa will accept any traffic to/from members of the Nasa AD. But
   no transit. No UCI authentication and no per packet charge.

1. NasaはNasa ADのメンバーからの/にどんなトラフィックも受け入れるでしょう。 トランジットがありません。 UCI認証とパケット充電あたりいいえ。

   [NASA1: (*,*,*)(*,Nasa,-){Nasa-research, support}
   {unauthenticated UCI,no-per-packet-charge}{}]

[NASA1: (*、*、*) (*、Nasa、-、)、Nasa-研究、サポート、いいえ、unauthenticated UCI、パケット充電あたり]

   2.  Nasa will carry transit traffic to/from other federal agency
   networks if it is in support of research, and if the total use of

2. Nasaは研究を支持していて、総使用であるなら他の連邦機関ネットワークからの/までトランジットトラフィックを運ぶために望んでいます。

Estrin                                                         [Page 14]

RFC 1125                  Policy Requirements              November 1989

Estrin[14ページ]RFC1125方針要件1989年11月

   available BW by non-nasa Federal agencies is below n%. NOTE THAT this
   non-interference policy type needs some more work in terms of
   integrating it into the routing algorithms. See Section 7.

非nasaの連邦政府の機関による利用可能なBWがn%の下にあります。 この不干渉方針がタイプするNOTE THATはそれをルーティング・アルゴリズムと統合することに関してそれ以上の仕事を必要とします。セクション7を見てください。

   [NASA2: (*,{F},*)(*,{F},*){research,support}
   {per-packet accounting, limited to n% of available BW}{}]

[NASA2: 研究、1パケットあたりの会計であって、n%の利用可能なBWに限られた(*、F、*)(*、F、*)サポート、]

   3.  NASA will carry commercial traffic to federal and regional and
   university ADs for nasa research or support. But it will not allow
   transit. The particular entry AD is not important.

3. NASAはnasa研究かサポートのために連邦と地方への商業トラフィックと大学ADsを運ぶでしょう。 しかし、それはトランジットを許容しないでしょう。 特定のエントリー、ADは重要ではありません。

   [NASA3: (*,{Co},*} (*,{F/R/U},*) {NASA research,support}
    {unauthenticated UCI, no per packet charge}{}]

[NASA3: (*、共同、*、NASAの研究、(*、F/R/U、*)サポート、unauthenticated UCI、いいえ、パケット充電あたり]

   4.  On a case by case basis NASA may provide access to its resources
   on a cost reimbursed basis. Transit traffic will not be carried on
   this basis.

4. aでは、ケースバイケースで、基礎NASAは基礎が還付された費用に関するリソースへのアクセスを提供するかもしれません。 トランジットトラフィックはこのベースで運ばれないでしょう。

    [NASA4: (*,*,-)(*,*,-){}
    {per-packet-charge, limited to n% of available BW} {}]

[NASA4: (*、*、-、)、(*、*、-、)、パケット単位で充電していて、n%の利用可能なBWに制限される、]

DEFENSE ADVANCED RESEARCH PROJECTS AGENCY (DARPA)

国防高等研究計画庁(DARPA)

   1.  DARPA will carry traffic to/from any host in DARPA AD from any
   external host that can get it there so long as UCI is research or
   support. No UCI authentication or per packet charge.

1. DARPAはUCIが研究かサポートである限り、それをそこに到着させることができるどんな外部のホストからもDARPA ADのどんなホストからの/までもトラフィックを運ぶでしょう。 UCI認証かパケット充電あたりいいえ。

   [DARPA1: (*,*,*)(*,DARPA,-){research,support}
   {unauthenticated-UCI, no per packet charge}{}]

[DARPA1: (*、*、*) (*、DARPA、-、)、研究、サポート、unauthenticated-UCI、いいえ、パケット充電あたり]

   2.  DARPA will carry traffic for any host connected to a F/Re/U/Co
   network talking to any other host connected to a F/Re/U/Co via any
   F/Re/U/Co entry and exit network, so long as there is it is being
   used for research or support, and the network is not heavily
   congested!!.  There is no authentication of the UCI and no per packet
   charging.  NOTE: Darpa would like to say something about the need to
   enter the Darpa AD at the point closest to the destination...but i
   don't know how to express this...

2. を通してDARPAがF/re/U/に接されたいかなる他のホストとも話しながらF/共同re/u/ネットワークに接続されたどんなホストのためにもトラフィックを運ぶ、共同、それがあって、長さはどんなF/共同re/U/エントリーと出口ネットワークによっても研究かサポートに使用されていて、ネットワークはずっしりと充血しません!. UCIの認証が全くありません、そして、パケット充電あたりいいえ。 以下に注意してください。 Darpaはポイントで目的地の最も近くにDarpa ADを入れる必要性に関して何かを言いたがっています…しかし、私はこれを言い表す方法を知りません…

   DARPA2: (*,{F/R/U/Co},{F/R/U/Co})(*,{F/R/U/Co},{F/R/U/Co})
   {research,support}{unauthenticated-UCI,no per packet charge,
   non-interference basis}{}]

DARPA2: (*、F/R/u/、共同、F/R/u/、共同、)(*、F/R/u/、共同、F/R/u/、共同、) 研究、サポート、unauthenticated-UCI、いいえ、パケット充電あたり不干渉基礎、]

DEFENSE COMMUNICATIONS AGENCY (DCA)

ディフェンスコミュニケーション代理店(DCA)

   1.  DCA will not carry any transit traffic. It will only accept and
   send traffic to and from its mailbridge(s) and only from and to hosts
   on other F/Re nets. All packets are marked and charged for by the

1. DCAは少しのトランジットトラフィックも運ばないでしょう。 それは、他のF/reネットでホストと、そして、ホストとmailbridge(s)とホストだけにトラフィックを受け入れて、送るだけでしょう。 すべてのパケットが、マークされて、課金されます。

Estrin                                                         [Page 15]

RFC 1125                  Policy Requirements              November 1989

Estrin[15ページ]RFC1125方針要件1989年11月

   kilopacket.

kilopacket。

   [DCA1:(mailbridge,DCA,-)(*,{F/Re},{F/Re}){research,support}
   {unauthenticated UCI, all incoming packets marked, per-kilopacket
   charge}{}]

[DCA1: (mailbridge、DCA、-、)、研究、(*、F/re、F/re)サポート、unauthenticated UCI、入って来るパケットがマークした1kilopacketあたりのすべてが充電される、]

6.3.2 THE REGIONALS

6.3.2 地方版

   Interviews with regional network administrations are now underway. In
   general their policies are still in formation due to the relatively
   recent formation of these regional networks. However, for the sake of
   illustration we provide an example of a hypothetical regional's
   network policies.

地域ネットワーク運営があるインタビューは現在、進行中です。 一般に、それらの方針はこれらの地域ネットワークの比較的最近の構成によるまだ構成中です。 しかしながら、イラストのために、私たちは仮定している地方版のネットワーク方針に関する例を提供します。

REGIONAL A

地方のA

   1.  Regional A will carry traffic from/to any directly connected
   F/Re/U network to any F/Re/U network via NSF if it is for a research
   or support UCI. (NSF requires that all Regional networks only pass it
   traffic that complies with its, NSF's, policies!)

1. 地方のAはそれが研究かサポートUCIのためのものであるならNSFを通して/から直接接続されたどんなF/re/UネットワークまでもどんなF/re/Uネットワークまでもトラフィックを運ぶでしょう。 (NSFが、すべてのRegionalネットワークがそれが従うトラフィックをそれに通過するだけであるのを必要とする、それ、NSF、方針!)

   [Regional A:(*,{F/Re/U},{F/Re/U})(*,{F/Re/U},NSF){research,support}
   {unauthenticated UCI, no-per-packet charge}{}]

[地方、A: 研究、(*、F/re/U、F/re/U)(*、F/re/U、NSF)サポート、unauthenticated UCI、いいえ、1パケットあたり充電、]

REGIONAL B

地方のB

   1.  Regional B will carry traffic from/to any directly connected
   F/Re/U network to any F/Re/U network via a commercial carrier
   regardless of its UCI. In this case the packets are charged for since
   the commercial carrier charges per kilopacket.

1. 地方のBはUCIにかかわらず商業運送業者を通して/から直接接続されたどんなF/re/UネットワークまでもどんなF/re/Uネットワークまでもトラフィックを運ぶでしょう。 商業運送業者がkilopacket単位で充電するので、この場合、パケットは課金されます。

   [Regional B:(*,{F/Re/U},{F/Re/U})(*,{F/Re/U},Cc){}
   {unauthenticated UCI, per-kilopacket charge}{}]

[地方のB: (*、F/re/U、F/re/U)(*、F/re/U、Cc)、unauthenticated UCI、kilopacket充電、]

6.3.3 CAMPUS AND PRIVATE NETWORKS

6.3.3 キャンパスのANDの私設のネットワーク

   Similar interviews should be conducted with administrators of campus
   and private networks. However, many aspects of their policies are
   contingent on the still unresolved policies of the regionals and
   federal agencies.  In any event, transit policies will be critical
   for campus and private networks to flexibly control access to lateral
   links and private wide area networks, respectively. For example, a
   small set of university and private laboratories may provide access
   to special gigabit links for particular classes of researchers.  On
   the other hand, source/destination policies should not be used in
   place of network level access controls for these end ADs.

同様のインタビューがキャンパスと私設のネットワークの管理者と共に行われるべきです。 しかしながら、それらの方針の多くの局面が地方版と連邦機関のまだ未定の方針次第です。 とにかく、キャンパスと私設のネットワークが柔軟にそれぞれ側部のリンクと個人的な広域ネットワークへのアクセスを制御するように、運送保険証券は重要になるでしょう。 例えば、小さいセットの大学と私設の実験室は特別なギガビットリンクへのアクセスを特定のクラスの研究者に提供するかもしれません。 他方では、平らなアクセスがこれらの終わりのADsのために制御するネットワークに代わってソース/目的地方針を使用するべきではありません。

Estrin                                                         [Page 16]

RFC 1125                  Policy Requirements              November 1989

Estrin[16ページ]RFC1125方針要件1989年11月

6.3.4  COMMERCIAL SERVICES

6.3.4 商業サービス

   Currently commercial communication services play a low level role in
   most parts of today's Research Internet; they provide the
   transmission media, i.e.,leased lines. In the future we expect
   commercial carriers to provide increasingly higher level and enhanced
   services such as high speed packet switched backbone services.
   Because such services are not yet part of the Research Internet
   infrastructure there exist no policy statements.

   Charging and accounting are certain to be an important policy type in
   this context.  Moreover, we anticipate the long haul services market
   to be highly competitive. This implies that competing service
   providers will engage in significant gaming in terms of packaging and
   pricing of services. Consequently, the ability to express varied and
   dynamic charging policies will be critical for these ADs.

7  PROBLEMATIC REQUIREMENTS

   Most of this paper has lobbied for articulation of relatively
   detailed policy statements in order to help define the technical
   mechanisms needed for enforcement.  We promoted a top down design
   process beginning with articulation of desired policies.  Now we feel
   compelled to mention requirements that are clearly problematic from
   the bottom up perspective of technical feasibility.

   *  Non-interference policies are of the form "I will provide
      access for principals x to resources y so long as it does not
      interfere with my internal usage." The problem with such policies
      is that access to an AD at any point in time is contingent upon a
      local, highly dynamic, parameter that is not globally available.
      Therefore such a policy term could well result in looping,
      oscillations, and excessive route (re)computation overhead,
      both unacceptable. Consequently, this is one type of policy that
      routing experts suggest would be difficult to support in a very
      large decentralized internetwork.

   *  Granularity can also be problematic, but not as devistating as
      highly dynamic PR contingencies. Here the caution is less specific.
      Very fine grain policies, which restrict access to particular
      hosts, or are contingent upon very fine grain user class
      identification, may be achieved more efficiently with network
      level access control [11] or end system controls instead of
      burdening the inter-AD routing mechanism.

   *  Security  is expensive, as always. Routing protocols are subject
      to fraud through impersonation, data substitution, and denial of
      service. Some of the proposed mechanisms provide some means for

Estrin                                                         [Page 17]

RFC 1125                  Policy Requirements              November 1989

      detection and non-repudiation. However, to achieve a priori
      prevention of resource misuse is expensive in terms of per
      connection or per packet cryptographic overhead. For some
      environments we firmly believe that this will be necessary and
      we would prefer an architecture that would accommodate such
      variability [12].

   In general, it is difficult to predict the impact of any particular
   policy term. Tools will be needed to assist people in writing and
   validating policy terms.

8  PROPOSED MECHANISMS

   Previous routing protocols have addressed a narrower definition of
   PR, as appropriate for the internets of their day. In particular, EGP
   [3], DGP[13], and BGP[6] incorporate a notion of policy restrictions
   as to where routing database information travels. None are intended
   to support policy based routing of packets as described here.  More
   recent routing proposals such as Landmark [14] and Cartesian [15]
   could be used to restrict packet forwarding but are not suited to
   source/destination, and some of the condition-oriented, policies. We
   feel these policy types are critical to support. We note that for
   environments (e.g., within an AD substructure) in which the simple-
   AD-topology conjecture holds true, these alternatives may be
   suitable.

   RFC 1104 [5] provides a good description of shorter term policy
   routing requirements. Braun classifies three types of mechanisms,
   policy based distribution of route information, policy based packet
   forwarding, and policy based dynamic allocation of network resources.
   The second class is characterized by Dave Clark's PR architecture,
   RFC 1102 [4]. With respect to the longer term requirements laid out
   in this document, only this second class is expressive and flexible
   enough to support the multiplicity of stub and transit policies. In
   other words, the power of the PR approach (e.g., RFC1102) is not just
   in the added granularity of control pointed out by Braun, i.e., the
   ability to specify particular hosts and user classes. Its power is in
   the ability to express and enforce many types of stub and transit
   policies and apply them on a discriminatory basis to different ADs.
   In addition, this approach provides explicit support for stub ADs to
   control routes via the use of source routing.  (FOOTNOTE 12:
   Moreover, the source routing approach loosens the requirements for
   every AD to share a complete view of the entire internet by allowing
   the source to detect routing loops.)  (FOOTNOTE 13:  The match
   between RFC1102 and the requirements specified in this document is
   hardly a coincidence since Clark's paper and discussions with him
   contributed to the requirements formulation presented here. His work
   is currently being evaluated and refined by the ANRG and ORWG.)

Estrin                                                         [Page 18]

RFC 1125                  Policy Requirements              November 1989

9  SUMMARY

   Along with the emergence of very high speed applications and media,
   resource management has become a critical issue in the Research
   Internet and internets in general. A fundamental characteristic of
   the resource management problem is allowing administratively ADs to
   interconnect while retaining control over resource usage. However, we
   have lacked a careful articulation of the types of resource
   management policies that need to be supported.  This paper addresses
   policy requirements for the Research Internet.  After justifying our
   assumptions regarding AD topology we presented a taxonomy and
   examples of policies that must be supported by a PR protocol.

10  ACKNOWLEDGMENTS

   Members of the Autonomous Networks Research Group and Open Routing
   Working Group have contributed significantly to the ideas presented
   here, in particular, Guy Almes, Lee Breslau, Scott Brim, Dave Clark,
   Marianne Lepp, and Gene Tsudik. In addition, Lee Breslau and Gene
   Tsudik provided detailed comments on a previous draft. David Cheriton
   inadvertently caused me to write this document.  Sharon Anderson's
   contributions deserve special recognition.  The author is supported
   by research grants from National Science Foundation, AT&T, and GTE.

11   REFERENCES

   [1] J. Postel, Internet Protocol,  Network Information Center, RFC
       791, September 1981.

   [2] G. Vaudreuil, The Federal Research Internet Coordinating
       Committee and National Research Network, ACM SIG Computer
       Communications Review,April 1988.

   [3] E. Rosen, Exterior Gateway Protocol (EGP), Network Information
       Center, RFC 827, October 1982.

   [4] D. Clark, Policy Routing in Internet Protocols, Network
       Information Center, RFC 1102, May 1989.

   [5] H.W.Braun, Models of Policy Based Routing, Network Information
       Center, RFC 1104, June 1989.

   [6] K. Lougheed, Y. Rekhter, A Border Gateway Protocol, Network
       Information Center, RFC 1105, June 1989.

   [7] J. Saltzer, M. Schroeder, The Protection of Information in
       Computer Systems, Proceedings of the IEEE, 63, 9 September 1975.

Estrin                                                         [Page 19]

RFC 1125                  Policy Requirements              November 1989

   [8] V. Jacobson, Congestion Avoidance and Control.  Proceedings of
       ACM Sigcomm, pp. 106-114, August 1988, Palo Alto, CA.

   [9] David Clark, Design Philosophy of the DARPA Internet Protocols,
       Proceedings of ACM Sigcomm, pp. 106-114, August 1988, Palo Alto,
       CA.

  [10] Gigabit Networking Group, B. Leiner, Editor. Critical Issues in
       High Bandwidth Networking, Network Information Center, RFC 1077,
       November 1988.

  [11] D. Estrin, J. Mogul and G. Tsudik, Visa Protocols for Controlling
       Inter-Organizational Datagram Flow, To appear in IEEE Journal on
       Selected Areas in Communications, Spring 1989.

  [12] D. Estrin and G. Tsudik, Security Issues in Policy Routing, IEEE
       Symposium on Research in Security and Privacy, Oakland, CA.  May
       1-3 1989.

  [13]  M. Little, The Dissimilar Gateway Protocol,  Technical report

  [14] P. Tsuchiya, The Landmark Hierarchy: A new hierarchy for routing
       in very large networks, IEEE SIGCOMM 88, Palo Alto, CA. September
       1988.

  [15] G. Finn, Reducing the Vulnerability of Dynamic Computer Networks
       USC/Information Sciences Institute, Technical Report, ISI/RR-88-
       201 July 1988.

  [16] A. Nakassis Routing Algorithm for Open Routing, Unpublished
       paper, Available from the author at the National Institute of
       Standards and Technology (formerly NBS), Washington D.C.

11  SECURITY CONSIDERATIONS

       This memo does not address the security aspects of the issues
       discussed.

AUTHOR'S ADDRESS:

       Deborah Estrin
       University of Southern California
       Computer Science Department
       Los Angeles, CA 90089-0782

       Phone: (213) 743-7842

       EMail: Estrin@OBERON.USC.EDU

Estrin                                                         [Page 20]

RFC 1125                  Policy Requirements              November 1989

Estrin                                                         [Page 21]