Network Working Group D. Katz Request for Comments: 2113 cisco Systems Category: Standards Track February 1997 IP Router Alert Option ｜IP Router Alert オプション Status of this 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. ｜このドキュメントはインターネットコミュニティに対してインターネット ｜スタンダードトラックプロトコル(/インターネット標準化過程プロトコル) ｜を規定し、改善のための議論や提案を要求するものである。このプロトコル ｜の状態と標準化の状況については、"Internet Official Protocol Standards" ｜(STD 1) の最新版を参照のこと。このメモの配布に制限はない。 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オプションについて記述する。これは、宛先に向けて送られるが、 ｜そのパスの途中のルータで、比較的複雑な処理が要求される新しいプロトコル ｜において有効であるが、これだけに限定されない。 1.0 Introduction ｜はじめに 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). ｜これの短所は、新しい機能は、宛先に向かう次のホップ (Hop)との、ユニ ｜キャストルーティングの中での最小の共通要素にのみ頼ることができるこ ｜とである。より豊富で詳細な情報の (例えばリンク状態データベースのよ ｜うな)存在について、それを扱うようなものを引き受けることはできない。 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). ｜また、新しい技術は徐々に展開できることが望ましく、特に、送信元と ｜宛先との間のパスの中の全てのルータをアップグレードさせなければ ｜ならないといったことは避けるべきである。この目的は新しいプロトコ ｜ルをサポートする他のルータと、直接に隣接していないルータは、その ｜場所を特定したり、他の同じ(機能を持つ)ルータを識別したりする手段 ｜を持たないので、利用可能な最小の共通要素の情報を用いるといったこ ｜とと相反するものである。 (ユニキャスト転送になんらかのフローディ ｜ングアルゴリズムを実装することなく --これは単純に目的と矛盾する)。 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[1]は、IP 宛先フィールドに、代りに、最終的な宛先のアドレスを ｜挿入することによって、この問題をうまく切りぬけていて、全てのRSVP ｜ルータで、特定の RSVP パケットタイプを探して、主要回線の転送パス ｜からそのようなパケットを取り出して、それから、それを転送する前に ｜ローカルで処理して、といった「少しの変更を...転送パスに」求める。 ｜これは明らかな長所を持つ、すなわち RSVP を理解しないルータでは、 ｜パケットは自然に最終的な宛先に向かって流れるので、自動的にトンネ ｜リングが可能になる。しかしながら、この小さな変更により作りだされ ｜る性能へのコストは、受け入れられないかもしれない、なぜなら、ルー ｜タの主要回線の転送パスは、より高く調整されていく傾向にあり 1つの ｜命令の追加でさえ、1秒あたり数百パケットの性能低下を受けさせる。 2.0 Router Alert Option ｜Router Alert オプション 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. 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 ｜書式 The Router Alert option has the following format: ｜Router Alert オプションは以下のフォーマットを持つ： +--------+--------+--------+--------+ |10010100|00000100| 2 octet value | +--------+--------+--------+--------+ Type: ｜種別 Copied flag: 1 (all fragments must carry the option) ｜コピーフラグ： 1 (全てのフラグメントでこのオプションを運ぶ) Option class: 0 (control) ｜オプションクラス： 0 (制御) Option number: 20 (decimal) ｜オプションナンバ：20 (10進) Length: 4 ｜長さ：4 Value: A two octet code with the following values: ｜値：以下の値を持つ2オクテットコード 0 - Router shall examine packet ｜0 - ルータはパケットを調べるべき 1-65535 - Reserved ｜1-65535 - 予約 2.2 Semantics ｜意味 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プロトコルフィールドを) 調べる。認識されない Valueフィールドは ｜黙って無視される。 The semantics of other values in the Value field are for further study. ｜Value フィールドの他の値の意味については、将来の課題である。 3.0 Impact on Other Protocols ｜他のプロトコルでの影響 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 ｜セキュリティに関する考察 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 を使用するプロトコル、例えば RSVP 又は IGMPv2 の振舞い ｜は、 プトロコルが Router Alert オプションの使用をあてにしているので ｜悪い影響を及ぼす。 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 オプションの設定されたパケットはルータの高速パスを通過 ｜しないので、オプションが設定されていない時よりも、 ルータ内で、より ｜ゆっくり処理されるので、そのフローは性能の低下を経験するであろう。 5.0 References ｜参考 [1] Braden, B. (ed.), L. Zhang, D. Estrin, S. Herzog, S. Jamin, "Resource ReSerVation Protocol (RSVP)," work in progress, March 1996. [2] Fenner, W., "Internet Group Management Protocol, Version 2 (IGMPv2)," work in progress, October 1996. Author's Address ｜著者のアドレス Dave Katz cisco Systems 170 W. Tasman Dr. San Jose, CA 95134-1706 USA Phone: +1 408 526 8284 Email: dkatz@cisco.com -- 訳: O.K.U. ( oku@olive.plala.or.jp ) ( http://kotekote.zatunen.com/rfc/ ) 注: 翻訳内容に関していかなる保障もいたしません。