RFC1561 日本語訳
1561 Use of ISO CLNP in TUBA Environments. D. Piscitello. December 1993. (Format: TXT=55902 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group D. Piscitello Request for Comments: 1561 Core Competence Category: Experimental December 1993
Piscitelloがコメントのために要求するワーキンググループD.をネットワークでつないでください: 1561年のコアコンピタンスカテゴリ: 実験的な1993年12月
Use of ISO CLNP in TUBA Environments
チューバ環境におけるISO CLNPの使用
Status of this Memo
このMemoの状態
This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 このメモはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
Abstract
要約
This memo specifies a profile of the ISO/IEC 8473 Connectionless-mode Network Layer Protocol (CLNP, [1]) for use in conjunction with RFC 1347, TCP/UDP over Bigger Addresses (TUBA, [2]). It describes the use of CLNP to provide the lower-level service expected by Transmission Control Protocol (TCP, [3]) and User Datagram Protocol (UDP, [4]). CLNP provides essentially the same datagram service as Internet Protocol (IP, [5]), but offers a means of conveying bigger network addresses (with additional structure, to aid routing).
RFCに関連して1347を使用してください、Bigger Addressesの上のTCP/UDP。このメモが8473年のISO/IEC Connectionless-モードNetwork Layerプロトコルのプロフィールを指定する、(CLNP、[1])、(TUBA([2]))。 通信制御プロトコルによって予想された低レベルサービスを提供するためにCLNPの使用について説明する、(TCP、[3])、およびユーザー・データグラム・プロトコル、(UDP([4]))。 CLNPは本質的にはインターネットプロトコルと同じデータグラムサービスを提供します。(しかし、IP、[5])、より大きいネットワークを伝える手段が扱う(援助ルーティングへの追加構造で)申し出。
While the protocols offer nearly the same services, IP and CLNP are not identical. This document describes a means of preserving the semantics of IP information that is absent from CLNP while preserving consistency between the use of CLNP in Internet and OSI environments. This maximizes the use of already-deployed CLNP implementations.
プロトコルはほとんど同じサービスを提供しますが、IPとCLNPは同じではありません。 このドキュメントはインターネットとOSI環境におけるCLNPの使用の間の一貫性を保存している間にCLNPから欠けているIP情報の意味論を保存する手段を説明します。 これは既に配布しているCLNP実装の使用を最大にします。
Acknowledgments
承認
Many thanks to Ross Callon (Wellfleet Communications), John Curran (BBN), Cyndi Jung (3Com), Paul Brooks (UNSW), Brian Carpenter (CERN), Keith Sklower (Cal Berkeley), Dino Farinacci and Dave Katz (Cisco Systems), Rich Colella (NIST/CSL) and David Oran (DEC) for their assistance in composing this text.
彼らの支援のために本稿を構成するのにおいてロスCallon(Wellfleet Communications)、ジョン・カラン(BBN)、シンディ・ユング(3Com)、ポール・ブルックス(UNSW)、ブライアンCarpenter(CERN)、キースSklower(カル・バークレー)、ディーノ・ファリナッチ、デーヴ・キャッツ(シスコシステムズ)、リッシュColella(NIST/CSL)、およびデヴィッド・オラン(12月)をありがとうございます。
Piscitello [Page 1] RFC 1561 CLNP in TUBA Environments December 1993
チューバ環境1993年12月のPiscitello[1ページ]RFC1561CLNP
Conventions
コンベンション
The following language conventions are used in the items of specification in this document:
以下の言語コンベンションは仕様に関する条項で本書では使用されます:
* MUST, SHALL, or MANDATORY -- the item is an absolute
requirement of the specification.
* SHALL、MANDATORY--項目は仕様に関する絶対条件であるに違いありません。
* SHOULD or RECOMMENDED -- the item should generally be
followed for all but exceptional circumstances.
* SHOULDかRECOMMENDED--一般に、商品はほとんど例外的な事情のために従われるべきです。
* MAY or OPTIONAL -- the item is truly optional and may be
followed or ignored according to the needs of the
implementor.
* 5月かOPTIONAL--作成者の必要性に従って、商品は、本当に、任意であり、従われているか、または無視されるかもしれません。
1. Terminology
1. 用語
To the extent possible, this document is written in the language of the Internet. For example, packet is used rather than "protocol data unit", and "fragment" is used rather than "segment". There are some terms that carry over from OSI; these are, for the most part, used so that cross-reference between this document and RFC 994 [6] or ISO/IEC 8473 is not entirely painful. OSI acronyms are for the most part avoided.
可能な範囲内で、このドキュメントはインターネットの言葉を借りて言えば書かれています。 例えば、パケットは「プロトコルデータ単位」よりむしろ使用されます、そして、「断片」は「セグメント」よりむしろ使用されます。 OSIから及ぶいくつかの用語があります。 これらがだいたい使用されるので、このドキュメントとRFC994[6]かISO/IEC8473の間の相互参照は完全に苦痛ではありません。 OSI頭文字語はだいたい避けられます。
2. Introduction
2. 序論
The goal of this specification is to allow compatible and interoperable implementations to encapsulate TCP and UDP packets in CLNP data units. In a sense, it is more of a "hosts requirements" document for the network layer of TUBA implementations than a protocol specification. It is assumed that readers are familiar with STD 5, RFC 791, STD 5, RFC 792 [7], STD 3, RFC 1122 [8], and, to a lesser extent, RFC 994 and ISO/IEC 8473. This document is compatible with (although more restrictive than) ISO/IEC 8473; specifically, the order, semantics, and processing of CLNP header fields is consistent between this and ISO/IEC 8473.
この仕様の目標はコンパチブル、そして、共同利用できる実装が、CLNPデータ単位でTCPとUDPがパケットであるとカプセル化するのを許容することです。 ある意味で、それはプロトコル仕様よりTUBA実装のネットワーク層ための「ホスト要件」ドキュメントです。 読者がある程度STD5、RFC791、STD5、RFC792[7]、STD3、RFC1122[8]、RFC994、およびISO/IEC8473に詳しいと思われます。 このドキュメントは互換性がある、(より制限している、)、ISO/IEC8473。 明確に、CLNPヘッダーフィールドの注文、意味論、および処理はこれとISO/IEC8473の間で一貫しています。
[Note: RFC 994 contains the Draft International Standard version of ISO CLNP, in ASCII text. This is not the final version of the ISO/IEC protocol specification; however, it should provide sufficient background for the purpose of understanding the relationship of CLNP to IP, and the means whereby IP information is to be encoded in CLNP header fields. Postscript versions of ISO CLNP and associated routing protocols are available via anonymous FTP from merit.edu, and may be found in the directory /pub/ISO/IEC.
RFC994はISO CLNPの国際規格案バージョンを含んでいます、ASCIIテキストで。注意: これはISO/IECプロトコル仕様の最終版ではありません; しかしながら、それはCLNPの関係をIPに理解する目的、およびCLNPヘッダーフィールドでコード化されるIP情報がことである手段に十分なバックグラウンドを提供するべきです。ISO CLNPと関連ルーティング・プロトコルの補遣版は、merit.eduからの公開FTPで利用可能であり、ディレクトリ/pub/ISO/IECで見つけられるかもしれません。
Piscitello [Page 2] RFC 1561 CLNP in TUBA Environments December 1993
チューバ環境1993年12月のPiscitello[2ページ]RFC1561CLNP
3. Overview of CLNP
3. CLNPの概要
ISO CLNP is a datagram network protocol. It provides fundamentally
the same underlying service to a transport layer as IP. CLNP provides
essentially the same maximum datagram size, and for those
circumstances where datagrams may need to traverse a network whose
maximum packet size is smaller than the size of the datagram, CLNP
provides mechanisms for fragmentation (data unit identification,
fragment/total length and offset). Like IP, a checksum computed on
the CLNP header provides a verification that the information used in
processing the CLNP datagram has been transmitted correctly, and a
lifetime control mechanism ("Time to Live") imposes a limit on the
amount of time a datagram is allowed to remain in the internet
system. As is the case in IP, a set of options provides control
functions needed or useful in some situations but unnecessary for the
most common communications.
ISO CLNPはデータグラムネットワーク・プロトコルです。 それはIPとしてのトランスポート層に対する基本的に同じ基本的なサービスを提供します。 CLNPは本質的には同じ最大のデータグラムサイズを提供します、そして、データグラムが最大のパケットサイズがデータグラムのサイズより小さいネットワークを横断する必要があるかもしれないそれらの事情のために、CLNPは断片化(データ単位識別、断片/全長、およびオフセット)にメカニズムを提供します。 IPのように、CLNPヘッダーの上に計算されたチェックサムは正しく、伝えられた状態でCLNPデータグラムを処理する際に使用される情報がそうである検証を提供します、そして、生涯制御機構(「生きる時間」)はデータグラムがインターネットシステムに残ることができる時間に指し値します。 IPのケースのように、1セットのオプションは最も一般的なコミュニケーションに、必要であるかいくつかの状況で役に立ちますが、不要な機能をコントロールに提供します。
Note that the encoding of options differs between the two protocols, as do the means of higher level protocol identification. Note also that CLNP and IP differ in the way header and fragment lengths are represented, and that the granularity of lifetime control (time-to- live) is finer in CLNP.
オプションのコード化が、より高い平らなプロトコル識別の手段のように2つのプロトコルの間で異なることに注意してください。 また、CLNPとIPがヘッダーと断片の長さが代理をされる方法で異なって、生涯の粒状が制御されることに注意してください、(時間、-、-ライブで)、CLNPで、よりすばらしいのはそうです。
Some of these differences are not considered "issues", as CLNP provides flexibility in the way that certain options may be specified and encoded (this will facilitate the use and encoding of certain IP options without change in syntax); others, e.g., higher level protocol identification and timestamp, must be accommodated in a transparent manner in this profile for correct operation of TCP and UDP, and continued interoperability with OSI implementations. Section 4 describes how header fields of CLNP must be populated to satisfy the needs of TCP and UDP.
これらの違いのいくつかが「問題」であることは考えられません、CLNPが、あるオプションが指定されて、コード化されるかもしれない(これは構文における変化なしであるIPオプションの使用とコード化を容易にするでしょう)方法で柔軟性を提供するとき。 TCPとUDPの正しい操作、およびOSI実装がある継続的な相互運用性のためのこのプロフィールの見え透いた方法で他のもの(例えば、より高い平らなプロトコル識別とタイムスタンプ)を設備しなければなりません。 セクション4はTCPとUDPの需要を満たすためにどうCLNPのヘッダーフィールドに居住しなければならないかを説明します。
Errors detected during the processing of a CLNP datagram MAY be reported using CLNP Error Reports. Implementations of CLNP for TUBA environments MUST be capable of processing Error Reports (this is consistent with the 1992 edition (2) of the ISO/IEC 8473 standard). Control messages (e.g., echo request/reply and redirect) are similarly handled in CLNP, i.e., identified as separate network layer packet types. The relationship between CLNP Error and Control messages and Internet Control Message Protocol (ICMP, [7]), and issues relating to the handling of these messages is described in Section 5.
CLNPデータグラムの処理の間に検出された誤りは報告された使用CLNP Error Reportsであるかもしれません。 TUBA環境のためのCLNPの実装は処理Error Reportsができなければなりません(これは1992年の8473年のISO/IEC規格の版(2)と一致しています)。 別々のネットワーク層パケットがタイプされるように、コントロールメッセージ(例えば、エコー要求/回答であって再直接の)は、CLNPで同様に扱われて、すなわち、特定されています。 CLNP Errorと、Controlメッセージとインターネット・コントロール・メッセージ・プロトコルとの関係、(ICMP、[7])、およびこれらのメッセージの取り扱いに関連する問題がセクション5で説明されます。
Piscitello [Page 3] RFC 1561 CLNP in TUBA Environments December 1993
チューバ環境1993年12月のPiscitello[3ページ]RFC1561CLNP
Table 1 provides a high-level comparison of CLNP to IP:
テーブル1はCLNPのハイレベルの比較をIPに提供します:
Function | ISO CLNP | DOD IP
----------------------|------------------------|-----------------------
Header Length | indicated in octets | in 32-bit words
Version Identifier | 1 octet | 4 bits
Lifetime (TTL) | 500 msec units | 1 sec units
Flags | Fragmentation allowed, | Don't Fragment,
| More Fragments | More Fragments,
| Suppress Error Reports | <not defined>
Packet Type | 5 bits | <not defined>
Fragment Length | 16 bits, in octets | 16 bits, in octets
Header Checksum | 16-bit (Fletcher) | 16-bit
Total Length | 16 bits, in octets | <not defined>
Addressing | Variable length | 32-bit fixed
Data Unit Identifier | 16 bits | 16 bits
Fragment offset | 16 bits, in octets | 13 bits, 8-octet units
Higher Layer Protocol | Selector in address | Protocol
Options | Security | Security
| Priority | TOS Precedence bits
| Complete Source Route | Strict Source Route
| Quality of Service | Type of Service
| Partial Source Route | Loose Source Route
| Record Route | Record Route
| Padding | Padding
| <defined herein> | Timestamp
機能| ISO CLNP| DOD IP----------------------|------------------------|----------------------- ヘッダ長| 八重奏では、示されます。| 32ビットの単語バージョンIdentifierで| 1つの八重奏| 4ビットのLifetime(TTL)| 500 msec単位| 1秒のユニットFlags| 許された断片化| 断片化しないでください。| より多くの断片| 以上は断片化します。| エラー・レポートを抑圧してください。| <は>Packet Typeを定義しませんでした。| 5ビット| <は>Fragment Lengthを定義しませんでした。| 八重奏における16ビット| 八重奏Header Checksumの16ビット| 16ビットの(フレッチャー)| 16ビットの全長| 八重奏における16ビット| <は>Addressingを定義しませんでした。| 可変長| 32ビットの固定Data Unit Identifier| 16ビット| 16ビットのFragmentは相殺します。| 八重奏における16ビット| 13ビット、8八重奏のユニットHigher Layerプロトコル| アドレスのセレクタ| プロトコルオプション| セキュリティ| セキュリティ| 優先権| TOS Precedenceビット| 完全な送信元経路| 厳しい送信元経路| サービスの質| サービスのタイプ| 部分的な送信元経路| ゆるい送信元経路| ルートを記録してください。| ルートを記録してください。| 詰め物| 詰め物| <はここに>を定義しました。| タイムスタンプ
Table 1. Comparison of IP to CLNP
1を見送ってください。 CLNPへのIPの比較
The composition and processing of a TCP pseudo-header when CLNP is used to provide the lower-level service expected by TCP and UDP is described in Section 6.
CLNPがTCPとUDPによって予想された低レベルサービスを提供するのに使用されるときのTCP疑似ヘッダーの構成と処理はセクション6で説明されます。
[Note: This experimental RFC does not discuss multicasting. Presently, there are proposals for multicast extensions for CLNP in ISO/IEC/JTC1/SC6, and a parallel effort within TUBA. A future revision to this RFC will incorporate any extensions to CLNP that may be introduced as a result of the adoption of one of these alternatives.]
[以下に注意してください。 この実験的なRFCはマルチキャスティングについて議論しません。 現在、TUBAの中にISO/IEC/JTC1/SC6、および平行な取り組みにはCLNPのためのマルチキャスト拡大のための提案があります。 このRFCへの今後の改正はこれらの代替手段の1つの採用の結果、導入されるかもしれないCLNPにどんな拡大も取り入れるでしょう。]
Piscitello [Page 4] RFC 1561 CLNP in TUBA Environments December 1993
チューバ環境1993年12月のPiscitello[4ページ]RFC1561CLNP
4. Proposed Internet Header using CLNP
4. CLNPを使用している提案されたインターネットヘッダー
A summary of the contents of the CLNP header, as it is proposed for use in TUBA environments, is illustrated in Figure 4-1:
それがTUBA環境における使用のために提案されるとき、CLNPヘッダーのコンテンツの概要は図4-1で例証されます:
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ........Data Link Header........ | NLP ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Header Length | Version | Lifetime (TTL)|Flags| Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Fragment Length | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Dest Addr Len | Destination Address... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... Destination Address... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... Destination Address... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... Destination Address... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... Destination Address... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PROTO field | Src Addr Len | Source Address... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... Source Address... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... Source Address... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... Source Address... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... Source Address... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Source Address | Reserved | Data Unit Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Fragment Offset | Total Length of packet | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options (see Table 1) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ........データはヘッダーをリンクします… | NLP ID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |ヘッダ長| バージョン| 生涯(TTL)|旗| タイプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 断片の長さ| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Dest Addrレン| 送付先アドレス… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... 送付先アドレス… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... 送付先アドレス… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... 送付先アドレス… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... 送付先アドレス… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | プロト分野| Src Addrレン| ソースアドレス… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... ソースアドレス… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... ソースアドレス… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... ソースアドレス… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... ソースアドレス… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |ソースアドレス| 予約されます。| データ単位識別子| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 断片オフセット| パケットの総Length| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | オプション(テーブル1を見ます)| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | データ| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note that each tick mark represents one bit position.
各ダニ麻痺が1つのビット位置を表すことに注意してください。
Figure 4-1. CLNP for TUBA
図4-1。 チューバのためのCLNP
Piscitello [Page 5] RFC 1561 CLNP in TUBA Environments December 1993
チューバ環境1993年12月のPiscitello[5ページ]RFC1561CLNP
Note 1: For illustrative purposes, Figure 4-1 shows Destination
and Source Addresses having a length of 19 octets,
including the PROTO/reserved field. In general, addresses
can be variable length, up to a maximum of 20 octets,
including the PROTO/reserved field.
注意1: 説明に役立った目的のために、図4-1は、DestinationとSource Addressesにはプロト/予約された分野を含む19の八重奏の長さがあるのを示します。 一般に、プロト/予約された分野を含む最大20の八重奏までアドレスは可変長であるかもしれません。
Note 2: Due to differences in link layer protocols, it is not
possible to ensure that the packet starts on an even
alignment. Note, however, that many link level protocols
over which CLNP is operated use a odd length link
(e.g., IEEE 802.2). (In Figure 4-1, the rest of the CLNP
packet is even-aligned.)
注意2: リンクレイヤプロトコルの違いのために、パケットが同等の整列を始めるのを保証するのは可能ではありません。 しかしながら、CLNPが操作される多くのリンク・レベルプロトコルが変な長さのリンク(例えば、IEEE802.2)を使用することに注意してください。 (図4-1では、CLNPパケットの残りは並べられさえします。)
The encoding of CLNP fields for use in TUBA environments is as follows.
TUBA環境における使用のためのCLNP分野のコード化は以下の通りです。
4.1 Network Layer Protocol Identification (NLP ID)
4.1 ネットワーク層プロトコル識別(NLP ID)
This one-octet field identifies this as the ISO/IEC 8473 protocol; it MUST set to binary 1000 0001.
この1八重奏の分野は、これが8473年のISO/IECプロトコルであると認識します。 それは2進の1000 0001にセットしなければなりません。
4.2 Header Length Indication (Header Length)
4.2 ヘッダ長指示(ヘッダ長)
Header Length is the length of the CLNP header in octets, and thus points to the beginning of the data. The value 255 is reserved. The header length is the same for all fragments of the same (original) CLNP packet.
ヘッダーLengthは八重奏における、CLNPヘッダーの長さと、その結果、データの始まりまでポイントです。 値255は予約されています。 同じ(オリジナル)のCLNPパケットのすべての断片に、ヘッダ長は同じです。
4.3 Version
4.3 バージョン
This one-octet field identifies the version of the protocol; it MUST be set to a binary value 0000 0001.
この1八重奏の分野はプロトコルのバージョンを特定します。 2進の値0000 0001にそれを設定しなければなりません。
4.4 Lifetime (TTL)
4.4 生涯(TTL)
Like the TTL field of IP, this field indicates the maximum time the datagram is allowed to remain in the internet system. If this field contains the value zero, then the datagram MUST be destroyed; a host, however, MUST NOT send a datagram with a lifetime value of zero. This field is modified in internet header processing. The time is measured in units of 500 milliseconds, but since every module that processes a datagram MUST decrease the TTL by at least one even if it process the datagram in less than 500 millisecond, the TTL must be thought of only as an upper bound on the time a datagram may exist. The intention is to cause undeliverable datagrams to be discarded, and to bound the maximum CLNP datagram lifetime. [Like IP, the colloquial usage of TTL in CLNP is as a coarse hop-count.]
IPのTTL分野のように、この分野はデータグラムがインターネットシステムに残ることができる最大の時間を示します。 この分野が値ゼロを含んでいるなら、データグラムを破壊しなければなりません。 しかしながら、ホストはゼロの生涯値があるデータグラムを送ってはいけません。 この分野はインターネットヘッダー処理で変更されます。 時間は500ミリセカンドのユニットで測定されますが、500ミリセカンド未満でデータグラムを処理してもデータグラムを処理するあらゆるモジュールがTTLを少なくとも1つ減少させなければならないので、データグラムが存在するとき、単に上限としてTTLを考えなければなりません。 意志は「非-提出物」データグラムが捨てられて、バウンドすることを引き起こすことです。最大のCLNPデータグラム生涯。 [IPに、CLNPのTTLの口語的な使用法は下品なホップカウントとして似ています。]
Piscitello [Page 6] RFC 1561 CLNP in TUBA Environments December 1993
チューバ環境1993年12月のPiscitello[6ページ]RFC1561CLNP
Unless otherwise directed, a host SHOULD use a value of 255 as the initial lifetime value.
別の方法で指示されない場合、ホストSHOULDは初期の生涯値として255の値を使用します。
4.5 Flags
4.5個の旗
Three flags are defined. These occupy bits 0, 1, and 2 of the Flags/Type octet:
3個の旗が定義されます。 これらはFlags/タイプ八重奏のビット0、1、および2を占領します:
0 1 2
+---+---+---+
| F | M | E |
| P | F | R |
+---+---+---+
0 1 2 +---+---+---+ | F| M| E| | P| F| R| +---+---+---+
The Fragmentation Permitted (FP) flag, when set to a value of one (1), is semantically equivalent to the "may fragment" value of the Don't Fragment field of IP; similarly, when set to zero (0), the Fragmentation Permitted flag is semantically equivalent to the "Don't Fragment" value of the Don't Fragment Flag of IP.
1つ(1)の値に設定されると、Fragmentation Permitted(FP)旗はIPのFragment分野ではなく、「断片化するかもしれない」というドンの値に意味的に同等です。 (0)のゼロを合わせるように設定されるとき、同様に、Fragmentation Permitted旗は「断片化しないでください」というIPのFragment Flagではなく、ドンの値に意味的に同等です。
[Note: If the Fragmentation Permitted field is set to the value 0, then the Data Unit Identifier, Fragment Offset, and Total Length fields are not present. This denotes a single fragment datagram. In such datagrams, the Fragment Length field contains the total length of the datagram.]
[以下に注意してください。 Fragmentation Permitted分野が値0に設定されるなら、Data Unit Identifier、Fragment Offset、およびTotal Length分野は存在していません。 これは単一の断片データグラムを指示します。 そのようなデータグラムでは、Fragment Length分野はデータグラムの全長を含んでいます。]
The More Fragments flag of CLNP is semantically and syntactically the same as the More Fragments flag of IP; a value of one (1) indicates that more segments/fragments are forthcoming; a value of zero (0) indicates that the last octet of the original packet is present in this segment.
CLNPのMore Fragments旗はIPのMore Fragments旗と意味的に、そして、シンタクス上同じです。 1つ(1)の値は、より多くのセグメント/断片が用意されているのを示します。 (0)がない値は、オリジナルのパケットの最後の八重奏がこのセグメントで存在しているのを示します。
The Error Report (ER) flag is used to suppress the generation of an error message by a host/router that detects an error during the processing of a CLNP datagram; a value of one (1) indicates that the host that originated this datagram thinks error reports are useful, and would dearly love to receive one if a host/router finds it necessary to discard its datagram(s).
Error Report(ER)旗はCLNPデータグラムの処理の間に誤りを検出するホスト/ルータによるエラーメッセージの世代を抑圧するのに使用されます。 1つ(1)の値は、このデータグラムを溯源したホストが、エラー・レポートが役に立つと考えるのを示して、データグラムを捨てるのが必要であることがホスト/ルータによってわかるなら、1を受け取るのを心から好むでしょう。
Piscitello [Page 7] RFC 1561 CLNP in TUBA Environments December 1993
チューバ環境1993年12月のPiscitello[7ページ]RFC1561CLNP
4.6 Type field
4.6 タイプ分野
The type field distinguishes data CLNP packets from Error Reports from Echo packets. The following values of the type field apply:
タイプ分野はError ReportsとEchoパケットとデータCLNPパケットを区別します。 タイプ分野の以下の値は適用されます:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| flags | 1 | 1 | 1 | 0 | 0 | => Encoding of Type = data packet
+---+---+---+---+---+---+---+---+
| flags | 0 | 0 | 0 | 0 | 1 | => Encoding of Type = error report
+---+---+---+---+---+---+---+---+
| flags | 1 | 1 | 1 | 1 | 0 | => Encoding of Type = echo request
+---+---+---+---+---+---+---+---+
| flags | 1 | 1 | 1 | 1 | 1 | => Encoding of Type = echo reply
+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 旗| 1 | 1 | 1 | 0 | 0 | =Typeの>コード化はデータ・パケット+と等しいです。---+---+---+---+---+---+---+---+ | 旗| 0 | 0 | 0 | 0 | 1 | =Typeの>コード化はエラー・レポート+と等しいです。---+---+---+---+---+---+---+---+ | 旗| 1 | 1 | 1 | 1 | 0 | =Typeの>コード化はエコー要求+と等しいです。---+---+---+---+---+---+---+---+ | 旗| 1 | 1 | 1 | 1 | 1 | =Typeの>コード化はエコー・リプライ+と等しいです。---+---+---+---+---+---+---+---+
Error Report packets are described in Section 5.
誤りReportパケットはセクション5で説明されます。
Echo packets and their use are described in RFC 1139 [9].
エコーパケットと彼らの使用はRFC1139[9]で説明されます。
4.7 Fragment Length
4.7 断片の長さ
Like the Total Length of the IP header, the Fragment length field contains the length in octets of the fragment (i.e., this datagram) including both header and data.
IPヘッダーのTotal Lengthのように、ヘッダーとデータの両方を含んでいて、Fragment長さの分野は断片(すなわち、このデータグラム)の八重奏における長さを含んでいます。
[Note: CLNP also may also have a Total Length field, that contains the length of the original datagram; i.e., the sum of the length of the CLNP header plus the length of the data submitted by the higher level protocol, e.g., TCP or UDP. See Section 4.12.]
[以下に注意してください。 また、CLNPには、Total Length分野があるかもしれなくて、それはオリジナルのデータグラムの長さを含んでいます。 すなわち、CLNPヘッダーの長さと、より高い平らなプロトコル、例えば、TCPによって提出されたデータかUDPの長さ。 セクション4.12を見てください。]
4.8 Checksum
4.8 チェックサム
A checksum is computed on the header only. It MUST be verified at each host/router that processes the packet; if header fields are changed during processing (e.g., the Lifetime), the checksum is modified. If the checksum is not used, this field MUST be coded with a value of zero (0). See Appendix A for algorithms used in the computation and adjustment of the checksum. Readers are encouraged to see [10] for a description of an efficient implementation of the checksum algorithm.
チェックサムはヘッダーだけの上に計算されます。 パケットを処理する各ホスト/ルータでそれについて確かめなければなりません。 処理(例えば、Lifetime)の間、ヘッダーフィールドを変えるなら、チェックサムは変更しています。 チェックサムが使用されていないなら、(0)がない値でこの分野をコード化しなければなりません。 チェックサムの計算と調整に使用されるアルゴリズムに関してAppendix Aを見てください。 読者がチェックサムアルゴリズムの効率的な実装の記述のための[10]を見るよう奨励されます。
4.9 Addressing
4.9 アドレシング
CLNP uses OSI network service access point addresses (NSAPAs); NSAPAs serve the same identification and location functions as an IP address, plus the protocol selector value encoded in the IPv4 datagram header, and with additional hierarchy. General purpose
CLNPはOSIネットワーク・サービスアクセスポイントアドレス(NSAPAs)を使用します。 NSAPAsはIPアドレスとして同じ識別と位置の機能を果たして、IPv4データグラムヘッダー、および追加階層構造で値がコード化したプロトコルセレクタを果たします。 汎用
Piscitello [Page 8] RFC 1561 CLNP in TUBA Environments December 1993
チューバ環境1993年12月のPiscitello[8ページ]RFC1561CLNP
CLNP implementations MUST handle NSAP addresses of variable length up to 20 octets, as defined in ISO/IEC 8348 [11]. TUBA implementations, especially routers, MUST accommodate these as well. Thus, for compatibility and interoperability with OSI use of CLNP, the initial octet of the Destination Address is assumed to be an Authority and Format Indicator, as defined in ISO/IEC 8348. NSAP addresses may be between 8 and 20 octets long (inclusive).
CLNP実装はISO/IEC8348[11]で定義されるように20の八重奏までの可変長のNSAPアドレスを扱わなければなりません。 また、TUBA実装(特にルータ)はこれらを収容しなければなりません。 したがって、CLNPのOSI使用がある互換性と相互運用性において、Destination Addressの初期の八重奏はAuthorityとFormat Indicatorであると思われます、ISO/IEC8348で定義されるように。 長い間(包括的な)、NSAPアドレスは8〜20の八重奏であるかもしれません。
TUBA implementations MUST support both ANSI and GOSIP style addresses; these are described in RFC 1237 [12], and illustrated in Figure 4-2. RFC 1237 describes the ANSI/GOSIP initial domain parts as well as the format and composition of the domain specific part. It is further recommended that TUBA implementations support the assignment of system identifiers for TUBA/CLNP hosts defined in [13] for the purposes of host address autoconfiguration as described in [14]. Additional considerations specific to the interpretation and encoding of the selector part are described in sections 4.9.2 and 4.9.4.
TUBA実装はANSIとGOSIPの両方にスタイルアドレスをサポートしなければなりません。 これらは、RFC1237[12]で説明されて、図4-2で例証されます。 RFC1237はドメインの特定の部分の形式と構成と同様にANSI/GOSIPの初期のドメイン部分について説明します。 TUBA実装がホスト・アドレス自動構成の目的のための[13]で定義されたTUBA/CLNPホストのために[14]で説明されるようにシステム識別子の課題をサポートするのは、さらにお勧めです。 セレクタ部分の解釈とコード化に特定の追加問題はセクション4.9.2と4.9で.4に説明されます。
+-------------+
| <-- IDP --> |
+----+--------+----------------------------------+
|AFI | IDI | <-- DSP --> |
+----+--------+----+---+-----+----+-----+---+----+
| 47 | 0005 |DFI |AA |Rsvd | RD |Area |ID |Sel |
+----+--------+----+---+-----+----+-----+---+----+
octets | 1 | 2 | 1 | 3 | 2 | 2 | 2 | 6 | 1 |
+----+--------+----+---+-----+----+-----+---+----+
+-------------+ | <-- IDP-->。| +----+--------+----------------------------------+ |AFI| イディ| <-- DSP-->。| +----+--------+----+---+-----+----+-----+---+----+ | 47 | 0005 |DFI|AA|Rsvd| rd|領域|ID|Sel| +----+--------+----+---+-----+----+-----+---+----+ 八重奏| 1 | 2 | 1 | 3 | 2 | 2 | 2 | 6 | 1 | +----+--------+----+---+-----+----+-----+---+----+
Figure 4-2 (a): GOSIP Version 2 NSAP structure.
図4-2(a): GOSIPバージョン2NSAP構造。
+-------------+
|<-- IDP --> |
+----+--------+----------------------------------+
|AFI | IDI | <-- DSP --> |
+----+--------+----+---+-----+----+-----+---+----+
| 39 | 840 |DFI |ORG|Rsvd | RD |Area |ID |Sel |
+----+--------+----+---+-----+----+-----+---+----+
octets | 1 | 2 | 1 | 3 | 2 | 2 | 2 | 6 | 1 |
+----+--------+----+---+-----+----+-----+---+----+
+-------------+ | <-- IDP-->。| +----+--------+----------------------------------+ |AFI| イディ| <-- DSP-->。| +----+--------+----+---+-----+----+-----+---+----+ | 39 | 840 |DFI|ORG|Rsvd| rd|領域|ID|Sel| +----+--------+----+---+-----+----+-----+---+----+ 八重奏| 1 | 2 | 1 | 3 | 2 | 2 | 2 | 6 | 1 | +----+--------+----+---+-----+----+-----+---+----+
Figure 4-2 (b): ANSI NSAP address format for DCC=840
図4-2(b): DCC=840であることのANSI NSAPアドレス形式
Piscitello [Page 9] RFC 1561 CLNP in TUBA Environments December 1993
チューバ環境1993年12月のPiscitello[9ページ]RFC1561CLNP
Definitions:
IDP Initial Domain Part
AFI Authority and Format Identifier
IDI Initial Domain Identifier
DSP Domain Specific Part
DFI DSP Format Identifier
AA Administration Authority
ORG Organization Name (numeric form)
Rsvd Reserved
RD Routing Domain Identifier
Area Area Identifier
ID System Identifier
Sel NSAP Selector
定義: IDP Initial Domain Part AFI AuthorityとFormat Identifier IDI Initial Domain Identifier DSP Domain Specific Part DFI DSP Format Identifier AA政権Authority ORG Organization Name(数値フォーム)Rsvd Reserved RDルート設定Domain Identifier Area Area Identifier ID System Identifier Sel NSAP Selector
4.9.1 Destination Address Length Indicator
4.9.1 目的地アドレス長さのインディケータ
This field indicates the length, in octets, of the Destination Address.
この分野はDestination Addressの八重奏における長さを示します。
4.9.2 Destination Address
4.9.2 送付先アドレス
This field contains an OSI NSAP address, as described in Section 4.9. It MUST always contain the address of the final destination. (This is true even for packets containing a source route option, see Section 4.13.4).
この分野はセクション4.9で説明されるようにOSI NSAPアドレスを含んでいます。 それはいつも最終的な目的地のアドレスを含まなければなりません。 (セクション4.13.4は、送信元経路オプションを含むパケットにさえ、これが本当であることを見ます。)
The final octet of the destination address MUST always contain the value of the PROTO field, as defined in IP. The 8-bit PROTO field indicates the next level protocol used in the data portion of the CLNP datagram. The values for various protocols are specified in "Assigned Numbers" [15]. For the PROTO field, the value of zero (0) is reserved.
送付先アドレスの最終的な八重奏はIPで定義されるようにいつもプロト分野の値を含まなければなりません。 8ビットのプロト分野はCLNPデータグラムのデータ部で使用される次の平らなプロトコルを示します。 様々なプロトコルのための値は「規定番号」[15]で指定されます。 プロト分野において、(0)がない値は予約されています。
TUBA implementations that support TCP/UDP as well as OSI MUST use the protocol value (1Dh, Internet decimal 29) reserved for ISO transport protocol class 4.
オウシと同様にTCP/UDPをサポートするTUBA実装はISOトランスポート・プロトコルクラス4のために予約されたプロトコル値(1Dh、インターネット10進29)を使用しなければなりません。
4.9.3 Source Address Length Indicator
4.9.3 ソースアドレス長さのインディケータ
This field indicates the length, in octets, of the Source Address.
この分野はSource Addressの八重奏における長さを示します。
4.9.4 Source Address
4.9.4 ソースアドレス
This field contains an OSI NSAP address, as described in Section 4.9.
この分野はセクション4.9で説明されるようにOSI NSAPアドレスを含んでいます。
The final octet of the source address is reserved. It MAY be set to the protocol field value on transmission, and shall be ignored on reception (the value of zero MUST not be used).
ソースアドレスの最終的な八重奏は予約されています。 それは、トランスミッションのときにプロトコル分野価値に設定されるかもしれなくて、レセプションで無視されるものとします(ゼロの値を使用してはいけません)。
Piscitello [Page 10] RFC 1561 CLNP in TUBA Environments December 1993
チューバ環境1993年12月のPiscitello[10ページ]RFC1561CLNP
4.10 Data Unit Identifier
4.10 データユニット識別子
Like the Identification field of IP, this 16-bit field is used to distinguish segments of the same (original) packet for the purposes of reassembly. This field is present when the fragmentation permitted flag is set to one.
IPのIdentification分野のように、この16ビットの分野は、再アセンブリの目的のために同じ(オリジナル)のパケットのセグメントを区別するのに使用されます。 断片化の受入れられた旗が1つに設定されるとき、この分野は存在しています。
4.11 Fragment Offset
4.11断片は相殺されました。
Like the Fragment Offset of IP, this 16-bit is used to identify the relative octet position of the data in this fragment with respect to the start of the data submitted to CLNP; i.e., it indicates where in the original datagram this fragment belongs. The offset is measured in octets; the value of this field shall always be a multiple of eight (8). This field is present when the fragmentation permitted flag is set to one.
IPのFragment Offsetのように、この16ビットはCLNPに提出されたデータの始まりに関してこの断片のデータの相対的な八重奏位置を特定するのに使用されます。 すなわち、それは、オリジナルのデータグラムでは、この断片がどこで属するかを示します。 オフセットは八重奏で測定されます。 この分野の値はいつも8(8)の倍数になるでしょう。 断片化の受入れられた旗が1つに設定されるとき、この分野は存在しています。
4.12 Total Length
4.12 全長
The total length of the CLNP packet in octets is determined by the originator and placed in the Total Length field of the header. The Total Length field specifies the entire length of the original datagram, including both the header and data. This field MUST NOT be changed in any fragment of the original packet for the duration of the packet lifetime. This field is present when the fragmentation permitted flag is set to one.
八重奏における、CLNPパケットの全長は、創始者によって決定されて、ヘッダーのTotal Length分野に置かれます。 Total Length分野はヘッダーとデータの両方を含むオリジナルのデータグラムの全長を指定します。 パケット生存期間の持続時間のためにオリジナルのパケットのどんな断片でもこの分野を変えてはいけません。 断片化の受入れられた旗が1つに設定されるとき、この分野は存在しています。
4.13 Options
4.13 オプション
All CLNP options are "triplets" of the form <parameter code>, <parameter length>, and <parameter value>. Both the parameter code and length fields are always one octet long; the length parameter value, in octets, is indicated in the parameter length field. The following options are defined for CLNP for TUBA.
すべてのCLNPオプションがフォーム<パラメタコード>、<パラメタの長さの>、および<パラメタ価値の>の「三つ子」です。 長い間、いつもパラメタコードと長さの分野の両方が1つの八重奏です。 八重奏では、長さのパラメタ価値はパラメタ長さの分野で示されます。 以下のオプションはTUBAのためのCLNPのために定義されます。
4.13.1 Security
4.13.1 セキュリティ
The value of the parameter code field is binary 1100 0101. The length field MUST be set to the length of a Basic (and Extended) Security IP option(s) as identified in RFC 1108 [16], plus 1. Octet 1 of the security parameter value field -- the CLNP Security Format Code -- is set to a binary value 0100 0000, indicating that the remaining octets of the security field contain either the Basic or Basic and Extended Security options as identified in RFC 1108. This encoding points to the administration of the source address (e.g., ISOC) as the administration of the security option; it is thus distinguished from the globally unique format whose definition is reserved for OSI use. Implementations wishing to use a security option MUST examine the
パラメタコード分野の値は2進の1100 0101です。 長さの分野はRFC1108[16]、および1で特定されるようにBasic(そして、Extended)セキュリティIPオプションの長さへのセットであるに違いありません。 セキュリティパラメタ値の分野の八重奏1(CLNP Security Format Code)は2進の値0100 0000に設定されます、セキュリティ分野の残っている八重奏がRFC1108で特定されるようにBasicとBasicかExtended Securityオプションのどちらかを含むのを示して。 このコード化はセキュリティオプションの管理としてソースアドレス(例えば、ISOC)の管理を示します。 それは定義がOSI使用のために控えられるグローバルにユニークな形式とこのようにして区別されます。 オプションが調べなければならないaセキュリティを使用したがっている実装
Piscitello [Page 11] RFC 1561 CLNP in TUBA Environments December 1993
チューバ環境1993年12月のPiscitello[11ページ]RFC1561CLNP
PROTO field in the source address; if the value of PROTO indicates the CLNP client is TCP or UDP, the security option described in RFC 1108 is used.
ソースアドレスのプロト分野。 プロトの値が、CLNPクライアントがTCPかUDPであることを示すなら、RFC1108で説明されたセキュリティオプションは使用されています。
[Note: If IP options change, TUBA implementations MUST follow the new recommendations. This RFC, or revisions thereof, must document the new recommendations to assure compatibility.]
[以下に注意してください。 IPオプションが変化するなら、TUBA実装は新しい推薦に続かなければなりません。 このRFC、またはそれの改正が互換性を保証するという新しい推薦を記録しなければなりません。]
The formats of the Security option, encoded as a CLNP option, is as follows. The CLNP option will be used to convey the Basic and Extended Security options as sub-options; i.e., the exact encoding of the Basic/Extended Security IP Option is carried in a single CLNP Security Option, with the length of the CLNP Security option reflecting the sum of the lengths of the Basic and Extended Security IP Option.
CLNPオプションとしてコード化されたSecurityオプションの形式は以下の通りです。 CLNPオプションはサブオプションとしてBasicとExtended Securityオプションを伝えるのに使用されるでしょう。 すなわち、Basic/拡張しているSecurity IP Optionの正確なコード化は独身のCLNP Security Optionで運ばれます、CLNP Securityオプションの長さがBasicとExtended Security IP Optionの長さを反映していて。
+--------+--------+--------+--------+--------+---//----+-
|11000100|XXXXXXXX|01000000|10000010|YYYYYYYY| | ...
+--------+--------+--------+--------+--------+---//----+----
CLNP CLNP CLNP BASIC BASIC BASIC
OPTION OPTION FORMAT SECURITY OPTION OPTION
TYPE LENGTH CODE TYPE LENGTH VALUE
(197) (130)
+--------+--------+--------+--------+--------+---//----+- |11000100|XXXXXXXX|01000000|10000010|YYYYYYYY| | ... +--------+--------+--------+--------+--------+---//----+---- 基本的な基本的な基本的なCLNP CLNP CLNPのタイプ長さのコードタイプ長さのオプションオプション形式セキュリティオプションオプション価値(197)(130)
---+------------+------------+----//-------+
... | 10000101 | 000LLLLL | |
-----+------------+------------+----//-------+
EXTENDED EXTENDED EXTENDED OPTION
OPTION OPTION VALUE
TYPE (133) LENGTH
---+------------+------------+----//-------+ ... | 10000101 | 000LLLLL| | -----+------------+------------+----//-------+ 拡張拡張拡張オプションオプションオプション価値のタイプ(133)長さ
The syntax, semantics and processing of the Basic and Extended IP Security Options are defined in RFC 1108.
BasicとExtended IP Security Optionsの構文、意味論、および処理はRFC1108で定義されます。
4.13.2 Type of Service
4.13.2 サービスのタイプ
[Note: Early drafts recommended the use of IP Type of Service as specified in RFC 1349. There now appears to be a broad consensus that this encoding is insufficient, and there is renewed interest in exploring the utility of the "congestion experienced" flag available in the CLNP QOS Maintenance option. This RFC thus recommends the use of the QOS Maintenance option native to CLNP.]
早めの草稿は、今現れるRFC1349の指定されるとしてのServiceのIP Typeの使用がこのコード化が不十分であるという広いコンセンサスであることを推薦しました、そして、CLNP QOS Maintenanceオプションで利用可能な「経験された混雑」旗に関するユーティリティを探ることへの関心は更新されます。[注意: その結果、このRFCはCLNP固有のQOS Maintenanceオプションの使用を推薦します。]
The Quality of Service Maintenance option allows the originator of a CLNP datagram to convey information about the quality of service requested by the originating upper layer process. Routers MAY use this information as an aid in selecting a route when more than one route satisfying other routing criteria is available and the
Service MaintenanceオプションのQualityは起因している上側の層のプロセスによって要求されたサービスの質に関してCLNPデータグラムの創始者を情報を伝達させます。 そしてルータが援助として他のルーティング評価基準を満たす1つ以上のルートが利用可能であるときにルートを選択する際にこの情報を使用するかもしれない。
Piscitello [Page 12] RFC 1561 CLNP in TUBA Environments December 1993
チューバ環境1993年12月のPiscitello[12ページ]RFC1561CLNP
available routes are know to differ with respect to the following qualities of service: ability to preserve sequence, transit delay, cost, residual error probability. Through this option, a router may also indicate that it is experiencing congestion.
利用可能なルートはそうです。以下のサービスの品質に関して異なるのを知ってください: 系列(トランジット遅れ)がかかった保護区、見逃し誤り確率への能力。 また、このオプションで、ルータは、混雑を経験しているのを示すかもしれません。
The encoding of this option is as follows:
このオプションのコード化は以下の通りです:
+-----------+-----------+----------+
| 1100 0011 | 0000 0001 | 110ABCDE |
+-----------+-----------+----------+
CLNP QOS OPTION QOS FLAGS
TYPE (195) LENGTH
+-----------+-----------+----------+ | 1100 0011 | 0000 0001 | 110ABCDE| +-----------+-----------+----------+ CLNP QOSオプションQOSはタイプ(195)長さに旗を揚げさせます。
The value of the parameter code field MUST be set to a value of binary 1100 0011 (the CLNP Quality of Service Option Code point). The length field MUST be set to one (1).
2進の1100 0011(Service Option CodeポイントのCLNP Quality)の値にパラメタコード分野の値を設定しなければなりません。 1つ(1)に長さの分野を設定しなければなりません。
Bits 8-6 MUST be set as indicated in the figure. The flags "ABCDE" are interpreted as follows:
図にみられるようにビット8-6を設定しなければなりません。 旗"ABCDE"は以下の通り解釈されます:
A=1 choose path that maintains sequence over
one that minimizes transit delay
A=0 choose path that minimizes transit delay over
one that maintains sequence
B=1 congestion experienced
B=0 no congestion to report
C=1 choose path that minimizes transit delay over
over low cost
C=0 choose low cost over path that
minimizes transit delay
D=1 choose pathe with low residual error probability over
one that minimizes transit delay
D=0 choose path that minimizes transit delay over
one with low residual error probability
E=1 choose path with low residual error probability over
low cost
E=0 choose path with low cost over one with low
residual error probability
A=1は1つの上のA=0が系列B=1混雑を維持するものの上でトランジット遅れを最小にする経路を選ぶトランジット遅れを最小にする系列がC=1が低価格Cの上でトランジット遅れを最小にする経路を選ぶと報告する混雑がない=0がトランジットを最小にする経路に関して低価格を選ぶB=0になったと主張する経路を選びます; 遅れD=1は遅れD=0が1つの上に低価格がある状態で低価格Eの上に低見逃し誤り確率がある状態で=1が経路を選ぶという低見逃し誤り確率Eがある1以上=0が低見逃し誤り確率で経路を選ぶトランジット遅れを最小にする経路を選ぶというトランジットを最小にするより多くのものの低見逃し誤り確率があるpatheを選びます。
4.13.3 Padding
4.13.3 詰め物
The padding field is used to lengthen the packet header to a convenient size. The parameter code field MUST be set to a value of binary 1100 1100. The value of the parameter length field is variable. The parameter value MAY contain any value; the contents of padding fields MUST be ignored by the receiver.
詰め物分野は、便利なサイズにパケットのヘッダーを伸すのに使用されます。 2進の1100 1100の値にパラメタコード分野を設定しなければなりません。 パラメタ長さの分野の値は可変です。 パラメタ値はどんな値も含むかもしれません。 受信機で詰め物分野のコンテンツを無視しなければなりません。
Piscitello [Page 13] RFC 1561 CLNP in TUBA Environments December 1993
チューバ環境1993年12月のPiscitello[13ページ]RFC1561CLNP
+----------+----------+-----------+
| 11001100 | LLLLLLLL | VVVV VVVV |
+----------+----------+-----------+
+----------+----------+-----------+ | 11001100 | LLLLLLLL| VVVV VVVV| +----------+----------+-----------+
4.13.4 Source Routing
4.13.4 ソースルート設定
Like the strict source route option of IP, the Complete Source Route option of CLNP is used to specify the exact and entire route an internet datagram MUST take. Similarly, the Partial Source Route option of CLNP provides the equivalent of the loose source route option of IP; i.e., a means for the source of an internet datagram to supply (some) routing information to be used by gateways in forwarding the internet datagram towards its destination. The identifiers encoded in this option are network entity titles, which are semantically and syntactically the same as NSAPAs and which can be used to unambiguously identify a network entity in an intermediate system (router).
IPの厳しい送信元経路オプションのように、CLNPのComplete Source Routeオプションは、インターネットデータグラムが取らなければならない正確で全体のルートを指定するのに使用されます。 同様に、CLNPのPartial Source RouteオプションはIPのゆるい送信元経路オプションの同等物を提供します。 すなわち、インターネットデータグラムの源がゲートウェイによってインターネットデータグラムを目的地に向かって送る際に使用されるために(いくつか)のルーティング情報を提供する手段。 このオプションでコード化された識別子はネットワーク実体タイトルです。(そのタイトルをNSAPAsと意味的に、そして、シンタクス上同じであり、中間システム(ルータ)で明白にネットワーク実体を特定するのに使用できます)。
The parameter code for Source Routing is binary 1100 1000. The length of the source routing parameter value is variable.
Sourceルート設定のためのパラメタコードは2進の1100 1000です。 ソースルーティングパラメタ価値の長さは可変です。
The first octet of the parameter value is a type code, indicating Complete Source Routing (binary 0000 0001) or Partial Source Routing (binary 0000 0000). The second octet identifies the offset of the next network entity title to be processed in the list, relative to the start of the parameter (i.e., a value of 3 is used to identify the first address in the list). The offset value is modified by each router using a complete source route or by each listed router using a partial source route to point to the next NET.
パラメタ価値の最初の八重奏はタイプコードです、Complete Sourceルート設定(2進の0000 0001)かPartial Sourceルート設定(2進の0000 0000)を示して。 2番目の八重奏はリストで処理されるために次のネットワーク実体タイトルのオフセットを特定します、パラメタの始まりに比例して(すなわち、3の値はリストにおける最初のアドレスを特定するのに使用されます)。 オフセット値は、完全な送信元経路を使用する各ルータかそれぞれの記載されたルータによって次のNETを示すのに部分的な送信元経路を使用することで変更されます。
The third octet begins the list of network entity titles. Only the NETs of intermediate systems are included in the list; the source and destination addresses shall not be included. The list consists of variable length network entity title entries; the first octet of each entry gives the length of the network entity title that comprises the remainder of the entry.
3番目の八重奏はネットワーク実体タイトルのリストを始めます。 中間システムのNETsだけがリストに含まれています。 ソースと送付先アドレスを含んでいないものとします。 リストは可変長ネットワーク実体タイトルの入力から成ります。 それぞれのエントリーの最初の八重奏はエントリーの残りを包括するネットワーク実体タイトルの長さを与えます。
4.13.5 Record Route
4.13.5 ルートを記録してください。
Like the IP record route option, the Record route option of CLNP is used to trace the route a CLNP datagram takes. A recorded route consists of a list of network entity titles (see Source Routing). The list is constructed as the CLNP datagram is forwarded along a path towards its final destination. Only titles of intermediate systems (routers) that processed the datagram are included in the recorded route; the network entity title of the originator of the datagram SHALL NOT be recorded in the list.
IPの記録的なルートオプションのように、CLNPのRecordルートオプションは、CLNPデータグラムが取るルートをたどるのに使用されます。 記録されたルートはネットワーク実体タイトルのリストから成ります(Sourceルート設定を見てください)。 経路に沿って最終的な目的地に向かってCLNPデータグラムを送るとき、リストを構成します。 データグラムを処理した中間システム(ルータ)のタイトルだけが記録されたルートに含まれています。 実体が記録されたコネがリストであったならデータグラムSHALL NOTの創始者について題をつけるネットワーク。
Piscitello [Page 14] RFC 1561 CLNP in TUBA Environments December 1993
チューバ環境1993年12月のPiscitello[14ページ]RFC1561CLNP
The parameter code for Record Route is binary 1100 1011. The length of the record route parameter value is variable.
Record Routeのためのパラメタコードは2進の1100 1011です。 記録的なルートパラメタ価値の長さは可変です。
The first octet of the parameter value is a type code, indicating Complete Recording of Route (0000 0001) or Partial Recording of Route (0000 0000). When complete recording of route is selected, reassembly at intermediate systems MAY be performed only when all fragments of a given datagram followed the same route; partial recording of route eliminates or "loosens" this constraint.
パラメタ価値の最初の八重奏はタイプコードです、Route(0000 0001)のComplete RecordingかRoute(0000 0000)のPartial Recordingを示して。 ルートの完全な録音が選択されるとき、与えられたデータグラムのすべての断片が同じルートに従ったときだけ、中間システムの再アセンブリは実行されるかもしれません。 ルートの部分的な録音は、この規制を取り除くか、または「緩めます」。
The second octet identifies the offset where the next network entity title entry (see Source Routing) MAY be recorded (i.e., the end of the current list), relative to the start of the parameter. A value of 3 is used to identify the initial recording position. The process of recording a network entity title entry is as follows. A router adds the length of its network entity title entry to the value of record route offset and compares this new value to the record route list length indicator; if the value does not exceed the length of the list, entity title entry is recorded, and the offset value is incremented by the value of the length of the network entity title entry. Otherwise, the recording of route is terminated, and the router MUST not record its network entity title in the option. If recording of route has been terminated, this (second) octet has a value 255.
次のネットワーク実体タイトルの入力(Sourceルート設定を見る)が記録されるかもしれないところで(すなわち、現在のリストの終わり)2番目の八重奏はオフセットを特定します、パラメタの始まりに比例して。 3の値は、初期の録音位置を特定するのに使用されます。 ネットワーク実体タイトルの入力を記録するプロセスは以下の通りです。 ルータは、記録的なルートの値へのネットワーク実体タイトルの入力の長さが相殺されたのを高めて、記録的なルートリスト長さのインディケータにこの新しい価値をたとえます。 値がリストの長さを超えていないなら、実体タイトルの入力は記録されています、そして、オフセット値はネットワーク実体タイトルの入力の長さの値によって増加されます。 さもなければ、ルートの録音は終えられます、そして、ルータはネットワーク実体タイトルをオプションに記録してはいけません。 ルートの録音が終えられたなら、この(2番目)の八重奏には、値255があります。
The third octet begins the list of network entity titles.
3番目の八重奏はネットワーク実体タイトルのリストを始めます。
4.13.6 Timestamp
4.13.6 タイムスタンプ
[Note: There is no timestamp option in edition 1 of ISO/IEC 8473, but the option has been proposed and submitted to ISO/IEC JTC1/SC6.]
[注意: ISO/IEC8473の版1にはタイムスタンプオプションが全くありませんが、ISO/IEC JTC1/SC6にオプションを提案して、提出しました。]
The parameter code value 1110 1110 is used to identify the Timestamp option; the syntax and semantics of Timestamp are identical to that defined in IP.
パラメタコード値1110 1110はTimestampオプションを特定するのに使用されます。 Timestampの構文と意味論はIPで定義されたそれと同じです。
The Timestamp Option is defined in STD 5, RFC 791. The CLNP parameter code 1110 1110 is used rather than the option type code 68 to identify the Timestamp option, and the parameter value conveys the option length. Octet 1 of the Timestamp parameter value shall be encoded as the pointer (octet 3 of IP Timestamp); octet 2 of the parameter value shall be encoded as the overflow/format octet (octet 4 of IP Timestamp); the remaining octets shall be used to encode the timestamp list. The size is fixed by the source, and cannot be changed to accommodate additional timestamp information.
RFC791、Timestamp OptionはSTD5で定義されます。 CLNPパラメタコード1110 1110はTimestampオプションを特定するのにオプションタイプコード68よりむしろ使用されます、そして、パラメタ値はオプションの長さを伝えます。 Timestampパラメタ価値の八重奏1は指針(IP Timestampの八重奏3)としてコード化されるものとします。 パラメタ価値の八重奏2はオーバーフロー/形式八重奏(IP Timestampの八重奏4)としてコード化されるものとします。 残っている八重奏は、タイムスタンプリストをコード化するのに使用されるものとします。 サイズをソースが固定していて、追加タイムスタンプ情報に対応するために変えることができません。
Piscitello [Page 15] RFC 1561 CLNP in TUBA Environments December 1993
チューバ環境1993年12月のPiscitello[15ページ]RFC1561CLNP
+--------+--------+--------+--------+
|11101110| length | pointer|oflw|flg|
+--------+--------+--------+--------+
| network entity title |
+--------+--------+--------+--------+
| timestamp |
+--------+--------+--------+--------+
| . |
.
+--------+--------+--------+--------+ |11101110| 長さ| 指針|oflw|flg| +--------+--------+--------+--------+ | ネットワーク実体タイトル| +--------+--------+--------+--------+ | タイムスタンプ| +--------+--------+--------+--------+ | . | .
5. Error Reporting and Control Message Handling
5. 誤り報告とコントロールメッセージハンドリング
CLNP and IP differ in the way in which errors are reported to hosts. In IP environments, the Internet Control Message Protocol (ICMP, [7]) is used to return (error) messages to hosts that originate packets that cannot be processed. ICMP messages are transmitted as user data in IP datagrams. Unreachable destinations, incorrectly composed IP datagram headers, IP datagram discards due to congestion, and lifetime/reassembly time exceeded are reported; the complete internet header that caused the error plus (at least) 8 octets of the segment contained in that IP datagram are returned to the sender as part of the ICMP error message. For certain errors, e.g., incorrectly composed IP datagram headers, the specific octet which caused the problem is identified.
CLNPとIPは誤りがホストに報告される方法で異なります。 IP環境、インターネット・コントロール・メッセージ・プロトコル、(ICMP、[7])は、処理できないパケットを溯源するホストに(誤り)メッセージを返すのに使用されます。 ICMPメッセージは利用者データとしてIPデータグラムで送られます。手の届かない目的地、不当に落ち着いたIPデータグラムヘッダー、混雑によるIPデータグラム破棄、および超えられていた生涯/再アセンブリ時間は報告されます。 ICMPエラーメッセージの一部としてそのIPデータグラムに含まれたセグメントの8つの八重奏を誤りプラス(少なくとも)に引き起こした完全なインターネットヘッダーを送付者に返します。 ある誤り、例えば、不当に落ち着いたIPデータグラムヘッダーに関しては、問題を引き起こした特定の八重奏は特定されます。
In CLNP environments, an unique message type, the Error Report type, is used in the network layer protocol header to distinguish Error Reports from CLNP datagrams. CLNP Error Reports are generated on detection of the same types of errors as with ICMP. Like ICMP error messages, the complete CLNP header that caused the error is returned to the sender in the data portion of the Error Report. Implementations SHOULD return at least 8 octets of the datagram contained in the CLNP datagram to the sender of the original CLNP datagram. Here too, for certain errors, the specific octet which caused the problem is identified.
CLNP環境で、ユニークなメッセージタイプは、CLNPデータグラムとError Reportsを区別するのにネットワーク層プロトコルヘッダーで使用されます。Error Reportはタイプして、CLNP Error Reportsは誤りの同じタイプの検出のときにICMPのように生成されます。 ICMPエラーメッセージのように、誤りを引き起こした完全なCLNPヘッダーをError Reportのデータ部の送付者に返します。 実装SHOULDはCLNPデータグラムにオリジナルのCLNPデータグラムの送付者に含まれたデータグラムの少なくとも8つの八重奏を返します。 また、ここで、ある誤りにおいて、問題を引き起こした特定の八重奏は特定されます。
A summary of the contents of the CLNP Error Report, as it is proposed for use in TUBA environments, is illustrated in Figure 5-1:
それがTUBA環境における使用のために提案されるとき、CLNP Error Reportのコンテンツの概要は図5-1で例証されます:
Piscitello [Page 16] RFC 1561 CLNP in TUBA Environments December 1993
チューバ環境1993年12月のPiscitello[16ページ]RFC1561CLNP
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ........Data Link Header........ | NLP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Header Length | Version | Lifetime (TTL)| 000 | Type=ER |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TOTAL Length of Error Report | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Dest Addr Len | Destination Address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Destination Address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Destination Address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Destination Address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Destination Address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PROTO field | Src Addr Len | Source Address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Source Address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Source Address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Source Address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Source Address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Source Address | Reason for Discard (type/len) |
| | 1100 0001 | 0000 0010 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason for Discard | Options... |
| code | pointer | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options |
: :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data |
: :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ........データはヘッダーをリンクします… | NLP ID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |ヘッダ長| バージョン| 生涯(TTL)| 000 | =をタイプしてください、えー。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | エラー・レポートの全長| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Dest Addrレン| 送付先アドレス… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... 送付先アドレス… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... 送付先アドレス… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... 送付先アドレス… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... 送付先アドレス… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | プロト分野| Src Addrレン| ソースアドレス… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... ソースアドレス… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... ソースアドレス… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... ソースアドレス… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... ソースアドレス… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... ソースアドレス| 破棄(タイプ/len)の理由| | | 1100 0001 | 0000 0010 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 破棄の理由| オプション… | | コード| 指針| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | オプション| : : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | データ| : : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note that each tick mark represents one bit position.
各ダニ麻痺が1つのビット位置を表すことに注意してください。
Figure 5-1. Error Report Format
図5-1。 エラー・レポート形式
Piscitello [Page 17] RFC 1561 CLNP in TUBA Environments December 1993
チューバ環境1993年12月のPiscitello[17ページ]RFC1561CLNP
5.1 Rules for processing an Error Report
Error Reportを処理するための5.1の規則
The following is a summary of the rules for processing an Error Report:
↓これはError Reportを処理するための規則の概要です:
* An Error Report is not generated to report a problem
encountered while processing an Error Report.
* Error Reportは、Error Reportを処理している間に行きあたられる問題を報告するために生成されません。
* Error Reports MAY NOT be fragmented (hence, the
fragmentation part is absent).
* 誤りReportsは断片化されないかもしれません(したがって、断片化部分は欠けています)。
* The Reason for Discard Code field is populated with one of
the values from Table 5-1.
* Discard Code分野へのReasonは値の1つでTable5-1から居住されます。
* The Pointer field is populated with number of the first
octet of the field that caused the Error Report to be
generated. If it is not possible to identify the offending
octet, this field MUST be zeroed.
* Pointer分野はError Reportを生成した分野の最初の八重奏の数で居住されます。 怒っている八重奏を特定するのが可能でないなら、この分野のゼロを合わせなければなりません。
* If the Priority or Type of Service option is present in the
errored datagram, the Error Report MUST specify the same
option, using the value specified in the original datagram.
* ServiceオプションのPriorityかTypeがerroredデータグラムに存在しているなら、Error Reportは同じオプションを指定しなければなりません、オリジナルのデータグラムで指定された値を使用して。
* If the Security option is present in the errored datagram,
the Error Report MUST specify the same option, using the
value specified in the original datagram; if the Security
option is not supported by the intermediate system, no Error
Report is to be generated (i.e., "silently discard" the
received datagram).
* Securityオプションがerroredデータグラムに存在しているなら、Error Reportは同じオプションを指定しなければなりません、オリジナルのデータグラムで指定された値を使用して。 Securityオプションが中間システムで後押しされていないなら、どんなError Reportも発生させていることになっていません(すなわち、容認されたデータグラムを「静かに、捨てます」)。
* If the Complete Source Route option is specified in the
errored datagram, the Error Report MUST compose a reverse of
that route, and return the datagram along the same path.
* Complete Source Routeオプションがerroredデータグラムで指定されるなら、Error Reportはそのルートの逆を構成して、同じ経路に沿ってデータグラムを返さなければなりません。
Piscitello [Page 18] RFC 1561 CLNP in TUBA Environments December 1993
チューバ環境1993年12月のPiscitello[18ページ]RFC1561CLNP
5.2 Comparison of ICMP and CLNP Error Messages
5.2 ICMPとCLNPエラーメッセージの比較
Table 5-1 provides a loose comparison of ICMP message types and codes to CLNP Error Type Codes (values in Internet decimal):
テーブル5-1はICMPメッセージタイプとコードのゆるい比較をCLNP Error Type Codes(インターネットでは、小数を評価する)に供給します:
CLNP Error Type Codes | ICMP Message (Type, Code) ----------------------------------|------------------------------------ Reason not specified (0) | Parameter Problem (12, 0) Protocol Procedure Error (1) | Parameter Problem (12, 0) Incorrect Checksum (2) | Parameter Problem (12, 0) PDU Discarded--Congestion (3) | Source Quench (4, 0) Header Syntax Error (4) | Parameter problem (12, 0) Need to Fragment could not (5) | Frag needed, DF set (3, 4) Incomplete PDU received (6) | Parameter Problem (12, 0) Duplicate Option (7) | Parameter Problem (12, 0) Destination Unreachable (128) | Dest Unreachable,Net unknown (3, 0) Destination Unknown (129) | Dest Unreachable,host unknown(3, 1) Source Routing Error (144) | Source Route failed (3, 5) Source Route Syntax Error (145) | Source Route failed (3, 5) Unknown Address in Src Route(146) | Source Route failed (3, 5) Path not acceptable (147) | Source Route failed (3, 5) Lifetime expired (160) | TTL exceeded (11, 0) Reassembly Lifetime Expired (161) | Reassembly time exceeded (11, 1) Unsupported Option (176) | Parameter Problem (12, 0) Unsupported Protocol Version(177) | Parameter problem (12, 0) Unsupported Security Option (178) | Parameter problem (12, 0) Unsupported Src Rte Option (179) | Parameter problem (12, 0) Unsupported Rcrd Rte (180) | Parameter problem (12, 0) Reassembly interference (192) | Reassembly time exceeded (11, 1)
CLNP誤りタイプコード| ICMPメッセージ(タイプ、コード)----------------------------------|------------------------------------ 理由は(0)を指定しませんでした。| パラメタ問題(12、0)プロトコル手順誤り(1)| パラメタ問題(12、0)の不正確なチェックサム(2)| PDUが捨てたパラメタ問題(12、0)--混雑(3)| ソース焼き入れ(4、0)ヘッダー構文エラー(4)| Fragmentにおけるパラメタ問題(12、0)の必要性がそうすることができなかった、(5)| 必要で、DFセット(3、4)不完全なPDU容認された(6)を破片手榴弾で殺傷してください。| パラメタ問題(12、0)はオプション(7)をコピーします。| パラメタ問題(12、0)の目的地手の届かない(128)| Dest Unreachable、ネット未知(3、0)の目的地Unknown(129)| Dest Unreachable、ホスト未知(3、1)のソースルート設定Error(144)| ソースRouteは(3、5)ソースRoute Syntax Error(145)に失敗しました。| ソースRouteはSrc Route(146)で(3、5)未知のAddressに失敗しました。| ソースRouteは許容できる(147)ではなく、経路に失敗しました(3、5)。| ソースRouteは(3、5)生涯満期の(160)に失敗しました。| TTLは(11、0)Reassembly Lifetime Expired(161)を超えていました。| Reassembly時間はサポートされないOption(176)を超えていました(11、1)。| パラメタ問題(12、0)のサポートされないプロトコルバージョン(177)| パラメタ問題(12、0)のサポートされないSecurity Option(178)| パラメタ問題(12、0)のサポートされないSrc Rte Option(179)| パラメタ問題(12、0)のサポートされないRcrd Rte(180)| パラメタ問題(12、0)Reassembly干渉(192)| 超えられていたReassembly時間(11, 1)
Table 5-1. Comparison of CLNP Error Reports to ICMP Error Messages
5-1をテーブルの上に置いてください。 ICMPエラーメッセージへのCLNPエラー・レポートの比較
Note 1: The current accepted practice for IP is that source quench
should not be used; if it is used, implementations MUST
not return a source quench packet for every relevant packet.
TUBA/CLNP implementations are encouraged to adhere to these
guidelines.
注意1: IPがそのソース焼き入れであるので、現在の慣例を使用するべきではありません。 それが使用されているなら、実現はあらゆる関連パケットのためにソース焼き入れパケットを返さなければならないというわけではありません。 TUBA/CLNP実現がこれらのガイドラインを固く守るよう奨励されます。
Note 2: There are no corresponding CLNP Error Report Codes for the
following ICMP error message types:
- Protocol Unreachable (3, 2)
- Port Unreachable (3, 3)
[Note: Additional error code points available in the ER type
code block can be used to identify these message types.]
注意2: 以下のICMPエラーメッセージタイプのためのどんな対応するCLNP Error Report Codesもありません: - 手が届かない状態で(3、2)、議定書を作ってください--、ポート手の届かなさ(3、3)[注意: これらのメッセージタイプを特定するのにERタイプコードで利用可能なポイントが妨げる追加エラーコードを使用できます。]
Piscitello [Page 19] RFC 1561 CLNP in TUBA Environments December 1993
チューバ環境1993年12月のPiscitello[19ページ]RFC1561CLNP
6. Pseudo-Header Considerations
6. 疑似ヘッダー問題
A checksum is computed on UDP and TCP segments to verify the integrity of the UDP/TCP segment. To further verify that the UDP/TCP segment has arrived at its correct destination, a pseudo-header consisting of information used in the delivery of the UDP/TCP segment is composed and included in the checksum computation.
チェックサムは、UDP/TCPセグメントの保全について確かめるためにUDPとTCPセグメントで計算されます。 UDP/TCPセグメントの配送に使用される情報から成る疑似ヘッダーは、UDP/TCPセグメントが正しい目的地に到着したことをさらに確かめるために、チェックサム計算に構成されて、含まれています。
To compute the checksum on a UDP or TCP segment prior to transmission, implementations MUST compose a pseudo-header to the UDP/TCP segment consisting of the following information that will be used when composing the CLNP datagram:
トランスミッションの前にUDPかTCPセグメントでチェックサムを計算するために、実現はCLNPデータグラムを構成するとき使用される以下の情報から成るUDP/TCPセグメントに疑似ヘッダーを構成しなければなりません:
* Destination Address Length Indicator
* 目的地アドレス長さのインディケータ
* Destination Address (including PROTO field)
* 送付先アドレス(プロト分野を含んでいます)
* Source Address Length Indicator
* ソースアドレス長さのインディケータ
* Source Address (including Reserved field)
* ソースアドレス(Reserved分野を含んでいます)
* A two-octet encoding of the Protocol value
* プロトコル価値をコード化する2八重奏
* TCP/UDP segment length
* TCP/UDPセグメントの長さ
If the length of the {source address length field + source address +
destination address field + destination address } is not an integral
number of octets, a trailing 0x00 nibble is padded. If GOSIP
compliant NSAP addresses are used, this never happens (this is known
as the Farinacci uncertainty principle). The last byte in the
Destination Address has the value 0x06 for TCP and 0x11 for UDP, and
the Protocol field is encoded 0x0006 for TCP and 0x0011 for UDP. If
needed, an octet of zero is added to the end of the UDP/TCP segment
to pad the datagram to a length that is a multiple of 16 bits.
ソースアドレス長さの分野+ソースアドレス+目的地アドレス・フィールド+送付先アドレスの長さが整数の八重奏でないなら、引きずっている0×00少量がそっと歩いています。 GOSIP対応することのNSAPアドレスが使用されているなら、これは決して起こりません(これはファリナッチ不確定性原理として知られています)。 Destination Addressにおける最後のバイトには、TCPのための値0x06とUDPのための0×11があります、そして、プロトコル分野はコード化されます。TCPのための0×0006とUDPのための0×0011。 必要であるなら、ゼロの八重奏は、16ビットの倍数である長さにデータグラムを水増しするためにUDP/TCPセグメントの終わりに加えられます。
[Note: the pseudoheader is encoded in this manner to expedite processing, as it allows implementations to grab a contiguous stream of octets beginning at the destination address length indicator and terminating at the final octet of the source address; the PROTOCOL field is present to have a consistent representation across IPv4 and CLNP/TUBA implementations.]
[注意: pseudoheaderは処理を速めるためにこの様にコード化されます、実現がそれで目的地アドレス長さのインディケータで始まって、ソースアドレスの最終的な八重奏のときに終わる八重奏の隣接の流れをつかむことができるとき; プロトコル分野はIPv4とCLNP/TUBA実現の向こう側に一貫した表現を持つために存在しています。]
Piscitello [Page 20] RFC 1561 CLNP in TUBA Environments December 1993
チューバ環境1993年12月のPiscitello[20ページ]RFC1561CLNP
Figure 6-1 illustrates the resulting pseudo-header when both source and destination addresses are maximum length.
ソースと送付先アドレスの両方が最大の長さであるときに、図6-1は結果として起こる疑似ヘッダーを例証します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Dest Addr Len | Destination Address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Destination Address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Destination Address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Destination Address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Destination Address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (PROTO) | Src Addr Len | Source Address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Source Address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Source Address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Source Address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Source Address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | (Reserved) | Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP/TCP segment length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Dest Addrレン| 送付先アドレス… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... 送付先アドレス… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... 送付先アドレス… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... 送付先アドレス… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... 送付先アドレス… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (プロト) | Src Addrレン| ソースアドレス… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... ソースアドレス… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... ソースアドレス… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... ソースアドレス… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... ソースアドレス… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | (予約される)です。 | プロトコル| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UDP/TCPセグメントの長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6-1. Pseudo-header
図6-1。 疑似ヘッダー
7. Security Considerations
7. セキュリティ問題
ISO CLNP is an unreliable network datagram protocol, and is subject to the same security considerations as Internet Protocol ([5], [8]); methods for conveying the same security handling information recommended for IP are described in Section 4.13.1, Security Option.
ISO CLNPは頼り無いネットワークデータグラムプロトコルであり、インターネットプロトコル([5]と同じセキュリティ問題を受けることがあります、[8])。 Security Option、IPのために推薦された同じセキュリティ取り扱い情報を伝えるための方法はセクション4.13.1で説明されます。
Piscitello [Page 21] RFC 1561 CLNP in TUBA Environments December 1993
チューバ環境1993年12月のPiscitello[21ページ]RFC1561CLNP
8. Author's Address
8. 作者のアドレス
David M. Piscitello Core Competence 1620 Tuckerstown Road Dresher, PA 19025
デヴィッドM.Piscitelloコアコンピタンス1620Tuckerstown道路Dresher、PA 19025
Phone: 215-830-0692 EMail: wk04464@worldlink.com
以下に電話をしてください。 215-830-0692 メールしてください: wk04464@worldlink.com
9. References
9. 参照
[1] ISO/IEC 8473-1992. International Standards Organization -- Data
Communications -- Protocol for Providing the Connectionless
Network Service, Edition 2.
[1] ISO/IEC8473-1992。 世界規格組織(データ通信)は、サービス、版2をコネクションレスなネットワークに提供するために議定書を作ります。
[2] Callon, R., "TCP/UDP over Bigger Addresses (TUBA)", RFC 1347,
Internet Architecture Board, May 1992.
[2] Callon(R.、「より大きい上のTCP/UDPは(tuba)を記述する」RFC1347、インターネット・アーキテクチャ委員会)は1992がそうするかもしれません。
[3] Postel, J., "Transmission Control Protocol (TCP)", STD 7, RFC
793, USC/Information Sciences Institute, September 1981.
[3] ポステル、J.、「通信制御プロトコル(TCP)」、STD7、RFC793、科学が1981年9月に設けるUSC/情報。
[4] Postel, J., "User Datagram Protocol (UDP)", STD 6, RFC 768,
USC/Information Sciences Institute, September 1981.
[4] ポステル、J.、「ユーザー・データグラム・プロトコル(UDP)」、STD6、RFC768、科学が1981年9月に設けるUSC/情報。
[5] Postel, J., "Internet Protocol (IP)", STD 5, RFC 791,
USC/Information Sciences Institute, September 1981.
[5] ポステル、J.、「インターネットプロトコル(IP)」、STD5、RFC791、科学が1981年9月に設けるUSC/情報。
[6] Chapin, L., "ISO DIS 8473, Protocol for Providing the
Connectionless Network Service", RFC 994, March 1986.
[6] チェーピン、L.、「ISOは8473をけなして、コネクションレスなネットワーク・サービスを提供するために議定書を作る」(RFC994)は1986に行進します。
[7] Postel, J., "Internet Control Message Protocol (ICMP)", STD 5,
RFC 792, USC/Information Sciences Institute, September 1981.
[7] ポステル、J.、「インターネット・コントロール・メッセージ・プロトコル(ICMP)」、STD5、RFC792、科学が1981年9月に設けるUSC/情報。
[8] Braden, R., Editor, "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, Internet Engineering Task
Force, October 1989.
[8] ブレーデン、R.、エディタ、「インターネットホストのための要件--コミュニケーションは層にします」、STD3、RFC1122、インターネット・エンジニアリング・タスク・フォース、1989年10月。
[9] Hagens, R., "An Echo Function for ISO 8473", RFC 1139, IETF-OSI
Working Group, May 1993.
[9] Hagens(R.、「ISO8473のためのエコー機能」、RFC1139、IETF-OSI作業部会)は1993がそうするかもしれません。
[10] Sklower, K., "Improving the Efficiency of the ISO Checksum
Calculation" ACM SIGCOMM CCR 18, no. 5 (October 1989):32-43.
[10]Sklower、K.、「ISOチェックサム計算について能率を上げ」ACM SIGCOMM CCR18、No.5(1989年10月): 32-43。
[11] ISO/IEC 8348-1992. International Standards Organization--Data
Communications--OSI Network Layer Service and Addressing.
[11] ISO/IEC8348-1992。 世界規格組織--データ通信--OSIネットワーク層サービスとアドレシング。
Piscitello [Page 22] RFC 1561 CLNP in TUBA Environments December 1993
チューバ環境1993年12月のPiscitello[22ページ]RFC1561CLNP
[12] Callon, R., Gardner, E., and R. Hagens, "Guidelines for OSI NSAP
Allocation in the Internet", RFC 1237, NIST, Mitre, DEC, July
1991.
[12]Callon、R.、ガードナー、E.、およびR.Hagens、「インターネットのオウシNSAP Allocationのためのガイドライン」、RFC1237、NIST、斜め継ぎ、12月(1991年7月)。
[13] Piscitello, D., "Assignment of System Identifiers for TUBA/CLNP
Hosts", RFC 1526, Bellcore, September 1993.
[13]Piscitello、D.、「チューバ/CLNPホストへのシステム識別子の課題」、RFC1526、Bellcore、1993年9月。
[14] ISO/IEC 9542:1988/PDAM 1. Information Processing Systems -- Data
Communications -- ES/IS Routeing Protocol for use with ISO CLNP
-- Amendment 1: Dynamic Discovery of OSI NSAP Addresses by End
Systems.
[14] ISO/IEC9542: 1988/PDAM1。 情報Processing Systems--データCommunications--ES/はISO CLNPとの使用のためのRouteingプロトコルです--、修正1: オウシNSAPのダイナミックな発見は終わりでシステムを記述します。
[15] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340
USC/Information Sciences Institute, July 1992.
[15] RFC1340USC/情報科学が1992年7月に設けるレイノルズ、J.、およびJ.ポステル、「規定番号」、STD2。
[16] Kent, S., "Security Option for IP", RFC 1108, BBN Communications,
November 1991.
[16] ケント、S.、「IPのためのセキュリティオプション」、RFC1108、BBNコミュニケーション、1991年11月。
Piscitello [Page 23] RFC 1561 CLNP in TUBA Environments December 1993
チューバ環境1993年12月のPiscitello[23ページ]RFC1561CLNP
Appendix A. Checksum Algorithms (from ISO/IEC 8473)
付録A.チェックサムアルゴリズム(ISO/IEC8473からの)
Symbols used in algorithms:
シンボルはアルゴリズムで使用しました:
c0, c1 variables used in the algorithms
i position of octet in header (first
octet is i=1)
Bi value of octet i in the header
n position of first octet of checksum (n=8)
L Length of header in octets
X Value of octet one of the checksum parameter
Y Value of octet two of the checksum parameter
c0、変数が私が置くチェックサムパラメタの八重奏twoのチェックサムパラメタY Valueの八重奏1の八重奏X Valueのヘッダーのチェックサム(n=8)L Lengthの最初の八重奏のヘッダーn位置の八重奏iのヘッダー(最初の八重奏はi=1である)の両性愛者の値における八重奏のアルゴリズムで使用したc1
Addition is performed in one of the two following modes:
添加は2つの次のモードの1つで実行されます:
* modulo 255 arithmetic;
* 法255演算。
* eight-bit one's complement arithmetic;
* 8ビットの1の補数演算。
The algorithm for Generating the Checksum Parameter Value is as follows:
Generating Checksum Parameter Valueのためのアルゴリズムは以下の通りです:
A. Construct the complete header with the value of the
checksum parameter field set to zero; i.e., c0 <- c1 <- 0;
A. ゼロに設定されたチェックサムパラメタ分野の値で完全なヘッダーを組み立ててください。 すなわち、c0<c1<0。
B. Process each octet of the header sequentially from i=1 to L
by:
B. 以下でi=1からLまでヘッダーの各八重奏を連続して処理してください。
* c0 <- c0 + Bi
* c0、<c0+両性愛者
* c1 <- c1 + c0
* c1<c1+c0
C. Calculate X, Y as follows:
C. X、以下のYについて計算してください:
* X <- (L - 8)(c0 - c1) modulo 255
* X<(L--8)(c0--c1)法255
* Y <- (L - 7)(-C0) + c1
* Y<(L--7)(-C0)+c1
D. If X = 0, then X <- 255
D.はXであるなら0、当時のX<255と等しいです。
E. If Y = 0, then Y <- 255
E.はYであるなら0、当時のY<255と等しいです。
F. place the values of X and Y in octets 8 and 9 of the
header, respectively
F. それぞれヘッダーの八重奏8と9にXとYの値を置いてください。
The algorithm for checking the value of the checksum parameter is as follows:
チェックサムパラメタの値をチェックするためのアルゴリズムは以下の通りです:
Piscitello [Page 24] RFC 1561 CLNP in TUBA Environments December 1993
チューバ環境1993年12月のPiscitello[24ページ]RFC1561CLNP
A. If octets 8 and 9 of the header both contain zero, then the
checksum calculation has succeeded; else if either but not
both of these octets contains the value zero then the
checksum is incorrect; otherwise, initialize: c0 <- c1 <- 0
A. ヘッダーの八重奏8と9がともにゼロを含んでいるなら、チェックサム計算は成功しました。 ほかに、両方ではなく、これらの八重奏のどちらかが値ゼロを含んでいるなら、チェックサムは不正確です。 さもなければ、以下を初期化してください。 c0<c1<0
B. Process each octet of the header sequentially from i = 1 to
L by:
B. 以下でi=1からLまでヘッダーの各八重奏を連続して処理してください。
* c0 <- c0 + Bi
* c0、<c0+両性愛者
* c1 <- c1 + c0
* c1<c1+c0
C. When all the octets have been processed, if c0 = c1 = 0,
then the checksum calculation has succeeded, else it has
failed.
C. すべての八重奏を処理してあるとき、c0がc1=0と等しいなら、チェックサム計算は成功して、ほかに、それは失敗しました。
There is a separate algorithm to adjust the checksum parameter value when a octet has been modified (such as the TTL). Suppose the value in octet k is changed by Z = newvalue - oldvalue. If X and Y denote the checksum values held in octets n and n+1 respectively, then adjust X and Y as follows:
八重奏が変更されたときチェックサムパラメタ価値を調整する別々のアルゴリズム(TTLなどの)があります。 八重奏kにおける値はZ=newvalueによって変えられます--oldvalueと仮定してください。 XとYが八重奏nとnで+1 それぞれ保持されたチェックサム値を指示するなら、Xと以下のYを調整してください:
If X = 0 and Y = 0 then do nothing, else if X = 0 or Y = 0 then the checksum is incorrect, else:
Xが0かY=0と等しく、次に、X=0とY=0が何もしないなら、ほかに、チェックサムは不正確ですほかです:
X <- (k - n - 1)Z + X modulo 255
X<(k--n--1)Z+X法255
Y <- (n - k)Z + Y modulo 255
Y<(n--k)Z+Y法255
If X = 0, then X <- 255; if Y = 0, then Y <- 255.
Xが0、当時のX<255と等しいなら。 Y=0であるなら、そして、Y<255です。
In the example, n = 89; if the octet altered is the TTL (octet 4), then k = 4. For the case where the lifetime is decreased by one unit (Z = -1), the assignment statements for the new values of X and Y in the immediately preceeding algorithm simplify to:
例、n=89で。 変更された八重奏がTTL(八重奏4)であるなら、次に、k=4です。 寿命が減少する1ユニット(Zは-1と等しい)、すぐにpreceedingしているアルゴリズムによるXとYの新しい値のための割り当て文が以下のことのために簡素化するケースのために
X <- X + 5 Modulo 255
X<X+5法255
Y <- Y - 4 Modulo 255
Y<Y--4 法255
Piscitello [Page 25]
Piscitello[25ページ]
一覧
スポンサーリンク
