RFC2113 日本語訳
2113 IP Router Alert Option. D. Katz. February 1997. (Format: TXT=7924 bytes) (Updated by RFC5350) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group D. Katz Request for Comments: 2113 cisco Systems Category: Standards Track February 1997
コメントを求めるワーキンググループD.キャッツ要求をネットワークでつないでください: 2113年のコクチマスSystems Category: 標準化過程1997年2月
IP Router Alert Option
IPルータ警戒オプション
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
This memo describes a new IP Option type that alerts transit routers to more closely examine the contents of an IP packet. This is useful for, but not limited to, new protocols that are addressed to a destination but require relatively complex processing in routers along the path.
このメモは、より密接にIPパケットのコンテンツを調べるようトランジットルータに注意を促す新しいIP Optionタイプについて説明します。 これは目的地に扱われますが、経路に沿ったルータで比較的複雑な処理を必要とする役に立って、他の、そして、新しいプロトコルです。
1.0 Introduction
1.0 序論
A recent trend in routing protocols is to loosely couple new routing functionality to existing unicast routing. The motivation for this is simple and elegant -- it allows deployment of new routing functionality without having to reinvent all of the basic routing protocol functions, greatly reducing specification and implementation complexity.
ルーティング・プロトコルにおける最近の傾向は緩く既存のユニキャストルーティングと新しいルーティングの機能性を結合することです。 これに関する動機は、簡単であって、上品です--基本的なルーティングプロトコル機能のすべてを再発明する必要はなくて、新しいルーティングの機能性の展開を許します、仕様と実装の複雑さを大いに減らして。
The downside of this is that the new functionality can only depend on the least common denominator in unicast routing, the next hop toward the destination. No assumptions can be made about the existence of more richly detailed information (such as a link state database).
この下落傾向は新しい機能性をユニキャストルーティングによる共通項、目的地に向かった次のホップに依存できるだけであるということです。 より豊かに詳細な情報(リンク州のデータベースなどの)の存在に関して仮定を全くすることができません。
It is also desirable to be able to gradually deploy the new technology, specifically to avoid having to upgrade all routers in the path between source and destination. This goal is somewhat at odds with the least common denominator information available, since a router that is not immediately adjacent to another router supporting the new protocol has no way of determining the location or identity of other such routers (unless something like a flooding algorithm is implemented over unicast forwarding, which conflicts with the simplicity goal).
また、徐々に新技術を配布して、ソースと目的地の間の経路のすべてのルータをアップグレードさせなければならないのを特に避けることができるのも望ましいです。 共通項情報が利用可能な状態でこの目標はいくらか不和です、すぐに新しいプロトコルをサポートする別のルータに隣接していないルータが他のそのようなルータの位置かアイデンティティを決定する方法を全く持っていないので(何も氾濫アルゴリズムのようなものが簡単さ目標と衝突するユニキャスト推進の上で実装されない場合)。
Katz Standards Track [Page 1] RFC 2113 Router Alert Option February 1997
キャッツStandardsはオプション1997年2月にRFC2113ルータ警戒を追跡します[1ページ]。
One obvious approach to leveraging unicast routing is to do hop-by- hop forwarding of the new protocol packets along the path toward the ultimate destination. Each system that implements the new protocol would be responsible for addressing the packet to the next system in the path that understood it. As noted above, however, it is difficult to know the next system implementing the protocol. The simple, degenerate case is to assume that every system along the path implements the protocol. This is a barrier to phased deployment of the new protocol, however.
ユニキャストルーティングを利用することへのある明白なアプローチは最終仕向地に向かった経路に沿った新しいプロトコルパケットの推進を近く跳ぶほど飛び越すことです。 新しいプロトコルを実装するそれぞれのシステムはそれを理解していた経路の次のシステムにパケットを扱うのに原因となるでしょう。 しかしながら、上で述べたように、プロトコルを実装する次のシステムを知るのは難しいです。 簡単で、堕落したケースは経路に沿ったあらゆるシステムがプロトコルを実装すると仮定することです。 しかしながら、これは新しいプロトコルの段階的な展開へのバリアです。
RSVP [1] finesses the problem by instead putting the address of the ultimate destination in the IP Destination Address field, and then asking that every RSVP router make a "small change in its ... forwarding path" to look for the specific RSVP packet type and pull such packets out of the mainline forwarding path, performing local processing on the packets before forwarding them on. This has the decided advantage of allowing automatic tunneling through routers that don't understand RSVP, since the packets will naturally flow toward the ultimate destination. However, the performance cost of making this Small Change may be unacceptable, since the mainline forwarding path of routers tends to be highly tuned--even the addition of a single instruction may incur penalties of hundreds of packets per second in performance.
特定のRSVPパケットタイプを探して、本線推進経路からそのようなパケットを取り出すために代わりにIP Destination Address分野に最終仕向地のアドレスを置いて、次に、あらゆるRSVPルータが「経路を進めることにおける…小銭」を作るように頼むことによって、RSVP[1]は問題を巧妙におこないます、それらを進める前にオンなパケットにローカル処理を実行して。 これには、RSVPを理解していないルータに自動トンネリングの通ることを許す明らかな利点があります、パケットが自然に最終仕向地に向かって流れるので。 しかしながら、このSmall Changeを作る性能費用は容認できないかもしれません、ルータの本線推進経路が、非常に調整される傾向があるので--ただ一つの指示の追加さえ性能で1秒あたり何百ものパケットの刑罰を被るかもしれません。
2.0 Router Alert Option
2.0 ルータ警戒オプション
The goal, then, is to provide a mechanism whereby routers can intercept packets not addressed to them directly, without incurring any significant performance penalty. This document defines a new IP option type, Router Alert, for this purpose.
目標は次に、ルータが直接それらに扱われなかったパケットを妨害できるメカニズムを提供することです、どんな重要なパフォーマンスに不利な条件も被らないで。 このドキュメントはこの目的のために新しいIPオプションタイプ、Router Alertを定義します。
The Router Alert option has the semantic "routers should examine this packet more closely". By including the Router Alert option in the IP header of its protocol message, RSVP can cause the message to be intercepted while causing little or no performance penalty on the forwarding of normal data packets.
Router Alertオプションには、意味があります。「ルータは、より密接にこのパケットを調べるべきです」。 プロトコルメッセージのIPヘッダーにRouter Alertオプションを含んでいることによって、RSVPはまず正常なデータ・パケットの推進でのパフォーマンスに不利な条件を引き起こしていない間に妨害されるべきメッセージを引き起こす場合があります。
Routers that support option processing in the fast path already demultiplex processing based on the option type field. If all option types are supported in the fast path, then the addition of another option type to process is unlikely to impact performance. If some option types are not supported in the fast path, this new option type will be unrecognized and cause packets carrying it to be kicked out into the slow path, so no change to the fast path is necessary, and no performance penalty will be incurred for regular data packets.
既に高速経路「反-マルチプレックス」でオプションが処理であるとサポートするオプションに基づいて処理されるルータが分野をタイプします。 すべてのオプションタイプが高速経路でサポートされるなら、処理する別のオプションタイプの追加は性能に影響を与えそうにはありません。 何人かのオプションタイプが高速経路でサポートされないと、この新しいオプションタイプは認識されていなくなるでしょう、そして、高速経路へのどんな変化も必要でないことで、遅い経路にけり出されるためにそれを運ぶ原因パケットを被りますが、どんなパフォーマンスに不利な条件もレギュラーのデータ・パケットのために被られないでしょう。
Katz Standards Track [Page 2] RFC 2113 Router Alert Option February 1997
キャッツStandardsはオプション1997年2月にRFC2113ルータ警戒を追跡します[2ページ]。
Routers that do not support option processing in the fast path will cause packets carrying this new option to be forwarded through the slow path, so no change to the fast path is necessary and no performance penalty will be incurred for regular data packets.
遅い経路を通して高速経路でオプションが処理であるとサポートしないルータでこの新しいオプションを運ぶパケットを進めるでしょう、そして、したがって、高速経路へのどんな変化も必要ではありません、そして、パフォーマンスに不利な条件は全くレギュラーのデータ・パケットのために被られないでしょう。
2.1 Syntax
2.1構文
The Router Alert option has the following format:
Router Alertオプションには、以下の形式があります:
+--------+--------+--------+--------+ |10010100|00000100| 2 octet value | +--------+--------+--------+--------+
+--------+--------+--------+--------+ |10010100|00000100| 2 八重奏値| +--------+--------+--------+--------+
Type: Copied flag: 1 (all fragments must carry the option) Option class: 0 (control) Option number: 20 (decimal)
以下をタイプしてください。 コピーされた旗: 1つ(すべての断片がオプションを運ばなければならない)のオプションのクラス: 0 (コントロール)オプション番号: 20 (小数)
Length: 4
長さ: 4
Value: A two octet code with the following values: 0 - Router shall examine packet 1-65535 - Reserved
値: 以下の値がある2八重奏コード: 0--ルータはパケット1-65535を調べるものとします--予約されます。
2.2 Semantics
2.2 意味論
Hosts shall ignore this option. Routers that do not recognize this option shall ignore it. Routers that recognize this option shall examine packets carrying it more closely (check the IP Protocol field, for example) to determine whether or not further processing is necessary. Unrecognized value fields shall be silently ignored.
ホストはこのオプションを無視するものとします。 このオプションを認識しないルータはそれを無視するものとします。 このオプションを認識するルータはさらなる処理が必要であるかどうか決定するために、より密接(例えば、IPプロトコル分野をチェックする)にそれを運ぶパケットを調べるものとします。 認識されていない値の分野は静かに無視されるものとします。
The semantics of other values in the Value field are for further study.
さらなる研究にはValue分野の他の値の意味論があります。
3.0 Impact on Other Protocols
3.0 他のプロトコルに関する影響
For this option to be effective, its use must be mandated in protocols that expect routers to perform significant processing on packets not directly addressed to them. Currently such protocols include RSVP [1] and IGMP [2].
このオプションが有効であるように、ルータが直接それらに扱われなかったパケットに重要な処理を実行すると予想するプロトコルで使用を強制しなければなりません。 現在の、そのようなプロトコルはRSVP[1]とIGMP[2]を含んでいます。
4.0 Security Considerations
4.0 セキュリティ問題
If the Router Alert option is not set and should be set, the behavior of the protocol using the Router Alert, e.g., RSVP or IGMPv2, will be adversely affected since the protocol relies on the use of the Router Alert option.
Router Alertオプションが設定されないで、設定されると、プロトコルがRouter Alertオプションの使用に依存するので、Router Alertを使用するプロトコルの振舞い(例えば、RSVPかIGMPv2)は、悪影響を受けるでしょう。
Katz Standards Track [Page 3] RFC 2113 Router Alert Option February 1997
キャッツStandardsはオプション1997年2月にRFC2113ルータ警戒を追跡します[3ページ]。
If the Router Alert option is set when it should not be set, it is likely that the flow will experience a performance penalty, as a packet whose Router Alert option is set will not go through the router's fastpath and will be processed in the router more slowly than if the option were not set.
それを設定するべきでないとき、Router Alertオプションを設定するなら、流れはパフォーマンスに不利な条件になりそうでしょう、Router Alertオプションが設定されるパケットがルータのfastpathを通らないで、ルータで、よりゆっくり処理されるときオプションが設定されなかったなら。
5.0 References
5.0の参照箇所
[1] Braden, B. (ed.), L. Zhang, D. Estrin, S. Herzog, S. Jamin, "Resource ReSerVation Protocol (RSVP)," work in progress, March 1996.
[1] ブレーデン、B.編(L.チャン)のD.Estrin、S.ハーツォグ、S.ジャマン、「資源予約プロトコル(RSVP)」は進行中(1996年3月)で働いています。
[2] Fenner, W., "Internet Group Management Protocol, Version 2 (IGMPv2)," work in progress, October 1996.
[2] フェナー、W.、「インターネット集団経営プロトコル、バージョン2(IGMPv2)」が進歩、1996年10月に働いています。
Author's Address
作者のアドレス
Dave Katz cisco Systems 170 W. Tasman Dr. San Jose, CA 95134-1706 USA
デーヴキャッツコクチマスSystems170W.タスマンサンノゼ博士(カリフォルニア)95134-1706米国
Phone: +1 408 526 8284 Email: dkatz@cisco.com
以下に電話をしてください。 +1 8284年の408 526メール: dkatz@cisco.com
Katz Standards Track [Page 4]
キャッツ標準化過程[4ページ]
一覧
スポンサーリンク