RFC1622 日本語訳
1622 Pip Header Processing. P. Francis. May 1994. (Format: TXT=34837 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group P. Francis Request for Comments: 1622 NTT Category: Informational May 1994
コメントを求めるワーキンググループP.フランシスの要求をネットワークでつないでください: 1622年のNTTカテゴリ: 情報の1994年5月
Pip Header Processing
種のヘッダー処理
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Preamble
序文
During 1992 and 1993, the Pip internet protocol, developed at Bellcore, was one of the candidate replacments for IP. In mid 1993, Pip was merged with another candidate, the Simple Internet Protocol (SIP), creating SIPP (SIP Plus). While the major aspects of Pip-- particularly its distinction of identifier from address, and its use of the source route mechanism to achieve rich routing capabilities-- were preserved, many of the ideas in Pip were not. The purpose of this RFC and the companion RFC "Pip Near-term Architecture" are to record the ideas (good and bad) of Pip.
1992と1993の間、Bellcoreで開発されたPipインターネットプロトコルはIPの候補replacmentsの1つでした。 1993年中頃に、SIPP(SIP Plus)を作成して、Pipは別の候補、Simpleインターネットプロトコル(SIP)に合併されました。 Pipの主要な局面(特にアドレスからの識別子の区別、および豊かなルーティング能力を達成する送信元経路メカニズムのその使用)は保持されましたが、Pipの考えの多くは保持されたというわけではありません。 このRFCの目的と仲間RFC「種の短期間構造」はPipにおける(良く悪い)の考えを記録することです。
The remainder of this document is taken verbatem from the Pip draft memo of the same title that existed when the Pip project ended. As such, any text that indicates that Pip is an intended replacement for IP should be ignored.
このドキュメントの残りはPipプロジェクトが終わったとき存在した同じタイトルに関するPip草稿メモからの取られたverbatemです。 そういうものとして、PipがIPへの意図している交換品であることを示すどんなテキストも無視されるべきです。
Abstract
要約
Pip is an internet protocol intended as the replacement for IP version 4. Pip is a general purpose internet protocol, designed to handle all forseeable internet protocol requirements. This specification defines the Pip header processing for Routers and Hosts.
種はIPバージョン4との交換として意図するインターネットプロトコルです。 種はすべてのforseeableインターネットプロトコル要件を扱うように設計された汎用のインターネットプロトコルです。 この仕様はRoutersとHostsのためにPipヘッダー処理を定義します。
Acknowledgements
承認
I want to individually acknowledge Rob Coltun, Steve Deering, Ramesh Govindan, Joel Halpern, John Ioannidis, Chris Petrilli, Bob Smart, and Zheng Wang. I want also to acknowledge the many people from the Pip working group who have participated in developing Pip. Finally, I want to acknowledge the SIP protocol (or, more accurately, the people behind the SIP protocol) for providing certain good ideas.
個別にロブColtun、スティーブ・デアリング、Ramesh Govindan、ジョエル・アルペルン、ジョンIoannidis、クリスPetrilli、ボブSmart、およびツェンワングを承認したいと思います。 また、Pipワーキンググループからの展開しているPipに参加した多くの人々を承認したいと思います。 最終的に、ある名案を提供するために、SIPプロトコル(より正確に、SIPの後ろの人々は議定書を作る)を承認したいと思います。
Francis [Page 1] RFC 1622 Pip Header Processing May 1994
1994年5月に処理するフランシス[1ページ]RFC1622種のヘッダー
Conventions
コンベンション
All functions in this specification are mandatory.
この仕様によるすべての機能が義務的です。
1. Introduction
1. 序論
Pip is an internet protocol intended as the replacement for IP version 4. Pip is a general purpose internet protocol, designed to handle all forseeable internet protocol requirements. This specification defines the Pip header processing for Routers and Hosts.
種はIPバージョン4との交換として意図するインターネットプロトコルです。 種はすべてのforseeableインターネットプロトコル要件を扱うように設計された汎用のインターネットプロトコルです。 この仕様はRoutersとHostsのためにPipヘッダー処理を定義します。
The design of Pip is fundamentally different from that of previous internetwork protocols. Pip is designed to be as general as possible, but without significantly compromising performance. Because of Pip's generality, it can handle forseeable routing and addressing requirements. It is hoped that it will be able to handle most if not all future routing and addressing requirements.
Pipのデザインは前のインターネットワークプロトコルのものと基本的に異なっています。 種ができるだけ一般的になるように設計されていますが、かなり評判を落とすような性能なしであります。 Pipの一般性のために、それはforseeableルーティングとアドレシング要件を扱うことができます。 大部分かすべての今後のルーティングとアドレシング要件を扱うことができることが望まれています。
There are many detailed aspects of Pip that provide this generality that are not discussed here. It is useful, however, to mention one general aspect. That is, Pip strives to remove as much "functional semantics" from the base specification as possible. Pip defines a packet header and forwarding rules that can include many different functional semantics (that is, routing, addressing, and flow paradigms). Therefore, the reader may often find him or herself asking "But how do you do foo with Pip?" The answer to this sort of question belongs in companion documents to the basic Pip spec.
ここで議論しないこの一般性を提供するPipの多くの詳細な局面があります。 しかしながら、1つの一般的な局面について言及するのは役に立ちます。 すなわち、Pipは、基礎仕様からのできるだけ多くの「機能的な意味論」を取り除くように努力します。 種は多くの異なった機能的な意味論(すなわち、ルーティング、アドレシング、および流れパラダイム)を含むことができるパケットのヘッダーと推進規則を定義します。 したがって、読者は、しばしば彼か自分が「しかし、あなたはPipと共にfooをどのようにしますか?」を尋ねているのを見つけるかもしれません。 基本のPip仕様への仲間ドキュメントにはこの種類の質問の答えがあります。
Pip can be thought of as a mechanism for triggering actions in hosts and routers, just as a machine language can be thought of as a mechanism for triggering actions in CPUs. The machine language has no functional semantics outside of the specific actions it triggers (move this register, write that memory location, etc.). But, the machine language is a very powerful tool upon which functional semantics are built. Likewise, Pip is a powerful tool upon which routing, addressing, and flow functions can be built.
ホストとルータにおける動作の引き金となるためのメカニズムとして種を考えることができます、ちょうどCPUで動作の引き金となるためのメカニズムとして機械語を考えることができるように。 機械語はそれが引き金となる特定の動作の外にどんな機能的な意味論も持っていません(このレジスタを動かしてください、そして、その記憶域などを書いてください)。 しかし、機械語は機能的な意味論がどれであるかに関して組立てられた非常に強力なツールです。 同様に、Pipはルーティング、アドレシング、および流れ機能を築き上げることができる強力な道具です。
Francis [Page 2] RFC 1622 Pip Header Processing May 1994
1994年5月に処理するフランシス[2ページ]RFC1622種のヘッダー
2. Pip Specification
2. 種の仕様
The Pip header is partitioned into three parts, the Initial Part, the Transit Part, and the Options Part.
Pipヘッダーは3つの部品、Initial Part、Transit Part、およびOptions Partに仕切られます。
+===========================+
| Initial Part |
+===========================+
| Transit Part |
+===========================+
| Options Part |
+===========================+
| |
| Payload |
| |
+===========================+ | 初期の部分| +===========================+ | トランジット部分| +===========================+ | オプション一部| +===========================+ | | | 有効搭載量| | |
Each part falls on a 32-bit boundary (as indicated by the double lines shown), and the Transit Part falls on a 64 bit boundary.
各部分は32ビットの境界の責任となります、そして、(見せられた二重線によって示されるように)Transit Partは64ビット境界に落ちます。
The concept of tunneling in an integral part of Pip. Pip achieves tunneling by encapsulating the Transit Part of the Pip header in another Transit Part. Therefore, when tunneling, there is one Transit Part for each (nested) tunnel:
Pipの不可欠の部分でトンネルを堀る概念。 種は、別のTransit PartでPipヘッダーのTransit Partを要約することによって、トンネリングを達成します。 したがって、トンネルを堀るとき、それぞれの(入れ子にされる)のトンネルあたり1Transit Partがあります:
+===========================+
| Initial Part |
+===========================+
| Transit Part |
+===========================+
| Transit Part |
+===========================+
.
.
.
+===========================+
| Transit Part |
+===========================+
| Options Part |
+===========================+
+===========================+ | 初期の部分| +===========================+ | トランジット部分| +===========================+ | トランジット部分| +===========================+ . . . +===========================+ | トランジット部分| +===========================+ | オプション一部| +===========================+
Because each Transit Part has only what is necessary for router forwarding and handling, this method of tunneling is reasonably efficient in terms of packet size.
各Transit Partにはルータ推進と取り扱いに必要なものしかないので、トンネリングのこの方法はパケットサイズでかなり効率的です。
Francis [Page 3] RFC 1622 Pip Header Processing May 1994
1994年5月に処理するフランシス[3ページ]RFC1622種のヘッダー
2.1 Initial Part
2.1 初期の部分
The Initial Part is formatted as shown in Figure 1.
Initial Partは図1に示されるようにフォーマットされます。
length, in bits
+===========================+
| Version Number = 8 | 4
+---------------------------+
| Sub-Version | 4
+---------------------------+
| Options Offset | 8
+---------------------------+
| Options Contents | 8
+---------------------------+
| Options Present | 8
+===========================+
| Packet SubID | 16
+---------------------------+
| Protocol | 16
+===========================+
| Dest ID | 64
+===========================+
| Source ID | 64
+===========================+
| Payload Length | 32
+===========================+
| Host Version | 8
+---------------------------+
| Payload Offset | 8
+---------------------------+
| Hop Count | 16
+===========================+
ビット+の長さ===========================+ | バージョン番号=8| 4 +---------------------------+ | サブバージョン| 4 +---------------------------+ | オプションは相殺されます。| 8 +---------------------------+ | オプションコンテンツ| 8 +---------------------------+ | オプションプレゼント| 8 +===========================+ | パケットSubID| 16 +---------------------------+ | プロトコル| 16 +===========================+ | Dest ID| 64 +===========================+ | ソースID| 64 +===========================+ | ペイロード長| 32 +===========================+ | ホストバージョン| 8 +---------------------------+ | 有効搭載量は相殺されました。| 8 +---------------------------+ | ホップカウント| 16 +===========================+
Figure 1: Initial Part
図1: 初期の部分
An explanation of each field follows.
それぞれの分野に関する説明は続きます。
2.1.1 Version Numbers
2.1.1 バージョン番号
The first octet is divided into two 4-bit fields, the Version and the Sub-Version. The Version field is set to be 8, and is meant to be version 8 of IP. (As of this writing, this is an experimental number assigned for development of Pip.) Thus, all encapsulation schemes defined for IP can work for Pip as well.
最初の八重奏は2つの4ビットの分野、バージョン、およびSub-バージョンに分割されます。 バージョン分野は、8であるように設定されて、IPのバージョン8であることが意味されます。 (この書くこと現在、これはPipの開発のために割り当てられた実験数です。) したがって、IPのために定義されたすべてのカプセル化計画がまた、Pipにうまくいくことができます。
As long as the Version field is 8, the Initial Part and Options Part of the Pip Header is as specified in this standard. (In other words, the Sub-Version field refers only to the Transit Part.)
バージョン分野が8である限り、Pip HeaderのInitial PartとOptions Partがこの規格で指定されるようにあります。 (言い換えれば、Sub-バージョン分野はTransit Partだけについて言及します。)
Francis [Page 4] RFC 1622 Pip Header Processing May 1994
1994年5月に処理するフランシス[4ページ]RFC1622種のヘッダー
By doing this, we allow the Transit Part of the Pip Header to change completely without necessarily requiring a host to understand the new Transit Part. If a host receives a Pip header with a Version number of 8 and an unknown Sub-version number, the host does not try to parse the Transit Part at all, rather it processes only the Initial Part and the Options Part. (By using the Pip Header Protocol to format Pip Headers, a host can be made to formulate the right Transit Part, even though the host doesn't understand the semantics of the Transit Part. This allows radical migration of the Transit Part while potentially not requiring changes to hosts.)
そうすれば、必ずホストが新しいTransit Partを理解するのが必要であるというわけではなくて、私たちはPip HeaderのTransit Partをすっかり変わらせます。 ホストが8のバージョン番号と未知のSub-バージョン番号でPipヘッダーを受け取るなら、ホストは全くTransit Partを分析しようとしないで、むしろそれはInitial PartとOptions Partだけを処理します。 (形式Pip HeadersにPip Headerプロトコルを使用することによって、ホストに右のTransit Partを定式化させることができます、ホストはTransit Partの意味論を理解していませんが。 これは潜在的にホストへの変化を必要としていない間、Transit Partの急進的な移動を許します。)
If a host or a router receives a packet with an unknown Version number, the packet is silently discarded.
ホストかルータが未知のバージョン番号でパケットを受けるなら、パケットは静かに捨てられます。
The Sub-Version field is set to the value 0 for the version of Pip defined in this specification. As long as the Sub-Version number is 0, the Transit Part is as specified in this standard. Any packet received by a router with a Version number of 8 and an unknown Sub- Version number is silently discarded.
Sub-バージョン分野はこの仕様に基づき定義されたPipのバージョンのために値0に設定されます。 Sub-バージョン番号が0である限り、Transit Partがこの規格で指定されるようにあります。 ルータによって8のバージョン番号と未知のSubバージョン番号で受け取られたどんなパケットも静かに捨てられます。
2.1.2 Options Offset
2.1.2 オプションは相殺されます。
The Options Offset indicates the position of the Options Part. The unit of measure of the Options Offset is 32-bit words, counting the first word of the Pip Header as word 0.
Options OffsetはOptions Partの位置を示します。 Options Offsetの測定の単位は32ビットの単語です、Pip Headerの最初の単語をWord0にみなして。
2.1.3 Options Contents
2.1.3 オプションコンテンツ
This field indicates how the Options Present field should be interpreted. Each bit of the Options field indicates if each of up to eight options is present in the Options Part. The Options Contents field indirectly indicates which option each bit of the Options Present field refers to. We say indirectly because the mapping referred to by the Options Contents field is stored locally. In other words, without additional information (the mapping), it is not possible to examine the Options Contents field and know what option each bit of the Options Present field refers to.
この分野はOptions Present分野がどう解釈されるべきであるかを示します。 Options分野の各ビットは、Options Partでそれぞれの最大8つのオプションが存在しているかどうかを示します。 Options Contents分野は、Options Present分野の各ビットがどのオプションを示すかを間接的に示します。 間接的にOptions Contents分野によって示されたマッピングが局所的に格納されるので、私たちは言います。 言い換えれば、追加情報(マッピング)がなければ、Options Contents分野を調べて、Options Present分野の各ビットがどんなオプションを示すかを知るのは可能ではありません。
Any of 256 possible Options Contents values can be active at a given time. (Note that the means by which the meaning of the Options Contents values are assigned and conveyed to routers and hosts is outside the scope of this specification.)
256の可能なOptions Contents値のいずれも一時にアクティブである場合があります。 (この仕様の範囲の外にOptions Contents値の意味がどれであるかによって割り当てられて、ルータとホストに伝えられた手段があることに注意してください。)
Francis [Page 5] RFC 1622 Pip Header Processing May 1994
1994年5月に処理するフランシス[5ページ]RFC1622種のヘッダー
2.1.4 Options Present
2.1.4 オプションプレゼント
This field indicates which of the Options indicated by the Options Contents field are actually present in the Options Part. Each bit of this field refers to a single option type. The mapping of each bit to its' option type is determined by the Options Contents field.
この分野は、Options PartでOptions Contents分野によって示されたOptionsのどれが実際に存在しているかを示します。 この分野の各ビットは単独のオプションタイプについて言及します。 ''オプションタイプへのそれぞれのビットのマッピングはOptions Contents分野のそばで決定しています。
For instance, assume that the Options Contents field indicates that bit 0 of the Options Present field refers to the PDN Address option, that bit 1 of the Options Present field refers to the foo option, and that bit 2 of the Options Present field refers to the Fragmentation option. (As of this writing, there is only one option. Until there are more than eight options, there is no need to define more than one Options Contents values.)
例えば、Options Contents分野が、Options Present分野のビット0がPDN Addressオプションを示して、Options Present分野のビット1がfooオプションを示して、Options Present分野のビット2がFragmentationオプションを示すのを示すと仮定してください。 (この書くこと現在、1つのオプションしかありません。 8つ以上のオプションがあるまで、1つ以上のOptions Contents値を定義する必要は全くありません。)
In this case, a value of 101 in the Options Present field indicates that the PDN Address and Fragmentation options are present in the Options Part, and that the foo option is not present.
この場合、Options Present分野の101の値はPDN AddressとFragmentationオプションがOptions Partに存在していて、fooオプションが存在していないのを示します。
Note that an Options Present value of 0 indicates that there are no options present, regardless of the value of the Options Contents field. Note also that no more than 8 options, not including the default first option (the Options Descriptor), can be present in any Options Part.
0のOptions Present値が、Options Contents分野の値にかかわらず現在のどんなオプションもないのを示すことに注意してください。 また、デフォルト第1の選択(Options Descriptor)を含まない8つ未満のオプションがどんなOptions Partにも存在している場合があることに注意してください。
The Options Contents/Options Present method of processing options allows for efficient processing of options. First, a router can ignore any options that may be present but that do not impact it (for instance, a router not attached to a PDN need not consider the PDN Address option). Second, the desired option can be very quickly retrieved, because the first option, the Options Descriptor option, contains the offset of each of the up to eight options indicated by the Options Present field.
処理オプションのOptions Contents/オプションPresent方法はオプションの効率的な処理を考慮します。 まず最初に、ルータは存在しているかもしれませんが、それに影響を与えないどんなオプションも無視できます(例えば、PDNに付けられなかったルータは、PDN Addressがオプションであると考える必要はありません)。 2番目に、必要なオプションはすぐに非常に検索できます、第1の選択(Options Descriptorオプション)がOptions Present分野によって示されたそれぞれの最大8つのオプションのオフセットを含んでいるので。
2.1.5 Packet SubID
2.1.5 パケットSubID
This field is used by Pip hosts to correctly associate received PCMP messages with local control blocks. This is necessary because the semantics of the Transit Part can change while a packet is in transit. Therefore, a router sending a PCMP message cannot necessarily provide all of the information needed by the Pip host to correctly identify the context of the received message (that is, which "packet flow" it is identified with).
この分野は、正しく受信されたPCMPメッセージを現場制御ブロックに関連づけるのにPipホストによって使用されます。 パケットがトランジット中である間、Transit Partの意味論が変化できるので、これが必要です。 したがって、PCMPメッセージを送るルータは必ず正しく受信されたメッセージの文脈を特定する(すなわち、それはどの「パケット流動」と同一視されていますか)ためにPipホストによって必要とされた情報のすべてを提供できるというわけではありません。
A PCMP message uses the Protocol, Source ID, Dest ID, and Packet SubID to define the PCMP messages context. It is not sufficient to use just Protocol, Source ID, and Dest ID, because two hosts running the same protocol between them may have multiple "flows", for
PCMPメッセージは、PCMPメッセージ文脈を定義するのにプロトコル、Source Dest ID(ID)、およびPacket SubIDを使用します。 まさしくプロトコル、Source ID、およびDest IDを使用するのは十分ではありません、彼らの間の同じプロトコルを走らせている2人のホストが複数の「流れ」を持っているかもしれないので
Francis [Page 6] RFC 1622 Pip Header Processing May 1994
1994年5月に処理するフランシス[6ページ]RFC1622種のヘッダー
instance, a data flow, a video flow, and an audio flow in the case of multi-media. Each flow may have a different Transit Part, and take different paths. Therefore, the Packet SubID field is needed to further differentiate.
例、データフロー、ビデオ流動、およびオーディオはマルチメディアの場合で流れます。 各流れは、異なったTransit Partを持って、異なった経路を取るかもしれません。 したがって、Packet SubID分野が、さらに分化するのに必要です。
2.1.6 Protocol
2.1.6 プロトコル
Indicates the protocol header found in the payload. The values for this field are the same as those used for IPv4.
ペイロードで見つけられたプロトコルヘッダーを示します。 この分野への値はIPv4に使用されるものと同じです。
2.1.7 Dest ID
2.1.7 Dest ID
The Dest ID field indicates the Pip ID of the final recipient of the Pip packet. This field is examined by both hosts and routers.
Dest ID分野はPipパケットの最終的な受取人のPip IDを示します。 この分野はホストとルータの両方によって調べられます。
When a Pip System processes the Routing Directive (RD), it may determine that it needs to examine the Dest ID for further processing. This may happen both when a host or router receives a Pip packet destined for itself, or when a router receives a packet that should be forwarded based on Dest ID (as indicated by the RD).
Pip Systemがルート設定Directive(RD)を処理するとき、それは、さらなる処理がないかどうかDest IDを調べるのが必要であることを決定するかもしれません。 ホストかルータがともにそれ自体のために運命づけられたPipパケットを受けるか、またはルータがDest IDに基づいて進められるべきであるパケットを受けるとき(RDによって示されるように)、これは起こるかもしれません。
When a Pip system determines at forwarding time that a packet is destined for itself, it checks the Dest ID to verify if that packet is destined for it. If the complete Dest ID matches one of its own Pip IDs, then the packet is for it, and is passed to the layer indicated by the Protocol field (in the Host Part). (The Pip system may of course wish to check a security option before passing a packet to an upper layer.)
Pipシステムが、推進時にパケットがそれ自体のために運命づけられていることを決定すると、それは、そのパケットがそれのために運命づけられているかどうか確かめるためにDest IDをチェックします。 完全なDest IDがそれ自身のPip IDの1つに合っているなら、パケットは、それのためにあって、プロトコル分野(Host Partの)によって示された層に通過されます。 (上側の層にパケットを通過する前に、Pipシステムはもちろんセキュリティオプションをチェックしたがっているかもしれません。)
If the complete Dest ID field does not match one of its own IDs, then an ID/RD Mismatch PCMP message is sent to the source of the packet, as indicated by the Source ID and potentially source information in the RD. The purpose of this message is to flush the ID to RD binding in the source Pip host.
完全なDest ID分野がそれ自身のIDの1つに合っていないなら、ID/RD Mismatch PCMPメッセージをパケットの源に送ります、Source IDと潜在的にRDのソース情報によって示されるように。 このメッセージの目的はソースPipホストで付くRDにIDを洗い流すことです。
2.1.8 Source ID
2.1.8 ソースID
This is the Pip ID of the source of the packet. It is passed to upper layers for the purposes of identifying the context for the packet.
これはパケットの源のPip IDです。 それはパケットのための文脈を特定する目的のために上側の層に通過されます。
2.1.9 Payload Length
2.1.9 ペイロード長
The Payload Length gives the length of the Pip packet payload in units of 8 bits. The Payload Length does not include the length of the Pip header.
有効搭載量Lengthは8ビットの単位のPipパケットペイロードの長さを与えます。 有効搭載量LengthはPipヘッダーの長さを含んでいません。
Francis [Page 7] RFC 1622 Pip Header Processing May 1994
1994年5月に処理するフランシス[7ページ]RFC1622種のヘッダー
2.1.10 Host Version
2.1.10 ホストバージョン
The Host Version field indicates what "version" of Pip software the sending host has implemented. This is to allow a host to inform a router which ancillary protocols/messages the host is able to accept. It is envisioned that over time, new host functions will be developed. Different hosts will install these new functions at different times. This field allows routers to know what functions the host can and cannot handle.
Hostバージョン分野は、送付ホストがPipソフトウェアのどんな「バージョン」を実行したかを示します。 これで、ホストは、ホストがどの付属のプロトコル/メッセージを受け入れることができるかをルータに知らせることになっていることができます。 それは思い描かれます。時間がたつにつれて、新しいホスト機能は開発されるでしょう。 異なったホストはこれらの新しい機能をいろいろな時間にインストールするでしょう。 この分野は、ホストがどんな機能は扱って、扱うことができないかを知るためにルータを許容します。
2.1.11 Payload Offset
2.1.11 有効搭載量は相殺されました。
The Payload Offset indicates the position of the Payload Part. The unit of measure of the Payload Offset is 32-bit words, counting the first word of the Pip Header as word 0.
有効搭載量Offsetは有効搭載量Partの位置を示します。 有効搭載量Offsetの測定の単位は32ビットの単語です、Pip Headerの最初の単語をWord0にみなして。
If a Pip system encapsulates a Transit Part in another Transit Part, then the Payload Offset is increased by the length of the new Transit Part.
Pipシステムが別のTransit PartでTransit Partを要約するなら、有効搭載量Offsetは新しいTransit Partの長さによって増加させられます。
2.1.12 Hop Count
2.1.12 ホップカウント
The Hop Count is decremented by every router that forwards the Pip packet. If a system receives a Pip header with a Hop Count equal to 0, and is not the recipient of the packet, then the packet is discarded and a PCMP Destination Unreachable is routed to the system indicated by the Routing Directive. (In other words, a host can legally receive a Transit Part with a Hop Count of 0, and indeed a host doesn't look at the Hop Count field upon reception.)
Hop CountはPipパケットを進めるあらゆるルータで減少します。 システムが0と等しいHop Countと共にPipヘッダーを受けて、パケットの受取人でないなら、パケットは捨てられます、そして、PCMP Destination Unreachableはルート設定Directiveによって示されたシステムに発送されます。 (言い換えれば、ホストは0のHop Countと共にTransit Partを法的に受け取ることができて、本当に、ホストはレセプションのHop Count分野を見ません。)
Francis [Page 8] RFC 1622 Pip Header Processing May 1994
1994年5月に処理するフランシス[8ページ]RFC1622種のヘッダー
2.2 Transit Part
2.2 トランジット部分
The Transit Part is formatted as shown in Figure 2.
Transit Partは図2に示されるようにフォーマットされます。
length, in bits
+===========================+
| Reserved | 16
+---------------------------+
| Transit Part Offset | 8
+---------------------------+
| HD Contents | 8
+===========================+
| Handling Directive (HD) | 32
---------------+===========================+
^ | FTIF Offset | 8
| +---------------------------+
| | RC Contents | 8
| +---------------------------+
| | Routing Context (RC) | 16
Routing +===========================+
| FTIF 1 | 16
Directive +---------------------------+
| | FTIF 2 | 16
| +---------------------------+
| .
| .
| .
| +---------------------------+
| | FTIF N | 16
| +---------------------------+
v | Padding | Variable
---------------+===========================+
ビット+の長さ===========================+ | 予約されます。| 16 +---------------------------+ | トランジット部分は相殺されました。| 8 +---------------------------+ | HDコンテンツ| 8 +===========================+ | 取り扱い指示(HD)| 32 ---------------+===========================+ ^ | FTIFは相殺します。| 8 | +---------------------------+ | | RCコンテンツ| 8 | +---------------------------+ | | ルート設定文脈(RC)| 16 ルート設定+===========================+ | FTIF1| 16 指示+---------------------------+ | | FTIF2| 16 | +---------------------------+ | . | . | . | +---------------------------+ | | FTIF N| 16 | +---------------------------+ v| 詰め物| 変数---------------+===========================+
Figure 2: Transit Part
図2: トランジット部分
An explanation of each field follows.
それぞれの分野に関する説明は続きます。
2.2.1 Transit Part Offset
2.2.1 トランジット部分は相殺されました。
This field gives the position of the first word of the next Transit Part. The unit of measure of the Transit Part Offset is 32-bit words, counting the first word of the current Transit Part as word 0. If there is no next Transit Part, then this field is written as all 0's.
この分野は次のTransit Partの最初の単語の位置を与えます。 Transit Part Offsetの測定の単位は32ビットの単語です、Word0として現在のTransit Partの最初の単語を数えて。 いいえ、次のTransit Partがあれば、この分野はすべての0として書かれます。
Francis [Page 9] RFC 1622 Pip Header Processing May 1994
1994年5月に処理するフランシス[9ページ]RFC1622種のヘッダー
2.2.2 HD Contents
2.2.2 HDコンテンツ
The HD Contents field indicates how the Handling Directive (HD) field should be interpreted. The HD field is divided into multiple fields, each representing a different handling function. Each individual field in the HD is called an HD Unit (HDU). The Options Contents field indirectly indicates which HDUs are in the HD field, and where they are. We say indirectly because the mapping referred to by the HD Contents field is stored locally. In other words, without additional information (the mapping), it is not possible to examine the HD Contents field and know what the HDU locations are.
HD Contents分野はHandling Directive(HD)分野がどう解釈されるべきであるかを示します。 それぞれ異なった取り扱い機能を表して、HD分野は複数の分野に分割されます。 HDのそれぞれの個々の分野はHD Unit(HDU)と呼ばれます。 Options Contents分野はどのHDUsがHD分野にあるか、そして、彼らがどこにいるかを間接的に示します。 間接的にHD Contents分野によって示されたマッピングが局所的に格納されるので、私たちは言います。 言い換えれば、追加情報(マッピング)がなければ、HD Contents分野を調べて、HDU位置が何であるかを知るのは可能ではありません。
Any of 256 possible HD Contents values can be active at a given time. (Note that the means by which the meaning of the HD Contents values are assigned and conveyed to routers and hosts is outside the scope of this specification.)
256の可能なHD Contents値のいずれも一時にアクティブである場合があります。 (この仕様の範囲の外にHD Contents値の意味がどれであるかによって割り当てられて、ルータとホストに伝えられた手段があることに注意してください。)
2.2.3 Handling Directive (HD)
2.2.3 取り扱い指示(HD)
The HD is a general purpose field used for the purpose of triggering special packet handling by a Pip system. The HD field does not influence a Pip router's next hop choice for a Pip packet, nor does it influence a Pip host's determination as to whether the Pip packet is destined for it. Examples of special packet handling would be "low priority queueing", or "high priority discard", etc. (Note that the Transit Options also influence "handling", in the sense that handling is essentially defined here to mean "anything that is not routing. The HD field, though, is intended for the most common types of handling--handling that is expected to be in a significant percentage of packets.)
HDはPipシステムで特別なパケット取り扱いの引き金となる目的に使用される汎用の分野です。 HD分野はPipパケットのためにPipルータの次のホップ選択に影響を及ぼしません、そして、Pipパケットがそれのために運命づけられているかどうかに関してそれはPipホストの決断に影響を及ぼしません。 特別なパケット取り扱いに関する例は、「低い優先権待ち行列」、または「高い優先権破棄」でしょうなど。 (また、Transit Optionsが取り扱いが「掘られていないものは何でも」を意味するためにここで本質的には定義されるという意味で「取り扱い」に影響を及ぼすことに注意してください。 もっとも、HD分野は最も一般的なタイプの取り扱いのために意図します--かなりの割合のパケットにあると予想される取り扱い。)
Both hosts and routers use the HD field. (Hosts may make use of the HD field for packet handling for both incoming and outgoing packets.)
ホストとルータの両方がHD分野を使用します。 (ホストは両方の送受信のパケットのためのパケット取り扱いにHD分野を利用するかもしれません。)
There is a complete distinction between the syntax and the semantics of the HD field. (This can be contrasted with, for instance, IP, which couples the semantics and syntax of the TOS bits. That is, the IP specification itself determines, to a first degree, how the TOS bits are interpreted.) Each Pip system can modify the semantic meaning of the HD, for instance, by increasing or decreasing the queueing priority of a packet. This is called packet tagging.
HD分野の構文と意味論の間には、完全な区別があります。 (例えば、IPに対してこれを対照できます。(それは、TOSビットの意味論と構文を結合します)。 すなわち、IP仕様自体は、TOSビットがどのように解釈されるかを第1度決定します。) 例えば、それぞれのPipシステムは、パケットの待ち行列優先権を増加するか、または減少させることによって、HDの意味意味を変更できます。 これはパケットタグ付けと呼ばれます。
From an abstract modeling perspective, the HD is handled as follows:
抽象的なモデル見解から、HDは以下の通り扱われます:
1. Extract the semantic meaning(s) (the handling instructions
associated with the HDUs) from the HD field. Transmitting Pip
hosts determine the semantic meaning by some other means, such as
the upper layer protocol. If the receiving system decapsulates
1. HD分野から意味意味(HDUsに関連している取扱上の注意事項)を抜粋してください。 伝わっているPipホストは上側の層のプロトコルなどのある他の手段で意味意味を決定します。 受電方式がdecapsulatesされるなら
Francis [Page 10] RFC 1622 Pip Header Processing May 1994
1994年5月に処理するフランシス[10ページ]RFC1622種のヘッダー
multiple Pip headers, then the HD semantics are extracted from the
lowest Pip header for which it is not the target (see example on
tunneling below).
複数のPipヘッダー、そして、HD意味論はそれが目標でない最も低いPipヘッダーから抜粋されます(以下でトンネルを堀ることに関する例を見てください)。
2. Handle the Pip packet according to those instructions. In some
cases, it is possible that the Pip system does not understand the
semantics of one or more HDUs of the HD field. For each HDU whose
semantics are not understood, however, the pip system at least
knows whether to 1) pass the HDU on untouched, 2) set it to all
0s, 3) set it to all 1s, 4) discard the packet silently, or 5)
discard the packet with a PCMP HDU Not Understood packet.
2. それらの指示に従って、Pipパケットを扱ってください。 いくつかの場合、PipシステムがHD分野の1HDUsの意味論を理解していないのは、可能です。 しかしながら、1に、)触れないところでHDUを渡してください、2が)すべての0にそれを設定するか、3が)すべての1にそれを設定するか、4が)静かにパケットを捨てるか、または5が)PCMP HDU Not Understoodパケットでパケットを捨てることにかかわらず種のシステムは、各HDUに関しては、意味論がだれのものでないかが分かったのを少なくとも知っています。
3. Modify the semantic meaning if necessary. Note also that if the
Pip packet is replicated for multicast, each packet has its HD
semantics modified individually. .LP .in 3 2.2.4 Tunneling .LP
Consider two Pip systems, X and Y, separated by one or
intermediate Pip systems. X wishes to tunnel a Transit Part to Y.
Y is therefore the target system of the tunnel. A Transit Part He
arrives at X. In order to forward the Transit Part to Y, X
encapsulates He in another Transit Part, Hy. Y is the target
system for Transit Part Hy. X sets the HD of He to what it would
have been if Y was directly connected to X (that is, there were no
intermediate Pip systems between X and Y). Further, it is
intended that Y will derive its HD semantics from the HD of
Transit Part He, not Transit Part Hy. .sp .KS
3. 必要なら、意味意味を変更してください。 また、Pipパケットがマルチキャストのために模写されるなら、各パケットで個別にHD意味論を変更することに注意してください。 .LP .in3 2.2.4Tunneling .LP Consider two Pipシステム(XとY)は、1か中間的Pipシステムで分離しました。Xは、したがって、Y.YへのTransit Partがトンネルの目標システムであることをトンネルに願っています。 彼はTransit PartをYに送るX.In命令に到達して、Xは要約されます。Transit Part、別のTransit Part(Hy)の彼。 YはTransit Part Hyの目標システムです。 XがHDを設定する、それが何であるだろうかへの彼はYであるなら直接Xに接されました(すなわち、XとYの間には、どんな中間的Pipシステムもありませんでした)。 さらに、YがHD意味論にTransit PartのHDに由来していることを意図します。彼(Transit Part Hyでない)。 .sp .KS
----0-----o-----o-----o-----o-----0----
X I J K L Y
----0-----o-----o-----o-----o-----0---- X I J K L Y
Now consider the operation of Pip system L (the previous hop system to Y). When L forwards the packet to Y, it may either decapsulate the packet (in the knowledge that Y is the target for Hy), or not decapsulate the packet. Either way, L derives its HD semantics from the HD of Transit Part Hy.
今度は、PipシステムLの操作が(Yへの前のホップシステム)であると考えてください。 LがパケットをYに送るとき、それは、パケット(YがHyのための目標であるという知識の)をdecapsulateしないか、パケットをdecapsulateしないかもしれません。 いずれにせよ、LがHD意味論にTransit Part HyのHDに由来しています。
If L does not decapsulate the Transit Part, then it is as though I, J, K, and L are a "subnetwork" (albeit a Pip subnetwork), and Y is stripping the "subnetwork" header (Hy) off before processing the true Transit Part (He). If L does decapsulate the Transit Part, then, from Y's perspective, it is essentially as though Y were directly connected to X.
LがどんなdecapsulateにもTransit Partをしないならまるで私、J、K、およびLが「サブネットワーク」(それにしても、Pipサブネットワーク)であり、Yが本当のTransit Part(彼)を処理する前に下に「サブネットワーク」ヘッダー(Hy)を裸にしているようです。 次に、LがYの見解からdecapsulateにTransit Partをするならまるで本質的にはYが直接Xに接続されるようでした。
Francis [Page 11] RFC 1622 Pip Header Processing May 1994
1994年5月に処理するフランシス[11ページ]RFC1622種のヘッダー
2.2.5 Routing Directive (RD)
2.2.5 ルート設定指示(RD)
The RD consists of the Routing Context (RC), the RC Contents, the FTIF Offset, and a series of zero or more FTIFs (Forwarding Table Index Fields). This series of FTIFs is called the FTIF Chain. The sole purpose of the RD is to determine how to forward the Pip packet--the RD does not influence handling in any way.
RDはルート設定のContext(RC)か、RC Contentsか、FTIF Offsetと、一連のゼロか、より多くのFTIFs(推進Table Indexフィールズ)から成ります。 FTIFsのこのシリーズはFTIF Chainと呼ばれます。 RDの唯一の目的はPipパケットを進める方法を決定することです--RDは何らかの方法で取り扱いに影響を及ぼしません。
Figure 3 illustrates the decision process for forwarding the Pip packet.
図3はPipパケットを進めるための決定の過程を例証します。
+---------+(next level RC)
(decapsulate)| |
| v
|<--------RC----------------->FIB
| / | | IF Offset)
| | |
| | v
|<------|---FTIF------------->FIB
| | / :
| |<- :(repeatedly...)
| | :
| | v
|<------|---FTIF------------->FIB
| / |
|<- |
v v
DestID-------------->FIB
+---------+ (次のレベルRC)(decapsulate)| | | v| <、-、-、-、-、-、-、--RC----------------->空言| / | | オフセット) | | | | | v| <、-、-、-、-、--、|、-、--FTIF------------->空言| | / : | | <、- :(反復して…) | | : | | v| <、-、-、-、-、--、|、-、--FTIF------------->空言| / | | <、-、| v DestIDに対して-------------->空言
Figure 3: Forwarding Process
図3: 推進の過程
Figure 3 is interpreted as follows. The FIB is the Forwarding Information Block. The FIB contains all the information needed to forward a packet, and may contain multiple next hop (for multicast). This information includes 1) the outgoing interface, 2) how to encapsulate the packet, including lower-layer address(es) (the lower-layer address(es) along with the outgoing interface determine the next hop Pip system), 3) whether and how to tunnel, 4) how to modify the semantics of the HD and RC, and how to modify the FTIF Offset. The goal of the forwarding algorithm is to reach the appropriate FIB.
図3は以下の通り解釈されます。 FIBはForwarding情報Blockです。 FIBはパケットを進めるのに必要であるすべての情報を含んでいて、次の複数のホップ(マルチキャストのための)を含むかもしれません。 この情報は外向的が連結する1、)下層を含んでいるとパケットをカプセルに入れるために、(es)が記述される2を)含んでいます。 (外向的なインタフェースに伴う下層アドレス(es)は次のホップPipシステムを決定します), そして、3)、トンネルへのどのように、4) どうHDとRCの意味論を変更するか、そして、どうFTIF Offsetを変更するか。 推進アルゴリズムの目標は適切なFIBに達することです。
The directed lines in Figure 3 start at the RC and, through various possible paths, reach a FIB. These lines represent the various information that can influence the forwarding decision (that is, the FIB chosen). For instance, there is no way to reach a FIB without
図3の有向直線は、RCで始まって、様々な可能な経路を通してFIBに達します。 これらの線は推進決定(すなわち、選ばれたFIB)に影響を及ぼすことができる様々な情報を表します。 例えば、道がFIBに達する全くありません。
Francis [Page 12] RFC 1622 Pip Header Processing May 1994
1994年5月に処理するフランシス[12ページ]RFC1622種のヘッダー
first examining the information in the RC. However, it is possible to identify a FIB by considering only the information in the RC (as indicated by the directed line leading directly right from the RC). Based on the information in the RC, it is also possible to determine that the Transit Part must be decapsulated, and 1) the RC of the next Transit Part be processed (the line leading directly left), 2) the FTIF indicated by the FTIF Offset is processed (the line leading down and right), or 3) the Dest ID is processed (the line leading down and lest).
最初に、RCの情報を調べます。 しかしながら、RCの情報だけを考えることによってFIBを特定するのは可能です(まさしくRCから直通する有向直線によって示されるように)。 そして、また、RCの情報に基づいてTransit Partをdecapsulatedしなければならなくて、1が)次のTransit PartのRCをdecapsulatedすることを決定するために、処理されてください(直通する線はいなくなりました)、FTIFがFTIF Offsetで示した2が)処理されるか(下に、そしてまさしく導く線)、または3)Dest IDが処理されるのも、可能である、(下に導く線、)
Likewise, when considering the value of an FTIF (in addition to all information already considered), the resulting action may be that 1) a FIB is identified, 2) the Transit Part is decapsulated, 3) the subsequent FTIF is processed, or 4) the Dest ID is processed.
FTIF(既に考えられたすべての情報に加えた)の値を考える場合、結果として起こる動作が1FIBあたり1が)特定されるということであることの同様に2) Transit Partがdecapsulatedされる、3) その後のFTIFが処理されるか、または4)Dest IDは処理されます。
The RC is handled similarly to the HD. The RC Contents field indicates how the RC should be interpreted. While the RC is constructed similarly to the HD in the sense that it consists of multiple fields, the RC can be interpreted as a flat field in-so-far as forwarding a Pip packet is concerned, whereas the HD cannot.
RCは同様にHDに扱われます。 RC Contents分野はRCがどう解釈されるべきであるかを示します。 RCが複数の分野から成るという意味で同様にHDに組み立てられている間、HDは解釈できませんが、Pipパケットを進めるのに関する限り、平らな野原としてRCを解釈できます。
Thus, in a mechanical sense, the RC Contents can be viewed as an index into a table that returns a pointer to another table (an rcTable), which is indexed by the RC itself. (Or, the combined RC Contents/RC can be viewed as a single large index into a single table, etc.)
したがって、機械的な意味で、インデックスとしてそれ自体でRCによって索引をつけられる別のテーブル(rcTable)にポインタを返すテーブルにRC Contentsを見なすことができます。 (ただ一つの大きいインデックスとして単一のテーブルなどに結合したRC Contents/RCを見なすことができます)
The FTIF Offset field indicates which FTIF is active. The active FTIF is the one that is used to index the forwarding table indicated by the RC Contents/RC. An FTIF Offset value of 0 means that the first FTIF is active, an FTIF Offset value of 1 means that the second FTIF is active, and so on. If there are no FTIFs, then the FTIF Offset has no meaning, and can be any value. In this case, the RC field itself will indicate how to forward the packet.
FTIF Offset分野は、どのFTIFがアクティブであるかを示します。 アクティブなFTIFはRC Contents/RCによって示された推進テーブルに索引をつけるのに使用されるものです。 0のFTIF Offset値は、最初のFTIFがアクティブであることを意味して、1のFTIF Offset値は、第2FTIFがアクティブであって、とてもオンであることを意味します。 FTIFsが全くなければ、FTIF Offsetは意味でないのを持って、どんな値であるかもしれません。 この場合、RC分野自体はパケットを進める方法を示すでしょう。
The FTIF Chain is padded out to a 32-bit boundary. Note that there can be more than 16 bits of padding (for instance, if it is desirable to pad out to a 64-bit boundary). The padding is ignored upon receipt, and can be transmitted as any value (that is, it does not have to be any specific pattern of 0's or 1's).
FTIF Chainは32ビットの境界に広げられます。 詰め物の16ビット以上があることができることに注意してください、(例えば、それが64ビットの境界に広げるのにおいて望ましい、) 詰め物を領収書で無視して、どんな値としても伝えることができます(すなわち、それはいずれかが0の特定のパターンか1であったならそうする必要はありません)。
Note that a single "number" in the FTIF chain may in fact be more than 16 bits in length. In this case, the number can be encoded as multiple FTIFs with no loss of generality. It is only required that in all cases a multiple FTIF number be distinguishable from a single FTIF number.
事実上、長さがFTIFチェーンにおける単一の「数」は16ビット以上であるかもしれないことに注意してください。 この場合、複数のFTIFsとして一般性の喪失なしで数をコード化できます。 すべての場合における複数のFTIF番号がただ一つのFTIF番号から区別可能であることが必要であるだけです。
Francis [Page 13] RFC 1622 Pip Header Processing May 1994
1994年5月に処理するフランシス[13ページ]RFC1622種のヘッダー
2.2.6 Router RD Forwarding Algorithm
2.2.6 ルータ推進第アルゴリズム
This section describes the forwarding algorithm for a Pip router.
このセクションはPipルータのために推進アルゴリズムを説明します。
1. Using the value of the RC field as an index, retrieve one of the
following instructions (steps 2 - 5) from the rcTable determined
by the RC Contents.
1. インデックスとしてRC分野の値を使用して、RC Contentsで断固としたrcTableから以下の指示(2--5を踏む)の1つを検索してください。
2. If the instruction is decapsulate, then decapsulate the Transit
Part and re-execute step 1 using the next Transit Part.
2. 指示がdecapsulateであり、次に、decapsulateが次のTransit Partを使用するTransit Partと再実行ステップ1であるなら。
3. If the instruction is forward, then retrieve the associated
Forwarding Information Block (FIB), and go to step 12.
3. 指示が前方にあるなら、関連Forwarding情報Block(FIB)を検索してください、そして、ステップ12に行ってください。
4. If the instruction is to examine the Dest ID, then retrieve the
FIB associated with the Dest ID, and go to step 12.
4. 指示がDest IDを調べることであるならDest IDに関連しているFIBを検索してください、そして、ステップ12に行ってください。
5. If the instruction is to examine the FTIF Chain, then retrieve the
forwardingTable indicated by the rcTable entry, and continue on to
step 6.
5. 指示がFTIF Chainを調べることであるならrcTableエントリーで示されたforwardingTableを検索してください、そして、ステップ6に続いてください。
6. Using the value of the currently active FTIF (this is the FTIF
indicated by the FTIF Offset if this is the first FTIF examined)
as an index, retrieve one or more of the following instructions
(steps 7 - 10) from the forwardingTable identified in step 5 or
step 10.
6. インデックスとして現在アクティブなFTIF(これはこれがFTIFが調べた1番目であるならFTIF Offsetによって示されたFTIFである)の値を使用して、ステップ5かステップ10で特定されたforwardingTableから以下の指示(7--10を踏む)の1つ以上を検索してください。
7. If the instruction is decapsulate, then decapsulate the Pip header
and re-execute step 1 using the new header (this is the same as
step 2).
7. 指示がdecapsulateであるなら、そして、新しいヘッダー(これはステップ2と同じである)を使用するPipヘッダーのdecapsulateと再実行ステップ1です。
8. If the instruction is forward, then (possibly additionally)
retrieve the associated FIB, and go to step 12 (this is the same
as step 3).
8. 指示が前方にあるなら、次に(ことによるとさらに)、関連FIBを検索してください、そして、ステップ12に行ってください(これはステップ3と同じです)。
9. If the instruction is to examine the Dest ID, then retrieve the
FIB associated with the Dest ID and go to step 12 (this is the
same as step 4).
9. 指示がDest IDを調べることであるならDest IDに関連しているFIBを検索してください、そして、ステップ12に行ってください(これはステップ4と同じです)。
10. If the instruction is to examine the next FTIF, then, according
to the information in the current forwardingTable entry, modify
the current FTIF and choose a new forwardingTable.
10. 現在のforwardingTableエントリーにおける情報に従って、指示が次のFTIFを調べることであるなら現在のFTIFを変更してください、そして、新しいforwardingTableを選んでください。
11. Make the next FTIF the current FTIF and go to step 6.
11. 次のFTIFを現在のFTIFにしてください、そして、ステップ6に行ってください。
12. The FIB contains a set of potential recipients for the Pip
packet, including next hop Pip systems (both directly connected
and at the end of Pip tunnels) and the upper layer of the local
12. FIBはPipパケットのための1セットの潜在的受取人を含みます、次のホップPipシステム(直接接続されてPipトンネルの端の)と地方の上側の層を含んでいて
Francis [Page 14] RFC 1622 Pip Header Processing May 1994
1994年5月に処理するフランシス[14ページ]RFC1622種のヘッダー
system. Taking into consideration 1) the incoming interface, 2)
the previous hop Pip system if known (as determined by the
lower-layer source address and incoming interface), and 3)
potentially other local information (such as congestion on
outgoing queues), prune the set of potential recipients. (This
may result in no pruning having taken place or in every potential
next hop having been pruned.)
システム。 知られているなら(下層ソースアドレスと入って来るインタフェースで決定するように)考慮1) 入って来るインタフェース、2に)前のホップPipシステムを連れていって、潜在的に他の3の)ローカルの情報(外向的な待ち行列の混雑などの)は潜在的受取人のセットから余計なものを取り除きます。 (行われたか、または次のあらゆる潜在的ホップで剪定されて、これは剪定をもたらさないかもしれません。)
13. For each remaining next hop, format a Pip header by modifying a)
the RC, b) the current FTIF, c) the FTIF Offset (to point to 1)
the FTIF pointed to in the received RD, 2) the current FTIF, 3)
the Nth FTIF counting from the 0th FTIF, or 4) the Nth FTIF
counting forwards or backwards from the current FTIF) and d) any
Pip header encapsulations, according to the information in the
FIB, and transmit the packet to the recipient (either a next hop
or upper layer).
13. 次のそれぞれの残っているホップに関しては、FIBの情報によると、a) RC、b) 現在のFTIF、c) FTIF Offset(1へのポイント) 第0FTIF、または4から)現在のFTIFから前方か後方に数えるNth FTIFを数える現在のFTIF、容認されたRD、2)3)Nth FTIFに示されたFTIFへの)、およびd) どんなPipヘッダーカプセル化も変更することによって、Pipヘッダーをフォーマットしてください、そして、受取人(次のホップか上側の層のどちらか)にパケットを伝えてください。
2.3 Options Part
2.3のオプションが離れています。
The Option Part is formatted as shown in Figure 4.
Option Partは図4に示されるようにフォーマットされます。
+===========================+
| Options Descriptor | 64
+===========================+
| Option 2 | Variable
+===========================+
| Option 3 | Variable
+===========================+
.
.
.
+===========================+
| Option N | Variable
+===========================+
+===========================+ | オプション記述子| 64 +===========================+ | オプション2| 変数+===========================+ | オプション3| 変数+===========================+ . . . +===========================+ | オプションN| 変数+===========================+
Figure 4: Options Part
図4: オプション一部
Every Option is at least one 32-bit word in length, and ends on a 32-bit word boundary. Because the type of each option is known from the Options Contents field, there is no need to indicate the option type in the options field themselves. Thus, there is no common format among the options--each option has its own format. The individual options are defined in another specification.
あらゆるOptionが長さにおける少なくとも1つの32ビットの単語であり、32ビットの語境界で終わります。 それぞれのオプションのタイプがOptions Contents分野から知られているので、オプションにおけるオプションタイプが自分たちをさばくのを示す必要は全くありません。 したがって、オプションの中にどんな一般的な形式もありません--各オプションには、それ自身の形式があります。 個人の選択は別の仕様に基づき定義されます。
Francis [Page 15] RFC 1622 Pip Header Processing May 1994
1994年5月に処理するフランシス[15ページ]RFC1622種のヘッダー
2.3.1 Options Descriptor
2.3.1 オプション記述子
The Options Descriptor option gives the offset of each option in the Options Part. The Options Descriptor consists of eight eight-bit Option Position fields, each of which gives the position of up to eight options (there can be no more than 8 Options Part). Each of the Option Position fields correspond to one of the bits in the Options Present field. The unit of measure of each Option Position is 32-bit words, counting the first word of the Options Part as word 0. The high order Option Position field corresponds to the high order bit in the Options Present field.
Options DescriptorオプションはOptions Partでのそれぞれのオプションのオフセットを与えます。 Options Descriptorは8つの8ビットのOption Position分野から成ります(8未満Options Partがあることができます)。それはそれぞれ最大8つのオプションの位置を与えます。 それぞれのOption Position分野はOptions Present分野でビットの1つに対応しています。 それぞれのOption Positionの測定の単位は32ビットの単語です、Options Partの最初の単語をWord0にみなして。 高位Option Position分野はOptions Present分野で高位のビットに対応しています。
Security Considerations
セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
Author's Address
作者のアドレス
Paul Francis NTT Software Lab 3-9-11 Midori-cho Musashino-shi Tokyo 180 Japan
NTTソフトウェア研究室の3 9-11テロのフランシス・美土里町の武蔵野市の東京日本のポール180
Phone: +81-422-59-3843 Fax +81-422-59-3765 EMail: francis@cactus.ntt.jp
以下に電話をしてください。 +81-422-59-3843 ファックス+81-422-59-3765はメールされます: francis@cactus.ntt.jp
Francis [Page 16]
フランシス[16ページ]
一覧
スポンサーリンク
