RFC1102 日本語訳
1102 Policy routing in Internet protocols. D.D. Clark. May 1989. (Format: TXT=59664 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group D. Clark
Request for Comments: 1102 M.I.T. Laboratory for Computer Science
May 1989
コメントを求めるワーキンググループD.クラークの要求をネットワークでつないでください: 1102 マサチューセッツ工科大学コンピュータ科学研究所1989年5月
Policy Routing in Internet Protocols
インターネットプロトコルにおける方針ルート設定
1. Status of this Memo
1. このMemoの状態
The purpose of this RFC 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. Distribution of this memo is unlimited.
このRFCの目的はインターネットの特定の問題と解決策の可能な方法に議論の焦点を合わせることです。 提案された解決策は全くインターネットの規格として本書では意図しません。 このメモの分配は無制限です。
2. Introduction
2. 序論
An integral component of the Internet protocols is the routing function, which determines the series of networks and gateways a packet will traverse in passing from the source to the destination. Although there have been a number of routing protocols used in the Internet, they share the idea that one route should be selected out of all available routes based on minimizing some measure of the route, such as delay. Recently, it has become important to select routes in order to restrict the use of network resources to certain classes of customers. These considerations, which are usually described as resource policies, are poorly enforced by the existing technology in the Internet. This document proposes an approach to integrating policy controls into the Internet.
インターネットプロトコルの不可欠の成分は経路選択機能です。(その経路選択機能はパケットがソースから目的地まで通る際に横断するネットワークとゲートウェイのシリーズを決定します)。 インターネットで使用される多くのルーティング・プロトコルがありましたが、ルートをある程度の最小にすることに基づいて1つのルートがすべての利用可能なルートから選択されるべきであるという考えを共有します、遅れなどのように。 最近、ルートを選択するのは、ネットワーク資源の使用をあるクラスの顧客に制限するために重要になりました。 これらの問題(通常、リソース方針として記述されている)はインターネットの既存の技術によって不十分に励行されます。 このドキュメントは方針コントロールをインターネットと統合することへのアプローチを提案します。
I assume that the resources of the Internet: networks, links, and gateways, are partitioned into Administrative Regions or ARs. Each AR is governed by a somewhat autonomous administration, with distinct goals as to the class of customers it intends to serve, the qualities of service it intends to deliver, and the means for recovering its cost. To construct a route across the Internet, a sequence of ARs must be selected that collectively supply a path from the source to the destination. This sequence of ARs will be called a Policy Route, or PR. Each AR through which a Policy Route passes will be concerned that the PR has been properly constructed. To this end, each AR may wish to insure that the user of the PR is authorized, the requested quality of service is supported, and that the cost of the service can be recovered.
私は、それがインターネットに関するリソースであると思います: ネットワーク(リンク、およびゲートウェイ)は、Administrative地方かARsに仕切られます。 各ARはいくらか自治の管理によって治められます、それが役立つつもりである顧客のクラスに関する異なった目標、それが提供するつもりであるサービスの品質、および費用を取り戻すための手段で。 インターネットの向こう側にルートを構成するために、ソースからの経路を目的地にまとめて供給するARsの系列を選択しなければなりません。 ARsのこの系列はPolicy Route、またはPRと呼ばれるでしょう。 Policy Routeが通る各ARはPRが適切に構成されたことを心配するでしょう。 このために、各ARはPRのユーザが認可されていて、要求されたサービスの質を支持して、サービスの費用は取り戻すことができるのを保障したがっているかもしれません。
In the abstract, a Policy Route is a series of ARs, which are assumed to be named with globally distinct identifiers. (The requirement for global names for ARs suggests that the name space of ARs is flat. That simplifying assumption is made in this RFC, but it should be possible to extend the scheme described here to permit nesting of ARs
要約では、Policy Routeは一連のARsです。(そのARsはグローバルに異なった識別子で命名されると思われます)。 ARsのためのグローバル名のための要件は、ARsの名前スペースが平坦であると示唆します。(その簡素化仮定はこのRFCでされますが、ここでARsの許可証巣篭もりに説明された計画を広げるのは可能であるべきです。
Clark [Page 1] RFC 1102 Policy Routing in Internet Protocols May 1989
1989年5月にインターネットプロトコルで掘られるクラーク[1ページ]RFC1102方針
to reduce the amount of global information. The problem of adding structure to the space of ARs is an exercise for later study.) Before a PR can be used, however, it must be reduced to more concrete terms; a series of gateways which connect the sequence of ARs. These gateways will be called Policy Gateways.
グローバルな情報の量を減少させるために。 ARsのスペースに構造を加えるという問題は後の研究のための運動です。) しかしながら、PRを使用できる前に、より多くの具体名辞に減少しなければなりません。 ARsの系列を接続する一連のゲートウェイ。 これらのゲートウェイはPolicy Gatewaysと呼ばれるでしょう。
Presently, the closest mechanism to policy routing in the Internet is EGP, the Exterior Gateway Protocol. EGP was constructed to permit regions of the Internet to communicate reachability information, even though they did not totally share trust. In this respect, the regions hooked together by EGP could each be viewed as Administrative Regions. However, the mechanisms of EGP imposed a topological restriction on the interconnection of the Administration Regions. In practice, this has proved unsatisfactory. Policy matters are driven by human concerns, and these have not turned out to be amenable to topological constraints, or indeed to constraints of almost any sort.
現在、インターネットでの方針ルーティングへの最も近いメカニズムはEGP、Exteriorゲートウェイプロトコルです。 EGPはインターネットの領域が可到達性情報を伝えることを許可するために組み立てられました、完全に信用を共有したというわけではありませんが。 この点で、Administrative地方としてそれぞれEGPによって一緒に掛けられた領域は見なすことができました。 しかしながら、EGPのメカニズムは政権地方のインタコネクトに位相的な制限を課しました。 実際には、これは不十分であると判明しました。 方針物質は人間の関心によって動かされます、そして、これらは位相的な規制、または、本当に、ほとんどどんな種類の規制にも従順であると判明しませんでした。
The proposals in this memo are designed to permit as wide a latitude as possible in the construction and enforcement of policies. In particular, no topological restrictions are assumed. In general, the approach taken in this memo is driven by the belief that since policies reflect human concerns, the system should primarily be concerned with enforcement of policy, rather than synthesis of policy. The proposal permits both end points and transit services to express and enforce local policy concerns.
このメモにおける提案は、できるだけ広い緯度に方針の工事と実施の入るのを許すように設計されています。 特に、どんな位相的な制限も想定されません。 一般に、方針が人間の関心を反映するのでシステムは主として方針の統合よりむしろ方針の実施に関係があるべきであるという信念によってこのメモで取られたアプローチが動かされます。 提案は、両端点とトランジットサービスが地方の方針関心を述べて、実施することを許可します。
3. Policy Routes
3. 方針ルート
Almost all approaches to policy control share, to some degree, the idea of a Policy Route. The distinguishing component of a policy approach is the procedure by which the Policy Route is synthesized. One approach to synthesizing routes is to associate with each distinct policy a subset of all the gateways in the system, and then run a routing algorithm across the subset of the gateways. This approach has several drawbacks. It requires a distinct routing computation for every policy, which may be prohibitively expensive. It requires the global agreement on the nature and scope of each policy, which is at odds with the desire of Administrative Regions to establish their own independent policy assertions. Finally, it almost inevitably implies a topological restriction on the interconnection of regions.
方針コントロールへのほとんどすべてのアプローチがPolicy Routeの考えをある程度共有します。 方針アプローチの区別コンポーネントはPolicy Routeが統合される手順です。 ルートを統合することへの1つのアプローチは、システムのすべてのゲートウェイの部分集合をそれぞれの異なった方針に関連づけて、次に、ゲートウェイの部分集合の向こう側にルーティング・アルゴリズムを走らせることです。 このアプローチには、いくつかの欠点があります。 それはあらゆる方針のための異なったルーティング計算を必要とします。(方針は法外に高価であるかもしれません)。 それら自身の独立している方針主張を確立するのが自然のグローバルな協定とそれぞれの方針の範囲を必要とします。(方針がAdministrative地方の願望と仲たがいしてあります)。 最終的に、それは領域のインタコネクトでほぼ必然的に位相的な制限を含意します。
Another synthesis approach is to have each Policy Gateway examine incoming packets and determine, based on local policy constraints, the most appropriate next AR. This approach might possibly work, but again has several drawbacks. First, it implies a substantial amount of computation at each Policy Gateway. More importantly, it removes the route selection from the location where it would most naturally
別の統合アプローチは、それぞれのPolicyゲートウェイに入って来るパケットを調べさせて、地方の方針規制に基づいて次の最も適切なARを決定することです。 このアプローチには、ことによると働くかもしれませんが、いくつかの欠点が再びあります。 まず最初に、それはそれぞれのPolicyゲートウェイでかなりの量の計算を含意します。 より重要に、それは最も自然にそうする位置からルート選択を取り除きます。
Clark [Page 2] RFC 1102 Policy Routing in Internet Protocols May 1989
1989年5月にインターネットプロトコルで掘られるクラーク[2ページ]RFC1102方針
be executed, the end-points of the connection.
実行されてください、接続のエンドポイント。
It is useful to think of the interconnected ARs as a marketplace, in which various services are offered and users select among these services to obtain packet transport. By this analogy, it seems appropriate that the actual selection of the Policy Route should be made by the end ARs desiring to send the packets, rather than by the Policy Gateways. Looking to the phone system for comparison, it is the customer of the phone system who selects which of the long distance carriers to use, whether to purchase a fixed price service or pay incrementally for usage, and so on. In this proposal, therefore, Policy Routes are synthesized at the end point, where the packet originates, and are attached to packets in order to direct them through the appropriate series of ARs. In other words, Policy Routes are a form of source routing. The role of synthesizing a Policy Route is shared between the source AR and the particular source host.
市場としてインタコネクトされたARsを考えるのは役に立ちます、様々なサービスを提供して、ユーザがこれらのサービスの中でパケット輸送を得るのを選択するもので。 この類推で、Policy Gatewaysでというよりむしろパケットを送ることを望んでいる終わりのARsまでにPolicy Routeの実際の選択をするべきであるのは適切に見えます。 比較の電話システムを当てにして、それは、長距離のキャリヤーのどれを使用したらよいかを選択する電話システムの顧客、定価サービスを購入するか、または増加して用法の代価を払うか、そして、などです。 この提案では、したがって、Policy Routesは、パケットが由来するところでエンドポイントで統合されて、ARsの適切なシリーズを通してそれらを指示するためにパケットに取り付けられます。 言い換えれば、Policy Routesはソースルーティングのフォームです。 Policy Routeを統合する役割はソースARと特定の送信元ホストの間で共有されます。
In this architecture, therefore, the function of the Policy Gateway is not to synthesize the Policy Route, but to verify it. In the following sections, we will address the two questions of how a Policy Route is verified, and how a Policy Route is synthesized.
したがって、この構造で、Policyゲートウェイの機能はPolicy Routeを統合するのではなく、それについて確かめることです。 以下のセクションで、私たちはPolicy Routeがどのように確かめられるか、そして、Policy Routeがどのように統合されるかに関する2つの質問を記述するつもりです。
In determining that Policy Routes should be synthesized at the end point, it is important to distinguish between those aspects of routing that reflect legitimate policy concerns, and those aspects of routing which, in reality, relate to the detailed operation of the ARs. For example, if one were to represent Policy Routes using the existing Internet source route mechanism, which allows the end point to specify a series of gateways through which the packet should pass, the result would be that too much function has been transferred from the internals of the Internet to the end points. The end point would have to have knowledge of exactly which gateways are up and operational at a particular moment, and this degree of knowledge cannot be justified by policy concerns. Further, it would be necessary to run a systemwide gateway reachability protocol.
Policy Routesがエンドポイントで統合されるべきであることを決定するのにおいて、正統の方針関心を反映するルーティングのそれらの局面、およびARsの詳細な操作にほんとうは関連するルーティングのそれらの局面を見分けるのは重要です。 例えば、あるものがエンドポイントがパケットが通るはずである一連のゲートウェイを指定できる既存のインターネット送信元経路メカニズムを使用することでPolicy Routesを表すなら、結果はインターネットのインターナルからエンドポイントまであまりに多くの機能を移したということでしょうに。 エンドポイントには、ちょうどどのゲートウェイが特定の瞬間に上がって操作上であるかに関する知識がなければならないでしょう、そして、方針関心はこの度の知識を正当化できません。 さらに、systemwideゲートウェイ可到達性プロトコルを走らせるのが必要でしょう。
This proposal attempts to strike a balance between end point specification of those concerns legitimately related to policy, and local determination in the Policy Gateways of the more specific details necessary for reliable operation. This leads to a two-level routing model, in which the abstract Policy Route, a series of administrative regions, is specified by the end point as a form of source route, and each Policy Gateway selects the next actual Policy Gateway that is to be used to forward this packet. In other words, the abstract Policy Route is made concrete incrementally. This division of function does require that the source AR know if there are faults that have partitioned pairs of ARs that are normally
この提案は、合法的に方針に関連するそれらの関心のエンドポイント仕様と、信頼できる操作に必要なより特定の詳細のPolicy Gatewaysの地方の決断の間のバランスをとるのを試みます。 これは2レベルのルーティングモデルに通じます、そして、それぞれのPolicyゲートウェイはこのパケットを進めるのに使用されることになっている次の実際のPolicyゲートウェイを選択します。(そこでは、抽象的なPolicy Route(一連の管理領域)は送信元経路のフォームとしてエンドポイントによって指定されます)。 言い換えれば、抽象的なPolicy Routeは増加して人工のコンクリートです。 機能のこの分割は、ソースARが、通常、組のARsを仕切った欠点があるかどうかを知っているのを必要とします。
Clark [Page 3] RFC 1102 Policy Routing in Internet Protocols May 1989
1989年5月にインターネットプロトコルで掘られるクラーク[3ページ]RFC1102方針
connected together. This implies a global reachability protocol to be run for the purpose of providing information to the source AR, but it need only concern itself at the level of ARs, not at the level of gateways. In a later section on cost-recovery, the topic of gateway selection will be discussed in more detail.
一緒に接続されています。 これはソースARに情報を供給する目的のために走るためにグローバルな可到達性プロトコルを含意しますが、それはゲートウェイのレベルにおいて関係があるのではなく、ARsのレベルにおいてそれ自体に関係があるだけでよいです。 原価回収の後のセクションで、さらに詳細にゲートウェイ選択の話題について議論するでしょう。
An objection to a scheme such as source routing is that the potentially bulky source route must be in every packet, and must be evaluated for each packet. One solution to this performance problem is to employ a limited form of route setup, in which the actual Policy Route is carried only in the first packet of a sequence, and a short identifier or "handle" is included in subsequent packets of the sequence. Each Policy Gateway evaluates the PR on first encounter, and caches the result, which is then retrieved for later packets using the handle in the packet. The idea of a handle and caching, and the need for a form of route setup, is discussed later.
ソースルーティングなどの計画への異論は潜在的に厖大な送信元経路はあらゆるパケットにあるに違いなくて、各パケットのために評価しなければならないということです。 この性能問題の1つの解決は限局型のルートセットアップを使うことです、そして、短い識別子か「ハンドル」が系列のその後のパケットに含まれています。(実際のPolicy Routeは系列の最初のパケットだけでセットアップで運ばれます)。 それぞれのPolicyゲートウェイは、最初の遭遇のときにPRを評価して、結果をキャッシュします。(次に、それは、後のパケットのためにパケットでハンドルを使用することで検索されます)。 後でハンドルの考え、キャッシュ、およびルートセットアップのフォームの必要性について議論します。
4. Verification of Policy Routes
4. 方針ルートの検証
As a packet arrives at a Policy Gateway, attempting to enter an AR, the Policy Gateway must decide whether it is legitimate to forward this packet, and if so, at what next Policy Gateway the packet should exit the AR (assuming that the final destination is not within the AR). The information available to the Policy Gateway to support its decision determines the range of policies that can be enforced. Determining what information is to be available is therefore a central feature of our proposal.
パケットがARに入るのを試みるPolicyゲートウェイに到着するとき、Policyゲートウェイは、このパケットを進めるのが正統であるかどうか決めなければなりません、そして、そうだとすれば、次は何、Policyゲートウェイでは、パケットはARを出るはずです(ARの中に最終的な目的地がないと仮定して)。 決定を支持するPolicyゲートウェイに利用可能な情報は励行されることができる方針の範囲を決定します。 したがって、どんな情報が利用可能であるかことであるかを決定するのは、私たちの提案の主要点です。
4.1. Identifying the User
4.1. ユーザを特定します。
Classic routing decisions, those minimizing some cost, are typically driven only by the destination of the packet. At a minimum, policy decisions must be based both on the source and the destination of the packet. In fact, source and destination addresses may not be sufficient to determine policy, for an AR may support different users with different rights, moreover a single user may wish to exercise different rights at different times. I suggest that to identify the user who is proposing to use this particular Policy Route, it is sufficient that the packets contain the source host and AR, the destination host and AR, and, optionally, a User Class Identifier, or UCI. In a later section, I discuss how to prevent misuse of the user class identifier.
古典的なルーティング決定(何らかの費用を最小にするもの)はパケットの目的地だけによって通常追い立てられます。 最小限では、政策決定をパケットのソースと目的地に基礎づけなければなりません。 事実上、ARが異なった権利で異なったユーザを支持するかもしれないのでソースと送付先アドレスが方針を決定するために十分でないかもしれない、そのうえ、シングルユーザーはいろいろな時間に異なった権利を行使したがっているかもしれません。 私は、この特定のPolicy Routeを使用するよう提案しているユーザを特定するために、パケットが任意に送信元ホストとARかあて先ホストとARと、User Class Identifierか、UCIを含むのが、十分であると示唆します。 後のセクションで、私はユーザ・クラス識別子の誤用を防ぐ方法について議論します。
In fact, the source and destination host address may not be needed to support the practical range of policy decisions required at intermediate ARs. Only the source and destination AR information may be necessary. If individual host addresses are to be used, that implies that intermediate ARs will want to keep track of the rights
事実上、ソースと目的地ホスト・アドレスは、中間的ARsで必要である実用的な範囲の政策決定を支持するのに必要でないかもしれません。 ソースと目的地AR情報だけが必要であるかもしれません。 中間的ARsはそれが個々のホスト・アドレスが使用されていることであるなら、権利の動向をおさえたくなるつもりでしょう。
Clark [Page 4] RFC 1102 Policy Routing in Internet Protocols May 1989
1989年5月にインターネットプロトコルで掘られるクラーク[4ページ]RFC1102方針
of individual hosts. It would be much simpler if the source AR could be trusted to permit only the proper hosts to use certain PRs. I will consider this further in a later section when I discuss the role of the Policy Controller.
個々のホストについて。 ソースARが、適切なホストだけが、あるPRを使用することを許可すると信じることができるなら、はるかに簡単でしょうに。 Policy Controllerの役割について議論するとき、私は後のセクションで、より遠くにこれを考えるつもりです。
4.2. Verifying the Route
4.2. ルートを確かめます。
The packet contains an abstract Policy Route: a series of AR identifiers. To validate this route, each Policy Gateway could store the complete selection of acceptable policy routes, and require that an incoming packet have a Policy Route that exactly matched one of the stored entries. This degree of constraint probably overspecifies the situation, and causes an information explosion. At the other end of the scale, Policy Gateways could simply be sensitive to the source AR and the destination AR. In some cases, particularly as regards to billing, this does not provide sufficient constraints. This proposal suggests that in deciding whether a given Policy Route is valid, a Policy Gateway should look at the source and destination ARs, and also the ARs immediately abutting the AR in question, called the entry and exit ARs.
パケットは抽象的なPolicy Routeを含んでいます: 一連のAR識別子。 それぞれのPolicyゲートウェイは、このルートを有効にするために、許容できる方針ルートの完全なセレクションを格納して、入って来るパケットにはまさに格納されたエントリーの1つに合っていたPolicy Routeがあるのを必要とすることができました。 この度の規制は、たぶん状況を過剰指定して、情力化を引き起こします。 スケールのもう一方の端では、Policy Gatewaysは単にソースARと目的地ARに敏感であるかもしれません。 いくつかの場合、特に支払いへの尊敬として、これは十分な規制を提供しません。 この提案は、与えられたPolicy Routeが有効であるかどうか決める際に、Policyゲートウェイがソースを見るべきであると示唆します、そして、目的地ARs、およびすぐに問題のARを隣接させるARsもエントリーと出口をARsと呼びました。
One can think of the verification information in the Policy Gateway as a number of templates. Each template is associated with a valid set of users, as described by the source and destination host address and the optional User Class, and contains the four ARs described above, Source, Destination, Exit, and Entry. An incoming packet should be forwarded if, and only if, there is a template matching the information in the packet. These templates will be called Policy Terms.
人は多くのテンプレートとしてPolicyゲートウェイの検証情報を考えることができます。 各テンプレートは、ソース、目的地ホスト・アドレス、および任意のUser Classによって説明されるように有効なセットのユーザに関連していて、上で説明された、4ARs、Source、Destination、Exit、およびEntryを含んでいます。 入って来るパケットを進めるべきである、唯一、パケットで情報に合っているテンプレートがあります。 これらのテンプレートはPolicy Termsと呼ばれるでしょう。
4.3. Conditions
4.3. 状態
The Policy Terms, as described so far, do not permit the expression of a realistic range of policies. What is needed is the ability to attach to a Policy Term a number of conditions, which describe circumstances under which the term is valid. These might include what type of service (TOS) is available, what times of day the term is valid, what accounting options are valid, and so on. A time-of- day condition, for example, would permit networks, like time-sharing systems, to offer their off-peak capacity to a wider community.
今までのところ説明されるPolicy Termsは現実的な範囲の方針の表現を可能にしません。 必要であるものは多くの状態をPolicy Termに添付する能力です。(状態は用語が有効である事情について説明します)。 これらの力は、どんなタイプのサービス(TOS)が利用可能です、用語が有効である日のどんな回、会計がゆだねるものが有効であって、とてもオンであるかということであるかを含んでいます。 -日では、例えば状態が可能にする時は申し出へのシステムを時分割するようにそれらのオフピークの容量をより広い共同体にネットワークでつなぎます。
In general, these conditions could be quite arbitrary. The important constraint on these conditions is that any condition imposed by the Policy Gateway must be understood by the end point, so that it can generate Policy Routes which will conform to the condition. If this is not so, and the Policy Gateway attaches capricious conditions to its policy terms, then the end points will construct Policy Routes in good faith which are rejected, leading to a failure to obtain service
一般に、これらの状態はかなり任意であるかもしれません。 これらの条件における重要な規制はPolicyゲートウェイによって課されたどんな状態もエンドポイントに解釈しなければならないということです、状態に従うPolicy Routesを発生させることができるように。 これがそうでなく、Policyゲートウェイが気紛れな状態を方針用語に添付すると、エンドポイントは誠実にPolicy Routesを組み立てるでしょう(拒絶されます)、サービスを得ないことに通じて
Clark [Page 5] RFC 1102 Policy Routing in Internet Protocols May 1989
1989年5月にインターネットプロトコルで掘られるクラーク[5ページ]RFC1102方針
and serious dissatisfaction among users. For this reason, it is necessary that the nature of policy conditions be negotiated in advance.
そして、ユーザの中の重大な不満。 この理由に、保険約款の本質があらかじめ交渉されるのが必要です。
The most interesting and difficult conditions are those that relate to the dynamic state of the network. An excellent example is a bilateral mutual aid agreement between two transit ARs in which each agrees to carry the load of the other if the other should go down. To capture this agreement, each might wish to put in Policy Terms with the condition that they are valid only if some other AR is non- functional. In the earlier discussion of Policy Route synthesis, it was necessary for the ARs to run a global up-down protocol to describe the connectivity of ARs. This protocol is sufficient to allow the Policy Gateway to know that some other AR is non- functional, but care is required in the dynamics of this system to ensure that the end point in the PR have a consistent view of the up-down status of the world. Otherwise, there would be transient service outages, which again would lead to user dissatisfaction.
最もおもしろくて難しい状態はネットワークの動態に関連するものです。 好例はそれぞれがもう片方であるならもう片方の積載物を運ぶのに同意する2トランジットARsの間の双方の相互援助協定が落ちるべきであるということです。 この協定を得るために、それぞれがある他のARが非機能的である場合にだけ彼らが有効であるという条件があるPolicy Termsを入れたがっているかもしれません。 Policy Route統合の以前の議論では、ARsがARsの接続性について説明するためにグローバルな上下プロトコルを走らせるのが必要でした。 このプロトコルは、Policyゲートウェイが、ある他のARが非機能的ですが、注意がPRにおけるエンドポイントには世界の上下状態の一貫した視点があるのを保証するのにこのシステムの力学で必要であることを知っているのを許容するために十分です。 さもなければ、一時的なサービス供給停止があるでしょう。(再び、供給停止はユーザ不満につながるでしょう)。
In general, this proposal asserts that policies should not be based on highly dynamic phenomenon. Administrative Regions should be thought of as stable entities which do not change state rapidly. Highly dynamic characteristics like queue length should be dealt with by proper engineering internal to the AR. Precisely because conditions must be propagated globally, attempting to base a condition on a highly dynamic parameter is liable to lead to system instability.
一般に、この提案は、方針が非常にダイナミックな現象に基づくべきでないと断言します。 管理地方は急速に状態を変えない安定した実体として考えられるべきです。 非常に、待ち行列の長さのような動特性はARへの内部の適切な工学によって対処されるべきです。 まさに状態をグローバルに伝播しなければならないので、状態を非常にダイナミックなパラメタに基礎づけるのを試みるのはシステムの不安定性に通じやすいです。
4.4. Ownership of Policy Gateways
4.4. 方針ゲートウェイの所有権
In Section 1, all the resources of the network were described as being partitioned among the ARs. This statement does not extend to the Policy Gateways, which sit on the boundary between ARs. Either the Policy Gateway must be composed of two physical halves, connected by a wire, or there must be a joint agreement for the ownership and operation of the gateway. This is a matter for further study.
セクション1では、ネットワークに関するすべてのリソースがARsの中で仕切られるとして記述されました。 この声明はPolicy Gatewaysに達しません。(Policy GatewaysはARsの間の境界に座ります)。 ワイヤによって接続された2つの物理的な半分でPolicyゲートウェイを構成しなければならない、さもなければ、ゲートウェイの所有権と操作のための共同協定があるに違いありません。 これはさらなる研究への問題です。
5. Examples of Policy Terms
5. 方針用語に関する例
This section presents examples of how policy terms would be used to express a range of practical policies. In order to give examples, it is necessary to define a notation for policy terms. The following is not necessarily the most compact form, but will be sufficient for some simple examples.
このセクションは方針用語がさまざまな実用的な方針を言い表すのにどう使用されるだろうかに関する例を提示します。 例を挙げるために、方針用語以下のために記法を定義するのが必ず最もコンパクトなフォームであるというわけではありませんが、いくつかの簡単な例に十分であることが必要です。
Clark [Page 6] RFC 1102 Policy Routing in Internet Protocols May 1989
1989年5月にインターネットプロトコルで掘られるクラーク[6ページ]RFC1102方針
A Policy Term will be expressed as follows:
Policy Termは以下の通り急送されるでしょう:
((Hs,ARs,ARent),(Hd,ARd,ARexit),UCI,Cg)
(Hs、ARs、ARent)、(Hd、急性呼吸器病、ARexit)、UCI、Cg)
where:
どこ:
Hs is the source host address,
ARs is the source AR,
ARent is the entry AR,
Hsがソースホスト・アドレスである、ARsがソースARである、ARentはエントリーARです。
and these three values comprise the first "element" of the term, describing the permitted access looking toward the source. Similarly, for the destination, there is an element describing the host address, the adjacent AR, and the ultimate AR.
そして、ソースに向かって見える受入れられたアクセスについて説明して、これらの3つの値が用語の最初の「要素」を包括します。 同様に、目的地にはホスト・アドレスについて説明する要素、隣接しているAR、および究極のARがあります。
In addition to the two directional elements of the term, there is global information:
用語の2つの方向の原理に加えて、グローバルな情報があります:
UCI is the User Class Id, and
Cg are any global conditions.
UCIはUser Class Idです、そして、Cgはあらゆるグローバルな状態です。
In many cases, an element will not want to constrain one of the values, and we will use the "*" symbol to indicate a "wild-card" match.
多くの場合、要素は値の1つを抑制したくならないでしょう、そして、私たちは「ワイルドカード」マッチを示すのに「*」シンボルを使用するつもりです。
To construct some simple examples, here is a topology, where H elements are hosts, G elements are Policy Gateways, and Numbered elements are ARs.
いくつかの簡単な例を構成するために、トポロジーはここにあります、そして、G要素はPolicy Gatewaysです、そして、Numbered要素はARsです。(そこでは、H要素がホストです)。
H1 --- 1 --- G1 ----- 2 ------ G2 ----- 3 ----- H2
| |
| |
| |
|---- G3 ----- 4 ------ G4 ------|------ G5 --- 5
| |
| |
| H4
H3
H1--- 1 --- G1----- 2 ------ G2----- 3 ----- H2| | | | | | |---- G3----- 4 ------ G4------|------ 5ヵ国蔵相会議--- 5 | | | | | H4 H3
In this picture, there are four hosts, five gateways, and five Administrative Regions.
この絵には、4人のホスト、5門、および5つのAdministrative地方があります。
First, consider AR two. It has no hosts attached, and models a transit service, such as the NSF network. It may have a very simple policy: it will carry any traffic between universities, without further constraint. If we let AR1 and AR3 be the regions of two
まず最初に、AR twoを考えてください。 それは、ホストを全く付けさせないで、NSFネットワークなどのトランジットサービスをモデル化します。 それには、非常に簡単な方針があるかもしれません: それはさらなる規制なしで大学の間のどんな交通も運ぶでしょう。 私たちが、AR1とAR3が2の領域であることをさせるなら
Clark [Page 7] RFC 1102 Policy Routing in Internet Protocols May 1989
1989年5月にインターネットプロトコルで掘られるクラーク[7ページ]RFC1102方針
particular universities, then its policy term could be written as:
そして、特定の大学であり以下として方針用語を書くことができました。
AR2: ((*,1,*),(*,3,*),*,*).
AR2: ((*,1,*),(*,3,*),*,*).
This says that AR 2 agrees to carry traffic from AR 1 to AR 3, without concern as to the entry and exit AR, and for any hosts in these ARs.
これは、AR2が、AR1からAR3までの交通を運ぶのに同意すると言います、エントリーと出口AR、およびこれらのARsのどんなホストに関する心配なしでも。
This notation works, but is very bulky, as a new term is required for every pair of universities. There are several ways to compact the notation. First, we can use the * and a new symbol, "-", to broaden the terms a bit. For example:
この記法は、働いていますが、新学期がすべての組の大学に必要であるように非常に厖大です。 記法を圧縮するいくつかの方法があります。 まず最初に、私たちは、用語を少し広くするのに*と新しいシンボル、「-」を使用できます。 例えば:
AR2: ((*,1,*),(*,*,-),*,*)
AR2: ((*,1,*),(*,*,-),*,*)
would assert that AR 1 can use AR 2 to talk to any directly attached AR, where we use the "-" to mean that the exit AR must be the destination AR. In other words, the destination AR must be directly attached to AR2. If AR 2 only attaches to universities, then this would provide the proper constraint.
AR1が私たちが出口アルゴンが目的地アルゴンであるに違いないことを意味するのに「-」を使用するどんな直接付属しているARとも話すのにAR2を使用できると断言するでしょう。 言い換えれば、直接目的地ARをAR2に取り付けなければなりません。 AR2が大学に付くだけであるなら、これは適切な規制を提供するでしょう。
Another approach is to use the User Class ID:
別のアプローチはUser Class IDを使用することです:
AR2:((*,*,*),(*,*,*),University,*)
AR2:(*、*、*)、(*、*、*)、大学、*)
says that any traffic of any sort that has the User Class of University is acceptable.
大学のUser Classを持っているどんな種類のどんな交通も許容できると言います。
Another, and perhaps most suitable notation, is to observe that the distinction between source and destination is actually artificial. While it helps in this memo to have names for the two ends, either end can be a source, depending on who sends the first packet. (A later section explores the bi-directional nature of PRs). A more general form of a PR is thus to permit any number of elements. That is, a Policy Term can have more than two elements, and the meaning of this is that a PR is valid if it uses any two of these.
別のもの、および恐らく最も適当な記法はソースと目的地での区別が実際に人工であることを観測することです。 2つの終わりの間、名前を持っているのがこのメモで助ける間、どちらかの終わりがソースであるかもしれません、だれが最初のパケットを送るかによって。 (後のセクションはPRの双方向の本質を探ります。) その結果、PRの、より一般的なフォームはそうです。いろいろな要素を可能にするために。 すなわち、Policy Termは2つ以上の要素を持つことができます、そして、この意味は何かこれらの2を使用するならPRが有効であるということです。
For example, if university 5 wanted to use the AR2 service, AR2 might write a Policy term as follows:
例えば、大学5がAR2サービスを利用したいなら、AR2は以下のPolicy用語を書くでしょうに:
AR2:((*,1,*),(*,3,*),(*,5,*),*,*)
AR2:((*,1,*),(*,3,*),(*,5,*),*,*)
which would permit a policy route between hosts in any two of the ARs 1, 3 and 5.
いずれの2ARs1、3、および5のホストの間の方針ルートを可能にします。
All the terms so far relate to the policies of AR2. If university 1 wanted to subscribe to this service, and use it to reach any other site, it would specify terms of its own. For example:
すべての用語が今までのところ、AR2の方針に関連します。 大学1がこのサービスに加入して、いかなる他のサイトにも達するのにそれを使用したいと思うなら、それはそれ自身の用語を指定するでしょうに。 例えば:
Clark [Page 8] RFC 1102 Policy Routing in Internet Protocols May 1989
1989年5月にインターネットプロトコルで掘られるクラーク[8ページ]RFC1102方針
AR1: ((*,1, -),(*,*,2),*,*).
AR1: ((*,1, -),(*,*,2),*,*).
This term says that any host in AR 1 can use AR 2 as a path to any host in any AR. Again we use the "-" notation to indicate that the entry AR is the same as the source AR, in this case the AR writing the term.
今期は、AR1のどんなホストも経路としてどんなARのどんなホストにもAR2を使用できると言います。 一方、私たちはエントリーアルゴンがソースアルゴンと同じであることを示すのに「-」記法を使用します、この場合アルゴンが用語を書いて。
The ARs numbered 3 and 5 are more interesting. While 3 is directly attached to 2, 5 is not. Instead, 5 has attached to 3. If 3 wants to use 2 for general transit service, it must provide a term similar to the one provided by 1:
ARsは3に達しました、そして、5は、よりおもしろいです。 3は直接そうですが、付いて、2、5はそうではありません。 代わりに、5は3まで差し押さえを食います。 一般的なトランジットサービスに2を使用する3個の必需品であるなら、1時までに提供されたものと同様の用語を提供しなければなりません:
AR3: ((*,3,-),(*,*,2),*,*).
AR3: ((*,3,-),(*,*,2),*,*).
If 5 wants to use 2, more terms are required. Since 2 is not directly attached, it cannot be named as the exit AR in a term written by 5. The directly attached AR, 3, is all that can be named:
2を使用する5個の必需品であるなら、より多くの用語が必要です。 2が直接付属していないので、出口ARとして5時までに書かれた用語でそれを命名できません。 直接付属しているAR(3)は命名できるすべてです:
AR5: ((*,5,-),(*,*,3),*,*).
AR5: ((*,5,-),(*,*,3),*,*).
Then AR3 must agree to carry the transit traffic for 5.
そして、AR3は、5のためのトランジット交通を運ぶのに同意しなければなりません。
AR3: ((*,5,-),(*,*,2),*,*)
AR3: ((*,5,-),(*,*,2),*,*)
AR3 might not want to carry all forms of transit traffic for 5, but only of certain sorts or to certain locations. This could be expressed by restricting the previous term. For example,
5のためにすべての形式のトランジット交通を運びたいのではなく、ある種類だけについて運びたいか、またはAR3はある位置にそうするかもしれません。 前の用語を制限することによって、これを言い表すことができるでしょう。 例えば
AR3: ((*,5,-),(*,2,-),*,*)
AR3: ((*,5,-),(*,2,-),*,*)
would permit traffic from 5 to cross 3 to reach 2, but only to hosts directly in those ARs.
5からの交通が範囲2に3を渡りますが、直接それらのARsのホストだけに渡ることを許可するでしょう。
For some further examples, consider AR 4, which might represent the AR of a commercial user. It connects together the hosts of that user, for example, H3, and is connected to the other environment to permit cross-communication. Given the terms so far, no traffic will flow into this AR.
AR4は、どれがさらなるいくつかの例のために営利的ユーザのARを表すかもしれないかと考えます。 それは、そのユーザ、例えば、H3のホストを一緒に接続して、交差しているコミュニケーションを可能にするためにもう片方の環境に関連づけられます。 今までのところの用語を考えて、交通は全くこのARに流れないでしょう。
If AR 1 wants to permit communication with AR 4, it could add:
AR1がAR4とのコミュニケーションを可能にしたいなら、加えるかもしれません:
AR1: ((*,1,-),(*,4,-),*,*)
AR1: ((*,1,-),(*,4,-),*,*)
This would permit communication between hosts directly in each AR, but no transit traffic. In particular, H3 and H2 cannot talk. There are several different terms that would permit them to talk.
これは各ARにもかかわらず、直接トランジット交通がないのにおけるホストのコミュニケーションを可能にするでしょう。 特に、H3とH2は話すことができません。 彼らが話すことを許可するいくつかの異なった用語があります。
Clark [Page 9] RFC 1102 Policy Routing in Internet Protocols May 1989
1989年5月にインターネットプロトコルで掘られるクラーク[9ページ]RFC1102方針
The direct path would be the following:
直接路は以下でしょう:
AR4: ((*,4,-),(H2,3,-),*,*)
AR3: ((*,3,-),(H3,4,-),*,*).
AR4: (*、4、-、)、(H2、3、-、)、*、*) AR3: (*、3、-、)、(H3、4、-、)、*、*)
This would permit direct connection through G4. Note, for variety, that each term has been set up so that any host in the local AR can match, but only one host in the other AR. The combination happens to permit only H3 and H2 to communicate.
これはG4を通したダイレクト接続を可能にするでしょう。 バラエティーのために、地方のARのどんなホストも合うことができるように各用語がセットアップされて、もう片方における1人のホストだけがARであることに注意してください。 組み合わせは、H3とH2だけが交信することをたまたま許可します。
If G4 were not there, another path would be via AR 2, which could be permitted by suitable terms in ARs 1,2,3 and 4.
G4がないなら、AR2を通して別の経路はあるでしょうに。ARs1、2、3、および4の適当な用語はARを受入れることができました。
Even if G3 and G4 exist, no transit traffic will flow across AR 4 from 1 to 3. Even if 1 and 3 want it to:
G3とG4が存在していても、トランジット交通は全くAR4の向こう側に1〜3まで流れないでしょう。 1と3が以下でことでありたいと思うなら
AR1: ((*,1,-),(*,3,4),*,*) and
AR3: ((*,3,-),(*,1,4),*,*),
AR1: ((*,1,-),(*,3,4),*,*) AR3: ((*,3,-),(*,1,4),*,*),
the lack of a term for AR4 will prevent a valid PR via that path. Only if AR 4 added:
AR4のための用語の不足はその経路を通して有効なPRを防ぐでしょう。 AR4が加えた場合にだけ:
AR4:((*,1,-),(*,3,-),*,*)
AR4:((*,1,-),(*,3,-),*,*)
would AR 4 start serving AR a transit path from 1 to 3.
AR4は、トランジット経路にARに役立ち1〜3まで始めるでしょう。
If AR4 added:
AR4が加えたなら:
AR4: ((*,4,-),(*,*,*),*,*), any host in AR 4 could talk to any host anywhere else, but AR 4 would still not become a transit service.
AR4: ((*,4,-),(*,*,*),*,*), AR4のどんなホストも他のどこかでどんなホストとも話すことができましたが、AR4はまだトランジットサービスになっていないでしょう。
These various examples demonstrate how individual ARs can offer Policy Terms that can be combined to form a route. The notation proposed here is probably not adequate to express the needed range of policies. For example, it may be desirable to have lists of ARs as part of a term, as well as single values and "*". Other notation might be proposed to permit exclusion of a limited set of ARs. It may also be appropriate to write elements that are directional, so that connections can be "opened" in one direction but not in others. This idea is vague in a connectionless architecture, but seems to relate to some real policy requirements.
これらの様々な例は個々のARsがどう、ルートを形成するために結合できるPolicy Termsを提供できるかを示します。 ここで提案された記法は、必要な範囲の方針を言い表すためにたぶん適切ではありません。 例えば、用語の一部としてARsのリストを持っているのは望ましいかもしれません、ただ一つの値と「*」と同様に。 他の記法は、ARsの限られたセットの除外を可能にするために提案されるかもしれません。 また、方向上の要素を書くのも適切であるかもしれません、接続を一方向に「開かれます」が、他のもので開くことができないように。 この考えは、コネクションレスな構造であいまいですが、いくつかの本当の方針要件に関連するように思えます。
In general, the problem of expressing policy terms in compact form is the same as the problem of constructing compact access control lists. There is still an ongoing argument whether access control lists should be ordered, and should permit exclusion, and so on. It would seem that the exact same issues arise here. Some experience attempting to express real policies may give guidance as to the
一般に、コンパクト形に方針用語を表すという問題はコンパクトなアクセスコントロールリストを構成するという問題と同じです。 除外などは、アクセスコントロールリストが注文されるべきであるか否かに関係なく、進行中の議論であり、可能にするべきです。 全く同じ問題がここに起こるように思えるでしょう。 速達本当の方針へのいくつかの経験の試みが指導を与えるかもしれません。
Clark [Page 10] RFC 1102 Policy Routing in Internet Protocols May 1989
1989年5月にインターネットプロトコルで掘られるクラーク[10ページ]RFC1102方針
expressive power needed.
必要である表現力。
6. Cost Recovery
6. 原価回収
Almost all of the existing Internet has been paid for as a capital purchase and provided to the users as a free good. There are limited examples of cost recovery, but these are based on an annual subscription fee rather than a charge related to the utilization. There is a growing body of opinion which says that accounting for usage, if not billing for it, is an important component of effective resource management. For this reason, tools for accounting and billing must be a central part of any policy mechanism. However, precisely because the administrative regions are autonomous, we cannot impose a uniform form of billing policy on all of the regions. Some of them may continue to provide service freely, or on the basis of an annual fee. Others may charge on the basis of resources consumed, but even here there may be variations in detail, as some may charge by the packet and others may charge by the byte. Again, in the telephone analogy, we see a variety of billing policies, with both local and long distance carriers selling service either on the basis of a monthly fee or on a fee-per-minute of usage, with time of day conditions attached. The billing problem is thus a very complicated one, for the user would presumably desire to minimize the cost, in the context of the various outstanding conditions.
資本が自由な利益としてユーザに購入して、提供されたとき、既存のインターネットのほとんどすべてが代価を払われました。 原価回収の限られた例がありますが、これらは利用に関連する料金よりむしろ年間予約申し込み料金に基づいています。 増加している用法のための会計(それのための支払いでなくても)が効果的な資源管理の重要な成分であると言う意見のボディーがあります。 この理由で、会計と支払いのためのツールはどんな方針メカニズムの中央の部分であるに違いありません。 しかしながら、まさに管理領域が自治であるので、私たちは一定のフォームの支払い方針を領域のすべてに課すことができません。 彼らの何人かが、自由、または年会費に基づいてサービスを提供し続けるかもしれません。 他のものは、消費されましたが、ここで同等のリソースに基づいて変化が詳細にあるかもしれないと宣言するかもしれません、或るものがパケットによって充電されるかもしれなくて、バイトに従って他のものが充電するとき。 一方、電話類推では、私たちはさまざまな支払い方針を見ます、両方が地元であり、長距離のキャリヤーが月額料金に基づいた用法の1分あたり1つの料金の上でサービスを販売していて、添付の時刻状態で。 その結果、支払い問題は非常に複雑なものです、おそらく、ユーザが、費用を最小にすることを望んでいるでしょう、したがって、様々な傑出している状態の文脈で。
If we are actually to pay for use of services, there is also the problem of collection. Using the current telephone system as an example, there are two strategies for collecting revenues. One is the pre-divestiture mode, in which the source AR (or the destination AR in the case of a collect call) serves as a single collection point for all of the ARs involved in the call. After divestiture, we see another paradigm, in which the transit AR separately bills the customer.
また、実際に私たちがサービスの使用の代価を払うつもりであるなら、収集の問題があります。 例として現在の電話を使用して、収入を集めるための2つの戦略があります。 1つはプレ剥奪モードです。(ソースAR(または、コレクトコールの場合における目的地AR)はARsのすべてのためのポイントが呼び出しにかかわったただ一つの収集としてそのモードで機能します)。 剥奪の後に、私たちは別のパラダイムを見ます。(トランジットARは別々にそれで顧客に請求します)。
There are many reasons to support both collection formats. The primary reason for separate billing is that not all regions may wish to charge the user in the same units of currency. Some regions may wish to charge actual dollars, while others may wish to charge using some form of private allocation units. On the other hand, having a single point of collection is very convenient, because it eliminates a lot of duplicate effort in collection. It does, however, require a greater degree of trust and coordination among ARs.
両方の収集形式を支持する多くの理由があります。 別々の支払いの第一の理由はすべての領域が同じユニットの通貨でユーザを請求したがっているかもしれないというわけではないということです。 いくつかの領域が実際のドルを請求したがっているかもしれません、他のものは何らかの形式の個人的な配分単位を使用することで充電したがっているかもしれませんが。 他方では、1ポイントの収集を持っているのは非常に便利です、収集における多くの写しの努力を排除するので。 しかしながら、それはARsの中で、より大きい度の信用とコーディネートを必要とします。
Single point collection also simplifies another sticky problem, lost packets. For most types of service, the user would presumably be offended if asked to pay for a significant number of packets undelivered because they have been lost before reaching the destination. If each region separately bills for its traffic, then
また、ただ一つのポイント収集は別の厄介な問題、無くなっているパケットを簡素化します。 ほとんどのタイプのサービスにおいて、目的地に達する前にそれらが失われたので「非-渡」された多くのパケットの代価を払うように頼まれるなら、おそらく、ユーザは怒るでしょう。 各領域は交通、その時、別々に請求します。
Clark [Page 11] RFC 1102 Policy Routing in Internet Protocols May 1989
1989年5月にインターネットプロトコルで掘られるクラーク[11ページ]RFC1102方針
to avoid billing for packets that are lost between that AR and the destination, it is necessary to have some form of lost packet reporting, which travels backward through system decrementing the counters of all the intervening ARs. If single point collection is performed, then the usage meters can be put in the destination AR, and periodically propagated to the billing AR, if that is a different region.
そのARと目的地の間で失われているパケットのために請求するのを避けるために、すべての介入しているARsのカウンタを減少させるシステムを通して後方に旅行する無くなっているパケット報告の何らかのフォームを持つのが必要です。 ただ一つのポイント収集が実行されるなら、用法メーターを目的地ARに入れて、定期的に支払いARに伝播できます、それが異なった領域であるなら。
The discussion of lost packets makes clear an important relationship between billing and policy. If a Policy Route takes packets through a region of known unreliability, the regions preceding it on the path may be quite unwilling to forgive the charges for packets which have successfully crossed their region, only to be lost further down the route. A billing policy is a way of asserting that one region wishes to divorce itself from the reliability behavior of another region. The conditions in the policy terms, and corresponding policy routes, must therefore be able to capture two distinct conditions. The first is whether or not there exists a bilateral agreement between two ARs by which one agrees to be the collection agent for the other. The concatenation of a number of these agreements permits a single collection point to be used for the entire policy route. The other condition is whether or not the AR will accept packet and byte counts from the next AR downstream as the basis of billing, or whether the AR insists that the billing be based on the counts at the exit point of this AR. This condition allows an AR to build a wall between it and a subsequent unreliable AR. One can imagine certain regions agreeing to carry traffic into unreliable regions, but only grudgingly, knowing that the result is going to be user frustration which may be directed to all the ARs indiscriminately. The use of a specific policy condition can make clear to the end user which ARs do not view themselves as interworking harmoniously.
無くなっているパケットの議論は支払いと方針との重要な関係を明らかにします。 Policy Routeが領域を通ってパケットを持って行くなら、知られている非信頼性、経路でそれに先行するのがそうする領域では、首尾よくそれらの領域を越えた料金のパケットを許して、さらにルートの下側に無くなるようにだけかなり不本意であってください。 支払い方針は1つの領域が別の領域の信頼性の振舞いからそれ自体と離婚したがっていると断言する方法です。 したがって、方針用語、および対応する方針ルートによる状態は2つの異なった状態を得ることができなければなりません。 1番目は二国間条約が存在しているかどうかというものがもう片方のための収集エージェントであるのに同意する2ARsの間のことです。 これらの多くの協定の連結は、単一の収集ポイントが全体の方針ルートに使用されることを許可します。 もう片方の状態はARが支払いの基礎として川下に次のARからパケットとバイト・カウントを認めるかどうか、またはARが、支払いがこのARのエキジットポイントでカウントに基づいていると主張するかどうかということです。 この状態で、ARはそれとその後の頼り無いARの間の壁を造ることができます。 人は、一定の地域が、頼り無い領域まで交通を運ぶのに同意すると想像できますが、結果がユーザフラストレーションになるのを知っていて、いやいやながらだけ、どれが無差別にすべてのARsに向けられるかもしれないか。 特定保険証券状態の使用は、円満に自分たちを織り込むことであるとみなすようにどのARsがそうしないエンドユーザに明らかにすることができます。
To enforce these mechanisms, the abstract PR which is included in the packet must be augmented with a number of conditions. First, for each AR there is a 3-way flag which describes whether the billing should be separately collected for the region, propagated back to the source (which corresponds to the normal telephone company paradigm), or propagated towards the destination (which corresponds to a collect call). Second, there is a flag which indicates whether the region is expected to accept from the next region downstream the packet and byte counts as the basis of billing. Third, there must be a charge code, a unique number somewhat resembling a credit card number to which bills may be sent. The Policy Terms in the Gateways must similarly be augmented to permit verification. The management of the charge code, insuring its uniqueness and preventing its abuse, is discussed later.
これらのメカニズムを実施するために、多くの状態に従って、パケットに含まれている抽象的なPRは増大しなければなりません。 1番目は、そこの各ARが支払いが別々に領域に集められるべきであるかどうか説明する3ウェイ旗であるので、ソース(正常な電話会社パラダイムに対応する)に伝播して戻ったか、または目的地(コレクトコールに対応する)に向かって伝播されました。 2番目に、領域が次の領域の川下からパケットとバイトを受け入れると予想されるかどうか支払いの基礎にみなすのを示す旗があります。 3番目に、料金コード(請求書が送られるかもしれないクレジットカード番号にいくらか類似しているユニークな数)があるに違いありません。 GatewaysのPolicy Termsは、検証を可能にするために同様に増大しなければなりません。 ユニークさを保障して、乱用を防いで、後で料金コードの管理について議論します。
These conditions, which relate to agreements between two ARs, are
これらの状態(2ARsの間の協定に関連する)はそうです。
Clark [Page 12] RFC 1102 Policy Routing in Internet Protocols May 1989
1989年5月にインターネットプロトコルで掘られるクラーク[12ページ]RFC1102方針
somewhat different from the conditions previously discussed, such as time of day. Conditions relating to AR agreements will be called "bilateral conditions," while the others are called "global conditions." Note that even though bilateral conditions relate to the agreement between two ARs, they can have global effects.
以前に時刻などのように議論した状態といくらか異なります。 AR協定に関係する状態は「双方の状態」と呼ばれるでしょうが、他のものは「グローバルな状態」と呼ばれます。 双方の状態が2ARsの間の協定に関連しますが、彼らがグローバルな効果を持つことができることに注意してください。
7. Gateway Selection
7. ゲートウェイ選択
In Section Two, this memo proposed that the end point should specify an abstract Policy Route, as a series of ARs, and the Policy Gateway at the entry to each AR should convert the next hop to a concrete route, selecting the Policy Gateway to exit from this region into the next. It turns out that this selection is not entirely devoid of policy concerns, and some additional conditions are required in the Policy Terms in order to make this operate properly.
セクションTwoでは、このメモは、エンドポイントが一連のARsとして抽象的なPolicy Routeを指定するべきであり、各ARへのエントリーのPolicyゲートウェイが次のホップをコンクリートのルートに変換するべきであるよう提案しました、Policyゲートウェイがこの領域から次に出るのを選択して。 この選択が方針関心に完全に欠けていないと判明して、いくつかの追加条件が、これを適切に作動させるのにPolicy Termsで必要です。
In order that each Policy Gateway be able to select the next Policy Gateway on the route, it is necessary to have a table which lists all of the potential Policy Gateways that connect together adjacent regions. Presumably, this information is very slowly changing, and is not difficult to propagate. The more dynamic information that is needed is whether each of these gateways is up. It is therefore necessary that all of the Policy Gateways attached to a given AR must run a local up-down algorithm, one which hopefully can determine not only that each of the other gateways is up, but that its interfaces are up and that it is properly forwarding traffic. It is slightly complicated to design such a test. However, we do not have to design a strategy for propagating this information globally, because it is only needed by the other Policy Gateways attached to each region.
それぞれのPolicyゲートウェイ、ルートの上で次のPolicyゲートウェイを選択できます、領域に隣接して一緒に接続する潜在的Policy Gatewaysのすべてを記載するテーブルを持つのが必要であるということになってください。 おそらく、この情報は、非常にゆっくり変化していて、伝播するのは難しくはありません。 必要であるよりダイナミックな情報はそれぞれのこれらのゲートウェイが上がっているかどうかということです。 したがって、与えられたARに取り付けられたPolicy Gatewaysのすべてがローカルの上下アルゴリズム、その上それぞれの他のゲートウェイが上がっていることを希望をいだいて決定できるものを走らせなければなりませんが、インタフェースが上がっていて、適切に交通を進めるのが必要です。 そのようなテストを設計するのはわずかに複雑です。 しかしながら、私たちはこの情報をグローバルに伝播するための戦略を設計する必要はありません、それが各領域に取り付けられた他のPolicy Gatewaysによって必要とされるだけであるので。
The policy matter related to concrete routes arises if there are several gateways connecting two administrative regions. As described so far, the exit Policy Gateway from any region (which is the entry Policy Gateway for the next region) is selected by the entry Policy Gateway for that region. In other words, each region may select its exit gateway, but has no control over its entry gateway. There are certain circumstances where a particular region might insist on being able to control the entry gateway used. Imagine two parallel transit regions, one which charges incrementally for service, the other of which provides its service as a free good. Obviously, from the point of view of the user, it is desirable to minimize the use of the charging AR, and maximize the use of the free AR. But this may lead to gross overloads in the free AR, and apparent discrimination against the charging AR. The owner of the free AR, therefore, might choose to impose a policy which says that it can be used only to reach certain points which are not directly connected to the AR which bills for its service, and the traffic must enter the free AR at the closest point to the destination. In other words, the free AR
2つの管理領域をつなげる数門があれば、コンクリートのルートに関連する方針の件は起こります。 今までのところ説明されるように、どんな領域(次の領域へのエントリーPolicyゲートウェイである)からの出口Policyゲートウェイもその領域へのエントリーPolicyゲートウェイによって選択されます。 言い換えれば、各領域は、出口ゲートウェイを選択するかもしれませんが、エントリーゲートウェイを管理しません。 特定の領域が制御できると主張するかもしれないエントリーゲートウェイが使用したある事情があります。 2の平行なトランジットが領域(サービスに増加して課金するもの)であると想像してください。そのもう片方が自由な利益としてサービスを提供します。 明らかに、ユーザの観点から、充電しているARの使用を最小にして、自由なARの使用を最大にするのは望ましいです。 しかし、これは自由なARの総計のオーバーロード、および充電しているARに対する見かけの区別に通じるかもしれません。 したがって、自由なARの所有者は、直接そうでないポイントがサービスのためのどの請求書をARに接続したか、そして、交通が最も近いポイントで自由なARを目的地に入れなければならないのを確信している範囲だけにそれを使用できると言う方針を課すのを選ぶかもしれません。 言い換えれば、自由なAR
Clark [Page 13] RFC 1102 Policy Routing in Internet Protocols May 1989
1989年5月にインターネットプロトコルで掘られるクラーク[13ページ]RFC1102方針
requires that it be allowed to choose its entry gateway so that it minimizes its costs (which are not, in fact, being billed), with the intent of shifting as much as possible of the cost onto the other network.
コスト(事実上、請求されていない)を最小にするように費用がもう片方のネットワークにできるだけ移行する意図をもってエントリーゲートウェイを選ぶことができるのが必要です。
By adding more bilateral conditions to the Policy Terms and the Policy Route in the packet, it is possible to control the various options for Policy Gateway selection. At each boundary between ARs, there are only a limited number of ways to select the Policy Gateway. Either it is selected by the entry side, by the exit side, or by some collaborative algorithm specified through a bilateral agreement. (There might be several such algorithms, which requires the possibility of more complexity in the specification. In particular, if two adjacent ARs have agreed to use a common routing metric for some type of service, they may agree to make a common routing based on this metric.)
パケットでPolicy TermsとPolicy Routeにより双方の状態を加えることによって、Policyゲートウェイ選択のための様々なオプションを制御するのは可能です。 ARsの間の各境界には、Policyゲートウェイを選択する方法の限られた数しかありません。 それはエントリーの側、出口側、または二国間条約を通して指定された何らかの協力的なアルゴリズムによって選択されます。 (そのようないくつかのアルゴリズムがあるかもしれません。(アルゴリズムは仕様による、より多くの複雑さの可能性を必要とします)。 2隣接しているARsが、タイプのサービスにおける、メートル法の一般的なルーティングを使用するのに同意したなら、特に、彼らは、これに基づく一般的なルーティングをメートル法にするのに同意するかもしれません。)
Allowing the policy gateway to be selected by the AR which is on the far side of the gateway represents an interesting implementation problem. It would be possible to send some message in advance of the packet, which requests the next AR to select its entry gateway. To do this, it would figure out what its exit gateway would be, and then figure backwards to minimize its costs (for example) to select the potential entry gateway back into the immediate region. This is complicated to describe, and would probably be complicated to implement. One way to focus the problem is to observe that routes are bi-directional, because a packet flow is bi-directional, and it is very desirable that the packets from both directions follow the same route. Once a packet has come back along the reverse route, the gateway from which it emerges is precisely the gateway which should be used for future traffic in the other direction. But each gateway, in either the forward or reverse direction, must remember a decision made by another AR.
ゲートウェイを越してあるARによって選択されるように方針ゲートウェイを許容すると、おもしろい実現問題は表されます。 何らかのメッセージをパケットの前に送るのは可能でしょう。パケットはエントリーゲートウェイを選択するよう次のARに要求します。 それは、これをするために、出口ゲートウェイが何であるかを理解して、次に、(例えば)潜在的参入ゲートウェイを即座の領域に選択して戻すためにコストを最小にするのを後方に計算されるでしょう。 これは、説明するために複雑であり、たぶん道具に複雑にされるでしょう。 問題の焦点を合わせる1つの方法はルートが双方向であることを観測することです、パケット流動が双方向であり、両方の指示からのパケットが同じルートに従うのが、非常に望ましいので。 パケットが逆のルートに沿っていったん戻ると、それが現れるゲートウェイは正確にもう片方の方向への将来の交通に使用されるべきであるゲートウェイです。 しかし、各ゲートウェイは別のARによってされた決定を前進の、または、反対の方向に覚えていなければなりません。
For this to work it is necessary that gateways not be stateless. If each Policy Gateway maintains a cache of recently computed Policy Routes, in particular remembering the result of computing the gateway for each abstract route, then by simply determining whether or not the forward direction or the reverse direction is allowed to constrain the gateway across this boundary, both policies can be enforced. But this requires building gateways with state, which has not been culturally acceptable in the Internet. I therefore consider as a separate topic the virtues of state in Policy Gateways. I believe that fairly simple algorithms exist to set up the required bindings in the Policy Gateways, but that problem is a matter for later study.
これが何とかうまくやられるのがゲートウェイが国がなくないのが必要です。 それぞれのPolicyゲートウェイが最近計算されたPolicy Routesのキャッシュを維持するなら、そして、順方向か反対の方向がこの境界の向こう側にゲートウェイを抑制できるか否かに関係なく、両方の方針を励行されることができることを単に決定することによってそれぞれの抽象的なルートにゲートウェイを計算するという結果を特に覚えています。 しかし、これは、インターネットで文化的に許容できない状態があるゲートウェイを建設するのを必要とします。 したがって、私は、Policy Gatewaysで別々の話題が状態の美徳であるとみなします。 私は、かなり簡単なアルゴリズムがPolicy Gatewaysで必要な結合をセットアップするために存在すると信じていますが、その問題は後の研究への問題です。
Clark [Page 14] RFC 1102 Policy Routing in Internet Protocols May 1989
1989年5月にインターネットプロトコルで掘られるクラーク[14ページ]RFC1102方針
8. Flow States
8. 流れ州
The previous section suggested that the gateway needed to maintain state in order to tie together the forward and reverse halves of a flow. This solved the particular problem of tying together the routing decision which had been made in each direction, so that they could be used in the other. There are, in fact, a number of reasons why the two halves of the flow should be tied together.
前項は、ゲートウェイが、半分の前進の、そして、逆の流れを結びつけるために状態を維持する必要だったと示唆しました。 これは各方向にされたルーティング決定を結びつけるという特定の問題を解決しました、もう片方にそれらを使用できるように。 事実上、半分の2回の流れが結びつけられるべきである多くの理由があります。
- There is considerable overhead in accounting and collecting for the
usage. It is clearly desirable to have both halves of the flow
metered jointly.
- 会計と用法の寄付を募るのにおいてかなりのオーバーヘッドがあります。 流れの両方の半分を共同で計量させるのは明確に望ましいです。
- If the route is not bi-directional, then a failure in the node
produces a uni-directional link. Uni-directional links are known
to cause anomalous behavior in protocols.
- ルートが双方向でないなら、ノードでの失敗はuni方向のリンクを生産します。 Uni方向のリンクがプロトコルにおける異常挙動を引き起こすのが知られています。
- As part of resource management, it may be desirable for
intermediate nodes to pass flow control information back to the
source of the flow. If identifiable reverse-direction packets
are passing through the gateway, then this information can be
piggy-backed onto those packets.
- 資源管理の一部として、中間的ノードがフロー制御情報を流れの源に戻すのは、望ましいかもしれません。 身元保証可能な逆指示パケットがゲートウェイを通り抜けているなら、この情報をそれらのパケットに背負うことができます。
An additional advantage of maintaining state in the gateway is that it will greatly reduce the overhead of dealing with incoming packets. There are a number of decisions which the Policy Gateway must make which are a part of forwarding a packet: it must validate the Policy Route against its terms, it must create or modify an accounting record, and it must select the next Policy Gateway. It is unreasonable to imagine performing these tasks from scratch for each incoming packet. Once these decisions have been made, the results should be cached, so that they can be used for subsequent packets.
ゲートウェイで状態を維持する追加利点は入って来るパケットに対処するオーバーヘッドを大いに下げるということです。 Policyゲートウェイがしなければならないパケットを進める一部である多くの決定があります: 用語に対してPolicy Routeを有効にしなければなりません、そして、会計帳簿を作成しなければならないか、または変更しなければなりません、そして、それは次のPolicyゲートウェイを選択しなければなりません。 最初からそれぞれの入って来るパケットのためにこれらのタスクを実行すると想像するのは無理です。 いったんこれらの決定をすると、その後のパケットにそれらを使用できるように結果をキャッシュするべきです。
The stateless gateway was proposed as part of the Internet design in order to insure a robust architecture. If the gateway has no state, then a crash of a gateway cannot endanger an on-going connection. If there is state in a gateway, and that state information is lost because of a crash, then it is possible that a flow would be disrupted.
国がないゲートウェイは、強健な構造を保障するためにインターネットデザインの一部として提案されました。 ゲートウェイに状態が全くないなら、ゲートウェイのクラッシュは継続している接続を危険にさらすことができません。 状態がゲートウェイにあって、その州の情報がクラッシュのために失われているなら、流れが混乱させられるのは、可能です。
In moving from a gateway with no state to a gateway which caches information, it is necessary to ensure that the cached information can be lost and reconstructed. The idea of keeping in gateways only that state which can be easily reconstructed I call "soft state."
ゲートウェイから状態なしで情報をキャッシュするゲートウェイに引っ越すのにおいて、キャッシュされた情報を失っていて、再建できるのを保証するのが必要です。 ゲートウェイに閉じ込めるという「軟性国家」と、容易に再建された私であるかもしれない州が呼ぶだけであるという考え。
Clark [Page 15] RFC 1102 Policy Routing in Internet Protocols May 1989
1989年5月にインターネットプロトコルで掘られるクラーク[15ページ]RFC1102方針
9. Synthesis and Selection of Policy Routes
9. 方針ルートの統合と品揃え
In this proposal, a packet contains a Policy Route, which is verified by each Policy Gateway along the way. This section discusses how the Policy Route is created in the first place.
この提案では、パケットはPolicy Routeを含んでいます。(Policy Routeは道に沿ってそれぞれのPolicyゲートウェイによって確かめられます)。 このセクションはPolicy Routeが第一にどう作成されるかを論じます。
PR creation cannot be done totally automatically by the system, but will in general require human judgment. Policies, after all, are matters of human concern. The approach to PR creation is thus a joint one, in which the system provides support to the persons setting policy.
PR創造は、システムで完全に自動的にすることができるというわけではありませんが、一般に、人間の判断を必要とするでしょう。 方針は結局人間の関心の物質です。 その結果、PR創造へのアプローチは共同ものです。(そこでは、システムが方針を設定する人々にサポートを提供します)。
Most commonly, the desired PR will be selected from among those available by first finding all valid PRs, and then picking one that meets the requirements of the user and has the lowest real cost. These two stages will be called synthesis and selection.
最も一般的に、必要なPRは、ユーザの最初にすべての有効なPRを見つけて、次に、条件を満たすものを選ぶことによって利用可能なものの中で選び抜かれて、最も低い実質費用を持っています。 これらの2つのステージが統合と選択と呼ばれるでしょう。
To synthesize a PR across a sequence of ARs, one must find a Policy Term in each AR that would permit such a PR. The Policy Terms in each adjacent AR must be compatible in their billing conditions and other particulars. One can imagine finding a sequence of Policy Terms that match, rather like dominoes, and reach from the source to the destination.
ARs、1の系列の向こう側にPRを統合するのはそのようなPRを可能にする各ARでPolicy Termを見つけなければなりません。 それぞれの隣接しているARのPolicy Termsは彼らの支払い状態と他の子細において互換性があるに違いありません。 人は、ドミノのように合って、ソースから目的地まで届くPolicy Termsの系列を見つけると想像できます。
For a Policy Term at some AR to be acceptable as a part of a PR, the following must be true:
いくらかのARのPolicy TermがPR、以下の必須の一部として許容できるには、本当であってください:
- The Source and Destination Host address and UCI must match the
term,
- Source、Destination Hostアドレス、およびUCIは用語に合わなければなりません。
- The Source and Destination AR must match the term,
- SourceとDestination ARは用語に合わなければなりません。
- The Entry and Exit AR must match the adjacent AR in the route,
- EntryとExit ARはルートで隣接しているARに合わなければなりません。
- The conditions in the term relating to the adjacent AR (e.g.,
billing) must match the conditions in the term from that region.
- 隣接しているAR(例えば、支払い)に関連する用語による状態はその領域からの用語による状態に合わなければなりません。
These conditions, of course, are exactly what the Policy Gateway would test in validating the PR when it is used.
これらの状態はもちろんまさにPolicyゲートウェイがそれが使用されているときPRを有効にする際にテストすることです。
As the route is synthesized from matching terms, the global conditions of each term are noted, and the combination of these become the condition under which the PR is valid. As a starting point of the synthesis the user may have indicated constraints on the acceptable conditions in order to limit the candidate terms in the synthesis.
ルートが合っている用語から統合されるとき、それぞれの用語のグローバルな状態は注意されます、そして、これらの組み合わせはPRが有効である状態になります。 統合の出発点として、ユーザは、統合が候補用語を制限するために容認できる条件で規制を示したかもしれません。
The result of PR synthesis, which is somewhat similar to the
PR統合は結果として生じます。(それは、いくらか同様です)。
Clark [Page 16] RFC 1102 Policy Routing in Internet Protocols May 1989
1989年5月にインターネットプロトコルで掘られるクラーク[16ページ]RFC1102方針
computation in a link-state routing algorithm where each Policy Term represents an abstract link, is a potentially long list of possible PRs to each destination AR, each with attached conditions. The selection process must identify one of these which is actually to be used. The selection can be based on the conditions, and on the cost of each PR.
各Policy Termが抽象的なリンクを表して、潜在的に長いリストである各目的地AR(添付の状態のそれぞれ)への可能なPRのLinkState方式アルゴリズムにおける計算。 選択の過程は実際に使用されることになっているこれらの1つを特定しなければなりません。 状態に基づいたそれぞれのPRの費用の上に選択があることができます。
To determine the cost, it must be possible to ask each AR to identify the cost of using that Policy Term in the context of this particular set of Entry and Exit ARs. Either there must be an architected protocol for reporting these costs, or the task of cost determination must be left to humans to perform outside the system. The problem with architected cost reporting is that while some ARs may bill using real dollars, others may bill in terms of abstract usage authorizations which have no meaning outside that AR. Even so, I believe that we should attempt to define a representation for reporting the billing basis associated with each AR. This is a matter for later study.
費用を決定するために、EntryとExit ARsのこの特定のセットの文脈でそのPolicy Termを使用する費用を特定するように各ARに頼むのは可能でなければなりません。 これらのコストを報告するためのarchitectedプロトコルがなければならないに違いありませんか、またはシステムの外で働くのを原価決定に関するタスクを人間に残さなければなりません。 他のものは、そのARの外に意味でないのを持っている抽象的な用法承認に関していくつかのARsが本当のドルを使用に請求するかもしれませんが、architected原価報告に関する問題がそれであることを請求するかもしれません。 たとえそうだとしても、私たちが、支払い基礎が各ARに関連していると報告する表現を定義するのを試みるべきであると信じています。 これは後の研究への問題です。
While PR synthesis may be an automated process, selection probably is not. While cost minimization will help prune the list, and some routes may be rejected automatically on the basis of conditions, part of the selection will in general require human judgment. This observation, together with the observation that PR synthesis may be costly, suggests first that synthesis and selection cannot be done for each packet or indeed each time a transport connection is established, and second that it should not be done separately for each host in the AR.
PR統合は自動化された過程であるかもしれませんが、選択はたぶんそのような過程ではありません。 費用極小化が、リストを剪定するのを助けて、いくつかのルートが状態に基づいて自動的に拒絶されているかもしれない間、一般に、選択の一部が人間の判断を必要とするでしょう。 この観測は、PR統合が高価であるかもしれないという観測と共に各パケットか本当に輸送接続が確立される各回と、ARの各ホストのために別々にそれをするべきでない2番目のために最初に、その統合と選択ができないのを示します。
Instead, each AR should have one (or more) Policy Servers, servers inside the AR which support the management of PRs. The Policy Server would perform a number of functions.
代わりに、各ARはPRの管理を支持するARの中に1(さらに)方針Servers、サーバを持っているはずです。 Policy Serverは多くの機能を実行するでしょう。
- It would store the Policy Terms for the AR, and make them available
to the Policy Gateways and the Servers of other ARs as appropriate.
- それで、適宜ARのためにPolicy Termsを格納して、彼らは他のARsのPolicy GatewaysとServersに利用可能になるでしょう。
- It would synthesize potential PRs to reach other ARs, and remember
which of these have been selected for use.
- それは、他のARsに達して、これらのどれが使用のために選択されたかを覚えているために潜在的PRを統合するでしょう。
- It will respond to requests from hosts in the AR for PRs, and
return them so that they can be included in outgoing packets.
- それは、出発しているパケットにそれらを含むことができるようにPRのためにARのホストから要求に応じて、それらを返すでしょう。
- It will participate on behalf of the AR in AR up-down protocols,
and other inter-AR routing algorithms.
- それはAR上下プロトコル、および他の相互ARルーティング・アルゴリズムによるARを代表して関与するでしょう。
- It will remember the location of all Policy Gateways attached to
this AR.
- それは、すべてのPolicy Gatewaysの位置がこのARに付いたのを覚えているでしょう。
Clark [Page 17] RFC 1102 Policy Routing in Internet Protocols May 1989
1989年5月にインターネットプロトコルで掘られるクラーク[17ページ]RFC1102方針
- It will provide the management interface for those persons who must
establish AR policy: setting of local Policy Terms, selection of
Policy Routes, and so on.
- それはAR方針を確立しなければならない人々に管理インタフェースを提供するでしょう: 地方のPolicy Termsの設定、Policy Routesの品揃えなど。
A host wishing to send packets outside the local AR must first obtain a PR to put into the packets. In the normal case, it would do so by directing a request to the local Policy Server, supplying the desired destination and other negotiable conditions. (For example, the TOS is negotiable, the current time is not.) The Server, based on this input, must select the most appropriate PR and return it.
地方のARの外にパケットを送りたがっているホストは最初に、パケットに置くPRを得なければなりません。 正常な場合では、そう地方のPolicy Serverに要求を向けることによって、するでしょう、必要な目的地と他の交渉可能な状態を提供して。 (例えば、TOSが交渉可能である、現在の時間はそうではありません。) この入力に基づくServerは最も適切なPRを選択して、それを返さなければなりません。
At this point in the process, human intervention is not reasonable, as it would take much too long. By now, sufficient selection must have been done so that automated PR selection is possible. The most direct implementation is that the manual selection process should yield an ordered (or partially ordered) list of potential PRs, and the list is searched in order until a PR is found that matches the destination and conditions. That PR is then returned.
多くにあまり時間がかかるでしょう、したがって、ここに、過程で、人間の介入は合理的ではありません。 今ごろ、自動化されたPR選択が可能であるように、十分な選択をしたに違いありません。 最もダイレクトな実現は手動の選択の過程が潜在的PRの注文されて(部分的に命令される)のリストをもたらすべきであるということです、そして、リストは目的地と状態に合っているPRが見つけられるまでのオーダーを捜されます。 そして、そのPRを返します。
10. Security
10. セキュリティ
There are a number of aspects of this scheme which present opportunities for abuse. In essentially all cases, the possible abuse is theft of network resources or improper charging. They thus have a somewhat different nature than problems related to corruption or disclosure of data. Mechanism to insure proper use and charging of resources often tolerate minor abuse in exchange for ease of operation. Also, control is often based on detection and recovery rather than prevention. Assumptions of this sort are probably acceptable here as well. An isolated packet, which is not a part of any sequence of packets, may be too small an item to account for or control. But if a significant stream of packets goes unaccounted, this is less acceptable.
乱用の機会を提示するこの計画の多くの局面があります。 本質的にはすべての場合では、可能な乱用はネットワーク資源か不適当な充電の窃盗です。 彼らには、その結果、いくらかデータの不正か公開に関連する問題と異なった自然があります。 しばしばリソースの適切な使用と充電を保障するメカニズムは操作の容易さと引き換えに小さい方の乱用を許容します。 また、コントロールはしばしば防止よりむしろ検出と回復に基づいています。 また、この種類の仮定はたぶんここで許容できます。 孤立しているパケット(パケットのどんな系列の一部ではありませんも)は、原因になる小さ過ぎる項目かコントロールであるかもしれません。 しかし、パケットの重要な小川が非説明されているのに行くなら、これはそれほど許容できません。
There are three general options for abuse. One is to falsify the user identification information in the PR, the source and destination host, the User Class Id and the charge code. Another is to take a valid PR and misuse it intact. And the third is to read out a valid charge code from a PR and then make additional charges against it.
乱用のための3つの一般的なオプションがあります。 人はPR、ソース、およびあて先ホストのユーザ登録名情報、User Class Id、および料金コードを改竄することになっています。 別のものは、完全な状態で有効なPRを取って、それを誤用することになっています。 そして、3番目は、PRから有効な料金コードを読みだして、次にそれに対して割増料金をすることです。
To protect against putting false user identification information into a PR, the PRs should be sealed or signed, using a crypto sealing technique. Since Policy Servers are the source of PRs, the sealing can be done by the Server. This would require that the seal or digital signature of each Server be known, but avoids the need to have each host known. The Server would be trusted to seal only valid PRs. It must only put User Class Ids and charge codes into PRs from a source permitted to use them, for example.
PRは、誤ったユーザ登録名情報をPRに入れないように保護するために、封をされるべきであるか、またはサインされるべきです、暗号の封をするテクニックを使用して。 Policy ServersがPRの源であるので、Serverは封を終わることができます。これは、それぞれのServerのシールかデジタル署名が知られていますが、各ホストを知らせる必要性を避けるのを必要とするでしょう。 Serverが有効なPRだけの封をすると信じられるでしょう。 それは例えばそれらを使用することが許可されたソースからPRにUser Class Idsと料金コードを入れるだけでよいです。
Clark [Page 18] RFC 1102 Policy Routing in Internet Protocols May 1989
1989年5月にインターネットプロトコルで掘られるクラーク[18ページ]RFC1102方針
Assuming a public key system, each Policy Server could have a separate key pair, the public half of which was advertised in some way. It is a matter for further study exactly what parts of the PR need be sealed.
公開鍵システムを仮定する場合、各Policy Serverには別々の主要な組があるかもしれません。その公共の半分は何らかの方法で広告に掲載されました。 ちょうどPRのどんな部分が封をされなければならないかは、さらなる研究への問題です。
If the Policy Server violates this trust, and uses a UCI or charge code with an unauthorized host, there are two sub-cases: the false source host is in the same AS, or is outside it. If it is outside, this can be detected by inspection of the PR, since the relation between AR and network number is (almost) static. One approach is to make an AR identifier part of the charge code, so that use of the code can be rejected unless that AR is the source AR for the packet. This works, but prevents using charge codes from a foreign location. Other more general techniques could probably be proposed.
Policy Serverが権限のないホストと共にこの信用に違反して、UCIか料金コードを使用するなら、2つのサブケースがあります: 偽の送信元ホストは、同じASにいるか、またはそれの外にいます。 それが外にあるなら、PRの点検でこれを検出できます、ARとネットワーク・ナンバーとの関係が(ほとんど)静的であるので。 1つのアプローチは料金コードのAR識別子部分を作ることです、そのARがパケットのためのソースARでないならコードの使用を拒絶できるように。 これは、働いていますが、外国位置から料金コードを使用するのを防ぎます。 たぶん他の、より一般的なテクニックを提案できました。
If the false source host is inside the AR, then further steps are required to prevent the problem. One general solution is to note that a PR is valid only if sealed by a Policy Server. Any AR attempting to collect for usage should be required to keep a copy of the PR as proof that the route was used. If there seems to be unauthorized use of a charge code, the owner can ask to see the PR which generated the charge, which will show the Policy Server which constructed the route. If this is an unauthorized use, action can be taken against the AR owning that Server, with the sealed PR as evidence. In other words, detection and redress may be more effective than prevention.
偽の送信元ホストがARの中にいるなら、さらなるステップが、問題を防ぐのに必要です。 1つの一般解はPolicy Serverによって封をされる場合にだけPRが有効であることに注意することです。用法の寄付を募るのを試みるARが、ルートが使用されたという証拠としてPRの写しを取っておくのに必要であるべきです。 充電コードの無断使用があるように思えるなら、所有者は、どれがルートを構成したかをPolicy Serverに示す充電を生成したPRを見るように頼むことができます。 これが無断使用であるなら、そのServerを所有しているARに対して行動を取ることができます、証拠としての密封されたPRで。 言い換えれば、検出と救済は防止より効果的であるかもしれません。
If we can assume that the Policy Server for a particular region is as trustworthy as that AR requires, there is still the problem of a Server of one region trying to steal from another AR. This could be done, for example, by taking a valid PR, and sending data forward along it from the "middle" of the route, so that what appears to be coming from one source is actually coming from another in a different AR.
私たちが、特定の領域へのPolicy ServerがそのARが必要とするのと同じくらい信頼できると思うことができるなら、1つの領域のServerが別のARから盗もうとするという問題がまだあります。 例えば、それに沿ってルートの「中央」から有効なPRを取って、データを考慮させるために送ることによって、これができるでしょう、1つのソースから何を来させるように見えるか実際に別のものと異なったARで来る予定であるように。
This would require that packets coming back along the route towards the original source be rerouted to the false source, which would require that the whole routing function within the AR be corrupted. It is unlikely that this would go long undetected, but if direct control of this class of fraud is needed, it could be achieved by requiring any AR intending to charge against a particular PR to obtain from time to time a confirmation, sealed by the Server of the source AR, that its policy gateway has in fact forwarded some number of packets using this PR. This sort of function is probably overkill, but this class of fraud needs to be considered.
これは、ルートに沿って一次資料に向かって戻るパケットが偽のソースに別ルートで送られるのを必要とするでしょう。(ソースはARの中の全体の経路選択機能が崩壊するのを必要とするでしょう)。 これが長い間非検出されているのに行くのが、ありそうもないのですが、このクラスの詐欺の直轄が必要であるなら、それは、時々得る特定のPRに対して事実上、方針ゲートウェイが持っているソースARのServerによって確認された確認がこのPRを使用することで何らかの数のパケットを進めたと宣言するつもりであるARを必要とすることによって、達成されるかもしれません。 この種類の関数はたぶん過剰殺傷ですが、このクラスの詐欺は、考えられる必要があります。
Obviously, a more detailed study will be required of the problem of resource theft, but I believe that a mechanism can be made to work
明らかに、リソース窃盗の問題は、より詳細な研究に要求されるでしょうが、私は、メカニズムは働かされることができると信じています。
Clark [Page 19] RFC 1102 Policy Routing in Internet Protocols May 1989
1989年5月にインターネットプロトコルで掘られるクラーク[19ページ]RFC1102方針
based on:
ベース:
- Local trust of the Policy Server within each AR.
- 各ARの中のPolicy Serverの地方の信頼。
- Sealing of the PR by the Server.
- PRはサーバによって封をされます。
- Selective validation of the seal at the Policy Gateway.
- Policyゲートウェイのシールの選択している合法化。
- Selective consistency checking of the PR at the Policy Gateway.
- PolicyゲートウェイのPRの選択している一貫性の照合。
- Use of seal on PR as evidence of the source of the PR.
- PRの源に関する証拠としてのPRにおけるシールの使用。
11. An Experimental Program -- Migration to Policy Routing
11. 実験用プログラム--方針ルート設定への移行
The proposal above calls for several Internet components not present today: the Policy Route IP option, Policy Gateways, Policy Servers, and support protocols such as the global AS up-down protocol and the local (to the AS) Policy Gateway up-down protocol. Any plan for introduction of policy routing must provide a method to experiment with the concept without changing all the hosts and the gateways now in place.
今日現在でないいくつかのインターネットコンポーネントのための呼び出しを超えた提案: グローバルなAS上下プロトコルや地方(ASへの)の方針ゲートウェイ上下などのPolicy Route IPオプション、Policy Gateways、Policy Servers、およびサポートプロトコルは議定書を作ります。 方針ルーティングの導入のためのどんなプランも現在適所ですべてのホストとゲートウェイを変えないで概念を実験するメソッドを提供しなければなりません。
Since the Policy Server is a new component which can be added to the Internet without changing any existing components, it is easy to put that facility in place. This, then, becomes the central part of an experimental plan. Later, it is possible to imagine adding the policy controls to some of the gateways. Most difficult will be modifying all the hosts to use the PR IP option. Based on our experience with adding minor features such as IP subnetworks, it will never be possible to get the PR option into all the hosts, and policy routing must be made to work anyway.
Policy Serverがどんな既存のコンポーネントも変えないでインターネットに加えることができる、新しいコンポーネントであるので、その施設を適所に置くのは簡単です。 そして、これは実験プランの中央の部分になります。 その後、数門に方針コントロールを加えると想像するのは可能です。 最も難しいのは、PR IPオプションを使用するためにすべてのホストが変更になるだろうこと。 IPサブネットワークなどの小さい方の特徴を加える私たちの経験に基づいてすべてのホストにPRオプションを届けるのが決して可能でなく、方針ルーティングをとにかく働かせなければなりません。
Taking into account these difficulties, here is a concrete experimental plan, in three phases.
これらの困難を考慮に入れて、三相における具体的な実験プランがここにあります。
In Phase I, software for a Policy Server is created, and made available to all potential ARs. As a part of its function, it has two "temporary" feature, to mimic the function of the missing host and gateway support.
Phase Iでは、Policy Serverのためのソフトウェアを作成されて、すべての潜在的ARsが入手します。 機能の一部として、それには、行方不明のホストとゲートウェイサポートの機能をまねるために、2の「一時的な」機能があります。
To mimic the function of the policy gateway, two policy Servers are placed "near" a current function gateway which happens to connect the two ARs, one on each side of the current gateway, and representing their respective ARs. These two Servers then proceed to fool the current gateway as follows.
方針ゲートウェイの機能をまねるために、2方針Serversは「近い」状態で置かれて、たまたま2ARs、それぞれの1を接続する流れ関数ゲートウェイが現在のゲートウェイと、彼らのそれぞれのARsを表すのに面があるということです。 そして、これらの2Serversが以下の現在のゲートウェイを馬鹿に続かせます。
- The current gateway is given the two Servers as neighbors in its
routing exchanges. In this way, the Servers can control which
- 隣人としてルーティング交換で2Serversを現在のゲートウェイに与えます。 このように、Serversはどれを制御できるか。
Clark [Page 20] RFC 1102 Policy Routing in Internet Protocols May 1989
1989年5月にインターネットプロトコルで掘られるクラーク[20ページ]RFC1102方針
network numbers are advertised. This is similar to the way "gated"
is used today to control routes.
ネットワーク・ナンバーの広告を出します。 これは「ゲート」が今日ルートを制御するのに使用される方法と同様です。
- A packet entering the AR is directed to the "near" Server inside
the AR, which performs the functions of the Policy Gateway and
then resends the packet. This may require the use of a regular
source route in some cases, but can probably just be done by
rewriting the destination IP address in the packet. (Note that
the IP PR option proposed in the Appendix has fields for the
original IP source and destination, so that these fields can be
reused in forwarding the packet from gateway to gateway.)
- ARに入るパケットはARの中の「近い」Serverに向けられます。ARはPolicyゲートウェイの機能を実行して、次に、パケットを再送します。 これがいくつかの場合通常の送信元経路の使用を必要とするかもしれませんが、たぶんパケットで送付先IPアドレスを書き直すことによって、ただできます。 (Appendixで提案されたIP PRオプションが元のIPソースと目的地への分野を持っていることに注意してください、ゲートウェイへのゲートウェイからパケットを進める際にこれらの分野を再利用できるように。)
To deal with the lack of host support for the PR option, we again make use of the Server. Since the Server is the recipient of all routing information coming into the AR (since it has been set up as the neighbor of the current gateway at the actual AR boundary) it alone knows the proper routes out. Internally, it advertises itself as the default gateway to all networks outside the AR, so that it receives all the packets intending to leave the region. It, rather than the host, adds the PR option and then sends the packet on the Policy Gateway (or the matching Server in the next AR playing its part) for relaying.
PRオプションのホストサポートの不足に対処するのに、私たちは再びServerを利用します。ServerがARに入るすべてのルーティング情報の受取人(それが現在のゲートウェイの隣人として実際のAR境界でセットアップされたので)であるので、それだけが外で適切なルートを知っています。 本質的に、デフォルトゲートウェイとしてARの外のすべてのネットワークに自分を売り込みます、領域を出るつもりでありながらすべてのパケットを受けるように。 それは、リレーのためにホストよりむしろPRオプションを加えて、次に、Policyゲートウェイ(または、本分を尽くす次のARの合っているServer)のパケットを送ります。
By controlling how routes are propagated by the regular gateways, it is possible to prevent hosts from manually setting up routes to bypass the Servers. In any event, enforcement is not the primary concern in Phase I of the experiment.
ルートが通常のゲートウェイによってどう伝播されるかを制御することによって、ホストがServersを迂回させるために手動でルートをセットアップするのを防ぐのは可能です。 とにかく、実施は実験のPhase Iのプライマリ関心ではありません。
In Phase II, certain of the current gateways are augmented with the Policy Gateway functions. This will make enforcement easier, and eliminate the extra hop which the packet had make in Phase I, as it passed from one Server to another through the current gateway. At the same time, some of the hosts are modified to insert the IP PR option into the packet at the source. This will explore the problems of PR selection.
IIの、そして、電流が確かなPhaseでは、Policyゲートウェイの機能に従って、ゲートウェイは増大します。 これは、実施をより簡単にして、それとしてのPhase Iでパケットで現在のゲートウェイを別のものに終えた1Serverから通るようにした付加的なホップを排除するでしょう。 同時に、何人かのホストが、IP PRオプションをソースのパケットに挿入するように変更されます。 これはPR選択の問題を探るでしょう。
In Phase III, the PR design is proposed for general implementation.
Phase IIIでは、PRデザインは一般的な実装のために提案されます。
12. Policy Route Setup
12. 方針ルートセットアップ
One objection to this scheme is the large size of the IP PR option. With all the information proposed in this memo, it is larger than the IP header itself. However, this problem can easily be avoided; the PR option seldom need be sent.
この体系への1つの異論がIP PRオプションの大判です。 すべての情報がこのメモで提案されている状態で、それはIPヘッダー自体より大きいです。 しかしながら、容易にこの問題を避けることができます。 めったにPRオプションを送る必要はありません。
Since the Policy Gateways are going to cache the result of processing the PR, the cache holds the equivalent of the PR. All that is required is a very short option in the packet which is a handle that
Policy GatewaysはPRを処理するという結果をキャッシュするでしょう、したがって、キャッシュがPRの同等物を保持します。 必要であるのが、aであるパケットの非常に短いオプションであるということであるすべてがそれを扱います。
Clark [Page 21] RFC 1102 Policy Routing in Internet Protocols May 1989
1989年5月にインターネットプロトコルで掘られるクラーク[21ページ]RFC1102方針
permits the gateway to find the correct cache entry. This handle would be included in the original IP PR option, and then repeated in every packet. The Policy Server which generated the PR could select the handle, so it would be unique for each AR. Perhaps the AR id and a 16 bit UID would be sufficient.
正しいキャッシュエントリーを掘り出し物へのゲートウェイに可能にします。 このハンドルは、オリジナルのIP PRオプションに含まれていて、次に、あらゆるパケットで繰り返されるでしょう。 PRを生成したPolicy Serverがハンドルを選択できたので、各ARに、それはユニークでしょう。 恐らく、ARイドと16ビットのUIDは十分でしょう。
The full PR option needs to be in the packet only if the cached Information in the gateway is lost. If a gateway crashes or the route changes, the end point must reconstruct the caches in the series of gateways that form the route. The end point could determine that this was necessary either when a gateway reports explicitly that it does not have an entry corresponding to a handle, or when the host determines that it is not getting the desired service.
ゲートウェイのキャッシュされた情報が無くなる場合にだけ、完全なPRオプションは、パケットにある必要があります。 ゲートウェイがダウンするか、またはルートが変化するなら、エンドポイントはルートを形成するゲートウェイのシリーズにおけるキャッシュを再建しなければなりません。 エンドポイントは、これがゲートウェイであるときに、どちらかが、ハンドルかそれともホストが、いつ必要なサービスを得ていないと決心するかまでエントリーを対応するようにしないと明らかに報告するのが必要であったことを決定するかもしれません。
This sort of action can be thought of as an extension to the idea of retransmitting. In transport protocols such as TCP, the host keeps track of the behavior of the network, and if it believes that something is wrong (e.g., there is a lack of an acknowledgment), it takes action to restore the desired service. Other examples include switching to another gateway if the currently active adjacent gateway seems to be down. Sending the full PR option in the packet is just another example of allowing the end node to restore the state of the connection if it seems to be broken.
拡大としてこの種類の動作を再送するという考えに考えることができます。 TCPなどのトランスポート・プロトコルでは、ホストはネットワークの振舞いの動向をおさえます、そして、何か問題があるのが(例えば、承認の不足があります)信じているなら、それは、必要なサービスを復元するために行動を取ります。 他の例は、現在アクティブな隣接しているゲートウェイが下がっているように思えるならもう1門に切り替わるのを含んでいます。 パケットで完全なPRオプションを送るのは、壊れているように思えるならエンドノードが接続の状態を回復するのを許容するただの例です。
Using this model, most packets would have only a short option (perhaps 12 bytes).
このモデルを使用して、ほとんどのパケットには短いオプション(恐らく12バイト)しかないでしょう。
This idea of restoring the state in the gateway as needed achieves the idea of "soft state" mentioned earlier, and allows gateways with state to achieve the same robustness associated with datagram networks.
ゲートウェイで状態を回復するというこの考えは、必要に応じてより早く言及された「軟性国家」の考えを実現して、状態があるゲートウェイがデータグラム・ネットワークに関連している同じ丈夫さを達成するのを許容します。
Author's Address
作者のアドレス
David D. Clark Massachusetts Institute of Technology Laboratory for Computer Science 545 Main Street Cambridge, MA 02139
Main Streetケンブリッジ、デヴィッドD.クラークマサチューセッツ工科大学コンピュータ科学研究所545MA 02139
Phone: (617) 253-6003
以下に電話をしてください。 (617) 253-6003
Email: ddc@LCS.MIT.EDU
メール: ddc@LCS.MIT.EDU
Clark [Page 22]
クラーク[22ページ]
一覧
スポンサーリンク
